Progress0 of 0 lessons

CICS Session Management

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.

Understanding CICS Sessions

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

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:

  • Device type (3270, 5250, VTAM, etc.)
  • Session parameters and configuration
  • Operational attributes
  • Security and authorization settings
  • Session pooling participation

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

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:

  • Task scheduling and prioritization
  • Program execution and control
  • Resource allocation for the transaction
  • Transaction lifecycle management
  • Error handling and recovery

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.

CICS Session Types Comparison
Session TypeDescriptionDefined InPurposeLifecycle
Terminal SessionRepresents the connection between a user terminal and CICS systemTerminal Control Table (TCT)Handles physical connection, device communication, and terminal-specific operationsEstablished at terminal connection, maintained during user interaction, terminated at disconnect
Transaction SessionRepresents the execution of a specific task or programProgram Control Table (PCT)Handles logical execution of work, task scheduling, and program executionInitiated by transaction request, active during program execution, completed when task finishes

Terminal Control Table (TCT) and Session Configuration

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.

TCT Entry Structure

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:

  • Terminal Name: Unique identifier for the terminal or terminal group
  • Device Type: Specifies the type of terminal device (3270, 5250, VTAM, etc.)
  • Line Name: Associates the terminal with a communication line
  • Session Parameters: Configuration settings for session establishment and maintenance
  • Pool Configuration: Whether the terminal participates in session pooling
  • Security Attributes: Authorization and security settings for the terminal

Session Establishment Process

When a terminal connects to CICS, the following process occurs:

  • Connection Request: The terminal initiates a connection request to CICS
  • TCT Lookup: CICS searches the TCT for a matching terminal entry
  • Resource Allocation: If session pooling is used, CICS allocates an available TCTTE from the pool; otherwise, it uses the dedicated TCTTE
  • Session Initialization: CICS initializes the session with appropriate parameters
  • Security Validation: User authentication and authorization are performed
  • Session Activation: The session becomes active and ready for transaction processing

Session Termination

Sessions can be terminated in several ways:

  • User Disconnect: User explicitly disconnects from the terminal
  • Timeout: Session times out due to inactivity
  • System Shutdown: CICS region shutdown terminates all active sessions
  • Administrative Action: System administrator forces session termination
  • Error Condition: Critical error causes session termination

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

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.

How Session Pooling Works

Session pooling operates through the following mechanism:

  • Pool Definition: A pool of generalized TCTTEs is defined for a line using the POOL option in the TCT
  • Dynamic Allocation: When a transaction is received over the line, CICS searches for an available TCTTE in the pool
  • Assignment: If an available TCTTE is found, it is assigned to the transaction for its duration
  • Release: Upon transaction completion, the TCTTE is released back into the pool for reuse
  • Reuse: The same TCTTE can be used by different transactions over time, improving resource efficiency

Benefits of Session Pooling

Session pooling provides several advantages:

  • Resource Efficiency: Reduces the need for a one-to-one correlation between physical terminals and TCT entries
  • Flexibility: Allows more transactions to be processed than there are dedicated terminal entries
  • Cost Reduction: Reduces memory and resource requirements for terminal management
  • Scalability: Enables handling of variable transaction volumes without proportional resource increases
  • Optimization: Better utilization of terminal resources, especially for high-volume transaction processing

Session Pooling Configuration

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:

text
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
TCT 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

Session Pooling Restrictions

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.

Session Pooling Restrictions
RestrictionDescriptionReasonImpact
Terminal Type ConsistencyOnly one terminal type is permitted per line (process queue)Due to device dependencies within CICSAll terminals in a pool must be of the same type
Read Request LimitationsTasks cannot issue Terminal Control READ requestsIncludes GET, PAGE, and CONVERSE commands which contain implied READsViolating this can cause permanent line lock, preventing further transactions
Segment ProcessingSegment processing must not be specifiedRequires multiple READs which can lead to permanent line locksApplications using segment processing cannot use pooled sessions
Automatic Task InitiationNot applicable in pooled environmentPooled sessions are dynamically allocatedAutomatic task initiation features cannot be used with pooled sessions
Statistics CollectionStatistics cannot be correlated to specific physical terminalsTCTTEs are dynamically allocated from a poolStatistics are accumulated per TCTTE but not per physical terminal
Sign-On LimitationsOnly one sign-on can exist for all terminal entries in a line poolFirst sign-on is propagated to all terminals in the poolSubsequent sign-ons are rejected until the current one is cleared
Master Terminal FunctionsCannot be used on terminals with pooled TCTTEsRequire multiple READs which are not allowedMaster terminal operations must use dedicated (non-pooled) sessions

