- 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.
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].
ERZ096176I The Version is 'buffer!'
This message prints CICS Version information
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.
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.
Recently I was trying to migrate a region in TXSeries 5.1 version to TXSeries 7.1 version. I found a webpage TXSeries link where the migration steps were clearly documented. So I wanted to write a blog about region migration.
Here in this link, the document also describes about migrating a TXSeries region from version 5.1 to 7.1 on a new machine. If you are migrating a region from TXSeries version 5.1 to 7.1 on a same machine, only step you would need to follow is to run the cicsmigrate command (Step 5 in the TXSeries link).
Run the command cicsmigrate on the region to create the upgrade script and then execute the generated upgrade script.
a) Create an upgrade script as follows:
# install_dir/bin/cicsmigrate -g script_name -o log_filename -r region_name
install_dir is the directory where CICS is installed.
script_name is the full path name of the upgrade script. If we open this script file, we will be able to see CICS commands in this script. These CICS commands would actually migrate the region to TXSeries 7.1 version.
log_filename is the log file, that logs the information about the migration.
region_name is the region that needs to be migrated.
b) Run the upgrade script by entering the following command.
# ksh script_name
script_name is full path name of the upgrade script.
When this script has run, the region has been migrated to the latest version level.
Further information on migration to TXSeries 7.1 can be found here: http://publib.boulder.ibm.com/infocenter/txformp/v7r1/index.jsp?topic=/com.ibm.cics.tx.doc_7.1.0/tasks/t_mig_tx_previous_ver.html
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.