CICS APPC Communication

APPC (Advanced Program-to-Program Communication), also known as LU 6.2, is an IBM Systems Network Architecture (SNA) protocol that enables programs running on different systems to communicate with each other. In CICS, APPC provides the foundation for distributed transaction processing, allowing CICS applications to communicate with other CICS systems or non-CICS systems over a network.

What is APPC?

APPC is an implementation of the SNA LU 6.2 protocol that allows peer-to-peer communication between application programs. Unlike traditional hierarchical SNA networks, APPC enables programs on different systems to communicate directly, making it ideal for distributed computing environments.

Key characteristics of APPC:

• Peer-to-Peer: Programs communicate as equals, not in a master-slave relationship
• Platform Independent: Works across different IBM and non-IBM systems
• Transaction Support: Provides synchronization and recovery capabilities
• Session Management: Manages logical connections between systems
• Conversation Control: Provides structured data exchange between programs

APPC Architecture Components

Understanding APPC requires familiarity with several key concepts:

Logical Units (LUs) and LU 6.2

A Logical Unit (LU) is an SNA addressable unit that manages data exchange between end users and the network. LU 6.2 is specifically designed for program-to-program communication:

• Local LU: The LU on your system that initiates or receives communication
• Partner LU: The LU on the remote system you're communicating with
• LU 6.2: The protocol type that supports peer-to-peer program communication

Sessions

A session is a logical connection established between two LUs. Sessions provide the physical pathway for conversations:

• Session Binding: The process of establishing a session between two LUs
• Parallel Sessions: Multiple sessions between the same pair of LUs for increased throughput
• Session Limits: Maximum number of concurrent sessions an LU can support
• Session Reuse: Sessions can support multiple conversations sequentially

Conversations

A conversation is the logical communication between two transaction programs (TPs). Unlike sessions, conversations are temporary and exist only while programs are exchanging data:

• Allocation: Starting a conversation between two programs
• Data Transfer: Sending and receiving data during the conversation
• Deallocation: Ending the conversation and freeing resources
• Conversation States: Different states control what operations are allowed

Transaction Programs (TPs)

Transaction Programs are application programs that use APPC to communicate:

• Local TP: The program on your system
• Partner TP: The program on the remote system
• Outbound TP: The program that initiates a conversation
• Inbound TP: The program that receives and responds to a conversation request

APPC Communication Methods in CICS

CICS supports APPC communication through several methods:

1. Distributed Transaction Processing (DTP)

DTP allows CICS transactions to communicate synchronously with transactions in other systems:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
WORKING-STORAGE SECTION.
01 WS-CONVERSATION-ID     PIC S9(8) COMP.
01 WS-RESPONSE            PIC S9(8) COMP.
01 WS-DATA-BUFFER         PIC X(100).
01 WS-DATA-LENGTH         PIC S9(4) COMP.
 
PROCEDURE DIVISION.
    * Allocate a conversation for DTP
    EXEC CICS ALLOCATE
        SYNCLEVEL(2)
        MODENAME('APPC01')
        CONVID(WS-CONVERSATION-ID)
        RESP(WS-RESPONSE)
    END-EXEC.
    
    IF WS-RESPONSE NOT EQUAL DFHRESP(NORMAL)
        EXEC CICS RETURN END-EXEC
    END-IF.
    
    * Send data to partner transaction
    MOVE 'Transaction data' TO WS-DATA-BUFFER
    MOVE 18 TO WS-DATA-LENGTH
    
    EXEC CICS SEND
        CONVID(WS-CONVERSATION-ID)
        FROM(WS-DATA-BUFFER)
        LENGTH(WS-DATA-LENGTH)
        RESP(WS-RESPONSE)
    END-EXEC.
    
    * Receive response
    EXEC CICS RECEIVE
        CONVID(WS-CONVERSATION-ID)
        INTO(WS-DATA-BUFFER)
        LENGTH(WS-DATA-LENGTH)
        RESP(WS-RESPONSE)
    END-EXEC.
    
    * Free the conversation
    EXEC CICS FREE
        CONVID(WS-CONVERSATION-ID)
        RESP(WS-RESPONSE)
    END-EXEC.
    
    EXEC CICS RETURN END-EXEC.

