- 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.
invhariharan 060000MAJR Marcações:  auto txseries install cics program 1 Comentário 3.384 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.
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.
invhariharan 060000MAJR Marcações:  wlm cics cicsplex workload txseries 2 Comentários 2.859 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:
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.
invhariharan 060000MAJR Marcações:  monitoring tools cics scripts txseries 2.480 Visualizações
The CICS TS for the z environment has a rich set of monitoring tools available from both IBM and the third-party vendors. Though TXSeries (CICS) is not blessed with similar offerings, it has a rich set of facilities available (that confirms to the CICS standard) for monitoring. These facilities mainly aid to get granular information on the activities occurring within the CICS region.
One of the first things that comes to mind thinking of monitoring a system, is on where and how to gather information that would indicate various events occurring within the TXSeries system. Following are the primary facilities available in a TXSeries system where one can gather information:
Now, the other part of the problem is how to use these facilities to monitor the system. There are different ways which we can adopt, some of them are listed below:
In summary, TXSeries does provide rich interface and wealth of information that aids monitoring, however it highly relies on users/administrators to exploit the provided interfaces, and not many third-party tools available to buy! A reference implementation is available for Tivoli agents, which can further be enhanced (as the source is available for download) to suit your requirements. A good start would be to use the TXSeries Web based administration console for monitoring.
So happy monitoring, and do drop in your comments and thoughts here!
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 (IBM Migration Assistant for Oracle Tuxedo) offering from IBM.
But Why Move ?...
I always heard that the support cost from BEA was high, and it became worse after Oracle acquired almost spiraling the costs....maintenance. And this at a time when businesses are cutting short their spending due to economic conditions prevailing. To be honest, in my opinion this (cost) isn't the obvious or primary reason as to why you should move to TXSeries... (probably re-negotiating with Oracle might help reduce the costs ;-)). It is because of the technical value that TXSeries brings on the table, and its complete eco system surrounding it which makes it a good value for money as compared to that of a Oracle stack.
What values does TXSeries bring to me...?
IBM TXSeries has been in the market for over than a decade and is a matured product; having a wide spread deployment world-wide running across various industries like Banking, Healthcare, Insurance, Retail, Manufacturing, Transportation, and so on.
Well, TXSeries adopts a robust framework of CICS (Customer Information Control System) - a much famous OLTP platform in the industry. The simplicity of the CICS architecture provides various benefits to that of a Oracle Tuxedo. Firstly, it is proven that with TXSeries that it consumes less CPU power and memory usage to that of Oracle Tuxedo for the same throughput (or a TPS factor). This means you can do more with less - Every business that runs would expect itself to grow year-a-year and so equally the demand in their IT infrastructure. In terms of large deployments is concerned, nothing gets better than TXSeries here - It's seamless to scale across different hardware platforms, provides an intuitive work load management, flexibility in deploying applications and refreshing them later with an updated version without requiring to stop your business. Multiple instances of TXSeries systems running on desperate hardware can talk 2PC (global transaction), provides monitoring through Web based administration tool, Tivoli agents, Web Services SupportPac, WebSphere Business Events SupportPac, IMAT SupportPac.... and all this at no additional cost!
How does IMAT help me... ?
IMAT SupportPac provides you the necessary tools that let's you to migrate your existing Tuxedo based application on a TXSeries environment seamlessly, without requiring considerable effort...During the migration process, your application remains as-is - this is a key benefit in the migration projects which are quite sensitive to any changes done in the application / business logics. Also you might think that being new to a TXSeries environment, it would require a larger learning curve - but this is not the case with IMAT... it is equipped will all the tools required with which you continue to develop and deploy your application as you were doing in the Tuxedo environment without needing to learn how you do all these newly in TXSeries! Isn't this a great boon for such migration? less learning and quick deployments of your existing applications! This is why we call IMAT a S.M.A.R.T migration offering. You can continue to maintain your existing applications and new application can be written to take advantage of the CICS Application Programming sets.
Does IMAT change my application code... ?
Nope. it doesn't. Your application is just link-edited with a library that is supplied with IMAT and enables it to run on the TXSeries environment.
Bullet proof investment for the future...
At the end of the day, one can always look up to CICS TS if they wish to scale over the roof... with the z Enterprise launched one can consolidate all the heterogeneous hardware in to one single blade... Imagine the benefits of doing so... less data center space, less cooling p.m., easier to manage and maintain in a centralized system, no hurlings of cables here and there... above all the reliability that you get for which mainframes are always known for! And what more, TXSeries applications are compatible to run on a CICS TS environment.
Where can I get this tool...?
Here is a link that can give you more information on how to download: http://www-01.ibm.com/support/docview.wss?rs=9&uid=swg24026819
Do I need anything else to try this tool...?
You will need TXSeries obviously, if you don't have a license yet... why don't try a trial download?... here is the link: http://www.ibm.com/developerworks/downloads/ws/txseries/index.html
Where can I ask a question on TXSeries... ?
There is a technical developerWorks forum for TXSeries, and here is the link: http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1014
TXSeries being positioned as a transaction processing platform for traditional applications written on COBOL, C, C++, and PL/I. - predominantly! There's no question asked if the entire application workload is written on Java which obviously would be hosted on a Java EE platform such as IBM WebSphere.
TXSeries and Java architecture
In TXSeries, CICS regions are designed to have a multi-process architecture model. That is, you will find a set of co-ordinated operating system processes running when you start a CICS region. There would be a number of application server processes running (1 to n, that are configurable), which are responsible to run the business transactions/applications. Each of this application server process would then have the JVM initialized, when a Java application is run on it. The classes gets loaded within the JVM heap of the application server process and are not shared with other application server processes.
Running Java programs on TXSeries would suffer performance impacts due to its architecture; nevertheless the Java support on TXSeries has certain advantages like below:
There are certain limitations in using the Java support, like for example, you can't deploy an EJB on TXSeries, and only limited set of JCICS API (v1) are supported for TXSeries.
You can use Rational Application Developer (RAD) tooling for developing TXSeries/Java applications.
For more information on the Java support on TXSeries refer to the following:
http://www.redbooks.ibm.com/abstracts/sg247185.html (section 3.6.1. details programming in Java)
TXSeries IEA Website material:
invhariharan 060000MAJR Marcações:  cics availability cluster wlm txseries high 2.118 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.
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
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.
invhariharan 060000MAJR Marcações:  cics txseries manager coordinator new transaction 1.766 Visualizações
Hmm... probably the first thing to know if you are new to TXSeries, is how to search for relevant materials/discussions on the web!
There's a lot of documents on the web that has mis-interpreted the name of the product with some of the variations you could see in the title of this blog itself! When I do a Google on "TXSeries" it's always the standard information from the product's site... I don't tend to see any discussion out there in the community, but a small tweak to the name, like "TX Series" +CICS produces some amazing results... give it a try!
I guess, the correct representation of the product name is "TXSeries" (the first three letters in capital) ... or to be more precise "TXSeries for Multiplatforms" as seen in the IBM's site.
So few tips if you are searching for any content related to this product. Use different variations of TXSeries like TXSeries (the correct one, unfortunately with less search results), TX Series (the most commonly used 'incorrect' representation), and so on. And a magic happens, and your search results gets more precise if you include the "CICS" word in your search.
I have heard this product getting referred to other names like CICS on open systems, CICS on distributed platforms, CICS open, CICS 6000, CICS on AIX... So if you are not finding any results with your searches, you might want to include some of these terms and try again.
If you still can't get relevant search results, may be that's something not yet discussed on the web, so you might want to try discussing it here: TXSeries Forum
So, happy searching! and you have learnt your first lesson on TXSeries!
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 required tools for providing scalability for your business applications running on different or same hardwares... providing horizontal scaling.
I know that Oracle Tuxedo provides clustering mechanisms that would route the incoming requests across a cluster of servers configured... in a round robin fashion or may be in some pre-determined fashion... So to scale your applications, cluster whatever machines you have (same or different hardware), deploy your application in each of them, job done, do you think?... well you may just run in to various problems if you do that!
There is more towards work load management tool these days than just to route the work!. That's why I call them as a Smarter Work Load Management tool... Say for instance it is very unlikely to have all the hardware machines on which your applications deployed are of the same horse power, and what if you wanted to make old systems to take part of the same cluster but doing relatively less load of work that the rest powerful machines? What if you want to route requests based on the data that is incoming (say route to a Geo specific server)? What if you wanted to take some machines out of the clusters for maintenance dynamically without stopping or interrupting your business? What if you wanted to send only certain number of requests irrespective of how powerful the machines are (partitioning)... Well there are loads of intuitive reasons such as these, which makes a primitive work load management tool inefficient, if not all, in most of the deployment scenarios. Doesn't addressing these make a smarter work load management tool?.
Answers to the above questions is what you would find as a feature in the Websphere TXSeries CICS software...With a license of TXSeries in hand, you get a fully functional Work Load Management tool with no additional cost... so when your business grows or want to scale your applications horizontally, you don't need to worry on buying additional tools/softwares. There are numerous ways you can configure the WLM tool in TXSeries, which makes it more appealing and flexible in a clustered environment. A true value for money feature!
lakshuraghav 0600009XU0 Marcações:  txseries 'txseries ldr_ctrl' ldr_ctrl=maxdata' 1.300 Visualizações
This blog covers the basics of shared memory segments used by TXSeries on AIX and increasing the shared memory available to applications using LDR_CTRL=MAXDATA settings.
TXSeries is a 32-bit product and works based on 32 bit virtual memory model of AIX. The total virtual address space of a CICS application server process (cicsas) is restricted to 4GB. In 32-bit AIX memory model, the address space is divided into 16 segments with each occupying 256 MB memory (256MB *16=4GB). The addressable memory segments are from 0 (0x00000000) to F (0xFFFFFFFF).
With 6 segments occupied , 10 segments are left for applications to attach. In TXSeries, the cicsas process use large memory model of AIX to allow large values for task private pool.
This large memory model for cicsas can be verified from the following command:
file –m/etc/magic /usr/lpp/cics/bin/cicsas
Hence, 4 segments of memory (1 GB) is reserved for heap.
There are only 6 segments remaining. Assuming the size of region pool and task shared pool to be less than 256 MB, each occupies a segment(0xA and 0xB by default). TXSeries uses a shared memory segment for CICS IPC (CIPC) communication which is usually 7th segment by default.
IBM’s CICS user conference – a gathering of CICS community was recently held in
Agenda was well laid out with a good mix of CICS, Rational tooling and TXSeries topics. Matt Whitbourne, CICS product manager spoke about CICS updates and recent innovations that have been happening in the CICS area. Hearing him it left us impressed on how a product > 40 years old continues to innovate and make sense for customers. CICS 4.1 is the latest release of CICS and has come in with a host of cool features, one of which being business events. Matt was talking about examples of innovation on how he got text messages from his bank on withdrawals, I was just thinking while it’s a good example but banks in
Like CICS, innovation continues on z hardware. New zEnterprise system which can host power blades as well begins a new era in enterprise systems. Other topics of interest were IBM’s latest offering (IMAT) on the TXSeries product to enable Oracle Tuxedo migrations and Rational developer tooling for CICS. Was interesting to see a demonstration on IMAT that shows how a migration across middleware could be achieved with such ease. Rational continues to provide developer tooling to support CICS platforms. RDp is their latest offering with support for COBOL , C , C++ and so on for power platform. Definitely of great interest for the TXSeries customers as it brings great value in terms of application development for TXSeries. You can develop, debug and deploy applications using RDp.
This was the third such CICS conference in