• Please review our updated Terms and Rules here

9 Track Linux commands and /Dev

Hi All;
Chuck, it might,
"" I've got OR for a non-SCSI (Pertec) interface, so that isn't going to help you. ""
I also have an old Pertec Card that fits in a 486 type of machine.. Its a "Computer Logics" Board..

THANK YOU Marty
 
The problem isn't with Linux's native ability; rather it's a problem with Unix/Linux standard toolset. The sg3_utils package facilitates the sending of SCSI commands directly to a device, but there's no Linux-standard for interchange of files with variable block lengths. So you pretty much have to sharpen your pencil and start coding--or resort to John Wilson's utilities or the like.
As a programmer, nothing else (than writing the software) even occured to me! :)
Well, there's 'dd' and 'mt', which, together with selecting the n-devices (or the equivalent non-rewind device on my Octane) can achieve the same, although it's a bit awkward.

When there's an old CCT I need to read I read it with a small program I wrote ages ago, it simply reads whatever's on the tape, in whichever format (variable or fixed record sizes, or mixed, single- or multiple files, any number of end of file marks, etc). and creates a disk file which encodes the original tape format (very simple format. A 4-byte value with either 0 for EOF, or the number of bytes in the following 'record').

Then I have tools I wrote to work with the disk file instead of using the physical tape. They work on the disk file as if it is a tape, as those ANSI and various backup formats typically encoded some of the protocol in actual record sizes (so just a data dump from the tape wouldn't be optimal really). So, a single tool for copying the tape (and I also have a write-tool which can use that file to re-create a tape too if necessary), and additional tools for the various tape formats, e.g. ANSI tapes, or Norsk Data backup format tapes, etc.

But, getting back to the OP's question.. 'mt' and 'dd' can together do almost everything with a tape, also those with variable-sized records. You would have to use the no-rewind device file if you want to do more than one operation. Using the tools manually from the command line can be used to establish what format the tape is, starting with the record size of the first record (which could be a tape label.)

What I don't know is how to set the drive to variable record size mode on Linux (or to switch to fixed record size mode. But variable size mode is much easier to work with if you want to figure out what size a record is). On SGI there are different device files for all the different modes of the tape drive, so that's very easy. In any case, just mt -f /dev/nst0 status is something that works on nearly all *nix (just have to figure out the equivalent of /dev/nst0 for each of them) and can be used to see the status and mode of the drive.

-Tor
 
Hi Alll;
Tor, Thanks for Your input.. I have a couple of questions..

"" When there's an old CCT I need to read I read it with a small program I wrote ages ago. "" What is a CCT ??

"" But, getting back to the OP's question. "" What is an OP ??

I just don't like it when people use abbreviations and I have know/no idea what they are referring to, instead of just spelling it out..

Thank You Marty
 
As a programmer, nothing else (than writing the software) even occured to me! :)

My point was that not everyone is a programmer. I was somewhat surprised myself to see that a backup utility that I wrote decades ago for DDS works just fine with 9 track tapes.

What I don't know is how to set the drive to variable record size mode on Linux (or to switch to fixed record size mode. But variable size mode is much easier to work with if you want to figure out what size a record is). On SGI there are different device files for all the different modes of the tape drive, so that's very easy. In any case, just mt -f /dev/nst0 status is something that works on nearly all *nix (just have to figure out the equivalent of /dev/nst0 for each of them) and can be used to see the status and mode of the drive.

When I was talking about variable-block size, I really meant variable-block size--here's the start of a tape that I'm working with currently:

Code:
  1024 bytes
FILEMARK
    54 bytes
   256 bytes
    54 bytes
    60 bytes
   102 bytes
    60 bytes
   150 bytes
    54 bytes
   150 bytes
    22 bytes
   150 bytes
  1218 bytes
   150 bytes
   130 bytes
   150 bytes
  1866 bytes
   150 bytes
  4096 bytes
  3056 bytes...


I can't imagine handling this with dd, nor does dd have any way to represent the block sizes in a file.

Marty, "OP" = original poster. "CCT" = computer compatible tape; usually means 1/2" open-reel tape.
 
@Marty,

"OP" is (in this context) used for "Original Poster", sorry for not spelling it out but it's used on every forum I read so I didn't think about it.
"CCT" means Computer Compatible Tape, and is the kind of reel-to-reel tape you use on your 9-track tape drive. Well, at least I have assumed so - I only know about the term "9-track" used about CCTs.

@Chuck(G),
Yes, those are really variable-size for sure - I can read those kinds of tapes with my own tool, however it doesn't work on all systems. The problem is really the tape driver in those cases, when it can't handle a change of record size between file marks. Where it can, it's usually also possible to use 'dd' actually - as long as you use the 'count=1' parameter. When I start looking at an unknown tape I typically start with 'dd if=/dev/tapedrivedevice bs=1 of=t.1 count=1' and then ls -l t.1 will tell me the record size. Another 'dd' to t.2 for the next record and so on. It works, when the driver is in variable size record mode and you use 'dd' with 'count=1'. It will read one physical record and write a file where the length is exactly that record size.

-Tor
 
Tor;331274 What I don't know is how to set the drive to variable record size mode on Linux (or to switch to fixed record size mode. But variable size mode is much easier to work with if you want to figure out what size a record is). -Tor[/QUOTE said:
#include <sys/mtio.h>

void set_variable(int fd) { /* fd should be opened to the /dev/nst0 device node */
struct mtop mto;

mto.mt_op = MTSETBLK;
mto.mt_count = 0;

if(ioctl(fd,MTIOCTOP,&mto) < 0) perror("setting variable block mode");
}
 
Thanks Roe.

Is there a non-programmable method also? On SGI it's so very easy because you just select the right device file (particularly important when you want to look at records with 'dd' instead of from inside your program).

I should add that I have actually used that programmable method in an application (for Linux) that I delivered to a customer. It works fine. I never tested if the setting "sticks" though.. could be used for a standalone mode tool if so I guess. Not as elegant as the SGI/IRIX way but..
 
Hi All;
I have been able to use Tapedump on my Linux Box to see what is on the three tapes that I have for reading/testing purposes, with the Cipher 990 Tape Drive..

THANK YOU Marty
 
Back
Top