Considering the official page for what 5.5.4.1 fixes is a single apar "encryption issue", I saw the need for that since we are going to implement encryption as soon as our TS1130 arrives to "upgrade" the last non-encrypt capable 3592.
As for 5.5.4.2 (which I plan to implement), I have had numerous problems with server-to-server exports either hanging or crashing and leaving an export session hung/non-cancelable. Also includes other fixes to address encryption. Another apar in 5.5.4.2 talks about mount requests failing due to a timing issue, which I have also experienced! If you have had any long time experience with IBM patches/maintenance/apars/ptf (for MF folks), which I am sure you have, you know as well as I do that often the apar description is not 100% your symptom but close enough and often fixes your problems. 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 Sims <r...@bu.edu> To: ADSM-L@VM.MARIST.EDU Date: 04/12/2010 09:40 AM Subject: Re: [ADSM-L] V5.5.4.1 recovery log issues Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> On Apr 12, 2010, at 9:18 AM, Zoltan Forray/AC/VCU wrote: > Well, this is becoming a very annoying and crazy problem. > > Since upgrading my Linux TSM server from 5.5.3.0 to 5.5.4.1, I am having > constant problems with the log filling and pinning. ... Zoltan - Your postings on your upgrade have not said why you went beyond the standard, fully tested maintenance level (5.5.4.0) to take your chances with a patch level (5.5.4.1). A patch level is intended to address a specific set of circumstances, as experienced by one or a few customers. One should not go there without specific need for the patch, and being accepting of possible side effects in order to restore functionality as addressed by the patch. This is not to say that this patch level itself is known to be responsible for the log pinning issue, but you are taking a chance with a patch. Richard Sims http://people.bu.edu/rbs/
