WyBlog, the best thing about New Jersey since the invention of the 24 hour diner.
Chris Wysocki
Caldwell, NJ
The nine most terrifying words in the English language are "I'm from the government and I'm here to help." - Ronald Reagan
Linkiest
CH 2.0 Info Center
The Jersey Report
Labor Union Report
Memeorandum
Net Right Nation
The Patriot Post Newsletter
Pajamas Media
PJTV
Victor Davis Hanson
J! E! T! S! Jets! Jets! Jets!
OpenVMS.org Portal
AVS Forum
NJ.com Caldwell Forum
The Caldwells Patch
The Jersey Tomato Press
"This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. It is being made available in an effort to advance the understanding of environmental, political, human rights, economic, democracy, scientific, social issues, etc. It is believed that this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit for research and educational purposes."
Thirty years ago today, on October 25, 1977, Digital Equipment Corporation released VAX/VMS V1.0 for the VAX-11/780. The Vax was designed to be the replacement for the PDP-11, a 16-bit minicomputer that was a real workhorse in its own right. With a 32-bit address space, virtual memory, and twice the number of registers, the Vax opened a whole new world of mid-range computing. The original Vaxen were actually dual-architecture; they had the full PDP-11 instruction set and could run PDP-11 binaries in Compatibility Mode. Bootstrap (we didn't call it "startup" back then) always began in Compatibility Mode. The procedure entailed loading a floppy disk that executed a subset of RSX (a PDP-11 operating system) with just enough smarts to locate the VMS system image, load it into memory, and switch the CPU to Native Mode to begin execution of the VAX/VMS operating system.
I remember seeing a VAX-11/780 at RPI in the basement of the Amos Eaton building, probably around 1979. I vaguely recall meeting a guy who was involved with working on it, but frankly I didn't pay the Vax much attention. I was heavily invested in IBM System/360 assembly language programming and since RPI had just upgraded to a 3083 I was a lot more excited about that. Besides, the Vax didn't use punch cards so how could it be a Real Computer? Hey, what did I know? I was just a geeky math major.
While I was in college I also worked here at Data Life during the summers. We had an IBM 360/20 back then, and a PDP-11/34 running RSTS. When I graduated from RPI I joined DL full-time. The lease on the 360 was coming up for renewal and IBM was pushing us to upgrade to a 4341. I thought this was a swell idea; after all I was true-blue-through-and-through. Simon hooked up with a DEC sales guy who showed him a new Vax model, the VAX-11/750. The Vax was way less expensive than the IBM 4341, and DEC promised us help with migrating our IBM Cobol applications, so early in 1981 one of the first VAX-11/750's to be installed in New Jersey landed here in Verona.
It had 256 kilobytes of memory, 2 RK07 removable disk drives with a capacity of 71 megabytes each, and a pair of MT11 9-track tape drives. (This was mostly a step up from what we had on the 360 - 128 K of memory, a bank of 5 and 10 megabyte disk packs, and 4 high-speed vacuum column tape drives.) Most of our data was on magtape, our processing consisted of reading data from one tape, massaging it, and writing it to another tape. Each "job" had from 10 to 15 "steps" in it, and each "step" involved reading one tape and writing another. We had a full-time tape librarian, his whole job consisted of cataloguing, cleaning, and tracking the thousands of tape reels we used each month.
The guys from DEC helped a lot with the conversion. We became experts in
the use of the LIB$TRA_EBC_ASC
library routine. (IBM systems
stored data in EBCDIC format but DEC systems use Ascii. Microsoft chose
Ascii for the PC so I guess Ascii "won".) The VAX-11/750 ran VAX/VMS V2.0,
and yes, ours had a card reader. The thing that was revolutionary to me
was the Vax could run our programs interactively; we didn't have to feed
them in via punch cards or execute them in "background" (IBM's OS/360 term for
batch processing). We could also load data in from tape and write it to
disk. 71 megabytes seemed like an ocean of space since we were used to only
having 5 or 10 megabytes of "scratch" space per job.
In the IBM world, programming consisted of modifying decks of punch cards,
feeding them into the card reader (along with the deck of punch cards that
contained the compiler), and parsing the line printer output for
error messages. In VAX/VMS the programs lived in disk files, we could
modify them using a text editor, the compiler was always there via the
$ COBOL
command, and error messages were immediately displayed
on our terminals. We could even run the programs right there and look at
the output before it was printed. We were in heaven!
Then, much like now, the life insurance industry's lifeblood was data. We took in reams of data each month from each of our clients and shipped back boxes and boxes of printed reports. We had a staff of keypunch operators who spent their entire day translating mountains of coded forms into boxes of punched cards. Once we got most of our applications converted to the Vax Mr-big-shot here thought it would be much more efficient if the keypunch girls could enter the data directly into the Vax. We could replace their 029 keypunch desks with a VT100 terminal!
Me and my big mouth. Change comes slowly in the life insurance world, and changing coding forms, especially for a 3rd party data processor, comes not at all. If a client had to go through the bother of learning a new set of coding forms he very well may decide to switch to a new DP vendor too. So, we could not change the data entry formats. There was also the small matter of retraining the keypunch operators. Today everybody is familiar with the ubiquitous PC keyboard with its numeric keypad, and the DEC VT100 terminals had the same format. That is, the numbers were laid out like this:
7 8 9 4 5 6 1 2 3 0
The problem was, despite trying really hard to adapt to this keypad, the keypunch girls were totally used to the 029 keypad, which like telephones and adding machines, had the top and bottom rows switched:
1 2 3 4 5 6 7 8 9 0
If we were going to phase out the keypunches, we had to find a way to modify the numeric keypad. The Keypunch Emulator was born. The VT100 terminal has the ability to switch the keypad into "application mode" whereby it transmits escape sequences instead of numbers to the host. No problem, I said, we can just intercept these escape sequences, translate them into the numbers the data entry folks expect, and display them.
It turned to be just a tad bit harder than that, but with help from one of the other fellows here, we finally got it to work. Simon had custom keycaps made up for a bunch of terminals (due to the sloping nature of the keyboard, simply exchanging the 1,2,3 keys with 7,8,9 resulted in bruised fingers because the 7,8,9 keys were thicker than the 1,2,3 keys). The keypunch emulator eventually came to include just about every feature found on an IBM 029 keypunch. We supported virtual drum cards, and the tab key inserted the appropriate number of spaces to jump to the next stop. They used the left arrow key to go back, and a "rubout" key (literally a key that punched every hole in the column) to correct mistakes, so we had to emulate that too. And, of course, we had to emulate "verify" mode (after one keypunch operator had entered the data, another operator would rekey the same data in verify mode, which checked that the data on the cards matched the data being rekeyed).
We don't actually use the keypunch emulator anymore. I think the last time it was needed was back around 1990. But, here's why VMS is so great. I just pulled it up. We've switched Vaxen (we upgraded the 750 to a 3400, and then to a 4100, and migrated to Alpha (AS2100, ES40, and DS20) and Itanium (rx2600). The keypunch emulator still works, even on my X-windows display that's pretending to be a VT100. The original compiled version (developed on VAX/VMS V2.4) runs unmodified on OpenVMS Vax V7.3. I ran it through the Alpha binary translator (VEST) and it ran fine on OpenVMS Alpha V8.3. I then took the translated Alpha program, ran it through the AEST Itanium binary translator. It translated fine, but didn't run correctly. Hmmm, this is supposed to work. A little time with the debugger exposed an error handling bug that had lain dormant for 25 years. So, as the saying goes, I "used the source, Luke", recompiled, and now it works on Itanium too.
Yes, time and technology have marched on, yet VMS (now OpenVMS) is still going strong. I chalk that up to its robust feature set, and the foresight of its developers. VMS has adapted to the 21st century while still preserving the legacy of the original Vax. The same Alpha system that ran my old keypunch emulator is also running the web server hosting this blog, using software written in Perl (a language that didn't exist 30 years ago). It's connected to a SAN array with 2.5 terabytes of storage (a 3½ million percent increase over the disk space on our first Vax). We still do all of our life insurance data processing on VMS, only now the applications are web-enabled, the magtapes have been replaced by XML files, and the output is produced in PDF format and emailed worldwide.
HP is still deeply committed to OpenVMS development; they have announced plans
for updates and enhancements through 2012. If they stay true to form, some time
next year, we'll see the release of an update schedule for 2013. Taped to my
office wall is a bumper sticker that DEC put out for the 20th
anniversary of VAX/VMS. The tag line is "Nothing Stops It". They weren't
kidding.
Posted at 15:44 by Chris Wysocki
[/vms]
Comments | Perm Link |
|
Tweet
Previous: Stuck in the 70's and Stuck on Stupid | Next: Waste on Wheels isn't the half of it |
Main |