This change to the Universal Naming Convention is hitting me BAD. And,
the documentation is almost nonexistent, and what there is, is
misleading. I've about had it with the WIN32 V3 backup/restore client.
I want to get one thing straight. With the V3 Win32 client, do disk
labels on non-removable disks matter anymore? The well hidden doc about
UNC in readme.old implies that they DO NOT MATTER anymore. Is this true?
APAR IC20281 seems to imply that they do and they don't, and that the
author of the APAR is confused too. If the Filespace Name is
"\\machine\C$\", then why would it be "DRIVE HAS NO LABEL" if the drive
was unlabeled?
But what does now matter very much is the "machine name", which is taken
from someplace buried deep within Windows 95, and which you should not
change without lousing up the rest of Win 95 in some inexplicable way.
Disk labels were much better - you could change them without a lot of
collateral damage. Also, the drive letter now matters, which is VERY BAD
news, since Windows (actually the underlying DOS) rearranges these on you
from time to time. When it does, suddenly an incremental backup
unexpectedly becomes a full backup. I mean, if I've got a drive with
three partitions C: D: E:, and a repartition to combine C: and D:,
leaving E: untouched, it will become D:, because that's just how DOS does
it and I gave up arguing with Bill Gates long ago. ADSM V2 Client would
have handled that in stride, and after a minor complaint about the letter
changing, would have carried on OK. To ADSM V3, it's a whole new
filespace.
You will get message
ANS1056E Share/network path cannot be resolved. Path does not exist.
on any mismatch - a message says very little about how to proceed.
WHAT TO DO: Use DSMC QUERY FILESPACE to find out what you can restore,
and its filespace name, which might be surprising. Then specify the
filespace on the DSMC RESTORE command inside curly brackets {}. And,
unless you lucked out and got everything to match despite not being told
what had to match, you MUST!!! specify a destination drive for the
restore. *****EVEN IF IT IS THE SAME!!!!!!*****
Oh, and the V3 GUI client is USELESS for restores!
And, the redbook about bare metal restores needs to be redone for V3
clients. UNC needs to be addressed thoroughly there, because it has such
severe implications for bare-metal restores. Or, perhaps the V3 client
should just be withdrawn, and then the redbook would still be OK.
Pardon my exasperation, but I've been struggling for three days with a
bare metal restore of a Windows 95 PC that had been backed up using the
WIN32 V3 client. I've never had trouble with ADSM restores like this
before. And this trouble was caused partly by out-of-date documentation
WHICH WAS SUPPLIED WITH THE V3 CLIENT. If you have SH26-4078-01, throw it
away, but there is nothing to replace it.
I'm sticking with V2 clients wherever I still have them! And, I'm going
to seriously figure out a way to backlevel this machine to V2 Client once
I endure this restore. Those performance and other improvements in the V3
client come at too high a price! This thing is a serious leap backwards.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
Aliases: USUICZ3P at IBMMAIL u52983 AT uicvm.uic DOT edu
=============== "Civilization was CAUSED by beer." =====================
|
