[Dshield] P.S. Re: Your father's internet

[Jim McCullough]

"Programmers who open-coded it could still pooch the
entire box though."

Does that mean bring everything to a grinding halt? Or, what the wires
glow cherry red and have the room fill with the wonderful stench of
fried electrical components?

On 7/24/07, Valdis.Kletnieks at vt.edu <Valdis.Kletnieks at vt.edu> wrote:
> On Mon, 23 Jul 2007 15:44:13 MDT, WebMaster at Commerco.Net said:
>
> > An S/360?  Wow, if memory serves, at least you did not have to worry
> > about preemptive process interrupts on those babies... I don't think
> > they had any. ;-)
>
> (I started off on a S/360-65J (wow. 1 meg of fast storage, and *3* meg of
> Large Core Storage - much denser but slower - 9000 ns cycle time. No, that's
> not a typo. ;)  and an HP 2114 (basically a PDP-8ish box, a whole 32K of
> donut memory).  Teletypes at 110 baud, and anybody who's used an ASR33 *KNOWS*
> why all the early Unix commands had 2-3 letters and no error messages.  Oh,
> and the reason VMS was so chatty was because when *it* got designed, the
> 1200 baud DecWriter was already available.  Much quieter, and you didn't mind
> a 3-line error when it went bzzt..bzzt.bzzt... instead of WAPPA WAPPA WAPPA. :)
>
> Not only did you need to worry about preemptive interrupts on the S/360 (fortunately,
> the operating system took care of *most* of those issues, like the fact that
> some unit-record devices had a one-record buffer, which meant that if the card
> reader was reading 1,200 cards per second, you *had* to service 1,200 interrupts
> per second, and within a specific amount of time - if you got the I/O interrupt
> from the card reader, you had to go read it *now*, because if you delayed
> for too long, you'd get an overrun, which counted as an I/O error, and it came
> to a screeching halt and you got to fish all the cards out and re-input the
> job.
>
> Consider that even the model 65 was a 1-MIP machine with a stiff tailwind,
> and the smaller ones, like the model 40 and the not-really-a-360 model 20,
> were much slower.  If you're taking 1,200 interrupts a second on just the
> card reader, and the line printer is going that fast too (fortunately, the
> 1403 printer understood chained CCWs, so you only had to interrupt once every
> few lines to service it), and maybe a few disk drives and tape drives going
> as well, and you only have 500K instructions/sec to get *everything* done,
> you got some *tight* coding down in the operating system, and even the
> high-end multitasking systems like OS/MVT had some serious realtime constraints
> in the I/O handlers...
>
> And then the bigger models had the issue of "imprecise interrupts" - under some
> circumstances a program interrupt could come back *late* (as in several opcodes
> after it executed).  Much hilarity ensued if you did something like this in
> user mode:
>
>          L       R1,somewhere_in_LCS
>          L       R0,some_flags
>          SVC     something              Call the operating system
> ... change to supervisor mode via the SVC
> ... invalid-address or protection-exception from that load from LCS finally
>     arrives
>
> The operating system then commits hari-kiri, because program exceptions in
> the supervisor are a Should Not Happen.  Fortunately, most of IBM's macros for
> calling the operating system happened to include a serializing instruction
> like BALR before issuing the actual SVC, so the interrupts would be taken while
> still in user space.  Programmers who open-coded it could still pooch the
> entire box though. (Don't ask how I found out about *that* one.. :)
>
> The supercomputer of the day, the model 91/95, which did 6 million floating
> point ops a second, had not only all those issues, but also was one of the
> first pipelined machines.  Took programmers a while to get their brains
> wrapped around *that*. ;)
>
> _________________________________________
> SANSFIRE 2007 July 25-August 2 in Washington, DC.  56 courses, SANS top
> instructors, and a great tools and solutions expo. Register today!
> http://www.sans.org/info/4651 (brochure code ISC)
>
>


-- 
Jim McCullough

"Just because the standard provides a cliff in front of you, you are
not necessarily required to jump off it."

    Norman Diamond