IBM 1620 - Operating Procedures

Operating Procedures

The "operating system" for the computer constituted the operator, who would use controls on the computer console, which consisted of a front panel and typewriter, to load programs from the available bulk storage media such as decks of punched cards or rolls of paper tape that were kept in cabinets nearby. Later, the model 1311 disc storage device attached to the computer enabled a reduction in the fetch and carry of card decks or paper tape rolls, and a simple "Monitor" operating system could be loaded to help in selecting what to load from disc.

A standard preliminary was to clear the computer memory of any previous user's detritus - being magnetic cores, the memory retained its last state even if the power had been switched off. This was effected by using the console facilities to load a simple computer program via typing its machine code at the console typewriter, running it, and stopping it. This was not challenging as only one instruction was needed such as 160001000000, loaded at address zero and following. This meant transmit field immediate (the 16: two digit op-codes) to address 00010 the immediate constant field having the value 00000 (five digit operand fields, the second being from address 11 back to 7), decrementing source and destination addresses until such time as a digit with a "flag" was copied. This was the normal machine code means of copying a constant of up to five digits. The digit string was addressed at its low-order end and extended through lower addresses until a digit with a flag marked its end. But for this instruction, no flag would ever be found because the source digits had shortly before been overwritten by digits lacking a flag. Thus the operation would roll around memory (even overwriting itself) filling it with all zeroes until the operator grew tired of watching the roiling of the indicator lights and pressed the Instant Stop - Single Cycle Execute button. Each 20,000 digit module of memory took just under one second to clear. On the 1620 II this instruction would NOT work (due to certain optimizations in the implementation). Instead there was a button on the console called Modify which when pressed together with the Check Reset button, when the computer was in Manual mode, would set the computer in a mode that would clear all of memory in a tenth of one second regardless of how much memory you had; when you pressed Start. It also stopped automatically when memory was cleared, instead of requiring the operator to stop it.

Other than typing machine code at the console, a program could be loaded via either the paper tape reader, the card reader, or any disk drive. Loading from either tape or disk required first typing a "bootstrap" routine on the console typewriter.

The card reader made things easier because it had a special Load button to signify that the first card was to be read into the computer's memory (starting at address 00000) and executed (as opposed to just starting the card reader, which then awaits commands from the computer to read cards) - this is the "bootstrap" process that gets into the computer just enough code to read in the rest of the code (from the card reader, or disc, or...) that constitutes the loader that will read in and execute the desired program.

Programs were prepared ahead of time, offline, on paper tape or punched cards. But usually the programmers were allowed to run the programs personally, hands-on, instead of submitting them to operators as was the case with mainframe computers at that time. And the console typewriter allowed entering data and getting output in an interactive fashion, instead of just getting the normal printed output from a blind batch run on a pre-packaged data set. As well, there were four program switches on the console whose state a running program could test and so have its behavior directed by its user. The computer operator could also stop a running program (or it may come to a deliberately programmed stop) then investigate or modify the contents of memory: being decimal-based, this was quite easy; even floating-point numbers could be read at a glance. Execution could then be resumed, from any desired point. Aside from debugging, scientific programming is typically exploratory, by contrast to commercial data processing where the same work is repeated on a regular schedule.