Windows 2000 client

2010-05-18 Thread Lee, Gary D.
I know this is old, but we have a situation.

Tried to instal the latest tsm windows 2000 client I had downloaded.
Gave us an error claiming it wasn't the correct client for that op sys.

This was a security fix issued by ibm its name was tsm536c_2_x32.exe.

On the off chance that it was a corrupt download, went to try and find it 
again, haven't been able to come up with it.

So, what is the latest client fix for win 2000; and where do I find it?

Thanks all.


Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310

 

Re: Windows 2000 client

2010-05-18 Thread Loon, EJ van - SPLXM
Hi Gary!
The latest version for Window 2000 is 5.3.6.7 and can be downloaded from
IBM:
ftp://service.boulder.ibm.com/storage/tivoli-storage-management/patches/
client/v5r3/Windows/Win2000/v536/TSM536C_7_X32.exe
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Lee, Gary D.
Sent: dinsdag 18 mei 2010 15:22
To: ADSM-L@VM.MARIST.EDU
Subject: Windows 2000 client

I know this is old, but we have a situation.

Tried to instal the latest tsm windows 2000 client I had downloaded.
Gave us an error claiming it wasn't the correct client for that op sys.

This was a security fix issued by ibm its name was tsm536c_2_x32.exe.

On the off chance that it was a corrupt download, went to try and find
it again, haven't been able to come up with it.

So, what is the latest client fix for win 2000; and where do I find it?

Thanks all.


Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310

 

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



Re: Windows 2000 client

2010-05-18 Thread TSM User
ftp://ftp.software.ibm.com/storage/tivoli-storage-management/patches/client/v5r3/Windows/x32/v536/

should get you where you're going.

Be aware that you'll have to type the file name in manually rather than
clicking on the link.  IBM has, intentionally or accidentally, inserted a
single blank space in front of many (most?) of the links on the FTP site, so
it's no longer possible to simply click all the way through to what you're
looking for anymore.



On Tue, May 18, 2010 at 9:21 AM, Lee, Gary D. g...@bsu.edu wrote:

 I know this is old, but we have a situation.

 Tried to instal the latest tsm windows 2000 client I had downloaded.
 Gave us an error claiming it wasn't the correct client for that op sys.

 This was a security fix issued by ibm its name was tsm536c_2_x32.exe.

 On the off chance that it was a corrupt download, went to try and find it
 again, haven't been able to come up with it.

 So, what is the latest client fix for win 2000; and where do I find it?

 Thanks all.


 Gary Lee
 Senior System Programmer
 Ball State University
 phone: 765-285-1310




Re: Windows 2000 client

2010-05-18 Thread ADSM-L

Off the top of my head, I think 5.3.7.4 was a more recent Windows 2000-
safe version that I used to deploy back in the day, but there may have
been one or two further Win2K-able releases after that.

//David Mc



On 18 May 2010, at 14:21, Lee, Gary D. g...@bsu.edu wrote:


I know this is old, but we have a situation.

Tried to instal the latest tsm windows 2000 client I had downloaded.
Gave us an error claiming it wasn't the correct client for that op
sys.

This was a security fix issued by ibm its name was tsm536c_2_x32.exe.

On the off chance that it was a corrupt download, went to try and
find it again, haven't been able to come up with it.

So, what is the latest client fix for win 2000; and where do I find
it?

Thanks all.


Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310



TSM/TDP and MySQL

2010-05-18 Thread Zoltan Forray/AC/VCU
This is a 2-part question:

#1 - Has anybody heard of any rumors (or a we are planning to) that
IBM/Tivoli will have a TDP for MySQL?

#2 - How do you backup MySQL?  We are increasingly expanding MySQL use and
since IBM currently doesn't offer a TDP for MySQL, we are looking at other
commercial products like Zmanda Recovery Manager (
http://www.zmanda.com/tivoli-mysql-backup.html)

Zoltan Forray
TSM Software  Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html


Unicode on UNIX

2010-05-18 Thread Fred Johanson
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


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 Johanson
TSM Administrator
University of Chicago

773-702-8464


Re: SV: RedHat 5.2 to 5.4 upgrade causes problems for TSMscsi tape drivers

2010-05-18 Thread John D. Schneider
As a followup for this question, can anybody tell me where I would get
the drivers for this?  It is a HP E-series 712e tape library with LTO4
drives.  We are upgrading from RedHat 5.2 to 5.4.

I went out to HP's web site, and the only thing they offered is called
LTT, Library and Tape Tools.  But it doesn't look like it includes a
driver, just diagnostic tools, which won't solve my problems, since
people have been telling me I need the driver.

If HP doesn't supply one for their own product, where am I supposed to
get one?


Best Regards,

John D. Schneider
The Computer Coaching Community, LLC
Office: (314) 635-5424 / Toll Free: (866) 796-9226
Cell: (314) 750-8721



 Original Message 
Subject: [ADSM-L] SV: RedHat 5.2 to 5.4 upgrade causes problems for
TSMscsi tape drivers
From: Christian Svensson christian.svens...@cristie.se
Date: Thu, May 13, 2010 3:44 am
To: ADSM-L@VM.MARIST.EDU

Hi John,
When you upgrading RHEL from 5.2 to 5.4. Then does RHEL upgrade the
kernel also. 
That mean you need to download the HP Tape Source Code Drivers again and
re-compile them.

The TSM Drivers you may have installed, they are only creating links to
the correct SG devices that HP drivers are creating.


Best Regards
Christian Svensson

Cell: +46-70-325 1577
E-mail: christian.svens...@cristie.se
Skype: cristie.christian.svensson
Supported Platform for CPU2TSM::
http://www.cristie.se/cpu2tsm-supported-platforms


Från: John D. Schneider [john.schnei...@computercoachingcommunity.com]
Skickat: den 13 maj 2010 06:42
Till: ADSM-L@VM.MARIST.EDU
Ämne: Re: RedHat 5.2 to 5.4 upgrade causes problems for TSMscsi tape
drivers

Len,

 The IBMTape drivers are intended only for the IBM tape drives. For
all others (such as the HP in my case), the TSM drivers are what TSM
wants us to use.
 So I believe that we are using the right sort of driver, and it has
been working for some months; the problem only arose when we upgraded
RedHat from 5.2 to 5.4.


Best Regards,

John D. Schneider
The Computer Coaching Community, LLC
Office: (314) 635-5424 / Toll Free: (866) 796-9226
Cell: (314) 750-8721



 Original Message 
Subject: Re: [ADSM-L] RedHat 5.2 to 5.4 upgrade causes problems for
TSMscsi tape drivers
From: Len Boyle len.bo...@sas.com
Date: Wed, May 12, 2010 11:29 pm
To: ADSM-L@VM.MARIST.EDU

Hello John,

I have not used tsm on Linux, but I have used ibm tape drives on linux.
I used the ibm lintape driver. These tape drives were fc based. I am not
sure if your tape drives are fc based. I am also not sure if the lintape
driver supports scsi tape drives.

I do have a tsm server running on windows and they recommended that we
use the ibm tape drivers and not the tsm drivers for the newer tape
drives.

So I am doing a bit of guessing here.

Since the tape driver is the piece between the os and the hardware I
would expect that be the first part that needs looking at. It might be a
change in the o/s api used by the tape driver.

With the lintape driver you can test out the tape drive without tsm
running. Do you have another box that you can test out the different
tape drivers and tape drives?

I just looked at the lintape readme and it appears that it only is
supported with IBM devices.

Does HP supply drivers for use with their tape drives and Linux?

You might want to call IBM service for tsm and see what they might
suggest.

-
I remember seeing this note on a past adsm-l mailing list entry.

Re: Library unavailable
Michael Green
Mon, 06 Jul 2009 23:23:45 -0700

I don't know about 3583, but with 3584 one shouldn't use the TSM
supplied drivers. IBM provides a so called 'lintape' (ex IBMtape)
driver on their FTP.
--
len


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
John D. Schneider
Sent: Wednesday, May 12, 2010 11:07 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] RedHat 5.2 to 5.4 upgrade causes problems for
TSMscsi tape drivers

