Thanks, Trevor. Now I've had to explain to management why I'm trapped in a
number of the proverbial hard places: I've run with a patch before, and the
attendant problems were worse than the fix, but if I can't exclude files or
filesystems on a DB machine, I can't run a backup. I've got the same
dilemma with server code: 3.7.3.14 will allow me to turn on shared
3494/3590, but can I afford to run with an unsupported patch? Maybe things
will get clearer when management get thru digesting the following paragraph
from a README in the maintenance directory:
>The Tivoli Storage Manager client versioning has changed starting with
> version 3.7. When a new PTF is built, the maintenance level will be
> raised
> by one. Thus 3.7.0.0 is the Initial GA level, and the first PTF will be
> 3.7.1.0. The last number is reserved for special fixtests which are
> sometimes necessary between tested PTF levels.
Have we lost a level of supported code here? With ADSM, vrmf (like
3.1.2.5) was in the fixes directory, while vrmff (3.1.2.57) was in
fixtest. With TSM, both are in patches.
At 09:42 AM 9/14/2000 +1100, you wrote:
>Hi Fred,
>
>Stuff under the maintenance directory are formal, fully tested releases.
>The patches directory contains fixes to known problems that needed to be
>fixed quickly. Therefore the changes have not been put through the same
>level of testing as a formal release. As a general rule you should not
>install updates from the patches directory unless you have or are likely
>to have the problems that the update is designed to fix.
>
>
>Trevor
>
>-----Original Message-----
>From: Fred Johanson [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, 14 September 2000 6:47 AM
>To: [EMAIL PROTECTED]
>Subject: Re: Excludes in TSM
>
>
>I'm still getting used to the way Tivoli organizes things. I've installed
>what was in LATEST from .../maintenance/... Should I get the latest from
>.../patches/... instead?
>
>
>At 09:40 AM 9/12/2000 -0400, you wrote:
> >What version of TSM 3.7.?.? What operating system. We are using Windows NT
> >with TSM version 3.7 on our server and a combination of 3.7.1.0 and
> >3.7.2.01 on the clients (I am slowly getting rid of the 3.7.1.0 clients due
> >to the fact that the exclude statements are ignored.) Going to release
> >3.7.2.01 als fixes several other problems with 3.7.1.0 (I think I have a
> >copy of what PMR's release 3.7.2.01 has if you like)
> >
> >Sean Duffy
> >Network Analyst
> >Alcatel Canada TA
> >
> >mailto:[EMAIL PROTECTED]
> >
> >
> >
> >
> > Fred Johanson
> > <[EMAIL PROTECTED] To: [EMAIL PROTECTED]
> > ICAGO.EDU> cc:
> > Sent by: "ADSM: Subject: Excludes in TSM
> > Dist Stor
> > Manager"
> > <[EMAIL PROTECTED]
> > T.EDU>
> >
> >
> > 09/11/00 12:56
> > PM
> > Please respond
> > to "ADSM: Dist
> > Stor Manager"
> >
> >
> >
> >
> >
> >Last week, I upgraded my server to TSM V3R7. The client had been TSM for
> >months and seems to have had no problem with the exclude file, which looks
> >like
> >
> >EXclude /adsmdb/.../*
> >EXclude /adsmlog/.../*
> >EXclude /adsmstgpool1/.../*
> >EXclude /adsmstgpool2/.../*
> >
> > ...
> >
> >EXclude /adsmarch/.../*
> >
> >I'd done an incremental before the upgrade and the occupancy for V3R1 was
> >about 4Gb. After the upgrade, I started another incremental. I waited a
> >reasonable length of time and I checked: 4Gb and still going. It kept
> >going all afternoon, and the q sess showed 10Gb, 15Gb, etc. It was still
> >run when I got home and it ran all night. The next morning, q sess showed
> >100Gb and counting. Q fi showed that it had processed a 30Gb and a 18Gb
> >storagepool. What led me to cancel was the q occ of the node, which showed
> >that the process had backedup both storage pools and was starting on the
> >DB. The pattern of the excludes has been working since V2R1, but suddenly
> >something seems to have gone wrong. Have I missed something?
> >
> >
Fred Johanson
System Administrator, ADSM
S.E.A.
University of Chicago
773-702-8464
