6. DATA SOURCES › 6.8 Multiple Session Manager Considerations
6.8 Multiple Session Manager Considerations
A multiple session manager is a VTAM application that lets a
terminal user maintain active sessions with more than one
host application simultaneously. The key advantage of such a
product is that it eliminates the need for a user who
requires access to two or more host applications to log off
of one application and log on to the other. This in turn
reduces system resources for application LOGONs and enhances
end user productivity.
Examples of multiple session managers are the following:
o CA-TPX,
o CA-Teleview
o SOLVE: Access Session Management
o NetView Access, Tivoli
There are many multiple session manager products on the
market today. While each is implemented somewhat
differently, there are specific data-related issues that are
common among them.
A multiple session manager introduces a separate layer in the
interface between the user and the host application. The
multiple session manager layer controls the user's access
between 16 to 255 separate applications, depending upon the
product's implementation. Figure 6-16, Multiple Session
Manager User Session, illustrates the interface between the
user at a terminal, the multiple session manager, and the
host applications.
+-------------+ +-------------+
VTAM | | VTAM | |
Appl. | TSO | Appl | CICS |
| | | |
+------+------+ +------+------+
| |
+-----+ +-----+
| |
+-----+-------+-------+-----+
Virtual Term. | TX990217 | TX990218 | Virtual Term.
+-------------+-------------+
VTAM | Multiple Session Manager |
Appl. | (e.g. TPX, TeleView) |
+------------+--------------+
|
|
|/|
|
|
+---------+---------+
User's | +---------------+ |
Terminal | | Multi-Sess Man| |
| | | |
(SLU = | | Select Appl | |
T1102015) | | 1 - TSO | |
| | 2 - CICS | |
| +---------------+ |
+---------+---------+
/ o o o o o o o o o /
/ o o o o o o o o o /
/___________________/
The terminal user is identified by a userid/password. Once
logged on to the multiple session manager, the user can
initiate sessions with authorized host applications. In
Figure 6-16, the user can log on to TSO and CICS. Once logged
on to these applications, the user can switch at will between
them without having to log off one before logging on to the
other.
To accomplish this, the multiple session manager establishes,
in the example illustrated in Figure 6-16, three separate
sessions. First, there is a session between the user's
terminal and the multiple session manager. Second, a
virtual terminal session is established between each real
application (TSO and CICS) and a virtual terminal that is
associated with the multiple session manager. By VTAM rule,
the virtual terminal name must be different from the real
terminal name.
Three sessions are established using the example in Figure
6-16:
o Application = TPX; Real Terminal = T1102015
o Application = TSO; Virtual Terminal = TX990217
o Application = CICS; Virtual Terminal = TX990218
DATA ISSUES
There are several issues that must be considered when
evaluating data recorded by products like NetView Session
Monitor, NPM Session Subsystem, and CA NetSpy, for users
accessing multiple applications through a multiple session
manager.
First, data will be recorded for each real and virtual
session established by the multiple session manager. In the
example above, each session will be identified by session
partners, as follows. PLU is the primary logical unit, or
primary session partner (usually an application); SLU is the
secondary logical unit, or secondary session partner (often a
terminal).
o TPX session with real terminal
PLU = TPX
SLU = T1102015
o Virtual terminal session with TSO
PLU = TSO
SLU = TX990217
o Virtual terminal session with CICS
PLU = CICS
SLU = TX990218
The virtual terminals identified by SLUs TX990217 and
TX990218 may bear no relationship to the real terminal,
T1102015, if a multiple session manager feature called
"pooling" is used. With pooling, virtual terminal names are
obtained as needed from a pool of virtual terminal names.
The advantage to using this feature is that new real
terminals can be added to a system and their users can take
advantage of a multiple session manager without requiring an
update to either VTAM or tables in the host application. The
disadvantage is that there is no way for an analyst or end
user of the data produced for such a virtual session to
determine what real terminal was in session with the host
application. On the other hand, the record that contains
data for the real terminal session does not identify the host
application (it identifies, instead, the multiple session
manager name). Where pooling is not used, data for the
virtual terminal session identifies a terminal (SLU) that can
be translated to the real terminal (SLU) name, but this must
be understood by the analyst or user of the data in order to
make a correct interpretation of the information.
Second, network message and character counts and session
connect time are included in the data for both the real
terminal session and each of the virtual terminal sessions.
The analyst must be careful when combining information from
these records because the results will be inflated.
Third, network response times are missing in the virtual
terminal session records.
Fourth, performance monitors like Tivoli NPM and CA NetSpy
rely on the use of the definite response (DR) feature to
calculate network response time. DR is an application option
flag, set in the outbound message, which requires the
terminal controller to return a positive indication to the
application that the message arrived at the terminal. It is
frequently used by host applications to synchronize
transmission to the terminal. When DR is used, NPM and CA
NetSpy can determine network response time as the difference
between the arrival time of the DR and the time the message
was sent to the terminal (with adjustments to compensate for
differences in character counts between the terminal user's
input message and the short message that returns as the
result of a DR request).
Some multiple session managers do not pass on the definite
response flag with the outbound message, but instead return
an immediate DR to the host application. When this occurs,
network response time is rendered meaningless.
This problem can be overcome if the network monitor provides
the facility to activate DR in the VTAM interface, after the
multiple session manager has already handled the outbound
message. CA NetSpy is an example of a network monitor with
such a feature. The CA NetSpy FORCEDR parameter is used to
invoke this option.
CA NetSpy also has a multiple session manager interface that
can reduce the problems these products normally present in
network monitor data. This interface and its effects are
described in Section 6.1.4.8, CA NetSpy Data Considerations.
Copyright © 2014 CA.
All rights reserved.
|
|