CCF-to-J2C Architecture Migration

Chapter 7. Migrating a real-life application 147

7.3.5 Result of the manual migration

After these changes, the application was working error-free using the new

CommandProxies and managed connection to CICS.

7.4 Evaluation of the migration

Within the time frame given, we could not make a full regression test of any of the

migration results. The Nova CICS interface that was tested appeared to work

flawlessly, making the migration a success as far as we can determine.

Evaluating the result of the migration effort is more complex. We want to

compare the performance of the migrated application to identify any changes,

especially in using managed connections instead of the original low-level, direct

use of the CICS TG.

We want to compare the number of code lines in the CCF classes against the

number of lines in the J2CA classes from the two different migrations, and we

want to compare the time spent performing the two migrations and how complex

the tasks were.

7.4.1 Performance

Technically there is no difference in the way the automated migration application

works compared to the original application. The only possibly significant change

between the two implementations of the application is an additional explicit class

instantiation, described in “Updating the code” on page 113.

Measurements show that there is a performance penalty from this, but only in the

first invocation of the class (most likely caused by the initial load of the class).

Later invocations of the class did not add any measurable performance penalty.

Next, we focused on the performance of the application using managed

connections versus the low-level CICS TG implementation.

Managed connection performance

We measured the performance of a specific CICS transaction, from the time it

was sent from the CTGCommand until it was retrieved back again. We call this

measured time

transaction time.

In the low-level interface implementation, we decided to measure the transaction

time in the flowECI() method, which is called after the ECIRequest has been

created from the request byte array. (Figure 7-5 on page 88 shows interaction

details.)

148 CCF-to-J2C Architecture Migration

In Example 7-15, the location of the start of the measurement is marked with 1.

The end of the measurement is marked by

2.

Example 7-15 Transaction time measurement in the low-level implementation

protected void flowECI(ECIRequest myEciRequest, String myBpiFunction, boolean

runningThreadded ) throws com.ibm.dk.nova.exception.NovaException {

1 long loadStart = System.currentTimeMillis();

com.ibm.bisic.sfw.util.PerformanceTimeSet timeSet = null;

if (timer != null) {

timeSet = new com.ibm.bisic.sfw.util.PerformanceTimeSet();

if (runningThreadded){

timer.addFunction(timeSet);

} else {

timer.addBackend(timeSet);

}

timeSet.setName(myBpiFunction);

timeSet.setStart();

}

NovaGateway.getInstance().flow(myEciRequest);

if (timeSet != null) {

timeSet.setEnd();

}

// - Check (for ups!) the results

if (myEciRequest.Cics_Rc != 0)

throw new NovaException(

"Cics_Rc=" + myEciRequest.Cics_Rc,

ErrorCodes.ERRCOD_JAVAGW_ECIRC_ERROR,

"CTGCommand.flowECI " + myEciRequest.getCicsRcString() + " " +

myEciRequest.Abend_Code);

if (myEciRequest.Commarea == null)

throw new NovaException(ErrorCodes.ERRCOD_JAVAGW_COMAREA_ERROR,

"CTGCommand.flowECI");

if (myEciRequest.Commarea.length == 0)

throw new NovaException(ErrorCodes.ERRCOD_JAVAGW_COMAREA_ERROR,

"CTGCommand.flowECI");

2 long loadEnd = System.currentTimeMillis();

long flowDur = loadEnd - loadStart;

System.out.println("CICS Execute: " + flowDur);

}

Chapter 7. Migrating a real-life application 149

In the managed connection implementation, the location for the measurement

was given; transaction time is the time it takes to perform the execute method on

the CommandProxy.

Example 7-16 Transaction time measurement for a managed connection

...

KeywordGenericCommandProxy proxy = new KeywordGenericCommandProxy();

proxy.setKeywordGenericRequestRecord(request);

long startExe = System.currentTimeMillis(); //<<-- measurement starts

proxy.execute();

long endExe = System.currentTimeMillis();//<<-- measurement ends

long durationexe = endExe - startExe;

System.out.println("Duration - CICS execute: " + durationexe);

response = proxy.getKeywordGenericResponseRecordPart();

...

It is a valid objection to say that for the measurements to be equal, the buildECI()

method should have been included in the transaction time for the low-level

implementation. We decided that we wanted to measure as close as possible to

the interaction with CICS.

In the case of the low-level implementation, this meant measuring in the

flowECI() method.

In the case of the CommandProxy implementation, we had little choice: The

lowest level of detail for the CICS interaction is the execute() method on the

CommandProxy.

This creates an offset where, if the two different implementations have the same

performance, the numbers for the low-level implementation should be less than

the numbers for the implementation that uses managed connections.

We did the measurements in the WTE, using the same back end for both the

low-level implementation and the managed network connection implementation.

The connection was a network connection that did not use local protocol.

The measurements show a consistent reduction in transaction time of about

100 ms per call when using managed connections from a CommandProxy class,

compared to the low-level implementation.

We speculate that this rather dramatic change (about 20% to 30%, depending on

the back-end processing time) is due to a more resource-optimized

implementation in the managed connection implementation. This implies that this

reduction in transaction time is independent of the protocol being used for CICS

TG, TCP or local. Further experiments will have to be performed to validate this.