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



Larry,

This sounds like a PTF problem as opposed to a coding problem - do a search for the message no. on the APAR site (http://www-912.ibm.com/n_dir/nas4apar.nsf/nas4aparhome) and you may have some luck.

HTH

Regards

Paul Tuohy
ComCon
+353 1 282 6230
www.comconadvisor.com


----- Original Message ----- From: "Larry Ducie" <larry_ducie@xxxxxxxxxxx>
To: <rpg400-l@xxxxxxxxxxxx>
Sent: Wednesday, November 02, 2005 5:26 PM
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


--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.