Re: Pulling My Hair Out

The reason the i5/OS messaging is so nice is that it is formatted nicely in a log that is automatically available [it need only be spooled], and extensive details about each message are included. Especially nice things like message identifiers, the program, module, and procedures both those that sent and those that /received/ the message, various replacement text for details related to the failure, and ... more. Although the "words" for just the messages are somewhat descriptive, so is an expression like "My car will not start", yet at the same time, those can be totally meaningless for lack of anything to help clarify the specifics behind the statement. To help people to help you keep from becoming bald :-) it would be best to give more specific details about the errors being received.

Presumably the following describes, for the failing UserPgm, the almost identical failure details:

MCH3601 Escape QRNXIO QSYS *STMT
From module . . . . . . . . : QRNXDBIO
From procedure . . . . . . : _QRNX_DB_SETLL
Statement . . . . . . . . . : 10
To module . . . . . . . . . : QRNXDBIO
To procedure . . . . . . . : _QRNX_DB_SETLL
Statement . . . . . . . . . : 10
Message . . . . : Pointer not set for location referenced.
RNX9998 Escape QRNXIE UserPgm
From module . . . . . . . . : QRNXMSG
From procedure . . . . . . : SignalException
Statement . . . . . . . . . : 21
To module . . . . . . . . . : UserPgm
To procedure . . . . . . . : _QRNP_PEP_UserPgm
Statement . . . . . . . . . : *N
Message . . . . : Internal failure in compiler or subroutine.

I can suggest that most likely, the above error would be due to storage corruption, that the open file pointer [or the pointer that enables navigating to that open file pointer] has most likely been /stomped/ on. Since it was noted there are no parameters in that program itself, then most typical is when calls with parameters are made out of the program; i.e. the called program writes to storage of the caller\calling program, likely where the parameter sizes are mismatched betwixt. Changing the program to use USROPN and sprinkle through the source leading up to the failing statement [e.g. before and after each CALL], either some DUMP or some CLOSE and OPEN operations to the failing file to help isolate where the corruption is happening in the program. In my experience, the most common problem is in calling programs, e.g. system APIs, with 4B00 instead of either 9B00 or the recommended 10I00 which can lead to all kinds of unpredictable results.

Regards, Chuck