RE: Problem with field selection subfile on V5R3M0

Larry,
        After the first call is the object marked as damaged?  You did
not mention if you delete the DSPF and PGM before creating them.  Does
doing that have any impact?

Thank you,
Matt Tyler
WinCo Foods, LLC
mattt@xxxxxxxxxxxxxx

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Larry Ducie
Sent: Wednesday, November 02, 2005 10:26 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Problem with field selection subfile on V5R3M0

Hi,

We have a display file containing a field selection subfile (sflpag = 
sflsiz) which has been compiled on a V5R3M0 machine. This subfile is
built 
using a RPGLE program - pretty standard stuff. We are getting a problem
as 
follows:

1) When the DSPF is first created and the RPG program called, the
program is 
hanging on a line which updates the subfile (update sfl1). When we look
at 
the job we see the following:

The I/O of the application files (option 14 - F11 from DSPJOB) does not 
increase.

The call stack entries do not change.

The thread information (option 20 from DSPJOB) is displaying a rapidly 
increasing total CPU, and a rapidly increasing Aux I/O.

The job is using 53% of total CPU and in status RUN.

To give you an idea of the problem - when we killed the call to the
program 
the I/O on the subfile was 11, but the aux I/O was 162,528! What was
being 
written/updated/deleted??? As I have already said, the program was
simply 
sitting on an update to the subfile, no I/O is performed on any
application 
files, but CPU and aux I/O is through the roof. Again, these values were

increasing extremely rapidly.


2) When we try to call the program again it falls over trying to open
the 
display file. We get the message: Space offset X'00001674' or 
X'0000000000000000' is outside current limit for object PMTWKFPRM, and
the 
program dumps. It would appear that the first use of the display file 
renders it completely unusable - to the point that a DSPFD forces a
dump, 
and a DSPFFD forces a dump. I can only assume that the system has run
off 
thinking it's modifying (adding many records to) the display file object
- 
thus setting the internal segment pointers in the header to spurious
values. 
Is this possible? Given that subsequent calls fail during the open of
the 
display file I can only assume that the space offset in question is 
retrieved from the display file. Of course, I could be wrong.


Does anybody know if this is a known problem with the compiler (DDS or
RPG)? 
We are compiling on a V5R3M0 development machine, but the objects are
being 
compiled at V5R2M0 (compiler 5722SS1 V5R3M0  050428).

Any help would be appreciated

Cheers

Larry Ducie