Conference cookie::mru

Thank you for the reply....but I think I can add some very important info.

** JU driver ** seems to be the problem......

The customer had upgraded SLS to V2.8, without stopping the JU driver from being
installed during system startup.

While JU driver was installed and no preferred_path was set, then you see the
curruption returned by MRU. 
Delete/add the PASS device and set preferred_path and you don't see the problem.

I explained to the customer that he shouldn't load the JU driver at system
startup. So, he rebooted and the problem was gone.

The customer stopped me here as the workaround was working, but I still didn't
know if it was the JU driver or the nopreferred_path. The customer wouldn't let
me set the controllers back to the original 'nopreferred_path'.

Over the pass couple of days I have been looking into another problem with the
same customer and the same config, but this time MRU was returning...

GS01>  robot show robot $2$dua2:
ROBOT $2$dua2:, is not responding: MRD Status invalid.

So I checked the preferred_path and it was still set to one controller. The JU
driver wasn't installed, but I did notice more info about the MRU...
On the previous occasion I had assumed that, as XROBOT.EXE is in sys$system then
the version of MRU must be V1.1.....wrong! 

GS01>  robot show ver
Media Robot Utility T1.1 (rev. 2)

GS01>  ana/imag/int robot.exe
IMAGE HEADER


        Image Identification Information
 		image name: "MRU_CLI"
                image file identification: "V1.0"
                link date/time:  5-MAR-1996 08:25:39.16
                linker identification: "05-13"

(please note that the ID is saying V1.0)

This is the version of MRU that was shipped to the customer with the TL822 (or
so he tells me). If this is the case then we have a problem (why are we shipping
field test versions of software to customers?). 
I copied over the current version....

GS01>  robot show ver
Media Robot Utility V1.1

GS01>  ana/imag/int robot.exe
IMAGE HEADER


        Image Identification Information

                image name: "MRU_CLI"
                image file identification: "MRU V1.1"
                link date/time: 19-AUG-1996 10:45:22.97
                linker identification: "05-13"

So, after spending 12 hours reseting HSJ's and deleteing/adding units and
devices... 

GS01>  robot :== $SYS$COMMON:[SYSMAINT.SAVEFILE.ROBOT]robot.exe
GS01>  robot show robot $2$dua2:

Media Robot Identifier: DEC     TL820    (C) DEC1F4F

Slots:          264
Drives:         3
Inports:        1
Outports:       1
Transports:     1
GS01>

All this and the original version of MRU still shows the same error. It appears
that the original problem with the access to the jukebox was cleared by reseting
the HSJ's, the only problem was that we were using field test version of MRU
which was telling us the status was invalid.

The moral to this is 'check the version of MRU, before spending hours checking
if the device is setup correctly'. 

Thank you all for the help in tracking down this problem. At least we have
managed to get a result (.5) with the handleing of currupt output from the
controllers.

Scott.

(P.S. If the customer is correct about the version shipped to him, then we are
going to have a problem. The jukebox in this case cost 1/4 million pounds and
the customer has two. Only the largest of our customer are going to have these.
So lets make sure we ship the correct version of software with them.)

	re: JU driver.

	I'll ask our writer to review the documentation around the
	switch from the JU driver to make sure that we say that it
	really is NO LONGER needed.

	re: MRU T1.1

	Track down the CDROM the customer used to install the software.
	The software that comes with the libraries is on its own CDROM
	that should be easy to identify.  It has the burgandy block
	digital at the top, with the colorful odd lettered StorageWorks
	below.  It very clearly says Media Robot Utility Version 1.1.

	If the CDROM isn't one of these, then find out where they got
	it.  If they're sure that it came with the library, then I'll
	get our product manager to track down the person that pirated
	our field test kit.

	If they didn't install the software from CDROM, find out where
	they got it, because they probably got an internal field test kit.
	That did happen every not now then, field people handing out
	our field test and internal use kits without telling us.  Caused
	us little end of grief, but made the customers generally happier.

	The VMS ident information for the VAX version of V1.1 is:

	Image Identification Information

                image name: "MRU_CLI"
                image file identification: "MRU V1.1"
                link date/time: 23-JUL-1996 13:00:36.88
                linker identification: "05-13

    Since this has been seen a 2nd time and I've taken a closer look
    at the applicatable part of the SCSI-2 spec, it seems that I can
    make the problem a little more obivous.  The SCSI Mode Sense data
    coming back from the HSJ is all NULs.  The first two bytes of the
    data are the page code and data length.  I can make reality check
    on these and create a failure when the robot/controller/command disk/
    DUdriver is lying.  I'm not sure I can do any double checks of the
    Inquiry data, but the mode sense check looks easy enough.

	Since the symtom for this particular problem is that the
	Mode Sense data for the Element Address Assignment Page
	comes back as all NULs, I've put a check into the OpenVMS
	Mode Sense routine to verify that the page returned has the
	expected page code.  If the page code isn't that of the Element
	Address Assignment Page, the new error MRD_STATUS_PAGE_CODE
	is returned.  The text for this error is:

		"Unexpected page code return by Mode Sense"