When to Use Session Pooling

Session pooling is best suited for applications where:

  • Each record received over the input process queue represents a new transaction
  • Transactions do not require Terminal Control READ requests (GET, PAGE, CONVERSE)
  • Segment processing is not needed
  • Automatic task initiation is not required
  • Statistics correlation to specific physical terminals is not critical
  • Only one sign-on per line pool is acceptable
  • Master terminal functions are not needed

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.

Session Management Tools

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.

CICS Session Management Tools
ToolVendorDescriptionKey FeaturesUse Case
SM/SWAPMacKinney SystemsAllows a single terminal to function as up to eight logical terminalsSession navigation, multitasking, improved productivityUsers who need to run multiple transactions simultaneously
InterSessionData 21Unified interface for managing multiple sessionsAutomated logon, built-in TN3270 server, robust securityOrganizations needing centralized session management
Terminal Productivity Executive (TPX)CA TechnologiesSession manager with single sign-on capabilityMultiple concurrent sessions, single terminal connection, application switchingEnterprise environments requiring single sign-on and session management

SM/SWAP

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:

  • Multiple Logical Terminals: Up to eight concurrent logical sessions per physical terminal
  • Session Navigation: Users can switch between sessions using designated keys
  • Improved Multitasking: Enables running multiple transactions simultaneously
  • Enhanced Productivity: Reduces the need for multiple physical terminals

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

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:

  • Unified Interface: Single screen access to all mainframe sessions
  • Automated Logon: Streamlines the login process across multiple sessions
  • Built-in TN3270 Server: Integrated terminal emulation capabilities
  • Robust Security: Enhanced security measures for session management
  • Session Switching: Easy navigation between different sessions

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)

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:

  • Single Sign-On: One login provides access to multiple applications
  • Concurrent Sessions: Maintains several sessions simultaneously
  • Session Switching: Easy switching between sessions via a single terminal connection
  • Application Integration: Seamless integration with various mainframe applications
  • Reduced Login Overhead: Eliminates the need for multiple logins

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.

Session Security and Authorization

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.

Session Authentication

When a terminal session is established, CICS performs authentication to verify the user's identity. This process involves:

  • User Identification: User ID is provided during session establishment
  • Password Verification: Password is validated against security system (e.g., RACF)
  • Security System Integration: CICS integrates with external security managers like RACF, ACF2, or Top Secret
  • Session Token: Upon successful authentication, a session token is created

Session Authorization

After authentication, CICS checks authorization to determine what resources and transactions the user can access. Authorization checks occur for:

  • Transaction Execution: Whether the user can execute specific transactions
  • Resource Access: Access to files, programs, and other CICS resources
  • Terminal Operations: Permissions for terminal-specific operations
  • Administrative Functions: Access to system management and control functions

Sign-On and Sign-Off

In pooled session environments, there are special considerations for sign-on and sign-off:

  • Single Sign-On: Only one sign-on can exist for all terminal entries in a given line pool at any one time
  • Sign-On Propagation: The first sign-on received by CICS is propagated to all terminals in the pool
  • Subsequent Sign-Ons: Any subsequent sign-on is rejected until the current one is cleared
  • Sign-Off: A sign-off clears the sign-on data from all terminal entries in the pool, allowing a new sign-on to be accepted

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.

Session Monitoring and Management

Effective session monitoring helps identify issues, optimize performance, and ensure reliable system operation. CICS provides various facilities for monitoring and managing sessions.

CEMT Commands for Session Management

