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

Hi Bruce, Duane,

Bruce wrote: "... In fact, it is good practice to use INZ in all D-specs unless you have a good reason not to."

Then Duane wrote: "I completely disagree, 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. There are exceptions of course, in my experience these occur most often with date/time/timestamps and constant values where the compiler will not allow you to use a CONST variable."

Yikes! Two very bold statements.


My thoughts:

The statement that "it is good practice to use INZ in all D-specs unless you have a good reason not to." could be interpreted to include the fact that all variables will be set to a default value as part of the *INIT process. So if we are calling that a good reason NOT to then you get my vote. If you don't then please remember that all variables get initialized anyway. Why set a numeric standalone variable to zero? It will only get initialized twice - once by the RPG and once by you. You gain nothing from setting a field to zero twice (unless you really want to make sure it stays zero!).

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



_________________________________________________________________
Need a place to rent, buy or share? Let us find your next place for you!
http://clk.atdmt.com/NMN/go/157631292/direct/01/