OpenVMS Notes: Linux

  1. The information presented here is intended for educational use by qualified computer technologists.
  2. The information presented here is provided free of charge, as-is, with no warranty of any kind.
  3. Is this text too small? You have two options:
    1. hold down the CTRL key while rolling the mouse wheel (zoom-in, zoom-out)
    2. use your keyboard like so:
      • hit: CTRL with "-" key to zoom smaller
      • hit: CTRL with "+" key to zoom larger
      • hit: CTRL with zero key to reset zoom
Edit: 2018-08-06 (updated real-world problems)

Introduction (Linux on an OpenVMS information page?)


Okay so everyone reading this already knows that OpenVMS is an operating system which competes with Unix and Linux so why did I include this topic as part of OpenVMS Notes?


  1. We were running MariaDB-5.5-25 on OpenVMS and where experiencing shutdown-related problems associated with very large databases using the InnoDB Engine (which masquerades as the XtraDB Engine). Many self-support blogs claim these issues can be fixed by upgrading to MariaDB-10 which is not (yet) available on OpenVMS. So setting up a nearby Linux box with MariaDB-10.1-19 on it would allow us to verify if the problem was fixed
    note: we intended to test "MariaDB-10 on Linux" from our OpenVMS business system. All you need to do is modify the client connect strings on the OpenVMS side to send requests to the Linux box via a private network. We opted to use an OpenVMS "logical name". Easy-peasy!
  2. Computer industry know-it-alls assert that every computer professional should be familiar with at least five computer languages and/or scripting environments. A similar case could be made for familiarity with 3-4-5 operating systems. These additional skills should translate directly into increased job security and employability (Happy Wife = Happy Life).
  3. Linux is the fastest growing computer ecosystem with 50% of all the computer systems on the planet are already running some sort of Linux. Got an Android phone? Android is a stripped-down version of Linux.

Reality Checks

OpenVMS is just as fast on modern hardware as UNIX or Linux. Quick installation time, ease of use, and stability have convinced me that OpenVMS is the superior OS. On top of this, OpenVMS does a much better job managing virtual memory (read on)

Linux has been the plaything of academia for a decade or two now which means it Linux is more feature-rich than proprietary operating systems, but it is not friendly. In fact it suffers from the problem of "too many chefs". What follows are a few examples of many.

Caveat: if you decide to enter the Linux world without a paid-up annual support contract then be prepared to support yourself. The self-help blogs are full of people "repeating the same mistakes" or "giving the same bad advice". Many do not appear (to me) to be seasoned computer professionals.

Performance Issues (a very small summary)

Editing a file on Linux

note: other editors exist but these are the only two I encountered during recent Linux installations

Different Linux distros use different commands to do similar things

The only thing common with the various Linux distributions is the name "Linux". For example, numerous Linux distributions use a different tool to partition a hard-disk. For example, check out the following list of commands to initialize then mount a disk.

OS Details

Initializing then mounting a disk in Windows is mostly automatic

OpenVMS Initializing then mounting a disk in OpenVMS is done in two commands:
  • initialize the disk:
       initialize/structure=5  disk-name:  volume-label
  • mount the disk:
       mount  disk-name:  volume-label
Note: online help is targeted at non-experts. Type "help initialize" or "help mount" from DCL to see what I mean
Linux In Linux you must do the following (incomplete list):
  • use either fdisk or parted to partition the disk (and know why you would use one over the other; most Linux systems only support one of these commands)
  • use mkfs (then choose one of 50+ volume formats); I prefer mkfs.xfs for most Linux volumes but formats like vfat and NTFS are available for those people requiring compatibility with Windows
  • use xfs_admin to set the volume label
  • use mkdir /mnt/whatever     (to create a mount point)
  • use mount /dev/sda3 /mnt/whatever
  • edit /etc/fstab                      (to force an automatic mount during the next reboot)
  • caveat: newer Linux distros also support LVM (Logical Volume Manager) which can increase overall confusion.
Note: online help is meant for experts. Type "man mount" or "man umount" to see what I mean. 

comment: For those of us who have worked on systems initially set up by, or previously maintained by, the clueless, perhaps a less friendly software environment is desirable.

Software Updates (support)



The Platform Name Game: x86, x86-64, x64, ia64, etc.

Getting Linux for an HP Integrity rx2660

Linux IA64 distributions list by most recently published update

Gentoo Linux @ Wikipedia