CEMT (CICS Execution Monitor Transaction) provides commands for monitoring and managing terminal sessions:

  • CEMT INQUIRE TERMINAL: Query terminal session status and information
  • CEMT SET TERMINAL: Modify terminal session settings
  • CEMT PERFORM TERMINAL: Perform operations on terminal sessions
  • CEMT INQUIRE TASK: View active transaction sessions

Example: Querying Terminal Session Status

To query the status of a terminal session:

text
1
2
3
4
5
6
7
8
9
10
CEMT 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

Example: Viewing Active Transaction Sessions

To view all active transaction sessions:

text
1
2
3
4
5
6
7
8
9
CEMT 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

Session Statistics

CICS collects statistics for terminal sessions, including:

  • Connection Count: Number of times the terminal has connected
  • Transaction Count: Number of transactions executed on the terminal
  • I/O Operations: Count of input/output operations
  • Error Count: Number of errors encountered
  • Session Duration: Total time the session has been active

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.

Best Practices for CICS Session Management

Following best practices ensures effective session management and helps maintain reliable CICS operations.

Analyze Application Requirements

Before implementing session pooling or configuring session parameters, thoroughly analyze your application requirements:

  • Determine if applications require Terminal Control READ requests
  • Identify if segment processing is needed
  • Assess whether master terminal functions are required
  • Evaluate sign-on requirements and restrictions
  • Consider statistics and monitoring needs

Monitor Session Utilization

Regularly monitor session utilization to optimize resource allocation:

  • Track active session counts
  • Monitor pool utilization for pooled sessions
  • Identify underutilized or overutilized resources
  • Analyze session duration and transaction patterns
  • Review session statistics and performance metrics

Implement Appropriate Security Measures

Ensure robust security for all sessions:

  • Enforce strong authentication requirements
  • Implement proper authorization controls
  • Configure session timeout policies
  • Monitor for unauthorized access attempts
  • Regularly review and update security settings

Use Session Management Tools

Consider implementing session management tools when appropriate:

  • Evaluate tools like SM/SWAP, InterSession, or TPX for enhanced productivity
  • Assess whether multi-session capabilities would benefit users
  • Consider single sign-on solutions for improved user experience
  • Evaluate unified session management interfaces

Document Session Configurations

Maintain comprehensive documentation of session configurations:

  • Document TCT definitions and pool configurations
  • Record session parameters and settings
  • Document security configurations and policies
  • Maintain records of session management tool configurations
  • Update documentation when configurations change

Establish Session Timeout Policies

Configure appropriate session timeout policies:

  • Set timeout values based on application requirements
  • Balance security needs with user convenience
  • Consider different timeout values for different session types
  • Implement automatic session cleanup for inactive sessions

Regular Review and Optimization

Periodically review and optimize session resources:

  • Review session utilization patterns
  • Optimize pool sizes based on actual usage
  • Identify and remove unused terminal definitions
  • Adjust session parameters based on performance data
  • Plan for capacity changes and growth

Common Session Management Issues and Solutions

Understanding common session management issues helps with quick problem resolution and system optimization.

Session Pool Exhaustion

When all TCTTEs in a pool are in use, new transactions cannot be processed. Solutions include:

  • Increase pool size to accommodate peak transaction volumes
  • Optimize transaction processing to reduce session hold time
  • Implement transaction queuing for peak periods
  • Monitor pool utilization to identify optimal pool sizes

Session Timeout Issues

Sessions timing out unexpectedly can disrupt user work. Consider:

  • Review and adjust timeout values based on application requirements
  • Implement session keep-alive mechanisms where appropriate
  • Educate users about timeout policies
  • Consider different timeout values for different application types

Sign-On Conflicts in Pooled Sessions

The single sign-on restriction in pooled sessions can cause issues. Solutions include:

  • Use dedicated sessions for applications requiring separate sign-ons
  • Implement proper sign-off procedures
  • Coordinate sign-on activities across users sharing a pool
  • Consider using session management tools that handle multiple sign-ons

Performance Degradation

Session-related performance issues can result from:

  • Insufficient pool sizes causing contention
  • Inefficient session allocation algorithms
  • Too many active sessions consuming resources
  • Session management overhead

