ADSM-L

Re: [ADSM-L] Unicode on UNIX

2010-05-18 13:10:25
Subject: Re: [ADSM-L] Unicode on UNIX
From: Michael Green <mishagreen AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 18 May 2010 20:09:03 +0300
On Tue, May 18, 2010 at 5:41 PM, Bjoern Rackoll
<backup AT rrz.uni-hamburg DOT de> wrote:
>>>> For my users with Unicode files on UNIX clients, I recommend this be
>>>> added
>>>> to the startup scripts for the scheduler or CAD:
>>>>
>>>> LANG=en_US
>>>>
>>>> LC_ALL=en_US
>>>>
>>>> export LANG
>>>>
>>>> export LC_ALL
>>
>> My observations indicate that this will work as long as you issue
>> these commands in your normal login shell and then run dsmcad.
>> However, if these variable are set in a strartup script upon boot, it
>> won't work. ANS4042E will continue to be logged in dsmerror.log. (In
>> fact there is no need to set LC_ALL variable. It's enough to set the
>> LC_CTYPE and LANG variables only.)
>>
>> I'd like to hear from anyone who was able make it work and survive
>> reboots.
>
> LC_CTYPE=en_US LANG=en_US nohup /usr/bin/dsmc sched
>
> in a startup script should do the trick. At least it does here. :-)

I'm wondering where do you place this line in SLES? In RHEL there is
/etc/rc.local which starts late in boot process after the network and
all other services are already up. In SLES the equivalent would be
/etc/init.d/boot.local. But in contrast to /etc/rc.local, boot.local
starts very early during boot (before network and stuff).

>> AFAIK, there is no /etc/locales.gen and locale-gen in SLES or RHEL.
>> The two major Linuxes for with the TSM client is produced and
>> supported.
>
> I've had these unicode problems only with Debian and Ubuntu, and for
> both distributions /etc/locales.gen and locale-gen exist. SLES (at least
> 10.3) does already have all required locales. But if not, 'localedef'
> will help. I don't know about RHEL, we don't use that distribution.
>

You are right in SLES and RHEL the en_US locale is in place (it would
be odd if it wasn't)

> For SLES based systems, we use the following startup script (uses German
> locales, so adjust these if they're not available on your system):

Well I'm used to use the init script provided by IBM for
SLES found here
<http://www-01.ibm.com/support/docview.wss?rs=663&context=SSGSG7&q1=linux+start+dsmcad&uid=swg21240599&loc=en_US&cs=utf-8&lang=en>
and
RHEL found here <http://www-01.ibm.com/support/docview.wss?uid=swg21358414>

Long ago I modified the SLES script to include the locale stuff as following:
< startproc $DSMCAD_BIN
> LC_CTYPE=en_US LANG=en_US startproc $DSMCAD_BIN

which sets the related variables temporarily only for the DSMCAD invocation.
Again, if I start this script manually from the root login shell
(after bootup, of course), it will work. Any file, no matter what
character set it uses in its file name will be backed up properly.
However, if the machine is rebooted, allowing the script to be started
automatically (as part of normal boot sequence), the consecutive
backup will report the dreaded ANS4042E errors with the very same
non-en_US files that had been backed up before without a hitch.
I've spent considerable time investigating this issue and haven't
found a solution. One of my findings is that no matter how the script
is started (manually or not) the
grep -a --color=yes -e LC_CT -e LANG /proc/`pgrep dsmcad`/environ
indicates that LC_CTYPE and LANG are set correctly to en_US. But
oddly, the ANS4042E doesn't pop up in the logs only in case of manual
script invocation. So far, I wasn't able to crack it.

> case "$1" in
>     start)
>         echo -n "Starting ADSM scheduler "
>         # set locale for TSM
>         if [ -d /usr/lib/locale/de_DE ]; then
>                export LANG=de_DE
>                export LC_CTYPE=de_DE
>        else
>                echo    " "
>                echo    "locale de_DE needed by TSM not found"
>                echo    "please generate locale with"
>                echo -n "\$ localedef"
>        fi
>         ## Start daemon with startproc(8). If this fails
>         ## the return value is set appropriately by startproc.
>         /sbin/startproc $DSMC schedule >>/var/adm/ras/dsmsched.log \
>                         2>>/var/adm/ras/dsmerror.log &
>
>         # Remember status and be verbose
>         rc_status -v
>         ;;

This part is not much different from mine, I guess. The only
difference is that you 'export' your LANG and LC_CTYPE variables,
meaning they will be inherited by every daughter process launched by
this script from now till termination, whereas in my script the
LC_CTYPE is inherited by DSMCAD only. It's my understanding that
either way is ok and should do the job.

--
Warm regards,
Michael