The company that I work for uses the OS/390 operating system. However we still have programs from the early 70's that are still coded in OS/VS Cobol (68). I have systems with assembler drivers & cobol 68 called modules that use the SPIE and SNAP macros to control & recover from abends, both program & system issued. I have the OPERTUNITY of researching the changes needed to bring these programs up to 370 & then to OS/390. I have converted some stand alone cobol 68 programs to 370. I would appreciate any help in how to upgrade/change from the SPIE/SNAP macros to the equivalent 370 comands. I have been testing with the CEE3DMP subroutine & have a question about it's operation that I can not find in the IBM manuals. After you issue the call and the subroutine returns to the program that issued it, just where does it return control too? In other words how does it decide what code to execute next?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
LE/370 - Need help with CEE3DMP
- Thread starter cgentry
- Start date
Hi C,
Answering your 2nd ques 1st: It should be the NSI following the call. Where are you issuing the call from? Is it being called from a DECLARATIVE?
1st ques: The only declarative processing for errors available with 370COBOL is for I/O errors. COBOLII had a USE FOR DEBUGGING feature that was dropped in 370COBOL.
Hope this helps, Jack.
Answering your 2nd ques 1st: It should be the NSI following the call. Where are you issuing the call from? Is it being called from a DECLARATIVE?
1st ques: The only declarative processing for errors available with 370COBOL is for I/O errors. COBOLII had a USE FOR DEBUGGING feature that was dropped in 370COBOL.
Hope this helps, Jack.
- Thread starter
- #3
slade
thanks for your reply. Let me be more spcefic. Theses programs run about 400 times a weeek with files from 200,000 - 2,000,000. When a logical problem is found on a record we intentionaly cause the program to abend (snap) so that the SPIE macro in the assembler program can take a controled dump, reload the offending program and continue. This allows us to then look at the problem record later without bring down a production run. The SPIE macro does the same thing for OC7, OC4's etc. Since 370 does not support the SPIE macro I am trying to find a way to duplicate it's function. The CEE3DMP appears to do part of what I need when an intentional abend/dump is needed.
thanks for your reply. Let me be more spcefic. Theses programs run about 400 times a weeek with files from 200,000 - 2,000,000. When a logical problem is found on a record we intentionaly cause the program to abend (snap) so that the SPIE macro in the assembler program can take a controled dump, reload the offending program and continue. This allows us to then look at the problem record later without bring down a production run. The SPIE macro does the same thing for OC7, OC4's etc. Since 370 does not support the SPIE macro I am trying to find a way to duplicate it's function. The CEE3DMP appears to do part of what I need when an intentional abend/dump is needed.
Hi C,
IBM's latest assembler uses an ESPIE and an ESTEA macro. Referenced in GC28-1642-05 Section 63.0.
I'm still not sure of the interaction of the COBOL and Assembler programs. If you could cut & paste the relevant code, it would be helpful. Tip - when you c&p, do this:
type:
This preserves the alignment & spacing of the orig code.
Jack.
IBM's latest assembler uses an ESPIE and an ESTEA macro. Referenced in GC28-1642-05 Section 63.0.
I'm still not sure of the interaction of the COBOL and Assembler programs. If you could cut & paste the relevant code, it would be helpful. Tip - when you c&p, do this:
type:
Code:
c&p lines go here
type:This preserves the alignment & spacing of the orig code.
Jack.
- Thread starter
- #5
Agian I thank you for your help. I agree that the ESTAE & ESPIE are still valid macros. However according to the IBM OS/390 migration guide: Existing user-written condition handling routines do not work under Language Environment (pages 212-213). These can be replaced by a using "CEEHDLR". I am looking for some guidance in how to use it and any other changes that I need in order to get it to work properly. I would have copied the assembler code code but the error handling routine that we wrote is eight pages long. In a nut shell it interpets the return code from the cobol program and determines if a fatal error has occured or if a controled dump should be taken and a fresh version of the offending program reloaded in order to continue processing. Agian thanks & I hope this better explains what I need.
Hi C,
You might want to try - the guys there are very good. In the meantime I'll keep working on it for you.
Jack.
You might want to try - the guys there are very good. In the meantime I'll keep working on it for you.
Jack.
Hi CG,
My recollection is that CEE3DMP just causes a dump and returns to the calling program. I'm not sure what manuals you have but have you seen this one?
Hope this helps in some small way.
Marc
My recollection is that CEE3DMP just causes a dump and returns to the calling program. I'm not sure what manuals you have but have you seen this one?
Hope this helps in some small way.
Marc
- Thread starter
- #10
When a called program (cobol 68) abends for any reason the driver program (assembler) takes control, interprets the abend, and reloads a fresh version of the offending program. Control stays within the driver program which then reads the next transaction/record to be processed. This allows us to continue processing without production coming down unless the error captured by the spie macro is determined to be a fatal error in which case the driver program abends and stops the run of the job.
- Status
Similar threads
- Locked
- Helpful tip
- Locked
- Question