Future Speakers

(subject to change)

February 2, 2016 - What’s New in z/OS Performance and Tuning by Randy Springs of BB&T

March 1, 2016 - EJES for JES2 and JES3 by Phoenix Software

April 5, 2016 - SHARE Conference Reports by SPARTA Members

We need ideas and volunteers for future speakers. Presentations don’t have to be fancy, just informative and interesting. Even a 5 or 10 minute talk can start an interesting interaction. Contact Ron Pimblett by phone as noted below.

2015-2016 SPARTA

Board of Directors

Randy Springs - President

BB&T                  (919) 745-5241

3200 Beechleaf Court, Suite 300

Raleigh, NC 27604

Ron Pimblett - Vice President

MDI Data Systems 919-426-6518

866-634-3282

Raleigh, NC 27609

Mike Lockey -  Secretary

Guilford Co. Information Services  336-641-6235

201 N. Eugene St.

Greensboro, NC 27401

Tommy Thomas - Treasurer

LabCorp                  336-436-4178

3060 S. Church St.

Burlington, NC 27215

Ed Webb -  Communications Director

SAS Institute Inc.  919-531-4162

SAS Campus Drive

Cary, NC 27513

Meetings

Meetings are scheduled for the first Tuesday evening of each month (except no meeting in January), with optional dinner at 6:15 p.m. and the meeting beginning at 7:00 p.m.

These monthly meetings usually are held at LabCorp’s Center for Molecular Biology and Pathology (CMBP) near the Research Triangle Park (see last page). Take I-40 to Miami Boulevard and go north. Turn right onto T.W. Alexander Drive. Go about a mile or so. Then turn right into LabCorp complex and turn Left to the CMBP Building (1912 T.W. Alexander Drive). In the lobby, sign in as a visitor to see Tommy Thomas. Tommy will escort you to the conference room.

Call for Articles

If you have any ideas for speakers, presentations, newsletter articles, or are interested in taking part in a presentation, PLEASE contact one of the Board of Directors with your suggestions.

Newsletter e-Mailings

The SPARTA policy is to e-mail a monthly notice to our SPARTA-RTP Group. The newsletter is posted to the website about five (5) days before each meeting so you can prepare. The SPARTA-RTP Group is maintained by Chris Blackshire; if you have corrections or problems receiving your meeting notice, contact Chris at chrisbl@nc.rr.com.

October 2015 “CBT Tape” Shareware Online

The directory and files from the latest CBT tape V490 (dated October 26, 2015) are available from www.cbttape.org.

If you need help obtaining one or more files, contact Ed Webb at SAS (see Board of Director’s list for contact info).

Minutes of the December 2, 2015 Meeting

•Meeting was called to order at 6:55 PM by Randy Springs, the SPARTA President.

•The December meeting was held at the SAS Training Center (Building F) in Cary, N.C.

•Twenty-one (21) people were present of which Ten (10) are 2015 members.

•Everyone in the room introduced themselves, told where they worked, and briefly described their job functions or their job hunting challenges.

•The usual Old and New Business portions of the meeting were postponed until the next meeting.

OLD BUSINESS

•The next SPARTA monthly meeting will be on Tuesday, February 2, 2016 at LabCorp in RTP.

•Food for the February 2 meeting will be chicken.

NEW BUSINESS

•Thanks to SAS and Ed Webb for hosting the meeting.

•There are currently 60 people on the SPARTA-RTP email list.

•Send any e-mail address changes to Chris Blackshire so he can update the SPARTA-RTP Listserv. You will be added by the moderator (Chris = SPARTA-RTP-owner@yahoogroups.com) sending you an invitation to Join the list.

•The abbreviated business portion of the meeting ended about 7:05 p.m.

PRESENTATION

zEnterprise Data Compression (zEDC) by Frank Kyne of Watson-Walker.

• Agenda

• Introduction
- Thanks to all for coming
- Thanks to Ron Pimblett for asking me along
- Thanks to SAS for hosting the meeting
- Who is Frank Kyne?
- - Third employee of Watson and Walker (Tuning Letter Editor)
- - 28 Years at IBM (working with MVS since 1978)
- - Born in New York City (0-14 years)
- - Moved to Ireland
- - 1998 Moved back to the USA
- - Contributor to over 80 IBM Redbooks
- Please ask questions as I go along

