× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Aha, that would be why I generally put Inz on a DS, so I can reset it. I thought I had a valid reason beyond, "Because." ;)

- Kurt

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

Yes, no, and yes.

Yes, CLEAR on a DS blanks numeric subfields.

No, RESET sets the variable/DS to the value of the variable/DS that it contained at the end of the *INZSR subroutine or at the end of the *INIT process if no *INZSR exists. Basically the same point in program execution.

Yes, a CLEAR on any individual variable will set it to its default value

Duane Christen


--


Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx

Visit PAETEC.COM


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Kurt Anderson
Sent: Tuesday, October 20, 2009 8:32 AM
To: 'RPG programming on the IBM i / System i'
Subject: 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
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.