|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
