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.
Where we've beenIt'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:
Having to know how to code and assemble them.
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 for in the future.
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.
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.
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)!
RFE 109248 IEBUPDTE Support for VB and LRECL > 80
This utility is limited to 80 bytes, but PDS/PDSE are not limited to 80 bytes, so we can not use it to add members to a PDS/PDSE that exceed the 80 byte limit.
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 BeMartin 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 BlogMartin published three blog posts:
Contacting UsYou 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.
Podchaser is the ultimate destination for podcast data, search, and discovery. Learn More