Re: Restore Display . . . *YES

["Denis Robitaille" <DRobitaille@xxxxxxxxxxxx>]

I know 2 solution to this problem.

1: In the window programs, declare the display file as user open. Then open and 
close the display file manually each time you enter and leave the program. The 
draw back is the overhead of opening/closing the display file on every call.

2: In the DDS of the display file, add a record format like this:

A          R EC00D1                                                 
A                                      CLRL(*NO) OVERLAY FRCDTA     

In the RPG, just before the return instruction:

c                   write     ec00d1                
c                   return                          

This works here

Denis Robitaille
Directeur service technique
Cascades Inc
819 363 5187
fax 819 363 5177


>>> Pete Hall <pbhall@execpc.com> 09/12 6:32 PM >>>
At 12:50 09/11/1999 , Booth Martin wrote:
>I am getting unexpected behavior and can't figure out why.  I have a
>program with a main screen with header information about the application
>and as the user makes various choices on the screen various windows are
>displayed to respond to his requests.  What is disconcerting is that when
>the window is displayed the screen in the background is the first screen
>used that day. It seems to never have the currnet background.

Here's an oldie from the archives that explains how to get around this 
problem. I can't take any credit for it, other than to say that I have done 
it, and it works.

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

To keep AS400 subprogram display from flashing the old data when reentered:

MOVE *OFF     PUTOVR          -- as the program is entered (not *INZSR)
                                                         and as another 
program with a display
                                                         is called.

MOVE PUTOVR *IN91            -- just before the EXFMT, *IN91 is the option
                                                        indicator on the 
DSPF next to the
                                                        PUTOVR keyword.

MOVE *ON       PUTOVR         -- just after the EXFMT.

PUTOVR  IFEQ  *OFF             -- just before writes to the display, must be
SFLREC  OREQ*ZERO               before the write to the message subfile.
         WRITE#CLRSCN            (SFLREC is number of SFL records and
         ENDIF                   is checked to clear/clean up the old
                                 subfile records previously displayed.

With the setup as described above you do not have to RSTDSP(*YES) which is 
a big advantage as it is a memory pig and you do not have to open and close 
your display files.  The key is that if pgm A calls pgm B and then control 
is returned to pgm A
you would normally receive an I/O error due to overlapping input capable 
fields.  There are two ways to correct this:

a) use RSTDSP(*YES), which will consume main storage and increase 
communications line time by forcing the system to save and restore the 
display for the program.

  b) use the setup as described above.   Difference; on a B30 .2 seconds on 
a locally attached
workstation.

Tim Hawkins

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Pete Hall
pbhall@execpc.com 
http://www.execpc.com/~pbhall 
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com 
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---