150 CCF-to-J2C Architecture Migration
7.4.2 Numerical comparison of the results
Table 7-2 Numerical comparison of the migration results
The most interesting fact here is the difference in the number of code lines and
the number of support classes for the CMA-migrated and the manually migrated
implementation. The differences between having a Service definition per COBOL
ccp file and having a Service definition per combination of request and response
COBOL ccp files are clear.
The differences in the number of code lines in the application accounts for the
added complexity to the application. In the case of the manual migration, the
classes that could be removed are estimated to total about 500 lines of code.
7.4.3 How much time did it take?
We spent 10 person hours investigating the previous chapters in this book and
the CMA tool.
We spent 15 person hours performing the application analysis (excluding the
documentation of the analysis for this chapter).
CMA migration
We spent 15 person hours planning the CMA automated migration, including
identifying the code that had be changed to align to the new interface in the J2CA
classes and what the changes should be.
We spent about 40 person hours performing the CMA migration and the post
CCF J2CA (CMA) J2CA ()manual)
number of classes 246 542 495
number of support files 60 174 87
application code lines 22,182 22,620 22,944
number of support files 60 174 87
Note: Only Record classes are included in the CCF count. The CCF classes
also include 60 RecordType classes, which are implemented as WSDL files in
J2CA. The 60 RecordType classes account for 9745 lines of code.
This is listed in row named number of support files, to compare the
RecordType classes with the number of WSDL files created.
Chapter 7. Migrating a real-life application 151
We spent about 10 hours on application testing, stabilization, and verification.
This totaled 65 person hours for the migration of about 240 CCF record classes.
Manual migration
We spent 40 hours planning the manual migration, including the documentation
of the request/response combinations, identification of necessary code changes
to implement the use of the CommandProxy, experimenting with the J2CA tools
and the generated classes, and so forth.
We spent 50 person hours performing the actual migration, implementing all new
J2CA Service definitions (the WSDL files) and generating classes from them.
We spent about 40 hours on application testing, stabilization, and verification.
This totaled 130 person hours for the manual migration of about 29 J2CA Service
definitions with 60 COBOL artifacts.
Table 7-3 Hours spent on the migration
* The preparation was only done once.
CMA-based Manual
Preparation* 25 25
Planning 15 40
Implementation 40 50
Stabilization 10 40
Tota l 65 130
Note: Reasons for the additional hours spent on manual migration included:
One of the assumptions we had made, the codepage for the J2CA Service
definitions, proved to be wrong. Some of the additional time was used to
identify the problem and the solution and implement the solution by modifying
all of the Service definitions.
A second issue surfaced: The transaction control in CICS had some problems
because of the settings on the JNDI CICS connection.
Finally, the request and the response commarea length were linked in the
CICS transactions, making the manual configuration of the commarea size
and the replylength for each and every Service definition necessary. We
suppose this problem is very application-specific.

Get CCF-to-J2C Architecture Migration now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.