First of all, I would never have the subsystem set up to 1 job only. In
your case I would set it to *NOMAX. If performance gets to be an issue,
then I would choke it down from there.
Secondly, you have the KIS job queue choked down to 1, however you have
different job priorities setup with either 0, 1, or * (nomax). Never
heard of using 0 in a job priority. But if that's there to discipline
people to assign the right priority, ok I guess. If the max you have in
any one priority is 1, and you're careful to ensure that jobs that have to
be ran consecutively are in the same job priority then I see no harm in
kicking up the total for that job queue to *nomax.
You still have job queue QS36EVOQQ to put a job in, if there are no
consecutive run concerns. On my system the closest name is QS36EVOKE, but
perhaps something is lost in the translation? And I think that last one,
QTXTSRAH, is called QTXTSRCH on my system (as in Text Search).
I once tried using Job Priorities (1-9) instead of different single string
job queues. I found it too easily to mess up and use the default
priority. And most users cannot assign priority 1 or 2. The default
"Highest scheduling priority" on CRTUSRPRF is 3.
DSPMSGD CPF1147
And while our vendor package allows us to store different job queues to be
used I don't think it allows us to assign different job priorities.
I'm not saying it's bad practive, it just wasn't my preference.
Rob Berendt
As an Amazon Associate we earn from qualifying purchases.
This thread ...
Re: Strange issue maybe you can help me with Mark, (continued)
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.