North Ridge Software
Logon | Search | Go to
About UsProductsSolutionsResourcesSupport
Home : Resources : White Papers : Session Switching
Newsletters
White Papers
Session Switching

Support: White Papers

Network Session Switching

Originally published: Sept 1996


Special Notices

This document contains information and the opinions expressed are the opinion of the authors and are distributed on an "as is" basis without any warranty either expressed or implied.

The use of this information or the implementation of any of the items discussed herein is the reader's responsibility. Any attempt to implement or use concepts or elements of this document in a specific environment may or may not succeed, dependent upon the ability of the implementor or the availability of certain hardware or software components.

The authors continue to have an interest in the general area covered by this paper and would be happy to hear from you. Please forward any correspondence to the address listed below.

All rights are reserved. No portion of this document may be reproduced, copied, distributed, transmitted, transcribed, or translated into any human or computer language, or otherwise disclosed to third parties without the express written permission of:

Acknowledgements

References within this manual to the following products should be recognized as references to proprietary products and trademarks of the following

firms:
AttachMate
Extra!
BI Moyle and Associates
BIM/Window
DCA
Workstation for Windows
Candle Corporation
Omegamon, CL/Supersession
MicroSoft
Windows
CKS Software
MultSess
Computer Associates
TOP SECRET, ACF2, UCC7, ROSCOE, EMAIL, IDMS/DC
Computer Corporation of America
MODEL204
IBM
ACF/VTAM, ACF/TCAM, NMPF, NPDA, VM/GCS, OS/VS1, NETVIEW, NLDM, NPA, CMS, Netview/Access, OS/2, Communications Manager, MVS, DOS/VSE, CICS/VS, TSO, IMS, RACF, NPDA, and NCCF
Isogon Corporation
InterSession
Legent
TPX
MacKinney Systems
VTAM/Switch
SofTouch Systems, Inc.
CICS-Windows
Software AG
Com-plete, Net-Pass
Systems Center
NetMaster
Technologic Software Concepts
PIE

Introduction

