In his posting, Brett Walker wrote:

>When data is backed up, the label should probably really read Objects
>Backed Up, because it counts directories as being backed up.  My guess
>is that the server is showing the actual number of files on the
>Q OCCUPANCY command, and the delete filespace shows actual number
>of objects.  So if your accounting is keying off of the Q OCCUPANCY
>command, then you should be alright.

Well, I don't know if we're all right or not. Our billing is based on actual
resources used. Under WDSF, a Q NODE name will tell you the number of files
(objects?) in backup and archive and how much data there is. We base our billing
on the cost of storing the DATA on tape AND the cost of the disk required to
maintain the database. The database disk storage, it turns out, is the single
largest cost component for us. If the 'number of files'
returned by ADSM's Q OCC command does not reflect the actual amount of disk
required for the database then we are NOT all right. As an extreme
example, if an AIX client backed up a file system with 100,000 directories and
zero length files, Q OCC would show 0 files (if I understand the discussion so
 far).
However, it seems to me that there MUST be database storage used by these
100,000 objects - they have names, modification dates, permissions, etc.
For WDSF, it's my understanding that each 1000 objects requires 1 3380 cylinder
for the database. Presumably, something like this is also true for ADSM.
If so, then in the preceding extreme example would take up about 100 cylinders
of 3380 disk and I would have no way of knowing it. Have I missed something?

It seems to me this feature is confusing and the information provided in the
response to Q OCC has little practical use as well as a large 'surprise factor'.
Any comments or suggestions would be welcome.

Regards,

Michael Kearney