Any chance to capture an ASRA in a linked program?

Stefan · Posted: Fri Oct 07, 2011 2:52 pm

I've been asked by a workmate if it's possible to trap an ASRA in a called program by the main module. This seems to happen quite often in development and test enviroments because the application is generated by a client/server repository-based generator and the programs are maintained by different people and the shared views (resulting in copybooks) are not always kept in synch. The application is called from a web front-end and data is passed via MQSeries. In case of s severe error the web server gets a time-out. The tester has to watch the hour glass for 30 seconds and then gets no explaining error message.
I first changed the COBOL call to a EXEC CICS LINK NOHANDLE. But the trapped conditions are only CICS related. An ASRA in the linked program causes the whole transaction to come down.

Do I have any chance to trap those severe errors and pass some useful information back to the calling application?

dbzTHEdinosauer · Posted: Sat Oct 08, 2011 3:17 am

I know that you don't want to hear this, but:

copybooks could be changed to include a length-of-copybook field.

CALLer/LINKer sets the field to length of (copybook 01-level).
CALLed/LINKed-to compares the field to length of (copybook 01-level)

Every CALLer/LINKer has to set the length before issuing the next module invokation.

had to resort to that several years ago because had no control over
copybook changes and enforcing new compiles. First error we found was in the FEHLERMELDUNG Schnittstelle. That was fun!

then have a standard message
&*(&$# copybook from invoker does not match copybook of invokee.

good luck, sounds as if you have development management control issues.

Bill O'Boyle · Posted: Sat Oct 08, 2011 7:06 am

Stefan,

Compile the LINKED-TO program using the LIST,NOOFFSET compile options, to generate the Assembler expansion.

Go into CEMT and issue -

CEMT SET TRD(ASRA) ADD MAX(10) TRAN as well as CEMT SET TRD(AKEA) ADD MAX(10) TRAN. (The threshold of 10 is just an example).

Run the transaction under CEDF and as soon as the S0C7 occurs, go to the upper-right corner of the CEDF screen, change the 00 -01 and press <Enter>. This will be the last CICS API issued before the Data-Exception. There will bre on offset displayed on the CEDF screen, which indicates the offset into the program. However, you need to subtract the length of the CICS-Stub from this offset (X'38' I think) and you should then be pointing to the instruction. You can get to transaction-stg under CEDF via <PF5>.

Review the listing and find this last API and the next API. Your data-exception is somewhere in between.

Ask your CICS Sysprog to print out ALL Transaction Dumps for this transid. Ensure he/she points to the active Dump-Dataset. There should be a TRACE in the Transaction-Dump, which will also help.

The Assembler expansion will be a benefit in finding the offending instruction and data.

Mr. Bill

Bill Woodger · Posted: Sun Oct 09, 2011 12:26 am

Nice idea by dbz, I always like a bit of self-verification. The results of the self-verification should only ever appear in testing, but when they do appear should save developer-time, avoiding 10-30 minutes looking into something that the program can identify for you. One thing it won't get is when the copybook change does not cause an increase in size. If the old "filler-at-the-end" technique is used, the lengths will not vary. Even if not, most of the time it would catch the problem, but on occasions it might not if the result of the change leave the copybook the same length, but with changes to the layout.

However, if your application, Stefan, is "generated" this may not be simple/possible to introduce anyway. However, why, since generated, do so many problems arise with mis-matched data? Perahps to concentrate on identifying from the data available to the generator how to ensure distribution of matched data for testing environments?

Is it only the copybook changes that you'd like the trap for, or for an ordinary ASRA/S0C7?

I don't have any idea if some version of the obvious one in this could be applied in CICS.

There is a thread not far away from yours, started by mlp, where they seem to have some sort of abend-handler in CICS, so a provisional "yes" to the question of your title generally, maybe.

Stefan · Posted: Mon Oct 10, 2011 1:22 pm

Many thansk to all of you for your valuable replies.

Dick's idea is really good but I'm not in the position to enforce new coding practices.

I really appreciate Bill's instructions on how to analyze a data exception and will keep these few lines in my "tips & tricks" box.

But the real problem is, that I need a general approach to trap any kind of abend which normally terminates a CICS transaction. The goal is to stabilize the main transaction especially in test environments where these kind of errors occur very often. When CICS detects such an error, the transaction is normally kicked out the system so that the invoking web-based front-end application does not receive any error message and runs into a time-out. My vision is to trap the severe error and build up and return a meaningful response message to the front-end to have the user (or in test environments: the tester or rather the developer) informed about the cause of error.

Is there really no chance to let CICS continue the transaction after a S0C7 or similar severe error occurred in a linked program ?

dick scherrer · Posted: Mon Oct 10, 2011 10:06 pm

Hello,

I'm sure this is not the answer you are looking for, but there should never be a s0c7 in a well-written, well-tested program. If an 0c7 is caused by some invalid data, that ony means the code letting the data into the system was not properly written/tested.

Stefan · Posted: Tue Oct 11, 2011 11:48 am

OK, I give up.

Thanks again for your thoughts and ideas. I agree with your comments. But in complex client/server applications there are so much technical components involved that the list of possible causes for a time-out is nearly unmanageable.

- There is a C program running on an application server which has been called by some kind of "master" application (shell program). This component sends queries to MQSeries on another PC server.
- There is some JAVA code running on a web server interacting with your browser and a few lines of code imbedded in your local HTML code.
- There is a CICS transaction checking for an incoming request from MQSeries on the mainframe.
- There is a follow-up CICS program doing the real business logic.
- There are DB2 trigger programs.
And all of these components are interacting and communicating with each other and thus may be the cause of a time-out.

So my hope was that at least the most robust part of the chain (namely CICS) could help in improving the application. I always prefer applications which inform the user about a severe error in clear text instead of having a blue screen or some other meaningless message screen.

dick scherrer · Posted: Tue Oct 11, 2011 7:27 pm

Hello,