× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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).

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.