VCTC Support in VM/ESA - News

This table describes updates to the CP Virtual Channel-to-Channel (VCTC) support since VM/ESA Release 2.1.0:

APAR PTF R210 PTF R220 PTF R230 PTF R240 Brief Description
VM59984 UM27554 (base) (base) (base) VM user hung waiting for PCI status from VCTC
VM60107 UM27652 (base) (base) (base) Incorrect sense data (00) returned for uncoupled VCTC
VM60486 UM27880 (base) (base) (base) VM user stuck in VMDIOWT after SIO to VCTC
VM60682 UM28120 UM28121 (base) (base) GCS cannot handle BUSY+DE status from SENSE CCW
VM61135 UM28491 UM28492 (base) (base) CTCA link does not start after the COUPLE command
VM61814 UM29066 UM29067 UM29068 (base) VCTCA hang in Extended Mode when one side does System Reset
VM62480 (n/a) (n/a) (n/a) UM29720 Introduced Virtual ESCON capability
VM62637 (n/a) (n/a) (n/a) (OPEN) Virtual ESCON BCTC ABENDIOV100 after Resetting Event

Select a link (in the APAR column) for more information.

Current Status is also available.

Current Status

The following problems have been investigated:

  1. Reset (HALT I/O) after normal operations causes a hang.

    Applications (like RSCS) that use GCS services to perform I/O to the adapter may encounter a "hang" after trying to reset the VCTC device. If this problem persists after applying all available service for Virtual CTCA support, it may be the result of a GCS problem that is should be addressed by APAR VM61251 for GCS.

    See APAR VM61251 in RETAIN for details.

  2. Guest machine times out on a CTCA link.

    Some customers report a guest machine that fails to respond to an I/O completion within a reasonable time interval (e.g. 30 minutes). TRSOURCE data indicates the CPEBK is stacked, but not dispatched during this period. So far, this has only happened on guest machines that are storage-constrained (e.g. Guest storage size is the same as real machine size). Our current theory is that the guest was placed on the "eligible" queue (which can remain un-dispatched for long periods of time) because of the storage requirements of other interactive users.

    If the problem persists after increasing available storage or reducing demand, please contact me (musselwh@us.ibm.com) with details.

APAR VM59984

VM user hung waiting for PCI status from VCTC

A VM user is "hung" waiting for PCI status (Program Controlled Interrupt) from a VCTC device. The partner has executed a CCW with the SUSPEND flag set (for SUSPEND/RESUME processing). Any event (like SUSPEND) that might break the command chain while the next CCW is being fetched could set the stage for this hang. The command chain is broken by calling HCPCTCVS with CCW 00 (this will appear in the CP Trace Table). This does not reset the chaining indicator (CACICCCW) in the GA code, so the partner might enter with a new CCW and have to wait because command chaining has priority.

An ESA R210 customer should apply APAR VM59984 / PTF UM27554.

This fix is included in the ESA R220 base system.

APAR VM60107

Incorrect sense data (00) returned for uncoupled VCTC

Incorrect sense data is returned for an uncoupled adapter after a System Reset (e.g. IPL) or Selective Reset (e.g. CSCH instruction). With the adapter operating in Extended Mode, a Control CCW (X'07') fails with Unit Check status in the CSW. The subsequent Sense CCW (X'04') returns with a sense byte = X'00'. The switch to Basic Mode (HCPCTVBM) was clearing both sense bytes. This agrees with the CTCA and 3088 hardware specifications (since sense data does not exist for Basic Mode adapters). However, it causes a problem for the simulation because Intervention Required and Interface Disconnect sense bits are closely associated with the NOTREADY state. If the adapter returns to Extended Mode operation without action from the NOTREADY side, the sense data will disagree with the NOTREADY status.

An ESA R210 customer should apply APAR VM60107 / PTF UM27652.

This fix is included in the ESA R220 base system.

APAR VM60486

VM user stuck in VMDIOWT after SIO to VCTC

A VM user is "hung" waiting for SIO to complete before it can continue to drive the next device. The application should have been released from I/O simulation as soon as the first CCW was accepted, but VCTC simulation (entry point HCPCTCVS) did not call HCPIOVUS to deliver initial status if that initial status was all zero. Instead, the application gets initial status when the first CCW in the chain completes.

This was observed primarily in applications using System/370 I/O operations (SIO and SIOF) but might affect ESA I/O activity to a lesser degree.

An ESA R210 customer should apply APAR VM60486 / PTF UM27880.

This fix is included in the ESA R220 base system.

APAR VM60682

GCS cannot handle BUSY+DE status from SENSE CCW

An application (like GCS) normally responds to a Unit Check (UC) status by performing a Sense (X'04') CCW to collect sense data from the device. When a CTCA device fails because the partner is resetting the device, it is possible for device to enter "NOTREADY" state (causing the UC status) and then enter "READY" state (causing an unsolicited Device End interrupt) before the application can start I/O to collect the sense data.

Some applications (like GCS) may not be able to tolerate the unexpected BUSY+DE (Busy with Device End) status from the Sense CCW. In the case of GCS, the sense buffer is initialized with the value X'107E' and that value is returned to the device owner when the Sense CCW terminates without really collecting sense data.

Sense data X'107E' implies a serious hardware failure, so GCS or the owning application may take the device offline (presumably to wait for a virtual technician).

