green screen restore display problem

Drew Dekreon

unread,

Jun 16, 2004, 2:23:30 PM6/16/04

to

(v4r5m0)
CL:
call pgm1 /* uses dummy record with ASSUME, puts up sfl window */
call pgm2 /* also uses dummy etc etc */

The problem is that the base screen is cleared after pgm1 ends - and I
don't know why and can't seem to prevent it.
I've tried mucking around with usrrstdsp in various places without success.
Adding a KEEP to the window sfl in pgm1 helps a bit, but I have both the
base screen and the pgm1 windows visible & overlayed by the pgm2 window.

What I want is the pgm2 window to simply overlay the original base screen.
What am I missing here?

gb

unread,

Jun 16, 2004, 10:32:13 PM6/16/04

to

RSTDSDP(*YES) on the pgm1 display file?

"Drew Dekreon" <drew_dekreonATchugachelectricDOTcom> wrote in message
news:10d1412...@corp.supernews.com...

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.705 / Virus Database: 461 - Release Date: 12/06/2004

walter

unread,

Jun 17, 2004, 1:48:02 AM6/17/04

to

Perhaps the RSTDSP option?

STRPDM -> DDS sources.
Usually you edit with option 17 and create during saving the file.
Do this instead: Save without create. Then option 14 F4 F9 thirs
parameter RSTDSP=*YES.
This is needed when you call from inside a program another one with
another display and then come back to the first pgm.

But actually I don't know if this works for your CL where pgm1 is
finished and then pgm2 starts. So I see nothing that makes the screen
display of pgm1 appear again after pgm2 is finished.

Walter

Brian

unread,

Jun 17, 2004, 1:46:28 PM6/17/04

to

Have you tried an explicit RMVWDW? In pgm1 you could write a mostly empty
record format that RMVWDW's pgm1's window.

Another option is to combine pgm1 and pgm2 record formats into one display
file. Use share(*yes) with the new display file so the open is shared
between pgm1 and pgm2. Now the pgm2 window can RMVWDW the pgm1 window.

"Drew Dekreon" <drew_dekreonATchugachelectricDOTcom> wrote in message
news:10d1412...@corp.supernews.com...

Drew Dekreon

unread,

Jun 18, 2004, 6:51:05 PM6/18/04

to

Just tried it -- rstdsp on pgm1, pgm2 left alone.
Result:
pgm1 overlays prior screen
screen blanked
pgm2 overlays blank screen

(tried adding rstdsp to pgm2 as well - I'm down to random trials now -
made no difference)

Drew Dekreon

unread,

Jun 18, 2004, 6:59:38 PM6/18/04

to

Actually, I tried compiling both screens with rstdsp.
The CL is called from a menu/command line, so the windows overlay the
existing menu.
As long as I only call one of them, pgm1 or pgm2, it overlays menu and
the menu reappears.
When I call pgm2 after pgm1, I get the screen going blank on pgm1 exit.

Drew Dekreon

unread,

Jun 18, 2004, 7:11:37 PM6/18/04

to

Added an RMVWDW to the window ctl record - no difference
Added a new window format specifying RMVWDW, wrote it at the end of pgm1
- no difference
Tried both with RSTDSP *yes & *no

The only thing that comes close is using KEEP on the window ctl. At
least I don't end up with a blank screen with window sitting in the
middle of it.

Tim M

unread,

Jun 20, 2004, 1:13:03 PM6/20/04

to

Use an *explicit* close in your program *OR* set on LR(if using RPG)

As long as you are using RSTDSP in any display file that is overlain
then this should do the trick

"Drew Dekreon" <drew_dekreonATchugachelectricDOTcom> wrote in message

news:10d6ser...@corp.supernews.com...

Drew Dekreon

unread,

Jun 21, 2004, 3:00:24 PM6/21/04

to

Thanks for your continued suggestions -
PGM1 uses IP (input primary) on the file, so LR is on when it ends
(data is subtotalled from IP file, then at lr time a subroutine is
called that exfmts the control record for the window sfl)

The really odd thing about all this is that the CL originally just
called PGM2 and everything worked fine: the window overlaid whatever was
on the screen and the screen was restored when it finished.
I simply added a called to PGM1 before PGM2 in the CL.

If I call either pgm1 or 2 directly from the command line it correctly
overlays the current display and restores it. The problem only comes up
when the CL calls them in succession.

Saml

unread,

Jun 21, 2004, 9:48:20 PM6/21/04

to

Here's what I have in the second display file in an application where I was
losing the original display. Not sure if it is the same situation as yours.
I have a full screen display, which pops up a subfile window on top of it.
The window can pop up a second window. When I exited the second window, the
full screen display blanked leaving only the first window on the screen.
Coding this in the second display worked.

A*=== PREVKEEP ==================================================
A* WRITE this format just before the display file is closed to
A* avoid erasing the underlying dispay in some cases while
A* processing through a subfile.
A R PREVKEEP CLRL(*NO)
A FRCDTA
A OVERLAY

I got this from a coworker, who got it from a previous job, so neither of us
claim rights to it. At the time I did it, I looked at the keywords and I
think I figured out why it worked. Now, without looking at the keyswords, I
not sure I understand it.

Sam

"Drew Dekreon" <drew_dekreonATchugachelectricDOTcom> wrote in message

news:10d6tlb...@corp.supernews.com...

Drew Dekreon

unread,

Jun 23, 2004, 8:39:45 PM6/23/04

to

Really interesting - you're basically writing an empty, transparent
screen on top of the original application screen.
I'm going to test this out tomorrow. It might work by fooling the
workstation subsystem by adding another window to the stack. I think it
is erroneously popping one extra saved window off the stack, leaving the
terminal blank. Your idea pushs an extra duplicate screen onto the stack..