Change the dsm.opt file.....not that difficult for end users to do.
______________________________ Reply Separator _________________________________
Subject: Node Rename 102
Author: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> at SMTP
Date: 8/29/96 4:15 PM
Date: August 29, 1996 Time: 14:41
From: Jerry Lawson
ITT Hartford Insurance Group
(860) 547-2960 jlawson AT itthartford DOT com
-----------------------------------------------------------------------------
A while back there was a discussion thread going on renaming nodes, and there
A while back there was a discussion thread going on renaming nodes, and there
were several creative suggestions made. Now I have a situation with a rename
that is giving me fits. I think I have discovered a logic flaw within ADSM as
part of the process. I am looking for your suggestions and comments.
Here is what happened. - A user was identified to ADSM, and we backed up her
machine, which was running Windows 3.1. After several months of this, her
machine was upgraded to Win95. Around here that includes a reformat of the
hard drive, and a new label on the drive. When the guy that does the installs
reinstalled ADSM, he mis-typed the node name (he has admin capability, and
sets up new clients.) He thought this was a new user, and so set her up from
scratch, including a new backup. Now the owner wants to pull back personal
files from the first restore that were lost in the reformat.
The quick and dirty way is to change her DSM.OPT and point to the old id, and
do the restore. For an end user, this is too much mess. A better solution
(some) is to provide access through the Set Authorization feature, and then
have the user jump back and forth. Better, but my ideal would be to have both
backups available under one node ID. (By the way, the confusing thing here is
that the second ID is actually the correct one - they mistake is in the first
one - so to be correct to our internal standards, I can't just delete the last
backup and go back to the old one......)
There are other potential solutions that come to mind, but the one that made
the most sense to me was to export the node, and import it as the right one.
This of course involved an export of the new node, a delete of all of the file
spaces and the node definition, a rename of the old node to the new node, and
then an import of the exported files. Sounded slick to me. The problem is -
it doesn't work!
What happens? - I get an ANR0689W message that says that the client platforms
conflict on import, and it won't let me restore. The text of the message goes
on to state that "Because file data may not be compatible across different
platforms, the node is not imported". The suggested response is to use Node
Rename to address the problem but of course that won't work because you can't
rename a node to one that already exists! The message also suggests that if
this was OS/2 and AIX, obviously the two won't work. HOWEVER - I want to
restore a WIN 3.1 onto a WIN95 - the file types ARE compatible. ADSM is
making a gratuitous assumption that I need to be protected from myself that is
incorrect.
Now I have always thought I could out-con some dumb software, so I went over
to the machine, set the DSM.OPT back to the original Node name, and ran a
quick 2 file backup. Now the node should recognize that it is a Win95 node -
right?. Wrong! went through the same process - exported the files, did the
renames, and tried the imports. Same message.
The first thing that I can think of is that field in the NODE display that
shows the platform type when the NODE is first backed up - the one that never
changes. If a node changes platforms (such as going from Windows to Win95) it
still says the first platform. I have customers who are on their third OS,
and the ADSM node still says it is the first one. Is Import looking at this?
If it is, there is a logic flaw - basing a go/no go decision on a field that
cannot be changed and is (very) potentially incorrect.
What I would like to see is a new operand on the Import command that is the
equivalent of "Force" - restore the filespace anyway, and then lets see if we
can read it. I can think of other such combinations which are valid, such as
Windows onto OS/2, OS/2 FAT onto Windows, that will work. Don't lock us out.
This scenario fortunately happened with a friend's PC - I didn't have problems
gaining access to it, and she was understanding. This is not always the case.
While I you are looking at operands for Import, a NewName= parm would be good
too - in this case it would avoid a rename process - export the node, then
import directly with the new name.
Ok - enough of my Rant - what do others think?
*****************************************************************************
Jerry Lawson
ITT Hartford Insurance Group
jlawson AT itthartford DOT com
Any idiot can face a crisis. It's the day to day stuff that really wears you
down.
Anton Chekov
|
