Re: SAVE SCREEN and RESTORE SCREEN commands

> When a SAVE SCREEN is issued, who does the saving?  The 5250 client, or
> the as/400?  It appears that the AS/400 is supposed to do the save and the
> 5250 client is supposed to send the contents of the screen to it.  That
> seems kind of odd since I would have thought the AS/400 already knows
> whats on the screen - it sent the screen to us afterall.

When the AS/400 sends us a SAVE SCREEN operation, all of the data that we
have for the screen is sent back to the AS/400.  The AS/400 saves that
data somewhere.

Then, when a RESTORE SCREEN is issued, it's followed by the data that we
sent it, allowing us to completely restore the screen to back to what it
was.

I think the main reason this was done is that a "real" 5250 terminal
doesn't have memory that it can save a screen into -- so it stores it in
the AS/400's memory.

The way that lib5250 implements this process is that it generates an
actual 5250 data stream that can be used to reproduce the screen.  That
data is sent to the AS/400 in response to SAVE SCREEN.  When the RESTORE
SCREEN is issued, that same 5250 data stream is sent back to us, and we
interpret it like any other 5250 data stream that we receive.


> Are GUI elements (such as scrollbars) sent as part of the SAVE SCREEN
> command?  The docs don't really say that I can tell.  What about windows?
> If a window created with the CREATE WINDOW structured field exists and a
> SAVE SCREEN is issued, should the whole screen (non-window parts and
> window) be sent or just the window?

Are you asking if they ARE, or if they SHOULD BE?!  I don't know if they
are, since I have only lightly skimmed your patches. But, I would
certainly think that they should be. You should be re-generating all of
the 5250 codes needed to bring the screen back to the state that it was
in.

> When a RESTORE SCREEN command is issued, where does the data to restore
> come from, the 5250 client or the AS/400?  tn5250 ignores the RESTORE
> SCREEN command and says that a valid WTD is upcoming.  Does the AS/400
> generate this WTD or is it the stuff done in wtd.c?

Yes, it's coming from the AS/400, but what it's sending is the data that
lib5250 generated earlier when it responded to the SAVE SCREEN command.
And yes, wtd.c is where a lot of that code generation takes place.


> SAVE SCREEN
> create window SF
> SAVE SCREEN
> create window SF
> RESTORE SCREEN
> CLEAR UNIT
> WTD of previous screen (unfortunately not quite the way I need it)
> RESTORE SCREEN
> CLEAR UNIT
> WTD of previous screen

I suspect that the problem is that when you added the window code to
lib5250, you did not add it to wtd.c, so that it doesn't get sent in
response to SAVE SCREEN -- and therefore doesn't get sent back in response
to RESTORE SCREEN.

It should NOT only send one window... it needs to send the ENTIRE screen
(unless you want to break other things!!)

The CLEAR UNIT and WTD are part of what we send in the SAVE SCREEN
operation, and therefore we get them back during the RESTORE SCREEN
operation.

I don't know how else to explain it.