Len,
 Thanks for your reply. No, we did not upgrade any of the TSM
software, including the tape drivers. We were running the
TIVsm-tsmscsi-6.1.3-1.x86_64 version both before and after the RedHat
5.2 to 5.4 upgrade.
 I have since found out that there is a 6.1.3-3 version of the
driver. Since they are running the 6.1.3.3 version of TSM, they
probably should be running that version of the driver, too. I don't
know why or why not, since that is before they became my customer. The
previous TSM admins that set all this up are no longer working for this
company.
 But I hesitate to recommend upgrading the drivers as a course of
action unless I can point to a concrete reason why. I went through the
Release Notes and Readmes and could not find any hint of a driver
problem being addressed. None of the 

Re: TSM/TDP and MySQL

2010-05-18 Thread Mark Yakushev
Hi Zoltan,

Take a look at the Backing Up Databases Using ADSMPIPE and the TSM API:
Examples Using Linux Redbook -
http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/redp3980.html?Open

It has a section on backing up MySQL.

Regards,

Mark Yakushev


From: Zoltan Forray/AC/VCU zfor...@vcu.edu
To:   ADSM-L@vm.marist.edu
Date: 05/18/2010 06:37 AM
Subject:[ADSM-L] TSM/TDP and MySQL



This is a 2-part question:

#1 - Has anybody heard of any rumors (or a we are planning to) that
IBM/Tivoli will have a TDP for MySQL?

