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:fred AT MIDWAY.UCHICAGO DOT EDU]
Sent: Thursday, 14 September 2000 6:47 AM
To: ADSM-L AT VM.MARIST DOT EDU
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:Sean.Duffy AT tas.alcatel DOT ca
>
>
>
>
> Fred Johanson
> <fred AT MIDWAY DOT UCH To: ADSM-L AT
VM.MARIST DOT EDU
> 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
|
