Adventures in Information Technology
Information Technology has certainly changed over the course of the author's three decades of experience. My first exposure to Information Technology arrived in the form of programming classes taken as part of a degree program in Computer Science.
An introductory course in FORTRAN proved to be quite an adventure. At the time, late 70s, neither interactive terminals nor personal computers had been thought of.
To write a FORTRAN program, the first task was to go to the University Library and purchase a pad of FORTRAN coding sheets and a large stack of punch cards. After creating the logic for a FORTRAN program, the next step was to convert the design into program code and place the code on the coding sheets. The character positions held special meaning when programming so coding sheets were used to make sure the the proper characters appeared in the correct positions.
The Key-Punch Machine
Remember the large stack of punch cards mentioned above? These cards were used as the input of the program code and data. Interactive computing had not been developed yet, so the data had to be included with the program instructions. The entire program was read from these punch cards, along with the data, then the job ran as a batch.
However, before the computer could read the cards, the programmer had to place the programming instructions and data on those cards. In a university environment, the task of programming a computer for a student entailed waiting in lots of lines at the library.
The first line was for the key-punch machine. As a student you would grab your large stack of punch cards and the coding sheets for your program and you would get in line and wait for an open key-punch machine. There were five key-punch machines available to students so the line could be quite large, depending on the number of students trying to write programs at the time.
Once you gained access to a key-punch machine and typed up your cards. Each line of code from the coding sheet represented the content of one punch-card. If there were 100 lines of code to your program then your card stack for the program would be 100 cards.
After you punched up your cards, you got into and waited in another line.
With a freshly punched stack of cards for a program, the student would next attempt to compile and run the program. To gain access to the mainframe computer, an IBM 360/370 at the time, the student required access to a card-reader. There was one card reader available to students so gaining access to the card-reader entailed waiting in another line.
When a student finally made his way to the front of the line, he handed his beloved stack of cards to the computer operator. The computer operator loaded the stack into the card reader and added the job to the mainframe's job queue. After the card-reader read the cards, the computer operator handed the stack back to the student.
I'm finally done! Nope ... time to get into another line.
No More Lines
The author will not wait in line to be seated in a restaurant or to see a movie, I wander why?
Waiting in line for hours without end can take a toll on a person.
The Job Printout
When the mainframe's job queue arrived at the student's job, the computer would attempt to compile and run the program. Did I mention that the punch-cards had to be in the correct order? I guess not, well, the punch-cards had to be in the correct order or the compiler would encounter a syntax error and terminate the job.
The eager student, having finally entered his job into the computer's job queue, wished to see the results of his program run. So, you guessed it, he waited in another line for a printout. The printouts were spit out of the printer in the order the mainframe encountered them with batch identifiers separating them. The computer operator would grab the runs off the printer, separate them, and announce which student jobs he had so the student's could retrieve them. The computer operator handled the print jobs when he had no card decks to feed into the card-reader.
So the student gets his printout. He is done ... right? Well maybe. If the program compiled and ran without any errors then the student had a printout demonstrating a successful program compile and run, which he could hand in to the professor.
If there were any errors in the program, then the student had to debug the program.
I believe that the idea of drawing flowcharts to design programs actually came about as a method to describe the process of waiting in line, which was a necessary endeavor to write programs as a student of Computer Science in the 70s.
The Debug Process
The compiler encountered a syntax error so the program did not compile and run. What was a student to do? The only solution was to debug the program.
With a little bit of luck, the compiler indicated what line number held the syntax error. This being the case, the student would take his coding sheets and locate the line number in question. The card that held that line of code would then be removed from the card stack and replaced with a new card. Wait a minute, I do not have a card punched that will fix the problem. Guess what ... back in line.
After locating the bad line or lines of code the student repeated the process of waiting in line.
- Wait in line for a key-punch to type the replacement card/cards
- Wait in line for the card-reader
- Wait in line for the printout.
The student would then repeat this process until either the program successfully compiled and ran or the student gave up.
How things have changed. Today i can design, code, compile, debug, test, and execute programs on my notebook computer where ever I happen to be. No more waiting in line.
What do you think? I'd love to hear from you.
Please leave a comment.
For an example of simple modern programming, continue to Essentail HTML Tags.
Updated on September 23, 2011.
More by this Author
The System Development Life Cycle (SDLC) comprises 9 basic components. Those components are explained here in this sample term paper.
This sample term paper was written to cover the topic of gathering requirements for a class in system development and design.