CCF-to-J2C Architecture Migration

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.