Re: RSU maintenance strategy - Need expert suggestions

[ANIL KUMAR]

Hi All,

Thanks very much for your timely and quick response. Yes have proposed a
strategy to the customer and will be reviewed by early next year. I will
have some follow-up questions regarding the same and will post to get some
advise. Thanks again.

On Tue, Dec 12, 2017 at 1:32 AM, Edward Gould 
wrote:

> Mark,
>
> > On Dec 9, 2017, at 12:32 PM, Mark Zelden  wrote:
> >
> > And then you just apply everything that turns up in MISSINGFIX for
> > FIXCAT(*) along with the RSU maintenance?
> >
> > Why install a 100% of missing maintenance specific to some hardware or
> hardware
> > feature you don't have or for some function you aren't using or planning
> to use
> > ahead of the time it has been fully tested via CST and shows up with an
> RSU sourceid?
> > What's to gain? To me it just seems more likely you could install a PTF
> that will end
> > up PE'd.
> >
> > Yes, RSU incorporates a "lot of PTFs that are not necessarily critical"
> - but that's the
> > point of putting on general preventive maintenance.   However, it also
> does
> > include critical maintenance as well - PE fixes, HIPERs and security /
> integrity.
> >
> > I guess we'll have to agree to disagree on this one.
> >
> > Regards,
>
> I will go along with you on this one. Once in a while you will find a
> chain so long it makes you ill. A long time ago, I chased a chain that had
> 3500 (thats right) 3500 ptfs waiting to go on because of one fix.  I think
> that is when my hair color started to turn gray. I can see chasing 3 or 4
> PTF’s but 3500 was out off the park for me.
> To get to your other points, I do not lay back and wait, everyday I am
> working I look for the hipers and the security/Integrity fixes on IBMLINK.
> I like to be proactive in this area as one time we had an auditor that
> thought he would get one over on me. He sent an email to the VP and asked
> if we had this specific PTF on as he thought it was important. The VP
> passes it on down the line to me. I looked it up and it didn’t even pertain
> to our system, so I thought I would do him one better and found the PTF in
> question and told him in English that the PTF did NOT involve our system
> but this PTF did. I did a cut and paste into the email of the cover letter
> and the pre’s and Co’s and that PTF had been on the system for 6 months. I
> then said to him in the future please call or email me directly so we
> didn’t tie up management in issues that we could handle quicker and more
> completely via email/phone call as we were there to serve him. That stopped
> the ambush’s. A few weeks later I get an email and didn’t reply to him the
> same day but the next day I replied again that the fix was not for our
> system but this one was and again I told him it had been on for 7 months.
> He tried it once more and I told him the same story except this one had
> been on a year. I smelled something fishy, I dropped by his desk when he
> wasn’t there and asked his team mate what was going on with these requests
> and he told me that VP of Auditing had become friends with another auditor
> in another shop and the *other* auditor was trying for a promotion and that
> he had some MVS sysprog feeding him these PTF numbers.
>
> Ed
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Edward Gould]

Mark,

> On Dec 9, 2017, at 12:32 PM, Mark Zelden  wrote:
> 
> And then you just apply everything that turns up in MISSINGFIX for
> FIXCAT(*) along with the RSU maintenance? 
> 
> Why install a 100% of missing maintenance specific to some hardware or 
> hardware 
> feature you don't have or for some function you aren't using or planning to 
> use
> ahead of the time it has been fully tested via CST and shows up with an RSU 
> sourceid?
> What's to gain? To me it just seems more likely you could install a PTF that 
> will end
> up PE'd.
> 
> Yes, RSU incorporates a "lot of PTFs that are not necessarily critical" - but 
> that's the
> point of putting on general preventive maintenance.   However, it also does
> include critical maintenance as well - PE fixes, HIPERs and security / 
> integrity.
> 
> I guess we'll have to agree to disagree on this one.
> 
> Regards,

I will go along with you on this one. Once in a while you will find a chain so 
long it makes you ill. A long time ago, I chased a chain that had 3500 (thats 
right) 3500 ptfs waiting to go on because of one fix.  I think that is when my 
hair color started to turn gray. I can see chasing 3 or 4 PTF’s but 3500 was 
out off the park for me.
To get to your other points, I do not lay back and wait, everyday I am working 
I look for the hipers and the security/Integrity fixes on IBMLINK. I like to be 
proactive in this area as one time we had an auditor that thought he would get 
one over on me. He sent an email to the VP and asked if we had this specific 
PTF on as he thought it was important. The VP passes it on down the line to me. 
I looked it up and it didn’t even pertain to our system, so I thought I would 
do him one better and found the PTF in question and told him in English that 
the PTF did NOT involve our system but this PTF did. I did a cut and paste into 
the email of the cover letter and the pre’s and Co’s and that PTF had been on 
the system for 6 months. I then said to him in the future please call or email 
me directly so we didn’t tie up management in issues that we could handle 
quicker and more completely via email/phone call as we were there to serve him. 
That stopped the ambush’s. A few weeks later I get an email and didn’t reply to 
him the same day but the next day I replied again that the fix was not for our 
system but this one was and again I told him it had been on for 7 months. He 
tried it once more and I told him the same story except this one had been on a 
year. I smelled something fishy, I dropped by his desk when he wasn’t there and 
asked his team mate what was going on with these requests and he told me that 
VP of Auditing had become friends with another auditor in another shop and the 
*other* auditor was trying for a promotion and that he had some MVS sysprog 
feeding him these PTF numbers.

Ed 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[van der Grijn, Bart (B)]

We install RSU four times a year. It definitely does not require 1 FTE. I would 
estimate it takes us about 16-32 man hours per quarter covering both z/OS and 
DB2. 
Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ANIL KUMAR
Sent: Wednesday, December 06, 2017 11:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU maintenance strategy - Need expert suggestions

This email originated from outside of the organization.


Hi All,

I needed expert suggestions on following the RSU maintenance strategy for
z/OS , associated ISV products , DB2 etc. Could you please let me know

