14

In a batch programming system developed in the late 1960s - early 1970s at the Joint Institute for Nuclear Research in the city of Dubna near Moscow, it was possible to dump object files to punch cards in "binary" format, then use those punch-card equivalents of binary object files in a deck together with sources. A typical object file on punch cards looked like this:

.............................................................................O..
..O.............................................................................
..O..O.....O..OOOO.......OOOO.....OOO....OOOOOO...OOOOOOO...................O.O.
.....O.....O..O...O.....O....O...O...O...O.....O.....O..........................
..O...O...O...O....O....O.......O.....O..O.....O.....O.......................OO.
..O...O...O...O.....O....OOOO...O.....O..O.....O.....O......................OOO.
.......O.O....O.....O........O..O.....O..OOOOOO......O.......................O..
O.O....O.O....O.....O........O..O..OO.O..O...O.......O......................OOO.
........O.....O....O...O.....O...O...O...O....O......O......................O...
O.......O.....OOOOO.....OOOOO.....OOO.O..O.....O.....O..........................
............................................................................OOO.
............................................................................OOO.

.O...O..........O...O.............O...O....O...O..........O.OO.O.....OO.OO...O..
....................O.............O........O...O..............O.....OO...OO.....
....O.O........................................................O...OOO.OOO..O.O.
..O........................................................O.O.O....OO...O......
..O..OO...............................O.................................O....OO.
....OOO...................................................O.O.O....O...O....OOO.
..O..O...............................................................O...O...O..
O.O.OOO..............................................................O.O.O..OOO.
..O.O...........................................................O..O.O...O..O...
O...............................................................O......O........
....OOO.O.......................................................O....O.O.O..OOO.
....OOO.........................................................O..O.OOO.OO.OOO.

.....O....O.....OOO....OOO.OO.....O...O.O.OO...O.O......O....................O..
.O......OOO...O..O.....OOO..OO...OOOO.....O.O.OO................................
....OO..O....O.OOO....O.O.OOO....OOO.O..O...O.O..O......O...................O.O.
..O...O.OOO..OO..O......O...O..O.OOOO...O...OOOO.O...O..O..........O...O........
.....O..OO...O..O..O...O...O.....OOO.OO.....O.OO............O................OO.
..O.O....O...O.O......O...O.......O.O........O.O.......O....................OOO.
..O..............O......O...O.......O........O............O............O.....O..
O.O.O........O.O.O.O..O.O.O.O........O....................O.O...............OOO.
..O..............O......O...O....................O...O....O...O.............O...
O.O.O.O........O......O...O....O..........O......O...O..........................
...............O.O....O.O.O.O....................O...O....O...O.............OOO.
..O.O.O........O.OO...O.OOO.OO.O..........O......O.O.O....O...O........O....OOO.

.O.O.O........O........O........O............................................O..
.OO...............O...OO..O....O................................................
....O.O..O....O...O....OO..OO...OO..........................................O.O.
..O...................OO..O....O................................................
..O..OO....................O....O............................................OO.
..O.OOO................OO..OO...OO..........................................OOO.
.....O....O....O...O.......O....O............................................O..
O.O.OOO...O....O...O....O..OO....O..........................................OOO.
....O.................OO..O....OO...........................................O...
O.O....................OO...O...OO..............................................
..O.OOO...O....O...O.......O................................................OOO.
..O.OOO..OO...OO..OO..OO..OO...OO...........................................OOO.

(An equivalent assembly language code is 42 lines long.)

Each card contains its ordinal number in the "object file", a parity column, and the module name in ECMA-1 code (with uniquely Cyrillic letters replacing the controls and some punctuations). The last card has an EOF flag.

In addition to Soviet mainframes, there were CDC and ICT computers at the JINR. Did their programming systems, or any other programming systems of that time, include such a capability, or was it a Soviet invention out of necessity, because magnetic tapes were in short supply and not of a particularly high quality?

