Perhaps some pseudo-abends in IMS do not result in TCB termination and
re-attach.  The IMS dependent region has a multi-level TCB structure
(originally to handle application programs issuing the EXIT SVC, such as
Cobol STOP RUN, as well as abnormal conditions).  The primary purpose of a
pseudo-abend (as opposed to a real abend issued by IMS) was to gather
diagnostic info (e.g. 67FF log records) and continue normal application
execution (including requeue of the affected transaction for many cases).
Ending the TCB and re-attach occurs when cleanup is needed.  This is often,
but I don't know if it is for every pseudo-abend condition and could even
vary by region type and environment.  Your best bet is a GTF trace to see
what conditions your testcase is encountering.  There are a lot of possible
permutations and support for Java etc. has complicated the
environment considerably.

On Tue, Jan 19, 2021 at 7:52 AM Gary Weinhold <weinh...@dkl.com> wrote:

> Excuse me for asking this question here, but I can't find an IMS DC list.
>
> We rely on getting control at task termination to clean up resources
> used by our software.  We create a PC to add an MVS RESMGR exit when our
> software is first accessed in an IMS MPR.  If there is a pseudo-abend,
> which we understand means the TCB on which transactions run will
> terminate, we expect our RESMGR exit to execute.  The IMS MPR control
> program will then attach a new TCB in the region on which to run
> transactions.  Our software will be reinitialized if a transaction
> accesses it.  This could happen many times.  However, if our RESMGR exit
> doesn't execute, we may deplete resources.
>
> Is it possible that the IMS MPR control program bypasses or deletes our
> RESMGR exit on some pseudo-abends?
>
>
>
> Gary Weinhold
> Senior Application Architect
> DATAKINETICS | Data Performance & Optimization
> Phone:+1.613.523.5500 x216
> Email: weinh...@dkl.com
> Visit us online at www.DKL.com
> E-mail Notification: The information contained in this email and any
> attachments is confidential and may be subject to copyright or other
> intellectual property protection. If you are not the intended recipient,
> you are not authorized to use or disclose this information, and we request
> that you notify us by reply mail or telephone and delete the original
> message from your mail system.
>
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to