That’s from CharlieBrowne’s original “Answer”. As discussion went on, it started becoming clear that “I checked all that thrice” might have been a slight exaggeration. At some point, ya’ gotta verify the fundamentals, eh?

Tom

I suspect that …
1. That field OENFQCD was previously 1 char
2. That the previous version of the display file is somewhere on your computer
— use DSPOBJD *ALLUSR/xxxx *file <– substitue your display file name for the xxxx
3. That the display file has level check .. *NO
4. That if you did the dspjob for the job that is displaying the bad data, as Tom suggested, you would discover in opt 14 that the display file is from the location of the older version.

How this works – you load the buffer for the display file based on the new spec
You pass this buffer to the old display file.
If level check is *Yes it would send an error but since it isn’t it lays the new buffer into the old record structure and everything is pushed to the left 4 spaces or so and since they are only output the fields are untouched in the RPG program.

Phil

Then, recreate the problem. Use DSPJOB when the problem is on the screen to ensure the job’s library list, call stack library names and open files llibrary names are all as expected.

Clearly there’s something involved that we’re not able to see because we’re remote.

Tom

With the original comment (“fetch cursor”), that’s a possibility. The compile shows library TESTITG, which might not be the run-time library. SQL wouldn’t see the same ‘level check’ as native I/O. If the runtime library file has a new CHAR(1) field before OENNOCD in the buffer (or perhaps a field length was increased), the “SELECT *” could mess things up good. That’s a definite reason for never using “SELECT *” in a production program if you don’t process the SQLDA yourself.

Tom