ADSM-L

Re: Drivers for 3590's

1996-12-05 18:44:23
Subject: Re: Drivers for 3590's
From: Richard Sims <rbs AT BU DOT EDU>
Date: Thu, 5 Dec 1996 18:44:23 -0500
Craig - Thanks for your elaboration.  It's great to be getting more
information on this.
    Could you clarify the issue of ADSM storing the location of the file on
the tape?  Is it stored in the database along with the other information
about the file?  When was this capability introduced?  The July HONE item as
written says that the capability was not there then, and in searching the latest
lpp.README file for the server I don't see an enhancement PTF for this.
I am also curious about the status of the HONE item is: its optimal-solution
item (number 3) specifies that the server is to keep information about file
location in its database and that the server would optimally perform
retrieval, which it seems you are saying has now been implemented.  But just
when was that?  This is obviously a point of confusion.
    As you can appreciate, this issue has been aggravated by IBM being unwilling
to provide the kind of information that would allow customers to understand what
is going on.  All this should be published in the ADSM manuals.  Without that,
customers are left to grasp what little information comes from any source, and
that information has consistently said that there were deficiencies in ADSM's
handling of 3590 technology.  And given what we were seeing from data
retrieval operations, there was good reason to believe it.  Certainly you can
appreciate that when customers spend hundreds of thousands of dollars and see
poor performance from their equipment they want to know what is wrong.  We as
a customer went to IBM about this and were told that there were 3590 handling
problems, as referenced by the HONE item.  All this for lack of published
information.
    The July quote which you reference:
 > When talking directly to tape, I was able to randomly retrieve 100KB files
 > off a 10GB tape with reasonable performance.  If I was careful how I sorted
 > files before reading them, I could achieve consistently good performance.
was from another customer who found ADSM's performance such that he embarked
upon experimentation to see if he could do better, such that he wrote his own
manager to the 3590 tape driver, and thereby achieved improved performance.
Yes, optimal access to files on tape can be done: the essential question was
whether ADSM would do it.  And on that point we had only corroborating
evidence that there was a problem.
    Please look back at your original posting this morning.  It asserts
correctly that appending to a 3590 tape is an efficient positioning and
writing operation.  We all get excellent throughput in that area.  Everyone
expects that from any tape; it's a non-issue.  But then your posting seems to
go on to denigrate the complementary "read/restore side of tape usage" almost
as though writing tapes is the norm and that reading them is an anomaly which
entails inevitable loss of performance.  You said that "reading of that tape
is positioned by the high speed locate" but made no mention until your reply
later today as to whether ADSM knew of position so as to optimize access.  As
you pointed out, high speed or not, doing that over many files (as in a mass
restore) is very time-consuming unless the agent controlling it can make the
most of current position.  Please take a fresh look at it the same way that we
customers first saw it.
    So all of this points to an obvious need for definitive, published
information so that customers can know what to expect for performance from
their ADSM+3590 combination, and thereby have a basis for measurement so as to
perceive when a performance problem lies in some other area.  It makes no
sense to blame the customer for not having the information which the vendor
has not provided.  We as customers are ourselves trying to provide responsive
systems to the people we serve, and prove that we have invested large sums of
(their) money wisely.  In short, we need solid information.
    Your submission today was the first piece of information in the long
history of this issue which began to address it.  It's a great starting point:
let's see it followed up in published documentation.  As an example of the
further information that would help here: We know from the 3590 device drivers
manual that it is STIOCSETPOS which performs "high speed locate"; but that's
all it says.  There is no perspective as to serpentine positioning or time
realities in getting to any given place on a 3590 tape.  And then there is the
larger point about ADSM knowing about the position of the file on the tape:
what it stores, and how it uses it to position for optimal retrieval times.
We would like to see that published - and have it show up in a query command,
which would help those who might like to optimize access to individual files
in a batched operation...and say whether or not ADSM itself might optimize
access when given a list of files vs. being asked to perform a filespace
restoral.  3590s are great technology: they would benefit from almost a whole
chapter in an ADSM manual describing the advantages and implications of their
use in an ADSM environment.  And how about all the parameters which you allude
to which would enhance their performance?  You have information-starved
customers out there - let's get that information out.
    Thanks for the information you are providing.  We need your assistance to
make our installations perform as we need them to and as IBM would like to
ensure satisfied customers.
        Richard Sims, Boston University Office of Information Technology
<Prev in Thread] Current Thread [Next in Thread>