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



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?


This email is intended only for the person or entity
to which it is addressed and may contain information
that is privileged, confidential or otherwise protected
from disclosure. If you are not the named addressee
or an employee or agent responsible for delivering
this message to the named addressee, you are not
authorized to read, print, retain copy, and disseminate
this message or any part of it. If you have received this
message in error please notify us immediately by email,
discard any paper copies and delete all electronic files
of this message.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.