Improve this question
11
  • 2
    If you don't restrict the question to punchcards: It was quite common to have binary object code on papertape for basically all the DEC PDP models.
    – dirkt
    Jan 12, 2017 at 13:02
  • Also, looking at IBM's JCL, it would be easy to include object files in a punched card deck. I've no idea if that was actually practice, though.
    – dirkt
    Jan 12, 2017 at 13:05
  • I used punched cards for source code (or a CDC Cyber (70?)) , but have never seen it mixed with object. What would be the point of that?
    – Mawg says reinstate Monica
    Jan 12, 2017 at 14:16
  • 1
    @Mawg The object code typically used fewer cards than the FORTRAN source; (definitely fewer than the assembly language source) and saved CPU time.
    – Leo B.
    Jan 12, 2017 at 17:29
  • 1
    @Mawg Compiler-output, of course.
    – Leo B.
    Jan 13, 2017 at 15:40

3 Answers 3

Reset to default
11

It wasn't just a Soviet thing:

… This time I decided to look closely at the program deck. By now I knew just about everything there was to know about the source deck. The program deck was quite different from the source deck.

To start with, it was a much smaller stack of cards. There were no letters typed on the top of the cards, and there were lots of punches in each of the cards. Lots of punches! In fact, some of the cards looked almost like lace. Clearly in order to verify that the compiler had done its job right I would need to learn how to read these cards as well as I could now read the source deck cards. I took the program deck to Bob and asked him how to decipher all those punches.

“Don’t worry about it,” he said. “This deck of cards, your object deck, is punched with a binary coding system that only computers understand. You could figure it out if you really had to, but you don’t.”

— Dale Fisk, describing Programming with Punched Cards on an IBM 360.

Douglas W. Jones' Punched Cards for Computer Programs also has some examples of instruction/binary/data cards.

Improve this answer
3
  • Cool, thanks! Punching the object name in large letters is a nice touch, tough.
    – Leo B.
    Jan 12, 2017 at 20:28
  • BTW, I found a decoding template for the binary format of 1130 punch cards. 54 16-bit words on a card.
    – dirkt
    Jan 14, 2017 at 12:00
  • @dirkt It's interesting that they were not concerned about the physical rigidity of the punch card. In the format shown in my post, each 6 bytes used 5 columns (giving 84 bytes per card because the first 4 and the last 4 columns were used for identification and error checking) to guarantee that at least every 5th column has no punches.
    – Leo B.
    Jan 14, 2017 at 17:28
6

If you didn't have access to (magnetic) backing store then the only way to keep your executable code once you'd compiled/assembled your source code would be to output the working file to paper tape or punched cards. However as a student in the late 70s, it was more a case of retrieving the job to correct source code errors, or runtime program faults; once you'd got a good run of the program and kept its printout you rarely needed to store the executable, as you wouldn't need to run it again, you'd be editing the source to make another executable, which you'd run once after you'd got the source code right.

Dirk is right about paper tape - we used it in an installation I can't name on a project I can't talk about for precisely that purpose, until 8" floppy disks containing all of 250KB per side became available.

Improve this answer
1
  • Think of the utility subroutines. Even during debugging of the main algorithm, it make sense to save the CPU resources by not having to recompile known good parts of the code again and again. And those utility subroutines could be reused.
    – Leo B.
    Jan 12, 2017 at 17:36
4

Punched card object files were used as a "standard" method of distribute software in some low-volume specialized applications. In the 1970s, magnetic disks were not generally portable, and the proliferation of incompatible magnetic tape hardware and software being developed made it problematical for a small scale software development team to produce tapes that were compatible with every recipient's hardware. Some form of binary data on cards was guaranteed to be compatible and readable, and the standard-size 2000-card package was physically almost indestructible by international post and courier services, since it was pretty much a large solid brick-shaped block of cardboard.

For example, working for a jet engine manufacturer, we had the task of shipping software that simulated engine performance to all the airlines flying the engines. We had an informal network of colleagues in other companies which allowed porting and testing the software on as wide a range of computer systems as was necessary, but we certainly didn't have the expertise to understand all the tape hardware and software formats used by hundreds of airlines, nor did we have access to the hardware to write every type of media that they might be using. But everybody's computer system could read a box (or more usually, several boxes) of cards.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .