Yes, do a q node f=d...for the node in question...max mount points
allowed...


        tsm: ADSM>q node us504s0a f=d

                             Node Name: US504S0A
                              Platform: WinNT
                       Client OS Level: 4.00
                        Client Version: Version 3, Release 1, Level 0.6
                    Policy Domain Name: NOTES_PD
                 Last Access Date/Time: 03/23/01   10:44:08
                Days Since Last Access: <1
                Password Set Date/Time: 11/16/98   17:02:39
               Days Since Password Set: 858
                 Invalid Sign-on Count: 0
                               Locked?: No
                               Contact: mail001a
                           Compression: Client
               Archive Delete Allowed?: Yes
                Backup Delete Allowed?: No
                Registration Date/Time: 11/16/98   17:02:39
             Registering Administrator: ADMIN
        Last Communication Method Used: Tcp/Ip
           Bytes Received Last Session: 367,562
               Bytes Sent Last Session: 1,738
              Duration of Last Session: 0.47
           Pct. Idle Wait Last Session: 66.74
        more...   (<ENTER> to continue, 'C' to cancel)

          Pct. Comm. Wait Last Session: 4.48
          Pct. Media Wait Last Session: 0.00
                             Optionset:
                                   URL:
                             Node Type: Client
            Password Expiration Period:
                     Keep Mount Point?: No
          Maximum Mount Points Allowed: Unlimited




        Louis Wiesemann <ljwies01 AT LOUISVILLE DOT EDU>
        03/23/2001 10:47 AM
        Please respond to "ADSM: Dist Stor Manager"
<ADSM-L AT VM.MARIST DOT EDU>@SMTP@Exchange
        To:     ADSM-L AT VM.MARIST DOT EDU@SMTP@Exchange
        cc:

        Subject:        Re: ANS1301E Error

        Thanks for your suggestions.

        Yes, I had available drives.  The only other process using a drive
was a DB backup.

        Yes, the disk pool is shared and was full enough that the 5G would
not fit, so that explains the tape mount attempt.  But I can still find no
reason for the job to fail.  We do have plenty of scratch tapes available.
There were no errors related to tape problems or other problems during the 4
to 5 minutes this backup was trying to run.  I have forced migration of the
storage pool.  It was only about half full, so had not triggered a migration
yet.  The backup seems to be running to the storage pool ok.

        This pool is not collocated, but we have seen backups wait for a
tape being used by migration when the storage pool was migrating for a
collocated pool.

        The last comment in your note

        >>you allow client backups to tape drives (a setting I believe...)?

        does trigger an idea.  We have recently seen a problem with some
Novell backups of large files that tried to go to tape.  They appeared to
fail because the MAXNUMMP setting apparently came in with our upgrade to
3.7, but existing nodes got set with MAXNUMMP=0 instead of the default of 1.
They failed with ANS1312E error that clearly referenced the MAXNUMMP
setting.  I'm wondering if this problem is the Unix client version.  This
client is an existing AIX client that also was left with the MAXNUMMP=0
after the upgrade.




----------------------------------------------------------------------------
------------------------------------
------------------------------------
        Louis J. Wiesemann
        Louis J. Wiesemann
502-852-8952


----------------------------------------------------------------------------
------------------------------------
------------------------------------
        The "Daily Word For Reflection" is a free service and a
        The "Daily Word For Reflection" is a free service and a
non-discussion
        list intended primarily to allow personal reflection on the Word of
God.

        SUBSCRIBE/UNSUBSCRIBE at:

           http://monica.cin.org:81/guest/RemoteListSummary/daily_word
        ________________________________________________________

        >>> Tim.Williams AT FRITOLAY DOT COM 03/23/01 10:10AM >>>
                Do you have available tape drives at that time (it appears
that your
        are going straight to tape). IF you are not going straight to tape,
the DISK

                area that you are trying to backup to can't hold your 5+GB
file.
        Mind you, that if the DISK pool is shared...it could be some percent
full
        from other
                backups? Another thought..colocation on?...tape in use by
another
        process (it shouldn't matter...but...)...available scratch tapes?
                FYI Thanks Tim
                you allow client backups to tape drives (a setting I
believe...)?