Debian Linux @ Wikipedia

FreeBSD @ Wikipedia

SuSE @ Wikipedia

CentOS @wikipedia

Ease of Install (Easiest First)

  OS Type install
1 OpenVMS binary 100% 100% < 1 hour
  • while OpenVMS is not a version of Linux or Unix,
    it still occupies the top spot for ease of installation
2 SuSE binary 100% 100% 1-2 hours
  • a pc-based terminal emulator is required; a real VT monitor will not work
  • elilo setup was done for me including the boot manager entry (cool)
3 CentOS binary 100% 100% 1-2 hours
  • elilo setup was done for me including the boot manager entry (cool)
  • this is a very old offering from 2008 so did not offer a version of MariaDB
4 Debian binary 100% 95% 2-3 hours
  • installation failed in the final phase (elilo setup); I had to to it manually
5 FreeBSD binary 100% 90% 2-3 hours
  • appeared to install in under 30 minutes. But then I discovered ...
  • that the installer never bothered to create a boot partition.
  • you need to do a manual partitioning using gpart (very unfriendly)
  • you will need to format the partitions with newfs
  • no elilo-like tools exist so you will be setting up the boot partition manually
9 Gentoo source build 5% n/a > 7 hours
  • after the initial boot, the run-time environment quickly shifts to the VGA monitor
  • installation instructions were spotty so I learned a lot the hard way
  • not recommended for anyone other than experts and/or hackers
  • provided the greatest amount of fun and frustration
  • When I finally got this working I was reminded of a line from the movie This Island Earth where the alien says: "you have assembled an interocitor; a feat which few men are capable"

Gentoo comments, caveats, and gotchas


  1. Type very carefully. This command "tar --help" passes one switch to tar while this command "tar -help" passes four switches (h, e, l, p) and will just ignore anything it does not understand
  2. Lots of UNIX sites published their own Gentoo installation guides but you would be wise to ignore everything published before 2014 because that year Gentoo went through major changes
  3. Using "parted" to partition your disks
  4. The Gentoo handbooks I tried (x86, amd64, ia64) in 2016 all work properly but are not 100% accurate
  5. If you do not execute the "swapon /dev/sda2" command, tar will fail when it unpacks the stage3 tarball
  6. Do not modify file "make.conf" in the IA64 version. Just inserting "-march=native" will cause numerous errors
    1. I checked out gcc on other Gentoo distros including i486, i586 and i686 but none of them ever mention (in the help) using "-march=native" although writing a simple hello-world.c program then compiling with "-march=native" seems to work. But the output appeared to be the same as not using the switch at all
    2. The Gentoo installation manual seems to infer that switches "-march" and "-mtune" are synonyms but they are not. The first switch selects the CPU architecture (eg. i586) while the second switch selects a specific optimization within the specified architecture (eg. pentiumiii)
    3. The IA64 version of gcc in 2016 does not support the "-march" switch because this compiler can only generate Itanium code. Viewing verbose help indicates that switch "-mtune" can have only two values: "itanium1" or "itanium2" with the compiler defaulting to "itanium2".
      • if you are seeing a lot of build errors then try using switch "-mtune=itanium1"
      • HP appears to have stopped working on Linux source code (at least from what I can see in the comments area of the IA64 kernel). I can only assume that they worried that free Linux would hurt sales of their own proprietary UNIX product called HP-UX
  7. Many people skip chapter #3 (setting up the network) because it auto-configures via dhcp during the CD or DVD boot. However, you still must copy "/etc/resolv.conf" to the Gentoo hard drive before you execute "chroot". Why? After you execute "chroot" you will be isolated from the previous environment. Failure to do this will cause file retrieval failures when you execute "emerge-webrsync"
  8. The IA64 Handbook is missing this command in chapter #4
        mkfs.vfat /dev/sda1
    which is required before copying your boot loader in chapter #10. Do not forget to mount this volume before executing "elilo --efiboot" (or consider setting up the boot partition manually; that's what I did on Gentoo as well as Debian
  9. After you issue chroot I suggest you issue the passwd command for root. Failure to do this now will cause problems during your first boot in chapter #11
  10. On your first kernel build you would be wise to do an automatic build via command "genkernel all". This will produce a kernel similar to the one associated with the CD ROM (will auto-detect hardware but boot a little slower). Once everything works properly you could try "make menuconfig" on a subsequent build.
  11. The file elilo.efi found on the Gentoo hard-drive is corrupt so copy the file used by the CD or DVD
  12. Here are the contents of elilo.conf on the boot partition (worked on 2016-0-xx)
      append="initrd=initramdisk root=/dev/sda3"
    and here are the contents of neil.msg on the boot partition (just a simple text file)
        gentoo1  (gentoo with ram disk)
        gentoo2  (standalone)

