On 1/25/2006 2:48 PM, IBM_User wrote:
IMS has a problem with TSO users who are running PARDLI=0 as a BMP (or MPP
region). PARDLI=1 is a partial solution, but has performance implications.
When the user unconditionally logs off, MVS throws an abend622 in their
direction and IMS has the habit of taking abendu0113 to protect DL/I and
FP database integrity. (This is a minor inconvenience in development
systems (if you consider an irate bunch of developers to be minor), but a
major headache when TSO uses are allowed to run as BMPs in database editor
products like FileManager/IMS. There are, always, good reasons for
allowing editing of production data with the database online.)
IBM supply an IMS specific version of IEFUTL (DFSUTL) to trap the abend322
and abend522 when the user gets bored and walks away for a coffee or
leaves for the day or sets something trawling through a database that
looks like a loop.
Is there a TSO exit point which can trap on abend622 and prevent the user
from dying? (I'm unable to see the TSO/VTAM customization guide on the web
library and don't have a licenced CD-rom with those books.)
We can leave the user hanging until we have a chance to terminate his BMP
PST in IMS in a graceful IMS controlled way.
I'm not aware of any TSO-specific exits like that, but I don't see why
you'd need one, either. An ESTAE should be able to catch a 622 abend.
You won't be able to retry (as it's a terminating error) but you can
spend as much time in your ESTAE routine as you'd like, as far as I
know, to give IMS time to clean things up gracefully.
Walt
----------------------------------------------------------------------
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
