How did programmers use networking to share expensive computer resources in the 60's and 70's?

Question

I'm young and wasn't alive during the 60's and 70's to experience networking and programming as it once was. I have been watching some talks by Van Jacobson on Content Centric Networking, and in these talks he gives a historical perspective stating that in the 60's and 70's, networking was designed to solve the problem of resource sharing, such as getting access to scarce card readers or high speed tape drives. He then proceeds to say that there was very little data in this era, and that data "didn't live on computers", it was something you carried around with you, e.g. on tapes or printouts.

I have two questions regarding this:

1) How did people "remotely" use something like a card reader? Surely at some point the physical cards had to be delivered to wherever the computer was. If you were 100 miles away, did this mean they posted the cards off ahead of time and then simply used networking to execute the commands necessary to run those card decks?

2) How did people generally get the result of their programs? Was it sent back across the wire, or were print outs/tapes etcetera posted after the program had been run back to the remote researcher?

I apologize if I've gotten my eras mixed up in any way here, as I said, I wasn't alive at the time.

Thanks.

Answer 1

Many businesses in the 60's and 70's used what was called "time-sharing" of remote computer resources.

1) The input was sent by a teletype machine which would send the inputs to the remote machine and the display was printed paper.

2) The program would run and the results would return on the teletype machine. Often the mainframe computer was thousands of miles away.

Telephone lines were usually used as the network transport, sort of an early usage of the modem.

I remember seeing my dad use one of those in the early 70's. The computer was on the east coast and the teletype was in Oklahoma City, OK.

Popular Science Article Describing Time Sharing in the 1960's

Answer 2

Basically, there wasn't a network. To do anything useful, you had to be co-located with the computer. So you took your cards to the ops centre, and put them in a box. The operators then loaded them into the card reader. Results were printed on paper or punched out on cards, and you once again went to the ops centre to pick them up.

Later on, things like 300-baud lines became available, but you couldn't put a lot of data down (or up) them, so you still had to be co-located to do any serious input or output.

Happy days!

Answer 3

There is some good information in this wikipedia article about computer terminals. One of the ways to get away from the punch cards was through the usage of terminals connected to a central system. This led to the need for scheduling algorithms, usage protocols, communication protocols (between system and terminal and ultimately to other systems). Advancements in the physical technology and protocol innovation for varying purposes helped lead away from this centralized computing model into a more networked computing model.

Answer 4

I learned to program using optical cards (fill-in-the-bubble version of the IBM punch cards) that my high school sent off to the local university for execution during slack time. It REALLY sucked waiting a week for the output to come back only to find out either a) you'd put the cards in your deck in the wrong order or b) the operator dropped the tray when loading the reader. We had a HUGE techological leap my senior year when we got a paper-tape punch and could do away with the cards.

More on point, my first real computing job was writing code on a dumb terminal. We fortunately had a local mainframe for most of our jobs. ($5 million machine to support ~300 local users, $500k annual operating costs, dedicated staff of 6 or 7) Every so often we needed to do something on the company's mainline systems in Houston from our Los Angeles location. Response time depended on how important the local management decided something was, b/c higher priority = higher chargebacks, never mind the slow links. And everything got billed back to our department - tape reads, CPU usage, paper costs for greenbar print output etc.