142 CCF-to-J2C Architecture Migration
5. After creating the Connection Factory, we entered the parameters that were
needed to establish connection with the CICS server (ServerName,
ConnectionURL, and the TranName).
Figure 7-51 Defining the connection properties
7.3.4 Problems
When we started testing the application with the manually created services, we
had problems with the results from CICS: The FormatHandler could not parse it.
After some work, we figured that the CICS transaction could not execute the
code because the input was wrong. An inspection of the byte stream being sent
to CICS and a comparison with the bytestream sent in the original application
indicated a codepage problem.
Chapter 7. Migrating a real-life application 143
Inspecting the code created in the CMA migration, we found that the Services
were supposed to use the codepage 8859-1 (8859_1 in the code) and not 037 as
we had specified.
We had to update all 29 Service definition files, two fields for each definition: one
for the request and one for the response.
Note: To get to the data being sent to and from CICS, we enabled the trace
feature in CICS TG. This can be done per parameters, but also controlled
programmatically using code similar to this:
// setup trace
T.setTFile(true, "d:\\tmp\\ctgtrace_managed1", 5000000);
T.setDebugOn(true);
One word of caution: This will generate a lot of data if it is left alone while the
application is running.
The class T is documented in the Javadocs that come with the CICS
Transaction Gateway software.
144 CCF-to-J2C Architecture Migration
Figure 7-52 shows the location of one of the fields in question.
Figure 7-52 Changing the codepage in the Service definition
Being able to communicate properly with CICS, we had another problem. The
transaction did not allow the execution.
An investigation into this problem revealed that there is a major difference
between the old ECIRequest and JavaGateway-based interface and the new
CCI-based interface.
In the old interface, only one parameter for the transaction could be specified: the
transaction ID. In the new interface, two parameters can be specified: the
TPNName and the Transaction name.
Note: All of the helper classes have to be regenerated after this change.
Note: We did a little experimentation to verify whether this was the problem:
We tried to replace the string 037 with 8859_1 in all the generated files, and it
worked without changing the Service definition files.
Chapter 7. Migrating a real-life application 145
In the old implementation, the TPNName defaults to be the same as the
transaction ID. In the CCI implementation, the TPNName defaults to the default
TPN defined in CICS and not the TransactionName.
As the CICS transaction in question instantiated other CICS transactions, among
them some VisualGenerator-created material requiring a special configuration of
the TPN, we repeatedly got errors of the type ELA2.
Setting the TPNName in the configuration of the CICS connector to be the same
as the Transaction name resolved the problem. Figure 7-53 shows the changes
that were made.
Figure 7-53 Setting the TPNName
After this modification, which only required one changed to solve the problem, we
had a new problem: The application retrieved data but had problems parsing the
retrieved data.
Investigating this, we noted that the returned data seemed to be truncated. Some
debugging revealed that the CICS transaction seemed to be doing an array copy
of the result into the output byte array, based on the length of the input byte array.
146 CCF-to-J2C Architecture Migration
To resolve the problem, we modified the size of the input commarea length to be
equivalent to response size, even if the size of the request record was smaller
(Figure 7-54). This setting is specified on the Service definition level so we had to
change this 29 times, two fields in each definition: the commarea and the
replylength.
Figure 7-54 Where to set the commarea and replylength values
Note: This investigation was very simple. We added code to the application to
retrieve the byte array from both the request and the response and print it to
standard out using a System.out.println statement. The resulting strings in the
console showed very clearly that the response was blank in the position that
was after the end of the request.

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

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.