I was a Systems Analyst. I helped salesmen prepare proposals, I did benchmarks and conversions, and customer training. Univac couldn't afford to put a computer in every branch, so I had less access and opportunity to program, than our customers. Made support awkward.
We also had internal competition and friction. The 9000 and 1100 teams resented if their technology was not pitched to a prospective customer. The 9000 was lower-end than 1100, but there was enough overlap in the mid-range.
I also programmed the CADE 1900, a data entry system that paid for many trips throughout Canada and the U.S.
Before that, I wrote apps in IBM mainframe Assembler for a life insurance company.
(Sorry I didn't reply sooner, I had not seen the question).
Thanks for these interesting insights. It's hard to imagine today how scarce computers actually were at that time. The assembler was for the System/360?
The Assembler (Basic Assembler Language or BAL) was for the Univac 9300 and 9400, clones of the IBM 360. Univac originally made and sold the 1100 series, with the Exec 8 O/S. The 1100 was a 36-bit machine, very successful in airline reservation systems, petroleum exploration, etc. but it was incompatible with IBM's 360 architecture. Univac developed the 9000 so IBM customers could easily convert.
The 9300 I programmed had 32K, tape drives, card reader & punch. It ran NCOS (Non-Concurrent OS). It had no virtual memory, so we had to write our own "overlays", sections of code that were loaded at beginning and end of a run, for initialization and wrapping up. No console, just sixteen lights to display error numbers, and eight butterfly switches for writing directly to memory.
That's fascinating. I spent significant time with early MUMPS and the machines of the time (https://github.com/rochus-keller/mumps/) which had a comparable amount of memory.
Was your whole insurance application only assembler, i.e. no COBOL or RPG at all?
The company started out with RPG. There was no COBOL compiler. They had to start processing health claims on paper tape, which could only be read with Assembler. They hired me to learn & write Assembler. We converted the master file update (40,000 cards, two hours twice a day) to Assembler, when I discovered a way to store 240 digits per card: twelve bits/column = three decimal digits. It was the 70's (7 = 0111), so our cards looked like lace doilies. Reconstructing jammed cards was fun.
I left the company after three years because I could only compile & test at night or on weekends.
Comments
Wow. Must feel like a completely different world compared to today. May I ask what your work was?
I was a Systems Analyst. I helped salesmen prepare proposals, I did benchmarks and conversions, and customer training. Univac couldn't afford to put a computer in every branch, so I had less access and opportunity to program, than our customers. Made support awkward.
We also had internal competition and friction. The 9000 and 1100 teams resented if their technology was not pitched to a prospective customer. The 9000 was lower-end than 1100, but there was enough overlap in the mid-range.
I also programmed the CADE 1900, a data entry system that paid for many trips throughout Canada and the U.S.
Before that, I wrote apps in IBM mainframe Assembler for a life insurance company.
(Sorry I didn't reply sooner, I had not seen the question).
Thanks for these interesting insights. It's hard to imagine today how scarce computers actually were at that time. The assembler was for the System/360?
The Assembler (Basic Assembler Language or BAL) was for the Univac 9300 and 9400, clones of the IBM 360. Univac originally made and sold the 1100 series, with the Exec 8 O/S. The 1100 was a 36-bit machine, very successful in airline reservation systems, petroleum exploration, etc. but it was incompatible with IBM's 360 architecture. Univac developed the 9000 so IBM customers could easily convert.
The 9300 I programmed had 32K, tape drives, card reader & punch. It ran NCOS (Non-Concurrent OS). It had no virtual memory, so we had to write our own "overlays", sections of code that were loaded at beginning and end of a run, for initialization and wrapping up. No console, just sixteen lights to display error numbers, and eight butterfly switches for writing directly to memory.
Imagine running an insurance company on 32K!
That's fascinating. I spent significant time with early MUMPS and the machines of the time (https://github.com/rochus-keller/mumps/) which had a comparable amount of memory.
Was your whole insurance application only assembler, i.e. no COBOL or RPG at all?
The company started out with RPG. There was no COBOL compiler. They had to start processing health claims on paper tape, which could only be read with Assembler. They hired me to learn & write Assembler. We converted the master file update (40,000 cards, two hours twice a day) to Assembler, when I discovered a way to store 240 digits per card: twelve bits/column = three decimal digits. It was the 70's (7 = 0111), so our cards looked like lace doilies. Reconstructing jammed cards was fun.
I left the company after three years because I could only compile & test at night or on weekends.
Cool. So at least the work-hours haven't changed much since ;-)