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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[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?

Post by 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,

[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: [phone] R: 49602 3-1404
Fax: [phone]



-----Mensagem original-----
De: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] Em nome de ANIL KUMAR
Enviada em: quinta-feira, 7 de dezembro de 2017 02:56
Para: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

AVISO LEGAL <br>...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<br>...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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[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
***@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-***@LISTSERV.UA.EDU] On Behalf Of ANIL KUMAR
Sent: Wednesday, December 06, 2017 11:56 PM
To: IBM-***@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 ***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Edward Gould]

Post by 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.

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[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

Post by 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.

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN


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

[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.

Post by ANIL KUMAR

Post by 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.

Post by ANIL KUMAR
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.

Post by ANIL KUMAR
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.

Post by ANIL KUMAR
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.

Post by ANIL KUMAR
Hence needed some advise on what strategy is being used by different

shops and what is the best practice. Please advise.

Post by ANIL KUMAR
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[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" <***@WSU.EDU>
To: IBM-***@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.

Post by ANIL KUMAR

Post by 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.

Post by ANIL KUMAR
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.

Post by ANIL KUMAR
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.

Post by ANIL KUMAR
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.

Post by ANIL KUMAR
Hence needed some advise on what strategy is being used by different

shops and what is the best practice. Please advise.

Post by ANIL KUMAR
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN


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

[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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David Purdy
Sent: Thursday, December 07, 2017 9:01 AM
To: IBM-***@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

Post by 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.

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[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-***@listserv.ua.edu> on behalf of ANIL KUMAR <***@GMAIL.COM>
Sent: Wednesday, December 6, 2017 11:55 PM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Mark Zelden]

Post by 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 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:***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Tom Marchant]

... 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.

[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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Mark Zelden]

Post by Tom Marchant

... 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:***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[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
***@sce.com


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

Post by Tom Marchant

... 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:***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

[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:***@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/

Post by 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
-----Original Message-----
Sent: Friday, December 08, 2017 3:27 PM
Subject: (External):Re: RSU maintenance strategy - Need expert suggestions

Post by Tom Marchant

... 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
--
Systems Programming expert at http://search390.techtarget.com/ateExperts/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

[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.

Post by Edward Gould
Mark,

Post by 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

Post by Mark Zelden
feature you don't have or for some function you aren't using or planning

to use

Post by Mark Zelden
ahead of the time it has been fully tested via CST and shows up with an

RSU sourceid?

Post by Mark Zelden
What's to gain? To me it just seems more likely you could install a PTF

that will end

Post by Mark Zelden
up PE'd.
Yes, RSU incorporates a "lot of PTFs that are not necessarily critical"

- but that's the

Post by Mark Zelden
point of putting on general preventive maintenance. However, it also

does

Post by Mark Zelden
include critical maintenance as well - PE fixes, HIPERs and security /

integrity.

Post by Mark Zelden
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,

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

[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:***@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/

Post by 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
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/

Post by 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
-----Original Message-----
Sent: Friday, December 08, 2017 3:27 PM
Subject: (External):Re: RSU maintenance strategy - Need expert suggestions

Post by Tom Marchant

... 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
--
Systems Programming expert at http://search390.techtarget.com/ateExperts/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

[John Eells]

Our recommendations (for IBM products) are here:

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

Post by 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

<snip>

[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-***@LISTSERV.UA.EDU] On Behalf Of ANIL KUMAR
Sent: Wednesday, December 06, 2017 11:56 PM
To: IBM-***@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 ***@listserv.ua.edu with the message: INFO IBM-MAIN