MustGather: Collect Trouble Shooting Data for Read First/Fix List for VTAM Channel to Channel (CTC) and Multi-path Channel (MPC) for z/OS Communications Server

Resolving The Problem

Table Of Contents

Section 1: Overview of CTC and MPC

• Section 1.1: Channel-to-Channel (CTC)
• Section 1.2: Subarea Multipath Channel (MPC)
• Section 1.3: APPN Multipath Channel (MPC)
• Section 1.3.1: Non-HPDT MPC (AHHC)
• Section 1.3.2: HPDT MPC

Section 2: CTC/MPC Operands

• Section 2.1: General Operands
• Section 2.2: CTC Specific Operands
• Section 2.3: HPDT Specific Operands
• Section 2.4: AHHC Specific Operands

Section 3: Gathering Documentation
Section 4: Recommended Maintenance
Section 5: Missing Interrupt Handler

Section 1: Overview of CTC and MPC

Section 1.1: Channel-to-Channel (CTC)

A channel-to-channel (CTC) connection utilizes a single subchannel for subarea host-to-host communications. The CTC is a basic data transport in which a single subchannel is used for both read and write operations. Since this type of connection only supports a single subchannel, there is no built in redundancy should an error be encountered.

To define a CTC connection between two subarea nodes, code a channel-attachment major node (VBUILD TYPE=CA) with LNCTL=CTCA on the GROUP definition statement. For more detailed information about defining CTC connections, refer to z/OS Communications Server: SNA Resource Definition Samples.

Back to top

Section 1.2: Subarea Multipath Channel (MPC)

A subarea multipath channel (MPC) connection is a logical extension of the basic CTC connection. This type of connection allows you to code a single transmission group (TG) for host-to-host communication that uses multiple write-direction and read-direction subchannels.

The main benefits of using MPC over CTC are improved turnaround time, throughput and availability. Because each subchannel operates in only one direction, the half-duplex turnaround time that occurs with other channel-to-channel connections is reduced. If you code a TG in which the subchannels are divided between two physical channels, you can increase availability because the TG will have a path to use, even if one physical channel fails. Because each TG can use more than one channel, and because the turnaround time required for half-duplex is reduced, throughput is increased. If multiple write subchannels are used, traffic is distributed among the subchannels as traffic requests increase. The use of multiple subchannels improves both throughput and availability. The MPC connection can tolerate subchannel failures as long as at least one read and one write device defined within the TG are active and online.

To define an MPC connection between two subarea nodes, code a channel-attachment major node (VBUILD TYPE=CA) with LNCTL=MPC on the GROUP definition statement. For more detailed information about defining subarea MPC connections, refer to z/OS Communications Server: SNA Resource Definition Samples.

Back to top

Section 1.3: APPN Multipath Channel (MPC)

In APPN environments, multipath channel connections are also available. These connections may operate in Non-HPDT and HPDT modes.

Back to top

Section 1.3.1: Non-HPDT MPC (AHHC)

Non-HPDT MPC, also called APPN Host-to-Host Connection (AHHC), is used by VTAM to enable connections between a VTAM APPN host node and an adjacent VTAM APPN host node.

To define an APPN non-HPDT MPC connection between, code a TRL major node (VBUILD TYPE=TRL) with LNCTL=MPC and MPCLEVEL=NOHPDT on the TRLE definition statement. For more detailed information about defining APPN non-HPDT MPC connections, refer to z/OS Communications Server: SNA Resource Definition Samples.

Back to top

Section 1.3.2: HPDT MPC

HPDT MPC, also called APPN Node-to-Node connections (ANNCs), is used between a VTAM APPN host node and an adjacent VTAM APPN host node or between a VTAM APPN host node and an adjacent nonhost APPN node.

This type of connection offers a High Performance Data Transfer (HPDT) feature. This feature utilizes storage from the Common Storage Manager (CSM) to eliminate data moves to and from the MPC transmit buffers to improve overall performance. When MPC is executing with this feature, it is considered to be in HPDT mode.

To define an APPN HPDT MPC connection between, code a TRL major node (VBUILD TYPE=TRL) with LNCTL=MPC and MPCLEVEL=HPDT on the TRLE definition statement. For more detailed information about defining APPN HPDT MPC connections, refer to z/OS Communications Server: SNA Resource Definition Samples.

Note: In order to utilize HPDT MPC, both connection partners must enable the function and have RTP-level HPR support.

Back to top

Section 2: CTC/MPC Operands

Review the operands listed in this section for correct coding and usage. Please see the SNA Resource Definition Reference for details about each operand.

Back to top

Section 2.1: General Operands

- MAXBFRU (TRLE/CTC/MPC Operand)
- REPLYTO (TRLE/CTC/MPC Operand)
- IOBUF (Start Option)

Back to top

Section 2.2: CTC Specific Operands

- MIH (GROUP or LINE Operand for LNCTL=CTCA)
Note: See section 5 for important information about Missing Interrupt Handlers

- MIHTMOUT (Start Option)
Note: See section 5 for important information about Missing Interrupt Handlers

- DELAY (GROUP, LINE or PU Operand for LNCTL=CTCA)

Back to top

Section 2.3: HPDT MPC Specific Operands

