|
Short Description
|
Response time limit from mainframe?
|
|
Entered
|
By:
Michael - Charleston
When: 1998-12-29 11:24:49 Build: 1.03.07A
|
|
Categories
|
Type:
Question
Department: Product
Category:
Troubleshooting
|
Description
|
Our users are encountering a troublesome situation. It seems that if a search on the mainframe takes longer than 5-10 seconds, Screensurfer decides to simply re-display the current page. For example, if you go to the CIVIL CASE SEARCH section of our site and do a "Search by Filing Date" from "Jan 01 1997" to "Jan 01 1998" on filing code "Wrongful Death", the screen will just re-display after a few seconds. And this is verified by checking the "DevInfo" for the session from the Admin Console. However, wait 10 seconds and re-check the "DevInfo" for that session again and it shows the mainframe screen has returned with several results (although, of course this does not show up in the browser).
What do we do about this?
|
|
|
|
Append
|
By: WindSurfer When: 1998-12-29 11:44:49 New Status:
Pending Customer
|
|
Comment
|
This sounds like a screen transition tuning issue.
Can you please reproduce this on the test server in diagnostic mode and one user, then send the surfdiag.log file to surfer@ieinc.com.
Essentially, if the mainframe is writing an initial buffer, then the final one, the "HostSettleTime" setting will frequently prevent the display of the initial screen because the second one comes within the hostsettletime window (default 1/10 second).
You may want to see if the <TEREADYWHEN StrictRecognition ...> tag can be executed on the primary search screen to assure that the search results are ready before transitioning the screen. This tag will prime the screen transition logic to only succeed when certain screen criteria exist. You can also look into TEREADYWHEN StrictBufferCount since this may be easier and quicker...this sounds like it should be count=2 as a setting if there is always two complete buffers written after a search.
|
|
|
|
Append
|
By: WindSurfer When: 1998-12-29 14:51:16 New Status:
Pending Customer
|
|
Comment
|
How's your screen transition progress? I noticed that one of the tags in our first response wasn't escaped properly, so it wasn't reading as it should-- TEREADYWHEN StrictRecognition was the tag that was hidden by not having the leading lessthan escaped.
One other thing to understand on the TEREADYWHEN is that it is temporary, and stays around until the next screen transition only.
When using TEREADYWHEN StrictRecognition, the screen recognition criteria you put-in is totally independent of existing screen event-driven TESECTIONS, and only apply to the active transition, so you can do anything you want, such as wait for a particular screen section to be blank, have one word in it, or whatever.
For your search screen, which probably can have so many different result screens, you can also have many, many criteria groups in one TEREADYWHEN if need be.
|
|
|
|
Append
|
By: Michael - Charleston When: 1998-12-29 15:28:51 New Status:
Pending IE
|
|
Comment
|
I tried using TEREADYWHEN StrictRecognition but that didn't seem to get me anywhere. Not sure about the StrictBufferCount since the Cobol programmer I work with informed me that the 3270 does not write to a buffer, but to a temporary storage area ...
I was able to re-produce in diagnostic mode and am sending you the surfdiag.log file in an email.
|
|
|
|
Append
|
By: WindSurfer When: 1998-12-29 15:32:47 New Status:
Pending Customer
|
|
Comment
|
I'll check the log file when it comes-in. What happened with the strictrecognition? Did it still transition prematurely, or did it then go 20 seconds (a timeout)? If it transitioned prematurely, it means that one of the criteria you used was satisfied by the intermediate screen.
Strictbuffercount isn't related necessarily to anything being done on the host-- it may be needed to deal with the TN3270 gateway, as sometimes a TN3270 process introduces extra 3270 datastream writes (buffers) which can trick the screen transition logic in Screensurfer.
|
|
|
|
Append
|
By: Michael - Charleston When: 1998-12-30 09:25:39 New Status:
Pending IE
|
|
Comment
|
Ho, ho, ho, the TESET Screen.TimeOut=120000 worked! Actually, it originally was about 5-10 seconds, the TEREADYWHEN got it up to 20 seconds, but this Screen.Timeout did the trick. Is there a way to set this globally through regedit? Or if I just place this statement in the logon template will this set Screen.TimeOut for the rest of the user's session?
|
|
|
|
Append
|
By: WindSurfer When: 1998-12-30 09:35:14 New Status:
Pending Customer
|
|
Comment
|
Good news-- but be careful about this solving everything, because the TEREADYWHEN wouldn't change the timeout from 5-10 to 20...since the TEREADYWHEN works inside the protocol handler, while the 20 seconds is used in the HTTP thread.
So, may still need TEREADYWHEN for certain search types, if they involve extra buffers...
The screen.timeout can be set in the logon template and will remain active until the 3270 session is finished, as this is a session-specific setting that is initialized when the session is started, then is read/write as a variable in expressions.
|
|
|
|
Append
|
By: Michael - Charleston When: 1998-12-30 11:38:08 New Status:
Pending IE
|
|
Comment
|
Is there a way to have a pop-up message appear if the search goes longer than 2 minutes?
|
|
|
|
Append
|
By: WindSurfer When: 1998-12-30 21:37:46 New Status:
Accepted
|
|
Comment
|
Great idea, but not one we had before (oh well, can't think of everything...).
Will put the status of this ticket as accepted, with the addition of a global.hosttimeout section which is activated anytime there is a screen transition that fails due to a timeout based on the active screen.timeout setting...as an addition, can add a TEEVENT HOSTTIMEOUT section, too.
|
|
|
|
Append
|
By: Michael - Charleston When: 1998-12-31 08:39:19 New Status:
Closed
|
|
Comment
|
Sounds good - thanks!
|