North Ridge Software is involved in delivering VTAM based software systems to the IBM System 370 and compatible marketplace (The Network Director and The Network Center). During these activities we encounter a large volume of questions relating to networking issues (some we can solve, some we can't).

One issue that has consistently been presented to us is the general question of session switching. It has been our experience that this term means many different things to many different people. This paper is our attempt to sort out the basic issues and present them for your review.

Use these observations as you feel most appropriate. Agree and/or disagree where you feel it is appropriate. But mostly, understand the issue and make sure your operation is using a strategy that makes sense for you.

This paper is not intended for solely one audience, but the assumption has been made that the reader has a working knowledge of how ACF/VTAM is configured and generally operates. If you are unsure of this, please reference the following IBM publications:

SC31-6434
Network Implementation Guide
SC31-6436
Programming
SC31-6438
Resource Definition Reference

These three publications provide the general background necessary to reinforce what is discussed in this paper. While these are VTAM 3.4 publications, other VTAM releases have the equivalent manuals and are equally applicable.

Software Components

To accomplish the use of a terminal device and facilitate the use of corporate data in the mainframe, several software components need to be identified.

VTAM

IBM's strategic direction for 370 and compatible host based Systems Network Architecture (SNA) concepts is the program product known as the Virtual Telecommunications Access Method, commonly called VTAM. The IBM program numbers forthe VTAM release current as of the publication of this paper (3.4) are:

5685-085
VTAM 3.4 for MVS/ESA
5684-095
VTAM 3.4 for VM/ESA
5665-280
VTAM 3.4 for VM/SP

Your system may be operating an older version of VTAM, which is just as applicable to the concepts included here. Essentially, VTAM is the software product that all telecommunications work revolves around in a 370 or compatible host environment.

Subsystems

The mainframe operating environment (MVS, VM, DOS, or a combination) operates multiple software systems that ACF/VTAM calls APPLICATIONS. We prefer the term subsystems to separate concepts like "Accounts Payable" (an Application) from "CICS" (a subsystem). This paper will use the subsystem term to represent a VTAM APPLICATION or software system that communicates with devices via the VTAM Application Programming Interface (API).

These subsystems (VTAM APPLICATIONS) are the portions of your network that require you to file an appropriate APPL definition in your VTAMLST definition. You will find the VTAMLST definitions normally filed in the SYS1.VTAMLST library for OS systems, the VTAM service machine's 191 disk or an extension, and the B. sublibrary in DOS systems.

Some common VTAM subsystems are:

IMS
IBM's Information Management System
CICS
IBM's Customer Information Control System
TSO
IBM's Time Sharing Option
CMS
IBM's Conversational Monitor System
NetView
IBM's Network Management product
Model204
CCA's database
ROSCOE
CA's interactive development system
COM-PLETE
Software AG's teleprocessing monitor
Omegamon
Candle Corporation's system monitor

When you use a terminal (called a "Logical Unit" in SNA terminology), you are asking VTAM to establish a connection between your device and a VTAM processing subsystem. This connection is identified as a session between the subsystem and your device.

Hardware Components

When you establish a session between your device and a subsystem, you make use of several hardware components. The common elements are:

Terminal

A terminal (referenced as a logical unit) typically consists of a display surface (screen) and a keyboard for data entry (generally known or generically identified as a 3270 device).

Examples of real IBM 3270 type devices are the IBM 3277, 3278, 3279, 3178, 3179, 3191, 3192, 3193, 3290, 3191, 3192, 3194, etc.

Terminal Control Unit

The terminal control unit co-ordinates activity between an individual device and the host. A "local control unit" is directly attached to a system channel. A "remote" control unit is connected to the host via a telecommunications controller (commonly known as a "front end").

Examples of IBM control units are 3271, 3272, 3274, 3276, 3174, etc.

Telecommunications Controller

The telecommunications controller is the channel attached device that manages communication lines, etc. to enable communications over common carrier lines (typically, the phone company). The TCU normally operates a copy of the Network Control Program (NCP).

Some examples of IBM telecommunications controller are 3704, 3705, 3725, and 3745.

CPU

The Central Processing Unit or CPU is the mainframe engine that executes the instructions necessary to make the network functional.

Examples of IBM CPUs are 4381, 9370, 3090, 3081, 9021, 9121, etc.

Cables and Connectors

The hardware units are cabled together in a variety of manners, dependent upon the specific hardware involved. Devices are typically connected to the host via co-axial cable (COAX) or, more recently, via some type of a Local Area Network (LAN) connection.

Pictorial Representations

This paper will use items as shown in the following figure to represent the various hardware elements involved in discussing the SNA session topic:

Hardware Artwork Used in Figures

Each of these elements should be viewed in a general manner. That is, the 3279 represents any device following the 3270 protocol to communicate with the host. Occasionally, the 3270 will be portrayed as a PC, but the reader is reminded that any device operating with the 3270 protocol is conceptually interchangeable. The 3090 CPU represents any host capable of hosting VTAM. The 3174 and 3705 represent any device that operates in the same capacity.

Some of the figures portray software products and the flow between them. They will be portrayed as three dimensional "boxes" in various shapes with flow between them represented by arrows. An example of this is as shown.

Software Artwork Used in Figures

It is important that you understand how the figures in this paper can be related back to your own environment. You need to be able to take the concepts and general architecture discussed here and relate it to your own network.

Normal LU Communications

A session between a single VTAM device and a subsystem can be initiated in multiple manners. Originally, all VTAM terminal users issued what is known as a VTAM USS command. The terminal screen would look similar to this:

USS LOGON Command

This is known as a SLU initiated session request, which means that the terminal user requested a connection to a subsystem. VTAM would process the LOGON request and, if valid, would create a session between the two Logical Units (the terminal and the subsystem).

Assuming the device is connected via a local control unit the session representation can be portrayed as:

A Standard LU-LU Session

The following actions occur in order to process a "transaction" (receive a request from the device and send an answer back):

  1. The terminal operator enters an appropriate request on the keyboard and presses ENTER
  2. The 3270 device "sends" the data to the control unit
  3. The terminal control unit forwards the request via a channel to VTAM in the host
  4. VTAM dispatches within the operating system and sends the request to the CICS system
  5. CICS dispatches within the operating system, processes the request, and returns the response by calling VTAM
  6. VTAM sends the output transmission to the terminal control unit
  7. The terminal control unit processes the output buffer and places the response on the display screen and frees the keyboard

Why Multiple Sessions?

One of the initial strengths of ACF/VTAM was the ability to utilize a single physical device and initiate a session with any of a variety of subsystems. Typical corporate applications grew within different subsystems (CICS, IMS, etc.), which required a terminal user to communicate with more than one subsystem to accomplish his/her job function.

This can be accomplished by the terminal user logging onto the first subsystem and accomplishing the processing required. If a need to utilize information from the second subsystem arises, the terminal user would typically terminate the session with the first subsystem (logoff, etc.) and then initiate a session with the second subsystem. This technique could force the terminal user through multiple session termination and initiation sequences, dependent upon the work flow pattern for the specific assignment. This activity produces much "unproductive" time for the individual user that spends too much time "switching" from one environment to the other.

To resolve this problem, it is possible to simply place multiple physical devices on the desk for the individual. However, this has the drawback of the expense (purchasing multiple devices) and can take up a significant amount of desk space. As an alternative, a couple of techniques have emerged to provide multiple sessions without the requirement for multiple physical devices on the desktop.


The Software Alternative

It is possible to acquire software to provide software session switching (commonly identified as "session managers"). These packages allow the physical device to enter a session with the session manager software and then issue commands to create one or more "virtual sessions" with actual target subsystems.

The physical device's input and output transmissions continue to be managed by the session manager. The input and output transmissions to and from the actual subsystem is "intercepted" by the session manager and forwarded to the physical device when the terminal operator desires.

Because the session manager actually manages all input and output to the physical device, it is possible for the terminal operator to press a "hot key" to notify the session manager about session switching requests that the operator may have. This process normally brings the terminal screen "back" to the session manager's menu or control panel that can be used to initiate a new session.

General Architecture

Each Session Manager manages the real session between the host and the physical device. Each time the device initiates a new session, the Session Manager creates a virtual session for communications to the subsystem. Input and output is routed by the Session Manager along the virtual and real sessions as appropriate.

This architecture allows a single physical device to use the Session Manager to create multiple virtual sessions with different (or the same) subsystems. Thus, the terminal user can switch between the virtual sessions under Session Manager control.

The following figure represents the structure that a physical device using a software session manager uses:

A Session Manager Session

The following actions occur in order to process a "transaction" (receive a request from the device and send an answer back):

  1. The terminal operator enters an appropriate request on the keyboard and presses ENTER
  2. The 3270 device "sends" the data to the control unit
  3. The terminal control unit forwards the request via a channel to VTAM in the host
  4. VTAM dispatches within the operating system and sends the request to the Session Manager
  5. The Session Manager requests VTAM to initiate a new "virtual session" (typically using a predefined APPL definition in VTAM). Note that this name will likely not match the actual physical device's LU name.
  6. VTAM causes the target subsystem's routines to receive control for communications with the virtual device
  7. The subsystem processes the request and responds by sending output to VTAM for the virtual device
  8. VTAM notifies the Session Manager that output has arrived on a specific virtual session
  9. The Session Manager identifies which physical device is mapped to the virtual session and notifies VTAM that the output should be sent to the physical device
  10. VTAM sends the output transmission to the terminal control unit
  11. The terminal control unit places the output on the terminal device

The Up Side

The software session managers provide many positive characteristics:

  1. They provide session capabilities for any VTAM device connected to the host. This includes current 3270 devices as well as older installed terminals.
  2. Some session managers can change the actual protocol used by the device (from SNA to non-SNA), which can simplify interfacing to older VTAM subsystems
  3. Data stream compression routines can be included to reduce the number of bytes sent to the actual device
  4. There is generally no limit to the number of sessions that can be started
  5. "Script" capabilities allow the session manager to "program" the session data stream after connecting to a virtual session
  6. Help desks can typically review the contents of another user's screen

The Down Side

However, the software session managers have some negative aspects to them:

  1. Requires that all real session traffic travel through the session product, which produces increased response times (we've heard anywhere from 1 to 5 additional seconds, generally based upon the product involved and the availability of host resources).
  2. Consumes significant portions of the CPU to support the dispatch and servicing of the additional address space each time for each transmission (we've encountered estimates from 5% to 25% of the CPU, dependent upon the size of the machine, the number of physical devices, and the number of virtual sessions for each physical device).
  3. Disables network rerouting of traffic, if the target VTAM system and the session manager are in different VTAM domains
  4. Requires a large number of VTAM APPL definitions to enable the virtual sessions)
  5. Increases exposure to network down time across the network (if the session product abends, all sessions it is operating also terminate)
  6. Creates additional security concerns
    1. Typically retains the user's password in storage, providing some potential for it being improperly exposed
    2. Changes the actual LU name from the physical name to a virtual name selected by the session manager (this can be significant if your installation makes use of the physical or actual LU name for any security based information).
    3. Passwords may be stored in "script" files associated with the session manager for using when a virtual session is established, which may or may not be secure

Network Routing

When a physical device enters a session with a cross domain or cross network subsystem, VTAM and the NCP can be (and normally are) configured to work together to optimize the network route associated with the session. This logic is intended to eliminate unnecessary processing of the session traffic.

A representation of this could be as pictured on the right:

Network Session Routing

The following actions occur in order to process a "transaction"(the host receives a request from the device and sends an answer back):

  1. The terminal operator enters an appropriate request on the keyboard and presses ENTER
  2. The 3270 device "sends" the data to the control unit
  3. The terminal control unit forwards the request via a link to a NCP executing in the communications processor
  4. VTAM dispatches within the operating system and determines that the session request is actually for a subsystem in Domain Two
  5. The NCP is instructed to route session traffic to Domain Two via NCP Two
  6. NCP One routes the input to NCP Two
  7. NCP Two forwards the input to VTAM in Domain Two
  8. VTAM provides the data to the subsystem for processing
  9. The subsystem sends the output response destined for the terminal back to its local domain copy of VTAM
  10. VTAM transmits the response back to NCP Two for routing
  11. NCP Two sends the answer back to NCP One
  12. The NCP passes the data stream on to the terminal control unit
  13. The 3270 device that initiated the request receives the response

However, if a session manager resides in the device's domain and the target of the virtual session is a cross domain or cross network session, the following route is taken.

Network Session Routing via a Session Manager

The following actions occur in order to process a "transaction" (the host receives a request from the device and send an answer back) when a local domain session manager has a cross domain or cross network virtual session established:

  1. The terminal operator enters an appropriate request on the keyboard and presses ENTER
  2. The 3270 device "sends" the data to the control unit
  3. The terminal control unit forwards the request via a link to a NCP executing in the communications processor
  4. VTAM dispatches within the operating system and determines that the session request is actually to the session manager product
  5. VTAM notifies the session manager that input has arrived
  6. The session manager correlates the real session input with the virtual session that is in progress and sends the input along to the eventual target subsystem
  7. VTAM receives the data from the session manager and routes it cross domain via NCP One
  8. NCP One forwards the data to NCP Two to reach Domain Two
  9. NCP Two notifies VTAM in Domain Two that data has arrived on the virtual session
  10. VTAM delivers the "input" to the subsystem
  11. The subsystem operates upon the request and returns the answer to VTAM in Domain Two to deliver it back to the device
  12. NCP Two is notified by VTAM Two that a response on the virtual session needs to be transmitted
  13. The data is transmitted to the appropriate NCP (NCP One)
  14. The response is sent back into VTAM One because the destination for the virtual session is the session manager that resides in Domain One
  15. VTAM provides the "output" back to the session manager
  16. The session manager matches the virtual output back to the physical device and instructs VTAM to send the output
  17. VTAM notifies the NCP (NCP One) to send the output to the device
  18. NCP One forwards the data to the control unit
  19. The 3270 receives the response to the request

This characteristic can introduce extremely difficult response time conditions, if your installation makes use of virtual sessions cross domain or cross network.

Some Implementations

Session managers that are available have a variety of facilities and prices, as well as operational characteristics.

A few vendors producing products that we are aware of are:

CL/Supersession
Candle Corporation
MultSess
CKS Software (previously Westinghouse)
Netview/Access
IBM Corporation
TPX
Legent
BIM/Window
BI Moyle and Associates
VTAM/Switch
MacKinney Systems
NetMaster
Systems Center
InterSession
Isogon Corporation
Software AG
Net-Pass

Our apologies to any vendor that we have inadvertently omitted, mis-spelled, etc. Our only desire with this list is to give the reader an idea of the vendors active in this area.

Not all the vendors are producing "pure" VTAM solutions. There are several products that operate in another "host environment" that do multiple sessions. However, the reader is reminded that these products have additional considerations that must be evaluated for applicability at your location.

In general, if the environment they use to host multiple sessions is the same environment that the majority of your usage is in, then they may be a reasonable solution for you. These types of systems do not tend to have the same operational overhead as the prior list, but are also not quite as general purpose.

CICS-Windows
SofTouch Systems, Inc.
PIE
Technologic Software Concepts

The Hardware Alternative

You also have available as an option the acquisition of hardware session switching capabilities (if you do not already have them). This approach allows a single physical device to operate as multiple devices with the switching function done within the network hardware.

This is accomplished generally via the implementation of what is called Distributed Function Terminal (DFT) support.

The newer control units have built upon this basic approach and implemented what is known as Multiple Logical Terminal (MLT) support right into the control unit (very useful for older terminal devices).

We are also beginning to see a wide variety of network hardware session switching in LANs, specialized PCs and associated software, etc. As the Programmable Work Stations (PWS or personal computers) become more powerful, the overhead necessary to support multiple sessions in the hardware is becoming increasingly insignificant.

General Architecture

The following figure represents the structure that a physical device using a hardware session manager uses:


Multiple Hardware Sessions

The following actions occur in order to process a "transaction"(receive a request from the device and send an answer back):

  1. The terminal operator enters an appropriate request on the keyboard
  2. The 3270 device "sends" the data to the control unit
  3. The terminal control unit forwards the request via a channel to VTAM in the host
  4. VTAM dispatches within the operating system and sends the request to the application system (CICS or TSO in the example)
  5. The application system dispatches within the operating system, processes the request, and returns the response by calling VTAM
  6. VTAM sends the output transmission to the terminal control unit
  7. The terminal control unit processes the output buffer and places the response on the display screen and frees the keyboard

The Up Side

The hardware approach to sessions have several strong points and resolve many of the difficulties associated with software session manager characteristics:

  1. Requires no CPU overhead to manage the session (session overhead is contained in the network), which eliminates CPU overhead and keeps response time at its optimum
  2. Because VTAM deals with each session as a real LU, all network rerouting via NCPs is continued for cross domain and cross network sessions
  3. Many hardware solutions (particularly PWS) allows the terminal operator a great degree of control over the appearance of the session on the physical device (overlapping windows, etc. that are quite limited via Session Managers)

The Down Side

There are still several "add on" features that hardware session switching does not resolve.

  1. Help desk review, data compression, and protocol conversion are not supported
  2. Implementation generally requires hardware that has been manufactured within the last 5 years (you may not have current control units) or the Brand X control units you use may not support DFT type devices

Some Implementations

Hardware session switching has been around for quite a while (we first starting using it at NRS on our internal systems in 1985). There are a variety of combinations that you can use within your installation. Some of the approaches that we have used or seen followed are:

Terminal Devices

The original DFT devices that supported multiple sessions are the IBM 3270/PC, 319x terminals, 3290 (orange plasma panel), etc. These devices have a Jump or Change Screen key on them that enable switching from one logical session to the next.

They all allow the terminal user to customize the physical display surface in the manner desired by the terminal operator. Specialized control programs in the device allow the device and control unit to communicate with each other to route the appropriate session traffic to the appropriate location.

Control Unit (MLT)

It is also possible to enable multiple sessions on older terminal devices with the MLT support available in the 3174 control units. The ALT Insert key combination becomes the Jump or Change Screen key.

This feature was originally called the Dual Logical Unit support (RPQ 8X0002) on the IBM 3274. Both this RPQ and the MLT support has always been free or incorporated into the price of the control unit itself from IBM (when's the last time you got a price like that?).

LANs

The emergence of Local Area Networks (LANs) has generated several LAN based solutions (Gateway, etc.). These mechanisms allow session switching facilities to be managed in the LAN server.

We expect this approach to be significantly expanded in the future to take advantage of the processing power in LAN servers.

PC Based

Newer generations of Programmable Work Stations (PWS) have introduced a variety of implementations on the PC that takes advantage of the connection to the host to enable multiple sessions via Co-axial cable or other LAN connection (like Token Ring, etc.).

The success of Windows Version 3 and the inevitable arrival of OS/2 has caused the user community to become very aware of "windowing" applications on the workstation. The end user wants to be able to do some non-3270 work on the same physical device panel that he/she is using for 3270 oriented work.

Some products that operate in the workstation and enable multiple sessions are:

Extra!
AttachMate
Workstation for Windows
DCA
OS/2 Communications Manager
IBM

There are quite a few more products that operate on the PC to accomplish multiple sessions. Most of them are quite good and provide the ability to size windows on the physical screen, etc.

Conclusion

NRS is a mainframe research and development software firm that specializes in networking software (specifically, VTAM products). As a result, we have an interest in making networks efficient, friendly, and stable. Please recognize this bias in our conclusions.

We believe that there are some excellent software session products on the market today marketed by competent firms with high integrity. However, we believe that the architecture mandated by VTAM causes an overhead in the network and host processors that can only be acceptable when the session product is utilized by a small percentage of the network.

As an alternative, we believe that hardware session switching is a much better and longer term solution for most computer systems. VTAM routing of session traffic between nodes becomes effective again in cross domain and cross network situations. Response times remain consistent and directly applicable to the throughput of the processor and are not constrained by the session manager bottleneck.

We want you to realize that putting session switching in the host is analogous to "using a large portion of the central processor as a big, expensive terminal control unit". If this is acceptable and/or desirable, then software session switching is for you.

We believe the future is in Programmable Work Stations (PCs, etc.) allowing the terminal user to split, divide, and utilize the device in a manner desired by the terminal user.

BUT, you need to decide what is appropriate for your shop. We hope this paper has helped get the issues out in the open for you. Good luck to you!


----------
Copyright © 2024 by North Ridge Software, Inc./WebMaster@North-Ridge.com
   RidgeStar, Internet Services