• What We Are Going To Talk About (Agenda)
- Understanding Compression
- Quick Introduction to zEDC
- Potential Benefits of zEDC
- List of Current IBM and ISV Exploiters for zEDC
- Performance Comparisons to Traditional DFSMS Compression Options
- Identifying the Potential Value of zEDC For You
- Configuring zEDC Using HCD
- How to Enable zEDC Exploitation
- Implementation Tips
- Monitoring and Reporting on zEDC Performance and Usage
- Other Monitoring Information for zEDC
- zEDC Hardware and Software Prerequisites
- Summary
- zEDC Reference information

• Understanding Compression
- From a z Systems perspective, there are two main types of compression:
- - Traditional compression
- - - Software – CSRCESRV (Run Length Encoding) Replaces runs of a character with a smaller number of bytes indicating the count and the character
- - - Hardware – CSRCMPSC – (Dictionary-based) Replaces common character strings with a shorter identifier of the string. This uses the CMPSC hardware instruction
- - - These are both designed to have a low cost of decompression on the basis that you will compress the data once, but decompress many times
- - “New” zEDC compression
- - - The algorithm used by zEDC compresses data by replacing characters with pointers to identical strings earlier in the block. So the larger the block of data being compressed, the more effective this form of compression can be
- - - Files compressed using zlib (which can use zEDC) can be shipped to other platforms and be decompressed using common tools
- In relation to data set compression on z/OS, the terms ‘compression’ (in IGDSMSxx member) and ‘compaction’ (in Data Class definition) are used interchangeably

• Quick Introduction to zEDC
- zEDC is a combination of specialized PCIe cards that deliver very high performance compression and decompression services, software services to communicate with the card, and exploitation in various software products. It consists of:
- - Hardware
- - - Up to 8 PCIe adapters per CPC, max of 2 per PCIe drawer domain
- - - Up to 15 LPARs sharing each adapter
- - - - IBM recommend a minimum of 4 adapters
- - - And don’t forget your Disaster Recovery CPCs!
- - Software
- - - There is a zEDC chargeable feature for z/OS that must be licensed on every CPC that will use zEDC
- - A very important point that you must understand to avoid confusion about zEDC is that it is a system service that will compress or decompress data for anyone. For example:
- - - The data owner might compress the data. As an example, SMF itself calls zEDC to compress the data before it is sent to the log stream. As far as System Logger is concerned, it is being sent 1s and 0s. It is irrelevant to it whether the data was compressed before it was given to it
- - - Or, the access method might use zEDC to compress the data. In that case, the user program has no idea that the data is going to be compressed – it just passes the data to BSAM or QSAM. The access method then takes that data, passes it to zEDC, and writes the compressed data to disk
- - - Or, you could have something like DFSMSdss, which can (optionally) call zEDC itself, OR it can pass the data to BSAM or QSAM which can call zEDC, OR, it could call zEDC and pass the compressed data to BSAM or QSAM which might call zEDC again
- - If someone says that VSAM doesn’t support zEDC, that means that VSAM itself will not call zEDC (you can still compress VSAM KSDSs using traditional compression)
- - However VSAM data sets could happily contain data that had been compressed by zEDC before it was passed to VSAM, as is the case with System Logger offload data sets for compressed SMF log streams

• Potential Benefits of zEDC
- Based on IBM tests and user experiences, IBM expects zEDC to achieve (on average) about double the compression of traditional z/OS compression techniques. This means SAVINGS ON DASD SPACE, reduced load on disk cache, ports, channels, switches, etc
- - And that is if you already use compression today! If, like many customers, you don’t use compression because of the CPU cost, zEDC will save you even more DASD SPACE in return for a small increase is CPU time
- If you compress HSM and/or DSS data that is written to tape today, using zEDC instead of traditional DSS or HSM compression can reduce the number of tapes you are using and also reduce CPU time
- - If you are using a virtual tape subsystem that compresses all incoming data, zEDC will reduce the volume of data being sent through the I/O subsystem and the number of z/OS I/Os
- - Plus, in some cases, compressing the data twice (once with zEDC and once by the tape subsystem) can result in smaller files than if it was only compressed once
- Because zEDC moves the load of compressing and decompressing data from the CPs to the PCIe card, zEDC FREES UP z/OS CPU CAPACITY that was being used to compress data sets
- - One zEDC card costs USD12K. How much does one CP cost?
- If you encrypt the data, compressing it first reduces the amount of data to be encrypted/decrypted, thereby reducing elapsed time and CPU utilization
- - Additionally, PTF UA72250 enhances the Encryption Facility for z/OS to support zEnterprise Data Compression (zEDC) for OpenPGP messages
- Because the capacity used on the zEDC card does not factor into your software bill, it might result in REDUCED SOFTWARE BILLS
- - This depends on whether you were using compression previously, and if the times when a lot of compression/decompression was being done coincided with your peak R4HA
- - Also need to make sure that the capacity freed up by zEDC is not eaten by discretionary work – if it is, your SW bills will not reduce

