Interlanguage Calls (ILC) between Java and COBOL, which allow to use the same Working Storage via different ILC calls of one COBOL program

We are modernizing our application and during this process the programs are migrated from COBOL to Java. Because it is not possible to do this in one big step, we do it component by component in many small steps. This requires that ICLs work well. In batch ILCs allows that Working Storage can be reused, when a Java component calls the same COBOL program many times. That means, you can use the information in the Working Storage, which are left behind, from the last call. This is especially helpfull for performance reasons, means specific SQLs only have to be executed one time during one transaction. But also for restart points, means, if the called program has to provide data in bundles or extremely row by row to determine the next bundle or row. Of course you can provide all this information in the interface but this causes a lot of changes and is not necessary in Batch and also not necessary in CICS, when you only use COBOL Calls without Java and without EXEC CICS LINK. 

In the CICS environment ILCs between Java and COBOL have to be implemented via EXEC CICS LINK and as a consequence each via Java called COBOL program creates a new LE enclave with new initialized Working Storage. Different from batch you can't use the information, which is left from the last call in the Working Storage. With each call of Java you get new initialized Working Storage. This is not good because the behaviour between Batch and CICS is different and we use the same code in both environments (ILC are transparent hidden via a framework component).  Also the benefits of the Batch behaviour can't be used in CICS. The requirement is, that CICS provides the possibility to support ILCs from Java to COBOL, which allows it to reuse the Working Storage of COBOL programs for further calls. In addition the access to Db2 should work in the same way, means COBOL and Java access Db2 via one thread and as one UOW during a transaction execution.