Chuck,
My original issue is within an AJS job, no way of waiting for the END* or STR* to complete before going to the next sequence.
I agree, DLYJOB is only a quick Band-Aid fix, and not the correct one.
Here is response back from IBM.
Work Management at this point has no list or documentation available that would show what commands return control to the user before the command completes. He explains that the commands for the different components of the OS and for the IBM Product options or for products like AJS are developed by completely different teams and that no requirement has been made to them to create a list of the commands that return control to the user before the command completes.
He further explains that he does not foresee a change to this policy in future releases.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, June 16, 2015 1:59 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Identifing IBM commands that return control before process completes
On 16-Jun-2015 07:19 -0600, Steinmetz, Paul wrote:
Is there a doc or link that would Identify all IBM commands that
return control before process complete? Examples, STRSBS, ENDSBS.
I am finding that if ever coding these commands, a DLYJOB is necessary
if the following command is dependent on the process being completed.
I am unaware of any list for the OS or LPPs.
Coding just a Delay Job (DLYJOB) is... well, daft. Code a procedure
that will wait for the asynchronous effect if waiting is necessary, or
if not possible to wait, then polling to test for the effect using a
short-wait delay-loop. For example, for End Subsystem (ENDSBS) [except
the controlling SBS], the successful completion of an Allocate Object
(ALCOBJ) request against the *SBSD object indicates the
async-End-Request has completed, after which processing would continue
after the Deallocate Object (DLCOBJ) request against that Subsystem
Description (SBSD).
I often wonder if anyone ever submits requests for the ability to
effect a sync-wait on such operations. I am shocked at how often in
discussions people so easily accept hard-coding delays as a /solution/
to an issue with consecutive requests failing, esp. those following
Start TCP/IP services (STRTCPxxx) requests. I would expect a huge
number of "we need something like SYNC() parm to ask the command to wait
until all that was requested to start has actually started."
midrange.com
