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