CICS session management is a fundamental aspect of maintaining efficient and reliable interactions between users and CICS applications. Learn about terminal sessions, transaction sessions, session pooling, and session management tools that help optimize resource utilization and enhance user productivity in CICS environments.
In CICS, sessions represent the connections and interactions between users and the CICS system. There are two primary types of sessions: terminal sessions and transaction sessions. Understanding the distinction between these session types is essential for effective CICS session management.
Terminal sessions represent the physical connection between a user's terminal and the CICS system. Each terminal that interacts with CICS is defined in the Terminal Control Table (TCT), which specifies characteristics such as:
Terminal sessions handle the physical layer of communication, managing the connection between the terminal device and CICS, processing input/output operations, and maintaining the terminal state throughout the user's interaction with the system.
Transaction sessions pertain to the execution of specific tasks or programs initiated by users. Each transaction is defined in the Program Control Table (PCT), which links transaction identifiers to corresponding programs and controls processing behavior. Transaction sessions handle:
While a terminal session represents the physical connection, a transaction session represents the logical execution of work. A single terminal session can initiate multiple transaction sessions over time, and multiple transaction sessions can potentially share terminal resources through session pooling.
| Session Type | Description | Defined In | Purpose | Lifecycle |
|---|---|---|---|---|
| Terminal Session | Represents the connection between a user terminal and CICS system | Terminal Control Table (TCT) | Handles physical connection, device communication, and terminal-specific operations | Established at terminal connection, maintained during user interaction, terminated at disconnect |
| Transaction Session | Represents the execution of a specific task or program | Program Control Table (PCT) | Handles logical execution of work, task scheduling, and program execution | Initiated by transaction request, active during program execution, completed when task finishes |
The Terminal Control Table (TCT) is central to CICS session management. It defines all terminal devices that can interact with the CICS region and specifies how sessions are established and managed for each terminal type.
Each entry in the TCT (called a Terminal Control Table Terminal Entry or TCTTE) contains information about a terminal or a group of terminals. Key attributes include:
When a terminal connects to CICS, the following process occurs:
Sessions can be terminated in several ways:
When a session terminates, if it was using a pooled TCTTE, the TCTTE is released back into the pool for reuse by other transactions. For dedicated sessions, the TCTTE remains assigned to the terminal until the terminal reconnects or the TCT definition is changed.
Session pooling is a powerful CICS feature that optimizes terminal resource utilization by allowing multiple transactions to share a pool of Terminal Control Table Terminal Entries (TCTTEs) for a line. Instead of requiring a one-to-one correlation between physical terminals and TCT entries, CICS can dynamically allocate available TCTTE entries from a pool to incoming transactions.
Session pooling operates through the following mechanism:
Session pooling provides several advantages:
To configure session pooling, you specify the POOL option in the Terminal Control Table definition. Here's an example of how session pooling might be configured:
1234567891011121314151617181920TCT Configuration Example: * Define a pool of TCTTEs for a line * POOL=YES specifies that this line uses session pooling * POOLSIZE=50 specifies the number of TCTTEs in the pool TCTTE TERMID=POOL01, DEVTYPE=3270, LINE=LINE01, POOL=YES, POOLSIZE=50, AUTINST=NO * Key attributes: * - TERMID: Terminal identifier (can be a generic name for pooled entries) * - DEVTYPE: Device type (must be consistent for all entries in pool) * - LINE: Communication line name * - POOL=YES: Enables session pooling for this line * - POOLSIZE: Number of TCTTE entries in the pool * - AUTINST=NO: Automatic task initiation not applicable in pooled environment
While session pooling offers significant benefits, it has important restrictions that must be understood and considered before implementation. These restrictions exist due to the dynamic nature of pooled sessions and device dependencies within CICS.
| Restriction | Description | Reason | Impact |
|---|---|---|---|
| Terminal Type Consistency | Only one terminal type is permitted per line (process queue) | Due to device dependencies within CICS | All terminals in a pool must be of the same type |
| Read Request Limitations | Tasks cannot issue Terminal Control READ requests | Includes GET, PAGE, and CONVERSE commands which contain implied READs | Violating this can cause permanent line lock, preventing further transactions |
| Segment Processing | Segment processing must not be specified | Requires multiple READs which can lead to permanent line locks | Applications using segment processing cannot use pooled sessions |
| Automatic Task Initiation | Not applicable in pooled environment | Pooled sessions are dynamically allocated | Automatic task initiation features cannot be used with pooled sessions |
| Statistics Collection | Statistics cannot be correlated to specific physical terminals | TCTTEs are dynamically allocated from a pool | Statistics are accumulated per TCTTE but not per physical terminal |
| Sign-On Limitations | Only one sign-on can exist for all terminal entries in a line pool | First sign-on is propagated to all terminals in the pool | Subsequent sign-ons are rejected until the current one is cleared |
| Master Terminal Functions | Cannot be used on terminals with pooled TCTTEs | Require multiple READs which are not allowed | Master terminal operations must use dedicated (non-pooled) sessions |
Session pooling is best suited for applications where:
Before implementing session pooling, thoroughly analyze your environment and application requirements to ensure that the restrictions do not adversely affect system operations. Applications that require interactive terminal operations, multiple READs, or master terminal functions should use dedicated (non-pooled) sessions.
Various third-party tools are available to enhance CICS session management capabilities. These tools provide features beyond what is available in standard CICS, including multi-session support, improved user interfaces, and enhanced productivity features.
| Tool | Vendor | Description | Key Features | Use Case |
|---|---|---|---|---|
| SM/SWAP | MacKinney Systems | Allows a single terminal to function as up to eight logical terminals | Session navigation, multitasking, improved productivity | Users who need to run multiple transactions simultaneously |
| InterSession | Data 21 | Unified interface for managing multiple sessions | Automated logon, built-in TN3270 server, robust security | Organizations needing centralized session management |
| Terminal Productivity Executive (TPX) | CA Technologies | Session manager with single sign-on capability | Multiple concurrent sessions, single terminal connection, application switching | Enterprise environments requiring single sign-on and session management |
SM/SWAP is a component of MacKinney Systems' Session Manager for CICS that allows a single terminal to function as up to eight logical terminals, each running different transactions. Key features include:
SM/SWAP is particularly useful for users who need to work with multiple applications or transactions concurrently, such as operators monitoring multiple systems or developers testing different components.
InterSession, offered by Data 21, provides a unified interface for managing multiple sessions. It enables users to access all mainframe sessions from a single screen and includes:
InterSession is ideal for organizations that need centralized session management and want to improve the user experience when working with multiple mainframe systems.
Terminal Productivity Executive (TPX), developed by CA Technologies, is a session manager that allows users to access multiple applications with a single sign-on. Features include:
TPX is well-suited for enterprise environments where users need to access multiple applications and want the convenience of single sign-on combined with efficient session management.
Security is a critical aspect of CICS session management. Each session must be properly authenticated and authorized before it can access CICS resources and execute transactions.
When a terminal session is established, CICS performs authentication to verify the user's identity. This process involves:
After authentication, CICS checks authorization to determine what resources and transactions the user can access. Authorization checks occur for:
In pooled session environments, there are special considerations for sign-on and sign-off:
This restriction exists because pooled sessions share terminal resources, and maintaining separate sign-on states for each logical session would be complex and potentially insecure.
Effective session monitoring helps identify issues, optimize performance, and ensure reliable system operation. CICS provides various facilities for monitoring and managing sessions.
CEMT (CICS Execution Monitor Transaction) provides commands for monitoring and managing terminal sessions:
To query the status of a terminal session:
12345678910CEMT INQUIRE TERMINAL(TERM01) * This command displays: * - Terminal name and status * - Device type and line information * - Session state (active, inactive, etc.) * - Current transaction (if any) * - User information * - Pool information (if pooled) * - Statistics and usage information
To view all active transaction sessions:
123456789CEMT INQUIRE TASK * This command displays: * - All active tasks (transaction sessions) * - Transaction ID and program name * - Terminal association * - Task status and priority * - Resource usage * - Execution time information
CICS collects statistics for terminal sessions, including:
For pooled sessions, statistics are accumulated for each TCTTE in the pool, but they cannot be correlated to specific physical terminals since TCTTEs are dynamically allocated.
Following best practices ensures effective session management and helps maintain reliable CICS operations.
Before implementing session pooling or configuring session parameters, thoroughly analyze your application requirements:
Regularly monitor session utilization to optimize resource allocation:
Ensure robust security for all sessions:
Consider implementing session management tools when appropriate:
Maintain comprehensive documentation of session configurations:
Configure appropriate session timeout policies:
Periodically review and optimize session resources:
Understanding common session management issues helps with quick problem resolution and system optimization.
When all TCTTEs in a pool are in use, new transactions cannot be processed. Solutions include:
Sessions timing out unexpectedly can disrupt user work. Consider:
The single sign-on restriction in pooled sessions can cause issues. Solutions include:
Session-related performance issues can result from:
Monitor performance metrics and adjust configurations accordingly.
Practice these exercises to reinforce your understanding of CICS session management:
For a given application, analyze and document:
Use CEMT commands to:
Use CEMT INQUIRE TASK to:
Design a session pool configuration for a high-volume transaction processing application:
Imagine CICS is like a big playground, and sessions are like the ways kids can play on the playground. There are two main types of "play sessions":
Now, imagine that sometimes the playground is very busy, and there aren't enough entrance tickets for everyone. Session pooling is like having a special box of tickets that can be shared. When someone finishes playing and leaves, they put their ticket back in the box, and someone else can use it. This way, more people can play even though there aren't enough tickets for everyone at the same time.
But there are some rules: you can only use one type of ticket at a time in the shared box, you can't do certain special activities that need your own personal ticket, and only one person can sign in with their name at a time for all the shared tickets. These rules make sure everything works smoothly and safely!
CICS session management is essential for maintaining efficient and reliable interactions between users and CICS applications. Key points to remember:
Understanding CICS session management helps you optimize resource utilization, improve system performance, and ensure reliable operation of CICS applications. Whether using dedicated sessions or session pooling, proper configuration and management are essential for maintaining efficient CICS operations.
1. What is the primary purpose of CICS session management?
2. What table defines terminal devices in CICS?
3. What is session pooling in CICS?
4. Which of the following is a restriction of session pooling?
5. What does SM/SWAP allow in CICS session management?
6. What is the purpose of InterSession?
7. What command or method is used to configure session pooling?
8. What happens to a TCTTE when a transaction completes in a pooled session?
Learn about the Terminal Control Table including terminal definitions, device types, session parameters, and TCT configuration
Understanding the Program Control Table including transaction definitions, program linking, and transaction processing behavior
Learn about CICS transaction management including task scheduling, transaction routing, and transaction lifecycle management
Understanding CICS resource management including resource definitions, resource tables, and resource allocation strategies