Reply to all posters:
1) The question as to where I got the idea that a subsequent TCB could
be pointing to itself and not the actual Job Step TCB:
MVS Data Areas, Volume 5 (SSAG - XTLST) GA22-7585-08
In the TCB information specifically for offset:
124 (7C) ADDRESS 4 TCBJSTCB (0) - ADDRESS OF FIRST JOB STEP TCB OR OF
THIS
TCB IF KEY ZERO
2) Next, I think the general question is, is this an exit where I'm
working?
No, this is specialized message processing that can be invoked from any
TCB in our address space (the program is RENT REFR but not LPA). It is
an attempt to write to a given DD (audit trail stuff) and it searches
the TCBs to run their DEB and TIOT pointers. It also avoids certain
specific DDNames, and it will build its own DCB on the fly and do SVC99
ALLOC to make it all happen.
Meanwhile, in another life I have seen where at least one daughter TCB
had a TIOT pointer that was NOT the same as the JS TCB (rather plain in
the various dumps I was reading -- gotten via suicide (S0C3), another
via SLIP and yet another via DUMP COMM=...).
So I'm trying to make sure that when I'm done with certain upgrades to
this particular module, it isn't the cause of other, shall we say,
silliness?
And yes, our code is APF, and so it is possible for us to even get
entered in SRB mode (while possible, highly unlikely, however I'm
converting the message in that case to WTO, if needed, otherwise it just
gets dropped).
Later,
Steve Thompson
----------------------------------------------------------------------
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
