VSM - ECAM I/O error RC=6A40FF14

Asset ID:	1-72-1484846.1
Update Date:	2012-08-31
Keywords:

Solution Type Problem Resolution Sure

Solution 1484846.1 : VSM - ECAM I/O error RC=6A40FF14

Applies to:

Sun StorageTek Virtual Tape Control Software (VTCS) - Version 6.2 and later
Sun StorageTek VSM System - Version 4 and later
IBM z/OS on System z

Symptoms

ECAM I/O error RC=6A40FF14 encountered at VTCS startup, usually after VTSS maintenance, but not limited to a VTSS maintenance session.

On VTCS startup or varying VTSS online a ECAM I/O error RC=6A40FF14 message is encountered.

Please note, this applies to ALL versions of VTCS back to 2.0, and ALL VTSS hardware.

Further possible messages:

SLS6675E VTSS:VTAPE1 VTD:xxxx CONFIGURATION ERROR RC=6A40FF14 SUBSYSTEM INFO:????????/0000/00000000
IOS002A xxxx,NO PATHS AVAILABLE
SLS6698I ECAM I/O ERROR ON VTD xxxx
IOS002A xxxx,NO PATHS AVAILABLE

Changes

Possible maintenance to the VTSS or the customer's I/O environment.

Possible VTSS, IOP, or channel failure in the customer environment.

Cause

For detailed information on this subject, it is recommended that the customer read the I/O Chapters in IBM's z/Architecture Principles of Operation manual.

VTCS is attempting to send the ECAM I/O commands to the VTSS via the offline I/O process. VTCS uses this process for ECAM I/O to the VTSS and this can use any path to the VTSS regardless of the online or offline state of the device on that path. The errors recieved as shown above indicate this offline I/O process has failed due to there being no valid path available for offline I/O. VTCS only requires a minimum of one valid offline I/O path to establish communication and send ECAM commands to the VTSS to enable the VTSS to come online.

While the minimum is one valid offline I/O path, VTCS will attempt at startup to communicate with all paths to the device, and will go through each device (VTD) performing the ECAM I/O. This will result in SLS6675E error messages for all devices which do not have a valid offline I/O path, and for all devices which do have a valid offline I/O path there will be no error message, and VTCS will be able to bring the VTSS online.

A further note here. A minimum of one valid offline I/O path must be available to the VTSS on each system which accesses the VTSS.

MVS maintains information on the I/O paths available for each device, this information includes path available, path valid and so on.

Simply when MVS wants to access a device (online or offline) it checks the path validation mask in the ECB. There is a bit setting for every possible path to the device. After an outage of any type this path valid mask is 0, and will remain this way until MVS validates the path. It does this by having a validation I/O go down the path. This is usually first done when a device is varied online, then each path is marked as validated, the bit for that path is set to 1. Unfortunately, if that bit is not set to 1, the code in MVS for I/O prevents an I/O from going down that path (except those I/O's that cause a validation to take place).

What the customer may encounter is this exact problem. All devices became invalidated due to maintenance, a VTSS, or I/O issue, and all the paths to each device are invalidated, the path mask bits are set to 0. Because the VTCS is prevented from issuing the I/O by MVS at startup or vary VTSS online, this causes the ECAM error messages. To fix this vary a device online, depending on the cause of the problem the device may need to be varied offline first. Note the device does not need to be retained online, it simply must have been brought online from an offline state since the problem was encountered. An online (then an offline) should validate at least one path, which is sufficient for VTCS's purposes. Additionally, at IPL, MVS in IPL processing MVS performs I/O to every device via every path for its self descriptor and other information. This is sufficient to validate one path to the device. Note: Nothing is corrupt here, the bits are reflecting the state of the device.

Every hardware error or event that takes the VTSS completely away from MVS will invalidate the path mask, as that path is no longer valid for I/O purposes. So the process required once there is an event which invalidates the device paths should be to VARY the devices and paths offline to MVS. Then vary the paths back online to MVS once the event is completed. Then vary at least one device online to MVS from each system. Only one is required.

Then VTCS on each system can issue I/O via this device. You will still see the config errors for all the other devices, but there will not be an error for the device which is online. The VTSS will come online after this.

You will still see the config errors each time VTCS is restarted or the VTSS is brought online, but any of the validated devices will not show this error and the VTSS will come online.

Once the system is IPLed or every device is brought online the errors will disappear.

A final note, if the one device is brought online then taken offline again, the offline I/O process can still use this. This can be done for all devices; bring them all online, then take offline, and repeat for each system, then VTCS can be started. Again more detailed information is in the z/Architecture Principles of Operation manual.

Solution

Vary at least one VTD offline.

Vary that VTD online. If required it can be varied offline again.

This may need to be repeated for each system which runs VTSS to access the VTSS. (This is not just systems which utilise the devices on the VTSS.)

VTCS may now be restarted, or the VTSS may be brought online.

Attachments

This solution has no attachment