MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » June 2014

RE: PTF apply philosophyies



fixed

Jim,

I've done the same for 20+ years.
I'm not totally agreeing with support on this issue, I was also ready to escalate.
Support stated it either a fiber cabling issue, fiber switch configuration issue, etc.
None of the above.
They requested I IPL the system to fix the issue, yea right.
When drive reported in and worked on another LPAR, it was a moment of silence.

Paul


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of franz9000
Sent: Thursday, June 05, 2014 10:31 PM
To: Midrange Systems Technical Discussion
Subject: Re: PTF apply philosophyies

Paul,

Your issue with the shared tape drive - we have a standard of running new ptfs on development for a few weeks before applying to production. We are moving to new hardware where tape drive will be shared via fiber.
I guess that standard no longer works...
Jim

----- Original Message -----
From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, June 05, 2014 10:16 PM
Subject: RE: PTF apply philosophyies


Larry,

I appreciate all the input, helps me build my case.
I agree that IPL with PTF apply needs to be done every 2 to 4 months.
I prefer 2 months, if possible.
On our Production LPAR, all SSD drives, I have IPL with PTF apply under 15
minutes.
Dedicated system save using multiple LTO5 HH fiber drives under 2 hours.
That's 2 hour 15 minute down time once every 2 months, between 23:00 and
2:00 am.
In my book, should be very acceptable, with a high level of system
recovery if needed.

When you and others state "load and run" specifically what do you mean?

On a side related issue, I had a LTO 5 HH fiber drive replaced today. On
production LPAR, following the replacement, the drive would not "report
in" properly under TAPMLB01, only as a standalone device.
On R&D LPAR, drive reported in fine.
R&D LPAR was more current with PTFs.
After 3 hours on with support, DLPAR multiple 577D from LPAR to LPAR, we
got the drive to report in properly by DLPAR the 577Ds to opposite LPAR.

Here's the summary from IBM support.
- It appears that the production box(pencor 05) is experiencing
unpredictable/intermittent issues regarding the handling of grouping tape
devices together under one library, dealing with D'LPAR'd IOP devices, and
so forth. This is most likely a direct result of there being a PTF
mismatch in tape code between Pencor6 and Pencor5 which are both sharing
the same Tape Library. It is a standard recommendation that all systems
using the same tape library that use virtual IOP's have equivalent PTF
levels, otherwise you can experience issues like this.

- We found in our testing that we could move the IOP on system bus 305
over to pencor5 and it would work fine, but moving IOP on bus 286 was not
working correctly. 286 worked fine on Pencor6 though, so we decided to
leave 305 on 5 and 286 on 6 as a temporary workaround until you can apply
the recommended virtual IOP/Fiber Tape PTF's that I sent you.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
DrFranken
Sent: Thursday, June 05, 2014 8:05 AM
To: Midrange Systems Technical Discussion
Subject: Re: PTF apply philosophyies

I do a LOT of PTFs and spoken to many of the fine folks at IBM re PTFs and
the process.

First off it has been stated that MANY PTFs simply require an IPL. The
objects being replaced simply cannot be updated at any other time as they
are always in use or otherwise locked. A claim of 90% of PTFs can be
applied immediately doesn't align with what I see. I suppose it's possible
in fact but with all the pre and co requisite PTFs all it takes is one PTF
in the 'set' to require an IPL and the other PTFs are stuck so effectively
all the PTFs require an IPL.

I have heard several times that using *IMMDLY (Immediate if possible,
Delayed to IPL when mandatory) Is NOT recommended for any PTF Groups
including CUMEs. It's essentially impossible to read every cover letter
and deal with all the special instructions. Failure to follow the special
instructions can mean many things, not the least of which is that many of
the PTFs that APPEAR to be applied are not active until an action is
taken, frequently the action is to IPL (which I find annoying!)

I do concur with other comments that if you are not provided sufficient
time for backups, PTFs, and other maintenance then having an HA system is
near mandatory. Clearly NOT doing PTFs and proper saves is just a system
crash looking for a bad time to occur. If time is so short when you DO get
a window that any problems push you into being considered an outage that
also is 'living on the edge'. Also consider making your load source disk
an SSD, this will 'enhance PTF apply performance.'

Generally I do like load and run Temp and SAVE 22. Run for perhaps 2 or
3 months. Then perm apply all and SAVE 22. Then repeat as necessary.

- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 6/4/2014 11:56 AM, Steinmetz, Paul wrote:

Management would like to minimize the IPL, PTF, and system save
downtimes.
HA/DR Is out of the question.
Currently, I try to IPL Production every 2 months for PTF apply along
with a system save.
The IPL and system save will probably go to 6 months or as needed.
90% of PTFs can be applied immediately without an IPL, however IBM does
not recommend immediate apply for more than a single PTF.
Applying a large amount of PTFs immediately has caused issues in the
past.
Permission has been granted for the PTF immediate apply, but I'm weary
from previous issues.

Any thoughts from the group.

Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx
http://www.pencor.com/

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.







Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact