Staying current with maintenance and validation

Daniel Lapp

Staying current with maintenance and validation
I'm a DB2 system programmer who would like to better understand how folks validate maintenance and what their idea of staying current is. First off IBM puts out monthly PUT tapes and quarterly RSUs, correct ? Their recommendation is to go to an RSU; but what about HIPER PTFs ? If you track them how do people decide which ones should go on and which ones don't ? If a hiper describes a situation that may occur but has not occurred yet (in your shop) and it describes your architecture, should an effort be made in a test environment to prove your vulnerability before just slapping it on ? Being a systems programmer I download and have new fixes at the ready between maintenance cycles so if an issue is encountered it's quick to get it fixed (provided the fix is available and I have it in house). What about validation ? If the politics dictate you must put a fix on even though the failing event has never occurred in your shop is it unreasonable to expect the applications side of the house to recreate the possible situation as outlined in the description supplied by the PTF as part of their validation before and after the PTF is applied ?

Speaking of validation, I am always able to run the IVP supplied by the vendor (but certainly more extensive validation is required) but what is considered a good validation architecture and process ? Anyone know where I could find some good information on that ?

Lastly, regarding all the third party products that only supply quarterly PUT tapes and it can become a full time job for one person just to keep up. This is especially true where one person is expected to maintain every third party product in the shop. After going to a PUT you find yourself with a list of fixes and hipers that is as long as the list of fixes inn the PUT you just applied . How do folks avoid the "painting the bridge mentality" where you suddenly find yourself in a nonstop cycle of applying fixes with no time to anything like process improvement or performance tuning ?

I realize (because I've been doing this function for longer than I like to admit) that systems programming has always been a balance best controlled by good process and procedures (rules). But I would love to hear what folks have to share about the topic since doing more with less is more apropos today than when folks first starting using the phrase.

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Avram Friedman

Re: Staying current with maintenance and validation
(in response to Daniel Lapp)
HIPERS
Don't get hyper about HIPERS.
Don't pull ahead of your target to pickup HIPERS and PE fixes.
(Don't put on a PE unless the fix is also at your target level)
I worked at a large datasharing shop that had almost dayly unscheduled outages.
We stopped being hyper about HIPERS and the shop became stable.

How current
I like to stay atleast 1 tape behind what ever a tape represents.
Let some other agressive systems programmer find the PEs for me.
The reality is the customer gets to decide on and fund the question of currency.
We have a customer (i work for an out sourcer) who is running DB2 V3.
Its as solid as a rock and the customer neither wants the outage (very high availability) or the risk.
One customer just got off V4 ... an almost unused system just excerised for some rare testing.
The customer is a software application ISV firm.
I would guess over 1/2 our customers are on unsupported versions of DB2, not at the outsourcers choicebut the clients choice.
We as an outsourcer prefer to be on supported software so we can get the vendors help without paying extra.
THe reality is of those things we are allowed to maintain, service gets applied once every year or so.
Let me stress we have lots of customers, losts of CPUs, lots of diffrent type of business requirements and not scheduled outages of major mainframe subsystems like DB2 can be correctly estimated at zero, non existant.

Validation.
Don't deliver anything that will be a clear embarasement.
When I was contracting for IBM in Poughkeepsie one of the projects I worked on was reestablishing centeralized service test.
Servicetest ran system tests of pre core closed service once a week. Core closed is when a PTF gets assigned to a tape for preventive delivery.
One of several reasons why service test was reextablished in Poughkeepsie and a day a week each were dedicated to testing DB2, IMS, and CICS non of which Poughkeepsie supports was to avoid the embarasement of a customer applying service and then reporting that a major subsystem won't start.
AT LEAST MAKE SURE THE PRODUCT WILL START UP BEFORE DELIVERY.
Take the actions indicated by the HOLD data
For extra credit
Try a command like -DIS THREAD(*)
Test system operation by forcing a log switch and make sure that ARCHIVE runs
Verify SQL by doing a SELECT * FROM SYSIBM.SYSVOLUMES in SPUFI
For extra extra credit ...
extra extra credit because these are complex t ests that need 2 things opperational
Check that DDF is both connected to the network and talking
Check that the connections to IMS, CICS, and MQ appear to work (You already did TSO and the console)
Make sure you have a sound backout plan, In DB2 land restoring the old SDSNLOAD does not cut it.

Planing ahead.
Good to


On Sun, 23 Jan 2011 10:06:07 -0500, Daniel Lapp <[login to unmask email]> wrote:

>I'm a DB2 system programmer who would like to better understand how folks validate maintenance and what their idea of staying current is. First off IBM puts out monthly PUT tapes and quarterly RSUs, correct ? Their recommendation is to go to an RSU; but what about HIPER PTFs ? If you track them how do people decide which ones should go on and which ones don't ? If a hiper describes a situation that may occur but has not occurred yet (in your shop) and it describes your architecture, should an effort be made in a test environment to prove your vulnerability before just slapping it on ? Being a systems programmer I download and have new fixes at the ready between maintenance cycles so if an issue is encountered it's quick to get it fixed (provided the fix is available and I have it in house). What about validation ? If the politics dictate you must put a fix on even though the failing event has never occurred in your shop is it unreasonable to expect the applications side of the house to recreate the possible situation as outlined in the description supplied by the PTF as part of their validation before and after the PTF is applied ?
>
>Speaking of validation, I am always able to run the IVP supplied by the vendor (but certainly more extensive validation is required) but what is considered a good validation architecture and process ? Anyone know where I could find some good information on that ?
>
>Lastly, regarding all the third party products that only supply quarterly PUT tapes and it can become a full time job for one person just to keep up. This is especially true where one person is expected to maintain every third party product in the shop. After going to a PUT you find yourself with a list of fixes and hipers that is as long as the list of fixes inn the PUT you just applied . How do folks avoid the "painting the bridge mentality" where you suddenly find yourself in a nonstop cycle of applying fixes with no time to anything like process improvement or performance tuning ?
>
>I realize (because I've been doing this function for longer than I like to admit) that systems programming has always been a balance best controlled by good process and procedures (rules). But I would love to hear what folks have to share about the topic since doing more with less is more apropos today than when folks first starting using the phrase.
>
>_____________________________________________________________________
>* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
>* If you are going to attend only one conference this year, this is it! *
>** DB2 certification -> no additional charge
>** Meet fellow DB2 users and leading DB2 consultants
>_____________________________________________________________________
>
>If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Avram Friedman

Re: Staying current with maintenance and validation
(in response to Avram Friedman)
hit enter by mistake adding a few extra lines to my original reply in line

On Sun, 23 Jan 2011 19:04:44 -0500, Avram Friedman <[login to unmask email]> wrote:

>HIPERS
>Don't get hyper about HIPERS.
>Don't pull ahead of your target to pickup HIPERS and PE fixes.
>(Don't put on a PE unless the fix is also at your target level)
>I worked at a large datasharing shop that had almost dayly unscheduled outages.
>We stopped being hyper about HIPERS and the shop became stable.
>
>How current
>I like to stay atleast 1 tape behind what ever a tape represents.
>Let some other agressive systems programmer find the PEs for me.
>The reality is the customer gets to decide on and fund the question of currency.
>We have a customer (i work for an out sourcer) who is running DB2 V3.
>Its as solid as a rock and the customer neither wants the outage (very high availability) or the risk of a change.
>One customer just got off V4 ... an almost unused system just excerised for some rare testing.
>The customer is a software application ISV firm.
>I would guess over 1/2 our customers are on unsupported versions of DB2, not at the outsourcers choice but the clients choice.
>We as an outsourcer prefer to be on supported software so we can get the vendors help without paying extra.
>THe reality is of those things we are allowed to maintain, service gets applied once every year or so.
>Let me stress we have lots of customers, losts of CPUs, lots of diffrent type of business requirements and the number of unscheduled outages of major mainframe subsystems like DB2 can be correctly estimated at zero, non existant.
>
>Validation.
>Don't deliver anything that will be a clear embarasement.
>When I was contracting for IBM in Poughkeepsie one of the projects I worked on was reestablishing centeralized service test.
>Servicetest ran system tests of pre core closed service once a week. Core closed is when a PTF gets assigned to a tape for preventive delivery.
>One of several reasons why service test was reextablished in Poughkeepsie and a day a week each were dedicated to testing DB2, IMS, and CICS non of which Poughkeepsie supports was to avoid the embarasement of a customer applying service and then reporting that a major subsystem won't start.
>AT LEAST MAKE SURE THE PRODUCT WILL START UP BEFORE DELIVERY.
>Take the actions indicated by the HOLD data
>For extra credit
> Try a command like -DIS THREAD(*)
> Test system operation by forcing a log switch and make sure that ARCHIVE runs
> Verify SQL by doing a SELECT * FROM SYSIBM.SYSVOLUMES in SPUFI
>For extra extra credit ...
> extra extra credit because these are complex t ests that need 2 things opperational
> Check that DDF is both connected to the network and talking
> Check that the connections to IMS, CICS, and MQ appear to work (You already did TSO and the console)
>Make sure you have a sound backout plan, In DB2 land restoring the old SDSNLOAD does not cut it.
>
>Planing ahead.
Good to do but do not pre execute.
For example do not pre receive the next tape.
Its just to easy to do an APPLY ... GROUP EXTEND

Don't do too much.
For example systems programmers are not end application users. Once you add end application user testing as a roll out requirement you are screwed in the preventive world. Once you ask a single m-f 9 to 5er person to get up for a 5 minute test at some time around 3 am on Sunday morning exact time to be determined by what may or may not happen you will encounter resistance. Guess what happens if you make such a request of say 2 end application users. How many people do you typically invite when you change the oil in your car?

If you are taking more than 1 unscheduled DB2 outage a year then you may be doing something wrong. Doing to much is a very common error. The other common error is not including a service window in SLAs.

Hope this is of some help
Avram Friedman


>
>
>On Sun, 23 Jan 2011 10:06:07 -0500, Daniel Lapp <[login to unmask email]> wrote:
>
>>I'm a DB2 system programmer who would like to better understand how folks validate maintenance and what their idea of staying current is. First off IBM puts out monthly PUT tapes and quarterly RSUs, correct ? Their recommendation is to go to an RSU; but what about HIPER PTFs ? If you track them how do people decide which ones should go on and which ones don't ? If a hiper describes a situation that may occur but has not occurred yet (in your shop) and it describes your architecture, should an effort be made in a test environment to prove your vulnerability before just slapping it on ? Being a systems programmer I download and have new fixes at the ready between maintenance cycles so if an issue is encountered it's quick to get it fixed (provided the fix is available and I have it in house). What about validation ? If the politics dictate you must put a fix on even though the failing event has never occurred in your shop is it unreasonable to expect the applications side of the house to recreate the possible situation as outlined in the description supplied by the PTF as part of their validation before and after the PTF is applied ?
>>
>>Speaking of validation, I am always able to run the IVP supplied by the vendor (but certainly more extensive validation is required) but what is considered a good validation architecture and process ? Anyone know where I could find some good information on that ?
>>
>>Lastly, regarding all the third party products that only supply quarterly PUT tapes and it can become a full time job for one person just to keep up. This is especially true where one person is expected to maintain every third party product in the shop. After going to a PUT you find yourself with a list of fixes and hipers that is as long as the list of fixes inn the PUT you just applied . How do folks avoid the "painting the bridge mentality" where you suddenly find yourself in a nonstop cycle of applying fixes with no time to anything like process improvement or performance tuning ?
>>
>>I realize (because I've been doing this function for longer than I like to admit) that systems programming has always been a balance best controlled by good process and procedures (rules). But I would love to hear what folks have to share about the topic since doing more with less is more apropos today than when folks first starting using the phrase.
>>
>>_____________________________________________________________________
>>* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
>>* If you are going to attend only one conference this year, this is it! *
>>** DB2 certification -> no additional charge
>>** Meet fellow DB2 users and leading DB2 consultants
>>_____________________________________________________________________
>>
>>If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv
>
>_____________________________________________________________________
>* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
>* If you are going to attend only one conference this year, this is it! *
>** DB2 certification -> no additional charge
>** Meet fellow DB2 users and leading DB2 consultants
>_____________________________________________________________________
>
>If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Daniel Lapp

Re: Staying current with maintenance and validation
(in response to Avram Friedman)
Thanks Avram, I come from the same school you do ! I hate being forced to
put on hipers for the sake of, "that could happen to us" even when that
problem has not happened to us. My experience is also that most vendors
will always tell you to be current meaning "today" if there is a new fix
available. It's called CYA for the vendor (in my opinion) and I don't blame
them. But the reality is that most vendors can not account for every
combination of software that each of their customers run and therefore use
words and phrases like, "Some customers may experience a Soc 4 abend if
........". You get the point

On Sun, Jan 23, 2011 at 10:06 AM, Daniel Lapp <[login to unmask email]> wrote:

> I'm a DB2 system programmer who would like to better understand how folks
> validate maintenance and what their idea of staying current is. First off
> IBM puts out monthly PUT tapes and quarterly RSUs, correct ? Their
> recommendation is to go to an RSU; but what about HIPER PTFs ? If you track
> them how do people decide which ones should go on and which ones don't ? If
> a hiper describes a situation that may occur but has not occurred yet (in
> your shop) and it describes your architecture, should an effort be made in a
> test environment to prove your vulnerability before just slapping it on ?
> Being a systems programmer I download and have new fixes at the ready
> between maintenance cycles so if an issue is encountered it's quick to get
> it fixed (provided the fix is available and I have it in house). What about
> validation ? If the politics dictate you must put a fix on even though the
> failing event has never occurred in your shop is it unreasonable to expect
> the applications side of the house to recreate the possible situation as
> outlined in the description supplied by the PTF as part of their validation
> before and after the PTF is applied ?
>
> Speaking of validation, I am always able to run the IVP supplied by the
> vendor (but certainly more extensive validation is required) but what is
> considered a good validation architecture and process ? Anyone know where I
> could find some good information on that ?
>
> Lastly, regarding all the third party products that only supply quarterly
> PUT tapes and it can become a full time job for one person just to keep up.
> This is especially true where one person is expected to maintain every
> third party product in the shop. After going to a PUT you find yourself
> with a list of fixes and hipers that is as long as the list of fixes inn the
> PUT you just applied . How do folks avoid the "painting the bridge
> mentality" where you suddenly find yourself in a nonstop cycle of applying
> fixes with no time to anything like process improvement or performance
> tuning ?
>
> I realize (because I've been doing this function for longer than I like to
> admit) that systems programming has always been a balance best controlled by
> good process and procedures (rules). But I would love to hear what folks
> have to share about the topic since doing more with less is more apropos
> today than when folks first starting using the phrase.
>
>


--
Dan Lapp
"The lapper"

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Cathy Taddei

Re: Staying current with maintenance and validation
(in response to Daniel Lapp)
I don't sweat it. If IBM puts out a PTF, I assume it to be "safe", so I don't spend any time at all wondering whether we have experienced the problem that it purports to fix. I do RSU maintenance once or twice a year, including all hipers. I always select the most current RSU level, because the RSU is by definition already 3 months old. The most time-consuming part is reading all the hold data and creating the implementation script. For IVP's I run DSNTEJ1 through 2C; validation consists of informing applications that new maintenance has been applied to the system test environment. When it's time to go to production, I get sign-off from applications that their testing was successful, then I'm good to go. I spend relatively little time maintaining DB2, which is good because I also support 3rd party tools, DASD management, and I'm now learning CICS.

HTH,
Cathy

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Daniel Lapp
Sent: Sunday, January 23, 2011 7:06 AM
To: [login to unmask email]
Subject: [DB2-L] Staying current with maintenance and validation

I'm a DB2 system programmer who would like to better understand how folks validate maintenance and what their idea of staying current is. First off IBM puts out monthly PUT tapes and quarterly RSUs, correct ? Their recommendation is to go to an RSU; but what about HIPER PTFs ? If you track them how do people decide which ones should go on and which ones don't ? If a hiper describes a situation that may occur but has not occurred yet (in your shop) and it describes your architecture, should an effort be made in a test environment to prove your vulnerability before just slapping it on ? Being a systems programmer I download and have new fixes at the ready between maintenance cycles so if an issue is encountered it's quick to get it fixed (provided the fix is available and I have it in house). What about validation ? If the politics dictate you must put a fix on even though the failing event has never occurred in your shop is it unreasonable to expect the applications side of the house to recreate the possible situation as outlined in the description supplied by the PTF as part of their validation before and after the PTF is applied ?

Speaking of validation, I am always able to run the IVP supplied by the vendor (but certainly more extensive validation is required) but what is considered a good validation architecture and process ? Anyone know where I could find some good information on that ?

Lastly, regarding all the third party products that only supply quarterly PUT tapes and it can become a full time job for one person just to keep up. This is especially true where one person is expected to maintain every third party product in the shop. After going to a PUT you find yourself with a list of fixes and hipers that is as long as the list of fixes inn the PUT you just applied . How do folks avoid the "painting the bridge mentality" where you suddenly find yourself in a nonstop cycle of applying fixes with no time to anything like process improvement or performance tuning ?

I realize (because I've been doing this function for longer than I like to admit) that systems programming has always been a balance best controlled by good process and procedures (rules). But I would love to hear what folks have to share about the topic since doing more with less is more apropos today than when folks first starting using the phrase.

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Daniel Lapp

Re: Staying current with maintenance and validation
(in response to Cathy Taddei)
I agree about DB2 and IBM but, it's the third party products I'm much more
worried about.

On Wed, Jan 26, 2011 at 1:59 PM, Taddei, Cathy
<[login to unmask email]>wrote:

> I don't sweat it. If IBM puts out a PTF, I assume it to be "safe", so I
> don't spend any time at all wondering whether we have experienced the
> problem that it purports to fix. I do RSU maintenance once or twice a year,
> including all hipers. I always select the most current RSU level, because
> the RSU is by definition already 3 months old. The most time-consuming part
> is reading all the hold data and creating the implementation script. For
> IVP's I run DSNTEJ1 through 2C; validation consists of informing
> applications that new maintenance has been applied to the system test
> environment. When it's time to go to production, I get sign-off from
> applications that their testing was successful, then I'm good to go. I
> spend relatively little time maintaining DB2, which is good because I also
> support 3rd party tools, DASD management, and I'm now learning CICS.
>
> HTH,
> Cathy
>
> -----Original Message-----
> From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Daniel Lapp
> Sent: Sunday, January 23, 2011 7:06 AM
> To: [login to unmask email]
> Subject: [DB2-L] Staying current with maintenance and validation
>
> I'm a DB2 system programmer who would like to better understand how folks
> validate maintenance and what their idea of staying current is. First off
> IBM puts out monthly PUT tapes and quarterly RSUs, correct ? Their
> recommendation is to go to an RSU; but what about HIPER PTFs ? If you track
> them how do people decide which ones should go on and which ones don't ? If
> a hiper describes a situation that may occur but has not occurred yet (in
> your shop) and it describes your architecture, should an effort be made in a
> test environment to prove your vulnerability before just slapping it on ?
> Being a systems programmer I download and have new fixes at the ready
> between maintenance cycles so if an issue is encountered it's quick to get
> it fixed (provided the fix is available and I have it in house). What about
> validation ? If the politics dictate you must put a fix on even though the
> failing event has never occurred in your shop is it unreasonable to expect
> the applications side of the house to recreate the possible situation as
> outlined in the description supplied by the PTF as part of their validation
> before and after the PTF is applied ?
>
> Speaking of validation, I am always able to run the IVP supplied by the
> vendor (but certainly more extensive validation is required) but what is
> considered a good validation architecture and process ? Anyone know where I
> could find some good information on that ?
>
> Lastly, regarding all the third party products that only supply quarterly
> PUT tapes and it can become a full time job for one person just to keep up.
> This is especially true where one person is expected to maintain every
> third party product in the shop. After going to a PUT you find yourself
> with a list of fixes and hipers that is as long as the list of fixes inn the
> PUT you just applied . How do folks avoid the "painting the bridge
> mentality" where you suddenly find yourself in a nonstop cycle of applying
> fixes with no time to anything like process improvement or performance
> tuning ?
>
> I realize (because I've been doing this function for longer than I like to
> admit) that systems programming has always been a balance best controlled by
> good process and procedures (rules). But I would love to hear what folks
> have to share about the topic since doing more with less is more apropos
> today than when folks first starting using the phrase.
>
> _____________________________________________________________________
> * IDUG North America * Anaheim, California * May 2-6 2011 *
> http://IDUG.ORG/NA *
> * If you are going to attend only one conference this year, this is it!
> *
> ** DB2 certification -> no additional charge
> ** Meet fellow DB2 users and leading DB2 consultants
> _____________________________________________________________________
>
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
> the home of IDUG's Listserv
>
> _____________________________________________________________________
> * IDUG North America * Anaheim, California * May 2-6 2011 *
> http://IDUG.ORG/NA *
> * Your only source for independent, unbiased, and trusted DB2
> information. *
> ** The most DB2 technical sessions of any conference
> ** Access IBM experts and developers
> _____________________________________________________________________
>
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
> the home of IDUG's Listserv
>



--
Dan Lapp
"The lapper"

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Raymond Bell

Re: Staying current with maintenance and validation
(in response to Daniel Lapp)
BMC do something broadly equivalent to a quarterly RSU. Some like to be bang up-to-date, others like to wait 3, 6, or even more months before going to a PUT as we call 'em. Plus our equivalent of HIPERs, which we proactively notify customers of. Some combo of PUTs and HIPERs keep most of our customers happy.

And Dan, you do know who invented the term PE, right? ;o)

Cheers,


Raymond

________________________________
From: IDUG DB2-L [[login to unmask email] On Behalf Of Daniel Lapp [[login to unmask email]
Sent: 26 January 2011 19:19
To: [login to unmask email]
Subject: Re: [DB2-L] Staying current with maintenance and validation

I agree about DB2 and IBM but, it's the third party products I'm much more worried about.

On Wed, Jan 26, 2011 at 1:59 PM, Taddei, Cathy <[login to unmask email]<mailto:[login to unmask email]>> wrote:
I don't sweat it. If IBM puts out a PTF, I assume it to be "safe", so I don't spend any time at all wondering whether we have experienced the problem that it purports to fix. I do RSU maintenance once or twice a year, including all hipers. I always select the most current RSU level, because the RSU is by definition already 3 months old. The most time-consuming part is reading all the hold data and creating the implementation script. For IVP's I run DSNTEJ1 through 2C; validation consists of informing applications that new maintenance has been applied to the system test environment. When it's time to go to production, I get sign-off from applications that their testing was successful, then I'm good to go. I spend relatively little time maintaining DB2, which is good because I also support 3rd party tools, DASD management, and I'm now learning CICS.

HTH,
Cathy

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of Daniel Lapp
Sent: Sunday, January 23, 2011 7:06 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] Staying current with maintenance and validation

I'm a DB2 system programmer who would like to better understand how folks validate maintenance and what their idea of staying current is. First off IBM puts out monthly PUT tapes and quarterly RSUs, correct ? Their recommendation is to go to an RSU; but what about HIPER PTFs ? If you track them how do people decide which ones should go on and which ones don't ? If a hiper describes a situation that may occur but has not occurred yet (in your shop) and it describes your architecture, should an effort be made in a test environment to prove your vulnerability before just slapping it on ? Being a systems programmer I download and have new fixes at the ready between maintenance cycles so if an issue is encountered it's quick to get it fixed (provided the fix is available and I have it in house). What about validation ? If the politics dictate you must put a fix on even though the failing event has never occurred in your shop is it unreasonable to expect the applications side of the house to recreate the possible situation as outlined in the description supplied by the PTF as part of their validation before and after the PTF is applied ?

Speaking of validation, I am always able to run the IVP supplied by the vendor (but certainly more extensive validation is required) but what is considered a good validation architecture and process ? Anyone know where I could find some good information on that ?

Lastly, regarding all the third party products that only supply quarterly PUT tapes and it can become a full time job for one person just to keep up. This is especially true where one person is expected to maintain every third party product in the shop. After going to a PUT you find yourself with a list of fixes and hipers that is as long as the list of fixes inn the PUT you just applied . How do folks avoid the "painting the bridge mentality" where you suddenly find yourself in a nonstop cycle of applying fixes with no time to anything like process improvement or performance tuning ?

I realize (because I've been doing this function for longer than I like to admit) that systems programming has always been a balance best controlled by good process and procedures (rules). But I would love to hear what folks have to share about the topic since doing more with less is more apropos today than when folks first starting using the phrase.

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv



--
Dan Lapp
"The lapper"


________________________________

[ http://www.idug.org/images/stories/db2/db2_10_savings.jpg ] < http://www-01.ibm.com/software/data/db2/zos/db2-10/ >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Cathy Taddei

Re: Staying current with maintenance and validation
(in response to Raymond Bell)
Yeah, third party products are a mixed bag. It depends on how we use them and how well the vendor supports them. Some get maintained twice a year, once a year, only for upgrades, or almost never. Some products that are rock solid in our shop could require frequent maintenance in another. I hate to touch some products because trouble always follows. But I do stay on supported releases, and if I find myself reporting a lot of problems to a vendor, then I'll try to stay more up to date on that product's maintenance.

Regards,
Cathy

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Daniel Lapp
Sent: Wednesday, January 26, 2011 11:20 AM
To: [login to unmask email]
Subject: Re: [DB2-L] Staying current with maintenance and validation

I agree about DB2 and IBM but, it's the third party products I'm much more worried about.
On Wed, Jan 26, 2011 at 1:59 PM, Taddei, Cathy <[login to unmask email]<mailto:[login to unmask email]>> wrote:
I don't sweat it. If IBM puts out a PTF, I assume it to be "safe", so I don't spend any time at all wondering whether we have experienced the problem that it purports to fix. I do RSU maintenance once or twice a year, including all hipers. I always select the most current RSU level, because the RSU is by definition already 3 months old. The most time-consuming part is reading all the hold data and creating the implementation script. For IVP's I run DSNTEJ1 through 2C; validation consists of informing applications that new maintenance has been applied to the system test environment. When it's time to go to production, I get sign-off from applications that their testing was successful, then I'm good to go. I spend relatively little time maintaining DB2, which is good because I also support 3rd party tools, DASD management, and I'm now learning CICS.

HTH,
Cathy

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>] On Behalf Of Daniel Lapp
Sent: Sunday, January 23, 2011 7:06 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] Staying current with maintenance and validation

I'm a DB2 system programmer who would like to better understand how folks validate maintenance and what their idea of staying current is. First off IBM puts out monthly PUT tapes and quarterly RSUs, correct ? Their recommendation is to go to an RSU; but what about HIPER PTFs ? If you track them how do people decide which ones should go on and which ones don't ? If a hiper describes a situation that may occur but has not occurred yet (in your shop) and it describes your architecture, should an effort be made in a test environment to prove your vulnerability before just slapping it on ? Being a systems programmer I download and have new fixes at the ready between maintenance cycles so if an issue is encountered it's quick to get it fixed (provided the fix is available and I have it in house). What about validation ? If the politics dictate you must put a fix on even though the failing event has never occurred in your shop is it unreasonable to expect the applications side of the house to recreate the possible situation as outlined in the description supplied by the PTF as part of their validation before and after the PTF is applied ?

Speaking of validation, I am always able to run the IVP supplied by the vendor (but certainly more extensive validation is required) but what is considered a good validation architecture and process ? Anyone know where I could find some good information on that ?

Lastly, regarding all the third party products that only supply quarterly PUT tapes and it can become a full time job for one person just to keep up. This is especially true where one person is expected to maintain every third party product in the shop. After going to a PUT you find yourself with a list of fixes and hipers that is as long as the list of fixes inn the PUT you just applied . How do folks avoid the "painting the bridge mentality" where you suddenly find yourself in a nonstop cycle of applying fixes with no time to anything like process improvement or performance tuning ?

I realize (because I've been doing this function for longer than I like to admit) that systems programming has always been a balance best controlled by good process and procedures (rules). But I would love to hear what folks have to share about the topic since doing more with less is more apropos today than when folks first starting using the phrase.
_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv



--
Dan Lapp
"The lapper"

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Daniel Lapp

Re: Staying current with maintenance and validation
(in response to Cathy Taddei)
Actually I don't know who invented the term PE.

Any suggestions on how to decide the combination of PUTs and HIPERs to use
without having to add maintenance weekly ? I'm all ears, and what's your
opinion on putting on every HIPER that BMC announces between quarterly PUTs
? I ask because I would love to do a better job and I read the descriptions
of the HIPERS so, I have to assume (maybe incorrectly) not every HIPER may
be needed for our environment.

On Wed, Jan 26, 2011 at 4:56 PM, Bell, Raymond <[login to unmask email]> wrote:

> BMC do something broadly equivalent to a quarterly RSU. Some like to be
> bang up-to-date, others like to wait 3, 6, or even more months before going
> to a PUT as we call 'em. Plus our equivalent of HIPERs, which we
> proactively notify customers of. Some combo of PUTs and HIPERs keep most of
> our customers happy.
>
> And Dan, you do know who invented the term PE, right? ;o)
>
> Cheers,
>
>
> Raymond
>
> ________________________________
> From: IDUG DB2-L [[login to unmask email] On Behalf Of Daniel Lapp [
> [login to unmask email]
> Sent: 26 January 2011 19:19
> To: [login to unmask email]
> Subject: Re: [DB2-L] Staying current with maintenance and validation
>
> I agree about DB2 and IBM but, it's the third party products I'm much more
> worried about.
>
> On Wed, Jan 26, 2011 at 1:59 PM, Taddei, Cathy <
> [login to unmask email]<mailto:[login to unmask email]>> wrote:
> I don't sweat it. If IBM puts out a PTF, I assume it to be "safe", so I
> don't spend any time at all wondering whether we have experienced the
> problem that it purports to fix. I do RSU maintenance once or twice a year,
> including all hipers. I always select the most current RSU level, because
> the RSU is by definition already 3 months old. The most time-consuming part
> is reading all the hold data and creating the implementation script. For
> IVP's I run DSNTEJ1 through 2C; validation consists of informing
> applications that new maintenance has been applied to the system test
> environment. When it's time to go to production, I get sign-off from
> applications that their testing was successful, then I'm good to go. I
> spend relatively little time maintaining DB2, which is good because I also
> support 3rd party tools, DASD management, and I'm now learning CICS.
>
> HTH,
> Cathy
>
> -----Original Message-----
> From: IDUG DB2-L [mailto:[login to unmask email]<mailto:[login to unmask email]>]
> On Behalf Of Daniel Lapp
> Sent: Sunday, January 23, 2011 7:06 AM
> To: [login to unmask email]<mailto:[login to unmask email]>
> Subject: [DB2-L] Staying current with maintenance and validation
>
> I'm a DB2 system programmer who would like to better understand how folks
> validate maintenance and what their idea of staying current is. First off
> IBM puts out monthly PUT tapes and quarterly RSUs, correct ? Their
> recommendation is to go to an RSU; but what about HIPER PTFs ? If you track
> them how do people decide which ones should go on and which ones don't ? If
> a hiper describes a situation that may occur but has not occurred yet (in
> your shop) and it describes your architecture, should an effort be made in a
> test environment to prove your vulnerability before just slapping it on ?
> Being a systems programmer I download and have new fixes at the ready
> between maintenance cycles so if an issue is encountered it's quick to get
> it fixed (provided the fix is available and I have it in house). What about
> validation ? If the politics dictate you must put a fix on even though the
> failing event has never occurred in your shop is it unreasonable to expect
> the applications side of the house to recreate the possible situation as
> outlined in the description supplied by the PTF as part of their validation
> before and after the PTF is applied ?
>
> Speaking of validation, I am always able to run the IVP supplied by the
> vendor (but certainly more extensive validation is required) but what is
> considered a good validation architecture and process ? Anyone know where I
> could find some good information on that ?
>
> Lastly, regarding all the third party products that only supply quarterly
> PUT tapes and it can become a full time job for one person just to keep up.
> This is especially true where one person is expected to maintain every
> third party product in the shop. After going to a PUT you find yourself
> with a list of fixes and hipers that is as long as the list of fixes inn the
> PUT you just applied . How do folks avoid the "painting the bridge
> mentality" where you suddenly find yourself in a nonstop cycle of applying
> fixes with no time to anything like process improvement or performance
> tuning ?
>
> I realize (because I've been doing this function for longer than I like to
> admit) that systems programming has always been a balance best controlled by
> good process and procedures (rules). But I would love to hear what folks
> have to share about the topic since doing more with less is more apropos
> today than when folks first starting using the phrase.
>
> _____________________________________________________________________
> * IDUG North America * Anaheim, California * May 2-6 2011 *
> http://IDUG.ORG/NA *
> * If you are going to attend only one conference this year, this is it!
> *
> ** DB2 certification -> no additional charge
> ** Meet fellow DB2 users and leading DB2 consultants
> _____________________________________________________________________
>
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
> the home of IDUG's Listserv
>
> _____________________________________________________________________
> * IDUG North America * Anaheim, California * May 2-6 2011 *
> http://IDUG.ORG/NA *
> * Your only source for independent, unbiased, and trusted DB2
> information. *
> ** The most DB2 technical sessions of any conference
> ** Access IBM experts and developers
> _____________________________________________________________________
>
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
> the home of IDUG's Listserv
>
>
>
> --
> Dan Lapp
> "The lapper"
>
>
> ________________________________
>
> [ http://www.idug.org/images/stories/db2/db2_10_savings.jpg]<
> http://www-01.ibm.com/software/data/db2/zos/db2-10/>
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here.<
> http://www.idug.org/register>
>
> _____________________________________________________________________
> * IDUG North America * Anaheim, California * May 2-6 2011 *
> http://IDUG.ORG/NA *
> * Your only source for independent, unbiased, and trusted DB2
> information. *
> ** The most DB2 technical sessions of any conference
> ** Access IBM experts and developers
> _____________________________________________________________________
>
> If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
> the home of IDUG's Listserv
>



--
Dan Lapp
"The lapper"

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Ted MacNEIL

Re: Staying current with maintenance and validation
(in response to Daniel Lapp)
>Actually I don't know who invented the term PE. 

IBM.
I've been involved with MainFrames (acadamicly - sp) since 1971, and professionaly since 1981), and I've always known the term,

It just means PTF in error.
-
Ted MacNEIL
[login to unmask email]

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* Your only source for independent, unbiased, and trusted DB2 information. *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Raymond Bell

Re: Staying current with maintenance and validation
(in response to Ted MacNEIL)
Hi Dan,

I'm guessing you're a BMC customer. In which case Support are more than willing to help out with how best to receive/apply (SMP/E puns unintended) maintenance, as is your local Software Consultant. But you did ask for my opinion, so here it is. If you read the Flash text then you're already doing a better job than some. And you're right; any given Flash may not affect you, given the products involved and the combination of circumstances under which the situation might occur. It's a judgement call as to whether you apply them or not, but if in doubt I'd put it on. You may not meet the exact criteria for the Flash today but may do so later. And if it's just not relevant for your product set SMP/E will reject it anyway.

There's an expression here in the UK I've picked up describing a never-ending task as like 'painting the Forth Bridge'. (http://en.wikipedia.org/wiki/Forth_Bridge) The colloquial belief has it, incorrectly, that once the crew had finished painting the Forth Bridge they'd immediately start again. So to avoid applying maintenance becoming a Forth Bridge job, personally (and I don't think I can stress enough that this is my opinion, not BMCs) I'd look to be applying the 6-monthly PUT 'tapes' and any intervening HIPERs that are appropriate. It does, as I said before, also depend on your site's policy on maintenance currency.

I mentioned the term PE only to point out that, as they invented the term, even IBM makes mistakes. They might be better than most but they're still human. Oh God, did I just say that? ;o)

Hope that helps.

Cheers,


Raymond


From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Daniel Lapp
Sent: 27 January 2011 00:43
To: [login to unmask email]
Subject: Re: [DB2-L] Staying current with maintenance and validation

Actually I don't know who invented the term PE.

Any suggestions on how to decide the combination of PUTs and HIPERs to use without having to add maintenance weekly ? I'm all ears, and what's your opinion on putting on every HIPER that BMC announces between quarterly PUTs ? I ask because I would love to do a better job and I read the descriptions of the HIPERS so, I have to assume (maybe incorrectly) not every HIPER may be needed for our environment.
________________________________


_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Daniel Lapp

Re: Staying current with maintenance and validation
(in response to Raymond Bell)
Thank you Raymond ! I am always learning new things and am appreciative of
anyone that shares their experience and opinion. I always say, show me a
wise man and I'll show you a man with a lot of experience. I've never had
an original thought, what I know is what I've learned from others.

We try to do exactly as you say and apply the six month put tapes twice
yearly. In between I make every effort to receive maintenance so that I
have it in house (in my global) and can apply it quickly if we run into a
problem. Our in house policy is pretty strict and we read the flashes,
apply them as triage maintenance when we have time or the timing allows.
The descriptions in the flashes are very good. So, one thing I like to
insist on is an earnest attempt by the app support folks to create the
problem situation if we haven't had it occur per se or recreate it in a test
environment so that some good validation can be done after applying the fix
or fixes.

I always thought it was an American that can up with the term, "Like
painting a bridge" ? After painting one I would stop, but painting four ?
;-)

On Thu, Jan 27, 2011 at 4:17 AM, Bell, Raymond <[login to unmask email]> wrote:

> Hi Dan,
>
>
>
> I’m guessing you’re a BMC customer. In which case Support are more than
> willing to help out with how best to receive/apply (SMP/E puns unintended)
> maintenance, as is your local Software Consultant. But you did ask for my
> opinion, so here it is. If you read the Flash text then you’re already
> doing a better job than some. And you’re right; any given Flash may not
> affect you, given the products involved and the combination of circumstances
> under which the situation might occur. It’s a judgement call as to whether
> you apply them or not, but if in doubt I’d put it on. You may not meet the
> exact criteria for the Flash today but may do so later. And if it’s just
> not relevant for your product set SMP/E will reject it anyway.
>
>
>
> There’s an expression here in the UK I’ve picked up describing a
> never-ending task as like ‘painting the Forth Bridge’. (
> http://en.wikipedia.org/wiki/Forth_Bridge) The colloquial belief has it,
> incorrectly, that once the crew had finished painting the Forth Bridge
> they’d immediately start again. So to avoid applying maintenance becoming a
> Forth Bridge job, personally (and I don’t think I can stress enough that
> this is my opinion, not BMCs) I’d look to be applying the 6-monthly PUT
> ‘tapes’ and any intervening HIPERs that are appropriate. It does, as I said
> before, also depend on your site’s policy on maintenance currency.
>
>
>
> I mentioned the term PE only to point out that, as they invented the term,
> even IBM makes mistakes. They might be better than most but they’re still
> human. Oh God, did I just say that? ;o)
>
>
>
> Hope that helps.
>
>
>
> Cheers,
>
>
>
>
>
> Raymond
>
>
>
>
>
> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *Daniel Lapp
> *Sent:* 27 January 2011 00:43
>
> *To:* [login to unmask email]
> *Subject:* Re: [DB2-L] Staying current with maintenance and validation
>
>
>
> Actually I don't know who invented the term PE.
>
>
>
> Any suggestions on how to decide the combination of PUTs and HIPERs to use
> without having to add maintenance weekly ? I'm all ears, and what's your
> opinion on putting on every HIPER that BMC announces between quarterly PUTs
> ? I ask because I would love to do a better job and I read the descriptions
> of the HIPERS so, I have to assume (maybe incorrectly) not every HIPER may
> be needed for our environment.
>
> ________________________________
>
>
> ------------------------------
>
> [image: Independent, not-for-profit, User Run - the IDUG difference! ] < http://www.idug.org >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>



--
Dan Lapp
"The lapper"

_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Aurora Dell'Anno

Re: Staying current with maintenance and validation
(in response to Daniel Lapp)
Dan,

CA have a similar thing to the IBM RSU, we call it CARS (CA Recommended
Service). It's a similar concept - you get either the individual PTFs
when they are released, or you can get your CARS package about every 3
months.



Thanks.


Aurora


Aurora Emanuela Dell'Anno
CA Technology - MSC
Sr. Engineering Services Architect
Tel: +44 (0)1753 577 733
Mobile: +44 (0)7768 235 339
[login to unmask email]
<mailto:[login to unmask email]>
CA Technology R&D Limited, Ditton Park, Riding Court Road, Datchet,
Slough, Berkshire, England SL3 9LL.

CA Technology R&D Limited is a company registered in England and Wales
under company registration number 07251836 with its registered office at
the address set out above. VAT number 697904179.


http://www.ca.com/

P please don't print this e-mail unless you really need to!




________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Daniel Lapp
Sent: 26 January 2011 19:20
To: [login to unmask email]
Subject: Re: [DB2-L] Staying current with maintenance and validation


I agree about DB2 and IBM but, it's the third party products I'm much
more worried about.


On Wed, Jan 26, 2011 at 1:59 PM, Taddei, Cathy
<[login to unmask email]> wrote:


I don't sweat it. If IBM puts out a PTF, I assume it to be
"safe", so I don't spend any time at all wondering whether we have
experienced the problem that it purports to fix. I do RSU maintenance
once or twice a year, including all hipers. I always select the most
current RSU level, because the RSU is by definition already 3 months
old. The most time-consuming part is reading all the hold data and
creating the implementation script. For IVP's I run DSNTEJ1 through 2C;
validation consists of informing applications that new maintenance has
been applied to the system test environment. When it's time to go to
production, I get sign-off from applications that their testing was
successful, then I'm good to go. I spend relatively little time
maintaining DB2, which is good because I also support 3rd party tools,
DASD management, and I'm now learning CICS.

HTH,
Cathy


-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of
Daniel Lapp
Sent: Sunday, January 23, 2011 7:06 AM
To: [login to unmask email]
Subject: [DB2-L] Staying current with maintenance and validation

I'm a DB2 system programmer who would like to better understand
how folks validate maintenance and what their idea of staying current
is. First off IBM puts out monthly PUT tapes and quarterly RSUs,
correct ? Their recommendation is to go to an RSU; but what about HIPER
PTFs ? If you track them how do people decide which ones should go on
and which ones don't ? If a hiper describes a situation that may occur
but has not occurred yet (in your shop) and it describes your
architecture, should an effort be made in a test environment to prove
your vulnerability before just slapping it on ? Being a systems
programmer I download and have new fixes at the ready between
maintenance cycles so if an issue is encountered it's quick to get it
fixed (provided the fix is available and I have it in house). What
about validation ? If the politics dictate you must put a fix on even
though the failing event has never occurred in your shop is it
unreasonable to expect the applications side of the house to recreate
the possible situation as outlined in the description supplied by the
PTF as part of their validation before and after the PTF is applied ?

Speaking of validation, I am always able to run the IVP supplied
by the vendor (but certainly more extensive validation is required) but
what is considered a good validation architecture and process ? Anyone
know where I could find some good information on that ?

Lastly, regarding all the third party products that only supply
quarterly PUT tapes and it can become a full time job for one person
just to keep up. This is especially true where one person is expected
to maintain every third party product in the shop. After going to a PUT
you find yourself with a list of fixes and hipers that is as long as the
list of fixes inn the PUT you just applied . How do folks avoid the
"painting the bridge mentality" where you suddenly find yourself in a
nonstop cycle of applying fixes with no time to anything like process
improvement or performance tuning ?

I realize (because I've been doing this function for longer than
I like to admit) that systems programming has always been a balance best
controlled by good process and procedures (rules). But I would love to
hear what folks have to share about the topic since doing more with less
is more apropos today than when folks first starting using the phrase.



_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *
* If you are going to attend only one conference this year,
this is it! *
** DB2 certification -> no additional charge
** Meet fellow DB2 users and leading DB2 consultants

_____________________________________________________________________

If you need to change settings,
http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv


_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 *
http://IDUG.ORG/NA *

* Your only source for independent, unbiased, and trusted DB2
information. *
** The most DB2 technical sessions of any conference
** Access IBM experts and developers


_____________________________________________________________________

If you need to change settings,
http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv





--
Dan Lapp
"The lapper"



________________________________


Introducing IBM(r) DB2(r) 10 for z/OS
< http://www-01.ibm.com/software/data/db2/zos/db2-10/ >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
are not already an IDUG member, please register here.
< http://www.idug.org/register >


_____________________________________________________________________
* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
** The best DB2 technical sessions in the world
** Independent, not-for-profit, User Run - the IDUG difference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv