ADSM-L

Re: Strange filesize after export/import

2006-07-28 07:26:27
Subject: Re: Strange filesize after export/import
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 28 Jul 2006 07:24:01 -0400
On Jul 28, 2006, at 2:20 AM, Andreas Priebe wrote:

...
Note the difference in FILE_SIZE: 56210 vs. 11195180! This seems
strange!
And what does the difference in the field AGGREGATED mean (No vs.
124/256)?

...

Another thing is puzzeling me: the blank in the filename in the
"select", which is not
appearing in the "query backup" result.

Andreas - See "CONTENTS" in http://people.bu.edu/rbs/ADSM.QuickFacts
          for the basics on this.

The FILE_SIZE has not reflected client file size since ADSMv3.
FILE_SIZE is the Aggregate size, which is also known as the Physical
size.  If you're familiar with MVS file blocking, then this is would
be a familiar concept.  It's a means of gaining greater throughput by
collecting and writing multiple smaller files as a larger clump.  In
your old system, as data expired within an Aggregate, a single
enduring file may be the sole survivor in an Aggregate.  Reclamation,
and Move Data with Reconstruct=Yes, will compact an Aggregate such
that the Aggregate size may coincidentally become equal to the client
file size; but that's a relatively rare condition, seen with old data.

The blank is a Select report convention for the Contents table which
separates the directories nest from the ultimate file.  (The
syscat.columns Remark column misleadingly says that this is "Client's
Name for File", when in fact it is Directories + Space + Filename.)
The intervening directories are known elsewhere in TSM SQL as the
"HL_NAME".

  Richard Sims

<Prev in Thread] Current Thread [Next in Thread>