Recommended CTG/IPIC Architecture: Distributed vs. Centralized CTG Gateway with TLS

[Valliappan Nagappan]

We are planning to migrate our CICS Transaction Gateway (CTG) connectivity from our existing ECI/TCP-IP configuration to IPIC with TLS encryption. We would appreciate guidance from Gen EDGE Community members and Broadcom Gen experts on the preferred architecture and any best practices we should consider.

Current Architecture

Our application consists of C clients running on Windows workstations. Currently, each client workstation runs its own CTG Gateway daemon locally.

The current communication flow is:

C Client → Local CTG Gateway Daemon → ECI/TCP-IP → CICS

Each workstation's CTG Gateway daemon establishes connectivity directly to CICS. The current ECI communication is not encrypted.

Our objective is to migrate to IPIC with TLS, while minimizing application changes and selecting an architecture that provides appropriate scalability, availability, performance, security, and operational support.

We are considering the following two options.

Option 1 – CTG Gateway Daemon Remains on Each Client Workstation

Under this option, we would retain the existing distributed CTG architecture. Each Windows workstation would continue to run its own CTG Gateway daemon, but the CICS connection would be changed from ECI to IPIC with TLS.

Proposed flow:

C Client → Local CTG Gateway Daemon → IPIC/TLS → CICS

In this model:

• Each workstation continues to have its own CTG Gateway daemon.
• Each Gateway daemon establishes its own IPIC/TLS connectivity to CICS.
• CICS would use the appropriate TCPIPSERVICE/IPIC and IPCONN configuration.
• The existing C application architecture would remain largely unchanged.
• TLS would be handled as part of the IPIC connectivity rather than through AT-TLS.

Option 2 – Centralized CTG Gateway Daemons on Windows Servers

Under this option, we would move the CTG Gateway daemon from the individual client workstations to centralized Windows servers.

Proposed architecture:

C Clients → Load Balancer → Windows CTG Gateway Servers → IPIC/TLS → CICS

Multiple Windows servers would be deployed for high availability and scalability, with CTG Gateway daemon instances running on those servers.

The C clients would connect through a load balancer to an available CTG Gateway server. The selected Gateway daemon would then route the ECI application requests to CICS using its IPIC/TLS connection.

This approach would centralize the CTG-to-CICS IPIC connectivity and potentially reduce the number of individual IPIC connections/IPCONNs that need to be managed on the CICS side.

Guidance Requested

We would appreciate input from Gen EDGE Community members, Broadcom experts, or anyone with experience implementing similar CTG/IPIC architectures on which approach would be considered preferable or best practice.

Specifically:

1. Recommended architecture
   Is it preferable to retain a CTG Gateway daemon on each Windows client, or centralize CTG Gateway daemons on a smaller number of Windows servers?
2. IPIC connection scalability
   If we retain the distributed model, are there practical or recommended limits on the number of CTG Gateway daemons/IPIC connections connecting to a CICS region?
3. IPIC multiplexing
   In the centralized model, can a single CTG Gateway daemon efficiently service a large number of C clients and multiplex their ECI requests over a smaller number of IPIC connections/sessions to CICS?
4. CTG sizing
   What CTG parameters and resource considerations should we evaluate when sizing centralized Gateway servers-for example, maxconnect, maxworker, IPIC session limits, JVM resources, and concurrent ECI request volume?
5. High availability / load balancing
   Is placing multiple CTG Gateway servers behind a load balancer a supported/recommended configuration? Are there session-affinity or persistence considerations for ECI clients?
6. IPCONN / autoinstall
   For either architecture, what is the recommended approach for IPCONN definitions and IPCONN autoinstall, particularly when multiple CTG Gateway daemon instances connect to the same CICS environment?
7. APPLID strategy
   Should each CTG Gateway daemon be configured with a unique and persistent APPLID/APPLIDQUALIFIER rather than allowing CTG to generate an APPLID dynamically?