Debian comments, caveats, and gotchas

What's up with elilo on Linux distros?

Overview 2016

Installing CentOS-5 on an HP ProLiant DL360-g5 (gen 5 cpu)

date: 2016.09.xx

Installing CentOS-6 on an HP ProLiant DL380-g6 (gen 6 cpu)

date: 2016.10.xx

date: 2017.01.xx

Installing CentOS-7 on an HP ProLiant ML370-g6 (gen 6 cpu)

date: 2016.12.xx

LVM (Logical Volume Manager)

Anyone who has moved to CentOS-7 will notice that the primary Linux partition has been mounted using LVM (Logical Volume Manager)


Installing CentOS-7 on an HP ProLiant  DL385-g7  (gen 7 cpu)

date: 2017.02.xx

Installing CentOS-7 on an HP ProLiant  DL385p Gen8  (gen 8 cpu)

date: 2018.07.xx

OpenVMS-Linux System Hybrid

as of this writing (2017.01.xx)

		+------------------------+	+--------------------------+
		| server : HPE rx2800-i2 |	| server : HP ML370-G6     |
		| OS     : OpenVMS-8.4   |	| OS     : CentOS-7        |
		| purpose: business s/w  |	| purpose: MariaDB-10.1.19 |
		| net-1  : TCP/IP        +------+ net-1  : TCP/IP          |
 private  ------+ net-2  : TCP/IP        |	+--------------------------+
 intranet	| net-3  : DECnet        +------> other OpenVMS systems
		| net-4  : DECnet        +------> other OpenVMS systems 

Real-world Linux Problems

1) We can not install or update software via YUM on one of our CentOS-7 platforms

We have two Linux platforms; one for development and one for production (comment: with Linux this may not be enough; see comments in this next section). The recommended approach is to first install (or update) software on the development box. If testing reveals everything is working properly then we would repeat the procedure on the production box. This also keeps both platforms more-or-less in sync.

I wanted to install the tree utility so I logged onto the development box where I entered this command:

	sudo yum install tree

... which worked properly. Then I repeated this command on the production platform which failed with numerous errors associated with file /usr/libexec/urlgrabber-ext-down which is a python script. What was worse was this: you could not execute most yum commands including "yum check-update". Investigating further, I noticed that someone had installed python3 then updated the symbolic link so that the python command pulls up python3 rather than python2

There are only two ways out of this problem (remember that this is an active business system).

  1. modify the symbolic link for "python" and point it at the symbolic link "python2" which probably points to a directory like python2.6. This will restore the system to its previous functionality but could break something if newer applications required python3 to be the default
  2. modify the first line (the shebang or sharp-bang hack line) from this "#! /usr/bin/python" to this "#! /usr/bin/python2"

It is safer to go with choice-2 for now then do choice-1 after you talk to your developers then test the changes on a qualification system before putting into production. Failure to go back to choice-1 will cause other problems. For example, you will not be able to execute firewall-cmd from either the command line or gnome desktop.

# 1) this is an example of a good working setup with two versions of python installed
# 2) notice (on the first result line) that python is pointing to python2
#    and python2 is pointing to python2.7
# 3) if yum and firewall-cmd require python2 then you would have thought the
#    developers would have modified their respective shebang lines
$ cd /usr/bin
$ ls pytho* -la
lrwxrwxrwx. 1 root root     7 Jan 12 15:25 python -> python2
lrwxrwxrwx. 1 root root     9 Dec 20  2016 python2 -> python2.7
-rwxr-xr-x. 1 root root  7136 Nov  5  2016 python2.7
lrwxrwxrwx. 1 root root     9 Apr 12  2017 python3 -> python3.4
-rwxr-xr-x. 2 root root 11312 Jan 17  2017 python3.4
lrwxrwxrwx. 1 root root    17 Apr 12  2017 python3.4-config -> python3.4m-config
-rwxr-xr-x. 2 root root 11312 Jan 17  2017 python3.4m
-rwxr-xr-x. 1 root root   173 Jan 17  2017 python3.4m-config
-rwxr-xr-x. 1 root root  3366 Jan 17  2017 python3.4m-x86_64-config
lrwxrwxrwx. 1 root root    16 Apr 12  2017 python3-config -> python3.4-config

