Re: Stop Bagging TSM Developers.
I agree. The developers do their best and then some. All the ones I have talked with are really committed to making this the best product they can. They take a lot of pride and interest in the product, which you can tell because they are not REQUIRED to participate in this list; they do it because they care. That said, it is pretty clear that the management doesn't provide them the time and/or resources needed to do sufficient quality testing. We are still sitting at 4.2.1.15 on our servers, and 4.2.0.0 or 4.2.1.20 for our 400+ WIN2K clients. We will probably continue to sit on this version of client server even after the April deadline, because the largest server is running at max capacity and I can't tolerate the problems with Expiration and WIn2K system object issues and continue to run. Unfortunately I can no longer defend this product to the local management, because we have to dedicate so many people resources to it. Testing for the clients takes way too much time because we have to prove we can do a complete restore down to the last icon on the desktop. And as I said, we can't upgrade the server because of the known problems. Sooner or later that message has to get to IBM/Tivoli management. Unfortunately it looks like they have to start losing customers before they get it. My opinion, and nobody else's... Wanda Prather -Original Message- From: Kauffman, Tom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 9:48 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. And for my 2 cents worth, I see this as a TSM management and not development problem. There seems to be no regression test suite, and no change control/revision control process. Tom Kauffman NIBCO, Inc. -Original Message- From: Jolliff, Dale [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 9:06 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. Just my opinion, but based on the bug releases of late, they are doing a pretty good bagging job on their own.
Re: Stop Bagging TSM Developers.
Did u try migrating clients to 5.1 and check weather expiration problems would go away? -Original Message- From: Prather, Wanda [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 12:44 PM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. I agree. The developers do their best and then some. All the ones I have talked with are really committed to making this the best product they can. They take a lot of pride and interest in the product, which you can tell because they are not REQUIRED to participate in this list; they do it because they care. That said, it is pretty clear that the management doesn't provide them the time and/or resources needed to do sufficient quality testing. We are still sitting at 4.2.1.15 on our servers, and 4.2.0.0 or 4.2.1.20 for our 400+ WIN2K clients. We will probably continue to sit on this version of client server even after the April deadline, because the largest server is running at max capacity and I can't tolerate the problems with Expiration and WIn2K system object issues and continue to run. Unfortunately I can no longer defend this product to the local management, because we have to dedicate so many people resources to it. Testing for the clients takes way too much time because we have to prove we can do a complete restore down to the last icon on the desktop. And as I said, we can't upgrade the server because of the known problems. Sooner or later that message has to get to IBM/Tivoli management. Unfortunately it looks like they have to start losing customers before they get it. My opinion, and nobody else's... Wanda Prather -Original Message- From: Kauffman, Tom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 9:48 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. And for my 2 cents worth, I see this as a TSM management and not development problem. There seems to be no regression test suite, and no change control/revision control process. Tom Kauffman NIBCO, Inc. -Original Message- From: Jolliff, Dale [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 9:06 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. Just my opinion, but based on the bug releases of late, they are doing a pretty good bagging job on their own.
Re: Stop Bagging TSM Developers.
Just my opinion, but based on the bug releases of late, they are doing a pretty good bagging job on their own.
Re: Stop Bagging TSM Developers.
And for my 2 cents worth, I see this as a TSM management and not development problem. There seems to be no regression test suite, and no change control/revision control process. Tom Kauffman NIBCO, Inc. -Original Message- From: Jolliff, Dale [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 9:06 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. Just my opinion, but based on the bug releases of late, they are doing a pretty good bagging job on their own.
Re: Stop Bagging TSM Developers.
I'm sure being a TSM developer isn't much fun these days - I can sympathize with them a bit from the aspect of some things being out of their control. I have been writing some scripts for TSM this morning, and I'm in a bit of a bad mood - hence the snipe at the developers. Now that I'm venting up on the soapbox as it were, I'd like to say this - I can remember a couple of times seeing it requested on this list that we be able to disable the Copyright headers that are displayed when doing commandline functions with the admin client. I would think that would be a fairly simple thing to implement. Perhaps a command line switch to eliminate the header and trailer... If we just can't be eliminated, could it at least be made a consistent length between the -tabdelimited, -commadelimited and unformatted output? On another note, I just spent a week in training for another vendor's product and friends, the grass looks lot less greener over there... OK, I'm off the soapbox. I'll shut up. In three months I'll be wishing this was the worst I had to complain about. -Original Message- From: Kauffman, Tom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 8:48 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. And for my 2 cents worth, I see this as a TSM management and not development problem. There seems to be no regression test suite, and no change control/revision control process. Tom Kauffman NIBCO, Inc. -Original Message- From: Jolliff, Dale [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 9:06 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. Just my opinion, but based on the bug releases of late, they are doing a pretty good bagging job on their own.
Re: Stop Bagging TSM Developers.
A workaround is to create a macro file of the command(s) you want, and redirect each of them to a file. Them run DSMADMC with MACRO macrofile and the results will be without the headers. I like to use -TAB and -ITEMCOMMIT options. like this: Q ACT BEGINT=-01:00 QACT.TXT and you'll get your output, tab delimited without the headers. A co-worker turned me on to this. I've used this in several Perl scripts to product activity reports. Bill Boyer Hit any user to continue! - ??? -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Jolliff, Dale Sent: Tuesday, February 18, 2003 12:07 PM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. I'm sure being a TSM developer isn't much fun these days - I can sympathize with them a bit from the aspect of some things being out of their control. I have been writing some scripts for TSM this morning, and I'm in a bit of a bad mood - hence the snipe at the developers. Now that I'm venting up on the soapbox as it were, I'd like to say this - I can remember a couple of times seeing it requested on this list that we be able to disable the Copyright headers that are displayed when doing commandline functions with the admin client. I would think that would be a fairly simple thing to implement. Perhaps a command line switch to eliminate the header and trailer... If we just can't be eliminated, could it at least be made a consistent length between the -tabdelimited, -commadelimited and unformatted output? On another note, I just spent a week in training for another vendor's product and friends, the grass looks lot less greener over there... OK, I'm off the soapbox. I'll shut up. In three months I'll be wishing this was the worst I had to complain about. -Original Message- From: Kauffman, Tom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 8:48 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. And for my 2 cents worth, I see this as a TSM management and not development problem. There seems to be no regression test suite, and no change control/revision control process. Tom Kauffman NIBCO, Inc. -Original Message- From: Jolliff, Dale [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 9:06 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. Just my opinion, but based on the bug releases of late, they are doing a pretty good bagging job on their own.
Re: Stop Bagging TSM Developers.
Perhaps a command line switch to eliminate the header and trailer... Watch for an option to display just the data in an upcoming release. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS Internet e-mail: [EMAIL PROTECTED] (change eye to i to reply) The only dumb question is the one that goes unasked. The command line is your friend. Good enough is the enemy of excellence. Jolliff, Dale [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 02/18/2003 10:07 Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: Stop Bagging TSM Developers. I'm sure being a TSM developer isn't much fun these days - I can sympathize with them a bit from the aspect of some things being out of their control. I have been writing some scripts for TSM this morning, and I'm in a bit of a bad mood - hence the snipe at the developers. Now that I'm venting up on the soapbox as it were, I'd like to say this - I can remember a couple of times seeing it requested on this list that we be able to disable the Copyright headers that are displayed when doing commandline functions with the admin client. I would think that would be a fairly simple thing to implement. Perhaps a command line switch to eliminate the header and trailer... If we just can't be eliminated, could it at least be made a consistent length between the -tabdelimited, -commadelimited and unformatted output? On another note, I just spent a week in training for another vendor's product and friends, the grass looks lot less greener over there... OK, I'm off the soapbox. I'll shut up. In three months I'll be wishing this was the worst I had to complain about. -Original Message- From: Kauffman, Tom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 8:48 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. And for my 2 cents worth, I see this as a TSM management and not development problem. There seems to be no regression test suite, and no change control/revision control process. Tom Kauffman NIBCO, Inc. -Original Message- From: Jolliff, Dale [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 9:06 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. Just my opinion, but based on the bug releases of late, they are doing a pretty good bagging job on their own.
Re: Stop Bagging TSM Developers.
Hi Steve! I don't understand your message. I haven't read any offending message about development on this list. Sure, there are several complaints about the stability of TSM lately, but I think the people have the right to complain in this case. Lately there have been several patches to patch patchlevels (think about the system object fixes). We all have to upgrade TSM to 5.1.x before April 15th. but we are eagerly awaiting a stable PTF level. We all know that TSM development are all doing everything they can to fix all bugs and we DO appreciate that very much!! But I think I speak for a lot of users when I say that Tivoli should wait with implementing new features for a while so they can put all efforts in making the product more bug free. On my part I volunteered for the TSM Beta program to help Tivoli debugging this fine piece of software. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Steve Harris [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 03:29 To: [EMAIL PROTECTED] Subject: Stop Bagging TSM Developers. Dear List, I'm compelled to ask you to please stop bagging the TSM development and support folks. TSM is a very complex product running in very complex environments, no two of which are the same. It runs on multiple platforms both client and server. The product has evolved a long way from its origins, as has the computing environment in general - I am sure that many of the original assumptions that the developers made are no longer valid. For example, who, ten years ago would have thought that a 3TB disk store might be a cheap proposition? The TSM folks have contantly improved their product in response to user input and client OS developments - again some of these changes may well go against the philosophy of the product - take windows system objects for an instance. Change = vulnerabilty to error in the short term. As to support expertise, this is a niche product with few users. Level one and even level 2 folks need time to become familiar with it and they do that the same way as we do, by interacting with the product (or in their case with users of the product who have problems). Would you like to be a level 3 expert in TSM who spends your day doing lower expertise support tasks? I don't think so. And those level three folks are needed to enhance debug and develop the TSM product line. Finally I need to remind us all that TSM patches are just that, Patches designed to fix a particular problem. Whilst it is sometimes impossible to avoid the upgrade waltz that someone here has recently mentioned, upgrading to a patch level should only be done *if you are affected by the problem that the patch addresses*. If you don't have the problem, go to the maintenance level, not the latest patch. Shooting at the development and support folks is easy and feels good in the short term for the poster, but it is depressing in the long run for them and for the rest of the list, and, ultimately futile. I'd ask you all to think twice before firing off the next salvo. Steve Harris (Asbestos suit donned!) AIX and TSM Admin Queensland Health, Brisbane Australia ** This e-mail, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost if you receive it and you are not the intended recipient(s), or if it is transmitted/ received in error. Any unauthorised use, alteration, disclosure, distribution or review of this e-mail is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this e-mail in error, you are asked to immediately notify the sender by telephone or by return e-mail. You should also delete this e-mail message and destroy any hard copies produced. ** ** 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. **
Re: Stop Bagging TSM Developers.
Hello, I completely agree with Eric. Fix the bugs in the current level ant delay new functions. We are on 4.2.1.15 and we want to upgrade to a 5.x level... Bye Rainer Tammer On Mon, 17 Feb 2003 10:33:43 +0100, Loon, E.J. van - SPLXM wrote: Hi Steve! I don't understand your message. I haven't read any offending message about development on this list. Sure, there are several complaints about the stability of TSM lately, but I think the people have the right to complain in this case. Lately there have been several patches to patch patchlevels (think about the system object fixes). We all have to upgrade TSM to 5.1.x before April 15th. but we are eagerly awaiting a stable PTF level. We all know that TSM development are all doing everything they can to fix all bugs and we DO appreciate that very much!! But I think I speak for a lot of users when I say that Tivoli should wait with implementing new features for a while so they can put all efforts in making the product more bug free. On my part I volunteered for the TSM Beta program to help Tivoli debugging this fine piece of software. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Steve Harris [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 03:29 To: [EMAIL PROTECTED] Subject: Stop Bagging TSM Developers. Dear List, I'm compelled to ask you to please stop bagging the TSM development and support folks. TSM is a very complex product running in very complex environments, no two of which are the same. It runs on multiple platforms both client and server. The product has evolved a long way from its origins, as has the computing environment in general - I am sure that many of the original assumptions that the developers made are no longer valid. For example, who, ten years ago would have thought that a 3TB disk store might be a cheap proposition? The TSM folks have contantly improved their product in response to user input and client OS developments - again some of these changes may well go against the philosophy of the product - take windows system objects for an instance. Change = vulnerabilty to error in the short term. As to support expertise, this is a niche product with few users. Level one and even level 2 folks need time to become familiar with it and they do that the same way as we do, by interacting with the product (or in their case with users of the product who have problems). Would you like to be a level 3 expert in TSM who spends your day doing lower expertise support tasks? I don't think so. And those level three folks are needed to enhance debug and develop the TSM product line. Finally I need to remind us all that TSM patches are just that, Patches designed to fix a particular problem. Whilst it is sometimes impossible to avoid the upgrade waltz that someone here has recently mentioned, upgrading to a patch level should only be done *if you are affected by the problem that the patch addresses*. If you don't have the problem, go to the maintenance level, not the latest patch. Shooting at the development and support folks is easy and feels good in the short term for the poster, but it is depressing in the long run for them and for the rest of the list, and, ultimately futile. I'd ask you all to think twice before firing off the next salvo. Steve Harris (Asbestos suit donned!) AIX and TSM Admin Queensland Health, Brisbane Australia ** This e-mail, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost if you receive it and you are not the intended recipient(s), or if it is transmitted/ received in error. Any unauthorised use, alteration, disclosure, distribution or review of this e-mail is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this e-mail in error, you are asked to immediately notify the sender by telephone or by return e-mail. You should also delete this e-mail message and destroy any hard copies produced. ** ** 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
Re: Stop Bagging TSM Developers.
I think the number of TSM clients is about to grow dramatically in the near future. IBM has bundled TSM into a package called Enterprise Edition. If you purchase an iSeries, (formerly known as an AS/400), with the Enterprise package IBM is bundling a LOT of software. One of these is TSM. We have TSM (kinda) running on our iSeries. An older version, and the 5.1 for OS/400 PASE. We can't get the 5.1 version running for a day without having to reboot out iSeries. And rebooting an iSeries is not something you do on a whim, like a PC or something. Two things IBM is going to have to do: 1) Improve quality. 2) Gear up for additional support. Rob Berendt -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin
Re: Stop Bagging TSM Developers.
I have had a discussion with a Tivoli - IBM CE/Sales Rep and he stated that IBM appears to be getting the message that many of us want more stability that features, which will then dictate how many new versions per year will be released. -Original Message- From: Mark Bertrand [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 1:21 PM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. I also agree, Fix the bugs or extend the support on 4. Mark B. -Original Message- From: Rainer Tammer [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 8:16 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. Hello, I completely agree with Eric. Fix the bugs in the current level ant delay new functions. We are on 4.2.1.15 and we want to upgrade to a 5.x level... Bye Rainer Tammer On Mon, 17 Feb 2003 10:33:43 +0100, Loon, E.J. van - SPLXM wrote: Hi Steve! I don't understand your message. I haven't read any offending message about development on this list. Sure, there are several complaints about the stability of TSM lately, but I think the people have the right to complain in this case. Lately there have been several patches to patch patchlevels (think about the system object fixes). We all have to upgrade TSM to 5.1.x before April 15th. but we are eagerly awaiting a stable PTF level. We all know that TSM development are all doing everything they can to fix all bugs and we DO appreciate that very much!! But I think I speak for a lot of users when I say that Tivoli should wait with implementing new features for a while so they can put all efforts in making the product more bug free. On my part I volunteered for the TSM Beta program to help Tivoli debugging this fine piece of software. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Steve Harris [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 03:29 To: [EMAIL PROTECTED] Subject: Stop Bagging TSM Developers. Dear List, I'm compelled to ask you to please stop bagging the TSM development and support folks. TSM is a very complex product running in very complex environments, no two of which are the same. It runs on multiple platforms both client and server. The product has evolved a long way from its origins, as has the computing environment in general - I am sure that many of the original assumptions that the developers made are no longer valid. For example, who, ten years ago would have thought that a 3TB disk store might be a cheap proposition? The TSM folks have contantly improved their product in response to user input and client OS developments - again some of these changes may well go against the philosophy of the product - take windows system objects for an instance. Change = vulnerabilty to error in the short term. As to support expertise, this is a niche product with few users. Level one and even level 2 folks need time to become familiar with it and they do that the same way as we do, by interacting with the product (or in their case with users of the product who have problems). Would you like to be a level 3 expert in TSM who spends your day doing lower expertise support tasks? I don't think so. And those level three folks are needed to enhance debug and develop the TSM product line. Finally I need to remind us all that TSM patches are just that, Patches designed to fix a particular problem. Whilst it is sometimes impossible to avoid the upgrade waltz that someone here has recently mentioned, upgrading to a patch level should only be done *if you are affected by the problem that the patch addresses*. If you don't have the problem, go to the maintenance level, not the latest patch. Shooting at the development and support folks is easy and feels good in the short term for the poster, but it is depressing in the long run for them and for the rest of the list, and, ultimately futile. I'd ask you all to think twice before firing off the next salvo. Steve Harris (Asbestos suit donned!) AIX and TSM Admin Queensland Health, Brisbane Australia ** This e-mail, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost if you receive it and you are not the intended recipient(s), or if it is transmitted/ received in error. Any unauthorised use, alteration, disclosure, distribution or review of this e-mail is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this e-mail in error, you are asked to immediately notify the sender by telephone or by return e-mail. You should also delete this e-mail message and destroy any hard copies produced
Re: Stop Bagging TSM Developers.
I also agree, Fix the bugs or extend the support on 4. Mark B. -Original Message- From: Rainer Tammer [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 8:16 AM To: [EMAIL PROTECTED] Subject: Re: Stop Bagging TSM Developers. Hello, I completely agree with Eric. Fix the bugs in the current level ant delay new functions. We are on 4.2.1.15 and we want to upgrade to a 5.x level... Bye Rainer Tammer On Mon, 17 Feb 2003 10:33:43 +0100, Loon, E.J. van - SPLXM wrote: Hi Steve! I don't understand your message. I haven't read any offending message about development on this list. Sure, there are several complaints about the stability of TSM lately, but I think the people have the right to complain in this case. Lately there have been several patches to patch patchlevels (think about the system object fixes). We all have to upgrade TSM to 5.1.x before April 15th. but we are eagerly awaiting a stable PTF level. We all know that TSM development are all doing everything they can to fix all bugs and we DO appreciate that very much!! But I think I speak for a lot of users when I say that Tivoli should wait with implementing new features for a while so they can put all efforts in making the product more bug free. On my part I volunteered for the TSM Beta program to help Tivoli debugging this fine piece of software. Kindest regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: Steve Harris [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 03:29 To: [EMAIL PROTECTED] Subject: Stop Bagging TSM Developers. Dear List, I'm compelled to ask you to please stop bagging the TSM development and support folks. TSM is a very complex product running in very complex environments, no two of which are the same. It runs on multiple platforms both client and server. The product has evolved a long way from its origins, as has the computing environment in general - I am sure that many of the original assumptions that the developers made are no longer valid. For example, who, ten years ago would have thought that a 3TB disk store might be a cheap proposition? The TSM folks have contantly improved their product in response to user input and client OS developments - again some of these changes may well go against the philosophy of the product - take windows system objects for an instance. Change = vulnerabilty to error in the short term. As to support expertise, this is a niche product with few users. Level one and even level 2 folks need time to become familiar with it and they do that the same way as we do, by interacting with the product (or in their case with users of the product who have problems). Would you like to be a level 3 expert in TSM who spends your day doing lower expertise support tasks? I don't think so. And those level three folks are needed to enhance debug and develop the TSM product line. Finally I need to remind us all that TSM patches are just that, Patches designed to fix a particular problem. Whilst it is sometimes impossible to avoid the upgrade waltz that someone here has recently mentioned, upgrading to a patch level should only be done *if you are affected by the problem that the patch addresses*. If you don't have the problem, go to the maintenance level, not the latest patch. Shooting at the development and support folks is easy and feels good in the short term for the poster, but it is depressing in the long run for them and for the rest of the list, and, ultimately futile. I'd ask you all to think twice before firing off the next salvo. Steve Harris (Asbestos suit donned!) AIX and TSM Admin Queensland Health, Brisbane Australia ** This e-mail, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost if you receive it and you are not the intended recipient(s), or if it is transmitted/ received in error. Any unauthorised use, alteration, disclosure, distribution or review of this e-mail is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this e-mail in error, you are asked to immediately notify the sender by telephone or by return e-mail. You should also delete this e-mail message and destroy any hard copies produced. ** ** 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
