I joined IBM in 1963 and began working on Unit Record installations (punch card equipment). I found the work sometimes challenging but always enjoyable, as I’ve noted elsewhere in this thread. I moved from a sales office to a datacenter in the TimeLife building in NYC. In addition to the datacenter, IBM had an education center and part of Systems Development Division. In the datacenter, I learned the 1401, 1460, 7090, 7044 and 7044/94 Directly Coupled System which used the 7044 as a front-end for I/O and job scheduling and let the 7094 devote itself to number crunching.
When the System /360 was announced in April 1964, we were all given a day’s “training” but only the senior Systems Engineers really got their hands on the new system initially. I recall all of us being puzzled about how the /360 could have 16 Condition Codes expressed with only two bits. It took awhile to get our heads around that and it still confuses people new to the hardware.
Eventually, I began working with the first software made available, Basic Fortran, Basic Cobol, Basic Assembler. These packages booted from a card deck and created an output card deck with the target program preceded by the bootable ‘kernel’ that ran the program and did any I/O required. I graduated to the 16K DOS (after a few weeks of 16k TOS, a tape-based system that was abandoned when DOS came out). DOS was woefully undocumented and I recall writing an ‘operator guide’ & ‘user manual’ for internal use by other Datacenter personnel. Unfortunately, I wrote it one night after working 3 days with no sleep – a regular occurrence in those hectic times. I was mentally foggy and feeling somewhat slap-happy and the resulting document – aside from being badly organized – was a hodgepodge of advice, humor, tips, facts and insanity. It instantly secured my place in the folklore of Early /360 Life.
IBM decided to form a small team to help move what would now be called ‘beta’ software to its more important and knowledgeable customers. They sent three of us and a manager to Poughkeepsie with carte blanche to get any piece of pre-release code, work out the worst kinks, get it to the customer and help them use/test it. One of us focused on Fortran compilers and Link Editor, another on COBOL and Sort. I focused on Sysgen, the process of booting a stripped-down version of OS that would run on most any configuration and using it to create a version customized for the users’ hardware environment and software requirements. Normally, the resulting system would only be bootable on the targeted hardware configuration, but the delivered ‘starter’ system had a special version of NIP (Nucleus Initialization Program) called Smart NIP and I used to install that in place of the one created by Sysgen. The user was then free to add or change his hardware environment without having to do a new Sysgen.
Some programs, including the Fortran Compiler, were notorious for being I/O-bound fetching themselves into memory from the Load Libraries. A clever programmer in SDD created a version of the Fetch routine called PCI Fetch which let these programs load much faster. In one shop where I installed it, Fortran compile times went from 5 minutes to 25 seconds.
I think my favorite piece of software from this project was a program called Superzap. This allowed the user to display and modify anything on disk, program or data, including the VTOC (Volume Table Of Contents, a ‘systems’ file on each disk that recorded allocation of files). I found this program incredibly useful when doing Sysgens, since the Sysgen process took 13 hours of machine time and if modifications were needed, one had to redo the entire process. SUPERZAP often let me make changes without that huge waste of time. I was looking for the documentation and went to one of the managers in SDD. He informed me there was no such program as SUPERZAP. I showed him my card deck. labeled SUPERZAP in bright red magic marker. He again said, “There. Is. No. Such. Program. Do. You. Understand. Me?”. I understood his position – if SUPERZAP were used to modify IBM code, it would be difficult to support a system that had been ‘zapped’ in ways you did not know. I could have gone back to my office 5 miles away and returned with the official paperwork that would have given me the right to any software I wanted and rubbed his nose in it, but I decided it wasn’t worth it. I located the original programmer who gladly gave me sufficient albeit unofficial documentation. I then proceeded to distribute the program to the field, including IBM hardware and software engineers. I knew that once it was introduced to the ‘wild’, there would be no way to prevent it’s use. IBM did eventually release it formally with reams of warnings against misuse.
During the early years, high-level executives and Data Processing personnel from customer shops were constantly visiting IBM’s Poughkeepsie headquarters for demos, consultations and education. IBM had a particular programmer that didn’t fit their clean-cut corporate image. He was a rather obese, bearded chap (in a day when beards denoted hippies and other counter-corporate folks), he walked around in torn-off denim shorts, flip-flops and a white shirt, unbuttoned, no tee-shirt, exposing his big hairy belly to the world. Whenever a delegation of customers were scheduled, there was one secretary whose task it was to locate this guy and sequester him in some remote room where customers would never set eyes on him. I have no idea what he did but it was evidently something so valuable that IBM was willing to tolerate and deal with his ‘non-IBM image’.