Re: jobs held in a subsystem when subsystem is ended

Thanks all

You guys are great. Makes sense now.

when the subsystem ends controlled, the held job will be released and have
roughly the amount of time in the delay parameter of the endsbs command to
continue to process.

If I needed to program for it I can do a rtvjoba endsts() and go from
there.

Jim Horn

____________________________________________________


------------------------------

message: 2
date: Thu, 02 Apr 2009 15:03:36 -0500
from: CRPence <CRPbottle@xxxxxxxxx>
subject: Re: jobs held in a subsystem when subsystem is ended

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?