Connecting to CICS
This chapter describes the communication protocols available for connecting the CICS Transaction Gateway (CICS TG) products with CICS server products. It describes at a high level the APIs supported by each protocol and the qualities of service provided.
This chapter contains the following topics:
4.1 CICS communication protocols
This section provides an overview of the various communication protocols available for use with CICS Transaction Gateway products and supported CICS server products. A more detailed technical analysis of their capabilities and qualities of service is provided in 4.3, “Quality of service and connection types” on page 50.
Over time and advances in technology, a mixture of wire protocols has been implemented by the CICS Family of products, each with its own characteristics and capabilities. There are now many possible combinations of products and protocols. It is often difficult to decide which will satisfy a specific set of application requirements.
Table 4-1 summarizes the communication protocols available to connect CICS TG products with CICS Transaction Server (CICS TS) and TXSeries products.
Table 4-1 Capabilities for CICS TG and CICS server products
|
CICS protocol
|
Available with CICS TG products
|
Connects with CICS server products
|
|
IPIC
|
z/OS
Multiplatforms Desktop Edition
|
CICS TS for z/OS
TXSeries for Multiplatforms
|
|
External CICS interface (EXCI)
|
z/OS
|
CICS TS for z/OS
|
|
TCPIP
|
Multiplatforms Desktop Edition
|
CICS TS for z/OS
CICS TS for z/VSE
TXSeries for Multiplatforms
CICS TS for System i
|
|
SNA
|
Multiplatforms Desktop Edition
|
CICS TS for z/OS
CICS TS for z/VSE
CICS TS for System i
|
4.1.1 What’s in a name?
Before proceeding any further, it is important to provide historical information regarding the names of the CICS connection protocols, known as TCPIP, ECI over TCP/IP, or ECI over IP.
|
Note: The CICS TCPIP protocol (without a slash) is a CICS Family communications protocol, operating over TCP/IP networks (with a slash). However, it is not the only CICS communications protocol to operate over TCP/IP networks.
|
At the time of its inception, the world of external CICS communications was viewed as being either Systems Network Architecture (SNA) or TCP/IP-based. The protocol drivers in the CICS TG products became known as SNA and TCPIP. Although convenient at the time, the choice of TCPIP subsequently proved to be too generic, and today causes confusion due to other CICS protocols also being built on top of TCP/IP networks. Today, both the IPIC and TCPIP CICS protocols operate over a TCP/IP network, as well as HTTP/HTTPS, Web Services, and no doubt more to follow in the future.
The TCPIP CICS Family protocol is often referred to as ECI over TCP/IP in the context of CICS TS for z/OS, or CICS TS for z/VSE, because those particular CICS server products only support ECI requests when using this protocol. Also, it is defined as “Protocol: ECI” in a CICS TCPIPService resource definition. However, the TXSeries and CICS TS for System i also support external presentation interface (EPI) requests with this protocol, and so ECI over TCP/IP is not always an appropriate name for this CICS Family protocol.
The subsequent sections of this topic provide a summary of each CICS communication protocol, in the context of the CICS TG products, CICS server products, and the CICS TG APIs.
4.1.2 IP interconnectivity (IPIC)
IPIC is a type of intersystem communications, introduced in CICS TS for z/OS V3.2. It provides a TCP/IP network-based alternative to intersystem communication (ISC) over Systems Network Architecture (ISC over SNA). It supersedes the older TCPIP protocol for ECI applications, providing enhanced capabilities, qualities of service, and cross-platform availability.
IPIC connections enable the integration of CICS-to-CICS, and CICS TG-to-CICS communications, into a TCP/IP-based network infrastructure. It also enables the use of Secure Sockets Layer (SSL) to provide secure connectivity.
IPIC is the only CICS protocol implemented by all of the CICS TG products, and is therefore available on all supported platforms. Before the CICS TG V7.1 products delivered support for IPIC, the only connectivity available with the CICS TG for z/OS product was EXCI.
IPIC provides ECI access to CICS TS for z/OS and TXSeries products over the TCP/IP network, supporting both COMMAREA and channel programs, and two-phase commit. Additionally, IPIC connections to CICS TS for z/OS support the external security interface (ESI) for password verification and change. IPIC does not provide external presentation interface (EPI) support.
Figure 4-1 shows how IPIC connectivity can be used with CICS TS for z/OS V3.2, or later. This general pattern is true for all CICS TG deployments, except that JCA resource adapters are not included with CICS TG Desktop Edition.
Figure 4-1 IPIC connectivity with CICS TS for z/OS
Figure 4-2 shows how IPIC connectivity can be used with TXSeries for Multiplatforms V7.1, or later. This general pattern is true for all CICS TG deployments, except that the JCA resource adapters are not included with CICS TG Desktop Edition.
Figure 4-2 IPIC connectivity with TXSeries
|
Note: The high-level difference between CICS TS for z/OS and TXSeries in terms of support for IPIC connectivity is that TXSeries does not support external security interface (ESI) requests for password expiry management, and it does not support password phrases.
|
4.1.3 EXCI
The External CICS Interface (EXCI) provides a means for non-CICS address spaces on z/OS to link to programs in a CICS region. For example in Figure 4-3 on page 47, EXCI allows batch jobs to connect to CICS and also allows the CICS Transaction Gateway for z/OS to make calls to CICS. The use of EXCI imposes some limits on both the client program and the CICS server program. The invoked CICS program must be a COMMAREA-based program. For the client application, use of EXCI limits the ECI request to only that portion which EXCI supports, and prevents use of external presentation interface (EPI) to invoke 3270 applications or ESI to invoke password functions in CICS.
Figure 4-3 EXCI connections with CICS TS for z/OS
4.1.4 TCPIP
When connecting to TXSeries and CICS TS for System i servers, the TCPIP connection protocol supports both ECI and EPI application programming interfaces. However, ECI requests are limited to COMMAREA-based application requests. When connecting to CICS TS for z/OS and CICS TS for VSE servers, this protocol supports only COMMAREA-based ECI requests, and is also referred to as ECI over TCP/IP.
|
Note: The TCPIP connection protocol is not supported with the CICS TG for z/OS product.
|
Figure 4-4 on page 48 shows how TCPIP connectivity can be used with CICS TS for z/OS and CICS TS for VSE. This general pattern is true for all CICS TG for Multiplatforms and CICS TG Desktop Edition deployments, except that JCA is not included with CICS TG Desktop Edition.
Figure 4-4 TCPIP connections with CICS TS for z/OS and CICS TS for z/VSE
Figure 4-5 shows how TCPIP connectivity can be used with TXSeries and CICS TS for i. This general pattern is true for all CICS TG for Multiplatforms and CICS TG Desktop Edition deployments, except that JCA is not included with CICS TG Desktop Edition.
Figure 4-5 TCPIP connections with TXSeries and CICS TS for i
4.1.5 SNA Advanced Program-to-Program Communication (APPC)
Advanced Program-to-Program Communication (APPC), also known as Logical Unit TYPE 6.2 (LU 6.2), is a Systems Network Architecture (SNA) protocol that supports both system-to-system communication and system-to-device communication. SNA connections are only supported in CICS TG for Multiplatforms and CICS TG Desktop Edition. As shown in Figure 4-6, the SNA connection protocol supports all of the gateway APIs to all CICS servers except TXSeries.
|
Note: An additional product, such as IBM Communication Manager, is required to provide SNA connectivity.
|
Figure 4-6 SNA APPC connections with the CICS TS family of products
4.2 CICS TG APIs and connection type
All CICS TG products provide both ECI and ESI programming interfaces for multiple programming languages. ECI provides access to CICS programs, with data encapsulated as COMMAREAs or channels and containers. ESI provides access to Password Expiry Management (PEM) capabilities, such as verify password or change password.
The CICS TG for Multiplatforms and CICS TG Desktop Edition products additionally provide the EPI for access to CICS terminal transactions through virtual 3270 sessions.
|
Note: Not all of the CICS TG programming interfaces are available in each CICS TG product, and not all programming interfaces included within a CICS TG product are available for use with all types of CICS connection. The choice of programming API might impose limitations on the connection type that you use.
|
Table 1-1 on page 14 summarizes the capabilities and options for connectivity between combinations of CICS TG and CICS server products. Table 4-2 on page 50 presents the same information, from the viewpoint of which API is required.
Table 4-2 Options for connectivity between combinations of CICS TG products and APIs
|
API
|
IBM CICS connection
|
||
|
CICS TG for z/OS
|
CICS TG for Multiplatforms
|
CICS TG Desktop Edition
|
|
|
ECI 1
|
EXCI
IPIC
|
IPIC
SNA
TCPIP
|
IPIC
SNA
TCPIP
|
|
ESI2
|
IPIC
|
IPIC
SNA
|
IPIC
SNA
|
|
EPI
|
N/A
|
SNA
TCPIP 3
|
SNA
TCPIP 4
|
1 Channels and containers are only available for ECI requests using IPIC CICS connections.
2 ESI is only applicable to IPIC connections to CICS TS for z/OS, or when using the SNA connection protocol to CICS TS for VSE and CICS TS for i.
3 EPI requests using TCPIP CICS connections are possible with TXSeries and CICS TS for i servers.
4 EPI requests using TCPIP CICS connections are possible with TXSeries and CICS TS for i servers.
The CICS TG information centers each include the topic, “Which API can be used?”, which provides a full cross-reference between programming language API support and CICS communications protocol available for the CICS TG for Multiplatforms and CICS TG Desktop Edition products:
The following topic is equivalent for the CICS TG for z/OS product:
4.3 Quality of service and connection types
This section takes each of the available CICS connection protocols and breaks out the capabilities and qualities of service.
There is a choice of network protocols for connecting to CICS. All protocols support ECI COMMAREA requests. Table 1-1 on page 14 shows the supported options for connecting to different CICS servers using the various protocols and client APIs. With the availability of IPIC connectivity and especially support for SSL on IPIC connections, it is now feasible to migrate many CICS TG solutions to IPIC, except for EPI-based applications. These will still require an SNA connection to support access to terminal-based transactions with CICS TS for z/OS and CICS TS for z/VSE. Because IPIC connections are the strategic direction for the CICS TG, this book will use IPIC connections in all examples and scenarios.
|
Note: EPI client applications connect to TXSeries using the TCPIP protocol rather than SNA, and to CICS TS for i using either TCPIP or SNA.
|
Performance is often a key factor in the evaluation of technology, but it is beyond the scope of this book. However, a good comparison of connection protocols is available in the IBM Redpaper™ publication, IBM CICS Performance Series: A Processor Usage Study of Ways into CICS, REDP-4906:
4.3.1 IPIC
This topic describes characteristics of CICS connections using the IPIC protocol, from the perspective of the CICS Transaction Gateway.
Key differentiators
IPIC connectivity continues to evolve and mature since its introduction in 2007, and now offers multiple benefits over the other CICS Family communication protocols:
•Channels and container support for ECI provides an improved method of exchanging data with CICS programs in amounts that far exceed the 32-KB limit that applies to COMMAREAs and additionally provides an optimized and more structured data interface.
•Very high offload to specialty processors, such as IBM zSeries Application Assist Processor (zAAP), when using CICS TG for z/OS.
Although the Gateway daemon is a Java-based address space, it switches to native code for all CICS communications protocols, except IPIC. When CICS TG for z/OS is deployed in a system with zAAP engines enabled, the offload will significantly reduce the general CPU cost per transaction.
•Higher concurrent workload capacity, especially compared to EXCI.
•Secure SSL/Transport Layer Security (TLS) connectivity to CICS TS for z/OS, or TXSeries, regardless of where the CICS TG product is deployed.
•Password phrases are supported for ECI and ESI with CICS TS for z/OS.
•Best transaction tracking capabilities, due to the provision of origin data, and integration with the Cross Component Trace (XCT) facility in WebSphere Application Server V8.5, or later.
•IPIC local mode is the only configuration offering extended architecture (XA) transaction support, for the CICS TG for Multiplatforms product.
•No support for EPI applications.
Because the CICS TG implementation of IPIC is Java and TCP/IP-based, it transparently benefits from ongoing improvements to these parts of the underlying software, for example:
•The IBM Java software development kit (SDK) regularly exploits the latest hardware offerings, for improvements in performance
•The IBM Java Secure Socket Extension (JSSE) library offers continually improving security capability, such as TLS 1.2 support, and exploitation of encryption hardware
•TCP/IP stack optimizations, for example, dynamic right sizing, or Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCE) exploitation
Transactions
IPIC connections can be used for synconreturn, extended logical unit of work (LUW), and XA transaction-based ECI requests. While all of the CICS server products support synconreturn and extended LUW transactions, CICS TS for z/OS is the only CICS server product providing support for XA transactions with IPIC connectivity.
The CICS TG for z/OS product supports XA transactions when the ECI resource adapter is deployed in local mode, for example, with WebSphere Application Server for z/OS, or remote mode, for example, with a certified Java EE application server, on any platform.
The CICS TG for Multiplatforms product supports XA transactions when the ECI resource adapter is deployed in local mode. It does not support XA transactions in remote mode.
The CICS TG Desktop Edition does not support XA transactions, because the Java EE resource adapters are not included.
|
Note: Only the CICS TG for z/OS product provides support for XA transactions in a 3-tier (remote mode) topology. Therefore, only CICS TG for z/OS can provide the combination of XA transaction support and Dynamic Server Selection capabilities for high availability, such as DSSPOLICY, or the CICS Request Exit.
|
From the application programming perspective, XA transactions are available exclusively through the ECI resource adapter, when a connection factory is configured to enlist in a global transaction. This can be achieved with either container-managed transaction (CMT) or bean-managed transactions (BMTs).
Security
IPIC connectivity offers the greatest selection of security options within the range of the CICS Family communication protocols. It allows for the selective implementation of various types of security, from identity assertion through to SSL client authentication, with full control over cipher suites.
Bind time security can be used to apply a security check when a request to establish a connection is received from, or sent to, a remote system. Its purpose is to prevent an unauthorized system from connecting to CICS. For IPIC, bind security is supported by the exchange of Secure Sockets Layer (SSL) certificates.
Link security restricts the resources that a user can access, depending on the remote system from which they are accessed. The practical effect of link security is to prevent a remote user from attaching a transaction or accessing a resource for which the link user ID has no authority.
With CICS TS for z/OS, the authority of the link comes from one of these user IDs:
•A user ID that is specified on an IPConn definition
•A user ID that is associated with a certificate received from the partner system, through an External Security Manager
User security can be used to check the received security context that flows from the requestor and determine the user ID under which the transaction executes. For ECI requests, the received security context (user ID and either password, or password phrase) is usually specified by the ECI application, or for Java EE applications, it can be specified in the ECI connection factory custom properties: userName and Password. With IPIC connections using SSL, the received security context can be derived from a client certificate.
Identity assertion is a special form of user security, where the transaction operates under the user ID specified by the requestor, without a password or password phrase credential. This is allowed in CICS TS for z/OS with IPIC connections, when the partner system meets these conditions:
•In a z/OS logical partition (LPAR) within the same sysplex
•Using a secure SSL IPIC connection
Identity propagation can be viewed as an extension of identity assertion, allowing a pre-validated distributed identity, from a non-System Authorization Facility (SAF)-based security domain, to be propagated from WebSphere Application Server to CICS. Identity propagation is only available with IPIC connections.
For further detail about identity propagation support in CICS Transaction Gateway, see the Information Center topic, Identity propagation:
http://ibm.co/1mYB2xG
For full details, see z/OS Identity Propagation, SG24-7850:
IPIC supports ESI requests, allowing application programs to perform password expiry management (PEM) operations, including change and verify password.
For full details about IPIC security with CICS TS for z/OS, see the Information Center topic, Implementing IPIC security:
http://ibm.co/WjtHyu
Capacity limits
Capacity for IPIC connections is determined by the number of sessions made available. The total number of IPIC sessions, across multiple connections, that can be created, are subject to available Java heap storage in either the Gateway daemon, or the Java EE application server (local mode).
Each IPIC connection is configured to have a specific number of logical sessions available, and a hard limit on that number is imposed by architectural limits in the CICS server product. Since the introduction of IPIC with CICS TS for z/OS V3.2, this limit remains at 999 sessions.
Given that multiple IPIC connections can be used concurrently, to multiple CICS server instances (or to a single CICS server instance), it is clear that the number of concurrent requests is now constrained only by the capacity for work in the connected CICS servers, the Gateway daemon (number of work threads), or the source of the workload, for example, WebSphere Application Server.
|
Note: With the CICS TG for z/OS product, full exploitation of IPIC capacity is only possible by disabling EXCI support. If EXCI support is not disabled, the maximum number of concurrent requests per Gateway daemon is constrained by the LPAR configuration value, LOGONLIM. This optional CICS configuration value has a default of 100 and a maximum possible value of 250.
|
At run time, a negotiation is made during connection establishment and the session limit is determined to be the lower of the two values, defined on each side.
|
Note: Before CICS TG V9.0, local mode IPIC connections always negotiated to 100 sessions. With CICS TG V9.0, or later, the ECI connection factory allows the number of sessions to be defined, through the custom property ipicSendSessions.
|
High availability options
Remote mode configurations can use multiple Gateway daemon address spaces, within one or more LPARs, to form a highly available Gateway group. A single port of entry can be used to balance connections between client applications and Gateway daemons, allowing the group of Gateway daemons to act as a single logical Gateway daemon. Such a configuration can provide redundant capacity to take up extra workload in the event of a planned or unplanned outage. It can also be used as a pattern to scale capacity. IPIC connectivity can be used in such configurations.
The TCPIPService listener port for an IPIC connection between CICS TG and CICS TS for z/OS must not be used in conjunction with any TCP/IP port sharing technology for the following reasons. First, XA transaction recovery must be completed with the same CICS server instance, and so reconnection with the same CICS region must be assured. Also, CICS TS for z/OS V4.1 delivered scalability improvements, using multiple TCP/IP sockets for each IPIC connection, and these related sockets must connect to the same CICS server instance.
IPIC connections can be used with any of the available Dynamic Server Selection capabilities available in the CICS TG products. However, individuals, who want to migrate from EXCI and who used the DFHXCURM exit program, must convert to either a DSSPOLICY definition, or implement equivalent logic in the Java-based CICS Request Exit.
Timeout behavior
IPIC connectivity caters for request timeout at both the application request level and at a connection establishment level.
ECI application programs can optionally specify a timeout value on a request-by-request basis. If this value expires before a response is received from the CICS server, the application receives a timeout error response. The mirror transaction in the CICS server is abended, or marked to abend when it completes, depending on whether it is defined with the SPURGE attribute set to YES.
CICS TG V9.0 introduced an alternative ECI request timeout option for IPICSERVER definitions, ecitimeout. This is designed as a safety mechanism, allowing system administrators to impose an overriding time limit for ECI requests, particularly where application code does not specify a sensible timeout value. This is especially useful for those migrating from EXCI, where the granularity for timeout was at the level of a Gateway daemon, or WebSphere Application Server instance (through the DFHXCOPT table). It supersedes any application-coded ECI timeout value at run time.
The server retry interval specifies the time in seconds between attempts to reconnect to a CICS server over an IPIC connection, following a loss of connectivity. This capability is available only in remote mode, and it is predefined to be inactive for local mode IPIC connections.
The server idle timeout value specifies the period of inactivity, after which an IPIC connection and the CICS server are closed. This capability can be configured in remote mode, but it is disabled for local mode IPIC connections.
|
Note: The default value for server idle timeout on IPIC connections, local and remote mode, changed from 60 to 0 seconds (zero means disabled) starting from CICS TG V9.0.
|
The connect timeout value specifies the time to wait for CICS to respond during connection establishment. A higher value might be inappropriate for IPIC connections that participate in a high availability group, because it is preferable to fail over quickly when a CICS server becomes unavailable.
Autoinstall
Specific IPIC connection resources (IPConns in CICS TS and Communication Definitions in TXSeries) can be dynamically created at run time, rather than explicitly defined and installed, one by one. This is often useful when connections with many partner systems are required, or short-lived connections, such as might be required in a development or test environment.
The following description of autoinstall applies to the CICS TS for z/OS product.
When an IPIC TCPIPService is defined, the Urm attribute is set to DFHISAIP, by default. DFHISAIP is a CICS-supplied, pre-built autoinstall user program. When a partner system, such as CICS Transaction Gateway, attempts to establish an IPIC connection with CICS TS for z/OS, it looks for a matching IPConn definition to use. If no matching IPConn definition is found, the autoinstall user program is invoked to generate an IPConn definition automatically.
The autoinstall of IPConn resources can be disabled in CICS TS for z/OS, by specifying the value No in the Urm attribute of the TCPIPService definition.
For further details about using IPIC autoinstall with CICS TG and WebSphere Application Server, see 4.4, “IPIC autoinstall for WebSphere Application Server clusters” on page 64.
For a good overview of IPIC autoinstall with CICS TS for z/OS, see the Information Center topic, Autoinstalling IPIC connections; preliminary considerations:
http://ibm.co/1rxNyVn
4.3.2 EXCI
This topic describes characteristics of CICS connections using the EXCI protocol, from the perspective of the CICS Transaction Gateway.
Key differentiators
EXCI connectivity is the original protocol used by CICS TG for z/OS to connect with CICS TS for z/OS. For this reason, it offers limited qualities of service due to architectural constraints:
•Available only on the z/OS platform, in remote and local mode configuration.
•Support for ECI applications is provided:
– No channel and container support. Only the COMMAREA convention is supported for exchanging data with CICS programs, and so application requests are constrained to the 32-KB architectural limit.
– Limited timeout capability.
•No support for EPI and ESI applications.
•Password phrases are supported for ECI requests.
•XA transaction support.
•Performance with EXCI can be favorable when compared like for like with IPIC, in terms of overall transaction CPU cost.
The potential for offload to zAAP engines is limited compared to IPIC, because a significant portion of the implementation is ineligible.
•Scalability of EXCI is constrained by the architectural limitations of EXCI pipes.
Transactions
EXCI connections can be used for synconreturn, extended LUW, and XA transaction-based ECI requests. The CICS TG for z/OS product supports XA transactions when the ECI resource adapter is deployed in local mode, for example, with WebSphere Application Server for z/OS, or remote mode, for example, with a certified Java EE application server.
|
Note: If you are using extended LUW and XA transaction ECI requests on EXCI connections in a sysplex environment, the CICS Transaction Gateway instance must run on the same LPAR as the CICS server. This is a CICS TS for z/OS limitation.
|
Security
The security options available for CICS TG configurations using EXCI connections are less complex than IPIC, but effective. Because EXCI uses cross-memory communications, there is no need to consider encryption techniques, such as SSL, and the Gateway daemon never supplies a password or password phrase credential to CICS.
Bind time security, also called multiregion operation (MRO) bind security, verifies that the system wanting to connect to CICS is authorized to do so. It is implemented using two DFHAPPL FACILITY class profiles: DFHAPPL.<DFHJVPIPE> and DFHAPPL.<APPLID>.
Link security is an additional level of authorization checking applied to the attaching transaction. A specific user ID (the link user ID) can be thought of as the user ID associated with the partner system sending a request to CICS. This can be explicitly defined within the CICS region SESSIONS definition for the EXCI connection; otherwise, the user ID of the Gateway daemon address space is used. Both the link user ID and the flowed user ID must be authorized to access all transactions and resources invoked as a result of the request.
User security causes a check to be made against the flowed user ID when an inbound request attaches the transaction in CICS. For ECI requests, the received security context is usually specified by the ECI application, or for Java EE applications, by the ECI connection factory custom property, userName. With EXCI connections, only the user ID credential is flowed to CICS TS for z/OS. It is assumed that the user ID has already been authenticated, either by the Gateway daemon in remote mode, or in WebSphere Application Server for z/OS, in local mode.
Surrogate user checking is another security mechanism available for EXCI connectivity, which is useful when the EXCI client (Gateway daemon or WebSphere Application Server) address space user ID is the same as the target CICS region user ID. This might be true when using a common user ID for started procedures.
In such a case, the link security check is bypassed and so a surrogate user check is advised. A surrogate user check is performed to verify that an EXCI client address space user ID is authorized to issue DPL calls for another user (that is, is authorized as a surrogate of the user ID specified on the ECI request).
For full details about EXCI security with CICS TS for z/OS, see the Information Center topic, Implementing EXCI security:
Capacity limits
Capacity for EXCI connections is constrained by an architectural limit of CICS TS for z/OS, imposed on each EXCI client address space. Each ECI request uses a single EXCI pipe, and the maximum number of pipes available per address space is governed at the LPAR level, by the LOGONLIM parameter. LOGONLIM has a default value of 100, and a maximum configurable value of 250.
Running a Gateway daemon with EXCI enabled effectively constrains its overall capacity, by imposing the same restriction (LOGONLIM) on the maximum number of worker threads.
CICS TG for z/OS offers two usage models for EXCI pipes. The pipe reuse model known as ALL allows worker threads to cache pipes, offering improved performance, but compromising concurrent capacity when connecting with multiple CICS TS for z/OS regions. To avoid the possibility of running out of EXCI pipes, the number of concurrent requests must be constrained to LOGONLIM divided by the possible number of CICS regions available for connection.
The EXCI pipe reuse model known as ONE does not cache pipes to worker threads and so allows full exploitation of the maximum number of EXCI pipes defined by LOGONLIM.
Each EXCI connection is configured to have a specific number of logical sessions available, and it is limited by the RECEIVECOUNT parameter defined in the CICS MRO SESSIONS definition. This needs to be at least equal to the maximum number of worker threads in a connected Gateway daemon or the pool size for local mode connection factories in WebSphere Application Server for z/OS.
High availability options
Remote mode configurations can use multiple Gateway daemon address spaces, within one or more LPARs, to form a highly available Gateway group. A single port of entry can be used to balance connections between client applications and Gateway daemons, allowing the group of Gateway daemons to act as a single logical Gateway daemon. Such a configuration can provide redundant capacity to take up extra workload in the event of a planned or unplanned outage. It can also be used as a pattern to scale capacity. EXCI connectivity can be used in such configurations.
In remote mode, EXCI connectivity can also be used with any of the Dynamic Server Selection capabilities available in the CICS TG for z/OS product. However, it is a preferred practice to avoid the use of a Dynamic Server Selection function of the Gateway daemon, together with the EXCI exit program, DFHXCURM. This combination will lead to confusion because the target CICS system selected by the Gateway daemon can be subsequently modified by DFHXCURM. Gateway daemon monitoring and statistics values will be ambiguous because the usage of DFHXCURM is transparent to the Gateway daemon.
Local mode configurations with WebSphere Application Server for z/OS can use a cluster of servant regions for high availability and use EXCI connectivity. However, each servant region is also subject to the LOGONLIM capacity constraint, and must use a dedicated, specific EXCI connection to avoid sharing the limited number of sessions (RECEIVECOUNT) in the target CICS region.
|
Note: CICS Transaction Gateway capabilities for Dynamic Server Selection are not available in local mode, but the EXCI user exit DFHXCURM can be used.
|
For a more thorough description of workload management within the CICS TG, see 7.3, “Dynamic server selection” on page 116.
Timeout behavior
The granularity of the possible timeouts in an EXCI connection is limited. You can set a TIMEOUT in the EXCI options table DFHXCOPT. This setting is then used by the EXCI to terminate any requests that have been waiting too long for a DPL_Request command to complete. It is also possible to have a transaction timeout (such as RTIMEOUT and DTIMEOUT) but it is not an end-to-end timeout.
Autoinstall
There is no autoinstall of EXCI MRO connections.
Although there is no autoinstall capability for EXCI, generic connections offer a useful alternative in development and test environments. Using a generic EXCI connection (CONNTYPE: GENERIC) allows Gateway daemon, WebSphere Application Server, and EXCI batch jobs to share a single connection, avoiding the need to install individual connections. However, be careful to ensure that an adequate number of sessions are available, through the associated SESSION definition attribute, RECEIVECOUNT.
Because it is not possible to reserve a subset of sessions within the generic EXCI connection for a particular EXCI client, they are not advised for use with CICS TG for z/OS configurations in production.
4.3.3 TCPIP
This topic describes characteristics of CICS connections using the TCPIP protocol, from the perspective of the CICS Transaction Gateway.
Key differentiators
TCPIP connectivity is the original CICS Family protocol to operate on TCP/IP-based networks. For this reason, it has some limitations when compared with IPIC:
•Available only with the CICS TG for Multiplatforms and CICS TG Desktop Edition products, in remote and local mode configuration
•Provides connectivity to all supported CICS servers
•Provides ECI capability with all supported CICS servers
No channel support. Only the COMMAREA convention is supported for exchanging data with CICS programs, and so application requests are constrained to the 32-KB architectural limit.
•Provides EPI capability with TXSeries and CICS TS for i
•No support for ESI
•No SSL - encryption only possible by using virtual private network (VPN) solutions
Transactions
TCPIP connections can be used for synconreturn and extended LUW transaction ECI requests to all supported CICS server products. There is no support for XA transactions.
Security
TCPIP connectivity to CICS servers offers the following security options:
•Bind time security can be used to prevent unauthorized remote systems from connecting to CICS. There is no specific method for implementing bind time security with TCPIP. However, the goal of bind time security can be achieved using standard TCP/IP firewall solutions.
•Link security is not supported for TCPIP CICS server connections.
•User security can be used to check the received user ID and password that flow from the requestor and determine the user ID under which the transaction operates. This can be used by the CICS server to restrict the CICS resources that can be accessed by a user. For ECI requests, the received user ID and password are usually specified by the ECI application. Or for Java EE applications, it can be specified in the ECI connection factory custom properties: userName and password. For EPI requests, the user ID and password can be set by the user application at the terminal or connection level, with the value for the terminal taking precedence. Or for Java EE applications, it can be specified in the EPI connection factory custom properties: userName and password.
With CICS TS for z/OS, there are only two options for user security with the TCPIP protocol:
•No security:
– No authentication takes place.
– Transactions are attached in CICS under the authority of the CICS default user.
•User ID and password authentication:
– The flowed user ID and password are authenticated by the External Security Manager.
– Transactions are attached in CICS under the authority of the flowed user ID.
There is no capability to attach transactions under the authority of the flowed user ID without a password credential.
Capacity limits
Unlike the other CICS communication protocols available for use with the CICS TG products, the TCPIP protocol is not constrained by a maximum number of logical sessions associated with the connection definition.
TCPIP connectivity is provided by the Client daemon component of both the CICS TG for Multiplatforms and the CICS TG Desktop Edition products. The maximum number of concurrent requests is limited by the maximum number of requests that the Client daemon is configured to process, across all defined CICS server connections. This is determined by the Client daemon configuration option, MAXREQUESTS.
High availability options
Remote mode applications using TCPIP connections can use the Dynamic Server Selection capabilities available in the Gateway daemon, the default CICS server definition, and the CICS request exit.
For CICS TG for Multiplatforms or CICS TG Desktop Edition on the Windows platform, an additional option, for both remote and local mode applications, is the Windows Workload manager. This capability allows a set of TCPIP connections to be treated as a single logical CICS server connection, with the option to provide weighting on the distribution of requests.
However, it is a preferred practice to avoid the use of a Dynamic Server Selection function of the Gateway daemon, together with the Windows Workload manager capability. This combination will lead to confusion because the target CICS system selected by the Gateway daemon can be subsequently modified by the Windows Workload manager feature.
Timeout behavior
TCPIP connectivity caters for request timeout at both the application request level and at a connection establishment level.
ECI application programs can optionally specify a timeout value. If this value expires before a response is received from the CICS server, the application receives a timeout error response. The mirror transaction in the CICS server is abended, or marked to abend when it completes, depending on whether it is defined with the SPURGE attribute set to YES.
The server retry interval specifies the time in seconds between attempts to reconnect to a CICS server over a TCPIP connection, following a loss of connectivity. Unlike IPIC connections, which allow a server retry interval to be defined on a per-connection basis, TCPIP (and SNA) connections share a single value, defined at the Client daemon level.
The server idle timeout value specified on a server definition for the TCPIP connection protocol specifies the period of inactivity, after which a TCPIP connection to a CICS server is closed.
The connect timeout value specifies the time to wait for CICS to respond during connection establishment. This capability is defined on a per-connection basis. A higher value is might be inappropriate when using Dynamic Server Selection because it is preferable to fail over quickly when a CICS server becomes unavailable.
EPI application programs can optionally specify a terminal install timeout value, and a read timeout value. The install timeout controls the time to wait for a terminal to be installed on a CICS server. If a response is not received from the server within the specified time, control is returned to the user application with an appropriate return code. The read timeout value controls the maximum length of time that the CICS Transaction Gateway will wait for a response from the user application after it has issued an EXEC CICS RECEIVE or CONVERSE command.
Autoinstall
For connections to TXSeries using the CICS Family TCPIP protocol, connections can be autoinstalled. For connections to CICS TS for z/OS or CICS TS for z/VSE using the CICS Family TCPIP protocol, connections must be predefined.
4.3.4 SNA
This topic describes characteristics of CICS connections using the SNA (APPC) protocol, from the perspective of the CICS Transaction Gateway.
Key differentiators
CICS connections using the SNA protocol have these differentiators:
•Available only with the CICS TG for Multiplatforms and CICS TG Desktop Edition products, in remote and local mode configuration.
•Support for ECI, ESI, and EPI.
No channel support with ECI. Only the COMMAREA convention is supported for exchanging data with CICS programs, and so application requests are constrained to the 32-KB architectural limit.
•It requires an additional software product to provide SNA connectivity, such as IBM Communications Server for Data Center Deployment.
The CICS TG for Multiplatforms and CICS TG Desktop Edition products, up to and including V9.0, require 32-bit SNA API libraries. Some SNA server products might install 64-bit SNA API libraries on 64-bit platforms, by default. For more information about how to install 32-bit SNA API libraries on 64-bit platforms, see your SNA server documentation.
•SNA APPC is not supported between CICS TG products and TXSeries. Use IPIC or TCPIP.
•It is possible to set up a connection using Enterprise Extender, which provides an SNA transport over TCP/IP, where the LU6.2 protocol is encapsulated in TCP/IP packets for transmission across the consolidated IP backbone.
Example configurations using Enterprise Extender are in the IBM publication, Migrating an SNA connection from TCP62 to Enterprise Extender, GC34-6889-00.
For supported products and levels, see the Supported Software topic in the Information Center of CICS TG for Multiplatforms.
Transactions
SNA connections can be used for synconreturn and extended LUW transaction ECI requests to all supported CICS server products. There is no support for XA transactions.
Security
SNA APPC connectivity to CICS servers offers the following security options:
•Bind time security can be used to prevent an unauthorized system from binding a session to CICS. A security check can be applied when a request to establish an APPC session is received from, or sent to, a remote system; that is, when the session is bound. In SNA terms, this is known as session security.
With CICS TS for z/OS, SNA APPC bind time security is implemented using a combination of CICS system initialization parameters (SEC=YES and XAPPC=YES), with the SAF profile, APPCLU.
•Link security is an additional level of authorization checking applied to the attaching transaction. A specific user ID (the link user ID) can be thought of as the user ID associated with the partner system sending a request to CICS.
With CICS TS for z/OS, this can be explicitly defined within the CICS region CONNECTION definition (SECURITYNAME), or SESSION definition (USERID) for the SNA APPC connection. If you do not specify a link user ID, CICS TS for z/OS uses the CICS default user ID. Both the link user ID and the flowed user ID must be authorized to access all transactions and resources invoked as a result of the request.
•User security can be used to check the received user ID and password that flow from the requestor and determine the user ID under which the transaction operates. This can be used by the CICS server to restrict the CICS resources that can be accessed by a user. For ECI requests, the received user ID and password are usually specified by the ECI application. Or for Java EE applications, it can be specified in the ECI connection factory custom properties: userName and password. For EPI requests, the user ID and password can be set by the user application at the terminal or connection level, with the value for the terminal taking precedence. Or for Java EE applications, it can be specified in the EPI connection factory custom properties: userName and password.
With CICS TS for z/OS, there are only two options for user security with the SNA APPC protocol:
•No security:
– No authentication takes place.
– Transactions are attached in CICS under the authority of the CICS default user.
•User ID and password authentication:
– The flowed user ID and password are authenticated by the External Security Manager.
– Transactions are attached in CICS under the authority of the flowed user ID.
There is no capability to attach transactions under the authority of the flowed user ID without a password credential.
SNA APPC supports ESI requests, allowing application programs to perform password expiry management (PEM) operations, including change and verify password.
For full details about SNA APPC security with CICS TS for z/OS, see the Information Center topic, Implementing LU6.2 security:
Capacity limits
The workload capacity for SNA APPC connectivity is primarily governed by sessions.
With CICS TS for z/OS, the SESSIONS definition (MAximum) is configured to specify the maximum number of sessions to be supported, and the number of contention-winner sessions (CICS-owned sessions). These values are negotiated during change number of sessions (CNOS) flows, when the sessions are actually bound; the negotiated values depend on the settings specified in the partner SNA node.
The maximum number of sessions must be at least as big as the MAXREQUESTS parameter in the CLIENT section of the CICS TG configuration file, to prevent creating a bottleneck to throughput. The contention-winner sessions must be set to 001 to ensure that START requests for terminal transactions are shipped serially from the server to the client.
With CICS TG for Multiplatforms, or CICS TG Desktop Edition, the partner SNA node is configured through an SNA server product, such as IBM Communications Server, where the number of sessions is defined in relation to the mode name for the APPC connection.
The maximum number of concurrent requests is also limited by the maximum number of requests that the Client daemon is configured to process, across all defined CICS server connections. This is determined by the Client daemon configuration option, MAXREQUESTS.
High availability options
SNA APPC connectivity can exploit the z/OS Communications Server generic resource function to balance workload between available CICS TS for z/OS regions. CICS TS for z/OS regions are assigned two APPLIDs, a generic one and a specific one. The IBM VTAM® component of z/OS Communication Server maintains a mapping between the generic APPLID, and the specific CICS APPLIDs that are members of a generic resource name.
The CICS TG for Multiplatforms or CICS TG Desktop Edition product is configured with an SNA connection, using the generic CICS APPLID. This also allows VTAM to perform dynamic workload balancing of the sessions across the available CICS TS for z/OS regions.
Remote mode applications using SNA APPC connections can exploit the Dynamic Server Selection capabilities available in the Gateway daemon, the default CICS server definition, and the CICS request exit.
For CICS TG for Multiplatforms or CICS TG Desktop Edition on the Windows platform, an additional option, for both remote and local mode applications, is the Windows Workload manager. This capability allows a set of SNA APPC connections to be treated as a single logical CICS server connection, with the option to provide weighting on the distribution of requests.
However, it is a preferred practice to avoid using the Dynamic Server Selection function of the Gateway daemon together with the Windows Workload manager capability. This combination will lead to confusion because the target CICS system selected by the Gateway daemon can be subsequently modified by the Windows Workload manager feature.
Timeout behavior
SNA APPC connectivity caters for request timeout at the application level and at the configuration level.
ECI application programs can optionally specify a timeout value. If this value expires before a response is received from the CICS server, the application receives a timeout error response. The mirror transaction in the CICS server continues to runs until the CICS program ends.
For synconreturn requests, the CICS program will complete its syncpoint normally, irrespective of the ECI timeout value, and the mirror transaction ends. For extended LUW requests, the mirror transaction is suspended, waiting for a further request. If the mirror transaction PROFILE is defined with a suitable read timeout value (RTIMOUT) and is defined with the SPURGE attribute set to YES, it will abend due to read timeout expiration.
The server retry interval specifies the time in seconds between attempts to reconnect to a CICS server over an SNA connection, following a loss of connectivity. Unlike IPIC connections, which allow a server retry interval to be defined on a per-connection basis, SNA (and TCPIP) connections share a single value, defined at the Client daemon level.
The server idle timeout value specified on a server definition for the SNA connection protocol specifies the period of inactivity, after which an SNA connection to a CICS server is closed.
EPI application programs can optionally specify a terminal install timeout value, and a read timeout value. The install timeout controls the time to wait for a terminal to be installed on a CICS server. If a response is not received from the server within the specified time, control is returned to the user application with an appropriate return code. The read timeout value controls the maximum length of time that the CICS Transaction Gateway will wait for a response from the user application after it issues an EXEC CICS RECEIVE or CONVERSE command.
Autoinstall
Specific SNA APPC connection resources can be dynamically created at run time, rather than explicitly defined and installed, one by one. This is often useful when connections with many partner systems are required, or short-lived connections, such as might be required in a development or test environment.
The following description of autoinstall applies to the CICS TS for z/OS product.
The CICS ISC capability must be enabled, if not already (ISC=YES). You must select your preferred autoinstall program. The CICS-supplied autoinstall exit program, DFHZATDY, can be used to provide APPC autoinstall (AIEXIT=DFHZATDY). The correct 'template' connection that will be used to create the new connection must also be installed.
When an APPC device attempts to log on to the CICS TS for z/OS region, a check for a matching APPC connection definition is made. If no matching definition is found, the autoinstall program is driven to generate a definition, based on the closest matching template definition.
|
Note: CICS TS for z/OS can be configured with a maximum number of concurrent logon requests (AIQMAX), which can result in the temporary suspension autoinstall activity.
|
4.4 IPIC autoinstall for WebSphere Application Server clusters
When using the CICS ECI resource adapter in a local mode topology from WebSphere Application Server to establish an IPIC connection to CICS TS, it is a preferred practice to specify APPLIDQUALIFIER and APPLID values in the Java EE Connector architecture connection factory custom properties, to identify the source of requests in monitoring data.
With a single application server configuration, the IPConn resource in CICS TS can be predefined or autoinstalled. However, if you are using a WebSphere Application Server cluster configuration, autoinstalled connections, which use the CICS default IPIC autoinstall user program, DFHISAIP, or predefined IPIC connections will encounter problems due to duplicate client identifiers.
The problem occurs when a Java EE application uses a cluster scope Java EE Connector architecture connection factory or multiple Java EE Connector architecture connection factory definitions with the same APPLIDQUALIFIER and APPLID values and displays the following symptoms:
1. The first application server in the cluster sends an ECI request to CICS TS causing an IPIC connection to be installed (either predefined or autoinstalled) and acquired.
2. Then, a different application server sends another ECI request. CICS TS tries to use the same IPCONN resource definition already installed, because the APPLIDQUALIFIER and APPLID values match, but rejects the request because that IPCONN resource is still in the acquired state by the first application server. The following error message DFHIS1015 is issued to the MSGUSR job log of the CICS TS region:
“Unable to accept connection for IPCONN ipConnName. IPCONN client session state is invalid.”
One solution to this problem is to leave the APPLIDQUALIFIER and APPLID values in the connection factory blank. In that case, DFHISAPI will generate values upon connection. However, this makes transaction tracking difficult because the generated values are transitory and will not be so useful for audit or debug purposes.
CICS TS 5.1 provides a better solution to this limitation through new sample IPIC autoinstall programs DFH$ISAI (Assembler) and DFH0ISAI (COBOL). These create IPCONN resources based on a template IPCONN resource definition, whose name and Applid attribute values must match the APPLIDQUALIFIER and APPLID of the partner respectively. If the connection request is accepted, the autoinstalled IPCONN name and its Applid attribute value will be dynamically generated using the partner APPLID followed by a unique integer suffix. The Networkid attribute will be set to the APPLIDQUALIFIER.
For example, assume the following definitions:
•Java EE Connector architecture connection factory custom properties:
– APPLIDQUALIFIER value CTGAPQAL
– APPLID value CTGAPPL
•CICS TCPIPSERVICE resource definition attributes:
URM value DFH0ISAI
•CICS IPCONN resource definition template called CTGAPQAL with attribute:
Applid value CTGAPPL
The following steps show the behavior for connecting from a WebSphere Application Server cluster:
1. The first IPIC connection request from an application server to that CICS TS region results in an IPCONN resource definition called CTGAPPL1 with an Applid attribute value of CTGAPPL1 and Networkid attribute value of CTGAPQAL being installed.
2. The next IPIC connection request to that CICS TS region from a different application server instance results in an IPCONN resource definition called CTGAPPL2 with an Applid attribute value of CTGAPPL2 and Networkid attribute value of CTGAPQAL being installed.
3. Subsequent connection requests from the same application server will reuse the IPCONN resource installed by the first request from that application server and will remain installed and acquired until the application server is shut down.
|
Note: The alternative Urm appends a counter value to the APPLID value in the connection factory. Because the maximum length of the APPLID attribute is eight characters, the value set in the connection factory determines the maximum possible number of application server instances able to connect with a common identification.
|
The sample autoinstall user programs DFH$ISAI and DFH0ISAI are provided as precompiled load modules in the load library, CICSHLQ.SDFHLOAD, and can be used directly, provided that the APPLID value in the ECI connection factory definition is no more than seven characters in length. Alternatively, the samples can be customized using the source code provided in the partitioned data set, CICSHLQ.SDFHSAMP. For more information, see the CICS TS Information Center topic, Sample autoinstall user program to support predefined connection templates:
The CICS TG Information Centers include several scenarios that demonstrate how to configure IPIC connections:
•SC01. Configuring a secure autoinstalled IPIC connection
•SC02. Configuring a secure predefined IPIC connection
•SC07. Configuring SSL between CICS TG and CICS TS
•SC08. Configuring an autoinstalled IPIC connection
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.