IBM’s CICS user conference – a gathering of CICS community was recently held in India across two cities of south India on 29th Nov and 1st Dec, 2010. CICS user conference is a world wide phenomenon where IBMers working on CICS area present various topics including latest updates, new features and so on around CICS products. Various partners and developers across the industries attended the conference and presenters included IBM UK and India employees.
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 India probably are yet to implement the same. And to my surprise, yesterday I get a text message and an email which says “ You have withdrawn X amount of money from a Y place”… Before really verifying the amount mentioned in it, I was thinking . CICS is getting cool and itJhmm, we just thought of it and there you go continues to do so as Will Yates demonstrated with deployment assistant and scripting support presentations. CICS has been the product that businesses across the world have evolved with and it continues to make great sense for them even in this modern era. Simply awesome!!!
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 India and was conducted in Bangalore and Chennai. Participants had good and healthy interactions with presenters on various topics. CICS conference was a great setup and there was exuberant environment on both the occasions and as some participants told, it makes sense to have more such events!!!
Modificado em por lakshuraghav
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).
Segment 0 is reserved for Kernel data and text.
Segment 1 is for application program text.
Segment 2 is for stack and application program data.
Segment D is the shared library text
Segment E is also shared memory and miscellaneous kernel usage
Segment F is the per-process shared library data.
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
/usr/lpp/cics/bin/cicsas: executable (RISC System/6000) or object module not stripped (maxdata=4)
(Using a modified magic file described in “Developing and Porting C and C++ Applications on AIX”)
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.
Now, the number of available shared memory segment is reduced to 3. The application library getting loaded in the CICSAS process such as user application,db2 client library, MQ library,Oracle client library etc (depending on the configuration ) will have 3 free shared memory segments to attach. An error will be raised when the loaded application or library attempts to attach more than 3 segments.
Sometimes, there is a possibility of hitting these limits when there are multiple resource managers configured in a region.One way to address the issue is to reduce the size of heap. If the user application does not require large heap, LDR_CTRL=MAXDATA can be used to increase the shared memory available for application by reducing the heap. If you set LDR_CTRL=MAXDATA=0x20000000 in region's environment file, then the heap memory can be restricted to 2 segments i.e. 512MB (instead of 4 segments) and additional 2 segments becomes available to the application.
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:
- Improved response times
- Increased service availability
- Balanced resource usage
- Maintenance without interruption
The cluster in TXSeries is similar to the cicsplex model followed in CICS TS on z/OS and maintains the same hierarchy. This means you have the same concept of COR (Client Owning Region) / TOR (Terminal Owning Region), AOR (Application Owning Region), and DOR (Data Owning Region) / FOR (File Owning Region). The COR / TOR regions would take the incoming requests, typically from one of the network dispatchers and invokes a workload management component to determine the best AOR to route the request to. The algorithm to determine the best AOR can be configured. Of course there are other implicit aspects taken care by the workload management component, which is for example if one of the AOR is down or non-responsive, the requests will be sent to another AOR.
Some of the unique benefits that this tool brings are:
- Multiple algorithms to choose from - round robin, weights, load factors, resource consumption, etc,. For example, you can specify a load factor for each CICS system allowing a balanced distribution of work
- Specify a maximum number of application servers available in each CICS system allowing better utilization of each CICS system
- Collects information about the AOR regions periodically; alternatively if there is any planned or unplanned shutdown of the CICS system it automatically informs the work load management component for not to route requests.
- Data based routing
- Upgrade / maintain regions without bringing down the entire cluster
- The AOR region configured can be a different CICS system such as CICS TS on z/OS
There are few limitations as well, that you might have to consider when designing workload management for TXSeries using this tool:
- A COR could be a single point of failure and as a result we need to configure multiple COR in the same environment.
- Multiple COR's in the same environment cannot share information of the AOR - so in effect COR1 will not be aware of the work load patterns of the AORs managed by COR2.
Also, you must be aware of some of the requirements on the applications to be able to deployable in the cluster:
- Applications should be suitable to combine on one machine. For example, they cannot share the same TDQ names
- All required facilities or dependent components must be available; CICS systems must be cloned
- All required application data must be accessible; for example, accessing of database from the CICS system
- This is most important - Application must not contain any affinities. For example, dependence on state or data available on a particular CICS region
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.
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,
- 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
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.
Here's a view of detailed CUG India 2011 agenda,
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.
- Firstly, we need to build the User Exit module for the Program Auto Install. For this we can use the sample that is provided with TXSeries under /usr/lpp/cics/samples/userexit directory. A Makefile is already supplied to build the user exit module, so just run "make" command as following:
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.
- Now we need to register this user exit module, for that run the following command:
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.
- After the above change you will need to cold start the CICS region for the definitions to take effect. Once the CICS region is started, you can just run your transaction and CICS should automatically pick up the corresponding program
- (Optional) You may also want to use the CICS_PROGRAM_PATH=<path> in the CICS region's environment file for specifying the location of your CICS application programs (if different from other than the region's bin directory).
You may want to check the following if you see any issues in running the program:
- Confirm if the console.<nnnnnn> has the following similar entries:
- ERZ015042W/0186 09/09/11 16:16:37.655655539 IVPCICS
49438/0001 : Program 'UXIT' now associated with user exit '13'
- if you don't see the above entry, this mean you have not
registered the user exit module correctly. So check your PD definition
- You may experience the following problem (logged in the CSMT.out file) or transaction abend A141:
- ERZ015022E/0146 09/09/11 16:17:43.398292610 IVPCICS 62300/0001 UMMG: Program '/usr/lpp/cics/src/samples/ivp/COBOL/DFHCMNU' not found
- The program names are case-sensitive.. so ensure your programs are in right case. For example if the file is dfhcmnu, then the above error will be flagged.
- The most likely reason is TXSeries is not able to find the application program in the specified location (or set through CICS_PROGRAM_PATH environment variable) - so check for the program module existence
- If the program module exists check the permission of the file; it should have access (usually read should be enough) permissions for the 'cics' user or just make sure the r+o (read other) bit is set. You will not only have to check the permission of the file, but also for the directories under which the program is residing. Easiest way to confirm this is to login as 'cics' user and doing an 'ls' command should clarify the permission problems.
So with this blog entry I hope to have clarified the Program Auto Install Feature of TXSeries, its benefits, the usage and the common issues around it. Please leave your comments if you have any.
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.
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
Usually these CICS messages are of 3 types
Information messages: CICS Information messages are meant for user
information purpose only. CICS Information message are of type
‘ERZxxxxxxI’. For example CICS message 'ERZ096176I'.
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
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
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
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
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.
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.
Data Volume is used to store a SFS Severs application data. Committed
data in SFS Server is stored in SFS Server’s data volume.
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.
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.
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.
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.
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.
information on migration to TXSeries 7.1 can be found here:
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
Here are the steps to configure a TXSeries region with a particular language(locale)
1) Create a new region
cicscp –v create region japreg
2) Setup region environment to work with the language.
Suppose we are configuring a region with Japanese language, we need
to export the following environment variables in the regions environment file.
3) Copy the Japanese map files into regions map directory.
cp $CICSPATH/msg/Ja_JP /var/cics_regions/japreg/maps/prime
Copying the Japanese map files into regions prime folder will
enable the region to pick the Japanese map files whenever we are
running CICS Supplied transactions like CSTD,CEBR etc
4)Start the region
cicscp –v start region japreg StartType=cold
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.
ERZ010135I/0362 09/15/10 23:21:12.642808969 test2 46208/0001
: CICS region 'japreg' is being started with locale categories Ja_JP
Ja_JP Ja_JP Ja_JP Ja_JP Ja_JP’
Hmm... probably the first thing to know if you are new to TXSeries, is
how to search for relevant materials/discussions on the web!
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!
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.
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
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!
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
- 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
- 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
- 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).
- 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
- 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
- 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
So happy monitoring, and do drop in your comments and thoughts here!
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:
http://www.redbooks.ibm.com/abstracts/sg247185.html (section 3.6.1. details programming in Java)
TXSeries IEA Website material:
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
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
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!
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
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