Part 1: The Road to Unisys Dorado

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.

The Mission

Robot Finds Kitten, or Robotfindskitten, is a so-called "Zen simulation" - a simple game that involves walking up to objects (marked by single text characters in a mostly-empty field) and reading their descriptions. If the object turns out to be kitten, the game ends. We'll be attempting a port of it to OS 2200, formerly known as EXEC 8 and 1100 OS, the operating system for the Clearpath Dorado.

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!

The Environment

Until approximately 2015, Unisys continued to sell its Libra and Dorado[4] mainframes with custom CISC processors, developed inhouse but increasingly neglected. The product line has, since the late 1990s, gradually moved to emulation on x86 systems, starting at the low end; by the early 2010s, performance under emulation had largely matched or exceeded native performance on the custom Unisys CMOS, and today, the product line is exclusively emulated. Unisys CMOS systems still exist in decent numbers in the wild, but the future of Unisys mainframes is with emulation.

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 --

• It can send and retrieve files to the host system.
• It can open OS 2200 files in the host's text editor, via the @XEDIT command within OS 2200.
• It has two distinct modes, SOS and ROS. SOS runs a high-level emulation of OS 2200 kernel calls for performance reasons, while retaining the original Dorado userspace. ROS runs a genuine OS 2200 kernel under machine emulation. SOS is faster and has a somewhat more forgiving default configuration (ROS required me to get familiar, quickly, with @SECMGR as it does not seem to come with canned user profiles) but I've found myself favoring ROS.[5]

Oddly, its splash screen is decorated with IBM mainframes.

Into OS 2200

OS 2200, while it has a rich shell environment, is not UNIX. It is not UNIX-like. It is not POSIX. If you come at it from a UNIX perspective, or even a VMS or VOS perspective, you are not likely to like it very much. Commands are especially unintuitive for UNIX users. Familiar-looking commands have surprising results. @CAT does not output or combine files, but creates them; the most direct equivalent to ls is called @PRT. It's a good idea to check the manual, even if you think something is a cognate. On a positive note, interactive commands are the same as those used in batch; the ECL language is used in both, unlike in MVS, where TSO and JCL are significantly different creatures.[6] As with any system of its lineage, subsystems and services abound; ASIS provides advanced authentication, akin to RACF. File management is performed through FURPUR; user management, through SECMGR. Databases, both the relational RDBMS and the hierarchical DMS 2200, are backed by the UDS underlying record store.

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.

OS 2200 Commands

These are a handful of commands I find myself using regularly on OS 2200. It's not comprehensive.

• @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.

OS 2200 Programming Languages

OS 2200 supports several programming languages, including at least four that are part of the relatively new "UCS" compiler infrastructure. The OS itself is written in a mixture of assembly and Unisys's own PLUS systems programming language. PLUS superficially resembles Pascal with some similarity to PL/I, and actually looks rather nice. Unfortunately, Unisys - while they provide a compiler and manuals - discourages use of PLUS for any reason other than compiling OS 2200 components.

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.

Next Steps

I've been working through the finer points of OS 2200 as an environment for programming, especially relating to the DPS 2200 structured-forms system and the PADS interactive debugger facility. I've been learning a lot and I'm excited for the next steps!

[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.

Back to Let's Play OS 2200!