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!

Port stealing between different cics processes

Whenever we bring up more than one region on the same host machine what if the first region's cics processes steals the listener port assigned to the second region's listener?
This is very much possible provided the listener ports for the second region lies in the dynamic port range of host machine's OS. This looks like an uncommon scenario but occurs surprisingly often.

Region A Steals Region B's Ports
First question which would strike anyone here is how the first region's process managed to steal the port assigned to the other region's listener. This is possible because, when first region comes up, it runs a daemon process called “SARPCD” which acts as an endpoint
between various cics processes. So the first region's cics processes needs to register with SARPCD for tcp, udp and cics_ipc transport layer protocol in order to communicate with other cics processes.
So here's the hook from Region A. Since Region B has not started yet, if its listener ports defined in /etc/services are in the dynamic port range of the host machine OS, then it is available to be used by the Region A's cics processes to register with SARPCD. Region B's ports are hence liable to be stolen by Region A!


Aftermath : Region B Fails to Start
Second question following it is about the consequences. Since
the port assigned to Region B has already been stolen by Region A's cics processes, whenever
we try to bring up Region B, it will fail with a message "cicsip failed to start"

The Solution
Now the next thing to follow is the solution. With the new IANA standard, dynamic port range has been shifted to 49152-65535. This reduces the chance of port stealing provided the assigned port range for the Region is below 49152.
Microsoft Windows operating systems from Server 2003 use the range 1025-5000 as ephemeral ports(dynamic port). Windows Vista and Server 2008 use the IANA range(49152-65535 ). So Windows versions before Vista are quite suseptible to this issue if we choose listener ports for Region B and subsequent regions in the range of 1025-5000.
To overcome this issue either choose listener port for subsequent regions above 5000 or tweak the registry to restrict the dynamic port range inside the provided range of 1024-5000 to a range for which you are not going to define a subsequent region's listener.

Information on how to tweak registry can be found here.

Introduction to WebServices in TXSeries

TXSeries for Multiplatforms announced the availability of in-bound web services support natively in November, 2009. The feature is provided as a support pac named CN01 (can be downloaded from here,http://www-01.ibm.com/support/docview.wss?rs=1083&uid=swg24024193). CN01 provides support for in-bound SOAP requests to be translated to program invocations in TXSeries. It allows to expose existing or new transactions as web services. There is no requirement for additional products now to be able to perform this function. Prior to this support pac, clients had to use WebSphere Application Server and CICS Transaction Gateway to be able to do this.
With this feature, TXSeries acts as a Web services provider. Transactions written in C or COBOL programming languages can be exposed as Web services. A new tool, CICS WebServices assistant is provided with this SupportPac, which helps to create Web services description language (WSDL) files from the language structure. Various commands are available for using the tool. In addition, RDz (Rational Developer for System z) provides web services assistant tool that can be used to create WSDL files. Refer to RDz documentation for more information on usage and details of applicable options for TXSeries.
Note : The WSDL files created using the Web services assistant tool are compatible with CICS TS (CICS Transaction Server for z/OS). However, TXSeries does not support all the features or options that CICS TS supports.
This SupportPac is supported for use with TXSeries 7.1 Fixpack 1. SupportPac does not work with prior versions of TXSeries.
Some important information about the support pac below,
Ability to expose CICS transactions as Web services. Does not support invocation of other Web services (outbound) from within TXSeries runtime.
Supported only on English language
Supports COMMAREA interface only. Does not support Containers & Channels.

Additional information and details available with following links ,
TXSeries web site -> http://www-01.ibm.com/software/htp/cics/txseries/
Infocenter -> http://publib.boulder.ibm.com/infocenter/txformp/v7r1/index.jsp
Podcast on Enhancing Business Flexibility using WebServices in TXSeries for Multiplatforms V7.1 can be found at the library -> http://www-01.ibm.com/software/htp/cics/txseries/library/
Developer works article : Using and configuring WebServices with TXSeries -> http://www.ibm.com/developerworks/webservices/library/ws-txseriesmulti/index.html

Introduction to TXSeries

Introduction to TXSeries
TXSeries for Multiplatforms is a distributed CICS transaction processor for mixed language applications.

IBM TXSeries for Multiplatforms V7.1 delivers simplified interoperability with IBM CICS Transaction Server, improved system resilience, problem determination, and application development tooling.
* Robust and extensible distributed transaction processing platform for deploying CICS applications written in C, C++, COBOL and PL/I.
* Widely used for integrating data and applications between distributed solutions and enterprise systems such as CICS and IMS.
* Reuse existing CICS applications and application programming skill sets in your organization consistent with corporate distributed platform policy.
* Develop, test and diagnose CICS applications using COBOL, PL/I, C, and C++ for deployment to CICS Transaction Server for z/OS.
* TXSeries for Multiplatforms V7.1 delivers significant enhancements in integration and connectivity through containers and channels and TCP/IP based interoperability between CICS regions, and further improvements to system resilience, application development and problem determination tooling, Web administration console, and installation.

Important documentation information can be found here, http://www-01.ibm.com/software/htp/cics/txseries/library/