Leigh Compton provided this workaround of the 32K limit in the CTG scenario.
"A few years ago,I developed an approach using both CTG & WebSphere MQ to help overcome this type of problem.
It's built on the assumption that the Java program will be using a smaller portion of the data when it builds the initial web page for the user - perhaps a summary of the data or a "menu" of available details.
This smaller portion is likely to be easily defined and very consistent, regardless of the total amount of data generated by the query.
The interaction works like this: Java program creates the query (input Commarea) and sends it to CICS over the CTG, CICS program executes the business logic associated with the query and produces an output Commarea containing the data which will be needed immediately to produce the initial web page.Excess (the detailed) data will be PUT to a MQ queue where the destination is on the Java server. The CICS program will place a correlation-ID from the PUT into the output Commarea so that it will be available to the Java program.
Java program takes the data from the Commarea and sends the initial web page to the user.
If/when the user requests the detailed data, the Java program will GET the message from the queue using the correlation-ID it received in the Commarea.
It capitalizes upon the best features of both CICS TG and WebSphere MQ.
The request to CICS is synchronous. If CICS cannot be reached, the Java application will know immediately. Had MQ been used, the Java application would have had to wait for a reply message to arrive and if a timeout occurs, the Java application is left with no knowledge of whether there is a problem or if the response was just *slow*.
The request/response data sent through the CTG can be significantly smaller than the total amount of data generated by the CICS application.
In many cases the Commarea size can be reduced, resulting in a higher throughput & less network time involved in the transfer.
|
