[sclangdon]

My first job was as a COBOL programmer on an IBM mainframe (OS/370 I believe) for Xerox. The system was absolutely massive and incredibly difficult to navigate. There were thousands of files with names that only had 6 characters. So everything was a two-letter system code, followed by four digits. LP0456, OP0234, SB1245, etc.

Then, in each of those files the variables had similar names in order to cut down on unique identifiers. WP100, WP101, up to the max number you needed at any given time. It was a nightmare. There was as much external documentation to keep track of all of this stuff as there was code.

On top of that, you could only build programs overnight in a batch process with the rest of the system, which was run by a different team in a different country (Spain, I believe). So you would write your program in the day, phone up the guys in Spain and explain that there was a new program going in and you were responsible for it. Problem was, if your program failed to build it would hold up the whole system, which HAD to be up and running and live again by the morning. This meant that every time you made a change that went into the nightly build you also had to be on call.

I remember eagerly watching the build queue at 1AM, waiting for my file's turn. Then immediately shutting everything down and going to sleep the moment it was successful. If it wasn't successful, well, then you had to fix it on the spot and phone Spain again to tell them to give it another try. Unfortunately, you rarely knew why it was failing.

[univacky]

Filenames? We used to DREAM of having filenames!

Writing COBOL on the UNIVAC 490 series (30 bit word, FIELDATA character set), our files were on tapes. A tape request was submitted to the tape library, they would pull the tape(s) containing your file(s), and deliver them to the operations floor.

The customer would submit hand-written transactions, which would be sent to the keypunchers, who would punch them onto cards.

The tapes and transaction cards would be sent to the ops floor (where there was the actual computer). The operator would load the first tape in each file onto a UNISERVO tape drive, and go to the patch panel to run wires to assign logical devices to physical devices. ( https://www.computerhistory.org/collections/catalog/10266686... see page 57)

Then they would put the job deck into the card reader and enter the "UR" (read the Unit Record device) command into the console, which had a spool of paper, not a screen. When the program was awaiting input, they would load the transaction cards and give the console command to continue the program.

We did have a fearsome beast of a FASTRAND drum system for random-access storage, but that was just for executable code and temporary files.

Then you might well get called in the middle of the night, because one of the programs in the job aborted. They called it "aborted" then. Or ABEND (ABnormal END), if you were an IBM person. You would come in, read the core dump (reading core dumps was a valuable skill), and determine that there was a data problem in a transaction (e.g. an alpha character in a numeric field). You would find the offending card, pull it, tear it in half and set it aside to be addressed in the morning as a missing transaction, and tell ops to rerun the job. With luck, there were no bad cards after that one.

Tell that to kids today, and they won't believe you.

[zozbot234]

> ... ABEND ...

Sorry, I don't know German.

[deadbeeves]

Luxury.

[dewey]

I shall never complain about resolving merge conflicts or dependency issues ever again.

[CodeSgt]

Good God that's awful lol. Say what you will about the state of software development today but at least we aren't there lmao