Re: XML-INTO allowmissing=yes unicode

Henrik

Your point is well-made. I thought I remembered that the INZ on subfields was a later enhancement, probably for exactly the reasons you give.

I might be mistaken on the timing, however, but here is part of the documentation of INZ from the V3R2 RPG Reference -

* | Static standalone fields and subfields of initialized data
structures are initialized to their default initial values (for
example, blanks for character, 0 for numeric).
* | Subfields of static uninitialized data structures (INZ not
| specified on the definition specification for the data structure)
are initialized to blanks (regardless of their data type).
* | Fields in automatic storage are not initialized.


I hope you all see the vertical bars in front of the text - these indicate something new or changed in the manual.

But I just looked at the V2R1M0 RPG III reference - it mentions an I in position 18, which is a data-structure-level initialization that behaves as just described.

Yes, I did say V2R1M0 - I found it at the IBM Library Server Library at http://publib.boulder.ibm.com/cgi-bin/bookmgr/LIBRARY - this has everything IBM, it seems. Architecture documents for MODCA, for DRDA, and things like AS/400 manuals back to 1991!! A blast from the past!

Enjoy
Vern

On 2/15/2012 9:23 AM, Henrik Rützou wrote:

Jon,

you are completely right, CLEAR resets the value blank/null according to
field types and
RESET sets x'40404040' even into packed numeric fields if they are in a DS
and don't
have a INZ keyword or the DS has a general INZ attribute.

RESET also works with initial field settings in *INZSR and in any other use
of RESET it
resets the values like CLEAR does if the field dosn't have a INZ keyword..

Tell me if that is logical and/or tell me where and when you has the use
for your non-INZ
fields other than alphanumeric fields ends up containing garbage that even
may cause
the program to fail.



On Wed, Feb 15, 2012 at 2:55 PM, Jon Paris<jon.paris@xxxxxxxxxxxxxx> wrote:

On Feb 15, 2012, at 3:55 AM, rpg400-l-request@xxxxxxxxxxxx wrote:

This is more likely a data structure behavior problem because a unicode
fields starts it's "life" with complete different values based on whether
they
are defined as a free field or in a data structure.

EVAL yyy:x
00000 00200020 00200020 00200020 00200020
00010 00200020 00200020 00200020 00200020
EVAL ccc:x
00000 40404040 40404040 40404040 40404040
00010 40404040 40404040 40404040 40404040

Which is exactly what I would have expected. All fields in a DS are always
initialized to spaces (and always have been) unless either the DS has an
INZ or an individual field has one. Similarly a clear of a DS will
initialize fields to appropriate defaults based on data type. The rules for
standalone fields are different and they are always initialized to a
suitable default for their data type.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com




--
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.