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



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.


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.