On Sun, 15 Jul 2007 13:47:48 -0400, John S. Giltner, Jr. wrote: >Johnny Luo wrote: >> Sorry for a newbie to jump in here... >> >> But I have a question: why IBM doesn't increase the clock of mainframe CPU? >> There is no need or there are some technical problems? >> >> I'm now working at one customer's site and every day's afternoon is a >> terrible time for all developers working on their development system: we >> just cannot use TSO/ISPF! You must wait 4 or 5 seconds for a response and >> sometimes you just hang there. The cause is that most teams will do their >> batch tests at that time thus eating all of CPU cycles. I guess they might >> need a more powerful CPU? (This situation has last for three months since I >> came here) > >For the same reason that Intel and AMD, or any other processors, don't >just increase their clock speeds. Reliability. > >What zSeries box do they have? I doubt very much that they have a fully >loaded z9 and are waiting 4-5 seconds for response time from TSO. >Unless your zSeries is maxed out on the number of processors, it could >just need an additional CPU, not necessarily a faster one. > >The question is not what response time your developers are getting, but >what response time are your customers getting?
In my world, developers are just as much customers as anyone else that uses the machine. They are more fun to harrass than outside customers though. > >If you company is like most, they really don't care about the response >time that developers get. As long as the customers work get done they >are happy. > > >Heck, for the distributed applications we have our users would LOVE to >ONLY wait 4-5 seconds. One application we converted from 3270 to Web >went from 2 seconds response time to 15 second response time. We have >customers that refuse to use that application. They have another way to >perform the same function that is still 3270 and they use it. > That sounds familiar. Are you hosting IBMLink ??? I have a situation with outsourcers who work from the other end of the world. Their work hours conflict with nightly batch processing and what used to be off-hours processing like backups and DB reorgs. They complain about slowness and we see nothing but great responses in TSO. Then it becomes a tracking exercise to find in what part of the infrastructure they're stalling. It really requires an end-to-end monitoring tool that we don't have just yet. You may be experiencing bad response time, but that doesn't necessarily mean the machine is not responding. You need to look at TSO response times via Omegamon or some other monitor to isolate where the slowness lies. In my case, I also found developers running file scans in TSO that could be done in batch. When resources are short, TSO second & third period performance is very bad. Good Luck. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
