RE: Re: Basing a field on an unreferenced field(s) doesn't work

Barbara,

I've started this new newsletter call "Midrange Developer" and I want to
include a hybrid version of your CharToNum procedure that uses the MI
instruction. I'll give you credit as the source of the information, but
I wanted to check with you if you minded me using the idea. Basically,
it would just be a short article (a paragraph or two) taking about the
on-going need for such a feature and then list the code for the
procedure.

What do you think?

Bob Cozzi
cozzi@rpgiv.com
Visit the on-line  Midrange  Developer  forum at: http://www.rpgiv.com


> -----Original Message-----
> From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]
On
> Behalf Of bmorris@ca.ibm.com
> Sent: Friday, January 11, 2002 12:18 PM
> To: rpg400-l@midrange.com
> Subject: Re: Re: Basing a field on an unreferenced field(s) doesn't
work
>
>
> >From: rob@dekko.com
> >Date: Fri, 11 Jan 2002 11:24:29 -0500
> >
> >Yes it does matter if the file field is unreferenced.
> >If I reference the individual file fields then the array elements
will
> also
> >work.
> >My argument is that just by defining an array over the fields with
the
> >pointer address should be enough.
> >Or is there some compiler option to say just bring the fields into
memory,
> >such as a don't optimise?
>
> Rob, specify DEBUG(*YES) in your H spec.  That will cause all I specs
to
> be moved to program fields even if the program fields aren't used (but
> that might be have a bigger impact than you want if you have lots of
> unused fields in your files).
>
> Defining the array over the fields with a pointer address should
indeed
> be enough, as long as the fields are "officially" contiguous.  But
they
> are not officially contiguous unless they are in a data structure.
>
> From a later post:
> >I've heard this before "You are also assuming that consecutive fields
in a
> >file are stored in consecutive memory location which is not always
the
> >case."  But I've seen no examples.
>
> You shouldn't need an example of a case where the fields are not
> contiguous.
> The fact that it is not guaranteed should be enough to stop you from
> assuming they will be contiguous.  Undefined behaviour can change at
> any time, from release to release or even from PTF to PTF.  (Go and
stand
> in
> the corner! :)
>
> A trivial case where the fields won't be contiguous is where you
> have explicitly coded them in separate data structures:
>
> D ds1             ds
> D   x
> D   ary1
> D   y
> D ds2
> D   z
> D   ary2
>
> The current RPG compiler generates field definitions in alphabetical
> order, I think.  So having the fields out of alphabetical order would
> probably be certain to put them out of storage order.  But the
compiler
> doesn't actually map fields to storage.  The component that does map
> out the storage might decide to take ARY1 and stick it in some little
> empty spot created by some boundary alignment thing, way far away from
> ARY2.
>
> Barbara Morris
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.