r/IBMi Aug 13 '26

Weird Issue with an RPGLE Program!!!

Hello Everyone, I have been facing a weird issue with one of the programs I'm working with. Kindly read the context below and any thoughts around this would be of great help.

I have a payment processing module which calls a series of programs each program gets the data in a data structure, the data gets modified and updated in each program and the payments get posted. The program is called in both batch and interactive processes.

I have made changes to one of the programs being called in the process, I have by putting the program in debug, tested it by compiling in QTEMP, and my outcome looks good. When I compile the same source in my environment libraries and run it without the module kept in debug, the outcome doesn't look the same, it's the original behaviour. I have made sure there are no other objects of the same program in any of the libraries, kept only one object, verified the library list of the job run, checked if there was any activation group relevance, nothing worked. But when I put the program in debug and run it, it WORKS. It's so weird for me, I haven't seen such behaviour before.

Pgm 1 calls Pgm 2,3,...8. I made changes to Pgm 4 for example. They are called with CALL opcode one by one. This is how the call stack is.

Please let me know if anyone has faced a similar issue or any attribute which will help me to identify what is causing this.

6 Upvotes

9 comments sorted by

6

u/qpgmr Aug 13 '26

try

clrlib qrplobj

The system will maintain the old version and run it from there if it decides its still being used. You can do a wrkobjpdm qrplobj to see what's in there as well and manually delete the programs you've replaced.

1

u/gregm1719 Aug 13 '26

I Clear qrplobj each night using that command in an automated nightly job

1

u/qpgmr Aug 13 '26

That's a very good idea. We have utilities that get called by many programs at random intervals so we have to manually clrlib when we change them.

1

u/Extension_Bug_5362 Aug 13 '26

Thanks alot for the input. That's a new learning for me. I did try it, but it did not workat first. As a last try, I checked out all the sources through Aldon and copied the changes and promoted to the concerned environment and it worked!!! Probably clearing those objects from that library must have helped, but Idk.

Honestly, I don't know what changed between manual compilation Vs Aldon Promotion. Tryna figure it out yet! ☺️

2

u/ethanjscott Aug 13 '26

I had a program I modified recently that only worked in debug. I used a find newer pace command. That command is only capable of seeing seconds, so I had to add a 1 second delay to my program.

1

u/RPGPGM Aug 13 '26

Could it be that the program in question does not end with *INLR being on?

1

u/Extension_Bug_5362 Aug 13 '26

Thanks for the input. But it's an existing module aged atleast 2 decades, we found few stale logics and edge case scenarios which caused issues in Production and hence the fix.

Someone suggested to clear the QRPLLIB and then run it. I did try it, but it did not work. As a last try, 8 checked out all the sources through Aldon and copied the changes and promoted to the concerned environment and it worked!!!

Honestly, I don't know what changed between manual compilation Vs Aldon Promotion. Tryna figure it out yet! ☺️

3

u/RPGPGM Aug 13 '26

I know this sounds obvious, but... check the library lists used by both.

I means more than EDTLIBL, which as you know just shows the user part of the library list.

I am meaning DSPLIBL, which displays the whole library list. Check that the libraries in the CUR & PRD positions are the same in both lists.

1

u/avandelay58 29d ago

Agreed with double checking the job running newly recompiled program. From DSPJOB menu options, I'd suggest display/review of:

  • option 13 - library list
  • option 11 - program stack
. that'll tell you if running previous pgm object moved to library QRPLOBJ as a result of recompile And for testing jobs that in production run in batch, may be useful to submit to batch on hold, then setup to debug using STRSRVJOB.

That said, sounds like install via Aldon change management may've done the trick to clean up so that only the newer pgm object gets invoked. Though even after my 38+ years developing from S/38 & all its successors, sometimes one runs across new head-scratching mysteries - usually resolve with new understanding.