Ways to monitor a TXSeries (CICS) system

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:

• CICS STATISTICS API
• This facility provides the ability to query on the usage of various CICS region resources through the COLLECT STATISTICS API. These would give you the aggregate information of various CICS resources consumed within the CICS region.  For example, you can inquire on the peak transactions, storage usage, terminals installed, etc,.
• CICS Monitoring Facility (CMF)
• This facility allows you to gather information pertaining to a task running within the CICS region. The CICS system has various pre-defined points called as EMP (Event Monitoring Points) that collects information from the runtime system. For example, you can gather information such as the start/end time of the task, time taken waiting for I/O or network operation, etc,. You can enable/disable specific EMP fields that is of your interest by configuring MD (Monitoring Definition) attributes.
• INQUIRE API
• This facility provides the ability to query information about CICS resources programatically.

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:

• User applications or scripts
• This is probably the most commonly seen approach, for monitoring the TXSeries CICS regions. For instance, you can choose to send a SMS to alert Administrators of any critical failures by watching TXSeries logs frequently, takes pre-defined actions such as re-starting the CICS region for certain abends/failures, archiving files, etc,. This approach however will not be useful to gather information from within the CICS runtime system, as the scripts will not have access to such information.
• User defined transactions 
• This is probably the best approach available to collect CICS region resource based information. This is done by having a long running transaction (often called a daemon)  collecting information at regular intervals (using the above mentioned facilities). The collected information then can be presented to the Administrator or users through WEB, or scripts, or any other applications via primitive mechanisms such as sockets, or files. Apart from collecting the information, the long running transaction can also intelligently find out if there are any transactions that are stuck, taking too much CPU or memory resources, and alarm accordingly.
• Tivoli Agents
• Enterprise systems often monitor more than one system at a time, and in such cases it definitely makes sense to monitor systems through Tivoli - thus providing a single window for Administrator for monitoring their system. The implementation is much similar to the approaches mentioned above, except that these are driven by the agents written in Tivoli.
• Here is an example of a Tivoli agent written to monitor availability and performance of a TXSeries system:
• http://www-01.ibm.com/software/brandcatalog/portal/opal/details?NavCode=1TW10TM5C
• Third-party tools
• I came across a nice and simple tool called EcStat2 which is a GUI to monitor TXSeries CICS system. It is a Windows based application, that collects information through CICS STATISTICS and INQUIRE APIs. This GUI tool connects to the CICS regions using CTG/CUC (ECI).
• Here is the download link: http://www.lrsolution.com/rss/download_en.html
• CICS supplied transactions
• For quick monitoring of the system, you can make use of the CSTD and CEMT supplied transaction for monitoring the system. These operations however differ from the above, as it needs to be performed manually.
• Monitoring through TXSeries Web Administration Console (>= TXSeries for Multiplatforms V6.2)
• Users can monitor resources such as System, Transaction and Program in a web environment. They have the ability to specify the fields to be monitored, do off-line analysis, and to archive the monitoring data.
• The advantage of this approach is that you wouldn't require to connect to the CICS region directly, and they can monitor the system from any system via a browser.

I have just summarized here on the various approaches that can be taken to monitor the TXSeries system. If you need information on the monitoring facilities available, and how to use them, you can refer to this white paper: http://www-01.ibm.com/support/docview.wss?uid=pub1gc34711500

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!

Java in a TXSeries environment

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:

• To invoke a web service
• To integrate with external Java applications
• Access CICS services using JCICS API

To invoke a Java CICS program, you don't need a special semantics... you can just do a EXEC CICS LINK command to call the Java/CICS program. TXSeries takes care of the data conversion between Unicode and your language code page.

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:

TXSeries Redbooks:
http://www.redbooks.ibm.com/abstracts/sg247185.html (section 3.6.1. details programming in Java)

TXSeries IEA Website material:
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.txseries/txseries/6.1/Programming/TXSeriesV6_JAVA/player.html?dmuid=20061231124436896636

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 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!

Smarter Migration of Oracle Tuxedo applications on to a IBM platform

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

Ubuntu Lucid too slow to boot?

Check if you have FAT or NTFS partition...presence of FAT/NTFS partitions can cause 'fsck' to run at every boot causing significant delay in the boot speed. Following are the entries that I find in my /etc/fstab:
#            
proc            /proc           proc    nodev,noexec,nosuid                  0       0
/dev/sda1       /               ext3    errors=remount-ro                      0       1
/dev/sda6       /data           vfat    defaults,umask=007,gid=46      0       1

All you need to do is to change the last parameter value in the FAT/NTFS entries from 1 to 0. The last parameter indicates whether the system checks for the file system during boot. 

With this change, my system just takes 40.6 seconds to boot as opposed to 2 minutes 6 seconds earlier!

This is just one reason as to why the boot could get slow. In any case it is best to run the 'bootchart' tool that captures information on the processes run during the boot [just google to get more information on the bootchart tool]. 

You can also press the ESC key as soon as the Ubuntu boot screen starts... to know messages coming out of the boot.

New to TXSeries, TX Series, TxSeries. Txseries, TXS, TXSeries/CICS.....?

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!