Re: Overlaying a DS Array In a LIKEREC DS

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

DAPN13 is not populated - defined in the record format (1000004D) but 
not used anywhere else.

It seems the 12 fields from DAPN1 to DAPN12 are "defined" twice - 
interesting, eh?

Vern

On 7/2/2010 1:05 PM, Michael D. Schutte wrote:
> Here, I tested it...
>
> H Option(*NoDEBUGIO:*SRCSTMT)
> H Debug(*YES)
> FSOMEFILE  IF   E           K DISK
> D MYDS            DS
> D  DAPN1
> D  DAPN2
> D  DAPN3
> D  DAPN4
> D  DAPN5
> D  DAPN6
> D  DAPN7
> D  DAPN8
> D  DAPN9
> D  DAPN10
> D  DAPN11
> D  DAPN12
> D Periods                             DIM(12) OVERLAY(MYDS:1) LIKE(DAPN1)
>
> /Free
>     Read GLPDA;
>     Dump;
>     *InLR = *On;
>     Return;
>   /End-Free
>
> These fields do show up in the compile with a RNF7031 error message.
>   *RNF7031 DAPN1             A(3)                   000500D     001700     1000004D
>   *RNF7031 DAPN10            A(3)                   001400D    1000013D
>   *RNF7031 DAPN11            A(3)                   001500D    1000014D
>   *RNF7031 DAPN12            A(3)                   001600D    1000015D
>   *RNF7031 DAPN13            A(3)                  1000016D
>   *RNF7031 DAPN2             A(3)                   000600D    1000005D
>   *RNF7031 DAPN3             A(3)                   000700D    1000006D
>   *RNF7031 DAPN4             A(3)                   000800D    1000007D
>   *RNF7031 DAPN5             A(3)                   000900D    1000008D
>   *RNF7031 DAPN6             A(3)                   001000D    1000009D
>   *RNF7031 DAPN7             A(3)                   001100D    1000010D
>   *RNF7031 DAPN8             A(3)                   001200D    1000011D
>   *RNF7031 DAPN9             A(3)                   001300D    1000012D
>
>
> However, the dump shows the fields are populated.
> MYDS                  DS
>     DAPN1               CHAR(3)              'MAY'
>     DAPN10              CHAR(3)              'FEB'
>     DAPN11              CHAR(3)              'MAR'
>     DAPN12              CHAR(3)              'APR'
>     DAPN2               CHAR(3)              'JUN'
>     DAPN3               CHAR(3)              'JUL'
>     DAPN4               CHAR(3)              'AUG'
>     DAPN5               CHAR(3)              'SEP'
>     DAPN6               CHAR(3)              'OCT'
>     DAPN7               CHAR(3)              'NOV'
>     DAPN8               CHAR(3)              'DEC'
>     DAPN9               CHAR(3)              'JAN'
> PERIODS             CHAR(3)              DIM(12)
>                        (1)                'MAY'            'D4C1E8'X
>                        (2)                'JUN'            'D1E4D5'X
>                        (3)                'JUL'            'D1E4D3'X
>                        (4)                'AUG'            'C1E4C7'X
>                        (5)                'SEP'            'E2C5D7'X
>                        (6)                'OCT'            'D6C3E3'X
>                        (7)                'NOV'            'D5D6E5'X
>                        (8)                'DEC'            'C4C5C3'X
>                        (9)                'JAN'            'D1C1D5'X
>                        (10)               'FEB'            'C6C5C2'X
>                        (11)               'MAR'            'D4C1D9'X
>                        (12)               'APR'            'C1D7D9'X
>
>
>
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
> Sent: Friday, July 02, 2010 1:12 PM
> To: rpg400-l@xxxxxxxxxxxx
> Subject: Re: Overlaying a DS Array In a LIKEREC DS
>
> Hi Dennis - it is certainly the "unreferenced" issue as the test in
> the thread I referenced demonstrated.
>
> When the READ is targetting a DS directly all fields are always moved
> because there are no field moves generated - the whole record is moved
> as a lump. Although this can't always be true in the case of EXFMT and
> a *ALL defined DS.
>
> The issue seems to be under what circumstances a DS that consists of
> fields from a record will be populated by a read that does _not_
> specify the DS as the result. The code in the referenced thread
> appears to show that the fields in an externally described DS will not
> be populated unless referenced elsewhere. Michael is convinced that if
> the field names are specified "by hand" that they get populated - and
> that's what I still have to test.
>
>
> Jon Paris
>
> www.Partner400.com
> www.SystemiDeveloper.com
>
>
>
> On Jul 2, 2010, at 1:00 PM, rpg400-l-request@xxxxxxxxxxxx wrote:
>
>    
> > Jon, I believe this is related to age-old "unreferenced fields"
> > idiosyncrasy.  Even as far back as the System/3, the RPG compiler
> > has always
> > removed fields that are unreferenced (RNF7031 "errors").  ...
> >      
>    
> > *BUT* I don't know what
> > happens when the READ is to a data structure.  Seems to me at that
> > point
> > that the fields should be populated.  If they're blank in that
> > scenario,
> > then it seems to me that either there's mystery happening and the
> > READ-INTO-DS doesn't work like it appears to be designed (which I
> > doubt), or
> > the compiler is wiping the unreferenced fields (which I also doubt).
> >      
>