APAR PN80424 addressed a problem with too many tapes having a status of
filling (with collocation enabled).  Provided the first tape wasn't in
some sort of error state (or had access set to readonly or unavailable),
it sounds like this fix might address the problem you saw.  Only other
time I could see this condition occurring is if you have multiple
concurrent incremental backups running for a client.

Tim Pittson
tpittson AT himail.hcc DOT com

>----------
>From:  Chet Martel[SMTP:cmartel AT PEACH.FRUIT DOT COM]
>Sent:  Friday, May 24, 1996 2:22 PM
>To:    Multiple recipients of list ADSM-L
>Subject:       Re: Incremental vs Full Backups
>
>At 06:47 AM 5/24/96 -0500, you wrote:
>>
>>Frank,
>>        Yes, you need to look at this in a different perspective.  For
>>backups,
>>ADSM uses version control (keep _n_ copies of a file if it's active
>>regardless of how old it is - active = exists on the client as of the
>>last backup) and a combination of version and retention period control
>>for inactive files (files no longer on the server as of the last ADSM
>>incremental backup).  If you're at all familiar with SMS on MVS, it's
>>very similar to the way an SMS Management Class works (backup frequency
>>/ # backups ds exists / # backups ds deleted / retain days only backup /
>>retain days extra backup).  Over time, as files expire and tapes become
>>partially full, these tapes are merged as part of reclamation
>>processing.  One factor to consider in setting up your ADSM environment
>>is whether or not to enable collocation  Enabling collocation tells ADSM
>>to keep each client's data on separate tapes.  With collocation
>>disabled, ADSM tries to fill each tape before writing to a new tape.
>>The upside to using collocation is that each client's data is on a
>>separate set of tapes which can speed up restores significantly. The
>>downside to collocation - more tapes are used, more tape mounts, more
>>background processing (tape reclamation).  Things to keep in mind when
>>deciding this are client size, tape capacity, etc.  Also, you can use
>>collocation for some clients and not for others by setting up separate
>>storagepools.
>>        This type of incremental backup philosophy takes some getting
>>used to
>>as it differs radically from traditional backup methodologies.  I can
>>tell you from experience that we've used ADSM to do more than a few full
>>client (Netware, OS/2, NT, etc.) recoveries and full file system
>>recoveries (AIX, HPUX, Ultrix) over the past 2.5 years and it hasn't
>>failed us yet.
>>
>>Tim Pittson
>>tpittson AT himail.hcc DOT com
>>
>>>----------
>>>From:  Frank Rehor[SMTP:Frank.Rehor AT CLOROX DOT COM]
>>>Sent:  Thursday, May 23, 1996 8:10 PM
>>>To:    Multiple recipients of list ADSM-L
>>>Subject:       Incremental vs Full Backups
>>>
>>>We are in the process of implementing ADSM for the first time in our
>>>shop
>>>and I'm trying to clear up some confusion on our part re: backups.  We
>>>come from a mainframe environment where we do weekly 'full' backups of
>>>datasets (backup all files in the shop) and daily 'incrementals'
>>>(backup
>>>only files changed since the last backup).  If we need to recover our
>>>system we restore the latest backup of a dataset which is, at most,
>>>only a
>>>week old.
>>>
>>>In ADSM we see only incremental backups.  Granted the first backup is
>>>truly
>>>a 'Full' since nothing has been backed up prior.  If a file does not
>>>get
>>>updated periodically it won't be backed up again.  The concern is how
>>>long
>>>we must keep backups to guarantee there being an available means to
>>>recover
>>>a file that, e.g., may be read only or updated very infrequently.
>>>
>>>Any feedback would be helpful.  Do we need to look at this from a
>>>totally
>>>different perspective than the mainframe world?
>>>
>>
>Any clue with Collocation enables why a second tape mount during the
>backup
>of a
>file system even though the first tape was nowhere near full.  As a
>matter of
>fact it was less than 1% full.  It was my intention to put a clients
>data on
>separate tapes but I have backed down since I came across this problem.
> At the
>time I was doing this I had IBM support on the phone with me and he had
>no
>clue as
>to why.
>