Internal processing in IntelliMagic Vision is performed on a Sysplex Boundary. We want the SMF data from all LPARS in a Sysplex, and if multiple Sysplexes attach to the same hardware, then we want these Sysplexes together in the same interest group. By processing the data in this manner, an interest group will provide an accurate representation of the hardware’s perspective of activity and allow an evaluation of whether this activity is below, equal to, or above the hardware’s capability. It’s also true that the shorter the interval, the more accurate the data will be in showing peaks and lulls. The shortest interval you can define is 1 minute. This would typically be the average of 60 samples (1 cycle per second). It’s always a balancing act between the accuracy of the data and the size/cost of storing and processing the data.
In IntelliMagic Vision we also bridge across SMF record types. Accomplishing this feat requires that the SMF/RMF or SMF/CMF data sources are coordinated. There are two variables to manage this.
1) Interval Length (generally 15-30 minutes)
2) Start of the interval (often the top of the hour)
IntelliMagic Vision will throw out data from an LPAR when the data is not recorded in the same interval as all the other LPARs. To handle such variation would impact the reporting accuracy of the Sysplex or consolidated Hardware views. There are overrides available in Reduce to set the interval length, so your options are override or correct. It is possible to override/normalize to a higher interval length, but not a shorter one.
You may see message
RMF0109E 12 System D001 has an interval length of 1800 s, cannot be normalized to standard interval length of 900 seconds. Records will be dropped.
If you want to know how SMF is recorded, issue the operator command ‘D SMF’ or examine the active SMFPRMxx parmlib member. Pay attention to the settings of INTVAL and SYNCVAL parameters (specified in minutes).
If you want to know how RMF is recorded, issue the operator command ‘F RMF,D ZZ’ or examine the active ERBRMFxx Parmlib member. The Settings of SYNC and INTERVAL are of interest.
If you specify SYNC(SMF) then the INTERVAL is ignored. SMF Values for INTVAL and SYNCVAL are used.
If you specify SYNC(RMF, mm) then INTERVAL is used and recording starts at mm.
NOSYNC says INTERVAL is used (and I think the default interval start value is 00).
To have RMF use the same settings as SMF, specify ERBRMFxx value SYNC(SMF). That way, if you change the SMF settings, then RMF will follow.
Some customers use CMF from BMC to provide their RMF type support. In this situation, issue the operator command ‘F MNVZPAS,DC=STATUS’.
This will produce a series of console messages…
BBDDA101I ———- Regular Interval Information ———-
BBDDA101I Base Cycle Time (in 1/100s) ……: 100
BBDDA101I Record Interval Time (in 1/100s) .: 90000
BBDDA101I Number of Cycles/Interval ……..: 900 (100%)
BBDDA101I #of Cycles in current Interval …: 89 ( 9%)
BBDDA101I Total #of Cycles ……………..: 5620394
BBDDA101I Total #of Regular Intervals ……: 6277
Pay particular attention to the number of cycles per interval. In this case it’s 900 seconds which equates to 15 minutes. CMF parameters that control Interval length and the start of the interval are:
To have CMF use the same settings as SMF, in CMF specify SMF=YES,SYNC=SMF. That way, if you change the SMF settings, then CMF will follow.
SMF Interval Data
The default SMF interval is 30 minutes and some customers will balk at using 15 minutes because they think it will double their SMF recording. This is likely not the case. Most SMF record types are written because an event occurred, not because a timer expired. Interval recording impacts type 30 Subtype 2 and type 42 and 7x data only. So yes, there’s an increase, but your daily SMF is not going to double. Depending on the number of records, this is a sample of the size of the SMF Interval Records.
Type 74.5 Cache Statistics
The ERBRMFxx Parmlib member needs to specify CACHE (NOCACHE is the default). Ideally, this needs to be from only one LPAR in the SYSPLEX, but it should be from the LPAR that has connectivity to all DSSs and reporting volumes online. There’s no problem in specifying CACHE in more than one (or all) LPARs, IntelliMagic Vision throws out the duplicate records when they are encountered. Some customers prefer to specify CACHE in more than one LPAR, because not all LPARs are active in all intervals, and they want continuous recording of this information.
The type 74.5 records contain cache statistics and read/write breakdowns by volume.
The equivalent CMF statement is:
Use the CMF statement for gathering both cache, and ESS array and link statistics (Link, Rank, and Extent Pool, as appropriate) from all detected cache and ESS Storage systems (see 74.8 below)
CACHE RECORDS = ALL
Type 74.7 Director Control Unit Port (CUP) Statistics
FICON Director/Switch statistics are stored on the switch platform itself and it does not need to be accessed by more than one LPAR out of all of the LPARs that run data through the switch. Every CEC and LPAR in every Sysplex that might be attached to a switching device can retrieve the switch information using a single LPAR which can then cut the 74-7 RMF records for all CECs, LPARs and sysplexes.
Brocade tells their students that they should set FCD in the ERBRMFxx member (the default is NOFCD – disabled) in only one LPAR of their Sysplex. They should also make sure that FICON STATS=NO has been set in the IECIOSxx member of all LPARs except in the one LPAR where ERBRMFxx is set to FCD in the sysplex.
In 2007, it was warned that obtaining Director Statistics (74.7) data from multiple LPARs could result in Missing Interrupts and boxed devices. Following this guideline will mean only the selected LPAR will report switch activity/errors, even with multiple Sysplexes involved.
The equivalent CMF statement is FICONSW. Same reporting considerations as RMF apply.
Type 74.8 Array and Link Statistics
The ERBRMFxx Parmlib member needs to specify ESS (NOESS is the default). Ideally, this needs to be from only one LPAR in the SYSPLEX, but it should be from the LPAR that has connectivity to all DSSs available. There’s no problem in specifying ESS in more than one (or all) LPARs; IntelliMagic Vision throws out the duplicate records when they are encountered. Some customers prefer to specify ESS in more than one LPAR, because not all LPARs are active in all intervals, and they want continuous recording of this information.
In cases where Remote Copy exists, it’s also useful to have a volume from the secondary DSS online to the primary host. That way we gather 74.8 information from both ends of the remote copy and can see both send and receive activity in the remote copy session(s).
Not all hardware vendors fully support the 74.8 records, but in no case is the request from RMF given an error.
The equivalent CMF statement is CACHE RECORDS= ESS. Same reporting considerations as RMF apply.
Use the CMF statement below for gathering both cache, and ESS array and link statistics (Link, Rank, and Extent Pool, as appropriate) from all detected cache and ESS Storage systems (see 74.5 above)
CACHE RECORDS = ALL
Accurate data concerning your environment is an essential element in assessing the health and vitality of your mainframes. The quality of this information involves it being complete, it being correctly organized and presented in a meaningful manner. IntelliMagic Vision handles the interpretation and presentation, the rest is up to us.
2020 Vision into z/OS Infrastructure Operation and Availability
More than ever before there is a need to see faster, farther, and deeper into the operation and performance of z/OS infrastructure areas. View this webinar to learn how.
6 Reports Every IBM TS7700 Performance Analyst Should Have
Rather than reviewing every indicator across your entire tape grid, there are 6 key reports that you should be reviewing regularly to keep your TS7700 in good working order.
IBM z15 Announcement Highlights and How to Take Advantage
The z15 (with a General Availability date of 9/23/2019) offers up to 190 CPU cores (vs. 170 on z14) and 40 TB of usable memory (vs. 32 on z14), in addition to processor cache and overall performance improvements.
Subscribe to our Newsletter
Subscribe to our newsletter and receive monthly updates about the latest industry news and high quality content, like webinars, blogs, white papers, and more.