SAVE SCREEN and RESTORE SCREEN commands

After talking with Ken Pouncey quite a bit it appears that to get the
enhanced 5250 protocol to work right I need to understand the SAVE SCREEN
and RESTORE SCREEN commands better.  I've got the docs right next to me
and have been pouring over them, but some things still aren't clear.

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 processing a SAVE SCREEN command, tn5250 calls several functions in
wtd.c that (afaict) do their own version of Write To Display.  Why write
to display?  The docs don't appear to suggest that a write to display is
required, unless I'm missing something (which is likely since the emulator
is clearly working).

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?

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?

When using the enhanced 5250 protocol, this is what I'm seeing:

I have an application which upon pressing an F key creates a window.  Upon
pressing another F key creates another window.  Then pressing a key
removes the second window.  Finally, pressing another f key removes the
first.  So the sequence is:

create window1 -> create window2 -> cancel window2 -> cancel window1

The trace shows this:

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

A thorough understanding of the above sequence of events is what I need to
make things work right.  The WTD after the first CLEAR UNIT is causing
problems since it doesn't create window1 the same way it did the first
time it was created.  What would work best is if the *only* thing the WTD
sent was window1 and not the whole screen.

Can anyone enlighten me?

James Rich

Vs lbh cynl n Zvpebfsg PQ  onpxjneqf, lbh pna urne fngnavp zrffntrf. Ohg
rira jbefr, vs lbh cynl vg sbejneq, vg vafgnyyf gurve fbsgjner!
        -- Fcbgvphf ba /.