Typical runs are done on known routes at known distances, but every once in awhile you just start running with an idea in mind and get a bit carried away. Other times you get more than a little carried away. These three running stories stick out in my memory as the extremes of the “more” side.
Back in my high school days I lived in North Dayton, a little more than three miles from the center of downtown Dayton. I wasn’t a long distance runner at the time, but I was in pretty good shape, so when some friends were meeting in Centerville to play some basketball, I decided I would just run there and have a nice longer run. But I wasn’t familiar with the southern parts of Dayton and had no real idea of how far Centerville was, but I guess I figured it couldn’t be too far since I just needed to go through Kettering and into Centerville. Didn’t know about Oakwood and Washington Township. By the time I made it to the basketball court in Centerville I was pretty tired, and only later found out I had run a little over 13 miles. Had the story ended there it would certainly qualify as unexpectedly long, but I then proceeded to play 45 minutes of full-court, one-on-one basketball. I was not only in decent shape, but I was also decently stupid. By the end of all that, it was all I could do to crawl into my buddy’s car and let him drive me home, hardly able to move.
Sometime in my late forties, the MeadWestvaco Information Technology leadership team went on an overnight retreat to Hueston Woods, one of Ohio’s large state parks. I had been to Hueston Woods many times and back in the days when I owned a motorcycle, the park was one of my favorite country destinations. After the first day of the retreat we had about an hour or so before our dinner reservations, so I laced up the running shoes and started running down the road, roughly following the shoreline of Acton Lake. I was feeling pretty good that particular day, so after I ran a couple miles to my initial turnaround point, I decided I would just keep going and run around the entire lake, figuring it would add a couple miles to my planned 4 mile route, as the lake wasn’t that big. A couple miles later the lake’s shoreline was nowhere to be found, but I knew I was going in the right direction, so I continued. A couple more miles passed, I was getting a little tired, and the roads were totally unfamiliar. But turning back at this point was certainly going to result in a very long run, so with a prayer, I continued forward. Now dusk was upon me and a little apprehension started to fill my mind. How far did I have left? Would I get there before dark? Am I really lost? Nothing worse than the fear of the unknown. Finally, and with great relief, I returned to the main road that led to the lodge, relieved that only a short distance remained. Exhausted, I went to my room, showered quickly and joined my group as they were eating dessert, having to explain my absence, but the look on my face probably said it all. I was so tired that all I could manage was to drink several glasses of water, as the thought of eating food was unpleasant. I sure had a great sleep that night.
Much of my formal mainframe training occurred in Crystal City, Maryland, located just west of Washington National Airport (now Ronald Reagan Washington National Airport) and southwest of Washington DC. One of my favorite runs was a two-mile trek over to the north end of the airport, stopping to enjoy jet planes on their final landing approach, roaring a few hundred feet above my head, with their landing gear down, wings at full flaps and the plane tipped slightly backwards to land rear wheels first. On one particular trip my friend Jim Nicholas and I travelled together, so I had my running buddy with me when we headed over to the airport. We were both in good shape and felt great that day, so instead of heading back to the hotel, we looked at the Washington Monument in the distance and figured that didn’t look too far, so we headed up to I-395 which would get us across the Potomac River and into DC. First lesson was that large objects in the distance are much farther away than they look. So when we finally entered DC at the Jefferson Memorial, we had run another three miles or more. But we were in DC and pumped up. We ran over to the Lincoln Memorial, then to the Washington Monument making a loop through the city. Then we learned the second lesson, we had to run back, and without the emotional benefits of exploration we had heading into the city. All told, our modest run turned into a half-marathon or more, but ended with one of the best running stories of our life.
Thursday, August 30, 2018
Friday, August 10, 2018
Wright State Days
My time at Wright State University (WSU) spanned six years, the first three being your normal full-time course load and working part-time jobs, and then three years working full-time for their administrative computer center and fitting in my senior-level courses. Both my student and professional time at WSU were full of learning that seemed endless, much different than the limited and directed nature of high school. Below are some of the memories that stand out from those days and reflect my lifelong lack of fear at jumping into whatever seemed interesting and fun. Much of this is related to mainframe technology, so while the terminology may be totally foreign, I hope you find it reflective of my favorite double-negative saying, “The best thing I never learned was that I couldn’t do something”.
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.
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.
Subscribe to:
Posts (Atom)