×
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.
James Lampert wrote:
Jim Franz wrote:
you have an option in endjob for max log entries - change to a small
number... 1
This will keep it from taking forever (if job log is what it is tied
up in)
Also, if ended "controlled" the delay time should be short.
No apparent effect.
Would pulling the QBATCH subsystem out from under it help?
James:
AFAIK, and especially if you're working with older OS/400, a
subsystem doesn't end _until_ the jobs within it end. In that sense,
you _can't_ pull QBATCH out from under it.
If the job is ending, then QBATCH will simply stick around until
your job does end. Further, if it's handling more than just a
single-threaded job queue, once you start ending QBATCH, no other
jobs will start in QBATCH until it has ended and restarted.
Granted, there are 'abnormal' ways to end jobs and subsystems; but
I'd vote for letting it finish unless that becomes totally
unacceptable. The time it might take to recover can be more than the
time it takes to end... and that assumes you'll know what needs
recovery in a reasonable time frame.
BTW, what OS/400 or i5/OS (or ?) are you running?
Tom Liotta
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.
midrange.com
