Renaming CICS Regions

Renaming a region in TXSeries is not as straightforward as renaming a folder on your desktop. The Region name is used in multiple places -As a prefix in creating sfs files, as an entry in the cicssrcdb ( Remember the subsystems blog ? ), the region environment file is created with its name etc..

So, if you do find yourself in a situation where you want to rename your region, there is a simple way to do so.
And no, there is NO "cicscp restart region blah blah ... "

Here is how you do it :

1) Navigate to CICSREGIONS directory which is /var/cics_regions on Unix systems and C:\var\cics_regions in Windows

2) Run the following command :
" cicsexport -r (Your Region Name) -o (Output File)"

Example : cicsexport -r Arena -o OutFile
This should ensure that an output file is created which contains all your region information. Now this regions is shippable to any other machine in a CICS understandable format.

3) Now Run this Command :
"cicsimport -r (New Region Name) -o (Output File) "

Example : "cicsimport -r ARENA -i OutFile"

Take Care that the file in -i option is the same file you created with cicsexport.

4) Now start your region using this command :
"cicscp start region ARENA StartType=cold"

Note : Did you notice that the region names are case sensitive? This might be a reason to rename your regions in case you want it to Communicate with a region on CICS on z/os.

You have now renamed your region! Good to go.

Rational Host Access Transformation Services(HATS) over TXSeries: Modernizing traditional

HATS transform the legacy 3270 and 5250 green screens into intuitive and rich web
applications which can be furthur exposed as WebServices. HATS does not only transform
applications into Web applications but they can be used to create mobile applications as
well.BMS maps functionality of TXSeries helps in creating applications in the form of these
legacy 3270 terminals. Rational HATS can be used to convert these into Webpages and hence
make these applications more user friendly.In order to make this conversion happen, consider we have a BMS map with certain input and output fields and which has been deployed over TXSeries.

In HATS, on creation of the new project one has to enter parameters like hostname, port number, Region name, TD entry etc to connect to the particular program and BMS map deployed in the TX region. Then using creation of macros and deploying them over the server the conversion of a 3270 terminal to a Webpage happens.

These webpages can be furthur tweeked and changes can be made in the properties to make them more interactive. Also a wsdl file gets created in the process which can then be used to create WebServices.

The use of green screens is no more appealing to people so on converting them to Webpages which is the trend of today, old applications can be converted with no code change.

Facing a problem in TXSeries… wondering what data to collect?

If only I had a tool that’d collect all the data that the product team wants from me to look at this problem…. Wishful thinking??? No. If you look around the utilities directory under the product install (/usr/lpp/cics/utils) you will find a tool called “cicsservice”.

“cicsservice” utility is meant to help automatically generate either the entire set of logs such as region logs, SFS logs, installed product information, intersystem communication information and so on. You could collect all the information at one go or selectively collect a set of information as well.

Prior to 7.1, usage of cicsservice tool was either to collect all data or interactively collect selective logs. With 7.1, a change has been made to use options to collect selective data non interactively. This can be quite handy, especially if you would like to involve this command in your customized scripts.

Some customers find that the size of output generated by cicsservice is high and gets hard to pass the data back to support teams. While selective data collection can help manage the size of data better, as a best practice you might want to archive older product logs, which will control the size of the data collected.

A generic tip on handling product logs : create separate file systems for storing your log files (dumps, trace etc.). This would ensure that even if the file system size hits the peak, region execution does not get affected.

Documentation on cicsservice can be found here, http://publib.boulder.ibm.com/infocenter/txformp/v7r1/index.jsp
TXSeries library can be found here, http://www-01.ibm.com/software/htp/cics/txseries/library/

TXSeries messages and codes ERZxxxxxx

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.

invhariharan's blog: Java in a TXSeries environment

invhariharan's blog: Java in a TXSeries environment: "TXSeries being positioned as a transaction processing platform for traditional applications written on COBOL, C, C++, and PL/I. - predominan..."

invhariharan's blog: Smarter Migration of Oracle Tuxedo applications on...

invhariharan's blog: Smarter Migration of Oracle Tuxedo applications on...: "I guess moving Oracle Tuxedo based applications on to an IBM based platform is never going to be easier than using the newly released IMAT (..."

invhariharan's blog: Smarter Work Load Management Tool

invhariharan's blog: Smarter Work Load Management Tool: "I don't think that Work Load Management terms are anything new to us! There are loads of load balancing software tools available...These are..."

Clueless about CICS subsystems?

By now, I trust the concept of a "region" is a familiar one. If not, this might be a good place to start -> click

In brief, a region is that independent environment in which your applications run. This particular environment, when started, comes up with a set of properties that are defined in the "stanza" files. For more details on regions - how to start, stop etc, visit this link.

On AIX, each region runs as a subsystem. A subsystem is any program or process or set of programs or processes that is usually capable of operating independently or with a controlling system. A subsystem is designed as a unit to provide a designated function. 

Similarly, a region running on other platforms that TXSeries supports; such as Windows, Solaris or HP, need to emulate a subsystem.

The concept of "subsystems" is unique only to AIX, hence, when a region comes up in Solaris/HP, the process "cicsstart" sets up a subsytem-like environment. It uses the "cicssrcdb" file that is present in the cics_src directory in order to access dynamic information in order to bring up the region.

That's about subsystems and the cics Region. More on cicssrcdb related blogs later!

Understanding and configuring TXSeries SFS volumes.

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.
export CICS_SFS_LOGICAL_PARTITION_SIZE=64

b) Set the environment variable CICS_SFS_LOG_SIZE to 128MB . This environment variable takes input in MB
export CICS_SFS_LOG_SIZE=128

c) Set the environment variable CICS_SFS_DATA_SIZE to 1024 MB(1 GB). This environment variable takes input in MB
export CICS_SFS_DATA_SIZE=1024

For any further information on this, refer TXSeries Infocenter documentation.

TXSeries region migration within a machine

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

where:

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

where:

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