        |  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
3270 Connect User's Guide
CHAPTER 5
This section discusses certain features available in the 3270 Connect designed to maximize performance of deployed services.
The overall performance of any service that uses back-end connectivity is usually dependent on the time it takes to establish a connection and begin interacting with the host. Obtaining the connection is "expensive" in terms of wait time. One strategy for dealing with this is connection pooling, a scheme whereby an intermediary process (whether the app server itself, or some memory-resident background process not associated with the server) maintains a set number of preestablished, pre-authenticated connections, and oversees the "sharing out" of these connections among client apps or end users.
Connection pooling overcomes the latency involved in opening a connection and authenticating to a host. But in terminal-based applications, a considerable amount of time can be spent "drilling down" through menu selections and navigating setup screens in order to get to the first bonafide application screen of the session. So even when connections are reused through pooling, session-prolog overhead can be a serious obstacle to performance.
Composer addresses these issues by providing connection pooling, managed by a special kind of component (called a logon component) that can maintain an open connection at a particular "drill-down" point in a terminal session, so that clients can begin transactions immediately at the proper point in the session.
Logon Components are useful in several types of situations:
When you have a need for multiple tiers of pooling based on multiple security challenges within your system. (For example, users may need one set of logon credentials to get into the network, another to get into the mainframe, and another to get into the CICS region.) Serial log-in requirements may dictate the use of multiple logon components.
When your service needs stateful "session-based" connections.
When you need the performance advantages available through connection pooling.
If performance under load is not a high-priority issue and your connectivity needs are relatively uncomplicated, you may not need to use Logon Components at all. But there is no way to know if performance is adequate merely by testing services at design time, on a desktop machine.
Components and services built with the 3270 Component Editor may appear to execute quickly at design time (in Animation Mode, for example). But in real-world conditions—which is to say under load, with dozens or even hundreds of requests per second arriving at the server—session overhead can be a significant factor in overall transaction time. The only way to know whether you need to use the special performance enhancement features described in this chapter is to do load testing on a server, under test conditions that mimic real-world "worst case" conditions.
When you install the 3270 Terminal Connect, three types of Connection Resources are added to Composer's Connection Resource wizard:
The TN3270 and EPI connections are true terminal connections that establish a session with a host system (e.g., a VTAM host—a system that supports the Virtual Telecommunications Access Method).
The TN3270 and EPI 3270 connection resources are designed to make individual connections to the host on an as-needed basis. The connection is made just-in-time and discarded as soon as the client is done. It is not reused in any way.
The Logon Connection, on the other hand, is different. It defines a pool of User IDs and passwords, each of which can make its own connection (TN3270 or EPI). The Logon Connection also serves as an indirection layer to allow clients to connect to the host at exactly the point in the host program (exactly the screen) where the client needs to start. This entry-point-location behavior is made possible by the Logon Component. (A Logon Connection always uses a Logon Component to get to the actual connection.) The architecture is shown in the graphic below.
A Connection Resource is always required in order to get to the host. (This is true for any Composer service that uses 3270 components.) For simplicity, this diagram shows the Connection Resource going directly to the host; in the real world, there may be intervening delegation layers involving VTAM.
The Logon Component contains Actions (an action model) designed to find a particular screen of interest in the host program. This drill-down location is the effective entry point of the transaction for any upstream process that uses this Logon Component. You can think of the Logon Component as a go-between between the physical connection (represented by the Connection Resource) and the logic layer (represented by the 3270 Component itself.
In order for a 3270 Component (at the top of the diagram) to use a Logon Component, it needs to enlist the aid of a Logon Connection resource. The Logon Connection is the bridge between the 3270 Component and the Logon Component.
The kinds and responsibilities of the various objects discussed above are summarized in the following table.
The Logon Connection differs from the ordinary "host-direct" connection resource in that it manages pooling (the sharing of connection instances and Logon Component instances at runtime).
In the context of a Composer service, pooling not only allows reuse of (open) connections at runtime, it also increases the effective bandwidth of a deployed service. Consider the simple case where you've designed a 3270 component that uses a regular connection resource. In creating the connection resource, you will have specified a UserID and password for the resource to use so that at runtime, the component can log in to the host. When an actual running instance of your component is using that connection, no other instance of the component can log in to the host using that same set of credentials. The bandwidth of your service is limited to one connected instance at a time.
With a Logon Connection, on the other hand, numerous host connections can be maintained in a "live" state so that multiple instances of your component can access the host (each on its own connection) without waiting. Throughput is dramatically increased.
The diagram below shows one possible runtime case where three component instances (two instance of 3270 Terminal Component A and one instance of 3270 Terminal Component B) are executing on the server. Instance 1 of Component A is using UserID `E' to obtain a connection. This component has its own dedicated instances of Logon Component M and Connection S.
Terminal Component B has just finished executing and is relinquishing its connection (established through credentials defined by UID `F'). Note that because connection pooling is in effect, Component B's downstream resources (its Logon Component instance, M2, and its Connection instance, S2) are not simply discarded; they remain live. As a result, Terminal Component A2 is able to obtain (reuse) the M2/S2 resource instances that were previously held byTerminal Component B.
In this diagram, Logon Connection D is associated with four connections based on four UIDs (user IDs or credentials: A-thru-F). One is in use; another (UID `F') is alive but not being used; and two are inactive but available (i.e., valid UIDs have been assigned, so these two connections can be made live at any time).
It's possible for several different 3270 components to draw from the same connection pool. It's also possible for different components to draw from different pools. This means different Logon Connections.
An important factor in deciding how many Logon Connection resources (in effect, how many pools) your service needs is the number of different start screens (or entry point screens) needed by the various components in your project. Suppose Terminal Component A needs to begin its work at a particular starting screen in a host application, but you've also designed another component—Terminal Component B—that needs to start on a different screen. Components A and B will need separate Logon Connections, and the separate Logon Connections will point to separate Logon Components. (In any given connection pool, Composer objects are shared in such a way that every user of the pool must start at the same screen.)
The combination of a Logon Connection, a Logon Component, and its Connection Resource form the basis of a connection pool. Starting from the host or VTAM layer and working up the chain:
The Connection Resource defines the most basic parameters necessary for establishing a connection with the VTAM host. When connection pooling is in effect, runtime instances of this object are kept alive and reused.
The Logon Component defines the set of steps (actions) necessary to get to a particular entry point in the host program. (At runtime, an instance of this component will actually carry out those steps in order to arrive at, and maintain ready-to-use, a particular screen location in the host program.) When connection pooling is in effect, instances of this object are kept alive and reused.
The Logon Connection is a special type of resource that contains all the information needed to define a connection pool. This resource is designed to encapsulate pool-management info and does not establish host connections directly; instead, it delegates those responsibilities to the Logon Component (which delegates them, in turn, to the appropriate Connection Resource).
To create the various objects required for pooling, you'll go through the following basic steps (each of which will be discussed in greater detail in the sections to follow):
First, you'll create a basic connection resource. The resource will be one of:
Next, you'll create a Logon Component that uses the connection resource defined in Step 1. As part of this process, you'll create an action model designed to navigate to a certain point in the host program.
You will create a Logon Connection resource, which is a specialized type of connection resource that relies on a Logon Component (from Step 2) to make the basic connection (through the resource defined in Step 1).
Finally, you'll create a 3720 Terminal Component and associate it with the Logon Connection resource of Step 3.
These steps are described in detail starting with the discussion at "Creating a Connection Pool" further below. Before going to that section, however, you should become familiar with the design principles behind the Logon Component (and also the Logon Connection). We'll start with the Logon Component, since it's impossible to create a Logon Connection without using a Logon Component.
The Logon Component is a special type of component: It has an Action Model, yet can be used as a connection resource as well. The Action Model of this type of component is designed to manage a connection that will be used by multiple 3270 Terminal Components. In most respects, the Logon Component is the same as a 3270 Terminal component. The differences are:
In a Logon Component, the Action Model is organized around connection-management tasks. Those tasks are implemented via special actions: the Logon Action, KeepAlive Action, and Logoff Action.
A Logon Component is not invoked directly by another component or service. Its invocation is under the control of a Logon Connection.
NOTE: A Logon Component must and can only be used in conjunction with a Logon Connection.
Instead of calling the Logon Component directly, using (for example) a Component Action, you will associate the Logon Component with a special connection resource called a Logon Connection. When your 3270 Terminal Component executes, it executes via the Logon Connection, which in turn executes the Logon Component.
The Logon Component provides several screen-management capabilities that are important factors in overall performance. These capabilities are implemented in terms of Logon, Keep Alive, and Logoff actions:
Logon Actions—These actions navigate through the host environment and park at a desired launch screen in the host system. The connection is activated using UserIDs from the pool. The 3270 Terminal components that subsequently reuse the connection have the performance benefit of already being at the launch screen and won't incur the overhead of navigating to the launch screen as if they had come in under their own new session.
Keep Alive Actions—These actions do two important tasks. First, they prevent the host from dropping a connection if it is not used within a standard timeout period defined by the host. Second, these actions must insure that the connection is always positioned at the "launch screen in the host, even after performing the Keep Alive actions needed to prevent the connection from dropping (the first important task).
Logoff Actions—These actions exit the host environment in a manner you prescribe for all the connections made by User IDs from the pool, when a connection is being terminated.
These actions and their meanings will be discussed in greater detail below. For now, it's enough to know that these three action groupings are created for you automatically when you first create a Logon Component. Note the (empty) Logon, Keep Alive, and Logoff action blocks in the action model shown below:
Actions you place in the Logon group are primarily concerned with signing into the host security screen and then navigating through the host menu system to a launch screen where each 3270 Terminal component's Action Model will start. It is important that any 3270 Terminal component using a Logon component be able to start execution at the same common screen. Otherwise, the performance gains of avoiding navigation overhead won't be realized and more importantly, the odd 3270 terminal component won't work.
You can create actions under the Logon Actions block the same way as you would in an ordinary 3270 Terminal Component—namely by using the Record feature to create (in real time) whatever actions are necessary in order to enter sign-on info such as User ID and Password (as well as your initial menu choices to arrive at the launch screen).
NOTE: Remember to use the User IDs and Passwords from the Logon Connection Pool. (See the discussion at "Creating a Logon Connection using a Pool Connection" below.) To do this, you need to map the two special system variables called USERID and PASSWORD to the appropriate fields on the screen. By specifying these two variables, you make it possible for exteNd Composer to automatically locate and use values from the next active and free Pool slot.
The launch screen is a common point of execution for all the 3270 Terminal Components that use the User ID pool provided by a Logon Connection. The Logon actions in a Logon Component (which are executed only once when a new connection is established) let the calling component—your 3270 Terminal Component—begin execution at a given screen in the host program.
The Logon Actions must be structured properly and therefore always begin and end with a Map Screen Action as shown in the screen below.
The final Map Screen action in the Logon block guarantees that control is not turned over to the 3270 Component before the screen of interest has arrived in the connection. Without this, the 3270 Component could start at an invalid screen, throw an exception, and possibly corrupt a transaction. It is not necessary for the Map Screen to contain any actions, per se, but it is critical that the Map Screen prevents control being passed to the 3270 Component prematurely. It also performs a field count check on the screen when it arrives to make sure it is the same screen captured during the initial recording session.
NOTE: You may notice when animating a Logon Component that the ending Map Screen is skipped. This is normal design-time behavior. In a production environment , the actions in a Logon Component always execute in an interleaved manner with a 3270 Terminal component. Animating a Logon Component from start to finish actually creates an abnormal sequence of events that would result in two Map Screens being processed in succession, which is not allowed.
The performance benefit comes into play as a result not only of connection reuse but launch-screen reuse. For example, if a User ID pool of three entries is fully used and (ultimately) reused by the execution of a component fifteen times, the overhead of navigating to a menu item that executes the transaction of interest will occuro nly three times. Likewise, there will only be three logons to the host because the Logon actions at the top of a Logon Component are executed only once—when a new connection is activated (not when it is reused). This is key to obtaining maximum performance in a high-transaction-volume production settings.
NOTE: When possible, use the Try/On Error action to trap potential logon errors that may be recoverable. Otherwise, the UserID trying to establish the failed logon will be discarded from the pool, decreasing the potential pool size. The pool size will remain smaller until you manually reset the discarded connections using the exteNd Composer Enterprise Server Console for 3270. See Managing Pools Sections in this Chapter for more details.
The Keep Alive block is where you will place actions that "ping the host" in whatever way necessary to keep the connection alive so that it can be reused.
Keep Alive actions usually involve sending an AID key, such as <ENTER>, to the host at some specified interval. However, if after sending the AID key the screen changes to some screen that is different than the launch screen, you must be sure to return the Logon Component to the launch screen in the Keep Alive section. Failure to do so will leave the next component at an incorrect screen, causing it to fail.
The Pool Info dialog of the Logon Connection setup dialog (see discussion at "Creating a Logon Connection using a Pool Connection" below) is where you control how often the Keep Alive actions will execute. If you specify in your Logon Connection pool that you would like to keep a free connection active for three minutes, but the host will normally drop a connection after two minutes of inactivity, you can specify keyboard actions to take place at 30-second intervals to let the host know the connection is still active.
Keep Alive actions will be executed multiple times, at intervals defined by the Keep Alive parameter defined on the Pool Info dialog of the Logon Connection.
The Inactivity Lifetime parameter (just below Keep Alive on the Pool Info dialog) tells Composer how long it should wait, in the event the connection is not actually used by a 3270 Terminal Component, before relinquishing the connection.
NOTE: The execution of the Keep Alive actions of a Logon Component will not cause the Inactivity Lifetime clock to reset in the Logon Connection. Only a 3270 Terminal component's execution will reset the Inactivity Lifetime. In other words, if a live connection is never actually used (but is merely kept alive by "Keep Alive" actions), then it will time out according to the Inactivity Lifetime value in the Pool Info dialog. But if the connection is used (by a 3270 component) before it times out, the timer is reset at that point.
The last action inside a Keep Alive block should be an empty but "enabled" navigation action. If a user disables this last action, animation will not work properly due to two consecutive empty navigation actions occurring. For example, if an action in Logon and the first action in Keep Alive are disabled, an error occurs.
Map Screen actions must occur at the beginning and end of the Keep Alive section.
Not only must the Keep Alive section prevent the connection from closing, but it must make sure that the proper launch screen is present when the execution is completed. Therefore, the first Map Screen checks to make sure that during the time the connection was available but not in use, an unexpected screen didn't arrive from the host. The ending Map Screen prevents the premature release of the connection to the next 3270 Component. See below for a typical Keep Alive block.
Logoff actions essentially navigate the User ID properly out of the host system after a timeout.
Logoff actions execute once for a given connection, and only when a connection times out (i.e. the Inactivity Lifetime expires) or the connection is closed via the 3270 Server console.
In a "best practices" sense, it's vitally important to make Logoff Actions bulletproof. If an exception occurs during execution of the Logoff actions, exteNd Composer will break its connection with the host, freeing the UserID in the pool. But the UserID may still be active on the host. Until the host kills the UserID (from inactivity), a subsequent attempt by the pool to log on with that UserID may fail, unless you've coded your logon to handle the situation. Logon failures cause the UserID to be discarded from the pool, reducing the potential pool size and performance overall. As with Logon and Keep Alive actions, the way to guarantee you are on the proper screen at the end of the logoff is to end with a Map Screen.
Each time a User ID is activated from the Logon Connection Pool, an instance of the corresponding Logon Component is created and associated with that User ID. Then the Logon actions are executed until the desired launch screen is reached. At this point the 3270 Terminal component execution begins. When it is finished another 3270 Terminal component using the same Logon Connection may begin executing, starting at the same launch screen.
If no other component requests the connection, then the connection-instance in question enters an active but free state (an "idle state") defined by the Inactivity Lifetime and KeepAlive settings on the Pool Info dialog of the Logon Connection. If the Keep Alive period (e.g., 2 minutes) is shorter than the Inactivity Lifetime (e.g., 120 minutes), then at appropriate (2-minute) intervals, the Keep Alive actions will be executed, preventing a host timeout and dropped connection; and the Keep Alive Period begins anew.
A Logon Component's execution lifetime is dependent on the activity of the Logon Connection that uses it. As long as one entry in the Logon Connection pool is active, then one instance of the Logon Component will be in memory in a live state. A Logon Component instance will go out of scope (cease executing) when the last remaining pool entry expires due to inactivity. The only other way to stop execution of a Logon Component is through the 3270 Console on the Server.
The Logon Connection is not a true connection object like a TN3270 Connection Resource, but a pointer to a Logon Component (which in turn connects to a host either through a conventional Connection Resource or yet more intervening Logon Connection/Logon Component pairs). The Logon Connection encapsulates information needed to describe a pool of connections. That includes User IDs and passwords, plus pool settings involving the time interval between retries on discarded connections, etc. Another function of the Logon Connection is that it ensures the use of different instances of the same Logon Component for all the User IDs for which connections are made.
The dialogs you'll use in setting up a pool of User IDs for a Logon Connection are shown in the following set of illustrations. Arrows denote the buttons that lead to continuation dialogs.
Every Logon Connection is associated with a given Logon Component. In addition, the Logon Connection provides the following User ID pool functionality:
It allows the specification of multiple User IDs in advance ensuring that clients are able to secure a connection when one is needed
It allows the reuse of a User ID/connection once it is established to eliminate repeated user authentications and disconnects
It allows a single User ID to use multiple connections if this is supported by the host system
It keeps a connection active to prevent host timeouts during inactive periods
It lets you specify when to remove a connection from the active pool
It sets a timeout period to use for a fully active pool to provide a free connection
It lets you specify error handling dependent on the state of the Logon Component used by the Logon Connection
In order for multiple instances of a 3270 Terminal component or different 3270 Terminal components to use a the same Logon Connection, the following conditions must be met:
All the 3270 Terminal components must use the same Connection Resource (thereby sharing the TN3270 Host, Port and data encoding parameters or EPI 3270 connection Gateway and Server parameters)
All the 3270 Terminal components must have a common launch screen in the host system from which they can begin execution (see "About the 3270 Logon Component" below for more detail).
If your host system security supports multiple logins from a single user ID, you may have circumstances where you wish to pool the single User ID. This can be accomplished by performing the following steps:
Specify a User ID/Password in the Connection Resource used by the Logon Component.
On the Pool Info dialog of the Logon Connection, specify a Pool Size greater than 1.
Do NOT check the Override the UID/PWD setting in the Pool Info dialog of the logon Connection.
These steps will cause each pool slot to use the User ID and Password contained in the Connection object and not use the user IDs from the pool.
When creating a 3270 Terminal component, you normally first create the Connection object it needs. Similarly, when creating the objects comprising a Connection Pool, you must create certain objects first, starting (in essence) at the host and working your way backwards to the 3270 Terminal Component that will access the host.
A typical sequence of steps for creating a Connection Pool is:
This step is simple. Create a new Connection Resource (TN3270 or EPI) as described in Chapter 2 of this Guide. Even though you will be using User IDs and Passwords defined in the Logon Connection later, you should still define one in the Connection as well. This will be needed when you define the Logon Component in the next step. Alternatively, you can simply use an existing Connection Resource.
To create a 3270 Logon Component:
From the Composer File menu, select New> xObject, then select the Component tab and choose 3270 Logon.
Click Finish and the Logon Component Editor appears.
NOTE: Recording actions follows a series of steps. The cursor must be positioned over Logon, turn record on, when you are done, turn Record off. Position the cursor to Keep Alive, turn Record on, when you are done, turn Record off. Position the cursor to Logoff, turn record on, when you are done, turn record off.
Record Logon Actions for logging into the host and navigating to the launch screen using the same Recording techniques described in Chapter 4 of this Guide.
Edit the Logon Map actions that enter a User ID and Password to instead use the special USERID and PASSWORD variables described in the section titled "3270 Specific Expression Builder Extensions" in Chapter 4 of this Guide.
Create the needed SEND Key actions in the Keep Alive section of the Action Model (a quick way is to copy an existing SEND key action, Paste it, and then modify the key code sent).
To create a 3270 Logon Connection:
From the Composer File menu, select New> xObject, then open the Resource tab and select Connection, or you can click on the icon. The Header Info panel of the New xObject Wizard appears.
For the Connection Type select "3270 Logon Connection" from the drop down list.
In the Connect Via control, select the Logon Component you just created.
Click on the Pool Info button and the Pool Info dialog appears.
Enter a Pool Size number. This represents the total number of connections you wish to make available in this pool. For each connection, you will be expected to supply a UserID/Password combination later.
Enter a KeepAlive time period. This number represents (in minutes) how often you wish to execute the Keep Alive actions in the associated Logon Component whenever the connection is active but free (i.e. not being used by a 3270 Terminal component). The number you enter here should be less than the Timeout period defined on the host for an inactive connection.
Enter an Inactivity Lifetime. This number represents (in minutes) how long you wish to keep an active free connection available before closing out the connection and returning it to the inactive portion of the connection pool. Remember, that once the connection is returned to its inactive state in the pool, it will incur the overhead of logging in and navigating host screens when it is re-activated.
Enter an Entry Wait time in seconds. This time represents how long a 3270 Terminal component will wait for a free connection when all the pool entries are active and in use. If this time period is reached, an Exception will be thrown to the Application Server.
Checking Override UID/PWD means you wish to specify User ID/Password combinations for use in the connection pool. When checked, this activates the Set USERIDs button. Click on the button to display the Set USERIDs and PASSWORDS dialog.
On the Toolbar there are three icons: Add which adds an empty row, Delete, which deletes a highlighted row and Paste which allows you to copy/paste information from a spreadsheet into the table.
NOTE: Alternate and faster ways to enter data are to copy data from a spread sheet and paste it into the table. Make sure your selection contains two columns. The first column must contain UserID; the second Password. Open the spreadsheet, copy the two columns and as many rows as needed. Open the table and immediately press the Paste icon located on the toolbar. You can also copy data from tables in a Microsoft Word® document using the same technique.
Enter as many USERID/PASSWORD combinations needed, until you reach the size of the pool you specified, then click OK. (If you enter more, then the pool size will automatically adjust to the new size.)
Click OK to dismiss the "Set User IDs and Passwords" dialog and return to the Pool Info dialog.
Optionally check the Pool Resource Names checkbox in the Pool Info dialog, if you are using 3270E (extended protocol) and intend to manage terminals by identifier strings. (Checking the checkbox will enable the Set Device Names... button. Click the button to bring up the "Set Resource Names" dialog. Then enter terminal IDs in the dialog and click OK.)
Optionally click the Use Sequential Connections checkbox if you want Composer to establish connections in the same order that User IDs were listed in the "Set User IDs and Passwords" dialog. Connections will be made in numerical sequence.
In the Retry discarded after field, enter a value representing the number of minutes to wait between connection retries (attempts to reestablish a connection).
In the Max retry discarded field, enter a value representing the number of connection attempts to try before giving up (which means permanently discarding the connection).
Optionally check the Reuse connection only if expression is true control. This control allows you to enter an ECMAScript expression that evaluates to true or false based on some test of the launch screen. The purpose of the expression is to check to make sure the launch screen is the proper one each time a new 3270 Component is about to reuse an active free connection. Under circumstances unrelated to your Composer service, it's possible that the launch screen will be replaced by the host with a different screen. For instance, if there is a system ABEND on the host, the launch screen in the Logon Component may be replaced by a System Message screen.
NOTE: For instructions on how to create this expression, see the discussion at "Handling System messages" in Chapter 2 of this Guide. Also refer to "Maximizing Performance of the 3270 Logon Connection" in this Chapter.
The following a is a sample Custom Script used to see if a particular screen is present. If it is not, the script writes a message to the console stating that the screen is bad and the logon connection is being released. This function is called from the "Reuse connect only if expression is true" control on the Pool Info dialog.
To prevent 3270 Components from beginning execution on a connection that may have been left on an invalid screen by a previous 3270 component, the Logon Connection Resource allows the connection itself to check for the presence of the launch screen. This is accomplished by using the option titled "Reuse connection only if expression is true" on the Pool Info dialog of the Logon Connection. The screen test you specify here is executed each time a 3270 Component completes execution. If the test fails, exteNd Composer will immediately disconnect from the host, possibly leaving a dangling UserID on the host. As noted before, the host will eventually kill the user, but the UserID may be discarded from the pool if it is accessed again before being killed, thereby reducing the pool size and consequently overall performance.
Another reason to use the "Reuse connection only if true" option is that you can perform very detailed tests against the screen to make sure it is your launch screen. While Map Screen actions do perform a screen check, they only look at the number of fields in the terminal data stream. In most cases, this is sufficient. However, it is possible two different screens can have the same number of fields in which case the expression based test that examines the content of the screen will produce more rigorous results. A best practices approach mandates that you use this feature all the time.
In some Composer applications, users have a need to place various control, auditing, and/or meta-data in an XML document. This document may or may not be in addition to the actual elements/documents being processed (i.e. created from an information source). If this document structure and data is dynamically created by multiple Map actions (i.e. over 100) performance of the component and therefore the entire service may suffer. To boost performance, create the portion of the document structure without the dynamic content ahead of time, then load it into the Service at runtime via an XML Interchange action and retain the Map actions for dynamic content. This can boost performance as much as 30% in some cases.
Sometimes, you may want the extra level of control over session parameters that a Logon Connection affords, without necessarily wanting to use pooling. In this case, you can follow the procedure outlined below.
To create a 3270 Logon Connection:
From the Composer File menu, select New> xObject, then select the Resource tab and choose Connection, or you can click on the icon. The Header Info panel of the New xObject Wizard appears. 
For the Connection Type select "3270 Logon Connection" from the drop down list.
In the Connect Via control, select the Logon Component you just created.
The Screen wait (seconds) field, displays the amount of time in seconds that a 3270 Terminal component will wait for a the next screen to arrive in the Map Action Pane.
Click the Session Connections radio button and then on Session Info button.
The Keep Alive (minutes) number represents (in minutes) how often you wish to execute the Keep Alive actions in the associated Logon Component whenever the connection is active but free (i.e. not being used by a 3270 Terminal component). The number you enter here should be less than the Timeout period defined on the host for an inactive connection.
The Inactivity Lifetime (minutes) number represents (in minutes) how long you wish to keep an active free connection available before closing out the connection and returning it to the inactive portion of the connection pool. Remember, that once the connection is returned to its inactive state in the pool, it will incur the overhead of logging in and navigating host screens when it is re-activated.
Click in the checkmark box if you want to Reuse connection only if expression is true. If you choose to do so, the expression field automatically displays and you can click on the expression icon to display the if the expression is true dialog.
At this point, you are ready to create a 3270 Terminal Component that can use the Connection Pool. For the most part, you will build the component as you would a normal 3270 Terminal component, the only difference being the Connection you specify on the connection panel of the New Component Wizard. (You'll specify a Logon Connection instead of a regular TN3270 or EPI Connection.)
To create a 3270 Terminal Component:
From the Composer File menu, select New>xObject, then select the Component tab and choose 3270 Terminal.The Header Info panel of the New xObject Wizard appears.
Select the necessary Input and Output Templates and click Next, and the Temp/Fault panel appears.
Select the necessary Temp and Fault Templates and click Next, and the Connection Info panel appears.
Select the Logon Connection you created and click on Next, and the Component editor appears.
Build the component according to instructions in Chapter 3 of this Guide.
Once the launch screen is obtained by the Logon Component's logon actions, it is handed to the 3270 Terminal Component that uses the connection. Then the 3270 Terminal component (when finished executing) leaves the screen handler back at the launch screen. If the 3270 Component finishes without being on the launch screen (i.e. it releases the connection back to the pool with an invalid screen), then it is possible that all subsequent 3270 Components that use the connection may throw exceptions, rendering the connection useless. It also will degrade overall performance and possibly cause data integrity problems within the component processing.
Once again, ensure that the launch screen is present. The last action to execute in a 3270 Component must be a Map Screen that checks for the launch screen. This can be tricky if your component has many decision paths that may independently end component execution. You must be sure that each path ends with a Map Screen action.
Connections pools can be managed through the 3270 Console Screen.
If you are using the Novell exteNd Application Server, log on to your server via your web browser using http://localhost/SilverMaster50 (or whatever is appropriate for the version in use). In this example, Novell exteNd App Server 5.0 is used.
NOTE: If you are not using the exteNd app server, enter a URL of this form:
Click on the exteNd Composer link. You should see the main console page:
Click on the 3270 link in the left (nav) frame. The 3270 Console General Properties Screen will come into view.
Click the Console button. A browser popup window (the Connection Pool Management Screen) should appear:
To initialize a Logon Connection Pool, enter its deployment context, the word "connection", and the actual connection name in the text field near the bottom of the screen. (See illustration above.) Then click the Initialize Pool button.
NOTE: Refer to the appropriate Composer Enterprise Server guide for more information.
Optionally click the Refresh Console button to update the view.
The Connection Pool Management Screen displays the current state of the connection(s) with the 3270 Connect. The screen contains a table listing the Pool Name, Description of the connection, the maximum number of connections in the pool, the number of connections in use, the number of connections available, the number of connections discarded. It also contains several buttons allowing you to perform various actions related to connection pooling, which are outlined in the table below.
The performance benefits of connection pooling are based on the ability of more than one user to access a resource, or set of resources, at once. The way a connection is established begins with the logon component picking the User ID and Password from the table. If the connection fails, then it is discarded for this User ID and Password and another is tried until a connection is established. The failure of one connection doesn't necessarily prevent a successful connection from being established.
The Connect for 3270 addresses the "one bad apple" problem by discarding any connection that can't be established (for whatever reason: bad user ID, timed-out password, etc.) and reusing the others. When a connection is determined to be unusable, the Connect for 3270 will write a message to the system log that says: "Logon connection in pool <Pool name> was discarded for User ID <User ID>."
Screen synchronization has special ramifications for users of pools. If a situation arises in which a user leaves a connection without the screen returning to its original state, the next user will begin a session with the screen in an unexpected state and an error will occur. To prevent this, we have a screen expression which the user can specify in the connection pool. It is important that the last action in a 3270 Component be a Send Attention Key action that will result in the session ending with the correct logon screen active.
NOTE: The last action should be an empty Map Screen action so that the 3270 Terminal component waits until the launch screen arrives before giving up the connection. (This should happen automatically, when you create the Send Attention Key action, but nevertheless, the last action should be the Map Screen.)
If you want to check, at runtime, for the presence of a bad screen at the end of a user session, include a Function Action at the end of your component's action model that executes a function similar to the one shown below:
function checkValidReleaseScreen(ScreenDoc)
{
var screenText = ScreenDoc.XPath("SCREEN").item(0).text
if((screenText.indexOf( "MENU") != -1 || screenText.indexOf("APLS") != -1) &&
(screenText.indexOf("COMMAND UNRECOGNIZED") == -1 || screenText.indexOf("UNSUPPORTED FUNCTION") == -1))
{
return true;
}
else // Write error messages to
// System.out and System.err:
{
java.lang.System.out.println("Warning - Releasing logon connection at bad screen");
java.lang.System.err.println("Warning - Releasing logon connection at bad screen");
return false;
}
}
In this particular example, this function checks the screen text and returns true if the screen contains "MENU" or "APLS" and does not contain "COMMAND UNRECOGNIZED" nor "UNSUPPORTED FUNCTION." Otherwise it returns false.
Copyright © 2003 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...