Are you able to share what your application cares about, in its resmgr,
with respect to the DCB?
Have you opened the DCBs in the mainline, not closed them in the mainline,
and then expected the RESMGR to close them?
Peter Relson
z/OS Core Technology Design
Thanks, Jim,
We suspected that must be the explanation, but I wanted reassurance that we
hadn't missed something.
I appreciated the other comments, too. I now understand why my searches for a
variety of keywords involving RESMGR, CLOSE, DCB, etc., showed many results,
some of which were inte
On 11/15/2018 2:27 PM, Jim Mulder wrote:
This is an intentional change in APAR OA55657.
You should see the same results on z/OS 2.1 with PTF UA97322.
With an obscure title like "OA55657: IN-SUPPORT-OF APAR FOR DFSMS
OA55365" and being unable to find APAR OA55365 in the data base, I must
> > From: "Gary Weinhold"
> > Recently we observed that when a task abends, the DCBs/ACBs are already
> > closed when we get control in the RESMGR exit. We know this was not
> > true under z/OS 2.1, but has occurred on our z/OS 2.3 system and at a
> > customer site recently.
On Thu, 15 Nov 2018
opment, Test IBM Corp.
:>Poughkeepsie NY
:>
:>"IBM Mainframe Discussion List" wrote on
:>11/15/2018 02:52:41 PM:
:>
:>> From: "Gary Weinhold"
:>> To: IBM-MAIN@LISTSERV.UA.EDU
:>> Date: 11/15/2018 05:23 PM
:>> Subject: RESMGR exit vs.
inhold"
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/15/2018 05:23 PM
> Subject: RESMGR exit vs. end of task
> Sent by: "IBM Mainframe Discussion List"
>
> Our product is called as a subroutine of the user's program (usually
> COBOL). Most of our code is use
Our product is called as a subroutine of the user's program (usually
COBOL). Most of our code is user key, but on the first call for a task
we issue a PC to set a RESMGR exit. This exit allows us to freemain our
control blocks and close any datasets we may have opened whether the
task abends
