|
| About Us | Products | Solutions | Resources | Support |
| Home : Resources : White Papers : Session Switching | |||||||||
| Support: White PapersNetwork Session SwitchingOriginally 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: AcknowledgementsReferences within this manual to the following products should be recognized as references to proprietary products and trademarks of the following firms:
IntroductionNorth 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:
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 ComponentsTo accomplish the use of a terminal device and facilitate the use of corporate data in the mainframe, several software components need to be identified. VTAMIBM'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:
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. SubsystemsThe 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:
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 ComponentsWhen you establish a session between your device and a subsystem, you make use of several hardware components. The common elements are: TerminalA 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 UnitThe 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 ControllerThe 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. CPUThe 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 ConnectorsThe 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 RepresentationsThis paper will use items as shown in the following figure to represent the various hardware elements involved in discussing the SNA session topic: 
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. 
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 CommunicationsA 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: 
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: 
The following actions occur in order to process a "transaction" (receive a request from the device and send an answer back):
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 AlternativeIt 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 ArchitectureEach 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: 
The following actions occur in order to process a "transaction" (receive a request from the device and send an answer back):
The Up SideThe software session managers provide many positive characteristics:
The Down SideHowever, the software session managers have some negative aspects to them:
Network RoutingWhen 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: 
The following actions occur in order to process a "transaction"(the host receives a request from the device and sends an answer back):
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. 
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:
This characteristic can introduce extremely difficult response time conditions, if your installation makes use of virtual sessions cross domain or cross network. Some ImplementationsSession 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:
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.
The Hardware AlternativeYou 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 ArchitectureThe following figure represents the structure that a physical device using a hardware session manager uses: 
The following actions occur in order to process a "transaction"(receive a request from the device and send an answer back):
The Up SideThe hardware approach to sessions have several strong points and resolve many of the difficulties associated with software session manager characteristics:
The Down SideThere are still several "add on" features that hardware session switching does not resolve.
Some ImplementationsHardware 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 DevicesThe 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?). LANsThe 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 BasedNewer 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:
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. ConclusionNRS 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! | ||||||||
| |||||||||
