Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Any chance to capture an ASRA in a linked program?

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS
View previous topic :: :: View next topic  
Author Message
Stefan

Active User


Joined: 12 Jan 2006
Posts: 110
Location: Germany

PostPosted: Fri Oct 07, 2011 2:52 pm    Post subject: Any chance to capture an ASRA in a linked program?
Reply with quote

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?
Back to top
View user's profile Send private message

dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6967
Location: porcelain throne

PostPosted: Sat Oct 08, 2011 3:17 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Sat Oct 08, 2011 7:06 am    Post subject: Reply to: Any chance to capture an ASRA in a linked program?
Reply with quote

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
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7315

PostPosted: Sun Oct 09, 2011 12:26 am    Post subject: Reply to: Any chance to capture an ASRA in a linked program?
Reply with quote

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.
Back to top
View user's profile Send private message
Stefan

Active User


Joined: 12 Jan 2006
Posts: 110
Location: Germany

PostPosted: Mon Oct 10, 2011 1:22 pm    Post subject:
Reply with quote

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. icon_cry.gif

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 ?
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Mon Oct 10, 2011 10:06 pm    Post subject:
Reply with quote

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.

Quote:
Is there really no chance to let CICS continue the transaction after a S0C7 or similar severe error occurred in a linked program ?
Given enough time and the necessary skill, pretty much anything can be done. I suspect the cost of doing this would make it quite unattractive to those who pay the bills. . .

Suggest some research be done into the reason(s) there are enough production abends to justify creating something like this.
Back to top
View user's profile Send private message
Stefan

Active User


Joined: 12 Jan 2006
Posts: 110
Location: Germany

PostPosted: Tue Oct 11, 2011 11:48 am    Post subject: Reply to: Any chance to capture an ASRA in a linked program?
Reply with quote

OK, I give up. icon_cry.gif

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.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Tue Oct 11, 2011 7:27 pm    Post subject:
Reply with quote

Hello,

Quote:
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.


Initially, an ASRA was mentioned. Now, the concern seems to be a time-out. Suggest each of these be treated as different "things" to resolve. Regardless of complexity, there should not be asra/0c7s in Production (or at least very rarely). The time-out issue(s) need to be addressed individually. It sounds like the network may be choking on this new load. . .

Quote:
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.
The most stable part of this application should be CICS. It has been carrying major loads for a very long time. . .

Hopefully, you are not the one who has to resolve all of the CICS coding problems as well as the client/network issues. These integrated environments are usually best served by a group effort (at least in my experience).

Good luck icon_smile.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts IMS T-Pipe queue counts in a COBOL Pr... Siva NKK Kothamasu IMS DB/DC 0 Tue May 09, 2017 6:31 pm
No new posts Need help in REXX CALL program Raje1002 CLIST & REXX 5 Wed Apr 19, 2017 11:18 pm
No new posts SQL query not working in Cobol program. CuriousMainframer COBOL Programming 14 Wed Feb 22, 2017 5:56 pm
No new posts How to Capture the Max return code of... anilkumar922 All Other Mainframe Topics 2 Thu Jan 12, 2017 12:02 pm
No new posts Executing OO COBOL program invoking J... Virendra Shambharkar COBOL Programming 2 Tue Jan 10, 2017 6:37 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us