> Looks like we found another 'bug?' with the CDL last night too. It is
trying to load a virtual 
> volume in a virtual drive but can not read the label. It then makrs it
as unlabeled and put's 
> it back in the virtual slot. It then tries another and same thing.
Then another and another 
> until we are out of volumes and backups stop. We have opened a bug
with that too and EMC has
> acknowledged that it is a bug. It is on the hardware side so NW is
waiting on hardware engineers to fix it. 

This sounds like a bug I had reported and gotten a fix for (which didn't
work every time) and is supposed to be in the newest jumbo release

The issue was that the media DB (nsrmmgd) wasn't ready in time to talk
to nsrd so the line of communication is gone - any volume is
unrecognized

This shows itself in two ways in my experience, either it continues to
label tapes and then can't use it (so another gets labelled...), or it
loads a labelled tape for use, reports some error and then ejects it
(and repeats...)

The original suggestion from EMC was to kill nsrmmgd (which
automatically restarts) but I just restart all services and 9/10 times
it works

HTH
Jerry



-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of NetWorker Forum
Sent: Friday, May 04, 2007 9:16 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] nsrclone

I have a perl script that creates a list of ssid's that I want to clone.
It organizes it by volume and then starts 5 threads with unique ssid's
to clone. I check the return code of the nsrclone command at the end and
if it's successful then I remove the  source ssid and keep the new
cloned ssid on physical tape. The problem is that sometimes there is a
message in STDERR that we didn't capture as part of the script. But if
you look at STDOUT it says "nsrclone: Successfully cloned all requested
save sets " and $? = 0. When you try to restore the cloned ssid it is
missing data. There is a bug ID "LGTsc05102" for this problem. The only
resolution is that I am now capturing STDOUT and STDERR and the script
does NOT do an automatic cleanup. We have to manually look through the
logs to make sure there are no errors and then we can remove them. 

Also, we ended up losing a significant amount of backed up data due to
NW's 2038 bug. No one told us this when we bought it and NW accepts a
browse and retention past the year 2038 but it then marks them eligible
for recycling within 24 hours. We didn't notice it for awhile, so we
lost a significant amount of data that we are legally bound to keep. FDA
requirements. 

Looks like we found another 'bug?' with the CDL last night too. It is
trying to load a virtual volume in a virtual drive but can not read the
label. It then makrs it as unlabeled and put's it back in the virtual
slot. It then tries another and same thing. Then another and another
until we are out of volumes and backups stop. We have opened a bug with
that too and EMC has acknowledged that it is a bug. It is on the
hardware side so NW is waiting on hardware engineers to fix it.

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER