Re: *DS4 to *DS3 Issue

Jon,

Some wild guesses here:

The first time it works OK is because the DSPF of OP3102R has not yet been 
opened and the screen size of the previous programme .
As you have defined the *DS3 first in the SELECTCPY DSPF that size becomes 
active, but it shows the *DS4 screen as by indicator on the record level.

Closing the window does not replace the screen size  of the previous screen, as 
it is not yet active.

Changing screens (*DS3 and *DS4)  within a flow of screens will turn the 
background black, is my experience. 

I would keep the DSPSIZes in the same order on the file level of all DSPFs and 
condition the two DSPMODs with an opposite indicator on the record level.

Perhaps that helps.

Regards,
Carel Teijgeler


*********** REPLY SEPARATOR  ***********

On 8-12-05 at 11:04 Jon Sinner wrote:

>I am in a fight with 2 DSPF's that have been coded to handle both *DS3 and 
>*DS4.
>
>Basic program flow:
>
>I call program OP3100R  that has a DSPF  that is coded as a SFL in *DS4 
>format.  
>I then select an option that calls another program: OP3102R.
>This program utilizes a DSPF that is also a SFL  but is in a window and is 
>coded for both *DS3 and *DS4 format.  
>
>In the *INZSR of OP3102R, I execute a procedure: GETCOMPANY that is in service 
>program SRVPROMPT.  
>The DSPF for this procedure is also coded to use both *DS3 AND *DS4 Formats.  
>This procedure also executes the procedure: GETSCNSIZ  in service
>program SRVUTIL to determine which screen size to use.  It then presents a 
>subfile in a window.    
>
>The first screen from OPI3100R is displayed in *DS4 and the procedure 
>GETCOMPANY displays its window subfile in *DS4.
>
>I then select my enter from GETCOMPANY, close the DSPF and return to OPI3102R. 
> 
>I then execute the GETSCNSIZ procedure again to determine the screen size.  
>But is returns the value for *DS3.  Has anyone experienced this behavior and 
>if so have you found a solution?