• List of Current IBM and ISV Exploiters for zEDC
- The following IBM products provide exploitation of zEDC at this time:
- - SMF (only in logstream mode)
- - BSAM and QSAM (but not VSAM KSDSs)
- - DFSMSdss
- - DFSMShsm when using DFSMSdss as the data mover
- - IBM Encryption Facility
- - MQ Series V8
- - Connect Direct
- - Zlib services
- - Java V7
- - Content Manager OnDemand, starting in 9.5.0.3 (shipped August 14, 2015)
- In all cases, zEDC exploitation is optional, so you must do something to explicitly indicate that you want to use it
- The following ISV products provide exploitation of zEDC at this time:
- - Data21
- - Innovation Data Processing
- - PKWARE - PKZIP and SecureZip
- - Alebra - Parallel Data Mover
- - Software AG - Entire Net-Work
- - Gzip 1.6 in Rocket Software Ported Tools for z/OS see http://www.rocketsoftware.com/products/free-tools
- If you know of any others, please let us know.

• Performance comparisons to traditional DFSMS compression options
Quantifying zEDC benefits – comparison to traditional compression
- The most common IBM exploiters of zEDC compression at this time are:
- - Sequential data sets (accessed using BSAM or QSAM)
- - SMF Log streams
- - DFSMSdss and hsm
- We ran some comparisons of different types of compression (DFSMS Generic compression, DFSMS Tailored compression (on both zEC12 and z13), and zEDC compression) on 3 different types of data:
- - SMF Sequential data sets
- - DB2 archive log offloads
- - SVC dump data sets
- We also ran some comparisons of decompression for the different compression methods
- And we have some measurements for dss DUMP processing
- Performance comparison (Charts not copied)
- - Measurement 1 - SMF
- - - 2 data sets containing SMF data, total size 60255 tracks
- - - All runs on z13, except Tailored_EC12, which ran on zEC12
- - Measurement 2 - DB2 logs
- - - 15 DB2 archive log data sets, total size 32175 tracks
- - - All runs on z13, except Tailored_EC12, which ran on zEC12
- - Measurement 3 - SVC dumps
- - - 5 SVC dump data sets, total size 40883 tracks
- - - All runs on z13, except Tailored_EC12, which ran on zEC12
- - Measurement 4 - decompression
- - - Decompression comparisons – uncompressed data set size 60255 tracks
- - - Measured on both zEC12 and z13
- - Measurement 5 - DFSMSdss DUMP
- - - DFSMSdss FULL VOLUME – (on zEC12)

• Identifying the potential value of zEDC for you
- At this time, the only tool available from IBM to help you estimate the potential cost and savings of zEDC (IBM’s zSystems Batch Network Analyzer (zBNA)) only handles sizing for BSAM/QSAM use of zEDC
- zBNA can be downloaded at no charge(!) from http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS5132
- While there are other easy-to-implement exploiters of zEDC, there are currently no tools to help you identify the value that zEDC will deliver for them
- - However it is likely that zEDC can be cost justified for use with sequential data sets alone. Savings through additional exploitation of zEDC are a bonus
- zBNA uses data from SMF Type 14, 15, 30, 42(6), 70, 72, and 113 records
- - Run CP3KEXTR against these SMF records to create input file for zBNA. Input should only contain records from one system for one night – loading larger volumes of data can result in ‘878’ abends in zBNA
- - To save time, TERSE the resulting file on z/OS and download that file to your PC. zBNA can input the tersed file directly
- zBNA has been receiving a stream of enhancements to its zEDC support, so make sure that you download the latest version and review the What’s New section on the web site to see the list of recent new functions
- If you are not familiar with zBNA, download the handouts from http://share.org for John Burg’s zBNA hands-on lab - Session 17551 System z Batch Network Analyzer (zBNA) Tool Hands-on Lab and get sample data from the IBM Techdocs web site, in the Education section
- Be aware that SAS does not support zEDC compression for its databases, however the SAS PDBs look like ordinary sequential data sets to zBNA, so be careful to exclude those from the calculations
- Similarly, any other ‘sequential’ data set that is processed by an access method other than BSAM or QSAM will not support zEDC, so be aware of those in the zBNA results
- To select just a subset of data sets, put your mouse over any of the check boxes and click right mouse button. Select ‘select all’, and then deselect any that you want to exclude
- Few tips for using zBNA:
- - zEDC provides 3 potential savings:
- - - DASD and tape space savings – should apply to EVERYONE
- - - Free up CP capacity – should apply to EVERYONE that uses compression today
- - Reduced software bills
- - - To achieve this benefit, you must be using compression today, and your peak Rolling 4-Hour Average must coincide with your peak compression activity
- - - But don’t get hung up on just this savings – the other two savings are real as well
- Remember that zBNA is only looking at one exploiter of zEDC. It does not do anything for SMF or zlib or MQ or Connect Direct or .... So if you plan to use additional exploiters, the benefit of zEDC is likely to be larger

