COBOL skills are diminishing and maintaining legacy systems in the modern J2EE and .Net world not including the trend for open languages such as PHP and MYSQL along with traditional middleware languages such as C and C++ are becoming a challenge. In the light of these shotage and need for bridging the legacy system to the future technologies, this site will feature articles that the author is knowledgeable and has had 14 and 8 years experience in COBOL technologies and middleware languages especially Java.

What are the current industry practice of how COBOL and legacy system communicate with J2EE and .NET enterprise platform? First, is through JMS messaging specification such as MQ series. Second, through IBM CTG (CICS Transaction Gateway).

The JMS option will use the stateless session beans in J2EE container as in a portal and can be used when high volume of threads are created for transactions. Once submitted from the front web interface, it sends the MQ object to the client MQ channel which has either a cluster or single MQ channel connection to the mainframe z/os MQ counterpart. Defining a MQ cluster will have the benefit of failover or no disruption of service even if one channel goes down. Now what are the basic set up required to create a MQ communication facility between the client and z/os channels. These are the following:

1. Define the channel in both the client and server in mainframe z/os
2. Define the MQ servers in both the client and server. These servers act like a basket of
messages where it is held there until the message is consumed by the receiver channel.
Sometimes messages goes to dead queue channel when it is left unattended for a set period of
time.
3 Define a table in z/os platform that will store the different channels and processes that
will process the cics message sent to it by the mq client
5. Define a MQ listener to listen and receive messages
6. Create an acknowldgement of the messages received and store in a certain table for
persistence and create a class in the front end to process the message.

How about for the CICS CTG option? This option can be asynchronous or synchronous. Here it needs to have a Java Gateway controller, ECI client, and a CICS CTG defined and created an instance of. First, the user is authenticated in CICS via its authentication facility. The two communicates in the form of java beans in the front which is mapped to the commmarea in the CICS programs that will process the transaction when the transaction id is called from the front end.

Sample code using these design pattern to integrate legacy online systems using COBOL, CICS, IMS DB/DC and DB2 with the front-end and middleware layer like Java, JavaScript, Jasper, Hibernate, VB.net, C# will be available in the forum.

There are no more distinct difference between these two methods of integrating legacy systems with the web. I recently compared the performance between using MQ Series and IBM CTG and no difference in performance for users around 20,0000 or 3 users per second. The response time for IBM CTG is commensurate now with the asynchronous MQ series. Given these scenario, the IBM CTG is a better choice as it requires less maintenance of channels and that running multiple threads is not a problem as if it were using asynchronous communication with the back end.

For more information on this topic you may submit a feedback or ask a question on the forum page and we will strive to give you an expert opinion and answer to your technical or business question.

If you want to get sample legacy and web source code, create a topic or question in the forum category and you will get a reply at the shortest time possible from expert practitioners and moderators.