Mainframe Performance Topics Podcast Episode 17 “Two Good, Four Better?”

(Originally posted 2018-03-01.)

This episode really has been a long time coming. If I reflect on why, there are two things…

  • The main one is our schedules. Marna and I, as you’ll see, have been all over the place.

  • The minor one is that – until about a month ago – I wasn’t on a creative streak. Nothing major, it happens. And I’m certainly on one now.

We certainly hadn’t got bored of doing this – and I hope you, dear listener, hadn’t got bored of us.

We enjoyed recording this one, so much so that we’re “going back into the studio” 🙂 straightaway.

In the meantime, I hope you’ve all caught up with previous episodes. There’s quite a lot of evidence of that from the statistics we see. (To repeat something I’ve said before, we’re not even close to obsessed with the statistics but enjoy the fact we continue to have a good audience.)

Episode 17 “Two Good, Four Better?”

Here are the show notes for Episode 17 “Two Good, Four Better?”. The show is called this because our Performance topic is about aspects of whether more LPARs in the same CECs in a sysplex is better or worse.

Here are the show notes.

Where we’ve been

It’s taken a long time to get back together to do another episode!

  • Marna has been to the zTechU Washington DC, and Milan, Italy for a z Sysposium for Italian customers, and at GSE UK at Whittlebury Hall.

  • Martin has been travelling a lot too. As well as being in Whittlebury Hall, Martin has been to Hamburg, Germany and Istanbul, Turkey to visit customers, IBM Silicon Valley Lab and Poughkeepsie Lab, and in New York City for a customer visit.

  • While in Poughkeepsie he dropped in on the Terminal Talk folks, in the “T4” (“Terminal Truck Talk Thing”).


Our “Mainframe” topic discusses the addition of a new parmlib member for RACF, IRRPRMxx.

  • It replaces ICHRDSNT (the RACF Data Set Name Table), and ICHRRNG (the RACF Range Table). These previously could be provided as usermods, maintained as assembler source. There are two levels of pain here:

    1. Having to know how to code and assemble them.

    2. Having to manage them as a usermod each release.

  • If you use both, the load modules for ICHRDSNT and ICHRRNG and the IRRPRMxx parmlib member, the parmlib member takes precedence.

  • IRRPRMxx is found at IPL within IEASYSxx RACF= statements. You can have up to three members. ICHRDSNT replaced by DATASETNAMETABLE statement, and ICHRRNG replaced by RANGETABLE statement in the parmlib member. Complete syntax is found here.

  • You don’t need to code the new IRRPRMxx from scratch, you can use a nicely provided REXX exec to convert from memory on what you are currently using, or from a load module on DASD with DSNT2PRM. Be careful, though, as any RVARY commands might change settings won’t be reflected. This tool is informal and off the web, and it can be run pre-V2.3 just to see what it produces.

  • You can’t use the IRRPRMxx until z/OS V2.3. But when you do, use the handy supplied TSO command RACPRMCK to verify the syntax of the parmlib member. Put it in the parmlib concatention, and try it out.

  • Then, when you’re ready to use your real IRRPRMxx members, just update your IEASYSxx and IPL.


Martin talked about whether 2 LPARs (on 2 CECs) or 4 LPARs (on 2 CECs) is better.

  • This is related to some trends, but it’s a big subject.

  • There are tradeoffs between 2 vs. 4. Better availability with 4, but would it perform better or worse? It might be better if you get to a state where each LPAR is contained in a single drawer (on z13 or z14). (At least two customers he knows does this.) There is more PR/SM overhead with more LPARs, which was discussed in a 1990 Washington Systems Center Orange book (“PR/SM Performance in LPAR Mode”, ZZ05-0453).

  • Also the topic of memory duplication, with more DB2 images. CICS and MQ would similarly have memory considerations too. There might be some scope for consolidation of DB2s.

  • Operational and software considerations need to be thought through. How much harder would it be to manage it, and also keep the software up to date across more images? Of course, much of the thinking would already have been done for 2-way.

  • Martin is planning on doing a presentation on this with Anna Shugol. This LPAR configuration design does remain in interesting topic.


Our podcast “Topics” topic is a follow up and a short discussion on what to do if your wifi isn’t performing as you wish.

  • It’s been a year since Marna’s son built his “gaming” personal computer. She asks him about what has gone well with it, and what he might save in the future for.

  • One thing that has been a problem is the wifi signal in the house. It is not consistently strong, and he would like an ethernet connection directly into the computer. That isn’t happening (with a cord down the hallway), so a different solution was found: Powerline Ethernet solution, which plugs into two electric outlets.

  • This was less than $100 and is working well. Other solutions do exist, but this cost effective one has been this gamer’s delight.

Customer Requirements

  • RFE 76283 KC4Z sysplex support

    Need KC4z to support sysplex environments - data should be stored at the sysplex level, i.e. /sharedapps and any system specific/runtime info stored in system level directories.

Our discussion:

This is in z/OS V2.3, and after performing a migration action, you’ll have it. It was nice to have a requirement that was delivered already (although it wasn’t marked as so at the time of the recording)!

Our discussion:

Indeed, this sounds to be like a good utility extension. Limited to FB and no larger than 80 bytes does mean that it can’t be used for some solutions today. Although Martin points out that other capabilities exist (for instance in DFSORT) to do this without the FB 80 restriction. Marna pointed out this very old utility was wonderful for doing quick additions in parmlib (which is what ServerPac does with customized data). We’ll have to see the response on this one, and how it ends up.

Where We’ll Be

Martin will hopefully be in Copenhagen, Denmark visiting a customer.

Marna will be at SHARE in Sacramento March 12-16 , and in Cairo IBM TechU April 15-17.

On The Blog

Martin published three blog posts:

Contacting Us

You can reach Marna on Twitter as mwalle and by email.

You can reach Martin on Twitter as martinpacker and by email.

Or you can leave a comment below.

Published by Martin Packer

I'm a mainframe performance guy and have been for the past 35 years. But I play with lots of other technologies as well.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: