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


  1.  Home
  2. RPG400-L
  3. May 2006

Re: CPF5192

Hi Ken

Thank you for your persistence in trying to resolve my problem.

Ken Sims wrote:

Hi Rob -


Also using FRCDTA will affect performance just as DFRWRT(*NO) does.
True, but only on the format(s) on which you specify it, rather than every format in the file like DFRWRT(*NO).
True, but the "header" format on which I do an EXFMT is in use well over 50% of the time, and, whilst I will try it as a "get round", I don't really want to leave it in as I will forget about it. I would prefer to spend time now solving it if I can.
You might also try going through the display file and removing keywords that may not actually be needed.
I will check these. I do use LOCK, PUTOVR, OVRDTA and OVRATR on a lot of formats.
If these were wrong, wouldn't I have a problem even when I was using DFRWRT(*NO)?
The display file was created by me on the System/38 and has slowly grown as I have added formats - it now has 181, but it is my only display file - used for absolutely everything. Whatever the application and whether I am using my development or my operational environment, the same programs are using the display file. The particular formats with the problem is a combination that I haven't used for some time - perhaps not since I was on V4R5M0. I will try them also on a old V4R5M0 system. The non-header format on which I am doing a WRITE hasn't been modified for 5 years.
I had a situation several months ago where I was modifying a program to call another program which has its own display file. I started getting display file errors on the display file of the original program when I started a new transaction, but only after my program had been called in the processing of the first transaction. This error had not occurred when I was testing my program inside of a simple shell.
The display file of the first program (which was purchased software that I now provide in-house support for) looked like something converted from S/36 SFGR specs or possibly written by a first-grader. (And the RPG/400 program was just as bad.) The display file had lots of unneeded OVERLAY keywords and other unneeded keywords. When I removed the keywords that weren't actually needed, the display file still worked the way it was supposed to, and the halts went away. 
Interesting.  I will have to experiment.

Once again, many thanks

Rob Dixon

Ken
http://www.kensims.net/
Opinions expressed are my own and do not necessarily represent the views
of my employer or anyone in their right mind.

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.