Re: TSM v4.2.1
At 11:52 AM 10/22/2001 -0400, Stephen A. Cochran wrote: >As someone who's still runnings ADSM 3.1 but with a new TSM AIX server on >order >and no choice but to run a newer version, is the general feeling that 4.1 is >stable, or is 4.1 still buggy? If 4.2.x is unusuable, what's the safe >fallback, >4.1 or 3.7? I've been running v4.1.4.1 for awhile, and am pretty happy with it. Our environment: RS6k/M80, AIX 4.3.3, ATL P3000/P6000, DLT8000 drives. I had been thinking about upgrading to v4.2 to get a larger recovery log, but after seeing all of the posts about v4.2 being bad, I think I'll wait a bit. ..Paul -- Paul Zarnowski Ph: 607-255-4757 747 Rhodes Hall, Cornell UniversityFx: 607-255-8521 Ithaca, NY 14853-3801 Em: [EMAIL PROTECTED]
Re: TSM v4.2.1
On 23-Oct-01 Bill Mansfield wrote: > I heard second-hand that the license registration bug wasn't going to be > fixed until TSM 5.x. Can anyone out there confirm? I hope not. Last 24 hours we had again > 10 ANR2841W messages. And another thing I noticed about v4.2.1 AIX, our server becomes slower and slower everyday. I'm thinking of restart the server everyday Cheers, Henk (not amused)
Re: TSM v4.2.1
I heard second-hand that the license registration bug wasn't going to be fixed until TSM 5.x. Can anyone out there confirm? _ William Mansfield Senior Consultant Solution Technology, Inc 630 357 7744 x338 Henk ten Have <[EMAIL PROTECTED]To: [EMAIL PROTECTED] L> cc: Sent by: Subject: Re: TSM v4.2.1 "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] RIST.EDU> 10/23/2001 03:34 AM Please respond to "ADSM: Dist Stor Manager" On 22-Oct-01 Neil Schofield wrote: > The fact that others are experiencing identical problems at least gives me > some hope of a resolution. You mean, we all end up in the same madhouse? Last night we get the following message: ANS1030E System ran out of memory. Process ended, which means: "...User Response: Stop TSM, restart TSM, and retry the operation..." And just for fun, I counted the ANR2841W messages over the last 24 hours158379 : one hundred fifty eight thousend three hundred seventy nine, so you know this isn't a typo Cheers, Henk.
Re: TSM v4.2.1
On 22-Oct-01 Neil Schofield wrote: > The fact that others are experiencing identical problems at least gives me > some hope of a resolution. You mean, we all end up in the same madhouse? Last night we get the following message: ANS1030E System ran out of memory. Process ended, which means: "...User Response: Stop TSM, restart TSM, and retry the operation..." And just for fun, I counted the ANR2841W messages over the last 24 hours158379 : one hundred fifty eight thousend three hundred seventy nine, so you know this isn't a typo Cheers, Henk.
Re: TSM v4.2.1
I can only endorse Geoff, Henk and Tom's views. I upgraded two servers from TSM v3.7.5 to TSM v4.2.1 last week - both on NT. I too discovered processes and sessions failing with ANR4887E. On one server, I also saw the TSM server process frequently drop out with a Dr Watson error. I logged a priority 1 PMR but after two days bit the bullet and sacraficed 48 hours worth of backups by restoring the system back to its state prior to the upgrade. You can guess what the business thought about that. Other than the major failings above, I also saw a few other things that concerned me: - RECONCILE VOLUMES processing again reports spurious ANR4358W errors on multiple virtual volumes. This was a problem in 3.7.4 but had been fixed in 3.7.5. - The output of QUERY PROCESS during a MOVE DATA for a virtual volumes showed a massive number of unreadable bytes. This was even though the unreadable file count was zero. Funnily enough all such concurrent processes showed the same value for unreadable bytes. - The performance of the MOVE DATA process for virtual volumes was less than 10% of the performance of all previous versions I've seen. The problem we all have is that 3.7 is unsupported next week. However I would now be very reluctant to go through the upgrade again without some very strong assurances for fear of how things might look if I have to regress again. The fact that others are experiencing identical problems at least gives me some hope of a resolution. Neil Schofield The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House Halifax Road Bradford BD6 2SZ Registered in England and Wales No 2366682
Re: TSM v4.2.1
--- Neil Schofield wrote: The problem we all have is that 3.7 is unsupported next week --- end of quote --- As someone who's still runnings ADSM 3.1 but with a new TSM AIX server on order and no choice but to run a newer version, is the general feeling that 4.1 is stable, or is 4.1 still buggy? If 4.2.x is unusuable, what's the safe fallback, 4.1 or 3.7? And if you're wondering, I'm still using 3.1 because it never crashes and never has any problems. Steve Cochran Dartmouth College
Re: TSM v4.2.1
More problems: This morning I noticed TSM reporting this: 10/22/01 07:24:23 ANR8308I 001: 3590 volume U00834 is required for use in library 3494LIB; CHECKIN LIBVOLUME required within 60 minutes. Except here is a message in the log on the 20th that shows the tape being checked out: 10/20/01 02:59:03 ANR6697I MOVE DRMEDIA: CHECKOUT LIBVOLUME for volume U00834 in library 3494LIB completed successfully. 10/20/01 03:01:18 ANR6683I MOVE DRMEDIA: Volume U00834 was moved from COURIER state to VAULT. When I queried the vol this morning it was reported as mountable. I Changed status to unavailable and TSM still sat there till the time the whole 60 minutes ran down waiting for that tape. Is this normal? >I logged a priority 1 PMR but after two days bit the bullet >and sacraficed >48 hours worth of backups by restoring the system back to its >state prior >to the upgrade. You can guess what the business thought about that. I honestly wish I could go back to the previous version and just update to the current level. Unfortunately I cannot, it's too late. Don't you wish TSM had a tool that would convert the database to a down level version so we could all get on a "SAFE" version/level? In fact how about build it into TSM? Before it mounted the database it could look at the level and convert it, just like it does when you upgrade. Why not be able to convert back? Geoff Gill TSM Administrator NT Systems Support Engineer SAIC E-Mail: [EMAIL PROTECTED] Phone: (858) 826-4062 Pager: (888) 997-9614