• Configuring zEDC using HCD
- The ITSO have created 2 excellent videos that lead you step-by-step through the process of defining a zEDC card in HCD. For info on how to add a zEDC card (in less than 7 minutes!), refer to:
- - https://www.youtube.com/watch?v=5We571gvh5o and https://www.youtube.com/watch?v=wZbtM77ubrs
- - Recommend using PFIDs starting with an even digit for one Resource Group, and an odd digit for the other Resource Group. Then make sure that every LPAR is connected to at least one card in each Resource Group (recommended minimum of 2 cards)
- After the hardware setup is complete, you need to update the IFAPRDxx member to enable zEDC (this requires an IPL)
- IF you have unauthorized programs using the zlib interface to zEDC, they must have READ access to the zEDC SAF profile (FPZ.ACCELERATOR.COMPRESSION.)

• How to enable zEDC exploitation - SMF Log Streams
- The first exploiter of zEDC was SMF (when in log stream mode). This is a very popular starting point because the implementation effort is trivial and the savings can be significant
- - SMF is also nice because the heaviest volume of SMF records is typically during the online day when other use of zEDC (sequential data sets, HSM, DSS) is typically light
- To exploit zEDC, SMF must be writing its records to log streams. SYS1.MAN data sets are not and will not be supported for zEDC compression. If you are already in log stream mode, you are 99.99% of the way there
- To enable compression of an SMF log stream, add the COMPRESS keyword to the LSNAME or DEFAULTLSNAME definition in SMFPRMxx:
- - DEFAULTLSNAME(IFASMF.DEFAULT,COMPRESS) DSPSIZMAX(200M)
- - You can have a mix of some log streams that are using zEDC and ones that are not
- Each log block has an indication of whether it contains zEDC-compressed data or not. When IFASMFDL reads the log block, it knows whether it needs to be decompressed or not. This allows you to have a mix of compressed and not-compressed log blocks in the same log stream (allows for a phased implementation of zEDC compression of shared SMF log streams across multiple systems)
- Summary of exploiting zEDC for SMF data
- - That’s it – just one new keyword in your SMFPRMxx member, no additional changes required
- - Compression of a log stream can be turned on and off dynamically
- - - But be aware that if you want to turn it OFF, removing the COMPRESS keyword will not achieve that – you must change COMPRESS to NOCOMPRESS
- - IFASMFDL is the only way to read the SMF log stream, and it automatically detects whether a log block is compressed or not, meaning that no JCL or Parm changes are required
- - See http://www.ibm.com/support/docview.wss?uid=isg3T1022540 for info about IFASEXIT and zEDC
- - To get the best value from zEDC, your SMF offload sequential data sets should use a data class that specifies the use of zEDC compression

• How to Enable zEDC Exploitation - BSAM/QSAM
- Traditional DFSMS compression for sequential data sets is enabled by assigning the correct SMS data class to a data set. One of the attributes in the data class definition is whether the data set should be compressed, and if so, what algorithm should be used:
- To enable zEDC compression, we recommend setting up a new data class for testing purposes. That data class should be defined with zEDC REQUIRED:
- You then conduct your testing by specifying the correct data class when you allocate the data set
- Testing should include allocation, deletion, extending the data set, filling the data set, partial release, single strip, multiple stripe, varying buffer numbers, backup, migration, recall, restore…..
- When testing is complete, update the previous compression data classes to indicate ZR (zEDC required), and (if appropriate) update the COMPRESS parameter in IGDSMSxx

