With externally described files, by default, the compiler does what it wants to with each individual field (or column), unless you tell it to do something else. For example, it converts the zoned field in the physical/logical file into a packed decimal for internal use in the program.
You can redefine one or more of those zoned fields by naming it as a stand-alone with the "Z" for zoned specified, but you cannot change the length or the decimal places this way, if I remember correctly.
You can also do specify them inside a data structure, take your pick of the fields, as in the previous examples in this thread of the overlay of the fields.
You can make sure the field definitions inside the RPG program are exactly the same as in the physical files by using the same file name as the EXTNAME() reference for an externally described data structure.
Alan Cassidy
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of paultherrien@xxxxxxxxxxxxxxxxxx
Sent: Tuesday, January 21, 2014 8:41 AM
To: 'RPG programming on the IBM i (AS/400 and iSeries)'
Subject: RE: overlaying arrays in v5r1
Vern, I recall that bit of conversation in this list, but I didn't give it much thought at the time. But it seems to me that if this is true that this would be disturbing behavior. If the fields for an externally defined file defined in the program F specs do not come into the program in the record layout as defined in the database then this would/could be a problem. If the record layout does not guide the compiler in the field order then what does? Are there rules to determine the sequence of the fields? ... If there are no rules then the field layout could change from compile to compile.
Paul
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Vernon Hamberg
Sent: Tuesday, January 21, 2014 5:19 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: overlaying arrays in v5r1
Hi Ken
I've used this same technique in the past, probably without problems.
Bit I think I've been told (maybe Jon Paris) that this technique is not guaranteed to be safe. There is no guarantee that contiguous fields will be brought into the program buffers in the same order - each field is brought into internal buffers individually - unless using LIKEREC or EXTNAME.
Now maybe we could use a pointer to the subfield in the LIKEREC DS as the based pointer of the stand-alone array - then it wouldn't matter, so long as the fields in question remain contiguous in the format.
Whadda y'all think?
Vern
On 1/20/2014 8:41 PM, Ken Sims wrote:
Hi Tom -
On Mon, 20 Jan 2014 15:17:33 -0600, Thomas Garvey <tgarvey@xxxxxxxxxx>
wrote:
Since I needed to use the externally described data structure, which
brings in the original fields as subfields, I could not create
separate data structures to name the subfields again and have them
overlaid (which I would LIKE to do to avoid the
overlay(field:startpos) format of the overlay keyword).
So, I did use the StartPos format. Fortunately, the file this is
based on is mature and won't be changing.
What I've done when the field are contiguous in the record format, and
that aspect will NOT change, however there could be fields added or
changed such that the absolute position in the record format could
change ...
... is to code the array stand-alone, based on a pointer, and have the
pointer defined to initialize to the address of the first of the
fields in the record format.
Ken
Opinions expressed are my own and do not necessarily represent the
views of my employer or anyone in their right mind.
--
--------------------------------------------------------------------------------
Confidentiality Notice: This email may contain confidential information or information covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions. It contains information that is legally privileged, confidential or otherwise protected from use or disclosure. This e-mail message, including any attachments, is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
--------------------------------------------------------------------------------
midrange.com