Key Points:

• SYNCLEVEL: Specifies synchronization level (0=none, 1=confirm, 2=syncpoint)
• MODENAME: Identifies the conversation mode defined in CICS resource definitions
• CONVID: Returns the conversation identifier for subsequent operations
• Synchronous: The local transaction waits for the remote transaction to complete

2. Distributed Program Link (DPL)

DPL allows a CICS program to call another program in a remote CICS region:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
WORKING-STORAGE SECTION.
01 WS-PROGRAM-NAME        PIC X(8) VALUE 'REMOTEPG'.
01 WS-COMMAREA            PIC X(100).
01 WS-COMMAREA-LENGTH     PIC S9(4) COMP VALUE 100.
01 WS-RESPONSE            PIC S9(8) COMP.
 
PROCEDURE DIVISION.
    * Initialize commarea
    MOVE SPACES TO WS-COMMAREA
    MOVE 'Request data' TO WS-COMMAREA
    
    * Link to remote program
    EXEC CICS LINK
        PROGRAM(WS-PROGRAM-NAME)
        COMMAREA(WS-COMMAREA)
        LENGTH(WS-COMMAREA-LENGTH)
        RESP(WS-RESPONSE)
    END-EXEC.
    
    IF WS-RESPONSE NOT EQUAL DFHRESP(NORMAL)
        EXEC CICS RETURN END-EXEC
    END-IF.
    
    * Process response in COMMAREA
    * Remote program has updated COMMAREA with results
    
    EXEC CICS RETURN END-EXEC.

3. Transaction Routing

Transaction routing allows terminals connected to one CICS system to run transactions in another CICS system:

• Terminal-Owning Region (TOR): The CICS region where the terminal is connected
• Application-Owning Region (AOR): The CICS region where the transaction runs
• Transparent: The terminal user doesn't know the transaction is running remotely

APPC Conversation States

APPC conversations exist in specific states that determine what operations are allowed:

• RESET: Initial state after allocation, ready for configuration
• SEND: Local program can send data to partner
• RECEIVE: Local program can receive data from partner
• CONFIRM: Waiting for confirmation from partner program
• CONFIRM-SEND: Can send data and waiting for confirmation
• CONFIRM-RECEIVE: Can receive data and waiting for confirmation
• SYNCLEVEL-1: Level 1 synchronization active
• SYNCLEVEL-2: Level 2 synchronization active with syncpoint coordination

Synchronization Levels

APPC supports three synchronization levels, each providing different guarantees:

Level 0 - None

No synchronization or confirmation:

• Performance: Fastest data transfer
• Reliability: No delivery confirmation
• Use Case: Non-critical data, high-volume scenarios
• Recovery: No automatic error recovery

Level 1 - Confirm

Confirmation required for data delivery:

• Performance: Moderate, with confirmation overhead
• Reliability: Delivery confirmation provided
• Use Case: Most business applications
• Recovery: Basic error recovery available

Level 2 - Syncpoint

Full transaction synchronization with syncpoint coordination:

• Performance: Slower due to syncpoint overhead
• Reliability: Full transaction integrity with ACID properties
• Use Case: Critical business operations requiring data consistency
• Recovery: Full recovery with rollback capability

APPC Resource Definitions

To use APPC in CICS, several resources must be defined:

Connection Definitions

Connections define the link between local and partner LUs:

• CONNECTION: Defines the APPC connection to a remote system
• Local LU: The LU name on your CICS system
• Partner LU: The LU name on the remote system
• Session Limits: Maximum number of concurrent sessions

Mode Definitions

Modes define the characteristics of conversations:

• MODE: Defines conversation parameters
• Sync Level: Default synchronization level for conversations
• Security: Authentication and authorization requirements
• Performance: Throughput and response time characteristics

