On Mon, 23 Apr 2007 08:40:54 -0700, Craig Bakken <[EMAIL PROTECTED]> wrote:

>This may be somewhat of a religious question, Is it better to be right up
to the current level of available maintenance or is it better to hang back a
few months worth so as not to apply a PTF that goes PE?  Is Z/OS 1.8 so
buggy that current maintenance is required?
>

It is somewhat religious and you're going to get lots of different answers. 
All of which have probably been covered in the archives.  IBM's recommendation
is to be at current RSU... since that already goes though CST prior to being 
marked for RSU.   But since everyone pretty much does that
these days, to me it is really no different than being on current PUT was in 
"the old days" and I have seen problems get rolled out too often (if everyone
waits to for the RSU, we are all testing it together).   So these days we 
are doing quarterly RSU minus 1 quarter + HIPERs.   HIPERs get looked
at on a daily basis via ASAP notification and we usually download 
current holddata and run SMP/E report errorsysmods weekly or more than
that just prior to rolling out a new sysres.

However, when rolling out a new OS to the first LPAR (other than sysprog
sandbox / test) I always start with current RSU + hipers to try and avoid
as many problems as possible.  New OS rollouts go though extra testing
and sign offs, so I feel more comfortable being "bleeding edge" on 
maintenance.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group:  G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to