On Tue, 9 Apr 2019 07:52:08 -0500 Steve Partlow <[email protected]> wrote:
:>I'll correct myself again:
:>SHAREMEMOBJ is cleaned up when the job step task (ASCBXTCB) terminates. I had
misunderstood a previous test. I've confirmed that if a subtask issues the
SHAREMEMOBJ and terminates, the address space still has access. We also tested
that when the job step ends, it is no longer accessible. Is that what you are
seeing? I don't see any evidence that this has changed since it was first
introduced.
Yes, that is how I expected it to work.
I am seeing a failure at job end, but looking at LOGREC I see the problem
occurred earlier (a silent SRB abend attempting an access).
Given that the SAHREMEMOBJ is issued in supervisor state with
IARV64 REQUEST=SHAREMEMOBJ,
USERTKN=RANGLIST,
RANGLIST=@RANGLIST,
ALETVALUE=2,
COND=YES,
MF=(E,OIARV64,COMPLETE)
If the application calls the service to DETACH it, the call is recorded.
How can something else DETACH this object without knowing the token?
Is there a standard way to trap this? The problem cannot be reproduced at
will. Seems to only occur under TSO.
--
Binyamin Dissen <[email protected]>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
