CICS Transaction Gateway V5 The WebSphere ... - IBM Redbooks

332 CICS Transaction Gateway V5
as a copy of the supplied mirror program DFHMIRS. If you have implemented this
use of DFHMIRR, you should install the fix for APAR PQ38644 after migrating to
CICS TS V1.3, then upgrade your CICS TG to V4 or V5 to enable use of the
EXCI Version 2, and so abandon DFHMIRR altogether.
This technique is to be encouraged, since it also solves the possible problem of
double code page conversion in a CICSplex. This can occur when the user
application specified in the ECIRequest is actually in a region remote from the
region that first runs the mirror transaction. The mirror transaction will set the
data conversion trigger to off when routing the DPL request through to the
remote region. Prior to the EXCI Version 2, you had to specify different DFHCNV
tables for the two CICS regions, or associate different mirror program names to
the mirror transactions in each region.
Table A-1 Mirror transaction characteristics for ECI requests
Default ECI
mirror transid
Supports data
conversion
trigger?
Mirror calls
DFHCCNV on
DPL request?
LU 6.2 or TCP62
connection
EXCI V2 connection
(CICS TG V4 or 5)
CPMI CSMI CPMI
Yes, and the trigger
is always set in the
ECI request
If data conversion
trigger is set, mirror
transid is CPMI, or
mirror program is
DFHMIRR
Yes, and the trigger is
always set in the ECI
request
Only if data
conversion trigger is
set, mirror transid is
CPMI, or mirror
program is DFHMIRR
EXCI Version 1
connection
Java on z/OS
Java programs executing on z/OS and using the CICS TG ECI methods deserve
a special mention because of the code page considerations on z/OS. Java
strings are stored in Unicode, and Java byte arrays are stored in the native code
page of the operating system. The COMMAREA flowed to CICS in an
ECIRequest is a Java byte array, but is often converted to or from a string, for
handling within the Java code. If the Java program executes in a Java Virtual
Machine (JVM) on z/OS, then conversion of a string to a byte array will require
the encoding to be specified.
In our previous example (Figure A-2 on page 331), we used the method
String.getBytes() to convert our string to a byte array, and the default String
constructor to convert the byte array to a string. This will convert the byte array to
a string using the default platform encoding. On Intel or UNIX platforms, this
encoding will probably be US ASCII (ISO 8859-1); however, on z/OS it will be
No
Only if mirror transid
is CPMI, or mirror
program is
DFHMIRR