I have a CICS module and i am trying to capture the ASRA abend (occured in the cobol statement) thru the HANDLE ABEND comand but it is not going to the label defined in the handle condition.
Does this command handles the above mentioned scenario also or it only handles the CICS command abends?
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
When you define your HANDLE ABEND LABEL, to capture an ASRA (as well as many other abends), the logic will be driven to the LABEL name which you've specified. But, I'm not a big fan of this HANDLE.
Instead, just let it abend normally and review the Transaction Dump and accompanying TRACE Table.
Your Tech Support folks should be able to assist you regarding the Batch JOB, which prints the Dump. You should also familiarize yourself in Debugging, a lost art form.
By allowing the Dump to be raised without the HANDLE ABEND, you'll get a snapshot of what happened at the time of the ABEND and this is what you want.
Invoking a HANDLE ABEND and/or an ASSIGN ABCODE, always alters the internals (such as the EIB), because the EIB may provide valuable information and possibly, be a key component which caused the ASRA in the first place.
You need to recompile your program, specifying the options LIST,NOOFFSET which will generate the Assembler expansion, because you will need this for Debugging.
Joined: 13 Jun 2007 Posts: 11 Location: Sao Paulo - Brazil
You need use these commad, and some arithimetic to solve the ASRA offset:
EXEC CICS ASSIGN ABCODE (WS-DUMP-ABCODE)
ASRAINTRPT(WS-DUMP-ASRAINTRPT)
ASRAKEY (WS-DUMP-ASRAKEY)
ASRAPSW (WS-DUMP-ASRAPSW)
PROGRAM (WS-DUMP-PGRMID)
END-EXEC.
/RANT ON
I was very surprised, when I started my current work, to see that the company policy is to use HANDLE ABEND in all sub-programs.
These programs are supposed to issue a DUMP and return to the calling program with a non-zero return code.
The main program then terminates with a message like "unable to complete the transaction".
When this happens, the ABEND is not accounted in CICS (the transaction terminates normally, after all), but when I tried to explain this to my bosses, they just refused to understand!
Oh well! Less ABENDS, less pressure from above...
/RANT OFF
Joined: 16 Apr 2008 Posts: 104 Location: South Carolina
Marso wrote:
Bill O'Boyle wrote:
But, I'm not a big fan of this HANDLE.
I agree with you, Bill.
/RANT ON
I was very surprised, when I started my current work, to see that the company policy is to use HANDLE ABEND in all sub-programs.
These programs are supposed to issue a DUMP and return to the calling program with a non-zero return code.
The main program then terminates with a message like "unable to complete the transaction".
When this happens, the ABEND is not accounted in CICS (the transaction terminates normally, after all), but when I tried to explain this to my bosses, they just refused to understand!
Oh well! Less ABENDS, less pressure from above...
/RANT OFF
This is the same sort of non-sense that goes on at my shop. Our application areas are 'graded' by their abends. So of course they avoid abends like the plague. They will issue HANDLE ABENDS, and then abend with a blank return code. Apparently their upper management doesn't care if their application recieves an abend with a blank abend code. It's almost like if you can see the abend code, then an abend didn't happen...
Upper management doesn't understand that in some circumstances recieving an abend is acceptable...