No announcement yet.

Pointer not set for location referenced

  • Filter
  • Time
  • Show
Clear All
new posts

  • Pointer not set for location referenced

    Hello All,

    I have 3 RPGLE programs - Pgm1, Pgm2 and Pgm3. Pgm1 calls Pgm2 which inturn calls Pgm3 and then returns control back to Pgm1. Pgm1 again calls Pgm2 and while processing SETLL operation on a file in PGM2, the program crashes with below error. As it is Pointer error, I believe it should be something to do with parameter passing. So I verified parameter and their length in all 3 programs. But, I dont find an issue. Also, none of the programs use data queues or any API calls.

    I understand that its not an easy task to trace this particular error. But, can anyone suggest how to go about this? Which program is most likely to cause this issue? And should this be only related to pointer error?

    Pointer not set for location referenced.
    Internal failure in compiler or subroutine.
    Function check. RNX9998 unmonitored by Pgm2 at statement *N, instruction
    The call to *LIBL/MM192 ended in error (C G D F).

  • #2
    To answer 'how to go about this', take a dump, analyze the variables, and pay attention to the error message. It says 'pointer not set', so believe it and you should find the error.


    • #3
      Are you using parameter lists and all commands or prototyping and CALLP?

      A pointer error can occur with parameter lists or optional parameters with prototyping. You'll get the pointer error if a parameter is not passed, but accessed without check in the called program.
      Double check whether you always pass all parameters.
      ... and if you are dealing with optional parameters (Prototyping - Options(*NoPass)), make sure, that you check if the parameter is passed (with %PARMS) before you access it.



      • #4
        Most common time I see this is when the CALL and CALLED programs have a parameter mismatch - either in number, type, or otherwise. Also may happen if you call a RPG3 from a RPG4 program and vise versa.


        • #5
          Another possible source of this kind of error is calling a CEE API and not passing the omissible feedback parameter. Or any other omissible parameter.

          Sometimes people think that "omissible" means "optional", so they don't pass it. But "omissible" means that the parameter is required, but you can pass *OMIT for the parameter.
          So you can code OPTIONS(*OMIT) on the prototype, but not OPTIONS(*NOPASS).

          When the feedback parameter is not passed, the API might find some other pointer where it expects the feedback parameter to be, and it might corrupt that pointer's data.


          • #6
            Thank you all for your replies.
            I found the issue. It was due to one array field having dimensions mismatch - In called program was set as DIM(500) whereas in calling program, it was set as DIM(100). Didnt expect that. I verified array length but missed to verify the dimensions length.


            • #7
              It always look simple, after the error is found, isn't it? On hindsight, was it 'discoverable' if you studied the variables in the program dump, like I suggested ?


              • #8
                Originally posted by Dennis See View Post
                It always look simple, after the error is found, isn't it? On hindsight, was it 'discoverable' if you studied the variables in the program dump, like I suggested ?
                Hi Dennis, I tried to analyze after Dump. But, unfortunately, i could not deduct more on this error through Dump. I am not saying Dump is a bad thing, it has helped me in other issues. But, for "Pointer" error, I am not sure if it would help. Can you provide more inputs on how you expected this to be?


                • #9
                  It would be interesting if you can post the the lines that show the definition and values of this array from the dump.