When I Was A Young Warthog: MSU Physical Plant (Part II)

This is the continuing story of working at the Physical Plant (aka “The Fizz”). See part one here.

During the semesters (technically, “quarters”), I worked about 12-15 hours per week. I was able to choose my work hours to mesh with my class schedule, so they were different each quarter. As I said before, I often signed up to do Friday backups, since I didn’t have to rush home to study for an exam the next day. During breaks, we worked a full 40-hour week, even Christmas break. We also worked 40 hours during the summer. This job paid (barely) for school and rent, along with a few scholarships and grants from the state.

We used an HP3000 mainframe, which ran the MPE operating system, a proprietary Hewlett Packard system. (I’m sure you’ve all heard of it.) It was set up for system administration and user management – most of the commands I used had to do with running programs, checking on users, running backups, etc. I don’t recall it having many (or any) really low-level functions that UNIX had, although it may be that it had those functions and I wasn’t aware of them.

We used COBOL, which is a language that has been around for many years and is popular for the kind of software we wrote. At one point, we started using a language called PROTOS, which was a COBOL-like language. The purpose of this language was to make it easier to write COBOL – running the PROTOS code actually generated COBOL code, and that COBOL code was then run on the system. Progress!

We used KSAM (Keyed Sequential Access Method) files. KSAM storage consisted of two files – one file, the Index file, which contained a listing of what was contained in the second file, called a Data file. For example, if you wanted to find where information about a certain employee was stored, you could look in the index for the employee’s social security number, and the index would tell you where in the data file that information was kept. Kind of like an index in a book – you look for the keyword in the index, and it tells you what page it’s on. When data was added or removed from the data file, the index file was updated to add or remove that information.

We used some basic text editing tools – we used an editor called “SA1” and it was not too different from the well-known vi editor in UNIX. It had plenty of archaic two- or three-letter commands to do various things. To print something, the command was “LOA”, which stood for “List Offline All”. SA1 was written by one person, possibly in his spare time, and wasn’t very widely used in the industry from what I could tell. We also used a product called SUPRTOOL (super tool!) that allowed various macros to be executed, a simple version of the modern day Perl script, but with much less functionality. SUPRTOOL would allow us to directly query information from KSAM files, among other things.

Our primary printer was a large line printer in the room with the mainframe, but we also had laser printers around. The LaserJet II was new at the time, and we had Laser Jets (aka “Laser Jet I”) around as well .

We had the first optical scanner I had ever seen – you could scan a page on a device that looked like a small copy machine, and some software would try to figure out which words were on the page. This technology was fledgling – on one page I scanned, every letter ‘a’ on the page was interpreted by the software as ‘@’.

We had a 286 PC in the office running Windows 3.1 that was used for various purposes, but our primary workstations were terminals to the mainframe. A terminal is a fairly unintelligent machine – it’s basically a screen with a keyboard and knowledge of how to get information to and from the mainframe. Almost all of what’s seen on the screen is provided by the mainframe. You could make some small changes to the terminal (for example, whether the text was white on black or black on white). No data was stored in the terminal; there were no hard drives or floppy drives. [Most of MSU’s programming class work was also done on terminals at the time – I’m pretty sure we had DEC VT100 and VT220 terminals. Later, we used Sun workstations more regularly. All these computers/terminals had different keyboard layouts, and at one point I was proficient at four different keyboards, including the one on the Tandy PC I had at home.]

In the mornings, we could come in to find the printers (or the printer paper baskets) full of reports that had run overnight. Whoever was assigned to distribute the report followed a list of recipients and either put them in a mailbox or put them in an envelope to be routed to the correct office. Some days had more reports than others, and different reports ran at different times. For example, some reports only ran at the end of the month. We sometimes had to edit a file on the system to put in dates for certain reports to use. If it was a report that covered the prior two weeks, we would type in the date from two weeks ago. When the report ran, it opened that file, read the date from it, and used that date to figure out what to print on the report. We had a sheet in the computer room with all the reports for that day, and which dates or other information needed to be entered for them, if any. Some reports had their own set of instructions in a big manual. The instructions would tell you exactly what to type to fill in the dates/information.

Most of the software design was done by the supervisors, and they did a good job at it. We did code reviews, which is a meeting where programmers look at copies of another programmer’s work and make comments and verify the logic in the code. Reviewing code doesn’t always weed out the problems, though; I remember one big bug that occurred in some code I wrote that caused several people to lose some of their work. That code had been reviewed and tested, but there was a problem anyway.

On rare occasions, there would be a problem we couldn’t easily diagnose, so we would attach a line monitor to the cable connecting the mainframe and the terminal. There is always a tiny chance that a cable or the environment is causing signals to be corrupted, and by using a line monitor, we could see exactly what bits and bytes were travelling through the cables. The output was fun to watch – a long line of numbers, letters, and oddball characters that programmers are used to seeing, and then sometimes someone’s full name or an address or business letter would scroll across the display. I don’t remember what we did about it when we noticed a cable was not delivering the signals correctly – we probably replaced the cable. [To be more specific, a union electrician probably replaced the cable – we were not allowed to make our own cables, nor were we allowed to run those cables from one place to another. That was union work.]

Some of you will remember the Y2K issue – the problem where many computers were storing dates with only two digits. 1987 was stored as 87, which was going to be a problem when the year 2000 arrived. Since most software considered the date to be the two-digit year + 1900, the year 2000 was going to be considered 1900 (the last two digits of 2000 + the number 1900.) The supervisors of our office did a smart thing – a few years prior to my joining the crew, they had either rewritten or updated all their software to account for the year 2000.

Since we were system administrators, and were responsible for all the software, we could run any of the programs on the mainframe, including the payroll software. We knew how much everyone in the office made, including our bosses and the other students. One day we were looking at the pay rates of the students who worked upstairs in the engineering office and noticed they were all making about a dollar an hour more than we were. When we asked our supervisor about that, she said they were not allowed to wear jeans or shorts to work. We were allowed to wear shorts and jeans, and we wanted to continue doing so. Our objections to the pay difference quickly disappeared.

This job was very helpful to me when I was applying for jobs after graduation. The economy was in a mini-recession in 1991 when I graduated, and having this experience helped me a lot.