1) How many times in a year do we need to apply the maintenance to z/os ,
ISV products , DB2 etc.
2) How to decide which ones to be applied. (latest RSU)
3) Whether the HIPERs included also be applied , even though we have not
encountered the specific issues in out shop.

So far in the account I was working for , it was not a strict rule to apply
maintenance be it z/OS or DB2 or associated ISV product. Infact I do not
remember any maintenance being applied to DB2 unless it was a major upgrade
for which the pre-req was needed. Even for ISV's if they are running fine,
then no action was taken.

However for a different shop , we have been asked to come up with the best
approach on whats needs to be done. If we keep updating the maintenance
then 1 FTE job will be consumed for the work for a year.

Hence needed some advise on what strategy is being used by different shops
and what is the best practice. Please advise.

If any documents etc are available please point me to them and I shall
read. Sincerely hoping to get some advise. Thanks.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[John Eells]

Our recommendations (for IBM products) are here:

https://www-03.ibm.com/systems/resources/zOS_Preventive_Maintenance_Strategy.pdf


ANIL KUMAR wrote:

Hi All,

I needed expert suggestions on following the RSU maintenance strategy for
z/OS , associated ISV products , DB2 etc. Could you please let me know



--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Mark Zelden]

Skip - I think you contradicted yourself too.  When you were talking about RSU 
you
wrote that it contains "new function that we can live without a little while 
longer".  
Well, if you run a REPORT MISSINGFIX FIXCAT(*) and apply all that maintenance,
you are doing the exact opposite.  You're putting on every single PTF related to
some "function you can live without for a while longer" (because it will end up
on RSU if not PE'd) or for a function / hardware  you won't ever use. 

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/

On Sat, 9 Dec 2017 12:32:11 -0600, Mark Zelden <m...@mzelden.com> wrote:

>And then you just apply everything that turns up in MISSINGFIX for
>FIXCAT(*) along with the RSU maintenance? 
>
>Why install a 100% of missing maintenance specific to some hardware or 
>hardware 
>feature you don't have or for some function you aren't using or planning to use
>ahead of the time it has been fully tested via CST and shows up with an RSU 
>sourceid?
>What's to gain? To me it just seems more likely you could install a PTF that 
>will end
>up PE'd.
>
>Yes, RSU incorporates a "lot of PTFs that are not necessarily critical" - but 
>that's the
>point of putting on general preventive maintenance.   However, it also does
>include critical maintenance as well - PE fixes, HIPERs and security / 
>integrity.
>
>I guess we'll have to agree to disagree on this one.
>
>Regards,
>
>Mark
>--
>Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
>ITIL v3 Foundation Certified
>mailto:m...@mzelden.com
>Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
>Systems Programming expert at http://search390.techtarget.com/ateExperts/
>
>
>On Sat, 9 Dec 2017 03:55:24 +, Jesse 1 Robinson <jesse1.robin...@sce.com> 
>wrote:
>
>>We do have specific FIXCAT runs for scheduled hardware or software upgrades, 
>>but this is the blanket report we run to cover all the bases in the ninth 
>>inning of a general maintenance upgrade. (Pardon the baseball metaphor.)
>>
>>REPORT MISSINGFIX 
>>   FIXCAT(*)  
>>   ZONES(MVST100) 
>>
>>My view is that RSU incorporates a lot of PTFs that are not necessarily 
>>critical. Many range from cosmetic to new function that we can live without a 
>>little while longer. All are good to have at some point but do not 
>>necessarily bear on immediate operability. FIXCAT OTOH is more likely to 
>>focus HIPERs and really important stuff that should be swept in to the mix if 
>>feasible, especially if a -n RSU has been chosen. 
>>
>>Once again, I imagine what I will tell the boss. ;-)
>>
>>.
>>.
>>J.O.Skip Robinson
>>Southern California Edison Company
>>Electric Dragon Team Paddler 
>>SHARE MVS Program Co-Manager
>>323-715-0595 Mobile
>>626-543-6132 Office ⇐=== NEW
>>robin...@sce.com
>>
>>
>>-Original Message-
>>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>>Behalf Of Mark Zelden
>>Sent: Friday, December 08, 2017 3:27 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: (External):Re: RSU maintenance strategy - Need expert suggestions
>>
>>On Fri, 8 Dec 2017 07:35:31 -0600, Tom Marchant <m42tom-ibmm...@yahoo.com> 
>>wrote:
>>
>>>On Thu, 7 Dec 2017 17:04:15 -0600, Mark Zelden wrote:
>>>
>>>>On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson wrote:
>>>>
>>>>>... As others have suggested, pay attention to HIPER and FIXCAT, and 
>>>>>ERRORSYSMOD reports. 
>>>>
>>>>What Skip said!   ...
>>>>
>>>>The part I wanted to stress the Skip wrote (and why I chimed in) was 
>>>>his advise to pull the HOLDDATA and run report errorsysmods when you decide 
>>>>to go forward.
>>>
>>>I agree with Skip and Mark. I would add that it is good to run a MISSINGFIX 
>>>report.
>>>And receive the latest HOLDDATA before every APPLY and ACCEPT.
>>>
>>
>>Of course that won't hurt, but the time to run MISSINGFIX is when you are 
>>implementing new hardware features, new software features, OS upgrades etc.  
>>
>>What FIXCAT categories do you do it on for normal maintenance?  I could see 
>>running it for
>>IBM.TargetSystem-RequiredService.z/OS.*   and   
>>IBM.TargetSystem-RequiredService.z/OSMF.*,
>>but if a PTF was recommended for your cu

Re: RSU maintenance strategy - Need expert suggestions

[Mark Zelden]

And then you just apply everything that turns up in MISSINGFIX for
FIXCAT(*) along with the RSU maintenance? 

Why install a 100% of missing maintenance specific to some hardware or hardware 
feature you don't have or for some function you aren't using or planning to use
ahead of the time it has been fully tested via CST and shows up with an RSU 
sourceid?
What's to gain? To me it just seems more likely you could install a PTF that 
will end
up PE'd.