2) Never use a graphical console to update Linux software

I have experienced several instances where updating software though a graphical interface fails for some reason then breaks the graphical interface. It should not surprise anyone that updating gnome-session, or any of its dependencies, might disturb the very session that is running yum or rpm

So if you are on the system console (which is almost always a VGA monitor) and want to move to non-graphical session, try one of the following keystrokes:

key press description notes
CTRL ALT F2 switch to terminal 2 (/dev/tty2) text only
CTRL ALT F3 switch to terminal 3 (/dev/tty3) text only
CTRL ALT F4 switch to terminal 4 (/dev/tty4) text only
CTRL ALT F5 switch to terminal 5 (/dev/tty5) text only
CTRL ALT F6 switch to terminal 6 (/dev/tty6) text only
CTRL ALT F1 switch to terminal 1 (the graphical interface) only graphical when runlevel > 3

The only other way to safely disable graphics is to lower the runlevel of your system to 3. (but only do this if you are certain that you won't kill some process currently needed by your customers)

3) Using Windows to access a Linux remote

The self-help blogs really fall down on this one because the only secure way to do this is to tunnel x-sessions over SSH. But whenever anyone on a self-help blog asks how to do this only using SSH, some idiot will chime in with a procedure on how to do it using VNC, RealVNC, TigerVNC or Vino which are all insecure.


CygWin and CygWin/X

4) Recovering a failed YUM update (2018-01-xx)

5) a recent (2018-01-xx) YUM update broke our development box (ouch!)

Caveat: the procedure just given will only fix the OpenSSL CLI. Note that msodbcsql will still be broken because that software calls routines in the shared libraries. To fix msodbcsql you (supposedly) need to do one of the following:

  1. fully install an older version of OpenSSL (libraries and all) in a secondary location then ensure all scripts invoking sqlcmd look there
    • I built an older version of OpenSSL from source code then installed it in /opt/oldopenssl
    • all scripts starting sqlcmd first define LD_LIBRARY_PATH to point to /opt/oldopenssl/lib
    • although strace proves that msodbcsql is first looking in a secondary location, msodbcsql still does not work
  2. completely replace the new version of OpenSSL (libraries and all) with an older version
    • playing with yum downgrade openssl* has not yet worked but I think I may be close
  3. reinstall the previous OS (CentOS-7.2 in this case)

6) a recent (2018-06-xx) update broke our production box (a major pain!)

One of our developers was experiencing problems developing a new LDAP-based application. So he invoked YUM to update LDAP on our production box. The big problem here is that the update was done in a careless way (without reading all the release notes). So the LDAP update also updated OpenSSL for the whole system so now we can no longer connect to that older Microsoft platform in Montreal. (see: this previous note)

It now appears that we will need to install a third CentOS platform whose only purpose would be to reach through to the older Microsoft platform. This platform would need to be modified so that it could never been updated.

Customer-owned IBM-managed data centers

Hardware is relatively inexpensive in 2018 (compared with systems before y2k) and operating systems like CentOS-7 are free which changes everything. As I understand it, many customer-owned IBM-managed data centers are run like this:

Comparing Linux problems to other operating systems

I have been a VMS system admin since 1987 then started to work with OpenVMS in 1999. On VMS or OpenVMS, I have always been able to roll back an update. But this appears to be impossible (or at least very difficult) with modern versions of Linux in 2018.




 comment: everyone reading this probably knows that software cannot be updated on most computer systems while it is being used. This is not true of OpenVMS where an active process has a run-time lock on some executable (like sys$exe:EDT.EXE;4 in the example above). But if your update is just copying in a newer version of EDT.EXE then it would be saved as EDT.EXE;5. Any process invoking EDT would pick up the new file while current processes could continue to use the old file. I have never seen anything like this on any other operating system.

Recommended Books

How Linux Works: What Every Superuser Should Know - 2nd Edition (2015) Brian Ward

The Linux Programming Interface (2010) Michael Kerrisk
A Linux and UNIX System Programming Handbook

External Links

Back to OpenVMS
 Back to Home
Neil Rieck
Kitchener - Waterloo - Cambridge, Ontario, Canada.