RSTDSP(*YES) alternative

[gregwga50]

I have an RPG program , PGMA that displays a record format and then if the user presses F4, it calls another RPG program, PGMB that displays a subfile from which a selection can be made. Upon return to PGMA, part of the subfile from PGMB is displayed at the bottom of the format displayed by PGMA. I can prevent this by compiling the DSPF that PGMA uses with RSTDSP(*YES). Is there another way to accomplish this using keywords in the DDS? The reason being is because we use a change management too that doesn't handle custom create parameters very well

[Alan S. Binkow]

A couple of ideas...

1) If PGMB is a window, you can specify RMVWDW (with an indicator) in its display file. See a RMVWDW example here: http://publib.boulder.ibm.com/html/a...bafpmst434.htm (It also works if the two screens are in separate programs).

2) You can create a format that consists of blanks in PGMA, covering the part of the screen where the remnants of the subfile appear. Then, when you have returned from PGMB, WRITE this format, thereby blanking the portion of the screen you don't want to see. It's a bit clumsy, I know, but it gets the job done.

[Terry Wincheste]

Add this record to your Display File DDS. You don't need to execute it...just recompile your DSPF (without RSTDSP) and compile your program to see if it works...

*---------------------------------------------------------------*
*        Dummy record to preserve screen for popup windows      *
*---------------------------------------------------------------*
          R DUMMY                                                
                                      ASSUME                     
                                 24 79' '

[Alan S. Binkow]

Terry --

An ASSUME record prevents the PGMA display from being cleared off when PGMB launches. I don't think it has any influence when PGMB returns?

[Terry Wincheste]

Strange, I never seem to have problems like this because I always code a dummy record in every display file. Have never had the need to use RSTDSP. Some of our screens make over 3 nested interactive calls (normal windows, subfile screens and windows, etc.) and they always seem to return to normal using this method

[gregwga50]

A couple of ideas...

1) If PGMB is a window, you can specify RMVWDW (with an indicator) in its display file. See a RMVWDW example here: http://publib.boulder.ibm.com/html/a...bafpmst434.htm (It also works if the two screens are in separate programs).

2) You can create a format that consists of blanks in PGMA, covering the part of the screen where the remnants of the subfile appear. Then, when you have returned from PGMB, WRITE this format, thereby blanking the portion of the screen you don't want to see. It's a bit clumsy, I know, but it gets the job done.

(1) No, PGMB does not display a window

(2) That sound like it will work

[gregwga50]

A couple of ideas...

1) If PGMB is a window, you can specify RMVWDW (with an indicator) in its display file. See a RMVWDW example here: http://publib.boulder.ibm.com/html/a...bafpmst434.htm (It also works if the two screens are in separate programs).

2) You can create a format that consists of blanks in PGMA, covering the part of the screen where the remnants of the subfile appear. Then, when you have returned from PGMB, WRITE this format, thereby blanking the portion of the screen you don't want to see. It's a bit clumsy, I know, but it gets the job done.

Suggestion #2 worked

[gregwga50]

I wonder if there is something I can change in PGMB. I have to change a lot of programs to call PGMB. It would be easier to change PGMB, if possible, then I would only have to make the change once instead of every program that calls PGMB

[tomliotta]

The reason being is because we use a change management too that doesn't handle custom create parameters very well

Does it allow post-creation commands? After creation, you might run CHGDSPF RSTDSP(*YES).

What is the CMS? Maybe someone has a suggestion. Not being able to set creation parameters would seem to be a serious limitation.

[kitvb1]

I'm curious, which Change Management System is it?

[CRinger400]

The DDS equivalent of RSTDSP(*YES) is USRRSTDSP if that helps any.

Ringer

[Brian Rusch]

The DDS equivalent of RSTDSP(*YES) is USRRSTDSP if that helps any.

Actually, it's just the opposite. RSTDSP(*YES) will automatically restore a display file if it was suspended by another display file (usually a window display), whereas USRRSTDSP tells the system not to automatically restore the display file if it is overlaid with a window. Here's the help text from the RSTDSP parameter and the text from the DDS manual for the USRRSTDSP keyword:

Restore display (RSTDSP) - Help *YES
The data being shown when this file is suspended is saved, and it is restored to the device display when the file is used again.

USRRSTDSP (User Restore Display) keyword for display files
You use this record-level keyword on a window record to specify that the application will manage the display.
If this keyword is not specified, the system saves and restores the underlying display when a window record is displayed.