Yes, RSU incorporates a "lot of PTFs that are not necessarily critical" - but 
that's the
point of putting on general preventive maintenance.   However, it also does
include critical maintenance as well - PE fixes, HIPERs and security / 
integrity.

I guess we'll have to agree to disagree on this one.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/


On Sat, 9 Dec 2017 03:55:24 +, Jesse 1 Robinson <jesse1.robin...@sce.com> 
wrote:

>We do have specific FIXCAT runs for scheduled hardware or software upgrades, 
>but this is the blanket report we run to cover all the bases in the ninth 
>inning of a general maintenance upgrade. (Pardon the baseball metaphor.)
>
>REPORT MISSINGFIX 
>   FIXCAT(*)  
>   ZONES(MVST100) 
>
>My view is that RSU incorporates a lot of PTFs that are not necessarily 
>critical. Many range from cosmetic to new function that we can live without a 
>little while longer. All are good to have at some point but do not necessarily 
>bear on immediate operability. FIXCAT OTOH is more likely to focus HIPERs and 
>really important stuff that should be swept in to the mix if feasible, 
>especially if a -n RSU has been chosen. 
>
>Once again, I imagine what I will tell the boss. ;-)
>
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler 
>SHARE MVS Program Co-Manager
>323-715-0595 Mobile
>626-543-6132 Office ⇐=== NEW
>robin...@sce.com
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Mark Zelden
>Sent: Friday, December 08, 2017 3:27 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: RSU maintenance strategy - Need expert suggestions
>
>On Fri, 8 Dec 2017 07:35:31 -0600, Tom Marchant <m42tom-ibmm...@yahoo.com> 
>wrote:
>
>>On Thu, 7 Dec 2017 17:04:15 -0600, Mark Zelden wrote:
>>
>>>On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson wrote:
>>>
>>>>... As others have suggested, pay attention to HIPER and FIXCAT, and 
>>>>ERRORSYSMOD reports. 
>>>
>>>What Skip said!   ...
>>>
>>>The part I wanted to stress the Skip wrote (and why I chimed in) was 
>>>his advise to pull the HOLDDATA and run report errorsysmods when you decide 
>>>to go forward.
>>
>>I agree with Skip and Mark. I would add that it is good to run a MISSINGFIX 
>>report.
>>And receive the latest HOLDDATA before every APPLY and ACCEPT.
>>
>
>Of course that won't hurt, but the time to run MISSINGFIX is when you are 
>implementing new hardware features, new software features, OS upgrades etc.  
>
>What FIXCAT categories do you do it on for normal maintenance?  I could see 
>running it for
>IBM.TargetSystem-RequiredService.z/OS.*   and   
>IBM.TargetSystem-RequiredService.z/OSMF.*,
>but if a PTF was recommended for your current release it would have an RSU* 
>sourceid also
>so that seems like an extra step that doesn't add value.
>
>Regards,
>
>Mark
>--
>Mark Zelden - Zdlden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
>Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
>http://www.mzelden.com/mvsutil.html
>Systems Programming expert at http://search390.techtarget.com/ateExperts/
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Jesse 1 Robinson]

We do have specific FIXCAT runs for scheduled hardware or software upgrades, 
but this is the blanket report we run to cover all the bases in the ninth 
inning of a general maintenance upgrade. (Pardon the baseball metaphor.)

REPORT MISSINGFIX 
   FIXCAT(*)  
   ZONES(MVST100) 

My view is that RSU incorporates a lot of PTFs that are not necessarily 
critical. Many range from cosmetic to new function that we can live without a 
little while longer. All are good to have at some point but do not necessarily 
bear on immediate operability. FIXCAT OTOH is more likely to focus HIPERs and 
really important stuff that should be swept in to the mix if feasible, 
especially if a -n RSU has been chosen. 

Once again, I imagine what I will tell the boss. ;-)

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Friday, December 08, 2017 3:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RSU maintenance strategy - Need expert suggestions

On Fri, 8 Dec 2017 07:35:31 -0600, Tom Marchant <m42tom-ibmm...@yahoo.com> 
wrote:

>On Thu, 7 Dec 2017 17:04:15 -0600, Mark Zelden wrote:
>
>>On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson wrote:
>>
>>>... As others have suggested, pay attention to HIPER and FIXCAT, and 
>>>ERRORSYSMOD reports. 
>>
>>What Skip said!   ...
>>
>>The part I wanted to stress the Skip wrote (and why I chimed in) was 
>>his advise to pull the HOLDDATA and run report errorsysmods when you decide 
>>to go forward.
>
>I agree with Skip and Mark. I would add that it is good to run a MISSINGFIX 
>report.
>And receive the latest HOLDDATA before every APPLY and ACCEPT.
>

Of course that won't hurt, but the time to run MISSINGFIX is when you are 
implementing new hardware features, new software features, OS upgrades etc.  

What FIXCAT categories do you do it on for normal maintenance?  I could see 
running it for
IBM.TargetSystem-RequiredService.z/OS.*   and   
IBM.TargetSystem-RequiredService.z/OSMF.*,
but if a PTF was recommended for your current release it would have an RSU* 
sourceid also
so that seems like an extra step that doesn't add value.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Mark Zelden]

On Fri, 8 Dec 2017 07:35:31 -0600, Tom Marchant  
wrote:

>On Thu, 7 Dec 2017 17:04:15 -0600, Mark Zelden wrote:
>
>>On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson wrote:
>>
>>>... As others have suggested, pay attention to HIPER and FIXCAT, and 
>>>ERRORSYSMOD reports. 
>>
>>What Skip said!   ...
>>
>>The part I wanted to stress the Skip wrote (and why I chimed in) was his 
>>advise to pull
>>the HOLDDATA and run report errorsysmods when you decide to go forward.
>
>I agree with Skip and Mark. I would add that it is good to run a MISSINGFIX 
>report.
>And receive the latest HOLDDATA before every APPLY and ACCEPT.
>

