I hope this is open as a high severity problem.

I am curious as to whether level 2 thinks this is a client problem, a server
problem, or a combination of the two.  I have had inquiries about getting the
V3 Sun client here, but so far have not yet downloaded it.  Perhaps I'll wait
a while longer.....

Jerry Lawson
jlawson AT thehartford DOT com


______________________________ Forward Header __________________________________
Subject: Problems with ADSM not detecting directories - Solaris 2.5.1
Author:  owner-adsm-l AT VM.MARIST DOT EDU at SMTP
Date:    5/19/98 11:27 AM


To all,

I've currently got this as an open PMR with IBM Support (Level 2), but I
thought that I would see if any other sites have run into a similar problem
and maybe to warn people of potential problems.

A couple of weeks ago, our Sun Admins tried to bring back some of their
files and found that all of the directories & files under the /net-3/user10
directory had NO active backups - all versions were inactive despite the
files still existing on the server.    I've identified at least two other
file systems that have the same problem.    We've got one of our junior
people poring through a 'query filespace' report and looking at file spaces
that have minimal backup times (less than 5 secs) to see if the problems
exist elsewhere.

I went through on another affected directory /net-3/user30 and did an
incremental backup of the sdsmjdr subdirectory via dsmc incremental
/net-3/user30/sdsmjdr/* -su=y and all of the files were incrementally backed
up.   I then went through and tried an incremental backup of /net-3 (dsmc
incremental /net-3) and watched with dismay as all of the 800 backup versions
just taken were expired!!!

We're running Solaris 2.5.1 ADSM client (version 3.1.0.0) - two of the ADSM
servers (AIX) are at 3.1.0.1 and the others are at 3.1.0.0.

There are no error messages in the dsmerror.log or dsmsched.log.   The only
indication that you get is if you happened to look at the dsmsched.log on
the night that all of these files went inactive - you would see an abnormal
number of files expired, but unless you happened to notice the backup times
for the file spaces decreasing down to next-to-nothing, you probably won't
catch that until it's been deleted out of your dsmsched.log.

We've tried to minimize our losses by setting the RETONLY parameter on the
STANDARD copy group to 365 days (it had been 90) to allow sometime for the
cause to be identified and a solution devised.

Has anyone else backing up Solaris 2.5.1 boxes experienced a similar
problem???
John Rushton
Lockheed Martin M&DS