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 <[email protected]> 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 <string> > >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 00000004. > 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 [email protected] with the message: INFO IBM-MAIN