Of course that won't hurt, but the time to run MISSINGFIX is when you are 
implementing
new hardware features, new software features, OS upgrades etc.  

What FIXCAT categories do you do it on for normal maintenance?  I could see 
running it for
IBM.TargetSystem-RequiredService.z/OS.*   and   
IBM.TargetSystem-RequiredService.z/OSMF.*,
but if a PTF was recommended for your current release it would have an RSU* 
sourceid also
so that seems like an extra step that doesn't add value.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Bobbie Justice]

I usually try to implement maintenance twice a year, but each shop is somewhat 
different, depending upon ipl schedule, 
size of shop, workload, etc.

If you're looking for a doc to justify your decision, there is this: 

https://www-03.ibm.com/systems/resources/zOS_Preventive_Maintenance_Strategy.pdf

Bobbie Jo Justice 
Senior Systems Engineer

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Tom Marchant]

On Thu, 7 Dec 2017 17:04:15 -0600, Mark Zelden wrote:

>On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson wrote:
>
>>... As others have suggested, pay attention to HIPER and FIXCAT, and 
>>ERRORSYSMOD reports. 
>
>What Skip said!   ...
>
>The part I wanted to stress the Skip wrote (and why I chimed in) was his 
>advise to pull
>the HOLDDATA and run report errorsysmods when you decide to go forward.

I agree with Skip and Mark. I would add that it is good to run a MISSINGFIX 
report.
And receive the latest HOLDDATA before every APPLY and ACCEPT.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Mark Zelden]

On Thu, 7 Dec 2017 20:05:15 +, Jesse 1 Robinson  
wrote:

>Each shop needs to craft its own policy on software maintenance. At one time 
>not that long ago, a new z/OS release came out every six months (!). Many 
>shops skipped releases because they didn't have time for each one. Now the 
>release interval is two years, which changes the scheduling dynamic a lot. As 
>others have suggested, pay attention to HIPER and FIXCAT, and ERRORSYSMOD 
>reports. 
>
>I thi k the best practice is to install a recent RSU--maybe the latest, maybe 
>one back--with a few extra important fixes (as above) laid on top. The *day* 
>you decide to go forward, pull HOLDDATA one more time and revise your plan if 
>necessary. Do this as frequently as your enterprise can tolerate. If it takes 
>you months to roll out maintenance to all LPARs, that extends the update 
>interval. However, it also raises the importance of being as current as 
>possible when you leave the starting gate.
>
>Here is my guiding ROT. If something goes seriously south in my system, I 
>imagine having to explain it to my boss.  If it turns out that the vendor 
>issued some kind of alert for this issue...
>
>1. I took the recommended action, which turneo out to cause yet a worse 
>problem.   
>2. I decided that we would not be impacted, so I chose to ignore the alert.
> 
>I would not want to have to defend #2. 
>
>.

What Skip said!   Hopefully at least quarterly RSU.   If not that, twice a 
year.   I know some
shops have LPARs that can only be IPLed once a year.  Obviously they are not 
getting quarterly
RSU maintenance rolled out the easy way (via IPL).

The part I wanted to stress the Skip wrote (and why I chimed in) was his advise 
to pull
the HOLDDATA and run report errorsysmods when you decide to go forward.  For me
it isn't "the day of", but it will be on Friday of the weekend of the scheduled 
IPLs. Since
it takes at least a couple of months to roll out to 30 LPARs, I run it again 
before the
next set of IPLs (different sysplexes / environments can run into different 
problems).

My client did get burned big time once with an LE PTF to support Enterprise 
COBOL 4 (IIRC) 
that broke COBOL behavior with Enterprise COBOL 3.  I think it went PE on the 
Thursday
or Friday before the IPLs and we didn't know.  It caused days and weeks of 
re-runs
of some applications because the problem with the data wasn't found immediately.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Seymour J Metz]

As others have said, there is no one size fits all either for rollout strategy 
or for frequency. You need to analyze the history, policies and requirements of 
your shop. The one thing that I would urge is frequent downloading of HOLDDATA.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
ANIL KUMAR <db2zsysp...@gmail.com>
Sent: Wednesday, December 6, 2017 11:55 PM
To: IBM-MAIN@listserv.ua.edu
Subject: RSU maintenance strategy - Need expert suggestions

Hi All,

I needed expert suggestions on following the RSU maintenance strategy for
z/OS , associated ISV products , DB2 etc. Could you please let me know

1) How many times in a year do we need to apply the maintenance to z/os ,
ISV products , DB2 etc.
2) How to decide which ones to be applied. (latest RSU)
3) Whether the HIPERs included also be applied , even though we have not
encountered the specific issues in out shop.

So far in the account I was working for , it was not a strict rule to apply
maintenance be it z/OS or DB2 or associated ISV product. Infact I do not
remember any maintenance being applied to DB2 unless it was a major upgrade
for which the pre-req was needed. Even for ISV's if they are running fine,
then no action was taken.

However for a different shop , we have been asked to come up with the best
approach on whats needs to be done. If we keep updating the maintenance
then 1 FTE job will be consumed for the work for a year.

Hence needed some advise on what strategy is being used by different shops
and what is the best practice. Please advise.

If any documents etc are available please point me to them and I shall
read. Sincerely hoping to get some advise. Thanks.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Carmen Vitullo]

My strategy was to weekly, via an automated process receive EHOLDATA, and 
monthly apply RSU maint, but only move the maint to prod twice a year. 
exceptions are to prepare for hardware upgrades, apply HIPERs, or PTF to fix an 
issue, and to apply toleration maint for z/OS upgrades. 
my 2.2 system was ordered at an RSU1701 level, I'm just now preparing to apply 
1709 to production. 
my predecessor and his boss only wanted to apply MAINT in preparation for an 
upgrade, so once a year, I finally talked him into semi annually 
makes my job easier 


Carmen Vitullo 

- Original Message -

From: "Dave Gibney" <gib...@wsu.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, December 7, 2017 1:38:45 PM 
Subject: Re: RSU maintenance strategy - Need expert suggestions 