For example, VTAM may drop a link with messages like: 

 IST446I I/O ERROR cuu, BUSY,17,9000,0000
 IST446I I/O ERROR cuu, DEVICE END, 43,1400,0000
 IST446I I/O ERROR cuu, DEVICE END/BUSY, ,9400,0000
and manual intervention will be required to convince GCS and/or VTAM to use the link again.

When VTAM reports ATTN+BUSY status and resumes without manual intervention, that is probably normal (I can only guess because I am NOT familiar with VTAM operations). It probably means both sides decided to initiate data transfer at the same time. One side "wins" (sending an ATTN interrupt to the other side) while the other side "loses" (getting ATTN+BUSY). The "loser" should read the command byte (CCW x'14') and start the matching channel program (e.g. Read the data).

An ESA R210 customer should apply APAR VM60682 / PTF UM28120.

An ESA R220 customer should apply APAR VM60682 / PTF UM28121.

APAR VM61135

CTCA link does not start after the COUPLE command

When one user has already initialized the link, and the second user is connected via the COUPLE command, the first user may not recognize the presence of the new partner. This appears to be the result of extra reset operations that are performed for a Virtual CTCA to cancel an outstanding I/O operation on the adapter. If the first user is command-chaining and the adapter is operating in Basic Mode, these resets will simply bump the channel program to the next CCW.

An ESA R210 customer should apply APAR VM61135 / PTF UM28491.

An ESA R220 customer should apply APAR VM61135 / PTF UM28492.

APAR VM61814

VCTCA hang in Extended Mode when one side does System Reset

An application program (in this case, TPF) using VCTC connections in Extended Mode may require an extra reset if the partner VM has performed a System Reset (CP IPL). This only seems to happen if a dependent operation (e.g. Read/Write) is in progress when one side is IPLed. The primary symptom is that communication does not resume after one side is IPLed, and it may be necessary to Halt, Clear, or redefine the virtual CTCA devices to resume operation.

A virtual IPL causes a System Reset for each VCTC device. Entry point HCPCTVSY is invoked to simulate the System Reset. This logic diverges from the hardware specifications because we discovered that strictly adhering to the rules (1) caused problems for older applications, and (2) was inconsistent with the behavior of a real CTCA when it is attached (dedicated) to the VM applications. Some applications were getting hoplessly out of synch when an extra IPL was performed on one side or the other because the System Reset caused the partner to advance to the next CCW in the channel program. Unfortunately, this appears to cause problems for other applications that expect the pending CCW to be terminated when the partner performs an IPL.

The good news is that we can discriminate between the two types of applications that need different behavior. The older applications that were adversely affected by the IPLing partner were in Basic Mode. This has to be the case, because the channel program would have been terminated with a Unit Check in Extended Mode. The TPF application (and any other application using Extended Mode) would NOT be confused by the extra IPL and System Reset because the active channel program would be terminated. Therefore, the System Reset exception can be restricted based primarily on Extended Mode verses Basic Mode.

Subroutine RESETCTC in module HCPCTV is modified to grant the exception (i.e. NOT reset the Y-SIDE when an X-SIDE reset is performed) only if ALL of the following conditions are TRUE:

  1. This is a System Reset (e.g. CP IPL), AND
  2. The adapter is Operating in Extended Mode, AND
  3. The X-SIDE is NOT currently suspended, AND
  4. The X-SIDE is NOT actively transferring data, AND
  5. The Y-SIDE is NOT suspended to synchronize CCWs.
Otherwise, any suspended activity will be canceled on BOTH sides of the adapter.

An ESA R210 customer should apply APAR VM61814 / PTF UM29066.

An ESA R220 customer should apply APAR VM61814 / PTF UM29067.

An ESA R230 customer should apply APAR VM61814 / PTF UM29068.

APAR VM62480

Introduced Virtual ESCON capability

This APAR addresses several "ease of use" concerns for users running Linux in a Virtual Machine. Since a significant number of VM/Linux guests are connected via physical ESCON links, support was added to CP to support a Virtual ESCON device.

APAR VM62480 is only available for ESA R240. This same support will be available in the base for any subsequent VM/ESA release.

APAR VM62637

Virtual ESCON BCTC ABENDIOV100 after Resetting Event

The ESCON adapter supports a "Resetting Event" latch that does not exist in the 3088 model. After an ESCON connection is established a System Reset (such as an IPL) turns on the "Resetting Event" latch. This means that the next CCW from the partner will be rejected unless it is an unmodified Read CCW (X'02'). Any other CCW is rejected with Unit Check status.

This would not be an appropriate response for a Basic Mode adapter because Unit Check status is not defined for a Basic Mode CTCA.

New code introduced via APAR VM62480 implemented the Resetting Event latch, but enabled it for both the CNC and the SCTC device types (since the CNC device may have to operate as a Standard Mode ESCON connection). This made it possible for the CNC device owner to IPL and generate a "Resetting Event" condition. However, if the partner is using a BCTC device the Unit Check status cannot be presented. The virtual ESCON simulation code tried to reflect ending status of X'00' for the CCW. The general I/O simulation logic detected this as a violation of the rules and generated soft ABEND IOV100 to report the violation.

An ESA R240 customer with APAR VM62480 in place should apply APAR VM62637 / PTF (OPEN).

(Back to VCTC Main Document)