8. TLS certificate management
   From an operational and certificate-management perspective, are there advantages to centralizing the CTG Gateway servers rather than managing TLS configuration and certificates on every individual workstation?
9. Performance and resiliency
   Are there significant performance, throughput, recovery, or resiliency differences between these two architectures that we should consider?
10. Migration best practices
    Are there Broadcom GEN/CTG reference architectures, documentation, technical papers, or sizing guidance that would be applicable to migrating an existing distributed ECI/CTG implementation to IPIC/TLS?

Our Primary Objective

Our primary goal is to introduce TLS encryption using IPIC while selecting an architecture that will remain scalable, reliable, and supportable as the number of C clients increases.

We would particularly appreciate feedback on Option 1 vs. Option 2, including any advantages, disadvantages, sizing considerations, limitations, or best practices based on your experience.

If anyone has implemented a similar GEN/CTG/CICS IPIC architecture, we would also be very interested in hearing about your experience and lessons learned.

Thank you in advance for your guidance.

[Attila Fogarasi]

I won't comment on the GEN part of your question or on the (many) benefits
of IPIC over ECI. Be aware that AT-TLS has significant performance and cost
advantages over CICS/TLS; this is because the encryption is moved from
running on CICS TCB to the TCP/IP stack where it is zIIP eligible. Your
other question on CTG Gateway topology really hinges on the workstation
transaction rate and number of workstations. Some considerations from a
network standpoint is the CICS limit of 999 sessions per IPCONN definition
(ie. concurrent tran execution), and for restart the TCPIPSERVICE
definition BACKLOG parameter (this throttles rate of new sockets being
established, typically high during recovery/restart).
Presumably your current CTG architecture works well (per workstation), so I
would suggest staying with it and maybe put the effort into AT-TLS
instead. Adding a server layer has as many drawbacks as advantages and
doesn't add value to the application business functions.

Attila Fogarasi

Senior Technical Architect | Mainframe Software


[phone] | [e-mail]

[Valliappan Nagappan]

Hi Attila,

Thank you for your thoughts on this. That really helps.

I have a follow-up question. Considering that we are currently running CICS TS 5.6, which of the following options would work better in the context described in my initial message?

Option 1

• TCPIPSERVICE: TRANSPORT(IPIC) + SSL(YES) + CIPHERS(xmlfile)

Option 2

• TCPIPSERVICE: TRANSPORT(IPIC) + SSL(NO) + CIPHERS()
• AT-TLS policy configured separately

Could you please let us know which approach you would recommend for our environment, and if there are any considerations or limitations specific to CICS TS 5.6?

Thanks again for your guidance.

------------------------------
Valliappan Nagappan
------------------------------

[Attila Fogarasi]

I recommend option 2 which is AT-TLS replacing native CICS SSL security.
The performance advantage is offloading cpu from the CICS TCB to the TCP/IP
stack, which runs on zIIP (saving MSU).
The administrative advantage is that the z/OS Policy Agent (PAGENT) manages
the AT-TLS configuration (replacing CICS init parms), and ciphers can be
controlled globally in the AT-TLS policy (instead of the CICS XML file).
This fulfills audit and separation of duties requirements. Also RACF
keyring access is no longer needed for the CICS region userid, instead it
is the TCP/IP started task userid which is permitted to the keyring.
Finally if your CICS application requires to know the client's identity
(for example for client certificate authentication) you can configure this
in AT-TLS (by default the TLS layer is hidden from CICS).
Finally AT-TLS provides more comprehensive logging as well as creating SMF
119 records for every connection initiation and termination (more
comprehensive than the CICS SMF 110 records). This could be important for
SIEM or Auditing.

Note I don't think any of this is GEN specific, this is really a CICS &
TCP/IP usage decision.

Attila Fogarasi

Senior Technical Architect | Mainframe Software


[phone] | [e-mail]