David Cole wrote:
MVollmer wrote:
ISTR the TCB maintains the SCB chain for ESTAE RTM environments. Is
there a progamatic way to determine if an ESTAE that I established is
still on that chain?
TCBSTAB contains a 24-bit pointer to the newest queued SCB (STAE
Control Block). Queued SCBs represent all pending recovery routines
except ARRs and FRRs. (Pending SCBs can represent ESTAEs, ESTAEXs,
ESTAIs, STAEs, STAIs, and FESTAEs. ARRs have SCBs ONLY when they are
actually active, never when they are pending. FRRs, SPIEs and ESPIEs
are never represented by SCBs.)
You can run the SCB chain chain via the SCBCHAIN field. If you are
running the chain for the current task, you can rely upon the chain
being stable.
To find out if a particular exit is still on the chain, compare its
entry address to the contents of the SCBEXIT field.
If you find such an SCB, then to find out if that exit is still "alive":
- Insure that the SCBDUMMY flag is off. (The truth is, though,
I've never seen it on. But still ...)
- Insure that the SCBINUSE flag is off.
If the SCBINUSE flag is on, then the ESTAE might be:
- Currently active.
- Percolated.
- Abended.
In all of these cases, should another abend occur, any ESTAE for which
the SCBINUSE flag is on will not again receive control until said flag
is turned off. (The SCBINUSE flag, when on, will be turned off only in
the event that the recovery routine returns to RTM with a "retry"
signal [SDWARCDE=4].)
For your purposes, you can consider the recovery routine to be out of
action if its SCBINUSE flag is on for any reason. (Note, unless your
testing code itself is within a recovery routine or within a different
task, then "currently active" will, by circumstance, never be that
reason for which you would find the flag to be on.)
If the SCBINUSE flag is on, then to determine whether it is because
the recovery routine is active, percolated or abended, you would have
to examine the current RTM2WA as well as the request blocks queue.
Will I find ALL ESTAE control blocks in the chain even after one or
more percolations have walked through that recovery chain?
A few years ago, the folks at RTM development added some code to purge
those percolated SCBs from the chain that represent recovery routi9nes
that would have no possibility of every being resumed. So the answer
to your question is "no".
I have a problem where I think someone is destroying my ESTAE
environment. Either they overlay it or they cancel it by mistake I'm
sure. But I need to prove it.
Unlike SPIE/ESPIE, estae-type recovery environments are never
overlayed, they are only superceded. When the superseding recovery
routine either percolates, abends or is removed [e.g. ESTAE 0], then
the superceded recovery routine may still receive control.
I want to thank John Kalinich for bringing this question to my attention.
David,
Thanks for your help on this. I certainly appreciate it.
In my situation, I'm running as a normal subtask. My region may or may
not be authorized. I don't think I can count on being authorized.
I'm a little confused about the OV parm. It would seem to me that
someone issuing this later in my task might overlay (alter key parms
like the exit and/or other fields) my established recovery environment
thereby possibly destroying my intended recovery mechanism. Did I read
this wrong? If yes, please bring me up to speed.
-Mark Vollmer
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
