Hi have the same approach as Leandro with this kind of error on Linux clients.
I create a script to automate the backup with those export commands :
export LANG=he_IL.utf8
export LC_CTYPE=he_IL.utf8
dsmc I -su=yes .....
And run a scheduler client with the option "command"
Regards Robert
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Leandro Mazur
Sent: Wednesday, May 19, 2010 1:46 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Unicode on UNIX
We had a lot of problems like that...the solution, at least in the cases
where the locale change was not possible, was to create a client schedule
(with action=command), create a script and put an export line in this
script....something like this:
export LC_ALL=pt_BR.ISO8859-1
export LANG=pt_BR.ISO8859-1
dsmc inc -verbose -sub=yes > some_log
not exactly the same, but you've got the idea...we've tried to put the
export lines on the "dsmc sched" script, but it didn't work...when you do
export on the command line, that's only valid for that session and I think
that the two scripts are two sessions separated (in the OS)....
I the cases where the change of locale was possible, the sysadmins put the
lines above in the /etc/environment...but the locales had to be installed
first.
On Tue, May 18, 2010 at 6:02 PM, Michael Green <mishagreen AT gmail DOT com>
wrote:
> On Tue, May 18, 2010 at 10:49 PM, km <km AT grogg DOT org> wrote:
> > I would advice against overriding the default settings in a script and
> > instead to set the correct locale for the system. Most system settings in
> > RHEL based distros are made in the sysconfig directory:
> >
> >
> http://www.centos.org/docs/5/html/5.1/Deployment_Guide/s2-sysconfig-i18n.html
> >
>
> Please let me disagree with you. I think it's a wrong approach to
> change locale for the entire OS for the sake of backups only.
> Besides, I'm not fully aware of consequences of changing the locale
> system wide.
> Are you?
>
> > In this case, if the locale does not exist, just install it. Since the
> en_US
> > locale is included in the glibc-common RPM try to reinstall or update
> that
> > RPM.
>
> I didn't tell en_US locale doesn't exist. In contrary, it does. What I
> said is that Linux TSM client will not backup files with funny
> characters in filename after dsmcad is started from init script on
> _bootup_ with LC_CTYPE and LANG locales set to en_US in RHEL and SLES.
>
> I challenge anyone to show that it works for him/her in any version of
> RHEL or SLES.
>
> >> However, a user running CentOS thinks that en_US does not exist in that
> flavor of LINUX, so he misses 1000s of files each night.
> >>
> >> Anyone have any thoughts on this?
>
> Fred has touched here a major problem that has plagued TSM product
> line for ages and continues to go unresolved. This is absolutely
> unacceptable that TSM client skips files with filenames that do not
> conform to specific locale. In my view, every file that can be
> registered in a file system (ext3/reiser/xfs) supported by major
> commercial Linux distributions (RHEL/SLES) must be backed up no matter
> what. As long as file system itself is consistent and underlying
> physical media is not damaged everything should just work.
> At around 2008 IBM published a paper called "Tivoli Storage Manager
> and Localization". The paper contains explanations on why it doesn't
> work and describes in length how to deal with the files named in
> various barbarian languages. It's a fascinating reading, but doesn't
> help much in my situation. And besides, with all due respect, IMO
> that's not something I, as administrator, should be dealing with. If
> GNU tar can swallow and restore these files without messing with
> locale or anything else, why TSM cannot?
> --
> Warm regards,
> Michael Green
>
--
__________________________________
Leandro Mazur
|
