[HPADM] SUMMARY: Is Output from DDS Lying?
From: Dave T. (davidlt77_at_hotmail.com)
Date: 10/21/03
- Previous message: Gosselin, Mark: "[HPADM] route cache bug??"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: hpux-admin@dutchworks.nl Date: Tue, 21 Oct 2003 10:07:48 -0400
It turns out the operator may be right. Thanks to the following for taking
time to respond:
Allan Marillier
Mike Keighley
Francois Dion
Bill Hassell
Dave Gagliardi
Bill's answer was the most complete, so I've included it below.
Thanks!
Dave
----Original Message Follows----
From: "Bill Hassell" <blhconsulting@mindspring.com>
To: "Dave T." <davidlt77@hotmail.com>
Subject: RE: [HPADM] Is Output from DDS Lying?
Date: Tue, 21 Oct 2003 09:43:26 -0400
Hi,
> A script that runs a make_tape_recovery from cron at night failed. The
> operator here had to put a DDS tape into the drive in the evening
> in order
> for the script to run successfully. The script first checks the
> status of
> the drive before attempting to run the make_tape_recovery, and it
> writes the
> output to a log. The error was as follows:
>
> Drive: HP C1537A
> Format: DDS-2 format
> Status: [45112400] BOT write-protected online compression
> immediate-report-mode
> File: 0
> Block: 0
This is what the drive reports. Certainly the DDS drive is an
electro-mechanical device and the write-protect circuit depends
on a microswitch which is activated when the protect tab is
in place. The possibility of a very slight mechanical difference
between each tape plus a sensor in the drive that is on the edge
of it's adjustment position could fail to see the write-enable
tab.
>
> The operator swears the tape was writeable, and he claimed that
> he has seen
> this happen many times in twenty years as an operator. In my
> nine years as
> a systems administrator, I have never seen this happen, but maybe it does
> occasionally, which leads to my reason for posting on this list.
I've seen this with lots of mechanical devices. It can be verifiied
by results on different drives where the problem never shpws up because
the switch is physically closer to the center of it's tolerance.
> 1. Can anyone verify the operator's claim that DDS drives occasionally
> report a tape as write-protected, when it isn't?
As mentioned above. I've seen this with 1/2" reel-to-reel as well
as 8mm and DDS...very seldom, but it still happens. Re-inserting the
tape usally fixes the problem.
> 2. On another note, in the past, the log has shown that no tape
> was in the
> drive at all, when the operator has claimed he put one in. Has
> anyone seen
> a DDS drive bogusly report that a tape is not in the drive, when in fact,
> one is?
This is actually more common! The problem is not that the tape isn't
in the drive, it is often due to firmware bugs. The process of loading
a tape is very complex, especially as the leader is read. The leader of
a DDS tape contains the media-ID information and BOT information. For
backwards compatibility with early DDS-1 tapes, the drive will accepts
DDS-1 without leader info and try to figure out the format of the BOT
log info. Occasionally, bugs have been introduced in trying to position
the tape and recognize the media where the drive gets confused. In most
cases, the tape is ejected but not always. I would update the drive to
the most recent version of firmware. (itrc.hp.com)
Bill
_________________________________________________________________
Never get a busy signal because you are always connected with high-speed
Internet access. Click here to comparison-shop providers.
https://broadband.msn.com
--
---> Please post QUESTIONS and SUMMARIES only!! <---
To subscribe/unsubscribe to this list, contact majordomo@dutchworks.nl
Name: hpux-admin@dutchworks.nl Owner: owner-hpux-admin@dutchworks.nl
Archives: ftp.dutchworks.nl:/pub/digests/hpux-admin (FTP, browse only)
http://www.dutchworks.nl/htbin/hpsysadmin (Web, browse & search)
- Previous message: Gosselin, Mark: "[HPADM] route cache bug??"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
