Just a guess but you may want to try it.
Ensure the default class and the one with longest retention in that domain
do not point to a diskpool (while other used direct backups to tape). We
made this work on 4.2.1.15 but actually is unsupported (and maybe I was
just lucky). The problem was when the files go to tape and the directories
(through longest retention class or explicitly stated DIRMC) go to disk.

Zlatko Krastev
IT Consultant






Eric Winters <ewinters AT AU1.IBM DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06.12.2002 00:59
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        smnode.c Error obtaining copy group


Dear All,

I could have sworn I had seen this posted somewhere but bizarrely cannot
locate it now when I really need it.

I've been backing up happily over the LAN with TDP for R/3 3.2.0.12 to a
TSM 4.2.3 server on AIX.

Now I've switched back to lanfree. The Storage Agent is at the same level
as the server.
I'm getting the following message on the server.

ANR9999D (Session: 60041, Origin: GISR07_SA) smnode.c(7828): ThreadId<11>
Error obtaining copy group name for ID 1 during Session 4849.

I seem to remember there was some mention of difficulties in rebinding
between management classes when moving between lanfree backups and lan
backups, however I thought the problem only showed itself if you tried to
change the management class whilst using lanfree and that the 'cure' was
to
send data over the lan where it would successfully rebind. I've been off
lanfree for a few weeks - true, the management class whilst on the lan has
been successfully changed. Just what is the story here?

Thanks to anyone who can shine a light on this - and I steel myself for a
scolding if this has indeed already been mentioned.

Regards,

Eric Winters
Sydney Australia