India CICS User Group

TXSeries provides a tool at 'no-cost' that brings in the ability to manage the workload running in TXSeries (called WLM) available for AIX platform. In other words using this tool you will be able to cluster a set of TXSeries regions and distribute the incoming workload among these. As in any cluster you will have a set of regions that look 'similar' (or cloned regions) that provides the necessary business functions. In general, any cluster system would provide the following:

• Improved response times
• Increased service availability
• Balanced resource usage
• Maintenance without interruption

The cluster in TXSeries is similar to the cicsplex model followed in CICS TS on z/OS and maintains the same hierarchy. This means you have the same concept of COR (Client Owning Region) / TOR (Terminal Owning Region), AOR (Application Owning Region), and DOR (Data Owning Region) / FOR (File Owning Region). The COR / TOR regions would take the incoming requests, typically from one of the network dispatchers and invokes a workload management component to determine the best AOR to route the request to. The algorithm to determine the best AOR can be configured. Of course there are other implicit aspects taken care by the workload management component, which is for example if one of the AOR is down or non-responsive, the requests will be sent to another AOR.

Some of the unique benefits that this tool brings are:

• Multiple algorithms to choose from - round robin, weights, load factors, resource consumption, etc,. For example, you can specify a load factor for each CICS system allowing a balanced distribution of work
• Specify a maximum number of application servers available in each CICS system allowing better utilization of each CICS system
• Collects information about the AOR regions periodically; alternatively if there is any planned or unplanned shutdown of the CICS system it automatically informs the work load management component for not to route requests.
• Data based routing
• Upgrade / maintain regions without bringing down the entire cluster
• The AOR region configured can be a different CICS system such as CICS TS on z/OS

There are few limitations as well, that you might have to consider when designing workload management for TXSeries using this tool:

• A COR could be a single point of failure and as a result we need to configure multiple COR in the same environment.
• Multiple COR's in the same environment cannot share information of the AOR - so in effect COR1 will not be aware of the work load patterns of the AORs managed by COR2.

Also, you must be aware of some of the requirements on the applications to be able to deployable in the cluster:

• Applications should be suitable to combine on one machine. For example, they cannot share the same TDQ names
• All required facilities or dependent components must be available; CICS systems must be cloned
• All required application data must be accessible; for example, accessing of database from the CICS system
• This is most important - Application must not contain any affinities. For example, dependence on state or data available on a particular CICS region

In this blog I would like to highlight my thoughts around providing a highly available environment for TXSeries systems. I would also be talking about the High availability products that helps to achieve building a solution.

An instance of a CICS region is what constitutes a TXSeries system - which often becomes a single point of failure if your business logic (your applications) runs in the single region. A simple solution to this is to have the TXSeries product configured with HACMP (on AIX), or a container (on Solaris) high available (HA) product. Here we will define a primary and a backup server and the HA product would take care of routing the incoming requests to the backup server if the primary is down (either a planned or unplanned shutdowns). So this way your business applications is always made available for the end users - However there are pitfalls with this solution. One such pitfall is that there would be a downtime when the switch over happens between the primary and secondary servers. This can cause the end users to drop out of your system and would mandate them to reconnect to business after a short period of interval. There are other pitfalls like for instance if the primary server goes in to an hang state where it will not be able to service more requests, or the CPU consuming might be so high that it would service the incoming requests quite slowly. Hence this might NOT be an acceptable solution for a pure 24X7 environment.

The other solution I was thinking is an interesting one because it not only provides a highly available solution but also a scalable environment for your applications. I am talking about the work load management (WLM) tool coupled with the high available (HA) products. The WLM tool is provided along with the TXSeries product at no extra charge and is available only on AIX. The mix of these tools would provide a robust solution for your applications to run in a TXSeries environment.

The architecture of this solution would be such that firstly, you will need to have a network dispatcher which could spray your incoming requests across all the physical servers that are connected to it... These servers would primarily be your COR regions (Client Owning Regions) which will further send the requests to one of the AOR regions (Application Owning Regions). Your business logic would then run on these AOR regions which will service your end user requests. A major advantage that I see with this solution would be that the system is always available for the end user and there is no down time seen by the end user. The solution also manages to work load the incoming requests better because the WLM tool not only helps to re-route the requests to another AOR region when one AOR region is down, but also route requests based on the health of a given AOR region.

You might also want to have a read through on one of my earlier blogs where I detail on some of the better ways of doing work load management for TXSeries systems.

I hope some of this sharing would help you build a robust highly available solution involving TXSeries CICS product. I will be glad to hear your thoughts and comments on this. Please feel free to share any comments.

 Most of the time we are concerned about our application logic and we only check that our TXSeries transaction is running fine without any abend. We see many CICS message(ERZxxxxxx), but do we know what exactly the message is reporting us ??
Each CICS message has a significance attached to it. CICS Messages being displayed in TXSeries logs (like console, CSMT.out, CCIN.out etc) files are of format ERZxxxxxx.

Usually these CICS messages are of 3 types

1) Information messages: CICS Information messages are meant for user information purpose only. CICS Information message are of type ‘ERZxxxxxxI’. For example CICS message 'ERZ096176I'.

2) Warning message: CICS Warning messages are of format ‘ERZxxxxxxW’.CICS warning message indicate that some issue was seen while processing, but the transaction would continue execution. For example, CICS message 'ERZ004072W'.

3) Error message: CICS Error messages are of format 'ERZxxxxxxE'. CICS Error message indicates an abnormal condition while executing transaction. Usually transaction force purge or any abnormal condition in transaction leads to transaction being terminated by printing an error message in TXSeries log files. For example CICS message 'ERZ010014E'.

A CICS tool 'cicserr' provides information about CICS message codes.

cicserr can be used as cicserr [message_code].

For example
#cicserr ERZ096176I
ERZ096176I The Version is 'buffer!'
Explanation:
This message prints CICS Version information
System action:
Nothing.
User response:
Nothing

User response for the Information message would be nothing, as this message specific information. CICS users can check the 'User response' for warning and error messages and perform the necessary actions to debug the message.