Re: Question on printer priorities and classes

Thanks for all the good feedback.

The QSPL subsystem has its own pool and its resources are managed by the system increasing or decreasing as required. Our response times are good, generally less than half a second and I do not see paging issues in WRKSYSSTS.

We also allow the system to manage memory etc with *calc in paging options.

Thanks

Sent from my iPad

On Feb 3, 2015, at 11:43 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 02-Feb-2015 10:52 -0600, Darryl Freinkel wrote:
We have a situation where we are experiencing delays in reports and
labels taking a long time to get to the printer and be printed. This
issue is primarily with zebra printers.

Investigating the writers, I noticed when looking at split in
WRKACTJOB that some printers run at priority 15 and others at 50.
This is something I never noticed before.

Differences in run-priority for the various writers is normal; presumably, in that case as well. Beyond Work With Active Jobs (WRKACTJOB), use the Work With System Status (WRKSYSSTS) to review the setup and the statistics for the *SPOOL pool; review the statistics [Faults and Pages] while the /printers/ should be doing the work that is apparently "taking a long time".

The slow printers are running at priority 15 and the problem
printers are configured as LAN printers.

The RUNPTY(15) is a higher priority than most all other user-defined [and even much system-defined] work on the system. The QSPL subsystem in which writers will operate [¿by default?] typically is defined to run in a *FIXED size pool. If the high-priority jobs require a large amount of memory but the pool size is small, then the amount of faulting and [non-database] paging will likely be great. With large faulting\paging, a great amount of time might be spent needlessly by the OS on making the job operate within the memory constraints, and therefore less time on actually completing of the operations of the job; offering CPU per the higher priority, to inefficient processes, is generally undesirable because that limits the amount of CPU time for completing more efficient tasks. Ensuring the /writer/ jobs have sufficient memory from the pool(s) of available memory will allow those jobs to operate more efficiently, and thus running with a higher priority has a positive effect, as a reduction in overall time spent completing the task; the lower-priority jobs would still be impacted for amount of CPU-time granted, but impacted over less real-time.

The configuration of the printer device [or remote OUTQ] will affect the amount of work and memory required to process the data before or while that data is sent to the final destination; e.g. being Host Print Transform (TRANSFORM) enabled requires more work [and presumably more memory] than if that attribute is not enabled.

Does anyone know why some printers run at different priorities and
use a high priority value?

The /writers/ default to operate at different priorities [and other Work Management attributes] according to the implementation of the writer; e.g. local-attach physical printer has a different WM configuration than a LAN printer and the default WM for that may be different than a writer for a Remote Output Queue. There are some Class (*CLS) objects in QGPL [IIRC, at least the objects QSPL1 through QSPL4] that define the RunPty [and some other of the run-time WM attributes] of the writer job; the Job Description (JOBD) may define other attributes. A request to Display Job (DSPJOB) of the writer job should reveal the Class and the Job Description used to start the writer job.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.