I still remember it like it was yesterday, that spring day in 1988 when I got a call from IBM telling me to come in to interview for a computer operator position. I was ecstatic when what was considered to be the greatest company in the world, the only one I wished to work for, was going to be my employer. It was a different time then, when IBM represented everything good about American business, and represented the pinnacle of success.
During my first day of work, I was introduced to a machine that was released in 1981, the 3081. I had some experience with an old Univac 1100/63 in college, but until then, I was more familiar with micro-computers, which were best represented by the still fairly-new 80386 and 68030. My first impression of the mainframes was unfavorable. Even by the microcomputers standards of the day, the interface was primitive and far less intuitive than that of PCs. I was not impressed.
The scale of things was shocking. The air-conditioned, raised-floor room was hundreds of feet wide and long, with almost a dozen 3081s and an enormous number of DASDs. We had six printers, which were enormous and almost the same size as the mainframe. There were three sets of consoles, one for the print area and one for the tape area, while the computers were monitored closely in the main console area.
We had three interfaces to MVS, as the operating system was called, which stood for multiple virtual storages, but we derisively referred to it as “man versus system.” There were the system consoles, which were essentially only available in operations: time share option (TSO) and operations planning and control (OPC). TSO was what many people used to do their work, while OPC was mainly for scheduling batch jobs that were going to run on the system. Many programmers preferred to work on VM, which was another operating system IBM offered for the 3081, before transferring their work to the MVS machine.
Our site had responsibility for the customer master record (CMR), which was used by many applications and sometimes directly by people. This ran on an IBM internal application called AAS, which was never sold. There were also some applications on CICS, which was the product IBM sold and is still widely used today by many companies. Many of these applications were critical, and any down time was extremely expensive during normal working hours. In fact, we were told that it cost IBM a million dollars every minute the system was down, which I never believed and still do not. Anyway, after these online applications would go down (usually at around 8:00 PM), the batch processing would begin. Jobs were scheduled in OPC and were submitted in kind of a "wrapper" called job control language (JCL). JCL could run several executables in one job and it specified the resources and order for the executables. You did not tell it explicitly in the executable which DASD to access, as the JCL defined where the input and output were. As mentioned, jobs were tracked in OPC, and were released based on time and/or dependencies. They were sent to the job entry system (JES) and from there were executed.
As mentioned, interfaces were poor compared to PCs of that time, but the reliability of the operating system was far greater than the Windows NT derivatives that we use today. It's something I learned to appreciate over time, and I still marvel at it. The 3081 was a "dyadic" design, meaning it had two processors that even shared the same cache. They could not be split into two computers, as they were inseparable. However, the sophistication of this operating system was such that even if one of the processors died, the system would stay up and continue to execute. The application that was using the failed processor would crash, but it would do so fairly gracefully as the operating system would recognize the failure and send it into the proper place for crashed applications (we'd track them in OPC, and either fix them ourselves or get their support team to take care of the problem). This is not to imply the 3081 CPUs were always crashing, as it was rare when they did so.
DASDs did fail fairly often, although most of the time failures happened when we had to power them down and then back up periodically. This was expected behavior and we always had CEs there for scheduled downtimes to repair those that were especially problematic. Normally, only one or two would fail out of the few hundred on the floor during each power down.
Each 3081 processor ran at a blistering clock speed of almost 38.5 MHz. By IBM's somewhat optimistic measurements, the base 3081 (model D) was up to 21 times faster than the 3033UP, while the higher-end model K was almost 30 times faster. Some of this, of course, came from the extra processor, although sharing the cache did create some overhead. The uniprocessor 3083, for example, actually ran 15% faster than the 3081 when the workload could not engage the 3081’s second processor. The 3084 was another extension of this line, and actually had a pair of dyadic processors. Unlike the 3081, it could be divided into two separate machines. Another improvement of the 3081 was that it could address more than 16 MB and used 31-bit addressing rather than the 3033’s 24-bit addressing. All in all, considering it was released only four years later than the 3033, it was a substantially improved machine. The hardware was good and the stability of the software was just incredible.
I hope the personal tone of this entry does not bore or irritate the reader, but I wanted to give a view of what working with these machines was really like. In many ways they were amazing machines. Still, as amazing as the 3081, 3083, and 3084 were, we were envious of sites that had the 3090, and we had heard the stories of how incredible the performance was.