> 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.