- 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
India CICS User Group
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,
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.
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.
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.
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.
You may want to check the following if you see any issues in running the program:
Usually TXSeries users would configure TXSeries regions to meet their architecture requirements. But users miss to configure and tune SFS volumes (both data and log volumes). Whenever a default region (SFS Server as File Manager) is created in TXSeries, SFS Server with the hostname is also created with default settings. Default settings include SFS Log Volume size and SFS Server Data Volume size.
SFS Log Volume is used to store a SFS Servers log files. The data in this volume is used during recovery of transactions. The recovery data typically would include non-committed SFS Server data.
SFS Data Volume is used to store a SFS Severs application data. Committed data in SFS Server is stored in SFS Server’s data volume.
If the SFS Server fails to commit the data to data volume then the SFS log volume is used during the recovery process. Once the data is committed in data volume, entries in the log volumes are deleted. A typical setting of log volume size could be something like 100MB and data volume size as 2GB.
Steps to follow for configuring SFS Server’s volume size.
Before creating the SFS Server, understand how much log volume and data volume size is necessary for your architecture. In this example, im setting SFS log volume size as 128MB and SFS data volume size as 1GB.
a) Set the environment variable CICS_SFS_LOGICAL_PARTITION_SIZE to Physical partition size in the machine. Physical partition size can be obtained by running ‘lsvg rootvg’ command.
b) Set the environment variable CICS_SFS_LOG_SIZE to 128MB . This environment variable takes input in MB
c) Set the environment variable CICS_SFS_DATA_SIZE to 1024 MB(1 GB). This environment variable takes input in MB
For any further information on this, refer TXSeries Infocenter documentation.
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:
Some of the unique benefits that this tool brings are:
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.
IBM TXSeries for
Multiplatforms supports multiple locales. Details of TXSeries supported
locales can be found in the infocenter link http://publib.boulder.ibm.com/infocenter/txformp/v7r1/index.jsp?topic=/com.ibm.cics.tx.doc/concepts/c_tx_supported_locales.html
1) Create a new region
2) Setup region environment to work with the language.
3) Copy the Japanese map files into regions map directory.
4)Start the region
To check whether the region is properly configured with Japanese language, we can check for the following ‘ERZ010135I ‘ message in the console file of the region.