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

I would be interested in that information LOL....FYI I have never used
INDDS, I just base a DS on %ADDR(*IN) & rename the indicators there.
If I need additional indicators that will not affect the DSPF I just add
a "D" spec as a standalone field type "N".

Just much more manageable IMO. 


Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces+tommy.holden=hcahealthcare.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+tommy.holden=hcahealthcare.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