RiscLua 8

Yep, both tape and disc, depending on outside factors*

80 Column punched card is the standard. Code lives between colums 8 and 72. Columns 1-7 tend to contain line numbers and 73-80 can contain comments. Code in any of these spaces will be ignored / cause errors.

Indentation / placement of ‘pic’ definitions is (from memory) defined by company coding standards – I never actually had to deal with punch cards, so don’t know if it’s an actual issue with them. Banks in particular tend to be pretty hot on their standards, though – funnily enough.

.* For real extra fun, there’s a secondary utility language called ‘JCL’ (job control language). This is used for scheduling programs on to the mainframe – it dictates memory localtions for working storage, required executables/libraries, volumes (disk/tape again) and provides logical mappings between files referenced in the program and files on the storage volume. The volume information is required because sometimes that means halting processing and flashing up a warning on the operator console to get up and go change a bloody-great disk pack in a big metal fridge thing somewhere.

Even better than that, JCL is also used for submitting programs to the mainframe for compilation – you submit the job, wait for it to get its timeslot, watch it fail and then print out a few thousand pages of core dump to see what you did wrong (in COBOL it’s usually leaving out a full-stop somewhere). Or if you’re unlucky, you spend time debugging the JCL instead because the program you wrote to compile your program has a bug in it…

80-column punched cards may have been the standard (though there was also a 96-column version), but the usage of the columns was certainly not fixed. It depended on language, and company standards. In our case, using PL/1, code was 1-72 and 73-80 was sequence numbers (if you did not want your day ruined when a box of cards was ‘shuffled’). I remember JCL well … and the times we had to wait 2 days for a compilation or test. Submissions were well desk-checked first!

Sorry, yes – I meant standard for COBOL. And, if memory serves, RPG – though RPG’s prescriptiveness made COBOL look positively lackadasical.

It was always bizarre in later years – developing Microfocus COBOL apps for Linux/Unix systems, using a Win32 COBOL-specific IDE and still having the same column restrictions. We were using COBOL-85 standard, so there was no backward compatibility excuse for it, just seemed it never occurred to anyone to get rid of it. I have a sneaking suspicion that even their OO-COBOL and COBOL.net offerings suffered in the same way too.

We were lucky at the bank in having a COBOL-II desktop compiler that caught most stuff before it went off to the mainframe for compilation. Didn’t catch everything though and that was where the fun began.

Oooooh! RPG. That was certainly not a free-format language. Several pre-printed forms, each with a myriad of columns for things. Was described as a civil-servants language – a form for every bl***y thing! But we ran a factory with it on an 8K machine.