I have a COBOL CICS process running on a mainframe legacy system. The process does over 2K DMLs in a highly concurrent DB environment. After each CRUD operation, the result is used to make further computations followed by CRUD operations again. This entire process runs under a transaction block such that any failure before its successful completion results in the entire set of DB changes to be rolled back, only on success of each and every step in the process till the end, there is a commit. The COBOL program is written in a manner that it doesn't consume more than 20 odd seconds for its completion or failure lest the other process starve for DB resource(locks, stalls etc.) due to the enormity of this transaction.

Now we are commissioned to expose this legacy application as a Java SOAP web service. The three approaches I have are:

  1. The Service layer of my Java code sends a message to the queue with input parameters, the already existing COBOL program picks the message from the queue and does the transaction. Java layer pings the queue asynchronously and when it has got a result from the COBOL process, it sends it back to the Controller.

  2. Write a Stored Procedure which mimics the job done by the COBOL process including the DB transaction and call that SP from Java Service layer.

  3. Write the Business logic inside Java Service/DAO layer and the transactions inside a Spring transaction block.

Business doesn't want the #1 approach as it means dependency on the legacy COBOL program. I have two doubts here :

  1. I have an understanding that SPs are better from performance point of view. But will the SP be able to handle 2K or more odd DMLs within a transaction block and do the job in time at least equivalent to the time which COBOL process takes ? If yes, then will it be efficient enough in locking-releasing DB resources as the DB is highly concurrent and I don't want other processes to starve due to it.

  2. I have never done a DB transaction of this magnitude from the Java code and I doubt whether Spring transaction block can hold 2K DMLs in a single block effectively. Even if it does I'm sure that it wouldn't match the speed of COBOL or SPs, hence it may acquire locks on records etc. and starve other processes which needs to access the same for long time.

The transactions are not on a particular DB table, it is distributed over 20 odd different tables containing critical financial data. I was thinking of breaking the large number of CRUD operations in chunks of Spring transaction blocks, but then it would have been a humongous task to code the entire roll back logic in Java, but it's alright, my main concern is locking other processes from DB access in the meanwhile.

I am a Java developer with meager knowledge of RDBMS and practically no knowledge of COBOL. I would be grateful if someone can help me point to the right direction so that I can come out with a solution myself.

  • Two... thousand DML statements? All in a single transaction? Commented Aug 27, 2014 at 16:47
  • @RobertHarvey Yes :(( hence the question, anything manageable would have been easier for me to find out a solution myself.
    – AllTooSir
    Commented Aug 27, 2014 at 16:51
  • Which database are you contemplating? Oracle? Commented Aug 27, 2014 at 16:53
  • @RobertHarvey Yes Oracle 11g is the existing DB !
    – AllTooSir
    Commented Aug 27, 2014 at 16:55
  • 3
    Is there any chance your 2k statements could be simplified into more set based operations? It just sounds like a you have a tumbling data antipattern
    – billinkc
    Commented Aug 27, 2014 at 17:04

2 Answers 2


I'd say 99 times out of 100 the answer is to grit your teeth and re-use the existing COBOL code. It sounds like it might have some fairly complex logic behind the scenes; unless you actually have an up-to-date and accurate spec you might have trouble re-producing the logic in all its nuances. This is bad mojo on a financial application as the bean counters will want bug-for-bug compatibility with the legacy code.

So, as a first stop, I would suggest that you seriously investigate what is needed to wrap your legacy process or integrate it with the front-end. You might take a look at the COBOL-Java integration options available from Micro Focus.

If you really can't re-cycle the existing code then you have a significant problem. While a sproc might well do what you want, you have the problem of making something mimic the exact behaviour of an apparently complex and probably poorly documented COBOL application.

Unless your replacement process is radically slower, wrapping 2000 DMLs in a transaction isn't going to be a major issue. It's possible to wrap entire ETL processes in a transaction and have them roll back on a failure. I have seen an application where it was necessary to do this, although it is unusual. Splitting a financial transaction is a no-no, especially on a double entry system. In almost all cases it should commit or roll back atomically. Stick with the single transaction.

The fact that the COBOL application does computations one DML at a time and uses the results in the next step of the computation does not bode well for conversion to set operations. Be prepared to have to do this row-by-row and find a way to make it run fast. A stored procedure may well be the way to do this. You don't say what DBMS you're using (DB/2 for Z/OS?).

Also, you might have to drop down to XA transactions (java.transactions API) and JDBC, especially if you need to work in the client layer. If you want good performance on 2000 row based operations you might have to go below the framework.


One of the promises of SOA is leveraging legacy systems through an abstraction layer, and a service bus.

You first say business is asking you to expose the legacy application as a web server, but then you say business doesn't want option #1 because it's dependant on the legacy COBOL program. So what they are really asking you then is to re-write it.

In that case the best approach is #2, rewrite the thing in stored procedures.

That has the following advantages over the Java/DAO approach:

  1. Store-procedure-oriented languages like PL/SQL, PL/PgSQL or Transact SQL ( you don't tell which RDBMS you are using ), being purpose-specific (as opossed to general purpose) are more COBOL-like than Java. They have a smaller set of instructions, a simpler grammar and, in general, it would be easier to write a line-by-line translation of a COBOL program in PL/SQL than, say, in Java.

  2. Stored procedures run in the database server, thus running faster than a client code in Java in an application server or client.

  3. You will also do better whithout the overhead of DAO/JDBC, since speed is so critical.

  4. What better to optimally handle blocks and transactions that the very language specifically built into the RDBMS for that very purpose.

I believe the first one of those four advantages is the one that is most important. And you will have an aditional advantage in that a non-programming, business expert will most probably understand the code and could help you validate formulas and business rules.

I've done a fair ammount of Oracle's PL/SQL programming myself for critical applications and I can tell you it's capable of handling very well huge transactions. I think, yes, SP are a tool fit for that purpose.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.