How to modernize mainframe 3270 applications?
Without throwing away your investments...
I have recently been faced with an Integration and Deployment dilemma with
one of our customers. The customer is a multi-billion dollar national
distribution organization, with facilities around the country. They are
currently running our Control I Order Management System on IBM 3270 mainframe.
They were initially interested in implementing our Control II version of the
software that leverages a relational database and a completely re-architected
code-base. It's a client/server solution that runs some of the largest
distribution facilities in the world. But it's not a SOA-based solution, which
is the direction that the client is looking to go for modernization. Fortunately
our Control.NET application is a SOA-based solution. We are currently migrating our Control II order management system to
run on the .NET CLR (Control.NET).
The new Control.NET application leverages all the great features of
the Microsoft server and .NET related technology offerings:
- The relational database is SQL Server 2005.
- The development environment is Visual Studio 2005 Team System,
though we are still using MKS Source Integrity to manage our code,
until we adequately test Team Systems code management features.
- 13 million lines of ANSI COBOL, recompiled to run on the .NET CLR using
Fujitsu's COBOL.NET compiler.
- BizTalk 2004 as the Business Process Management System (BPMS) for
communication and message coordination between systems.
- SharePoint Portal Server 2003 for personalize and targeted
information worker content and dashboarding.
- SQL Reporting Services 2005 for business intelligence and
reporting.
- ClickOnce deployment for web-enabled thin-client deployment that
allows rich user interface functionality.
I am trying to find a solution that would allow the customer to use our new
Control.NET order management system, but still be able to leverage the existing
data on the mainframe without being forced to do a complete systems switch-over.
They would like to migrate and modernize their system over time.
This approach requires our system, Control.NET, to be able to access data
(i.e. Inventory, Customer or Vendor data) not from our relational database, but
rather from the existing IBM 3270 mainframe data that exists in IMS and
VSAM
data files. Unfortunately this presents a dilemma. IMS and VSAM data files are
not relational databases, but rather IMS data is a hierarchical database and
VSAM data is just indexed files.
Our Options…
We have a few options for how we might solve the problem:
Option 1 – Synchronize Databases. This option would require synchronization
between the relational database we use for Control.NET and the VSAM / IMS data
used in Control I. There are a few options we could go with here.
There are six approaches that you could pursue. As background and for IBM's
recommendations, take a look at chapter 8 of the IBM Redbook titled,
Cross-Platform DB2 Stored Procedures Building and Debugging, posted to http://www.redbooks.ibm.com/abstracts/sg245485.html.
This IBM Redbook compares most of the approaches that are available to you:
1. Employ IBM DataPropogator to synchronize IMS DB records with SQL Server
records.
2. Connect the IMS region to a DB2 instance using the IMS attachment
facility, then use DTS to poll DB2 to capture changes. If you need to push
changes to IMS, then see the next approach.
3. Update DB2 using SQL Server Replication or DTS, then pass the changes to
DB2 to IMS DB using the standard DB2 stored procedures (see Redbook).
4. Call IMS program (using Transaction Integrator) that would read/write to
IBM DB records on behalf of Microsoft SQL Server (albeit in a non-SQL way--you'd
have create your own SQL consumer application to map from SQL Server Replication
INSERT, UPDATE, DELETE statements to record access commands via TI). Also, you
can use this same approach to call CICS program (using Transaction Integrator)
that would read/write to IBM DB records on behalf of Microsoft SQL Server
(albeit in a non-SQL way).
5. Create a new IMS program that calls SQL Server via the HIS 2004
Transaction Integrator for Host-Initiated Processing.
IBM solves this problem with a commercial software application. Microsoft
offers enabling technology only. You need to determine which platform is in the
control position: SQL Server or IMS DB.
Option 2 – Direct ODBC Calls using 3rd
Party App. This option would allow us to make calls to our DAO (data access
objects), which would then make ODBC calls into a 3rd party application sitting
on the Mainframe. The 3rd party application would be running in its own region
on the mainframe waiting for ODBC commands from our application. When it
receives a command, it would execute that ODBC call against the IMS database or
VSAM files, depending on where the data is located. In essence our application
would think it’s calling a relational database, when in reality it’s executing
changes against VSAM data files or IMS hierarchical data. We would have a
possible issue with two phased commits.
Option 3 – Direct DAO to DAO Calls through BPMS. This option would allow us
to make calls to our DAO (data access objects), which would then write the
commands to MQ messages. The MQ messages would be sent to a BPMS (BizTalk or
WebSphereMQ or Fuego -whatever the client wants). The BPMS executes the DAO’s on
the mainframe side and sends a transaction complete response to our application.
In this case the BPMS would handle our two phased commit issues.
Personally I like Option 3. The 3rd party solutions tack on a minimum of an
extra $150K in software licensing. Needless to say I would love to find a
solution that doesn’t require that kind of added expense for software.