Re: SOC1 and SYSUDUMP and CEEDUMP
Only ca. 150 pages on paper (excerpts from CEEDUMP and SYSUDUMP, and compile listings, of course), so that the students can write notes on it, the rest of the dumps is in the machine, in PDF format (landscape shape). The students read them on the screen, works pretty well, or they go to SYSVIEW directly, or SDSF, which is what is done in reality. When I prepare a class for a certain customer (all sites are different), I go to the site and run certain test programs there, look at the dumps created and prepare the class for that customer. BTW: regardless of the language used. and: I'm a member of the Green party in Germany ... Kind regards Bernd Am 26.11.2014 03:54, schrieb Shane Ginnane: On Wed, 26 Nov 2014 01:33:00 +0100, Bernd Oppolzer wrote: I do classes on dump diagnose, BTW, Many years ago I did a dump class - as an adjunct to the MVS Internals class Amdahl used to offer. Hand-outs for the class included multiple fanfold listings - each several inches thick. which we had to get home in addition to the voluminous class notes. To save on freight I got the local office to ship them interstate for me. Hopefully Bernd is more ecologically sensitive ;-) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
of course we did the same thing (tons of paper) some 25 years ago. Am 27.11.2014 10:43, schrieb Bernd Oppolzer: Only ca. 150 pages on paper (excerpts from CEEDUMP and SYSUDUMP, and compile listings, of course), so that the students can write notes on it, the rest of the dumps is in the machine, in PDF format (landscape shape). The students read them on the screen, works pretty well, or they go to SYSVIEW directly, or SDSF, which is what is done in reality. When I prepare a class for a certain customer (all sites are different), I go to the site and run certain test programs there, look at the dumps created and prepare the class for that customer. BTW: regardless of the language used. and: I'm a member of the Green party in Germany ... Kind regards Bernd Am 26.11.2014 03:54, schrieb Shane Ginnane: On Wed, 26 Nov 2014 01:33:00 +0100, Bernd Oppolzer wrote: I do classes on dump diagnose, BTW, Many years ago I did a dump class - as an adjunct to the MVS Internals class Amdahl used to offer. Hand-outs for the class included multiple fanfold listings - each several inches thick. which we had to get home in addition to the voluminous class notes. To save on freight I got the local office to ship them interstate for me. Hopefully Bernd is more ecologically sensitive ;-) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Paper (was Re: SOC1 and SYSUDUMP and CEEDUMP)
Bernd Oppolzer wrote: of course we did the same thing (tons of paper) some 25 years ago. Years ago I and my (mostly ex) colleagues sifted through dump lists, syslog, job printouts, timesheets, RACF logs (RACFRW - four lines PER event!), schedules of jobs, etc. We have lots of trolleys, racks, vaults, printers, etc. just for paper handling... I was also responsible to manually keep a room full of IBM books in tidy order. Plus extra papers to say where in what folder is a book. Boring work with 'nothing to read'... ;-) Later I ordered a team member to collect printouts, work through it and mark 'interesting' things with a pen or just tear+fold out a corner so I can locate a page in a stack easily. Later, IPCS and other dump tools came - fewer paper. Whew! Later when due to costs and storage of paper became serious issues, we discarded all printing partially, later fully. Only those lines were printed and kept for a few months. Now our storage team is fluent in ISMF and other tools, their need to print out VTOCs, TAPEMAP, LISTC etc. disappeared. All documentations are now in text, PDF and m$word format including IPL procedures, meeting notules, etc. too. All those books and printouts were sent away for recycling eventually. Even our (groaning) auditors had to bite the bullet and accept now electronic evidences. Even Hot-Topics and Cheryl Watson publications are available electronically. Cool. Now, paper is only useful for one thing - wipe clean a delicate body part privately... ;-) Oh, wait, paper is also useful for another thing - lighting a fire so we can have a braai (barbeque)! :-D and: I'm a member of the Green party in Germany ... Color me in, I'm green of envy... ;-) Mind you, the recycling fad is now finally catching on here in Sunny South Africa... Last year, I traded in my film Canon camera for a digital Canon camera. That only because the last developing at a shop was a sort of flop due to stupid shop employees and I'm too lazy to have a dark room. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
LE runtime is TERMTHDACT(UADUMP,,96) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
It is still an option in COBOL 5.1.1. The default is NOSSRANGE. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, November 24, 2014 4:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SOC1 and SYSUDUMP and CEEDUMP There is - it is named SSRANGE for the Enterprise COBOL compilers, at least up through 4.2. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
Peter Ten Eyck wrote: LE runtime is TERMTHDACT(UADUMP,,96) Ok. I will bite. I see in LE book, this: Under non-CICS, if the appropriate DD statement is used, you will get a system dump of your user address space. A$$suming you're not running CICS, did you used that DD statement? (Even after some RTFM, I think it is CEEDUMP, yes, I know you wrote you used CEEDUMP, but now I'm wondering?) Are you sure it is the ONLY Abend? You're not getting something like U40?? abend? Alternatively, can you try rerunning your COBOL program with same or other input and see at what line of that input does that abend occur? Time for a PMR? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
Thanks. That is the normal way for a majority of LE abend handling. Without more specific information, I would probably open up an SR with LE support and request assistance. It is possible that your Cobol program is over writing LE and/or Cobol Storage. It is possible there is a PTF that might correct your issue. You would need to see what module the CEEDUMP is indicating is the issue. When you get an SYSUDUMP you would need to use IPCS and VERBX LEDATA to get to the regs to see what is going on. Usually LE will dynamically allocate the CEEDUMP so you should not need to allocate one. The CEEDUMP run-time option is used to specify options to control the processing of the Language Environment dump report. Non-CICS default: CEEDUMP(60,SYSOUT=*,FREE=END,SPIN=UNALLOC) Check out: z/OS Language Environment Programming Reference The DYNDUMP run-time option provides a way to obtain dynamic dumps of user applications that would ordinarily be lost due to the absence of a SYSMDUMP, SYSUDUMP, or SYSABEND DD statement. Also these share presentations may be helpful http://www-03.ibm.com/systems/z/os/zos/features/lang_environment/conference/share.html Lizette I have a COBOL program that is getting a SOC1 and produces a dump when the SYSUDUMP DD is code in the failing step. If CEEDUMP is coded instead of SYSUDUMP no dump is produced. This program is complied with the same COBOL parameters and run in the same LE environment as other COBOL programs which do produce a dump when using the CEEDUMP DD. Is there something about SOC1 abends that would cause the issues with CEEDUMP? What am I missing here? Note: z/OS 1.13 IBM ENTERPRISE COBOL FOR Z/OS 4.2.0 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Ten Eyck Sent: Tuesday, November 25, 2014 6:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SOC1 and SYSUDUMP and CEEDUMP LE runtime is TERMTHDACT(UADUMP,,96) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
Lizette Koehler wrote: Also these share presentations may be helpful http://www-03.ibm.com/systems/z/os/zos/features/lang_environment/conference/share.html Ah, yes. I remember now. Thanks Lizette! Peter Ten Eyck, are you using a SLIP? According to that presentation, you should not use a SLIP on S0Cx abends. Please review your SLIP settings. Also I see there: 'LE environment has already been cleaned-up and therefore a dump at this point is useless.' Hmmm, very interesting. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht Sent: Tuesday, November 25, 2014 8:14 AM Peter Ten Eyck wrote: LE runtime is TERMTHDACT(UADUMP,,96) Ok. I will bite. I see in LE book, this: Under non-CICS, if the appropriate DD statement is used, you will get a system dump of your user address space. A$$suming you're not running CICS, did you used that DD statement? (Even after some RTFM, I think it is CEEDUMP, yes, I know you wrote you used CEEDUMP, but now I'm wondering?) I believe, but am not inclined to look it up at this moment, it is //SYSUDUMP or //SYSMDUMP, depending on whether you want a formatted dump or one you can examine with IPCS. -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht Sent: Tuesday, November 25, 2014 8:42 AM Lizette Koehler wrote: Also these share presentations may be helpful http://www-03.ibm.com/systems/z/os/zos/features/lang_environment/confer ence/share.html Ah, yes. I remember now. Thanks Lizette! Peter Ten Eyck, are you using a SLIP? According to that presentation, you should not use a SLIP on S0Cx abends. Please review your SLIP settings. Also I see there: 'LE environment has already been cleaned-up and therefore a dump at this point is useless.' Hmmm, very interesting. Indeed. We're currently working a PMR in which, to get an SVCDUMP of a S0C4 before LE's condition handlers got hold of it, we coded an LE override 'TRAP(OFF,NOSPIE)' in the PROC and set a SLIP trap for the 31 jobs (we used the default MATCHLIM=1 because we needed only one dump). We also had to disable Fault Analyzer's dump intercept with //IDIOFF DD DUMMY in the PROC. We also concurrently had a SLIP SA trap recording a GTF trace on the same 31 jobs. IBM Support now has all that doc; hopefully it will reveal the culprit. -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
On 11/25/2014 8:19 AM, Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht Sent: Tuesday, November 25, 2014 8:42 AM Lizette Koehler wrote: Also these share presentations may be helpful http://www-03.ibm.com/systems/z/os/zos/features/lang_environment/confer ence/share.html Ah, yes. I remember now. Thanks Lizette! Peter Ten Eyck, are you using a SLIP? According to that presentation, you should not use a SLIP on S0Cx abends. Please review your SLIP settings. Also I see there: 'LE environment has already been cleaned-up and therefore a dump at this point is useless.' Hmmm, very interesting. Indeed. We're currently working a PMR in which, to get an SVCDUMP of a S0C4 before LE's condition handlers got hold of it, we coded an LE override 'TRAP(OFF,NOSPIE)' in the PROC and set a SLIP trap for the 31 jobs (we used the default MATCHLIM=1 because we needed only one dump). We also had to disable Fault Analyzer's dump intercept with //IDIOFF DD DUMMY in the PROC. We also concurrently had a SLIP SA trap recording a GTF trace on the same 31 jobs. IBM Support now has all that doc; hopefully it will reveal the culprit. -jc- If you want to see the environment before clean up, look at these LE runtime options for TERMTHDACT: UADUMP, UAONLY, UATRACE, UAIMM. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
On Tue, 25 Nov 2014 07:27:23 -0700 Lizette Koehler stars...@mindspring.com wrote: :You would need to see what module the CEEDUMP is indicating is the issue. When you get an SYSUDUMP you would need to use IPCS and VERBX LEDATA to get to the regs to see what is going on. A nit. IPCS runs against SYSMDUMP. SYSUDUMP is a report file. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Comstock Sent: Tuesday, November 25, 2014 9:46 AM On 11/25/2014 8:19 AM, Chase, John wrote: [ snip ] Indeed. We're currently working a PMR in which, to get an SVCDUMP of a S0C4 before LE's condition handlers got hold of it, we coded an LE override 'TRAP(OFF,NOSPIE)' in the PROC and set a SLIP trap for the 31 jobs (we used the default MATCHLIM=1 because we needed only one dump). We also had to disable Fault Analyzer's dump intercept with //IDIOFF DD DUMMY in the PROC. We also concurrently had a SLIP SA trap recording a GTF trace on the same 31 jobs. IBM Support now has all that doc; hopefully it will reveal the culprit. -jc- If you want to see the environment before clean up, look at these LE runtime options for TERMTHDACT: UADUMP, UAONLY, UATRACE, UAIMM. Tried UAIMM; it dumped too late for the problem we're having. Thus the 'TRAP(OFF,NOSPIE)' and a SLIP trap. -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
Thanks for the good feedback. I had the programmer use the SYSUDUMP DD for this program... which did produce a SOC1 dump. This dump was sent to Abend-Aid and the programmer was able to make a correction to the code and get the program running cleanly. I still do not know what it is about that program that would not produce a CEEDUMP. As mentioned in my previous post, the identical compile and LE runtime will produce a CEEDUMP for other failing programs. I wrote a simple COBOL program (divide by zero… S0CB) to prove this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
As I told already in my previous post on this topic: there are certains types of errors, especially when code area is overwritten (S0C1 can be a symptom for that kind of error), when LE error handler is not able to cope with program errors (maybe LE control blocks are damaged too). If you are lucky, you get a message like backward chain destroyed etc., but when you're in a real mess, you will be thrown back to SYSUDUMP. IMO it is still necessary for every developer to be able to read SYSUDUMPs or to have a person nearby that is able to assist. I do classes on dump diagnose, BTW, and not every developer needs to know all about this, but he or she should have a fellow worker around who is able to help, just in case. adIf someone in Germany or Middle Europe needs such classes, please feel free to contact me offline./ad Thank you, kind regards Bernd Am 25.11.2014 20:56, schrieb Peter Ten Eyck: Thanks for the good feedback. I had the programmer use the SYSUDUMP DD for this program... which did produce a SOC1 dump. This dump was sent to Abend-Aid and the programmer was able to make a correction to the code and get the program running cleanly. I still do not know what it is about that program that would not produce a CEEDUMP. As mentioned in my previous post, the identical compile and LE runtime will produce a CEEDUMP for other failing programs. I wrote a simple COBOL program (divide by zero… S0CB) to prove this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
On Wed, 26 Nov 2014 01:33:00 +0100, Bernd Oppolzer wrote: I do classes on dump diagnose, BTW, Many years ago I did a dump class - as an adjunct to the MVS Internals class Amdahl used to offer. Hand-outs for the class included multiple fanfold listings - each several inches thick. which we had to get home in addition to the voluminous class notes. To save on freight I got the local office to ship them interstate for me. Hopefully Bernd is more ecologically sensitive ;-) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SOC1 and SYSUDUMP and CEEDUMP
I have a COBOL program that is getting a SOC1 and produces a dump when the SYSUDUMP DD is code in the failing step. If CEEDUMP is coded instead of SYSUDUMP no dump is produced. This program is complied with the same COBOL parameters and run in the same LE environment as other COBOL programs which do produce a dump when using the CEEDUMP DD. Is there something about SOC1 abends that would cause the issues with CEEDUMP? What am I missing here? Note: z/OS 1.13 IBM ENTERPRISE COBOL FOR Z/OS 4.2.0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
Dump information is only written to CEEDUMP following an S0C1 abend, if the S0C1 was handled by LE. This should be the normal case in a LE environment. But in this case, if you don't get CEEDUMP information written following the S0C1, I guess that THIS S0C1 is not handled by LE, but it is a normal S0C1 handled by the system, so the normal action is: output to SYSUDUMP, if SYSUDUMP is present in the Job Step, and no output, if not. The opsys does not output anything to CEEDUMP. The reason why the S0C1 is not handled by LE could be: NOSPIE,NOSTAE option in effect, via LE parm or via CEEOPTS (don't know, there are several possibilities to do this) ... this is called TRAP(OFF) nowadays, I guess ... the S0C1 occurs, BEFORE the LE error handler has been established other reasons ... ??? HTH kind regards Bernd Am 24.11.2014 22:38, schrieb Peter Ten Eyck: I have a COBOL program that is getting a SOC1 and produces a dump when the SYSUDUMP DD is code in the failing step. If CEEDUMP is coded instead of SYSUDUMP no dump is produced. This program is complied with the same COBOL parameters and run in the same LE environment as other COBOL programs which do produce a dump when using the CEEDUMP DD. Is there something about SOC1 abends that would cause the issues with CEEDUMP? What am I missing here? Note: z/OS 1.13 IBM ENTERPRISE COBOL FOR Z/OS 4.2.0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
One more idea: I once had a strange S0C1 abend because due to an index range error large parts of the program code were overwritten, and even the LE error handler was unable to diagnose the error correctly, although under normal circumstances it should be able to do so. This was PL/1, not COBOL. What helped me out of this mess: I added some condition prefixes to the critical PL/1 procedures, like (SUBSCRIPTRANGE): which tells the PL/1 compiler to check the array indices for the correct ranges; this way I got a SUBSCRIPTRANGE condition at runtime which showed the error before the code area was overwritten. I don't know if there are similar features in COBOL. Kind regards Bernd Am 24.11.2014 23:00, schrieb Bernd Oppolzer: Dump information is only written to CEEDUMP following an S0C1 abend, if the S0C1 was handled by LE. This should be the normal case in a LE environment. But in this case, if you don't get CEEDUMP information written following the S0C1, I guess that THIS S0C1 is not handled by LE, but it is a normal S0C1 handled by the system, so the normal action is: output to SYSUDUMP, if SYSUDUMP is present in the Job Step, and no output, if not. The opsys does not output anything to CEEDUMP. The reason why the S0C1 is not handled by LE could be: NOSPIE,NOSTAE option in effect, via LE parm or via CEEOPTS (don't know, there are several possibilities to do this) ... this is called TRAP(OFF) nowadays, I guess ... the S0C1 occurs, BEFORE the LE error handler has been established other reasons ... ??? HTH kind regards Bernd Am 24.11.2014 22:38, schrieb Peter Ten Eyck: I have a COBOL program that is getting a SOC1 and produces a dump when the SYSUDUMP DD is code in the failing step. If CEEDUMP is coded instead of SYSUDUMP no dump is produced. This program is complied with the same COBOL parameters and run in the same LE environment as other COBOL programs which do produce a dump when using the CEEDUMP DD. Is there something about SOC1 abends that would cause the issues with CEEDUMP? What am I missing here? Note: z/OS 1.13 IBM ENTERPRISE COBOL FOR Z/OS 4.2.0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
How is your termthdact coded for the le environment? Lizette -Original Message- From: Peter Ten Eyck peter_tene...@farmfamily.com Sent: Nov 24, 2014 2:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SOC1 and SYSUDUMP and CEEDUMP I have a COBOL program that is getting a SOC1 and produces a dump when the SYSUDUMP DD is code in the failing step. If CEEDUMP is coded instead of SYSUDUMP no dump is produced. This program is complied with the same COBOL parameters and run in the same LE environment as other COBOL programs which do produce a dump when using the CEEDUMP DD. Is there something about SOC1 abends that would cause the issues with CEEDUMP? What am I missing here? Note: z/OS 1.13 IBM ENTERPRISE COBOL FOR Z/OS 4.2.0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOC1 and SYSUDUMP and CEEDUMP
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Monday, November 24, 2014 5:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SOC1 and SYSUDUMP and CEEDUMP One more idea: I once had a strange S0C1 abend because due to an index range error large parts of the program code were overwritten, and even the LE error handler was unable to diagnose the error correctly, although under normal circumstances it should be able to do so. This was PL/1, not COBOL. What helped me out of this mess: I added some condition prefixes to the critical PL/1 procedures, like (SUBSCRIPTRANGE): which tells the PL/1 compiler to check the array indices for the correct ranges; this way I got a SUBSCRIPTRANGE condition at runtime which showed the error before the code area was overwritten. I don't know if there are similar features in COBOL. There is - it is named SSRANGE for the Enterprise COBOL compilers, at least up through 4.2. HTH Peter Kind regards Bernd Am 24.11.2014 23:00, schrieb Bernd Oppolzer: Dump information is only written to CEEDUMP following an S0C1 abend, if the S0C1 was handled by LE. This should be the normal case in a LE environment. But in this case, if you don't get CEEDUMP information written following the S0C1, I guess that THIS S0C1 is not handled by LE, but it is a normal S0C1 handled by the system, so the normal action is: output to SYSUDUMP, if SYSUDUMP is present in the Job Step, and no output, if not. The opsys does not output anything to CEEDUMP. The reason why the S0C1 is not handled by LE could be: NOSPIE,NOSTAE option in effect, via LE parm or via CEEOPTS (don't know, there are several possibilities to do this) ... this is called TRAP(OFF) nowadays, I guess ... the S0C1 occurs, BEFORE the LE error handler has been established other reasons ... ??? HTH kind regards Bernd Am 24.11.2014 22:38, schrieb Peter Ten Eyck: I have a COBOL program that is getting a SOC1 and produces a dump when the SYSUDUMP DD is code in the failing step. If CEEDUMP is coded instead of SYSUDUMP no dump is produced. This program is complied with the same COBOL parameters and run in the same LE environment as other COBOL programs which do produce a dump when using the CEEDUMP DD. Is there something about SOC1 abends that would cause the issues with CEEDUMP? What am I missing here? Note: z/OS 1.13 IBM ENTERPRISE COBOL FOR Z/OS 4.2.0 -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
