[The following is 1.3.29B - haven't tried it on v2beta2]

Recall that we're using global.default as a pass through 
emulator, to avoid coding all screens.

Adding the TEREADYWHEN clause below - to skip extraneous buffers - seems to cause undesirable side effects: besides 
slowing down response a few seconds on a recognized screen,
any unrecognized (passthru!) screen takes an inordinate 
amount of time to flush to html ( - probably flushes on a 
time out? ) 

Is this because the default screen is now forced to
strictly recognize only the ones declared? 

And if so,then wouldn't using TEREADYWHEN on global.default 
be a contridiction; all unrecognized screens must be 
identified first? 

Or am I going about this the wrong way? Could a strict 
buffer count be used instead, or would that just result
in the same issue?

thanks,
- Howard

<TESECTION home>
           
    <TEACTION CONNECT "LU_GROUP_1">

    <TEREADYWHEN StrictRecognition
     
 

BTW, FixSampleCode needs fixing <G>
Here's the code:

<TESECTION home>
           
           <TEACTION CONNECT "LU_GROUP_1">

           <TEREADYWHEN StrictRecognition

              VTAM when Screen_4_66 IS "SERVICE"
              SystemB when Screen_1_2 IS "** WELCOME"
              SystemC when Screen_1_42 IS "CICS">

           <TEPUTSECTION DEFAULT>

</TESECTION>

If so, it really shouldn't slow things down, and usually tends to speed things up (unless you hit the timeout, when none of your criteria is met).

If the TEREADYWHEN applies to the first screen (welcome) displayed, than it can't be used, as it requires an active session to work...in this case you need to use a set of TECONNECTED tags, each including portions of the screen that are in the later buffers in a multi-screen/multi-buffer write.

We have the logs you sent of your screen dialogs, and think that what is probably the culprit is extraneous writes from SNA Server on the TN3270 outbound stream, which don't touch the screen buffer but bump the timer so you get the "sorry" message.

By the way, you can rid yourself of the "sorry" message while we try to fix this-- set the registry setting "SilentSynchErr" to "yes".

The intention is that the correct screen displays after
the user has either cleared or transistioned to a different
system. 

Have TECONNECTED's already as you mentioned. However, the
recognition text is almost exactly the same because these
are the screens that can appear on connect _and_ when we 
tranistion from system to system. I'll work with them
a bit more.

It is slower with tereadywhen on.

I've been scrutinizing these new the trace files - with and 
without the readywhen (1.3.29)  The results seem 
inconsistent: 

  VTAM sends 1 to 3 screens back - even when I stop, 
  restart, and repeat the same sequence for the same 
  region. ouch.

  Also, these traces seem to indicate that the recognition
  is not happening on exactly the screens I've told to
  recognize. (Wonder if I'm reading them wrong? I can send
  you two sets of traces, if you'd like.)

Hmmm, maybe both are caused by the 'extraneous writes from 
SNA Server'?  

Worse, I've tested
 

... some regions that are new to me - they are very ugly,
having screens that popup a second or two with a message
before settling on the final, expected screen.

Good then, it seems that the extranious SNA is one issue
and the recognition the other.

BTW it's set "SilentSynchErr" = 1

thanks

- Howard
the truncated poster