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