• How to Enable zEDC Exploitation - DFSMSdss & HSM
- Obvious candidates for zEDC exploitation are DFSMSdss and DFSMShsm
- - The data sets they create are not actively used, so the ratio of decompressions to compressions should be low
- - You want to balance data availability and protection with minimal disk or tape space usage
- - Both already provide compression options that use software compression, so are good potentials for CPU savings if you can replace their traditional compression with zEDC
- Ability to use zEDC to compress and decompress data was added in z/OS 2.1 + APARs (OA42198, OA42238, and OA42243)
- - z/OS 1.12 and 1.13 can read zEDC-compressed data sets, but use software (extremely CPU-intensive) to do it
- DFSMSdss supports the following operations against zEDC-compressed data sets:
- - CONSOLIDATE
- - COPY
- - DEFRAGv - - DUMP
- - - If you wish, you can protect the use of zEDC on the DUMP command using the STGADMIN.ADR.DUMP.ZCOMPRESS SAF profile
- - RESTORE
- - PRINT
- - RELEASE
- Most of the DFSMSdss support for zEDC is related to processing data sets that have already been compressed by zEDC
- - It doesn’t make sense to decompress the data, then immediately compress it again
- - DFSMSdss understands which data sets are in zEDC-compressed format and reads the data as-is (without calling zEDC) from the source volume where appropriate (COPY, for example)
- - For most dss operations, the data is then written as-is to the output data set
- For DUMP operations against zEDC-compressed data sets, there are two options:
- - If you specify ZCOMPRESS in the dss SYSIN, dss passes the data to zEDC to be further compressed and it is then written to DASD. In this case, the output data set can be EF or non-EF
- - If the output data set is in extended format (based on the data class), dss writes very large blocks (of already zEDC-compressed data) to BSAM. If the data class indicates that zEDC should be used, BSAM then calls zEDC to compress the data again before writing it to the output data set
- Note that dss COPY does NOT support the ZCOMPRESS keyword
- DFSMShsm supports the following operations against zEDC-compressed data sets:
- - MIGRATION, RECALL
- - BACKUP, RECOVER, FRBACKUP, FRRECOV, ABACKUP, ARECOVER
- - Full Volume DUMP, RECOVER FROMDUMP
- DFSMShsm support for zEDC is limited to when hsm is using dss as its data mover
- Add the following to ARCCMDxx member:
- - SETSYS ZCOMPRESS(DASDBACKUP(YES))
- - SETSYS ZCOMPRESS(DASDMIGRATE(YES))
- - SETSYS ZCOMPRESS(TAPEBACKUP(YES))
- - SETSYS ZCOMPRESS(TAPEMIGRATE(YES))
- - DEFINE DUMPCLASS(xxx ZCOMPRESS(YES))
- - Restart HSM
- DFSMShsm can use zEDC to compress any data set type except for PDS when migrating or backing up the data
- But, DFSMShsm will NOT call zEDC to compress an already-compressed data set
- - Like dss, HSM will copy already-compressed data sets to its output data sets without decompressing and then recompressing them
- - Same applies on a RECALL of a data set that was previously compressed on Primary DASD
- Ensure that you have the PTF for APAR OA48394 if using zEDC with HSM
- DFSMSdss/zEDC tips…
- - Compression ratio is very dependent on input data. In DFSMS lab measurements, compression ratios ranged between 3:1 and 9:1
- - In ITSO measurements, HWCOMPRESS consistently used the most CPU. This was on a zEC12, would expect it to be better on z13. But users of HWCOMPRESS are still expected to see the largest savings from moving to zEDC
- - Compare the ZCOMPRESS/EF run to the NoComp/zEDC run – both call zEDC once, but dss passes more data at a time to BSAM when using zEDC-format output data sets, possibly resulting in better compression ratios
- - If using DFSMSdss DUMP to write to tape, you should specify ZCOMPRESS rather than COMPRESS or HWCOMPRESS – data class with COMPACT(ZR or ZP) will not work for tape data set
- - Even if input data set has already been compressed with zEDC, it may be possible to get further compression improvements on DUMP (to tape) with ZCOMPRESS or DUMP to zEDC-compressed (disk) data set

