RE: Packed field with Blanks in it... how?

When the program starts the data in uninitialized.
Uninitialized data structures contain blanks. X'40'.

If the program successfully reads the file, then the data is moved into the records.

If the record is not found, then the data is left in the prior state.

This is why everyone is suggesting to "clear" or add "INZ" to the data structure definition.
Because without the initialization the field will remain with X'40's.

The real issue is that the program does not correctly check if a record was received.
That's why we have "%FOUND" for CHAIN and "NOT %EOF(filename)" for READ.


If they'd spent 10 seconds they could have accounted for that simple issue.

READ filename data_structure;
If %EOF(filename);
Clear data_structure;
Endif;


Such a trivial bug to leave in a program.

Beside the fact that they never accounted for what their program should do if that record is not found.
Why doesn't it send an error telling you that the data has not been setup correctly?
Then you don't have to spend days debugging an error where the programmer just "assumed" the data would always be there.


Chris Hiebert
Senior Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.

From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Brad Stone
Sent: Tuesday, November 9, 2021 7:16 AM
To: RPG programming on the IBM i (AS/400 and iSeries) <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Packed field with Blanks in it... how?


I am helping a customer with a random problem where a field from a file

(packed 16,0) is getting filled with blanks.



On a dump we see hex 04040404040.... in it. And of course it's throwing a

data decimal error.



I tried to look in the program for something obvious, but it's an old

monolith of a program with weird columnar RPGIII code.



Anyhow, in what instances would a field read from a file (or even an

unsuccessful read) that is defined as packed get blanks in it? The field

is not manipulated in any way that I can see.



If reads and no record, it should be zero. If it reads and gets a record,

it should be the value from the file (in this case, confirmed to be zero..

and even hex value shows 000000000000000F.



Just grasping at straws I guess. I've not seen this unless there is an

overlaying DS on a numeric field that gets set to blanks for some reason.



Bradley V. Stone