Demetrius, We have "SUBDIR YES" set in the dsm.opt file on all our clients
but DO NOT have the any NFSTIMEOUT
option set anywhere.  I am also not seeing the ANS1028S error message in my
client's dsmerror.log... it does sound as if
there may be a bit of substance to this theory though... I am going to make
a subdir in the lost+found dir on one of the boxes
where I have observed the problem and see what happens. Thanks -

George Lesho
AFC Enterprises






"Malbrough, Demetrius" <DMalbrough AT TTIINC DOT COM>@VM.MARIST.EDU> on 
01/25/2002
01:15:50 PM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: George Lesho/Partners/AFC)
Fax to:
Subject:  Re: TSM error log question


-George-
Are you also seeing ANS1028S error messages? If so you may be getting a
Are you also seeing ANS1028S error messages? If so you may be getting a
bite of APAR IC32589...

APAR= IC32589  SER=                            MS MSGANS1028S
DSMSTAT ERROR BREAKS PARTIAL INCREMENTAL/SELECTIVE WITH ANS1028S
WHEN USING OPTIONS SUBDIR=YES AND NFSTIMEOUT > 0

Status: OPEN                                Closed:

Apar Information:

RCOMP= 5698TSMCL    TIVOLI STR MGR  RREL= R42A
FCOMP=                              PFREL= F     TREL= T


Return Codes:

Applicable Component Level/SU:


Error Description:
Problem Description: When running partial incremental/selective
backups, you may encounter ANS1028S error message. This will
happen if you have specified the subdir option yes, and have
specified a filespace that does not contain sub-directories.
..
For example:

When running the command dsmc i /etc -su=yes you will encounter
the ANS1028S error message.

During this command the client scans the root file system and
tries to find "etc" objects. During this search it issues a
number of stat/lstat (AIX system) calls against the scanned
directory structure. If we use NFSTIMEOUT <> 0, our client uses
dsmstat executables which are actually virtual stat calls. When
we set NFSTIMEOUT = 0 the client uses native OS calls.
..
A SERVICE trace taken during the backup has the following
entries during the time of the failure.
****
incrdrv.cpp     (5883): PrivIncrFileSpace: Received rc=106 from
fioGetDirEntries:  / /.cedit
incrdrv.cpp     (5883): PrivIncrFileSpace: Received rc=106 from
fioGetDirEntries:  /  /.ddd
incrdrv.cpp     (5883): PrivIncrFileSpace: Received rc=106 from
fioGetDirEntries:  / /.dt/Desktop
aix/pserrno.cpp (220):  TransErrno: Unexpected error from lstat,

errno = 32
incrdrv.cpp     (5883): PrivIncrFileSpace: Received rc=131 from
fioGetDirEntries:  / /.dt/help/root-murphy-0
ANS1028S Internal program error.  Please see your service

Local Fix:
Setting NFSTimeout to 0 has provided a workaround for this
problem.