• zEDC Implementation Tips
- If the system has the required releases and PTFs to support zEDC use by BSAM/QSAM, that meets the criteria of zEDC Required EVEN IF THE LPAR DOES NOT HAVE ACCESS TO A zEDC CARD. So the job ends with RC=0, with NO joblog message to tell you that zEDC was not available, and with a data set that is in zEDC-format, but whose contents are not compressed
- - Save yourself hours of frustration by issuing D PCIE command to be sure
- Remember that compressed seq data sets (generic, tailored, or zEDC) must be Extended Format. If you specify DSNTYPE=LARGE, that overrides DSNTYPE=EXT in the data class, meaning that the data set will not be compressed, even if the data class specifies that compression should be used
- Make sure that IFASMFDL steps have a region size of at least 4MB
- Some zEDC exploiters provide the ability to decompress zEDC-compressed data if zEDC is not available. This is EXTREMELY CPU-intensive
- Test software decompression of a compressed data set in an LPAR that doesn’t have access to zEDC card. This will convince you of why you want access to zEDC in any LPAR that might touch zEDC-compressed data
- - Decompressing 5425 track data set WITH zEDC: - - Decompressing 5425 track data set WITHOUT zEDC
- - - – Elapsed 22.92 Secs – Elapsed 84 Secs
- - - – TCB 1.88 Secs – TCB 70 Secs (!)
- - - – SRB 0.24 Secs – SRB 0.21 Secs
- What is the impact of zEDC on your chargeback algorithms?
- - YOUR bills may go UP, because you must pay for the hardware and software
- - Your USERS bills go DOWN, because now they are using less CPU time….
- To address this scenario, IBM have added a new zEDC Usage Statistics section in the SMF Type 30 records. You will now be able to see how much use a jobstep made of zEDC and can adjust its bill accordingly
- - But remember that you do NOT pay for the “CPU Time” on the zEDC card, so the user’s bill should reflect the data center’s reduced costs - See APARs OA45767 and OA48268 (OPEN)
- An important zEDC PTF is UA77619 (ABEND11E-0702 OR ABEND002-F6 in job using zEDC). The PTF is available, but one of the pre-reqs is PE
- However you can force on the pre-req PTF if you specify FREEMAINEDFRAMES(NO) in DIAGxx
 For more information, see APAR OA46291
- If you are using CICS SMF record compression and/or DB2 record compression today, those functions use software compression, not zEDC
- Recommend that you turn off CICS and DB2 SMF record compression after you implement zEDC compression for the associated SMF log streams
- - zEDC will provide at least as good compression, probably more
- - AND you save the CPU cost in CICS and DB2
- If you want to take zEDC on and offline for testing purposes (or to see how exploiters react if zEDC goes away):
- - Issue D PCIE to get PFID for zEDC devices
D PCIE
IQP022I 13.58.49 DISPLAY PCIE 376
PCIE 0012 ACTIVE
PFID DEVICE TYPE NAME STATUS ASID JOBNAME PCHID VFN
00000025 Hardware Accelerator ALLC 0013 FPGHWAM 01BC 0006
00000035 Hardware Accelerator ALLC 0013 FPGHWAM 027C 0006
- Issue CF PFID(xx),OFFLINE,FORCE for each device:
CF PFID(25),OFFLINE,FORCE
IQP034I PCIE FUNCTION 00000025 NOT AVAILABLE FOR USE. 405
PCIE DEVICE TYPE NAME = (Hardware Accelerator ).
IQP034I PCIE FUNCTION 00000025 AVAILABLE FOR CONFIGURATION.
PCIE DEVICE TYPE NAME = (Hardware Accelerator ).
IEE505I PFID(25),OFFLINE
IEE712I CONFIG PROCESSING COMPLETE
- - To bring devices back online, issue CF PFID(xx),ONLINE
- - If you config off all zEDC cards while SMF is using compression, you will get nasty message IFA730E, but SMF continues writing to the log stream, but without compressing the records
- When maintenance is applied to zEDC cards (a hardware function), all the cards in one of the two Resource Groups will be taken offline
- To ensure that zEDC remains available, every LPAR should be connected to at least 1 zEDC card in each Resource Group.
- - This means that you should ALWAYS have a minimum of two zEDC cards on a CPC. If you only have one, you may need to pause processing for any workload using zEDC while maintenance is being applied
- To cater for the possibility of one of the surviving cards failing while maintenance is being applied to the other Resource Group, IBM recommend that each LPAR should be connected to 4 zEDC cards
- Apply the PTF for APAR OA48434 – this is a Health Check to ensure that the LPAR has access to more than one zEDC card. Enable the check and add the check message to your automation to ensure that the appropriate personnel are notified if a card becomes unavailable