Transaction Program Definitions

Transaction programs must be defined to handle inbound conversations:

• TP Name: The name of the transaction program
• Program: The CICS program to execute
• Transaction: The transaction ID to run the program
• Security: User ID and password requirements

Complete Example: APPC Communication

Here's a complete example demonstrating APPC communication between two CICS systems:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
IDENTIFICATION DIVISION.
PROGRAM-ID. APPCCONV01.
AUTHOR. Mainframe Master.
DATE-WRITTEN. 2024.
 
ENVIRONMENT DIVISION.
 
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-CONVERSATION-ID     PIC S9(8) COMP.
01 WS-RESPONSE            PIC S9(8) COMP.
01 WS-RESPONSE2           PIC S9(8) COMP.
01 WS-SYNCLEVEL           PIC S9(4) COMP VALUE 2.
01 WS-MODE-NAME           PIC X(8) VALUE 'APPC01'.
01 WS-DATA-BUFFER         PIC X(200).
01 WS-DATA-LENGTH         PIC S9(4) COMP.
01 WS-END-OF-CONVERSATION  PIC X(1) VALUE 'N'.
 
PROCEDURE DIVISION.
MAIN-PROCESSING.
    * Step 1: Allocate APPC conversation
    EXEC CICS ALLOCATE
        SYNCLEVEL(WS-SYNCLEVEL)
        MODENAME(WS-MODE-NAME)
        CONVID(WS-CONVERSATION-ID)
        RESP(WS-RESPONSE)
        RESP2(WS-RESPONSE2)
    END-EXEC.
    
    IF WS-RESPONSE NOT EQUAL DFHRESP(NORMAL)
        PERFORM ALLOCATION-ERROR
        EXEC CICS RETURN END-EXEC
    END-IF.
    
    * Step 2: Send request to partner transaction
    MOVE 'Customer inquiry request' TO WS-DATA-BUFFER
    MOVE 25 TO WS-DATA-LENGTH
    
    EXEC CICS SEND
        CONVID(WS-CONVERSATION-ID)
        FROM(WS-DATA-BUFFER)
        LENGTH(WS-DATA-LENGTH)
        RESP(WS-RESPONSE)
    END-EXEC.
    
    IF WS-RESPONSE NOT EQUAL DFHRESP(NORMAL)
        PERFORM SEND-ERROR
        EXEC CICS RETURN END-EXEC
    END-IF.
    
    * Step 3: Receive response from partner
    EXEC CICS RECEIVE
        CONVID(WS-CONVERSATION-ID)
        INTO(WS-DATA-BUFFER)
        LENGTH(WS-DATA-LENGTH)
        RESP(WS-RESPONSE)
    END-EXEC.
    
    IF WS-RESPONSE NOT EQUAL DFHRESP(NORMAL)
        PERFORM RECEIVE-ERROR
        EXEC CICS RETURN END-EXEC
    END-IF.
    
    * Step 4: Process the response
    * WS-DATA-BUFFER now contains the response from partner
    
    * Step 5: Issue syncpoint for level 2 conversations
    IF WS-SYNCLEVEL = 2
        EXEC CICS SYNCPOINT
            RESP(WS-RESPONSE)
        END-EXEC
    END-IF.
    
    * Step 6: Free the conversation
    EXEC CICS FREE
        CONVID(WS-CONVERSATION-ID)
        RESP(WS-RESPONSE)
    END-EXEC.
    
    EXEC CICS RETURN END-EXEC.
 
ALLOCATION-ERROR.
    EXEC CICS WRITE OPERATOR
        TEXT('APPC ALLOCATE failed')
    END-EXEC.
 
SEND-ERROR.
    EXEC CICS WRITE OPERATOR
        TEXT('APPC SEND failed')
    END-EXEC.
 
RECEIVE-ERROR.
    EXEC CICS WRITE OPERATOR
        TEXT('APPC RECEIVE failed')
    END-EXEC.

