In his recent blog post, Matthew Wilson describes how CICS TS V5.3 provides you with the ability to use a Java EE application running in a Liberty JVM server from any CICS program. In this article the performance costs in CPU time and transaction response time when linking to COBOL or Java versions of a simple application from a COBOL program are compared. There is a Java version of the application for both Liberty and OSGi JVM servers. Because the linked target application is trivial the cost comparison is essentially comparing the supporting infrastructure rather than comparing the costs of using different programming languages.

How does the performance of the simple application compare?

The details are shown later in this blog, but in summary linking to the Java EE version of the application running in a Liberty JVM server has lower total CPU cost than the OSGi JVM server version, although this extra time is eligible to be offloaded to a zIIP processor. The Liberty JVM server provides optimized thread reuse so it consumes less total CPU time than the version deployed in an OSGi JVM server.

The response times of the COBOL and Liberty versions are similar. The optimised thread management of the Liberty JVM server provides shorter response times than the OSGi JVM server version.

Link to Liberty overview

APAR PI63005 provides support for a CICS program to invoke a Java EE application running in a Liberty JVM server. To be invoked by a CICS program, the Java EE application is required to be a plain Java object (POJO) packaged in a Web ARchive (WAR) or Enterprise ARchive (EAR). CICS creates the program resources described by the @CICSProgram annotations when the application is started in a Liberty JVM server. Data passed between programs by channel is supported. COMMAREA and INPUTMSG are not supported.

The application used for this study

The application comprises just two CICS programs. A terminal-based CICS transaction initially invokes programA and this LINKs to programB.
The logic flow between these programs is:

  • programA is invoked at a terminal and builds a container containing a short string and then does an EXEC CICS LINK to programB.
  • programB reads the contents of the passed container and copies them to a response container and returns to programA.
  • programA checks the contents of the response container and writes an OK message to the terminal.

Application flow diagram

programA is written in COBOL. There are three versions of programB comprising very similar application logic:

  1. COBOL
  2. Java deployed in an OSGi JVM server (OSGiJVM)
  3. Java deployed in a Liberty JVM server (LinktoLiberty)

Extract of the source for programA

       PROCEDURE DIVISION.                                    
       MAIN-PROCESSING SECTION.                
      * Logic to create Container1 needed here  ............. 
           EXEC CICS PUT CONTAINER('Container1')  
                CHANNEL('CCHA')                   
                FROMCODEPAGE('IBM037')            
                FROM(WS-RANDOM-DATA)              
                END-EXEC.                           
      * LINK to program of choice passing CHANNEL               
           EXEC CICS LINK PROGRAM('PROGRAMB')                
                CHANNEL('CCHA')                        
                END-EXEC.                              
      * Read response CONTAINER 
           EXEC CICS GET CONTAINER('Response')                  
                CHANNEL('CCHA')                                 
                INTO(WS-RESPONSE)                               
                FLENGTH(WS-RESPONSE-LEN)                        
                END-EXEC.                                       
      * Logic to check Response CONTAINER needed here  .............           
        RETURNTOCICS.                 
           EXEC CICS RETURN END-EXEC. 
           EXIT.  

Extract of the source for programB: COBOL version

This COBOL version of programB is defined to CICS with CONCURRENCY(REQUIRED) so that the application is run mainly on an L8 TCB.

       PROCEDURE DIVISION.                               
       MAIN-PROCESSING SECTION.                         
      * Read passed CONTAINERs                            
           EXEC CICS GET CONTAINER('Container1')          
                CHANNEL('CCHA')                           
                INTO(WS-RANDOM-DATA)                      
                END-EXEC.  
      * Logic to copy Container1 to Response CONTAINER needed here  .............      
           EXEC CICS PUT CONTAINER('Response')            
                CHANNEL('CCHA')                           
                FROM(WS-RESPONSE)                         
                END-EXEC.
      * Back to CICS 
        RETURNTOCICS.                      
           EXEC CICS RETURN END-EXEC. 
           EXIT.

Extract of the source for programB: Java OSGi JVM server version

public class GetandReturnChannelOSGi 
{
    public void run() throws CicsException
    {
        Task t = Task.getTask();
        if (t != null)
        {
            String containerName = "Container1";
            Channel channel = t.getCurrentChannel();
            Container container1 =  channel.getContainer(containerName);
            String data = container1.getString();
            Container response = channel.createContainer("Response");
            response.putString("OK was sent " + data);
        }	
    }

    public static void main(CommAreaHolder cah) throws CicsException
    {
        GetandReturnChannelOSGi newClass = new GetandReturnChannelOSGi();
        newClass.run();
    }
}

Extract of the source for programB: Java Liberty JVM server version showing @CICSProgram annotation

