Many of the mainframe computers purchased by companies sometime in the past 3 decades are still in use. This is because they were a major financial investment to buy, they house years' worth of crucial data, resources have been spent to develop applications for these systems, and because quite honestly they still do their job well.

"Web-enabling" these legacy systems can be a daunting task...but it needn't be. This article looks at three methods for making CFMX talk with the mainframe; our shop uses all three methods extensively in order to deliver a suite of heavily-used e-commerce applications over the Internet.

The Mandate
The state agency where I work does hundreds of thousands of transactions involving about a quarter billion dollars yearly, nearly all of it supported on the mainframe (Z800 with OS/390) and written in COBOL with a bit of SQL thrown in. Nearly all of the transactions are processed by analysts sitting at "dumb terminals." Our mandate was to web-enable all applicable processes for the agency's customers...as quickly as possible. Our efforts have been enormously successful due in large measure to good development-business collaboration and concerted in-house training. The series of applications that have been deployed started with the lowest hanging fruit on the tree: publicly accessible inquiries, which means using CFMX to grab data from the mainframe's DB2.

The CFMX-ODBC Scenario
We won't explain this scenario in detail, because creating and using database connections is a ColdFusion developer's bread and butter activity. We initially used IBM's DB2 Connect Enterprise Edition as the connection mechanism, which involved setting up and maintaining a special server to act as a conduit/controller for all DB2 connections. It performed poorly and so we migrated to local ODBC drivers on all CFMX boxes.

Publicly-accessible inquiries and reports served to reduce business analyst's telephone answering to a minimum; next to be tackled were more complex inquiries dependent upon logic embedded in COBOL code and simple transactions dependent upon CICS processes - the next scenario.

CFMX-Metaserver-Transidiom-CICS Scenario
Although there are plenty of products now available to web-enable mainframe-resident data, most have limited flexibility and do not lend themselves to a logical sequence of migration from the "monolithic" application architecture of yesteryear to the newer ideal of a loosely coupled, multitier architecture. With these goals in mind, we purchased and deployed Metaserver, a very flexible middleware product. Based on the Linda Engine developed at Yale, it serves both as the primary location for finance-related business logic and as the connector to the mainframe via yet another product, Transidiom. See Figure 1 for how these pieces fit together.

The Transidiom IDE contains wizards to script the interaction between a terminal user and a series of mainframe screens; it is a kind of "screen mapping" product, somewhat more sophisticated than traditional "screen scraping" products. For an external customer, hitting a form's "Submit" for a simple transaction means these events take place:
(a) The CFML action template instantiates a Java "MetaClient" object (supplied by Metaserver and deployed as .jar files on the CFMX server) and passes over any arguments to Metaserver;
(b) Metaserver creates a mainframe session and passes the data over to
(c) Transidiom, which runs the automated terminal script on the mainframe. Any responses, including error messages, are passed back through the same chain to CFMX and the user. All data passing between CFMX, Metaserver, and Transidiom are sent as XML packets, which are easily parsed in CFML; I wrote a custom CFC that converts any record-set type data from the mainframe into a cfquery to simplify presentation coding.

This solution allowed us to use existing business code as-is and to web-enable transactions quickly; however, we discovered that customers who were submitting hundreds of records caused a performance bottleneck if each record required a separate series of Transidiom scripts. This was not unexpected; besides, Transidiom was envisioned as a temporary solution. The long-term vision is to replace the old Cobol code with Java and possibly use a business-rules engine. Meanwhile, to relieve the bottleneck, we began to employ yet another method to access mainframe data and code: DB2 stored procedures.

SQL Server and Oracle come packaged with procedural languages (Transact-SQL and pl/SQL, respectively), which makes writing and deploying them relatively simple. DB2 stored procedures aren't packaged this way, which makes them a bit trickier to write and deploy; however, they can be written in C++, Java, or Cobol. Like its competitors, DB2 stored procedures can be called from CFML easily with the <cfstoredproc ...> and associated <cfprocparam ...> tags. The idea being introduced here is that you can use DB2 as an agent for passing data between CFMX and non-relational data and CICS transactions. Let's look at two scenarios our shop uses.

The CFMX-DB2 Stored Procedure Scenario #1
To use these two scenarios, the mainframe's system programmer will need to make a Work Load Manager (WLM) available to you. Once you have access to a WLM, using this scenario takes these additional steps:
(1) Define the Stored Procedure to DB2 using the "create stored procedure" DDL statement. Your database administrator (DBA) can do this by executing the DDL in SPUFI. See the top of Listing 1 for an example; note that the language declared is COBOL; it can also be Java or C++, but in our shop COBOL is the available skill set. Stored Procedures written in COBOL and SQLJ use the static SQL methods and produce a Database Resource Module (DBRM). The DBRM is bound to DB2 by the DBA and DB2 knows all the access paths stored procedures need. Stored procedures written in COBOL or SQLJ provide a lot better performance than stored procedures written using Dynamic SQL. If your application must execute a stored procedure frequently then you can cache the Program Load Module in a WLM by specifying the STAY RESIDENT parameter as YES when the stored procedure is defined in DB2.
(2) If you need to access VSAM or QSAM files from a stored procedures then you need to tell the mainframe system programmer to allocate/define the files to a WLM. You can read and update VSAM data using this method. However, if the VSAM file allocated in CICS is in 'update mode' you will not be able to update from within the WLM, in which case you need to use the stored procedure scenario #2 (below); the WLM will make an EXCI call to CICS program and the CICS program will do the VSAM update.
(3) Write the stored procedure itself, making sure that you use the same parameter types and other variable names you declared in the previous step. If you are writing stored procedures in COBOL then using structured programming methods will facilitate maintenance and reuse.

Once you write the stored procedure, compile and bind the stored procedure. The bottom of Listing 1 shows the linkage section of a COBOL stored procedure, which is otherwise ordinary COBOL code.

The CFMX-DB2 Stored Procedure scenario #2
The previous scenario will handle most application requirements. If transactional integrity is required (Atomicity, Consistency, Isolation, Durability) or if you want to leverage existing CICS transactions with minimal changes, then CICS programs can be called from within the stored procedure using the External CICS Interface (EXCI); all input and output parameters are passed through the COMMAREA.

Again, setting up the WLM is similar to scenario #1. For making EXCI calls, the mainframe CICS system programmer has to define EXCI transaction for your CICS region. The top of Listing 2 is DB2 DDL creating a new stored procedure; the bottom of Listing 2 shows two fragments of a COBOL stored procedure declaring and making an EXCI call.

Runtime performance for both stored procedure scenarios is very fast.

Conclusions
Using the last two scenarios, you will have access to almost any mainframe datastore, which means that within the COBOL modules you can set up data structures, feed them data from those heterogeneous sources, manipulate the data, run cursors, perform complex business logic, and then return the results (including record sets) to CFMX.

The average Cold Fusion developer isn't likely to know much about the mainframe; therefore, in-house systems programmers and COBOL developers must cooperate to deploy these solutions.

Many thanks to Madan Mankala and Jim Leamon for their mainframe expertise.