Re: 8.1.15 Linux client update causing failures

[Zoltan Forray]

Good to hear. I opened a ticket as Andy recommended but have not heard
anything about an available eFix.

FWIW,  I seemed to have caused these issues when I re-activated replication
on one of my servers.  This server was originally using virtual volumes to
create offsite backups (trying to move away from tapes since we will be
getting rid of magnetic tape/libraries by the time we move to a new
datacenter by the end of 2023).  However, we started having weekly
cores/crashes on this server.  At first IBM gave us an eFix (8.1.14.102)
but we continued to have weekly crashes and when IBM analyzed our latest
crash, they said they discovered a new problem caused by RECONCILE VOLUMES
which we use daily on these virtual volumes/server.

On Wed, Jul 20, 2022 at 4:58 AM Loon, Eric van (ITOP DI) - KLM <
eric-van.l...@klm.com> wrote:

> Hi everybody,
>
> I tested a fix I received from IBM this morning, which seems to be working
> OK. So let's hope IBM will release a 8.1.15.100 soon.
>
> Kind regards,
> Eric van Loon
> Core Infra
>
> -Original Message-
> From: ADSM: Dist Stor Manager  On Behalf Of Andrew
> Raibeck
> Sent: dinsdag 19 juli 2022 22:46
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: 8.1.15 Linux client update causing failures
>
> Hi, the following flash is published for this issue.
>
> https://www.ibm.com/support/pages/node/6605073
>
> Best regards,
>
> Andy
>
> Andrew Raibeck
> IBM Spectrum Protect Level 3
> IBM Systems, Storage
> stor...@us.ibm.com
>
> IBM
>
> -Original Message-
> From: ADSM: Dist Stor Manager  On Behalf Of Andrew
> Raibeck
> Sent: Tuesday, 19 July, 2022 07:05
> To: ADSM-L@VM.MARIST.EDU
> Subject: [EXTERNAL] Re: 8.1.15 Linux client update causing failures
>
> Hi Michael,
>
> The APAR is IT41452. It is not yet visible on the web, but it should be in
> the next day or two. Then, until the APAR is closed, you need to log in
> with your IBM ID to view it.
>
> Best regards,
>
> Andy
>
> Andrew Raibeck
> IBM Spectrum Protect Level 3
> IBM Systems, Storage
> stor...@us.ibm.com
>
> IBM
>
> -Original Message-
> From: ADSM: Dist Stor Manager  On Behalf Of Michael
> Roesch
> Sent: Tuesday, 19 July, 2022 05:30
> To: ADSM-L@VM.MARIST.EDU
> Subject: [EXTERNAL] Re: 8.1.15 Linux client update causing failures
>
> Hi all,
>
> Did IBM already create an APAR for this issue? We're currently holding off
> on the 8.1.15.0 client rollout and it would be great to know if IBM's
> initial assumptions have proven true, which would mean we're not affected
> b/c we don't use replication.
>
> Thank you
>
> Kind regards
> Michael Roesch
>
> On Thu, Jul 14, 2022 at 2:29 PM Andrew Raibeck  wrote:
>
> > Hi Zoltan,
> >
> > The problem I refer to occurs immediately while starting the client.
> > Even by merely running "dsmc", it crashes. Is that the case for you?
> > Or does the operation run for a period of time, and then crash? If the
> > problem occurs on a particular client, does it always occur? Or is it
> intermittent?
> >
> > If you have gdb installed on a representative system, then try getting
> > a stack trace.
> >
> > 1. Start gdb:
> >
> > gdb /opt/tivoli/tsm/client/ba/bin/dsmc core_file_name
> >
> > where "core_file_name" is the name of the core.
> >
> > 2. In the "(gdb)" prompt, type these commands:
> >
> > bt
> > q
> >
> > The first command shows the backtrace (which is the part of interest)
> > and the second command quits the debugger.
> >
> > If you do not have a core file, then it is probably because the core
> > file ulimit is too small or 0. Run "ulimit -c" to display the current
> value.
> > Then run "ulimit -c unlimited", reproduce the issue, and get the
> > backtrace as I previously mentioned. After, you can set the ulimit
> > back to its original value and delete the core file.
> >
> > The following article includes an alternative (and more comprehensive)
> > doc
> > collection:
> >
> >
> > https://www.ibm.com/support/pages/collecting-data-spectrum-protect-cli
> > ent-crash-linux
> >
> > The following is a representative backtrace of the problem I referred to.
> >
> > (gdb) bt
> > #0  0x7f04e2c06387 in raise () from /lib64/libc.so.6
> > #1  0x7f04e2c07a78 in abort () from /lib64/libc.so.6
> > #2  0x00712a74 in psTrapHandler(int) ()
> > #3  
> > #4  0x7f04e2c06387 in raise () from /lib64/libc.so.6
> > #5  0x7f04e2c07a78 in abort () from /lib64/libc.so.6
> > #6  0x7f04e2c48ed

Re: 8.1.15 Linux client update causing failures

[Andrew Raibeck]

Hi, the following flash is published for this issue.

https://www.ibm.com/support/pages/node/6605073

Best regards,

Andy

Andrew Raibeck
IBM Spectrum Protect Level 3
IBM Systems, Storage
stor...@us.ibm.com

IBM

-Original Message-
From: ADSM: Dist Stor Manager  On Behalf Of Andrew Raibeck
Sent: Tuesday, 19 July, 2022 07:05
To: ADSM-L@VM.MARIST.EDU
Subject: [EXTERNAL] Re: 8.1.15 Linux client update causing failures

Hi Michael,

The APAR is IT41452. It is not yet visible on the web, but it should be in the 
next day or two. Then, until the APAR is closed, you need to log in with your 
IBM ID to view it.

Best regards,

Andy

Andrew Raibeck
IBM Spectrum Protect Level 3
IBM Systems, Storage
stor...@us.ibm.com

IBM

-Original Message-
From: ADSM: Dist Stor Manager  On Behalf Of Michael Roesch
Sent: Tuesday, 19 July, 2022 05:30
To: ADSM-L@VM.MARIST.EDU
Subject: [EXTERNAL] Re: 8.1.15 Linux client update causing failures

Hi all,

Did IBM already create an APAR for this issue? We're currently holding off on 
the 8.1.15.0 client rollout and it would be great to know if IBM's initial 
assumptions have proven true, which would mean we're not affected b/c we don't 
use replication.

Thank you

Kind regards
Michael Roesch

On Thu, Jul 14, 2022 at 2:29 PM Andrew Raibeck  wrote:

