I would never install a x.x.x.0 release in production unless Tivoli had
categorical proof that it was absolutely solid.  Typically, I wait 3 months
after it is generally available and do some APAR searches to see where the
problems are.  I typically wait until x.x.x.2 or .3 before I put in
production.  Remember everyone is installing the stuff in a test area that
has many TB at stake and verifying the product works correctly before the
deploy to production.  They are the ones generating the initial problems
that are fixed and they do a lot of testing.

-----Original Message-----
From: PINNI, BALANAND (SBCSI) [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 18, 2002 11:48 AM
To: [EMAIL PROTECTED]
Subject: Re: WARNING about Tivoli 4.2.1.0


Dough,
Did u put 4.2.1.9 Fix and try ,because I feel 3.7.0 also had problems .But
after updating fixes it went well. So could u pl tell us did they say even
after  updating to 4.2.1.9 u may face problems? Because it will help me know
what else I need to look at later . Thanks Balanand

-----Original Message-----
From: James, Doug [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 18, 2002 7:42 AM
To: [EMAIL PROTECTED]
Subject: WARNING about Tivoli 4.2.1.0


We tested 4.2.1.0 for a month, and then applied it in production.  After two
weeks in production, TSM died.  After sending IBM lots of data dumps, the
IBM help desk admitted that there were KNOWN BUGS in 4.2.1.0.  Our choices
were to backlevel to an older version of TSM, or move ahead to a BETA
version, 4.2.1.9, that was supposed to fix our problem.  We have been
running this Beta for about two months, but it is scary to be on the
bleeding edge.  I do not understand why Tivoli would put out code with major
known problems.

Doug James

-----Original Message-----
From: Robert Ouzen [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 17, 2002 3:16 AM
To: [EMAIL PROTECTED]
Subject: Re: Novell performance issue


Hi George

>From where did you get 4.2.1.24 Client I found only from Tivoli 4.2.1.0 (
IP22371.exe)

T.I.A Regards Robert Ouzen


                      \\\///
                     / _  _ \
                   (| (.) (.) |)
  +----------oOOo--()--oOOo---------------------+
  |                                                        |
  |                 Ouzen Robert                   |
  |             Helpdesk Manager                |
  |               Haifa University                   |
  |                                                        |
  |   E-mail: [EMAIL PROTECTED]         |
  |   Work : 972-4-8240345                     |
  |                                                        |
 +--------------oooO---------------------------------+
                 (   )     Oooo.
                  \ (      (   )
                   \_)      ) /
                           (_/





-----Original Message-----
From: Jason Mount [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 17, 2002 7:50 AM
To: [EMAIL PROTECTED]
Subject: Re: Novell performance issue


George,

I was using the 4.2.1.0 NW client and the SMDR/TSA that came with SP3 for NW
5.1. After going to 4.2.1.24 client and TSA5up7, a lot of my TSM error
messages and performance problems went away. I am too scared of Beta files,
but I have about 40 NW 5.1 servers running it and no burps from these
SMDR/TSA files yet. Sugguest you try them out on a few non-critical systems
and then go roll them out.

----- Original Message -----
From: "Brandon Eckmann/NS/WSC" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 14, 2002 1:41 PM
Subject: Re: Novell performance issue


> George,
> I've been at TSA500 5.4 and SMDR 5.5 for 4 months now with no problems
> running with DSMC  ver4  rel2  level 1.7.
>
>
> Brandon Eckmann
> Network and Technology Services
> Wayne State College
> Wayne NE.
>
>
>
> |---------+---------------------------->
> |         |           George Lesho     |
> |         |           <[EMAIL PROTECTED]>|
> |         |           Sent by: "ADSM:  |
> |         |           Dist Stor        |
> |         |           Manager"         |
> |         |           <[EMAIL PROTECTED]|
> |         |           .EDU>            |
> |         |                            |
> |         |                            |
> |         |           02/14/2002 11:35 |
> |         |           AM               |
> |         |           Please respond to|
> |         |           "ADSM: Dist Stor |
> |         |           Manager"         |
> |         |                            |
> |---------+---------------------------->
>
>-----------------------------------------------------------------------
>----
-----------------------------------------------------------------------|
>   |
|
>   |       To:       [EMAIL PROTECTED]
      |
>   |       cc:
|
>   |       Subject:  Re: Novell performance issue
|
>
>-----------------------------------------------------------------------
>----
-----------------------------------------------------------------------|
>
>
>
>
> Thanks for the tip but my cache hit percentage is in the low 99s for
> both my AIX and Win2K TSM servers. The issue is more likely related to
> the version of Novell and its components based on reading and comments
> from others... Here is where we are at:
>
> TSA500    5.03
> TSANDS    5.25
> SMDR      5.04
>
> The Novell admins are hesitant to put on TSA5UP7 or TSA5UP8 because
> these are still beta but contain important fixes that apparantly TSM
> likes
> (speedwise)
>
> Any other hints/suggestion would be VERY appreciated. Backups are
> taking forever on these Novell 5 boxes...
>
> George Lesho
> AFC Enterprises
>
>
>
>
>
>
> Brandon Eckmann/NS/WSC <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 02/14/2002
> 11:21:26 AM
>
> Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
>
> Sent by:  "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
>
>
> To:   [EMAIL PROTECTED]
> cc:    (bcc: George Lesho/Partners/AFC)
> Fax to:
> Subject:  Re: Novell performance issue
>
> On the TSM server side, run "query db format=detail" and check the
> "Cache Hit Pct" line. If it is under 98%, you need to increase the
> number of database buffers in the TSM server.
>
>
>
> Brandon Eckmann
> Network and Technology Services
> Wayne State College
> Wayne NE.
>
>
>
> |---------+---------------------------->
> |         |           George Lesho     |
> |         |           <[EMAIL PROTECTED]>|
> |         |           Sent by: "ADSM:  |
> |         |           Dist Stor        |
> |         |           Manager"         |
> |         |           <[EMAIL PROTECTED]|
> |         |           .EDU>            |
> |         |                            |
> |         |                            |
> |         |           02/13/2002 02:43 |
> |         |           PM               |
> |         |           Please respond to|
> |         |           "ADSM: Dist Stor |
> |         |           Manager"         |
> |         |                            |
> |---------+---------------------------->
>   >
> ----------------------------------------------------------------------
> ----
------------------------------------------------------------------------|
>
>
>   |
> |
>   |       To:       [EMAIL PROTECTED]
> |
>   |       cc:
> |
>   |       Subject:  Novell performance issue
> |
>   >
> ----------------------------------------------------------------------
> ----
------------------------------------------------------------------------|
>
>
>
>
>
>
> I now have two Novell clients; one each hung off AIX 433 / TSM 4145
> and Win2K / TSM 415 respectively. These clients are at Novell 5.0 SP5
> with TSM client 413. I have compression turned off in the dsm.opt
> file. I get repreated indications in the activity logs from both TSM
> servers that such and such a file can't be backed up because it is not
> found.
>
> 02/08/02   16:14:40      ANE4005E (Session: 1271, Node: ADSM_PEACH1)
Error
>                           processing
> 'DATA2:/PFC/BRAND/SJM/BRAND/B_REVIEW/BR1996/P-
>                           D_08_96/COMPMKTS.XLS': file not found
>
> Performance is terrible. I sure could use some help with this issue.
> Incremental backups are in the 8 hour range...
>
> George Lesho
> AFC Enterprises
>



Blue Cross Blue Shield of Florida, Inc., and its subsidiary and affiliate
companies are not responsible for errors or omissions in this e-mail
message. Any personal comments made in this e-mail do not reflect the views
of Blue Cross Blue Shield of Florida, Inc.

Reply via email to