(Originally posted 2005-04-13.)
Session ZP05: Parallel Sysplex Tuning, Presenter: Joan Kelley
Joan gave a good summary of CF levels and general-but-detailed tuning recommendations.
Enhanced Patch Apply on z890 and z990 allows different CF levels on the same CEC. But a customer suggested that in their environment re-IPLing one of the CF LPARs brought it automatically up to the newer level. Joan will try to reproduce in the lab.
CF Level 14 dispatcher changes are to help with scaling to larger request rates. For example duplexing CF to CF signalling does not get stuck behind other requests.
SMF 74-4 CF utilisation no longer includes polling for work. This is a more realistic view of CF busy. SMF 70 CF
LPAR busy is not changed.
CF busy ROTs based on at what utilisation the service time doubles.
Joan positioned duplexing as having the most benefit for structures that don’t support rebuild. Also for IXGLOGR
structures duplexing reduces the need to have staging (disk) data sets, which should improve Logger performance.
Joan offered a rule of thumb of duplexing recovery being 40 times faster compared to log recovery, and 4 times
faster compared to rebuilding the structure. Of course this comes at a cost but Joan reiterated what we already
know: Smart installations have some “white space”, especially on CPU and memory for the failure takeover case.
ISCLOCK is a good structure to do performance tests with as it’s the fastest structure because requests carry no
actual data.
IC Links (internal to the processor complex) are processed by any physical processor – whether Pool 1 (CPs) or Pool
2 (ICF/IFL.zAAP). Two links are usually enough. Limit the number to the sum of Pool 1 and Pool 2 engines – 1. More
than that can cause performance degradation.
If you increase the ISGLOCK structure and get no more entries look at APAR OA10868. It fixes a bug.
Joan mentioned that XCF traffic is increasing in general – because of new exploiters. So it might be worth keeping a
closer eye on it.
Session TSP08: New RMF Measurements for the DS6000 and DS8000, Speaker: Siebo Friesenborg
Siebo used to work in our worldwide consulting team but now he works for the Storage product division.
If you haven’t seen Siebo present I suggest you do – whatever the topic. Just take your sense of humour along with you. It’s wonderful to listen to / watch him. And Siebo was on top form today.
If you specify ESS in RMF 74-8 records will get written with a series of counters for ECKD, PPRC or SCSI. NOESS is
the default. Siebo strongly recommends you specify ESS.
74-5 enhanced Raid Rank statistics to give numbers for each physical volume – for DS6000 and DS8000 (2107).
Session G10: zSeries vs UNIX vs AMD/Intel Platforms: Which one is best?, Speaker: Phil Dalton
This was a cheering marketing presentation but with lots of good information. Here are a just a couple of factoids:
In the last few years the zSeries application portfolio has grown dramatically (particularly if you include Linux on
zSeries).
Phil knows of customers with in excess of 8,000 Linux servers under z/VM on a single machine. Obviously it’s not
nearly as many as the “gee whiz” demo we used to do. But it is a real customer having a mind-boggling large number
of Linux servers on a single footprint.
Session TSS18: DFSMS Catalog Overview and Diagnostics, Speaker: Becky Ballard
This was for me a good review of ICF Catalogs. (It’s been a while.)
Catalog Address Space (CAS) normally is ASID 000C or 000D. If not it’s not necessarily a problem but it will
indicate a restart. Restarting CAS actually is only minimally disruptive: It shouldn’t harm users that already have
a data set open. Catalog requests will be redriven by CAS on restart if they were in-flight.
Becky uttered the words “experience the IDC3000I message”. I have nothing against that particular message – I just
thought it was a lovely turn of phrase.
LISTCAT basically formats the VVRs (VSAM Volume Records). There are two types of VVR: Primary for the cluster and
secondary for each component. LISTCAT draws information from both.
F CATALOG can be very useful in checking maintenance levels, performance information, etc. Also can actually modiFy things. 🙂 You can even modiFy the CAS service task limit – but I’m not clear why you’d need to.
Informational APAR II10752 gives good advice on Catalog performance.
Mainframe, Performance, Topics 