× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Question on how the AS/400 handles "spooling"
  • From: "Dennis Lovelady" <dennis@xxxxxxxxxxxx>
  • Date: Thu, 14 Jan 1999 15:55:04 -0500

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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.