• Monitoring and Reporting on zEDC Performance and Usage
- The bandwidth of the zEDC card is over 1GB/sec
- - Compare this to about 300 MB/sec for the CMPSC instruction and between 50 and 100MB/sec for zlib
- In our test with 16 parallel compression jobs running, we couldn’t drive the utilization of the card above 34%. So, for most customers, 2 cards should provide sufficient capacity
- If you find that utilization of the card is increasing, that is a GOOD THING, because it means that work that would previously have run on a general purpose CP (and that would have been counted in the determination of your software bills) is now being processed on a cheaper, faster processor AND is not impacting your software bills
- In z/OS 2.1, the only RMF reporting for zEDC usage was via the 74.9 SMF records. These could be processed by the RMF PostProcessor to create XML reports
- In the following reports, system SC81 (z/OS 2.2) was running 16 concurrent IEBGENERs, copying uncompressed data sets to zEDC-compressed data sets. The only zEDC activity in system SC80 (z/OS 2.1) was a small amount of SMF activity, writing to zEDC-compressed log streams
- - Note that the same report template is used for RoCE and zEDC, so some fields will be empty in the reports for zEDC devices
- - Much higher queue time on SC80 due to low level of activity in SMF, resulting in it waiting for enough data to fill a buffer
- - Use the “Time Busy” field to monitor utilization of card BY THIS LPAR
- Hardware Accelerator Compression Activity
- - Remember that this report includes total numbers for ALL exploiters. To get information for a specific exploiter, need to go to info provided by that exploiter
- The interesting fields in these reports are:
- - Adapter Utilization – indication of the utilization of the zEDC card BY THIS LPAR
- - Time Busy % - % of time adapter was busy by this system. Basically another view of Adapter Utilization – also only provides information about utilization by this LPAR
- - Request Execution Time - Average time, in mics, to process a request from this z/OS
- - Request Queue Time - How long were blocks waiting to be sent to zEDC?
- - Consider that exploiter might queue several blocks before sending to zEDC
- - Request Size - Average sum size, in KB, of blocks sent to and from zEDC
- - Compression Request Rate - Number of compression requests per sec
- - Compression Throughput - MB compressed per second
- - Compression Ratio - Average compression ratio for this LPAR
- - Decompression Request Rate - Number of compression requests per sec
- - Decompression Throughput - MB compressed per second
- - Decompression Ratio - Average compression ratio for this LPAR
- Only major challenge is that there is no one source of information about the utilization of each card. You need to extract this information from every system that is sharing that card and sum across all systems
- RMF in z/OS 2.2 added the ability to display a subset of zEDC information using Monitor III (Option 3.14 PCIE)
- The PCIE Activity display for RMF Hardware Accelerator and Compression Activity provides much more useful info
- - Note that all the info only relates to this LPAR’s use of the card

