I worked for that guy before! ;-D This form of risk management might be
appropriate for supporting obsolete systems, like companies still
running S/36 applications, where ANYTHING that could break a system must
be carefully planned. But with a modern platform, this form of risk
management seems to cause more risk (by not applying patches, closing
security holes, upgrading vendor code to comply with new regulatory
mandates, etc.)
In a well managed environment, you might create a test partition, maybe
a clone of your production box, then upgrade and test the applications.
Once everyone is convinced that these updates work, then schedule the
upgrade for the production lpar. We use our development partition for
this.
-Eric
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Lennon_s_j@xxxxxxxxxxx
Sent: Wednesday, January 06, 2010 6:19 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: TAATOOL Usage in Production Code
On 1/6/2010 5:52 PM, ALopez@xxxxxxxxxx wrote:
We use directly in PRODUCTION.
I wonder what your boss would want to do with products like SEQUEL?
Boss doesn't like purchased software and regular upgrades.
I think he's worried that if we upgrade purchased software it may cause
production code to break. Which I admit is a possibility, but I think
it is pretty remote. Probably about the same chance as doing an OS
upgrade.
I'm building a case to try to talk him out of it.
Prior developers didn't use TAATOOLs much but they did extract few into
our production source. Personally, my approach is to code
"TAATOOL/cmdname" and let the product lib take care of getting the right
object.
Thanks to those who have responded.
(However, we did just install Aldon LMi. And we got the latest TAATOOL
when we went to V6R1.)
midrange.com
