1820647 Members
2551 Online
109626 Solutions
New Discussion юеВ

how to read DDS drive ?

 

how to read DDS drive ?

Hi,

I've a machine here with a
4-mm DAT drive, HP JetStore 2000e (35470A), capacity 2GB

One of my users is trying to exchange data with another machine which has:
4-mm DAT drive, HP C1537A (DDS3), capacity 12-24GB
(I found the tape model by asking my user to "grep tape /var/sam/*")

He is now able to read tape there using /dev/rmt/c2t2d0BESTb.

However when he writes data there, he cannot read it back here.
There he has no admin rights.

What should we do ?

Thanks,
6 REPLIES 6
Julio Yamawaki
Esteemed Contributor

Re: how to read DDS drive ?

Hi,

When you exchange data (and media) between a 2 GB DAT and a 12 GB DAT, you have two problems:
1. 2 GB DAT drives accept only 60 m tape cartridge, 12/24 GB accept any cartridge until 124 m
2. If you write in a 60 m cartridge on 12/24 DAT drive, you have to create a DDS-1 non-compressed drive with SAM and write on this device, instead of 0m or even c0t0d0Best.

Re: how to read DDS drive ?

that sounds good, but how do I (I have absolutely no HP experience) explain my user how to explain to the other IT guy (who is a SUN only guy) how to create the device under SAM ?

I know how to fire SAm and add the tape itself, but I don't see which menus should the other follow to create that DDS drive.


PS: our drive is able to use DDS-1 / 90m tapes

Re: how to read DDS drive ?

Another thing:
the other drive should have compression.
How do you differentiate which devices offers compression against which one does not ?

Re: how to read DDS drive ?


Any recommendations on where to buy such a tape drive ?
4-mm DAT drive, HP C1537A (DDS3), capacity 12-24GB

We're in sanjose.

Thanks,
Michael Tully
Honored Contributor

Re: how to read DDS drive ?

One thing I suggest you do is, if you have to exchange data both ways, as opposed to one is to set up the DDS3 device to write in DDS1 format onto the 90M tapes.

Here is a suggestion, I haven't tried it so no warranty.
Obtain the hardware path of the tape drive that is DDS3. This will have to be done by somebody with 'root' access.
# mksf -C tape -H 0/12/0/0.6.0 -b DDS1 -c1 /dev/rmt/?m_DDS1_mode

Failing all of that here is a link. I'm sure that there are others.
http://partsurfer.hp.com
Anyone for a Mutiny ?
Bill Hassell
Honored Contributor

Re: how to read DDS drive ?

One of the best commands in HP-UX (and other Unix's wish they had) is ioscan. Run the command:

ioscan -knfC tape

and you'll see all the tape drives known to the kernel (probably just one). You'll also see that the opsystem creates device files automatically and they will be listed for that tape drive. The other really useful command in HP-UX is lssf which decodes device files as in:

lssf /dev/rmt/*

Now writing to the 35470A tape drive is no problem with 60 meter tapes as long as the permissions on the device file allow writing by the user. This is no different than any other flavor of Unix. However, when you start exchanging data with unlike machines (even other Unix's) there can be issues with tape formats. Note that DDS tapes are upward compatible...DDS1 can be read on a DDS2 or DDS3, etc tape drive, but the reverse is NOT true. The tape formats are not backwards compatible, and DDS-1 (your JetStore tape) is very old. There are lots of vendors that have used DDS-2 or DDS-3 (preferred) drives.

tar is an industry standard BUT not all flavors of tar understand different tape block sizes. HP-UX doesn't understand tar written on some other systems and needs the block size converted. This can be a pain to discover and implement so I prefer to use pax as the interchange method. pax understands both tar and cpio and is also smart enough to 'discover' the block size automatically.

So test the tape locally with a simple tar of /stand and then check the tape by reading the table of contents:

tar -cvf /dev/rmt/ /stand
tar -tvf /dev/rmt/

If that works OK, then creating a tape that can be read on another machine will involve creatimng a compatible format. tar on HP-UX may or may not be compatible with Linux or Solaris or Irix, etc. Make sure what the failure is...there is a big difference between a blocksize error in tar and a tape parity error. The former is a softwarte issue, the latter is a hardware problem. Ideally, the target machine may have pax which should be fairly compatible with the HP-UX version.


Bill Hassell, sysadmin