Re: Cume/Groups -- MIDRANGE-L

good comment on the IPLs setting back the query engine, haven't thought
about that one for a long time since some old boxes with HUGE databases at
a previous job... way less of an issue here, which is nice!

BRMS is great and the recovery report is very nice to work from... we
periodically test restoring from the BRMS executed/defined version of our
saves (full, weekly, daily to get to the most up to date pieces, etc..

Even to the point of getting the right BRMS software encryption keys back
in place on the system - it's great practice and nice knowing it works in
the real world. I've run into business partner technicians who operate
backup solution services for multiple customers who didn't fully understand
the SW encryption keys used with BRMS - to the point of where they never
changed the default save/restore key to an actual in house defined key... I
remember teaching him about that angle and seeing the knowledge sink in
that he had a bunch of customers he'd need to work with to define actual
save/restore keys that weren't set to the default... hehe).

Even when we actually migrate a box by using the tried and true Save 21
type version of the migration, we always do a few BRMS versions of the same
thing as a good opportunity for practice while we've got a new unused box
as an opportunity.

Thanks for the comments everyone... .i'm going to do apply the 999 LPP PTFs
*perm after a save and before running the cume and groups, and run the cume
and all groups in one GO PTF option 8 operation this time.

From: "Rob Berendt" <robertowenberendt@xxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxxxxxxxx>
Date: 03/30/2023 10:45 AM
Subject: Re: Cume/Groups
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx>

I already said we apply quarterly so I'll address the other stuff.
Like you we do the H/A software role swap, full system save, PTF's and IPL.
Any more often would be because your policy dictates PTF's get applied
faster. Or you want a more frequent full system save.
IPLing too often confuses the query engine and may hurt performance.
CISC boxes were the last that we IPLed more than quarterly and that was
because temporary addresses would fill. I've never come close on a RISC
box.
BRMS knows we have H/A software and the recovery report actually tells us
which tapes from both systems we would need. For example our last
quarterly full system save of our DEV lpar was 3/11. We get nightly saves
of it's H/A partition. They're in different cities so they have different
VTL's. But the volumes are replicated to each other.
Volume Media Creation Storage System
Serial Status Class Date Location ID
G70086 *ACT ULTRIUM7 3/29/23 USSG7VTL GDISYS2
G70204 *ACT ULTRIUM7 3/29/23 USSG7VTL GDISYS2
I70339 *ACT ULTRIUM7 3/11/23 USSI7VTL GDISYS1
I70340 *ACT ULTRIUM7 3/11/23 USSI7VTL GDISYS1
I70341 *ACT ULTRIUM7 3/11/23 USSI7VTL GDISYS1
I70342 *ACT ULTRIUM7 3/11/23 USSI7VTL GDISYS1
This list is provided by BRMS and requires no tracking by me.
The actual recovery report steps me through it.
I have several LPARs and have done a few system migrations using BRMS
reports this month alone.
We also use parallel saves over four drives in the VTL at once and that's
why four tapes on 3/11. No problem for the restore to handle this.
Your backup is worthless if you aren't testing it.

On Wed, Mar 29, 2023 at 8:05 AM <ChadB@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

we do a Mimix role swap religiously and run on the dev/ha box every month
for a full day and use that opportunity for a Save 21 and IPL

but that's more about keeping our HA options tested and rehearsed and
getting the full save is very nice... the IPL isn't really needed much
anymore in my experience in recent years

From: "Gerald Magnuson" <gmagqcy.midrange@xxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxxxxxxxx>
Date: 03/28/2023 03:53 PM
Subject: Re: Cume/Groups
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx>

How often do people IPL these days?
we do it monthly, and I am not sure if I am too eager to apply PTF's or
hesitant....

On Tue, Mar 28, 2023 at 2:48 PM Rob Berendt <robertowenberendt@xxxxxxxxx>
wrote:

At some time each ptf should be permanently applied.
Some might only do it immediately before a release upgrade.
We do it once a quarter. We set all to apply perm at the next IPL, and
prior to that IPL, we order the next batch of cume, groups and

recommended

PTFs.

For the argumentative, look at it this way. You have PTF MF12345 temp
applied and all is well and good. Next group comes out and it's time

for

your maintenance so you order and apply it. MF23456 was part of that

and

it supercedes MF12345 so it perm applies that. MF23456 is only temp.

Now

you run into some strange new combination which causes an error. You

tie

it to MF23456 so you remove it. You still have the error. You then
discover it was originally caused by MF12345. It just hadn't occurred
because you didn't hit that unique situation. You cannot remove that

you call IBM. You have a few choices here.
1 - slip the lic and load/apply lower PTFs (if you have them laying

around)

2 - call ibm and report the problem and they say "yeah, we know about
that. Get MF23468."
3 - Restore from backup
...
Summary: Sooner or later the PTF is going to get perm applied anyway.

If

it doesn't happen in 3 months it would be a pretty rare situation that

you

would notice it later.

On Tue, Mar 28, 2023 at 3:28 PM Bryan Dietz <bdietz400@xxxxxxxxx>

wrote:

My "worry" about perm applying non-57xx999 PTFs is defective PTFs, or
PTFs that change behavior.

If you need to remove it, the latter, you are hosed. For defective

PTfs

you need to wait for fixing PTF.

Certainly you would not load and immediately perm apply PTFs, so your
risk might be low(er). But i think it is still there.

Bryan

Larry "DrFranken" Bolhuis wrote on 3/28/2023 2:16 PM:

CLEARLY it is the 999 PTFs that would cause issues with the link

loader

or cause issues that can clobber the system, and thus require a

reload.

So restricting the perm apply to 999 PTFs (LIC) only is not a bad

idea.

Not sure why IBM would recommend NOT to perm apply the other PTFs -

OS

and LPPs but we can assume they know better!

- DrF

On 3/28/2023 3:05 PM, Michael Mayer wrote:

I have a recent IBM Case about this and they say and I quote them:
“When applying CUME’s / Group’s, the only PTF’s that we recommend
should be applied
*PERM is the 5770999 LIC MF’s.

Respectfully,
Michael Mayer
IBM i on Power System Admin
ERMCO-ECI
2225 Industrial Rd
Dyersburg, Tennessee 38024
Office and OnCall: 731.676.4318
Cell: 518.641.8906
Email: michael.mayer@xxxxxxxxxxxxx<

mailto:michael.mayer@xxxxxxxxxxxxx

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ermco-2Deci.com&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FaHmtsrlv1gHUX-sfadM4FPhmi77DyRJDjh8NvpP6sE&m=cuCSoRBHQioxIt7yf7vNse7HItH5o9P7oBe6JpsFsX8&s=ov8gvhhCvf1bm_OWiQ-t3MT0Ck6qVd6__Nhh_jkE6Uw&e=

<

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ermco-2Deci.com_&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FaHmtsrlv1gHUX-sfadM4FPhmi77DyRJDjh8NvpP6sE&m=cuCSoRBHQioxIt7yf7vNse7HItH5o9P7oBe6JpsFsX8&s=4KBBEG7BJWoNBVE848zHC5clrhAY_QhNJ9U-33diHSs&e=

IBM i Personal Blog:

https://urldefense.proofpoint.com/v2/url?u=https-3A__ibmireference.blogspot.com&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FaHmtsrlv1gHUX-sfadM4FPhmi77DyRJDjh8NvpP6sE&m=cuCSoRBHQioxIt7yf7vNse7HItH5o9P7oBe6JpsFsX8&s=q4ylLGpQ0npx8bnzkhV_g63i0t8kraONtEsYRltXOfw&e=

<

https://urldefense.proofpoint.com/v2/url?u=https-3A__ibmireference.blogspot.com_&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FaHmtsrlv1gHUX-sfadM4FPhmi77DyRJDjh8NvpP6sE&m=cuCSoRBHQioxIt7yf7vNse7HItH5o9P7oBe6JpsFsX8&s=P6KcJ9JUslJDpQ6vzUljrPcxJ7HhNsJH0Uus3RtHuL0&e=

“Success is not final. Failure is not fatal. It is the courage to
continue that counts”.

--

-- .
Bryan
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.midrange.com_mailman_listinfo_midrange-2Dl&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FaHmtsrlv1gHUX-sfadM4FPhmi77DyRJDjh8NvpP6sE&m=cuCSoRBHQioxIt7yf7vNse7HItH5o9P7oBe6JpsFsX8&s=n4FxdeVUs0p2JA7B2-pED8EHCY9cM2rUjwsBiHqi4QI&e=

or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at

https://urldefense.proofpoint.com/v2/url?u=https-3A__archive.midrange.com_midrange-2Dl&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FaHmtsrlv1gHUX-sfadM4FPhmi77DyRJDjh8NvpP6sE&m=cuCSoRBHQioxIt7yf7vNse7HItH5o9P7oBe6JpsFsX8&s=oUMaBuyEpDAa44G9fAot83Uru_2hVPVbYY-UF3IE_tA&e=

.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:

or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at

.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:

or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at

.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.midrange.com_mailman_listinfo_midrange-2Dl&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FaHmtsrlv1gHUX-sfadM4FPhmi77DyRJDjh8NvpP6sE&m=xC4X8qxGx5Yvd9fKf1zcyZwF06PPGhThqRHWMmx-3MQ&s=xxXJbDN10cnr9ZSBtIlhgK_wGWt62-0vzuLBgo0v7M8&e=

or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at

https://urldefense.proofpoint.com/v2/url?u=https-3A__archive.midrange.com_midrange-2Dl&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FaHmtsrlv1gHUX-sfadM4FPhmi77DyRJDjh8NvpP6sE&m=xC4X8qxGx5Yvd9fKf1zcyZwF06PPGhThqRHWMmx-3MQ&s=1edyF-AIWaB5p9xGZHumr0OHqPt3muXAPCDzXkn1-go&e=
.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.midrange.com_mailman_listinfo_midrange-2Dl&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FaHmtsrlv1gHUX-sfadM4FPhmi77DyRJDjh8NvpP6sE&m=xC4X8qxGx5Yvd9fKf1zcyZwF06PPGhThqRHWMmx-3MQ&s=xxXJbDN10cnr9ZSBtIlhgK_wGWt62-0vzuLBgo0v7M8&e=

or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://urldefense.proofpoint.com/v2/url?u=https-3A__archive.midrange.com_midrange-2Dl&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=FaHmtsrlv1gHUX-sfadM4FPhmi77DyRJDjh8NvpP6sE&m=xC4X8qxGx5Yvd9fKf1zcyZwF06PPGhThqRHWMmx-3MQ&s=1edyF-AIWaB5p9xGZHumr0OHqPt3muXAPCDzXkn1-go&e=
.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.