Fancy trying the granddaddy of Windows NT for free? Now's your chance VMS Software Inc (VSI) has opened its hobbyist licensing scheme for the x86-64 version of one of the most reliable OSes in the business. The slow-but-steady migration of OpenVMS onto commodity x86 kit has passed a couple of significant milestones. A year ago, we covered the release of OpenVMS 9.2, the first production-ready …
Remember - some people do not have the source code for software they depend on. Although I would expect that by now they would have had to buy themselves into another lock in relationship with a different vendor.
About all I remember of VMS is that every time the team dealing with it got a new hire someone would have to deal with a machine clogged up by a full disk because VMS defaults to creating new versions of files instead of overwriting.
“ About all I remember of VMS is that every time the team dealing with it got a new hire someone would have to deal with a machine clogged up by a full disk because VMS defaults to creating new versions of files instead of overwriting.”
So the team didn’t seem to know about (proactive) version limits available on files and/or directories? I remember teaching that in the “VMS Utilities and Command” course when working at Digital.
Indeed. I used VMS for a few university classes, and one of the first things students were shown was how the file versioning worked, and how many versions our accounts were configured to keep. (Three, if memory serves, which was enough to protect from accidents and few enough to teach an important lesson about backing things up.)
"Can anyone explain why, with spinnign rust costing $10/Tb we don't have VMS-style versioning filesystems on PCs?"
Because all the PC operating systems are utter shit, apart from the BSDs. Admittedly the BSDs don't do versioning filesystems of course but instead offer decent user-level tools for version control. Which is where that cruft belongs. It doesn't go in the kernel.
BTW the cost of spinning rust isn't the issue. It's the cost of supporting and maintaining zillions of lines of buggy bloatware that shouldn't be in the kernel. Which explains why nobody else has done this since VMS died. [Apart from a handful of icky niche platforms like ClearCase.] If that (bad) idea had any merit, it would be in all of today's operating systems. It isn't. QED.
Rather than it being done at the file system level, M$ offer this as part of Sharepoint etc. instead.
Cruddy sharepoint implementation aside, it is a rather useful function to have, particularly where you can see WHO and WHEN someone screwed up your file.
I do find it hilarious that an OS that had it's commercial release in the 1970's offered this functionality when disk space was at an absolute premium.
It's also useful if ransomware encrypts a bunch of files and you can always revert back to a previous unencrypted version.
Or get the original file from a data corruption incident.
Or get back the version which was not accidentally overwritten.
Or get back the file after accidentally deleting it (not really file versioning, but some systems keep a deleted file for X period of time before purging as part of versioning).
I know my Synology NAS has those functions and it's proven useful when someone does something boneheaded.
It's an idea that comes up periodically. AFS, at least the setup I used, provided a read-only view of the previous day's backup mounted as a "yesterday" filesystem.
SCO OpenServer's HTFS did VMS-style versioning (old file renamed to filename;version, except that it hid old versions by default in ls output.
nilfs2 is available on Linux, and its (continuous) snapshots can be mounted read-only as well, so effectively you can go back to any previous version of any file that hasn't been overwritten yet by the circular-buffer design of the log. At least that's my understanding; I haven't used it myself.
Subversion's autoversioning feature lets OSes with a WebDAV filesystem client mount a Subversion repository (properly configured) as an automatically-versioned filesystem. As the Subversion book notes, though, this can generate a ton of metadata, and some applications may update files in ways that play havoc with Subversion's diff algorithms and generate a lot of diff data as well.
The simple answer is "Because it's far too good for the likes of you peasants".
Microsoft did not want to make file versioning a standard feature in Windows because it had the look of a premium feature for which they might be able to charge extra money.
See also, gas boilers in the UK. It was actually slightly cheaper to make one with electronic ignition than one with a permanent pilot burner chuffing the best part a kilowatt up the flue whether or not heat was wanted (and, in the case of a certain Combi that sounds like a wingless illuminated insect, running the exhaust fan on low speed just to keep the pilot alight); but manufacturers thought it sounded like a fancy space-age feature for which they could charge extra, and consumers did not see past the initial purchase price to the extra 730kWh on every month's gas bill.
If you want to remember a very small amount of VMS, you can download this free OS image, and run it in the Simh emulator.
Dave Cutler wrote some of the VMS 1.0 kernel in assembler, which he later regretted after leading the Windows NT kernel project.
You will get: VAX/VMS Version 1.00 21-AUG-1978 15:54
I got it running on Oracle Linux 9. Direct networking isn't needed, as it will open a telnet socket on a "VAX780 simulator DZ device, line 0" within the host OS.
I don't think there is a TCP stack for VMS 1.0.
https://gunkies.org/wiki/Installing_VMS_V1.0_on_SIMH
For the full effect, you can also get the ROMs for a DEC VT240 terminal, and emulate it on a telnet socket with MAME.
https://www.mail-archive.com/simh@trailing-edge.com/msg09086.html
I ended up using these command line options to get it running (change 2323 below to 6666 for a VMS 1.0 install):
mame -rp . vt240 -window -nothrottle -host null_modem -bitb socket.target.hostname.com:2323
VT240!!!! Luxury!!!!!!!
And definitely not around at VMS 1.0 time.
When I started (not 1.0 but early - a few utilities still used the RSX programs in emulation - wasn't PIP wonderful?) most people were using VT100's. As a lowest-of-the-low summer student employee I was stuck with a VT52. I am sure I didn't see a VT240 for a couple of years after that.
And, by the way, I still have a Gold key on my keyboard!
Well, my keyboard manufacturer seems to have written "Pause --- Break" on the keycap, and forgotten to colour the key properly, but to me it is the Gold key. I bind many of my emacs keybindings to Gold sequences (for example - Gold-l is goto-line, which is what I used in 1980).
If I remember correctly, my VT52 in 1980 actually had a key coloured gold.
[Author here]
> Or you could get a community license for alpha and run the latest version of VMS on AXPBox.
The latest version of VMS is 9.x and it is Intel-only.
AFAIK, Alpha support tops out at 8.x and the last few point releases in the 8.x series were Itanium only.
So Alpha support is not the latest: it's _two_ releases behind $CURRENT.
> VMS defaults to creating new versions of files instead of overwriting.
I would much prefer this than accidentally overwriting all todays work. Or having to remember to save as filename001, 002, 003. You could also set it to only retain the last three versions. No modern innovative desktop has such a feature baked into the file system.
Some programs autosave at timed intervals or operation counts. This stomps on your previously-good autoversioned copies (the last three, or wherever you set the limit).
Sometimes when you've messed up inside a program (or the cat jumps down onto your keyboard), you'd like to exit the program and discard all changes. Autosave blocks you from doing that. One must configure and/or disable autosave within each program that implements it, if even it can be configured.
[Author here]
> I wonder how long it lasts to make economic sense.
I considered adding a "why would anyone care" paragraph. I decided not to. It seems I should have.
DEC kit was exceptionally well-made and as bulletproof as their OS. I know people still running PDP-11s, let alone VAXen and Alpha boxes.
If someone is still running some important function on VMS, then they could be running it on VAXen (probably somewhat unlikely now, but possible), on Alpha boxes (plausible), or on Itanium ones (not that old but no longer made and facing EOL.)
But there are also emulators, and VMS' clustering is unparalleled (pun intended) so you can run an emulator and cluster it with the host machine the emulator is running on. This can be is a lot more efficient than running an emulated machine -- a VM -- with emulated disks containing filesystems, lessons the PC virtualisation industry has yet to learn.
You could be running VAX or Alpha emulators, which cost money, on x86 kit. This way, you could recompile your app and get a performance boost from running native.
You could be running real Alpha or Itanium kit, in which case this lets you migrate to current commodity server kit, with hardware support contracts and readily available spares.
You could support real aging native VMS kit with cluster members with cheap modern hardware, for a fast and inexpensive upgrade.
You could have some special app you can't afford to port, or the people who wrote it are gone or dead or something.
You could have some special VMS expertise and this is cheaper than retraining or hiring new people.
VMS was huge once. If there's still money to be made from modernizing OS/2, then this potential market is bigger. And while VSI does not own the VAX version and can't award VAX licenses, it does and can sell Alpha and Itanium licenses, support, etc. It's not dependant on new sales.
VMS was huge once
For good reason - it was awesome!
I do remember the "Grey Wall" of documentation. My first company got a VAXstation running VMS to support a project, and the documentation occupied about half of a large steel bookcase in the development lab. One day the software engineer assigned to the project wanted to find the API call required to print a message on the console; it eventually took 4 of use a half day going through numerous manuals to eventually find the syscall he wanted. Fun days, now lost in the mists of time.
The same was once true of the IBM PC, and of the Sun OS and tools - a long row of folders covering every aspect you could think of.
Now it ought to be simple to have it electronically delivered, but so much software and hardware has bugger-all in the way of documentation. And no, doxygen generated stuff from headers that tell you nothing about the workings or calling values of a function DO NOT COUNT.
Sadly we live in a world where the list of changes in an updated version of a piece of software says, simply, "Bug fixes and performance enhancements." (Google, all the bloody time, and loads of others following the leader)
I'm possibly not old enough to know about the VMS documentation, but I do recall several home computers of the early 80s that came with big fat user guides that described their version of BASIC, how stuff like the video system and memory worked, processor instructions and how to use them, and quite often a selection of useful calls into the OS to allow one to use various prewritten routines.
I miss those days.
The shelf full of manuals is nothing!. In the '80s, I had a PDP-11 system running RSX-11M, with paid software maintenance. Every month, I got a PRINTED patch list of MACRO-11 code, and I think they were cumulative since the version was released each one got thicker. I had them stacked in a corner of our secure room that held the system. Eventually, I had two stacks each about four feet tall.
I never got around to applying any of these fixes, because we took the attitude that if something wasn't affecting us, it did not need to be patched! Such innocent days, although at the time the closest thing we had to networking were remote terminals connected to RS-232 serial lines (although we did have a CAMTEC X.25 PAD attached to one of the DL-11 lines).
Plus the fact it was much more interesting to play with the Edition 6 and Edition 7 UNIX kernel on the system during the time I had the system down for maintenance!
it eventually took 4 of use a half day going through numerous manuals to eventually find the syscall he wanted.
I used to know that documentation, and the preceding blue wall, so well that I could have told you what book, and probably roughly what page, from memory.
Fun times, I must dig out an old box to load that hobbyist version. Does it come with any compilers?
...that is available for free (mentioned above) comes with Basic, Fortran and COBOL compilers. Alas, it does not appear to include C.
$ help fortran
FORTRAN - Invokes the VAX-11 FORTRAN IV-PLUS compiler to compile one or more source programs.
$ help cob
COBOL - Invokes the PDP-11 COBOL-74/VAX compiler. The /RSX11 qualifier is required.
$ help basic
BASIC - Invokes the PDP-11 BASIC-PLUS-2/VAX compiler.
"Alas, it does not appear to include C."
VMS had, at least back in the day, a love-hate relationship with C. I sometimes wonder if there were someone at DEC still nursing a grudge that BLISS lost out to it.
By the time VAX C came around, the company I worked at already had quite an investment in Whitesmith's C compiler and related tools.
We were a COBOL shop, and in the very early 90s we needed to write a small amount of functionality (asynchronous multi-threaded terminal IO handling using QIO syscalls) where COBOL - surprise, surprise - just wouldn't cut it, and at the time DEC charged for their C-compiler (very expensive) so it was decided the only option was to write it in MACRO32.
Fortunately I already knew 68K assembler and the MACRO32 differences were pretty minimal, so it all worked out great (and I only crashed the dev VAX twice while testing, successfully getting VMS on one occasion to allocate a negative amount of virtual memory which was apparently something DEC had never seen before!)
But then about 2 years later the official C-compiler became available for free from DEC, and in hindsight it would have made more sense to convert the MACRO32 to C code but that never happened, so the MACRO32 code ran until the VAX systems were decommissioned in about 2010-2015 I think. I'm pretty sure they got their money's worth out of that code!
VAX was the third or forth CPU family I learned assembly on, and it was a lark. Not elegant, I suppose – very much CISC – but between the rich instruction set and DEC's great macro library you could do all sorts of cool things. I learned it for a class and one of the assignments required implementing error handling with stack unwinding. Nice.
VAX Pascal was DECs darling language in the 80's, it had all the language extensions needed to make it suitable for writing "proper" applications (a bit like Turbo Pascal did for PCs) and indeed London Underground's then-newly rolled-out computerised ticketing system (1987 onwards) had a datacentre in Baker Street comprised of a bunch of VAX 11/785s to which each tube station was connected via an on-site PDP-11 station computer to which all of the local ticket machines were connected; the ticket machines talked to the PDP which then packaged up and forwarded the ticketing data to the VAXes at Baker St. The central control and accounting software running on the VAXes was written in VAX Pascal and the UI used DEC's SMG screen windowing library, basically a character-based GUI of menus, pop-up windows and the like. All very cutting edge back then.
Find me any OS that didn't need some handholding with regards navigating the basic functionality on offer. Even tactile things like iOS I can think of basic functions that you would have to google to even realise they exist.
With UNIX, the core toolchains are obviously extremely potent. The documentation, and weird naming conventions, not so much. Sure, you and I know what grep and awk are, or how to call up the man page. But where did you learn to do that?
DOS had some absolute deathtraps in the command line if you didn't know what you were doing. DELTREE *.* is a particular favourite, being as that will empty your entire disk irrespective what directory you were sat in. As opposed to DEL which would operate from currently selected directory. Consistent!
AmigaDOS I got on with relatively well, being somewhere between UNIXland in it's toolchain and DOS for human readability of commands.
At uni I remember discovering that VMS HELP understood wildcards, including VMS's unique "and so on" (...) operator.
$ HELP xxxx
would give top level help for the xxxx command, and
$ HELP xxxx ...
would list all the help, including options, for it.
$ HELP * ...
would list all the help for all commands.
That was also when we discovered that dumping a 2" think wad of HELP printout to the lab's dot-matrix printer in one go would burn out the print head ...
Oops.
... from Bell Labs came with manual sources on-line. A newbie ought read the UNIX Programmer's Manual, Volume 2. This contained the tutorials and how-tos. If you're looking at the bound copies published by Wiley, Volume 1 had the blue cover background, and Volume 2 had the green cover background.
I can't say what did or didn't come with AT&T-published UNIX, nor of the many commercial variants.
it eventually took 4 of use a half day going through numerous manuals to eventually find the syscall he wanted.
Half a day?! What you needed is a system admin with Rain Man-like "Grey wall" powers!
One day, many many years ago, I was writing in MACRO32 on a VAX, and needed the documentation for the QIO syscall.
I walked into tech support, custodians of the Grey Wall, and spoke to the senior system admin - a man of very few words - and our "conversation" went something like this:
Me: "Hi Raymond <not his real name> I'm looking for the QIO documentation, any idea where the manual is?"
Raymond thinks for a second or 2, then says: "4th rack from the left, 3rd row down, 2nd manual from the right. Section 8."
And he was spot on! I was in and out of there in less than 2 minutes. :-)
One of my former employers has an 8 node Alpha cluster that is still running. Its old, but reliable as hell. Many spindles have been replaced and woven back in to the volumes.
I helped test last release of this, it was *not quite* ready to replace what is currently running on the Alpha cluster. I suppose I'll be asked to look at this one.
(For the record, the cluster talks to both the telecoms networks and the banking networks. Government intervention is always an incorrectly tapped escape key away)
One day, one happy day, business is going to return to prioritizing stability over convenience.
I suppose that won't happen until all current CxOs have kicked the bucket and their noxious influence die with them.
But one day, we will return to a world where uptime is king, and change for the sake of change is anathema.
The golden rule is : if it works, don't fix it.
Very little is gained by adding a dark theme. Just my two cents . . .
You could have some special app you can't afford to port
$WORK had a precursor to an ERP system called a manufacturing management system ("manman"). It was written in Fortran for the RDB database product. It ran on a model 200 (VAX 4000 series).
Because it was "accounting" software, it (or the data) had to be available for 7 years after the accountants discontinued use and moved on to Oracle or some such. So we kept it running.
Round about then the first smart phones came out. You could download many different apps, including a port of a VAX emulator called simh. It would run on a 1GB android phone, and could support a 32MB VAX.
So I offered it up to the chief accountant -- he could have his own personal copy of VAX/VMS running the (old by then) manman software on his phone.
Inexplicably, he declined.
>You could have some special app you can't afford to port
Or you can't risk porting or it's not worth it for a single project
There are a couple of astronomy satellites whose data collection / analysis was running on VMS in the 2010s, and IIRC the Eurofighter avionics development was on VMS so hopefully somebody has a build system
Last December I finally left my last job (aged 79) supporting VMS - the "open" is silent - at the multi-node Charon emulation site of a Local Government department.
There were no young 'uns to be found to support VMS, just a couple of us old fogies. Almost a decade there, and in all that time "it just worked", any problems were on the human side, with several dozen programmers (COBOL) and several hundred users.
Now it's all moved to several Windows machines.
Sic transit gloria mundi
Well with a supported version that runs on (some) current commodity hardware it may attract further investment and rise phoenix like...
The real hurdle is too many people in IT today think there is only Windows and Linux and these represent the pinnacle of OS design and development, because that is all they know...
Nobody in their right mind thinks that Linux is the pinnacle of OS design (much less Windows). That's not the point. The point is that Linux servers are ubiquitous and just "good enough" for just about everything you might want a server for. It may very well be that in some respects, VMS is better. But it doesn't matter, because better than "good enough" is still "good enough".
Nobody in their right mind thinks that Linux is the pinnacle of OS design (much less Windows).
I know I'll get shot down in flames for this, but I think you've got that the wrong way round.
I'd argue NT is better designed than *NIX. The underlying kernel has things like fine grained security baked in from the start, and a decent driver interface. (Okay, it's a shame they then grafted Windows onto it, but still...)
NT 3.1 had things like a user space graphics stack, for increased security. It proved too slow with early 90s hardware but it wasn't a bad idea.
Or another example, you can use SATA drives on XP even though it was released 2 years before the first SATA drive; because you can get storage drivers for it.
[Author here]
> I'd argue NT is better designed than *NIX.
That's a bold statement... but I can't falsify it. The underlying design is excellent.
BTW, the graphics stack remained in user space up to and including NT 3.51, the third release. It's NT 4 that moved it into the kernel, which was blatantly a foolish and short-sighted decision even at the time.
Unfortunately a lot of clueless marketing weasels got their say and it's bloated to the point of being FUBAR with layers of ugly crud on top.
VMS and VMS++ ie WNT, are better designed than Unix
They were actually designed over decades rather than a quick hack that got out of hand
However Unix was available - Carbon Fibre and Titanium are way better building materials than 2x4s but if you need to build a shed which are you using?
They [VMS and WINNT] were actually designed over decades
That statement is false, if you believe the VMS Wikipedia entry. "OpenVMS, often referred to as just VMS, is a multi-user, multiprocessing and virtual memory-based operating system. ... It [VMS] was first announced by Digital Equipment Corporation (DEC) as VAX/VMS (Virtual Address eXtension/Virtual Memory System) alongside the VAX-11/780 minicomputer in 1977. ... In April 1975, Digital Equipment Corporation embarked on a project to design a 32-bit extension to its PDP-11"
From 1975 to 1977 is two years for design, coding, testing, and debugging. Not "decades."
More Wikipedia: "Windows NT is a proprietary graphical operating system produced by Microsoft, the first version of which was released on July 27, 1993. ... The first version of Windows NT was Windows NT 3.1 and was produced for workstations and server computers. ... Microsoft decided to create a portable operating system, compatible with OS/2 and POSIX and supporting multiprocessing, in October 1988. When development started in November 1989, Windows NT was to be known as OS/2 3.0,"
From 1988 to 1993 is five years for design, coding, testing and debugging. Again, that is not "decades".
VMS article: https://en.wikipedia.org/wiki/OpenVMS
WNT article: https://en.wikipedia.org/wiki/Windows_NT
One major design decision shared by VMS and NT is hard file locking, and that has vast consequences on uptime/availability.
Linux is able to apply patches to underlying libraries that are in use. Processes that have linked in the older library report when their mapped libraries are unlinked:
# grep deleted /proc/1/maps | head -1
7ff80804e000-7ff80805c000 r--p 00000000 fc:00 201330314 /usr/lib64/libgcrypt.so.20.4.0 (deleted)
Because NT cannot do this, you get to enjoy "Patch Tuesday."
The stupidly short MAX_PATH is correctable with a registry setting; I have no idea why it's not turned on by default at least in 2022, but I'm not particularly wise in the ways of WNT heavy wizardry. (I'm a MS employee, but my attempts to parse the os.2020 repository typically end in a headache.)
"Linux is able to apply patches to underlying libraries that are in use."
That's a major bug, not a feature.
You're already in deep, deep shit if you're having to patch libraries on the fly. It's even worse if processes have to unlink and relink those libraries while they are running. That's not good for stability or availability. It's like changing the engines on a plane while it's in flight.
It would have been possible to get a similar outcome in VMS by using a search list (a form of 'logical name' or a kind of environment variable): you'd put the new files in directory [NEW], leave old files in directory [OLD}, (re)define LIBDIR as [NEW],[OLD] after which LIBDIR:FILE.EXT would resolve to the file in [NEW} if it existed, otherwise to the file in [OLD] when it was next opened.
Of course this wasn't such a big deal at the time with fewer updates and fewer packages - uptime concerns were as much about hardware reliability as software maintenance and clustering was then the solution to both.
I think I prefer the Linux approach in the file system, but I suspect something like search lists could contribute something in the snap/flatpak space.
Logical names and search lists (together and separately) are the things I still miss from VMS. I have, several times over the years, idly thought about implementing both within the C RTL.(not the kernel).
Now I'm retired I have no excuse not to have a go. But I think I have been worn down enough not to care any more.
Worked for a company who did weather forecast presentation/annotation software which ran exclusively on VMS. Unfortunately, all the VMS people left and no one was keen to learn it. The major customers (Dutch Air Force and Dutch TV station) enacted the escrow clauses and took on maintenance themselves. God knows where they got people with VMS dev experience as we couldn't.
Those were the days! I was a VMS specialist from v3 through to v6 and even worked for DEC for the majority of that time. Writing a file archiving system in Bliss 32 was probably the peak moment. In some ways VMS spoilt me as the DCL command language was consistent and intuitive. Want to print the file Myfile.txt? try $ Print Myfile.txt I even wrote an application in DCL for a client.
Whenever I dip my toes into the Linux terminal it always seems to be just a mess. Non-intuitive commands and each one has its own non-standard switches and options.
While I have a soft spot and high regard for VMS, I can't think of a single application I use that would run on it.
TPU/EVE was a great asset. Around 1989 I wrote a set of routines to take marked-up output from a bibliographic database (CAIRS) and transform it into pretty two-column output which could be printed, superseding the previous arrangements which were much uglier, and involved scissors and glue. Cut'n'paste, only for real!
TPU had (has?) the LEARN command:
Create a temporary edit macro by demonstration, run it a definable number of times
Useful in 100K-line files for specific (anchored) global edits
TPU also had the option of defining keys, macros e.g. entering text in a right-to-left language, box editing, much fun stuff...
icon ===> show my greybeard
> Non-intuitive commands and each one has its own non-standard switches and options.
And that was by deliberate intent !
Encountering Unix after having used TOPS-10 and VMS and studied OS design at Uni. to Unix was a shock ...
Yes it is powerful and there are things that are easier to do in it than in VMS, these however don't excuse the abomination of the Unix/Linux command line syntax.
IIRC from my days working with VMS, you could write executables in any of the supported compiled languages and then define a DCL command that acted as a wrapper around one or more executables, complete with parameter validation and parsing all done by the DCL interpreter before calling the executable(s) with the appropriate arguments. It was very powerful and saved tools developers a lot of time, the nearest I've come across in recent times for parameter handling and validation is PowerShell.
I worked on a VAX cluster for a major (for the Caribbean) national computing centre, for the better part of a decade. The VAXen were rock solid, never broke, gave very little trouble. We did government work, and major public utilities (the water people, for example) and some private companies which didn’t want to, or couldn’t afford to, build something as powerful and reliable. We stayed up during a direct hit by a hurricane and several near misses, and an earthquake. Yes, the VAXen sneered at an earthquake. Try that with your Dell boxes. (We had taken precautions, notably with the hard drives, and there was a lot of worry about the drives after the Major Shaking Event, but everything still worked. Other people, who had not spent the money to take precautions because we were, after all, in an earthquake zone, were very sorry. Some of them lacked proper backups. Oops.)
I spent the first 17 years of my career at DEC, starting first with WPS (PDP-8s), then RSTS/E (PDP-11s), then VMS applications, then Ultrix-32 (VAX ported BSD UNIX), OSF/1, Alpha, and ending up in StorageWorks, a trade name still used by HP. Reading this brought a tear to my eye.
I long for the days of stability and having just about everything you needed at your fingertips. Now you never know when your whole system is going to get bound up trying to open some resource in the background.
LSE (Language Sensitive Editor) integrated with VAX Debug was pretty slick. Now it's a mixed bag, different IDEs for different languages, no consistency in interfaces, etc, etc.
I'd love to see an article exploring modern OpenVMS, including the DECWindows desktop (CDE) and just generally playing around with it and showing lots of screenshots. It's one of the most interesting OS's I've heard of - one of the oldest still developed systems, the spiritual father to Windows, used to be a workstation OS with stuff like the Mozilla browser ported to it, but completely unknown to 99.99% of people who are at most aware of Windows and Linux/Unix-like systems.
"I'd love to see an article exploring modern OpenVMS, including the DECWindows desktop (CDE) and just generally playing around with it and showing lots of screenshots."
+1 for that. I haven't used VMS since I was a student, and I remember very little about it. I'd be fascinated to see what it can do.
I wonder if all the VMS utilities are still written in Bliss? I worked on porting the Bliss compiler from TOPS20 to the VAX hardware so our little compiler group was very much involved with VMS 1.0. Even the Index File part of RMS was written in Bliss, as well as most of the compilers. I have not run into a language since with such a powerful MACRO processor.
As someone who worked for DEC in the days when PDP-11s ruled the world and the only VAX was the 11/780, I've been eagerly anticipating a hobbyist version of VMS on x86. In the field, I was mainly an '11 guy familiar with RT-11, RSX-11 and RSTS (with a side helping of MUMPS). When I got out of the field, I took a job at DECs Bedford MA training center and taught VMS and Unix classes. I'm interested in running VMS mainly curiosity and walking down memory lane.
My first programming job was during the summer between my junior and senior college years, and it was writing PL/I on a VAX. VMS' design of saving old versions took some getting used to, but was handy once learned. Yes, I remember the wall of manuals that I used to teach myself PL/I and learn enough VMS to get by. I wrote a query-and-retrieval system for the college's student records database. My boss, in the reference letter he wrote for me, said it had capabilities exceeding some commercial offerings of the time (that might have been the ability to write queries with boolean expressions of arbitrary depth and complexity). That boss had an interesting way of encouraging work -- he'd stop by, smoking his cigarette, and tell me stories of the *really* early days of computing -- until he could see I was itching for him to wrap it up so I could get back to the task at hand. Except for the smoke, one of the best bosses I've had, and I've been lucky to have a lot of good bosses.
Our DEC installation was a showpiece for the college, demonstrating their embrace of the modern era (it was an early adopter within the State University of New York system). The VAX, with its tape and disk drives and CPU cabinets was in an airy two-story room, and there were large windows in the second floor where you could look down from a hallway, watching the dedicated tech going about his duties. There were even picture windows at ground level -- to another hallway and even the outdoors! -- so passers-by could admire the machine. A DEC service guy would show up several times a month for hardware repairs/maintenance/upgrades. Everybody in the department, including me, had their own office with a window and a door just a short ways away on that second-floor hallway. Those were the days.
Now, the computing center is a row of racks in a sub-basement behind several locked doors, and the IT staff (no, not me!) are in a windowless warren off a back hallway. They're sentenced to maintaining, among other things, a non-standard ActiveDirectory installation. Progress, I guess, on somebody's metric.
Never set the colour of all items on the screen (ie., background, text, mouse cursor, etc.) to be the same - these changes are very persistent and as a mere user the only way I could fix it involved the use of another identical workstation, a ruler and some very carefully measured mouse movements.
The support team's response to my problem was amusement, and, if I did manage to recover, could I please let them know how I did it.
I doubt I can remember many VMS commands now, well not beyond SET DEF and EVE anyway, but VMS used to be my bread and butter. Mainly Pascal programming, but some Whitesmiths C too. And DCL scripts of course. Happy days.
I also remember writing a Tetris clone for the command line (the only GUI as far as I remember was CDE, and that was horrible) and hiding it on a few of the test systems. It’s not all work work work y’know.
VMS was a younger OS (1977) than Unix (early 1970s)
VMS was an engineered product for the then new VAX while Unix was more an ad hoc affair probably flying under the corporate radar of the time.
Interestingly an even older OS Multics had a very long life probably for the same reasons VMS has survived. VMS has been ported to three newer architectures while Multics was stuck on one (GE645.)
One observation I would make is that the cost of hardware that *could* run Unix or Unix-like OSes has always been orders of magnitude cheaper than which could run proprietary enterprise OSes. You could run a variety of real Unix versions on 386 PC eg System V/386 for a fraction the cost of microvax running VMS. My first personal "unix" was Minix running on a PC/AT followed by a version of Coherent.
The complaint about the inconsistent use of switch / command line options for the various Unix utilities is fair comment. When you consider these utilities were writen at different times, different locations by different people I am not sure we haven't done too badly ;) The beauty is that you can rewrite the whole menagerie including the shell in the language of your choice (even Rust:) implementing the command line convention(s) of your choice. Plan9 probably comes close but old habits die hard.
Opinion in the 80s was that Ken Olsen missed judged the market opportunity and so failed to cash in by reducing the price of the MicroVAX to match the IBM PC-AT. Consensus was that had DEC done so they would have probably greatly hindered Microsoft’s rise to dominate the business desktop market (DEC had a good business applications portfolio compared to the IBM PC). However, in Olsen’s defence, doing this would have killed the margins they were getting…
Encountered a similar conundrum in the late 1990s when I and a Colleague put together an offering where the company effectively took their own mainframe customers and re host them on their Unix servers, instead of allowing their competitors to do it. To my mind the mainframe revenues were time limited and it was better existing customers spent with us rather than the competition, however, in both cases management had to grapple with a downsizing of the mainframe business…
We ported our Cobol and Fortran code off our VMS Vax to Sun Sparc in 1998 and that was the last time I used VMS. Literally some of that stuff had been written before I was born (in the early 70s) and had been ported from a Sperry mainframe before that.
Ironically now we have "offshore colleagues" porting that same stuff from Sparc to Intel Linux boxes. If it works there I expect it will run unmolested for another 30 years.
It might surprise people that we're not a bank. Education sector.
Debugging was a joy on VMS, regardless of language - single stepping a COBOL programme that called a module written in C which then calls a MACRO32 library, you could debug them all in a really easy to use and comfortable environment, switching seemlessly from one language to another as you step into/step out.
DEC were years ahead when it came to their common language environment.
Linux still doesn't come close, as gdb is horrible.
When I saw the comment number before opening this page I knew I was in for a good time. Thank you for the war stories. I hope there'll be more.
VMS is definitely interesting but what to use it for since production use would need a license that probably costs way too much. As said above: an /engineered/ system instead of haphazard "good enough" -- the pinnacle of which is Linux.
Looking at the OpenVMS installer it is clear what inspired the OpenBSD installer.
I’ve worked for a steel manufacturing company for the past 31 years and we’re still a DEC shop.
Started with Vax 4300, then Alpha DS20e now Itanium. X86 is the next jump.
The Alpha hardware controlling our main production line started to die last year and we seamlessly ported both Alphas running v8.3 over to vtAlpha emulator running on VMWare.
Running VSI’s 8.4-3 on an Itanium for our main inventory control software database running Mimer. All the COBOL code was ported off years ago and the front end is written in Delphi against the Mimer db.
VMS is the only true 24x7 operating system for manufacturing lines. Ran one of my Alphas 5 years before I had to reboot to do an upgrade.
I started my career in computers at 16 when I left school and scored my first job as a 'Computer Operator' for the head office of a large UK bank here in New Zealand in 1986.
I cut my teeth operating a VAX 11/750 (and it's 'backup' machine, a PDP 11) which ran the banks Foreign Exchange market trades, along with a Wang VS100 which handled the domestic money market operations.
We (my co-operator and I) worked rotating shifts. Day shift was 7am - 3pm one week, and night shift was 3pm - 11pm the following week and repeat.
Our duties were to perform backups (reel to reel tapes), run nightly processing jobs, print, split and deliver reports produced by the overnight processing and anything else considered 'computery' (changing printer ribbons, lineflo paper, setting up VT100's and Wang desktop workstations for staff, etc).
But our main task when on night shift was to babysit the overnight processing on both the VAX and VS100. Most days, it really only involved doing the pre and post processing backups and sorting and delivering the resulting reports. I remember the Wang being very, very reliable, hardware and software wise, as the software running the domestic money market application was supported in-house.
The VAX was also a mostly very reliable piece of hardware, but was let down by a dog of an application for the FX business that was supported out of the banks Sydney office at the time. Most night shifts did not finish at 11pm due to the FX system crashing and requiring over the phone support from Sydney.
Picture we operators (we were not 'programmers') with an old analogue phone glued to our ear in a noisy computer room, aircon blowing full blast, band printers screeching, etc. reading the error message from the LA36 DECwriter II to the guy in Sydney, then having to wait for him to read back commands for us to type back into the LA36 DECwriter II in order to try and get the processing started again. A lot of the time, the night shift operator was still at the office when the day shift guy would arrive for his shift at 7am the next morning. It was PAINFUL! But, for years, we earned a LOT of overtime from having to stay past 11pm to get everything done, that it was almost worth it.
The only time I remember there being any ongoing hardware issues with either the VAX or the Wang, was when we moved into a newly built head office building. During the first winter in the new building, there were mysterious problems with both systems freezing for no apparent reason. This took months to resolve and I'm proud to say I was probably the one that discovered the cause of the problem. I was called to the GM's office one morning, because one of the metal panels covering the heater elements in his office had fallen off the wall (yes, this was considered an 'IT' problem!)
When I looked at where the panel had come off the wall, I could see that there was COAX and Ethernet cabling wrapped around and melted to the heater element! Whoever did the cabling for the building when it was built had done this, so every time the heaters kicked in during that first winter, the plastic shielding on the cables melted a little bit more, until one day, the copper within the cables finally made contact with the heater elements which sent some strange signals back to the VAX and VS which caused them to crash!
Luckily, it turned out the only place the cabling had been wrapped around the element like this, was in the GM's office, but the whole building had to be checked just in case.
I worked there for 6 years, then moved on to a couple of other companies also using DEC and Wang gear, but I think the last place I used a VAX with OpenVMS was in about 2000.
Ah, they were the days!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