Monitor performance metrics and adjust configurations accordingly.

Exercises

Practice these exercises to reinforce your understanding of CICS session management:

Exercise 1: Analyze Session Requirements

For a given application, analyze and document:

  • Whether the application requires Terminal Control READ requests
  • If segment processing is used
  • Whether master terminal functions are needed
  • Sign-on requirements
  • Determine if session pooling is appropriate

Exercise 2: Query Terminal Session Status

Use CEMT commands to:

  • Query the status of a specific terminal session
  • View all active terminal sessions
  • Identify session pool information
  • Review session statistics

Exercise 3: Monitor Transaction Sessions

Use CEMT INQUIRE TASK to:

  • View all active transaction sessions
  • Identify which transactions are associated with which terminals
  • Monitor transaction session duration
  • Analyze transaction session patterns

Exercise 4: Design Session Pool Configuration

Design a session pool configuration for a high-volume transaction processing application:

  • Determine appropriate pool size based on expected transaction volume
  • Document TCT configuration parameters
  • Identify any restrictions that apply
  • Plan for monitoring and optimization

Explain It Like I'm 5 Years Old

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":

  • Terminal Sessions: Think of this like having a special entrance ticket to the playground. This ticket lets you come into the playground and stay there. It's like your connection to the playground - as long as you have your ticket (terminal session), you can be in the playground.
  • Transaction Sessions: This is like actually playing a game on the playground. Each time you want to play a different game (like going on the swings, then the slide, then the seesaw), you start a new "game session" (transaction session). You can play many different games while you're in the playground with your entrance ticket.

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!

Summary

CICS session management is essential for maintaining efficient and reliable interactions between users and CICS applications. Key points to remember:

  • Terminal sessions represent the physical connection between terminals and CICS, defined in the Terminal Control Table (TCT)
  • Transaction sessions represent the logical execution of work, defined in the Program Control Table (PCT)
  • Session pooling allows multiple transactions to share a pool of TCTTE entries, improving resource utilization
  • Session pooling has important restrictions including terminal type consistency, READ request limitations, and sign-on restrictions
  • Session management tools like SM/SWAP, InterSession, and TPX provide enhanced capabilities beyond standard CICS
  • Security is critical, with authentication and authorization required for all sessions
  • CEMT commands provide facilities for monitoring and managing sessions
  • Best practices include analyzing requirements, monitoring utilization, implementing security measures, and regular optimization
  • Common issues include pool exhaustion, timeout problems, sign-on conflicts, and performance degradation

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.

Test Your Knowledge

1. What is the primary purpose of CICS session management?

  • To manage only database connections
  • To manage and control terminal sessions and transaction sessions within a CICS region
  • To monitor system performance only
  • To handle only file operations

2. What table defines terminal devices in CICS?

  • Program Control Table (PCT)
  • Terminal Control Table (TCT)
  • File Control Table (FCT)
  • Transaction Control Table

3. What is session pooling in CICS?

  • A method to pool database connections
  • A feature that allows multiple transactions to share a pool of TCTTE entries for a line
  • A way to pool memory resources
  • A technique for pooling file handles

4. Which of the following is a restriction of session pooling?

  • Multiple terminal types per line are allowed
  • Tasks can issue Terminal Control READ requests freely
  • Only one terminal type is permitted per line
  • Segment processing is fully supported

5. What does SM/SWAP allow in CICS session management?

  • A single terminal to function as up to eight logical terminals
  • Swapping memory between sessions
  • Swapping files between sessions
  • Swapping database connections

6. What is the purpose of InterSession?

  • To manage only database connections
  • To provide a unified interface for managing multiple sessions from a single screen
  • To monitor system performance only
  • To handle only file operations

7. What command or method is used to configure session pooling?

  • CEMT SET POOL
  • The POOL option in the Terminal Control Table (TCT)
  • CICS configuration file only
  • Program Control Table settings

8. What happens to a TCTTE when a transaction completes in a pooled session?

  • It is permanently deleted
  • It is released back into the pool for reuse
  • It remains assigned to the terminal
  • It is moved to a different pool