I do it on an irregular basis, usually in preparations for a z/OS upgrade, or 
because it seems like it's been too long. And yep, Sandbox, Sandbox, 
Development, Production. In sequence and with time at each stage. 

> > 
> 
> On Dec 7, 2017, at 9:37 AM, Allan Staller <allan.stal...@hcl.com> wrote: 
> > 
> > Hi All, 
> > 
> > I needed expert suggestions on following the RSU maintenance strategy 
> > for z/OS , associated ISV products , DB2 etc. Could you please let me 
> > know 
> > 
> > 1) How many times in a year do we need to apply the maintenance to z/os , 
> ISV products , DB2 etc. 
> > 2) How to decide which ones to be applied. (latest RSU) 
> > 3) Whether the HIPERs included also be applied , even though we have not 
> encountered the specific issues in out shop. 
> > 
> > So far in the account I was working for , it was not a strict rule to apply 
> maintenance be it z/OS or DB2 or associated ISV product. Infact I do not 
> remember any maintenance being applied to DB2 unless it was a major 
> upgrade for which the pre-req was needed. Even for ISV's if they are running 
> fine, then no action was taken. 
> > 
> > However for a different shop , we have been asked to come up with the 
> best approach on whats needs to be done. If we keep updating the 
> maintenance then 1 FTE job will be consumed for the work for a year. 
> > 
> > Hence needed some advise on what strategy is being used by different 
> shops and what is the best practice. Please advise. 
> > 
> > If any documents etc are available please point me to them and I shall 
> > read. 
> Sincerely hoping to get some advise. Thanks. 


-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Jesse 1 Robinson]

Each shop needs to craft its own policy on software maintenance. At one time 
not that long ago, a new z/OS release came out every six months (!). Many shops 
skipped releases because they didn't have time for each one. Now the release 
interval is two years, which changes the scheduling dynamic a lot. As others 
have suggested, pay attention to HIPER and FIXCAT, and ERRORSYSMOD reports. 

I think the best practice is to install a recent RSU--maybe the latest, maybe 
one back--with a few extra important fixes (as above) laid on top. The *day* 
you decide to go forward, pull HOLDDATA one more time and revise your plan if 
necessary. Do this as frequently as your enterprise can tolerate. If it takes 
you months to roll out maintenance to all LPARs, that extends the update 
interval. However, it also raises the importance of being as current as 
possible when you leave the starting gate.

Here is my guiding ROT. If something goes seriously south in my system, I 
imagine having to explain it to my boss.  If it turns out that the vendor 
issued some kind of alert for this issue...

1. I took the recommended action, which turned out to cause yet a worse 
problem.   
2. I decided that we would not be impacted, so I chose to ignore the alert.
 
I would not want to have to defend #2. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Purdy
Sent: Thursday, December 07, 2017 9:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RSU maintenance strategy - Need expert suggestions

Also consider maintenance timing and levels for a z/OS upgrade.   We had a 
maintenance level gap between the running and new z/OS, and an IDCAMS return 
code changed in the  maintenance gap.  It could have been worse.  I modified 
the maintenance strategy to update the old release at a higher or equal level 
than the new release.   Lower risk/exposure, but not completely eliminated.

We're doing an RSU + HIPER + assorted FIXCAT per year and just before a new 
z/OS, hardware, or major program product. I'm reviewing an automated weekly 
holddata download and reporting on applied PTFs now in PE status.  Just don't 
have the manpower to do it more frequently.  Sign up for red alerts as well.


Possibly excessive paranoia.

David

On Thursday, December 7, 2017 Edward Gould <edgould1...@comcast.net> wrote:
> 

On Dec 7, 2017, at 9:37 AM, Allan Staller <allan.stal...@hcl.com> wrote:
> 
> Hi All,
> 
> I needed expert suggestions on following the RSU maintenance strategy 
> for z/OS , associated ISV products , DB2 etc. Could you please let me 
> know
> 
> 1) How many times in a year do we need to apply the maintenance to z/os , ISV 
> products , DB2 etc.
> 2) How to decide which ones to be applied. (latest RSU)
> 3) Whether the HIPERs included also be applied , even though we have not 
> encountered the specific issues in out shop.
> 
> So far in the account I was working for , it was not a strict rule to apply 
> maintenance be it z/OS or DB2 or associated ISV product. Infact I do not 
> remember any maintenance being applied to DB2 unless it was a major upgrade 
> for which the pre-req was needed. Even for ISV's if they are running fine, 
> then no action was taken.
> 
> However for a different shop , we have been asked to come up with the best 
> approach on whats needs to be done. If we keep updating the maintenance then 
> 1 FTE job will be consumed for the work for a year.
> 
> Hence needed some advise on what strategy is being used by different shops 
> and what is the best practice. Please advise.
> 
> If any documents etc are available please point me to them and I shall read. 
> Sincerely hoping to get some advise. Thanks.

Allan,
As other have said each shop is different. The idea of putting RSU maintenance 
in test for 4 weeks, then pre production, then production and letting them cook 
as I call it, is for the installation I work is sufficient. In previous 
environments it was not practical as we didn’t have the hardware to have the 
luxury of doing the cooking process and we usually came in on Sundays at 3AM 
and did our testing ourselves. *IF* you got the resources by all means do it as 
others suggested. 
The only caveat I will throw in is to every day look at any hipers and *know* 
your system to see if they pertain to you, also look at logrec every morning to 
see what software hits you took the night before and see if there are many 
duplicate hits, if yes get the fixing PTF on in a reasonable hurry (i.e. don’t 
schedule an IPL), KNOW your system and once you get the feel you will be able 
to better guess how urgent a PTF needs to go on and how fast. Any HIPERS just 
order an

Re: RSU maintenance strategy - Need expert suggestions

[Gibney, Dave]

I do it on an irregular basis, usually in preparations for a z/OS upgrade, or 
because it seems like it's been too long. And yep, Sandbox, Sandbox, 
Development, Production. In sequence and with time at each stage.

