India CICS User Group

Correspondendo a: cics

Workload Management in TXSeries and its Unique Benefits:

invhariharan Marcações: wlm cics cicsplex workload txseries ‎ 2 Comentários ‎ 4.362 Visualizações

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

The tool can also help in building highly available solutions for TXSeries in an active-active configuration, as an alternative or in-conjunction with the HACMP environment for TXSeries. Overall the WLM tool provides a one-stop solution for managing workloads for TXSeries systems, including a web based administration of WLM components and simple-to-use configuration through the 'cicswlmcfg' master command.

India CICS User Group Conference 2011

namasevi Marcações: conference cics 2011 websphere ibm india ‎ 8.443 Visualizações

It's time for this year's CICS User Group conference in India again. This year's CICS User Group conference in India is being held at the southern city of Chennai for a day on the 19th September, 2011.

IBM's CICS is 40+ years old and still keeps evolving. CICS continues to be one of the most powerful, reliable, scalable and secure application environments because of it's deep integration with underlying z/OS operating system. Most of fortune 100 and top 50 banks in the world trust CICS to run their core, mission critical business applications. With the recent release of CICS v4.2 , it's the right time for all of you to hear what's going on in the CICS world.

If you have CICS interest of any kind, as a developer, administrator or otherwise, you should not miss the one-day event being held at "Trident Hotel", in Chennai. This event is a full day event starting from 8 AM and going on upto 6:00 PM in the evening. Some of the key highlights of this event are,

Keynote address by Dave Andrews - CICS Director
Evolution of CICS V4.2 - Events Processing, Connectivity and Scalability
Modernize , Extend and Re-use COBOL assets with WebSphere eXtended Transaction Runtime

Along with CICS TS v4.2, IBM introduced a new addition to it's transaction processing portfolio called WebSphere eXtended Transaction Runtime (WXTR). Version 1 of this product was release in June 2011 as well. There would be a session and a poster presentation at this year's CUG on WXTR.

Here's a view of detailed CUG India 2011 agenda,

Program Auto Install in TXSeries

invhariharan Marcações: auto txseries install cics program ‎ 1 Comentário ‎ 5.509 Visualizações

Well, program auto install is a feature provided in the CICS system which would allow you to define a CICS program at run-time. Usual or common way of defining a program to a TXSeries system would be to add an entry in to the PD definition with the help of a RDO command; say, cicsadd -c pd -r region1 MYPROG PathName=myprog.ibmcob. This process of registering the programs is good if you have limited number of CICS programs that you need to define; however in certain cases the number of application programs are many (say hundreds) in which case it is cumbersome to not only define these many entries in to the PD definition but also will be difficult to maintain and manage them. This is where the program auto install feature would come handy. Let's see how this works:

When a request is received from the client (say a request to run a transaction) CICS system attempts to find the corresponding program to be loaded/executed by looking at the TD definition. Further CICS checks to see if there is a corresponding program entry in the PD definition. If exists it goes ahead, load the program and executes them. But if the program entry does not exist in the PD definition.. this is where the program auto install process kicks in.

CICS system realising that there is no program entry, in the PD definition, it invokes a User Exit program to retrieve details on the program. Ok, I know some of you might be wondering what this User Exit program is?!. Well, User Exit programs are plug-in points where user can write piece of code and plug that in to the TXSeries runtime. The plug-in is built as a C module and is registered with the TXSeries system. There are many user-exits points supported by TXSeries, and one of them is the Program Auto Install User Exit. User Exit programs are usually associated with a Number that is used during the registration, so that TXSeries can know at runtime for what purpose the module needs to be invoked. By now you would have realised that for the Program Auto Install to work we need to register a User Exit Program Module.

Let me take you through the procedure for enabling Program Auto Install under TXSeries. The following steps assumes that you have a CICS region already running.

Firstly, we need to build the User Exit module for the Program Auto Install. For this we can use the sample that is provided with TXSeries under /usr/lpp/cics/samples/userexit directory. A Makefile is already supplied to build the user exit module, so just run "make" command as following:

cd /usr/lpp/cics/samples/userexit

make

The program module will be generated under the same directory called, "cicsuxit". You may want to copy this to the region's bin directory or any other directory that you may prefer.

Now we need to register this user exit module, for that run the following command:

cicsadd -c pd -r <region_name> UXIT PathName="cicsuxit" UserExitNumber=13

In the above the number '13' refers to Program Auto Install. So when CICS doesn't find an PD entry it will invoke the 'cicsuxit' user exit program module.

After the above change you will need to cold start the CICS region for the definitions to take effect. Once the CICS region is started, you can just run your transaction and CICS should automatically pick up the corresponding program

(Optional) You may also want to use the CICS_PROGRAM_PATH=<path> in the CICS region's environment file for specifying the location of your CICS application programs (if different from other than the region's bin directory).

You may want to check the following if you see any issues in running the program:

Confirm if the console.<nnnnnn> has the following similar entries:

ERZ015042W/0186 09/09/11 16:16:37.655655539 IVPCICS 49438/0001 : Program 'UXIT' now associated with user exit '13' ('UE015013')
- if you don't see the above entry, this mean you have not registered the user exit module correctly. So check your PD definition and retry.

You may experience the following problem (logged in the CSMT.out file) or transaction abend A141:

ERZ015022E/0146 09/09/11 16:17:43.398292610 IVPCICS 62300/0001 UMMG: Program '/usr/lpp/cics/src/samples/ivp/COBOL/DFHCMNU' not found

The program names are case-sensitive.. so ensure your programs are in right case. For example if the file is dfhcmnu, then the above error will be flagged.
The most likely reason is TXSeries is not able to find the application program in the specified location (or set through CICS_PROGRAM_PATH environment variable) - so check for the program module existence
If the program module exists check the permission of the file; it should have access (usually read should be enough) permissions for the 'cics' user or just make sure the r+o (read other) bit is set. You will not only have to check the permission of the file, but also for the directories under which the program is residing. Easiest way to confirm this is to login as 'cics' user and doing an 'ls' command should clarify the permission problems.

So with this blog entry I hope to have clarified the Program Auto Install Feature of TXSeries, its benefits, the usage and the common issues around it. Please leave your comments if you have any.

Designing a Highly available architecture for a TXSeries system

invhariharan Marcações: cics availability wlm cluster txseries high ‎ 3.436 Visualizações

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.

TXSeries messages and codes ERZxxxxxx

nikhilraj Marcações: message txseries cicserr codes ibm cics ‎ 3.126 Visualizações

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.

Feed para Entradas de Blog

Blogs