RE: Problem with field selection subfile on V5R3M0 - cause found!

Right.
INDDS requires that the DDS have the INDARA keyword on it. I hope all
display files since 1983 have had this keyword inserted into them.

Also, when you use the INDDS itself, the indicator is not passed to the
program at all. So if indicator 63 is used for DSPATR(PC RI) setting on
indicator 63 in your code will have no impact on the display file nor the
DSPATR keyword in this case.
You have to "set on/off" the Named Indicator in position 63 of the INDDS
instead of *IN63. If there is no named indicator in that position, I suppose
you could defeat the purpose of using the INDDS, by specifying an array
index of something like MyIndyDS(63) = *ON, but this just gives me a
headache.

-Bob Cozzi
www.RPGxTools.com
RPG xTools - Enjoy programming again.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of DeLong, Eric
Sent: Thursday, November 03, 2005 10:31 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Problem with field selection subfile on V5R3M0 - cause found!

Larry,

I can't help but wonder, are you sure you're using the INDARA in the dspf
DDS?  I didn't think you could use the INDDS keyword in RPG unless the DSPF
had the INDARA attribute.

My understanding of INDARA and (in RPGIV) INDDS, is that it reserves a block
of memory that represents all possible indicator values being passed between
the HLL and the DSPF.  *IN01 is the first byte of this space, *IN99 is the
99th byte...  Whether all these indicators are being used in the DSPF is
irrelevant, since space is reserved for them anyway....

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: rpg400-l-bounces+edelong=sallybeauty.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+edelong=sallybeauty.com@xxxxxxxxxxxx]On Behalf
Of Larry Ducie
Sent: Thursday, November 03, 2005 6:01 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Problem with field selection subfile on V5R3M0 - cause
found! 


Hi All,

I have found a "solution" to our problem, but I can't see how it would be 
the "cause" of the problem.

Basically, the display file indicator DS (indds) had four indicators defined

which were not in the display file. The programmer who wrote the 
program/display file had copied one of my programs and modified it to create

a new program. As a result he had left these four indicators in the indds, 
but removed them from the DDS. In the program these indicators were still 
getting updated - and consequently some portion of the internals of the 
display file was being overwritten.

I removed the fields from the indds and made them standalone indicators and 
recompiled - all worked fine. This isn't the solution, and the programmer is

now working on removing the indicators and all references from the program 
"as I type", but it begs the question: How can this happen? I assumed that 
the indds was contiguous. There are fields defined before and after these 
fields in the indds so I would have thought that the memory affected by 
these indicators would be "safe". Can we really completely corrupt a display

file by setting on an indicator sitting in an indds DS within a RPG program,

which is not defined within the display file?

Cheers

Larry Ducie