> >
> 
> On Dec 7, 2017, at 9:37 AM, Allan Staller  wrote:
> >
> > Hi All,
> >
> > I needed expert suggestions on following the RSU maintenance strategy
> > for z/OS , associated ISV products , DB2 etc. Could you please let me
> > know
> >
> > 1) How many times in a year do we need to apply the maintenance to z/os ,
> ISV products , DB2 etc.
> > 2) How to decide which ones to be applied. (latest RSU)
> > 3) Whether the HIPERs included also be applied , even though we have not
> encountered the specific issues in out shop.
> >
> > So far in the account I was working for , it was not a strict rule to apply
> maintenance be it z/OS or DB2 or associated ISV product. Infact I do not
> remember any maintenance being applied to DB2 unless it was a major
> upgrade for which the pre-req was needed. Even for ISV's if they are running
> fine, then no action was taken.
> >
> > However for a different shop , we have been asked to come up with the
> best approach on whats needs to be done. If we keep updating the
> maintenance then 1 FTE job will be consumed for the work for a year.
> >
> > Hence needed some advise on what strategy is being used by different
> shops and what is the best practice. Please advise.
> >
> > If any documents etc are available please point me to them and I shall read.
> Sincerely hoping to get some advise. Thanks.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[David Purdy]

Also consider maintenance timing and levels for a z/OS upgrade.   We had a 
maintenance level gap between the running and new z/OS, and an IDCAMS return 
code changed in the  maintenance gap.  It could have been worse.  I modified 
the maintenance strategy to update the old release at a higher or equal level 
than the new release.   Lower risk/exposure, but not completely eliminated.

We're doing an RSU + HIPER + assorted FIXCAT per year and just before a new 
z/OS, hardware, or major program product. I'm reviewing an automated weekly 
holddata download and reporting on applied PTFs now in PE status.  Just don't 
have the manpower to do it more frequently.  Sign up for red alerts as well.


Possibly excessive paranoia.

David

On Thursday, December 7, 2017 Edward Gould  wrote:
> 

On Dec 7, 2017, at 9:37 AM, Allan Staller  wrote:
> 
> Hi All,
> 
> I needed expert suggestions on following the RSU maintenance strategy for 
> z/OS , associated ISV products , DB2 etc. Could you please let me know
> 
> 1) How many times in a year do we need to apply the maintenance to z/os , ISV 
> products , DB2 etc.
> 2) How to decide which ones to be applied. (latest RSU)
> 3) Whether the HIPERs included also be applied , even though we have not 
> encountered the specific issues in out shop.
> 
> So far in the account I was working for , it was not a strict rule to apply 
> maintenance be it z/OS or DB2 or associated ISV product. Infact I do not 
> remember any maintenance being applied to DB2 unless it was a major upgrade 
> for which the pre-req was needed. Even for ISV's if they are running fine, 
> then no action was taken.
> 
> However for a different shop , we have been asked to come up with the best 
> approach on whats needs to be done. If we keep updating the maintenance then 
> 1 FTE job will be consumed for the work for a year.
> 
> Hence needed some advise on what strategy is being used by different shops 
> and what is the best practice. Please advise.
> 
> If any documents etc are available please point me to them and I shall read. 
> Sincerely hoping to get some advise. Thanks.

Allan,
As other have said each shop is different. The idea of putting RSU maintenance 
in test for 4 weeks, then pre production, then production and letting them cook 
as I call it, is for the installation I work is sufficient. In previous 
environments it was not practical as we didn’t have the hardware to have the 
luxury of doing the cooking process and we usually came in on Sundays at 3AM 
and did our testing ourselves. *IF* you got the resources by all means do it as 
others suggested. 
The only caveat I will throw in is to every day look at any hipers and *know* 
your system to see if they pertain to you, also look at logrec every morning to 
see what software hits you took the night before and see if there are many 
duplicate hits, if yes get the fixing PTF on in a reasonable hurry (i.e. don’t 
schedule an IPL), KNOW your system and once you get the feel you will be able 
to better guess how urgent a PTF needs to go on and how fast. Any HIPERS just 
order and receive them so if you need to put them on its easy. I put 
maintenance on that and always tested it out, it was my own system. Before it 
affected anyone I wanted to know. Now, there are some components that lets say 
don’t always send out reliable fixes, those I keep careful track of and handle 
them gingerly as testing tends not to catch these PTFs , I will not say which 
components as they have changed from time to time, but you will know after you 
baby sit the systems for a couple of years.

Ed


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Edward Gould]

> On Dec 7, 2017, at 9:37 AM, Allan Staller  wrote:
> 
> Hi All,
> 
> I needed expert suggestions on following the RSU maintenance strategy for 
> z/OS , associated ISV products , DB2 etc. Could you please let me know
> 
> 1) How many times in a year do we need to apply the maintenance to z/os , ISV 
> products , DB2 etc.
> 2) How to decide which ones to be applied. (latest RSU)
> 3) Whether the HIPERs included also be applied , even though we have not 
> encountered the specific issues in out shop.
> 
> So far in the account I was working for , it was not a strict rule to apply 
> maintenance be it z/OS or DB2 or associated ISV product. Infact I do not 
> remember any maintenance being applied to DB2 unless it was a major upgrade 
> for which the pre-req was needed. Even for ISV's if they are running fine, 
> then no action was taken.
> 
> However for a different shop , we have been asked to come up with the best 
> approach on whats needs to be done. If we keep updating the maintenance then 
> 1 FTE job will be consumed for the work for a year.
> 
> Hence needed some advise on what strategy is being used by different shops 
> and what is the best practice. Please advise.
> 
> If any documents etc are available please point me to them and I shall read. 
> Sincerely hoping to get some advise. Thanks.

