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



Actually AFaIK the controlled ENDSBS request instigates a controlled end for each job. In the archive message http://archive.midrange.com/midrange-l/200705/msg00943.html I suggested that the conditions of HELD and END are mutually exclusive, and therefore the controlled ENDJOB effects and implicit RLSJOB [and presumably with no CPC1163 denoted action by a user that could perhaps be identified as *SYSTEM or as I suggested then by *ENDJOB]. Thus the /controlled/ end enables the jobs in the subsystem to reach their coded test for "am I ending controlled" rather than remaining held until they receive the /terminate immediate/ instruction at the end of the timeout.

Since I allude to the lack of message, I doubt any evidence will be in the DSPLOG if indeed originated by the ENDJOB itself. However the various /job data/ that is [may be] tracked by the established system auditing, there may be a T-JS entry recorded for the 'R' release activity in addition to the 'E' for the end activity, however I would guess there too, the implicit nature of the release may leave one wanting for an explicit indication.

Regards, Chuck

Pete Massiello wrote:

Ending of a SBS would NEVER release the job. Find the job log, or do a DSPLOG and I bet you will see the message Job
NEVEREND/SHERLOCK/123456 has been release by DAISYDUCK.

Good hunting.

JDHorn wrote:

I'll try to be more clear

We have a job running all day in qbatch that checks our data every
1 minute to see if it should go to an ftp site to retrieve data
from one of our customers in response to data we sent them.

Someone held it during the day using option 3 on the wrkactjob
screen. (If you did a wrkactjob of qbatch it was at a hld status)

it stayed at the hld status till 10:30 pm

during our automated night process, subsystem qbatch is ended
controlled at 10:30 PM.

working with the display log and timestamps on the ftplog, I saw
that just seconds after the subsystem was ended controlled, the
held program seemed to "wake up" and processed data from the ftp
site.

I have attempted to use the Sherlock Holmes technique to eliminate
every other possibility, and this seems to be the only one left.

Any ideas?



---- original post -------

Does anyone know?

Is there a chance that - - if a job is held in a subsystem (it had
been started by a jobscde) - if the subsystem is ended controlled then - the job becomes active again while the subsystem ends?



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.