public class GetandReturnChannel 
{    
    @CICSProgram("JAVACHRT")
    public void link() throws CicsException
    {
        Task t = Task.getTask();
        if (t != null)
        {
            String containerName = "Container1";
            Channel channel = t.getCurrentChannel();
            Container container1 =  channel.getContainer(containerName);
            String data = container1.getString();
            Container response = channel.createContainer("Response");
            response.putString("OK was sent " + data);
        }	
    }
}

How is the cost of the application measured?

A simulated network of 100 terminals was used to execute the CICS transaction initially invoking programA at a rate of about 5000 requests per second. A warmup period of 1 minute was sufficient to ensure that the Java applications were compiled by the JIT compiler to an optimised level producing consistent transaction CPU costs.

RMF was used as the source of the performance data used in this study. RMF can measure the CPU use and the number of transactions executed by a CICS region. This data was used to derive the average transaction cost. RMF also records the zIIP-eligibility of any CPU consumed. If the CPU is non-zIIP eligible then it has to run on a general processor so maximizing zIIP-eligibility is generally a good thing. Analysis of RMF data and measurement of zIIP-eligibility is described in more detail in the IBM CICS Performance Series redpaper.

The results – comparing response time and cost per transaction

Comparing cost of EXEC CICS LINK

What’s the difference in CPU cost between link to COBOL and Java?

The programs used for this study are simple, with very little application logic. They demonstrate the difference in CPU cost of the EXEC CICS LINK infrastructure within CICS that enables calls to COBOL or Java CICS programs.

Linking to COBOL is the lowest cost, both in terms of total and non-zIIP eligible CPU. Linking to the Java EE version of the application running in a Liberty JVM server costs just over twice the total CPU cost of the COBOL version and about half of this extra time can be offloaded to run on a zIIP processor. Using either version of the Java program costs more total CPU than the COBOL version and also costs more general processor time too. Much of the cost of running Java is zIIP-eligible but profiling analysis has shown that the management of the extra TCBs needed in the Java cases needs increased z/OS dispatcher time. The increased time spent in z/OS dispatching routines is not zIIP eligible. Using JCICS also creates more calls to the CICS EXEC interface (with ASSIGN and CONTAINER management calls) which leads to a further increase in general processor time compared to the COBOL case.

Compared to the OSGi JVM server case, Java and UNIX threads are managed more efficiently in the Liberty JVM server case by employing thread reuse techniques. This improved efficiency makes the Liberty JVM server case significantly cheaper in terms of total CPU cost than using an OSGi JVM server. You can read more about this optimized thread usage in Ian Mitchell’s blog post.

What’s the difference in response times between link to COBOL and Java?

The response times for the COBOL and Liberty JVM server versions were very similar and CICS suspend time was the main contributor to this time. At the transaction rate of about 5000 per second for all three measurements, waiting for first CICS dispatch (recorded in the CICS monitor data field DSPDELAY) accounted for most of the time the transactions were suspended. A longer response time was observed for the OSGi JVM server version. This was due to a longer dispatch time caused by the T8 TCB being placed into an operating wait state for much longer times by the less efficient Java and UNIX thread management of the OSGi JVM server.

3 comments on"Link to Liberty in CICS TS V5.3 – what’s the performance cost?"

  1. Hans-Peter(ivv) April 22, 2017

    Hi Graham,
    having read your report, I am wondering whether we should migrate our current CICS Java OSGi bundles to Liberty for performance reasons.
    Now that I can LINK into Liberty from Cobol, are there still advantages of OSGi JVMSERVER versus CICS Liberty? What kind of things can I do in OSGi JVMSERVER which are not supported in CICS Liberty? What is the future of OSGi JVMSERVER in CICS?

    • Grham Rawson April 24, 2017

      Hello Hans-Peter – my blog article shows how the cost of LINKing from a CICS COBOL application to a CICS Java application benefits from the thread management efficiencies of the CICS Liberty JVMSERVER. Unless you are performing many LINKs between COBOL and Java applications you probably wouldn’t make a saving compared to the overhead costs of running a CICS Liberty JVMSERVER and the Java EE environment that it provides. It would be interesting for you to try it. As for the future of OSGi JVMSERVER support, I believe it’s here to stay but the CICS Beta site is a good place to look for future developments (https://www-01.ibm.com/software/data/enterprise-application-servers/cics/trials/).

  2. Phil_Wakelin April 26, 2017

    Aside from the semantics of the call, the main difference is that link to an OSGi JVM server supports linking with COMMAREA or Channel, supports all syncpoint options, and supports JMS to MQ using the MQCONN controlled by the CICS UOW. Link to Liberty on the other hand currently only supports a link with a Channel and doesn’t support syncpointing in Java, or JMS via the MQCONN, however, Liberty has a much richer Java EE API and supports T4 JDBC and remote JMS which are powerful new topologies.

Join The Discussion

Your email address will not be published. Required fields are marked *