CICS TS Performance (Part 2)

I ran into a problem implementing the changes I wrote abut in my last posting.

Seems CICS uses two types of VTAM RECEIVE requests. The RECEIVE OPTCD=ANY only solves half the problem. There are times CICS switches the LU being used into CS (Continue Specific) mode. A this point CICS uses RECEIVE OPTCD=SPEC. The buffer size used for these requests is not a SIT parameter.

The solution to the problem of setting the RECEIVE OPTCD=SPEC buffer size is to set the CICS TYPETERM IOAREALEN to 32767. Also, you must cold start CICS to have this take effect. The default value for the IBM supplied TYPETERMs appears to be a value ranging from 256 to 512 (but I admit I did not check all of them).

With RAMAX set to 32767 and the TYPETERM IOAREALEN set to 32767 all CICS RECEIVEs (ANY and SPEC) will use large buffers. Storage used for these buffers is located in 31-bit storage.

With virtual storage being cheap these days, the better trade off is to use large buffers and eliminate the CPU overhead/dispatching/etc involved with CICS doing multiple RECIEVE operations.

From the CICS Performance Guide ...

4.3.1 Terminal input/output area (TYPETERM IOAREALEN or TCT TIOAL)

If you are using VTAM, the IOAREALEN keyword of an RDO TYPETERM resource definition determines the initial size of the terminal input/output area (TIOA) to be passed onto a transaction for each terminal. The syntax for IOAREALEN is ({0|value1},{0|value2}). This operand is used only for the first input message for all transactions.

4.3.1.1 Effects

When value1,0 is specified for IOAREALEN, value1 is the minimum size of the terminal input/output area that is passed to an application program when a RECEIVE command is issued. If the size of the input message exceeds value1, the area passed to the application program is the size of the input message.

When value1, value2 is specified, value1 is the minimum size of the terminal input/output area that is passed to an application program when a RECEIVE command is issued. Whenever the size of the input message exceeds value1, CICS will use value2. If the input message size exceeds value2, the node abnormal condition program sends an exception response to the terminal.

One value defining the minimum size is used for non-SNA devices, while two
values specifying both the minimum and maximum size are used for SNA devices.

...

To verify this I modified these TYPETERMs for testing ...
E G(VSETYPE)

 ENTER COMMANDS
 NAME     TYPE         GROUP
+ VSE3277  TYPETERM     VSETYPE
 VSE3278Q TYPETERM     VSETYPE
 VSE32782 TYPETERM     VSETYPE
 VSE32783 TYPETERM     VSETYPE
 VSE32784 TYPETERM     VSETYPE
 VSE32785 TYPETERM     VSETYPE
 VSE3279G TYPETERM     VSETYPE
 VSE32792 TYPETERM     VSETYPE
 VSE32793 TYPETERM     VSETYPE

IOAREALEN was set as follows ...
APPLICATION FEATURES
BUildchain ==> No No | Yes
USerarealen ==> 255 0-255
Ioarealen ==> 32767 , 00000 0-32767
UCtran ==> Tranid No | Yes | Tranid

Since these are non-SNA TN3270(E) sessions I modified only the first value. In fact, for SNA sessions the process is more complex.

After changing the value for the TYPETERMs we use I ran some traces. Sure enough the IOAREALEN is used for the buffer size on RECEIVE OPTCD=SPEC for non-SNA sessions. Actually, if you are interested, the value you specify is rounded up based on some algorithm. Specifying 32767 actually causes CICS to issue a RECEIVE for x'800C' (32780) bytes.

Since most CICS 3270 access these days is through a TN3270E server, the actual VTAM communication is really just program-to-program (PLU-to-SLU). Sessions involved are non-SNA. I understand increasing buffer sizes for SNA sessions would probably be another more involved solution.

I would set RAMAX=32767 and change the non-SNA TYPETERMs to specify IOAREALEN=32767

So, there you have it.