What's going on with the V3 Client in general.

You sound very exasperated although I feel that the majority of your claims
are very justified.
I am very dissatisfied with the V3 Client. I agree that it is as you stated
poorly documented.
We've had various problems with the introduction of the UNC filespaces,
everything from the half
hearted unicode support (which caused more problems than it fixed) to this
very bizarre problem with
the drive labels.

I really don't understand what the developers are trying to accomplish with
this and I would appreciate
some sort of feedback from IBM. When going through the documentation on all
this drive label business
a number of problems situations are indicated but no resolutions are
provided... what is the point in that?

I'm also not impressed with the performance of ADSM v3. It is such a
resource hog! I am currently backing up
an NT Server and memory utilization by the ADSM Client hit 110Mbytes within
3minutes.
This is not an old version - this is V3.1.0.6!

We simply cannot backup certain servers during the day with this sort of
resource hogging going on. I thought that one
of the main improvements of V3 was to move the work to the server from the
client? This may be true on restores,
but backup is still very client intensive. The Memoryefficentbackup option
does help, slightly, but the time it takes is
just not acceptable.







        -----Original Message-----
        From:   Roger Deschner [SMTP:U52983 AT UICVM.UIC DOT EDU]
        Sent:   Saturday, January 16, 1999 4:24 PM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        What's going on with LABELs in V3 client?

        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."
=====================