Error Handling in APPC

Proper error handling is critical for robust APPC applications:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
WORKING-STORAGE SECTION.
01 WS-CONVERSATION-ID     PIC S9(8) COMP.
01 WS-RESPONSE            PIC S9(8) COMP.
01 WS-RESPONSE2           PIC S9(8) COMP.
01 WS-ERROR-MESSAGE        PIC X(80).
 
PROCEDURE DIVISION.
    EXEC CICS ALLOCATE
        SYNCLEVEL(2)
        MODENAME('APPC01')
        CONVID(WS-CONVERSATION-ID)
        RESP(WS-RESPONSE)
        RESP2(WS-RESPONSE2)
    END-EXEC.
    
    EVALUATE WS-RESPONSE
        WHEN DFHRESP(NORMAL)
            * Success - continue processing
            CONTINUE
            
        WHEN DFHRESP(INVREQ)
            * Invalid request - check parameters
            MOVE 'Invalid APPC request' TO WS-ERROR-MESSAGE
            PERFORM ERROR-HANDLER
            
        WHEN DFHRESP(NOTFND)
            * Connection or mode not found
            MOVE 'APPC connection not found' TO WS-ERROR-MESSAGE
            PERFORM ERROR-HANDLER
            
        WHEN DFHRESP(CONVFAILURE)
            * Conversation failure
            MOVE 'APPC conversation failure' TO WS-ERROR-MESSAGE
            PERFORM ERROR-HANDLER
            
        WHEN DFHRESP(NOSPACE)
            * No session available
            MOVE 'No APPC session available' TO WS-ERROR-MESSAGE
            PERFORM ERROR-HANDLER
            
        WHEN OTHER
            * Unexpected error
            MOVE 'Unexpected APPC error' TO WS-ERROR-MESSAGE
            PERFORM ERROR-HANDLER
    END-EVALUATE.
    
ERROR-HANDLER.
    EXEC CICS WRITE OPERATOR
        TEXT(WS-ERROR-MESSAGE)
    END-EXEC.
    
    * Attempt to free conversation if allocated
    IF WS-CONVERSATION-ID NOT = 0
        EXEC CICS FREE
            CONVID(WS-CONVERSATION-ID)
            RESP(WS-RESPONSE)
        END-EXEC
    END-IF.
    
    EXEC CICS RETURN END-EXEC.

APPC vs. Other Communication Methods

Understanding when to use APPC versus other CICS communication methods:

APPC vs. MRO (Multiregion Operation)

• APPC: Used for communication between systems in different locations or sysplexes
• MRO: Used for communication between CICS regions in the same sysplex
• APPC: Requires network infrastructure (SNA or TCP/IP)
• MRO: Uses cross-memory services, no network required

APPC vs. IPIC (IP Interconnectivity)

• APPC: Uses SNA/LU 6.2 protocol over SNA network
• IPIC: Uses TCP/IP protocol over IP network
• APPC: Traditional mainframe networking
• IPIC: Modern IP-based networking, easier to integrate with non-mainframe systems

Best Practices for APPC Communication

1. Resource Management

• Always free conversations when done, even after errors
• Monitor session usage and avoid exceeding session limits
• Use appropriate sync levels for your use case
• Implement timeout mechanisms for long-running conversations

2. Error Recovery

• Check RESP and RESP2 codes after every APPC command
• Implement retry logic for transient failures
• Log all errors for troubleshooting
• Use syncpoint for critical operations requiring rollback

3. Performance Optimization

• Choose appropriate sync level (Level 0 for high volume, Level 2 for critical data)
• Minimize conversation allocation overhead by reusing sessions
• Use efficient data transfer methods
• Configure parallel sessions for increased throughput

4. Security Considerations

• Validate all input data before sending
• Use secure conversation modes for sensitive data
• Implement proper authentication and authorization
• Audit conversation activities
• Use encrypted sessions for sensitive communications

Explain It Like I'm 5 Years Old

Exercises

Quiz