Paul, I can't agree more. We had to wait a while before we could apply the fix 4.2.1.8, to fix our 3494 libary problems. Tivoli had it ready, but didn't release it because they weren't satisfied with it. Forunately we weren't running TSM 4.2 in a production environment at that time.
We are now running production at level 4.2.1.9, and it runs like a charm. fix X.X.X.10 doesn't fix problems we are having, so we will not upgrade at this time. We are testing it at our site of course. Adding to Paul's comments on this list; Me and my co-workers are constantly following discussions on this list and read the posts that concerns us as well and act on it. Indeed, not every post is usefull for everyone, but we experience this list as a international ring of TSM friends, all trying to exploit the product to its full potential. Note; I've noticed that the profesionality on this list is growing day by day. The number of members is quite constant, but the level is getting higher. Not forgetting about the newbies of course, who can learn a great deal in this list. I did. Ilja G. Coolen _____ ABP / USZO CIS / BS / TB / Storage Management Telefoon : +31(0)45 579 7938 Fax : +31(0)45 579 3990 Email : [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Intranet : Storage Web <http://intranet/cis_bstb/html_content/sm/index_sm.htm> _____ - Everybody has a photographic memory, some just don't have film. - -----Oorspronkelijk bericht----- Van: Seay, Paul [mailto:[EMAIL PROTECTED]] Verzonden: dinsdag 19 februari 2002 6:13 Aan: [EMAIL PROTECTED] Onderwerp: Product Release Install Advice: (Used to be WARNING about Tivoli 4.2.1.0) First of all, BETAs apply to .0 releases before they are released GA or patches that we never see as they are tested at selected client sites to verify the fix test works in a customer environment. These are x.x.x.n releases are patches on top of the base release, with all inclusive fixes up to that point that have had limited testing. That means they have tested the general area the problem was to fix, but not a GA release test. The first thing I do before I put anything into production is check to see what open problems there are that may affect me. By the time 4.2.1.9 came out, months had passed since 4.2.1.0 GA. If I felt scared to put on 4.2.1.9, then I would have but on 4.2.1.8. 4.2.1.8 was a good patch level. We had been running it for months before we upgraded to 4.2.1.10 just last week. We are using all the special features. So far, the patches to 4.2.1.0 have not introduced any new problems, only fixed problems to my knowledge. That is execellent, PE APARS are worse than broken code GA releases because they could break something that is working and they are very difficult for the customer to test. I did see them pull back a Windows client update not because it broke something, but because it did not completely fix the problem. They urged customers to go to the final fix to the problem if they had installed the 4.2.1.16 fix. I will admit we have a few problems that Tivoli has not fixed yet, but we are the only customer experiencing them (or 1 of a few) and Tivoli is very focused on serving us. That is why I ask myself if I am wasting their time going through a dump especially if I am running a code level and there are 50 APARs that have been fixed since the code level went GA. You want good support, when you call up and you are current and it is a problem never seen before, you get attention. Doug, nothing personal meant by this. Just trying to get the attention of everyone that having Tivoli Support focusing time on problems already fixed is not good for anyone. Andy should have said it, but he could not because he is your vendor. "Give me a problem that I have not already fixed". The response you got from Tivoli Support seemed really offbase about 4.2.1.9 being a "BETA". Poor choice of words on their part. The correct answer should have been "Limited Testing Fix Patch 4.2.1.9 is known to fix many problems. Please install this and see if the problem is reproducable, you are experiencing many of the symptoms that have already been fixed". This all said, prudence is still a good thing. Just because x.x.x.n just hit the website does not mean put it on. If it fixes a problem you are having, yes. We are staying very current because we are using a lot of SAN stuff. There are still some minor bugs in it. Tivoli made great strides to improve the ease with the latest releases to show you what is the latest patches and maintenance available. I have seen them hold back for a while before putting something in the latest directory, yet have it available in the service site elsewhere. I will give Tivoli one thing, at least they are trying to fix their bugs and get a fix out timely. I cannot say that for any other vendors. Most of them say, next release, or nope. Now for the good news. Tivoli, based on what I know, is investing a tremendous amount resources on GA release testing prior to release of a product. Why?, to make all of us more comfortable and more problem free. Code defects are extremely expensive for a company that gives away 1 year free support. That in itself says something about their commitment to quality. Other vendors just say you do not have a support contract. When 5.1 arrives I expect them to be much better, or at least I hope. They were way behind the eight ball prior to 4.2.1 and probably rushed it to release. But, much of what they were doing for SAN was not nailed down from a hardware point of view at the time they were doing their 4.2.1 testing, so the testing probably suffered a little. Doug, welcome to a family of folks on this list server that will give you the straight scoop and some advice, good or bad, that you didn't ask for. Remember, they only have one goal: To make every TSM customer successful. You will also find that bad advice is quickly and politely corrected by each of us. Come back soon. Ask about the problems with a patch, you will get at least 10 responses. Thanks for bringing this issue to the forefront and getting such a healthy discussion going on it. Maybe everyone can learn something. -----Original Message----- From: James, Doug [mailto:[EMAIL PROTECTED]] Sent: Monday, February 18, 2002 8: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.
