Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!hpopd!hpcpbla!kev
From: kev@hpcpbla.HP.COM (Kevin Jones)
Newsgroups: comp.periphs.scsi
Subject: Re: Random Access DAT
Message-ID: <9850033@hpcpbla.HP.COM>
Date: 19 Jun 91 06:49:57 GMT
References: <1991Jun14.211246.4340@newshost.anu.edu.au>
Organization: HP Computer Peripherals Bristol, UK
Lines: 95

> BEWARE!  The method youare refering to is called QFA (Quick File Access)
> and is implemented very differently from manufacturer to manufacturer.  This
> was due to the lack of a defination in the SCSI spec when these devices
> were designed.  The spec now contains the new commands for this, but it will
> be a while before everyone implments them.

There are no problems with DDS "Random Access".
  * Not with the tape format
  * Not with the search algorithms
  * Not with the SCSI interface spec
  * Not with any host driver that has correctly implemented the
    SCSI "Space" command.

There are now 3 methods of achieving "Random Access" via SCSI commands
that I'm aware of:

1. Using the SCSI "SPACE" command. This can instruct the drive to
   space FILEMARKS, SETMARKS, RECORDS and Sequential Filemarks/Setmarks
   (a "sequential" mark is a group of marks, eg. "Space 2 sequential
    Filemarks" = Space to the next pair of filemarks).
   All spacing is done relative to the current tape position.
   This is the command which would be used in response to an 'mt' on
   UNIX. Most host drivers implement it. Its trivial. There is no
   ambiguity or misunderstandings in the SCSI spec about this command.

   DDS will "fast search" in response to a SPACE.
   8mm products will NOT since they cannot space to a "logical position".

2. Using the SCSI "READ POSITION" and "LOCATE" commands.
   I think these may be the commands Roy was warning you about.
   A "Read Position" causes the drive to return the "current tape
   address". You can subsequently send this address back to the
   drive to get it to position to the point where you issued the
   LOCATE. This seems popular with PC's where a backup application
   can do a "LOCATE" before writing a file. It can then create
   a tape index containing filenames and "Locate positions".

   There are some problems with using LOCATE/READ-POSITION:
     1. Many drivers don't implement these commands.
        This is no big deal for DDS/UNIX since its better to use
        "SPACE" anyhow.
     2. Until recently, the "current tape address" was a bit vendor
        specific. ie. you could be positioned before file "x" and
        LOCATE shows you are at tape address 1234, whereas in a
        different manufacturers drive, at the same tape position,
        LOCATE returns tape address 1235. Not all that important if
        you stick with the same drive. If however you do a LOCATE
        on one then feed that address into a READ POSITION on another
        then you end up in the wrong place.

        This problem has now been addressed by the ANSI comittee.
        Prior to that, a common understanding had developed amongst
        DDS manufacturers about the definition of "current tape address"
        such that interchange problems between different vendors will
        not be a problem.

   8mm products cannot utilise the LOCATE/READ-POSITION
   commands to fast search. See below.......

3. The third method of "Random Access" is very much vendor specific.
   My information on this "Random Access" method is a bit sketchy,
   but it goes something like:

   A vendor unique SCSI command allows you to read the current
   "track address" from the drive. A second vendor unique SCSI command
   causes the drive to position to a specified track address.

   This all sounds like the LOCATE and READ POSITION commands.
   The main difference is that the address returned is the physical
   tape address. With LOCATE/READ-POSITION, logical addressing
   means that "incrementing by 1" causes you to move up 1 block
   or 1 mark (it could be argued that "READ-POSITION" is now redundant
   since block addressing was standardised, and that a smart enough
   driver could "mirror" what the drive would return in response
   to a READ-POSITION command), with these vendor unique commands,
   there is no such correlation.

   Since these commands are only a couple of months old, I would
   expect to see them supported only on drivers that have been written
   for 8mm products. They are not as useful as the LOCATE/READ-POSITION
   commands, and NOWHERE NEAR AS USEFUL as the SPACE command.

-----------------------------------------------------------------
Kevin Jones.                       | Hewlett Packard Ltd,
                                   | Computer Peripherals Bristol,
kev%hpcpbla@hplb.hpl.hp.com        | Filton Road,
                                   | Stoke Gifford,
Tel: 011 44 272 799910 (ext 22351) | Bristol.   BS12 6QZ.
                                   | ENGLAND.
-----------------------------------------------------------------

This response does not represent the official position of, or
statement by, the Hewlett-Packard Company.  The above data is
provided for informational purposes only. It is supplied
without warranty of any kind.