Re: Controlling the definition of fields defined like(...)

Roger,

if you don't specify the specific type of a field in a data structure
the default is packed, as all numeric data is eventually converted to
packed for manipulation and math.

which has gotten me to thinking, maybe I was backward about what
defining the eDS does - I think it describes it specifically as how it
is in the file (packed, zoned) whereas only having the field described
by the F and input specs will aways declare it to the program as
packed.

try this.  add an eDS for file C to both programs and see if it fixes
your problem.

On 6/14/06, Roger Vicker, CCP <rv-lists@xxxxxxxxxx> wrote:

Rick,

More Details.

PFile C:
    Field dividnum is 5p 0

DSPFile B:
    Field dividnum is reffld(dividnum C) which compiles as zoned.

Program A:
    F spec for pfile C
    DS as in original post (below)

Program B:
    F spec for dspfile B
    F spec for pfile C
    DS as in original post (below)

In both programs the array is defined as like(dividnum) and in a DS but
in program B the compiler makes the type as packed. I thought that
unless you specified the full attributes of numeric field in a DS the
compiler would zone type it. I even tried defining a dummy 1A field as
an overlay of the sel array in program B to hint the compiler to zone it
and the array is still packed.

Also, in checking the compile listing for both programs the field
dividnum is zoned in A and packed in B just like the array.

Roger

On 6/13/2006 9:53 PM, rick baird wrote:

>Roger,
>
>If I understand the problem correctly, you have a field defined as
>zoned because it's defined like a field in a file, and another as
>packed because it's in a DS.
>
>try this: in the program that has the zoned field, in addition to the
>F spec, define the file as an external data structure.  you don't have
>to do anything with it, but I think (i know, trouble), it will map all
>the zoned fields to packed.
>
>I don't know if you can define a display file (you did say it was a
>display file, right?) as an eDS, but if not, if a similar field is
>also defined in another file, define that file as an eDS and use that
>field for your like().
>
>hope this helps,
>
>Rick
>
>On 6/13/06, Roger Vicker, CCP <rv-lists@xxxxxxxxxx> wrote:
>
>
>>This is starting to drive me down the hall screaming.
>>
>>And the archives had a promising solution with data structures but it
>>just doesn't work. V5R3
>>
>>I have a file with a field (dividnum) defined as packed 5,0.
>>
>>I have two programs that use the file. Program B has a display file with
>>the field in it via reffld(dividnum)
>>
>>Program A has a data structure defined with a specified length and an
>>array in it defined as like(dividnum) that is passed to/from program B
>>using prototypes.
>>
>>Program B has a data structure defined with with the same specified
>>length and an array in it defined as like(dividnum) that is pointer
>>based. Program B sets the pointer to the data structure as the address
>>of Program A's data structure that is passed to it. I have verified that
>>the pointer "magic" works just fine.
>>
>>// Program A
>>
>>D SelDs           ds           384
>>
>>D   sel                               like(dividnum) DIM(32) ASCEND
>>
>>
>>// Program B
>>
>>D SelDs           ds           384    based(SelDsAdr)
>>
>>D   sel                               like(dividnum) DIM(32) ASCEND
>>
>>D SelDsAdr        s               *
>>
>>
>>The problem is that the array in program A is zoned, as I would expect
>>it to be since it is in a data structure. Program B however defines the
>>array as being packed.
>>
>>There has got to be a way to define fields by reference to reduce code
>>changes when lengths changes but either get consistent type (zoned,
>>packed...) or be able to force the type so that they can be passed as
>>parameters between programs.
>>
>>Does everyone hard code field lengths for numeric parameter passing or
>>have I missed something?
>>
>>Roger Vicker, CCP
>>
>>--
>>*** Vicker Programming and Service *** Have bits will byte *** www.vicker.com 
***
>>Never deprive someone of hope, it may be all they have.
>>
>>--
>>This is the RPG programming on the AS400 / iSeries (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.
>>
>>
>>
>>

--
*** Vicker Programming and Service *** Have bits will byte *** www.vicker.com 
***
Never deprive someone of hope, it may be all they have.

--
This is the RPG programming on the AS400 / iSeries (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.