|
Neil, In a message dated 97-07-28 19:58:52 EDT, you write: > > Despite my upping both jobs to priority 10, setting purge for both to *NO, > > and setting both timeslices to 100,000, neither is consuming more than 18% > > CPU with nobody else on the systems. > > > > Last week, we asked our Systems Engineering department for some help > > with our > > BPCS conversion program's performance under the same circumstances, and > > they did _something_ to make it run with more CPU percentage. > > Increased the jobs TIMESLICE value or RUNPTY, and maybe there were other > competing jobs running at the same time and therefore an increase may > have helped here ? Other jobs were a consideration at that time, but we had already increased the RUNPTY and TIMESLICE ourselves. <<snip>> > > Check system value QDYNPTYSCD on RISC system. It was on on the RISC, our SE's are looking into it now. > What is sysval QPFRADJ set to now vs. then ? '0' in both instances. > Is the 'expert cache' (Paging option *CALC, from F11 on WRKSYSSTS) set > for the pool you are running the batch job in ? *FIXED > Changing you priority to 10 isn't going to do a thing for you if there > are no other jobs competing for the CPU between priorities 10 and 50 at > the same time. > > Never mind the CPU usage of the job, how long is the job taking to > complete now vs. what it took before ? Is it still quicker than it was? > With a faster CPU on the new machine a job that may have been CPU bound > could now become disk bound, and unable to eat as many of the new faster > CPU cycles as it it could the slower cycles on the old system. > Were there any changes made to the disk configurations ? Actually, based upon our benchmarks from when the Production box was a 320, it's running much slower now. I think that I failed to mention that this is an SQLRPG. The program used to start out slowly in Transactions per Minute, but gain speed as it progressed through the database. Now it seems to remain at a constant TPM rating throughout its duration. Add to this the fact that the disk arms nearly doubled when we upgraded, and the speed becomes even more confusing (note that this was a MOVE rather than an upgrade, so we don't have the old disks getting more I/O than the new ones). Interesting point about the "binding" shift though. It's entirely possible that the program is now just "doing all that it can do", although that doesn't explain the slower performance (other than the fact that it's an OPM program). I'll keep trying... Thanks! Dean Asmussen Enterprise Systems Consulting, Inc. Fuquay-Varina, NC USA E-Mail: DAsmussen@AOL.COM "There is no abstract art. You must always start with something." -- Pablo Picasso * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the Midrange System Mailing List! To submit a new message, * * send your mail to "MIDRANGE-L@midrange.com". To unsubscribe from * * this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe MIDRANGE-L' in the body of your message. Questions * * should be directed to the list owner / operator: david@midrange.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
