|
Hi, Chuck: Nice to see your smiling face. >to save so I restarted it at page 1901 and it took FOREVER to do >... >and while this was going on it CREAMED our other printers. A >printer would ask for form type or get alignment or end of forms >messages and take 5 or 10 minutes to do anything. There were INCREDIBLE >pauses between each spool file printed on these other printers. The >system was NEVER over 20 % CPU and that was the peak. The writer for the >5si did show towards the top of the list but with less than 4% CPU. >Interactive and batch response were GREAT. >WHAT was going on with spooling ? It was not taking a break - it would have been blowing through the spool data, counting pages, until it came to the start point. Page 1901 doesn't sound like a big deal - I'd expect the /400 to take that in stride, and in a hurry. However.... :^) The other system performance being good (and CPU utilization being low) does not surprise me at all. Work Management defaults for spool jobs set them at priority 52, if I recall (maybe that was MY standard, rather than IBM's?), so spool jobs will not impact other work under most circumstances. It sounds like the spooler is operating in the manner of an MRT program, and that's a little frightening, and I don't truly believe that is the case. But MRTs would do this. Bruce? Simon? >HOW is this handled on the system ? Your spooling subsystem ACTLVL is probably set pretty low (WRKSBSD) and TIMESLICE may be set too high (WRKCLS) - you might want to check these. I would expect the system to go into a long wait for disk accesses now and then, which should throw out the job and allow other printers to have some CPU. If you mean, "how does the system find the right page, and continue from there?" my philosophy (never having seen da code) is that it goes through all the same steps as the actual print process, but sends the output to the bit bucket until it reaches the designated point (p. 1901 in your case), where it starts sending data to the printer. As I said, I have not seen the code for this, but based upon your analogy and upon watching the effects of certain actions over the years, I have come to this conclusion. >In all my years with the AS/400 I have NEVER seen anything like this. It >was like the one BIG job (and all in all this wasn't THAT big of a job) >was TOTALLY dominating QSPL or whatever, to the detriment of other >writers but yet otherwise not impacting the system AT ALL (??????? >!!!!!!!!). I suppose, overall, my response is not as much of a helper as it is in support of your question. This is interesting, to say the least. It'll be interesting to hear what those who know QSP* have to say. Dennis -- Dennis Lovelady Simpsonville, SC mail: dennis@lovelady.com URL: http://lovelady.piedmont.net ICQ: 5734860 -- "He is so unlucky that he runs into accidents which started out to happen to somebody else." - Don Marquis +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | 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.