ACSLS: "Cell is Full" Reported After Failure on SL8500 Robot, "Device Response Time-Out" Error, 1301 and "Device io Exception" Error, 3987

Asset ID:	1-72-2114807.1
Update Date:	2017-12-18
Keywords:

Solution Type Problem Resolution Sure

Solution 2114807.1 : ACSLS: "Cell is Full" Reported After Failure on SL8500 Robot, "Device Response Time-Out" Error, 1301 and "Device io Exception" Error, 3987

Applies to:

Sun StorageTek Auto Cartridge Sys Lib SW (ACSLS) - Version 8.0 and later
Sun StorageTek SL8500 Modular Library System - Version All Versions and later
Information in this document applies to any platform.

Symptoms

Robot 1.1.0.1.0 fails on a put of cartridge in slot with a "Device response time-out" error, 1301 and "Device io exception" error, 3987

hbc/log/stk/log_error

2016-03-05T09:41:24.362, 1.1.0.1.0, root, hli0, move, 8673901, error, 1301, "Device response time-out", request=<request sequence="1024827"><command>putCartridge</command><requestId>internalActivity</requestId><parms><address>1,1,-27,2,9</address><cartType>Ultrium3</cartType><safeColumn>-2</safeColumn></parms></request>
2016-03-05T09:41:24.408, 1.1.0.1.0, root, hli0, move, 8673901, error, 1319, "Robot operation failed - robot in put", volumeLabel=U20980L3 hliLsm=0
2016-03-05T09:41:39.452, 1.1.0.1.0, root, default,SL8500RobotR, -103, error, 1301, "Device response time-out", request=<request sequence="1024914"><command>healthCheck</command><requestId>internalActivity</requestId><parms><watchdogTimeout>0</watchdogTimeout></parms></request>
2016-03-05T09:41:39.470, 1.0.0.0.0, root, default,SL8500RobotR, -103, error, 3215, "Robot initialization error - Data: 2016-03-05T09:41:39.467, 1.0.0.0.0, root, default, internal, 0, error, 3987, "Device io exception""
2016-03-05T09:41:39.467, 1.0.0.0.0, root, default,SL8500RobotR, -103, error, 3987, "Device io exception"
2016-03-05T09:42:43.426, 1.1.0.1.0, root, default, internal, 0, error, 3333, "Dropped unexpected device response", Data=<response sequence="1024827" final="true"><command>putCartridge</command><result identifier="1"><resultStatus><resultSeverity>info</resultSeverity><resultCode>0000</resultCode><resultText><!|CDATA|End of Text||></resultText><operationalState>000</operationalState></resultStatus><address>1,1,-27,2,9</address><trackPosMils>17794</trackPosMils></result></response>

Two days later after the robot failure a "location full/obstructed" is reported while putting cartridge U21111 in slot 1,1,-27,2,9. There is a warning 3893 telling slot 1,1,-27,2,9 does contain cartridge U20980

2016-03-07T01:17:29.229, 1.1.0.2.0, root, hli0, move, 8770101, error, 3955, "Error from device Code: 510 - Robot says location full/obstructed", Data=<response sequence="1056479" final="true"><command>putCartridge</command><result identifier="1"><resultStatus><resultSeverity>error</resultSeverity><resultCode>5010</resultCode><resultText><!|CDATA|servo mech reach event 5010 at 1743 tachs, 2144 mils||></resultText><operationalState>510</operationalState></resultStatus><address>1,1,-27,2,9</address><trackPosMils>285132</trackPosMils></result></response>
2016-03-07T01:17:30.812, 1.1.0.2.0, root, hli0, move, 8770101, error, 1103, "Destination full - cartridge returned to source", volumeLabel=U21111L3 hliLsm=0
2016-03-07T01:17:30.783, 1.0.0.0.0, root, hli0, move, 8770101, warn, 3893, "Cartridge unexpectedly discovered", cartridge=U20980L3 address=1,1,-27,2,9

In addition a Cell Full is reported in ACSLS

2016-03-07 05:04:41 ACSLH[0]: Error: 0422 - General procedure error: Cell is full
2016-03-07 05:05:16 ACSLH[0]: ACS: 1; LC/LMU error: Co_4400:st_parse_error:

Cause

A bad railnet communication with robot 1.1.0.1.0 on the rail caused the robot to go offline and a "cell full" to be reported for the slot that was last accessed by this robot.

Because of the Device response time-out" and hardware exception on robot 1.1.0.1.0, status of slot address=1,1,-27,2,9 was never updated in library cartridge database, to reflect cartridge U20980 was indeed put into this slot.
This incident created a mismatch of the status for slot address=1,1,-27,2,9 which currently contains cartridge U20980 but is still an "empty" slot in the the library cartridge database . Hence the cell full situation reported to ACSLS on the request to put another cartridge U21111 in the given slot.

Solution

1- Run a Verify Audit in SLConsole to update Slot 1,1,-27,2,9

Here is the exact procedure for a Verified Audit in the SL3000 User's Guide

Chapter 11
Performing a Verified Audit on a Range of Cells
A verified audit validates the status of a specific cartridge location or range of locations in the cartridge database. If a cartridge address has a verified status of false, a physical audit of that location is performed and the cartridge database is updated.

1. In SLC, select Tools > Diagnostics.
2. Select the Library in the device tree.
3. Click the Audit tab.
4. Select Yes for Verified Audit (select No for Entire Library and Physical Audit).
5. From the drop-down lists, select the internal address for the starting and ending
locations of the audit.
6. Click Audit.

Slot must reflect it does contain cartridge volser U20980 in the output of the audit task displayed in the SLConsole transcript window.

2- Re-synchronize ACSLS media database with the library media contents

On the ACSLS server, from a shell as acsss user (requires to have the password for acsss)
Type the following command:

cmd_proc -l

At the ACSSA> prompt, type the following command to audit ACS1

Note: Site have two standalone SL8500 attached to ACSLS. The library ( which had the failed robot) needing audit here is ACS1

audit 1,1,0 acs 1

This will fix the cell full situation in ACSLS.

References

<NOTE:1547088.2> - How to Upload Files to Oracle Support

Attachments

This solution has no attachment