- MPCACT (Start Option)
- MPCDYN (GROUP or LINE Operand for LNCTL=MPC)
- MAXREADS (TRLE Operand)
- PACKING (TRLE Option)
- STORAGE (TRLE Operand)
- MPCUSAGE (TRLE Operand)

Back to top

Section 2.4: AHHC Specific Operands

- MPCACT (Start Option)
- MPCDYN (GROUP or LINE Operand for LNCTL=MPC)

Back to top

Section 3: Gathering Documentation

The following minimum doc is required for VTAM CTC/MPC problems and must be run concurrently from both machines.
I. VTAM internal trace (VIT) with OPT=(CIO,PIU,MSG,PSS,CIA),MODE=EXT
II. CCWTRACE (GTF with IO and SSCH or equiv & DATA SIZE=100)
III. A dump of VTAM obtained using F vtamproc,CSDUMP

Back to top

Section 4: Recommended Maintenance

The following maintenance is recommended for all VTAM channel-to-channel (CTC) users, including the D/T3088, and for all VTAM Multi-path Channel (MPC, AHHC, ANNC) users.

The following applies to all VTAM releases:
For CTCA users apply the highest level of ISTTSCXE.
For MPC users apply the highest level of ISTTSC8E.
For HPDT users apply the highest level of ISTTSCMA.

To find the current module level, issue:
D vtamproc,VTAMSTOR,MODULE=module_name

For V2R1 MPC/AHHC users see:

OA44091 DISPLAY TRLE FOR MPC DEVICE IST1221I NOT REFLECTING CORRECT
OA47307 MPC HANGS PREQC STATE AT ACTIVATION. LOGS SHOW IST574E AND
INOP ON THIS SIDE - INOP AND VARY INACT ON THE OTHER SIDE. (FIN)
OA48196 IST1222I XXXX DEVICE XXXX IS INOPERATIVE WHEN MPC IS ACTIVATED.
OA48743 IST1222I READ DEVICE XXXX IS INOPERATIVE - SEEN FOR MPC WITH
MORE THAT ONE READ/WRITE - WHEN ONE VTAM IS RE-STARTED.
OA49292 ABEND0C4 IN VTAM MODULE ISTTSC8S

For V2R2 MPC/AHHC users see:

OA48743 IST1222I READ DEVICE XXXX IS INOPERATIVE - SEEN FOR MPC WITH
MORE THAT ONE READ/WRITE - WHEN ONE VTAM IS RE-STARTED.
OA49292 ABEND0C4 IN VTAM MODULE ISTTSC8S


Back to top

Section 5: Missing Interrupt Handler

z/OS Communications Server supports a variety of protocols in device-layer communication to attached devices. One important aspect of device-layer communications, as it relates to the Missing Interrupt Handler, is whether communication to the attached device is via a single subchannel, or via multiple subchannels.

When multiple subchannels are used for device-layer communications, WRITE operations and READ operations are separated onto their own subchannel(s). On a multi-subchannel device, the Missing Interrupt Handler is automatically (by VTAM) configured OFF on the READ subchannel(s). (This is necessary, as a READ command is normally active for such devices, and MIH would detect a missing interrupt on the READ subchannel(s) any time the device experienced an idle period.) Therefore, there is no need to specify any MIH values for VTAM read devices.

However, it’s important to configure a reasonable MIH value on the WRITE subchannel(s) on a multi-subchannel device as this will protect the system from a storage-usage spike, brought on by a hung device. In addition, do NOT set an MIH value of 0 (which disables MIH) for a VTAM write device or a single-subchannel device. Reasonable values for MIH on the WRITE (or only) subchannel range from 15 seconds to 30 seconds (A value of 30 seconds might be warranted if either channel extenders are in the configuration, or dispatching delays (due to running second level under VM) are possible).

For non-extended CTC channels, being driven by z/OS Communications Server running native, 15 seconds is the recommended MIH value.

Note: For some write operations on MPC HPDT write devices, z/OS Communications Server will dynamically set an MIH value (generally 30 seconds). However, in order to provide comprehensive MIH coverage, it is still recommended that users configure an MIH value for these devices.

To summarize the above, MIH on the WRITE subchannel should be configured ON, with a value of between 15 and 30 seconds.

Note: To override the default MIH value for a given subchannel, either use the MIH statement in the IECIOSxx parmlib member or use the SETIOS MIH command.

MIH can be changed while the system is running, use command:
SETIOS MIH,DEV=(XXXX),TIME=YY:YY

**Where XXXX is the write CUA and YY:YY is the appropriate period of time.**

You can display the MIH settings using the following command:
D IOS,MIH,DEV=(YYYY,XXXX)
**Where YYYY is the read CUA and XXXX is the write CUA. **

Setting MIH after the hang occurs will not clear the hang. You must INACTIVATE / ACTIVATE the device to clear the device hang and to free any storage backed up on the work queue for that device.

A missing interrupt handler can also be defined through VTAM. MIHTMOUT is a VTAM start option that specifies the time out value, in tenths of a second, for CTC connections. MIHTMOUT should not be set higher than the default value of 1800. CTC connections will use the lower of the MIHTMOUT value and the MIH value set through the operating system. Note that MIHTMOUT only applies to CTC connections and has no effect on MPC connections.

Back to top