The most common problem in a recovery routine is failure to restore registers properly. The older the code, the more likely you are to hit such a glitch. I once debugged a bizarre COBOL program error that was completely inexplicable. I set a SLIP trap for the 'first' error, which turned out to be a run of the mill S0C7 data problem. The program had an ancient assembler recovery routine that messed up the registers and took a wild branch into PLPA. My solution was to BR14 out the recovery routine rather than try to fix it.
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Beaver Sent: Wednesday, February 01, 2017 3:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: COBOL/LE question i am guess the c/vs was nores nodynam and the asm90 is your real trouble maker Sent from my iPhone Steve Beaver > On Feb 1, 2017, at 16:58, Steve Beaver <st...@stevebeaver.com> wrote: > > Rex OS VS call Wold to call Bob five is a big jump > > Sent from my iPhone > Steve Beaver > > >> On Feb 1, 2017, at 16:55, Pommier, Rex <rpomm...@sfgmembers.com> wrote: >> >> We're starting down that path. Management doesn't want to have to recompile >> things but I'm thinking we may need to do so just to see if that's the >> problem. >> >> Rex >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Steve Beaver >> Sent: Wednesday, February 01, 2017 4:54 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: COBOL/LE question >> >> I have a simple question do you happen to have a the source modules >> that if you attempted to reassemble them and recompile them to see if >> that's the problem >> >> Sent from my iPhone >> Steve Beaver >> >> >>> On Feb 1, 2017, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> wrote: >>> >>> Hello all, >>> >>> We are in the process of migrating from z/OS 1.13 to 2.2. We just ran into >>> an issue with our COBOL and LE environment. We are running COBOL 4.2. >>> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, >>> IBM introduced the warning message "IGZ0268W An invocation was made of >>> OS/VS COBOL program XXXXXXX." along with providing a usermod that can be >>> installed to suppress the message. Normally that is OK but we have an >>> ancient load module written partially in OS/VS COBOL and partially in >>> assembler that has a home-grown ESTAE routine attached to it. This program >>> has consistently failed spectacularly while testing it under 2.2. Here's >>> the sequence of events. >>> >>> 13.04.12 JOB01549 +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED >>> <<<< 4 normal messages issued at start of run >>> 13.04.12 JOB01549 +TRBCYCLE: BEGIN PROCESSING >>> >> We're starting down that path. Management doesn't want to have to recompile >> things but I'm thinking we may need to do so just to see if that's the >> problem. >> >> Rex >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Steve Beaver >> Sent: Wednesday, February 01, 2017 4:54 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: COBOL/LE question >> >> I have a simple question do you happen to have a the source modules >> that if you attempted to reassemble them and recompile them to see if >> that's the problem >> >> Sent from my iPhone >> Steve Beaver >> >> >>> On Feb 1, 2017, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> wrote: >>> >>> Hello all, >>> >>> We are in the process of migrating from z/OS 1.13 to 2.2. We just ran into >>> an issue with our COBOL and LE environment. We are running COBOL 4.2. >>> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, >>> IBM introduced the warning message "IGZ0268W An invocation was made of >>> OS/VS COBOL program XXXXXXX." along with providing a usermod that can be >>> installed to suppress the message. Normally that is OK but we have an >>> ancient load module written partially in OS/VS COBOL and partially in >>> assembler that has a home-grown ESTAE routine attached to it. This program >>> has consistently failed spectacularly while testing it under 2.2. Here's >>> the sequence of events. >>> >>> 13.04.12 JOB01549 +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED >>> <<<< 4 normal messages issued at start of run >>> 13.04.12 JOB01549 +TRBCYCLE: BEGIN PROCESSING >>> >>> 13.04.12 JOB01549 +TRBCYCLE: LIMIT= 900.00 SECONDS EACH 001 >>> >>> 13.04.13 JOB01549 +TRBCYCLE: 20 ABENDS ALLOWED >>> >>> 13.06.37 JOB01549 +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 >>> (LE) <<<< first abend message >>> >>> $HASP375 DCD110 ESTIMATED LINES EXCEEDED (a bunch of these) >>> CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET: >>> >>> IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110 >>> +CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP. >>> +CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 00000001 406 >>> WHILE RUNNING PROGRAM IGZCMSG WHICH STARTS AT 1687F3B0 >>> AT THE TIME OF INTERRUPT >>> PSW 00080000 804340DA >>> GPR 0-3 0043D9A8 0043D668 0043D668 00433038 >>> GPR 4-7 0043D38C 0043D698 00433038 0043D658 >>> GPR 8-B 0042CED0 0042AB40 0045D050 9687F3B0 >>> GPR C-F 0042AC30 0043D490 804340DA 966F4958 >>> +CEE0374C CONDITION=IGZ0016W TOKEN=00010010 49C9C7E9 00000002 407 >>> WHILE RUNNING PROGRAM UNKNOWN >>> AT THE TIME OF INTERRUPT >>> Hello all, >>> >>> We are in the process of migrating from z/OS 1.13 to 2.2. We just ran into >>> an issue with our COBOL and LE environment. We are running COBOL 4.2. >>> Within the maintenance for COBOL and the upgrade in LE from 1.13 to 2.2, >>> IBM introduced the warning message "IGZ0268W An invocation was made of >>> OS/VS COBOL program XXXXXXX." along with providing a usermod that can be >>> installed to suppress the message. Normally that is OK but we have an >>> ancient load module written partially in OS/VS COBOL and partially in >>> assembler that has a home-grown ESTAE routine attached to it. This program >>> has consistently failed spectacularly while testing it under 2.2. Here's >>> the sequence of events. >>> >>> 13.04.12 JOB01549 +TRBCYCLE: ESTAE ISSUED/LE COND HDLR REGISTERED >>> <<<< 4 normal messages issued at start of run >>> 13.04.12 JOB01549 +TRBCYCLE: BEGIN PROCESSING >>> >>> 13.04.12 JOB01549 +TRBCYCLE: LIMIT= 900.00 SECONDS EACH 001 >>> >>> 13.04.13 JOB01549 +TRBCYCLE: 20 ABENDS ALLOWED >>> >>> 13.06.37 JOB01549 +TRBCHDLR: U4038 ABEND TRAPPED FOR POLICY 1512345623 >>> (LE) <<<< first abend message >>> >>> $HASP375 DCD110 ESTIMATED LINES EXCEEDED (a bunch of these) >>> CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4087 TO DATA SET: >>> >>> IEA822I COMPLETE TRANSACTION DUMP WRITTEN TO RRP.D032.T1306504.DCD110 >>> +CEE3797I LANGUAGE ENVIRONMENT HAS DYNAMICALLY CREATED A DUMP. >>> +CEE0374C CONDITION=IGZ0268W TOKEN=0001010C 49C9C7E9 00000001 406 >>> WHILE RUNNING PROGRAM IGZCMSG WHICH STARTS AT 1687F3B0 >>> AT THE TIME OF INTERRUPT >>> PSW 00080000 804340DA >>> GPR 0-3 0043D9A8 0043D668 0043D668 00433038 >>> GPR 4-7 0043D38C 0043D698 00433038 0043D658 >>> GPR 8-B 0042CED0 0042AB40 0045D050 9687F3B0 >>> GPR C-F 0042AC30 0043D490 804340DA 966F4958 >>> +CEE0374C CONDITION=IGZ0016W TOKEN=00010010 49C9C7E9 00000002 407 >>> WHILE RUNNING PROGRAM UNKNOWN >>> AT THE TIME OF INTERRUPT >>> PSW 00080000 804340DA >>> GPR 0-3 00441DE0 00441AA0 00441AA0 00433038 >>> GPR 4-7 0044187C 00441AD0 00433038 00441A90 >>> GPR 8-B 0042CED0 00000008 0045D050 9687F3B0 >>> GPR C-F 0042AC30 004418C8 804340DA 966F4958 >>> FLT 0-2 49310F59C0000000 4E000000030869B8 >>> FLT 4-6 4E00000000025368 0000000000000000 >>> >>> IEA995I SYMPTOM DUMP OUTPUT 417 >>> USER COMPLETION CODE=4087 REASON CODE=00000000 >>> TIME=13.06.50 SEQ=00312 CPU=0000 ASID=0045 >>> PSW AT TIME OF ERROR 078D1000 966A5806 ILC 2 INTC 0D >>> ACTIVE LOAD MODULE ADDRESS=1660D410 OFFSET=000983F6 >>> NAME=CEEPLPKA >>> DATA AT PSW 166A5800 - 00181610 0A0DA7F4 001C1811 >>> GR 0: 84000000 1: 84000FF7 >>> 2: 00000000 3: 00433038 >>> 4: 166E8398 5: 166E8A34 >>> 6: 00429358 7: 166A57CA >>> 8: 80000000 9: 00443EC6 >>> A: 00000001 B: 966A5728 >>> C: 0042AC30 D: 00441EC8 >>> E: 8043404E F: 00000000 >>> END OF SYMPTOM DUMP >>> >>> >>> I'm not asking anybody to chase the dumps for me or anything like that, >>> just wondering if anybody has had issues like this while migrating to 2.2. >>> I added a STEPLIB to the job step to point to the 1.13 SCEERUN and SCEERUN2 >>> libraries and the program runs fine. I've tried it with and without the >>> USERMOD designed to suppress the warning message about OS/VS COBOL to no >>> avail. To make it even more bizarre, I even went so far as to try it in my >>> 1.13 system with a STEPLIB pointing to the 2.2 SCEERUN and SCEERUN2 >>> libraries to try to get it to fail and it didn't. >>> >>> Am I looking at the wrong place by looking at this IGZ0268W message? Am I >>> missing something obvious? >>> >>> Thanks for any advice you may be able to offer. >>> >>> Rex ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN