Computer OS preference

Speaking of PDP's, my first "PC" at work was a Robin - a VT100 with a floppy drive. Later I got a Rainbow, and used it for WPS+ and Lotus 1-2-3.

 

I remember when the VT100s came out. They were exciting and fast. Prior to that we mostly used teletypes of one form or another.

Tom

 

In the early to mid 1980's, Honeywell TDC 3000 used their version of Unix. I knew OS 210.M1 inside and out, and could go on for hours about DEB/PED procedures.

You know, Tom, some of us are really showing our age when we talk about such Old Iron

 

My first (unsuccessful) attempt at programming was on the mainframe at college. We would use a card-punch machine to create a stack of fortran punch cards, and then hand in the cards. The program would be run at night, and the next morning we'd get a print-out of our results. In my case, this invariably consisted of compiler errors. I never got a program to compile.

A few years later, while taking classes at another college, there was a teletype machine that connected directly to a computer the size of a very big filing cabinet. Programs could be saved, and fed back in, using punched paper tape. I actually got programs to run, but they were simple ones.

I'm not sure I understood back then that there was such a thing as an OS.

My Kaypro 2X was years after that.

 

Punch card readers were fun, they always needed cleaning to work properly. Those machines remained in fairly constant use up through the mid 1980's, some departments kept them longer yet

 

Punch card interface - great for computers, a nightmare for humans.

 

I've told this story before ..
My father was consulting for a research institute in the early 70's that had just moved from punch cards to a mainframe with terminals. It was a *huge* success, and allowed the programmers to use an interpreted language that checked syntax line by line. Whoever wrote the interpreter had a sense of humor: syntax errors led to profane cussing from the machine directed at the programmer.

 

Oh dear

In todays highly litigious environment, the person at the terminal would sue for undue mental anguish and receive therapy for the rest of their life

 

Speak for yourself (about the fun part). When I took a COBOL class in college, we had to submit programs in decks of punch cards. The problem with machine created errors (I would type an A and an A would be printed at the top of the card; what would be punched was anything) got so bad, that I would have 3 decks being submitted to catch the errors. Then when I pulled out all of the errors, I would be left with a single deck that I submitted for grading. Punch cards were a real drag on productivity. No wonder the card punch machines are enjoying a new life as boat anchors.

 

OK, here's my favorite punch card story, from Hughes Electronics.

In the mid-70's, satellites had to be relatively small and light (compared to modern ones) to launch on the rockets of the time. The weights and measures group was one of the prime movers in satellite development. One day the weights guy showed up at the programming shop.
"You haven't turned in your weights sheet for your software!" he complained.
"Software doesn't weight anything so we didn't think we had to fill one out" the head programmer explained. Not to be deterred, the weights guy picked up a deck of punchcards off the desk.
"This is software, right?" he challenged.
"Well, yes," the programmer admitted.
"OK, so what does it weigh?" The programmer thought a second, then responded.
"So you think the deck of cards is the software?" the programmer asked.
"Of course!" the weights guy answered'
"Well, you're wrong. The software is the holes in the cards, not the cards, and the holes don't weight anything" the programmer explained.
"Oh, OK," the weights person said, and wondered off. The software group was forever more exempt from the weights and measures requirements.

 

So maybe there was nothing wrong with my program at all: The card punch machine didn't punch what I had written!!!?!?!?!?!???? I never could figure out what I had done wrong. This makes me feel a lot better about that early attempt at programming. Of course, other people's programs ran...

 

It is very possible. My first experience with submitting a program that was punched was extreme frustration; I had carefully written out the program statements needed to perform the required function. I then typed out the punch cards with the program statements and submitted the job for execution. The error result that came back was as if a complete pile of garbage had been submitted.

I then tried testing individual program instructions to see if I had missed anything (there was a separate syntax tester where you typed in a program instruction to see if there were any syntax errors). No syntax errors were found. After the syntax test, the immediate reaction was that I didn't know how to string program statements together. Add in the time pressure of a hard deadline for submission of the programing project and limited opportunity to submit new jobs (jobs would be run every 4 hours from 8 a.m. to 11:00 p.m.).... The image of a meltdown was fast approaching - it was: Wth! these program statements have worked in the past, I am just making a more capable program that strings multiple functions together; and, and, and. Each time I submitted a job, the error count grew and the type of error was completely not related to the functions I was attempting to accomplish. More use of the F word and pacing trying to figure out what was happening. Then the computer lab closed for the evening and I was no closer to completing my project.

The next days program submissions were repeats of the previous days' results. I could see that I was going nowhere fast and so, it was time for a timeout that I could not afford to take given the hard and fast deadline that was one day away. However, without taking a timeout, I was going to biff the project. So I took off for 4 hours and played racquetball for 4 hours straight.

On returning from the racquetball break, I was wondering if there might be problems with the deck itself. That was the epiphany. I then checked each and every card in the deck to compare what was typed on the top of the deck against the actual punched holes to confirm or dispute what was printed in the respective column on the card, and BINGO!, errors all over the place. I spent the next 8 hours re-typing and re-checking the replacement cards to be sure what was punched was actually what needed to be punched. I submitted the deck of cards in time for the last run of the day and when the output was generated, magically I had a program with no errors....

