2. USAGE CONSIDERATIONS › 2.6 Multiple Session Manager Considerations
2.6 Multiple Session Manager Considerations
A multiple session manager is a VTAM application that
permits a terminal user to 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:
o CA TPX Session Management for z/OS
o CA Teleview Session Management for z/OS
o SOLVE: Access
o NetView Access, Tivoli
While each multiple session manager is implemented
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 to
16 to 255 separate applications, depending upon the product's
implementation. Figure 2-15, 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., CA TPX or TeleView) |
+------------+--------------+
|
|
|/|
|
|
+---------+---------+
User's | +---------------+ |
Terminal | | Multi-Sess Mgr| |
| | | |
(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 /
/___________________/
Figure 2-15. Multiple Session Manager User Session
The terminal user is identified to the multiple session
manager by a userid/password. Once logged on to the multiple
session manager, the user may initiate sessions with
authorized host applications. For example, in Figure 2-15,
the user may log on to TSO and CICS. Once logged on to these
applications, the user may switch at will between them
without having to log off of one before logging on to the
other.
To accomplish this, the multiple session manager establishes
three separate sessions, as illustrated in Figure 2-15.
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.
Note: VTAM requires that the virtual terminal name must be
different from the real terminal name.
Three VTAM sessions are established in the example in Figure
2-15:
o Application = CA TPX Session Management for z/OS; 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, where PLU is the primary logical unit,
or primary session partner (usually an application), and SLU
is the secondary logical unit, or secondary session partner
(often a terminal).
o CA TPX Session Management for z/OS 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 of using this feature is that new real
terminals may be added to a system and their users may 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
may be translated to the real terminal (SLU) name, but this
must be understood by the analyst or user of the data in
order to correctly interpret 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 since the results will be inflated.
Third, network response times are missing in the virtual
terminal session records.
Fourth, performance monitors like Tivoli's 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 the definite
response flag on 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 Chapter 6.