Allan,
As other have said each shop is different. The idea of putting RSU maintenance 
in test for 4 weeks, then pre production, then production and letting them cook 
as I call it, is for the installation I work is sufficient. In previous 
environments it was not practical as we didn’t have the hardware to have the 
luxury of doing the cooking process and we usually came in on Sundays at 3AM 
and did our testing ourselves. *IF* you got the resources by all means do it as 
others suggested. 
The only caveat I will throw in is to every day look at any hipers and *know* 
your system to see if they pertain to you, also look at logrec every morning to 
see what software hits you took the night before and see if there are many 
duplicate hits, if yes get the fixing PTF on in a reasonable hurry (i.e. don’t 
schedule an IPL), KNOW your system and once you get the feel you will be able 
to better guess how urgent a PTF needs to go on and how fast. Any HIPERS just 
order and receive them so if you need to put them on its easy. I put 
maintenance on that and always tested it out, it was my own system. Before it 
affected anyone I wanted to know. Now, there are some components that lets say 
don’t always send out reliable fixes, those I keep careful track of and handle 
them gingerly as testing tends not to catch these PTFs , I  will not say which 
components as they have changed from time to time, but you will know after you 
baby sit the systems for a couple of years.

Ed


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Allan Staller]

YMMV.  The answer is whatever works for your shop. There are as many choices as 
shops.

I generally apply PUT (not RSU) maintenance twice annually to (current -2) for 
the major subsystems. The choice between PUT and RSU is up to your installation.
IVS maintenance is applied "as needed" to support the above activities.

Given IBMs recent conversion to 2 year release cycles, I have given some 
thought to moving to once annually for maintenance. No decision has yet been 
reached.

I.E. if PUT1712 (or RSU1712) is current, I will apply bulk maintenance through 
PUT1710/RSU1710

Many moons ago, when PUTs (Program Update Tape)  were shipped regularly from 
IBM (and the documentation was available), it was noted that virtually all PE's 
generated by a particular PUT tape were reported within 60 days. Thus, at N-2 
by appropriate exclusion of PTFS, you could have a virtually trouble free 
installation for that particular tape.

I have seen nothing to indicate the underlying ecosystem has changed and 
continue to use current-2.

HTH,



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ANIL KUMAR
Sent: Wednesday, December 6, 2017 10:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU maintenance strategy - Need expert suggestions

Hi All,

I needed expert suggestions on following the RSU maintenance strategy for z/OS 
, associated ISV products , DB2 etc. Could you please let me know

1) How many times in a year do we need to apply the maintenance to z/os , ISV 
products , DB2 etc.
2) How to decide which ones to be applied. (latest RSU)
3) Whether the HIPERs included also be applied , even though we have not 
encountered the specific issues in out shop.

So far in the account I was working for , it was not a strict rule to apply 
maintenance be it z/OS or DB2 or associated ISV product. Infact I do not 
remember any maintenance being applied to DB2 unless it was a major upgrade for 
which the pre-req was needed. Even for ISV's if they are running fine, then no 
action was taken.

However for a different shop , we have been asked to come up with the best 
approach on whats needs to be done. If we keep updating the maintenance then 1 
FTE job will be consumed for the work for a year.

Hence needed some advise on what strategy is being used by different shops and 
what is the best practice. Please advise.

If any documents etc are available please point me to them and I shall read. 
Sincerely hoping to get some advise. Thanks.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER:: 

 The contents of this e-mail and any attachment(s) are confidential and 
intended for the named recipient(s) only. E-mail transmission is not guaranteed 
to be secure or error-free as information could be intercepted, corrupted, 
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents (with or without referred errors) 
shall therefore not attach any liability on the originator or HCL or its 
affiliates. Views or opinions, if any, presented in this email are solely those 
of the author and may not necessarily reflect the views or opinions of HCL or 
its affiliates. Any form of reproduction, dissemination, copying, disclosure, 
modification, distribution and / or publication of this message without the 
prior written consent of authorized representative of HCL is strictly 
prohibited. If you have received this email in error please delete it and 
notify the sender immediately. Before opening any email and/or attachments, 
please check them for viruses and other defects. 

::DISCLAIMER:: 

 The contents of this e-mail and any attachment(s) are confidential and 
intended for the named recipient(s) only. E-mail transmission is not guaranteed 
to be secure or error-free as information could be intercepted, corrupted, 
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents (with or without referred errors) 
shall therefore not attach any liability on the originator or HCL or its 
affiliates. Views or opinions, if any, presented in this email are solely those 
of the author and may not necessarily reflect the views or opinions of HCL or 
its affiliates. Any form of reproduction, dissemination, copying, disclosure, 
modification, distribution and / or publication of th

Re: RSU maintenance strategy - Need expert suggestions

[Jousma, David]

We do maintenance twice per year.   The process to migrate from TECH->DEV->PROD 
takes us approx. 8-12 weeks allowing time for the maintenance to age in TECH 
for at least a month while testing, then moving to DEV for at least a month 
before moving to PROD.  PROD is done over a period of 4 weeks.

So, when we start maintenance process, we usually select maintenance a little 
bit greener than IBM suggests, knowing that it will age before going to prod, 
so I usually select current PUT-1, and current RSU to apply+select FIXCAT 
groups, followed by monitoring ERRORSYSMOD report, and applying HIPER, XSYSTEM, 
SECINT iteratively, until we are a couple weeks from going to PROD at which 
time things get locked down.  I also tend to go look on ShopZ to see if any of 
the ancillary IBM products have upgrades, and order/install/maintenance those, 
which makes the next z/OS upgrade much easier, as it usually ends up being just 
the OS itself getting the upgrade, and not all the APP DEV tools, etc.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ANIL KUMAR
Sent: Wednesday, December 06, 2017 11:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU maintenance strategy - Need expert suggestions

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Hi All,

I needed expert suggestions on following the RSU maintenance strategy for z/OS 
, associated ISV products , DB2 etc. Could you please let me know

1) How many times in a year do we need to apply the maintenance to z/os , ISV 
products , DB2 etc.
2) How to decide which ones to be applied. (latest RSU)
3) Whether the HIPERs included also be applied , even though we have not 
encountered the specific issues in out shop.

