There is an open SR on this (SR 8606105598, ITRC doc KBRC00004686), but it
doesn't appear to be a resolved issue yet. I believe it's actually a
combination of the firmware and the code that loads the tape, but it's a lot
of C code, and I get lost after the first 4 or 5 sets of parentheses ;)

After having dealt with this issue quite a few times, I've seen how regular
and how intermittent the problem can be. Quite a few times the customer has
been "saved" simply by trying BO ALT 3 or 4 times. One of those times might
just make it past the code, and everything runs smoothly from there (once
you're past the problem, you're past it).

However, many times we haven't been able to ever boot off the tape, so the
workaround is usually to boot back up PRI, then either recreate the tape
(rerun AUTOINST, AUTOPAT, or PATCHIX) using a 125m tape, or some people have
been able to use SLTCOPY and just copy the tape. TCPY might work there,
also.

Bottom line, tapes <125m MAY have a problem booting.

Matt


> If you are going to use a DDS-3 drive to create an SLT then you need to
use
> a DDS-3 tape, I have yet to have  a system boot from a DDS-2 tape that was
> created on a DDS-3 drive. Really doesn't have anything to do with the O/S
> version as I have experienced this on 5.5, 6.0, and 6.5.

I have also seen this phenomenon. Does anyone know what the reason for this
is?

It obviously has something to do with the creating of the SLT on DDS2 media
by a DDS3 drive (as opposed to a problem with a DDS3 drive reading a DDS2
SLT.) I conclude this for several reasons. First, we have created many DDS2
SLTs that have been used to load on DDS3 drives. Second, the factory SLTs
are still delivered on DDS1 60 meter tapes. Consequently DDS3 drives have no
inherent difficulties reading non-DDS3 SLTs. The only problem appears to be
reading a non DDS3 tape specifically created on a DDS3 drive.

It appears to me that this is somewhat of a time-bomb waiting to go off on
an unsuspecting system manager who creates his/her SLTs in this manner. Do
we know what the problem is? Is it a SYSGEN problem? A firmware issue on the
DDS3 drives? Is it going to be fixed?

Doug.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *