Created 22 September 2022 - Updated 24 September 2022
Even in tech, the word "mainframe" - especially in the United States - brings up images of IBM's monstrous Z systems. They're definitely the most common, but they're actually only one of at least four mainframe families still in use in the United States. One of the other three, the Unisys Clearpath Dorado family, is the direct and compatible descendant of the Univac 1100 family of mainframes developed in the early to mid 1960s. They are unapologetically strange systems - integers are represented as ones' complement, and the machine word is 36-bit; the operating system is proudly baroque and more than a little intimidating.
They're also way more fun than I expected.
If you've been around IBM mainframe operating systems, you probably have a certain idea of what they're like - menus everywhere, JCL to do anything useful, and a command facility that has been described as "like kicking a dead whale down the beach."[1] Especially for UNIX users, the lack of emphasis on anything resembling a command shell in the MVS family is jarring and a little offputting. I expected OS 2200 to feel like that, especially in light of my previous experience with its more technically advanced Unisys stablemate[2], MCP, but it really isn't - instead I found a complex but ultimately very likable command-line facility, powerful language and scripting features, and a mixture of very good and very bad documentation.
This is what it looks like.
I've actually used this in a semi-serious environment in the past - as a well-behaved ncurses test application when chasing terminal gremlins on Stratus VOS - but this is not that time. We also won't be using the original source code. Our target system has terminal handling wildly unlike any UNIX (or even VOS) system, and while it has a C compiler, properties of the system mean that any realistic port would end up becoming a complete rewrite. Instead we'll be doing a new implementation, using the native OS 2200 forms system called DPS 2200.[3] We should probably use COBOL for the authentic OS 2200 forms application experience, but I'll at least be doing some experimentation in C due to my greater experience with it. How much ends up in COBOL depends, ultimately, on how high my level of masochism goes in any given minute. FORTRAN is also an option.
I'm learning OS 2200 as I go, so I may do things in a way that's frustrating for people familiar with the Dorado system. I apologize in advance for my inexperience with the platform!
Generally, the emulator runs in a fairly complex preconfigured Linux environment; however, for the personal dev/test environment we'll be working with, OS 2200 runs in a turnkey emulation platform called PS/2200. PS/2200, while a little inflexible, is an impressive piece of software with some really useful convenience features. Namely --
Oddly, its splash screen is decorated with IBM mainframes.
Filenames will look horrifying to the UNIX user. SYS$LIB$*UC$INCLUDE.STDIO/H
is a perfectly valid and meaningful OS 2200 path. OS 2200's FS is either non-hierarchical or marginally hierarchical, depending on point of view. The general form is qualifier*filename.elementname
. Qualifier, while actually part of the filename, acts somewhat like a top level directory. Program files contain elements, in this case named STDIO/H
; this concept will be familiar to MVS users, since it's similar to the Z concept of a PDS, but less so to UNIX users, to who a 2200 file looks more like a directory. For extra fun, Unisys calls a file with named elements a "program file"; a binary is called an "object module", and (unless it's a processor, a special type of application) is executed with the @XQT
command. OS 2200's own system files all contain $ as part of their filename, to avoid name conflicts with user files. Flags, as distinct from parameters, are appended to the command and separated by a comma; for instance, to view the elements contained within SYS$LIB$*UC$INCLUDE.
, you would run @PRT,T SYS$LIB$*UC$INCLUDE.
- including the trailing period.
OS 2200 also has "directories" - but they're only meaningful on clustered systems, and there are only two: STD (private local storage) and SHARED (cluster storage.) Only a few commands accept a directory specifier; for those commands, the form directory#qual*file.element
is used.
OS 2200 files can also, for security, have read and write keys - essentially passwords for reading and writing; these are delimited by slashes after the filename, like SUNSET*SFT/read_key/write_key
.
The OS 2200 system isn't generally case sensitive. There may be some exceptions I haven't found yet.
@UC
- Invokes the UCS C compiler. In its simplest form, @UC sourcefile,outputfile
. For simple programs I usually try to keep the source and output in the same program file - so, for instance, @UC sunset*sft.src,sunset*sft.out
@PRT
- Prints information about files. On its own, @PRT
dumps the list of all files in the Master File Table. @PRT,T
with a program file parameter gives the table of contents of that file. @PRT,P
lists the files associated with the current project (or, for a privileged user, any project.)@FORMGN
- Form generator. Designs forms then outputs them as generated source in an appropriate language.@XQT
- Runs an object module. Object modules can also be started directly by @ followed by their filename, but only if they're written as processors - which have special considerations.@START
- Runs a canned runstream - the local term for a script.@RUN
- Specifies details of a batch or demand run. An unadorned @RUN can start a demand (interactive) session or, depending on the account configuration, a batch run.@XEDIT
- Within the PS/2200 emulator, invokes the host text editor. The U flag updates an existing file or element, the I flag uses a new file or element, and the R flag opens the file or element read-only.@IPF
- Launches the Interactive Processing Facility, an enhanced interactive environment with some extra convenience features beyond the regular demand-mode environment.@FIN
- Ends a session or runstream.Most customer applications are written in COBOL, though I know of at least one customer - United Airlines - who historically has a large Fortran codebase. Both are UCS languages. C is also provided, and I've been told it's fairly widely used by ISV utility programs. For utility and systems programming, assembly language is also very common. I've seen references to UCS Ada, presumably for defense customers, but I haven't seen any direct documentation on it and I have no idea if it's still supported. There is also Java support, but that has some intricacies and I'll dive further into it in another post.
There may also have been UCS Pascal at one point, but if so, it seems to be long dead.
[1] I am aware TSO fans exist. I won't pretend to understand them.
[2] MCP is an impressively advanced system - memory access is done via descriptors, and it was built as a pure HLL system in the early 1960s. It also has some design decisions I will charitably call "unconventional", including that the base scalar type is 48-bit floating-point. No matter how copacetic its internals are, its mouthfeel is a bit unpleasant - at least to me.
[3] Its documentation is not very approachable - or rather, all available references seem to assume significant existing exposure. That's what makes it fun.
[4] Libra is for MCP, Dorado is for OS 2200. They are unrelated systems developed at distinct companies and running on radically distinct hardware.
[5] I'm not sure what this focus on largely-undetectable ~authenticity~ says about me as a person.
[6] This aspect is shared with BS2000 but is otherwise uncommon in mainframe operating systems. Both GCOS 7 and GCOS 8 have distinct languages for interactive and batch use, as does the extended MVS family.