[bit.listserv.cics-l] DFHZCP exits

C4322LR@UMVMA.BITNET (Len Rugen) (02/20/90)

I haven't used the exit to do this.  What we have done is to have a
callable module to make a change to TCTTE that remains in effect for the
duration of the session, or until reset.  Just changing the UCTRAN bit
doesn't seem to do anything, the field that works is TCTUECTB.
This could be done from a simple transaction, maybe even a 'prefix' to
the transaction that needs mixed case.  Here's a part of the code......

SETON    EQU   *                                                        00000680
         MVI   TCTEUCTB,X'01'          SET UCTRAN ON                    00000690
         B     RETURN                                                   00000700
         SPACE 3                                                        00000710
SETOFF   EQU   *                                                        00000720
         NI    TCTEUCTB,X'00'          SET UCTRAN OFF                   00000730
         B     RETURN                                                   00000740

RJD@UNC.BITNET (919 Joel Dunn 966-5837) (02/21/90)

I will try once again to respond to this note!  The mail system has now
eaten my last two attempts.

I don't have a direct answer to this question, but I think I can offer
some relevant comments.  I have written a XZCIN exit, and I found that
the only way I could debug it effectively was to use WTO's.  I suggest
that you code a simple exit, put in some WTO's and write the TIOA out
to the log and check on the case translation.  You should be able to
determine where XZCIN is invoked.

The subject of UCTRAN under MRO is extremely timely.  We have just gone
to production using MRO (CICS 2.1.1 under MVS/XA) and had a few problems
with this.  We have many application programs that link to systems-
supplied assembler routines to change TCTEUCTB to dynamically change
the case translation in a VTAM environment.  When these routines are
invoked in an AOR, the change has no effect, since the setting of
TCTEUCTB in the TOR determines the UCTRAN translation.  To solve this,
I modified our routines to start a transaction back in the TOR that
does a DFHTC CTYPE=LOCATE to find the matching TCTTE and zap the bit
to match the setting in the AOR.  It seems to work very well!

I am willing to share the code if anyone is interested.

Joel Dunn
Manager, Communications
UNC-Chapel Hill Administrative Data Processing

>     Can someone tell me precisely when exit XZCIN is driven??  Is it before
> or after UCTRAN occurs??
>
>     I am trying to install some IBM office automation software in an MRO
> environment.  All our existing applications require UCTRAN to be "on", but
> the office automation stuff wants it "off".  Among the replies I have
> received via our SE (EQUAL items and replies) were two apparently conflicting
> answers:  One said to write a GLUE for XZCIN to flip the UCTRAN bit in the
> TCTTE as required, and the other said that the XZCIN exit won't work because
> translation occurs BEFORE xzcin is driven.  We are on CICS 1.7.0.