Re: 0C4 error upon calling an external REXX module!
LOL. As my college Greek teacher told me, when I complained about an illogicality - well, he waxed eloquent on a number of points on that subject, but he finished with "...you'll find it a lot easier to learn it than to change it". --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Sometimes you feel like a nut. After a day of working on a walnut farm, you don't. -Mike Rowe of the TV show "Dirty Jobs" */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Friday, March 15, 2024 19:31 You're right, but that is the standard Rexx message for any situation where the called module does not return a zero return code (return code as opposed to return string value). "You must have called the routine incorrectly, because it said it was not happy with the call." I agree with you, but Rexx does not, and Rexx counts more than I do. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 0C4 error upon calling an external REXX module!
FWIW, I would say >1) 0C4? That's a really weird code to get from a REXX call, isn't it? No, anything you call might generate an 0C4. I think 0C4 is probably the most common program exception. If the called module expected two parameters and did not check to make sure it got two and not one, I might expect a 0C4. >2) It says "incorrect call to routine", but the call is ~not~ incorrect; >there's only one argument and it's any string value. You're right, but that is the standard Rexx message for any situation where the called module does not return a zero return code (return code as opposed to return string value). "You must have called the routine incorrectly, because it said it was not happy with the call." I agree with you, but Rexx does not, and Rexx counts more than I do. Charles On Fri, 15 Mar 2024 13:00:06 -0400, Bob Bridges wrote: >We just got done resolving a very odd error, and I spent a lot of time >constructing an email in order to ask for help here. We now have spotted the >cause, but I hate to waste the work, and the puzzle in case anyone likes >puzzles. > >We just finished upgrading from z/OS 1.14 to 2.2. (I know, the rest comes in >phase 3.) A REXX/ISPF app started abending at each call to the external >subroutine named LOG. The call looks like this: > > call log > >What LOG should do, and used to do, is manipulate the string and send me a TSO >message; what actually happened each time looks like this: > > System abend code 0C4, reason code 0004. > Abend in external subroutine LOG. > 28 +++ call log self 'Entering' > Error running SCR0100, line 28: Incorrect call to routine > >I added statements here and there trying to get it to give up its secrets but >made little progress. The clues I settled on were: > >1) 0C4? That's a really weird code to get from a REXX call, isn't it? > >2) It says "incorrect call to routine", but the call is ~not~ incorrect; >there's only one argument and it's any string value. > >3) Since LOG's purpose is to send a TSO SEND message, attention focused for a >while on the fact that SYS1.BRODCAST had filled up. But a sysprog determined >it had been full for ages, and it had been sending me messages just fine for >months, until the upgrade. > >4) The TSO SEND command continues to work fine, when I call it from the ISPF >command line. > >5) The LOG subroutine, too, works fine, when I invoke it from the ISPF command >line using the TSO EX command, like this: > > ==> tso ex 'hlq.library.name(log)','string' > >6) I added SAY statements inside the LOG module, hoping to find out exactly >where it was bogging down, but none of them were executed. I concluded that >it isn't any code inside LOG that's failing, but the call itself; the REXX >interpreter's never getting as far as the LOG exec. > >7) I wondered whether a new member named LOG had crept into the SYSPROC or >SYSEXEC concatenation and was supplanting this one, but no. > >I commented out all the calls to LOG and everything worked fine. > >In the end a sysprog checked the linklist and determined that #7 was on the >right track; there's a new Broadcom module named LOG. So all I gotta do is >rename my LOG module and reïnstate the calls using the new name. But it sure >kept me awake a few nights first. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
0C4 error upon calling an external REXX module!
We just got done resolving a very odd error, and I spent a lot of time constructing an email in order to ask for help here. We now have spotted the cause, but I hate to waste the work, and the puzzle in case anyone likes puzzles. We just finished upgrading from z/OS 1.14 to 2.2. (I know, the rest comes in phase 3.) A REXX/ISPF app started abending at each call to the external subroutine named LOG. The call looks like this: call log What LOG should do, and used to do, is manipulate the string and send me a TSO message; what actually happened each time looks like this: System abend code 0C4, reason code 0004. Abend in external subroutine LOG. 28 +++ call log self 'Entering' Error running SCR0100, line 28: Incorrect call to routine I added statements here and there trying to get it to give up its secrets but made little progress. The clues I settled on were: 1) 0C4? That's a really weird code to get from a REXX call, isn't it? 2) It says "incorrect call to routine", but the call is ~not~ incorrect; there's only one argument and it's any string value. 3) Since LOG's purpose is to send a TSO SEND message, attention focused for a while on the fact that SYS1.BRODCAST had filled up. But a sysprog determined it had been full for ages, and it had been sending me messages just fine for months, until the upgrade. 4) The TSO SEND command continues to work fine, when I call it from the ISPF command line. 5) The LOG subroutine, too, works fine, when I invoke it from the ISPF command line using the TSO EX command, like this: ==> tso ex 'hlq.library.name(log)','string' 6) I added SAY statements inside the LOG module, hoping to find out exactly where it was bogging down, but none of them were executed. I concluded that it isn't any code inside LOG that's failing, but the call itself; the REXX interpreter's never getting as far as the LOG exec. 7) I wondered whether a new member named LOG had crept into the SYSPROC or SYSEXEC concatenation and was supplanting this one, but no. I commented out all the calls to LOG and everything worked fine. In the end a sysprog checked the linklist and determined that #7 was on the right track; there's a new Broadcom module named LOG. So all I gotta do is rename my LOG module and reïnstate the calls using the new name. But it sure kept me awake a few nights first. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* It is well to remember that the entire universe, with one trifling exception, is composed of others. -John Andrew Holmes */ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
