RE: INZ in all D-specs : Was Problem with moving Data Structures

Won't a CLEAR on a DS put blanks into numeric subfields? That's been my understanding, and to truly initialize a DS you'd want to do a RESET. However you can do a CLEAR on a numeric subfield to put zeros into it.

-Kurt Anderson

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Tuesday, October 20, 2009 7:23 AM
To: RPG programming on the IBM i / System i
Subject: Re: INZ in all D-specs : Was Problem with moving Data Structures

Larry,

I think you're getting confused.

Even without INZ on the DS, you can use EVAL or ZADD to load a value
into a numeric subfield. What you can't do is use ADD.

You can of course also use the CLEAR op-code to initialize individual
subfields or the entire DS.

HTH,
Charles

On Tue, Oct 20, 2009 at 7:30 AM, Larry Ducie <larry_ducie@xxxxxxxxxxx> wrote:

The statements that "personally I believe it is bad practice to use INZ. IMO if you are accessing a variable/DS before you have written data to it your logic is incorrect and needs to be addressed" requires considerable support. I agree that we don't need to worry about initializing standalone variables to default values because they are initialized by the RPG, but a DS is another matter. As I'm sure you are aware a DS is just a character string and can be treated as such (you can make a variable LIKE a DS and it becomes a character variable of the same length). This also means that RPG treats it as a character string during *INIT and sets it to blanks. This results in all decimal data types (and dates) defined within it have all bytes set to hex(40). This is not a problem if you populate the DS from another DS or from a file operation - because the operation is a character move operation and subfield definitions are not checked. But without INZ on the DS definition you have!
 no way of individually initializing the internal decimal fields to default values. The simple act of trying to set them to zero in your code will result in a decimal data arror BECAUSE they already have an incorrect value for the data type. I'm not quite sure what you mean when you state that you shouldn't acces a DS before "you have written data to it". How would you populate a packed decimal variable within an uninitialized DS from a standalone packed decimal variable? Maybe I'm missing something, but that single assignment would fail because the DS packed subfield already has invalid data in it - blanks.

I think INZ is very powerful, and extremely useful. It is good for setting non-default values for standalone variables and essential for initializing DS subfields to protect individual decimal or date subfield assignment operations. Also, the variable values set in INZ are all saved as part of the *INIT process and can be re-instated using the RESET op-code. In fact, that is only half the story. Any values set within the *INZSR are saved on leaving the subroutine so you can custom-set your initial values in there. a RESET will set the variables back to the value they were when saved after running *INZSR. This is why you can't perform a RESET within the *NNZSR - what is the variable going to be reset to???
 Just my thoughts - I'd probably put myself somewhere in the middle, but it is quite a wide gap so I'd find it difficult to put myself anywhere else! :-)

Cheers

Larry Ducie