Re: Long Filename Error

Bill, are you referring to a NetWare short-too-long file name conversion
issue?

I am not aware of any problems on NT -- especially any that would cause an
abort -- with regard to handling longer file names (greater than 259
characters) once you have the fix for IC27346 in place. The only caveat is
that USEUNICODEFILENAMES NO must be specified in the dsm.opt file for long
file name support to work. Perhaps that is Kelil's problem?

The issue with long file names is documented in APAR IC27346, and was
fixed in a 3.7.2 fixtest, and 4.1.1 and up. You just need to be sure you
have USEUNICODEFILENAMES NO in dsm.opt. The 3.1 Windows client never
handled the long file names correctly.

For more info on this, you can search the ADSM-L archives at www.adsm.org.
Just use a search criterion of "IC27346" (without the quotes), and you
should find the appropriate information.

Kelil, if you are using USEUNICODEFILENAMES NO and the backup is actually
aborting with a message about long file names, you should contact
IBM/Tivoli support for assistance. Actually, you should contact them
regardless of the USEUNICODEFILENAMES setting, since TSM should just skip
the long file names if the option is not set to NO; it should not cause an
abort.

Regards,

Andy

Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: araibeck AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




William Boyer <wboyer AT PTD DOT NET>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
08/29/2001 00:58
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Long Filename Error



Without specific error message, I'm going to assume you're getting the
same
problem we have/had here. The new client is trying to do the short-to-long
filename conversion and choking. We opened an ETR with Tivoli and the
response was the 4.2 level of BOTH client and server will fix the problem
with the conversion. In the mean time, you can either:

1. Specify MEMORYEFFICIENTBACKUP YES in the DSM.OPT file. This will
prevent
the client from doing the conversion.

2. Give the client a different nodename. The files will be backed up
correctly using the long filename. No conversion is done in this case, BUT
you'll get a full backup the first time.

We've done a combination of the two, depending on the size of the client.
Can't really afford to backup everything on some of them again.

Bill Boyer
DSS, Inc.
  -----Original Message-----
  From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
kelil kenzu
  Sent: Tuesday, August 28, 2001 11:40 AM
  To: ADSM-L AT VM.MARIST DOT EDU
  Subject: Long Filename Error


  We recently upgrade NT client from version 3.1.7 to 4.1.3.  Since the
upgrade we have had problems backing up some of our clients.  Scheduled
backups abort with the error of long filenames.  However, the same files
that we are having problems backing up with the new client used to be
backuped with 3.1.7 with out any problems.  When i try to do a restore the
last time these files were backuped were with the old ADSM Client version.

  Any Ideas would be greatly appreciated


  Thanks,

  Kelil


----------------------------------------------------------------------------
--
--
  Get your FREE download of MSN Explorer at http://explorer.msn.com
  Get your FREE download of MSN Explorer at http://explorer.msn.com