Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
z/OS REXX Batch interface to cleanly interrupt an intentional DO FOREVER loop
52 views
Skip to first unread message
gary.j...@salliemae.com
Mar 18, 2013, 12:00:19 PM3/18/13
to
We are running a z/OS Batch REXX which updates a row in a DB2 table every 60 seconds within a FOREVER LOOP.
This process was created to trigger a Change data capture mechanism as a sort of 'heart-beat' process.
The current REXX logic gets passed parameters to determine (among other things) the amount of time to "SLEEP" between iterations of the SQL UPDATE statement.
There are times that we want to terminate this process without causing an ABEND. Since this REXX runs as either a started-task or batch job, an operating system Cancel, causes it to abend with a S222. Our Auto Operations monitoring tool sees this abend and triggers a page-out.
We want to have the REXX Logic determine if we terminate it and then end gracefully.
I don't believe that a WTOR routine would work here, because a call to that routine would wait for an operator response and then not do its 'heart-beat' update FOREVER.
I've tried to use SIGNAL ERROR, FAILURE and HALT, but when I issue the cancel command, the REXX doesn't seem to intercept it and the job abends S222.
Suggestions are very welcome.
Thanks,
Gary J
This process was created to trigger a Change data capture mechanism as a sort of 'heart-beat' process.
The current REXX logic gets passed parameters to determine (among other things) the amount of time to "SLEEP" between iterations of the SQL UPDATE statement.
There are times that we want to terminate this process without causing an ABEND. Since this REXX runs as either a started-task or batch job, an operating system Cancel, causes it to abend with a S222. Our Auto Operations monitoring tool sees this abend and triggers a page-out.
We want to have the REXX Logic determine if we terminate it and then end gracefully.
I don't believe that a WTOR routine would work here, because a call to that routine would wait for an operator response and then not do its 'heart-beat' update FOREVER.
I've tried to use SIGNAL ERROR, FAILURE and HALT, but when I issue the cancel command, the REXX doesn't seem to intercept it and the job abends S222.
Suggestions are very welcome.
Thanks,
Gary J
Barry Schwarz
Mar 18, 2013, 2:17:27 PM3/18/13
to
On Mon, 18 Mar 2013 09:00:19 -0700 (PDT), gary.j...@salliemae.com
wrote:
You need something to change that the REXX can test for and then
terminate normally when the change occurs. A couple of possibilities:
There is an area in the CVT reserved for the user (the site). If you
are not using it for anything else, the REXX could set it to zero and
run normally as long as it is zero. When you need to stop the REXX,
start a task which changes the value in the CVT.
The REXX can allocate a dataset, free the DD name, and run normally as
long as the dataset exists. When you need to stop the REXX, delete
the dataset.
A WTOR can work. You don't need to wait for the response. At the end
of each sleep period, the REXX can test if the ECB for the WTOR has
been posted (and even evaluate the response).
--
Remove del for email
wrote:
terminate normally when the change occurs. A couple of possibilities:
There is an area in the CVT reserved for the user (the site). If you
are not using it for anything else, the REXX could set it to zero and
run normally as long as it is zero. When you need to stop the REXX,
start a task which changes the value in the CVT.
The REXX can allocate a dataset, free the DD name, and run normally as
long as the dataset exists. When you need to stop the REXX, delete
the dataset.
A WTOR can work. You don't need to wait for the response. At the end
of each sleep period, the REXX can test if the ECB for the WTOR has
been posted (and even evaluate the response).
--
Remove del for email
0 new messages