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



Chuck,

Thanks, learn something every day on this list.

Does this mean if I did a Controlled shutdown with 60 seconds, does
it release the job as soon as the controlled shutdown is performed, or does
it release the job when the 60 seconds have expired. Therefore, if I had
held a job which was just shy of completing, and it completes in less than
the 60 seconds in the example, would it then have a zero completion code?

Pete



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, April 02, 2009 4:04 PM
To: midrange-l@xxxxxxxxxxxx
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?



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

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.