Date:         Fri, 12 Nov 2010 10:17:11 -0500
Reply-To:     kevin.evans@leo.gov
Sender:       CICS List <CICS-L@LISTSERV.UGA.EDU>
From:         Kevin Evans <kevin.evans@LEO.GOV>
Organization: DOJ/FBI
Subject:      Re: CICS HANDLE ABEND
In-Reply-To:  <OF2E2E4C5C.4AF3EF9A-ON852577D9.004EB092-852577D9.00515B46@metlife.com>
Content-type: multipart/alternative;

I can give you one example of "handle abend" being useful. In our
communications code, I can't afford to just abend the task. I have to be
able to take some action (highlighted console message, logging the event,
sending something back to the end-user to let them know we are having
issues) and a bunch of other things. Our applications code sitting behind us
is allowed to abend, but the "handle abend" in our communications regions
catches that and notifies our end-user.



K



From: CICS List [mailto:CICS-L@LISTSERV.UGA.EDU] On Behalf Of Ronald Weinger
Sent: Friday, November 12, 2010 9:49 AM
To: CICS-L@LISTSERV.UGA.EDU
Subject: Re: CICS HANDLE ABEND




IMHO, abends, by definition, are abnormal. If the HANDLE ABEND process
destroys the root cause evidence then it is more dangerous than the abend
itself, and I have seen many instances of  cleverly  destroyed footprints.
For processes with separate UOWs, such as WMQ app server to CICS processes,
a properly coded HANDLE would be very useful, but the code on both 'sides'
needs to be proper. Letting a real person at the beginning of the chain know
something went wrong and what to tell the help desk so it can be related
back to the failed process is very good idea. If it doesn't tell anymore
than what the 'timeout' process tells, why bother ar all? If the server
sends automated requests, unless the response could stop them, it too won't
help anything.  The most common mainframe abends are ASRAs, 0C7 and 0C4, and
AICAs.. If these are frequent, have someone fix them, clean up the data or
program a better input editor, fix the addressing, get the loop out.,
As a former end user, if I couldn't complete the 'work' I only cared about
having something useful to report to someone who could fix my problem, not
how gracefully the task ended.(Could be why I moved out of being an end
user).







From:

"Chase, John" <jchase@USSCO.COM>


To:

CICS-L@LISTSERV.UGA.EDU


Date:

11/11/2010 08:30 AM


Subject:

Re: CICS HANDLE ABEND


Sent by:

"CICS List" <CICS-L@LISTSERV.UGA.EDU>



  _____




> -----Original Message-----
> From: CICS List On Behalf Of Frank Swarbrick
>
> [ snip ]
>
> Seems to me that it would be useful to have EXEC CICS HANDLE ABEND
enhanced so there would be an
> option to the following:
> 1) Do a transaction dump for the abend
> 2) Give control to the user abend handler label/program
> 3) When the program returns to CICS, continue with abend processing;
ie DTB et al.
>
> No idea if that's feasible, but it seems to me to be ideal.  We'd get
the best(?) of both words.  A
> dump and DTB, but also the ability to terminate gracefully from the
end user's point of view.

HANDLE ABEND tells CICS to transfer control to a label or program you
specify, in case of an abend.  That label or program is, effectively, an
"exit routine" in which you can already do the things you ask (and more,
if desired).

For example:

ABEND-HANDLE-ROUTINE.
       . . .
       EXEC CICS DUMP
               TRANSACTION
               DUMPCODE(whatever)
               <other options>
       END-EXEC.
       . . .
       CALL 'CEE3DMP' USING <title, options, fc>.
       . . .
       EXEC CICS SYNCPOINT
               ROLLBACK
       END-EXEC.
       . . .
ABEND-HANDLE-ROUTINE-EXIT.
       EXIT.

Now, I "speak" just enough COBOL to embarrass myself (and others), but I
believe this code fragment does everything you specified:

1.  Produces a transaction dump (and optionally a SYSDUMP, depending on
your dump table options for the dumpcode you specify);

2.  Produces an LE dump, according to the options you specify;

3.  Instructs CICS to back-out everything in "this" LUW that has not
already been committed.


> Maybe I'm just crazy.

Naw; you just stopped reading too soon.  :-)

  -jc-




The information contained in this message may be CONFIDENTIAL and is for the
intended addressee only.  Any unauthorized use, dissemination of the
information, or copying of this message is prohibited.  If you are not the
intended addressee, please notify the sender immediately and delete this
message.

[text/html]