James E. Henderson wrote:
> boblq wrote:
>
>> On Friday 23 June 2006 09:57 am, Nicholas Wheeler wrote:
>>
>>
>>> PS: 7 years of Linux experience makes me a newbie. Ya'll must be grand
>>> masters.
>>>
>>
>> Chuckle, my first work with computers was in 1961. The machine filled
>> several rooms and was full of tubes.
>> Carl goes back further. So I think does Jim Sack.
>> So yes, you are a newbie. Sadly though, that does not make us grand
>> masters,
>> just "experienced." LOL.
>> BobLQ
>>
>>
>>
> Me too! I started in 1959 on a giant machine that used tubes, a
> Burroughs 220. I remember that the mean time between failures was about
> 15 minutes. It was slow and fussy, with a 4K mercury delay line memory
> and punched card input/output.
The winner!
my story:
I had a Heathkit analog computer (tubes) to play with about that time,
but I guess that doesn't (er..) count. Also at that time, I suppose I
might have gotten involved with an IBM 1620 in the EE dept, but I
changed my major to physics.
So it ends up my first real hands-on experience was about 1962 in
grad-school on a GE-225. I used Fortran-II (aka card-fortran, it had the
simple IF-statement -- no steenkin' else-branch needed).
As I recall, the mainframe had 32K of 60-bit ram (core, or course).
There were 2 6-ft tall tape drives for holding the fortran
compiler,assembler, etc, and for building intermediate code products, I
think. The final output was a card deck spit out by the nifty card
punch. Then you added job control cards and your data deck at the end
and the whole package was fed into a card reader right at the console.
I believe the system was reputed to be something like a half or a
million bucks. The main computer room was at least 1000 sq ft.
I thought it was quite an honor when they allowed me to run my own
programs as a sanctioned console operator on Saturdays. I had to
open up, start the beast (bootstrapping from toggle-switch instructions
that read and executed a card in the card reader. As I understood it
that card had instructions to read the rest of the bootstrap code from
the remaining cards in the reader. All of this is really not too far
from what we do now, eh?
My program decks, I could hold in one hand usually, but some guys had
huge programs they carried around in multiple punchcard boxes (1000 each
box?). There are many horror stories of programmers who neglected to use
the (optional) card sequencing field in cols 81-90(?), and learned their
lesson after one experience dropping their deck. You young'uns need to
know that there were card sorting machines to put things back together.
They were pretty nifty machines, too!, those card sorters. I believe in
earlier days, they may have played a large role in the business machines
industry.
There was a wonderfully fast and noisy line printer, about the size of a
mini-cooper (maybe just slightly less), which spent a large part of its
time printing compiler error listings and coredumps -- when it wasn't
being reloaded with paper.
There was a job-control requirement for specifying max CPU time and
printer output, so the cost of runaway programs was somewhat controlled.
During normal operating hours, people submitted their job-decks and the
operator spent all his time feeding decks into the reader, and servicing
the printer. There may have been some programs or libraries that
required loading special tapes, too. Card jams in the reader and punch
provided additional entertainment.
For trivia day, I'll tell about one cute little trick that made it
easier to separate job output.
The "jobname" from the jobcard was printed like an ascii "banner"
program (ah, so that's where that term came from, you say), and it was
arranged to print on two sequential pages, and the two pages each had
printing that overlapped the perforations -- whereas normal output
skipped ('to channel 1', double-score trivia points) the page boundary.
"So what?", you say: the operator could look the edge of a foot-high
stack of printout and see where each job started, because regardless of
whether the previous one used an odd or even number of pages, _one_ of
the printed perf-boundaries would always be visible. Then it was a
simple matter of dividing at each such boundary, and delivering separate
job output stacks to the output rack/table.
Ahhh, for the good old days (not!).
..jim
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
