Thanks for your update. The Level 2 Support Engineer who I talked with
explained some of the complexities involved in making this change and I
appreciate that it's not definitely something that can be done overnight.

Good to know that it's being addressed.

Thanks,

Nathan

        -----Original Message-----
        From:   Andy Raibeck [SMTP:storman AT US.IBM DOT COM]
        Sent:   Thursday, January 06, 2000 4:09 PM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Re: How to backup files containing Japanese
characters

        Hi Nathan,

        Yes, this one is also near and dear to my heart...

        The key is that if the file name contains characters that are not
        in the native code page for the language version of NT that you
        are running, then we won't be able to back the file up. For English
        NT systems, any double-byte character is not in the Latin I ANSI
        code page (1252), so ADSM/TSM can not back them up.

        The existing support for Unicode is of very narrow scope, and is
        intended only for the Mac namespace support.

        You can rest assured that this is very high-priority item for us,
        and that a solution is being worked on. I can not say when it will
        appear, but it is still a ways off; I would not expect any
        solution sooner than 4Q2000. The delay is not
        because we are putting it off, but because it is a very complex
        change that is much more easily said than done. NOTE: standard
        disclaimer about this not being a formal announcement, etc.,
        apply.

        Regards,

        Andy

        Andy Raibeck
        IBM
        Tivoli Storage Manager Client Development
        e-mail: storman AT us.ibm DOT com
        "The only dumb question is the one that goes unasked."

        Absolutely correct. One of my fav topics also. The only real
workaround is
        not to copy files from one NT server using a certain codepage to
another NT
        server using a different codepage. Depending upon how NT decideds to
map
        these characters into the Unicode codepage will dictate whether ADSM
will
        be
        able to back them up. If NT maps into a private use range, then ADSM
will
        complain.

        Alan and I have both posted quite often on this topic. Although ADSM
does
        support unicode, it's support is not complete. Until such time that
it is,
        these problems will continue. I believe that full unicode support
for TSM
        is
        on the table, but I don't know how high on the list of priorities it
is. I
        did put in my 2 cents with Tivoli that I thought this was an
important
        design change, but we'll wait and see.

        I've also ran into this problem with a remote control package called
        Remotely Possible which creates a cache folder. From time to time
Remotely
        Possible created some files with very unusual chars. ADSM didn't
just skip
        the files, it caused an assertion failure within the program. The
only fix
        was to crank up the GUI, do a backup and then see where ADSM was
dieing. It
        was then a case of deleting the offending file(s). What was even
stranger
        was that when I tried to send the offending files to ADSM
Development,
        Outlook couldn't attach them to an email and pkzip couldn't zip
them.. I
        ended up copying them onto a disk and mailing it. Hmmm.. looks like
ADSM
        isn't the only program that has problems dealing with NT's
implementation
        of
        Unicode, even Microsoft seems confused.

        Nathan