Re: 24 x 80 is too small.

["trevor perry" <trevorp@xxxxxxxxxxxxxxxx>]

Ok, let me make it simple. I am not referring to the design of block mode.
Simply the fact that previous iSeries/AS400s/S38s ran SLOWER than they do
today. Performance was slow, we were using block mode, so we designed
systems that had cluttered (er, FULL) screens. Now that performance of
iSeries has been improved so much, block mode works much faster, and we no
longer have to design cluttered screens in a reaction to poor performance.

Didn't I say that already?

----- Original Message ----- 
From: "Douglas Handy" <dhandy1@xxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, February 25, 2004 10:10 PM
Subject: Re: 24 x 80 is too small.


> Trevor,
>
> >By modern I was not referring to block mode. What I was saying was that
we
> >used to design according to poor performance - that being caused by block
> >mode.
>
> On the contrary, IMHO block mode leads to *better* performance on systems.
It
> is what allows the offloading from the main CPU of handling keystroke
level
> processing and lets a IOP like the WS controller handle the traffic until
an
> "Attention IDentification" (AID) generating key is pressed.  It is only
then
> that a program must resume execution or be swapped back into storage, and
this
> allows the main processor to handle more tasks more efficiently.
>
> With this model, interactive programs spend most of their time in a wait
state
> so the CPU can service a higher volume of concurrent users or get more
batch
> work done while awaiting the next AID request from a block mode device.
>
> If the program had to run to service each key press and release, you'd
have much
> more task dispatching going on and you'd need much more horsepower for
good
> performance with the same number of interactive users.
>
> With block mode, you can only get "poor performance" when a block is sent
and
> received.  On underpowered systems where that is true, you could get much
worse
> performance if the system had to respond at the keystroke level instead.
>
> Block mode is why we could have subsecond response times with multiple
> concurrent users even when the entire main storage was 48-64KB (not MB) on
the
> early S/34's.  And by using MRT's, we could handle an even higher
concurrent
> user load in a given amount of main storage.
>
> And if we were working with remote workstations over a speedy multipoint
2400bps
> line, block mode was even more beneficial...
>
> Just my .02,
> Doug