Binder REP Cards Was: What's the linkage editor really wants 3293

(Anne & Lynn Wheeler) writes:

I feel your pain. I could never understand how anyone could make an buttembler run so slowly. I suppose it takes a certain perverted sort of imagination - the kind prized by bureaucrats - to be able to think of ways to bog down a process that much.

The same was true of the buttembler on the Univac 9300 (their answer to the 360-20). I had a production program which had grown to 2000 cards. It took 40 minutes to buttemble. The buttembler would read the deck in and then sit there doing lots of disk I-O for a looooong time before the printer woke up and spat out the listing.

So I wrote my own buttembler, which did the job in half the time (and as a bonus included a cross-reference listing, which Univac's buttembler lacked). When you're working on a single-tasking machine in a shop where programmers have rock-bottom priority, such a time saving is well worth it.

The 9300's object decks were punched in "compressed code", in which the holes related to bits in a byte in a way which was very simple and totally consistent (unlike EBCDIC). So patching their equivalent of TXT cards would have been much easier. Still, I was lucky enough to learn early on that the 9300 supported REP cards in its JCL. Specifying addresses and data in hex was much easier. Even with my own buttembler, that 2000-line program took enough time to buttemble that I avoided re-buttesmbling as long as possible. The JCL would wind up containing dozens of REP cards before it finally collapsed under the weight of the patches - then, and only then, was it time to re-buttemble the program.

-- I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!