After that experience, I would run 3 decks and pull out the erroneous cards after the first run (deck1 card2 would have an error, which was replaced with deck2 card2 which had no errors and so on), which would result in one complete deck with no errors. It was a most inefficient way to operate, but given the certainty of key punch errors, the only way to operate.

The next quarter, I took a BASIC programming class which used data entry consoles to enter the programs. My first question on using the data entry console was why did we have to endure the misery of the punch cards???? The answer was that the punch cards were a form of filter - the people who didn't have the aptitude for programing were filtered out (but that didn't address all of the keypunch problems that were not the fault of the person writing the code...). BASIC introduced a whole new type of torture - how to make a large program (that was larger than 64K bytes) run in a 64K byte space, but that is another matter.

 

Either the card punch machine needed cleaning, or the card reader needed cleaning. Every time the puncher knocked out that little rectangle of paper, the cutout had to go somewhere

There is a collection bin in a puncher to catch most of the little bits of paper. However, they ended up everywhere, and sometimes the puncher could stick and/or hit the wrong slot on the card

It was common for little cutout pieces of card to stick to the punch card, especially as the puncher became worn. Remember a certain incident in Florida with hanging chads? Not only did the handing cutout cause jams in the reader, the reader could be easily confused

I've run the same batch of punchcards through the reader several times, and had different output. Scary to think that for most of the cold war, such technology determined whether or not to launch ICBM's

Oh bunny, we are *really* showing our age to the forum youngsters, with tales like that

But what you described wasn't that unusual with punch cards. It's a wonder the Air Force didn't launch ICBM's, or that banks could even properly balance their books, back when everything depended on punch cards

 

Many years later, when I had the Kaypro 2X, a 64K computer, I learned Basic. I discovered that if I tried to copy a large array into another large array, the interpreter would not simply copy from one to another; it would create a third array to use to make the transfer, often resulting in a failure of the program because there was not enough memory. That seemed so stupid to me that I started asking people if I should try to learn assembly, and someone suggested C instead. From then on I did all my programming in C.

When multi-tasking and event-driven programming came on the scene, programming became too tedious for me, and no longer fun. I am sure there are compilers now that can do the tedious stuff for you (set up a window and manage re-sizing and fetching of input, etc., and let me just write the code for the stuff I want the program to do) but I don't feel like spending the money.

 

RSX-11D came on the scene in 1972. It was multi-user, multi-tasking, and event driven. RSX-11M was a smaller footprint version, suitable for smaller PDP-11s.

Tom

 

Or, the punch machine just got misaligned. When I was being tormented by the keypunch machines, I found that the machines would get serviced on Monday and Tuesday. Each day after being serviced, progressively more errors would creep into my decks of cards. It got to the point where I stopped using the keypunch machines after Wednesday.

When programs would get moved to operational status or weapons control, they would be loaded onto a tape drive that was a bit more reliable than the punch card readers. But there were other episodes that came close to pressing the launch button. Hardware and software failures resulted in several false launch alarms that had to be confirmed by checking back-up radar and satellite sensors separately, which ultimately denied the launch warning. All of which was too close for comfort....

 

I'm a big fan of "whatever works."

XP on my home desktop, XP on my laptop, an oldish version of Ubuntu Linux in one of my offices and Mac OSX (Leopard) in another office.

Basically, I use what I need, where I need it. I use Linux at work because I need a number of packages written for Unix (that work in Linux). I use Mac OSX at the other office because I tend to do a lot of multimedia stuff there and I want to do some of my Linux-focused stuff there, too.

I just ordered a new Mac laptop and I'm seriously tempted to triple-boot between OSX, Ubuntu, and Windows 7. That might be crazy, though.

 

In the department where I got my PhD, there was someone who had written a stellar evolution code and had an early version on punch cards. He wanted to save that version. So, he sent the boxes and boxes of punch cards off to some place in Pennsylvania that can still read them and got back a CD with one little, tiny track on it.

 

I have a MacBook Pro and have Ubuntu and Windows 2000 installed using VMWare Fusion. I also have Win XP installed under BootCamp. I would run Win XP instead of Win 2k under Fusion, but when I try to launch XP using emulation, it thinks I'm trying to use it on a different computer and wants a new activation code.

 

Okay, well, when it came on the scene for me.

When I was studying Spanish at NDSU in around 1993 or -4 there were some Unix workstations running X-Windows. Since they were so much faster than my PC-AT (!) I wanted to port a cool graphics program I had written onto them and have it run in color (my PC-AT had a monochrome Hercules graphics card) and so I asked the computer guy how to put a pixel of a given color at a given location. I thought that was all I needed to know.

He replied "It's not that simple" and showed me a stack of books about 4 feet high which constituted the X-Windows programming manual. "But," he said, "you only need to read the first two volumes to get started." I got halfway through the first volume (the size of a big-city telephone book) before I gave up. I did learn the concept of event-driven programming sufficiently to heartily dislike it.

Later, when I had my first Windows computer I bought a C compiler for it and had a go at it, but it was too tedious to be fun anymore.

I have not tried programming since.