Like the COBOL programmers who coded their original applications decades ago, mainframes are showing their age but still do useful tasks in the
While almost all new SOA development at the largest exclusive state-fund workers' compensation system in the U.S. is done in .NET, Stacy Pickett, software architect for Entarco USA Inc., an enterprise architecture consultancy, said mainframes still play a part. He is focused on the data services portion of the SOA implementation at BWC and most of the data relating to more than $19 billion in assets is in mainframe IBM DB2 databases interacting with COBOL applications and using CICS.
In the SOA implementation the DB2 data is need by .NET applications that provide it as services that update the status of workers' compensation policies and claims for employers and workers accessing the information via standard Web browsers, Pickett explained.
In some cases the decades old MVS mainframe operating system is up to the task, he said, but in other areas it is not. Finding a middle way between sending all the mainframes into retirement or living with legacy limitations has been one of Pickett's challenges.
"Where it's appropriate we are looking at moving some of the code off MVS, but leaving the actual database on MVS," he explained. "For instance, CICS COBOL has 32k data limits of how much data you can pass in and out through that pipe. So we've had to code some applications to make multiple passes through the CICS servers to get all the data we need."
While multiple passes of the database works, it is not the most efficient way to provide data to end users, so Pickett is looking at moving the data access off the mainframes in cases where large amounts of data are required.
"Where we can transition those pieces to a .NET C# server and then access mainframe DB2, we're trying to do that to get around some of the limitations of what you can do with COBOL," he explained. "If the application design doesn't call for a large amount of data to be passed back and forth then it would most likely remain in COBOL and CICS DB2. For the most part we're still doing CICS DB2, but when we need a large pipe for the data, we'll shift over to the C# server."
An early SOA adopter, BWC first began transitioning from a client/server system with a Web interface for employers and workers to the current SOA implementation more than four years ago, Pickett said. The motivation for the transition to SOA was to create a more flexible environment for assembling future applications.
"The main advantage is using the SOA concept where you're separating the technology from the user interface and the backend server," he said. "Eventually they want to have a pieces and parts application where they can change how they implement the data sources on the backend without affecting the UI on the front-end, and vice versa."
The application he helped design and develop to link the .NET environment via a COM proxy to the COBOL applications and DB2 data was written in the CA Gen development environment, he explained. The integration is done through the webMethods Broker.
"The .NET program calls the COM piece, which then goes through the communications software to call the MVS server, Pickett said.
In this way Pickett has used CA Gen to deliver more than 100 reusable mainframe services, consisting of CICS transactions.
He also said that the automated code generation capabilities in CA Gen compensate for one of the problems cited by those who advocate re-writing all legacy code: How are you going to maintain the applications after the aging population of COBOL programmers retire? Pickett said maintenance of the COBOL applications is done using a pseudo-code feature in CA Gen that allows programmers to write changes in simple English and automatically generate COBOL updates.
Based on his experience with the BWC implementation, Pickett said he expects mainframe legacy systems to be viable in SOA for a long time to come.
"They've been saying the mainframe was dead for decades," he noted, "and it's still here."