On Mon, 18 Oct 2010 14:26:29 -0700, Edward Jaffe <edja...@phoenixsoftware.com> wrote:
> >I had no idea this was the case. IMHO, this behavior seems "wrong". At the very >least, it violates the "principle of least astonishment." Had someone noticed >this when MPF was first written, it might have been APARable. > >-- Ed, As I said, it was a concious design decision at the time to do it that way and was done to mollify the people that insisted that if a message was suppressed from display, that it'd still be available somewhere else. We can look back on the decision now and say that it was dumb, but at the time, suppressing messages from display ran into a lot of opposition, even though an operator couldn't survive without it. We ran a lot of human factor studies back then on message rates, and what we found was that an operator couldn't handle more than about a message a second on a sustained basis. We also collected and analyzed a lot of SYSLOGs and came up with my Rule of Thumb: an upper bound on message rates is approximately 0.1 message / second / MIP for a system running a broad mix of work -- batch, TSO, CICS, IMS, etc. At ~27 MIPs, a 3084 given that criteria had a message rate of ~2.7 messages / second which was beyond what our human factors studies said an operator could handle. That is of course aggregate, but what we also found out was that the bulk of the message traffic was going to route codes 1 & 2 which was the master console. You could try to split some of the traffic off to other consoles, but the master console (and the operator assigned to it) became the bottleneck. This all seems quaint by today's standards, but it was quite a problem at the time. I still remember having to present to the Poughkeepsie (hardware) Lab Director (a guy known as "Black Jack" Bertram) and tell him that his shiny new 3084 couldn't be operated (and possibly not sold) because of the message rate problem. To put it politely, he wasn't happy. And that is how MPF very quickly came into being, warts and all. At least some of the warts are fixable... W. Kevin Kelley -- IBM Pok Lab -- z/OS Core Technical Development ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