• Other Monitoring Information for zEDC
- All the information in the Monitor III display (both primary panel and the cursor-sensitive field display) is also available using the RMF Overview reports function – see section “PCIE Function Activity - SMF record type 74-9” in the RMF User’s Guide
- The collection of PCIE data by RMF is controlled by the PCIE keyword in ERBRMF04 member – it is ENabled by default
- How do you know when you need more zEDC capacity?
- - The zEDC card works on a simple round robin polling mechanism, checking each LPAR it is connected to, to see if they have any work for it
- - - If no work, it tries the next LPAR
- - - As the card utilization increases, the interval between when it polls each LPAR gets larger, potentially resulting in queueing for longer in the z/OS images
- - - - The queue time is reported in the RMF PCIE report (“Request Queue Time”)
- - - - Unlike zIIPs, there is no overflow to general purpose CPs – if the card is overloaded, users of its services will simply observe longer queue times
- - So, the point at which you need more zEDC capacity is determined by how much queue time you are willing to tolerate
- - - Queue time is determined by normal queue time formula. With more ‘servers’ (more zEDC cards), you can run at higher utilizations before queue time increases
- As part of APAR OA42195, the SMF Type 14/15 records have new flags and fields related to zEDC:
- - Offsets Name Length Format Description
- - 6 (6) SMF14CDL 8 binary Number of bytes of compressed data read or written since this open
- - 14 (E) SMF14UDL 8 binary Number of bytes of data read or written since this open (data length prior to compression)
- - 22 (16) SMF14CDS 8 binary Size of the compressed format data set (number of compressed user data bytes)
- - 30 (1E) SMF14UDS 8 binary Size of the compressed format data set (number of uncompressed user data bytes)
- - 80 (50) SMF14CMPTYPE 1 binary Compression Type
- - - Meaning When Set
- - - 0 SMF14CMPTYPENA Not compressed format or Unknown
- - - 1 SMF14CMPTYPEGEN Generic Compression
- - - 2 SMF14CMPTYPETLRD Tailored Compression
- - - 3 SMF14CMPTYPEZEDC zEDC Compression
- Information is also held in the data set’s catalog entry
- - ACT-DIC-TOKEN X'6001... indicates that the data was compressed using zEDC
- - User-Data-Size statistics shows original and compressed number of bytes used to calculate the compression ratio
- This info is also in DCOLLECT
- For information about SMF use of zEDC, refer to 2 new fields in the Type 23 records:
- - SMF23BBC Original (before compression) number of bytes written to this log stream in this interval
- - SMF23BAC zEDC compressed bytes total written to this log stream in this interval
- These fields are in the base in z/OS 2.2, and delivered by APAR OA47917 in z/OS 2.1
- - NOTE: This APAR also exploits enhancements in zEDC microcode that result in better compression ratios for SMF data.

• zEDC Hardware and Software Prerequisites
- zEDC cards are available on zEC12, zBC12, z13, and later
- - Up to 8 cards per CPC, 2 per PCIe drawer
- - Max of 15 LPARs per card
- Exploitation requires z/OS 2.1 or later
- - Ability to read zEDC-compressed files using software decompression is available on z/OS 1.13 and later
- - Requires support (appropriate releases or PTFs) in the exploiters that you want to use as well
- - Make sure that you monitor the IBM.FUNCTION.zEDC FIXCAT for required PTFs
- Using software to decompress data that was compressed using zEDC is EXTREMELY CPU intensive and should only be used in exceptional situations
- Data sets compressed using BSAM/QSAM zEDC support must be SMS managed
- - Data class should specify zEDC Preferred or zEDC Required
- - Data sets compressed with traditional DFSMS compression also must be SMS managed

• Summary
- Initial take-up of zEDC was slow because you must have zEC12 or later and z/OS 2.1 or later AND you want those on every system that will share the data, and it is only now that those configurations are becoming common
- Customer experiences so far have been very positive. One customer described zEDC as ‘a game changer’
- Download and run zBNA – it has many uses in addition to planning for zEDC, so everyone should have it anyway
- Once the hardware and software are in place, the implementation of zEDC is simple
- Recommend to start with SMF, then move on to DFSMSdss and HSM, and then all large sequential data sets
- Tell anyone that is responsible for large file transfers to and from z/OS about the benefits they might be able to get from zEDC

• zEDC Reference Information
- IBM Redbook SG24-8259, Reduce Storage Occupancy and Increase Operations Efficiency with IBM zEnterprise Data Compression
- IBM RedPaper, REDP-5158, zEDC Compression: DFSMShsm Sample Implementation
- z/OSMF Workflow IBM: z/OS V2R1 zEnterprise® Data Compression Setup Workflow
- zEDC Product Manual SA23-1377, z/OS MVS Programming: Callable Services for High-Level Languages
- IBM Manual SA23-1380, z/OS MVS Initialization and Tuning Reference
- IBM Hot Topics August 2014, Save BIG with QSAM/BSAM compression by using zEDC and All aboard with zEDC
- IBM Hot Topics August 2013, z Enterprise Data Compression Express
- IBM Journal of R&D, Volume 59, Number 4/5, July/Sep. 2015, Integrated high-performance data compression in the IBM z13
- For a list of zEDC articles created by its lead designer, refer to https://www.linkedin.com/pub/anthony-sofia/4/6aa/713
- Multiple excellent SHARE presentations by Anthony Sofia, Barbara McDonald, Cecilia Lewis, and Glenn Wilcock

• Contact info
Frank Kyne
Editor and Technical Consultant
Watson and Walker
frank@watsonwalker.com
Phone 1-845-309-2956
http://www.watsonwalker.com


• The presentation and meeting ended about 8:30 P.M.