So far in the account I was working for , it was not a strict rule to apply 
maintenance be it z/OS or DB2 or associated ISV product. Infact I do not 
remember any maintenance being applied to DB2 unless it was a major upgrade for 
which the pre-req was needed. Even for ISV's if they are running fine, then no 
action was taken.

However for a different shop , we have been asked to come up with the best 
approach on whats needs to be done. If we keep updating the maintenance then 1 
FTE job will be consumed for the work for a year.

Hence needed some advise on what strategy is being used by different shops and 
what is the best practice. Please advise.

If any documents etc are available please point me to them and I shall read. 
Sincerely hoping to get some advise. Thanks.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

RES: RSU maintenance strategy - Need expert suggestions

[ITURIEL DO NASCIMENTO NETO]

Anil,

It depends on the size of your environment.
If you have few lpars then it is possible the enhance the frequency of applying 
Maintenance.
In our case it's almost impossible apply Maintenance more than twice a year, so 
we do apply RSUxx12 and RSUxx06
and critical PTFs, when it's the case.

For ISVs we try to do the same.

Atenciosamente / Regards / Saludos

BANCO BRADESCO S.A.
4250 / DITI Engenharia de Software
Sistemas Operacionais Mainframes
Ituriel do Nascimento Neto
Tel: +55 11 3684-9602 R: 49602 3-1404
Fax: +55 11 3684-4427



-Mensagem original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de 
ANIL KUMAR
Enviada em: quinta-feira, 7 de dezembro de 2017 02:56
Para: IBM-MAIN@LISTSERV.UA.EDU
Assunto: RSU maintenance strategy - Need expert suggestions

Hi All,

I needed expert suggestions on following the RSU maintenance strategy for z/OS 
, associated ISV products , DB2 etc. Could you please let me know

1) How many times in a year do we need to apply the maintenance to z/os , ISV 
products , DB2 etc.
2) How to decide which ones to be applied. (latest RSU)
3) Whether the HIPERs included also be applied , even though we have not 
encountered the specific issues in out shop.

So far in the account I was working for , it was not a strict rule to apply 
maintenance be it z/OS or DB2 or associated ISV product. Infact I do not 
remember any maintenance being applied to DB2 unless it was a major upgrade for 
which the pre-req was needed. Even for ISV's if they are running fine, then no 
action was taken.

However for a different shop , we have been asked to come up with the best 
approach on whats needs to be done. If we keep updating the maintenance then 1 
FTE job will be consumed for the work for a year.

Hence needed some advise on what strategy is being used by different shops and 
what is the best practice. Please advise.

If any documents etc are available please point me to them and I shall read. 
Sincerely hoping to get some advise. Thanks.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AVISO LEGAL ...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) 
a quem é dirigida, podendo conter informação confidencial e/ou legalmente 
privilegiada. Se você não for destinatário desta mensagem, desde já fica 
notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de 
qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. 
Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este 
E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de 
dados, registros ou sistema de controle. Fica desprovida de eficácia e validade 
a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha 
poderes de representação. 
LEGAL ADVICE...This message is exclusively destined for the people to whom 
it is directed, and it can bear private and/or legally exceptional information. 
If you are not addressee of this message, since now you are advised to not 
release, copy, distribute, check or, otherwise, use the information contained 
in this message, because it is illegal. If you received this message by 
mistake, we ask you to return this email, making possible, as soon as possible, 
the elimination of its contents of your database, registrations or controls 
system. The message that bears any mandatory links, issued by someone who has 
no representation powers, shall be null or void.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RSU maintenance strategy - Need expert suggestions

[Mike Schwab]

My shop did it once a quarter.  Can you take the time to review each
Hyper / RSU for PTFs that fix a problem your site is having and apply
as soon as ready, or wait if you didn't find anything up to xx months?

On Wed, Dec 6, 2017 at 10:55 PM, ANIL KUMAR  wrote:
> Hi All,
>
> I needed expert suggestions on following the RSU maintenance strategy for
> z/OS , associated ISV products , DB2 etc. Could you please let me know
>
> 1) How many times in a year do we need to apply the maintenance to z/os ,
> ISV products , DB2 etc.
> 2) How to decide which ones to be applied. (latest RSU)
> 3) Whether the HIPERs included also be applied , even though we have not
> encountered the specific issues in out shop.
>
> So far in the account I was working for , it was not a strict rule to apply
> maintenance be it z/OS or DB2 or associated ISV product. Infact I do not
> remember any maintenance being applied to DB2 unless it was a major upgrade
> for which the pre-req was needed. Even for ISV's if they are running fine,
> then no action was taken.
>
> However for a different shop , we have been asked to come up with the best
> approach on whats needs to be done. If we keep updating the maintenance
> then 1 FTE job will be consumed for the work for a year.
>
> Hence needed some advise on what strategy is being used by different shops
> and what is the best practice. Please advise.
>
> If any documents etc are available please point me to them and I shall
> read. Sincerely hoping to get some advise. Thanks.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

RSU maintenance strategy - Need expert suggestions

[ANIL KUMAR]

Hi All,

I needed expert suggestions on following the RSU maintenance strategy for
z/OS , associated ISV products , DB2 etc. Could you please let me know

1) How many times in a year do we need to apply the maintenance to z/os ,
ISV products , DB2 etc.
2) How to decide which ones to be applied. (latest RSU)
3) Whether the HIPERs included also be applied , even though we have not
encountered the specific issues in out shop.

So far in the account I was working for , it was not a strict rule to apply
maintenance be it z/OS or DB2 or associated ISV product. Infact I do not
remember any maintenance being applied to DB2 unless it was a major upgrade
for which the pre-req was needed. Even for ISV's if they are running fine,
then no action was taken.

However for a different shop , we have been asked to come up with the best
approach on whats needs to be done. If we keep updating the maintenance
then 1 FTE job will be consumed for the work for a year.

Hence needed some advise on what strategy is being used by different shops
and what is the best practice. Please advise.

If any documents etc are available please point me to them and I shall
read. Sincerely hoping to get some advise. Thanks.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN