GOTHIC was a mainframe assembler program that read a single input card and printed out, sideways, each character using multiple lines of asterisks, creating large letters in a Gothic-looking font. Since the mainframe printers used continuous forms, GOTHIC was perfect for creating large fancy banners, many feet long, announcing birthdays or other special occasions. But GOTHIC was written for a DOS (Disk Operating System) mainframe, not the MVT (Multiprogramming with a Variable number of Tasks) version we used at Wright State, so it would need some modification to work, which I decided I would try, even though I didn’t have a clue what assembler language was, that class still a couple years away. Undeterred, I slowly came to understand that most of assembler language was a one-to-one mapping to the actual instructions that mainframes execute, for example, that an AR (Add Register) adds the contents of one of sixteen registers, essentially a really, really fast place to store a number, to another register. That was good news, as all those instructions did not need to change. The other piece to GOTHIC was something I learned were called “macros”, and those were different between DOS and MVT. One by one I swapped one macro, for example, a DOS DTF (Define The File) to its MVT equivalent, a DCB (Data Control Block). The program changed, I received some help with the JCL (Job Control Language) need to compile, link and execute GOTHIC and submitted it. A bit later I was asked to come back to the office of John Sloan, since then a great friend and one-time townhouse mate, where I was told my program crashed MVT because I had not “saved my return registers properly”, which at the time I had no clue what that meant, but it was the one last difference between DOS and MVT. However, I was pretty sure that a mainframe should not crash because of a simple student error. All ended well, GOTHIC was converted and was a big hit for years to come. And it got my name known within the administrative computer center, which opened more doors in the months and years to come.
The last quarter of my freshman year included learning the COBOL (COmmon Business-Oriented Language) programming language. To stretch the mainframe’s limited resources, the class used WATBOL (WATerloo CoBOL), a teaching compiler developed by the University of Waterloo in Ontario, Canada. All proceeded well until the last assignment of the quarter and I couldn’t get my program to run without issuing an error and stopping. I checked the code over and over and tried a number of ways to figure out the source of the problem until I stumbled upon an unlikely “fix”. Adding a simple “PRINT” statement at a certain point in the program, for some unknown reason, bypassed the error. But this statement also meant my output didn’t look right. I was sure the problem was with WATBOL and not my program, and with my professor’s permission and support, I converted my program to COBOL, figured out how to create real MVT datasets, and copy WATBOL’s file data to the needed input files. I spent the first week of my summer break in a mad rush to complete this transition and was rewarded when my program, now running in a real COBOL environment, worked perfectly and I was able to turn in that final assignment and rest assured that my diagnosis of a WATBOL error was correct. It was a great lesson to learn early in my career that, even widely used programs like WATBOL can contain bugs and that nobody is perfect.
But perhaps my biggest accomplish of all was writing the new, online Admissions system for the university. I had spent a year or so as a student employed as a maintenance programmer for the administrative computer center when the decision was made to have an online program developed to enter the data needed for an applicant to be considered for admission to Wright State. I jumped at the chance given me to write such a new and visible system, and spent countless hours learning how to write IMS (Information Management System) DB (Database) and DC (Data Communications) programs, dividing it into four separate programs to fit into the available computer memory, adding features, security and working out the bugs. In the end, these four programs totalled about 40,000 lines of COBOL code and were used for many years to admit students. Not too shabby for a 21-year-old puppy in the I.T. profession.
As I was writing the new Admissions system I learned the tedious process of creating BMS (Basic Mapping Support) maps, a set of statements that described where titles, labels, input fields and their attributes would display on a IBM 3270 terminal and map it back to the format used by an online program. This was very much a repetitive, trial-and-error process of preparing a card deck, assembling it and testing it out on a terminal until it was perfect. I decided to write an online program that would allow a programmer to type everything needed, starting from a blank terminal screen, and let the program create the BMS statements, essentially reversing the existing process, making it visual and much less iterative. IBM expressed interest in acquiring it, as nothing at the time was on the market that generated maps like my program. They ultimately decided not to, but it was pretty exciting to create something brand new and have the dominant technology company of the time even consider it.
My friend Jim Nicholas hired me as his assistant systems programmer in late 1977, an opportunity I jumped at as few people were able to break into this advanced technical field as a senior in college. While working full-time stretched my final academic year into three calendar years, I learned at the hand of one of the very best mainframe guys to walk the planet. Jim moved on to The Mead Corporation in 1979 and I stepped into the large shoes he left behind, hoping I was not too outmatched for the job. The big project I had to accomplish was converting our SVS (Single Virtual Storage) mainframe operating system to MVS (Multiple Virtual Storages). I had worked with Jim when we converted from MVT to SVS, but now it was all up to me to use SMP (System Modification Program) to install and configure MVS, apply all the needed PTFs (Program Temporary Fixes), update HASP (Houston Automatic Spooling Priority) to JES2 (Job Entry Subsystem 2) and make updates to the existing system modifications. The amount of change was staggering, but thanks to learning from the best, the conversion was a success.
Back in these old days, data was inputted to mainframes via punch cards, each of which consisted of eighty columns containing a code for each character. But as IBM 3270 terminals became common in our offices, it made sense to input the data directly to the mainframe and bypass the cards. I worked with one of the ladies who keypunched cards all day, leveraging my assembler language classes and my desire to learn VTAM (Virtual Telecommunications Access Method), IBM’s newest way to communicate to the mainframe from terminals, RJE (Remote Job Entry) stations and other devices. It was a fun little project, nothing as crazy as GOTHIC, WATBOL or the other stories, and I thought nothing more would come of it. But during my job interview at Mead, one of the projects they needed someone to take on was adding VTAM support to their homegrown, online Fast Response system and were surprised, and maybe a bit unbelieving, that I had already built a similar interface as a student. But rattling off how I had used VTAM’s OPNDST and CLSDST macros and lots of other details left little doubt I had gained this obscure skill at a young age. It wouldn’t be the last time that I would learn something because it seemed like fun which later turned out to be useful on some other project. Funny how that works out that way.
Wright State not only provided me with a top-notch Computer Science education, it afforded me the support and resources needed to learn beyond the curriculum, provided my first full-time job and many opportunities and experiences that let me advance my career at an accelerated rate. I’ll be forever grateful for the beginning they gave me.