Re: Defining an array over a group of fields in a file

[CRPence <CRPbottle@xxxxxxxxx>]

  As I understand it... The issue is not about if\when changes would be 
made to the layout\record-format of the files, but how the compiler 
chooses to define the alignment of the declared variables for the fields 
of the record format.  That although the program created by one 
particular compile may have been verified [e.g. via debug] that the 
declarations were aligned as contiguous storage, the next compile might 
not also effect that same contiguous alignment, regardless that the 
files or most anything else about the source has remained essentially 
unchanged; i.e. perhaps only a PTF to the compiler has changed, which 
resulted in the different alignment of the declarative for the fields.

  The following example I gave in a CLP to effect an implied contiguous 
alignment for use in an effective /array/ [though that code is untested 
because I have only v5r3, and of course CL has no actual array support, 
but the effect is the equivalent of an array]:
http://archive.midrange.com/midrange-l/201301/msg00225.html

Regards, Chuck

On 12 Mar 2013 09:38, TheBorg wrote:
> Good point, and I generally agree with the statement you made below,
> but in this case I know that the client will never upgrade their JDE
> software to a newer version, and these fields have always been
> contiguous within the F0902 record, so I'm not concerned about any
> file changes. We are currently in the process of converting
> everything to SAP...
>
> On 12 Mar 2013 09:00, Vernon Hamberg wrote:
> > I had used this approach - basing an array on a pointer to the
> > first of several fields.
> >
> > However, I've gone away from that. Apparently, there is no
> > guarantee that the fields will be in the order you expect. So IF it
> > has worked, this is an accident.
> >
> > Another DS with the field names in the order you want, and with
> > the array overlaying them, and no data definitions, forces the
> > fields to be contiguous, so far as RPG is concerned. <<SNIP>>