EnterpriseLink Server uses timeout configuration settings to decide how much time to wait between responses from the host system and when connecting and disconnecting from the host system. These can be found under http://localhost/stadmin - > Configuration - > EnterpriseLink Server. Here is an explanation of these settings:

Session Timeout

Specify a value in seconds that represents the amount of time that a browser must be idle before the session is disconnected by EnterpriseLink. The default is 1800 seconds (30 minutes).

New Page Timeout

Specify a value in seconds that represents the maximum amount of time EnterpriseLink Server waits when connecting to a host for the first time. If the host responds earlier than the given value, the screen is translated into the page and the page is sent to the browser. This is also the timeout used when waiting for the host to respond after data has been sent to it (submitted on the web page). The default is 30 seconds.

New Screen Timeout

Specify a value in milliseconds that represents the maximum amount of time EnterpriseLink Server waits between network packets that make up a screen. Sometimes, the host sends multiple screens that are combined together to make a composite screen. For example, first the screen format and then the data is sent immediately after. The New Screen Timeout value ensures that the entire composite screen is received before being converted to a web page. The default is 1500 milliseconds (1.5 seconds) and represents the maximum amount of time to wait between network packets. The actual wait time may be shorter when a packet matching a screen captured in the Repository is received. However, if that screen matches the previous screen (a common case), the timeout is still used and the message "Current and previous screen names are the same (HostScreenxxxx); wait for more data streams to ensure a screen change won't occur" is displayed in the Server.log with log level 4 set. This behavior can be eliminated by checking the Do Not Wait If Same Screen sub-option (see below). Another common case is that host systems often send multiple packets consisting of blank screens. The message "Blank input or blank output-only screen detected (HostScreenxxxx); wait for more data streams in the event of a slow system." is logged in Server.log in this case. If this causes too many delays because the blank screen often appears in your application, the behavior can be eliminated by checking the Do Not Wait If Blank Screen sub-option (see below).

Keyboard Lock Timeout

Specify a value in seconds that represents the amount of time EnterpriseLink Server waits before generating a Web page if the host screen contains an indication to lock the keyboard. The default is 10 seconds. For host applications that use the keyboard lock to indicate an error, set the value to fewer than 10 seconds so that the user does not have to wait to see that an error has occurred.

Do Not Wait If

The 3270 datastream is non-deterministic. There is no termination condition. Some mainframe applications will build up a 3270 screen by sending multiple partial screens back-to-back.

EnterpriseLink Server heuristics have built over time to determine when we need to wait for more screen data. The worst thing is firing on a match when there is more data that is likely to come in later asynchronous packets. But, many applications are built very synchronously. Often the only asynchronous behavior is when the SSCP logon screen hands off to CICS or when CICS hands off to the first menu screen. It is most safe to uncheck most of these options on the EnterpriseLink Server configuration page, but you can try to check some of them to see if they speed up matching correct screens. Here's a description of these sub options:

• Same Screen – We’ve seen (usually broken) host applications send a “no op” packet right after the user sends data to the screen, this appears as the same screen to be quickly followed up by the “real next screen.” If we didn’t have the default behavior to wait in this case we would display the same page prematurely
• Blank Screen – This occurs usually on the handoff from the subsystem control program to CICS or when one mainframe LPAR controlling the communication hands off to a different LPAR that runs the CICS app for that region. You see this if the first customer screen is “choose your country” or in the DLA case “choose the 1 of 12 warehouses”. So, it’s the SSCP that clears the screen then turns control over to CICS to write it. If we didn’t wait we would display the page build on the empty screen.
• Undefined Screen – This is the typical behavior, if we can’t find a match wait 1500ms hoping to get more data to match
• No Transitions – Most screens have a transition recorded for them – some sort of PF or ENTER key data that is used to advance to another screen. If there are no transitions recorded then that sometimes means that the user didn’t press anything between screens, so we at run-time we wait for that second packet to arrive. This is common in CICS applications that have their screens divided into a “customer header” part at the top and an “order detail” at the bottom. There are two different transactions that write the different parts of the screen. But, if you know this isn’t the case in the host app you can check (turn off) this heuristic.
• Null Transition – Are recorded in the repository as a from and to screen but with no data entry or AID key press event. This almost certainly means two screens follow in rapid succession so you should wait.

The checkboxes on this configuration page allow you to disable the default behavior of waiting New Screen Timeout amount of time in these situations. Most customers do not check any of these boxes. But, if an second-and-a-half delay is regularly encountered between two web pages you can either reduce the timeout setting or trying checking one or more of these boxes to remove the delay.