Originally Posted by DoubleDAZ
Re Univac, we had switches that we could set to step through the code one instruction at a time and follow along with a code sheet, alter instructions on the fly, etc. This was all circa 1965 when the Air Force Supply System got their own mainframe computers, had their own cadre of operators/programmers, and controlled the specs and coding. We made plenty of mistakes because it was all learn as you go and we were adapting the supply system to automation at the same time we were learning that automation. They were fun times and if I could go back tomorrow, I would.
Ya gotta be kidding......this from someone who has punched instructions in from the Univac computer's front panel for simple I/O test routines...ala Altair..
"Writing Code" for mid-60's era Univac computers was just that--carefully entering your "code" into paper "coding sheets"....scratch, scratch, erase, erase...
It then took many hours for someone (someone else if you were lucky) "typing" at the IBM Card keypunch machine--which was very slow, required very strong fingers and hence was murder for touch typists.
After carefully checking say the first few thousand IBM Cards (one line of code per card), you submit the several pounds of card decks and come back the next day to pick up your "source listing" (several inches of printout) to see how many syntax errors had to be fixed by repunching the guilty cards....REPEAT as necessary until it passes the Card Verification ('spell and syntax check') process.
[Even "moderate" sized programs would fill one drawer up to several file cabinets with card decks and source listings.]
THEN you could submit the one or more boxes of IBM Cards to see if it would either RUN (and hence good enough to save both the source listing and compiled object code on a tape image)....[On-line code entry to tape image came along later....]
Or CRASH....which it invariably would.....resulting in a briefcase sized printout called the "core dump" which showed the contents (in Octal) of each and every memory location. Knowing ONLY that there was an illegal operation (usually divide by zero) in a particular memory location, you could then manually "de-assemble" the Octal numbers back into their respective machine instructions so that you could then try to figure out which module/sub-routine/code line was "involved" in causing the problem....so that you could START the debug process....so the average debug "rate" was pretty pathetic....I remember chasing my tail for many days before I uncovered a problem in the compiler's MathPack--the COTAN function call was hozed for certain ranges of angles....
Even though I had access to my first Univac "Personal Computer" in 1967, it still took several minutes to many hours to "run" most programs (using "high level" code compilers), after spending perhaps half an hour or more to load the IBM Card decks. Of course, that time got much, much longer whenever the Card Reader decided to spew out a scrambled stream of 52-card pickup....
I don't miss it---nor the (itchy) paper tape that was later used to load vintage (1973) Intel 1702 EPROMS (for Intel 8008 uproc). Incredibly, they used ten ASCII characters on the tape for each 8-bit byte on the EPROM via the infamous "BNNNNPPPPF" format (Begin, Negative, Positive, Finish). I guess the excessive time to read the paper tape (via slow TTY reader) was helping to cover up how slow it was to actually program the EPROM.
If only we could do comm engineering without all that messy software......HAH!!!!!