×
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.
On 05/09/2008, at 7:43 AM, Frances Denoncourt wrote:
Is there any reason that DSPF/programs should have problems with a
second footer?
No, as long as:
a) There is room on the physical screen for the footer
b) No part of the subfile (SFL) record overlaps the footer
c) The code actually writes the footer to the display
This is about the fourth or fifth program being modified in this
project that when the SUBFTR02 is read I get a session or device
error stating that cannot read without a prior write or words to
that effect.
The OS doesn't lie (generally). If it says there was no prior write
then that is likely the case. Ensure your code does write the footer
in all cases where it attempts to read the footer. Ensure later
writes don't occupy the same screen area as the footer (even sharing
end and start attribute bytes is too much) which cause SUBFT02 to be
removed from the active formats.
I've added new fields to each of the subfiles. But, have not done
anything else with the logic other than populating the new fields.
Have these new fields in the SFL record increased the amount of space
required to display the sub-file?
I thought it might be a fold/drop issue, but removing that didn't
help. Put the FOLD/DROP back in and removed the READ of the SUBFt02
which did resolve the issue.
Unlikely to be fold/drop itself since the DDS compiler accounts for
the space needed in folded mode when compiling. More likely to be
additional fields requiring more space or a new format occupying
space used by another format.
We read SubFtr02 [field S1Path] to look for a jump to another program.
When I commented out the READ [putting back the FOLD/DROP], no
error. Of course, I can't jump to another menu option, now, either.
Removing the read of SUBFT02 will, of course, resolve the issue
because you're no longer attempting to read without a prior write.
However, I must mention, that one that did keep erroring, worked
fine after I removed the FOLD/DROP.
That's weird and suggests something else is going on that you haven't
properly diagnosed.
These program have not been modified for over a year with the
exception of one that is new but cloned from an old one.
Why would that matter? You're modifying them now.
Did you change from using SFLEND to SFLEND(*MORE) at the same time?
Did you do anything that would cause record formats to occupy more
screen space than they did previously?
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