#2 - How do you backup MySQL?  We are increasingly expanding MySQL use and
since IBM currently doesn't offer a TDP for MySQL, we are looking at other
commercial products like Zmanda Recovery Manager (
http://www.zmanda.com/tivoli-mysql-backup.html)

Zoltan Forray
TSM Software  Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html



Win2000 tsm client

2010-05-18 Thread Lee, Gary D.
Thanks all.  Downloading as I write this.



Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310

 

Re: Unicode on UNIX

2010-05-18 Thread Bjoern Rackoll

Hi Fred,


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


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?


I've written some documentation on this at 
http://www.rrz.uni-hamburg.de/serversysteme/unix-server/adsm-backup/benutzung-des-tsm-clients/faq.html 



This page is unfortunately only available in German, but the main points 
are:


- Try 'locale-gen en_US' as root. Check with 'locale -a' if the required 
locale has been generated.


- If that doesn't work, add 'en_US ISO-8859-1' to '/etc/locales.gen' and 
proceed as above ('locale-gen en_US').


After completing these tasks, don't forget to restart the TSM scheduler. :-)

Regards,

--
Björn Rackoll
Universität Hamburg
Regionales Rechenzentrum
Zentrale Dienste
Schlüterstr. 70
20146 Hamburg
Tel.: +49 (0)40 42838 - 63 11
Fax: +49 (0)40 42838 - 62 70
E-Mail: bac...@rrz.uni-hamburg.de


Re: TSM/TDP and MySQL

2010-05-18 Thread Zoltan Forray/AC/VCU
Thanks for the reference.  I should have mentioned I already looked at
this.

My bosses requirements are: ANY product must be supported by
IBM/Tivoli for usage on a TSM server. Point-in-time recovery is mandatory,
or there is no point to using any product.

From what I have read (correct me if I am wrong) about using mysqldump, it
doesn't do/support this process.
Zoltan Forray
TSM Software  Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html



From:
Mark Yakushev bar...@us.ibm.com
To:
ADSM-L@VM.MARIST.EDU
Date:
05/18/2010 09:52 AM
Subject:
Re: [ADSM-L] TSM/TDP and MySQL
Sent by:
ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



Hi Zoltan,

Take a look at the Backing Up Databases Using ADSMPIPE and the TSM API:
Examples Using Linux Redbook -
http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/redp3980.html?Open


It has a section on backing up MySQL.

Regards,

Mark Yakushev


From: Zoltan Forray/AC/VCU zfor...@vcu.edu
To:   ADSM-L@vm.marist.edu
Date: 05/18/2010 06:37 AM
Subject:[ADSM-L] TSM/TDP and MySQL



This is a 2-part question:

#1 - Has anybody heard of any rumors (or a we are planning to) that
IBM/Tivoli will have a TDP for MySQL?

#2 - How do you backup MySQL?  We are increasingly expanding MySQL use and
since IBM currently doesn't offer a TDP for MySQL, we are looking at other
commercial products like Zmanda Recovery Manager (
http://www.zmanda.com/tivoli-mysql-backup.html)

Zoltan Forray
TSM Software  Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html


Re: Unicode on UNIX

2010-05-18 Thread Michael Green
On Tue, May 18, 2010 at 4:55 PM, Bjoern Rackoll
bac...@rrz.uni-hamburg.de wrote:
 Hi Fred,

 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.



 I've written some documentation on this at
 http://www.rrz.uni-hamburg.de/serversysteme/unix-server/adsm-backup/benutzung-des-tsm-clients/faq.html

 This page is unfortunately only available in German, but the main points
 are:

 - Try 'locale-gen en_US' as root. Check with 'locale -a' if the required
 locale has been generated.

 - If that doesn't work, add 'en_US ISO-8859-1' to '/etc/locales.gen' and
 proceed as above ('locale-gen en_US').

 After completing these tasks, don't forget to restart the TSM scheduler. :-)

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.


Re: Unicode on UNIX

2010-05-18 Thread Bjoern Rackoll
 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've written some documentation on this at
 
http://www.rrz.uni-hamburg.de/serversysteme/unix-server/adsm-backup/benutzung-des-tsm-clients/faq.html


 This page is unfortunately only available in German, but the main points
 are:

 - Try 'locale-gen en_US' as root. Check with 'locale -a' if the required
 locale has been generated.

 - If that doesn't work, add 'en_US ISO-8859-1' to '/etc/locales.gen' and
 proceed as above ('locale-gen en_US').

 After completing these tasks, don't forget to restart the TSM 
scheduler. :-)


 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.

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



#!/bin/sh
#
# Template SUSE system startup script for example service/daemon FOO
# Copyright (C) 1995--2005  Kurt Garloff, SUSE / Novell Inc.
#
# This library is free software; you can redistribute it and/or
modify it
# under the terms of the GNU Lesser General Public License as
published by
# the Free Software Foundation; either version 2.1 of the License,
or (at
# your option) any later version.
#
# This library is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307,
# USA.
#
# /etc/init.d/FOO
#   and its symbolic link
# /(usr/)sbin/rcFOO
#
# Template system startup script for some example service/daemon FOO
#
# LSB compatible service control script; see http://www.linuxbase.org/spec/
#
# Note: This template uses functions rc_XXX defined in /etc/rc.status on
# UnitedLinux/SUSE/Novell based Linux distributions. If you want to base
your
# script on this template and ensure that it works on non UL based LSB
# compliant Linux distributions, you either have to provide the rc.status
# functions from UL or change the script to work without them.
# See skeleton.compat for a template that works with other distros as well.
#
### BEGIN INIT INFO
# Provides:  tsmsched
# Required-Start:$syslog $remote_fs
# Should-Start:
# Required-Stop:
# Should-Stop:
# Default-Start: 3 5
# Default-Stop:  0 1 2 6
# Short-Description: TSM schedulder
# Description:   controls TSM scheduler
#   IBM Tivolo Storage Manager
### END INIT INFO
#
# Any extensions to the keywords given above should be preceeded by
# X-VendorTag- (X-UnitedLinux- X-SuSE- for us) according to LSB.
#
# Notes on Required-Start/Should-Start:
# * There are two different issues that are solved by Required-Start
#and Should-Start
# (a) Hard dependencies: This is used by the runlevel editor to determine
# which services absolutely need to be started to make the start of
# this service make sense. Example: nfsserver should have
# Required-Start: $portmap
# Also, required services are started before the dependent ones.
# The runlevel editor will warn about such missing hard dependencies
# and suggest enabling. During system startup, you may expect an error,
# if the dependency is not fulfilled.
# (b) Specifying the init script ordering, not real (hard) dependencies.
# This is needed by insserv to determine which service should be
# started first (and at a later stage what services can be started
# in parallel). The tag Should-Start: is used for this.
# It tells, that if a service is available, it should be started
# before. If not, never mind.
# * When specifying hard dependencies or ordering requirements, 

Re: Windows 2000 client

2010-05-18 Thread Clark, Margaret
5.4.0.2 was the last release that could be installed on Windows 2000.  It 
works.  - Margaret

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of ADSM-L
Sent: Tuesday, May 18, 2010 6:35 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Windows 2000 client

Off the top of my head, I think 5.3.7.4 was a more recent Windows 2000-
safe version that I used to deploy back in the day, but there may have
been one or two further Win2K-able releases after that.

//David Mc



On 18 May 2010, at 14:21, Lee, Gary D. g...@bsu.edu wrote:

 I know this is old, but we have a situation.

 Tried to instal the latest tsm windows 2000 client I had downloaded.
 Gave us an error claiming it wasn't the correct client for that op
 sys.

 This was a security fix issued by ibm its name was tsm536c_2_x32.exe.

 On the off chance that it was a corrupt download, went to try and
 find it again, haven't been able to come up with it.

 So, what is the latest client fix for win 2000; and where do I find
 it?

 Thanks all.


 Gary Lee
 Senior System Programmer
 Ball State University
 phone: 765-285-1310



Re: Windows 2000 client

2010-05-18 Thread Thorneycroft, Doug
This is the latest Windows 2000 client

ftp://index.storsys.ibm.com/tivoli-storage-management/maintenance/client
/v5r4/Windows/Win2000/


Tsm client scheduler 6.2 with centos linux

2010-05-18 Thread Lee, Gary D.
Client version 6.2

Best I can get for the linux version is as follows:

Linux version 2.6.18-128.el5xen (mockbu...@builder10.centos.org) (gcc version 
4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Wed Jan 21 11:12:42 EST 2009

When dsmc sched is run, about a minute later in the error log is the following:


05/17/2010 14:04:25 ANS2820E An interrupt has occurred. The current operation 
will end and the
client will shut down.
05/17/2010 14:04:26 ANS0361I DIAG: Unknown thread, fatal error, signal 11

This is not my machine, and I have no privs.  Any pointers will be helpful.
Google turned up nothing, tsm help turned up nothing.


Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310

 

Re: Win2000 tsm client

2010-05-18 Thread Grigori Solonovitch
Maybe it is too late, but we are using 5.4.1.2 on Windows 2000.


From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Lee, Gary D. 
[g...@bsu.edu]
Sent: Tuesday, May 18, 2010 4:55 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Win2000 tsm client

Thanks all.  Downloading as I write this.



Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310



Please consider the environment before printing this Email.

CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail 
message and any attachments hereto may be legally privileged and confidential. 
The information is intended only for the recipient(s) named in this message. If 
you are not the intended recipient you are notified that any use, disclosure, 
copying or distribution is prohibited. If you have received this in error 
please contact the sender and delete this message and any attachments from your 
computer system. We do not guarantee that this message or any attachment to it 
is secure or free from errors, computer viruses or other conditions that may 
damage or interfere with data, hardware or software.


Severe PMR 82034

2010-05-18 Thread Andrew Carlson
I submitted a PMR, 82034.  TSM 6.2 running on AIX 6.1.4.2, hanging on
shutdown, and hanging starting up after killing it.  They say it looks
like PMR 80033, where they had to downgrade to AIX 6.1.2, which fixed
the hang.  No info yet on why, or when a later fix will be available.
This is not difinitive yet either, Level 2 is still looking at it.
Luckily this was my test system . . .

--
Andy Carlson
---
Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month,
The feeling of seeing the red box with the item you want in it:Priceless.


Re: TSM/TDP and MySQL

2010-05-18 Thread Remco Post
On 18 mei 2010, at 16:23, Zoltan Forray/AC/VCU wrote:

 Thanks for the reference.  I should have mentioned I already looked at
 this.
 
 My bosses requirements are: ANY product must be supported by
 IBM/Tivoli for usage on a TSM server. Point-in-time recovery is mandatory,
 or there is no point to using any product.
 
 From what I have read (correct me if I am wrong) about using mysqldump, it
 doesn't do/support this process.

it does. You can keep as many backups as you want, and make them as frequently 
as you want. MySQL supports roll-forward of database journals IIRC, so if you 
set the DB to roll-forward logging, archive the logs to TSM and make frequent 
MySQL dumps, you can recover to any point in time. Of course, if your data is 
that valuable that you need to be able to recover to any specific point in 
time, investing in a commercial DB like db2 or Oracle makes sense.

API applications are all supported for usage on a TSM server. It's just that 
the code using the API is not supported, so that part is up to you. That is the 
way open source works

Zmanda most likely uses the TSM API as well, it's just a commercial 
implementation... So you pay for support rather than do it yourself.
-- 
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622


Re: Tsm client scheduler 6.2 with centos linux

2010-05-18 Thread Richard Sims
Gary - Signal 11 is a segfault, the result of a programming error.  Best to 
contact TSM Support.
You may be able to get around the segfault by tweaking various client options 
until the client no longer fails (e.g., Memoryefficient) as a temporary 
expedient.  Also assure that the client is not virtual-storage constrained.

   Richard Sims


Re: Tsm client scheduler 6.2 with centos linux

2010-05-18 Thread Remco Post
Downgrade to 5.5 or some other TSM client level that is not at major 6 ;-)

On 18 mei 2010, at 17:09, Lee, Gary D. wrote:

 Client version 6.2
 
 Best I can get for the linux version is as follows:
 
 Linux version 2.6.18-128.el5xen (mockbu...@builder10.centos.org) (gcc version 
 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Wed Jan 21 11:12:42 EST 2009
 
 When dsmc sched is run, about a minute later in the error log is the 
 following:
 
 
 05/17/2010 14:04:25 ANS2820E An interrupt has occurred. The current operation 
 will end and the
 client will shut down.
 05/17/2010 14:04:26 ANS0361I DIAG: Unknown thread, fatal error, signal 11
 
 This is not my machine, and I have no privs.  Any pointers will be helpful.
 Google turned up nothing, tsm help turned up nothing.
 
 
 Gary Lee
 Senior System Programmer
 Ball State University
 phone: 765-285-1310
 

-- 
Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622


Re: Unicode on UNIX

2010-05-18 Thread Michael Green
On Tue, May 18, 2010 at 5:41 PM, Bjoern Rackoll
bac...@rrz.uni-hamburg.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=663context=SSGSG7q1=linux+start+dsmcaduid=swg21240599loc=en_UScs=utf-8lang=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


Re: Win2000 tsm client

2010-05-18 Thread Andrew Raibeck
 Maybe it is too late, but we are using 5.4.1.2 on Windows 2000.

Grigori, you should be aware that this is not a supported configuration.
The last supported TSM client level for Windows 2000 is 5.3.6.x.

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Hartford/i...@ibmus
Internet e-mail: stor...@us.ibm.com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager


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

ADSM: Dist Stor Manager ADSM-L@vm.marist.edu wrote on 2010-05-18
11:49:40:

 From: Grigori Solonovitch grigori.solonovi...@ahliunited.com
 To: ADSM-L@vm.marist.edu
 Date: 2010-05-18 13:08
 Subject: Re: Win2000 tsm client
 Sent by: ADSM: Dist Stor Manager ADSM-L@vm.marist.edu

 Maybe it is too late, but we are using 5.4.1.2 on Windows 2000.


Re: Win2000 tsm client

2010-05-18 Thread Andrew Raibeck
I should also mention that it is not easy to back down to 5.3.6.x. To do
that, you would have to uninstall the 5.4 client first, then install
5.3.6.x. In addition, you will not be able to restore files backed up with
the 5.4 client; you will get an error message saying that the object has an
unknown format, or something like that. The simplest way around this is to
rename the existing file spaces to something different, then start with
fresh backups. You can keep the old file spaces around as long as you might
need to restore something from them, after which they can be deleted.

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Hartford/i...@ibmus
Internet e-mail: stor...@us.ibm.com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager


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

ADSM: Dist Stor Manager ADSM-L@vm.marist.edu wrote on 2010-05-18
13:14:49:

 From: Andrew Raibeck/Hartford/i...@ibmus
 To: ADSM-L@vm.marist.edu
 Date: 2010-05-18 13:16
 Subject: Re: Win2000 tsm client
 Sent by: ADSM: Dist Stor Manager ADSM-L@vm.marist.edu

  Maybe it is too late, but we are using 5.4.1.2 on Windows 2000.

 Grigori, you should be aware that this is not a supported configuration.
 The last supported TSM client level for Windows 2000 is 5.3.6.x.

 Andy Raibeck
 IBM Software Group
 Tivoli Storage Manager Client Product Development
 Level 3 Team Lead
 Internal Notes e-mail: Andrew Raibeck/Hartford/i...@ibmus
 Internet e-mail: stor...@us.ibm.com

 IBM Tivoli Storage Manager support web page:
 http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/
 Tivoli_Storage_Manager


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

 ADSM: Dist Stor Manager ADSM-L@vm.marist.edu wrote on 2010-05-18
 11:49:40:

  From: Grigori Solonovitch grigori.solonovi...@ahliunited.com
  To: ADSM-L@vm.marist.edu
  Date: 2010-05-18 13:08
  Subject: Re: Win2000 tsm client
  Sent by: ADSM: Dist Stor Manager ADSM-L@vm.marist.edu
 
  Maybe it is too late, but we are using 5.4.1.2 on Windows 2000.

Re: Unicode on UNIX

2010-05-18 Thread km
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

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.

-km

On 18/05, Fred Johanson 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


 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 Johanson
 TSM Administrator
 University of Chicago

 773-702-8464


Re: Unicode on UNIX

2010-05-18 Thread Michael Green
On Tue, May 18, 2010 at 10:49 PM, km k...@grogg.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


Re: Unicode on UNIX

2010-05-18 Thread Leandro Mazur
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
scriptsomething 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 mishagr...@gmail.com wrote:

 On Tue, May 18, 2010 at 10:49 PM, km k...@grogg.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


Re: Unicode on UNIX

2010-05-18 Thread km
On 19/05, Michael Green wrote:
 On Tue, May 18, 2010 at 10:49 PM, km k...@grogg.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?

You should not change it for the sole purpose of backups but rather the
system locale should (YMMV) match what is being used on the system. This is
very common in non english speaking countries and fully supported with UTF-8
since atleast the release of RHEL 4. So yes, I am.

  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.

Wasn't that what the OP was saying, that the locale did not exist? Atleast
that is what I interpret this as:

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.

This looks to me like the en_US locale is borked, which is part of
glibc-common. Maybe it was a hypothetical question. My bad in that case.

 I challenge anyone to show that it works for him/her in any version of
 RHEL or SLES.

The system i18n settings are sourced by rc.sysinit before either inittab or
any of the runlevel scripts are run so in theory everything should inherit
it correctly. I will check this tomorrow.

  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

I totally agree with this. A very common problem is servers with
filenames in different locales on the same server, for example software
repositories or file shares for multiple countries/languages.

-km


Re: Unicode on UNIX

2010-05-18 Thread Robert Clark
If you lie down with dogs, you get up with fleas. You pick a few distros,
and expect TSM to fix locale issues?

I've seen interactive backups fail, as some user's home directory was
missing a NULL and the locale in effect was en_US-UTF8 or something
similar.

Well, I guess it beats trying to backup a Netware volume that is shared by
Windows and Macintosh clients.

[RC]



From:
Michael Green mishagr...@gmail.com
To:
ADSM-L@VM.MARIST.EDU
Date:
05/18/2010 02:03 PM
Subject:
Re: [ADSM-L] Unicode on UNIX
Sent by:
ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



On Tue, May 18, 2010 at 10:49 PM, km k...@grogg.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



U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.



-


Re: Unicode on UNIX

2010-05-18 Thread Michael Green
On Wed, May 19, 2010 at 2:20 AM, km k...@grogg.org wrote:

 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?

 You should not change it for the sole purpose of backups but rather the
 system locale should (YMMV) match what is being used on the system. This is
 very common in non english speaking countries and fully supported with UTF-8
 since atleast the release of RHEL 4. So yes, I am.

I think it's rather hard to predict the complications that may arise
from changing locale. Some applications might exhibit adverse effects
if locale is changed to something other than what the app was tested
with. In many occasions it's not feasible to know what locale is
required on a workstation. I work at an academic institution in a
non-English speaking country. Among our researchers and students
community we have many individuals who are fluent in more than two
languages. For example we have a student from Russia who, besides his
native tongue, is also fluent in English and Hebrew. It's not uncommon
to find files on his computer disk that have names in any of these
three languages. Which locale should I set for him? What locale should
be set on an Novell iFolder file server with an NSS volume that has
files in all kinds of languages? Do I need now to start managing
locales for hundreds of servers and workstations in order to satisfy
TSM's whims?

 I challenge anyone to show that it works for him/her in any version of
 RHEL or SLES.

 The system i18n settings are sourced by rc.sysinit before either inittab or
 any of the runlevel scripts are run so in theory everything should inherit
 it correctly. I will check this tomorrow.

I'll try that too.
--
Warm regards,
Michael Green


Re: Win2000 tsm client

2010-05-18 Thread Grigori Solonovitch
I think you are right, but we were pushed out from 5.3.6.X by autitors because 
of some vulnerabilities, which are fixed in 5.4.1.2 (not in 5.4.1.1).
Fortunately, it was possible to upgrade client to 5.4.1.2 (5.4.1.3 says not 
supported under 2000).
We have tested 5.4.1.2 carefully and found it working. Test included normal 
backup/restores and Windows recovery by TBMR 6.1.1.
So we are using 5.4.1.2 on all 4 remaining Windows 2000 servers.


From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Andrew 
Raibeck [stor...@us.ibm.com]
Sent: Tuesday, May 18, 2010 8:14 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Win2000 tsm client

 Maybe it is too late, but we are using 5.4.1.2 on Windows 2000.

Grigori, you should be aware that this is not a supported configuration.
The last supported TSM client level for Windows 2000 is 5.3.6.x.

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Hartford/i...@ibmus
Internet e-mail: stor...@us.ibm.com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager


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

ADSM: Dist Stor Manager ADSM-L@vm.marist.edu wrote on 2010-05-18
11:49:40:

 From: Grigori Solonovitch grigori.solonovi...@ahliunited.com
 To: ADSM-L@vm.marist.edu
 Date: 2010-05-18 13:08
 Subject: Re: Win2000 tsm client
 Sent by: ADSM: Dist Stor Manager ADSM-L@vm.marist.edu

 Maybe it is too late, but we are using 5.4.1.2 on Windows 2000.

Please consider the environment before printing this Email.

CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail 
message and any attachments hereto may be legally privileged and confidential. 
The information is intended only for the recipient(s) named in this message. If 
you are not the intended recipient you are notified that any use, disclosure, 
copying or distribution is prohibited. If you have received this in error 
please contact the sender and delete this message and any attachments from your 
computer system. We do not guarantee that this message or any attachment to it 
is secure or free from errors, computer viruses or other conditions that may 
damage or interfere with data, hardware or software.


Re: what filespaces are candidate for migration?

2010-05-18 Thread Mehdi Salehi
That was a misunderstanding, David.

Regards,
Mehdi