Responded to offline.
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.eyebm DOT com (change eye to i to reply)
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
PAC Brion Arnaud <Arnaud.Brion AT PANALPINA DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
10/25/2002 07:34
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Directories written in the wrong pool, although
using dirmc option
Hi Andy,
And thanks a lot for your response. I checked dsm.opt on one of the
nodes generating problems, it looks like :
LANG AMENG
tcpport 1500
TCPSERVERADDRESS XXXXX
ipxsocket 0005
ipxserveraddress 0000000000409512588A
netbiosname client1
netbiosservername ntserver1
namedpipename \\.\pipe\adsmpipe
Exclude "*:\macintosh volume\*"
Exclude "*:\macintosh volume\*.*"
Exclude "*:\macintosh volume\...\*"
Exclude "*:\macintosh volume\...\*.*"
Exclude "*:\microsoft uam volume\*"
Exclude "*:\microsoft uam volume\*.*"
Exclude "*:\microsoft uam volume\...\*"
Exclude "*:\microsoft uam volume\...\*.*"
Exclude "*:\...\EA DATA. SF"
Exclude *:\...\pagefile.sys
Exclude *:\IBMBIO.COM
Exclude *:\IBMDOS.COM
Exclude *:\MSDOS.SYS
Exclude *:\IO.SYS
Exclude *:\...\SYSTEM32\CONFIG\*.*
Exclude *:\...\SYSTEM32\CONFIG\...\*
SUbdir Yes
passwordaccess generate
TCPWINDOWSIZE 64
BACKUPRegistry YES
ERRORLOGRETENTION 7
SCHEDLOGRETENTION 7
I tried "dsmc show opt" and found the dirmc was pointing to the right
management class. I also made sure this node was properly associated
with option set containing dirmc. So I still have no idea what happens
:(
I then ended by creating a new policy domain, specific for SQL machines,
to get a rid of this problem, but it's really frustrating ...
Thanks anyway.
Regards.
Arnaud
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Arnaud Brion, Panalpina Management Ltd., IT Group |
| Viaduktstrasse 42, P.O. Box, 4002 Basel - Switzerland |
| Phone: +41 61 226 19 78 / Fax: +41 61 226 17 01 |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----Original Message-----
From: Andrew Raibeck [mailto:storman AT US.IBM DOT COM]
Sent: Friday, 25 October, 2002 14:39
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Directories written in the wrong pool, although using dirmc
option
For why MGMT-SQL-META was used before you created the client option set,
see posting http://msgs.adsm.org/cgi-bin/get/adsm0208/1119.html in the
ADSM-L archives for .some thoughts on this. Also, make sure that each
individual node doesn't have DIRMC explicitly coded in it, and make sure
that each of the nodes in question are associated with the desired
client options set.
If that doesn't explain the trouble, then try the following from an OS
prompt:
1) Change into the directory where the TSM executables are located:
2) Run the following command:
dsmc show opt | findstr /c:dirmc
or if your scheduler uses an options file other than the default of
dsm.opt.
dsmc show opt -optfile=youroptfilename | findstr /c:dirmc
(NOTE: "show opt" is not an officially documented command.)
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.eyebm DOT com (change eye to i to reply)
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
PAC Brion Arnaud <Arnaud.Brion AT PANALPINA DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> 10/25/2002
03:23 Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Directories written in the wrong pool, although
using dirmc option
Hi *SM'ers,
I'm facing a strange problem, and would like to know if somebody could
give me an explanation ... The picture : We had a policy domain, named
"NT" defined for Windows systems, that got only one mgmt class, called
NT-SYSTEMS, copy group looking like that : NT ACTIVE NT-SYSTEM STANDARD
15 15 30 60, pointing to a disk pool called diskpool_win. I then was
required to initiate new backups, for Microsoft SQL DB's. I thought it
would not be necessary to create a new policy domain to do those
backups, and just added new management classes and copy pools, looking
like : NT ACTIVE MGMT-SQL-FULL STANDARD 6 0 No Limit No Limit, pointing
directly to a tape pool called tapelto_sql_full, used for SQL full
backups NT ACTIVE MGMT-SQL-LOG STANDARD 1 0 No Limit No Limit ,
pointing to a disk pool named diskpool_sql_logs, size 4 GB, used for SQL
log backups NT ACTIVE MGMT-SQL-META STANDARD 6 0 No Limit No Limit,
pointing to a disk pool named diskpool_sql_meta, size 1MB, used for SQL
meta data I activated, and validated the whole stuff, and next night,
got all my NT nodes having backup status "failed". After some
headscratching, I found my problem was due to the fact that all
directory data was sent to diskpool_sql_meta, which was too small, and
had no migration pool. So far I agreed : directory data had took the
management class having the longest retention period. I then built a new
disk storage pool, named diskpool_dir, size 4 GB, attached to a new Mgmt
class looking like : NT ACTIVE MGMT-DIR STANDARD 15 15 No Limit No limit
And also defined a new client option set for NT nodes, specifying "DIRMC
MGMT-DIR". Once again activated the whole thing, and had 3 peaceful
nights ... until today. The event logger showed me some NT nodes had
status "failed" for their backup, reason : "no space available". I then
found that diskpool_meta was once again full, because those nodes had
written directories path into it ! But that time I really can't
understand what happened. Does anybody have a clue what happens here ?
Zillion thanks in advance ! Arnaud
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Arnaud Brion, Panalpina Management Ltd., IT Group |
| Viaduktstrasse 42, P.O. Box, 4002 Basel - Switzerland |
| Phone: +41 61 226 19 78 / Fax: +41 61 226 17 01 |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