> Hi Zoltan,
>
> The problem I refer to occurs immediately while starting the client. 
> Even by merely running "dsmc", it crashes. Is that the case for you? 
> Or does the operation run for a period of time, and then crash? If the 
> problem occurs on a particular client, does it always occur? Or is it 
> intermittent?
>
> If you have gdb installed on a representative system, then try getting 
> a stack trace.
>
> 1. Start gdb:
>
> gdb /opt/tivoli/tsm/client/ba/bin/dsmc core_file_name
>
> where "core_file_name" is the name of the core.
>
> 2. In the "(gdb)" prompt, type these commands:
>
> bt
> q
>
> The first command shows the backtrace (which is the part of interest) 
> and the second command quits the debugger.
>
> If you do not have a core file, then it is probably because the core 
> file ulimit is too small or 0. Run "ulimit -c" to display the current value.
> Then run "ulimit -c unlimited", reproduce the issue, and get the 
> backtrace as I previously mentioned. After, you can set the ulimit 
> back to its original value and delete the core file.
>
> The following article includes an alternative (and more comprehensive) 
> doc
> collection:
>
>
> https://www.ibm.com/support/pages/collecting-data-spectrum-protect-cli
> ent-crash-linux
>
> The following is a representative backtrace of the problem I referred to.
>
> (gdb) bt
> #0  0x7f04e2c06387 in raise () from /lib64/libc.so.6
> #1  0x7f04e2c07a78 in abort () from /lib64/libc.so.6
> #2  0x00712a74 in psTrapHandler(int) ()
> #3  
> #4  0x7f04e2c06387 in raise () from /lib64/libc.so.6
> #5  0x7f04e2c07a78 in abort () from /lib64/libc.so.6
> #6  0x7f04e2c48ed7 in __libc_message () from /lib64/libc.so.6
> #7  0x7f04e2c51299 in _int_free () from /lib64/libc.so.6
> #8  0x7f04e2c3e1b7 in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6
> #9  0x006efe2f in clientOptions::optSaveReplConnInfo() ()
> #10 0x0068103f in cuSignOnEResp(Sess_o*) ()
> #11 0x00652b75 in scSignOnTheSession(Sess_o*) ()
> #12 0x00658ce3 in NegotiateSession(Sess_o*) ()
> #13 0x00653648 in OpenSess(Sess_o*, bool) ()
> #14 0x00654ad0 in Logon(Sess_o*) ()
> #15 0x00656c36 in CheckSession(Sess_o*, sessLoadPolicy_t) ()
> #16 0x0043e5fe in dscInit(int, char**, cliType_t) ()
> #17 0x0043eb5b in dscmain(int, char**) ()
> #18 0x0043b3fa in main ()
>
> If your backtrace differs, or you want further assistance diagnosing 
> your particular instance of the crash, then please open a support case with 
> IBM.
> If you want, you can privately email your case number to me, for my 
> awareness.
>
> If you open a case with IBM, it will help support "hit the ground running"
> if you can provide some information up front.
>
> 1. Temporarily enable core file creation.
>
> 2. Add these options to configure the client for SERVICE tracing:
>
> TRACEFLAGS SERVICE
> TRACEFILE /some_path/dsmc_trace.txt
>
> (I'm sure you have done this befoe.)
>
> 3. Reproduce the problem.
>
> 4. Collect the diagnostic data as described in this article:
>
>
> https://www.ibm.com/support/pages/collecting-data-spectrum-protect-cli
> ent-crash-linux
>
> 5. Put the core file ulimit setting back to its original value.
>
> 6. Open a case with IBM and provide the service trace, dsmc output (or 
> dsmsch

Re: 8.1.15 Linux client update causing failures

[Michael Roesch]

Thank you, Andy

On Thu, Jul 14, 2022 at 12:39 PM Andrew Raibeck  wrote:

> Hi,
>
> Initial assessment is that clients that meet all of the following
> conditions are affected:
>
> - The client is Linux (any architecture), including backup-archive client
> and API applications
> - The client is  configured for automatic failover to a replication server
>
> Note that the preceding information is subject to change as we learn more.
>
> Kindest regards,
>
> Andy
>
> Andrew Raibeck
> IBM Spectrum Protect Level 3
> IBM Systems, Storage
> stor...@us.ibm.com
>
> IBM
>
> -Original Message-
> From: ADSM: Dist Stor Manager  On Behalf Of Michael
> Roesch
> Sent: Thursday, 14 July, 2022 06:23
> To: ADSM-L@VM.MARIST.EDU
> Subject: [EXTERNAL] Re: 8.1.15 Linux client update causing failures
>
> Hi,
>
> Does the client for AIX show this problem as well? Did this happen on x64
> Linux or also on PPC?
>
> Kind regards
> Michael Roesch
>
> On Wed, Jul 13, 2022 at 4:19 AM Saravanan Palanisamy <
> evergreen.sa...@gmail.com> wrote:
>
> > So far We don’t see any issues in windows. All scheduled backups are
> > successful.
> >
> > Regards
> > Sarav
> > +65 9857 8665
> >
> >
> > > On 13 Jul 2022, at 9:00 AM, Tom Alverson 
> wrote:
> > >
> > > Is the windows client safe for this version?
> > >
> > >
> > >> On Tue, Jul 12, 2022, 7:06 PM Saravanan Palanisamy <
> > >> evergreen.sa...@gmail.com> wrote:
> > >>
> > >> Hi Zoltan
> > >>
> > >> Yes we have also faced same issue and IBM support confirmed they
> > >> will
> > open
> > >> new APAR. We have reverted all clients v8.1.14 to address the issue.
> > >>
> > >> Regards
> > >> Sarav
> > >> +65 9857 8665
> > >>
> > >>
> > >>>> On 13 Jul 2022, at 2:31 AM, Del Hoobler  wrote:
> > >>>
> > >>> Hi Zoltan,
> > >>>
> > >>> IBM knows about this ... and it's being actively worked.
> > >>>
> > >>> I am sure it will be mitigated soon.
> > >>>
> > >>> Feel free to open a fresh IBM Support case so you can be quickly
> > >> notified once it is fixed.
> > >>>
> > >>>
> > >>> Del
> > >>>
> > >>> 
> > >>> From: ADSM: Dist Stor Manager  on behalf of
> > >> Zoltan Forray 
> > >>> Sent: Tuesday, July 12, 2022 1:56 PM
> > >>> To: ADSM-L@VM.MARIST.EDU 
> > >>> Subject: [EXTERNAL] 8.1.15 Linux client update causing failures
> > >>>
> > >>> We started rolling out the 8.1.15 Linux client via apogee and many
> > >> clients
> > >>> are failing with:
> > >>>
> > >>> *** Error in `dsmc': double free or corruption (!prev):
> > >> 0x02baf970
> > >>> ***
> > >>>
> > >>> The only matching Google hit goes back to a V7 client issue - long
> > fixed.
> > >>>
> > >>> At first I thought it might be related to a Linux flavor (we run
> > Rocky8,
> > >>> CentOS 7.1/8, RHEL 7/8) but I don't see a pattern.  All of these
> > servers
> > >>> are upgrading from 8.1.14 and downleveling the client to 8.1.14
> > >>> fixes
> > >> this.
> > >>>
> > >>> Anyone else seeing this?
> > >>>
> > >>> FWIW, I could swear that during one of my many Google searches I
> > >>> saw a reference to 8.1.15.2 (eFix?) but now I can't find it again.
> > >>> --
> > >>> *Zoltan Forray*
> > >>> Enterprise Backup Administrator
> > >>> VMware Systems Administrator
> > >>> Enterprise Compute & Storage Platforms Team VCU Infrastructure
> > >>> Services
> > >>> www.ucc.vcu.edu > >>> __www.ucc.vcu.edu=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Ij6DLy1l7wDp
> > >>> CbTfcDkLC_KknvhyGdCy_RnAGnhV37I=lx_phvPLtz3INd_W8oJ4eGdfN5WYsItt
> > >>> NeFE_AVOLSP0Mp2Rq34RX6Nb9ogoyHYd=e_k1hOLaA6N1PWcNH0bBFZaIJtG1FAb
> > >>> mQyN9dy5iR6c= > 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
> > >>> INVALID URI REMOVED
> > >>> du_=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Ij6DLy1l7wDpCbTfcDkLC_Kknv
> > >>> hyGdCy_RnAGnhV37I=lx_phvPLtz3INd_W8oJ4eGdfN5WYsIttNeFE_AVOLSP0Mp
> > >>> 2Rq34RX6Nb9ogoyHYd=VS499q-uVPEP-6-QrjIgicZ_oLB4kvyLNBmMlJeWBEI
> > >>> =
> > >>>  > >>> questionpro.com=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Ij6DLy1l7wDpCb
> > >>> TfcDkLC_KknvhyGdCy_RnAGnhV37I=lx_phvPLtz3INd_W8oJ4eGdfN5WYsIttNe
> > >>> FE_AVOLSP0Mp2Rq34RX6Nb9ogoyHYd=BqXWlinKYJb1mlgHqBJJz4HitGo2CCEEt
> > >>> UAK46yC9F4=  >
> > >>
> >
>

Re: 8.1.15 Linux client update causing failures

[Andrew Raibeck]

Hi Michael,

The APAR is IT41452. It is not yet visible on the web, but it should be in the 
next day or two. Then, until the APAR is closed, you need to log in with your 
IBM ID to view it.

Best regards,

Andy

Andrew Raibeck
IBM Spectrum Protect Level 3
IBM Systems, Storage
stor...@us.ibm.com

IBM

-Original Message-
From: ADSM: Dist Stor Manager  On Behalf Of Michael Roesch
Sent: Tuesday, 19 July, 2022 05:30
To: ADSM-L@VM.MARIST.EDU
Subject: [EXTERNAL] Re: 8.1.15 Linux client update causing failures

Hi all,

Did IBM already create an APAR for this issue? We're currently holding off on 
the 8.1.15.0 client rollout and it would be great to know if IBM's initial 
assumptions have proven true, which would mean we're not affected b/c we don't 
use replication.

Thank you

Kind regards
Michael Roesch

On Thu, Jul 14, 2022 at 2:29 PM Andrew Raibeck  wrote:

> Hi Zoltan,
>
> The problem I refer to occurs immediately while starting the client. 
> Even by merely running "dsmc", it crashes. Is that the case for you? 
> Or does the operation run for a period of time, and then crash? If the 
> problem occurs on a particular client, does it always occur? Or is it 
> intermittent?
>
> If you have gdb installed on a representative system, then try getting 
> a stack trace.
>
> 1. Start gdb:
>
> gdb /opt/tivoli/tsm/client/ba/bin/dsmc core_file_name
>
> where "core_file_name" is the name of the core.
>
> 2. In the "(gdb)" prompt, type these commands:
>
> bt
> q
>
> The first command shows the backtrace (which is the part of interest) 
> and the second command quits the debugger.
>
> If you do not have a core file, then it is probably because the core 
> file ulimit is too small or 0. Run "ulimit -c" to display the current value.
> Then run "ulimit -c unlimited", reproduce the issue, and get the 
> backtrace as I previously mentioned. After, you can set the ulimit 
> back to its original value and delete the core file.
>
> The following article includes an alternative (and more comprehensive) 
> doc
> collection:
>
>
> https://www.ibm.com/support/pages/collecting-data-spectrum-protect-cli
> ent-crash-linux
>
> The following is a representative backtrace of the problem I referred to.
>
> (gdb) bt
> #0  0x7f04e2c06387 in raise () from /lib64/libc.so.6
> #1  0x7f04e2c07a78 in abort () from /lib64/libc.so.6
> #2  0x00712a74 in psTrapHandler(int) ()
> #3  
> #4  0x7f04e2c06387 in raise () from /lib64/libc.so.6
> #5  0x7f04e2c07a78 in abort () from /lib64/libc.so.6
> #6  0x7f04e2c48ed7 in __libc_message () from /lib64/libc.so.6
> #7  0x7f04e2c51299 in _int_free () from /lib64/libc.so.6
> #8  0x7f04e2c3e1b7 in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6
> #9  0x006efe2f in clientOptions::optSaveReplConnInfo() ()
> #10 0x0068103f in cuSignOnEResp(Sess_o*) ()
> #11 0x00652b75 in scSignOnTheSession(Sess_o*) ()
> #12 0x00658ce3 in NegotiateSession(Sess_o*) ()
> #13 0x00653648 in OpenSess(Sess_o*, bool) ()
> #14 0x00654ad0 in Logon(Sess_o*) ()
> #15 0x00656c36 in CheckSession(Sess_o*, sessLoadPolicy_t) ()
> #16 0x0043e5fe in dscInit(int, char**, cliType_t) ()
> #17 0x0043eb5b in dscmain(int, char**) ()
> #18 0x0043b3fa in main ()
>
> If your backtrace differs, or you want further assistance diagnosing 
> your particular instance of the crash, then please open a support case with 
> IBM.
> If you want, you can privately email your case number to me, for my 
> awareness.
>
> If you open a case with IBM, it will help support "hit the ground running"
> if you can provide some information up front.
>
> 1. Temporarily enable core file creation.
>
> 2. Add these options to configure the client for SERVICE tracing:
>
> TRACEFLAGS SERVICE
> TRACEFILE /some_path/dsmc_trace.txt
>
> (I'm sure you have done this befoe.)
>
> 3. Reproduce the problem.
>
> 4. Collect the diagnostic data as described in this article:
>
>
> https://www.ibm.com/support/pages/collecting-data-spectrum-protect-cli
> ent-crash-linux
>
> 5. Put the core file ulimit setting back to its original value.
>
> 6. Open a case with IBM and provide the service trace, dsmc output (or 
> dsmsched.log if you schedule the operation), dsmerror.log, and the 
> files collected from the article of step 4.
>
> You can remove the core file after the data is sent to IBM.
>
> Regards,
>
> Andrew Raibeck
> IBM Spectrum Protect Level 3
> IBM Systems, Storage
> stor...@us.ibm.com
>
> IBM
>
> -Original Message-
> From: ADSM: Dist Stor Manager  On Behalf Of 
> Zoltan Fo

Re: 8.1.15 Linux client update causing failures

[Michael Roesch]

Hi all,

Did IBM already create an APAR for this issue? We're currently holding off
on the 8.1.15.0 client rollout and it would be great to know if IBM's
initial assumptions have proven true, which would mean we're not affected
b/c we don't use replication.

Thank you

Kind regards
Michael Roesch

On Thu, Jul 14, 2022 at 2:29 PM Andrew Raibeck  wrote:

> Hi Zoltan,
>
> The problem I refer to occurs immediately while starting the client. Even
> by merely running "dsmc", it crashes. Is that the case for you? Or does the
> operation run for a period of time, and then crash? If the problem occurs
> on a particular client, does it always occur? Or is it intermittent?
>
> If you have gdb installed on a representative system, then try getting a
> stack trace.
>
> 1. Start gdb:
>
> gdb /opt/tivoli/tsm/client/ba/bin/dsmc core_file_name
>
> where "core_file_name" is the name of the core.
>
> 2. In the "(gdb)" prompt, type these commands:
>
> bt
> q
>
> The first command shows the backtrace (which is the part of interest) and
> the second command quits the debugger.
>
> If you do not have a core file, then it is probably because the core file
> ulimit is too small or 0. Run "ulimit -c" to display the current value.
> Then run "ulimit -c unlimited", reproduce the issue, and get the backtrace
> as I previously mentioned. After, you can set the ulimit back to its
> original value and delete the core file.
>
> The following article includes an alternative (and more comprehensive) doc
> collection:
>
>
> https://www.ibm.com/support/pages/collecting-data-spectrum-protect-client-crash-linux
>
> The following is a representative backtrace of the problem I referred to.
>
> (gdb) bt
> #0  0x7f04e2c06387 in raise () from /lib64/libc.so.6
> #1  0x7f04e2c07a78 in abort () from /lib64/libc.so.6
> #2  0x00712a74 in psTrapHandler(int) ()
> #3  
> #4  0x7f04e2c06387 in raise () from /lib64/libc.so.6
> #5  0x7f04e2c07a78 in abort () from /lib64/libc.so.6
> #6  0x7f04e2c48ed7 in __libc_message () from /lib64/libc.so.6
> #7  0x7f04e2c51299 in _int_free () from /lib64/libc.so.6
> #8  0x7f04e2c3e1b7 in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6
> #9  0x006efe2f in clientOptions::optSaveReplConnInfo() ()
> #10 0x0068103f in cuSignOnEResp(Sess_o*) ()
> #11 0x00652b75 in scSignOnTheSession(Sess_o*) ()
> #12 0x00658ce3 in NegotiateSession(Sess_o*) ()
> #13 0x00653648 in OpenSess(Sess_o*, bool) ()
> #14 0x00654ad0 in Logon(Sess_o*) ()
> #15 0x00656c36 in CheckSession(Sess_o*, sessLoadPolicy_t) ()
> #16 0x0043e5fe in dscInit(int, char**, cliType_t) ()
> #17 0x0043eb5b in dscmain(int, char**) ()
> #18 0x0043b3fa in main ()
>
> If your backtrace differs, or you want further assistance diagnosing your
> particular instance of the crash, then please open a support case with IBM.
> If you want, you can privately email your case number to me, for my
> awareness.
>
> If you open a case with IBM, it will help support "hit the ground running"
> if you can provide some information up front.
>
> 1. Temporarily enable core file creation.
>
> 2. Add these options to configure the client for SERVICE tracing:
>
> TRACEFLAGS SERVICE
> TRACEFILE /some_path/dsmc_trace.txt
>
> (I'm sure you have done this befoe.)
>
> 3. Reproduce the problem.
>
> 4. Collect the diagnostic data as described in this article:
>
>
> https://www.ibm.com/support/pages/collecting-data-spectrum-protect-client-crash-linux
>
> 5. Put the core file ulimit setting back to its original value.
>
> 6. Open a case with IBM and provide the service trace, dsmc output (or
> dsmsched.log if you schedule the operation), dsmerror.log, and the files
> collected from the article of step 4.
>
> You can remove the core file after the data is sent to IBM.
>
> Regards,
>
> Andrew Raibeck
> IBM Spectrum Protect Level 3
> IBM Systems, Storage
> stor...@us.ibm.com
>
> IBM
>
> -Original Message-
> From: ADSM: Dist Stor Manager  On Behalf Of Zoltan
> Forray
> Sent: Thursday, 14 July, 2022 08:04
> To: ADSM-L@VM.MARIST.EDU
> Subject: [EXTERNAL] Re: 8.1.15 Linux client update causing failures
>
> Andy,
>
> You said *"- The client is configured for automatic failover to a
> replication server"* but that doesn't jive with our situation/environment.
> Until recently, we have not run replication on any of our backups (offsite
> copies are to tape or virtual volumes on another ISP server) and disk
> backups are to non-container (FILE) storage. I queried our Linux admins 

Re: 8.1.15 Linux client update causing failures

[Andrew Raibeck]

Hi Zoltan,

The problem I refer to occurs immediately while starting the client. Even by 
merely running "dsmc", it crashes. Is that the case for you? Or does the 
operation run for a period of time, and then crash? If the problem occurs on a 
particular client, does it always occur? Or is it intermittent?

If you have gdb installed on a representative system, then try getting a stack 
trace. 

1. Start gdb:

gdb /opt/tivoli/tsm/client/ba/bin/dsmc core_file_name

where "core_file_name" is the name of the core.

2. In the "(gdb)" prompt, type these commands:

bt
q

The first command shows the backtrace (which is the part of interest) and the 
second command quits the debugger.

If you do not have a core file, then it is probably because the core file 
ulimit is too small or 0. Run "ulimit -c" to display the current value. Then 
run "ulimit -c unlimited", reproduce the issue, and get the backtrace as I 
previously mentioned. After, you can set the ulimit back to its original value 
and delete the core file.

The following article includes an alternative (and more comprehensive) doc 
collection:

https://www.ibm.com/support/pages/collecting-data-spectrum-protect-client-crash-linux

The following is a representative backtrace of the problem I referred to.

(gdb) bt
#0  0x7f04e2c06387 in raise () from /lib64/libc.so.6
#1  0x7f04e2c07a78 in abort () from /lib64/libc.so.6
#2  0x00712a74 in psTrapHandler(int) ()
#3  
#4  0x7f04e2c06387 in raise () from /lib64/libc.so.6
#5  0x7f04e2c07a78 in abort () from /lib64/libc.so.6
#6  0x7f04e2c48ed7 in __libc_message () from /lib64/libc.so.6
#7  0x7f04e2c51299 in _int_free () from /lib64/libc.so.6
#8  0x7f04e2c3e1b7 in fclose@@GLIBC_2.2.5 () from /lib64/libc.so.6
#9  0x006efe2f in clientOptions::optSaveReplConnInfo() ()
#10 0x0068103f in cuSignOnEResp(Sess_o*) ()
#11 0x00652b75 in scSignOnTheSession(Sess_o*) ()
#12 0x00658ce3 in NegotiateSession(Sess_o*) ()
#13 0x00653648 in OpenSess(Sess_o*, bool) ()
#14 0x00654ad0 in Logon(Sess_o*) ()
#15 0x00656c36 in CheckSession(Sess_o*, sessLoadPolicy_t) ()
#16 0x0043e5fe in dscInit(int, char**, cliType_t) ()
#17 0x0043eb5b in dscmain(int, char**) ()
#18 0x0043b3fa in main ()

If your backtrace differs, or you want further assistance diagnosing your 
particular instance of the crash, then please open a support case with IBM. If 
you want, you can privately email your case number to me, for my awareness.

If you open a case with IBM, it will help support "hit the ground running" if 
you can provide some information up front.

1. Temporarily enable core file creation.

2. Add these options to configure the client for SERVICE tracing:

TRACEFLAGS SERVICE
TRACEFILE /some_path/dsmc_trace.txt

(I'm sure you have done this befoe.)

3. Reproduce the problem.

4. Collect the diagnostic data as described in this article:

https://www.ibm.com/support/pages/collecting-data-spectrum-protect-client-crash-linux

5. Put the core file ulimit setting back to its original value.

6. Open a case with IBM and provide the service trace, dsmc output (or 
dsmsched.log if you schedule the operation), dsmerror.log, and the files 
collected from the article of step 4.

You can remove the core file after the data is sent to IBM.

Regards,

Andrew Raibeck
IBM Spectrum Protect Level 3
IBM Systems, Storage
stor...@us.ibm.com

IBM

-Original Message-
From: ADSM: Dist Stor Manager  On Behalf Of Zoltan Forray
Sent: Thursday, 14 July, 2022 08:04
To: ADSM-L@VM.MARIST.EDU
Subject: [EXTERNAL] Re: 8.1.15 Linux client update causing failures

Andy,

You said *"- The client is configured for automatic failover to a replication 
server"* but that doesn't jive with our situation/environment.
Until recently, we have not run replication on any of our backups (offsite 
copies are to tape or virtual volumes on another ISP server) and disk backups 
are to non-container (FILE) storage. I queried our Linux admins and these 
failures are all over the place - not just for the few we recently started 
replicating.

On Thu, Jul 14, 2022 at 6:39 AM Andrew Raibeck  wrote:

> Hi,
>
> Initial assessment is that clients that meet all of the following 
> conditions are affected:
>
> - The client is Linux (any architecture), including backup-archive 
> client and API applications
> - The client is  configured for automatic failover to a replication 
> server
>
> Note that the preceding information is subject to change as we learn more.
>
> Kindest regards,
>
> Andy
>
> Andrew Raibeck
> IBM Spectrum Protect Level 3
> IBM Systems, Storage
> stor...@us.ibm.com
>
> IBM
>
> -Original Message-
> From: ADSM: Dist Stor Manager  On Behalf Of 
> Michael Roesch
> Sent: Thursday, 14 July, 2022 06:23
> To: ADS

Re: 8.1.15 Linux client update causing failures

[Zoltan Forray]

Andy,

You said *"- The client is configured for automatic failover to a
replication server"* but that doesn't jive with our situation/environment.
Until recently, we have not run replication on any of our backups (offsite
copies are to tape or virtual volumes on another ISP server) and
disk backups are to non-container (FILE) storage. I queried our Linux
admins and these failures are all over the place - not just for the few we
recently started replicating.

On Thu, Jul 14, 2022 at 6:39 AM Andrew Raibeck  wrote:

> Hi,
>
> Initial assessment is that clients that meet all of the following
> conditions are affected:
>
> - The client is Linux (any architecture), including backup-archive client
> and API applications
> - The client is  configured for automatic failover to a replication server
>
> Note that the preceding information is subject to change as we learn more.
>
> Kindest regards,
>
> Andy
>
> Andrew Raibeck
> IBM Spectrum Protect Level 3
> IBM Systems, Storage
> stor...@us.ibm.com
>
> IBM
>
> -Original Message-
> From: ADSM: Dist Stor Manager  On Behalf Of Michael
> Roesch
> Sent: Thursday, 14 July, 2022 06:23
> To: ADSM-L@VM.MARIST.EDU
> Subject: [EXTERNAL] Re: 8.1.15 Linux client update causing failures
>
> Hi,
>
> Does the client for AIX show this problem as well? Did this happen on x64
> Linux or also on PPC?
>
> Kind regards
> Michael Roesch
>
> On Wed, Jul 13, 2022 at 4:19 AM Saravanan Palanisamy <
> evergreen.sa...@gmail.com> wrote:
>
> > So far We don’t see any issues in windows. All scheduled backups are
> > successful.
> >
> > Regards
> > Sarav
> > +65 9857 8665
> >
> >
> > > On 13 Jul 2022, at 9:00 AM, Tom Alverson 
> wrote:
> > >
> > > Is the windows client safe for this version?
> > >
> > >
> > >> On Tue, Jul 12, 2022, 7:06 PM Saravanan Palanisamy <
> > >> evergreen.sa...@gmail.com> wrote:
> > >>
> > >> Hi Zoltan
> > >>
> > >> Yes we have also faced same issue and IBM support confirmed they
> > >> will
> > open
> > >> new APAR. We have reverted all clients v8.1.14 to address the issue.
> > >>
> > >> Regards
> > >> Sarav
> > >> +65 9857 8665
> > >>
> > >>
> > >>>> On 13 Jul 2022, at 2:31 AM, Del Hoobler  wrote:
> > >>>
> > >>> Hi Zoltan,
> > >>>
> > >>> IBM knows about this ... and it's being actively worked.
> > >>>
> > >>> I am sure it will be mitigated soon.
> > >>>
> > >>> Feel free to open a fresh IBM Support case so you can be quickly
> > >> notified once it is fixed.
> > >>>
> > >>>
> > >>> Del
> > >>>
> > >>> 
> > >>> From: ADSM: Dist Stor Manager  on behalf of
> > >> Zoltan Forray 
> > >>> Sent: Tuesday, July 12, 2022 1:56 PM
> > >>> To: ADSM-L@VM.MARIST.EDU 
> > >>> Subject: [EXTERNAL] 8.1.15 Linux client update causing failures
> > >>>
> > >>> We started rolling out the 8.1.15 Linux client via apogee and many
> > >> clients
> > >>> are failing with:
> > >>>
> > >>> *** Error in `dsmc': double free or corruption (!prev):
> > >> 0x02baf970
> > >>> ***
> > >>>
> > >>> The only matching Google hit goes back to a V7 client issue - long
> > fixed.
> > >>>
> > >>> At first I thought it might be related to a Linux flavor (we run
> > Rocky8,
> > >>> CentOS 7.1/8, RHEL 7/8) but I don't see a pattern.  All of these
> > servers
> > >>> are upgrading from 8.1.14 and downleveling the client to 8.1.14
> > >>> fixes
> > >> this.
> > >>>
> > >>> Anyone else seeing this?
> > >>>
> > >>> FWIW, I could swear that during one of my many Google searches I
> > >>> saw a reference to 8.1.15.2 (eFix?) but now I can't find it again.
> > >>> --
> > >>> *Zoltan Forray*
> > >>> Enterprise Backup Administrator
> > >>> VMware Systems Administrator
> > >>> Enterprise Compute & Storage Platforms Team VCU Infrastructure
> > >>> Services
> > >>> www.ucc.vcu.edu > >>> __www.ucc.vcu.edu=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Ij6DLy1l7wDp
&g

Re: 8.1.15 Linux client update causing failures

[Andrew Raibeck]

Hi,

Initial assessment is that clients that meet all of the following conditions 
are affected:

- The client is Linux (any architecture), including backup-archive client and 
API applications
- The client is  configured for automatic failover to a replication server

Note that the preceding information is subject to change as we learn more.

Kindest regards,

Andy

Andrew Raibeck
IBM Spectrum Protect Level 3
IBM Systems, Storage
stor...@us.ibm.com

IBM

-Original Message-
From: ADSM: Dist Stor Manager  On Behalf Of Michael Roesch
Sent: Thursday, 14 July, 2022 06:23
To: ADSM-L@VM.MARIST.EDU
Subject: [EXTERNAL] Re: 8.1.15 Linux client update causing failures

Hi,

Does the client for AIX show this problem as well? Did this happen on x64 Linux 
or also on PPC?

Kind regards
Michael Roesch

On Wed, Jul 13, 2022 at 4:19 AM Saravanan Palanisamy < 
evergreen.sa...@gmail.com> wrote:

> So far We don’t see any issues in windows. All scheduled backups are 
> successful.
>
> Regards
> Sarav
> +65 9857 8665
>
>
> > On 13 Jul 2022, at 9:00 AM, Tom Alverson  wrote:
> >
> > Is the windows client safe for this version?
> >
> >
> >> On Tue, Jul 12, 2022, 7:06 PM Saravanan Palanisamy < 
> >> evergreen.sa...@gmail.com> wrote:
> >>
> >> Hi Zoltan
> >>
> >> Yes we have also faced same issue and IBM support confirmed they 
> >> will
> open
> >> new APAR. We have reverted all clients v8.1.14 to address the issue.
> >>
> >> Regards
> >> Sarav
> >> +65 9857 8665
> >>
> >>
> >>>> On 13 Jul 2022, at 2:31 AM, Del Hoobler  wrote:
> >>>
> >>> Hi Zoltan,
> >>>
> >>> IBM knows about this ... and it's being actively worked.
> >>>
> >>> I am sure it will be mitigated soon.
> >>>
> >>> Feel free to open a fresh IBM Support case so you can be quickly
> >> notified once it is fixed.
> >>>
> >>>
> >>> Del
> >>>
> >>> 
> >>> From: ADSM: Dist Stor Manager  on behalf of
> >> Zoltan Forray 
> >>> Sent: Tuesday, July 12, 2022 1:56 PM
> >>> To: ADSM-L@VM.MARIST.EDU 
> >>> Subject: [EXTERNAL] 8.1.15 Linux client update causing failures
> >>>
> >>> We started rolling out the 8.1.15 Linux client via apogee and many
> >> clients
> >>> are failing with:
> >>>
> >>> *** Error in `dsmc': double free or corruption (!prev):
> >> 0x02baf970
> >>> ***
> >>>
> >>> The only matching Google hit goes back to a V7 client issue - long
> fixed.
> >>>
> >>> At first I thought it might be related to a Linux flavor (we run
> Rocky8,
> >>> CentOS 7.1/8, RHEL 7/8) but I don't see a pattern.  All of these
> servers
> >>> are upgrading from 8.1.14 and downleveling the client to 8.1.14 
> >>> fixes
> >> this.
> >>>
> >>> Anyone else seeing this?
> >>>
> >>> FWIW, I could swear that during one of my many Google searches I 
> >>> saw a reference to 8.1.15.2 (eFix?) but now I can't find it again.
> >>> --
> >>> *Zoltan Forray*
> >>> Enterprise Backup Administrator
> >>> VMware Systems Administrator
> >>> Enterprise Compute & Storage Platforms Team VCU Infrastructure 
> >>> Services 
> >>> www.ucc.vcu.edu >>> __www.ucc.vcu.edu=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Ij6DLy1l7wDp
> >>> CbTfcDkLC_KknvhyGdCy_RnAGnhV37I=lx_phvPLtz3INd_W8oJ4eGdfN5WYsItt
> >>> NeFE_AVOLSP0Mp2Rq34RX6Nb9ogoyHYd=e_k1hOLaA6N1PWcNH0bBFZaIJtG1FAb
> >>> mQyN9dy5iR6c= > 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 
> >>> INVALID URI REMOVED
> >>> du_=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Ij6DLy1l7wDpCbTfcDkLC_Kknv
> >>> hyGdCy_RnAGnhV37I=lx_phvPLtz3INd_W8oJ4eGdfN5WYsIttNeFE_AVOLSP0Mp
> >>> 2Rq34RX6Nb9ogoyHYd=VS499q-uVPEP-6-QrjIgicZ_oLB4kvyLNBmMlJeWBEI
> >>> = 
> >>>  >>> questionpro.com=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=Ij6DLy1l7wDpCb
> >>> TfcDkLC_KknvhyGdCy_RnAGnhV37I=lx_phvPLtz3INd_W8oJ4eGdfN5WYsIttNe
> >>> FE_AVOLSP0Mp2Rq34RX6Nb9ogoyHYd=BqXWlinKYJb1mlgHqBJJz4HitGo2CCEEt
> >>> UAK46yC9F4=  >
> >>
>

Re: 8.1.15 Linux client update causing failures

[Michael Roesch]

Hi,

Does the client for AIX show this problem as well? Did this happen on x64
Linux or also on PPC?

Kind regards
Michael Roesch

On Wed, Jul 13, 2022 at 4:19 AM Saravanan Palanisamy <
evergreen.sa...@gmail.com> wrote:

> So far We don’t see any issues in windows. All scheduled backups are
> successful.
>
> Regards
> Sarav
> +65 9857 8665
>
>
> > On 13 Jul 2022, at 9:00 AM, Tom Alverson  wrote:
> >
> > Is the windows client safe for this version?
> >
> >
> >> On Tue, Jul 12, 2022, 7:06 PM Saravanan Palanisamy <
> >> evergreen.sa...@gmail.com> wrote:
> >>
> >> Hi Zoltan
> >>
> >> Yes we have also faced same issue and IBM support confirmed they will
> open
> >> new APAR. We have reverted all clients v8.1.14 to address the issue.
> >>
> >> Regards
> >> Sarav
> >> +65 9857 8665
> >>
> >>
> >>>> On 13 Jul 2022, at 2:31 AM, Del Hoobler  wrote:
> >>>
> >>> Hi Zoltan,
> >>>
> >>> IBM knows about this ... and it's being actively worked.
> >>>
> >>> I am sure it will be mitigated soon.
> >>>
> >>> Feel free to open a fresh IBM Support case so you can be quickly
> >> notified once it is fixed.
> >>>
> >>>
> >>> Del
> >>>
> >>> 
> >>> From: ADSM: Dist Stor Manager  on behalf of
> >> Zoltan Forray 
> >>> Sent: Tuesday, July 12, 2022 1:56 PM
> >>> To: ADSM-L@VM.MARIST.EDU 
> >>> Subject: [EXTERNAL] 8.1.15 Linux client update causing failures
> >>>
> >>> We started rolling out the 8.1.15 Linux client via apogee and many
> >> clients
> >>> are failing with:
> >>>
> >>> *** Error in `dsmc': double free or corruption (!prev):
> >> 0x02baf970
> >>> ***
> >>>
> >>> The only matching Google hit goes back to a V7 client issue - long
> fixed.
> >>>
> >>> At first I thought it might be related to a Linux flavor (we run
> Rocky8,
> >>> CentOS 7.1/8, RHEL 7/8) but I don't see a pattern.  All of these
> servers
> >>> are upgrading from 8.1.14 and downleveling the client to 8.1.14 fixes
> >> this.
> >>>
> >>> Anyone else seeing this?
> >>>
> >>> FWIW, I could swear that during one of my many Google searches I saw a
> >>> reference to 8.1.15.2 (eFix?) but now I can't find it again.
> >>> --
> >>> *Zoltan Forray*
> >>> Enterprise Backup Administrator
> >>> VMware Systems Administrator
> >>> Enterprise Compute & Storage Platforms Team
> >>> VCU Infrastructure Services
> >>> www.ucc.vcu.edu<http://www.ucc.vcu.edu>
> >>> 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://phishing.vcu.edu/
> >>> <https://adminmicro2.questionpro.com >
> >>
>

Re: 8.1.15 Linux client update causing failures

[Saravanan Palanisamy]

So far We don’t see any issues in windows. All scheduled backups are 
successful. 

Regards 
Sarav 
+65 9857 8665


> On 13 Jul 2022, at 9:00 AM, Tom Alverson  wrote:
> 
> Is the windows client safe for this version?
> 
> 
>> On Tue, Jul 12, 2022, 7:06 PM Saravanan Palanisamy <
>> evergreen.sa...@gmail.com> wrote:
>> 
>> Hi Zoltan
>> 
>> Yes we have also faced same issue and IBM support confirmed they will open
>> new APAR. We have reverted all clients v8.1.14 to address the issue.
>> 
>> Regards
>> Sarav
>> +65 9857 8665
>> 
>> 
>>>> On 13 Jul 2022, at 2:31 AM, Del Hoobler  wrote:
>>> 
>>> Hi Zoltan,
>>> 
>>> IBM knows about this ... and it's being actively worked.
>>> 
>>> I am sure it will be mitigated soon.
>>> 
>>> Feel free to open a fresh IBM Support case so you can be quickly
>> notified once it is fixed.
>>> 
>>> 
>>> Del
>>> 
>>> 
>>> From: ADSM: Dist Stor Manager  on behalf of
>> Zoltan Forray 
>>> Sent: Tuesday, July 12, 2022 1:56 PM
>>> To: ADSM-L@VM.MARIST.EDU 
>>> Subject: [EXTERNAL] 8.1.15 Linux client update causing failures
>>> 
>>> We started rolling out the 8.1.15 Linux client via apogee and many
>> clients
>>> are failing with:
>>> 
>>> *** Error in `dsmc': double free or corruption (!prev):
>> 0x02baf970
>>> ***
>>> 
>>> The only matching Google hit goes back to a V7 client issue - long fixed.
>>> 
>>> At first I thought it might be related to a Linux flavor (we run Rocky8,
>>> CentOS 7.1/8, RHEL 7/8) but I don't see a pattern.  All of these servers
>>> are upgrading from 8.1.14 and downleveling the client to 8.1.14 fixes
>> this.
>>> 
>>> Anyone else seeing this?
>>> 
>>> FWIW, I could swear that during one of my many Google searches I saw a
>>> reference to 8.1.15.2 (eFix?) but now I can't find it again.
>>> --
>>> *Zoltan Forray*
>>> Enterprise Backup Administrator
>>> VMware Systems Administrator
>>> Enterprise Compute & Storage Platforms Team
>>> VCU Infrastructure Services
>>> www.ucc.vcu.edu<http://www.ucc.vcu.edu>
>>> 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://phishing.vcu.edu/
>>> <https://adminmicro2.questionpro.com >
>> 

Re: 8.1.15 Linux client update causing failures

[Tom Alverson]

Is the windows client safe for this version?


On Tue, Jul 12, 2022, 7:06 PM Saravanan Palanisamy <
evergreen.sa...@gmail.com> wrote:

> Hi Zoltan
>
> Yes we have also faced same issue and IBM support confirmed they will open
> new APAR. We have reverted all clients v8.1.14 to address the issue.
>
> Regards
> Sarav
> +65 9857 8665
>
>
> > On 13 Jul 2022, at 2:31 AM, Del Hoobler  wrote:
> >
> > Hi Zoltan,
> >
> > IBM knows about this ... and it's being actively worked.
> >
> > I am sure it will be mitigated soon.
> >
> > Feel free to open a fresh IBM Support case so you can be quickly
> notified once it is fixed.
> >
> >
> > Del
> >
> > 
> > From: ADSM: Dist Stor Manager  on behalf of
> Zoltan Forray 
> > Sent: Tuesday, July 12, 2022 1:56 PM
> > To: ADSM-L@VM.MARIST.EDU 
> > Subject: [EXTERNAL] 8.1.15 Linux client update causing failures
> >
> > We started rolling out the 8.1.15 Linux client via apogee and many
> clients
> > are failing with:
> >
> > *** Error in `dsmc': double free or corruption (!prev):
> 0x02baf970
> > ***
> >
> > The only matching Google hit goes back to a V7 client issue - long fixed.
> >
> > At first I thought it might be related to a Linux flavor (we run Rocky8,
> > CentOS 7.1/8, RHEL 7/8) but I don't see a pattern.  All of these servers
> > are upgrading from 8.1.14 and downleveling the client to 8.1.14 fixes
> this.
> >
> > Anyone else seeing this?
> >
> > FWIW, I could swear that during one of my many Google searches I saw a
> > reference to 8.1.15.2 (eFix?) but now I can't find it again.
> > --
> > *Zoltan Forray*
> > Enterprise Backup Administrator
> > VMware Systems Administrator
> > Enterprise Compute & Storage Platforms Team
> > VCU Infrastructure Services
> > www.ucc.vcu.edu<http://www.ucc.vcu.edu>
> > 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://phishing.vcu.edu/
> > <https://adminmicro2.questionpro.com >
>

Re: 8.1.15 Linux client update causing failures

[Saravanan Palanisamy]

Hi Zoltan 

Yes we have also faced same issue and IBM support confirmed they will open new 
APAR. We have reverted all clients v8.1.14 to address the issue. 

Regards 
Sarav 
+65 9857 8665


> On 13 Jul 2022, at 2:31 AM, Del Hoobler  wrote:
> 
> Hi Zoltan,
> 
> IBM knows about this ... and it's being actively worked.
> 
> I am sure it will be mitigated soon.
> 
> Feel free to open a fresh IBM Support case so you can be quickly notified 
> once it is fixed.
> 
> 
> Del
> 
> 
> From: ADSM: Dist Stor Manager  on behalf of Zoltan 
> Forray 
> Sent: Tuesday, July 12, 2022 1:56 PM
> To: ADSM-L@VM.MARIST.EDU 
> Subject: [EXTERNAL] 8.1.15 Linux client update causing failures
> 
> We started rolling out the 8.1.15 Linux client via apogee and many clients
> are failing with:
> 
> *** Error in `dsmc': double free or corruption (!prev): 0x02baf970
> ***
> 
> The only matching Google hit goes back to a V7 client issue - long fixed.
> 
> At first I thought it might be related to a Linux flavor (we run Rocky8,
> CentOS 7.1/8, RHEL 7/8) but I don't see a pattern.  All of these servers
> are upgrading from 8.1.14 and downleveling the client to 8.1.14 fixes this.
> 
> Anyone else seeing this?
> 
> FWIW, I could swear that during one of my many Google searches I saw a
> reference to 8.1.15.2 (eFix?) but now I can't find it again.
> --
> *Zoltan Forray*
> Enterprise Backup Administrator
> VMware Systems Administrator
> Enterprise Compute & Storage Platforms Team
> VCU Infrastructure Services
> www.ucc.vcu.edu<http://www.ucc.vcu.edu>
> 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://phishing.vcu.edu/
> <https://adminmicro2.questionpro.com >

Re: 8.1.15 Linux client update causing failures

[Del Hoobler]

Hi Zoltan,

IBM knows about this ... and it's being actively worked.

I am sure it will be mitigated soon.

Feel free to open a fresh IBM Support case so you can be quickly notified once 
it is fixed.


Del


From: ADSM: Dist Stor Manager  on behalf of Zoltan Forray 

Sent: Tuesday, July 12, 2022 1:56 PM
To: ADSM-L@VM.MARIST.EDU 
Subject: [EXTERNAL] 8.1.15 Linux client update causing failures

We started rolling out the 8.1.15 Linux client via apogee and many clients
are failing with:

 *** Error in `dsmc': double free or corruption (!prev): 0x02baf970
***

The only matching Google hit goes back to a V7 client issue - long fixed.

At first I thought it might be related to a Linux flavor (we run Rocky8,
CentOS 7.1/8, RHEL 7/8) but I don't see a pattern.  All of these servers
are upgrading from 8.1.14 and downleveling the client to 8.1.14 fixes this.

Anyone else seeing this?

FWIW, I could swear that during one of my many Google searches I saw a
reference to 8.1.15.2 (eFix?) but now I can't find it again.
--
*Zoltan Forray*
Enterprise Backup Administrator
VMware Systems Administrator
Enterprise Compute & Storage Platforms Team
VCU Infrastructure Services
www.ucc.vcu.edu<http://www.ucc.vcu.edu>
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://phishing.vcu.edu/
<https://adminmicro2.questionpro.com >

8.1.15 Linux client update causing failures

[Zoltan Forray]

We started rolling out the 8.1.15 Linux client via apogee and many clients
are failing with:

 *** Error in `dsmc': double free or corruption (!prev): 0x02baf970
***

The only matching Google hit goes back to a V7 client issue - long fixed.

At first I thought it might be related to a Linux flavor (we run Rocky8,
CentOS 7.1/8, RHEL 7/8) but I don't see a pattern.  All of these servers
are upgrading from 8.1.14 and downleveling the client to 8.1.14 fixes this.

Anyone else seeing this?

FWIW, I could swear that during one of my many Google searches I saw a
reference to 8.1.15.2 (eFix?) but now I can't find it again.
--
*Zoltan Forray*
Enterprise Backup Administrator
VMware Systems Administrator
Enterprise Compute & Storage Platforms Team
VCU Infrastructure Services
www.ucc.vcu.edu
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://phishing.vcu.edu/
<https://adminmicro2.questionpro.com>

Re: 8.1.2+ Linux client and file rights in /etc/adsm

[Zoltan Forray]

Andy,

Thanks for the confirmation that we can remove global write.

On Wed, Aug 15, 2018 at 7:27 AM Andrew Raibeck  wrote:

> @Zoltan, set the files with chmod 664 (-rw-rw-r--).
>
> @Tandon, if that is not working for Netezza, you should contact Netezza
> support about that. Full permissions does not sound right to me.
>
> Regards,
>
> Andy
>
>
> 
>
> Andrew Raibeck | IBM Spectrum Protect Level 3 | stor...@us.ibm.com
>
> IBM Tivoli Storage Manager links:
> Product support:
>
> https://www.ibm.com/support/entry/portal/product/tivoli/tivoli_storage_manager
>
> Online documentation:
>
> http://www.ibm.com/support/knowledgecenter/SSGSG7/landing/welcome_ssgsg7.html
>
> Product Wiki:
>
> https://www.ibm.com/developerworks/community/wikis/home/wiki/Tivoli%20Storage%20Manager
>
> "ADSM: Dist Stor Manager"  wrote on 2018-08-14
> 20:13:56:
>
> > From: Tandon Kadambala 
> > To: ADSM-L@VM.MARIST.EDU
> > Date: 2018-08-14 20:16
> > Subject: Re: 8.1.2+ Linux client and file rights in /etc/adsm
> > Sent by: "ADSM: Dist Stor Manager" 
> >
> > Hi,
> >
> > We have give chmod 777 TSM* and spcli*
> >
> > We checked netzza db backups all working fine.
> >
> > Without full permissions it won't work
> >
> > Thanks and regards,
> > Tandon K
> > TSM Administrator,
> > IBM India Pvt LTD.,
> >
> >
> > On Wed, Aug 15, 2018, 12:58 AM Zoltan Forray  wrote:
> >
> > > Can someone point me to a document that lists the minimum file rights
> > > required for files in /etc/adsm?
> > >
> > > Our security/scanning process is barking about file in /etc/adsm having
> > > world/global rights and we need to either justify or remove those
> rights:
> > >
> > > /etc/adsm]
> > > -rw-rw-rw-.  1 root root80 Sep 13  2017 spclicert.crl
> > > -rw-rw-rw-.  1 root root 10080 Sep 18  2017 spclicert.kdb
> > > -rw-rw-rw-.  1 root root80 Sep 13  2017 spclicert.rdb
> > > -rw---.  1 root root   193 Sep 13  2017 spclicert.sth
> > > -rw-rw-rw-.  1 root root  1290 Jun 15 19:05 TSM.IDX
> > > -rw-rw-rw-.  1 root root  6319 Jun 15 19:05 TSM.KDB
> > > -rw---.  1 root root   193 Sep 13  2017 TSM.sth
> > >
> > > --
> > > *Zoltan Forray*
> > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> > > Xymon Monitor Administrator
> > > VMware Administrator
> > > Virginia Commonwealth University
> > > UCC/Office of Technology Services
> > > www.ucc.vcu.edu
> > > 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 INVALID URI REMOVED
> > u=http-3A__phishing.vcu.edu_=DwIBaQ=jf_iaSHvJObTbx-
> >
>
> siA1ZOg=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV37I=4lGIl0DL_WDWrNOSA_GwiuHuTHt9GekFlm6mfMiH-
>
> > pg=bVn4fQViO6UoLJnZlE9OkAshwADIEfzXMHvlOclYXy8=
> > >
> >
>


--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
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://phishing.vcu.edu/

Re: 8.1.2+ Linux client and file rights in /etc/adsm

[Andrew Raibeck]

@Zoltan, set the files with chmod 664 (-rw-rw-r--).

@Tandon, if that is not working for Netezza, you should contact Netezza
support about that. Full permissions does not sound right to me.

Regards,

Andy



Andrew Raibeck | IBM Spectrum Protect Level 3 | stor...@us.ibm.com

IBM Tivoli Storage Manager links:
Product support:
https://www.ibm.com/support/entry/portal/product/tivoli/tivoli_storage_manager

Online documentation:
http://www.ibm.com/support/knowledgecenter/SSGSG7/landing/welcome_ssgsg7.html

Product Wiki:
https://www.ibm.com/developerworks/community/wikis/home/wiki/Tivoli%20Storage%20Manager

"ADSM: Dist Stor Manager"  wrote on 2018-08-14
20:13:56:

> From: Tandon Kadambala 
> To: ADSM-L@VM.MARIST.EDU
> Date: 2018-08-14 20:16
> Subject: Re: 8.1.2+ Linux client and file rights in /etc/adsm
> Sent by: "ADSM: Dist Stor Manager" 
>
> Hi,
>
> We have give chmod 777 TSM* and spcli*
>
> We checked netzza db backups all working fine.
>
> Without full permissions it won't work
>
> Thanks and regards,
> Tandon K
> TSM Administrator,
> IBM India Pvt LTD.,
>
>
> On Wed, Aug 15, 2018, 12:58 AM Zoltan Forray  wrote:
>
> > Can someone point me to a document that lists the minimum file rights
> > required for files in /etc/adsm?
> >
> > Our security/scanning process is barking about file in /etc/adsm having
> > world/global rights and we need to either justify or remove those
rights:
> >
> > /etc/adsm]
> > -rw-rw-rw-.  1 root root80 Sep 13  2017 spclicert.crl
> > -rw-rw-rw-.  1 root root 10080 Sep 18  2017 spclicert.kdb
> > -rw-rw-rw-.  1 root root80 Sep 13  2017 spclicert.rdb
> > -rw---.  1 root root   193 Sep 13  2017 spclicert.sth
> > -rw-rw-rw-.  1 root root  1290 Jun 15 19:05 TSM.IDX
> > -rw-rw-rw-.  1 root root  6319 Jun 15 19:05 TSM.KDB
> > -rw---.  1 root root   193 Sep 13  2017 TSM.sth
> >
> > --
> > *Zoltan Forray*
> > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> > Xymon Monitor Administrator
> > VMware Administrator
> > Virginia Commonwealth University
> > UCC/Office of Technology Services
> > www.ucc.vcu.edu
> > 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 INVALID URI REMOVED
> u=http-3A__phishing.vcu.edu_=DwIBaQ=jf_iaSHvJObTbx-
>
siA1ZOg=Ij6DLy1l7wDpCbTfcDkLC_KknvhyGdCy_RnAGnhV37I=4lGIl0DL_WDWrNOSA_GwiuHuTHt9GekFlm6mfMiH-

> pg=bVn4fQViO6UoLJnZlE9OkAshwADIEfzXMHvlOclYXy8=
> >
>

Re: 8.1.2+ Linux client and file rights in /etc/adsm

[Tandon Kadambala]

Hi,

We have give chmod 777 TSM* and spcli*

We checked netzza db backups all working fine.

Without full permissions it won't work

Thanks and regards,
Tandon K
TSM Administrator,
IBM India Pvt LTD.,

On Wed, Aug 15, 2018, 5:43 AM Tandon Kadambala 
wrote:

> Hi,
>
> We have give chmod 777 TSM* and spcli*
>
> We checked netzza db backups all working fine.
>
> Without full permissions it won't work
>
> Thanks and regards,
> Tandon K
> TSM Administrator,
> IBM India Pvt LTD.,
>
>
> On Wed, Aug 15, 2018, 12:58 AM Zoltan Forray  wrote:
>
>> Can someone point me to a document that lists the minimum file rights
>> required for files in /etc/adsm?
>>
>> Our security/scanning process is barking about file in /etc/adsm having
>> world/global rights and we need to either justify or remove those rights:
>>
>> /etc/adsm]
>> -rw-rw-rw-.  1 root root80 Sep 13  2017 spclicert.crl
>> -rw-rw-rw-.  1 root root 10080 Sep 18  2017 spclicert.kdb
>> -rw-rw-rw-.  1 root root80 Sep 13  2017 spclicert.rdb
>> -rw---.  1 root root   193 Sep 13  2017 spclicert.sth
>> -rw-rw-rw-.  1 root root  1290 Jun 15 19:05 TSM.IDX
>> -rw-rw-rw-.  1 root root  6319 Jun 15 19:05 TSM.KDB
>> -rw---.  1 root root   193 Sep 13  2017 TSM.sth
>>
>> --
>> *Zoltan Forray*
>> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
>> Xymon Monitor Administrator
>> VMware Administrator
>> Virginia Commonwealth University
>> UCC/Office of Technology Services
>> www.ucc.vcu.edu
>> 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://phishing.vcu.edu/
>>
>

Re: 8.1.2+ Linux client and file rights in /etc/adsm

[Tandon Kadambala]

Hi,

We have give chmod 777 TSM* and spcli*

We checked netzza db backups all working fine.

Without full permissions it won't work

Thanks and regards,
Tandon K
TSM Administrator,
IBM India Pvt LTD.,


On Wed, Aug 15, 2018, 12:58 AM Zoltan Forray  wrote:

> Can someone point me to a document that lists the minimum file rights
> required for files in /etc/adsm?
>
> Our security/scanning process is barking about file in /etc/adsm having
> world/global rights and we need to either justify or remove those rights:
>
> /etc/adsm]
> -rw-rw-rw-.  1 root root80 Sep 13  2017 spclicert.crl
> -rw-rw-rw-.  1 root root 10080 Sep 18  2017 spclicert.kdb
> -rw-rw-rw-.  1 root root80 Sep 13  2017 spclicert.rdb
> -rw---.  1 root root   193 Sep 13  2017 spclicert.sth
> -rw-rw-rw-.  1 root root  1290 Jun 15 19:05 TSM.IDX
> -rw-rw-rw-.  1 root root  6319 Jun 15 19:05 TSM.KDB
> -rw---.  1 root root   193 Sep 13  2017 TSM.sth
>
> --
> *Zoltan Forray*
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> Xymon Monitor Administrator
> VMware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> www.ucc.vcu.edu
> 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://phishing.vcu.edu/
>

8.1.2+ Linux client and file rights in /etc/adsm

[Zoltan Forray]

Can someone point me to a document that lists the minimum file rights
required for files in /etc/adsm?

Our security/scanning process is barking about file in /etc/adsm having
world/global rights and we need to either justify or remove those rights:

/etc/adsm]
-rw-rw-rw-.  1 root root80 Sep 13  2017 spclicert.crl
-rw-rw-rw-.  1 root root 10080 Sep 18  2017 spclicert.kdb
-rw-rw-rw-.  1 root root80 Sep 13  2017 spclicert.rdb
-rw---.  1 root root   193 Sep 13  2017 spclicert.sth
-rw-rw-rw-.  1 root root  1290 Jun 15 19:05 TSM.IDX
-rw-rw-rw-.  1 root root  6319 Jun 15 19:05 TSM.KDB
-rw---.  1 root root   193 Sep 13  2017 TSM.sth

--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
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://phishing.vcu.edu/

Re: 8.1 Linux client and IT13701 causing heartburn

[Zoltan Forray]

Thank you for the information.  I check weekly for client/server patches so
I will keep an eye open for this APAR update.

On Mon, Jan 30, 2017 at 8:37 AM, Heinz Flemming 
wrote:

> According to Zoltan Forray
> > Heinz
> >
> > Have you heard anything back from IBM on your PMR? I just had another
> > user call with the same problem, except that they ran traces to figure
> out
> > where it was failing and the directory it stops on does not have but a
> few
> > sub/nested directories.  Fortunately, the TESTFLAGS workaround seems to
> > have worked for them.
>
> Today, I received the following message from IBM:
>
>
> 
> I opened apar IT18901 and it will be available on internet in next days.
> The workaround is the same we previosuly informed you or youc an keep to
> use the fix we delivered to you that contains the official fix that will be
> implemented in  next releases,
> 
>
>
> Best regards,
> Heinz
>
> --
> Karlsruher Institut fuer Technologie (KIT)
> Steinbuch Centre for Computing (SCC)
>
> Heinz Flemming
> Scientific Data Management (SDM)
>
> 76131 Karlsruhe
> E-Mail: heinz.flemm...@kit.edu
> www.scc.kit.edu
>
> KIT - Die Forschungsuniversitaet in der Helmholtz-Gemeinschaft
> --
>



--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator (in training)
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
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: 8.1 Linux client and IT13701 causing heartburn

[Heinz Flemming]

According to Zoltan Forray
> Heinz
>
> Have you heard anything back from IBM on your PMR? I just had another
> user call with the same problem, except that they ran traces to figure out
> where it was failing and the directory it stops on does not have but a few
> sub/nested directories.  Fortunately, the TESTFLAGS workaround seems to
> have worked for them.

Today, I received the following message from IBM:



I opened apar IT18901 and it will be available on internet in next days.
The workaround is the same we previosuly informed you or youc an keep to
use the fix we delivered to you that contains the official fix that will be
implemented in  next releases,



Best regards,
Heinz

--
Karlsruher Institut fuer Technologie (KIT)
Steinbuch Centre for Computing (SCC)

Heinz Flemming
Scientific Data Management (SDM)

76131 Karlsruhe
E-Mail: heinz.flemm...@kit.edu
www.scc.kit.edu

KIT - Die Forschungsuniversitaet in der Helmholtz-Gemeinschaft
--

Re: 8.1 Linux client and IT13701 causing heartburn

[Zoltan Forray]

Heinz

Have you heard anything back from IBM on your PMR? I just had another
user call with the same problem, except that they ran traces to figure out
where it was failing and the directory it stops on does not have but a few
sub/nested directories.  Fortunately, the TESTFLAGS workaround seems to
have worked for them.

If you Google the error message, someone with a Windows 2016 server is also
experiencing the "1400" problem.

On Tue, Jan 10, 2017 at 5:31 AM, Heinz Flemming 
wrote:

> According to Zoltan Forray
> > Thanks you for confirming this and opening the PMR.
> >
> > I have passed the "workaround" to the user who first discovered the
> "issue"
> > to see if it fixes his problem.  I hope a patch comes out soon that
> allows
> > us to choose this upper-limit.
> >
> > Can you post the PMR number so we can follow it?
>
> PMR 63214,073,724
>
> IBM will open an APAR.
>
>
> Greetings, Heinz
>
> --
> Karlsruher Institut fuer Technologie (KIT)
> Steinbuch Centre for Computing (SCC)
>
> Heinz Flemming
> Scientific Data Management (SDM)
>
> 76131 Karlsruhe
> E-Mail: heinz.flemm...@kit.edu
> www.scc.kit.edu
> --
>



--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator (in training)
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
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: 8.1 Linux client and IT13701 causing heartburn

[Heinz Flemming]

According to Zoltan Forray
> Thanks you for confirming this and opening the PMR.
>
> I have passed the "workaround" to the user who first discovered the "issue"
> to see if it fixes his problem.  I hope a patch comes out soon that allows
> us to choose this upper-limit.
>
> Can you post the PMR number so we can follow it?

PMR 63214,073,724

IBM will open an APAR.


Greetings, Heinz

--
Karlsruher Institut fuer Technologie (KIT)
Steinbuch Centre for Computing (SCC)

Heinz Flemming
Scientific Data Management (SDM)

76131 Karlsruhe
E-Mail: heinz.flemm...@kit.edu
www.scc.kit.edu
--

Re: 8.1 Linux client and IT13701 causing heartburn

[Zoltan Forray]

Thanks you for confirming this and opening the PMR.

I have passed the "workaround" to the user who first discovered the "issue"
to see if it fixes his problem.  I hope a patch comes out soon that allows
us to choose this upper-limit.

Can you post the PMR number so we can follow it?

On Thu, Jan 5, 2017 at 10:49 AM, Heinz Flemming <heinz.flemm...@kit.edu>
wrote:

> According to Zoltan Forray
> > I have a user who after upgrading their Linux client to 8.1 now has a
> > problem with backups stopping suddenly due to APAR IT13701 whose fix is
> in
> > the 8.1 client.
> >
> > Before upgrading to 8.1, the backups ran fine.
> >
> > I have gone back and forth with them about this being a "fix", not a
> > problem but for obvious reasons, he doesn't agree since this wasn't a
> > problem before upgrading to 8.1?
> >
> > The APAR states:
> >
> > IT13701: CLIENT CRASHES DURING BACKUP WHEN PROCESSING AN INVALID
> DIRECTORY
> > STRUCTURE
> >
> > but they did not have any crashes so my guess is their directory
> structure
> > is just over 1400 but not enough to cause a crash/memory problem.
> >
>
> I've a similar problem with the 8.1.0.0 client on a Red Hat 8 system:
>
> ANS0361I DIAG: incrdrv.cpp (10473): ERROR: PrivIncrFileSpace():
> path '/home/sys/sccwww-intern/Software/TS
> M/statistik/Kontakte/install-mails' contains more directory levels than
> it can be processed...
>
> ANS1999E Incremental processing of '/home/sys/sccwww-intern' stopped.
>
> ANS6718E The path contains too many nested subdirectories. The maximum
> number of nested  directories is 1400.
>
>
> A PMR was opened.
>
> IBM has proposed to set the following in the dsm.opt option file:
>
> TESTFLAGS threadstacksize:2048
>
> In my case it has helped as a workaround.
>
>
>
> Greetings, Heinz
>
> --
> Karlsruher Institut fuer Technologie (KIT)
> Steinbuch Centre for Computing (SCC)
>
> Heinz Flemming
> Scientific Data Management (SDM)
>
> 76131 Karlsruhe
> --
>



--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator (in training)
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
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: 8.1 Linux client and IT13701 causing heartburn

[Heinz Flemming]

According to Zoltan Forray
> I have a user who after upgrading their Linux client to 8.1 now has a
> problem with backups stopping suddenly due to APAR IT13701 whose fix is in
> the 8.1 client.
>
> Before upgrading to 8.1, the backups ran fine.
>
> I have gone back and forth with them about this being a "fix", not a
> problem but for obvious reasons, he doesn't agree since this wasn't a
> problem before upgrading to 8.1?
>
> The APAR states:
>
> IT13701: CLIENT CRASHES DURING BACKUP WHEN PROCESSING AN INVALID DIRECTORY
> STRUCTURE
>
> but they did not have any crashes so my guess is their directory structure
> is just over 1400 but not enough to cause a crash/memory problem.
>

I've a similar problem with the 8.1.0.0 client on a Red Hat 8 system:

ANS0361I DIAG: incrdrv.cpp (10473): ERROR: PrivIncrFileSpace(): path 
'/home/sys/sccwww-intern/Software/TS
M/statistik/Kontakte/install-mails' contains more directory levels than it can 
be processed...

ANS1999E Incremental processing of '/home/sys/sccwww-intern' stopped.

ANS6718E The path contains too many nested subdirectories. The maximum number 
of nested  directories is 1400.


A PMR was opened.

IBM has proposed to set the following in the dsm.opt option file:

TESTFLAGS threadstacksize:2048

In my case it has helped as a workaround.



Greetings, Heinz

--
Karlsruher Institut fuer Technologie (KIT)
Steinbuch Centre for Computing (SCC)

Heinz Flemming
Scientific Data Management (SDM)

76131 Karlsruhe
--

8.1 Linux client and IT13701 causing heartburn

[Zoltan Forray]

I have a user who after upgrading their Linux client to 8.1 now has a
problem with backups stopping suddenly due to APAR IT13701 whose fix is in
the 8.1 client.

Before upgrading to 8.1, the backups ran fine.

I have gone back and forth with them about this being a "fix", not a
problem but for obvious reasons, he doesn't agree since this wasn't a
problem before upgrading to 8.1?

The APAR states:

IT13701: CLIENT CRASHES DURING BACKUP WHEN PROCESSING AN INVALID DIRECTORY
STRUCTURE

but they did not have any crashes so my guess is their directory structure
is just over 1400 but not enough to cause a crash/memory problem.

Unfortunately, unless the rules have changed, they can't go back/downgrade
to 7.1.6.4 without starting all over again, correct?  This system has 7TB
and 10-million files in current backups with most of it in the /home
directory.

Can anyone from IBM explain how the 1400 number was chosen as the limit
(yes I realize this is a very big number for a nested directory structure)
?  Any way to get a opt/sys file option to let the user choose the value?

Your thoughts on this?

--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
Xymon Monitor Administrator
VMware Administrator (in training)
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
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: Error when upgrading the 7.1 Linux client

[Erwann SIMON]

Hello Eric,

TIVsm-filepath contains a kernel module used by tsmjbbd (TIVsm-JBB) and each is 
specific to a kernel version.

If you're not using tsmjbbd, you simply don't need those packages (TIVsm-JBB 
and TIVsm-filepath)

-- 
Best regards / Cordialement / مع تحياتي
Erwann SIMON

- Mail original -
De: EJ van Loon (ITOPT3) - KLM eric-van.l...@klm.com
À: ADSM-L@VM.MARIST.EDU
Envoyé: Mardi 21 Avril 2015 10:33:37
Objet: [ADSM-L] Error when upgrading the 7.1 Linux client

Hi TSM-ers!
Has anybody been able to upgrade their 7.1 Linux client to 7.1.2.0 on RedHat 5? 
When I try to upgrade it I receive the following error:

error: Failed dependencies:
rpmlib(FileDigests) = 4.6.0-1 is needed by 
TIVsm-filepath-7.1.2-0.x86_64
rpmlib(PayloadIsXz) = 5.2-1 is needed by TIVsm-filepath-7.1.2-0.x86_64

Which seems to indicate that the files where build with a higher rpm release 
that the one on RedHat 5...
Thanks for any help in advance!
Kind regards,
Eric van Loon
AF/KLM Storage Engineering

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

Error when upgrading the 7.1 Linux client

[Loon, EJ van (ITOPT3) - KLM]

Hi TSM-ers!
Has anybody been able to upgrade their 7.1 Linux client to 7.1.2.0 on RedHat 5? 
When I try to upgrade it I receive the following error:

error: Failed dependencies:
rpmlib(FileDigests) = 4.6.0-1 is needed by 
TIVsm-filepath-7.1.2-0.x86_64
rpmlib(PayloadIsXz) = 5.2-1 is needed by TIVsm-filepath-7.1.2-0.x86_64

Which seems to indicate that the files where build with a higher rpm release 
that the one on RedHat 5...
Thanks for any help in advance!
Kind regards,
Eric van Loon
AF/KLM Storage Engineering

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: Error when upgrading the 7.1 Linux client

[Loon, EJ van (ITOPT3) - KLM]

Hi Erwann!
I received the same error even when I selected only the API for installation!
Anyway, I managed to upgrade 7.1.1.0 to 7.1.2.0 by using yum instead of rpm. 
It's working now.
Thanks for your reply!
Kind regards,
Eric van Loon
AF/KLM Storage Engineering

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Erwann 
SIMON
Sent: dinsdag 21 april 2015 15:00
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Error when upgrading the 7.1 Linux client

Hello Eric,

TIVsm-filepath contains a kernel module used by tsmjbbd (TIVsm-JBB) and each is 
specific to a kernel version.

If you're not using tsmjbbd, you simply don't need those packages (TIVsm-JBB 
and TIVsm-filepath)

-- 
Best regards / Cordialement / مع تحياتي
Erwann SIMON

- Mail original -
De: EJ van Loon (ITOPT3) - KLM eric-van.l...@klm.com
À: ADSM-L@VM.MARIST.EDU
Envoyé: Mardi 21 Avril 2015 10:33:37
Objet: [ADSM-L] Error when upgrading the 7.1 Linux client

Hi TSM-ers!
Has anybody been able to upgrade their 7.1 Linux client to 7.1.2.0 on RedHat 5? 
When I try to upgrade it I receive the following error:

error: Failed dependencies:
rpmlib(FileDigests) = 4.6.0-1 is needed by 
TIVsm-filepath-7.1.2-0.x86_64
rpmlib(PayloadIsXz) = 5.2-1 is needed by TIVsm-filepath-7.1.2-0.x86_64

Which seems to indicate that the files where build with a higher rpm release 
that the one on RedHat 5...
Thanks for any help in advance!
Kind regards,
Eric van Loon
AF/KLM Storage Engineering

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


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: Upgrading a Linux client

[Ehresman,David E.]

For Linux clients, I've always had to remove (rpm -e) and install (rpm ivh or 
rpm -Uvh) the client rpms.  If upgrade now works without a remove first, I'd 
love to know at what client level that started.

David

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Remco 
Post
Sent: Thursday, May 15, 2014 1:54 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Upgrading a Linux client

what he said, or rpm -Uhv will maybe do (-U for upgrade, -i for install), h for 
nice hash marks as a progress bar and v for not Very quiet ;-)

Op 14 mei 2014, om 16:19 heeft Erwann Simon erwann.si...@free.fr het volgende 
geschreven:

 Eric, 
 
 You need to uninstall (rpm -e) and then reinstall (rpm -i).
 
 
 On 14 mai 2014 16:17:02 CEST, Loon, EJ van (SPLXM) - KLM 
 eric-van.l...@klm.com wrote:
 Hi guys!
 I'm not really an Linux expert, but I'm trying to upgrade a 6.2 client
 to 7.1 on a Linux nodes. When I follow the commands from the manual to
 install the API client (rpm -i TIVsm-API64.x86_64.rpm) it fails with
 several of the following messages:
 
 file /opt/tivoli/tsm/client/api/bin64/sample/dapiutil.c from install of
 TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
 TIVsm-API64-6.2.4-0.i586
 file /opt/tivoli/tsm/client/api/bin64/sample/dpsthread.h from install
 of TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
 TIVsm-API64-6.2.4-0.i586
 file /opt/tivoli/tsm/client/api/bin64/sample/dsmapips.h from install of
 TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
 TIVsm-API64-6.2.4-0.i586
 
 I tried the -U switch, but that doesn't help either. What am I doing
 wrong here? Isn't it possible to upgrade the client and should I
 uninstall 6.2.4 first?
 Thanks again for your help!
 Kind regards,
 Eric van Loon
 AF/KLM Storage Engineering
 
 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
 
 
 -- 
 Erwann SIMON
 Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

-- 

 Met vriendelijke groeten/Kind Regards,

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

Re: Upgrading a Linux client

[Erwann Simon]

Hi David,

Upgrade (rpm -U) is working begining with client 6.3. I guess it has been 
changed to enable/facilitate autodeployment.

-- 
Best regards / Cordialement / مع تحياتي
Erwann SIMON

- Mail original -
De: David E. Ehresman deehr...@louisville.edu
À: ADSM-L@VM.MARIST.EDU
Envoyé: Jeudi 15 Mai 2014 15:04:31
Objet: Re: [ADSM-L] Upgrading a Linux client

For Linux clients, I've always had to remove (rpm -e) and install (rpm ivh or 
rpm -Uvh) the client rpms.  If upgrade now works without a remove first, I'd 
love to know at what client level that started.

David

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Remco 
Post
Sent: Thursday, May 15, 2014 1:54 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Upgrading a Linux client

what he said, or rpm -Uhv will maybe do (-U for upgrade, -i for install), h for 
nice hash marks as a progress bar and v for not Very quiet ;-)

Op 14 mei 2014, om 16:19 heeft Erwann Simon erwann.si...@free.fr het volgende 
geschreven:

 Eric, 
 
 You need to uninstall (rpm -e) and then reinstall (rpm -i).
 
 
 On 14 mai 2014 16:17:02 CEST, Loon, EJ van (SPLXM) - KLM 
 eric-van.l...@klm.com wrote:
 Hi guys!
 I'm not really an Linux expert, but I'm trying to upgrade a 6.2 client
 to 7.1 on a Linux nodes. When I follow the commands from the manual to
 install the API client (rpm -i TIVsm-API64.x86_64.rpm) it fails with
 several of the following messages:
 
 file /opt/tivoli/tsm/client/api/bin64/sample/dapiutil.c from install of
 TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
 TIVsm-API64-6.2.4-0.i586
 file /opt/tivoli/tsm/client/api/bin64/sample/dpsthread.h from install
 of TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
 TIVsm-API64-6.2.4-0.i586
 file /opt/tivoli/tsm/client/api/bin64/sample/dsmapips.h from install of
 TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
 TIVsm-API64-6.2.4-0.i586
 
 I tried the -U switch, but that doesn't help either. What am I doing
 wrong here? Isn't it possible to upgrade the client and should I
 uninstall 6.2.4 first?
 Thanks again for your help!
 Kind regards,
 Eric van Loon
 AF/KLM Storage Engineering
 
 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
 
 
 -- 
 Erwann SIMON
 Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

-- 

 Met vriendelijke groeten/Kind Regards,

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

Upgrading a Linux client

[Loon, EJ van (SPLXM) - KLM]

Hi guys!
I'm not really an Linux expert, but I'm trying to upgrade a 6.2 client to 7.1 
on a Linux nodes. When I follow the commands from the manual to install the API 
client (rpm -i TIVsm-API64.x86_64.rpm) it fails with several of the following 
messages:

file /opt/tivoli/tsm/client/api/bin64/sample/dapiutil.c from install of 
TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package 
TIVsm-API64-6.2.4-0.i586
file /opt/tivoli/tsm/client/api/bin64/sample/dpsthread.h from install 
of TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package 
TIVsm-API64-6.2.4-0.i586
file /opt/tivoli/tsm/client/api/bin64/sample/dsmapips.h from install of 
TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package 
TIVsm-API64-6.2.4-0.i586

I tried the -U switch, but that doesn't help either. What am I doing wrong 
here? Isn't it possible to upgrade the client and should I uninstall 6.2.4 
first?
Thanks again for your help!
Kind regards,
Eric van Loon
AF/KLM Storage Engineering

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: Upgrading a Linux client

[Erwann Simon]

Eric, 

You need to uninstall (rpm -e) and then reinstall (rpm -i).


On 14 mai 2014 16:17:02 CEST, Loon, EJ van (SPLXM) - KLM 
eric-van.l...@klm.com wrote:
Hi guys!
I'm not really an Linux expert, but I'm trying to upgrade a 6.2 client
to 7.1 on a Linux nodes. When I follow the commands from the manual to
install the API client (rpm -i TIVsm-API64.x86_64.rpm) it fails with
several of the following messages:

file /opt/tivoli/tsm/client/api/bin64/sample/dapiutil.c from install of
TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
TIVsm-API64-6.2.4-0.i586
file /opt/tivoli/tsm/client/api/bin64/sample/dpsthread.h from install
of TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
TIVsm-API64-6.2.4-0.i586
file /opt/tivoli/tsm/client/api/bin64/sample/dsmapips.h from install of
TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
TIVsm-API64-6.2.4-0.i586

I tried the -U switch, but that doesn't help either. What am I doing
wrong here? Isn't it possible to upgrade the client and should I
uninstall 6.2.4 first?
Thanks again for your help!
Kind regards,
Eric van Loon
AF/KLM Storage Engineering

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


-- 
Erwann SIMON
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

Re: Upgrading a Linux client

[Remco Post]

what he said, or rpm -Uhv will maybe do (-U for upgrade, -i for install), h for 
nice hash marks as a progress bar and v for not Very quiet ;-)

Op 14 mei 2014, om 16:19 heeft Erwann Simon erwann.si...@free.fr het volgende 
geschreven:

 Eric, 
 
 You need to uninstall (rpm -e) and then reinstall (rpm -i).
 
 
 On 14 mai 2014 16:17:02 CEST, Loon, EJ van (SPLXM) - KLM 
 eric-van.l...@klm.com wrote:
 Hi guys!
 I'm not really an Linux expert, but I'm trying to upgrade a 6.2 client
 to 7.1 on a Linux nodes. When I follow the commands from the manual to
 install the API client (rpm -i TIVsm-API64.x86_64.rpm) it fails with
 several of the following messages:
 
 file /opt/tivoli/tsm/client/api/bin64/sample/dapiutil.c from install of
 TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
 TIVsm-API64-6.2.4-0.i586
 file /opt/tivoli/tsm/client/api/bin64/sample/dpsthread.h from install
 of TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
 TIVsm-API64-6.2.4-0.i586
 file /opt/tivoli/tsm/client/api/bin64/sample/dsmapips.h from install of
 TIVsm-API64-7.1.0-0.x86_64 conflicts with file from package
 TIVsm-API64-6.2.4-0.i586
 
 I tried the -U switch, but that doesn't help either. What am I doing
 wrong here? Isn't it possible to upgrade the client and should I
 uninstall 6.2.4 first?
 Thanks again for your help!
 Kind regards,
 Eric van Loon
 AF/KLM Storage Engineering
 
 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
 
 
 -- 
 Erwann SIMON
 Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

-- 

 Met vriendelijke groeten/Kind Regards,

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

Linux client questions

[Lee, Gary]

Is the current linuxx86 client 64 bit, 32, or both?

All of my linuxes are 64 bit, but another department has some 32 bit systems 
out there and was asking.  I didn't see any reference on the tsm client 
download site.

Thanks for any assistance.


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

 

Re: Linux client questions

[Zoltan Forray/AC/VCU]

All of the Linux clients, to date, are labeled x86 as part of the name.
No x64 client versions as far as I can tell


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:   Lee, Gary g...@bsu.edu
To: ADSM-L@VM.MARIST.EDU
Date:   02/14/2012 11:19 AM
Subject:[ADSM-L] Linux client questions
Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



Is the current linuxx86 client 64 bit, 32, or both?

All of my linuxes are 64 bit, but another department has some 32 bit
systems out there and was asking.  I didn't see any reference on the tsm
client download site.

Thanks for any assistance.


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

Re: Linux client questions

[Erwann Simon]

Hi Gary,

It depends on the TSM version of the client :
- Linuxx86 client is 32 bits only up to version 6.2. Note there are 2 API 
packages, on is 32 bits (TIVsm-API) while other on is 64 bits (TIVsm-API64).
- Linuxx86 client is 64 bits only from version 6.3.


- Mail original -
De: Gary Lee g...@bsu.edu
À: ADSM-L@VM.MARIST.EDU
Envoyé: Mardi 14 Février 2012 16:57:34
Objet: [ADSM-L] Linux client questions

Is the current linuxx86 client 64 bit, 32, or both?

All of my linuxes are 64 bit, but another department has some 32 bit systems 
out there and was asking.  I didn't see any reference on the tsm client 
download site.

Thanks for any assistance.


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

linux client

[Tim Brown]

Does the x86 linux client support SUSE Linux SLES 10 SP2



Thanks,



Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas  Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbr...@cenhud.com mailto:tbr...@cenhud.com
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255




This message contains confidential information and is only for the intended 
recipient. If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, please notify the sender immediately by replying to this note and 
deleting all copies and attachments.

Problems backing up Linux client - missed filesystem

[Minns, Farren - Chichester]

Hi All



TSM Server 5.5.2.0 on Solaris

Linux Client 5.5.0.0 - Real Application Cluster v6



I have the following issue. When the backup runs as a scheduled service it only 
checks/backs up the /boot filesystem.



I put the following in dsm.sys and that certainly allows me to run manual 
backups, but the incremental still doesn't work.



virtualmountpoint /



Any ideas?



Regards



Farren


John Wiley  Sons Limited is a private limited company registered in England 
with registered number 641132.
Registered office address: The Atrium, Southern Gate, Chichester, West Sussex, 
United Kingdom. PO19 8SQ.

Re: Problems backing up Linux client - missed filesystem

[Thomas Denier]

-Farren Minns wrote: -

TSM Server 5.5.2.0 on Solaris

Linux Client 5.5.0.0 - Real Application Cluster v6

I have the following issue. When the backup runs as a scheduled
service it only checks/backs up the /boot filesystem.

I put the following in dsm.sys and that certainly allows me to run
manual backups, but the incremental still doesn't work.

virtualmountpoint /

Any ideas?

I generally don't recommend using maintenance level 0 of a new
release of TSM code. Before Version 6 came out we were generally
getting good results with 5.5.1.0 client code. We are now getting
good results with 6.2.2.0 client code on systems with OS levels
supported for use with 6.2 client code.

Thomas Denier

Re: Problems backing up Linux client - missed filesystem

[Minns, Farren - Chichester]

OK, thanks for the advice.

Regards

Farren




-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@vm.marist.edu] On Behalf Of Thomas 
Denier
Sent: 12 December 2011 16:49
To: ADSM-L@vm.marist.edu
Subject: Re: [ADSM-L] Problems backing up Linux client - missed filesystem

-Farren Minns wrote: -

TSM Server 5.5.2.0 on Solaris

Linux Client 5.5.0.0 - Real Application Cluster v6

I have the following issue. When the backup runs as a scheduled
service it only checks/backs up the /boot filesystem.

I put the following in dsm.sys and that certainly allows me to run
manual backups, but the incremental still doesn't work.

virtualmountpoint /

Any ideas?

I generally don't recommend using maintenance level 0 of a new
release of TSM code. Before Version 6 came out we were generally
getting good results with 5.5.1.0 client code. We are now getting
good results with 6.2.2.0 client code on systems with OS levels
supported for use with 6.2 client code.

Thomas Denier


John Wiley  Sons Limited is a private limited company registered in England 
with registered number 641132.
Registered office address: The Atrium, Southern Gate, Chichester, West Sussex, 
United Kingdom. PO19 8SQ.

Re: Problems backing up Linux client - missed filesystem

[Ehresman,David E.]

Have you checked your dsmsched.log on the client for errors?  Have you checked 
your tsm server actlog for the same time period for informative messages?

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Minns, 
Farren - Chichester
Sent: Monday, December 12, 2011 12:01 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Problems backing up Linux client - missed filesystem

OK, thanks for the advice.

Regards

Farren




-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@vm.marist.edu] On Behalf Of Thomas 
Denier
Sent: 12 December 2011 16:49
To: ADSM-L@vm.marist.edu
Subject: Re: [ADSM-L] Problems backing up Linux client - missed filesystem

-Farren Minns wrote: -

TSM Server 5.5.2.0 on Solaris

Linux Client 5.5.0.0 - Real Application Cluster v6

I have the following issue. When the backup runs as a scheduled
service it only checks/backs up the /boot filesystem.

I put the following in dsm.sys and that certainly allows me to run
manual backups, but the incremental still doesn't work.

virtualmountpoint /

Any ideas?

I generally don't recommend using maintenance level 0 of a new
release of TSM code. Before Version 6 came out we were generally
getting good results with 5.5.1.0 client code. We are now getting
good results with 6.2.2.0 client code on systems with OS levels
supported for use with 6.2 client code.

Thomas Denier


John Wiley  Sons Limited is a private limited company registered in England 
with registered number 641132.
Registered office address: The Atrium, Southern Gate, Chichester, West Sussex, 
United Kingdom. PO19 8SQ.

Re: Problems backing up Linux client - missed filesystem

[Minns, Farren - Chichester]

Hi

Yes, and not actually seeing errors.

The backup runs fine, but only check the /boot filesystem.

Regards

Farren






-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Ehresman,David E.
Sent: 12 December 2011 17:07
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Problems backing up Linux client - missed filesystem

Have you checked your dsmsched.log on the client for errors?  Have you checked 
your tsm server actlog for the same time period for informative messages?

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Minns, 
Farren - Chichester
Sent: Monday, December 12, 2011 12:01 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Problems backing up Linux client - missed filesystem

OK, thanks for the advice.

Regards

Farren




-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@vm.marist.edu] On Behalf Of Thomas 
Denier
Sent: 12 December 2011 16:49
To: ADSM-L@vm.marist.edu
Subject: Re: [ADSM-L] Problems backing up Linux client - missed filesystem

-Farren Minns wrote: -

TSM Server 5.5.2.0 on Solaris

Linux Client 5.5.0.0 - Real Application Cluster v6

I have the following issue. When the backup runs as a scheduled
service it only checks/backs up the /boot filesystem.

I put the following in dsm.sys and that certainly allows me to run
manual backups, but the incremental still doesn't work.

virtualmountpoint /

Any ideas?

I generally don't recommend using maintenance level 0 of a new
release of TSM code. Before Version 6 came out we were generally
getting good results with 5.5.1.0 client code. We are now getting
good results with 6.2.2.0 client code on systems with OS levels
supported for use with 6.2 client code.

Thomas Denier


John Wiley  Sons Limited is a private limited company registered in England 
with registered number 641132.
Registered office address: The Atrium, Southern Gate, Chichester, West Sussex, 
United Kingdom. PO19 8SQ.



John Wiley  Sons Limited is a private limited company registered in England 
with registered number 641132.
Registered office address: The Atrium, Southern Gate, Chichester, West Sussex, 
United Kingdom. PO19 8SQ.

Re: Problems backing up Linux client - missed filesystem

[Richard Sims]

If your scheduler is not running under CAD, any changes made to dsm.sys and 
dsm.opt will not be known to that scheduler process until it is restarted.

You should also review the output of 'dsmc q opt' and 'dsmc q inclexcl' for 
containing what you actually want, as compiled specifications.  An option of 
virtualmountpoint / seems pointless.

Richard Sims

Re: linux client and TSM gui

[Richard van Denzel]

The Linux client is installed in /opt/tivoli/tsm/client/ba/bin. I've had it
working using dsmj and XMing as the X-Windows server.

Richard.

2011/6/2 Remco Post r.p...@plcs.nl

 On 2 jun 2011, at 15:02, Tim Brown wrote:

  Even if I export the display doesn't the dsm executable have to reside
  On the linux client. I don't see the dsm executable in the bin folder


 'the bin' folder? I assume you mean /opt/tivoli/tsm/client/ba/bin ?
 the gui for linux is dsmj

 On some systems, sometimes the installer also creates links for TSM in
 /usr/bin, but YMMV

  On linux
 
  Tim
 
 
  -Original Message-
  From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
 Mark Mooney
  Sent: Thursday, June 02, 2011 8:36 AM
  To: ADSM-L@VM.MARIST.EDU
  Subject: Re: linux client and TSM gui
 
  Tim,
 
  You'll need to possibly export your display and then the executable for
 the GUI is dsm instead of dsmc.
 
  Thanks,
  Mooney
 
  -Original Message-
  From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
 Tim Brown
  Sent: Thursday, June 02, 2011 8:35 AM
  To: ADSM-L@VM.MARIST.EDU
  Subject: linux client and TSM gui
 
  Is there a way to run a TSM GUI session on Linux, I am able to run the
 command line interface.
 
 
 
  Thanks,
 
 
 
  Tim Brown
  Systems Specialist - Project Leader
  Central Hudson Gas  Electric
  284 South Ave
  Poughkeepsie, NY 12601
  Email: tbr...@cenhud.com mailto:tbr...@cenhud.com
  Phone: 845-486-5643
  Fax: 845-486-5921
  Cell: 845-235-4255
 
 
 
 
  This message contains confidential information and is only for the
 intended recipient. If the reader of this message is not the intended
 recipient, or an employee or agent responsible for delivering this message
 to the intended recipient, please notify the sender immediately by replying
 to this note and deleting all copies and attachments.

 --
 Met vriendelijke groeten/Kind Regards,

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

linux client and TSM gui

[Tim Brown]

Is there a way to run a TSM GUI session on Linux, I am able to run the command 
line interface.



Thanks,



Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas  Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbr...@cenhud.com mailto:tbr...@cenhud.com
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255




This message contains confidential information and is only for the intended 
recipient. If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, please notify the sender immediately by replying to this note and 
deleting all copies and attachments.

Re: linux client and TSM gui

[Mark Mooney]

Tim,

You'll need to possibly export your display and then the executable for the GUI 
is dsm instead of dsmc.

Thanks,
Mooney

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tim 
Brown
Sent: Thursday, June 02, 2011 8:35 AM
To: ADSM-L@VM.MARIST.EDU
Subject: linux client and TSM gui

Is there a way to run a TSM GUI session on Linux, I am able to run the command 
line interface.



Thanks,



Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas  Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbr...@cenhud.com mailto:tbr...@cenhud.com
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255




This message contains confidential information and is only for the intended 
recipient. If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, please notify the sender immediately by replying to this note and 
deleting all copies and attachments.

Re: linux client and TSM gui

[Robert J Molerio]

If that dosent work try dsmj after exporting your display variable.

On Thu, Jun 2, 2011 at 8:34 AM, Tim Brown tbr...@cenhud.com wrote:

 Is there a way to run a TSM GUI session on Linux, I am able to run the
 command line interface.



 Thanks,



 Tim Brown
 Systems Specialist - Project Leader
 Central Hudson Gas  Electric
 284 South Ave
 Poughkeepsie, NY 12601
 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com
 Phone: 845-486-5643
 Fax: 845-486-5921
 Cell: 845-235-4255




 This message contains confidential information and is only for the intended
 recipient. If the reader of this message is not the intended recipient, or
 an employee or agent responsible for delivering this message to the intended
 recipient, please notify the sender immediately by replying to this note and
 deleting all copies and attachments.

Re: linux client and TSM gui

[Rick Adamson]

We configure our linux machines to use run level 3 only and configure
the managedservices option in the client options file. This enables
you to use the web GUI interface from a browser, remote or locally.
Page 308 in the 5.5 BA user guide. Hope this helps...

~Rick


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Tim Brown
Sent: Thursday, June 02, 2011 8:35 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] linux client and TSM gui

Is there a way to run a TSM GUI session on Linux, I am able to run the
command line interface.



Thanks,



Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas  Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbr...@cenhud.com mailto:tbr...@cenhud.com
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255




This message contains confidential information and is only for the
intended recipient. If the reader of this message is not the intended
recipient, or an employee or agent responsible for delivering this
message to the intended recipient, please notify the sender immediately
by replying to this note and deleting all copies and attachments.

Re: linux client and TSM gui

[Tim Brown]

Even if I export the display doesn't the dsm executable have to reside
On the linux client. I don't see the dsm executable in the bin folder
On linux

Tim


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark 
Mooney
Sent: Thursday, June 02, 2011 8:36 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: linux client and TSM gui

Tim,

You'll need to possibly export your display and then the executable for the GUI 
is dsm instead of dsmc.

Thanks,
Mooney

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tim 
Brown
Sent: Thursday, June 02, 2011 8:35 AM
To: ADSM-L@VM.MARIST.EDU
Subject: linux client and TSM gui

Is there a way to run a TSM GUI session on Linux, I am able to run the command 
line interface.



Thanks,



Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas  Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbr...@cenhud.com mailto:tbr...@cenhud.com
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255




This message contains confidential information and is only for the intended 
recipient. If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, please notify the sender immediately by replying to this note and 
deleting all copies and attachments.

Re: linux client and TSM gui

[Mark Mooney]

It might be dsmj then.

Tim Brown tbr...@cenhud.com wrote:


Even if I export the display doesn't the dsm executable have to reside
On the linux client. I don't see the dsm executable in the bin folder
On linux

Tim


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark 
Mooney
Sent: Thursday, June 02, 2011 8:36 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: linux client and TSM gui

Tim,

You'll need to possibly export your display and then the executable for the GUI 
is dsm instead of dsmc.

Thanks,
Mooney

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tim 
Brown
Sent: Thursday, June 02, 2011 8:35 AM
To: ADSM-L@VM.MARIST.EDU
Subject: linux client and TSM gui

Is there a way to run a TSM GUI session on Linux, I am able to run the command 
line interface.



Thanks,



Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas  Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbr...@cenhud.com mailto:tbr...@cenhud.com
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255




This message contains confidential information and is only for the intended 
recipient. If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, please notify the sender immediately by replying to this note and 
deleting all copies and attachments.

Re: linux client and TSM gui

[Remco Post]

On 2 jun 2011, at 15:02, Tim Brown wrote:

 Even if I export the display doesn't the dsm executable have to reside
 On the linux client. I don't see the dsm executable in the bin folder


'the bin' folder? I assume you mean /opt/tivoli/tsm/client/ba/bin ?
the gui for linux is dsmj

On some systems, sometimes the installer also creates links for TSM in 
/usr/bin, but YMMV

 On linux
 
 Tim
 
 
 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark 
 Mooney
 Sent: Thursday, June 02, 2011 8:36 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: Re: linux client and TSM gui
 
 Tim,
 
 You'll need to possibly export your display and then the executable for the 
 GUI is dsm instead of dsmc.
 
 Thanks,
 Mooney
 
 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tim 
 Brown
 Sent: Thursday, June 02, 2011 8:35 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: linux client and TSM gui
 
 Is there a way to run a TSM GUI session on Linux, I am able to run the 
 command line interface.
 
 
 
 Thanks,
 
 
 
 Tim Brown
 Systems Specialist - Project Leader
 Central Hudson Gas  Electric
 284 South Ave
 Poughkeepsie, NY 12601
 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com
 Phone: 845-486-5643
 Fax: 845-486-5921
 Cell: 845-235-4255
 
 
 
 
 This message contains confidential information and is only for the intended 
 recipient. If the reader of this message is not the intended recipient, or an 
 employee or agent responsible for delivering this message to the intended 
 recipient, please notify the sender immediately by replying to this note and 
 deleting all copies and attachments.

-- 
Met vriendelijke groeten/Kind Regards,

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

Re: linux client for RHES v3

[Zoltan Forray/AC/VCU]

Being a university, we also have older/non-mainstream systems we backup
(IRIX anyone?  DEC VAX?).

Looks like 5.3 (which is no longer supported) is the highest you can go
for RH3 - per this page:

https://www-304.ibm.com/support/docview.wss?uid=swg21303997

Red Hat Enterprise Linux 3 (AS,WS,ES) (need
compat-gcc-c++-7.3-2.96.122.i386.rpm)
Red Hat Enterprise Linux 4 (AS,WS,ES)
RedFlag 4.1

To answer your next question,  Yes we have clients at  5.2.3 backing up to
a 5.5.5 server with no issues.
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:
Richard Rhodes rrho...@firstenergycorp.com
To:
ADSM-L@VM.MARIST.EDU
Date:
05/18/2011 03:20 PM
Subject:
[ADSM-L] linux client for RHES v3
Sent by:
ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



Hi everyone,

We have just found that we have to start TSM backups of a RedHat
Enterprise Linux ES Release 3 server (that's what I'm told the version
is).I went looking on IBM's web site - the oldest compatibility info I
can come up with is for TSM client v5.4.1 as supporting RH v5.

Does anyone have any idea what TSM client would work onRedHat
Enterprise Linux ES Release 3  . . . if any?

(Then I get to try and find that client)

Thanks

Rick


-
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.

Re: Ang: linux client for RHES v3

[Richard Rhodes]

Thanks!

I pulled the 5.3.6.7 client from the ftp site Daniel listed.I had 
thought all the FTP sites were gone . . . I'm glad one is still around.

Rick




From:   Erwann SIMON erwann.si...@free.fr
To: ADSM-L@VM.MARIST.EDU
Date:   05/18/2011 03:53 PM
Subject:Re: Ang: linux client for RHES v3
Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



Hi,

A 5.3.6.x client is supported as a 5.4 client for a RHE{S|L} 3:
https://www-304.ibm.com/support/docview.wss?uid=swg24019416

Best regards / Cordialement / مع تحياتي
Erwann SIMON


Le 18/05/2011 20:46, Daniel Sparrman a écrit :
 If you mean support as in IBM supporting it, I'd say no.

 If you're saying, can I run it, yes you should be able to run older 
code. It's mostly just about the kernel level. Check the FTP. I know 
5.2.2.6 is stating it runs on RHEL 3.0, perhaps an even newer client does.

 
ftp://ftp.software.ibm.com/storage/tivoli-storage-management/patches/client/v5r2/Linux/Linux86/v522/


 Best Regards

 Daniel



 Daniel Sparrman
 Exist i Stockholm AB
 V?xel: 08-754 98 00
 Fax: 08-754 97 30
 daniel.sparr...@exist.se
 http://www.existgruppen.se
 Posthusgatan 1 761 30 NORRT?LJE



 -ADSM: Dist Stor ManagerADSM-L@VM.MARIST.EDU  skrev: -


 Till: ADSM-L@VM.MARIST.EDU
 Fr?n: Richard Rhodesrrho...@firstenergycorp.com
 S?nt av: ADSM: Dist Stor ManagerADSM-L@VM.MARIST.EDU
 Datum: 05/18/2011 21:18
 ?rende: linux client for RHES v3

 Hi everyone,

 We have just found that we have to start TSM backups of a RedHat
 Enterprise Linux ES Release 3 server (that's what I'm told the version
 is).I went looking on IBM's web site - the oldest compatibility info 
I
 can come up with is for TSM client v5.4.1 as supporting RH v5.

 Does anyone have any idea what TSM client would work onRedHat
 Enterprise Linux ES Release 3  . . . if any?

 (Then I get to try and find that client)

 Thanks

 Rick


 -
 The information contained in this message is intended only for the
 personal and confidential use of the recipient(s) named above. If
 the reader of this message is not the intended recipient or an
 agent responsible for delivering it to the intended recipient, you
 are hereby notified that you have received this document in error
 and that any review, dissemination, distribution, or copying of
 this message is strictly prohibited. If you have received this
 communication in error, please notify us immediately, and delete
 the original message.

linux client for RHES v3

[Richard Rhodes]

Hi everyone,

We have just found that we have to start TSM backups of a RedHat
Enterprise Linux ES Release 3 server (that's what I'm told the version
is).I went looking on IBM's web site - the oldest compatibility info I
can come up with is for TSM client v5.4.1 as supporting RH v5.

Does anyone have any idea what TSM client would work onRedHat
Enterprise Linux ES Release 3  . . . if any?

(Then I get to try and find that client)

Thanks

Rick


-
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.

Ang: linux client for RHES v3

[Daniel Sparrman]

If you mean support as in IBM supporting it, I'd say no.

If you're saying, can I run it, yes you should be able to run older code. It's 
mostly just about the kernel level. Check the FTP. I know 5.2.2.6 is stating it 
runs on RHEL 3.0, perhaps an even newer client does.

ftp://ftp.software.ibm.com/storage/tivoli-storage-management/patches/client/v5r2/Linux/Linux86/v522/

Best Regards

Daniel



Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE



-ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU skrev: -


Till: ADSM-L@VM.MARIST.EDU
Från: Richard Rhodes rrho...@firstenergycorp.com
Sänt av: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU
Datum: 05/18/2011 21:18
Ärende: linux client for RHES v3

Hi everyone,

We have just found that we have to start TSM backups of a RedHat
Enterprise Linux ES Release 3 server (that's what I'm told the version
is).I went looking on IBM's web site - the oldest compatibility info I
can come up with is for TSM client v5.4.1 as supporting RH v5.

Does anyone have any idea what TSM client would work onRedHat
Enterprise Linux ES Release 3  . . . if any?

(Then I get to try and find that client)

Thanks

Rick


-
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.

Re: Ang: linux client for RHES v3

[Erwann SIMON]

Hi,

A 5.3.6.x client is supported as a 5.4 client for a RHE{S|L} 3:
https://www-304.ibm.com/support/docview.wss?uid=swg24019416

Best regards / Cordialement / مع تحياتي
Erwann SIMON


Le 18/05/2011 20:46, Daniel Sparrman a écrit :

If you mean support as in IBM supporting it, I'd say no.

If you're saying, can I run it, yes you should be able to run older code. It's 
mostly just about the kernel level. Check the FTP. I know 5.2.2.6 is stating it 
runs on RHEL 3.0, perhaps an even newer client does.

ftp://ftp.software.ibm.com/storage/tivoli-storage-management/patches/client/v5r2/Linux/Linux86/v522/

Best Regards

Daniel



Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE



-ADSM: Dist Stor ManagerADSM-L@VM.MARIST.EDU  skrev: -


Till: ADSM-L@VM.MARIST.EDU
Från: Richard Rhodesrrho...@firstenergycorp.com
Sänt av: ADSM: Dist Stor ManagerADSM-L@VM.MARIST.EDU
Datum: 05/18/2011 21:18
Ärende: linux client for RHES v3

Hi everyone,

We have just found that we have to start TSM backups of a RedHat
Enterprise Linux ES Release 3 server (that's what I'm told the version
is).I went looking on IBM's web site - the oldest compatibility info I
can come up with is for TSM client v5.4.1 as supporting RH v5.

Does anyone have any idea what TSM client would work onRedHat
Enterprise Linux ES Release 3  . . . if any?

(Then I get to try and find that client)

Thanks

Rick


-
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.

Re: Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

[Wolfgang J Moeller]

Last year, I had reported ...

 on a (real big!) x86_64 machine, with freshly installed SuSE SLES 10.3,
 scanning a mere ~500k files (and typically saving  10,000 per run),
 dsmc has been found to consume about 1.3 GByte of virtual memory
 per single run. This is about tenfold from what you'd expect ...

 And even worse, in the case of running dsmc sched, the memory
 consumption is cumulative in the sense that after three runs,
 virtual memory has grown to about the maximum of ~4 GB [...]

 Sure running dsmc via the CAD is currently a work-around ... but how long?
[...]
 IBM support is rather stumped. Any ideas welcome!

After lots  lots of digging, IBM support finally came up
with the idea of testing memory usage of the UNIX function getpwuid() -
used by dsmc in order to find the files' owner name -
and it turned out that when LDAP client authorization was involved,
this function would leak ~300kB of memory _per_call_!

It also turned out that nscd (name service caching daemon) was not
running - once started, the memory leak would be experienced by nscd,
and no longer by dsmc. However, in order to keep nscd running,
it would require regular re-starts because of its enormous memory growth
(as it happens, this machine also has lots of unrelated LDAP client load).

It is rumored that various LDAP clients based on the same open source
exhibit this behaviour, and apparently the bug isn't fixed yet. Watch out!

Best regards,

Wolfgang J. Moeller moel...@gwdg.de

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany

Re: Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

[Skylar Thompson]

Thanks for reporting back. This is something we've struggled with too.
I'll have to give nscd a shot.

On 02/ 1/11 01:16 AM, Wolfgang J Moeller wrote:

Last year, I had reported ...


  on a (real big!) x86_64 machine, with freshly installed SuSE SLES 10.3,
  scanning a mere ~500k files (and typically saving  10,000 per run),
  dsmc has been found to consume about 1.3 GByte of virtual memory
  per single run. This is about tenfold from what you'd expect ...

  And even worse, in the case of running dsmc sched, the memory
  consumption is cumulative in the sense that after three runs,
  virtual memory has grown to about the maximum of ~4 GB [...]

  Sure running dsmc via the CAD is currently a work-around ... but how long?
[...]
  IBM support is rather stumped. Any ideas welcome!

After lots  lots of digging, IBM support finally came up
with the idea of testing memory usage of the UNIX function getpwuid() -
used by dsmc in order to find the files' owner name -
and it turned out that when LDAP client authorization was involved,
this function would leak ~300kB of memory_per_call_!

It also turned out that nscd (name service caching daemon) was not
running - once started, the memory leak would be experienced by nscd,
and no longer by dsmc. However, in order to keep nscd running,
it would require regular re-starts because of its enormous memory growth
(as it happens, this machine also has lots of unrelated LDAP client load).

It is rumored that various LDAP clients based on the same open source
exhibit this behaviour, and apparently the bug isn't fixed yet. Watch out!

Best regards,

Wolfgang J. Moellermoel...@gwdg.de

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany


--
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S048, (206)-685-7354
-- University of Washington School of Medicine

Re: TSM 6.2.0.0 Linux client crash

[Keith Arbogast]

This issue also affects the 6.2.1.0 client. I received the note below from a 
client admin. His is a LinuxX86 node running TSM 6.2.1.0. Has this been fixed 
in a later client?

Thank you,
Keith

--
dsmc segfaults on startup:

[r...@i136 ~]# dsmc sched
Segmentation fault
[r...@i136 ~]#

Looking at the trace for dsmc, it seems to have a problem with /etc/issue:

.
mmap2(NULL, 25462, PROT_READ, MAP_SHARED, 3, 0) = 0xf78f7000
close(3)= 0
futex(0x57fa4c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open(/dev/tty, O_RDONLY|O_LARGEFILE)  = 3
ioctl(3, SNDCTL_TMR_TEMPO or TCGETA, {B38400 opost isig icanon echo
...}) = 0
close(3)= 0
brk(0x88cd000)  = 0x88cd000
uname({sys=Linux, node=i136, ...})  = 0
open(/etc/issue, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=206, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xf78f6000
read(3, \nWelcome to India.FutureGrid.Org..., 4096) = 206
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
[r...@i136 ~]#

I removed the content from /etc/issue, and dsmc starts without problems.

Re: TSM 6.2.0.0 Linux client crash

[Richard Sims]

APAR IC67814 deals with it.

   Richard Sims

Re: Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

[Wolfgang J Moeller]

Grigori Solonovitch wrote:
 I think there is a mistake in version. If you mention 6.2.1.0, try to install 
 6.2.1.1.
 There are some bugs related to memory allocation which are fixed in 6.2.1.1.
 At least, client 6.2.1.1 helped to fix my problems with memory allocation.

Sorry for the typo. 6.2.1.1 is my current version.

My fault:
 [...]
  OTOH, do you have evidence that dsmc (meanwhile upgraded to 6.6.2.1,
should_have_been:_6.2.1.1
  without a noticable diffence in behaviour) still might contain such
  weird bugs? After all, TSM backup ought not follow symlinks at all.
 [...]

Best regards,

Wolfgang J. Moeller moel...@gwdg.de

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany

Re: Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

[Wolfgang J Moeller]

Robert Clark writes:

 Dumb question, but have you examined the client to see if there are any
 circular links?

 (For example a link low in the tree that points higher in the tree.)

To a first approximation, this doesn't seem to be the problem -
I can see the extensive memory usage even with a backup
restricted to file systems which do not contain symlinks at all.
(The whole system's symlink structure is somewhat challenging
to verify.)

OTOH, do you have evidence that dsmc (meanwhile upgraded to 6.6.2.1,
without a noticable diffence in behaviour) still might contain such
weird bugs? After all, TSM backup ought not follow symlinks at all.
Though I do remember that in olden times, circular links and stuff
would lead to dsmc aborting ... (no outright errors here, with
the client under consideration).

Best regards,

 Wolfgang J. Moellermoel...@gwdg.de

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany

Re: Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

[Grigori Solonovitch]

Ithink there is a mistake in version. If you mention 6.2.1.0, try to install 
6.2.1.1. There are some bugs related to memory allocation which are fixed in 
6.2.1.1. At least, client 6.2.1.1 helped to fix my problems with memory 
allocation.


From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Wolfgang J 
Moeller [moel...@gwdg.de]
Sent: Friday, July 16, 2010 1:30 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Excessive memory consumption by 5.5 Linux client on SLES 
10.3 x86_64

Robert Clark writes:

 Dumb question, but have you examined the client to see if there are any
 circular links?

 (For example a link low in the tree that points higher in the tree.)

To a first approximation, this doesn't seem to be the problem -
I can see the extensive memory usage even with a backup
restricted to file systems which do not contain symlinks at all.
(The whole system's symlink structure is somewhat challenging
to verify.)

OTOH, do you have evidence that dsmc (meanwhile upgraded to 6.6.2.1,
without a noticable diffence in behaviour) still might contain such
weird bugs? After all, TSM backup ought not follow symlinks at all.
Though I do remember that in olden times, circular links and stuff
would lead to dsmc aborting ... (no outright errors here, with
the client under consideration).

Best regards,

 Wolfgang J. Moellermoel...@gwdg.de

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany

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: Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

[Skylar Thompson]

I was going to go that route, but unfortunately RHEL4 isn't officially
supported with the v6 clients.

On 07/16/10 08:02, Grigori Solonovitch wrote:

Ithink there is a mistake in version. If you mention 6.2.1.0, try to install 
6.2.1.1. There are some bugs related to memory allocation which are fixed in 
6.2.1.1. At least, client 6.2.1.1 helped to fix my problems with memory 
allocation.


From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Wolfgang J 
Moeller [moel...@gwdg.de]
Sent: Friday, July 16, 2010 1:30 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Excessive memory consumption by 5.5 Linux client on SLES 
10.3 x86_64

Robert Clark writes:


Dumb question, but have you examined the client to see if there are any
circular links?

(For example a link low in the tree that points higher in the tree.)


To a first approximation, this doesn't seem to be the problem -
I can see the extensive memory usage even with a backup
restricted to file systems which do not contain symlinks at all.
(The whole system's symlink structure is somewhat challenging
to verify.)

OTOH, do you have evidence that dsmc (meanwhile upgraded to 6.6.2.1,
without a noticable diffence in behaviour) still might contain such
weird bugs? After all, TSM backup ought not follow symlinks at all.
Though I do remember that in olden times, circular links and stuff
would lead to dsmc aborting ... (no outright errors here, with
the client under consideration).

Best regards,

  Wolfgang J. Moellermoel...@gwdg.de

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany

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.


--
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S048, (206)-685-7354
-- University of Washington School of Medicine

Re: Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

[Wolfgang J Moeller]

Skylar Thompson wrote:

 I ran into something similar on RHEL4 when dealing with directories with
 lots of files (11 million in one of them - so many that ext3 b-tree
 indexing failed). I think even with MEMORYEFFICIENTBACKUP enabled, the
 client will still need to allocate enough memory to handle one directory
 at a time. Do you have any directories like that?

No, apart from a rather standard root file system - which accounts for
over 300k of the ~500k files involved, and typically makes for ~150 MB
dsmc memory consumption - the other (pretty large) files are evenly
spread over 20k directories.
And did you ever see _cumulative_ memory growth (aka memory leak?).

There got to be something pretty weird with this machine ...
I'm still working with TSM support.

 On 07/07/10 01:19, Wolfgang J Moeller wrote:
  Good morning,
 
  on a (real big!) x86_64 machine, with freshly installed SuSE SLES 10.3,
  scanning a mere ~500k files (and typically saving  10,000 per run),
  dsmc has been found to consume about 1.3 GByte of virtual memory
  per single run. This is about tenfold from what you'd expect ...
 
  And even worse, in the case of running dsmc sched, the memory
  consumption is cumulative in the sense that after three runs,
  virtual memory has grown to about the maximum of ~4 GB, so that
  the next time the scheduler ought to run, it will simply refuse
  to proceded with a cannot obtain memory message (that's how
  the problem was discovered in the first place).
 
  Reproducible with x86 Linux clients 5.5.2.7 and 5.5.1.4.
  TSM server 5.5.2.1 on AIX, in case it matters.
 
  Sure running dsmc via the CAD is currently a work-around ... but how long?
 
  Normal operation of the client system also involves a lot of 32-bit code
  (like the TSM client); I also performed a few simple 'malloc()' tests -
  no indication so far that the memory allocation was fundamentally flawed.
 
  IBM support is rather stumped. Any ideas welcome!
 
  On this particular machine, I'd rather not experiment too much
  with (potentially incompatible) client versions, unless it was known
  that a recent 6.x version did indeed solve a problem of this kind ...

---

Best regards,

Wolfgang J. Moellermoel...@gwdg.de

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany

Re: Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

[Skylar Thompson]

Yeah, for us dsmc would grow past 3GB over a couple days and then die
because of the 32-bit virtual address space limit. Our solution was to
educate users to avoid putting lots of files in one directory, and if
there was a real need to notify us so we can exclude them in advance
with exclude.dir.

On 07/15/10 07:02, Wolfgang J Moeller wrote:

Skylar Thompson wrote:


I ran into something similar on RHEL4 when dealing with directories with
lots of files (11 million in one of them - so many that ext3 b-tree
indexing failed). I think even with MEMORYEFFICIENTBACKUP enabled, the
client will still need to allocate enough memory to handle one directory
at a time. Do you have any directories like that?


No, apart from a rather standard root file system - which accounts for
over 300k of the ~500k files involved, and typically makes for ~150 MB
dsmc memory consumption - the other (pretty large) files are evenly
spread over20k directories.
And did you ever see _cumulative_ memory growth (aka memory leak?).

There got to be something pretty weird with this machine ...
I'm still working with TSM support.


--
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S048, (206)-685-7354
-- University of Washington School of Medicine

Re: Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

[Robert Clark]

Dumb question, but have you examined the client to see if there are any
circular links?

(For example a link low in the tree that points higher in the tree.)

[RC]



From:
Wolfgang J Moeller moel...@gwdg.de
To:
ADSM-L@VM.MARIST.EDU
Date:
07/15/2010 07:04 AM
Subject:
Re: [ADSM-L] Excessive memory consumption by 5.5 Linux client on SLES 10.3
x86_64
Sent by:
ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



Skylar Thompson wrote:

 I ran into something similar on RHEL4 when dealing with directories with
 lots of files (11 million in one of them - so many that ext3 b-tree
 indexing failed). I think even with MEMORYEFFICIENTBACKUP enabled, the
 client will still need to allocate enough memory to handle one directory
 at a time. Do you have any directories like that?

No, apart from a rather standard root file system - which accounts for
over 300k of the ~500k files involved, and typically makes for ~150 MB
dsmc memory consumption - the other (pretty large) files are evenly
spread over 20k directories.
And did you ever see _cumulative_ memory growth (aka memory leak?).

There got to be something pretty weird with this machine ...
I'm still working with TSM support.

 On 07/07/10 01:19, Wolfgang J Moeller wrote:
  Good morning,
 
  on a (real big!) x86_64 machine, with freshly installed SuSE SLES
10.3,
  scanning a mere ~500k files (and typically saving  10,000 per run),
  dsmc has been found to consume about 1.3 GByte of virtual memory
  per single run. This is about tenfold from what you'd expect ...
 
  And even worse, in the case of running dsmc sched, the memory
  consumption is cumulative in the sense that after three runs,
  virtual memory has grown to about the maximum of ~4 GB, so that
  the next time the scheduler ought to run, it will simply refuse
  to proceded with a cannot obtain memory message (that's how
  the problem was discovered in the first place).
 
  Reproducible with x86 Linux clients 5.5.2.7 and 5.5.1.4.
  TSM server 5.5.2.1 on AIX, in case it matters.
 
  Sure running dsmc via the CAD is currently a work-around ... but how
long?
 
  Normal operation of the client system also involves a lot of 32-bit
code
  (like the TSM client); I also performed a few simple 'malloc()' tests
-
  no indication so far that the memory allocation was fundamentally
flawed.
 
  IBM support is rather stumped. Any ideas welcome!
 
  On this particular machine, I'd rather not experiment too much
  with (potentially incompatible) client versions, unless it was known
  that a recent 6.x version did indeed solve a problem of this kind ...

---

Best regards,

 Wolfgang J. Moellermoel...@gwdg.de

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany



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: Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

[Skylar Thompson]

I ran into something similar on RHEL4 when dealing with directories with
lots of files (11 million in one of them - so many that ext3 b-tree
indexing failed). I think even with MEMORYEFFICIENTBACKUP enabled, the
client will still need to allocate enough memory to handle one directory
at a time. Do you have any directories like that?

On 07/07/10 01:19, Wolfgang J Moeller wrote:

Good morning,

on a (real big!) x86_64 machine, with freshly installed SuSE SLES 10.3,
scanning a mere ~500k files (and typically saving  10,000 per run),
dsmc has been found to consume about 1.3 GByte of virtual memory
per single run. This is about tenfold from what you'd expect ...

And even worse, in the case of running dsmc sched, the memory
consumption is cumulative in the sense that after three runs,
virtual memory has grown to about the maximum of ~4 GB, so that
the next time the scheduler ought to run, it will simply refuse
to proceded with a cannot obtain memory message (that's how
the problem was discovered in the first place).

Reproducible with x86 Linux clients 5.5.2.7 and 5.5.1.4.
TSM server 5.5.2.1 on AIX, in case it matters.

Sure running dsmc via the CAD is currently a work-around ... but how long?

Normal operation of the client system also involves a lot of 32-bit code
(like the TSM client); I also performed a few simple 'malloc()' tests -
no indication so far that the memory allocation was fundamentally flawed.

IBM support is rather stumped. Any ideas welcome!

On this particular machine, I'd rather not experiment too much
with (potentially incompatible) client versions, unless it was known
that a recent 6.x version did indeed solve a problem of this kind ...

Best regards,

Wolfgang J. Moellermoel...@gwdg.de

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany


--
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S048, (206)-685-7354
-- University of Washington School of Medicine

6.2.1.1 Linux client missing gsk rpms

[Zoltan Forray/AC/VCU]

Can someone with IBM can get this to the folks that packaged the latest
client patches.

I downloaded 6.2.1.1 for Linux, to get the fix for the /etc/issue problem.
 Sent it to my Linux client that discovered the problem, for verification.

I was wondering why 6.2.1.1 was 15mb smaller than 6.2.1.0.  Here us what
my Linux guy said:

6.2.1.1 is 15mb smaller because it does not contain the gsk*.rpm files,
so you have to download and untar 6.2.1.0-TIV-TSMBAC-LinuxX86.tar first,
then download and untar 6.2.1.1-TIV-TSMBAC-LinuxX86.tar which overwrites
the TIVsm-API.i386.rpm TIVsm-API64.i386.rpm TIVsm-BA.i386.rpm and
TIVsm-HSM.i386.rpm files

Considering that the gsk* libraries are mandatory, they should be with the
package.
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

Excessive memory consumption by 5.5 Linux client on SLES 10.3 x86_64

[Wolfgang J Moeller]

Good morning,

on a (real big!) x86_64 machine, with freshly installed SuSE SLES 10.3,
scanning a mere ~500k files (and typically saving  10,000 per run),
dsmc has been found to consume about 1.3 GByte of virtual memory
per single run. This is about tenfold from what you'd expect ...

And even worse, in the case of running dsmc sched, the memory
consumption is cumulative in the sense that after three runs,
virtual memory has grown to about the maximum of ~4 GB, so that
the next time the scheduler ought to run, it will simply refuse
to proceded with a cannot obtain memory message (that's how
the problem was discovered in the first place).

Reproducible with x86 Linux clients 5.5.2.7 and 5.5.1.4.
TSM server 5.5.2.1 on AIX, in case it matters.

Sure running dsmc via the CAD is currently a work-around ... but how long?

Normal operation of the client system also involves a lot of 32-bit code
(like the TSM client); I also performed a few simple 'malloc()' tests -
no indication so far that the memory allocation was fundamentally flawed.

IBM support is rather stumped. Any ideas welcome!

On this particular machine, I'd rather not experiment too much
with (potentially incompatible) client versions, unless it was known
that a recent 6.x version did indeed solve a problem of this kind ...

Best regards,

Wolfgang J. Moeller moel...@gwdg.de

Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany

Re: Linux Client failing with ANS1999E error

[James Choate]

Andrew,
Thanks for your help.
'/public/proval-old' was the culprit.
We are now backing up without errors.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Andrew 
Raibeck
Sent: Tuesday, April 20, 2010 6:17 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Linux Client failing with ANS1999E error

I suspect the error occurs when the backup-archive client attempts to stat
the file system.

Are you able to successfully stat this file system?

 stat /public/proval-old

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-04-19
17:40:57:

 [image removed]

 Re: Linux Client failing with ANS1999E error

 James Choate

 to:

 ADSM-L

 2010-04-19 21:09

 Sent by:

 ADSM: Dist Stor Manager ADSM-L@vm.marist.edu

 Please respond to ADSM: Dist Stor Manager

 I just ran an fsck on /public/proval-old, No errors were found on that
mount.

 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On
 Behalf Of Ben Bullock
 Sent: Monday, April 19, 2010 10:25 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: Re: Linux Client failing with ANS1999E error

 I have seen something like this before. I would guess that according
 to the log, that something is corrupt in '/public/proval-old' .
 Perhaps a bad inode, invalid file name or just plain corrupt file. I
 would do some 'ls -l' in and around that directory looking for a bad
file.

 TSM backups are great for sniffing out filesystem problems. ;-)

 Ben


 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On
 Behalf Of James Choate
 Sent: Monday, April 19, 2010 9:46 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: Re: [ADSM-L] Linux Client failing with ANS1999E error

 04/19/2010 08:38:26
 
 04/19/2010 08:38:26 Schedule Name: TEST_SCHEDULE
 04/19/2010 08:38:26 Action:Incremental
 04/19/2010 08:38:26 Objects:
 04/19/2010 08:38:26 Options:
 04/19/2010 08:38:26 Server Window Start:   08:40:00 on 04/19/2010
 04/19/2010 08:38:26
 
 04/19/2010 08:38:26 Command will be executed in 18 minutes.
 04/19/2010 08:56:26
 Executing scheduled command now.
 04/19/2010 08:56:26 Node Name: CLLINUX1 04/19/2010 08:56:26 Session
 established with server TSMSRV1: Windows
 04/19/2010 08:56:26   Server Version 5, Release 5, Level 0.0
 04/19/2010 08:56:26   Server date/time: 04/19/2010 08:56:26  Last
 access: 04/19/2010 08:38:26

 04/19/2010 08:56:26 --- SCHEDULEREC OBJECT BEGIN TEST_SCHEDULE 04/
 19/2010 08:40:00 04/19/2010 08:56:27 Incremental backup of volume '/'
 04/19/2010 08:56:27 Incremental backup of volume '/boot'
 04/19/2010 08:56:27 Incremental backup of volume '/public'
 04/19/2010 08:56:27 Incremental backup of volume '/pictometry'
 04/19/2010 08:56:27 Incremental backup of volume '/public/proval-old'
 04/19/2010 08:56:28 ANS1115W File '/public/proval-old' excluded by
 Include/Exclude list 04/19/2010 08:56:28 Successful incremental
 backup of '/public/proval-old'

 04/19/2010 08:56:28 ANS1999E Incremental processing of '/' stopped.

 04/19/2010 08:56:28 --- SCHEDULEREC STATUS BEGIN
 04/19/2010 08:56:28 Total number of objects inspected:1
 04/19/2010 08:56:28 Total number of objects backed up:0
 04/19/2010 08:56:28 Total number of objects updated:  0
 04/19/2010 08:56:28 Total number of objects rebound:  0
 04/19/2010 08:56:28 Total number of objects deleted:  0
 04/19/2010 08:56:28 Total number of objects expired:  0
 04/19/2010 08:56:28 Total number of objects failed:   0
 04/19/2010 08:56:28 Total number of bytes transferred:   0  B
 04/19/2010 08:56:28 Data transfer time:0.00 sec
 04/19/2010 08:56:28 Network data transfer rate:0.00 KB/sec
 04/19/2010 08:56:28 Aggregate data transfer rate:  0.00 KB/sec
 04/19/2010 08:56:28 Objects compressed by:0%
 04/19/2010 08:56:28 Elapsed processing time:   00:00:01
 04/19/2010 08:56:28 --- SCHEDULEREC STATUS END 04/19/2010 08:56:28
 ANS1028S An internal program error occurred.
 04/19/2010 08:56:28 --- SCHEDULEREC OBJECT END TEST_SCHEDULE 04/19/
 2010 08:40:00 04/19/2010 08:56:28 ANS1512E Scheduled event
 'TEST_SCHEDULE' failed.
 Return code = 12.
 04/19/2010 08:56:28 Sending results for scheduled event 'TEST_SCHEDULE'.
 04/19/2010 08:56:28 Results sent to server for scheduled event
 'TEST_SCHEDULE'.

 04/19/2010 08:56:28 ANS1483I

Re: Linux Client failing with ANS1999E error

[Richard Sims]

On Apr 19, 2010, at 5:41 PM, James Choate wrote:

 I am looking for the longest fully qualified file name on the system.
 
 An error=6 might be indicating ENAMETOOLONG (The only errno that equals 6 in 
 Linux).

Errno 6 is ENXIO.  FWIW, I've accumulated some notes on it over time...

ENXIO   6   No such device or address.
Typically, this means that a file representing a device
has been installed incorrectly, and the system can't
find the right kind of device driver for it.
Is expected if opening a FIFO for writing with the
O_NDELAY flag, thus indicating that no process yet has
the FIFO open for reading.
I/O on a special file refers to a subdevice that does
not exist, or beyond the limits of the device. It may
also occur when, for example, an illegal tape drive unit
number is selected or a disk pack is not loaded on a
drive.  Also seen when trying to open /dev/lmcp0 and the
/etc/lmcpd daemon is not running.
When the operation involves access to memory areas
(e.g., /dev/kmem) it may be that the address/offset
being used is out of range. (Interestingly, an lseek()
or lseek64() to a bogus address will not complain, but
the following read() which depends upon that seek will
fail.)

  Richard Simshttp://people.bu.edu/rbs/

Re: Linux Client failing with ANS1999E error

[Andrew Raibeck]

I suspect the error occurs when the backup-archive client attempts to stat
the file system.

Are you able to successfully stat this file system?

 stat /public/proval-old

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-04-19
17:40:57:

 [image removed]

 Re: Linux Client failing with ANS1999E error

 James Choate

 to:

 ADSM-L

 2010-04-19 21:09

 Sent by:

 ADSM: Dist Stor Manager ADSM-L@vm.marist.edu

 Please respond to ADSM: Dist Stor Manager

 I just ran an fsck on /public/proval-old, No errors were found on that
mount.

 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On
 Behalf Of Ben Bullock
 Sent: Monday, April 19, 2010 10:25 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: Re: Linux Client failing with ANS1999E error

 I have seen something like this before. I would guess that according
 to the log, that something is corrupt in '/public/proval-old' .
 Perhaps a bad inode, invalid file name or just plain corrupt file. I
 would do some 'ls -l' in and around that directory looking for a bad
file.

 TSM backups are great for sniffing out filesystem problems. ;-)

 Ben


 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On
 Behalf Of James Choate
 Sent: Monday, April 19, 2010 9:46 AM
 To: ADSM-L@VM.MARIST.EDU
 Subject: Re: [ADSM-L] Linux Client failing with ANS1999E error

 04/19/2010 08:38:26
 
 04/19/2010 08:38:26 Schedule Name: TEST_SCHEDULE
 04/19/2010 08:38:26 Action:Incremental
 04/19/2010 08:38:26 Objects:
 04/19/2010 08:38:26 Options:
 04/19/2010 08:38:26 Server Window Start:   08:40:00 on 04/19/2010
 04/19/2010 08:38:26
 
 04/19/2010 08:38:26 Command will be executed in 18 minutes.
 04/19/2010 08:56:26
 Executing scheduled command now.
 04/19/2010 08:56:26 Node Name: CLLINUX1 04/19/2010 08:56:26 Session
 established with server TSMSRV1: Windows
 04/19/2010 08:56:26   Server Version 5, Release 5, Level 0.0
 04/19/2010 08:56:26   Server date/time: 04/19/2010 08:56:26  Last
 access: 04/19/2010 08:38:26

 04/19/2010 08:56:26 --- SCHEDULEREC OBJECT BEGIN TEST_SCHEDULE 04/
 19/2010 08:40:00 04/19/2010 08:56:27 Incremental backup of volume '/'
 04/19/2010 08:56:27 Incremental backup of volume '/boot'
 04/19/2010 08:56:27 Incremental backup of volume '/public'
 04/19/2010 08:56:27 Incremental backup of volume '/pictometry'
 04/19/2010 08:56:27 Incremental backup of volume '/public/proval-old'
 04/19/2010 08:56:28 ANS1115W File '/public/proval-old' excluded by
 Include/Exclude list 04/19/2010 08:56:28 Successful incremental
 backup of '/public/proval-old'

 04/19/2010 08:56:28 ANS1999E Incremental processing of '/' stopped.

 04/19/2010 08:56:28 --- SCHEDULEREC STATUS BEGIN
 04/19/2010 08:56:28 Total number of objects inspected:1
 04/19/2010 08:56:28 Total number of objects backed up:0
 04/19/2010 08:56:28 Total number of objects updated:  0
 04/19/2010 08:56:28 Total number of objects rebound:  0
 04/19/2010 08:56:28 Total number of objects deleted:  0
 04/19/2010 08:56:28 Total number of objects expired:  0
 04/19/2010 08:56:28 Total number of objects failed:   0
 04/19/2010 08:56:28 Total number of bytes transferred:   0  B
 04/19/2010 08:56:28 Data transfer time:0.00 sec
 04/19/2010 08:56:28 Network data transfer rate:0.00 KB/sec
 04/19/2010 08:56:28 Aggregate data transfer rate:  0.00 KB/sec
 04/19/2010 08:56:28 Objects compressed by:0%
 04/19/2010 08:56:28 Elapsed processing time:   00:00:01
 04/19/2010 08:56:28 --- SCHEDULEREC STATUS END 04/19/2010 08:56:28
 ANS1028S An internal program error occurred.
 04/19/2010 08:56:28 --- SCHEDULEREC OBJECT END TEST_SCHEDULE 04/19/
 2010 08:40:00 04/19/2010 08:56:28 ANS1512E Scheduled event
 'TEST_SCHEDULE' failed.
 Return code = 12.
 04/19/2010 08:56:28 Sending results for scheduled event 'TEST_SCHEDULE'.
 04/19/2010 08:56:28 Results sent to server for scheduled event
 'TEST_SCHEDULE'.

 04/19/2010 08:56:28 ANS1483I Schedule log pruning started.
 04/19/2010 08:56:28 ANS1484I Schedule log pruning finished successfully.
 04/19/2010 08:56:28 TSM Backup-Archive Client Version 5, Release 5,
 Level 2.0 04/19/2010 08:56:28 Querying server for next scheduled event.
 04/19/2010 08:56:28 Node Name: CLLINUX1 04/19/2010 08:56:28 Session
 established with server

Re: Linux Client failing with ANS1999E error

[Lindsay Morris]

Ben said
TSM backups are great for sniffing out filesystem problems. ;-)

I would add and network problems, and application problems , and database
performance problems ...

The TSM admin is like the canary in the coal mine.
(Wait, that's a terrible analogy .. they end up dead...)


Lindsay Morris
CEO, TSMworks
Tel. 1-859-539-9900
lind...@tsmworks.com

Re: Linux Client failing with ANS1999E error

[Allen S. Rout]

 On Tue, 20 Apr 2010 08:39:11 -0400, Lindsay Morris lind...@tsmworks.com 
 said:

 The TSM admin is like the canary in the coal mine.
 (Wait, that's a terrible analogy .. they end up dead...)


Terrible because it's inaccurate, or terrible because we don't like
the implications?

Your viewers want to know. :)

- Allen S. Rout

Re: Linux Client failing with ANS1999E error

[Richard Sims]

Jim -

That evidence says that the warranted changes have not been made to
the client to correct the initially reported problems, which
continue.  A thorough review of that client should be conducted,
starting with 'dsmc query option' and 'dsmc query inclexcl', as the
administration of that client are not what they should be.

Richard Sims

Re: Linux Client failing with ANS1999E error

[Richard Sims]

On Apr 19, 2010, at 6:22 AM, Richard Sims wrote:


Jim -

That evidence says that the warranted changes have not been made to
the client to correct the initially reported problems, which
continue.  A thorough review of that client should be conducted,
starting with 'dsmc query option' and 'dsmc query inclexcl', as the
administration of that client are not what they should be.



One further thing - which the client administrator should already know:
If changes *were* made to the client options file, and its scheduling
is *not* being performed via CAD, then obviously the scheduler should
have been restarted after client options file changes for them to be
in effect.

   Richard Sims

Re: Linux Client failing with ANS1999E error

[James Choate]

04/19/2010 08:38:26

04/19/2010 08:38:26 Schedule Name: TEST_SCHEDULE
04/19/2010 08:38:26 Action:Incremental
04/19/2010 08:38:26 Objects:
04/19/2010 08:38:26 Options:
04/19/2010 08:38:26 Server Window Start:   08:40:00 on 04/19/2010
04/19/2010 08:38:26

04/19/2010 08:38:26 Command will be executed in 18 minutes.
04/19/2010 08:56:26
Executing scheduled command now.
04/19/2010 08:56:26 Node Name: CLLINUX1 04/19/2010 08:56:26 Session established 
with server TSMSRV1: Windows
04/19/2010 08:56:26   Server Version 5, Release 5, Level 0.0
04/19/2010 08:56:26   Server date/time: 04/19/2010 08:56:26  Last
access: 04/19/2010 08:38:26

04/19/2010 08:56:26 --- SCHEDULEREC OBJECT BEGIN TEST_SCHEDULE 04/19/2010 
08:40:00 04/19/2010 08:56:27 Incremental backup of volume '/'
04/19/2010 08:56:27 Incremental backup of volume '/boot'
04/19/2010 08:56:27 Incremental backup of volume '/public'
04/19/2010 08:56:27 Incremental backup of volume '/pictometry'
04/19/2010 08:56:27 Incremental backup of volume '/public/proval-old'
04/19/2010 08:56:28 ANS1115W File '/public/proval-old' excluded by 
Include/Exclude list 04/19/2010 08:56:28 Successful incremental backup of 
'/public/proval-old'

04/19/2010 08:56:28 ANS1999E Incremental processing of '/' stopped.

04/19/2010 08:56:28 --- SCHEDULEREC STATUS BEGIN
04/19/2010 08:56:28 Total number of objects inspected:1
04/19/2010 08:56:28 Total number of objects backed up:0
04/19/2010 08:56:28 Total number of objects updated:  0
04/19/2010 08:56:28 Total number of objects rebound:  0
04/19/2010 08:56:28 Total number of objects deleted:  0
04/19/2010 08:56:28 Total number of objects expired:  0
04/19/2010 08:56:28 Total number of objects failed:   0
04/19/2010 08:56:28 Total number of bytes transferred:   0  B
04/19/2010 08:56:28 Data transfer time:0.00 sec
04/19/2010 08:56:28 Network data transfer rate:0.00 KB/sec
04/19/2010 08:56:28 Aggregate data transfer rate:  0.00 KB/sec
04/19/2010 08:56:28 Objects compressed by:0%
04/19/2010 08:56:28 Elapsed processing time:   00:00:01
04/19/2010 08:56:28 --- SCHEDULEREC STATUS END 04/19/2010 08:56:28 ANS1028S An 
internal program error occurred.
04/19/2010 08:56:28 --- SCHEDULEREC OBJECT END TEST_SCHEDULE 04/19/2010 
08:40:00 04/19/2010 08:56:28 ANS1512E Scheduled event 'TEST_SCHEDULE' failed.
Return code = 12.
04/19/2010 08:56:28 Sending results for scheduled event 'TEST_SCHEDULE'.
04/19/2010 08:56:28 Results sent to server for scheduled event 'TEST_SCHEDULE'.

04/19/2010 08:56:28 ANS1483I Schedule log pruning started.
04/19/2010 08:56:28 ANS1484I Schedule log pruning finished successfully.
04/19/2010 08:56:28 TSM Backup-Archive Client Version 5, Release 5, Level 2.0 
04/19/2010 08:56:28 Querying server for next scheduled event.
04/19/2010 08:56:28 Node Name: CLLINUX1 04/19/2010 08:56:28 Session established 
with server TSMSRV1: Windows
04/19/2010 08:56:28   Server Version 5, Release 5, Level 0.0
04/19/2010 08:56:28   Server date/time: 04/19/2010 08:56:28  Last
access: 04/19/2010 08:56:28

04/19/2010 08:56:28 --- SCHEDULEREC QUERY BEGIN 04/19/2010 08:56:28 --- 
SCHEDULEREC QUERY END 04/19/2010 08:56:28 Next operation scheduled:
04/19/2010 08:56:28

04/19/2010 08:56:28 Schedule Name: TEST_SCHEDULE
04/19/2010 08:56:28 Action:Incremental
04/19/2010 08:56:28 Objects:
04/19/2010 08:56:28 Options:
04/19/2010 08:56:28 Server Window Start:   08:40:00 on 04/20/2010
04/19/2010 08:56:28

04/19/2010 08:56:28 Schedule will be refreshed in 6 hours.

This is the info from dmserror.log for this run.
04/19/2010 08:35:34 ANS2820E An interrupt has occurred. The current operation 
will end and the client will shut down.
04/19/2010 08:36:12 ANS2820E An interrupt has occurred. The current operation 
will end and the client will shut down.
04/19/2010 08:36:49 ANS2820E An interrupt has occurred. The current operation 
will end and the client will shut down.
04/19/2010 08:38:24 ANS2820E An interrupt has occurred. The current operation 
will end and the client will shut down.
04/19/2010 08:56:27 TransErrno: Unexpected error from GetFSInfo:stat, errno = 6 
04/19/2010 08:56:27 TransErrno: Unexpected error from GetFSInfo:stat, errno = 6 
04/19/2010 08:56:28 TransErrno: Unexpected error from GetFSInfo:stat, errno = 6 
04/19/2010 08:56:28 TransErrno: Unexpected error from GetFSInfo:stat, errno = 6 
04/19/2010 08:56:28 TransErrno: Unexpected error from lstat, errno = 6 
04/19/2010 08:56:28 TransErrno: Unexpected error from GetFSInfo:stat, errno = 6 
04/19/2010 08:56:28 TransErrno: Unexpected error from GetFSInfo:stat, errno = 6 
04/19/2010 08:56:28 ANS1115W File 

Re: Linux Client failing with ANS1999E error

[Ben Bullock]

I have seen something like this before. I would guess that according to the 
log, that something is corrupt in '/public/proval-old' . Perhaps a bad inode, 
invalid file name or just plain corrupt file. I would do some 'ls -l' in and 
around that directory looking for a bad file.

TSM backups are great for sniffing out filesystem problems. ;-)

Ben
 

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of James 
Choate
Sent: Monday, April 19, 2010 9:46 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Linux Client failing with ANS1999E error

04/19/2010 08:38:26

04/19/2010 08:38:26 Schedule Name: TEST_SCHEDULE
04/19/2010 08:38:26 Action:Incremental
04/19/2010 08:38:26 Objects:
04/19/2010 08:38:26 Options:
04/19/2010 08:38:26 Server Window Start:   08:40:00 on 04/19/2010
04/19/2010 08:38:26

04/19/2010 08:38:26 Command will be executed in 18 minutes.
04/19/2010 08:56:26
Executing scheduled command now.
04/19/2010 08:56:26 Node Name: CLLINUX1 04/19/2010 08:56:26 Session established 
with server TSMSRV1: Windows
04/19/2010 08:56:26   Server Version 5, Release 5, Level 0.0
04/19/2010 08:56:26   Server date/time: 04/19/2010 08:56:26  Last
access: 04/19/2010 08:38:26

04/19/2010 08:56:26 --- SCHEDULEREC OBJECT BEGIN TEST_SCHEDULE 04/19/2010 
08:40:00 04/19/2010 08:56:27 Incremental backup of volume '/'
04/19/2010 08:56:27 Incremental backup of volume '/boot'
04/19/2010 08:56:27 Incremental backup of volume '/public'
04/19/2010 08:56:27 Incremental backup of volume '/pictometry'
04/19/2010 08:56:27 Incremental backup of volume '/public/proval-old'
04/19/2010 08:56:28 ANS1115W File '/public/proval-old' excluded by 
Include/Exclude list 04/19/2010 08:56:28 Successful incremental backup of 
'/public/proval-old'

04/19/2010 08:56:28 ANS1999E Incremental processing of '/' stopped.

04/19/2010 08:56:28 --- SCHEDULEREC STATUS BEGIN
04/19/2010 08:56:28 Total number of objects inspected:1
04/19/2010 08:56:28 Total number of objects backed up:0
04/19/2010 08:56:28 Total number of objects updated:  0
04/19/2010 08:56:28 Total number of objects rebound:  0
04/19/2010 08:56:28 Total number of objects deleted:  0
04/19/2010 08:56:28 Total number of objects expired:  0
04/19/2010 08:56:28 Total number of objects failed:   0
04/19/2010 08:56:28 Total number of bytes transferred:   0  B
04/19/2010 08:56:28 Data transfer time:0.00 sec
04/19/2010 08:56:28 Network data transfer rate:0.00 KB/sec
04/19/2010 08:56:28 Aggregate data transfer rate:  0.00 KB/sec
04/19/2010 08:56:28 Objects compressed by:0%
04/19/2010 08:56:28 Elapsed processing time:   00:00:01
04/19/2010 08:56:28 --- SCHEDULEREC STATUS END 04/19/2010 08:56:28 ANS1028S An 
internal program error occurred.
04/19/2010 08:56:28 --- SCHEDULEREC OBJECT END TEST_SCHEDULE 04/19/2010 
08:40:00 04/19/2010 08:56:28 ANS1512E Scheduled event 'TEST_SCHEDULE' failed.
Return code = 12.
04/19/2010 08:56:28 Sending results for scheduled event 'TEST_SCHEDULE'.
04/19/2010 08:56:28 Results sent to server for scheduled event 'TEST_SCHEDULE'.

04/19/2010 08:56:28 ANS1483I Schedule log pruning started.
04/19/2010 08:56:28 ANS1484I Schedule log pruning finished successfully.
04/19/2010 08:56:28 TSM Backup-Archive Client Version 5, Release 5, Level 2.0 
04/19/2010 08:56:28 Querying server for next scheduled event.
04/19/2010 08:56:28 Node Name: CLLINUX1 04/19/2010 08:56:28 Session established 
with server TSMSRV1: Windows
04/19/2010 08:56:28   Server Version 5, Release 5, Level 0.0
04/19/2010 08:56:28   Server date/time: 04/19/2010 08:56:28  Last
access: 04/19/2010 08:56:28

04/19/2010 08:56:28 --- SCHEDULEREC QUERY BEGIN 04/19/2010 08:56:28 --- 
SCHEDULEREC QUERY END 04/19/2010 08:56:28 Next operation scheduled:
04/19/2010 08:56:28

04/19/2010 08:56:28 Schedule Name: TEST_SCHEDULE
04/19/2010 08:56:28 Action:Incremental
04/19/2010 08:56:28 Objects:
04/19/2010 08:56:28 Options:
04/19/2010 08:56:28 Server Window Start:   08:40:00 on 04/20/2010
04/19/2010 08:56:28

04/19/2010 08:56:28 Schedule will be refreshed in 6 hours.

This is the info from dmserror.log for this run.
04/19/2010 08:35:34 ANS2820E An interrupt has occurred. The current operation 
will end and the client will shut down.
04/19/2010 08:36:12 ANS2820E An interrupt has occurred. The current operation 
will end and the client will shut down.
04/19/2010 08:36:49 ANS2820E An interrupt has occurred. The current operation 
will end and the client will shut down.
04/19/2010 08:38:24 ANS2820E An interrupt has occurred. The current operation 
will end and the client will shut down.
04/19

Re: Linux Client failing with ANS1999E error

[Richard Sims]

On Apr 19, 2010, at 11:45 AM, James Choate wrote:


04/19/2010 08:56:26 --- SCHEDULEREC OBJECT BEGIN TEST_SCHEDULE
04/19/2010 08:40:00 04/19/2010 08:56:27 Incremental backup of volume
'/'
04/19/2010 08:56:27 Incremental backup of volume '/boot'
04/19/2010 08:56:27 Incremental backup of volume '/public'
04/19/2010 08:56:27 Incremental backup of volume '/pictometry'
04/19/2010 08:56:27 Incremental backup of volume '/public/proval-old'
04/19/2010 08:56:28 ANS1115W File '/public/proval-old' excluded by
Include/Exclude list 04/19/2010 08:56:28 Successful incremental
backup of '/public/proval-old'


Jim -

In my April 16th response I suggested that the /public/proval-old file
system object be examined to determine exactly what it is, and if
there is anything wrong with it.  That still needs to be done.  It is
very odd that it should be included in Incremental backup of volume
messages, as those reflect Domain statements in your client options;
and you already have a /public in there, which on the surface of it
would preclude having a /public/proval-old (whose name suggests that
the word approval maybe should have been in there).  And having /
boot identified as a separate file system doesn't seem right for a
Linux system, where /boot is normally a subdirectory in the root volume.

I would recommend a full review of the client options (which may be on
the TSM client and server), to remove inappropriate Virtualmountpoint
specifications (along with proper obsolescence of the corresponding
filespaces on the TSM server).  Things just aren't right on that
client system.

   Richard Sims

Re: Linux Client failing with ANS1999E error

[Shawn Drew]

It seems to me that /public/proval-old is a filesystem of some sort since
there was no other virtualmountpoint messages.   Maybe it's a loopback
mount or something?

Try putting this in there to exclude it:
exclude.fs /public/proval-old

If that doesn't work, provide the output of a df

If it does work, it would just be a workaround for something weird going
on with your filesystems.

Regards,
Shawn

Shawn Drew





Internet
r...@bu.edu

Sent by: ADSM-L@VM.MARIST.EDU
04/19/2010 12:31 PM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Linux Client failing with ANS1999E error






On Apr 19, 2010, at 11:45 AM, James Choate wrote:

 04/19/2010 08:56:26 --- SCHEDULEREC OBJECT BEGIN TEST_SCHEDULE
 04/19/2010 08:40:00 04/19/2010 08:56:27 Incremental backup of volume
 '/'
 04/19/2010 08:56:27 Incremental backup of volume '/boot'
 04/19/2010 08:56:27 Incremental backup of volume '/public'
 04/19/2010 08:56:27 Incremental backup of volume '/pictometry'
 04/19/2010 08:56:27 Incremental backup of volume '/public/proval-old'
 04/19/2010 08:56:28 ANS1115W File '/public/proval-old' excluded by
 Include/Exclude list 04/19/2010 08:56:28 Successful incremental
 backup of '/public/proval-old'

Jim -

In my April 16th response I suggested that the /public/proval-old file
system object be examined to determine exactly what it is, and if
there is anything wrong with it.  That still needs to be done.  It is
very odd that it should be included in Incremental backup of volume
messages, as those reflect Domain statements in your client options;
and you already have a /public in there, which on the surface of it
would preclude having a /public/proval-old (whose name suggests that
the word approval maybe should have been in there).  And having /
boot identified as a separate file system doesn't seem right for a
Linux system, where /boot is normally a subdirectory in the root volume.

I would recommend a full review of the client options (which may be on
the TSM client and server), to remove inappropriate Virtualmountpoint
specifications (along with proper obsolescence of the corresponding
filespaces on the TSM server).  Things just aren't right on that
client system.

Richard Sims



This message and any attachments (the message) is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.

Re: Linux Client failing with ANS1999E error

[James Choate]

I am looking for the longest fully qualified file name on the system.

An error=6 might be indicating ENAMETOOLONG (The only errno that equals 6 in 
Linux).

Repeated runs (manual) today have resulting in the exact same result.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of 
Richard Sims
Sent: Monday, April 19, 2010 10:31 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Linux Client failing with ANS1999E error

On Apr 19, 2010, at 11:45 AM, James Choate wrote:

 04/19/2010 08:56:26 --- SCHEDULEREC OBJECT BEGIN TEST_SCHEDULE
 04/19/2010 08:40:00 04/19/2010 08:56:27 Incremental backup of volume
 '/'
 04/19/2010 08:56:27 Incremental backup of volume '/boot'
 04/19/2010 08:56:27 Incremental backup of volume '/public'
 04/19/2010 08:56:27 Incremental backup of volume '/pictometry'
 04/19/2010 08:56:27 Incremental backup of volume '/public/proval-old'
 04/19/2010 08:56:28 ANS1115W File '/public/proval-old' excluded by
 Include/Exclude list 04/19/2010 08:56:28 Successful incremental
 backup of '/public/proval-old'

Jim -

In my April 16th response I suggested that the /public/proval-old file
system object be examined to determine exactly what it is, and if
there is anything wrong with it.  That still needs to be done.  It is
very odd that it should be included in Incremental backup of volume
messages, as those reflect Domain statements in your client options;
and you already have a /public in there, which on the surface of it
would preclude having a /public/proval-old (whose name suggests that
the word approval maybe should have been in there).  And having /
boot identified as a separate file system doesn't seem right for a
Linux system, where /boot is normally a subdirectory in the root volume.

I would recommend a full review of the client options (which may be on
the TSM client and server), to remove inappropriate Virtualmountpoint
specifications (along with proper obsolescence of the corresponding
filespaces on the TSM server).  Things just aren't right on that
client system.

Richard Sims

Re: Linux Client failing with ANS1999E error

[James Choate]

I just ran an fsck on /public/proval-old, No errors were found on that mount.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Ben 
Bullock
Sent: Monday, April 19, 2010 10:25 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Linux Client failing with ANS1999E error

I have seen something like this before. I would guess that according to the 
log, that something is corrupt in '/public/proval-old' . Perhaps a bad inode, 
invalid file name or just plain corrupt file. I would do some 'ls -l' in and 
around that directory looking for a bad file.

TSM backups are great for sniffing out filesystem problems. ;-)

Ben


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of James 
Choate
Sent: Monday, April 19, 2010 9:46 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Linux Client failing with ANS1999E error

04/19/2010 08:38:26

04/19/2010 08:38:26 Schedule Name: TEST_SCHEDULE
04/19/2010 08:38:26 Action:Incremental
04/19/2010 08:38:26 Objects:
04/19/2010 08:38:26 Options:
04/19/2010 08:38:26 Server Window Start:   08:40:00 on 04/19/2010
04/19/2010 08:38:26

04/19/2010 08:38:26 Command will be executed in 18 minutes.
04/19/2010 08:56:26
Executing scheduled command now.
04/19/2010 08:56:26 Node Name: CLLINUX1 04/19/2010 08:56:26 Session established 
with server TSMSRV1: Windows
04/19/2010 08:56:26   Server Version 5, Release 5, Level 0.0
04/19/2010 08:56:26   Server date/time: 04/19/2010 08:56:26  Last
access: 04/19/2010 08:38:26

04/19/2010 08:56:26 --- SCHEDULEREC OBJECT BEGIN TEST_SCHEDULE 04/19/2010 
08:40:00 04/19/2010 08:56:27 Incremental backup of volume '/'
04/19/2010 08:56:27 Incremental backup of volume '/boot'
04/19/2010 08:56:27 Incremental backup of volume '/public'
04/19/2010 08:56:27 Incremental backup of volume '/pictometry'
04/19/2010 08:56:27 Incremental backup of volume '/public/proval-old'
04/19/2010 08:56:28 ANS1115W File '/public/proval-old' excluded by 
Include/Exclude list 04/19/2010 08:56:28 Successful incremental backup of 
'/public/proval-old'

04/19/2010 08:56:28 ANS1999E Incremental processing of '/' stopped.

04/19/2010 08:56:28 --- SCHEDULEREC STATUS BEGIN
04/19/2010 08:56:28 Total number of objects inspected:1
04/19/2010 08:56:28 Total number of objects backed up:0
04/19/2010 08:56:28 Total number of objects updated:  0
04/19/2010 08:56:28 Total number of objects rebound:  0
04/19/2010 08:56:28 Total number of objects deleted:  0
04/19/2010 08:56:28 Total number of objects expired:  0
04/19/2010 08:56:28 Total number of objects failed:   0
04/19/2010 08:56:28 Total number of bytes transferred:   0  B
04/19/2010 08:56:28 Data transfer time:0.00 sec
04/19/2010 08:56:28 Network data transfer rate:0.00 KB/sec
04/19/2010 08:56:28 Aggregate data transfer rate:  0.00 KB/sec
04/19/2010 08:56:28 Objects compressed by:0%
04/19/2010 08:56:28 Elapsed processing time:   00:00:01
04/19/2010 08:56:28 --- SCHEDULEREC STATUS END 04/19/2010 08:56:28 ANS1028S An 
internal program error occurred.
04/19/2010 08:56:28 --- SCHEDULEREC OBJECT END TEST_SCHEDULE 04/19/2010 
08:40:00 04/19/2010 08:56:28 ANS1512E Scheduled event 'TEST_SCHEDULE' failed.
Return code = 12.
04/19/2010 08:56:28 Sending results for scheduled event 'TEST_SCHEDULE'.
04/19/2010 08:56:28 Results sent to server for scheduled event 'TEST_SCHEDULE'.

04/19/2010 08:56:28 ANS1483I Schedule log pruning started.
04/19/2010 08:56:28 ANS1484I Schedule log pruning finished successfully.
04/19/2010 08:56:28 TSM Backup-Archive Client Version 5, Release 5, Level 2.0 
04/19/2010 08:56:28 Querying server for next scheduled event.
04/19/2010 08:56:28 Node Name: CLLINUX1 04/19/2010 08:56:28 Session established 
with server TSMSRV1: Windows
04/19/2010 08:56:28   Server Version 5, Release 5, Level 0.0
04/19/2010 08:56:28   Server date/time: 04/19/2010 08:56:28  Last
access: 04/19/2010 08:56:28

04/19/2010 08:56:28 --- SCHEDULEREC QUERY BEGIN 04/19/2010 08:56:28 --- 
SCHEDULEREC QUERY END 04/19/2010 08:56:28 Next operation scheduled:
04/19/2010 08:56:28

04/19/2010 08:56:28 Schedule Name: TEST_SCHEDULE
04/19/2010 08:56:28 Action:Incremental
04/19/2010 08:56:28 Objects:
04/19/2010 08:56:28 Options:
04/19/2010 08:56:28 Server Window Start:   08:40:00 on 04/20/2010
04/19/2010 08:56:28

04/19/2010 08:56:28 Schedule will be refreshed in 6 hours.

This is the info from dmserror.log for this run.
04/19/2010 08:35:34 ANS2820E An interrupt has occurred. The current operation 
will end and the client will shut down.
04/19/2010 08:36:12 ANS2820E An interrupt has occurred

Re: Linux Client failing with ANS1999E error

[James Choate]

Hi Richard  Len,
Thanks for your input.
I made the recommended change to the dsm.sys and took out the virtual mount 
point.  I also added an exclude.dir /public .

This is the latest message.
2010-04-17 18:21 ANR2579E Schedule PROD_6PM in domain PROD for node CLLINUX1 
failed (return code 12). (SESSION: 12576)

I do not have access to the client schedule log file at this time, but when the 
admin of the box sends me the file, I will repost.

Thanks,


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of 
Richard Sims
Sent: Friday, April 16, 2010 1:22 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Linux Client failing with ANS1999E error

Jim -

The backup log doesn't match timewise with the other logs, but I'll assume they 
are from multiple attempts of the same thing.
It looks like the /public/proval-old object is bad in some way, and needs 
examination.  If that system hasn't had fsck's in a while, it may be time.
I'd code an Exclude for it (or change the 'Exclude /public/*' to an Exclude.Dir 
on /public, for at least performance reasons) and reattempt the backup.
And remove the Virtualmountpoint for /, as it is a file system.

  Richard Sims

Re: Linux Client failing with ANS1999E error

[James Choate]

I have attached the dsmsched.log  dsmerror.log

Dsmsched.log file

04/17/2010 18:08:35 TSM Backup-Archive Client Version 5, Release 5, Level 2.0
04/17/2010 18:08:35 Querying server for next scheduled event.
04/17/2010 18:08:35 Node Name: CLLINUX1
04/17/2010 18:08:35 Session established with server TSMSRV1: Windows
04/17/2010 18:08:35   Server Version 5, Release 5, Level 0.0
04/17/2010 18:08:35   Server date/time: 04/17/2010 18:08:36  Last access: 
04/17/2010 12:08:35
04/17/2010 18:08:35 --- SCHEDULEREC QUERY BEGIN 04/17/2010 18:08:35 --- 
SCHEDULEREC QUERY END 04/17/2010 18:08:35 Next operation scheduled:
04/17/2010 18:08:35 
04/17/2010 18:08:35 Schedule Name: PROD_6PM
04/17/2010 18:08:35 Action:Incremental
04/17/2010 18:08:35 Objects:
04/17/2010 18:08:35 Options:
04/17/2010 18:08:35 Server Window Start:   18:00:00 on 04/17/2010
04/17/2010 18:08:35 
04/17/2010 18:08:35 Command will be executed in 13 minutes.
04/17/2010 18:21:35
Executing scheduled command now.
04/17/2010 18:21:35 Node Name: CLLINUX1
04/17/2010 18:21:35 Session established with server TSMSRV1: Windows
04/17/2010 18:21:35   Server Version 5, Release 5, Level 0.0
04/17/2010 18:21:35   Server date/time: 04/17/2010 18:21:36  Last access: 
04/17/2010 18:08:36
04/17/2010 18:21:35 --- SCHEDULEREC OBJECT BEGIN PROD_6PM 04/17/2010 18:00:00 
04/17/2010 18:21:35 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:35 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:36 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:36 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:36 Incremental backup of volume '/'
04/17/2010 18:21:36 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:36 Incremental backup of volume '/boot'
04/17/2010 18:21:36 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:36 Incremental backup of volume '/public'
04/17/2010 18:21:36 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:36 Incremental backup of volume '/pictometry'
04/17/2010 18:21:36 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:36 Incremental backup of volume '/public/proval-old'
04/17/2010 18:21:37 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:37 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:38 ANS1898I * Processed 9,500 files *
04/17/2010 18:21:39 ANS1898I * Processed54,000 files *
04/17/2010 18:21:40 ANS1898I * Processed85,500 files *
04/17/2010 18:21:41 ANS1898I * Processed   115,500 files *
04/17/2010 18:21:42 ANS1898I * Processed   124,500 files *
04/17/2010 18:21:42 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:42 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:42 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/17/2010 18:21:42 ANS1898I * Processed   167,500 files *
04/17/2010 18:21:42 Successful incremental backup of '/public/proval-old'
04/17/2010 18:21:42 ANS1999E Incremental processing of '/' stopped.
04/17/2010 18:21:42 --- SCHEDULEREC STATUS BEGIN 04/17/2010 18:21:42 Total 
number of objects inspected:  167,621
04/17/2010 18:21:42 Total number of objects backed up:0
04/17/2010 18:21:42 Total number of objects updated:  0
04/17/2010 18:21:42 Total number of objects rebound:  0
04/17/2010 18:21:42 Total number of objects deleted:  0
04/17/2010 18:21:42 Total number of objects expired:  0
04/17/2010 18:21:42 Total number of objects failed:   0
04/17/2010 18:21:42 Total number of bytes transferred:   0  B
04/17/2010 18:21:42 Data transfer time:0.00 sec
04/17/2010 18:21:42 Network data transfer rate:0.00 KB/sec
04/17/2010 18:21:42 Aggregate data transfer rate:  0.00 KB/sec
04/17/2010 18:21:42 Objects compressed by:0%
04/17/2010 18:21:42 Elapsed processing time:   00:00:07
04/17/2010 18:21:42 --- SCHEDULEREC STATUS END 04/17/2010 18:21:42 ANS1028S An 
internal program error occurred.
04/17/2010 18:21:42 --- SCHEDULEREC OBJECT END PROD_6PM 04/17/2010 18:00:00 
04/17/2010 18:21:42 ANS1512E Scheduled event 'PROD_6PM' failed.  Return code = 
12.
04/17/2010 18:21:42 Sending results for scheduled event 'PROD_6PM'.

Linux Client failing with ANS1999E error

[James Choate]

Has anyone seen this error?  I can't figure out whats going on and the messages 
guide isn't to helpful in resolving this error.   Below are the client OS, BA 
client version, Server version, dsm.sys from the client, error in the 
dsmsched.log, dsmerror.log and a snippet from the srvr actlog file.
Any help is appreciated.




I have a linux (Fedora 10) client running   Client Version 5, Release 5, Level 
2.0 

The client is new to this TSM server.  The TSM server Windows  2003 Enterprise 
R2
  Server Version 5, Release 5, Level 0.0

My dsm.sys file looks like:
VIRTUALMOUNTPOINT /
ERRORLOGRETENTION 7 D
SCHEDLOGRETENTION 7 D
MAXCMDRETRIES 4
QUERYSCHEDPERIOD 1
EXCLUDE /.../*
EXCLUDE.DIR /tmp
EXCLUDE.DIR /var/log
EXCLUDE.FILE /opt/tivoli/tsm/client/ba/bin/*.log
INCLUDE /etc/*
INCLUDE /public/*
INCLUDE /pictometry/*
INCLUDE /opt/tivoli/tsm/*
INCLUDE /root/*
PASSWORDACCESS GENERATE
   COMMMethod TCPip
   TCPPort1500
   TCPServeraddress   MYTSMSRVR
   nodename   CLLINUX1


Running the backup.

#dsmc incr
IBM Tivoli Storage Manager
Command Line Backup/Archive Client Interface
  Client Version 5, Release 5, Level 2.0
  Client date/time: 04/16/2010 12:16:44
(c) Copyright by IBM Corporation and other(s) 1990, 2009. All Rights Reserved.
Node Name: CLLINUX1
Session established with server MYTSMSRVR: Windows
  Server Version 5, Release 5, Level 0.0
  Server date/time: 04/16/2010 12:16:44  Last access: 04/16/2010 12:12:44
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
Incremental backup of volume '/'
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
Incremental backup of volume '/boot'
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
Incremental backup of volume '/public'
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
Incremental backup of volume '/pictometry'
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
Incremental backup of volume '/public/proval-old'
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1898I * Processed 9,500 files *
ANS1898I * Processed37,000 files *
ANS1898I * Processed74,500 files *
ANS1898I * Processed   108,500 files *
ANS1898I * Processed   124,500 files *
ANS1898I * Processed   165,500 files *
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1898I * Processed   167,500 files *
Successful incremental backup of '/public/proval-old'
ANS1999E Incremental processing of '/' stopped.

Total number of objects inspected:  167,621
Total number of objects backed up:0
Total number of objects updated:  0
Total number of objects rebound:  0
Total number of objects deleted:  0
Total number of objects expired:  0
Total number of objects failed:   0
Total number of bytes transferred:   0  B
Data transfer time:0.00 sec
Network data transfer rate:0.00 KB/sec
Aggregate data transfer rate:  0.00 KB/sec
Objects compressed by:0%
Elapsed processing time:   00:00:11
ANS1028S An internal program error occurred.

dsmerror.log

04/16/2010 12:05:02 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/16/2010 12:05:03 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/16/2010 12:05:03 TransErrno: Unexpected error from GetFSInfo:stat, errno = 6
04/16/2010 12:05:03 TransErrno: Unexpected error from lstat, errno = 6
04/16/2010 12:05:03 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/16/2010 12:05:03 TransErrno: Unexpected error from GetFSInfo:stat, errno = 6
04/16/2010 12:05:04 ANS1999E Incremental processing of '/public/proval-old' 
stopped.
04/16/2010 12:05:04 ANS1999E Incremental processing of '/' stopped.
04/16/2010 12:05:04 ANS1028S An internal program error occurred.
04/16/2010 12:05:04 ANS1512E Scheduled event 'PROD_12PM' failed.  Return code = 
12.



Q actlog for error message:

04/16/2010 12:00:09  ANR0406I Session 11017 started for node CLLINUX1
  (Linux86) (Tcp/Ip CLLINUX1(41275)).
  (SESSION: 11017)

Re: Linux Client failing with ANS1999E error

[Richard Sims]

Jim -

The backup log doesn't match timewise with the other logs, but I'll assume they 
are from multiple attempts of the same thing.
It looks like the /public/proval-old object is bad in some way, and needs 
examination.  If that system hasn't had fsck's in a while, it may be time.
I'd code an Exclude for it (or change the 'Exclude /public/*' to an Exclude.Dir 
on /public, for at least performance reasons) and reattempt the backup.
And remove the Virtualmountpoint for /, as it is a file system.

  Richard Sims

Re: Linux Client failing with ANS1999E error

[Len Boyle]

I have not seen this error message before. 
I think that if you remove the following line from the opt file your errors 
will go away.

VIRTUALMOUNTPOINT /

len

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of James 
Choate
Sent: Friday, April 16, 2010 2:51 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Linux Client failing with ANS1999E error

Has anyone seen this error?  I can't figure out whats going on and the messages 
guide isn't to helpful in resolving this error.   Below are the client OS, BA 
client version, Server version, dsm.sys from the client, error in the 
dsmsched.log, dsmerror.log and a snippet from the srvr actlog file.
Any help is appreciated.




I have a linux (Fedora 10) client running   Client Version 5, Release 5, Level 
2.0 

The client is new to this TSM server.  The TSM server Windows  2003 Enterprise 
R2
  Server Version 5, Release 5, Level 0.0

My dsm.sys file looks like:
VIRTUALMOUNTPOINT /
ERRORLOGRETENTION 7 D
SCHEDLOGRETENTION 7 D
MAXCMDRETRIES 4
QUERYSCHEDPERIOD 1
EXCLUDE /.../*
EXCLUDE.DIR /tmp
EXCLUDE.DIR /var/log
EXCLUDE.FILE /opt/tivoli/tsm/client/ba/bin/*.log
INCLUDE /etc/*
INCLUDE /public/*
INCLUDE /pictometry/*
INCLUDE /opt/tivoli/tsm/*
INCLUDE /root/*
PASSWORDACCESS GENERATE
   COMMMethod TCPip
   TCPPort1500
   TCPServeraddress   MYTSMSRVR
   nodename   CLLINUX1


Running the backup.

#dsmc incr
IBM Tivoli Storage Manager
Command Line Backup/Archive Client Interface
  Client Version 5, Release 5, Level 2.0
  Client date/time: 04/16/2010 12:16:44
(c) Copyright by IBM Corporation and other(s) 1990, 2009. All Rights Reserved.
Node Name: CLLINUX1
Session established with server MYTSMSRVR: Windows
  Server Version 5, Release 5, Level 0.0
  Server date/time: 04/16/2010 12:16:44  Last access: 04/16/2010 12:12:44
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
Incremental backup of volume '/'
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
Incremental backup of volume '/boot'
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
Incremental backup of volume '/public'
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
Incremental backup of volume '/pictometry'
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
Incremental backup of volume '/public/proval-old'
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1898I * Processed 9,500 files *
ANS1898I * Processed37,000 files *
ANS1898I * Processed74,500 files *
ANS1898I * Processed   108,500 files *
ANS1898I * Processed   124,500 files *
ANS1898I * Processed   165,500 files *
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1278W Virtual mount point '/' is a file system. It will be backed up as a 
file system.
ANS1898I * Processed   167,500 files *
Successful incremental backup of '/public/proval-old'
ANS1999E Incremental processing of '/' stopped.

Total number of objects inspected:  167,621
Total number of objects backed up:0
Total number of objects updated:  0
Total number of objects rebound:  0
Total number of objects deleted:  0
Total number of objects expired:  0
Total number of objects failed:   0
Total number of bytes transferred:   0  B
Data transfer time:0.00 sec
Network data transfer rate:0.00 KB/sec
Aggregate data transfer rate:  0.00 KB/sec
Objects compressed by:0%
Elapsed processing time:   00:00:11
ANS1028S An internal program error occurred.

dsmerror.log

04/16/2010 12:05:02 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/16/2010 12:05:03 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/16/2010 12:05:03 TransErrno: Unexpected error from GetFSInfo:stat, errno = 6
04/16/2010 12:05:03 TransErrno: Unexpected error from lstat, errno = 6
04/16/2010 12:05:03 ANS1278W Virtual mount point '/' is a file system. It will 
be backed up as a file system.
04/16/2010 12:05:03 TransErrno: Unexpected error from GetFSInfo:stat, errno = 6
04/16/2010 12:05:04 ANS1999E Incremental processing of '/public/proval-old' 
stopped.
04/16/2010 12:05:04

Re: TSM 6.2.0.0 Linux client crash

[Andrew Raibeck]

We have confirmed a defect in the TSM Linux client that can cause this
crash, and will open an APAR.

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.


 Am Thursday 25 March 2010 schrieben Sie:

  At the moment, I'm just curious at the moment if anybody else has seen
this
  issue:
 
  TSM 6.2.0.0 Linux client will crash if /etc/issue is larger than a 127
byte
  text file.  127 bytes or less of text, the client works fine.  128
bytes
  or more, and it segfaults.  127 bytes of random data copied from
  /dev/urandom or nulls from /dev/zero, and the client runs fine. This
has
  been replicated on both 32bit and 64bit Linux systems.  The Mac OS X
  client on 10.5.7 worked fine.  The 32bit client was an upgrade from
5.5,
  I'm not sure if the 64bit was or not, but I can find out, OS X was a
new
  install.  Tried against different server versions, though that doesn't
  seem to matter.  Various bits below.
 
  I didn't see any mention of it searching the list archives, but I also
  didn't spend a lot of time searching.  The IBM known issues page didn't
  seem to list this.

Re: TSM 6.2.0.0 Linux client crash

[Zoltan Forray/AC/VCU]

I asked my sole Linux 6.2 client (who is having the crash) to confirm if
his /etc/issue is  127 bytes and if this could be his crash cause. He
said:

It is likely, as I usually add additional information to the /etc/issue
file and its 607 bytes.

I will test at my next opportunity.

That is a very odd problem.

Will let you know more when he responds.



From:
Michael Prix m...@rs6000.darktech.org
To:
ADSM-L@VM.MARIST.EDU
Date:
03/25/2010 06:16 PM
Subject:
Re: [ADSM-L] TSM 6.2.0.0 Linux client crash
Sent by:
ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU



Hello,

sorry, can't confirm.

IBM Tivoli Storage Manager
Command Line Backup-Archive Client Interface
  Client Version 6, Release 2, Level 0.0
  Client date/time: 03/25/10   23:10:48
(c) Copyright by IBM Corporation and other(s) 1990, 2010. All Rights
Reserved.

Node Name: LIN02
Session established with server TSMAIX03: AIX-RS/6000
  Server Version 5, Release 5, Level 3.0
  Server date/time: 03/25/10   23:10:48  Last access: 03/25/10   23:04:56

tsm quit
lin02:/opt/tivoli/tsm/client/ba/bin # wc -c /etc/issue
173 /etc/issue
lin02:/opt/tivoli/tsm/client/ba/bin # uname -a
Linux lin02 2.6.27.42-0.1-default #1 SMP 2010-01-06 16:07:25 +0100 x86_64
x86_64 x86_64 GNU/Linux


--
Michael Prix


Am Thursday 25 March 2010 schrieben Sie:

 At the moment, I'm just curious at the moment if anybody else has seen
this
 issue:

 TSM 6.2.0.0 Linux client will crash if /etc/issue is larger than a 127
byte
 text file.  127 bytes or less of text, the client works fine.  128 bytes
 or more, and it segfaults.  127 bytes of random data copied from
 /dev/urandom or nulls from /dev/zero, and the client runs fine. This has
 been replicated on both 32bit and 64bit Linux systems.  The Mac OS X
 client on 10.5.7 worked fine.  The 32bit client was an upgrade from 5.5,
 I'm not sure if the 64bit was or not, but I can find out, OS X was a new
 install.  Tried against different server versions, though that doesn't
 seem to matter.  Various bits below.

 I didn't see any mention of it searching the list archives, but I also
 didn't spend a lot of time searching.  The IBM known issues page didn't
 seem to list this.

 --
 Cameron Hanover
 chano...@umich.edu

 A computer once beat me at chess, but it was no match for me at kick
 boxing. --Emo Philips


 
 64bit Linux:
 [r...@watson etc]# for i in `seq 1 127`; do echo -n y  /etc/issue;
done
 [r...@watson etc]# dsmc
 IBM Tivoli Storage Manager
 Command Line Backup-Archive Client Interface
  Client Version 6, Release 2, Level 0.0
  Client date/time: 03/25/2010 12:42:02
 (c) Copyright by IBM Corporation and other(s) 1990, 2010. All Rights
 Reserved.

 Node Name: WATSON
 Session established with server JEFFERSON: Linux/x86_64
  Server Version 6, Release 2, Level 0.0
  Server date/time: 03/25/2010 12:43:05  Last access: 03/25/2010 12:33:33

 tsm
 [r...@watson etc]# for i in `seq 1 128`; do echo -n y  /etc/issue;
done
 [r...@watson etc]# dsmc
 Segmentation fault

 (from strace)
 open(/etc/issue, O_RDONLY|O_LARGEFILE) = 3
 fstat64(3, {st_mode=S_IFREG|0644, st_size=609, ...}) = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =
 0xf7f47000 read(3, This is the University of Michig..., 4096)
=
 609
 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
 +++ killed by SIGSEGV +++


 32bit Linux:
 embizacho ~ # wc -c /etc/issue
 782 /etc/issue
 embizacho ~ # uname -a
 Linux .edu 2.6.24-gentoo-r8 #1 SMP Wed Oct 29
13:16:53
 EDT 2008 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
 embizacho ~ # dsmc
 Segmentation fault

 (strace)
 open(/etc/issue, O_RDONLY|O_LARGEFILE) = 3
 fstat64(3, {st_mode=S_IFREG|0644, st_size=782, ...}) = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =
 0xb7f2 read(3, ..., 4096) = 782
 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
 +++ killed by SIGSEGV +++

 packages installed:
 TIVsm-API.i386.rpm
 TIVsm-BA.i386.rpm
 gskcrypt32-8.0.13.3.linux.x86.rpm
 gskssl32-8.0.13.3.linux.x86.rpm

TSM 6.2.0.0 Linux client crash

[c.hanover]

At the moment, I'm just curious at the moment if anybody else has seen this 
issue:

TSM 6.2.0.0 Linux client will crash if /etc/issue is larger than a 127 byte 
text file.  127 bytes or less of text, the client works fine.  128 bytes or 
more, and it segfaults.  127 bytes of random data copied from /dev/urandom or 
nulls from /dev/zero, and the client runs fine.
This has been replicated on both 32bit and 64bit Linux systems.  The Mac OS X 
client on 10.5.7 worked fine.  The 32bit client was an upgrade from 5.5, I'm 
not sure if the 64bit was or not, but I can find out, OS X was a new install.  
Tried against different server versions, though that doesn't seem to matter.  
Various bits below.

I didn't see any mention of it searching the list archives, but I also didn't 
spend a lot of time searching.  The IBM known issues page didn't seem to list 
this.

--
Cameron Hanover
chano...@umich.edu

A computer once beat me at chess, but it was no match for me at kick boxing.
--Emo Philips



64bit Linux:
[r...@watson etc]# for i in `seq 1 127`; do echo -n y  /etc/issue; done
[r...@watson etc]# dsmc
IBM Tivoli Storage Manager
Command Line Backup-Archive Client Interface
 Client Version 6, Release 2, Level 0.0  
 Client date/time: 03/25/2010 12:42:02
(c) Copyright by IBM Corporation and other(s) 1990, 2010. All Rights Reserved.

Node Name: WATSON
Session established with server JEFFERSON: Linux/x86_64
 Server Version 6, Release 2, Level 0.0
 Server date/time: 03/25/2010 12:43:05  Last access: 03/25/2010 12:33:33

tsm
[r...@watson etc]# for i in `seq 1 128`; do echo -n y  /etc/issue; done
[r...@watson etc]# dsmc
Segmentation fault

(from strace)
open(/etc/issue, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=609, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf7f47000
read(3, This is the University of Michig..., 4096) = 609
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++


32bit Linux:
embizacho ~ # wc -c /etc/issue
782 /etc/issue
embizacho ~ # uname -a
Linux .edu 2.6.24-gentoo-r8 #1 SMP Wed Oct 29 13:16:53 EDT 
2008 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
embizacho ~ # dsmc
Segmentation fault

(strace)
open(/etc/issue, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=782, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7f2
read(3, ..., 4096) = 782
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

packages installed:
TIVsm-API.i386.rpm
TIVsm-BA.i386.rpm
gskcrypt32-8.0.13.3.linux.x86.rpm
gskssl32-8.0.13.3.linux.x86.rpm

Re: TSM 6.2.0.0 Linux client crash

[Michael Prix]

Hello,

sorry, can't confirm.

IBM Tivoli Storage Manager
Command Line Backup-Archive Client Interface
  Client Version 6, Release 2, Level 0.0
  Client date/time: 03/25/10   23:10:48
(c) Copyright by IBM Corporation and other(s) 1990, 2010. All Rights Reserved.

Node Name: LIN02
Session established with server TSMAIX03: AIX-RS/6000
  Server Version 5, Release 5, Level 3.0
  Server date/time: 03/25/10   23:10:48  Last access: 03/25/10   23:04:56

tsm quit
lin02:/opt/tivoli/tsm/client/ba/bin # wc -c /etc/issue
173 /etc/issue
lin02:/opt/tivoli/tsm/client/ba/bin # uname -a
Linux lin02 2.6.27.42-0.1-default #1 SMP 2010-01-06 16:07:25 +0100 x86_64
x86_64 x86_64 GNU/Linux


--
Michael Prix


Am Thursday 25 March 2010 schrieben Sie:

 At the moment, I'm just curious at the moment if anybody else has seen this
 issue:

 TSM 6.2.0.0 Linux client will crash if /etc/issue is larger than a 127 byte
 text file.  127 bytes or less of text, the client works fine.  128 bytes
 or more, and it segfaults.  127 bytes of random data copied from
 /dev/urandom or nulls from /dev/zero, and the client runs fine. This has
 been replicated on both 32bit and 64bit Linux systems.  The Mac OS X
 client on 10.5.7 worked fine.  The 32bit client was an upgrade from 5.5,
 I'm not sure if the 64bit was or not, but I can find out, OS X was a new
 install.  Tried against different server versions, though that doesn't
 seem to matter.  Various bits below.

 I didn't see any mention of it searching the list archives, but I also
 didn't spend a lot of time searching.  The IBM known issues page didn't
 seem to list this.

 --
 Cameron Hanover
 chano...@umich.edu

 A computer once beat me at chess, but it was no match for me at kick
 boxing. --Emo Philips


 
 64bit Linux:
 [r...@watson etc]# for i in `seq 1 127`; do echo -n y  /etc/issue; done
 [r...@watson etc]# dsmc
 IBM Tivoli Storage Manager
 Command Line Backup-Archive Client Interface
  Client Version 6, Release 2, Level 0.0
  Client date/time: 03/25/2010 12:42:02
 (c) Copyright by IBM Corporation and other(s) 1990, 2010. All Rights
 Reserved.

 Node Name: WATSON
 Session established with server JEFFERSON: Linux/x86_64
  Server Version 6, Release 2, Level 0.0
  Server date/time: 03/25/2010 12:43:05  Last access: 03/25/2010 12:33:33

 tsm
 [r...@watson etc]# for i in `seq 1 128`; do echo -n y  /etc/issue; done
 [r...@watson etc]# dsmc
 Segmentation fault

 (from strace)
 open(/etc/issue, O_RDONLY|O_LARGEFILE) = 3
 fstat64(3, {st_mode=S_IFREG|0644, st_size=609, ...}) = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
 0xf7f47000 read(3, This is the University of Michig..., 4096) =
 609
 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
 +++ killed by SIGSEGV +++


 32bit Linux:
 embizacho ~ # wc -c /etc/issue
 782 /etc/issue
 embizacho ~ # uname -a
 Linux .edu 2.6.24-gentoo-r8 #1 SMP Wed Oct 29 13:16:53
 EDT 2008 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
 embizacho ~ # dsmc
 Segmentation fault

 (strace)
 open(/etc/issue, O_RDONLY|O_LARGEFILE) = 3
 fstat64(3, {st_mode=S_IFREG|0644, st_size=782, ...}) = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
 0xb7f2 read(3, ..., 4096) = 782
 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
 +++ killed by SIGSEGV +++

 packages installed:
 TIVsm-API.i386.rpm
 TIVsm-BA.i386.rpm
 gskcrypt32-8.0.13.3.linux.x86.rpm
 gskssl32-8.0.13.3.linux.x86.rpm

Re: Netware to Linux client migration

[Jürgen Weinelt]

David Longo wrote:
 
 2.  With the new Linux servers, they will also implement Novell's
 Dynamic Storage Technology.  This will enable the infrequent accessed
 files to be dumped off to a shadow space on SATA drives.
 
 Does anybody know if this speeds up  the TSM backup?  In other
 words, does the file scan done when backups run also have to scan
 this also each day?  Any experienced do's/don'ts about this from
 TSM point of view?

I've no personal, first-hand experience with this, but I investigated
DST a while ago and decided that it is unlikely to be helpful for TSM-based
backups.

Basically, DST means that you've got two physical volumes that are
presented to your client PCs as a single logical volume. In the
background, a rule set moves files from one physical volume to the
other (usually one volume is expensive/fast, the other cheap/slow).
It also allows conventional backup software (the kind that needs to
do full backups periodically) to backup the cheap/slow volume less
frequently, saving both time and tapes.

As far as I know, the unified view is strictly limited to NCP clients,
which means that for TSM, there really are two separate volumes to
backup (can anyone confirm this?). Since TSM uses the incremental
forever approach, it's actually counter-productive to move a file from
one volume to the other, because TSM will see it as a new file and
will have to back it up for a second time.

-- 
Jürgen Weinelt
Rechenzentrum der Universität Würzburg

Netware to Linux client migration

[David Longo]

I have TSM server 5.5.2 and some older Netware clients.  Netware 6.5
and most are TSM client 5.2.2.0.  These are our Network file shares.

The current volumes are NSS (TSM server filespace type NTW:LONG.)
The team is about to migrate all Netware over to Linux, SLES 10 and
the TSM filespace type will be NSS.  They have done a small one as a test
and this is how it comes out.

Several questions.

1.  I know that disimilar filesystem types can't be backed up/restored.
So, with the old Netware filespaces, I need to keep them around to
restore old data to one spare Netware server and then they copy data
to new system if a restore is needed after migrating.

I thought I would ask though if there is anyway that this can be migrated
as this is probably a popular move and maybe there is a way to do it,
even if a third party something.  Ha ha!  I know is a dumb question,
but I see Andy Raibeck's standard line about that frequently!

2.  With the new Linux servers, they will also implement Novell's
Dynamic Storage Technology.  This will enable the infrequent accessed
files to be dumped off to a shadow space on SATA drives.

Does anybody know if this speeds up  the TSM backup?  In other
words, does the file scan done when backups run also have to scan
this also each day?  Any experienced do's/don'ts about this from
TSM point of view?

Thanks,
David Longo



#
This message is for the named person's use only.  It may 
contain private, proprietary, or legally privileged information.  
No privilege is waived or lost by any mistransmission.  If you 
receive this message in error, please immediately delete it and 
all copies of it from your system, destroy any hard copies of it, 
and notify the sender.  You must not, directly or indirectly, use, 
disclose, distribute, print, or copy any part of this message if you 
are not the intended recipient.  Health First reserves the right to 
monitor all e-mail communications through its networks.  Any views 
or opinions expressed in this message are solely those of the 
individual sender, except (1) where the message states such views 
or opinions are on behalf of a particular entity;  and (2) the sender 
is authorized by the entity to give such views or opinions.
#

Re: Linux client memory woes

[Michael Green]

Folks, turns out that whereas 64 bit clients for Linux PPC and Zseries
are already available, it's not for x64 arch. Moreover, there are
currently no plans for development the 64 bit version of BA client for
Linux x64.

Just to remind you that x64 client is required to overcome the 4GB
memory limit of the 32 bit BA client on Linux x64. Such ability would
allow for backup of much more objects within the same scheduled
process without having to resort to the help of awkward workarounds
such MEMORYEFFICIENTBACKUP.

The TSM support person (who was very responsive by the way) who
received my PMR is ready to file a so called Design Change Request
on my behalf. Within that request I need to formulate a Business
Justification, where I highlight how important this could be to my
business to get such a change in the future.

As I'm not very good at writing Business Justifications, I would
appreciate your input/ideas on this matter.
--
Warm regards,
Michael Green



On Mon, Jan 4, 2010 at 3:16 PM, Michael Green mishagr...@gmail.com wrote:
 Just to follow up on this: I've received a confirmation from TSM level
 2 support that BA Client for Linux i386/x64 is 32 bit application and
 thus fundamentally limited to 4GB RAM.

Re: Linux client memory woes

[Richard Sims]

IBM's failure to spontaneously provide a TSM Linux client for prevalent, modern 
CPU architectures is certainly a marked departure from the company's early 
pronouncements of Linux being a strategic direction meriting concerted product 
development.

TSM client product management has markedly failed in its role to both meet 
customer needs and keep the product competitive in a challenging marketplace of 
backup products.  In a properly run software organization it should never be 
necessary for customers to have to file a request for intrinsic functionality 
in the product line and then wait further years for it to appear: timely 
development would be a natural result of strategic product planning.  The 
absence of a 64-bit client is a remarkable failing.

   Richard Sims

On Jan 5, 2010, at 4:47 AM, Michael Green wrote:

 Folks, turns out that whereas 64 bit clients for Linux PPC and Zseries
 are already available, it's not for x64 arch. Moreover, there are
 currently no plans for development the 64 bit version of BA client for
 Linux x64.
 
 Just to remind you that x64 client is required to overcome the 4GB
 memory limit of the 32 bit BA client on Linux x64. Such ability would
 allow for backup of much more objects within the same scheduled
 process without having to resort to the help of awkward workarounds
 such MEMORYEFFICIENTBACKUP.
 
 The TSM support person (who was very responsive by the way) who
 received my PMR is ready to file a so called Design Change Request
 on my behalf. Within that request I need to formulate a Business
 Justification, where I highlight how important this could be to my
 business to get such a change in the future.
 
 As I'm not very good at writing Business Justifications, I would
 appreciate your input/ideas on this matter.
 --
 Warm regards,
 Michael Green

Re: Linux client memory woes

[Howard Coles]

And there you go, a perfect Business Justification  Not ours IBM,
yours.  Get off your butt and get this done.  There is NO excuse for not
having already created a 64 bit Linux client, especially since, from
what I understand, the TSM Server only runs on 64 bit Linux.  I find it
absolutely amazing that as long as 64 bit processors have been out,
we're using 32bit anything.

See Ya'
Howard Coles Jr.
John 3:16!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Richard Sims
Sent: Tuesday, January 05, 2010 7:40 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Linux client memory woes

IBM's failure to spontaneously provide a TSM Linux client for prevalent,
modern CPU architectures is certainly a marked departure from the
company's early pronouncements of Linux being a strategic direction
meriting concerted product development.

TSM client product management has markedly failed in its role to both
meet customer needs and keep the product competitive in a challenging
marketplace of backup products.  In a properly run software organization
it should never be necessary for customers to have to file a request for
intrinsic functionality in the product line and then wait further years
for it to appear: timely development would be a natural result of
strategic product planning.  The absence of a 64-bit client is a
remarkable failing.

   Richard Sims

On Jan 5, 2010, at 4:47 AM, Michael Green wrote:

 Folks, turns out that whereas 64 bit clients for Linux PPC and Zseries
 are already available, it's not for x64 arch. Moreover, there are
 currently no plans for development the 64 bit version of BA client for
 Linux x64.
 
 Just to remind you that x64 client is required to overcome the 4GB
 memory limit of the 32 bit BA client on Linux x64. Such ability would
 allow for backup of much more objects within the same scheduled
 process without having to resort to the help of awkward workarounds
 such MEMORYEFFICIENTBACKUP.
 
 The TSM support person (who was very responsive by the way) who
 received my PMR is ready to file a so called Design Change Request
 on my behalf. Within that request I need to formulate a Business
 Justification, where I highlight how important this could be to my
 business to get such a change in the future.
 
 As I'm not very good at writing Business Justifications, I would
 appreciate your input/ideas on this matter.
 --
 Warm regards,
 Michael Green

Re: Linux client memory woes

[Schaub, Steve]

Similar to the lack of an HSM for Windows version that runs on W2K3 x64...

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Howard 
Coles
Sent: Tuesday, January 05, 2010 9:23 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Linux client memory woes

And there you go, a perfect Business Justification  Not ours IBM,
yours.  Get off your butt and get this done.  There is NO excuse for not
having already created a 64 bit Linux client, especially since, from
what I understand, the TSM Server only runs on 64 bit Linux.  I find it
absolutely amazing that as long as 64 bit processors have been out,
we're using 32bit anything.

See Ya'
Howard Coles Jr.
John 3:16!

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Richard Sims
Sent: Tuesday, January 05, 2010 7:40 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Linux client memory woes

IBM's failure to spontaneously provide a TSM Linux client for prevalent,
modern CPU architectures is certainly a marked departure from the
company's early pronouncements of Linux being a strategic direction
meriting concerted product development.

TSM client product management has markedly failed in its role to both
meet customer needs and keep the product competitive in a challenging
marketplace of backup products.  In a properly run software organization
it should never be necessary for customers to have to file a request for
intrinsic functionality in the product line and then wait further years
for it to appear: timely development would be a natural result of
strategic product planning.  The absence of a 64-bit client is a
remarkable failing.

   Richard Sims

On Jan 5, 2010, at 4:47 AM, Michael Green wrote:

 Folks, turns out that whereas 64 bit clients for Linux PPC and Zseries
 are already available, it's not for x64 arch. Moreover, there are
 currently no plans for development the 64 bit version of BA client for
 Linux x64.
 
 Just to remind you that x64 client is required to overcome the 4GB
 memory limit of the 32 bit BA client on Linux x64. Such ability would
 allow for backup of much more objects within the same scheduled
 process without having to resort to the help of awkward workarounds
 such MEMORYEFFICIENTBACKUP.
 
 The TSM support person (who was very responsive by the way) who
 received my PMR is ready to file a so called Design Change Request
 on my behalf. Within that request I need to formulate a Business
 Justification, where I highlight how important this could be to my
 business to get such a change in the future.
 
 As I'm not very good at writing Business Justifications, I would
 appreciate your input/ideas on this matter.
 --
 Warm regards,
 Michael Green

-
Please see the following link for the BlueCross BlueShield of Tennessee E-mail 
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm

Re: Linux client memory woes

[Michael Green]

Just to follow up on this: I've received a confirmation from TSM level
2 support that BA Client for Linux i386/x64 is 32 bit application and
thus fundamentally limited to 4GB RAM.

I've also been given this link
http://www-01.ibm.com/support/docview.wss?uid=swg21197422 that
discusses memory requirements of BA client and presents ways to reduce
them.
--
Warm regards,
Michael Green