VSAM Demystified
VSAM Demystified
VSAM Demystified
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>VSAM</strong> <strong>Demystified</strong> stified<br />
Learn the latest <strong>VSAM</strong> functions and<br />
manage <strong>VSAM</strong> data<br />
Understand, evaluate, and use<br />
<strong>VSAM</strong> properly<br />
Problem determination<br />
and recommendations<br />
ibm.com/redbooks<br />
Front cover<br />
Dave Lovelace<br />
Rama Ayyar<br />
Alvaro Sala<br />
Valeria Sokal
International Technical Support Organization<br />
<strong>VSAM</strong> <strong>Demystified</strong><br />
September 2003<br />
SG24-6105-01
Note: Before using this information and the product it supports, read the information in<br />
“Notices” on page xix.<br />
Second Edition (September 2003)<br />
This edition applies to Version 1, Release 4 of z/OS (product number 5694-A01) and z/OS V1<br />
DFSMS Transactional <strong>VSAM</strong> Services (feature number 6330).<br />
© Copyright International Business Machines Corporation 2001, 2003. All rights reserved.<br />
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP<br />
Schedule Contract with IBM Corp.
Contents<br />
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii<br />
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii<br />
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix<br />
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx<br />
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi<br />
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi<br />
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii<br />
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii<br />
Chapter 1. <strong>VSAM</strong> basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
1.1 A brief description of <strong>VSAM</strong> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />
1.2 <strong>VSAM</strong> functions by release level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />
1.3 What is <strong>VSAM</strong>? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
1.3.1 <strong>VSAM</strong> access types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
1.4 Major <strong>VSAM</strong> parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
1.4.1 Catalog management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
1.4.2 Record management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
1.5 <strong>VSAM</strong> terminology and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
1.5.1 Logical record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
1.5.2 Key field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
1.5.3 Ways to identify logical records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
1.5.4 Physical record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
1.5.5 Control interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
1.5.6 Control area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
1.5.7 Spanned records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
1.5.8 Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
1.5.9 Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
1.5.10 Sphere. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
1.5.11 Alternate indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
1.5.12 Splits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
1.5.13 <strong>VSAM</strong> buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
1.6 <strong>VSAM</strong> data set organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
1.6.1 Key-sequenced data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
1.6.2 Entry sequenced data set (ESDS) . . . . . . . . . . . . . . . . . . . . . . . . . . 19<br />
1.6.3 Relative record data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
1.6.4 Variable relative record data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. iii
iv <strong>VSAM</strong> <strong>Demystified</strong><br />
1.6.5 Linear data set (LDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
1.7 Comparing <strong>VSAM</strong> data set organizations . . . . . . . . . . . . . . . . . . . . . . . . . 24<br />
1.8 Choosing a <strong>VSAM</strong> data set type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />
1.9 Extended format data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28<br />
1.10 Extended addressability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
1.11 Data striping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
1.12 Processing a <strong>VSAM</strong> cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
1.12.1 Allocating a <strong>VSAM</strong> cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
1.12.2 Accessing <strong>VSAM</strong> cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
1.12.3 Unallocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
1.13 <strong>VSAM</strong> exploiters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
1.13.1 DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
1.13.2 Hierarchical file system (HFS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
1.13.3 zSeries File System (zFS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
1.13.4 CICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40<br />
1.13.5 DFSMShsm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40<br />
1.13.6 DFSMSrmm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40<br />
1.13.7 Java Record I/O (JRIO). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40<br />
Chapter 2. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
2.1 Service level agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44<br />
2.2 Transaction performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44<br />
2.3 Performance management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46<br />
2.3.1 I/O performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46<br />
2.4 <strong>VSAM</strong> performance management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47<br />
2.5 <strong>VSAM</strong> rule-of-thumb mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
2.5.1 Invalid rules-of-thumb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
2.6 Parameters affecting performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49<br />
2.6.1 Allocation units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49<br />
2.6.2 Guaranteed Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50<br />
2.6.3 Optimizing control area (CA) size . . . . . . . . . . . . . . . . . . . . . . . . . . . 52<br />
2.6.4 Partial release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53<br />
2.6.5 Allocation constraint relief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
2.6.6 Control interval size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
2.6.7 FREESPACE definition for KSDS and ESDS . . . . . . . . . . . . . . . . . . 56<br />
2.6.8 Index options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
2.6.9 Key Range and Ordered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
2.6.10 Share options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
2.6.11 Initial load option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59<br />
2.6.12 Region size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
2.6.13 Buffering options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
2.6.14 Buffering techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68<br />
2.6.15 Data compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
2.6.16 <strong>VSAM</strong> Data striping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103<br />
2.7 <strong>VSAM</strong> performance by scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115<br />
2.7.1 Performance scenario using RMF reports . . . . . . . . . . . . . . . . . . . 115<br />
2.7.2 Reducing the number of I/Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119<br />
2.7.3 I/O wait time (IOSQ) for <strong>VSAM</strong> data sets . . . . . . . . . . . . . . . . . . . . 125<br />
2.7.4 I/O service time (connect) for <strong>VSAM</strong> data sets . . . . . . . . . . . . . . . . 129<br />
2.7.5 Decreasing <strong>VSAM</strong> CPU time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132<br />
2.8 <strong>VSAM</strong> and ESS controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134<br />
2.8.1 ESS model 800 enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 134<br />
2.8.2 Lab experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135<br />
2.9 Performance monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136<br />
2.9.1 Resource measurement facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . 136<br />
2.9.2 Tivoli Decision Support (TDS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137<br />
2.9.3 Generalized Trace Facility (GTF) . . . . . . . . . . . . . . . . . . . . . . . . . . 137<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery . . . . . . . . . . . . . 139<br />
3.1 <strong>VSAM</strong> problem determination hints and tips . . . . . . . . . . . . . . . . . . . . . . 140<br />
3.1.1 How to check your <strong>VSAM</strong> data set . . . . . . . . . . . . . . . . . . . . . . . . . 140<br />
3.1.2 z/OS system messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141<br />
3.1.3 Catalog Search Interface IGGCSIVS program . . . . . . . . . . . . . . . . 141<br />
3.1.4 System LOGREC messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142<br />
3.1.5 GTF CCW traces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142<br />
3.1.6 DITTO/ESA output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142<br />
3.1.7 What can you get from the SMF records? . . . . . . . . . . . . . . . . . . . 142<br />
3.2 Some common <strong>VSAM</strong> problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142<br />
3.2.1 Lack of virtual storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143<br />
3.2.2 Initial loading problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144<br />
3.2.3 Mismatch between catalog and data set. . . . . . . . . . . . . . . . . . . . . 145<br />
3.2.4 Hardware errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147<br />
3.2.5 Bad data or bad channel program. . . . . . . . . . . . . . . . . . . . . . . . . . 149<br />
3.2.6 Structural damage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150<br />
3.2.7 Improper sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153<br />
3.2.8 Mismatch between catalog and VTOC . . . . . . . . . . . . . . . . . . . . . . 155<br />
3.2.9 <strong>VSAM</strong> does not produce expected output. . . . . . . . . . . . . . . . . . . . 155<br />
3.2.10 <strong>VSAM</strong> RLS problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156<br />
3.2.11 <strong>VSAM</strong> and DFSMStvs considerations. . . . . . . . . . . . . . . . . . . . . . 157<br />
3.2.12 OEM problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157<br />
3.2.13 Enqueue issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157<br />
3.2.14 Migration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159<br />
3.2.15 Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160<br />
3.2.16 Deadlocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160<br />
3.2.17 Beware of some <strong>VSAM</strong> restrictions. . . . . . . . . . . . . . . . . . . . . . . . 161<br />
3.3 What documentation to collect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162<br />
Contents v
vi <strong>VSAM</strong> <strong>Demystified</strong><br />
3.3.1 Catalog performance problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . 162<br />
3.3.2 <strong>VSAM</strong> RLS problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162<br />
3.3.3 IDCAMS problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163<br />
3.3.4 Broken <strong>VSAM</strong> data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163<br />
3.3.5 Broken catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164<br />
3.3.6 How to obtain <strong>VSAM</strong> record management trace?. . . . . . . . . . . . . . 164<br />
3.4 How to recover a damaged <strong>VSAM</strong> data set . . . . . . . . . . . . . . . . . . . . . . 165<br />
3.4.1 EXAMINE command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165<br />
3.4.2 DIAGNOSE command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166<br />
3.4.3 VERIFY command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166<br />
3.4.4 Broken Index scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169<br />
3.4.5 Abend task scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171<br />
3.4.6 Recovering damaged BCS entries . . . . . . . . . . . . . . . . . . . . . . . . . 172<br />
3.4.7 Recovering damaged VVDS entries . . . . . . . . . . . . . . . . . . . . . . . . 172<br />
3.5 Prevention is better than cure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173<br />
3.5.1 Back up your <strong>VSAM</strong> data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173<br />
3.5.2 Keep your system at current maintenance levels . . . . . . . . . . . . . . 178<br />
3.5.3 Use Resource Recovery Management Services (RRMS) . . . . . . . 178<br />
3.6 Where to look for more information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178<br />
3.6.1 IBM manuals and sources of relevant information . . . . . . . . . . . . . 178<br />
3.6.2 Information APARs from IBMLINK on <strong>VSAM</strong> problems . . . . . . . . . 179<br />
3.6.3 Information APARs on specific problems . . . . . . . . . . . . . . . . . . . . 179<br />
3.6.4 <strong>VSAM</strong> information on the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . 180<br />
3.7 IDC3009I message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181<br />
3.8 IDCAMS LISTCAT output fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187<br />
3.8.1 High used RBA value (HURBA) for KSDS . . . . . . . . . . . . . . . . . . . 192<br />
3.8.2 High allocated RBA value (HARBA) . . . . . . . . . . . . . . . . . . . . . . . . 193<br />
3.8.3 FREESPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193<br />
3.8.4 High key RBA/CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193<br />
3.8.5 High-level index RBA value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194<br />
3.8.6 Sequence set first RBA value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194<br />
3.8.7 Number of index levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194<br />
3.8.8 Time stamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194<br />
3.9 SMF record types related to <strong>VSAM</strong> data sets . . . . . . . . . . . . . . . . . . . . . 194<br />
3.9.1 SMF record type 60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194<br />
3.9.2 SMF record type 61. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195<br />
3.9.3 SMF record type 62. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195<br />
3.9.4 SMF record type 63. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195<br />
3.9.5 SMF record type 64. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196<br />
3.9.6 SMF record type 65. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197<br />
3.9.7 SMF record type 66. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197<br />
3.9.8 SMF record type 67. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198<br />
3.9.9 SMF record type 68. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
3.9.10 SMF record type 69. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199<br />
3.9.11 SMF record type 42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199<br />
3.10 RRMS and <strong>VSAM</strong> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets . . . . . . . . . . . . . . . . . . . . . . . 203<br />
4.1 Reorganization considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204<br />
4.1.1 CI/CA splits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204<br />
4.1.2 The loss of useful space in Data CA . . . . . . . . . . . . . . . . . . . . . . . . 204<br />
4.1.3 CI/CA splits causing free space increase . . . . . . . . . . . . . . . . . . . . 208<br />
4.2 New Index CI size calculation algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 208<br />
4.2.1 Analyze existing data sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210<br />
4.3 Sharing <strong>VSAM</strong> data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212<br />
4.3.1 Write and read integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215<br />
4.3.2 <strong>VSAM</strong> sharing mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216<br />
4.3.3 Sharing data in a single <strong>VSAM</strong> control block structure . . . . . . . . . . 218<br />
4.3.4 Sharing data with many <strong>VSAM</strong> control block structures . . . . . . . . . 223<br />
4.3.5 General share options: Considerations. . . . . . . . . . . . . . . . . . . . . . 226<br />
4.3.6 Protecting <strong>VSAM</strong> data set through DISP parameter . . . . . . . . . . . . 227<br />
4.4 Extended addressability (EA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228<br />
4.5 Catalog Search Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231<br />
4.5.1 CSI setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231<br />
4.6 Major sources of <strong>VSAM</strong> processing options . . . . . . . . . . . . . . . . . . . . . . 233<br />
4.6.1 ACB control block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235<br />
4.6.2 DD statement keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237<br />
4.6.3 Catalog BCS and VVDS entries . . . . . . . . . . . . . . . . . . . . . . . . . . . 237<br />
4.6.4 SMS constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237<br />
4.7 Media Manager, Open, Close, EOV in <strong>VSAM</strong>. . . . . . . . . . . . . . . . . . . . . 238<br />
4.7.1 OPEN macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239<br />
4.7.2 CLOSE macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239<br />
4.7.3 End-of-Volume (EOV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240<br />
4.8 <strong>VSAM</strong> and 64 bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240<br />
4.9 Special considerations for COBOL users and SMB . . . . . . . . . . . . . . . . 241<br />
4.9.1 COBOL users take note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . 243<br />
5.1 Introducing <strong>VSAM</strong> RLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244<br />
5.1.1 What is <strong>VSAM</strong> RLS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244<br />
5.1.2 Why RLS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244<br />
5.1.3 How does RLS work? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244<br />
5.1.4 RLS in a single system (monoplex). . . . . . . . . . . . . . . . . . . . . . . . . 245<br />
5.1.5 CICS and <strong>VSAM</strong> RLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246<br />
5.1.6 RLS restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249<br />
5.2 RLS terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250<br />
Contents vii
viii <strong>VSAM</strong> <strong>Demystified</strong><br />
5.3 Planning for RLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253<br />
5.3.1 Hardware requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253<br />
5.4 Implementing <strong>VSAM</strong> RLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253<br />
5.4.1 Define Sharing Control Data Set (SHCDS). . . . . . . . . . . . . . . . . . . 253<br />
5.4.2 Define CF cache structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256<br />
5.4.3 Define CF lock structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258<br />
5.4.4 SMS definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260<br />
5.4.5 Modifying the PARMLIB IGDSMSxx Member . . . . . . . . . . . . . . . . . 262<br />
5.4.6 Security definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263<br />
5.4.7 Using a <strong>VSAM</strong> sphere in RLS mode . . . . . . . . . . . . . . . . . . . . . . . . 264<br />
5.4.8 RLS Recoverable spheres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265<br />
5.5 RLS problem determination and recovery. . . . . . . . . . . . . . . . . . . . . . . . 266<br />
5.5.1 Problems with SHCDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266<br />
5.5.2 Problems with SMS<strong>VSAM</strong>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266<br />
5.5.3 Problems with locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266<br />
5.5.4 SHCDS FALLBACK procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267<br />
5.5.5 RLS rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267<br />
5.5.6 MVS commands for RLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268<br />
5.6 RLS enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278<br />
5.6.1 RLS/KSDS extended addressability . . . . . . . . . . . . . . . . . . . . . . . . 278<br />
5.6.2 <strong>VSAM</strong> RLS CF structure duplexing and rebuild . . . . . . . . . . . . . . . 278<br />
5.6.3 RLS CF caching enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . 280<br />
5.7 RLS performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282<br />
5.7.1 Factors affecting RLS data sharing performance . . . . . . . . . . . . . . 282<br />
5.7.2 CF access time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295<br />
5.7.3 RLS performance gains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297<br />
5.7.4 CICSPlex RLS performance comparison . . . . . . . . . . . . . . . . . . . . 299<br />
5.7.5 Batch RLS performance experiments and comparison. . . . . . . . . . 300<br />
5.7.6 RMF and <strong>VSAM</strong> RLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306<br />
5.7.7 MVS commands about RLS performance. . . . . . . . . . . . . . . . . . . . 320<br />
5.7.8 SMF records covering <strong>VSAM</strong> RLS . . . . . . . . . . . . . . . . . . . . . . . . . 321<br />
Chapter 6. DFSMStvs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323<br />
6.1 Introducing DFSMStvs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324<br />
6.2 Why DFSMStvs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324<br />
6.2.1 How to extend CICS availability . . . . . . . . . . . . . . . . . . . . . . . . . . . 324<br />
6.2.2 Reducing the batch window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325<br />
6.3 Some definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326<br />
6.3.1 Backward recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326<br />
6.3.2 Forward recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326<br />
6.3.3 Atomic updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326<br />
6.3.4 Unit of work and unit of recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . 327<br />
6.3.5 Two-phase commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
6.3.6 In-flight and in-doubt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329<br />
6.3.7 Repeatable read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329<br />
6.3.8 Recoverable data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330<br />
6.4 CICS support for recoverable <strong>VSAM</strong>. . . . . . . . . . . . . . . . . . . . . . . . . . . . 330<br />
6.5 DFSMStvs overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331<br />
6.5.1 The RLS connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332<br />
6.5.2 DFSMStvs locking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332<br />
6.5.3 DFSMStvs logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332<br />
6.5.4 Recovery coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335<br />
6.6 Our experiences with implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 337<br />
6.6.1 Define list structures in the CFRM policy . . . . . . . . . . . . . . . . . . . . 338<br />
6.6.2 Define the log structures and log streams in LOGR policy . . . . . . . 340<br />
6.6.3 Define SMS constructs for DFSMStvs . . . . . . . . . . . . . . . . . . . . . . 345<br />
6.7 DFSMStvs problem determination tips . . . . . . . . . . . . . . . . . . . . . . . . . . 345<br />
6.7.1 How to take a dump of the problem? . . . . . . . . . . . . . . . . . . . . . . . 346<br />
6.7.2 Classes of errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346<br />
6.7.3 Determining the Failing Module . . . . . . . . . . . . . . . . . . . . . . . . . . . 346<br />
6.7.4 Apparent batch job hangs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347<br />
6.7.5 Other hangs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347<br />
6.7.6 Quiescing a data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347<br />
6.7.7 Close/delete/rename of data set with inflight UR . . . . . . . . . . . . . . 348<br />
6.7.8 New and changed system level commands for DFSMStvs . . . . . . 348<br />
6.7.9 SET SMS and SETSMS commands . . . . . . . . . . . . . . . . . . . . . . . . 354<br />
6.7.10 VARY SMS command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354<br />
6.7.11 SYS1.PARMLIB changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355<br />
6.7.12 Changes to Job Control Language (JCL) . . . . . . . . . . . . . . . . . . . 358<br />
6.7.13 Changes to IDCAMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358<br />
6.7.14 Messages and codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361<br />
6.7.15 Macros that have been changed to support DFSMStvs . . . . . . . . 361<br />
Appendix A. Sample code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363<br />
JRIO API examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364<br />
Locate a record by key in keyed access record file . . . . . . . . . . . . . . . . . 364<br />
Position to a record in a random access record file . . . . . . . . . . . . . . . . . 364<br />
Read a record from a keyed access record file. . . . . . . . . . . . . . . . . . . . . 364<br />
Read a record from a random access record file . . . . . . . . . . . . . . . . . . . 365<br />
Update a record in a keyed access record file . . . . . . . . . . . . . . . . . . . . . 365<br />
Accessing the <strong>VSAM</strong> Shared Information (VSI) . . . . . . . . . . . . . . . . . . . . . . . 366<br />
Sample programs extract from SMF record type 64 . . . . . . . . . . . . . . . . . . . 367<br />
SMF64 sample code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367<br />
SMFLSR sample program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380<br />
REXX code to list compression ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384<br />
SMFRLS Sample program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387<br />
Contents ix
x <strong>VSAM</strong> <strong>Demystified</strong><br />
GTF procedure example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393<br />
Appendix B. Miscellaneous performance items. . . . . . . . . . . . . . . . . . . . 395<br />
Our test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396<br />
Hardware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396<br />
Software configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396<br />
General lab description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396<br />
What do we measure? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398<br />
RLS experiments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399<br />
DASD cache concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399<br />
Cache Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402<br />
Using cache modes in a non-SMS data set . . . . . . . . . . . . . . . . . . . . . . . 408<br />
Using cache in an SMS data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409<br />
Share options analogy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412<br />
Symptoms (messages) from a broken data set . . . . . . . . . . . . . . . . . . . . . . . 414<br />
IDCAMS EXAMINE messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420<br />
Appendix C. Catalog performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421<br />
Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422<br />
Enhanced Catalog Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422<br />
GRS configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422<br />
Diagnosing prolonged catalog ENQ times . . . . . . . . . . . . . . . . . . . . . . . . . . . 423<br />
LPAR considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425<br />
GRS environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426<br />
Catalog contention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428<br />
Appendix D. Information APARs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441<br />
II12927 - Documentation for <strong>VSAM</strong> problems . . . . . . . . . . . . . . . . . . . . . . . . 442<br />
II13326 - Common problems with SHCDS. . . . . . . . . . . . . . . . . . . . . . . . . . . 444<br />
BDC000010564 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451<br />
BDC000007033 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459<br />
II12603 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465<br />
II12243 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467<br />
BDC000022923 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468<br />
RTA000141603 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475<br />
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477<br />
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481<br />
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481<br />
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481<br />
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482<br />
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482<br />
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485<br />
Contents xi
xii <strong>VSAM</strong> <strong>Demystified</strong>
Figures<br />
1-1 3390/3380 Track Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
1-2 General format of a control interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
1-3 General format of a sequence set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
1-4 General format of an index set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
1-5 Components of a KSDS structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
1-6 Entry sequenced data set (ESDS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20<br />
1-7 General format of a relative record data set . . . . . . . . . . . . . . . . . . . . . 21<br />
1-8 Linear data set (LDS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
1-9 DEFINE command required parameters . . . . . . . . . . . . . . . . . . . . . . . . 32<br />
1-10 ISPF under TSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
1-11 AMS commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
1-12 DITTO selection panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
1-13 DITTO edit function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
1-14 <strong>VSAM</strong> edit panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
2-1 Response time components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45<br />
2-2 Data Class panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
2-3 <strong>VSAM</strong> message indicating too small a region size . . . . . . . . . . . . . . . . 62<br />
2-4 Address space layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62<br />
2-5 NSR buffering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70<br />
2-6 <strong>VSAM</strong> shared resources (LSR/GSR). . . . . . . . . . . . . . . . . . . . . . . . . . . 78<br />
2-7 CMS dictionary selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98<br />
2-8 ISMF Data Class display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100<br />
2-9 Striped <strong>VSAM</strong> data set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105<br />
2-10 Layering in <strong>VSAM</strong> data set striping . . . . . . . . . . . . . . . . . . . . . . . . . . . 106<br />
2-11 Sample JCL to create a striped data set . . . . . . . . . . . . . . . . . . . . . . . 107<br />
2-12 Sample content of KEYEDEXG data class . . . . . . . . . . . . . . . . . . . . . 108<br />
2-13 Sample content of STRIPE storage class . . . . . . . . . . . . . . . . . . . . . . 109<br />
2-14 Sample IDCAMS control statements and output for four stripes . . . . . 110<br />
2-15 Example of KEYEDEXT data class . . . . . . . . . . . . . . . . . . . . . . . . . . . 111<br />
2-16 Example of content of STRIPE storage class . . . . . . . . . . . . . . . . . . . 112<br />
2-17 Second example with five stripes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113<br />
2-18 RMF SYSSUM report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116<br />
2-19 RMF Enclave report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116<br />
2-20 Enclave Classification Data report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117<br />
2-21 Monitor III Device Delay report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118<br />
2-22 Monitor III DEVN report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118<br />
2-23 Monitor III DSNV report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119<br />
2-24 Hiperbatch example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. xiii
xiv <strong>VSAM</strong> <strong>Demystified</strong><br />
2-25 Volume Cache report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127<br />
3-1 JCL, program, message and catalog entry . . . . . . . . . . . . . . . . . . . . . 169<br />
3-2 IEC161I message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170<br />
3-3 IDC message in the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170<br />
3-4 Examine messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171<br />
3-5 Exporting KSDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174<br />
3-6 IMPORT of KSDS cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174<br />
4-1 Indexes of KSDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205<br />
4-2 HARBA, HURBA, and free space . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206<br />
4-3 Lost space in data CA due to Index CI size too small . . . . . . . . . . . . . 207<br />
4-4 Message due to index CI size too small . . . . . . . . . . . . . . . . . . . . . . . 209<br />
4-5 Sample output of the CISIZE tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211<br />
4-6 Job to download the CISIZE tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212<br />
4-7 Sharing <strong>VSAM</strong> data sets in the Parallel Sysplex . . . . . . . . . . . . . . . . . 214<br />
4-8 DATA CLASS DEFINE ISMF panel . . . . . . . . . . . . . . . . . . . . . . . . . . . 229<br />
5-1 RLS in Sysplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245<br />
5-2 RLS in Monoplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246<br />
5-3 CICS before <strong>VSAM</strong> RLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248<br />
5-4 CICS after <strong>VSAM</strong> RLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249<br />
5-5 An example of defining a CF lock structure . . . . . . . . . . . . . . . . . . . . . 258<br />
5-6 Displaying MAXSYSTEM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259<br />
5-7 CF cache set in Storage Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261<br />
5-8 Cache Set assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261<br />
5-9 SMS<strong>VSAM</strong> errors due to SHCDS access failure . . . . . . . . . . . . . . . . . 264<br />
5-10 MVS messages for a JOB using RLS . . . . . . . . . . . . . . . . . . . . . . . . . 265<br />
5-11 Display the lock structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269<br />
5-12 Display the lock structure (continued) . . . . . . . . . . . . . . . . . . . . . . . . . 270<br />
5-13 Sample output of D SMS,CFLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271<br />
5-14 Sample of CFCACHE display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272<br />
5-15 Sample output of D SMS,SHCDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273<br />
5-16 Output of D SMS,<strong>VSAM</strong>,ALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274<br />
5-17 Cross invalidation and locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288<br />
5-18 Example of two locks synonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290<br />
5-19 RLSLRU report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308<br />
5-20 RLSSDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309<br />
5-21 CF Usage Summary report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312<br />
5-22 CF Structure Activity report (IGWLOCK00) . . . . . . . . . . . . . . . . . . . . . 315<br />
5-23 CF Structure Activity report (RLS_CACHE). . . . . . . . . . . . . . . . . . . . . 317<br />
5-24 Subchannel Activity report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318<br />
5-25 CF to CF report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319<br />
5-26 XCF Activity report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320<br />
5-27 D SMS, CFLS command output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321<br />
5-28 Output from SMF64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
6-1 An atomic update example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327<br />
6-2 Unit of recovery examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328<br />
6-3 Sharing <strong>VSAM</strong> data through a CICS file owning region. . . . . . . . . . . . 331<br />
6-4 Merged forward recovery log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333<br />
6-5 Undo and redo logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335<br />
6-6 RRS as the sync point manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336<br />
6-7 Commit processing participants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337<br />
6-8 Define list structures in the CFRM policy for TVS . . . . . . . . . . . . . . . . 339<br />
6-9 Define the log structures and log streams for TVS . . . . . . . . . . . . . . . 341<br />
6-10 Define the log structures and log streams for TVS (cont) . . . . . . . . . . 342<br />
6-11 Define the log structures and log streams for TVS (cont) . . . . . . . . . . 343<br />
6-12 Sample JCL to define Log Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . 344<br />
6-13 DFSMStvs Sample RACF Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 345<br />
6-14 Output of D SMS, TRANS<strong>VSAM</strong>,ALL . . . . . . . . . . . . . . . . . . . . . . . . . 350<br />
6-15 Output of the D SMS,SHUNTED(ALL) command . . . . . . . . . . . . . . . . 351<br />
6-16 Output of D SMS,URID(ALL) cDFSMStvsommandDFSMStvs . . . . . . 352<br />
6-17 Output of D SMS,LOG(IGWTV063.IGWLOG.SYSLOG command . . . 353<br />
6-18 Output of the D SMS, DSNAME(dsn) commandDFSMStvs . . . . . . . . 353<br />
6-19 Modified Output from the D SMS,OPTIONS command . . . . . . . . . . . . 354<br />
6-20 Sample IFAPRDxx parmlib member to enable DFSMStvs . . . . . . . . . 355<br />
6-21 Sample SYS1.PARMLIB(IGDSMSxx) member . . . . . . . . . . . . . . . . . . 356<br />
B-1 DASD Activity Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400<br />
B-2 Types of writes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406<br />
B-3 Cache Subsystem Status report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408<br />
B-4 Cache activity report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408<br />
B-5 D SMS,CACHE output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411<br />
B-6 Sharing <strong>VSAM</strong> data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413<br />
C-1 RMF Monitor panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429<br />
C-2 RMF Monitor III Primary Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430<br />
C-3 RMF III Job Selection Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431<br />
C-4 ENQ / DEQ Main Menu Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433<br />
C-5 ENQ / DEQ Monitor: Major Name List Option . . . . . . . . . . . . . . . . . . . 434<br />
C-6 ENQ / DEQ Monitor: locating a major name . . . . . . . . . . . . . . . . . . . . 434<br />
C-7 ENQ / DEQ Monitor: Minor Name List . . . . . . . . . . . . . . . . . . . . . . . . . 435<br />
C-8 ENQ / DEQ Monitor: Jobname List . . . . . . . . . . . . . . . . . . . . . . . . . . . 435<br />
C-9 F CATALOG,REPORT, PERFORMANCE output . . . . . . . . . . . . . . . . 436<br />
C-10 F CATALOG Command in SDSF batch. . . . . . . . . . . . . . . . . . . . . . . . 437<br />
Figures xv
xvi <strong>VSAM</strong> <strong>Demystified</strong>
Tables<br />
1-1 <strong>VSAM</strong> functions by release level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />
1-2 Comparison of ESDS, KSDS, RRDS, VRRDS, and linear data sets. . . 25<br />
2-1 this table compares the RECOVERY and SPEED options . . . . . . . . . . 60<br />
2-2 Region JCL parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
2-3 Parameters affecting buffer allocation . . . . . . . . . . . . . . . . . . . . . . . . . . 65<br />
2-4 NSR: Read sequential varying the number of buffers. . . . . . . . . . . . . . 71<br />
2-5 NSR - Initial Load mode varying the number of buffers . . . . . . . . . . . . . 73<br />
2-6 NSR buffering with direct access; STRNO=1 . . . . . . . . . . . . . . . . . . . . 76<br />
2-7 Direct access: benefits of using SMB: Updates and insertions . . . . . . . 86<br />
2-8 Some effects of ACB’s MACRF and storage class BIAS parameters . . 86<br />
2-9 Initial load mode comparing SMB with no-SMB buffering . . . . . . . . . . . 87<br />
2-10 SMB: AIX support with Data Set Name Sharing (MACRF=DSN) . . . . . 88<br />
2-11 SMB: AIX support with DDname Sharing (MACRF=DDN) . . . . . . . . . . 89<br />
2-12 SMB: AIX support for DO, no <strong>VSAM</strong> control block structures . . . . . . . . 91<br />
2-13 SMB: AIX support for non DO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91<br />
2-14 Comparing compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101<br />
2-15 Random processing: extended format versus non-extended format . . 131<br />
2-16 NSR: Read sequential varying the number of buffers . . . . . . . . . . . . . 133<br />
2-17 Direct access: benefits of using SMB: Reads and insertions. . . . . . . . 133<br />
2-18 Direct access: benefits of using SMB: Reads . . . . . . . . . . . . . . . . . . . 134<br />
2-19 Comparison initial load with ESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135<br />
2-20 Comparison Direct access with ESS . . . . . . . . . . . . . . . . . . . . . . . . . . 136<br />
3-1 IDC3009I message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181<br />
4-1 One <strong>VSAM</strong> Control Block Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 219<br />
4-2 Relationship between share options and <strong>VSAM</strong> functions . . . . . . . . . 227<br />
4-3 <strong>VSAM</strong> Data Set Parameters and Processing Options . . . . . . . . . . . . . 233<br />
5-1 Batch RLS results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. xvii
xviii <strong>VSAM</strong> <strong>Demystified</strong>
Notices<br />
This information was developed for products and services offered in the U.S.A.<br />
IBM may not offer the products, services, or features discussed in this document in other countries. Consult<br />
your local IBM representative for information on the products and services currently available in your area.<br />
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM<br />
product, program, or service may be used. Any functionally equivalent product, program, or service that<br />
does not infringe any IBM intellectual property right may be used instead. However, it is the user's<br />
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.<br />
IBM may have patents or pending patent applications covering subject matter described in this document.<br />
The furnishing of this document does not give you any license to these patents. You can send license<br />
inquiries, in writing, to:<br />
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.<br />
The following paragraph does not apply to the United Kingdom or any other country where such provisions<br />
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES<br />
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,<br />
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,<br />
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer<br />
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.<br />
This information could include technical inaccuracies or typographical errors. Changes are periodically made<br />
to the information herein; these changes will be incorporated in new editions of the publication. IBM may<br />
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at<br />
any time without notice.<br />
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any<br />
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the<br />
materials for this IBM product and use of those Web sites is at your own risk.<br />
IBM may use or distribute any of the information you supply in any way it believes appropriate without<br />
incurring any obligation to you.<br />
Information concerning non-IBM products was obtained from the suppliers of those products, their published<br />
announcements or other publicly available sources. IBM has not tested those products and cannot confirm<br />
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on<br />
the capabilities of non-IBM products should be addressed to the suppliers of those products.<br />
This information contains examples of data and reports used in daily business operations. To illustrate them<br />
as completely as possible, the examples include the names of individuals, companies, brands, and products.<br />
All of these names are fictitious and any similarity to the names and addresses used by an actual business<br />
enterprise is entirely coincidental.<br />
COPYRIGHT LICENSE:<br />
This information contains sample application programs in source language, which illustrates programming<br />
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in<br />
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application<br />
programs conforming to the application programming interface for the operating platform for which the<br />
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,<br />
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,<br />
modify, and distribute these sample programs in any form without payment to IBM for the purposes of<br />
developing, using, marketing, or distributing application programs conforming to IBM's application<br />
programming interfaces.<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. xix
Trademarks<br />
The following terms are trademarks of the International Business Machines Corporation in the United States,<br />
other countries, or both:<br />
AIX®<br />
CICS®<br />
CICSPlex®<br />
DB2®<br />
DFSMS/MVS®<br />
DFSMSdfp<br />
DFSMSdss<br />
DFSMShsm<br />
DFSMSrmm<br />
DFSORT<br />
^<br />
Enterprise Storage Server®<br />
ECKD<br />
xx <strong>VSAM</strong> <strong>Demystified</strong><br />
ESCON®<br />
FICON<br />
Hiperbatch<br />
Hiperspace<br />
IBM®<br />
ibm.com®<br />
IMS<br />
Language Environment®<br />
MQSeries®<br />
MVS<br />
OS/390®<br />
Parallel Sysplex®<br />
PR/SM<br />
The following terms are trademarks of other companies:<br />
Redbooks<br />
Redbooks (logo) <br />
RACF®<br />
RMF<br />
S/390®<br />
System/390®<br />
Tivoli®<br />
VTAM®<br />
z/Architecture<br />
z/OS®<br />
zSeries®<br />
Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other<br />
countries, or both.<br />
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the<br />
United States, other countries, or both.<br />
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun<br />
Microsystems, Inc. in the United States, other countries, or both.<br />
UNIX is a registered trademark of The Open Group in the United States and other countries.<br />
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure<br />
Electronic Transaction LLC.<br />
Other company, product, and service names may be trademarks or service marks of others.
Preface<br />
Virtual Storage Access Method (<strong>VSAM</strong>) is one of the access methods used to<br />
process data. Many of us have used <strong>VSAM</strong> and work with <strong>VSAM</strong> data sets daily,<br />
but exactly how it works and why we use it instead of another access method is a<br />
mystery.<br />
This book helps to demystify <strong>VSAM</strong> and gives you the information necessary to<br />
understand, evaluate, and use <strong>VSAM</strong> properly. It clarifies <strong>VSAM</strong> functions for<br />
application programmers who work with <strong>VSAM</strong>. The practical, straightforward<br />
approach should dispel much of the complexity associated with <strong>VSAM</strong>. Wherever<br />
possible an example is used to reinforce a description of a <strong>VSAM</strong> function.<br />
This IBM® Redbook is intended as a supplement to existing product manuals. It<br />
is intended to be used as an initial point of reference for <strong>VSAM</strong> functions.<br />
This book also builds upon the subject of Record Level Sharing and the new<br />
z/OS® feature called DFSMStvs.<br />
The team that wrote this redbook<br />
This redbook was produced by a team of specialists from around the world<br />
working at the International Technical Support Organization, San Jose Center.<br />
Dave Lovelace is a Project Leader at the International Technical Support<br />
Organization, San Jose Center. Before joining the ITSO this year, Dave worked in<br />
the IBM Storage Systems Group as Program Director of Business Development<br />
and Strategic Alliances. With more than 30 years in the IT industry, Dave has<br />
held positions as an IBM Systems Engineer, an MVS Systems Programmer, a<br />
Marketing Support Representative in OS/390® marketing, Software Packaging<br />
(CBIPO) and several years working in client/server environments with the US<br />
Military Academy at West Point.<br />
Rama Ayyar is a Senior IT Specialist with the IBM Support Center in Sydney,<br />
Australia. Rama has over 20 years of experience with the MVS operating system<br />
and has been in the Computer industry for over 30 years. His areas of expertise<br />
include TCP/IP, RACF®, DFSMS, configuration management, dump analysis and<br />
disaster recovery. Rama holds a master’s degree in Computer Science from the<br />
Indian Institute of Technology, Kanpur.<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. xxi
xxii <strong>VSAM</strong> <strong>Demystified</strong><br />
Alvaro Sala is an IBM retiree. He worked in IBM for more than 30 years, always<br />
in large systems. Alvaro co-authored many Redbooks and spent many years<br />
teaching, from S/360 to S/390®. He has a Chemistry Engineer degree from the<br />
University of Sao Paulo, Brazil.<br />
Valeria Sokal is a Business Partner from Brazil. She has 12 years experience as<br />
an OS/390 System Programmer. She co-authored these Redbooks: OS/390<br />
Workload Manager Exploitation and Implementation and ABC’s for OS/390<br />
System Programmers.<br />
Thanks to the following people for their invaluable contributions to this project:<br />
Mary Lovelace<br />
ITSO, San Jose<br />
Savur Rao<br />
Terri Menendez<br />
Helen Witter<br />
Ruth Ferziger<br />
James Becker<br />
Storage Systems Group, San Jose<br />
Charlie Burger<br />
Advanced Technical Systems Center, San Jose<br />
Bob Haimowitz<br />
International Technical Support Organization, Raleigh<br />
Paul Rogers<br />
International Technical Support Organization, Poughkeepsie<br />
Become a published author<br />
Join us for a two- to six-week residency program! Help write an IBM Redbook<br />
dealing with specific products or solutions, while getting hands-on experience<br />
with leading-edge technologies. You'll team with IBM technical professionals,<br />
Business Partners and/or customers.<br />
Your efforts will help increase product acceptance and customer satisfaction. As<br />
a bonus, you'll develop a network of contacts in IBM development labs, and<br />
increase your productivity and marketability.<br />
Find out more about the residency program, browse the residency index, and<br />
apply online at:<br />
ibm.com/redbooks/residencies.html
Comments welcome<br />
Your comments are important to us!<br />
We want our Redbooks to be as helpful as possible. Send us your comments<br />
about this or other Redbooks in one of the following ways:<br />
► Use the online Contact us review redbook form found at:<br />
ibm.com/redbooks<br />
► Send your comments in an Internet note to:<br />
redbook@us.ibm.com<br />
► Mail your comments to:<br />
IBM Corporation, International Technical Support Organization<br />
Dept. QXXE Building 80-E2<br />
650 Harry Road<br />
San Jose, California 95120-6099<br />
Preface xxiii
xxiv <strong>VSAM</strong> <strong>Demystified</strong>
Chapter 1. <strong>VSAM</strong> basics<br />
1<br />
This chapter reviews the concepts and terminology associated with <strong>VSAM</strong>,<br />
explains how a <strong>VSAM</strong> data set is different from other data set types, discusses<br />
the various types of <strong>VSAM</strong> data sets, and what makes them unique, and<br />
describes how <strong>VSAM</strong> data is stored and accessed.<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 1
1.1 A brief description of <strong>VSAM</strong><br />
2 <strong>VSAM</strong> <strong>Demystified</strong><br />
In the early 1970s, <strong>VSAM</strong> (Virtual Sequential Access Method) was introduced by<br />
IBM as a collection of three data set organizations — sequential, indexed, and<br />
direct-access, together with the access methods and utilities to be used on the<br />
large scale IBM operating systems.<br />
The word virtual means only that <strong>VSAM</strong> was introduced at approximately the<br />
same time as the initial IBM virtual storage operating systems OS/VS1 and<br />
OS/VS2. Since then <strong>VSAM</strong> has been continually improved and enhanced.<br />
1.2 <strong>VSAM</strong> functions by release level<br />
Some recent improvements to <strong>VSAM</strong> are extended format and extended<br />
addressability which allows a data set to go beyond the 4 GB limitation, system<br />
managed buffering (SMB) for improved performance, data compression, data<br />
striping, record level sharing (RLS), and most recently, transactional <strong>VSAM</strong>.<br />
Table 1-1 shows the recent <strong>VSAM</strong> enhancements by DFSMS release level.<br />
Note: DFSMS/MVS® V1R5 was the last independent release. With z/OS<br />
V1R3, DFSMS became an integral component of z/OS. This book is written at<br />
the z/OS V1R4 DFSMS level.<br />
Table 1-1 <strong>VSAM</strong> functions by release level<br />
Function Available since Section described in<br />
Data compression for <strong>VSAM</strong> KSDS DFSMS/MVS V1 R2 “Data compression” on<br />
page 94<br />
Extended addressability for <strong>VSAM</strong><br />
KSDS<br />
DFSMS/MVS V1.R3 “Extended addressability<br />
(EA)” on page 228<br />
<strong>VSAM</strong> RLS DFSMS/MVS V1.R3 Chapter 5, “<strong>VSAM</strong> Record<br />
Level Sharing” on page 243<br />
RLS support of extended addressabiliy<br />
of <strong>VSAM</strong> KSDS<br />
DFSMS/MVS V1 R4 Chapter 5, “<strong>VSAM</strong> Record<br />
Level Sharing” on page 243<br />
SMB for <strong>VSAM</strong> KSDS DFSMS/MVS V1 R4 “System managed buffering<br />
(SMB)” on page 82<br />
Data striping for <strong>VSAM</strong> LDS through an<br />
SPE<br />
DFSMS/MVS V1 R5 “<strong>VSAM</strong> Data striping” on<br />
page 103
Function Available since Section described in<br />
Extended addressability for all <strong>VSAM</strong><br />
data sets<br />
Data striping and multi-layering for all<br />
<strong>VSAM</strong> data set<br />
Ignore DEFINE parameters IMBED,<br />
REPLICATE<br />
Ignore DEFINE parameters<br />
KEYRANGE, ORDERED<br />
DFSMS/MVS V1 R5 “Extended addressability<br />
(EA)” on page 228<br />
DFSMS/MVS V2 R10 “<strong>VSAM</strong> Data striping” on<br />
page 103<br />
z/OS V1R3 DFSMS “Index options” on page 58<br />
z/OS V1R3 DFSMS “Key Range and Ordered” on<br />
page 58<br />
SMB retry capability for DO access bias z/OS V1R3 DFSMS “System managed buffering<br />
(SMB)” on page 82<br />
SMB support for AIX® z/OS V1R3 DFSMS “SMB support for AIX” on<br />
page 87<br />
RLS cache CI size bigger than 4KB z/OS V1R3 DFSMS “RLS CF caching<br />
enhancements” on page 280<br />
<strong>VSAM</strong> data striping support for data<br />
sets with REUSE attribute<br />
RLS caching all or some of the data in a<br />
Coupling Facility cache structure<br />
Maximum Volume Count, vols added<br />
dynamically to a data set without<br />
manual intervention and taking down<br />
the application<br />
DFSMS Data Set Separation, to<br />
allocate data sets in distinct physical<br />
DASD controllers<br />
Real addresses greater than 2 GB<br />
available for all <strong>VSAM</strong> data sets<br />
Media Manager the unique <strong>VSAM</strong> I/O<br />
driver, exception for Improved Control<br />
Interval Processing (ICIP)<br />
RLS system-managed duplexing<br />
rebuild process<br />
z/OS V1R3 DFSMS “<strong>VSAM</strong> data striping topics”<br />
on page 103<br />
z/OS V1R3 DFSMS “RLS CF caching<br />
enhancements” on page 280<br />
DFSMS z/OS V1R3 “Implementing <strong>VSAM</strong> data<br />
striping” on page 106<br />
DFSMS z/OS V1R3 “I/O wait time (IOSQ) for<br />
<strong>VSAM</strong> data sets” on<br />
page 125<br />
z/OS V1R4 DFSMS “<strong>VSAM</strong> and 64 bits” on<br />
page 240<br />
DFSMS z/OS V1R4 v “What is <strong>VSAM</strong>?” on page 4<br />
z/OS V1R4 DFSMS “System-managed duplexing<br />
rebuild” on page 279<br />
RLS Coupling Facility duplexing z/OS V1R4 DFSMS “System-managed duplexing<br />
rebuild” on page 279<br />
Chapter 1. <strong>VSAM</strong> basics 3
Function Available since Section described in<br />
Dynamic Cache Reassignment z/OS V1R3 DFSMS “RLS CF caching<br />
enhancements” on page 280<br />
1.3 What is <strong>VSAM</strong>?<br />
4 <strong>VSAM</strong> <strong>Demystified</strong><br />
<strong>VSAM</strong> is one of several access methods in z/OS. It only applies to data stored in<br />
DASD devices. An access method is re-entrant code contained in DFSMSdfp,<br />
a component of the DFSMS z/OS product. This access method makes it easier<br />
for an application to execute an I/O operation (moving data between an I/O<br />
device and memory).<br />
1.3.1 <strong>VSAM</strong> access types<br />
There are three types of access in <strong>VSAM</strong>:<br />
► Random: This is also referred to as direct access. The logical record needs to<br />
be located by the use of a search argument coming from the application.<br />
There is no search argument connection between two consecutive logical<br />
record accesses.<br />
► Sequential: The entire file is processed (for Read or Write), one logical record<br />
after the other. The application does not need to provide any search<br />
argument. The access method can implement a Read look ahead technique<br />
to load logical records in the buffers not yet required by the application<br />
program.<br />
► Skip sequential: A combination of the two previous types of access. The<br />
application randomly provides one search argument and from the located<br />
logical record on, all records are processed sequentially. An example is<br />
sequentially processing all the customers of a bank branch office in a file that<br />
has all the customers of the bank.<br />
1.4 Major <strong>VSAM</strong> parts<br />
There are two major parts to <strong>VSAM</strong>, catalog management and record<br />
management.<br />
1.4.1 Catalog management<br />
<strong>VSAM</strong> maintains extensive information about data sets and direct access storage<br />
space in an integrated catalog facility (ICF) catalog. The catalog’s collection of
information about a data set defines that data set’s characteristics. All <strong>VSAM</strong> files<br />
must be defined in an ICF catalog.<br />
In this book, we will not go into detail on Catalog Management. For more<br />
information, refer to the IBM Redbooks Enhanced Catalog Sharing and<br />
Management, SG24-5594, and Integrated Catalog Facility Backup and<br />
Recovery, SG24-5644.<br />
1.4.2 Record management<br />
The record management part of <strong>VSAM</strong> contains the access method code. In this<br />
book, when we say <strong>VSAM</strong> we mean <strong>VSAM</strong> record management, unless the<br />
opposite is stated. <strong>VSAM</strong> is used to organize records into four types of data sets:<br />
key-sequenced, entry-sequenced, linear, or relative record. The primary<br />
difference between the types of <strong>VSAM</strong> data sets is the way their records are<br />
stored and accessed.<br />
1.5 <strong>VSAM</strong> terminology and concepts<br />
1.5.1 Logical record<br />
Before we discuss <strong>VSAM</strong> in detail, we need to review some <strong>VSAM</strong> concepts<br />
implemented by <strong>VSAM</strong> constructs. These concepts will be used throughout the<br />
book. We are going to start with the smallest <strong>VSAM</strong> entity, the logical record, to<br />
the largest <strong>VSAM</strong> entity, the sphere. After that we cover splits, buffering, control<br />
blocks and other constructs.<br />
A logical record is a unit of information used to store data in a <strong>VSAM</strong> data set. It<br />
is made up of a set of bytes containing a logical description of an item processed<br />
by an application program. This item can be a customer with all his or her<br />
information, or an employee with all associated data (name, serial number,<br />
department).<br />
The logical record is designed by the application programmer from the business<br />
model. The logical record is divided in fields, such as: the name of the item, its<br />
key, the address, and the account information. The application through a GET<br />
request that a specific logical record be moved from the I/O device to memory in<br />
order to be processed. Through a PUT the specific logical record is moved from<br />
memory to an I/O device.<br />
A logical record can be of a fixed size or a variable size depending on the<br />
business requirements. <strong>VSAM</strong> supports both depending on the specific<br />
organization. An example of a variable logical record could be the account<br />
Chapter 1. <strong>VSAM</strong> basics 5
1.5.2 Key field<br />
6 <strong>VSAM</strong> <strong>Demystified</strong><br />
information about a bank customer where all debit and credit transactions are<br />
individually described at the end of the register.<br />
An important field in the logical record is the key. Its contents can be used to<br />
retrieve the specific logical record. It identifies the item associated with the<br />
logical record. Keys can be the customer number or the parts number.<br />
To differentiate between keys used in <strong>VSAM</strong> objects, the key used in a base<br />
cluster is called a primary key or base key. The key used in an alternate index<br />
is called an alternate key.<br />
In <strong>VSAM</strong> key sequenced organization, a record must have a unique,<br />
imbedded fixed-length primary key located in the same position within each<br />
logical record. Primary keys can be a minimum of one byte and a maximum of<br />
255 bytes.<br />
There can be multiple key fields in the same logical record, called alternate or<br />
secondary keys. Unlike the primary keys, which must be unique, identical<br />
alternate may occur in more than one logical record. This allows the search<br />
with a given alternate key to read all base cluster records containing this<br />
alternate key.<br />
1.5.3 Ways to identify logical records<br />
In <strong>VSAM</strong> there are three ways to identify a logical record:<br />
► Key field<br />
► Relative byte address (RBA)<br />
The RBA of a logical record is the offset of its first byte from the beginning of<br />
the file.<br />
Then, the first logical record in a <strong>VSAM</strong> file has an RBA of zero; the second<br />
logical record has an RBA equal to the length of the first record, and so on.<br />
<strong>VSAM</strong> returns to the application the RBA of the stored logical record. The<br />
RBA of a logical record in <strong>VSAM</strong> includes the free space and control<br />
information stored before this logical record.<br />
RBAs might change when records are added, deleted, or changed in size.<br />
With compressed files, the RBAs for compressed records are not predictable.<br />
Therefore, access by RBA is not suggested for normal use.<br />
There are two important RBA values, kept in the Catalog:<br />
– High used RBA (HURBA) is the RBA of the first available byte for inclusion<br />
at end of the <strong>VSAM</strong> file.<br />
– High allocated RBA (HARBA) is the RBA of the last byte in the <strong>VSAM</strong> file
1.5.4 Physical record<br />
► Relative Record Number (RRN)<br />
It is the relative number of a logical record in a <strong>VSAM</strong> specific organization<br />
(RRDS). If a logical record has an RRN of 3 means that it is the fourth logical<br />
record in the file.<br />
The terms logical record and record are used interchangeably in this book<br />
A physical record is device dependent, its size is calculated at the time the data<br />
set is defined. All physical records have the same length. A physical record is<br />
also called a physical block or simply a block.<br />
To understand what a physical record on DASD is, we need to review the<br />
3390/3380 count key data (CKD) track format. Every track starts with an index<br />
marker, a gap, a home address (describing the cylinder and track number) and a<br />
gap. After that, we have the physical records of the track. Refer to Figure 1-1.<br />
I<br />
M<br />
G<br />
A<br />
P<br />
Home<br />
Address<br />
CCHH<br />
G<br />
A<br />
P<br />
R 0<br />
Figure 1-1 3390/3380 Track Format<br />
8 64<br />
8<br />
Count<br />
Count<br />
CCHH<br />
R = 0<br />
DL = 64<br />
3390/3380<br />
Track Format<br />
G<br />
A<br />
P<br />
DATA<br />
A physical record is formed by a count, a gap, an optional key, a gap and the<br />
data. The key field is only present in non-indexed VTOC and partitioned data sets<br />
(PDS) directories. The count part indicates the number of the physical record in<br />
the track and its data length, which could be variable. The data is usually a set of<br />
G<br />
A<br />
P<br />
CCHH<br />
R = 1<br />
DL = 4KB<br />
R 1<br />
G<br />
A<br />
P<br />
4KB<br />
DATA<br />
Count<br />
CCHH<br />
R = 2<br />
DL = 4KB<br />
Chapter 1. <strong>VSAM</strong> basics 7
1.5.5 Control interval<br />
8 <strong>VSAM</strong> <strong>Demystified</strong><br />
logical records (packed together) transferred from or to memory by just one Read<br />
or Write CCW. The access method uses the BLKSIZE parameter to determine<br />
the length of the physical record. A large block size results in fewer gaps in the<br />
track (track capacity is better used) but larger buffer in memory to keep the data.<br />
Today actual 3390/3380 devices are becoming rare. The new controllers logically<br />
mimic fix block architecture (FBA) disks. You may ask the question “Do I care<br />
about the BLKSIZE to optimize space, if the 3390/3380 track does not really<br />
exist?” The answer is yes. The controller simulates the 3390/3380 track. It knows<br />
for an specific BLKSIZE how many physical records fit on the 3390/3380 track.<br />
So remember the rule-of-thumb (ROT) of a half track BLKSIZE (for sequential<br />
processing) to better utilize the 3390/3380 logical track capacity.<br />
There are two techniques for an access method create physical records:<br />
► First format it with zeroes and later fulfill the data portion with real data. This<br />
technique is used for random data creation or to create software end of files<br />
marks. These EOFs are data parts full of zeroes.<br />
► Format and fulfill with real data at same time. This technique is used for<br />
sequential data creation.<br />
<strong>VSAM</strong> may have control information along with logical records in the data portion<br />
of the physical record, as we see in the control interval <strong>VSAM</strong> concept.<br />
Control interval (CI) is a <strong>VSAM</strong> unique concept. A CI is formed by physical<br />
records, usually just one. It is the fundamental building block of every <strong>VSAM</strong> file.<br />
A CI is a contiguous area of direct access storage that <strong>VSAM</strong> uses to store data<br />
records and control information that describes the records. A CI is the unit of<br />
information that <strong>VSAM</strong> transfers between the storage device and the processor<br />
during one I/O operation. Whenever a record is retrieved from direct access<br />
storage, the entire CI containing the record is read into a <strong>VSAM</strong> I/O buffer in<br />
virtual storage. The desired record is transferred from the <strong>VSAM</strong> buffer to a<br />
user-defined buffer or work area.<br />
Based on the CI size, <strong>VSAM</strong> calculates the best size of the physical block in<br />
order to better use the 3390/3380 logical track. The CI size can be from 512 byes<br />
to 32 KB.<br />
The size of the physical record (block) is determined by <strong>VSAM</strong> based on the CI<br />
size, if the data set is in extended format or not (refer to 1.9, “Extended format<br />
data set” on page 28) and on the best use of space in the 3390/3380 track. For<br />
example in a 3390 without EF, with a CI Size of 22528 bytes, the block size is<br />
5632 bytes; with a CI Size of 24576, the block size is 24576 bytes.
For random access, it is recommended to use small data CIs, to avoid bringing<br />
uneeded logical records into memory. For sequential access, it is recommended<br />
that you define large CIs to decrease the number of I/O operations and the<br />
number of Read/Write CCWs.<br />
A CI consists of:<br />
► Logical records stored from beginning to end<br />
► Free space, for data records to be inserted into or lengthened<br />
► Control information, which is made up of two types of fields; one control<br />
interval definition field (CIDF) per CI, and several record definition fields<br />
(RDF) describing the logical records.<br />
– CIDF is a 4-byte field.<br />
– It contains information about the amount and location of free space.<br />
– RDF is a 3-byte field.<br />
– It describes the length of records. For fixed length records there are two<br />
RDFs, one with the length and other with how many with the same length.<br />
For more information on the structure of the control information fields, refer to<br />
DFSMS Using Data Sets, SC26-7410.<br />
Figure 1-2 shows the general format of a CI. The CI components and properties<br />
may vary depending on the data set organization. For example, an LDS does not<br />
contain CIDFs and RDFs in its CI. All of the bytes in the LDS CI are data bytes.<br />
Refer to 1.6, “<strong>VSAM</strong> data set organizations” on page 16, for more details.<br />
LR1 LR2 LRn<br />
Control Interval Format<br />
LR = Logical record<br />
RDF = Record definition field<br />
CIDF = Control interval definition field<br />
FREE SPACE<br />
Figure 1-2 General format of a control interval<br />
Control information fields<br />
The size of CIs can vary from one file to another, but all the CIs within the data<br />
component of a particular data set must be of the same length. Refer to 1.5.8,<br />
“Component” on page 10 for details on the data component.<br />
R<br />
D<br />
Fn<br />
R<br />
D<br />
F2<br />
R<br />
D<br />
F2<br />
C<br />
I<br />
D<br />
F<br />
Chapter 1. <strong>VSAM</strong> basics 9
1.5.6 Control area<br />
10 <strong>VSAM</strong> <strong>Demystified</strong><br />
You can request the CI size using the AMS DEFINE command, you can let<br />
<strong>VSAM</strong> determine the CI size, or you can specify an SMS data class, thereby<br />
using the CISIZE defined by your storage administrator.<br />
Control area (CA) is also a <strong>VSAM</strong> unique concept. A CA is formed by two or<br />
more CIs put together into fixed-length contiguous areas of direct access<br />
storage. A <strong>VSAM</strong> data set is composed of one or more CAs. In most cases, a CA<br />
is the size of a 3390/3380 cylinder. The minimum size of a CA is one track. The<br />
CA size is implicitly defined when you specify the size of a data set at data set<br />
definition.<br />
CAs are needed to implement the concept of splits. The size of a <strong>VSAM</strong> file is<br />
always a multiple of its CA. <strong>VSAM</strong> files are extended in units of CAs. A spanned<br />
record cannot be larger than a CA.<br />
1.5.7 Spanned records<br />
1.5.8 Component<br />
Spanned records are logical records that are larger than the CI size. To have<br />
spanned records, the file must be defined with the SPANNED attribute at the time<br />
it is created. Spanned records are allowed to extend across or span control<br />
interval boundaries. The RDFs describe whether the record is spanned or not.<br />
A spanned record must always begin on a control interval boundary and fills one<br />
or more control intervals within a single control area. A spanned record cannot<br />
share the CI with any other records. In other words, the free space at the end of<br />
the last segment is not filled with the next record. This free space can only be<br />
used to extend the spanned record.<br />
Spanned records are needed when the application requires very long logical<br />
records. A spanned record may be the data component of an AIX cluster. If<br />
spanned records are used for KSDS, the primary key must be within the first<br />
control interval. Refer to“Alternate indexes” on page 14.<br />
A component is an individual part of a <strong>VSAM</strong> data set. Each component has a<br />
name, an entry in the catalog and an entry in the VTOC. The KSDS and VRRDS<br />
organizations have data and index components. ESDS, RRDS and LDS<br />
organizations only have data components. A component can be multi-extent and<br />
multi-volume, however <strong>VSAM</strong> does not allow JCL concatenation between two<br />
<strong>VSAM</strong> components. You receive the IEC161I message with RC 68.
There are two types of components, the data component and the index<br />
component.<br />
Data component<br />
The data component is the part of a <strong>VSAM</strong> data set, alternate index, or catalog<br />
that contains the data records.<br />
Index component<br />
Using the index, <strong>VSAM</strong> is able to randomly retrieve a record from the data<br />
component when a request is made for a record with a certain key. The key<br />
determines the record’s position in the data set. <strong>VSAM</strong> divides the index CI into<br />
sections in order to speed up the search of a key.<br />
A <strong>VSAM</strong> index can consist of more than one level. Each level contains pointers to<br />
the next lower level.<br />
The index component is a collection of logical records containing data keys and<br />
the address (RBA) of the data logical records containing these keys. These data<br />
keys are taken from a fixed defined field in each data logical record. The keys in<br />
the index logical records are compressed (rear and front). The RBA pointers are<br />
compacted.<br />
Using the index, <strong>VSAM</strong> is now able to retrieve a logical record from the data<br />
component when a request is made with a certain key. A <strong>VSAM</strong> index can<br />
consist of more than one level (balanced tree). Each level contains pointers to<br />
the next lower level. Because there are random and sequential types of access<br />
<strong>VSAM</strong> divides the index into two parts: sequence set and index set.<br />
Sequence set<br />
The sequence set is used for sequential access.<br />
The sequence set is the lowest level of index CIs and directly points (through an<br />
RBA) to the data CI in the CA. There is one index entry per CI data and<br />
consequently one index CI for each data CA.<br />
Every logical record contains pointers and high key information for each data CI.<br />
It also contains horizontal pointers from one sequence set CI to the next higher<br />
keyed sequence set CI (see Figure 1-3). These horizontal pointers are needed<br />
because the possibility of splits, which make the physical sequence different from<br />
the logical collating sequence.<br />
Chapter 1. <strong>VSAM</strong> basics 11
12 <strong>VSAM</strong> <strong>Demystified</strong><br />
Sequence Set<br />
Figure 1-3 General format of a sequence set<br />
Control Interval<br />
Control Interval Control Interval<br />
Forward horizontal pointer at same level<br />
Vertical pointers to data control intervals<br />
one pointer for each control interval in control area<br />
determines minimum CI size for index<br />
Index Set<br />
Sequence Set<br />
Control Interval Control Interval Control Interval Control Interval<br />
Index set<br />
The index set is used for random access. The index set is the remainder of the<br />
index component. If there is more than one sequence set CI, <strong>VSAM</strong><br />
automatically builds another index CI in other level. Each CI in the index set<br />
contains pointers and high key information for CIs in the next lower level of the<br />
index. See Figure 1-4.
1.5.9 Cluster<br />
Index Set<br />
Figure 1-4 General format of an index set<br />
Control Interval<br />
Control Interval Control Interval<br />
The highest level of the index always contains a single index CI.<br />
Index Set<br />
Sequence Set<br />
Control Interval Control Interval Control Interval Control Interval<br />
Forward horizontal pointer at same level<br />
Vertical pointers to next lower level index<br />
records<br />
Just one CI in the top<br />
A cluster is a set of related components (maximum two). For a KSDS, a cluster is<br />
the set of a data component and an index component. The concept of cluster<br />
simplifies <strong>VSAM</strong> processing, providing a way to treat index and data components<br />
as a single entity, with its own catalogued name. You can also give each<br />
component a name. This allows you to process the data portion separately from<br />
the index portion.<br />
RRDS, ESDS, and LDS formats are considered to be clusters without index<br />
components. To be consistent, they are given cluster names that are normally<br />
used when processing the data set.<br />
Now comes the crucial <strong>VSAM</strong> question: “What in <strong>VSAM</strong> corresponds to an MVS<br />
data set?” The best answer is it depends. If you are referring to the cluster name<br />
(in a DD statement for example), then the cluster corresponds to the data set. If<br />
you are referring to a component, then it corresponds to the data set.<br />
Chapter 1. <strong>VSAM</strong> basics 13
1.5.10 Sphere<br />
14 <strong>VSAM</strong> <strong>Demystified</strong><br />
A sphere is a base <strong>VSAM</strong> cluster and its associated clusters. These associated<br />
clusters are the alternate indexes (AIXs) of the base cluster. An AIX is a KSDS<br />
cluster containing index entries in the index component organized by the<br />
alternate keys of its associated base data records. In the AIX data component<br />
there is a set of primary keys associated with the referred secondary key. Then,<br />
the concept of an sphere provides another way of locating records (by using<br />
other keys) in the data component of a cluster.<br />
An AIX can only be defined over a KSDS or ESDS clusters.<br />
1.5.11 Alternate indexes<br />
Alternate indexes (AIXs) allows logical records of a KSDS or of an ESDS (in this<br />
context called a base cluster) to be accessed sequentially and directly by more<br />
than one key field. AIXs eliminate the need to store the same data in different<br />
sequences in multiple data sets for the purposes of various applications. Each<br />
alternate index is a KSDS cluster consisting of an index component and a data<br />
component.<br />
Any field in the base cluster record can be used as an alternate key. It may also<br />
overlap the primary key (in a KSDS), or with any other alternate key. The same<br />
base cluster may have several AIXs varying the alternate key. The alternate key<br />
must follow all the key requirements as described in “Logical record” on page 5,<br />
with the exception of uniqueness. There may be more than one primary key<br />
value per the same alternate key value. As an example the primary key is an<br />
employee number and the alternate key is the department name, obviously the<br />
same department name may have several employee numbers.<br />
The records in the data component contain the alternate key value and all the<br />
primary keys corresponding to the alternate key value (pointers to data in the<br />
base cluster). The primary keys in the logical record are in ascending sequence<br />
within an alternate index value. If you have a large number of primary keys per<br />
alternate key, consider defining the AIX as spanned and compressed.<br />
The AMS program allows you to define, and then to create AIXs when the<br />
BLDINDEX command is specified. An AIX is defined only after its associated<br />
base cluster has been defined, and it can be built only after its base has been<br />
loaded with at least one record.<br />
The BLDINDEX command causes a sequential scan of the specified base<br />
cluster, during which alternate key values and primary keys (for a KSDS) or<br />
record RBAs (for an ESDS) are extracted and put together to form alternate<br />
index records. These records are sorted by ascending alternate keys. The<br />
alternate index records are then constructed and written.
1.5.12 Splits<br />
Alternate index paths<br />
Before accessing a KSDS or ESDS through an alternate index, a path must be<br />
defined. A path is the mean by which a base cluster is accessed through its<br />
alternate indices. A path is defined and named using the AMS DEFINE PATH<br />
command. At least one path must be defined for each of the alternate indices<br />
through which the base cluster is to be accessed. The path name refers to the<br />
base cluster and alternate index pair. When a program opens a path for<br />
processing, both the base cluster and the alternate index are opened. A base<br />
cluster plus all its AIXs is called a sphere.<br />
CI and CA splits occur as a result of data record insertions (or increasing the<br />
length of an already existing record) in KSDS and VRRDS organizations. If a<br />
record is to be inserted (in key sequence) and there is not enough free space in<br />
the CI, the CI is split. Approximately half of the records in the CI are transferred to<br />
a free CI provided in the CA, and the record to be inserted is placed in the<br />
original CI.<br />
If there are no free CIs in the CA and a record is to be inserted, a CA split occurs.<br />
Half of the CIs are sent to the first available CA at end of the data component.<br />
This movement creates free CIs in the original CA, then the record to be inserted<br />
causes a CI split.<br />
You should keep in mind that splits are not bad. Splits are how <strong>VSAM</strong> deals with<br />
a lack of space, and this generates free space that will help prevent additional<br />
splits.<br />
As a result of the split, the physical sequence of records and CIs is no longer the<br />
same as the logical sequence. A new index entry is inserted in the sequence set<br />
for the new CI, and the existing index entry is updated.<br />
Splits (mainly CA splits) consume resources when they occur. However, the fact<br />
that the data is spread in the 3390/3380 volume is no longer a performance<br />
issue. Refer to 2.5, “<strong>VSAM</strong> rule-of-thumb mode” on page 48.<br />
The number of CI and CA splits is maintained in the catalog.<br />
One example about splits is a real life situation where a customer had a KSDS<br />
loaded with just one record with key 0. First, a batch job added a few records with<br />
a very high numeric key. After the job randomly started adding lots of records<br />
with keys less than the ones inputted by batch. Thousands of splits took place<br />
affecting performance. The available solution was to run the job after the online<br />
and the number of splits went back to normal.<br />
Chapter 1. <strong>VSAM</strong> basics 15
1.5.13 <strong>VSAM</strong> buffering<br />
16 <strong>VSAM</strong> <strong>Demystified</strong><br />
Buffering is one of the key aspects as the I/O performance is concerned. A<br />
<strong>VSAM</strong> buffer is a virtual storage area where the CI is transferred during an I/O<br />
operation. In <strong>VSAM</strong> there are two types of buffers: buffers for data CIs and<br />
buffers for index CIs. A buffer pool is a set of buffers with the same size. A<br />
resource pool is a buffer pool with some control blocks describing the pool and<br />
the clusters with CIs in the resource pool. Refer to “Buffering options” on<br />
page 63, for details on <strong>VSAM</strong> buffering.<br />
1.6 <strong>VSAM</strong> data set organizations<br />
<strong>VSAM</strong> arranges records by index key, relative record number, or relative byte<br />
address. It is used for direct or sequential processing of fixed-length and variable<br />
length records on DASD. <strong>VSAM</strong> data is cataloged for easy retrieval. <strong>VSAM</strong><br />
supports five data set organizations:<br />
► Key-sequenced data set (KSDS)<br />
► Entry-sequenced data set (ESDS)<br />
► Relative record data set (RRDS), of which there are two types:<br />
Fixed-length relative record data set (RRDS)<br />
Variable-length relative record data set (VRRDS)<br />
► Linear data set (LDS)<br />
► HFS files<br />
1.6.1 Key-sequenced data set<br />
In a KSDS organization, records are initially loaded in the data component in<br />
ascending collating sequence by key. The key contains a unique value that<br />
determines that record's collating position in the data set.<br />
In <strong>VSAM</strong> KSDS, if a search argument of a logical record is its key field, then:<br />
► In all logical records, the key length must be the same. The length of the key<br />
must be from one byte to 255 bytes.<br />
► In all logical records the key offset (in relation to the logical record beginning)<br />
must be the same.<br />
► The value of the key field cannot be duplicated among the logical records, it<br />
must be unique.<br />
► After it is specified, the value of the key cannot be altered, however the entire<br />
record can be deleted.
► In a spanned record, this field must be located totally in the first control<br />
interval.<br />
Logical records in a KSDS organization can be fixed or variable length records.<br />
When a new record is added to the data component, it is inserted logically in its<br />
collating sequence by key. Refer to Figure 1-5 for the structure of a KSDS.<br />
KSDS Structure<br />
Control Interval Control Interval Control Interval Control Interval<br />
Control Interval<br />
Control Interval<br />
Control Interval<br />
Control Interval<br />
Control Interval<br />
Control Interval Control Interval<br />
C<br />
O A<br />
N R<br />
T E<br />
R A<br />
O<br />
L<br />
Figure 1-5 Components of a KSDS structure<br />
Index Set<br />
Cluster<br />
Sequence Set<br />
Index Component<br />
Data Component<br />
For <strong>VSAM</strong> organizations where the key field in a logical record is a search<br />
argument (as with the KSDS organization), a “balanced tree” index based in<br />
these key values needs to be created. Refer to the Figure 4-1 on page 205. The<br />
index has logical records (called index records) which allows a fast random<br />
search of a data logical record with a matching key value. In the index<br />
component. There is one logical record (with the highest key) for each CI of data,<br />
and a CI for each CA of data.<br />
KSDS types of access<br />
There are three methods by which to access a KSDS. These are sequential,<br />
direct, and skip-sequential.<br />
► Sequential access is used to load a KSDS, and to retrieve, update, add and<br />
delete records in an existing data set.<br />
Chapter 1. <strong>VSAM</strong> basics 17
18 <strong>VSAM</strong> <strong>Demystified</strong><br />
<strong>VSAM</strong> uses the index component to access data records in ascending or<br />
descending sequence by key. When retrieving records, you do not need to<br />
specify key values because <strong>VSAM</strong> automatically obtains the next logical<br />
record in key sequence. The sequence set (a low portion of the index) is used<br />
to find the next logical CI, through horizontal pointers.<br />
Sequential access allows you to avoid searching the index more than once.<br />
Sequential is faster than direct for accessing multiple data records in<br />
ascending key order. Problem is that many times the application logic does<br />
not need to process all of them.<br />
► Direct access is used to retrieve, update, add and delete records in an<br />
existing data set.<br />
The application program needs to supply a key value for each record to be<br />
processed. You can supply the full key or a generic key. The generic key is the<br />
high order portion of a full key. For example, you might want to retrieve all<br />
records whose keys begin with XY (where XY is the generic key), regardless<br />
of the full key value.<br />
<strong>VSAM</strong> searches the index from the highest level index set CI to the sequence<br />
set for a record to be accessed. Vertical pointers in the sequence set CI are<br />
used to access the data CA containing the record. The number of index CIs<br />
accessed is numerically identical to the number of layers.<br />
Direct access saves you a lot of I/O overhead by not retrieving the entire data<br />
set sequentially to process a small percentage of the total number of records.<br />
► Skip-sequential access is used to retrieve, update, add and delete records in<br />
an existing data set.<br />
<strong>VSAM</strong> retrieves selected records, but in ascending sequence of key values.<br />
Skip sequential access avoids:<br />
– Retrieving the entire data set sequentially in order to process a relatively<br />
small percentage of the total number of records in key collating sequence<br />
– Retrieving the desired records directly, which causes the index to be<br />
searched from top to bottom level for each record<br />
For each request the sequence set is used to find the next logical CI and to check<br />
if it contains the requested record. If the first skip-sequential search is the first<br />
access after opening the data set, a direct search is initiated by <strong>VSAM</strong> to find the<br />
first record. From then on the index sequence set level is used to find the<br />
subsequent records. If other operations were performed before (for example,<br />
read sequential), either the last position of that operation is used as a starting<br />
point to search the sequence set records, or a re-positioning is necessary. If<br />
spanned records are used for KSDS, the primary key must be within the first<br />
control interval.
You specify the KSDS organization using the IDCAMS DEFINE command with<br />
the INDEXED parameter.<br />
1.6.2 Entry sequenced data set (ESDS)<br />
An ESDS is comparable to a sequential non-<strong>VSAM</strong> data set in the sense that<br />
records are sequenced by the order of their entry in the data set, rather than by<br />
key field in the logical record, which could be fixed or variable length records.<br />
All new records are placed at the end of the data set. There is no split concept.<br />
Existing records can never be deleted. As far as <strong>VSAM</strong> is concerned, the record<br />
is not deleted. It is the responsibility of the application program to identify that<br />
record as invalid. If the application wants to delete a record, it must flag that<br />
record as inactive.<br />
Records can be updated, but without length change. To change the length of a<br />
record, you must either store it at the end of the data set as a new record, or<br />
override an existing record of the same length that you have flagged as inactive.<br />
ESDS types of access<br />
A record can be accessed sequentially or directly by its RBA. The specific RBA is<br />
converted to CCHHR terms, in order to prepare the locate record CCW for the<br />
I/O operation:<br />
► Sequential access<br />
<strong>VSAM</strong> automatically retrieves records in stored sequence. Sequential access<br />
can be started from the beginning or somewhere in the middle of a data set. If<br />
processing is to begin in the middle of a data set, RBA positioning is<br />
necessary before sequential access can be performed.<br />
► Direct (or random) access<br />
When a record is loaded or added, <strong>VSAM</strong> notes its RBA. To retrieve records<br />
directly, you must supply the RBA for the record as a search argument.<br />
Although an ESDS does not contain an index component, you can build an<br />
alternate index to keep track of these RBAs. Refer to “Alternate indexes” on<br />
page 14.<br />
Skip sequential access is not allowed for an ESDS. Refer to 1.6.1,<br />
“Key-sequenced data set” on page 16, for more information on skip sequential<br />
access.<br />
Figure 1-6 shows the format of an ESDS.<br />
Chapter 1. <strong>VSAM</strong> basics 19
20 <strong>VSAM</strong> <strong>Demystified</strong><br />
CI 1<br />
RBA 0<br />
CI 2<br />
RBA 4096<br />
CI 3<br />
RBA 8192<br />
CI 4<br />
RBA 12288<br />
RECORD<br />
1<br />
RECORD<br />
5<br />
RECORD<br />
9<br />
Entry Sequenced Data Set<br />
RECORD<br />
2<br />
RECORD<br />
6<br />
RECORD<br />
10<br />
RECORD<br />
3<br />
RECORD<br />
7<br />
UNUSED SPACE<br />
Figure 1-6 Entry sequenced data set (ESDS)<br />
RECORD<br />
4<br />
RECORD<br />
8<br />
UNUSED SPACE<br />
UNUSED SPACE<br />
UNUSED<br />
SPACE<br />
Empty spaces in the CI are referred to as unused space because they can never<br />
be used. This is a result of CI internal fragmentation.<br />
You specify ESDS organization using the IDCAMS DEFINE command and<br />
specifying the NONINDEXED parameter.<br />
AIX can also be applied to ESDS organization. Instead of radomly accessing an<br />
ESDS by RBA, you can ask for an AIX, where a key field in the logical record is<br />
used as a random search argument. In this case, the AIX (remember, it is a<br />
KSDS cluster) data component automatically relates the key with the RBA in the<br />
base cluster. The BLDINDEX command causes a sequential scan of the<br />
specified base cluster, during which key values and record RBAs are extracted<br />
and put together to form alternate index records. Before accessing an ESDS<br />
through an alternate index, a path must be defined.<br />
An example of ESDS with an AIX could be a file used as a time stamp log,<br />
describing all the bank transactions in a checking account application.<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F
1.6.3 Relative record data set<br />
An relative record data set consists of a number of pre-formatted fixed-length<br />
slots. Each slot has a unique relative record number (RRN), and the slots are<br />
sequenced by ascending relative record number. These slots are grouped in CIs.<br />
Each fixed length logical record occupies a slot, and is stored and retrieved by<br />
the relative record number of that slot. The position of a logical record is fixed<br />
and its relative record number (RRN) cannot change. The logical records are<br />
grouped in CIs.<br />
Because the slot can either contain data or be empty, a data record can be<br />
inserted or deleted without affecting the position of other data records in the<br />
RRDS organization. The RDF shows whether the slot is occupied or empty. Free<br />
space is not provided because the entire data set is divided into fixed-length<br />
slots. There may be empty spaces in the CI, referred to as unused space,<br />
because they can never be used. This is a result of CI internal fragmentation.<br />
Figure 1-7 shows the format of an RRDS.<br />
C<br />
O<br />
N<br />
A<br />
T<br />
R<br />
R<br />
E<br />
O<br />
A<br />
L<br />
C<br />
O<br />
N<br />
A<br />
T<br />
R<br />
R<br />
E<br />
O<br />
A<br />
L<br />
RELATIVE RECORD DATA SET (RRDS)<br />
CI 0<br />
CI 1<br />
CI 2<br />
CI 3<br />
CI 0<br />
CI 1<br />
CI 2<br />
CI 3<br />
SLOT 1<br />
SLOT 6<br />
SLOT 11<br />
SLOT 16<br />
SLOT 21<br />
SLOT 26<br />
SLOT 31<br />
SLOT 36<br />
SLOT 2 SLOT 3 SLOT 4 SLOT 5<br />
SLOT 7 SLOT 8 SLOT 9 SLOT 10<br />
SLOT 12 SLOT 13 SLOT 14 SLOT 15<br />
SLOT 17 SLOT 18 SLOT 19 SLOT 20<br />
SLOT 22 SLOT 23 SLOT 24 SLOT 25<br />
SLOT 27 SLOT 28 SLOT 29 SLOT 30<br />
SLOT 32 SLOT 33 SLOT 34 SLOT 35<br />
SLOT 37 SLOT 38 SLOT 39 SLOT 40<br />
Figure 1-7 General format of a relative record data set<br />
Chapter 1. <strong>VSAM</strong> basics 21<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
R<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F<br />
C<br />
I<br />
D<br />
F
22 <strong>VSAM</strong> <strong>Demystified</strong><br />
Typical RRDS processing<br />
The application program inputs the RRN of the target record and <strong>VSAM</strong> is able to<br />
find its location (using CCHHR format) quickly using a formula that takes into<br />
consideration the geometry of the DASD device. The relative record number is<br />
always used as a search argument.<br />
An RRDS can be processed sequentially, directly or skip-sequentially.<br />
► RRDS sequential access is treated the same way as ESDS sequential<br />
access. However, empty slots are automatically skipped by <strong>VSAM</strong>.<br />
► An RRDS can be processed directly by supplying the relative record number<br />
as a key. <strong>VSAM</strong> calculates the RBA and accesses the appropriate record or<br />
slot through CCHHR. RRDS direct address processing by supplying the RBA<br />
is not supported.<br />
► Skip-sequential access is treated like an RRDS direct processing request, but<br />
the position is maintained. After that, records must are processed in<br />
ascending relative record number sequence.<br />
You specify the RRDS organization using the IDCAMS DEFINE command with<br />
the NUMBERED option.<br />
1.6.4 Variable relative record data set<br />
A VRRDS is a fixed length RRDS, except that it contains variable-length records.<br />
Each record has a unique relative record number, and is placed in ascending<br />
relative record number order. Each record is stored and retrieved using its<br />
relative record number. VRRDS has no slots.<br />
The relative record number of a record cannot change. When that record is<br />
erased, the relative record number can be reused for a new record.<br />
Because the logical records have a variable size, it is not possible to use a<br />
formula to derive its RBA from its RRN. In a sense a VRRDS organization is a<br />
KSDS processed by RRN instead of a key. There is an index and data<br />
component forming the cluster. The search argument is the RRN pointing to the<br />
RBA of the corresponding logical record in the data component.<br />
You can specify free space for inserting records and increasing the length of a<br />
record. The split concept is implemented.<br />
You specify the VRRDS organization with the IDCAMS DEFINE command with<br />
the NUMBERED option and variable length record.
1.6.5 Linear data set (LDS)<br />
A linear data set (LDS) contains data that can be accessed as byte-addressable<br />
strings in virtual storage. It is a <strong>VSAM</strong> data set with a control interval size multiple<br />
of 4096 bytes. An LDS has no imbedded control information in its CI, that is, no<br />
RDFs and CIDFs. All LDS bytes are data bytes. Logical records must be blocked<br />
and deblocked by the application program. Logical records are transparent from<br />
<strong>VSAM</strong>’s point of view.<br />
In a sense, a LDS is a non-<strong>VSAM</strong> file with some of the <strong>VSAM</strong> facilities, such as<br />
the use of IDCAMS and <strong>VSAM</strong> specific information in the catalog. The most<br />
common LDS exploiter is DB2®.<br />
Like the ESDS and RRDS, an LDS contains a data component only.<br />
Figure 1-8 shows the format of an LDS.<br />
C<br />
O<br />
N<br />
A<br />
T<br />
R<br />
R<br />
E<br />
O<br />
A<br />
L<br />
C<br />
O<br />
N<br />
A<br />
T<br />
R<br />
R<br />
E<br />
O<br />
A<br />
L<br />
CI<br />
CI<br />
CI<br />
CI<br />
CI<br />
CI<br />
CI<br />
CI<br />
Figure 1-8 Linear data set (LDS)<br />
LINEAR DATA SET (LDS)<br />
DATA<br />
DATA<br />
DATA<br />
DATA<br />
DATA<br />
DATA<br />
DATA<br />
DATA<br />
You specify the LDS organization with the IDCAMS DEFINE command<br />
specifying the LINEAR parameter.<br />
Chapter 1. <strong>VSAM</strong> basics 23
24 <strong>VSAM</strong> <strong>Demystified</strong><br />
Data-in-Virtual<br />
DIV is an optional and unique buffering technique used for LDS data sets.<br />
Application programs can use DIV to map an LDS data set or a portion of a data<br />
set into an address space, a data space, or a hiperspace. An LDS cluster is<br />
sometimes referred to as a DIV object.<br />
Data is read into central storage through the paging algorithms only when that<br />
data block is actually referenced. During RSM page steal processing, only<br />
changed pages are written to auxiliary storage. Unchanged pages are discarded<br />
since they can be retrieved again from the permanent data set.<br />
DIV is designed to improve the performance of applications that process large<br />
files non-sequentially in an unpredictable pattern. It reduces the number of I/O<br />
operations that are traditionally associated with data retrieval. Likely candidates<br />
are large arrays or table files.<br />
Mapping a linear data set<br />
To establish a map from a linear data set to a window (a program provided area<br />
in multiples of 4K on a 4K boundary), the program issues:<br />
► DIV IDENTIFY to introduce (allocate) a linear data set to DIV services.<br />
► DIV ACCESS to cause a <strong>VSAM</strong> open for the data set and indicate access<br />
mode (read or update).<br />
► DIV MAP to enable the viewing of the data object by establishing an<br />
association between a program provided area and the data object. The area<br />
may be in an address space, data space, or hiperspace.<br />
No actual I/O is done until the program references the data in the window. The<br />
reference results in a page fault which causes DIV services to read the data from<br />
the linear data set into the window.<br />
► DIV SAVE can be used to write out changes to the data object.<br />
► DIV RESET can be used to discard changes made in the window since the<br />
last SAVE operation.<br />
1.7 Comparing <strong>VSAM</strong> data set organizations<br />
Table 1-2 provides a summary of the characteristics of <strong>VSAM</strong> data set types<br />
described in this chapter.
Table 1-2 Comparison of ESDS, KSDS, RRDS, VRRDS, and linear data sets<br />
ESDS KSDS<br />
Records are in the<br />
same order as<br />
they are entered<br />
Records can be<br />
fixed or variable<br />
length<br />
Direct access by<br />
RBA<br />
Consist of data<br />
component only<br />
Alternate index<br />
allowed<br />
A record’s RBA<br />
cannot change<br />
Space at the end<br />
of the data set is<br />
used for adding<br />
records<br />
A record cannot<br />
be deleted, but<br />
you can reuse its<br />
space for a record<br />
of the same length<br />
Spanned records<br />
allowed<br />
Extended format<br />
allowed<br />
Records are in<br />
collating<br />
sequence by key<br />
field after load<br />
Records can be<br />
fixed or variable<br />
length<br />
Direct access by<br />
key or by RBA<br />
Consist of data<br />
and index<br />
components<br />
Alternate indexes<br />
allowed<br />
A record’s RBA<br />
can change<br />
Free space is<br />
used for inserting<br />
and lengthening<br />
records<br />
Space given up by<br />
a deleted or<br />
shortened record<br />
becomes free<br />
space<br />
Spanned records<br />
allowed<br />
Extended format<br />
or compression<br />
allowed<br />
Fixed-length<br />
RRDS<br />
Records are in<br />
relative record<br />
number order<br />
Records have<br />
fixed length<br />
Direct access by<br />
relative record<br />
number<br />
Consist of data<br />
component only<br />
No alternate index<br />
allowed<br />
A record’s relative<br />
record number<br />
cannot change<br />
Empty slots is in<br />
the data set are<br />
used for adding<br />
records<br />
A slot given up by<br />
a deleted record<br />
can be reused<br />
No spanned<br />
records<br />
Extended format<br />
allowed<br />
Variable-length<br />
RRDS Linear data sets<br />
Records are in<br />
relative record<br />
number order<br />
Records have<br />
variable length<br />
Direct access by<br />
relative record<br />
number<br />
Consist of data<br />
and index<br />
components<br />
No alternate index<br />
allowed<br />
A record’s relative<br />
record number<br />
cannot change<br />
Free space is<br />
used for inserting<br />
and lengthening<br />
records<br />
Space given up by<br />
a deleted or<br />
shortened record<br />
becomes free<br />
space<br />
No spanned<br />
records<br />
Extended format<br />
allowed<br />
No processing at<br />
record level<br />
No processing at<br />
record level<br />
Access with<br />
Data-In-Virtual<br />
(DIV) optionally<br />
Consist of data<br />
component only<br />
No alternate index<br />
allowed<br />
No processing at<br />
record level<br />
No processing at<br />
record level<br />
No processing at<br />
record level<br />
No spanned<br />
records<br />
Extended format<br />
allowed<br />
Chapter 1. <strong>VSAM</strong> basics 25
1.8 Choosing a <strong>VSAM</strong> data set type<br />
26 <strong>VSAM</strong> <strong>Demystified</strong><br />
During the application development process, the application programmer needs<br />
to make decisions about the data model. Among these decisions, we have data<br />
organization, function, type of access, performance, and recovery tools you<br />
need. <strong>VSAM</strong> has several organizations and different ways for accessing your<br />
data. How to choose the one for your application is discussed here.<br />
Before you select a particular <strong>VSAM</strong> organization, you need answer the following<br />
questions:<br />
► What is the main purpose of your data set? Does it look more like a log, a<br />
database, or an inventory?<br />
► Do you need to access data by a key field in sequential or direct mode?<br />
► Do you need to access the records in sequence, skip sequential, randomly, or<br />
all of them?<br />
► Are all the logical records the same length?<br />
► Does the logical record length change?<br />
► Do you need to have insertions and deletions?<br />
► Is the data set going to be extended?<br />
► How often do you need to delete records?<br />
► Do you use spanned records?<br />
► Do you want to keep the data in order by the contents of the key field?<br />
► Do you want to access the data by an alternate index?<br />
► Do you want to exploit DIV?<br />
► Do you want to use data compression?<br />
► Do you need the utility functions provided by IDCAMS?<br />
When you have answered these questions, you can use them to choose the best<br />
organization for your data set. Remember that <strong>VSAM</strong> data sets cannot be<br />
processed using non-<strong>VSAM</strong> applications. Similarly, non-<strong>VSAM</strong> data sets cannot<br />
be processed using the <strong>VSAM</strong> access method.<br />
Following are our recommendations for choosing a data set organization.<br />
► Use QSAM or BSAM if:<br />
– You use no direct processing.<br />
– There are no insertions or deletions, and no change in the logical record<br />
length.<br />
– Record additions are only at the end of the data set.
– You are not concerned about IDCAMS functions.<br />
– You want to have data compression.<br />
– Performance and easy recovery are main issues.<br />
► Use KSDS if:<br />
– The data access is sequential, skip sequential, or direct access by a key<br />
field.<br />
– You would prefer easy programming for direct data processing.<br />
– There will be many record insertions, deletions, and logical record length<br />
variations.<br />
– You may optionally access records by an alternate index.<br />
– Complex recovery (due to index and data components) is not a problem.<br />
– You want to use data compression.<br />
► Use VRRDS if:<br />
– You have the same requirements as for a KSDS, but will use record<br />
number instead of a key field as argument.<br />
► Use RRDS if:<br />
– The record processing is sequential, skip sequential, or direct processing.<br />
– Easy programming for direct processing is not a requirement.<br />
– The argument for accessing data in direct mode is a relative record<br />
number, not the contents of a data field (key). RRDS is suitable for the type<br />
of logical records identified by a continuous and dense pattern of numbers<br />
(such as 1,2,3,4...).<br />
– All records are fixed length.<br />
– There are a small number of record insertions and deletions, and all the<br />
space for insertions must be pre-allocated in advance.<br />
– Performance is an issue. RRDS performance is better than KSDS, but<br />
worse than QSAM or BSAM.<br />
► Use ESDS if:<br />
– You are adding logical records only at the end of the data set and reading<br />
them sequentially (in the application control).<br />
– The logical record is variable length<br />
– You seldom need direct record processing by key (using AIX).<br />
– You are using a batch processing application.<br />
Chapter 1. <strong>VSAM</strong> basics 27
28 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Use LDS if:<br />
– You want to exploit DIV.<br />
– Your application manages logical records.<br />
– Performance is an issue.<br />
Many times, you will be using a specific <strong>VSAM</strong> organization depending on the<br />
software product you are running — for example, DB2 uses LDS data sets. In this<br />
case you do not have the option to chose the <strong>VSAM</strong> organization.<br />
1.9 Extended format data set<br />
Extended format is a technique that affects the way count key data (CKD) is<br />
stored in a 3390/3380 logical track. Extended format was first introduced to<br />
implement data striping. It increases the performance and the reliability of an I/O<br />
operation.<br />
It is recommended that you convert your data sets to extended format for better<br />
performance, additional function and improved reliability A good time to convert<br />
to extended format is when you reorganize your <strong>VSAM</strong> data set.<br />
All <strong>VSAM</strong> data set organizations can be defined in extended format, this includes<br />
KSDS, ESDS, RRDS, VRRDS, and LDS. The benefits available to extended<br />
format data sets include”<br />
► Data striping<br />
► Data compression<br />
► <strong>VSAM</strong> extended addressability<br />
► Partial space release<br />
► System-managed buffering<br />
When you create a <strong>VSAM</strong> component with the extended format option, there are<br />
two major differences from those not in extended format.<br />
► If a data set is allocated as an extended format data set, 32 bytes are added<br />
to each physical block. This physical block suffix may increase the amount of<br />
space actually needed for the data set, depending on the CI size. For<br />
example, in a 3390 device with a CI size of 18432 bytes implies in additional<br />
space of 12.5%. The 32-bytes suffix contains:<br />
– A relative record number<br />
– A 3-byte field to detect controller invalid padding, thus improving the<br />
availability of the I/O operation<br />
► The length of the data portion of the physical block is 4KB, a sort of fixed<br />
block architecture.
The block format and the suffix are transparent to the application, that is, the<br />
application does not require internal or external modifications to create and use<br />
the extended format data set.<br />
Extended format also improves <strong>VSAM</strong> function. The <strong>VSAM</strong> I/O driver media<br />
manager only writes channel programs to exploit extended format. All the new<br />
<strong>VSAM</strong> functions are supported by media manager, therefore, EF is a prerequisite<br />
for them.<br />
Extended format data sets must be system-managed. A system-managed data<br />
set must have an associated storage class and reside in a system-managed<br />
volume. Extended format data sets are described in the catalog as striped data<br />
sets with a stripe count of one. When a data set is allocated as an extended<br />
format data set, the data and index are extended format. Any alternate indexes<br />
related to an extended format cluster are also extended format.<br />
When in extended format, there is no support for the key-range <strong>VSAM</strong> option,<br />
MVS checkpoint restart, or hiperbatch because these options are not supported<br />
by media manager. Key-range is not recommended in an SMS environment with<br />
the new RAID controllers.<br />
Certain types of key-sequenced data set types cannot be allocated as extended<br />
format, including:<br />
► Catalogs<br />
► System data sets (SMS is not active at early IPL stages)<br />
► Temporary data sets<br />
If a data set is allocated as an extended format data set, 32 bytes are added to<br />
each physical block. This physical block suffix may increase the amount of space<br />
actually needed for the data set, depending on the CI size. For example, in a<br />
3390 device with a CI size of 18432 bytes implies in additional space of 12.5<br />
percent.<br />
To convert a non-extended format data set to extended format, or to allocate an<br />
extended format data set, you need to create an SMS data class (DC) with the<br />
DATASETNAMETYPE field equal to EXT and assign the data sets to that data class.<br />
Refer to Figure 4-8 on page 229.<br />
1.10 Extended addressability<br />
With extended addressability the 4 GB <strong>VSAM</strong> architectural limit for data set size<br />
imposed by using the 4-byte field for the relative byte address (RBA) was<br />
eliminated.<br />
Chapter 1. <strong>VSAM</strong> basics 29
30 <strong>VSAM</strong> <strong>Demystified</strong><br />
It is important to state up-front that extended addressability and extended format<br />
are not the same concept. Extended format is a way of storing data in a<br />
3390/3380 logical volume. Extended addressability provides the ability to have<br />
larger <strong>VSAM</strong> data sets. However, extended format is a prerequisite for extended<br />
addressability.<br />
Using extended addressability, the size limit for a <strong>VSAM</strong> data set is determined<br />
by either:<br />
► CI size multiplied by 4 GB<br />
► The volume size multiplied by 59<br />
A 4 K CI size yields a maximum data set size of 16 TB, while a 32 KB CI size<br />
yields a maximum data set size of 128 TB. A 4K CI size is preferred by many<br />
applications for performance reasons. No increase in processing time is<br />
expected for extended format data sets that grow beyond 4 GB.<br />
To use extended addressability, the data set must be:<br />
► SMS-managed<br />
► Defined as extended format<br />
1.11 Data striping<br />
Refer to “Extended addressability (EA)” on page 228 to get more information on<br />
the subject.<br />
Usually, in a multi-extent, multi-volume <strong>VSAM</strong> data set processed in sequential<br />
access, processing does not allow for any type of parallelism for I/O operations<br />
among the volumes. This means that when an I/O operation is executed for an<br />
extent in a volume, no other I/O activity from the same task or same data set is<br />
scheduled to the other volumes. In a situation where I/O is the major bottleneck,<br />
and there are available resources in the channel subsystem and controllers, it is<br />
a waste of these resources.<br />
Data striping addresses this sequential access performance problem by adding<br />
two modifications to the traditional data organization:<br />
► The records are not placed in key ranges along the volumes; instead they are<br />
organized in stripes.<br />
► Parallel I/O operations are scheduled to sequential stripes (CIs) in different<br />
volumes.<br />
By striping CIs, <strong>VSAM</strong> can spread simultaneous I/Os across multiple devices.<br />
This format allows a single application request for records in multiple tracks and<br />
CIs to be satisfied by concurrent I/O requests to multiple volumes.
The result is improved performance by achieving data transfer into the<br />
application at a rate greater than any single I/O path.<br />
1.12 Processing a <strong>VSAM</strong> cluster<br />
Before we cover how to process a <strong>VSAM</strong> cluster it is recommended that you have<br />
an idea about the source of <strong>VSAM</strong> processing options. Refer to “Major sources of<br />
<strong>VSAM</strong> processing options” on page 233.<br />
To process a <strong>VSAM</strong> cluster the following actions must be executed:<br />
► Allocate the data set to establish the logical link between a program and a<br />
data<br />
► Open the data set, identifying it with a DDNAME.<br />
► Accessing data through GETs and PUTs using an access method.<br />
► Close the data set.<br />
► Unallocate the data set.<br />
Following is a brief discussion of the <strong>VSAM</strong> processing actions.<br />
1.12.1 Allocating a <strong>VSAM</strong> cluster<br />
First, we want to differentiate between data set allocation and data set creation.<br />
The expression allocate a data set does not imply creating a data set, one can<br />
allocate an already existing data set. Allocate a data set to a task, means to<br />
create a data set (if it does not exist) and establish a connection between a<br />
program running under such task with the data set. However, after allocation the<br />
data set must first be opened in order to be accessed. This connection is<br />
represented by an entry in the task’s TIOT (a control block) linking the DDNAME<br />
with the UCB representing the device containing the data set.<br />
There are several ways to allocate a data set, through a DD card, through TSO<br />
ALLOC command, IDCAMS or by issuing the DYNALLOC macro within a<br />
program.<br />
The functions used at allocation time depend if the data set already exists or not:<br />
► If it exists, its device is located through a catalog search, a serialization ENQ<br />
is issued, and a VTOC search is executed.<br />
► If it does not exist, a device needs to be selected by SMS and SRM. The data<br />
set is created, an entry made in the VTOC, and catalogued (all <strong>VSAM</strong><br />
components must be catalogued).<br />
Chapter 1. <strong>VSAM</strong> basics 31
32 <strong>VSAM</strong> <strong>Demystified</strong><br />
Defining <strong>VSAM</strong> Clusters<br />
To define a cluster is an <strong>VSAM</strong> expression and it means to create and catalog the<br />
cluster, it does not imply allocating the data set. You can define a <strong>VSAM</strong> data set<br />
using any of the following methods:<br />
► IDCAMS DEFINE or ALLOCATE commands. Here, clusters are defined but<br />
not allocated to a task<br />
► ALLOCATE TSO command allocates (defining is included) a cluster <strong>VSAM</strong><br />
from a TSO terminal. The TSO commands are described in MHL OS/390<br />
TSO/E Command Reference, SC28-1969.<br />
► JCL DD statements define and allocate a <strong>VSAM</strong> cluster. For information on<br />
using JCL, see z/OS MVS JCL Reference, GC28-1757, and z/OS MVS JCL<br />
User's Guide, GC28-1758.<br />
► Dynamic allocation allocates and defines a <strong>VSAM</strong> cluster. The DYNALLOC<br />
macro is described in z/OS MVS Authorized Assembler Services Guide,<br />
GC28-1763.<br />
Using IDCAMS<br />
When using IDCAMS to define a <strong>VSAM</strong> data set, you specify:<br />
► Component name or cluster name.<br />
► Data set type. The default is INDEXED (KSDS).<br />
► Space allocation, both primary and secondary allocations, and the volumes<br />
on which the cluster’s components are to have space.<br />
► Data set attributes, such as record size and CI size. For a KSDS, you specify<br />
key information and free space.<br />
► Catalog information.<br />
Figure 1-9 shows the syntax of the DEFINE command and required parameters.<br />
DEFINE CLUSTER -<br />
(NAME(entryname))-<br />
CYLINDERS(primary secondary)|<br />
KILOBYTES(primary secondary)|<br />
MEGABYTES(primary secondary)|<br />
RECORDS (primary secondary)|<br />
TRACKS(primary secondary) -<br />
VOLUMES(volser[volser...]) -<br />
DATA (parameters) -<br />
INDEX (parameters) -<br />
CATALOG(subparameters)<br />
Figure 1-9 DEFINE command required parameters
1.12.2 Accessing <strong>VSAM</strong> cluster<br />
<strong>VSAM</strong> clusters can be accessed by different types of programs, such as batch<br />
program, CICS® application programs, IDCAMS, and DITTO. TSO REXX and<br />
CLISTs cannot be used to access <strong>VSAM</strong> entities.<br />
Batch and CICS application programs<br />
They can be written using languages that support <strong>VSAM</strong>, such as: COBOL, PL/I,<br />
JAVA, and Assembler. To obtain <strong>VSAM</strong> services, these application programs use<br />
<strong>VSAM</strong> macros, mainly the GET/PUT. For details, refer to DFSMS/MVS Macro<br />
Instructions for Data Sets, SC26-4913.<br />
IDCAMS<br />
IDCAMS is a program included in DFSMSdfp used to establish and maintain<br />
catalogs and <strong>VSAM</strong> clusters.<br />
IDCAMS can be invoked:<br />
► As a job or job step by specifying PGM=IDCAMS on the EXEC card.<br />
► From a TSO terminal executing commands. There is also under ISPF an user<br />
friendly option 3.2.V (<strong>VSAM</strong> utilities), that produces a panel where certain<br />
functions may be asked. Refer to Figure 1-9.<br />
► From an application program.<br />
Chapter 1. <strong>VSAM</strong> basics 33
34 <strong>VSAM</strong> <strong>Demystified</strong><br />
Menu Utilities Help<br />
<strong>VSAM</strong> Utilities<br />
Command ===><br />
Process Request Data Type<br />
1 1. Define 1. Alias<br />
2. Delete 2. Alternate Index<br />
3. Information (Listcat) 3. Cluster<br />
4. Generation Data Group<br />
5. Non-<strong>VSAM</strong><br />
6. Page Space<br />
7. Path<br />
8. User Catalog<br />
9. Data *<br />
10. Index *<br />
11. NVR **<br />
12. Truename **<br />
13. VVR **<br />
* Listcat Only<br />
** Delete Only<br />
Figure 1-10 ISPF under TSO<br />
More: +<br />
You can also call the IDCAMS program from within another program and pass<br />
the Access Method Services command and parameters to the IDCAMS program.<br />
There are two types of Access Method Services commands: functional<br />
commands and modal commands.<br />
► Functional commands are used to request the actual work, for example,<br />
defining a data set or listing a catalog, see Figure 1-11.<br />
► Modal commands allow the conditional execution of functional commands.<br />
TSO users can use functional commands only. See DFSMS Access Method<br />
Services for Catalogs, SC26-7394 for more information.
Access Method Services (AM S)<br />
LIST<br />
CATALOG<br />
INFORM ATION<br />
MODIFY<br />
DATA SET<br />
ATTRIBUTES<br />
LISTCAT<br />
A L T E R<br />
DELETE<br />
<strong>VSAM</strong><br />
OBJECTS<br />
Figure 1-11 AMS commands<br />
DELETE<br />
CREATE<br />
<strong>VSAM</strong><br />
OBJECTS<br />
DEFINE<br />
IDCA M S<br />
E XPO RT<br />
LIST<br />
DATA<br />
SETS<br />
LOADING/<br />
UNLOADING<br />
COPYING<br />
DITTO/ESA<br />
DITTO is a very powerful utility product that you can use to browse, edit, and<br />
delete <strong>VSAM</strong> records.<br />
You can start DITTO in full-screen mode from a TSO terminal. Check with your<br />
system programmer how to invoke DITTO as start procedures may vary with the<br />
installation.<br />
In full-screen mode, you can use menus, online help, and interactive browse and<br />
update functions. You will probably find full-screen mode the most convenient<br />
way to run DITTO, especially if you are a new DITTO user.<br />
You can also run DITTO in line, command, or batch modes. Refer to DITTO/ESA<br />
V1R3 User’s Guide, SH19-8221, for more information on using DITTO.<br />
Figure 1-12 shows the DITTO Task Selection Menu. Choose option 1 and then<br />
option 3 to browse a <strong>VSAM</strong> data set.<br />
PRINT<br />
IM P O RT<br />
R E P R O<br />
Chapter 1. <strong>VSAM</strong> basics 35
36 <strong>VSAM</strong> <strong>Demystified</strong><br />
Figure 1-12 DITTO selection panel<br />
Choose option 2 on the Task Selection Menu and then option 1 to edit a <strong>VSAM</strong><br />
data set.<br />
Figure 1-13 shows the DITTO edit menu.
Figure 1-13 DITTO edit function<br />
Figure 1-14 shows an example of editing a record using DITTO.<br />
Chapter 1. <strong>VSAM</strong> basics 37
1.12.3 Unallocation<br />
38 <strong>VSAM</strong> <strong>Demystified</strong><br />
Figure 1-14 <strong>VSAM</strong> edit panel<br />
Unallocation undoes what allocation did. There are three ways to unallocate a<br />
<strong>VSAM</strong> cluster.<br />
► Closing the data set can perform this function if FREE=CLOSE was specified<br />
for the allocation.<br />
► Your program can call dynamic unallocation.<br />
► During the step termination process, the initiator/terminator program<br />
automatically unallocates any remaining allocated data sets, not to be<br />
accessed in the following steps.<br />
1.13 <strong>VSAM</strong> exploiters<br />
The major applications that exploit <strong>VSAM</strong> functions are described in this section.
1.13.1 DB2<br />
DB2 uses linear (LDS) <strong>VSAM</strong> data sets for its table spaces, without implementing<br />
Data-in-Virtual. All the control (including buffer pool) is done by DB2. For<br />
example, DB2 implements data striping in LDS data sets.<br />
1.13.2 Hierarchical file system (HFS)<br />
HFS is a UNIX® Services data organization with no determined logical records<br />
— it is a byte string — made of embedded directories and data. It can be<br />
accessed by Posix code (a UNIX standard for operating system interfaces, APIs)<br />
running under z/OS or by z/OS applications. In the second case an HFS looks<br />
like a <strong>VSAM</strong> ESDS organization and is accessed in the same way.<br />
Accessing HFS files through <strong>VSAM</strong><br />
You can access an HFS file through <strong>VSAM</strong> in one of the following ways:<br />
► JCL DD statement specifying PATH=pathname<br />
► SVC99<br />
► TSO ALLOCATE command<br />
HFS files are simulated as an ESDS. However, since HFS files are not actually<br />
stored as ESDSs, <strong>VSAM</strong> cannot simulate all the characteristics of a sequential<br />
data set. As a result, there are certain macros and services which have<br />
incompatibilities or restrictions when dealing with HFS files. Refer to DFSMS<br />
Using Data Sets, SC26-7410 for more information.<br />
1.13.3 zSeries File System (zFS)<br />
zSeries® File System (zFS) is a z/OS UNIX file system that can be used in<br />
addition to the Hierarchical File System (HFS). zFS provides significant<br />
performance gains in accessing files approaching 8K in size that are frequently<br />
accessed and updated. The access performance of smaller files is equivalent to<br />
that of HFS. zFS provides reduced exposure to loss of updates by writing data<br />
blocks asynchronously and not waiting for a sync interval. zFS is a logging file<br />
system. It logs metadata updates. If a system failure occurs, zFS replays the log<br />
when it comes back up to ensure that the file system is consistent.<br />
Application programming interfaces<br />
zFS file systems contain files and directories that can be accessed with the z/OS<br />
hierarchical file system application programming interfaces on the z/OS<br />
operating system as follows:<br />
► An application interface composed of C interfaces, some of which are<br />
managed within the C Run-Time Library (RTL), while others access kernel<br />
Chapter 1. <strong>VSAM</strong> basics 39
1.13.4 CICS<br />
1.13.5 DFSMShsm<br />
1.13.6 DFSMSrmm<br />
40 <strong>VSAM</strong> <strong>Demystified</strong><br />
interfaces to perform authorized system functions on behalf of the<br />
unauthorized caller<br />
► An interactive z/OS shell interface by shell users<br />
A zFS aggregate<br />
A zFS aggregate is a data set that contains zFS file systems. The aggregate is a<br />
<strong>VSAM</strong> Linear Data Set (<strong>VSAM</strong> LDS) and is a container that can contain one or<br />
more zFS file systems. An aggregate can only have one <strong>VSAM</strong> LDS, but it can<br />
contain an unlimited number of file systems. The name of the aggregate is the<br />
same as the <strong>VSAM</strong> LDS name. Sufficient space must be available on the volume<br />
or volumes, as multiple volumes may be specified on the DEFINE of the <strong>VSAM</strong><br />
LDS. DFSMS decides when to allocate on these volumes during any extension of<br />
a primary allocation. <strong>VSAM</strong> LDSs greater than 4 GB may be specified by using<br />
the extended format and extended addressability capability in the data class of<br />
the data set.<br />
CICS allows the exploiting of <strong>VSAM</strong> clusters by CICS transactions. CICS uses<br />
the MVS system logger data set for logging.<br />
DFSMShsm has three control data sets, respectively migration control data set<br />
(MCDS), backup control data set (BCDS) and offline control data set (OCDS). All<br />
of them are <strong>VSAM</strong> KSDSs. In a multi-MVS image environment these data sets<br />
can be shared between distinct DFSMShsm instances. This environment is<br />
called HSMplex.<br />
DFSMSrmm also uses <strong>VSAM</strong> data sets for their control data sets. They are<br />
defined with SHAREOPTIONS(3 3) and they use the VSI control block to ensure<br />
that they have the most recent HURBA on each system.<br />
1.13.7 Java Record I/O (JRIO)<br />
JRIO is a set of APIs under OS/390 2.6 (JDK 1.1.8) level allowing the access of<br />
Java code to I/O record oriented data organizations. It is an additional to java.io<br />
APIs which only supports HFS type of access.<br />
JRIO lets Java applications access traditional z/OS file systems in addition to the<br />
Hierarchical File System (HFS). JRIO makes it easier for Java applications to
access records within files and to access file systems through native methods<br />
when java.io Application Programming Interfaces (APIs) do not support those file<br />
systems.<br />
JRIO is a class library, similar to java.io. While java.io provides byte-oriented or<br />
field-oriented access to files, JRIO provides record-oriented access, which is<br />
much more natural. The major differences are:<br />
► Read/write sequential and random access for a byte string data sets is<br />
provided by java.io.<br />
► JRIO allows:<br />
– Read/Write, append, update-in-place (changing length), insert, delete<br />
– Different types of records format as: fixed, variable, spanned, undefined<br />
– Different types of access as: sequential, key direct, RBA direct, skip<br />
sequential<br />
JRIO lets record-oriented applications (supporting multiple file systems) run<br />
using files on different file systems. It also provides a set of z/OS native code<br />
drivers to access:<br />
► Virtual Sequential Access Method (<strong>VSAM</strong>) data sets (KSDS only)<br />
► Non-<strong>VSAM</strong> record-oriented data sets (sequential or random access)<br />
► The system catalog (listing the High Level Qualifiers (HLQ) from the system<br />
catalog and data sets for a given HLQ)<br />
► Partitioned data set (PDS) directory<br />
► HFS for sequential and random I/O access to records. The HFS support uses<br />
pure Java code to provide a set of concrete classes and directory classes that<br />
use the underlying java.io. JRIO also provides navigational support for HFS<br />
directories.<br />
To run a JRIO application, Java commands implicitly set the CLASSPATH for the<br />
JRIO classes, which reside in the same subdirectory as the Java for z/OS<br />
classes.<br />
Then, you should update your CLASSPATH to include the application classes by<br />
using the following Shell command:<br />
export CLASSPATH=.:/u/joe/java/myclasses:$CLASSPATH<br />
In this example, the class loader first scans the current directory for the<br />
application classes. If that fails, the class loader then scans the<br />
/u/joe/java/myclasses directory.<br />
Chapter 1. <strong>VSAM</strong> basics 41
42 <strong>VSAM</strong> <strong>Demystified</strong><br />
To run the JRIO sample programs, update CLASSPATH to include the JRIO<br />
sample classes by using the following Shell command:<br />
export CLASSPATH=$CLASSPATH:$JAVA_HOME/recordio:<br />
$JAVA_HOME/recsamp.jar/<br />
JRIO and <strong>VSAM</strong><br />
JRIO provides indexed I/O access to records within a <strong>VSAM</strong> KSDS. The <strong>VSAM</strong><br />
support uses z/OS native code to provide a set of concrete classes that<br />
implement the KeyedAccessRecordFile class. This lets you access records:<br />
► In entry sequence order<br />
► By primary unique key<br />
► By alternate unique or non-unique key<br />
In “JRIO API examples” on page 364, you’ll find a set of APIs that you may use to<br />
access KSDS <strong>VSAM</strong> data sets.
Chapter 2. Performance<br />
2<br />
How can you get most out of your <strong>VSAM</strong> clusters? How can you improve data<br />
storage and retrieval? What parameters can be used when you define a <strong>VSAM</strong><br />
data set to enhance data access?<br />
This chapter answers these questions and describes the <strong>VSAM</strong> functions that<br />
can enhance performance. Hints and tips are provided to help you implement<br />
these <strong>VSAM</strong> functions. However the specific performance aspects of <strong>VSAM</strong> RLS<br />
and Transactional <strong>VSAM</strong> are discussed in their respective chapters.<br />
Before we discuss <strong>VSAM</strong> performance, we first review some performance<br />
basics.<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 43
2.1 Service level agreement<br />
44 <strong>VSAM</strong> <strong>Demystified</strong><br />
To make the subject of performance more objective and related to specific<br />
business needs, the Service Level Agreement or SLA was introduced.<br />
The SLA is a agreement between Information Systems organizations and user<br />
departments that should describe:<br />
► Average transaction response time (Tr) for accessing:<br />
– Network<br />
– Input/output (I/O)<br />
– CPU<br />
► The distribution of the response times, a measurement about how erratic they<br />
are<br />
► The throughput, also called external throughput rate (ETR), measured in<br />
ended transactions per second of elapsed time (not CPU time)<br />
► System availability, which is the percentage of time that the system is<br />
available to the end user<br />
2.2 Transaction performance<br />
A transaction is a business unit of work produced by an online or batch<br />
interaction with an end user or a department with the system. It can be a CICS,<br />
TSO, a WEB, an APPC, distributed DB2, or even a batch interaction. If your MVS<br />
is in Workload Manager (WLM) goal mode, all these transactions are monitored<br />
and accounted for by z/OS.<br />
To characterize the performance of a transaction, we need to understand its<br />
different response time components. Figure 2-1 shows general response time<br />
components, where:<br />
► Tr = Ts + Tw<br />
Ts is Service Time, Tw is Waiting Time (also called queue time), and Tr is<br />
Response Time
Tw<br />
CPU<br />
Tw<br />
I/O<br />
Tw (CPU): Time with ready dispatchable units, but not enough dispatching priority.<br />
Tw (I/O): Time with I/Os delayed in UCB or channel subsystem.<br />
Tw (TP): Time in the VTAM or TCP/IP queues.<br />
Tw (Storage): Time suffering a page fault or being swapped-out.<br />
Tw (Other): Time delayed by operator, ENQ, data set recall, server AS service.<br />
Ts (CPU): Time with dispatchable units executing CPU.<br />
Ts (I/O): Time with I/Os being executed (connected or disconnected).<br />
Ts (TP): Time being transported in the network.<br />
Figure 2-1 Response time components<br />
► Exploding the above formula, we have:<br />
Ts = Ts(CPU) + Ts(IO) + Ts(TP)<br />
Tw = Tw(CPU) + Tw(IO) + Tw(TP) + Tw(Storage) + Tw(Other)<br />
► ETR = Ne / T<br />
ETR is the External Throughput Rate, Ne is the number of ended<br />
transactions, T is the elapsed time.<br />
► There is also one formula relating the Tr with ETR, derived by Little’s law:<br />
ETR = N / (Tt + Tr)<br />
Exploding the Response Time (Tr)<br />
Tw<br />
TP<br />
Tw<br />
Storag<br />
e<br />
Tr<br />
Tw Ts<br />
Tw<br />
Other<br />
Ts<br />
CPU<br />
In this formula, N is the average number of users sending transactions<br />
(logged on), and Tt is the average thinking time of these users. Following are<br />
some considerations regarding this formula:<br />
– The variables that more intensively affect the ETR are N and Tt due to<br />
their usual numeric values. Therefore, you should never accept an SLA<br />
specifying ETR, because the only variable that the IS department can<br />
directly control is Tr.<br />
Ts<br />
I/O<br />
Ts<br />
TP<br />
Chapter 2. Performance 45
46 <strong>VSAM</strong> <strong>Demystified</strong><br />
– However, experiences show that when Tr is in a sub-second value, the<br />
value of Tt drops dramatically. This fact has to do with the human behavior<br />
in front of a terminal. If the machine responds fast (in a sub-second value),<br />
we also respond fast.<br />
Transaction response time is the best way to characterize the performance of a<br />
transaction. Here, the target is to reduce its value and consequently to increase<br />
the ETR figures (when the value is below one second). Remember that in RMF<br />
reports the Ts(TP) and Tw(TP) are not included in the response time pictured.<br />
2.3 Performance management<br />
2.3.1 I/O performance<br />
Performance management is the activity in an installation that monitors and<br />
allocates data processing resources to transactions according to a service level<br />
agreement (SLA).<br />
There are three main ways to solve performance problems:<br />
► Buy: You can simply buy more resources.<br />
► Tune: Tuning your system makes more effective and efficient use of those<br />
resources.<br />
► Steal: You can “steal” the resources from a less critical transaction.<br />
As CPU speed increases, the I/O response time (I/O Tr) is the determinant factor<br />
in the average transaction response time, as shown in the formula:<br />
I/O Tr = I/O Ts + I/O Tw<br />
So obviously, you can get excellent response time returns by reducing I/O wait<br />
time and I/O service time.<br />
Generally speaking, you can reduce the average I/O response time (I/O Tr) using<br />
software or hardware techniques. The software techniques aim to decrease the<br />
number of I/O operations, by implementing:<br />
► Virtual address space (above and below the bar) buffer and data space<br />
buffers<br />
► Hiperspace buffers<br />
► Data compression<br />
► Data striping
Examples of hardware techniques are:<br />
► Faster channels (as FICON, FICON Express)<br />
► Faster device paths (adapters) to the controllers<br />
► Larger controller cache<br />
► More DASD subsystem concurrency, for example, parallel access volumes<br />
(PAV) in Enterprise Storage Server® (ESS).<br />
► Faster disks (RPMs), small size, RAID-10<br />
However, experience has shown that when you succeed fighting an I/O<br />
bottleneck, increasing the I/O rate (for example, implementing data striping),<br />
suddenly the bottleneck is moved from the I/O subsystem to the processor.<br />
2.4 <strong>VSAM</strong> performance management<br />
The goal of <strong>VSAM</strong> performance management is to decrease the values of I/O<br />
wait time (Tw(IO)) and I/O service time (Ts(IO)) — that is, the I/O response time<br />
(Tr(IO)), for the transactions accessing <strong>VSAM</strong> data. It can be done by avoiding<br />
I/O or doing it faster and playing with I/O priorities. These priorities must be<br />
closely linked to your business needs.<br />
In this performance chapter, we use two approaches to help you to improve<br />
<strong>VSAM</strong> performance. First, we discuss all the <strong>VSAM</strong> external parameters whose<br />
values may affect performance. We give recommendations based on experience,<br />
on how those parameters should be set. This is known as “rule-of-thumb” (ROT)<br />
mode. At each topic end you have a set of recommendations, which summarize<br />
the explanations.<br />
In the second approach, we simulate a scenario (as real as possible), where one<br />
or several <strong>VSAM</strong> data sets are causing performance problems to key<br />
transactions in a real installation. We suggest a methodology to fix the situation.<br />
Here some of the recommendations covered in the rules of thumb are presented<br />
again, now connected with an specific <strong>VSAM</strong> behavior.<br />
Also, other factors not connected to <strong>VSAM</strong> parameters, such as I/O configuration<br />
delays, use of FICON channels, SMS storage class attributes, use of<br />
Hiperbatch, and workload CPU bound, are introduced and discussed.<br />
Throughout this chapter, you see a set of screens containing real RMF reports<br />
covering <strong>VSAM</strong> I/O measurements related to the theories presented. These<br />
measurements were obtained in our lab setup described in “General lab<br />
description” on page 396.<br />
Chapter 2. Performance 47
2.5 <strong>VSAM</strong> rule-of-thumb mode<br />
48 <strong>VSAM</strong> <strong>Demystified</strong><br />
Before we start, let us make a general statement about <strong>VSAM</strong> cluster parameters<br />
affecting performance and their defaults. You should note that these defaults<br />
were established a long time ago, when virtual storage was all below the 16 MB<br />
line; central storage size restricted; the DASD was slow, removable, and<br />
expensive; and channels were a scarce resource.<br />
Therefore, the defaults are outdated in many cases. The reason IBM does not<br />
change the defaults is to maintain compatibility with your existing workload.<br />
Compatibility is an important feature protecting your investment. You do not need<br />
to throw out your code and hardware when z/OS changes a release. However,<br />
keep in mind that these <strong>VSAM</strong> defaults can be easily overwritten through JCL,<br />
the ACB macro, data class constructs, ACS routines, or IDCAMS.<br />
2.5.1 Invalid rules-of-thumb<br />
Another important point to mention is that you may have heard many<br />
recommendations about data set placement and the effect on I/O performance.<br />
We call these recommendations “invalid rules-of-thumb” (IROTs). Generally<br />
speaking, they are out of date due to the introduction of the RAID controllers and<br />
enhancements to channel programs, such as these:<br />
► The physical 3390/3380 volume concept no longer exists, and we do not<br />
know where their logical tracks are located on the disks, so we should not<br />
care about seek arm movement considerations, in such devices.<br />
Also, in the past we had several changes in the device geometry as new<br />
products were introduced. Now the logical 3390/3380 geometry will still be<br />
valid for a long time because it is not affected by enhancements to the disk<br />
controllers. For example, the device independence recommendation (records<br />
instead of tracks for units of allocation), due to changes in future track or<br />
cylinder geometry, is not a consideration anymore.<br />
► In the case of a cache miss, the channel always reads (or writes) in cache,<br />
asynchronously in relation to the disk, so there are no extra revolutions.<br />
caused by 3390 RPS misses.<br />
► The existence of the Define Extent Format CCW, the Prefix CCW, and Parallel<br />
Access Volume (PAV) for the Enterprise Storage Server (ESS).<br />
The following recommendations (IROTS), are no longer valid:<br />
► Place your VTOC around the middle of the volume, or at 1/3 for the purists.<br />
► If you need to place two active data sets in the same volume, place them<br />
close to each other, to avoid arm stealing along seeks.
► Do not allow much secondary allocation in the same volume because of the<br />
embedded long seeks in the same data set.<br />
► Use <strong>VSAM</strong> KSDS embedded sequence set index records to minimize seeks.<br />
► Use <strong>VSAM</strong> KSDS replication to avoid unnecessary revolutions.<br />
► When allocating a data set on device dependent geometry, use cylinders, not<br />
tracks, for better performance.<br />
► It is better to use a device independent geometry for allocation units (for<br />
example, records) to avoid modifications when the 3390/3380 geometry<br />
changes.<br />
► Reorganize your KSDS data set after some CA splits in order to avoid long<br />
embedded seeks. (For information on <strong>VSAM</strong> KSDS data set reorganization<br />
refer to 4.1, “Reorganization considerations” on page 204.)<br />
► Avoid channel utilization above 30% to inhibit RPS misses and another DASD<br />
revolution.<br />
► Use <strong>VSAM</strong> keyrange to have control over the allocation of the key ranges of<br />
your data set.<br />
► Avoid many active data sets in the same ESS volume.<br />
2.6 Parameters affecting performance<br />
2.6.1 Allocation units<br />
The following <strong>VSAM</strong> parameters and options can affect performance.<br />
When you define your new data set, either the end user or SMS administrator<br />
through defining a data class (DC) must specify the amount of space to be<br />
allocated for it. One of the allocation functions for a new data sets is the creation<br />
of the DSCB in the VTOC, is done by the DADSM routine. Refer to “Allocating a<br />
<strong>VSAM</strong> cluster” on page 31, for more information about allocation. If SMS is<br />
active, you can specify a data class and take advantage of the space allocation<br />
set by your storage administrator. If you choose to specify space explicitly, you<br />
can specify it for <strong>VSAM</strong> data sets in units of records, kilobytes, megabytes,<br />
tracks, or cylinders.<br />
DADSM only accepts allocation requests in tracks or cylinders. The units<br />
specified (records, kilobytes, or megabytes) are converted by IDCAMS before the<br />
DADSM request.<br />
If you specify records as the allocation unit, the number of records you declare is<br />
multiplied by the value of the keyword RECORDSIZE(AVERAGE) value, to derive<br />
Chapter 2. Performance 49
50 <strong>VSAM</strong> <strong>Demystified</strong><br />
the space in bytes. This keyword can also indicate the maximum value allowed<br />
for the record length. Later during the access, If the maximum record length is<br />
exceeded, <strong>VSAM</strong> rejects the new record.<br />
When the primary amount on the first volume is used up, a secondary amount is<br />
allocated on that volume by the end-of-volume (EOV) routine. <strong>VSAM</strong> acquires<br />
space in increments of control areas (CAs). Each time a new record does not fit<br />
in the allocated space, EOV allocates more space in the secondary space<br />
amount. This can be repeated until the volume is out of space or the extent limit<br />
is reached. Depending on the type of data set allocation request, a new volume<br />
may be used.<br />
Do not define a small amount of secondary space allocation value, especially for<br />
a KSDS or a VRRDS data set. There are a large number of I/O operations<br />
involved when the secondary allocation takes place.<br />
We do not state any recommendations on allocation because these depend on<br />
the use, or not, of the Guaranteed Space option.<br />
2.6.2 Guaranteed Space<br />
The allocation function depends on whether the data set has the Guaranteed<br />
Space attribute.<br />
The Guaranteed Space, a storage class SMS attribute lets you reserve space on<br />
specific volumes (VOLSER) for clusters that require special placement to meet<br />
performance or availability requirements. For example, IMS logs that are<br />
duplexed by IMS to improve availability should be on separate volumes. However,<br />
the specified volumes must be described in the storage group associated with<br />
the cluster.<br />
Typically, you use storage class performance and availability attributes and<br />
storage group assignments to determine where to place your data set. You<br />
assign storage groups in your storage group ACS routine. SMS then selects<br />
volumes by evaluating each candidate's ability to satisfy the performance,<br />
availability, and space requirements for the data set. To place data sets on<br />
specific volumes, assign a storage class to the data set that supports<br />
Guaranteed Space and maps to the correct storage group. If the resulting<br />
storage group does not contain the specified volume, or all the volumes are not in<br />
the same storage group, the allocation will fail.<br />
For non-guaranteed space data set allocation, when you allocate space, it is<br />
possible for the user to specify whether to use primary or secondary allocation<br />
amounts when extending to a new volume. This is done with an SMS
DATACLASS parameter for <strong>VSAM</strong> attributes, as shown in Figure 2-2, of the ISMF<br />
application.<br />
ADDITIONAL The ADDITIONAL VOLUME AMT field shows the type of allocation<br />
VOLUME AMT amount when a <strong>VSAM</strong> data set in extended format begins<br />
allocation<br />
---(15)--- on subsequent new volumes.<br />
Possible values:<br />
PRIMARY Primary allocation amount has been requested.<br />
SECONDARY Secondary allocation amount has been requested.<br />
--------- If the value has not been specified. The system will use<br />
the default value of Primary.<br />
Figure 2-2 Data Class panel<br />
For a Guaranteed Space data set allocation, the following conditions must met:<br />
► All volumes specifically specified in VOLSER belong to the same storage<br />
group.<br />
► The storage group to which these volumes belong is in the list of storage<br />
groups selected by the ACS routines for this allocation.<br />
We recommend that you allocate space at the data component level, because<br />
this is the component that you are able to size. <strong>VSAM</strong> allocates space as follows:<br />
► If space is specified at the cluster or alternate index level (refer to 1.5.11,<br />
“Alternate indexes” on page 14), the amount needed for the index is<br />
subtracted from the specified amount. The remainder of the specified amount<br />
is assigned to data.<br />
► If space is specified at the data component level only, the specified amount is<br />
assigned to data. The amount needed for the index is in addition to the<br />
specified amount.<br />
► If allocation is specified at both the data and index levels, the specified data<br />
amount is assigned to data and the specified index amount is assigned to the<br />
index.<br />
► If secondary allocation is specified at the data level, secondary allocation<br />
must be specified at the index level or the cluster level.<br />
Recommendations<br />
► For KSDS and VRRDS formulate space for data component only.<br />
Chapter 2. Performance 51
52 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Use the most you can space information from data class definition.<br />
► Avoid Guaranteed Space.<br />
► Avoid to use tracks as unit to get rid of the contiguous requirement. Use<br />
records, this unit is closer to the application needs.<br />
► Do not use a very small secondary allocation figure.<br />
► Consider using “Allocation constraint relief” on page 54.<br />
2.6.3 Optimizing control area (CA) size<br />
Before we discuss this topic, we want to clarify that when we say cylinder and<br />
track, we are referring to the logical 3390/3380 cylinder and track, not the<br />
cylinder and track of the disks in the RAID DASD controllers.<br />
Generally, the primary and secondary space allocation amounts determine the<br />
CA size, as follows:<br />
► If either the primary or secondary allocation is smaller than one cylinder, the<br />
smaller value is used as the CA size.<br />
– TRACKS(100,3): This results in a 3-track CA size.<br />
– TRACKS(3,100): This results in a 3-track CA size.<br />
– KILOBYTES(100,50): The system determines the control area based on<br />
50 KB, resulting in a 1-track CA size.<br />
– RECORDS(2000,5): Assuming that 10 records would fit on a track, this<br />
results in a 1-track CA size.<br />
► If both the primary and secondary allocations are equal to or larger than one<br />
cylinder, the CA size is one cylinder. An exception is for data striping, where<br />
the CA size can be 16 tracks (one more than the cylinder) — the maximum<br />
size for a CA.<br />
– CYLINDERS(5,10): This results in a 1-cylinder CA size.<br />
For KSDS and VRRDS organizations the index CI size and buffer space can also<br />
affect the CA size. The previous examples assume the index CI is large enough<br />
to handle all the data CIs in the CA, and the buffer space is large enough not to<br />
affect the CI size.<br />
A spanned record cannot be larger than a CA minus the control information size<br />
(10 bytes per CI for fixed logical records length). Therefore, do not specify large<br />
spanned records and a small primary or secondary allocation which results in a<br />
CA not large enough to contain the largest spanned record.<br />
CA size has significant performance implications. One-cylinder CAs have the<br />
following advantages:
2.6.4 Partial release<br />
► There is a smaller probability of CA splits.<br />
► The index is more consolidated. One index CI addresses all the CIs in a CA. If<br />
the CA is large, fewer index records and index levels are required. For<br />
sequential access, a large CA decreases the number of reads of index<br />
records.<br />
► There are fewer sequence set index CIs because there are less CAs of one<br />
cylinder size. In sequential access all those records need to be read. Fewer<br />
index CIs means more effective channel programs.<br />
► If you have allocated enough buffers, a large CA allows you to read more<br />
buffers into storage at one time. A large CA is useful if you are accessing<br />
records sequentially.<br />
► The overlap between I/O and CPU for sequential processing is done in a CA<br />
boundary. When reached the application must wait until the last input/output<br />
to the CA is done before proceeding to the next CA. The I/O operations are<br />
always scheduled within CA boundaries.<br />
The following disadvantages of a one-cylinder CA must also be considered:<br />
► If there is a CA split, more data is moved.<br />
► During sequential I/O, a large CA ties up more real storage and more buffers.<br />
Partial release is used to release data (not index) unused space from the end of<br />
an extended format data set. Refer to 1.9, “Extended format data set” on<br />
page 28. Partial release is specified through the SMS management class or by<br />
the JCL RLSE subparameter.<br />
All space after the high used RBA (HURBA) is released on a CA boundary up to<br />
the high allocated RBA (HARBA). Refer to 3.8, “IDCAMS LISTCAT output fields”<br />
on page 187, to get more information on HURBA and HARBA. If the high used<br />
RBA is not on a CA boundary, the high used amount is rounded to the next CA<br />
boundary. Partial release restrictions are:<br />
► Alternate indexes (AIXs) opened for path or upgrade processing are not<br />
eligible for partial release. The data component of an AIX when opened as<br />
cluster could be eligible for partial release.<br />
► Partial release processing is not supported for temporary close. Temporary<br />
close (TYPE=T) means that the ACB is still opened, so there is no need of an<br />
Open to restart processing. However, the data set looks closed with EOF<br />
marks at the end.<br />
► Partial release processing is not supported for data sets defined with<br />
guaranteed space.<br />
Chapter 2. Performance 53
54 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Extended format is a requirement.<br />
2.6.5 Allocation constraint relief<br />
Users occasionally encounter data set allocation or extension failures (X37<br />
abends) because there is not enough space available on a volume to satisfy the<br />
request. SMS alleviates this situation to by performing volume selection,<br />
checking all candidate volumes before failing an allocation.<br />
You can also use SMS data class the Space Constraint Relief and Reduce<br />
Space Up To (%) attributes to request that an allocation be retried, if it fails due to<br />
space constraints.<br />
Recommendations<br />
► Do not define a small amount of secondary space allocation for a KSDS or<br />
VRRDS data set.<br />
► Allocate space at the cluster or data levels.<br />
► Do not use tracks as an allocation unit; this forces the CONTIG attribute for<br />
secondary allocations.<br />
► Avoid either primary or secondary allocation smaller than one cylinder,<br />
because it makes the CA size less than one cylinder.<br />
► Consider partial release, if applicable.<br />
► Consider constraint relief, if applicable.<br />
2.6.6 Control interval size<br />
There are two types of control intervals (CIs) in a KSDS and VRRDS: the index<br />
and the data. The other <strong>VSAM</strong> organizations only have data CIs. The data CI and<br />
index CI sizes are declared in the IDCAMS DEFINE command and kept in the<br />
catalog. If you define CI size for the cluster, this value is used for both data CI<br />
and index CI. In the following sections we offer recommendations about how to<br />
size both.<br />
Data control interval size<br />
There are arguments favoring both large and small CI sizes. Let us look at each<br />
of these possibilities:<br />
► For sequential processing, larger data CI sizes are desirable. For example,<br />
given a 16 KB data buffer space to be fulfilled, it is faster to read two 8 KB CIs<br />
with one I/O operation than four 4 KB CIs with one operation.<br />
► A large CI is a more centralized management of the free space CI, and<br />
consequently causing fewer CI splits. One component with one 16 KB CI with
20% of free space has less splits than a two 8 KB CIs with the same 20% of<br />
free space.<br />
► For direct processing, smaller data CIs are desirable because the application<br />
only needs to retrieve one logical record at a time, then avoiding useless data<br />
transfer.<br />
► For data set shared access within an address space, refer to 4.3.3, “Sharing<br />
data in a single <strong>VSAM</strong> control block structure” on page 218. The size of the CI<br />
affects the amount of data locked by <strong>VSAM</strong>; the smaller, the better.<br />
In conclusion, for data sets accessed both randomly and sequentially, a small<br />
data CI with multiple buffers to help for sequential processing can improve<br />
performance.<br />
Index control interval size<br />
Usually you do not specify index CI size for KSDS and VRRDS. Let <strong>VSAM</strong><br />
calculates it. Recall that <strong>VSAM</strong> uses one index record per each data CI and one<br />
index CI per each data CA. The size of the index CI affects:<br />
► The number of levels in the index set. However, the number of indexes will<br />
effect the performance only for very large clusters that are greater than four<br />
levels.<br />
► The usable capacity of a data CA. Sometimes a small index CI size may<br />
cause some loss in the usable capacity of the associated data CA. For the<br />
calculation of the CI index size, <strong>VSAM</strong> assumes a compressed key of 5 bytes.<br />
Sometimes the key does not compress well and this assumption is<br />
underestimated. Pay attention that at z/OS 1.3 the formula used by <strong>VSAM</strong> to<br />
calculate the index CI size changed. To see this modification and also to<br />
determine if your CI size is too small and because of this you are losing data<br />
CA space, refer to 4.2, “New Index CI size calculation algorithm” on page 208.<br />
Recommendations<br />
► For sequential access, define data CIs with 16 KB or larger.<br />
► For random access, define data CIs with 4 KB.<br />
► For mixed random and sequential access, define data CIs with 4 KB (for<br />
favoring random access) and plenty of buffer space in the buffer pool<br />
(allowing CCW chaining for sequential access).<br />
► Let <strong>VSAM</strong> derive the size of the index CI. Define it yourself only when you are<br />
losing data CA capacity due to small CI index size.<br />
Chapter 2. Performance 55
2.6.7 FREESPACE definition for KSDS and ESDS<br />
56 <strong>VSAM</strong> <strong>Demystified</strong><br />
Freespace option specifies, through IDCAMS DEFINE (kept in the catalog), the<br />
percentage of each data CI and each data CA is to be set aside as free space<br />
when the cluster KSDS or VRRDS is initially loaded or when a mass insertion<br />
(writes skip sequential) is done. You can change the amount of free space using<br />
the IDCAMS ALTER command. Free space is specified as a percentage. If the<br />
FREESPACE amount is altered after the data set is initially loaded, and<br />
sequential insert processing is used, the allocation of free space is not honored.<br />
The syntax of the FREESPACE parameter is:<br />
FREESPACE(CI-percent CA-percent)<br />
There is no free space external specification for index CIs or index CAs.<br />
Freespace is used to reduce the number of CI and CA splits along insertions or<br />
updating in-place records with a length increase.<br />
When you specify free space in CI (first value in FREESPACE CI percentage),<br />
ensure that the CI free space percentage does not result in lots of unused free<br />
space. You can ensure this by taking into account the logical record length, the<br />
size of the CI, and the length of CIDF and RDFs. Following is a numeric example:<br />
► Assuming a fixed length record data set, where each CI is 4096 bytes,<br />
10 bytes are reserved for control information (2 RDFs and 1 CIDF). Each<br />
logical record has 1000 bytes and you want to reserve room for 10%<br />
inclusion.<br />
► If you specify 10% of CI free space <strong>VSAM</strong> reserves 410 bytes (4096 * 0.10)<br />
for free space. The logical record space is 3676 (4096 - 420) bytes.<br />
► Because the records loaded in the data set are 1000-byte records, there is<br />
only space for three records, leaving 1086 (410 + 676) for insertions. In this<br />
free space you can fit another logical 1000 byte record, so your free space<br />
setting is correct. You are loosing only 86 bytes of unused space. All this<br />
calculation is done for a non-compressed data set. For compression<br />
information, refer to 2.6.15, “Data compression” on page 94.<br />
For CA free space, <strong>VSAM</strong> ensures that at least one CI per CA remains empty<br />
during loading when you declare a FREESPACE CA percentage amount other<br />
than zero.<br />
Too much free space in a CI or CA can result in:<br />
► Increased number of index levels be cause less data per data CI/CA, which<br />
affects run times for direct processing slightly.<br />
► More DASD storage required to contain the data set.
► More I/O operations required to sequentially process the same number of<br />
records. Note that these extra I/O operations are only affected by an excess of<br />
CI free space. CA free space does not increase the number of I/O operations<br />
in a sequential read because totally free CIs are not moved to storage.<br />
Too little free space can result in an excessive number of CI and CA splits<br />
(depending on the key pattern of the records to be inserted), with consequences<br />
such as:<br />
► The CA splits are resource consuming, due to the overhead (during the split),<br />
since approximately half of the CIs from the CA are moved to the end of the<br />
data set.<br />
► CI and CA splits may also affect the sequential processing because the DASD<br />
controller, to better use the cache, only detects 3390/3380 tracks physical<br />
sequence. Splits make the logical sequence different from the physical<br />
sequence.<br />
Determine the amount of CI free space based on the percentage of record<br />
additions expected, and their distribution.<br />
If you know in advance the pattern of the keys being inserted, you can take<br />
advantage of it by choosing the technique best suited for the application.<br />
Recommendations<br />
► Determine the amount of CI free space based on the percentage of record<br />
additions expected, and their distribution:<br />
No additions. If no records will be added and if record sizes will not be<br />
changed, there is no need for free space.<br />
Few additions. If few records will be added to the data set, consider a free<br />
space specification of (0 0). When records are added, new CAs are created to<br />
provide room for additional insertions.<br />
If the few records to be added are fairly evenly distributed, CI free space<br />
should be equal to the percentage of records to be added (FSPC (nn 0),<br />
where nn equals the percentage of records to be added.)<br />
Evenly distributed additions. If new records will be evenly distributed<br />
throughout the data set, CA free space should equal the percentage of<br />
records to be added to the data set after the data set is loaded. (FSPC (0 nn),<br />
where nn equals the percentage of records to be added.)<br />
Unevenly distributed additions. If new records will be unevenly distributed<br />
throughout the data set, specify a small amount of free space. Additional<br />
splits, after the first, in that part of the data set with the most growth will<br />
produce CIs with only a small amount of unneeded free space.<br />
Chapter 2. Performance 57
2.6.8 Index options<br />
58 <strong>VSAM</strong> <strong>Demystified</strong><br />
Mass insertion. If you are inserting a group of sequential records, you can<br />
take full advantage of mass insertion by using the ALTER command to<br />
change free space to (0 0) after the data set is loaded.<br />
Additions to a specific part of the data set. If new records will be added to only<br />
a specific part of the data set, load those parts where additions will not occur<br />
with a free space of (0 0). Then, alter the specification to (n n) and load those<br />
specific parts of the data set.<br />
There are two index options associated with a cluster defined in the IDCAMS<br />
DEFINE command and stored in the catalog respectively REPLICATE and<br />
IMBED. They exploit 3390/3380 characteristics.<br />
Beginning with DFSMS 1.5 this parameter is no longer valid. No warning<br />
message is issued. Because of that they are not discussed here.<br />
Recommendations<br />
► Do not use REPLICATE.<br />
► Do not use IMBED.<br />
2.6.9 Key Range and Ordered<br />
2.6.10 Share options<br />
Key Range, for example, allows the user to select a volume to a set of keys in a<br />
collating sequence (another volume to another set). The major reason of that is<br />
to increase the parallelism of access, because you use multiple volumes.<br />
Ordered implies that the order of declared volumes must be followed along<br />
secondary allocation.<br />
These options are not recommended anymore, because they place a burden in<br />
the user. It is recommended that they not be used on z/OS 1.3 systems and up,<br />
because they are not supported.<br />
There are several mechanisms to implement <strong>VSAM</strong> data set integrity (read and<br />
write integrity). They are:<br />
► Intra address space locks for serializing <strong>VSAM</strong> data sets among tasks of the<br />
same address space.<br />
► <strong>VSAM</strong> SHAREOPTIONS play an important role in <strong>VSAM</strong> integrity, specifying<br />
whether and to what extent <strong>VSAM</strong> data sets are to be shared among tasks in<br />
one or multiple z/OS address spaces. This feature uses ENQ on<br />
SYS<strong>VSAM</strong>.data-set-name in order to achieve the required serialization.
► ENQ/Reserve serialization functions issued by the application.<br />
► JCL disposition (OLD or SHR), which also implies in an ENQ.<br />
► Record level sharing (RLS) locking mechanism, which is covered in “Define<br />
CF lock structures” on page 258.<br />
The reason that we are covering these mechanisms in the performance chapter<br />
is because usually integrity and performance vary inversely. Total integrity may<br />
result in bad performance.<br />
When you define <strong>VSAM</strong> data sets, you can specify how the data is to be<br />
serialized (if shared) within a single system or among multiple systems that can<br />
have access to your data. Before you define the level of sharing and the<br />
serialization mechanism for a data set, you must evaluate the consequences of<br />
reading incorrect data (a loss of read integrity) and writing incorrect data (a loss<br />
of write integrity). And the situations that can result when one or more do not<br />
adhere to guidelines recommended for accessing such shared data sets. On the<br />
other hand, it is important to avoid the unnecessary use of certain serialization<br />
functions which may cause a performance degradation.<br />
Refer to 4.3, “Sharing <strong>VSAM</strong> data sets” on page 212, for more information.<br />
Recommendations<br />
► If you are sure that no application updates or deletes the <strong>VSAM</strong> data set, then<br />
do not use SHAREOPTIONS 4. It causes bufferpool refresh for direct reads or<br />
writes. The bufferpool is useless and no I/Os are saved.<br />
► If you are doing your own serialization use ENQ SHARE instead of ENQ<br />
EXCLUSIVE for reads.<br />
► In a cross-systems environment, avoid the use of the RESERVE macro,<br />
which locks the full 3390/3380 logical volume. Instead use the ENQ macro for<br />
a global resource with GRS. However, for applications already using the<br />
Reserve macro, it can be transformed (without changing the code) in a<br />
Systems ENQ through the GRS Conversion RNL.<br />
2.6.11 Initial load option<br />
Initial load mode occurs when you load (write) your data sequentially in a <strong>VSAM</strong><br />
data set which has a High Used RBA (HURBA) equal to zero. The data set to be<br />
loaded is already IDCAMS defined (cataloged and described through the DSCB<br />
in VTOC). Initial load can be done through by IDCAMS REPRO, IMPORT or<br />
application program. There are two cases:<br />
► After the DEFINE indicating that this is the first time you are writing into the<br />
data sets its initial contents, or<br />
Chapter 2. Performance 59
60 <strong>VSAM</strong> <strong>Demystified</strong><br />
► When a data set, defined with the REUSE attribute, is opened with<br />
MACRF=RST (reset) in the ACB, meaning that you reusing the data set with<br />
new data.<br />
You need to load a data set first, because in <strong>VSAM</strong> non-RLS mode, your<br />
application program cannot open for input to an empty data set.<br />
Initial load uses a NSR buffering, refer to “Non-shared resources (NSR)” on<br />
page 68.<br />
RECOVERY and SPEED options<br />
There are two options where performance of an initial load process may be<br />
affected, respectively RECOVERY and SPEED. Those options have to do with<br />
the techniques used by an access method for creating physical records:<br />
► RECOVERY. This option first formats a 390/3380 track (erases the previous<br />
contents) by executing the Write Count Data CCW (also called Write Format)<br />
creating physical records full of zeroes in the Data part (of a CKD physical<br />
record). These zeroes mean a <strong>VSAM</strong> end-of-file indicator.<br />
► The data portion of tracks are filled with real data by executing the Write Data<br />
CCW (Write Modified). The I/O response time for the load almost doubles.<br />
Read “DASD cache highlights” on page 126, for more information on Write<br />
Format and Write Modified CCWs. The tracks beyond HURBA are not<br />
formatted.<br />
► The Recovery option allows the restart of the load operation from the last<br />
written record (just before the first end-of-file physical record), however other<br />
difficulties such as tape repositioning (in the input file) have inhibited<br />
customers from using it.<br />
► SPEED: The data CIs/CAs are not pre-formatted with zeroes. The Write<br />
Count Data CCW is executed (in just one pass) creating the physical record<br />
with real data in the data part. An end-of-file indicator is written only after the<br />
last record is loaded. As in the Write Modified type of channel program (in<br />
RECOVERY), many writes are assembled in the same channel program to<br />
improve CPU and I/O usage (depending on the number of NSR data buffers).<br />
However free CIs (if you declare CAs with free CIs) are not written together<br />
with occupied CIs in the same channel program.<br />
Table 2-1 this table compares the RECOVERY and SPEED options<br />
Initial<br />
Load<br />
Extended<br />
Format<br />
EXCP Total<br />
Connect<br />
Time<br />
(msec)<br />
CPU TIME<br />
(sec)<br />
Recovery Yes 22276 36881 7.8 64<br />
Elapsed<br />
time (sec)
Initial<br />
Load<br />
2.6.12 Region size<br />
Extended<br />
Format<br />
EXCP Total<br />
Connect<br />
Time<br />
(msec)<br />
CPU TIME<br />
(sec)<br />
Recovery No 20569 33156 7.7 60<br />
Speed No 8604 16993 7.5 35<br />
Speed Yes 8605 20079 7.6 38<br />
Elapsed<br />
time (sec)<br />
Because it has just one pass, with SPEED you get better performance for initial<br />
load mode. Refer to Table 2-1.<br />
Be aware that during load mode processing, you cannot share data sets. Share<br />
options are overridden during load mode processing to (1 3). When a shared<br />
data set is opened for create or reset processing, your program has exclusive<br />
control of the data set within your operating system by the use of the ENQ<br />
Systems exclusive in the SYS<strong>VSAM</strong> resource. If data sets are shared between<br />
systems, never place this resource name in the exclusion list.<br />
There are other <strong>VSAM</strong> options affecting the initial load performance:<br />
► System managed buffering (SMB) due to better buffer management.<br />
► Extended format; refer to 1.9, “Extended format data set” on page 28.<br />
Recommendations<br />
► Do not use the RECOVERY option.<br />
► Use SMB.<br />
► Use extended format.<br />
► Remember that any specific SHAREOPTIONS assignment in an initial load is<br />
forced to (1 3).<br />
The key to reducing the number of I/O operations is to keep more data in virtual<br />
storage. The recommendations given here go in this direction. So, before you<br />
implement them, you should review the region size parameter to avoid an S878<br />
type of abend, as shown in the following <strong>VSAM</strong> message:<br />
Chapter 2. Performance 61
62 <strong>VSAM</strong> <strong>Demystified</strong><br />
IDC3351I ** <strong>VSAM</strong> CLOSE RETURN CODE IS 136<br />
Not enough virtual storage was available in the program's address space for<br />
a work area for Close<br />
Figure 2-3 <strong>VSAM</strong> message indicating too small a region size<br />
The portion of the user's private area within each virtual address space that is<br />
available to the user's programs is called the user region (located from the<br />
bottom to top of the private area). The region size is the amount of storage in the<br />
user region available to the job, started task, or TSO/E user. Figure 2-4 shows<br />
the virtual storage layout. For a description of each area, refer to the OS/390<br />
MVS Initialization and Tuning Guide, SC28-1751.<br />
Figure 2-4 Address space layout
Table 2-2 Region JCL parameter<br />
You specify a job's region size by coding the REGION parameter in the JOB or<br />
EXEC statement. The system rounds all region sizes to a 4K multiple. Some jobs<br />
run out of virtual space and abend when:<br />
► The REGION specified is greater that the available private area.<br />
► A private area GETMAIN reaches the limit determined by the IEFUSI exit (the<br />
default is the specified REGION plus 64K) even if there is virtual free space<br />
available.<br />
► A private area GETMAIN cannot be served because no contiguous virtual<br />
free space exists with the required size. This means a collision between the<br />
top-to-bottom and bottom-to-top subpools.<br />
Refer toTable 2-2 to understand how the JCL REGION parameter is interpreted<br />
and how much virtual storage is available, below and above 16 MB, for each step<br />
of a job.<br />
Do not hesitate to increase your job region size, or even avoid it by specifying<br />
REGION=0. Good buffering can reduce the number of I/Os, job elapsed time,<br />
CPU time and device connect, and disconnect time. If your job is I/O bound, then<br />
by giving it enough resources, it executes more quickly. That is a benefit for the<br />
user and for total system performance.<br />
REGION value Region available below 16 MB Region available above 16 MB<br />
0k > REGION < 16 MB Establishes the private area size<br />
below<br />
If your job is experiencing constraints in virtual storage below 16 MB when <strong>VSAM</strong><br />
data sets are opened, you can relieve storage usage below 16 MB by specifying<br />
that <strong>VSAM</strong> allocate the buffers and/or control blocks above 16 MB. For details,<br />
refer to “Locating <strong>VSAM</strong> buffers above 16 MB” on page 81.<br />
2.6.13 Buffering options<br />
32 MB<br />
16 MB > REGION =< 32M All private area below is available 32 MB<br />
32 MB > REGION =< 2G All private area below is available Establishes the private area size<br />
available above 16 MB<br />
0K or 0M All private area below is available All private area above is available<br />
Buffering in virtual storage is an important technique in <strong>VSAM</strong> to improve<br />
performance. You have the possibility of using this technique through the<br />
buffering options.<br />
Chapter 2. Performance 63
64 <strong>VSAM</strong> <strong>Demystified</strong><br />
A <strong>VSAM</strong> resource pool is a set of <strong>VSAM</strong> control blocks plus a buffer pool. These<br />
control blocks are not enough to allow the data set to be processed. At open time<br />
more control blocks are created, which together with the buffer pool form a<br />
structure control blocks. Here are several key aspects for managing a buffer pool:<br />
► The algorithm to keep CIs in the buffers. For random it is LRU, the most<br />
accessed CIs are kept in buffer. For sequential access, it uses the sequential<br />
algorithm, which has two pieces: look ahead for reads and to dispose of any<br />
CI already processed (reads or writes) to make room for the new ones.<br />
► What to do with the CIs updated in the buffers. Should they be stored through<br />
in DASD immediately or later? For random, there is an option called Defer<br />
Write, where the installation decides what to do. For sequential, <strong>VSAM</strong> defers<br />
the write until half of the buffers are ready for the write. <strong>VSAM</strong> Shareoptions<br />
may change this behavior. Refer to “Share options” on page 58.<br />
► The amount of buffers can degrade the performance. For random it is<br />
recommended to have all the index CIs and lots of data CIs in the buffer pool.<br />
For sequential just one index CI buffer (sequence set) and many data CIs<br />
buffers for the look ahead.<br />
► When the same cluster is shared between two applications (for read/write) in<br />
different MVS systems, the coherency of the buffer pool must be guaranteed.<br />
That is, if a CI is altered in a local buffer pool, the other local buffer pool<br />
should reflect such change.<br />
When a buffer's contents are written, using direct access, the buffer's space is<br />
not released. The control interval remains in storage until overwritten with a new<br />
control interval. If your program refers to that control interval, <strong>VSAM</strong> does not<br />
have to reread it. <strong>VSAM</strong> checks to see if the desired control interval is in storage.<br />
This is not valid for share option 4, where buffers used for direct processing are<br />
refreshed for each request.<br />
Buffer space is released when all data sets that are using the buffer pool are<br />
closed, and for the LSR/GSR, the DLVRP macro is issued. If an abend occurs<br />
before closing <strong>VSAM</strong> data sets, the buffers are not flushed by <strong>VSAM</strong> or MVS<br />
Recovery Termination Manager routines. It is left to the application decision<br />
throughout the use of an (E)SPIE/(E)STAE routine to close the data sets and<br />
consequently flush the buffers. For details about ESTAE and ESPIE macros,<br />
refer to OS/390 MVS Programming: Authorized Assembler Services Reference,<br />
Volume 2 (ENFREQ-IXGWRITE), GC28-1765. Pay attention that such routines<br />
do not gain the control when the abend is caused by an operator CANCEL<br />
command. Also there are options (TRAP) in Language Environment® to control<br />
the flush or not flush of those buffers.<br />
Choosing the adequate <strong>VSAM</strong> buffer length and buffering technique is the key to<br />
reducing the number of I/Os and reducing the I/O response time (Tr). More<br />
buffers (either data or index) than necessary might cause excessive paging or
excessive internal processing. There is an optimum point at which more buffers<br />
do not decrease the job elapsed time and device connect time. You can see that<br />
in Table 2-4 on page 71. You should attempt to have data available just before it<br />
is to be used. If data is read into buffers too far ahead of its use in the program, it<br />
can be paged out.<br />
For more efficient use of virtual storage, buffer pools can be shared among data<br />
sets using locally or globally shared buffer pools. There are four types of<br />
resource pools management, called modes, according to the technique used to<br />
manage them:<br />
► Non-Shared Resource (NSR)<br />
► Local Shared Resource (LSR)<br />
► Global Shared Resource (GSR)<br />
► Record Level Shared (RLS)<br />
Those modes are not an attribute of a cluster, but an access option as interpreted<br />
by the Open routine. The same cluster can be opened in NSR by a task and in<br />
LSR by another task, or the same task can open a cluster initially as LSR and<br />
later as NSR. You see details about each one in this chapter, except for RLS. The<br />
exploiter of RLS is mainly CICS.<br />
Buffers are acquired dynamically usually when the data set is opened. However<br />
with LSR/GSR they are acquired by the application program before the Open<br />
through the BLDVRP macro. Also they can be allocated after the Open through<br />
the Dynamic String Addition function. The amount of space for buffers is based<br />
on parameters in effect when the program opens the data set.<br />
One of the major sources for determining how much space should be allocated in<br />
a buffer pool is the Access Control Block (ACB). The system obtains buffer pool<br />
information for <strong>VSAM</strong> data sets as follows:<br />
► DD statements overrides SMS data class information.<br />
► SMS data class<br />
► The program’s ACB<br />
► The catalog entry<br />
► For LSR buffering, the BUFND, BUFNI, BUFFERSPACE and STRNO<br />
parameters do not apply and cannot be overridden by JCL.<br />
Table 2-3 has the parameters that influence buffer pool allocation.<br />
Table 2-3 Parameters affecting buffer allocation<br />
Source Parameter<br />
DD Statement BUFSP, BUFND, BUFNI, and ACCBIAS<br />
Chapter 2. Performance 65
66 <strong>VSAM</strong> <strong>Demystified</strong><br />
SMS data class (ACDS) RECORD ACCESS BIAS (ACCBIAS)<br />
Program’s ACB MACRF=(IN|OUT, SEQ|SKP, DIR)<br />
STRNO=n, BUFSP=n, BUFND=n,<br />
BUFNI=n (1)<br />
SHRPOOL=n (2)<br />
The catalog entry for the data set BUFFERSPACE<br />
Note: (1) Applies only to NSR.<br />
(2) Only for LSR/GSR, connect the ACB to an existent resource pool<br />
You can see how specifications in the MACRF, ACB’s parameter, affects buffering<br />
and data set processing:<br />
► Buffering management: NUB for management of I/O buffers to be done by<br />
<strong>VSAM</strong> or UBF when management of I/O buffers is left up to the user, or a<br />
<strong>VSAM</strong> exploiter as DB2. NUB is the default value.<br />
► <strong>VSAM</strong> buffering modes to be used: NSR (default), LSR, GSR or RLS. These<br />
modes assigning buffers to strings, so the number of strings also affects the<br />
buffering<br />
► The manner in which the records are intended to be accessed: Direct (DIR),<br />
sequential (SEQ), skip sequential (SKP).<br />
► Type of argument used to access records: By key (KEY option), by RBA (ADR<br />
option), by RRN, or access is to the entire contents of a control interval rather<br />
than to an individual data record (CNV). KEY is the default.<br />
► What kind of processing is done in the data set: Input (IN, default) or output<br />
(OUT); this is just an intention.<br />
► How writes are to be managed: defer writes (DFR) or not (NDF). For details<br />
about deferring writes; refer to “Deferring write requests” on page 80.<br />
► Using LSR, how <strong>VSAM</strong> deals with conflict for an exclusive control in buffers:<br />
<strong>VSAM</strong> defers the request until the resource becomes available (LEW, default)<br />
or <strong>VSAM</strong> returns the exclusive control return code X’14’ to the application<br />
program (NLW). The application program is then able to determine the next<br />
action.<br />
► Insert record strategy: Split CIs and CAs at the insert point (SIS) or at the<br />
midpoint (NIS, default) when doing direct PUTs.<br />
In MACRF at ACB, you code the types of access you intend to use during the<br />
processing. They are used mainly for buffering management and at open time. To<br />
process the data set, you use request parameter lists (RPL), where you specify<br />
only the processing options appropriate to that particular request.
If you open a data set whose ACB includes MACRF=(SEQ,DIR), buffers are<br />
allocated according to the rules for sequential processing, NSR buffering<br />
management.<br />
BUFFERSPACE, BUFSP, BUFND, BUFNI affects buffering<br />
The BUFFERSPACE value in the catalog entry for the data set is the minimum<br />
amount of buffer space while the value assigned to BUFSP, in JCL or ACB, is the<br />
maximum amount of buffer space. The BUFFERSPACE value applies to the<br />
whole cluster. Additional buffer space can be assigned to any data set by:<br />
► Modifying the data set's BUFFERSPACE value<br />
► Specifying a larger BUFSP value with the AMP parameter in the data set's DD<br />
statement<br />
If you do not specify BUFSP, the amount of virtual storage used for buffers is the<br />
largest of these values:<br />
► The amount specified in the catalog (BUFFERSPACE)<br />
► The amount determined from BUFND and BUFNI<br />
► The minimum storage required to process the data set with its specified<br />
accessing options, as sequential, direct<br />
The BUFSP value takes precedence over BUFNI and BUFND as follows:<br />
► If the number of buffers specified in the BUFND and BUFNI subparameters<br />
exceed the virtual storage specified in the BUFSP space, the number of<br />
buffers is decreased to fit in the BUFSP space as follows:<br />
– If the ACB indicates direct access only, first the number of data buffers is<br />
decreased until it reaches the BUFSP value, but it never becomes less<br />
than the minimum required. If the BUFSP value is not reached, then the<br />
number of index buffers is decreased until BUFSP is reached.<br />
– For sequential access, BUFNI is decreased to reach BUFSP up to the<br />
minimum plus one. If not reached, BUFND is decreased. When the<br />
minimum is reached, but BUFSP is not reached, than one buffer is<br />
subtracted from the number of index buffers.<br />
► If BUFSP specifies more space than is required by BUFND and BUFNI, the<br />
number of buffers is increased to fill the BUFSP space as follows:<br />
– For direct access only, additional index buffers are allocated.<br />
– For sequential access, one additional index is allocated and as many data<br />
buffers as possible are allocated.<br />
If BUFSP is specified and the amount is smaller than the minimum amount of<br />
storage required to process the data set, <strong>VSAM</strong> cannot open the data set.<br />
Chapter 2. Performance 67
68 <strong>VSAM</strong> <strong>Demystified</strong><br />
When processing a data set using a path, the number of needed buffers<br />
increase, since buffers are needed for the alternate index, the base cluster, and<br />
any alternate indexes in the upgrade set.<br />
When a base cluster is opened for processing with its alternate index, the<br />
BUFSP, BUFND, BUFNI, and STRNO parameters apply only to the path's<br />
alternate index. The minimum number of buffers are allocated to the base cluster<br />
unless the cluster's BUFFERSPACE value (specified in the DEFINE command)<br />
or BSTRNO value (specified in the ACB macro) allows for more buffers. <strong>VSAM</strong><br />
assumes direct processing, and extra buffers are allocated between data and<br />
index components accordingly.<br />
The default for the number of <strong>VSAM</strong> allocation buffers is as follows:<br />
► For the index component: BUFNI=STRNO<br />
► For the data buffers: BUFND=STRNO+1<br />
One of the data buffers (BUFND) is used only for formatting CAs and splitting CIs<br />
and CAs. Only data buffers are needed for ESDS, RRDS, or LDS.<br />
This default is also the minimum number of buffers required by <strong>VSAM</strong>.<br />
Recommendations<br />
Do not specify BUFSP or BUFFERSPACE, take the default value. This avoids<br />
mistakes in calculation leading to different results from those expected. For NSR<br />
use SMB and for LSR it is an exploiter decision.<br />
2.6.14 Buffering techniques<br />
Here is a look at various buffering techniques.<br />
Non-shared resources (NSR)<br />
Non-shared resources (NSR) is the default <strong>VSAM</strong> buffering technique. It has the<br />
following characteristics:<br />
► The buffers are not shared among <strong>VSAM</strong> data sets.<br />
► The buffers are located in the private area.<br />
► It is suited for sequential processing, because the buffers are managed via a<br />
sequential algorithm:<br />
– For sequential processing, there is look-ahead (time permitting CIs not yet<br />
requested are brought to buffer pools), and CIs in the buffer pool are not<br />
managed by LRU (meaning after use by the application program, they are<br />
strong candidates to leave the buffer pool).
– For direct processing, there is no look-ahead (which is good), but CIs are<br />
not managed by LRU (which is bad).<br />
► It is used by high level languages.<br />
► The resource pool (buffer pool plus control blocks) is built automatically by<br />
OPEN accordingly to BUFND, BUFNI, BUFFERSPACE, BUFSPC.<br />
► NSR has specific properties when assigning buffers to strings (or place<br />
holders).<br />
– Each string has its own buffer for the index sequence set component.<br />
Additional index buffers provided (allowed by the buffer parameters) are<br />
used to cache index set records, shared among strings<br />
– Each string has its own buffer for the data component. If additional data<br />
buffers are provided, they are for:<br />
Sequential reads and writes<br />
CA splits<br />
Spanned records<br />
– There is also a buffer for insert records is used only along CI splits.<br />
► It dynamically extends the number of strings as they are needed by<br />
concurrent requests for the ACB.<br />
► For subtask sharing, when a CI is not available for the type of task processing<br />
requested, <strong>VSAM</strong> under NSR buffering has a proper way of managing the<br />
contention. For details, refer to 2.6.10, “Share options” on page 58.<br />
Figure 2-5 shows how NSR buffers are constructed.<br />
Chapter 2. Performance 69
70 <strong>VSAM</strong> <strong>Demystified</strong><br />
User ACB<br />
MACRF=<br />
(NSR,NUB)<br />
Additional index buffers (BUFNI-STRNO)<br />
used to cache index set records<br />
shared among strings<br />
Additional data buffers (BUFND-(STRNO+1))<br />
sequential READS/WRITES<br />
CA splits<br />
spanned records<br />
Figure 2-5 NSR buffering<br />
<strong>VSAM</strong> NSR<br />
STRNO=2<br />
PLH<br />
PLH<br />
BUFNI=3<br />
Buffer 1<br />
Buffer 2<br />
Buffer 3<br />
BUFND=4<br />
Insert Buffer<br />
Buffer 1<br />
Buffer 2<br />
Buffer 3<br />
NSR with sequential access<br />
NSR is best used for applications that use sequential or skip sequential as their<br />
primary access mode.<br />
At initial buffer pool loading for reads on the behalf of a string, <strong>VSAM</strong> NSR loads<br />
the buffers using just one channel program with chained CCWs. The number of<br />
CIs in the channel program is equal to the number string’s assigned buffer plus<br />
all additional buffers to a maximum of CIs/CA, since I/Os are scheduled on CA<br />
boundaries.<br />
When another string, at the same time, needs buffers, <strong>VSAM</strong> uses its assigned<br />
buffer and the remaining buffers to a maximum of CIs/CA, and so forth. So,<br />
having more buffers than CI/CA plus one is useful only when having more than<br />
one string. When a string finishes using its buffers (processed by the application<br />
program associated with the string), additional buffers are available to other<br />
strings.<br />
For overlap between CPU and I/O after initial buffer pool load:<br />
► For sequential reads, once one-half of the buffers is being processed by the<br />
application program, an I/O operation is scheduled for this half. This continues<br />
until a CA boundary is encountered and the application must wait until the last
I/O to the CA is done before proceeding to the next CA. The I/O operations<br />
are always scheduled within CA boundaries.<br />
► For sequential writes, once one-half of the buffers are filled by the application<br />
program with logical records, an I/O operation is scheduled for this half. Then<br />
for sequential PUT processing, <strong>VSAM</strong> NSR does not immediately write the<br />
updated CI from the buffer unless a CI split is required. <strong>VSAM</strong> saves I/O<br />
operations by deferring sequential writes. For details about deferred write<br />
(sequential and direct), refer to “Deferring write requests” on page 80.<br />
When you are accessing data sequentially, you can increase performance by<br />
increasing the number of data buffers, up to a certain limit. When there are<br />
multiple data buffers, <strong>VSAM</strong> uses a read-ahead function to read the next data<br />
control intervals into buffers as buffers become available as described<br />
above.Table 2-4 shows results of tests varying the number of buffers.<br />
Table 2-4 NSR: Read sequential varying the number of buffers.<br />
Data<br />
buffers<br />
Index<br />
buffers<br />
EXCPs Device<br />
connect<br />
time<br />
SRB<br />
time<br />
TCB<br />
time<br />
Default=2 Default=1 167828 23.50 2.12 7.52 120<br />
10 1 33568 14.48 0.53 3.99 36<br />
30 1 11577 11.82 0.26 3.44 22<br />
50 1 6948 11.40 0.21 3.35 19<br />
50 2 6948 11.40 0.21 3.37 19<br />
90 1 4633 11.26 0.18 3.44 18<br />
181 1 3476 11.15 0.19 3.86 14<br />
181 3 3476 11.19 0.19 3.91 19<br />
10000 1 3476 11.16 0.19 3.89 19<br />
SMB 01 Stripe 4633 15.75 0.23 3.45 22<br />
SMB - 02 Stripes 7580 17.11 0.17 3.61 15<br />
SMB - 04 Stripes 14073 19.3 0.17 3.65 11<br />
SMB 08 Stripes 27061 24.30 0.17 3.77 10<br />
Note: All times are in seconds<br />
Elapsed<br />
time<br />
As more buffers are used, the number of Execution Channel Program (EXCPs) is<br />
reduced. This means there are fewer I/O interrupts. That is why SRB time<br />
Chapter 2. Performance 71
72 <strong>VSAM</strong> <strong>Demystified</strong><br />
consumption drops so much compared with TCB time. For a discussion about<br />
what is a <strong>VSAM</strong> EXCP in numerical values, refer to Appendix B, “Miscellaneous<br />
performance items” on page 395. With <strong>VSAM</strong>, the number of EXCPs is equal to<br />
the number of SSCH instructions, that is the number of I/O operations, and not<br />
the number of transferred CIs or transferred physical blocks.<br />
► The TCB time drops due to decrease in I/O preparation. After the optimum<br />
point, the TCB time increase due to excessive buffering management<br />
processing. Remember that our program is just a read and forget, so all the<br />
TCB time is consumed in the I/O process. We recommend you read the in<br />
section “Our test environment” on page 396, for a better understanding of the<br />
test results shown in this book.<br />
With SHAREOPTIONS 4, buffers are refreshed at each request. Also, the<br />
read-ahead (a look-ahead synonym) function has no effect and defer write is not<br />
used. Therefore, for SHAREOPTIONS 4, keeping data buffers at a minimum can<br />
actually improve performance.<br />
The POINT macro does not cause read-ahead processing unless RPL<br />
OPTCD=SEQ is specified. POINT positions the data set for subsequent<br />
sequential retrieval.<br />
Having only one index I/O buffer per string does not hinder performance in a read<br />
sequential access because to access a logical record, <strong>VSAM</strong> gets to the next<br />
index sequence set and uses it for the complete data CA. At end of the CA by<br />
using the horizontal pointers, rather than the vertical pointers in the index set, the<br />
next index sequence set CI is retrieved. Extra index buffers have little effect<br />
during sequential processing. You can see that in Table 2-4.<br />
When reading sequential, buffers are used to balance the ability of the<br />
application to process data with the capacity of the storage device to deliver the<br />
data to the application. One of the factors, that affects the amount of data CI<br />
buffers needed is the number of logical records per data CI, and how heavy is its<br />
processing. In a data CI with many records, the read data buffers are saturated<br />
before a data CI with few records. Saturated means you do not get better<br />
performance by increasing the number of buffers. In this case the CPU<br />
processing become the slower factor.<br />
By specifying enough data buffers, you can access the same amount of data per<br />
I/O operation with small data CIs as with large data CIs.<br />
Table 2-4 contains the results from our lab tests. Remember that, in our lab tests,<br />
the data set record processing is minimal (very I/O-bound). Also notice that we<br />
did not run in a controlled environment, so the elapsed time value can vary<br />
according to priority and system workload. The numeric values are total and not<br />
an average per I/O operation.
If you experience a sequential performance problem waiting for input from the<br />
device, you should specify more data buffers to improve your job's run time. More<br />
data buffers allow you to do more read-ahead processing and less I/O operation<br />
for the same amount of data, which decreases the disconnect time.<br />
If your data set is SMS managed, NSR utilizes extended format, therefore you do<br />
not need to worry about how many buffers to specify for the index or data<br />
component. This means that you can take advantage of system managed<br />
buffering. For details, refer to “System managed buffering (SMB)” on page 82.<br />
Buffering in NSR initial load mode<br />
Initial load mode occurs when you load your data sequentially in a <strong>VSAM</strong> data<br />
set which has a High Used RBA (HURBA) equal to zero. Initial Load uses a NSR<br />
buffering option.<br />
Pay attention to performance aspects of using RECOVERY or SPEED attributes,<br />
Refer to 2.6.11, “Initial load option” on page 59.<br />
There is a difference with index buffers when you compare reading and initial<br />
loading (or extending) sequentially a <strong>VSAM</strong> KSDS cluster. In the first case <strong>VSAM</strong><br />
never refers to the index set, then there is no need to set aside buffers for such<br />
index CIs. However, along Initial loads the index set CIs are built, then there is a<br />
little gain in performance if you provide some buffering for them.<br />
With extended format data sets and SPEED (writing each CA with just one I/O<br />
pass) you can get much better performance using SMB. For details, refer to<br />
“System managed buffering (SMB)” on page 82.<br />
Table 2-5 shows the results of loading an empty data set, with 2,000,000 records,<br />
using IDCAMS REPRO. The best result is obtained when:<br />
Data buffers = 181 = CIs/CA + 1<br />
Index Buffers = 3 (the number of index levels after data set loading)<br />
Table 2-5 NSR - Initial Load mode varying the number of buffers<br />
Data<br />
buffers<br />
Index<br />
buffers<br />
Extended<br />
Format /<br />
stripes<br />
EXCPs Device<br />
connect<br />
time (sec)<br />
CPU<br />
Time<br />
(sec)<br />
Default Default No / 1 27856 41.2 8.65 68<br />
90 Default Yes / 1 13970 24.9 8.08 41<br />
181 Default Yes / 1 13969 24.5 8.08 42<br />
181 3 Yes / 1 12810 24.6 8.08 44<br />
Elapsed<br />
time<br />
(sec)<br />
Chapter 2. Performance 73
Data<br />
buffers<br />
74 <strong>VSAM</strong> <strong>Demystified</strong><br />
Index<br />
buffers<br />
Extended<br />
Format /<br />
stripes<br />
EXCPs Device<br />
connect<br />
time (sec)<br />
360 Default Yes / 1 13969 25.5 8.07 44<br />
10000 3 Yes / 1 13971 24.3 8.06 42<br />
SMB SMB yes / 1 12813 28.4 8.05 48<br />
SMB SMB yes / 2 14153 28.6 8.18 30<br />
SMB SMB yes / 4 11991 20.2 8.2 28<br />
SMB SMB yes / 8 22815 34 8.24 22<br />
NSR with direct access<br />
NSR is not intended for direct or random access. However, many of your<br />
applications may use NSR for direct processing because it is simple. In this topic<br />
we look at how NSR works for direct access. Remember that today you have<br />
solutions available to avoid NSR direct processing without changing your code:<br />
system managed buffering, and batch local shared resources. We cover their<br />
functions later in this chapter.<br />
In direct access, records are randomly accessed by key, RBA or RRN depending<br />
on the data set organization. Increasing data buffers do not boost performance,<br />
because <strong>VSAM</strong> NSR does not implement an LRU algorithm to manage the buffer<br />
pool.<br />
Two good aspects of NSR read direct processing are:<br />
► Does not use look-ahead buffers<br />
► Only reads one CI per GET request<br />
CPU<br />
Time<br />
(sec)<br />
Elapsed<br />
time<br />
(sec)<br />
For direct output processing (PUT for update), <strong>VSAM</strong> defers write only when<br />
OPTCD=NSP option is specified in the RPL macro; otherwise, <strong>VSAM</strong><br />
immediately writes the updated CI.<br />
Within a NSR buffer pool, data and index sequence set buffers are not shared<br />
among strings, refer to “Non-shared resources (NSR)” on page 68. Each string is<br />
associated with one request parameter list (RPL). For example, when an<br />
application uses an RPL to issue a direct GET for a record with a key of 1234<br />
using NSR, <strong>VSAM</strong> manages buffers as follows:<br />
1. <strong>VSAM</strong> locates the correct CI, though a top-down search through the index<br />
set.<br />
2. <strong>VSAM</strong> then reads the data CI into storage and gives the user the requested<br />
record.
3. If the user then issues another direct GET for a record with a key of 6789,<br />
which is in a different CI from record 1234, the same data buffer gets used for<br />
this request, and the CI containing 6789 overlays the CI containing 1234.<br />
4. If the user issues another direct GET for a record with key 1235 (which is in<br />
the same CI as 1234), that CI must be read in again because the intervening<br />
GET for 6789 causes the previous buffer contents to be lost.<br />
This problem cannot be solved by using multiple strings. If, for example, the<br />
requests for 1234, 6789, and 1235 use three different RPLs, both CIs are in<br />
storage when the request for 1235 occurs, but <strong>VSAM</strong> looks only in the buffer<br />
assigned to the string related to RPL requesting 1235 and does not look in<br />
another string's buffers to satisfy the request. The CI has be read in again<br />
anyway.<br />
This NSR characteristic leads to performance complaints in cases where the<br />
processing is random, but the same CI is requested multiple times (re-visiting)<br />
with intervening requests to other CIs.<br />
When the number of I/O buffers provided for index records is greater than the<br />
number of strings, the surplus is shared among the strings:<br />
► One buffer is used for the highest-level index record.<br />
► Additional buffers are used, as required, for other index set index records, as<br />
shown in Figure 2-5 on page 70.<br />
For a KSDS or VRRDS, with NSR direct access, you should provide at least<br />
enough index buffers. It needs to be at least to the value of the STRNO<br />
parameter of the ACB plus one, if you want <strong>VSAM</strong> to always keep the<br />
highest-level index record always resident. You can increase performance by<br />
going beyond such number. Unused index buffers do not degrade performance.<br />
Direct processing always requires a top-down search through the index.<br />
Then, for optimum performance, the number of index buffers should at least<br />
equal the number of high-level index set CIs plus one per string. This makes the<br />
entire high-level index set and one sequence set CI per string in virtual storage.<br />
Table 2-6 shows how adding index buffers improves performance. The elapsed<br />
time can vary according to the system workload. Note that additional index<br />
buffers are not use for more than one sequence set buffer per string.<br />
<strong>VSAM</strong> NSR reads index buffers one at a time (per I/O operation). Index buffers<br />
are loaded when the index is referred to. When many index buffers are provided,<br />
index buffers are not reused for another index CI, until a requested index CI is not<br />
in storage.<br />
<strong>VSAM</strong> NSR keeps as many index set records as the buffer space allows in virtual<br />
storage. Ideally, the index would be small enough to allow the entire index set to<br />
Chapter 2. Performance 75
76 <strong>VSAM</strong> <strong>Demystified</strong><br />
remain in virtual storage. Then, you should be aware of how index I/O buffers are<br />
used so you can determine how many to provide.<br />
Many data buffers do not increase performance, because only one data buffer is<br />
used for each access, as you can see in Table 2-6. The elapsed time can vary<br />
according to the system workload.<br />
Table 2-6 NSR buffering with direct access; STRNO=1<br />
Data Buffers Index<br />
Buffers<br />
EXCPs Device<br />
Connect time<br />
(sec)<br />
CPU time<br />
(sec)<br />
Default Default 794950 103.34 31.76 506<br />
90 1 794950 103.34 32.42 506<br />
Default 3 505171 76.67 21.11 326<br />
Default 5 445160 62.32 18.87 291<br />
Default 50 368823 51.64 16.36 242<br />
Elapsed<br />
time<br />
(sec)<br />
Default 1200 368823 51.64 17.13 243<br />
If your job is having performance problems randomly accessing <strong>VSAM</strong> data sets<br />
in NSR mode, you can improve performance with no changes in your<br />
applications, as follows:<br />
► If your data set is SMS managed, has extended format, and your installation<br />
has DFSMS V1R4 or later, you can use system managed buffering. For<br />
details, refer to “System managed buffering (SMB)” on page 82.<br />
► If the above conditions are not met, you can use BLSR. For details, refer to<br />
“Batch local shared resources (BLSR)” on page 92.<br />
Refer to “Sample programs extract from SMF record type 64” on page 367 for<br />
information that can help you find data sets which are candidates to use SMB or<br />
BSLR. Both offer real gains for direct access.<br />
If your data set meets both requirements for SMB and BLSR, use SMB, for better<br />
results.<br />
Recommendations<br />
For NSR, we recommend:<br />
► For sequential processing, use SMB to get an optimum buffering, or:<br />
BUFNI = Number of levels<br />
BUFND = Number of CI/CA plus one
Additional data buffers, when STRNO higher than one<br />
► For direct access, use SMB or BLSR to convert to LRU algorithm, or in a<br />
worst case keep NSR with:<br />
BUFNI = STRNO plus number of levels<br />
BUFND = Let the default value (STRNO plus one)<br />
NSR with mixed access<br />
The best advice here is still to suggest SMB or BLSR. If you need to keep NSR<br />
then, for mixed access situations (sequential and direct), you can improve<br />
performance by doing the following:<br />
► Increase the number of index component buffers to the number of index<br />
levels, to favor direct access. Table 2-6 shows how the number of index<br />
component buffers can improve performance for direct access.<br />
► Increase the number of data component buffers, to favor sequential access.<br />
Table 2-4 on page 71 shows how this can improve performance, based on<br />
tests in our lab.<br />
Local Shared Resources (LSR)<br />
This is another mode of managing <strong>VSAM</strong> buffers. In this mode, the buffers in a<br />
LSR pool:<br />
► Are shared among <strong>VSAM</strong> data sets accessed by tasks in the same address<br />
space. It is a centralized way for buffer management. Instead of having<br />
individual buffer pools (some very much utilized, some not), we have a large<br />
one shared by several <strong>VSAM</strong> data sets, improving the utilization of the<br />
resource.<br />
► Are explicitly constructed through BLDVRP macro, before the OPEN for the<br />
first data set that uses it.<br />
► Are explicitly deleted by the DLTVRP macro.<br />
► Are located in the private area and ESO hiperspace (if specified in BLDVRP<br />
macro).<br />
► Its CIs are replaced based on the least recently used (LRU) algorithm, which<br />
is designed for random processing.<br />
► Have no look-ahead, even for sequential processing.<br />
► Usually implemented only by CICS.<br />
► For subtask sharing, when a CI is not available (locked) to the task for the<br />
type of processing requested, <strong>VSAM</strong> under LSR and GSR buffering has a<br />
proper way of managing the contention. For details, refer to 2.6.10, “Share<br />
options” on page 58.<br />
Chapter 2. Performance 77
78 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Applications using LSR can invalidate BP contents through MRKBFR macro<br />
and force them to be written immediately through WRTBFR macro.<br />
LSR relieves virtual storage constraint and reduces I/O for applications that<br />
access the same data multiple times. This technique is best used for truly<br />
random access, with multiple references to the same data. Subsequent access<br />
to data does not have to go through DASD.<br />
With LSR (and GSR), the number and size of buffers are specified in BLDVRP<br />
macro (see Figure 2-6) and are not overridden by ACB or JCL. The buffer pool is<br />
identified by a number and a data set is connected to it through the ACB macro,<br />
where the buffer pool ID is specified. After all data sets using a resource pool are<br />
closed, the resource pool can be delete issuing the DLVRP (delete <strong>VSAM</strong><br />
resource pool) macro. For more details about macros, refer to DFSMS/MVS<br />
Macro Instructions for Data Sets, SC26-4913.<br />
User ACB<br />
MACRF=<br />
(NSR,NUB)<br />
User ACB<br />
MACRF=<br />
(NSR,NUB)<br />
INDEX<br />
Data<br />
INDEX<br />
Data<br />
User ACB<br />
MACRF=<br />
(NSR,NUB)<br />
INDEX<br />
Data<br />
Buffers and I/O related control blocks<br />
associated with a pool (BLDVRP)<br />
Multiple data sets share pooled resources<br />
Figure 2-6 <strong>VSAM</strong> shared resources (LSR/GSR)<br />
Buffers and I/O related<br />
control blocks<br />
Online transaction program (OLTP) applications like CICS and IMS are the<br />
biggest users of LSR shared resources because they typically need to have<br />
hundreds of data sets open in one address space at any given time. Having an<br />
individual buffer pool for each data set would be a waste of virtual storage. With
CICS and IMS, the BLDVRP is issued by them, not directly by the user<br />
application. Information for building the shared buffer pool is specified in the<br />
product FCT table (for CICS). Refer to the product manuals.<br />
With LSR and GSR, writes can be deferred until <strong>VSAM</strong> needs a buffer to satisfy a<br />
GET request. Deferring writes saves I/O requests in cases where subsequent<br />
requests can be satisfied by the data already in the buffer pool. For more details,<br />
refer to “Deferring write requests” on page 80.<br />
The search for a CI in the buffer pool is not affected by the pool size once the<br />
search is by hashing, so there is no overhead. Also, with LSR buffering, your<br />
application can use hiperspace as a second level of buffering. If you intend to<br />
build an application using LSR buffering techniques:<br />
► Note that LSR is suited for direct access; for sequential access, use NSR.<br />
► Build resource pools before any open to the data sets that use them.<br />
► Build a separate resource pool for indexes to avoid index data being flushed<br />
by data being read.<br />
► Use defer write if possible.<br />
For details on how to build an LSR pool, refer to DFSMS/MVS Using Data Sets,<br />
SC26-4922.<br />
LSR with direct access<br />
LSR buffering mode is designed for direct access. If your applications use NSR<br />
buffering and direct access, and you are having performance problems, you can<br />
take advantage of LSR buffering techniques using SMB or BLSR.<br />
Refer to “System managed buffering (SMB)” on page 82, and “Batch local shared<br />
resources (BLSR)” on page 92.<br />
LSR with sequential access<br />
As we said, LSR buffering mode is designed for random access, not sequential. If<br />
you are relying on sequential look-ahead (also called read-ahead) for good<br />
performance LSR buffering could degrade, rather than improve performance.<br />
LSR does not do read-ahead. Your sequential request is read in just one data CI<br />
per I/O operation. You should use NSR buffering, where <strong>VSAM</strong> can read up to a<br />
CA's worth of data CIs in a single I/O, conditions permitting. For details about<br />
NSR, refer to “NSR with sequential access” on page 70.<br />
Chapter 2. Performance 79
80 <strong>VSAM</strong> <strong>Demystified</strong><br />
Recommendations<br />
If you intend for your batch application to use the LSR buffering technique, we<br />
recommend you:<br />
1. Write the application using the default buffering NSR. It is easier and you can<br />
use a high level language, such as COBOL.<br />
2. Use SMB to convert to LSR when processing or BLSR if there is no SMS.<br />
Global Shared Resources (GSR)<br />
GSR is similar to LSR buffering technique. The GSR characteristics that differ<br />
from LSR are:<br />
► The buffer pool is shared among <strong>VSAM</strong> data sets accessed by tasks in<br />
multiple address spaces in the same system image.<br />
► Buffers are located in CSA.<br />
► The code using this must be in supervisor state.<br />
► Buffers cannot use hiperspace.<br />
► The separate index resource pools are not supported for GSR.<br />
With these differences in mind, refer to “Local Shared Resources (LSR)” on<br />
page 77, for details on how GSR buffering technique works.<br />
GSR is not used by any of the main <strong>VSAM</strong> exploiters.<br />
The disadvantages of GSR are:<br />
► Use of common area, a limited resource in the system<br />
► The address space that opened the data set for the first time must remain<br />
started to allow acquire new space to the data set.<br />
► The allowed number of resource pools is one by storage key number (0-7).<br />
► All <strong>VSAM</strong> requests related to the global resource pool may be issued only by<br />
a program in supervisor state with the same protection key as the resource<br />
pool.<br />
► Workload balancing: you cannot distribute the workload between system<br />
images and keep a single control block structure.<br />
Recommendations<br />
Do not use GSR mode for buffering, use RLS.<br />
Deferring write requests<br />
Specify defer write, if possible in the ACB. With defer write, <strong>VSAM</strong> uses the buffer<br />
pool in a store in mode. That is, the updates are not propagated immediately to
DASD. They are deferred until the WRTBFR macro is issued or until <strong>VSAM</strong><br />
needs a buffer to satisfy a GET request.<br />
The performance advantages of deferring writes are these:<br />
► If the same record is updated n times and is then written asynchronously to<br />
DASD, you save n-1 I/O operations. It is clear that, if there are no further<br />
updates, there are no saves.<br />
► The application issuing the write does not wait for the I/O operation.<br />
The negative aspect of deferring writes is that <strong>VSAM</strong> does not have a log (at<br />
present). If the system fails before the buffer destage, you lose some updates in<br />
your data set. So it is up to you to make the decision based on the type of data<br />
you are processing.<br />
The Defer Write option is only valid for LSR and GSR. The defer write option is<br />
bypassed in LSR and GSR if SHAREOPTIONS 4 is specified. Refer to 4.3,<br />
“Sharing <strong>VSAM</strong> data sets” on page 212.<br />
When NSR defer write is used, with the exception of SHAREOPTIONS 4, the<br />
buffers are immediately refreshed.<br />
You specify that writes are to be deferred by coding MACRF=DFR in the ACB,<br />
along with MACRF=LSR or GSR:<br />
ACB MACRF=({LSR|GSR},{DFR| NDF},...),...<br />
In RLS mode, deferred writes are ignored and direct request modified buffers are<br />
immediately written to disk and the coupling facility.<br />
Locating <strong>VSAM</strong> buffers above 16 MB<br />
The default <strong>VSAM</strong> allocation for a resource pool is below 16 MB line. The<br />
exception is SMB, where the default is above 16 MB line. The location of the<br />
buffers and I/O control blocks can be controlled using:<br />
► In an assembler application program:<br />
– For NSR buffering, in the RMODE31 keyword in ACB<br />
– For LSR/GSR buffering, in BLDVRP macro<br />
► In the JCL, through RMODE31 parameter on the DD statement<br />
The values you may specify for RMODE31 follow:<br />
► ALL is used to allocate I/O relate control blocks and buffers above 16 MB.<br />
IDCAMS does not accept this value because it only accesses control blocks<br />
below the 16 MB line.<br />
► BUFF is used only to allocate buffers above 16 MB.<br />
Chapter 2. Performance 81
82 <strong>VSAM</strong> <strong>Demystified</strong><br />
► CB is used only for I/O relate control blocks above 16 M. IDCAMS does not<br />
accept this value because it only accesses control blocks below the 16 M line<br />
► NONE is the default. <strong>VSAM</strong> allocates I/O related control blocks and buffers<br />
below 16 M.<br />
With the flexibility of JCL, you can avoid the necessity of changing an existing<br />
application. But be aware that programs with AMODE=24 can abend with S0C4<br />
when locate mode is used and RMODE31=BUFF is specified.<br />
Locate mode is used when OPTCD=LOC is specified in the RPL, and indicates<br />
to <strong>VSAM</strong> to return to the application the address of the record, which is located in<br />
the buffer. Using locate mode, programs addressing 24 bits cannot access data<br />
above 16 MB (addressing 31 bits).<br />
There is also a move mode, where <strong>VSAM</strong> moves your logical record from the<br />
buffer to a user area your program specifies.<br />
COBOL for OS/390 always:<br />
► Uses MVE mode; <strong>VSAM</strong> moves the record to an area whose address is<br />
indicated in the RPL, built by COBOL.<br />
► Requires <strong>VSAM</strong> buffers above 16 MB.<br />
You can relieve the storage constraint below 16 MB for application programs<br />
using <strong>VSAM</strong> data sets by specifying RMODE31 in the AMP parameter. You can<br />
increase the number of buffers with no effect on virtual storage below 16 MB. Do<br />
not forget to specify enough private area above. Refer to 2.6.12, “Region size” on<br />
page 61.<br />
Recommendation<br />
We recommend you use <strong>VSAM</strong> buffers above 16 MB.<br />
System managed buffering (SMB)<br />
SMB was introduced in DFSMS V1R4 and is available to all <strong>VSAM</strong> data sets<br />
open for NSR processing. SMB enables <strong>VSAM</strong> to determine the optimum<br />
number of index and data buffers, as well as the type of buffer management: LSR<br />
(LRU, lots of index buffers, lost of data buffers containing 20% of data, no<br />
look-ahead) or NSR (discard the ones already processed, just one index buffer,<br />
look-ahead).<br />
SMB allocates, at Open time, the optimum number of data and index buffers<br />
based on the type of access declared in the ACB’s MACRF parameter. Usually<br />
SMB allocates much more buffers than without SMB. Then, the installation<br />
should allow a larger virtual storage, as making Region equal to zero. If the
Region is not enough, you may receive the following message: IEC161I<br />
001(8,36).<br />
Performance improvements can be dramatic with random access, particularly if<br />
you have little buffering, due to defaults, because SMB enlarges the number of<br />
buffers and switches from NSR mode to LSR mode as bufferpool managing is<br />
concerned. This can be seen in Table 2-7 on page 86.<br />
When processing a <strong>VSAM</strong> data set, using SMB, and SMB switches to LSR<br />
mode, you can receive the message IEC161I 001(8,36)-087. It is issued due an<br />
error building the <strong>VSAM</strong> resource pool (BLDVRP macro) and indicates that there<br />
was not enough virtual storage to satisfy the request done by SMB. SMB gets the<br />
available storage and processing goes on. To get optimum SMB buffering, you<br />
should provide enough virtual storage. Refer to 2.6.12, “Region size” on page 61.<br />
You can relieve the use of storage below 16 MB by specifying that <strong>VSAM</strong><br />
allocates buffers above16 MB. Refer to “Locating <strong>VSAM</strong> buffers above 16 MB” on<br />
page 81.<br />
SMB is available under the following conditions:<br />
► The data set must be in extended format. To be in extended format, the data<br />
set must be system managed (SMS) and use a data class defined with<br />
DSNTYPE=EXT. For details about extended format; refer to 1.9, “Extended<br />
format data set” on page 28.<br />
► In the application program, ACB must be NSR and MACRF keyword cannot<br />
contain:<br />
– ICI data list: Improved control interval processing.<br />
– UBF: Management of I/O buffers left up to the <strong>VSAM</strong> user, as in DB2.<br />
– For releases prior to z/OS 1.3 DFSMS, processing the data set through<br />
the alternate index of the path specified in the DDname is not supported.<br />
When the conditions above are not satisfied, the job does not abend, but the<br />
SMB services are not used and no messages are issued.<br />
You can invoke SMB services through one of the following methods:<br />
► Using a data class defined with RECORD_ACCESS_BIAS<br />
► Specifying ACCBIAS in the AMP parameter of JCL DD statement<br />
The order of precedence for specifying values are shown in the SOURCE column<br />
in Table 2-3 on page 65.<br />
Both parameters can be used to specify access bias with a subparameter<br />
ACCBIAS, where you specify the type of buffering management technique. You<br />
can specify ACCBIAS equal to one of the following values:<br />
Chapter 2. Performance 83
84 <strong>VSAM</strong> <strong>Demystified</strong><br />
► SYSTEM: Let the system determine the buffering technique, based on:<br />
– The ACB’s MACRF type of access intention: sequential, direct, or skip<br />
sequential, or a combination, and<br />
– The Storage Class specifications: read or write bias for sequential direct<br />
access and MSR.<br />
One of the four techniques is used (DO, DW, SO or SW). Refer to Table 2-8<br />
on page 86. Those are explained in sequence.<br />
The MACRF type of access is just an intention. The real type of access is<br />
declared per I/O operation in the RPL If you know in advance that the MACRF<br />
is not correct (by talking to the programmer, for example). You must give a<br />
hand by telling it the real type of access.<br />
Also in MACRF all the accessing types maybe specified, not helping SMB in<br />
discovering the best buffer management method. This situation also happens<br />
in COBOL when ACCESS MODE IS DYNAMIC is used. It means all of them<br />
(direct, sequential and skip sequential) are declared in the MACRF. To help<br />
SMB there are the following parameters:<br />
– DO: SMB optimizes buffers management to direct access. SMB changes<br />
the buffering management to LSR and allocates the adequate number of<br />
buffers for direct processing.<br />
– DW: To indicate to SMB that the processing is mixed direct and sequential,<br />
but with dominance of direct access. So, more index buffers are allocated<br />
to support direct processing but some buffers will be reserved for data to<br />
help any sequential processing that might occur. The buffering<br />
management technique is changed to LSR.<br />
– SO: Indicates to SMB to optimize buffer allocations for sequential<br />
processing. More data buffers (less index buffers) are allocated to support<br />
sequential access.<br />
– SW: Specifies mixed processing, but with dominance of sequential<br />
access. SMB optimizes buffer handling for sequential processing<br />
allocating more data buffers, but buffers will be reserved for index to help<br />
direct access. SMB is faster than NSR for sequential process, as indicated<br />
in Table 2-9 on page 87.<br />
► USER: Bypass SMB. This is the default if you code no specification for the<br />
ACCBIAS subparameter. This default is not used when the data class<br />
specifies RECORD_ACCESS_BIAS.<br />
For direct optimization (DO), you can use the following DD AMP parameters (not<br />
present in the data class) to tell the LSR buffer manager how to handle the<br />
processing of the buffers:
► SMBVSP: Specifies the amount of virtual storage to obtain for buffers when<br />
opening the data set. Used to override the default buffer space to be obtained,<br />
which is calculated assuming that 20% of the data accounts for 80% of the<br />
accesses. The buffer space acquired is split across two LSR pools: one for<br />
the index and one for the data. The specification can be done in either of two<br />
formats:<br />
– SMBVSP=nnK<br />
– SMBVSP=nnM<br />
► SMBHWT: Used to allocate hiperspace buffers based on a multiple of the<br />
number of address space virtual buffers that have been allocated. It can be an<br />
integer from 0 to 99. The value specified is not a direct multiple of the number<br />
of virtual buffers that are allocated to the resource pool, but act as a weighting<br />
factor for the number of hiperspace buffers to be established. The hiperspace<br />
size buffer will be a multiple of 4K. These buffers may be allocated for the<br />
base data component of the sphere. If the CI size of the data component is<br />
not a multiple of 4K, both virtual space and hiperspace is wasted. The default<br />
is 0 and means that hiperspace is not used.<br />
► SMBDFR: Allows the user to specify whether writing the data from a buffer to<br />
DASD can be deferred until the buffer is required for another request or the<br />
data set is closed. By the way, a CLOSE macro invoked with TYPE=T<br />
(temporary, does not need an OPEN to restart processing) option does not<br />
write the buffers to DASD when LSR processing is used for direct<br />
optimization. The format is:<br />
SMBDFR=Y or N<br />
Y is the default for SHAREOPTIONS (1,3) and (2,3)<br />
N is the default for SHAREOPTIONS (3,3), (4,3) and (x,4)<br />
Table 2-7 shows the benefits of using SMB, compared with the use of BLSR,<br />
refer to “Batch local shared resources (BLSR)” on page 92 and buffering default.<br />
When we ran our test, we had 61 CA splits. Some CPU time was due to<br />
managing these splits; allocating extents, and data set catalog entry update. For<br />
considerations on CA and CI splits, see 1.5.12, “Splits” on page 15.<br />
If you specify RECORD_ACCESS_BIAS=SYSTEM in the data class, you should:<br />
► Rely on the MACRF accessing options (in MACRF we trust)<br />
► Make sure that MACFR only has one access type<br />
► Ensure that storage class bias parameters is correctly set<br />
You can also see that for extended format data sets, you can get performance<br />
enhancements, even with default buffering. In our lab tests (refer to Table 2-7),<br />
the number of EXCPs, CPU time, and connect time is less than non-extended<br />
Chapter 2. Performance 85
86 <strong>VSAM</strong> <strong>Demystified</strong><br />
format data sets. For details on why this happens, see “Use of extended format”<br />
on page 134.<br />
Table 2-7 Direct access: benefits of using SMB: Updates and insertions<br />
Ext format Buffering EXCPs connect<br />
time (sec)<br />
CPU time<br />
(sec)<br />
No Default 861744 123.51 51.37 843<br />
Yes Default 764332 120 50.32 809<br />
No BLSR 330852 73.13 24.42 245<br />
Yes SMB<br />
(System)<br />
280276 62.5 19.22 189<br />
Gain using SMB (%) 67 50 62.5 78<br />
When SYSTEM is specified, the parameters used to determine how buffers are<br />
allocated and managed are:<br />
► ACB’s MACRF values of SEQ, DIR, and SKP<br />
► The storage class values for BIAS and MSR<br />
Table 2-8 shows how ACB’s MACRF and storage class BIAS parameters affect<br />
the buffer allocation and management when SYSTEM is specified.<br />
Table 2-8 Some effects of ACB’s MACRF and storage class BIAS parameters<br />
ACB MACRF parameters<br />
Storage class BIAS<br />
Elapsed<br />
time (min)<br />
SEQ DIR Both None<br />
MACRF=DIR DW DO DO DO<br />
MACRF=SEQ (default) SO SW SO SO<br />
MACRF=(SEQ,SKP) SO SW SW SW<br />
MACRF=SKP DW DW DW DW<br />
MACRF=(DIR,SEQ) or (DIR,SKP)<br />
or (DIR,SEQ,SKP)<br />
SW DW DW DW<br />
Note: DO=Direct Optimized; DW=Direct Weighted; SO=Sequential Optimized;<br />
SW = Sequential Weighted<br />
Table 2-9 shows the results when loading our laboratory data set using default<br />
buffering and SMB. You can see, the results are the same using sequential<br />
optimization (SO) or SYSTEM. For details about our lab, refer to “General lab<br />
description” on page 396.
Table 2-9 Initial load mode comparing SMB with no-SMB buffering<br />
Extended<br />
format<br />
Buffering EXCPs Connect<br />
time<br />
Retry capability for Direct Optimized technique (DO)<br />
In z/OS 1.3 DFSMS, retry capability was added to DO technique. SMB tries to:<br />
1. Obtain storage buffers to about 20% of data set records plus to buffer the<br />
entire index component, if the <strong>VSAM</strong> organization is keyed.<br />
2. Reduce the numbers of buffers by 50% from the optimum amount for the data<br />
components and retry.<br />
3. Reduce the number of data buffers to the minimum and retry. The minimum<br />
size is 1 MB.<br />
4. Reduce the number of index buffers to the minimum and retry. The minimum<br />
is the amount of virtual storage to contain the entire index set plus 20% of the<br />
sequence set records.<br />
If none of the retries above is successful, change to Direct Weighted (DW).<br />
Messages related with SMB<br />
Messages related to SMB are listed below:<br />
► IEC161I 001(sfi)-032:<br />
CPU time Elapsed<br />
time<br />
No NSR - Default 27856 41.2 8.65 68<br />
Yes ACCBIAS=SO 12813 28.4 8.04 48<br />
Yes ACCBIAS=SYSTEM 12813 28.4 8.05 48<br />
Gain using SMB (%) 54 30 7 30<br />
Note: All times are shown in seconds<br />
sfi is 101, 102 or BLDVRP return and reason code. For BLDVRP return<br />
codes, refer to “Return Codes from Macros Used to Share Resources Among<br />
Data Sets” in z/OS DFSMS Macro Instructions for Data Sets, SC26-7408.<br />
► IEC161I 001(sfi)-033: means that SMB did not return ACCBIAS.<br />
► IEC161I 001(sfi)-034: sfi is for CATALOG LOCATE ERROR.<br />
SMB support for AIX<br />
With z/OS DFSMS R1.3, <strong>VSAM</strong> data sets using alternate indexes and SMB have<br />
a better performance. Now SMB supports data sets with alternate indexes for the<br />
DO technique and better size the resources needed for processing with non-DO<br />
technique.<br />
Chapter 2. Performance 87
88 <strong>VSAM</strong> <strong>Demystified</strong><br />
Using SMB, the buffer allocation and buffering technique used depends on:<br />
► The order in which the components are opened:<br />
– Base Cluster<br />
– Path Cluster<br />
– The ACCBIAS informed by the user or detected by SMB<br />
– Where <strong>VSAM</strong> control blocks exist, in such a case, there are already<br />
buffers:<br />
When connecting to the existing structure, just add more buffers to<br />
existing pool.<br />
When connecting is not possible, build new control blocks and new<br />
buffers, using SHAREOPTIONS, to enforce the sharing rules.<br />
During OPEN time, the decision to share a control block structure is based on<br />
DSN and DDN sharing criteria. For sharing criteria refer to “Using a single <strong>VSAM</strong><br />
control block structure” on page 221.<br />
Table 2-10 presents how SMB allocates buffers when a <strong>VSAM</strong> control block<br />
structure exists for the components, when sharing by data set name<br />
(MACRF=DSN).<br />
Table 2-10 SMB: AIX support with Data Set Name Sharing (MACRF=DSN)<br />
OPEN BASE CLUSTER:<br />
Current<br />
ACCBIAS<br />
User<br />
ACCBIAS a<br />
COMPONENT SHARE<br />
OPTIONS<br />
DO DO or blank All Does not<br />
matter<br />
BUFFERS<br />
Connect in the<br />
existing structure<br />
and LSR pool<br />
DO Non DO Base Cluster Apply See Note b<br />
Upgrade<br />
AIXes c<br />
BUFNI=# levels<br />
BUFND=2<br />
Non-DO DO All Apply See note b
OPEN BASE CLUSTER:<br />
Current<br />
ACCBIAS<br />
User<br />
ACCBIAS a<br />
Non-DO Non-DO or<br />
blank<br />
OPEN PATH CLUSTER:<br />
Base Cluster Does not<br />
matter<br />
UPGRADE<br />
AIXes e<br />
Does not<br />
matter<br />
DO DO or blank All Does not<br />
matter<br />
Table 2-11 SMB: AIX support with DDname Sharing (MACRF=DDN)<br />
More BUFND and<br />
BUFNI added to<br />
current pool d<br />
BUFNI=# levels<br />
BUFND=2<br />
Connect in the<br />
existing structure<br />
and LSR pool<br />
DO Non DO Base Cluster Apply See note b<br />
UPGRADE<br />
AIXes c<br />
Apply BUFNI=# levels<br />
BUFND=2<br />
Non DO DO All Apply See note b<br />
Non DO Non-DO or<br />
blank<br />
Path AIX Does not<br />
matter<br />
UPGRADE<br />
AIXes<br />
Does not<br />
matter<br />
More BUFND and<br />
BUFNI added to<br />
current pool d<br />
BUFNI=# levels<br />
BUFND=2<br />
a. ACCBIAS specified by the user in the DDname being opened<br />
b. A new <strong>VSAM</strong> control block structure is used and SMB allocates buffers according<br />
to user ACCBIAS or ACCBIAS detected by SMB.<br />
c. When open intention for UPGRADE components is for OUTPUT<br />
d. When SMB detects ACCBIAS=DO, SMB treats as DW.<br />
e. For UPGRADE components, If this is the first OPEN for OUTPUT.<br />
Table 2-11 presents how SMB allocates buffers when sharing by DDname, that is<br />
MACRF=DDN in ACB.<br />
OPEN BASE CLUSTER:<br />
Current<br />
ACCBIAS<br />
User<br />
ACCBIAS a<br />
COMPONENT SHARE<br />
OPTIONS<br />
BUFFERS<br />
COMPONEN; SHAREOPTIONS BUFFERS<br />
DO DO or blank All Does not matter Connect in the<br />
existing structure<br />
and LSR pool<br />
Chapter 2. Performance 89
90 <strong>VSAM</strong> <strong>Demystified</strong><br />
OPEN BASE CLUSTER:<br />
Current<br />
ACCBIAS<br />
User<br />
ACCBIAS a<br />
DO Non DO Base Cluster Apply See Note b<br />
Upgrade<br />
AIXes c<br />
Apply BUFNI=# of levels<br />
BUFND=2<br />
Non-DO DO All Apply See note b<br />
Non-DO Non-DO or<br />
blank<br />
OPEN PATH CLUSTER:<br />
Base Cluster Does not matter More BUFND and<br />
BUFNI added to<br />
current pool d<br />
UPGRADE<br />
AIXes e<br />
Does not matter BUFNI=# of levels<br />
BUFND=2<br />
DO DO or blank All Does not matter Connect in the<br />
existing structure<br />
and LSR pool<br />
DO Non DO Base Cluster Apply See note B<br />
UPGRADE<br />
AIXes c<br />
Apply BUFNI=# of levels<br />
BUFND=2<br />
Non-DO DO All Apply See Note f<br />
Non-DO Non-DO or<br />
blank<br />
COMPONEN; SHAREOPTIONS BUFFERS<br />
Path AIX Does not matter More BUFND and<br />
BUFNI added to<br />
current pool d<br />
UPGRADE c Does not matter BUFNI=# of levels<br />
BUFND=2<br />
a. ACCBIAS informed by the user in the DDname being opened<br />
b. A new <strong>VSAM</strong> control block structure is used and SMB allocates buffers according<br />
to user ACCBIAS or ACCBIAS detected by SMB.<br />
c. When open intention for UPGRADE components is for OUTPUT<br />
d. When SMB detects ACCBIAS=DO, SMB treats as DW.<br />
e. For UPGRADE components, If this is the first OPEN for OUTPUT.<br />
f. A new <strong>VSAM</strong> control block structure is used and SMB builds an LSR pool.<br />
Table 2-12 shows how SMB allocates buffers when there is no control block<br />
structure. This means, at the first OPEN.
Table 2-12 SMB: AIX support for DO, no <strong>VSAM</strong> control block structures<br />
OPEN ACCBIAS a<br />
Table 2-13 shows the amount of processing per compressed read or write<br />
operations that we found in our lab environment.<br />
Table 2-13 SMB: AIX support for non DO<br />
COMPONENT BUFFERS<br />
Base Cluster DO All LSR Pool<br />
Non DO Base Cluster SMB b<br />
Upgrade AIXes c<br />
BUFNI=# of levels<br />
BUFND=2<br />
Path Cluster DO All LSR Pool<br />
Non DO Base Cluster SMB allocates buffers<br />
for ACCBIAS=DW<br />
Upgrade AIXes d c BUFNI=# of levels<br />
BUFND=2<br />
Path AIX According to<br />
ACCBIAS or<br />
processing intention<br />
a. User informed or detected by SMB<br />
b. SMB allocates buffers according to user ACCBIAS or detected by SMB.<br />
c. When open intention is for output and is the first open<br />
d. Add to the Path AIXes if it is defined as UPGRADE<br />
OPEN COMPONENT BUFFERS<br />
MACRF=DDN Base Cluster Base Cluster according to ACCBIAS or<br />
processing intention<br />
Upgrade AIXes BUFNI=# of levels<br />
BUFND=2<br />
Pathname Base Cluster SMB allocates buffers for<br />
ACCBIAS=DW<br />
Path AIX according to ACCBIAS or<br />
processing intention<br />
Upgrade AIXes<br />
a<br />
BUFNI=# of levels<br />
BUFND=2<br />
Chapter 2. Performance 91
92 <strong>VSAM</strong> <strong>Demystified</strong><br />
OPEN COMPONENT BUFFERS<br />
MACRF=DDN Pathname Base Cluster SMB allocates buffers for<br />
ACCBIAS=DW<br />
Path AIX according to ACCBIAS or<br />
processing intention<br />
Upgrade AIXes a BUFNI=# of levels<br />
BUFND=2<br />
Base Cluster Base Cluster according to ACCBIAS or<br />
processing intention<br />
Upgrade AIXes a BUFNI=# of levels<br />
BUFND=2<br />
Path AIX according to ACCBIAS or<br />
processing intention<br />
a. When OPEN for output for the first time.<br />
Batch local shared resources (BLSR)<br />
BLSR is a subsystem that provides advantages in an application using <strong>VSAM</strong><br />
NSR buffering techniques to switch to LSR without changing the application<br />
source code or link-editing the application again. Only a JCL change is required.<br />
Your application performance will improve using BLSR when direct access is<br />
used and the same CI is referenced more than once in the processing. Using the<br />
BLSR subsystem with sequential access could degrade performance rather than<br />
improve it. For information about how LSR works, see “Local Shared Resources<br />
(LSR)” on page 77.<br />
For mixed processing (some direct, some sequential), you may benefit from<br />
using BLSR. If the amount of data to be processed sequentially is not very large,<br />
you can compensate for the lack of read-ahead by using a large data CI size.<br />
BLSR supports the <strong>VSAM</strong> data set types KSDS, ESDS, RRDS and VRRDS.<br />
Using BSLR, you can force <strong>VSAM</strong> buffers and control blocks to be located above<br />
16 MB without having to use hiperspace. You can also use hiperspace, and you<br />
can restrict its use with RACF or an equivalent security software.<br />
The BLSR subsystem has the following restrictions:<br />
► The ACB cannot be above 16 MB. Otherwise, the system fails the OPEN<br />
request with error message IEC190I.
► If the application closes and then reopens the ACB without refreshing the<br />
DDNAME, the request is bypassed, and the data set is opened using the<br />
same options as the last time it was opened.<br />
That is, if the data set was previously opened for LSR processing, then it is<br />
reopened for LSR. Similarly, if the data set was not eligible for LSR processing<br />
the first time, then it is reopened for NSR processing, even if LSR is now<br />
applicable.<br />
High-level languages refresh the DDNAME for each open. Consequently, the<br />
subsystem is always called for:<br />
► COBOL/VS programs using the ISAM interface to access <strong>VSAM</strong> data sets.<br />
► PL/1 programs written for ISAM accessing <strong>VSAM</strong> data sets.<br />
► Other programs using the RDJFCB macro to try to identify the file type, for<br />
example, IDCAMS.<br />
Before using BSLR, the subsystem must be installed. Contact your installation<br />
system programmer, or refer to the manual MVS Batch Local Shared Resources,<br />
GC28-1469.<br />
When the subsystem is active, to invoke its services, add the SUBSYS<br />
parameter to the JCL. The following example illustrates how to do this.<br />
If, for example, the application opens the following data set for NSR processing:<br />
//<strong>VSAM</strong>DD DD DISP=SHR,DSN=<strong>VSAM</strong>DSN<br />
You can convert to the BLSR subsystem as follows:<br />
1. Change the DDNAME on the previous JCL command statement, for example,<br />
from <strong>VSAM</strong>DD to NEWBUFF:<br />
//NEWBUFF DD DISP=SHR,DSN=<strong>VSAM</strong>DSN<br />
2. Add the following DD statement, where the SUBSYS subsystem-name<br />
subparameter is BLSR and the SUBSYS DDNAME subparameter is the DD<br />
name selected in Step 1:<br />
//<strong>VSAM</strong>DD DD SUBSYS=(BLSR,'DDNAME=NEWBUFF')<br />
When SUBSYS is specified in JCL, the job’s INITIATOR issues the IEFSSREQ<br />
macro, invoking BLSR subsystem services, passing the information specified in<br />
the SUBSYS parameter.<br />
Then, the BSLR subsystem:<br />
1. Includes an EXIT to call BLSR at OPEN.<br />
2. Dynamically allocates the data set to the correct DDNAME (NEWBUFF in the<br />
example).<br />
Chapter 2. Performance 93
94 <strong>VSAM</strong> <strong>Demystified</strong><br />
When the application opens the <strong>VSAM</strong>DD ACB, the BLSR subsystem completes the<br />
conversion to LSR processing.<br />
The following system parameters are not allowed with the SUBSYS parameter:<br />
*, AMP, BURST, CHARS, COPIES, DATA, DDNAME, DYNAM, FLASH, MODIFY, QNAME, SPACE,<br />
SYSOUT.<br />
You must nullify any of these parameters if they are specified on a DD statement<br />
you are overriding.<br />
You specify the SUBSYS parameter as:<br />
SUBSYS=(subsys-name,'DDNAME=value','subparm1=value',....,'subparmn=value')<br />
Where:<br />
► subsys-name is the name given to BLSR subsystem, usually, BLSR.<br />
► DDNAME=value is the name of the DDNAME to be open by the application<br />
program.<br />
The following subparameters are allowed on the BLSR SUBSYS parameter:<br />
BUFND, BUFNI, HBUFND, HBUFNI, RMODE31, STRNO, DEFERW, SHRPOOL,<br />
BUFSD, BUFSI and MSG.<br />
BLSR can be used with SMS and non-SMS-managed data sets.<br />
If your data set is SMS-managed and is in extended format, you will get better<br />
performance using SMB. For details, see “System managed buffering (SMB)” on<br />
page 82.<br />
We recommend:<br />
► If possible, use SMB. The results are better, as shown in Table 2-7 on<br />
page 86.<br />
► If possible, locate the buffers above 16 MB.<br />
2.6.15 Data compression<br />
To compress means to store data in a format that requires less space than the<br />
original data. There are quite a few methods (algorithms) to compress data, such<br />
as:<br />
► Character-based methods: Huffman, Run-length encoding, Ziv-Lempel<br />
► Bit-level methods: Image data compression, IDRC (tape controllers)<br />
Some of these methods use the concept of a dictionary, which is a mapping from<br />
one vocabulary to another. There are two types:
► Compression dictionary<br />
► Expansion dictionary<br />
The same method may use many dictionaries.<br />
S/390 uses the Ziv-Lempel (ZL) method in software and hardware options.<br />
ZL-based schemes work by entering phrases into a dictionary and then, when a<br />
repeat occurrence of that particular phrase is found, outputting the dictionary<br />
index instead of the phrase. Several compression algorithms are based on this<br />
principle. They differ mainly in the manner in which they manage the dictionary,<br />
and all of them tend to perform much better in decoding than in encoding. S/390<br />
compression uses the ZL1 version of the ZL implementation, and the RVA family<br />
of products uses ZL2.<br />
Where to use compression<br />
Compression can be executed in the processor or outbound in an I/O controller<br />
(for example, tape). With CPU compression, you save:<br />
► I/O buffer pool space<br />
► Channel cycles<br />
► Controller cache space<br />
► Controller internal data path cycles<br />
► Media space (disk and tape)<br />
► Transmission line cycles (for TP)<br />
The advantages of compressing in the controller are to save:<br />
► Controller cache space<br />
► Controller internal data path cycles<br />
► Media space (disk and tape)<br />
► CPU cycles<br />
z/OS compression interface<br />
The interface to data compression in z/OS is through the Compression<br />
Management Facility (CMF), which consists of two parts.<br />
Compression service activation<br />
Compression service activation covers checking and setting up the required<br />
compression environment.<br />
It determines if the Compression Call instruction is available; if not, the<br />
compression is done by software.It verifies if the SYS1.DBBLIB data set is<br />
available. It contains dictionary building blocks (DBB) used for compression.<br />
Chapter 2. Performance 95
96 <strong>VSAM</strong> <strong>Demystified</strong><br />
Compression management services (CMS)<br />
Compression management services covers the actual process a data set goes<br />
through when compression is requested. CMS provides and carries out the<br />
following services used by <strong>VSAM</strong>.<br />
<strong>VSAM</strong> Candidate data set verification<br />
<strong>VSAM</strong> Candidate data set verification has the following requirements:<br />
► KSDS organization only. Only data is compressed, indexes are not<br />
compressed (AIXs are not compressed).<br />
► SMS functions must be active and the data set must be SMS managed and in<br />
extended format.<br />
► Data class assigned has to specify the DSNTYPE=EXT with a required<br />
COMPACTION=Y (blank defaults to N).<br />
► Have a primary allocation of at least 5 MB (data component only) due to the<br />
amount of sampling needed to develop a dictionary token. If no secondary<br />
allocation is specified, then the primary allocation must be at least 8 MB.<br />
► Have a minimum record length of 40 bytes (not including key length).<br />
► CI Mode processing is not allowed.<br />
► BCS catalog, system data sets, and temporary data sets cannot be<br />
compressed because extended format is not supported.<br />
For <strong>VSAM</strong> extended format and compression restrictions and incompatibilities<br />
see DFSMS Using Data Sets, SC26-4922-01.<br />
Dictionary selection<br />
There are two forms of compression: generic and tailored (refer to Figure 2-7 on<br />
page 98.)<br />
► Generic compression:<br />
This involves the sampling and interrogation of the compression eligible data<br />
set by CMF. Next, a sample from the data set is taken, at load time, and<br />
compared to the DBBs for similar content and compression efficiency. Up to<br />
64 KB of the data set can be sampled and written before the data set starts to<br />
be compressed. The first time a compressed format data set is written to disk,<br />
the first bytes are written in non-compressed form.<br />
Because the dictionary is assembled using DBBs during the sampling and<br />
interrogation, the dictionary does not exist when the first bytes of the data set<br />
are written. Once the dictionary is built, the data can use this dictionary to<br />
compress the rest of the data set. Information about the mix of DBBs selected<br />
during the sampling and interrogation process is kept in the catalog. This
information enables the decompression of the data set when required but<br />
does not require a dictionary to be stored with the data set.<br />
► Tailored compression:<br />
Tailored compression introduces a new form of compression for sequential<br />
extended format data sets. By the way, <strong>VSAM</strong> data sets do not support<br />
Tailored compression.<br />
With tailored compression, the system attempts to derive a compression<br />
dictionary that is tailored specifically to the initial data written to a data set.<br />
Once a tailored dictionary is derived, it is imbedded in the compressed data<br />
set. This technique is expected to provide improved compression ratios,<br />
thereby reducing DASD usage and channel traffic.<br />
Because the dictionary is tailored to the user data, significantly more data is<br />
sampled than was required by generic compression. The process of sampling<br />
the data and building the dictionary during creation of a new data set takes<br />
more CPU cycles and is, therefore, most noticeable when compressing small<br />
data sets. For larger data sets, the cost of sampling is amortized significantly.<br />
Reuse of a tailored compressed data set saves the cost of sampling and<br />
dictionary creation.<br />
An installation has the option of either using the new tailored compression or<br />
continuing to use generic DBB-based compression first introduced with<br />
DFSMS V1R2. Tailored compression allows for more types of data to be<br />
compressed, for example, where non-English languages are used.<br />
Because the original generic dictionary was developed with standard<br />
American-English scripts, files containing sequences of characters that do not<br />
appear in the American scripts do not compress very well. The tailored<br />
dictionary avoids this problem, as it is generated dynamically from the data<br />
itself, for each data set.<br />
Dynamically generating a tailored dictionary from the data itself should make<br />
tailored compression more useful to the non-English-speaking world. Tailored<br />
compression support does not apply to <strong>VSAM</strong> KSDSs, which can continue to<br />
be compressed with generic DBB dictionary compression.<br />
Chapter 2. Performance 97
DBBs<br />
Noncompressed<br />
Data<br />
Compression Management Services<br />
Figure 2-7 CMS dictionary selection<br />
98 <strong>VSAM</strong> <strong>Demystified</strong><br />
Data<br />
Class<br />
Sample<br />
Interrogate<br />
Compare<br />
Build<br />
Write<br />
Compressed<br />
Forms of candidate data sets<br />
A compression-eligible data set can exist in one of three forms, depending on the<br />
moment:<br />
► Dictionary selection: The data set is eligible, but its makeup is yet to be<br />
determined. The dictionary tokens are compared with the data set contents<br />
during interrogation and sampling. Interrogation maps bytes into alpha,<br />
numeric, upper- or lower-case, and sampling evaluates DBB compression<br />
efficiency.<br />
► Mated: The data set is mated with the appropriate dictionary; this concludes<br />
the sampling and interrogation processes.<br />
► Rejected: A suitable dictionary match was not found during sampling and<br />
interrogation, so compression is bypassed, or for a sequential data set, the<br />
data set was closed before a token could be selected. Note that the data set<br />
is in compressed format.
There are some types of data sets that are not suitable for ZL compression,<br />
resulting in rejection, such as these:<br />
► Small data sets.<br />
► Data sets in which the pattern of the data does not produce a good<br />
compression rate, such as image data.<br />
► Small records. Compression is performed on a logical record basis. When<br />
logical records are very short, the cost of additional work may become<br />
excessive compared to the reduction in size that compression achieves.<br />
Data compression and decompression<br />
Data compression and decompression are invoked whenever read and/or write<br />
or get and/or put is done on a mated data set. A mated data set is one that has<br />
acquired a suitable dictionary token through successful interrogation and<br />
sampling processes. In other words, suitable building blocks have been found<br />
and selected from the DBB distribution library, and their combination constitutes<br />
the dictionary token associated with the data set and held in the catalog entry as<br />
well. Compression and decompression of a mated data set use the dictionary<br />
built from the dictionary token associated with the data set entry in the extended<br />
format cell of the catalog.<br />
The dictionary is customized to the data set through the dictionary selection<br />
process. However, the dictionary is not stored with the data. Only the token<br />
information is stored, because the dictionary is a table dynamically built in<br />
storage from the token information that enables the compression and<br />
decompression of a data set when it is opened.<br />
Using this approach, DFSMS retains responsibility for dictionary management<br />
and shields the user and application from the physical representation of<br />
compressed data on disk.<br />
Compression concepts<br />
Some basic concepts regarding compression include:<br />
► Import into an empty data set does not propagate extended format and<br />
compression information.<br />
► When data is compressed, the length of a stored record may change after an<br />
update without any logical record length change.<br />
► Locate mode processing is allowed but requires a larger number of internal<br />
work areas to process.<br />
► ISMF adds a %user data reduction (compression factor) field in data set<br />
application.<br />
Chapter 2. Performance 99
100 <strong>VSAM</strong> <strong>Demystified</strong><br />
► IDCAMS REPRO copies data sets without decompressing:<br />
– If the target data set is eligible for compression, and<br />
– If the target device is a like device, or CI sizes are equal for <strong>VSAM</strong><br />
► Otherwise, REPRO decompress the data when reading and optionally<br />
compresses the data when writing.<br />
► Our SMF sample report shows the compression factor.<br />
► LISTCAT lists the compression related information.<br />
► IEHLIST indicates that the data set is compressed.<br />
► DFSMSdss can be used for:<br />
– Logical dump: This does not change format from compressed to<br />
non-compressed or vice versa; and includes cataloging information with<br />
dump.<br />
– Logical restore: This does not change format from non-compressed to<br />
compressed.<br />
– Logical copy: This never changes the format from non-compressed to<br />
compressed.<br />
– DFSMShsm avoids double compression.<br />
<strong>VSAM</strong> compression<br />
<strong>VSAM</strong> compression is done transparently to the application, through the data<br />
class (DC) parameter in SMS data sets. This DC assigned to the data set has to<br />
specify the following DSNTYPE=EXT with a required COMPACTION=Y (blank<br />
defaults to N). Figure 2-8 shows the ISMF list of the DC:<br />
DATACLAS EXTENDED MEDIA<br />
NAME DATA SET NAME TYPE ADDRESSABILITY COMPACTION TYPE<br />
--(2)--- -------(26)------- -----(27)----- ---(28)--- -(29)-<br />
DCSMB EXTENDED REQUIRED NO ---- ------<br />
DCSTRIPE EXTENDED REQUIRED NO ---- ------<br />
DCXXXX EXTENDED REQUIRED NO ---- ------<br />
DIRECT ------------------ NO ---- ------<br />
ECCST ------------------ NO YES MEDIA2<br />
EHPCT ------------------ NO YES MEDIA3<br />
Figure 2-8 ISMF Data Class display<br />
<strong>VSAM</strong> compression only applies to KSDS in extended format. All the fields to the<br />
left of the key in the logical record are not compressed. In your next data model,<br />
you can define the key field with offset equal to zero.
Compression affects the catalog, VTOC, and SMF information about <strong>VSAM</strong> data<br />
sets. Refer to “Compression information sources” on page 101 for information on<br />
how to get this data.<br />
Compression performance<br />
The relative CPU compression cost depends on:<br />
► Dictionary size:<br />
Usually, you do not have much control over this.<br />
► Ratio of reads to writes of compressed records:<br />
Ziv-Lempel expands faster (less CPU cycles) than compresses. This means<br />
that it is better suited for data sets with a high read-to-write ratio.<br />
Table 2-14 shows the amount of processing per compressed read or write<br />
operation that we found in our lab environment.<br />
Table 2-14 Comparing compression<br />
Type of access a<br />
a. SMB was used in all experiments<br />
Compression EXCPs Device connect<br />
time (sec)<br />
Initial load No 12813 28.38 48<br />
Initial load Yes 10243 23.09 57<br />
Direct access<br />
(updates/inserts)<br />
Direct access<br />
(updates/inserts)<br />
Direct access<br />
(reads)<br />
Direct access<br />
(reads)<br />
No 280276 62.5 189<br />
Yes 288461 74.23 112<br />
Yes 99347 15.90 76<br />
No 102697 16.43 77<br />
Step elapsed<br />
time (sec)<br />
We recommend that you:<br />
► Do not use compression for data sets with low read-to-write ratio (less than<br />
60%).<br />
► Set key offset equal to zero.<br />
Compression information sources<br />
Compressed data sets have specific information about the compression process<br />
in different sources.<br />
Chapter 2. Performance 101
102 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Catalogs:<br />
ICF catalogs are not eligible for compression, but are enhanced to contain<br />
additional information about compressed format data sets in the extended<br />
format cell of the catalog entry. The extended format cell is part of the <strong>VSAM</strong><br />
volume data set (VVDS) component of the ICF catalog.<br />
The extended format cell holds:<br />
– Number of stripes (STRIPE-COUNT)<br />
– Compression flags (COMP-FORMAT)<br />
– Physical block size<br />
– Non-compressed user data set size in bytes (USER-DATA-SIZE)<br />
– Compressed user data set size in bytes (COMP-USER-DATA-SIZE)<br />
– Active dictionary token (ACT-DIC-TOKEN — Active Dictionary Token or<br />
NULL)<br />
– Whether user data sizes are valid (SIZES-VALID)<br />
– Compression characteristic record.<br />
In the appendix, there is a REXX routine to search in a catalog for all<br />
compressed data sets or an specific one. It shows for each of them the percent<br />
compression ratio. This tool allows you to determine if your CPU’s cycles are<br />
efficiently utilized, in terms of saving storage media, channel cycles, and buffer<br />
pools. Refer to “SMFLSR sample program” on page 380.<br />
► SMF:<br />
New fields have also been added to SMF type 64 records for <strong>VSAM</strong><br />
compression. These new fields record the size of the data before and after<br />
compression, flags for extended format and compression, and dictionary<br />
tokens used for compression. You can find more detailed information on the<br />
SMF record layout in MVS/ESA SP V5 System Management Facilities (SMF),<br />
GC28-1457.<br />
QSAM compression information in the type 14 and 15 records is updated<br />
when CLOSE is performed on a sequential compressed format data set.<br />
Information on the dictionary token selected and the compressed and<br />
non-compressed data set size is added to the SMF type 14 and 15 records.<br />
This information is also maintained in the extended format cell in the catalog.<br />
► VTOC:<br />
There is now a compression indicator, DS1COMPR, and an extended format<br />
data set indicator, DS1STRP, in the VTOC. Because a compressed format<br />
data set must be an extended format data set, both indicators are on for<br />
compressed format data sets:<br />
VTOC Format 1 DSCB
2.6.16 <strong>VSAM</strong> Data striping<br />
DS1STRP — extended format <strong>VSAM</strong> data set. Contained within the<br />
DS1SMSFG offset x’ 4 E’<br />
DS1COMPR — Compressed data set. Contained within the DS1FLAG1<br />
offset x’ 3 D’<br />
Usually, in a multi-extent, multi-volume <strong>VSAM</strong> data set processed in sequential<br />
access mode, processing does not present any type of parallelism for I/O<br />
operations among the volumes. This means that when an I/O operation is<br />
executed for an extent in a volume, no other I/O activity from the same task/same<br />
data set is scheduled to the other volumes. In a situation where I/O is the major<br />
bottleneck, and there are available resources in the channel subsystem and<br />
controllers, it is a waste of these resources.<br />
Data striping addresses this performance problem by imposing two modifications<br />
to the traditional data organization:<br />
► The records are not placed in key ranges along the volumes; instead they are<br />
organized in stripes.<br />
► Parallel I/O operations are scheduled to sequential stripes in different<br />
volumes.<br />
By striping data, the tracks in the case of SAM, and the control intervals (CIs) for<br />
<strong>VSAM</strong>, are spread across multiple devices. This format allows a single<br />
application request for records in multiple tracks and CIs to be satisfied by<br />
concurrent I/O requests to multiple volumes.<br />
The result is improved performance by achieving data transfer into the<br />
application at a rate greater than any single I/O path. The scheduling of I/O to<br />
multiple devices in order to satisfy a single application request is referred to as an<br />
I/O packet.<br />
<strong>VSAM</strong> data striping topics<br />
Data striping support for <strong>VSAM</strong> was initially provided with DFSMS 2.10. Support<br />
is provided for all <strong>VSAM</strong> organization, including KSDS, ESDS, RRDS, VRRDS,<br />
and LDS.<br />
The idea is to spread sequenced data CIs in different data CAs located in<br />
different volumes. Following are the characteristics of a <strong>VSAM</strong> striped data set:<br />
► Striping is done by CI, as opposed to a track for SAM.<br />
► A stripe is associated with a single volume or a set of volumes (if you have<br />
multi-layer).<br />
Chapter 2. Performance 103
104 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Only the data component of a base cluster may be striped.<br />
► A data set may have up to a maximum of 16 stripes.<br />
► A stripe on a single volume has a maximum of 123 extents per stripe.<br />
► A multi-layered stripe (a stripe allocated on several volumes) has a maximum<br />
of 255 extents per stripe.<br />
► The following features are supported in a striped <strong>VSAM</strong> data set:<br />
– Extended addressability (>4GB):<br />
– Compressed format<br />
– Partial release<br />
► A data set is system-managed.<br />
► A data set is allocated in extended format.<br />
► Prior to DFSMS z/OS 1.3 a striped data set cannot be reused.<br />
► A data set may be assigned either GUARANTEED SPACE (does not support<br />
multi-layered) or NON-GUARANTEED SPACE.<br />
► For guaranteed space, the number of stripes is equal to the number of<br />
volumes (VOLUME COUNT) you specify in the data class or the VOLUMES<br />
parameter in JCL, up to a maximum of 16 stripes. The JCL specification<br />
overrides the data class.<br />
For non-guaranteed space, SMS determines the number of stripes to use<br />
based on the value of the SUSTAINED DATA RATE(SDR) in the storage<br />
class.<br />
Figure 2-9 shows an example of a four-stripe <strong>VSAM</strong> data set.
C<br />
O<br />
N<br />
T<br />
R<br />
O<br />
L<br />
A<br />
R<br />
E<br />
A<br />
Example: Data CI size - 4k, Physical Blocksize - 4k<br />
4k blocks per 3390 track - 12, Stripe count - 4<br />
CYL (n n)<br />
Stripe/VOL 1 Stripe/VOL 2 Stripe/VOL 3 Stripe/VOL 4<br />
CI<br />
0<br />
0<br />
1<br />
CI<br />
0<br />
4<br />
9<br />
CI<br />
0<br />
9<br />
7<br />
CI<br />
1<br />
4<br />
5<br />
CI<br />
0<br />
0<br />
5<br />
CI<br />
0<br />
5<br />
3<br />
CI<br />
1<br />
0<br />
1<br />
CI<br />
1<br />
4<br />
9<br />
CI<br />
0<br />
0<br />
9<br />
CI<br />
0<br />
5<br />
7<br />
CI<br />
1<br />
0<br />
5<br />
CI<br />
1<br />
5<br />
3<br />
CI<br />
thru 0<br />
4<br />
5<br />
CI<br />
thru 0<br />
9<br />
3<br />
CI<br />
thru 1<br />
4<br />
1<br />
CI<br />
thru 1<br />
8<br />
9<br />
CI<br />
0<br />
0<br />
2<br />
CI<br />
0<br />
5<br />
0<br />
CI<br />
0<br />
9<br />
8<br />
CI<br />
1<br />
4<br />
6<br />
CI<br />
0<br />
0<br />
6<br />
CI<br />
0<br />
5<br />
4<br />
CI<br />
1<br />
0<br />
2<br />
CI<br />
1<br />
5<br />
0<br />
Figure 2-9 Striped <strong>VSAM</strong> data set<br />
CI CI<br />
0 thru 0<br />
1 4<br />
0 6<br />
CI CI<br />
0 thru 0<br />
5 9<br />
8 4<br />
CI CI<br />
1 thru 1<br />
0 4<br />
6 2<br />
CI CI<br />
1 thru 1<br />
5 9<br />
4 0<br />
1st track<br />
2nd track<br />
3rd track<br />
4th track<br />
As you can see, a data control area is formed by CIs not within sequenced key<br />
range. Also for a KSDS, index records in the sequence set contained in the same<br />
CI index point to different CAs.<br />
Layering and striped data<br />
<strong>VSAM</strong> supports multi-layering. A layer in a striped environment is defined as the<br />
relationship of the volumes that make up the total number of stripes. That is,<br />
those volumes that participate as part of an I/O packet.<br />
Once the stripe extends to a new volume, and the I/O packet changes, this<br />
constitutes another layer. The Sequential Access Method (SAM) is restricted to<br />
extending only to the current stripe volume and does not support the concept of<br />
multi-layering.<br />
Figure 2-10 shows an example of the concept of layering with a three-stripe data<br />
set.<br />
CI<br />
0<br />
0<br />
3<br />
CI<br />
0<br />
5<br />
1<br />
CI<br />
0<br />
9<br />
9<br />
CI<br />
1<br />
4<br />
7<br />
CI<br />
0<br />
0<br />
7<br />
CI<br />
0<br />
5<br />
5<br />
CI<br />
1<br />
0<br />
3<br />
CI<br />
1<br />
5<br />
1<br />
CI<br />
0<br />
1<br />
1<br />
CI<br />
0<br />
5<br />
9<br />
CI<br />
1<br />
0<br />
7<br />
CI<br />
1<br />
5<br />
5<br />
CI<br />
thru 0<br />
4<br />
7<br />
CI<br />
thru 0<br />
9<br />
5<br />
CI<br />
thru 1<br />
4<br />
3<br />
CI<br />
thru 1<br />
9<br />
1<br />
CI<br />
0<br />
0<br />
4<br />
CI<br />
0<br />
5<br />
2<br />
CI<br />
1<br />
0<br />
0<br />
CI<br />
1<br />
4<br />
8<br />
CI<br />
0<br />
0<br />
8<br />
CI<br />
0<br />
5<br />
6<br />
CI<br />
1<br />
0<br />
4<br />
CI<br />
1<br />
5<br />
2<br />
CI<br />
0<br />
1<br />
2<br />
CI<br />
0<br />
6<br />
0<br />
CI<br />
1<br />
0<br />
8<br />
CI<br />
1<br />
5<br />
6<br />
CI<br />
thru 0<br />
4<br />
8<br />
CI<br />
thru 0<br />
9<br />
6<br />
CI<br />
thru<br />
1<br />
4<br />
4<br />
CI<br />
thru 1<br />
9<br />
2<br />
Chapter 2. Performance 105
106 <strong>VSAM</strong> <strong>Demystified</strong><br />
Layer 1: VOLA VOLB VOLC<br />
Layer 2: VOLA VOLD VOLC<br />
Stripe 1 - extends on same volume<br />
Stripe 2 - extends to VOLD<br />
Stripe 3 - extends on same volume<br />
Layer 3: VOLE VOLF VOLG<br />
Stripe 1 - extends to VOLE<br />
Stripe 2 - extends to VOLF<br />
Stripe 3 - extends to VOLG<br />
Stripe 1 - extends on same volume<br />
Stripe 2 - extends on same volume<br />
Stripe 3 - extends on same volume<br />
Figure 2-10 Layering in <strong>VSAM</strong> data set striping<br />
Stripe 1 Stripe 2 Stripe 3<br />
VOLA VOLB VOLC<br />
VOLD<br />
Primary space allocation<br />
Secondary space allocation<br />
LSS1<br />
VOLE VOLF VOLG<br />
Implementing <strong>VSAM</strong> data striping<br />
To create a striped <strong>VSAM</strong> data set, you must do the following:<br />
► Define an SMS-managed <strong>VSAM</strong> data set in extended format.<br />
You should specify Data Set Name Type in the data class. This forces the<br />
allocation in a DASD controller supporting EF. Data Set Name Type may be<br />
set to EXT Preferred (SMS tries to allocate in a controller supporting EF). The<br />
data set is not defined as striped if it is not allocated in extended format.<br />
► Specify the Sustained Data rate (SDR) parameter in the storage class for<br />
either guaranteed or non-guaranteed space. This tells SMS that you want to<br />
implement striping.<br />
► For guaranteed space, specify the VOLUME COUNT in the data class or the<br />
VOLUMES parameter in JCL. The JCL specification overrides the data class.<br />
VOLUME COUNT represents the number of volume cells associated with<br />
data set in catalog entries. If additional volumes are required, the data set<br />
access must be closed, the IDCAMS ALTER ADDVOLUMES command must<br />
be issued. With z/OS DFSMS 1.3 the MAXIMUM VOLUME COUNT data<br />
class parameter is introduced. It represents actual maximum number of
volumes an SMS-managed <strong>VSAM</strong> cluster can span. Now, volumes can be<br />
added dynamically to the cluster without manual intervention and without<br />
taking the application down.<br />
If you do not specify either the volume count or the volume serial numbers,<br />
you only get a single stripe.<br />
► For non-guaranteed space, just specify the SDR value in the storage class.<br />
SMS computes the number of stripes based on the rule that each volume<br />
delivers 4 MB/second rate. The volume count is ignored. Then, if you specify<br />
16 MB/sec, <strong>VSAM</strong> generates a 4-stripes data set.<br />
As a simple example: if you specified a SDR of 17MB/sec, your data set will<br />
be defined with 4 stripes.<br />
Examples of defining striped data sets<br />
In this example, we create a striped <strong>VSAM</strong> data set using guaranteed space, and<br />
a specified volume count of 4. The data class name is KEYEDEXG, and the<br />
storage class is STRIPE.<br />
//STRIPED JOB 'DEF STRIPED-EF <strong>VSAM</strong> DS',MSGCLASS=X,NOTIFY=&SYSUID<br />
//STEP1 EXEC PGM=IDCAMS<br />
//SYSPRINT DD SYSOUT=*<br />
//SYSIN DD *<br />
DELETE DAWN.KSDSEXG<br />
DEFINE CLUSTER -<br />
(NAME(DAWN.KSDSEXG) -<br />
DATACLASS(KEYEDEXG) -<br />
STORAGECLASS(STRIPE))<br />
LISTC ALL ENTRIES(DAWN.KSDSEXG)<br />
/*<br />
Figure 2-11 Sample JCL to create a striped data set<br />
Chapter 2. Performance 107
108 <strong>VSAM</strong> <strong>Demystified</strong><br />
The content of the KEYEDEXG data class is:<br />
CDS Name . . . : SYS1.SMS.SCDS<br />
Data Class Name : KEYEDEXG<br />
Description : USING GUARANTEED SPACE<br />
Recorg . . . . . . . . . : KS<br />
Recfm . . . . . . . . . .:<br />
Lrecl. . . . . . . . . . : 300<br />
Keylen . . . . . . . . . : 8<br />
Keyoff . . . . . . . . . : 0<br />
Space Avgrec . . . . . . : K<br />
Avg Value . . . . : 300<br />
Primary . . . . . : 600<br />
Secondary . . . . : 100<br />
Directory . . . . :<br />
Retpd Or Expdt . . . . . :<br />
Volume Count . . . . . . : 4<br />
Add'l Volume Amount . :<br />
Imbed . . . . . . . . . :<br />
Replicate . . . . . . . :<br />
CIsize Data . . . . . . : 4096<br />
% Freespace CI . . . . . : 10<br />
CA . . . . . : 10<br />
Shareoptions Xregion . . :<br />
Xsystem . . :<br />
Compaction . . . . . . . :<br />
Media Interchange<br />
Media Type . . . . . :<br />
Recording Technology :<br />
Data Set Name Type . . . : EXTENDED<br />
If Extended . . . . . . : REQUIRED<br />
Extended Addressability : NO<br />
Record Access Bias . . : USER<br />
Reuse . . . . . . . . . . : NO<br />
Initial Load . . . . . . : RECOVERY<br />
Spanned / Nonspanned . . :<br />
BWO . . . . . . . . . . . :<br />
Log . . . . . . . . . . . :<br />
Logstream Id . . . . . . :<br />
Space Constraint Relief . : NO<br />
Reduce Space Up To (%) :<br />
Figure 2-12 Sample content of KEYEDEXG data class
The content of the STRIPE storage class is:<br />
CDS Name . . . . . : SYS1.SMS.SCDS<br />
Storage Class Name : STRIPE<br />
Description : TO BE USED FOR STRIPING TEST<br />
Performance Objectives<br />
Direct Millisecond Response . . . :<br />
Direct Bias . . . . . . . . . . . :<br />
Sequential Millisecond Response . :<br />
Sequential Bias . . . . . . . . . :<br />
Initial Access Response Seconds . :<br />
Sustained Data Rate (MB/sec) . . . : 17<br />
Availability . . . . . . . . . . . . : NOPREF<br />
Accessibility . . . . . . . . . . . : NOPREF<br />
Backup . . . . . . . . . . . . . . :<br />
Versioning . . . . . . . . . . . . :<br />
Guaranteed Space . . . . . . . . : YES<br />
Guaranteed Synchronous Write . . : NO<br />
Cache Set Name . . . . . . . . . :<br />
CF Direct Weight . . . . . . . . :<br />
CF Sequential Weight . . . . . . :<br />
Figure 2-13 Sample content of STRIPE storage class<br />
Chapter 2. Performance 109
110 <strong>VSAM</strong> <strong>Demystified</strong><br />
This is the job output. The data set is explicitly defined with four stripes with the<br />
specified volume count of 4:<br />
DEFINE CLUSTER -<br />
(NAME(DAWN.KSDSEXG) -<br />
DATACLASS(KEYEDEXG) -<br />
STORAGECLASS(STRIPE))<br />
IGD17070I DATA SET DAWN.KSDSEXG ALLOCATED<br />
SUCCESSFULLY WITH 4 STRIPE(S).<br />
IDC0508I DATA ALLOCATION STATUS FOR VOLUME SBOX30 IS 0<br />
IDC0508I DATA ALLOCATION STATUS FOR VOLUME MHLV14 IS 0<br />
IDC0508I DATA ALLOCATION STATUS FOR VOLUME SBOX31 IS 0<br />
IDC0508I DATA ALLOCATION STATUS FOR VOLUME SBOX28 IS 0<br />
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME SBOX30 IS 0<br />
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME MHLV14 IS 0<br />
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME SBOX31 IS 0<br />
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME SBOX28 IS 0<br />
IDC0512I NAME GENERATED-(D) DAWN.KSDSEXG.DATA<br />
IDC0512I NAME GENERATED-(I) DAWN.KSDSEXG.INDEX<br />
IDC0181I STORAGECLASS USED IS STRIPE<br />
IDC0181I MANAGEMENTCLASS USED IS MCDB22<br />
IDC0181I DATACLASS USED IS KEYEDEXG<br />
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0<br />
Figure 2-14 Sample IDCAMS control statements and output for four stripes<br />
In this example, we create a striped <strong>VSAM</strong> data set using non-guaranteed space<br />
and SDR 17 MB/sec:<br />
//STRIPED JOB 'DEF STRIPED-EF <strong>VSAM</strong> DS',MSGCLASS=X,NOTIFY=&SYSUID<br />
//STEP1 EXEC PGM=IDCAMS<br />
//SYSPRINT DD SYSOUT=*<br />
//SYSIN DD *<br />
DELETE DAWN.KSDSEXT<br />
DEFINE CLUSTER -<br />
(NAME(DAWN.KSDSEXT) -<br />
DATACLASS(KEYEDEXT) -<br />
STORAGECLASS(STRIPE))<br />
LISTC ALL ENTRIES(DAWN.KSDSEXT)<br />
/*
The content of the KEYEDEXT data class is:<br />
CDS Name . . . : SYS1.SMS.SCDS<br />
Data Class Name : KEYEDEXT<br />
Description : TO BE USED FOR STRIPING TEST<br />
Recorg . . . . . . . . . : KS<br />
Recfm . . . . . . . . . :<br />
Lrecl . . . . . . . . . : 300<br />
Keylen . . . . . . . . . : 8<br />
Keyoff . . . . . . . . . : 0<br />
Space Avgrec . . . . . . : K<br />
Avg Value . . . . : 300<br />
Primary . . . . . : 600<br />
Secondary . . . . : 100<br />
Directory . . . . :<br />
Retpd Or Expdt . . . . . :<br />
Volume Count . . . . . . : 8<br />
Add'l Volume Amount . :<br />
Imbed . . . . . . . . . :<br />
Replicate . . . . . . . :<br />
CIsize Data . . . . . . : 4096<br />
% Freespace CI . . . . . : 10<br />
CA . . . . . : 10<br />
Shareoptions Xregion . . :<br />
Xsystem . . :<br />
Compaction . . . . . . . :<br />
Media Interchange<br />
Media Type . . . . . :<br />
Recording Technology :<br />
Data Set Name Type . . . : EXTENDED<br />
If Extended . . . . . . : REQUIRED<br />
Extended Addressability : NO<br />
Record Access Bias . . : USER<br />
Reuse . . . . . . . . . . : NO<br />
Initial Load . . . . . . : RECOVERY<br />
Spanned / Nonspanned . . :<br />
BWO . . . . . . . . . . . :<br />
Log . . . . . . . . . . . :<br />
Logstream Id . . . . . . :<br />
Space Constraint Relief . : NO<br />
Reduce Space Up To (%) :<br />
Figure 2-15 Example of KEYEDEXT data class<br />
Chapter 2. Performance 111
112 <strong>VSAM</strong> <strong>Demystified</strong><br />
The content of the STRIPE storage class using non-guaranteed space is shown<br />
here:<br />
CDS Name . . . . . : SYS1.SMS.SCDS<br />
Storage Class Name : STRIPE<br />
Description : TO BE USED FOR STRIPING TEST<br />
Performance Objectives<br />
Direct Millisecond Response . . . :<br />
Direct Bias . . . . . . . . . . . :<br />
Sequential Millisecond Response . :<br />
Sequential Bias . . . . . . . . . :<br />
Initial Access Response Seconds . :<br />
Sustained Data Rate (MB/sec) . . . : 17<br />
Availability . . . . . . . . . . . . : NOPREF<br />
Accessibility . . . . . . . . . . . : NOPREF<br />
Backup . . . . . . . . . . . . . . :<br />
Versioning . . . . . . . . . . . . :<br />
Guaranteed Space . . . . . . . . : NO<br />
Guaranteed Synchronous Write . . : NO<br />
Cache Set Name . . . . . . . . . :<br />
CF Direct Weight . . . . . . . . :<br />
CF Sequential Weight . . . . . . :<br />
Figure 2-16 Example of content of STRIPE storage class<br />
This is the job output of our second example. The data set is defined with five<br />
stripes. SMS is allocated on 5 volumes out of the 8 volumes defined in the<br />
storage group. Only the data component is striped:
DEFINE CLUSTER -<br />
(NAME(DAWN.KSDSEXT) -<br />
DATACLASS(KEYEDEXT) -<br />
STORAGECLASS(STRIPE))<br />
IGD17070I DATA SET DAWN.KSDSEXT ALLOCATED<br />
SUCCESSFULLY WITH 5 STRIPE(S).<br />
IDC0508I DATA ALLOCATION STATUS FOR VOLUME SBOX31 IS 0<br />
IDC0508I DATA ALLOCATION STATUS FOR VOLUME SBOX28 IS 0<br />
IDC0508I DATA ALLOCATION STATUS FOR VOLUME SBOX29 IS 0<br />
IDC0508I DATA ALLOCATION STATUS FOR VOLUME SBOX30 IS 0<br />
IDC0508I DATA ALLOCATION STATUS FOR VOLUME MHLV13 IS 0<br />
IDC0509I INDEX ALLOCATION STATUS FOR VOLUME SBOX31 IS 0<br />
IDCAMS SYSTEM SERVICES<br />
IDC0512I NAME GENERATED-(D) DAWN.KSDSEXT.DATA<br />
IDC0512I NAME GENERATED-(I) DAWN.KSDSEXT.INDEX<br />
IDC0181I STORAGECLASS USED IS STRIPE<br />
IDC0181I MANAGEMENTCLASS USED IS MCDB22<br />
IDC0181I DATACLASS USED IS KEYEDEXT<br />
IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0<br />
Figure 2-17 Second example with five stripes<br />
After loading the data set, the LISTCAT output shows the HURBA only on the<br />
first volume. For the other volumes, HURBA=0.<br />
CA size considerations<br />
CA size calculations are affected by striping. Normally, the CA size is the lesser<br />
of the primary or secondary value and must not exceed 15 tracks if allocation is<br />
in tracks; or a cylinder, if allocation is in cylinders.<br />
In striped data sets, the CA size amount must be a multiple of the number of<br />
stripes. That is, a CA cannot end in the middle of a stripe.<br />
To meet this restriction, the CA size may have to be rounded to the next integral<br />
of the stripe count. Also, since the maximum stripe count is 16, a CA size of 16<br />
tracks must be allowed to accommodate 16 stripes. Note that CA size maximum<br />
is increased to 16 tracks from previous 1 cylinder (15 tracks) allocation.<br />
For striped data sets, all computations for CA size are performed using the<br />
equivalent amount of tracks, for example:<br />
► A data set has seven stripes.<br />
► The equivalent allocation in tracks is (45 30), so 15 tracks are used.<br />
► 15 tracks rounded to the next integral of stripe count is 21. But 21 is greater<br />
than maximum of 16 tracks, so CA size is rounded down to 14 tracks.<br />
Chapter 2. Performance 113
114 <strong>VSAM</strong> <strong>Demystified</strong><br />
Performance considerations<br />
Consider the following when using <strong>VSAM</strong> striped data sets:<br />
► The effective throughput gains on sequential access increases almost in<br />
proportion to the number of stripes, unless there is contention at the device,<br />
subsystem, path or channel level<br />
► The throughput gains decreases from the expected, if you work with many<br />
stripes, or the Law of Diminishing Returns starts to work due to the raising of<br />
management. For KSDS, it has been experienced that after the fourth stripe,<br />
the processing improvement curve flattens. You may not get performance<br />
improvements if you define more than 4 stripes.<br />
► The I/O response time for a striped data set is as long as the longest I/O in the<br />
stripe or the effective throughput is limited to the slowest stripe.<br />
► The I/O post to the application is done when all the I/O to the stripes ends.<br />
Likewise, if an I/O error occurs in one of the stripes/volumes, the I/O operation<br />
ends with an error.<br />
► For striped data sets, you should use SMB to determine the number of<br />
buffers, or you should allocate a larger value for the BUFND, depending on<br />
your application.<br />
If you are not using SMB, specify a BUFND value that is at least equal to the<br />
number of stripes. SMS needs at least one buffer for each stripe/volume<br />
accessed by the I/O request. Refer to 2.6.13, “Buffering options” on page 63<br />
for more information. Using the default BUFND eliminates some of the<br />
benefits of striping.<br />
► Using LSR for a <strong>VSAM</strong> striped data set is not rejected. However, you may not<br />
see a performance improvement in the way that NSR does.<br />
► As we have mentioned, SMS computes the number of stripes based in your<br />
SDR parameter divided by a 4 MB/second rate. Because your DASD volume<br />
performs much better than this figure, you may get an actual better rate than<br />
what you have specified in the SDR in the storage class.<br />
► Striping does not give a benefit for data sets accessed directly. However,<br />
these data sets are also accessed sequentially during backup, report<br />
generating, and so on. Therefore, you may want to consider striping all your<br />
<strong>VSAM</strong> data sets<br />
► <strong>VSAM</strong> striping is not supported in RLS mode.<br />
Recommendations<br />
We make the following recommendations:<br />
► For striped data sets, use SMB to determine the number of buffers or allocate<br />
a larger value for the BUFND, depending on your application. Using the<br />
default BUFND eliminates some of the benefits of striping.
► All the volumes that contain the stripes should have the same speed.<br />
► As a rule of thumb for <strong>VSAM</strong>, do not go beyond 4 stripes — if you do, you will<br />
overload the processor.<br />
► Define striping only for sequential processing.<br />
2.7 <strong>VSAM</strong> performance by scenarios<br />
Here, we simulate a scenario, where one or more <strong>VSAM</strong> data sets are causing<br />
performance problems to key transactions in a real installation. We cover all the<br />
aspects that may affect the <strong>VSAM</strong> I/O delay time, (Tw(IO)); and the I/O service<br />
time, (Ts(IO)). Also, because <strong>VSAM</strong> CPU service time, (Ts(CPU)), which is used<br />
by <strong>VSAM</strong>, has some effect on the total response time, we offer suggestions on<br />
how to decrease it.<br />
2.7.1 Performance scenario using RMF reports<br />
Before we start let us say a few words about RMF.<br />
RMF is an IBM program product which measures z/OS system performance.<br />
RMF has three Monitors and a Postprocessor function.<br />
Each Monitor has a Data Gatherer and a Data Reporter. For Monitor I and<br />
Monitor II, both functions are clustered in the same address space. For Monitor<br />
III, they are in distinct address spaces.<br />
► Monitor I is an ongoing non-interactive monitor measuring system variables.<br />
► Monitor II is interactive, showing data about address spaces.<br />
► Monitor III is interactive, showing the performance of specific transactions<br />
In this <strong>VSAM</strong> performance management topic, we use an approach in steps that<br />
are based on RMF Monitor III, and assumes you are in WLM goal mode:<br />
1. Look for your most important service class period that is not reaching the goal<br />
in the RMF Monitor III SYSSUM report (see Figure 2-18).<br />
Chapter 2. Performance 115
116 <strong>VSAM</strong> <strong>Demystified</strong><br />
------- Goals versus Actuals -------- Trans --Avg. Resp. Time-<br />
Exec Vel --- Response Time --- Perf Ended WAIT EXECUT ACTUAL<br />
Name T I Goal Act ---Goal--- --Actual-- Indx Rate Time Time Time<br />
BATCH W 100 0.000 0.000 0.000 0.000<br />
BATCHLOW S 5 25 100 0.25 0.000 0.000 0.000 0.000<br />
HTTPW1 W 100 0.000 0.000 0.000 0.000<br />
HTTPS1 S 1 25 0.80 AVG 1.60 AVG 2.0 44.4 0.000 1.600 1.600<br />
OMVS W 97 0.030 0.001 0.711 0.712<br />
OMVS S 98 0.030 0.001 0.711 0.712<br />
1 2 0.0 0.500 AVG 0.001 AVG 0.00 0.010 0.000 0.001 0.001<br />
Figure 2-18 RMF SYSSUM report<br />
HTTPS1 is a service class associated with the transactions of an HHTP<br />
scalable server. These transactions code run in tasks under enclaves. Its<br />
importance (I) is one (the maximum), its goal is average response time of<br />
0.80 seconds. Its actual response time is 1.6 seconds and the performance<br />
index is 2.0 meaning 100% out of the target.<br />
2. Let us look at the Enclave report in Figure 2-19 to see where the problem is:<br />
ENCLAVE Attribute CLS/GRP P Goal % D EAppl% TCPU USG DLY IDL<br />
ENC0003 CCT HTTPS1 1 0.80 25 18.75 26.78 30 88 0.0<br />
HTML<br />
COLLOR<br />
ENC0001 CTT HTTPS1 1 0.80 24 16.27 23.12 29 89 0.0<br />
HTML<br />
CARDOSO<br />
Figure 2-19 RMF Enclave report<br />
3. In this report, you see two enclaves belonging to the service class HTTPS1<br />
suffering 88% and 89% of delay, respectively. It means that those transactions<br />
for this percentage of time do not progress. There are two types of resource<br />
delays, as far as WLM is concerned:<br />
– Delays for resources controlled by WLM. A resource controlled by WLM is<br />
the one where WLM can change the priority of the request in the queue.<br />
Therefore, those delays are measured by WLM in order to be minimized<br />
(by playing with queue priority), depending on the performance index of<br />
the service class. They are:<br />
CPU<br />
I/O (if you are in WLM I/O Management option)<br />
Storage
Delay for HTTP Queue Server<br />
WLM capping<br />
The 88% and 89% values pictured in the at RMF report refer to such WLM<br />
managed resources.<br />
– Here is a list of delays tracked by RMF Monitor III but not managed by<br />
WLM:<br />
ENQ delays<br />
Operator delays (mount and messages)<br />
Subsystem delays (JES, HSM and XCF)<br />
4. Now let us zoom in to these delays in the report Enclave Classification Data in<br />
Figure 2-20:<br />
The following details are available for enclave ENC00003 :<br />
Press Enter to return to the Report panel.<br />
Detailed Performance Statistics:<br />
-- CPU Time -- ------------- Execution States -------------<br />
Total 26.78 #STS -Using- ------ Delay ------ IDL UNK<br />
Delta 22.50 CPU I/O CPU I/O STO CAP QUE<br />
592 6 27 12 77.0 0.0 0.0 0.0 0.0 0.3<br />
Figure 2-20 Enclave Classification Data report<br />
5. As you can see, detailing the enclave ENC00003, 77% of the WLM managed<br />
delays are caused by I/O delays, that is, I/O requests from the tasks enclaves<br />
being delayed in the UCB (IOS queue time) or in the channel subsystem<br />
(pending time). The Using I/O value is 27%. The Using I/O concept has an<br />
ambiguous meaning depending on who is creating such figure:<br />
– In RMF terms (as the case) the task enclave application is executing a<br />
channel program (connected plus disconnect) for 27% of the observed<br />
time.<br />
– In WLM terms, the I/O disconnect time is not included. WLM uses this<br />
figure to derive the Execution Velocity values<br />
6. Next we zoom a little more, going to the Monitor III Device Delay report (DEV)<br />
in Figure 2-21.<br />
Chapter 2. Performance 117
118 <strong>VSAM</strong> <strong>Demystified</strong><br />
Service DLY USG CON ------------ Main Delay Volume(s) -<br />
Jobname C Class % % % % VOLSER % VOLSER % VOLSER<br />
HTTPS000 S SYSSTC 77 27 23 70 VSMS15 11 VSMS19<br />
MICHAELL B NRPRIME 39 15 14 39 BPXLK1<br />
MCPDUMP S SYSSTC 36 18 20 36 D24PK2<br />
CHARLESR B NRPRIME 33 13 13 28 BPXLK1 3 HSML02 2 BPXSSK<br />
DFHSM S SYSSTC 30 83 35 10 HSML17 5 SMS026 4 HSMOCD<br />
SHUMA3 T TSOPRIME 18 52 53 13 D83ID0 5 HSML02<br />
Figure 2-21 Monitor III Device Delay report<br />
To date, there is no RMF report showing details (at a volume level) about the<br />
I/O use and I/O delay of an enclave. You must know the name of the address<br />
space where the HTTP transactions are doing I/O. It must be one of the HTTP<br />
server address spaces. In this case it is the HTTPS000. Here we can see that<br />
the volume VSMS15 is responsible for 70% of the delays experienced by the<br />
enclave the HTTP transactions.<br />
7. Then, we go to the Monitor III DEVN report in Figure 2-22 to see more details<br />
about the volume.<br />
Device Identification -- -- Activity -- ACT CON DSC - Pending - - Jobs -<br />
VolSer Num Type CU S Rate RspT IosQ % % % % Rsn. % USG DEL<br />
VSMS15 006C 33903 3990-3 S 42.1 .022 .006 68 8 60 2 DB 1 0.0 0.8<br />
VSMS10 0051 33903 3990-3 S 80.7 .011 .005 47 24 1 22 DB 11 0.2 0.7<br />
JOBL17 0703 33903 3990-3 S 52.2 .015 .000 76 22 54 0 0.2 0.6<br />
TSO015 006E 33903 3990-3 S 11.1 .024 .001 26 3 20 3 0.0 0.3<br />
VSMS06 0056 33903 3990-3 S 8.9 .034 .001 30 9 18 3 DB 2 0.1 0.2<br />
Figure 2-22 Monitor III DEVN report<br />
In the DEVN report for volume VSM15, we have the I/O response time (.022<br />
seconds), the I/O rate (42.1 I/Os per second), the IOSQ time (0.006 second)<br />
and the percent distribution of connect, disconnect and pending. If you want<br />
to know how much of connect per I/O operation (AVG CONN TIME) follow this<br />
line of thought: “If the RMF range is 100 seconds, the total connect time was 8<br />
seconds. In 100 seconds, it was executed (42.1 * 100) I/O instructions. So,<br />
dividing 8 by 4210, we have 2 milliseconds of AVG CONN TIME”.<br />
8. The final step in using RMF reports is to discover the data set involved in the<br />
performance problem. We can do this through the Monitor III DSNV report in<br />
Figure 2-23.
------------------------- Volume VSM15 Device Data --------------------------<br />
Number: 006C Active: 68% Pending: 1% Average Users<br />
Device: 33903 Connect: 8% Delay DB: 1% Delayed<br />
Shared: Yes Disconnect: 60% Delay CU: 1% 1.4<br />
Delay DP: 0%<br />
-------------- Data Set Name --------------- Jobname ASID DUSG% DDLY%<br />
Figure 2-23 Monitor III DSNV report<br />
Finally we have all the information — the volume and the data set name (which,<br />
incidentally, is a <strong>VSAM</strong> data set PROD.KSDS.MARCH.U12). You should<br />
determine the largest figure between IOSQ, pending, connected, and<br />
disconnected in your installation (in our example it is disconnect time). IOSQ is<br />
better to pick it up in average ms per I/O operation frm the DEVN report.<br />
Depending on the one you pick, go to the corresponding topic in this chapter,<br />
where you find recommendations to improve it. Remember that all of these<br />
suggestions refer to one of the three ways of solving performance problems, that<br />
is: buy, tune, or steal.<br />
However, before you try to find a way to improve your I/O performance, refer to<br />
2.7.2, “Reducing the number of I/Os” on page 119, which offers suggestions to<br />
eliminate this problem.<br />
2.7.2 Reducing the number of I/Os<br />
The general rule, that the best I/O is the one that is not executed, still applies to<br />
<strong>VSAM</strong>. Therefore, before trying to improve the I/O operation, let us focus on how<br />
to avoid these I/Os. The general techniques for doing that are explained in the<br />
following sections.<br />
Buffering<br />
Buffering is one of the most important <strong>VSAM</strong> features that can be used to avoid<br />
I/Os, and consequently to improve performance. There are two types of<br />
buffering: <strong>VSAM</strong> controlled buffer pools, and Hiperbatch.<br />
<strong>VSAM</strong> controlled buffer pools<br />
<strong>VSAM</strong> controlled buffer pools are controlled by LSR, NSR, RLS, and GSR<br />
buffering modes. Some of them allocated in the application address space and<br />
some in the hiperspace. Refer to 2.6.13, “Buffering options” on page 63.<br />
Let us look at the value of buffering from the perspective I/O performance by<br />
creating the following scenario.<br />
Chapter 2. Performance 119
120 <strong>VSAM</strong> <strong>Demystified</strong><br />
Scenario<br />
► KSDS cluster requiring 0.5 GB (512 * 1024 * 1024 bytes) in a 3390<br />
► Data CI size is 4K<br />
► FREESPACE (15 9)<br />
► The control area size is not restricted, then it is 15 tracks<br />
► There is 180 data CIs in each control area<br />
► The index control interval size is 1536 bytes<br />
► There is 729 Control Areas, and therefore 729 index sequence set CIs<br />
► There is 5 index set records<br />
► There is 3 index levels<br />
Supposing no hits in the buffer<br />
► Program application generating 45 random reads per second, with a<br />
M/M/1queue behavior. This M/M/1 means normal distribution for the<br />
inter-arrival time (M) and for the service time (M) plus just one (1) server<br />
► 100% of DASD caching hits for index, each I/O at 0.5 msec<br />
► 100% of DASD caching hits for index causing an average service time of 0.5<br />
msec<br />
► 50% of DASD caching hits for data, each causing an average service time of<br />
6 msec<br />
Calculation<br />
► I/O Service_Time per average Read caused by three index I/Os and one data<br />
I/O: (3 x 0.5 + 6) = 7.5 ms<br />
► Device Utilization (U)% = IO_Rate x Service_Time x 100= 45 x 0.75 = 33.75%<br />
► I/O Queue_Time = I/O_Service_Time x (U / (1-U))= 3.8 ms<br />
► I/O_Response_Time = 7.5 + 3.8 = 11.13 ms<br />
Supposing all index set in the buffer<br />
Supposing all index set in the buffer (66% buffer hit) and 50% buffer hits for data:<br />
► I/O Service_Time per average Read caused by one index sequence set I/O<br />
and one data I/O: (1 x 0.5 + 3) = 3.50 ms<br />
► Device Utilization (U)% = IO_Rate x Service_Time x 100= 45 x 0.3 = 15.75%<br />
► I/O Queue_Time for M/M/1= I/O_Service_Time x (U / (1-U)) = 0.65 ms<br />
► I/O_Response_Time = 3.00 + 0.65 = 3.65 ms<br />
► I/O_Response_Time gain proportion = 11.13 / 3.65 = 3.04 times faster
The price of the I/O improvement.<br />
To improve 304% your I/O use buffers, and consequently a trade off between I/O<br />
and memory. How much more buffers?<br />
► For five index set buffers: 5 x 1536 = 7680 KB<br />
► For data buffers calculation we may use a derivation of the 80/20 rule. To have<br />
80% hits we need 20% of buffers. To have 50% hits (as in the scenario)<br />
maybe we just need 10 percent. We have 180 x .91 = 163 CIs not free per CA.<br />
10% of the total number of CIs is: 729 x 163 x 0.1 x 4 _KB = 47.5_ MB<br />
As you can see in an address space of 2Gb and with central storage much larger<br />
than 2Gb the storage price is minimum for the I/O performance gain We have a<br />
bargain.<br />
Hiperbatch<br />
Hiperbatch is designed to eliminate the problems caused by:<br />
► Multiple jobs in one z/OS image requesting data from the same QSAM/<strong>VSAM</strong><br />
NSR data set simultaneously. Each job causes I/O operations to the device<br />
holding the data set. The more jobs that access the data set concurrently, the<br />
more I/O operations and contention for the device, and the longer the wait<br />
time for each I/O request.<br />
► Jobs or job steps passing temporary or short-lived QSAM or <strong>VSAM</strong> NSR data<br />
sets to subsequent jobs. As a job completes, it puts the data used back onto<br />
DASD.<br />
One important aspect of Hiperbatch is that installations can take advantage of<br />
these performance benefits without having to change existing application<br />
programs or the JCL required to run them.<br />
Hiperbatch depends on the data lookaside facility (DLF) address space, to<br />
control access to an Hiperspace Expanded Storage Only (HS ESO).<br />
RACF DLFCLASS profiles provides the data set name list that DLF needs. The<br />
existence of a DLFCLASS profile for a <strong>VSAM</strong> data set identifies that data set as<br />
one that is eligible to be processed as a DLF object.<br />
When DLF is active, the first attempt to access a QSAM or <strong>VSAM</strong> data set<br />
defined to DLF causes it to create a DLF object (like a data set in the HS ESO). A<br />
DLF object contains data from a single data set managed by Hiperbatch. The<br />
user (an application program) is connected to the DLF object, and the connected<br />
user can then access the data in the object through normal QSAM or <strong>VSAM</strong><br />
macro instructions.<br />
Chapter 2. Performance 121
122 <strong>VSAM</strong> <strong>Demystified</strong><br />
When subsequent users access the data set, they are connected to the object.<br />
The system manages shared access to the DLF object in the same way it would<br />
manage shared access to the data set. When a user relinquishes access, DLF<br />
disconnects that user from the object.<br />
A DLF object exists until there are no users of the data set, at which time DLF<br />
deletes the object. As long as there is at least one user of a data set the access<br />
pattern means that the DLF object exists.<br />
However, if a batch job or job step creates a data set and passes it as input to<br />
another job or job step, there is not always one user of the data set, and the<br />
system would delete the DLF object. To prevent this automatic deletion of an<br />
object, define the data set to DLF as a retained DLF object. A retained DLF<br />
object is one that the system does not automatically delete when there are no<br />
users of the data set.<br />
Refer to Figure 2-24 for the following example:<br />
We have a non-retained data set (called Master), that is a DLF object. All the<br />
reading jobs should be started in parallel (as usual without Hiperbatch). The first<br />
job (J1) reads sequentially the record one (R1) and suffers the I/O delay. After the<br />
I/O completion, one copy of R1 is delivered to J1, and another copy is kept in the<br />
HS ESO by Hiperbatch. When J2 requests an I/O for R1 reading, it is intercepted<br />
and fulfilled with the R1 copy in the HS ESO. Then, for N Jobs reading M records<br />
each, from the Master, we have only M accesses to DASD, instead of M * N.<br />
Figure 2-24 highlights the I/O operations not executed.
J0<br />
x<br />
Note: means chronological events<br />
(1) J0 Updates master<br />
(2) J0 Closes and unlockes master<br />
(3) J1 Reads R1 (copy to HS ESO)<br />
(4) J1 R1 (copy to J1 buffer)<br />
(5) J2 Reads R1 (from HS ESO)<br />
(6) J2 Reads R2 (copy to HS ESO)<br />
(7) J2 R2 (copy to J2 buffer)<br />
(8) J1 Reads R2 (from HS ESO)<br />
Figure 2-24 Hiperbatch example<br />
Hiperbatch: Non-Retained Dataset Example<br />
1<br />
Updates<br />
Close 2<br />
R1<br />
J1<br />
Here are some comments about using Hiperbatch with <strong>VSAM</strong>:<br />
► <strong>VSAM</strong> non-shared resource (NSR) access is a requirement.<br />
► Hiperbatch does not support extended format data sets.<br />
► <strong>VSAM</strong> organizations KSDS, ESDS, and RRDS with a control interval of 4096<br />
bytes, or a multiple of 4096 bytes, are eligible.<br />
► The EXCP counts in SMF records used to record I/O use do not change; the<br />
counts reflect I/O operations requested regardless of whether a request is<br />
satisfied by a physical I/O operation or from a DLF object in expanded<br />
storage.<br />
► If the data set is a <strong>VSAM</strong> key sequenced data set (KSDS), the DLF object<br />
contains only the data component, not the index component.<br />
3<br />
J2<br />
HS ESO<br />
R2 6<br />
R2<br />
Master 4<br />
8<br />
5<br />
7<br />
R1<br />
Chapter 2. Performance 123
124 <strong>VSAM</strong> <strong>Demystified</strong><br />
► To avoid data integrity exposures, Hiperbatch does not process a <strong>VSAM</strong> data<br />
set with shareoptions 3 or 4, even if that data set has been defined as eligible<br />
for Hiperbatch.<br />
► <strong>VSAM</strong> data sets with the number of strings (ACBSTRNO) value greater than<br />
1, cannot be Hiperbatch objects.<br />
► <strong>VSAM</strong> data sets must be opened by the base cluster name.<br />
► If a random (or sequential) program changes data in the data set, that change<br />
is also made to the DLF object.<br />
► This method is best suited for sequential processing.<br />
IBM provides an online monitor that you can use to track Hiperbatch activity on<br />
your system. Using the monitor, you can evaluate:<br />
► How Hiperbatch is using expanded storage (or central storage in<br />
z/Architecture)<br />
► The use patterns for individual data sets<br />
► The I/O operation savings for individual jobs<br />
For information about how to install the Hiperbatch monitor, see MVS Hiperbatch<br />
Guide, GC28-1470. Once it is installed, you can invoke the monitor under TSO/E<br />
by issuing the following command:<br />
COFDMON<br />
I/Os associated with CA splits<br />
These I/Os should be avoided. CA splits generate many I/O operations. CA splits<br />
occur in a KSDS or VRRDS along inclusions and increase the logical record size<br />
during an update. CA splits may be minimized by the use of CA free space. Refer<br />
to “Splits” on page 15. However, a CI splits is not a real performance problem<br />
because it needs less than five I/Os.<br />
Secondary space allocations<br />
Every secondary allocation implies going through End-of-Volume processing with<br />
several I/Os in the catalog and VTOC. Refer to 2.6.1, “Allocation units” on<br />
page 49. You should require a consistent amount of secondary allocation.<br />
Write checks<br />
Write checks needlessly increases the number of I/O operations. These should<br />
be avoided.
RECOVERY option<br />
Use the SPEED option instead, when loading a <strong>VSAM</strong> data set. Refer to 2.6.11,<br />
“Initial load option” on page 59.<br />
2.7.3 I/O wait time (IOSQ) for <strong>VSAM</strong> data sets<br />
Tw(IO) has two components respectively: IOS Queue Time and Pending Time.<br />
First lets consider IOSQ time. Let us suppose that you are reading this because<br />
the IOSQ time is the dominant factor in the I/O of your <strong>VSAM</strong> data set.<br />
IOS Queue Time is the time waiting for the device availability in the z/OS<br />
operating system. For a non-ESS device, Input Output Supervisor (IOS) does not<br />
start an I/O operation to a device if there is a previous one executing. In this case,<br />
the I/O operation is queued in the UCB (a control block representing the device to<br />
IOS).<br />
A queue starts to build up when the unique server (device) is utilized above 35<br />
percent. This rule applies to the IOSQ Time. This utilization can be caused by<br />
activity coming from this sysplex image or from another image (in a shared DASD<br />
case), or both.<br />
To decrease the IOSQ Time, you can:<br />
► Buy a faster device/channel to decrease the I/O Service Time (Ts(IO)) and<br />
consequently the utilization (for the same I/O load) and the queue time.<br />
► Decrease the Ts(IO) by tuning. Refer to 2.7.4, “I/O service time (connect) for<br />
<strong>VSAM</strong> data sets” on page 129.<br />
► Change the service class goal containing the transaction which is generating<br />
the I/Os causing the IOSQ time delay. Increase the importance of the goal or<br />
change its numerical value to make it more difficult to be obtained. In<br />
consequence, the I/O priority is raised by the WLM goal mode. This happens<br />
when the transaction is not reaching its goal and the major delay is the I/O<br />
delay. Be aware that, in this case, you are not improving the I/O in general, but<br />
just improving the response time of your favorite transactions.<br />
► Decrease the I/O rate against the device by avoiding placement of several<br />
active data sets on the same volume, (mainly index and data from the same<br />
KSDS). If this happens, verify your ACS routines, perhaps by using<br />
guaranteed space to force the index in a specific volume. Use different<br />
storage groups or the new function DFSMS Data Set Separation announced<br />
in DFSMS z/OS 1.3, where you can separate data sets from each other in<br />
different physical DASD controllers.<br />
► Increasing the parallelism as a way to decrease queue times:<br />
Chapter 2. Performance 125
126 <strong>VSAM</strong> <strong>Demystified</strong><br />
– If your controller has support for dynamic parallel access volume (PAV) as<br />
in the ESS controller, the most effective action to decrease your high IOSQ<br />
time is to implement such hardware/software feature. With PAV you may<br />
have parallel I/Os against the same logical 3390/3380 device (two writes in<br />
the same extent are not allowed) consequently decreasing the IOSQ time.<br />
However, PAV has a price that is, to have N parallel access, we need to<br />
have N alias UCBs and UCWs. If dynamic PAV is activate, WLM manages<br />
the number of UCBs and UCWs per device, increasing the parallelism in<br />
certain devices (and decreasing in others) in order to fulfill the goals of the<br />
most important service classes. Refer to “<strong>VSAM</strong> and ESS controllers” on<br />
page 134.<br />
– Use the great level of parallelism implemented through FICON channels.<br />
DASD cache highlights<br />
A DASD cache is fast storage located in the controller. In a sense it resembles<br />
the buffer pool in memory. A cache, has two functions:<br />
► Minimize access to disks (by having cache hits).<br />
► Serve as a speed matching buffer to synchronize hardware elements with<br />
different speeds (like channels and disks) along a cache miss during<br />
sequential access.<br />
In this explanation the term disk does not have the same meaning of DASD. Disk<br />
implies the RAID media, where data is stored in fixed block architecture (FBA)<br />
blocks through an SSA or an SCSI protocol as used by modern controllers.<br />
DASD is the logical 3390/3380 device as perceived by you, your application, and<br />
your MVS operating system.<br />
To have random cache hits (saving disk access) for reads and writes, the I/O<br />
workload must frequently access the same data or index CI in <strong>VSAM</strong> terms.<br />
Typically there are two types of hits, when the application revisits data:<br />
► Exactly the same logical record, in a CI is already in cache.<br />
► Different logical record in the same CI already in cache because another<br />
logical record was previously accessed.<br />
For sequential access, it is important to say that cache does not save data CI<br />
disk I/O operations. The cache only tries to match the speed of the disks and<br />
channels. Consequently, the faster resource is less utilized. The controller has a<br />
sequential algorithm for reads that implements a look ahead mechanism.
<strong>VSAM</strong> hints to decrease disconnect time due to cache<br />
If the average disconnect time of your key <strong>VSAM</strong> data sets is above two<br />
milliseconds, read this topic. In our example, refer to the scenario described in<br />
Step 6 on page 117.<br />
In the explanations given in this chapter, we still use Monitor III data.<br />
For this performance scenario, let us look at the RMF Monitor III Volume Cache<br />
report in Figure 2-25.<br />
The following details are available for Volume VSM015 on SSID 0043<br />
Press Enter to return to the Report panel.<br />
Cache: Active DFW: Active Pinned: None<br />
------ Read ------ --------- Write --------- Read Tracks<br />
Rate Hit Hit% Rate Fast Hit Hit% %<br />
Norm 3.7 3.6 79.8 0.8 0.8 0.8 100 82.2 0.1<br />
Seq 0.0 0.0 100 0.1 0.1 0.1 93.3 21.1 0.0<br />
CFW 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0<br />
Total 3.7 3.7 98.9 0.9 0.9 0.9 99.1 80.0<br />
------ Misc ------ - Non-Cache - --- CKD ---- - Record Caching -<br />
DFW Bypass : 0.0 ICL : 0.0 Write: 0.0 Read Miss : 0.0<br />
Figure 2-25 Volume Cache report<br />
There are no cache reports per data set in RMF. You can use the volume (the<br />
one that contains your <strong>VSAM</strong> data set) report to reach your conclusions.<br />
Look at the Inhibit cache load (ICL) value first. If it is consistently non-zero, this<br />
may mean:<br />
1. IDCAMS does not properly set the cache attributes in the volume, verify this<br />
by checking whether CACHE and DFW are active in the report header. Then,<br />
change it to normal and DFW.<br />
2. It is an SMS managed data set, and its cache attribute is never-cache. Then,<br />
change its MSR value to allow always-cache or may-cache.<br />
3. It is an SMS data set, and its cache attribute is may-cache. Then change it to<br />
allow always-cache.<br />
If, after making the modifications listed above, the disconnect time does<br />
decrease, or your ICL is close to zero, we have one of two cases:<br />
► Cache overloaded.<br />
► Your data set is cache-unfriendly.<br />
Chapter 2. Performance 127
128 <strong>VSAM</strong> <strong>Demystified</strong><br />
Follow the logic below to determine in your situation. If we reach the conclusion<br />
that your data set is cache unfriendly, better to undo modifications 2 and 3 above,<br />
and read “Decrease <strong>VSAM</strong> disconnect time in general” on page 129.<br />
► If the access is bounded to writes (READ% consistently below 50%), take a<br />
look in the WRITE HIT% column.<br />
Pick up the line corresponding to the highest value in Write RATE (between<br />
NORM and SEQ).<br />
– If NORM is the larger, you have predominantly a random access. Compare<br />
in the NORM line, the FAST value with RATE.<br />
If they are not the same (very seldom), it implies that SMS is not always<br />
using DFW cache mode.<br />
If they are almost the same, check the WRITE HIT% value. It must be<br />
higher than 95%, if less the controller “almost 100% quick writes”<br />
(almost 100% of the random writes should be hits) is not working.<br />
– If SEQ is the larger value (you are writing sequential) and WRITE HIT%<br />
less than 95%, take a look in the DFW Bypass figure. If consistently<br />
non-zero, this means:<br />
The write sequential load saturated the NVS and DFW bypass<br />
occurred. It could be the records are sent synchronously from volatile<br />
cache to disks, or it could be the records are sent asynchronous from<br />
volatile cache to disks and this time is included in disconnect time. In<br />
this case your workload is the cache-unfriendly type. Refer to<br />
“Decrease <strong>VSAM</strong> disconnect time in general” on page 129.<br />
► If the access is dominant in reads (READ% consistently above 50%), look in<br />
the READ HIT% column. Pick up the value corresponding to the highest value<br />
in READ RATE (between NORM and SEQ).<br />
– If NORM is the larger, you have a random access. If the corresponding<br />
READ HIT% is less than 80%:<br />
A low random Read hit. This means that your reads are candidates for<br />
using cache, but they are not having enough hits. Your workload may<br />
be cache unfriendly, if so, here are two suggestions:<br />
Be sure that SMS is using record level cache (RLC) for reads. It avoids<br />
polluting the cache with the rest of the logical 3390/3380 physical track.<br />
Try using a smaller CI for read data or less free space in the CIs. It<br />
avoids polluting the cache with other non-referenced logical records or<br />
free space.<br />
Read “Decrease <strong>VSAM</strong> disconnect time in general” on page 129<br />
– If NORM is the smaller, you have a sequential access. If the corresponding<br />
READ HIT% is less than 80%:
A low sequential read hit. This means that the speed of the channel is<br />
higher than the disk speed. In this case refer to “Decrease <strong>VSAM</strong><br />
disconnect time in general” on page 129.<br />
The KSDS has many CI splits, impeding the controller in recognizing<br />
the sequential pattern; then there is no look-ahead and the cache is<br />
treated in LRU mode. Reorganizing the data set may be an answer.<br />
Refer to 4.1, “Reorganization considerations” on page 204.<br />
Decrease <strong>VSAM</strong> disconnect time in general<br />
One of the reasons to be reading this section is that you have reached the<br />
conclusion that your data set is cache unfriendly.<br />
If cache cannot help your <strong>VSAM</strong> data set, you need to reduce the contention on<br />
the disks. Here are some suggestions.<br />
► Reducing I/O rate (demand) against the controller. This can be done by:<br />
– Either compression or use of smaller CIs for random processing. If you are<br />
accessing data randomly, try to use a smaller CI for read data or less free<br />
space in the CIs. It avoids polluting the cache with other non-referenced<br />
logical records or free space<br />
For compression, refer to 2.6.15, “Data compression” on page 94. For use<br />
of smaller CIs, refer to 2.6.6, “Control interval size” on page 54.<br />
– Reorganize of the data set, if there is plenty of free space in the CIs. Refer<br />
to 2.7.4, “I/O service time (connect) for <strong>VSAM</strong> data sets” on page 129.<br />
However, this reorganization may cause splits.<br />
– Reducing the number of active data sets in the controller.<br />
► Decrease the number of writes in the controller by moving data sets, to avoid<br />
the effect of write penalty in RAID-5. Use the SHARK feature, JBOD, (“Just a<br />
Bunch of Disks”) for your temporary data sets to get rid of write penalty. Use<br />
Shark 800 RAID-10 (RAID-1 plus striping) well suited for intensive write<br />
workloads.<br />
► Try to allocate your data set in 3390/3380 logical volumes mapped in less<br />
capacity disks (18.2 Gb) spinning at 15,000 RPM instead of 10,000RPM.<br />
2.7.4 I/O service time (connect) for <strong>VSAM</strong> data sets<br />
Connect time means the period of time when the channel is transferring data<br />
from or to the cache or exchanging control information with the controller about<br />
one I/O operation.<br />
Chapter 2. Performance 129
130 <strong>VSAM</strong> <strong>Demystified</strong><br />
The average connect time per I/O operation depends on:<br />
► The speed of the communication (including protocol) between the channel<br />
and the controller.<br />
► The amount of data transferred per I/O operation (in all of the chained Read<br />
or Write CCWs)<br />
To analyze your I/O connect time, we recommend that you know the type of<br />
access your <strong>VSAM</strong> data set is facing: sequential or direct. Let us divide our<br />
analysis following these two types:<br />
► Sequential access. If you did not change your channel and controller and you<br />
observe a relatively high connect time for your sequential access <strong>VSAM</strong> data<br />
set, things are working well. It means that a great deal of data is being<br />
transferred in just one I/O operation, through one CCW with a big blocksize or<br />
many CCWs (many buffers). So, the recommendation is to increase the<br />
average connect time. You can get that by using plenty of buffer space in the<br />
buffer pool for sequential processing.<br />
Doing that, you decrease the number of SSCHs instructions (I/O operations).<br />
For every I/O operation starting, there is a standard conversation between the<br />
channel and the controller. If you decrease the number of SSCH instructions,<br />
but are transferring the same amount of data, you save in total connect time.<br />
In other words your average connect time (per I/O operation) increases, but<br />
your total connect time decreases. Refer to Table 2-5 on page 73 and<br />
Table 2-14 on page 101. If the cluster is going to be accessed sequentially<br />
and randomly, the CI size should be made smaller (4 KB). To solve the<br />
performance problem in sequential access, you can define many data buffers,<br />
thus causing <strong>VSAM</strong> to chain CIs in just one channel program. Refer to 2.6.6,<br />
“Control interval size” on page 54.<br />
► Direct access. Here the smaller the average connect time, the better. You<br />
should have small CIs. This avoids bringing unneeded logical records into<br />
memory.<br />
Decrease average connect time<br />
What follows a set of recommendations to decrease the average connect time for<br />
both direct and sequential accesses:<br />
► Use FICON native or FICON Express channels for sequential access. For that<br />
your controllers must have a host adapter able to understand such protocol.<br />
► Use data compression in CPU:<br />
There is a difference between compaction and compression. Compaction has<br />
to do with the simple task of extracting blanks and zeroes from a text.<br />
Compression is a much more elaborate task, where dictionaries may be used<br />
to obtain the best result (like the Ziv-Lempel algorithm). These dictionaries
contain the most repeated set of characters found in the text and their<br />
respective compressed substitution. Refer to 2.6.15, “Data compression” on<br />
page 94.<br />
► Use the ECKD extended format:<br />
ECKD extended format (also called extended format) is a technique that<br />
effects the way count key data is stored in a 3390/3380 logical track. It<br />
improves performance for certain types of I/O operation, by decreasing<br />
Ts(I/O) with a better channel program. Extended format is the base for using<br />
<strong>VSAM</strong> features such as SMB, data striping, compression. and It is<br />
recommended that, if time permits, you convert your data sets to extended<br />
format to get this better performance. Refer to Table 2-15, showing the<br />
following results from our tests of random processing: extended format versus<br />
non-extended format data sets.<br />
Table 2-15 Random processing: extended format versus non-extended format<br />
Ext format Buffering EXCPs Connect<br />
time (sec)<br />
No Default 861744 124<br />
Yes Default 764333 120<br />
Here, for random processing, you can see some decrease in the number of<br />
EXCPs and in the connect time. However, the big performance appeal of<br />
extended format is that it allows the use of strong performance capabilities<br />
such as striping, compressing, and SMB.<br />
► Less free space in the CIs:<br />
The existence of a significant amount of free space in a CI, may increase the<br />
I/O connect time. This free space may be caused by an excess in the<br />
definition of the data set, or by CI and CA splits. Remember that any CI with a<br />
logical record is moved to storage in a sequential read. This is not true with<br />
totally free CIs, where no I/O operations are executed towards them.<br />
Note: We are not saying that all insertions increase the average free space<br />
per byte in the data set.<br />
The solution here may be a reorganization. Refer to 4.1, “Reorganization<br />
considerations” on page 204, watching for an increase in the number of splits.<br />
► Parallel <strong>VSAM</strong> I/O operations:<br />
Sometimes, if you cannot decrease the service time (Ts), you may increase the<br />
ETR (and decrease the queue time) by introducing parallelism. There are two<br />
types of I/O parallel processing:<br />
Chapter 2. Performance 131
132 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Within a transaction:<br />
The <strong>VSAM</strong> option which allows I/O parallelism within a transaction or task<br />
(when accessing a <strong>VSAM</strong> cluster) is data striping. Refer to 2.6.16, “<strong>VSAM</strong><br />
Data striping” on page 103.<br />
► Between transactions:<br />
There are <strong>VSAM</strong> options which allow parallelism between transactions or<br />
tasks, when accessing a <strong>VSAM</strong> cluster, such as:<br />
STRNO: In multiple string processing, there can be multiple<br />
independent Request Parameter Lists (RPL) within an address space<br />
for the same data set. The data set can have multiple tasks that share a<br />
common control block structure. There are several ACB and RPL<br />
arrangements to indicate that multiple string processing will occur.<br />
In the first ACB opened, STRNO or BSTRNO is greater than 1.<br />
Multiple ACBs are opened for the same data set within the same<br />
address space and are connected to the same control block structure.<br />
Multiple concurrent RPLs are active against the same ACB using<br />
asynchronous requests.<br />
Multiple RPLs are active against the same ACB using synchronous<br />
processing with each requiring positioning to be held.<br />
Refer to z/OS DFSMS Using Data Sets, SC26-7410, for more information on<br />
multiple string processing.<br />
In ESS, the PAV and Multiple Allegiance features implement I/O parallelism in the<br />
same volume, within or among transactions.<br />
2.7.5 Decreasing <strong>VSAM</strong> CPU time<br />
The major theme of this section is to decrease the Tr(I/O) for <strong>VSAM</strong> I/O<br />
operations, in order to decrease the response time of key transactions using<br />
<strong>VSAM</strong> data sets. However, chances are that the enhancements introduced by<br />
your changes may shift the bottleneck to the CPU side. You will find that:<br />
► If you compress your <strong>VSAM</strong> data set, your transaction response time<br />
decreases, which is good.<br />
► If you stripe your <strong>VSAM</strong> data set, your transaction response time decreases,<br />
which is also good.<br />
► If you compress and stripe your <strong>VSAM</strong> data set, your response time gets<br />
bigger (which is bad). The reason is that CPU is extremely busy, causing<br />
huge CPU delays negating the I/O gains.
<strong>VSAM</strong> buffering<br />
The adequate use of buffering (mainly for direct access) may result in savings in<br />
the CPU usage, as you can see in Table 2-16.<br />
Increasing the number of buffers decreases the number of EXCPs, that is, the<br />
number of executed I/O operations. In <strong>VSAM</strong>: one EXCP corresponds to one<br />
SSCH and corresponds to one I/O operation. For the same amount of logic in<br />
your code, the CPU time that you spend is a direct function of the number of<br />
EXCPs. Because in our lab, the read data is not processed, we can say that:<br />
► SRB time is caused by I/O interrupts (back end) processing.<br />
► TCB time is the I/O operation preparation and buffer pool management.<br />
It is clear that increasing the number of buffers means the management cycles<br />
dominate the savings in the I/O operations. Refer to “Our test environment” on<br />
page 396.<br />
Table 2-16 NSR: Read sequential varying the number of buffers<br />
Data buffers Index buffers EXCPs SRB time<br />
(seconds)<br />
Default=2 Default=1 167828 2.12 7.52<br />
10 1 33568 0.53 3.99<br />
30 1 11577 0.26 3.44<br />
181 1 3476 0.19 3.86<br />
SMB 4633 0.23 3.45<br />
Also, the use of better techniques to manage your buffer pool, such as BLSR or<br />
system management buffers (SMB), can save enormous CPU cycles. See<br />
Table 2-17, which shows data obtained from our lab.<br />
Table 2-17 Direct access: benefits of using SMB: Reads and insertions<br />
Ext format Buffering EXCPs connect time<br />
(sec)<br />
TCB time<br />
(seconds)<br />
CPU time<br />
(sec)<br />
No Default 861744 123.5 52.46<br />
No BLSR 330852 73.14 24.42<br />
Yes SMB 280276 62.5 19.22<br />
Gain using SMB (%) 68% 50 63<br />
Chapter 2. Performance 133
134 <strong>VSAM</strong> <strong>Demystified</strong><br />
Use of extended format<br />
The use of extended format data sets can save a consistent amount of CPU time<br />
(TCB plus SRB). Consider the values shown in Table 2-18.<br />
Table 2-18 Direct access: benefits of using SMB: Reads<br />
Ext format Buffering EXCPs CPU time (sec)<br />
No Default 794950 31.76<br />
Yes SMB 102697 8.53<br />
Gain using SMB (%) 87% 73%<br />
Refer to 1.9, “Extended format data set” on page 28, for more information.<br />
Compression<br />
Compression of data can really increase the CPU time in your program.<br />
► Track versus cylinder allocation<br />
It is not true anymore that, when allocating <strong>VSAM</strong> data sets in cylinders, you<br />
consume less CPU than using track allocation. Because, if the channel<br />
program is crossing an extent boundary, it is informed about the correct<br />
extents through the Define Extent CCW.<br />
2.8 <strong>VSAM</strong> and ESS controllers<br />
In the previous versions of this book, we made extensive tests with <strong>VSAM</strong><br />
clusters in order to measure how effective some <strong>VSAM</strong> features are. All of these<br />
experiences were made on a ESS model F model. In this version of this book, we<br />
change completely our I/O workload. However, we repeat two of those old<br />
measurements (with the old I/O workload), just changing the type of channels<br />
(from ESCON® to FICON) and using the new ESS model 800. The objective is to<br />
compare the gains in <strong>VSAM</strong> by just changing the I/O hardware.<br />
2.8.1 ESS model 800 enhancements<br />
Before we show the results, we cover the new main enhancements of ESS model<br />
800 Shark in order to correlate them with the measured results:<br />
► More processor power<br />
Model 800 offers 4 x 600 MHz processors per cluster (old model F20 it was 4<br />
x 225 MHz per cluster). There is also a turbo feature implementing 6 x 668<br />
MHz per cluster (our ESS is not a turbo).
2.8.2 Lab experiments<br />
► Aggregate bandwidth<br />
Model 800 allows 4.8 GB/second of aggregate bandwidth against 2.7<br />
GB/second in model F20.<br />
► Up to 64 GB of cache, formatted in 4 KB segments, so for small data blocks (4<br />
KB and 8 KB are common database block sizes) minimum cache is wasted.<br />
Our CI size is 4 KB.<br />
► High performance 15,000 rpm disks drives. We did not use such disks in our<br />
tests<br />
► New CCWs. For the z/OS environments, the ESS supports channel command<br />
words (CCWs) that reduce the characteristic overhead associated to the<br />
previous (3990) CCW chains. Basically, with these CCWs, the ESS can read<br />
or write more data with fewer CCWs. CCW chains using the old CCWs are<br />
converted to the new CCWs whenever possible. The cooperation of z/OS<br />
software and the ESS provides the best benefits for the application’s<br />
performance.<br />
We repeated two runs, as we did in the previous version of this book. The first<br />
one accessing sequentially and the second accessing randomly:<br />
► Initial load with speed and SMB.<br />
The results are shown in Table 2-19.<br />
Table 2-19 Comparison initial load with ESS<br />
Initial<br />
Load<br />
Extended<br />
Format<br />
EXCPs Connect<br />
Time<br />
(msec)<br />
CPU Time<br />
(sec)<br />
Shark - F YES 2341 21.5 2.7 27<br />
Shark-800 YES 2401 5.6 1.81 10<br />
Elapsed<br />
Time (sec)<br />
As you can see, there is four times less connect time for almost the same<br />
number of EXCPS. What Shark and FICON can do is to decrease the connect<br />
time, and they did it. About the number of EXCPs depends on the number of<br />
buffers. There is a decrease in CP time because we jump from a 9672 to the<br />
z900 1C7.<br />
► Direct access with SMB (inserts and updates)<br />
Chapter 2. Performance 135
136 <strong>VSAM</strong> <strong>Demystified</strong><br />
Table 2-20 Comparison Direct access with ESS<br />
The connect time per EXCP in the first run is 0.9 ms. The same figure in the<br />
second run is 0.2 ms. So, the gain in connect was more than 8 fold. Note also<br />
the decrease in the elapsed time.<br />
2.9 Performance monitors<br />
SMB EXCPs Connect<br />
Time (sec)<br />
Follows a list of performance monitors, whose output can help you in solving<br />
SMS<strong>VSAM</strong> performance problems.<br />
2.9.1 Resource measurement facility<br />
CPU Time<br />
(sec)<br />
Shark - F YES 79,741 75 11.04 150<br />
Shark-800 YES 28,405 6 3.99 7<br />
Elapsed<br />
Time (sec)<br />
RMF product issues reports about performance problems as they occur, so that<br />
your installation can take action before the problems become critical. Your<br />
installation can be used RMF to:<br />
► Determine that your system is running smoothly<br />
► Detect system bottlenecks caused by contention for resources<br />
► Evaluate the service your installation provides to different groups of users<br />
► Identify the workload delayed and the reason for the delay<br />
► Monitor system failures, system stalls, and failures of selected applications<br />
RMF comes with three monitors, Monitor I, II and III.<br />
► Monitor III with its ability to determine the cause of delay is where we start. It<br />
provides short term data collection and online reports for continuous<br />
monitoring of system status and solving performance problems. It allows the<br />
system tuner to distinguish between delays for important jobs and delays for<br />
jobs that are not as important to overall system performance<br />
► Monitor I provides long term data collection for system workload and resource<br />
utilization. The Monitor I session is continuous, and measures various areas<br />
of system activity over a long period of time.<br />
You can get Monitor I reports directly as real-time reports for each completed<br />
interval (single-system reports only), or you let run the Postprocessor to<br />
create the reports, either as single-system or as sysplex reports. Many
installations produce daily reports of RMF data for ongoing performance<br />
management. Sometimes a report is called a Monitor I report (for example,<br />
the Workload Activity report) although it can be created only by the<br />
Postprocessor.<br />
► Monitor II provides online measurements on demand for use in solving<br />
immediate problems. This Monitor II session can be regarded as a snapshot<br />
session. Unlike the continuous Monitor I session, a Monitor II session<br />
generates a requested report from a single data sample. Since Monitor II is<br />
an ISPF application, you might use Monitor II and Monitor III simultaneously<br />
in split-screen mode to get different views of the performance of your system.<br />
In addition, you can use the Spreadsheet Reporter for further processing the<br />
measurement data on a workstation by help of spreadsheet applications. The<br />
following chapters provide sample reports including the name of the<br />
corresponding macro.<br />
2.9.2 Tivoli Decision Support (TDS)<br />
TDS is product contained in Tivoli ® Information Management for z/OS suite of<br />
products.<br />
Tivoli Information Management for z/OS is a process automation tool that<br />
delivers Systems Management Services, including Incident, Problem, Change<br />
and Asset management applications, for your end-to-end managed environment.<br />
With TDS you can also have immediate access to key enterprise information<br />
about performance and capacity, stored in a DB2 database. TDS provides<br />
ready-to-use views and reports, so that you can identify key problems. You can<br />
design your own reports and views through the use of SQL language easy code.<br />
Information viewed with TDS can be published on a Web site, or as an<br />
information ticker that streams across the user’s desktop if your company uses<br />
broadcast tools. Users can then check the information before calling their internal<br />
help desk to report a problem.<br />
2.9.3 Generalized Trace Facility (GTF)<br />
GTF is an MVS component able to capture very detailed information about<br />
events occurring in the system. Among those events, we have: SSCHs and I/O<br />
interruptions. If you have a complex <strong>VSAM</strong> DASD I/O performance situation, you<br />
may run GTF with CCW trace option as shown in the “REXX code to list<br />
compression ratio” on page 384. When you can use IPCS to format the data<br />
produced by GTF or you may use a home made product.<br />
Chapter 2. Performance 137
138 <strong>VSAM</strong> <strong>Demystified</strong><br />
For example, we use GTF data to calculate in our lab the total connected time<br />
associated to one data sets.
Chapter 3. <strong>VSAM</strong> problem<br />
determination and recovery<br />
In this chapter we provide some general tips on <strong>VSAM</strong> problem determination.<br />
We then go through a number of common <strong>VSAM</strong> problems and explain how to<br />
recover from them. We then follow with some suggestions to avoid problems and<br />
then we point you to some useful documentation that will assist you with your<br />
problem determination and recovery.<br />
The topics cover:<br />
► <strong>VSAM</strong> problem determination hints and tips<br />
► Some common <strong>VSAM</strong> problems<br />
► What documentation to collect<br />
► How to recover a damaged <strong>VSAM</strong> data set<br />
► Prevention is better than cure<br />
► Where to look for more information<br />
► IDC3009I message<br />
► IDCAMS LISTCAT output fields<br />
3<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 139
3.1 <strong>VSAM</strong> problem determination hints and tips<br />
140 <strong>VSAM</strong> <strong>Demystified</strong><br />
In the complex environment of computing today, users have an array of tools and<br />
disciplines at their disposal to aid problem determination and recovery of <strong>VSAM</strong><br />
spheres and data sets. z/OS writes numerous records like SMF, LOGREC and<br />
syslog that can be used to debug a problem and recover data.<br />
You may have heard user comments like these:<br />
► Everything was working yesterday; we haven’t changed anything since then.<br />
► We are starting to get strange error messages, and the explanations in the<br />
manual are meaningless.<br />
► We cannot access the data, and do not know where to turn for help.<br />
Your data is one of the most valuable assets of your business. The challenge, in<br />
order to save your data, is to use all the error information available to answer<br />
these three questions:<br />
► What caused this problem?<br />
► How you can recover your data?<br />
► What you can do to avoid these problems in the future?<br />
In this section we will give you some general tips on what to look for and how to<br />
determine what caused the problem and how to recovery from a problem.<br />
3.1.1 How to check your <strong>VSAM</strong> data set<br />
A number of IDCAMS commands are available to check your <strong>VSAM</strong> data sets.<br />
EXAMINE<br />
You can use the EXAMINE IDCAMS command to analyze and report on the<br />
structural integrity of the index and data components of a key-sequenced data<br />
set cluster (KSDS) and of a variable-length relative record data set cluster<br />
(VRRDS). Any problems with the <strong>VSAM</strong> data set will be reported by one of the<br />
IDCxxxxx messages. Look in MVS System Messages, Volume 3 (GDE - IEB) for<br />
the explanation for these messages.<br />
The EXAMINE command is described in detail in “EXAMINE command” on<br />
page 165.<br />
VERIFY<br />
The VERIFY command causes a catalog to correctly reflect the end of a <strong>VSAM</strong><br />
data set after an error occurs while closing a <strong>VSAM</strong> data set. The error might
have caused the catalog to be incorrect. For details of this command refer to<br />
“VERIFY command” on page 166<br />
DIAGNOSE<br />
The DIAGNOSE command can be used to scan a basic catalog structure (BCS)<br />
or a <strong>VSAM</strong> volume data set (VVDS) to validate the data structures and detect<br />
structure errors. See “DIAGNOSE command” on page 166 for more details.<br />
DFSMSdss PRINT command<br />
With the PRINT command, you can print:<br />
► A single volume non-<strong>VSAM</strong> data set, as specified by a fully qualified name.<br />
You must specify the volume where the data set resides, but you do not need<br />
to specify the range of tracks it occupies.<br />
► A single-volume <strong>VSAM</strong> data set component (not cluster). The component<br />
name specified must be the name in the VTOC, not the name in the catalog.<br />
► Ranges of tracks.<br />
► All or part of the VTOC. The VTOC location need not be known.<br />
LISTCAT<br />
You can list the catalog entries using the LISTCAT command. It is described in<br />
“IDCAMS LISTCAT output fields” on page 187.<br />
3.1.2 z/OS system messages<br />
OS/390 components issue messages with the IEA prefix, associated with data<br />
set allocation, master scheduler functions, and RTM. The IOS prefix is for IOS<br />
functions. Usually those messages follow abends:<br />
► IEC070I — RC32, RC202, RC104, or RC203<br />
► IOS000I — Command reject (IOS errors in general)<br />
3.1.3 Catalog Search Interface IGGCSIVS program<br />
This Catalog Search Interface (CSI) produces a list of data set names defined in<br />
a given catalog that reside on a specific volume. Refer to 4.5, “Catalog Search<br />
Interface” on page 231, for more information.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 141
3.1.4 System LOGREC messages<br />
3.1.5 GTF CCW traces<br />
142 <strong>VSAM</strong> <strong>Demystified</strong><br />
Often the system will recover from a problem and so will be transparent to you;<br />
but it will generate error records in the LOGREC. If you suspect a problem<br />
LOGREC may give you some valuable information.<br />
You can collect GTF CCW traces to get detailed information on I/Os to <strong>VSAM</strong><br />
data sets. These traces can be formatted using IPCS. For sample JCL to collect<br />
a GTF trace refer to Example 3-6, “Sampler JCL for GTF trace” on page 165.<br />
3.1.6 DITTO/ESA output<br />
This utility can be used to browse <strong>VSAM</strong> records. For details, refer to<br />
“DITTO/ESA” on page 35<br />
3.1.7 What can you get from the SMF records?<br />
You can get a lot of information from SMF record types 60 to 69 to analyze <strong>VSAM</strong><br />
problems. SMF record type 42 contains information on <strong>VSAM</strong> RLS statistics.<br />
Refer to 3.9, “SMF record types related to <strong>VSAM</strong> data sets” on page 194 for<br />
detailed information on these SMF records. You can use our SMF 64 sample<br />
program as described in that topic.<br />
3.2 Some common <strong>VSAM</strong> problems<br />
Here we describe some problems which may affect the processing and the<br />
existence of your <strong>VSAM</strong> data sets. To simplify our search for a solution to each<br />
problem, we can use the three “Whats”, for example, occurrence, recovery, and<br />
avoidance.<br />
In each subsection we cover the three “Whats”:<br />
► What happened to cause this problem?<br />
► What must you do in order to recover your data now?<br />
► What must you do to avoid this problem in the future?<br />
Broken data sets can be caused by many different circumstances, including user<br />
errors. When diagnosing these types of problems, the first thing that must be<br />
done is to identify what is actually wrong with the data set. The first sign of a<br />
problem is the <strong>VSAM</strong> or the z/OS system messages. A single error can often<br />
generate numerous messages. You should focus your attention on the return<br />
code presented and the companion explanation. This return code will be the one
passed by the system component that first encountered the error. In most cases,<br />
you will need additional documentation; refer to 3.3, “What documentation to<br />
collect” on page 162.<br />
In this section we group the errors by categories. However, this is not an easy<br />
task. Some of the categories overlap and even interact with others. For example,<br />
a bad channel program may be caused by an improper sharing, which caused a<br />
structural damage.<br />
3.2.1 Lack of virtual storage<br />
The following messages may indicate a lack of virtual storage:<br />
► IDC3351I ** <strong>VSAM</strong> {OPEN|CLOSE|I/O} RETURN CODE IS return-code<br />
– 136 (Close): Not enough virtual storage was available in the program's<br />
address space for a work area for Close.<br />
– 132 (Open): One of the following errors occurred:<br />
Not enough storage was available for work areas.<br />
The format-1 DSCB or the catalog cluster record is incorrect.<br />
– 136 (Open): Not enough virtual storage space is available in the program's<br />
address space for work areas, control blocks, or buffers.<br />
– 40 (I/O): Insufficient virtual storage in the user's address space to<br />
complete the request.<br />
► IEC161I 001 [(087)]-ccc,jjj, sss,ddname,dev,ser,xxx, dsname,cat<br />
What happened?<br />
Due to the lack of virtual storage, an abend occurs. In this case, a symptom<br />
dump may be included.<br />
What to do for recovery?<br />
Because the data set processing was interrupted (abended) in apparently<br />
unknown circumstances, there are two cases:<br />
► <strong>VSAM</strong> data set is being accessed by a subsystem as CICS, then CICS was<br />
doing the synchpoint, journaling, and is able to recover your data by rolling it<br />
back.<br />
► <strong>VSAM</strong> data set being accessed by your program; then you should correct the<br />
virtual storage problem and re-run the program (if possible) or restore the<br />
backup and re-run the job.<br />
Sometimes, the message is not the result of an abend. It can be an alert as with<br />
IEC161I, where BLDVRP macro indicates that there was not enough virtual<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 143
144 <strong>VSAM</strong> <strong>Demystified</strong><br />
storage to satisfy the request done by System Management Buffering (SMB).<br />
SMB gets the available storage, and processing goes on.<br />
What to do to avoid future problems?<br />
Initially, read 2.6.12, “Region size” on page 61. If possible, increase your region<br />
below or above, or decrease the common area below 16 MB, or force your<br />
software to be in R31 mode.<br />
Determine if the <strong>VSAM</strong> buffers and their control blocks are below or above the 16<br />
MB line. If below, read “Locating <strong>VSAM</strong> buffers above 16 MB” on page 81 to learn<br />
how to move them above with integrity.<br />
3.2.2 Initial loading problems<br />
The following messages may indicate initial load problems:<br />
► IDC3308I ** DUPLICATE RECORD xxx<br />
The output data set of a REPRO command already contains a record with the<br />
same key or record number.<br />
► IDC3351I ** <strong>VSAM</strong> {OPEN|CLOSE|I/O} RETURN CODE IS return-code<br />
– 8 (I/O): You attempted to store a record with a duplicate key, or there is a<br />
duplicate record for an alternate index with the unique key option<br />
– 12 (I/O): You attempted to store a record out of ascending key sequence in<br />
skip-sequential mode; record had a duplicate key; for skip-sequential<br />
processing, your GET, PUT, and POINT requests are not referencing<br />
records in ascending sequence; or, for skip-sequential retrieval, the key<br />
requested is lower than the previous key requested. For shared resources,<br />
the buffer pool is full.<br />
– 116 (I/O): During initial data set loading (that is, when records are being<br />
stored in the data set the first time it is opened), GET, POINT, ERASE,<br />
direct PUT, and skip-sequential PUT with OPTCD=UPD are not allowed.<br />
During initial data set loading, for initial loading of a relative record data<br />
set, the request was other than a PUT insert.<br />
What happened?<br />
These messages point to problems with initial load or mass insertion (also called<br />
skip sequential) of a <strong>VSAM</strong> cluster.<br />
Initial load of your data set can be done by IDCAMS REPRO or by a program of<br />
yours. Refer to 2.6.11, “Initial load option” on page 59, for more information.<br />
When loading a <strong>VSAM</strong> KSDS data set, the logical records must be sorted in a<br />
key sequenced order. No out-of-sequence or duplicated keys are allowed. Refer
to the above messages for a more detailed explanation about which of these<br />
requirements were not fulfilled.<br />
If the duplicated keys message applies to the initial load of an alternate index<br />
(AIX) cluster, remember that for AIX is possible to have duplicated keys, but in<br />
this case you should not use the UNIQUE parameter, which would definitely<br />
cause this error.<br />
Mass insertion resembles initial load in the sense that all the added logical<br />
records also need to be sorted by a key field. The difference is that in mass<br />
insertion, we are loading sequentially logical records to a data set which already<br />
has previous data.<br />
What to do for recovery?<br />
Here, there is not a need for recovery. Your data is saved in the input file. It is a<br />
matter of sorting and re-running the program.<br />
What to do to avoid future problems?<br />
After correcting the error, introduce a procedure in production to avoid having the<br />
same error again.<br />
3.2.3 Mismatch between catalog and data set<br />
The following error messages may indicate a mismatch between catalog and<br />
data set information:<br />
► IDC3351I ** <strong>VSAM</strong> OPEN RETURN CODE IS 108<br />
108: Attention message: the time stamps of a data component and an index<br />
component do not match. This indicates that either the data or the index has<br />
been updated separately from the other. Check for possible duplicate VVRs.<br />
► IDC3351I DATA SET IS ALREADY OPEN FOR OUTPUT OR WAS NOT CLOSED<br />
CORRECTLY<br />
► The data set is already OPEN for output by a user on another system, or was<br />
not previously closed.<br />
► IDC11709I DATA HIGH-USED RBA IS GREATER THAN HIGH-ALLOCATED RBA<br />
The data component high-used relative byte address is greater than the<br />
high-allocated relative byte address. Supportive messages display pertinent<br />
data, and processing continues.<br />
► IDC11712I DATA HIGH-ALLOCATED RBA IS NOT A MULTIPLE OF CI SIZE<br />
The high-allocated relative byte address is not an integral multiple of the<br />
control interval size.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 145
146 <strong>VSAM</strong> <strong>Demystified</strong><br />
► IDC11727I INDEX HIGH-USED RBA IS GREATER THAN HIGH-ALLOCATED RBA<br />
The index component high-used relative byte address is greater than the<br />
high-allocated relative byte address.<br />
► IDC3350I synad[SYNAD] NO RECORD FOUND from <strong>VSAM</strong><br />
What happened?<br />
The data set may be intact, but the catalog information describing the data set<br />
mismatch problems. It sometimes results in an open failure.<br />
The most common discrepancies between the catalog and cluster are these:<br />
► There were different time stamps between index and data components.<br />
► HURBA and HARBA not correctly updated, mainly caused by an abend,<br />
without a normal close.<br />
► Open-for-output bit on for a closed cluster; mainly caused by an abend,<br />
without a normal close, or other task accessing from other system. Refer to<br />
3.4.5, “Abend task scenario” on page 171, for more information.<br />
► RBAs fields in the VVR do not match the data set attributes, for example:<br />
– If the RBA of the high-level index CI is corrupted, you are not be able to<br />
perform direct requests against the data set.<br />
– If the RBA of the sequence set index CI is corrupted, you are not able to<br />
perform sequential access.<br />
These last two discrepancies are not covered here; refer to 3.2.6, “Structural<br />
damage” on page 150.<br />
A LISTCAT output (or CSI report) can help with the documentation for problem<br />
determination.<br />
What to do for recovery?<br />
IDCAMS VERIFY is a requirement in this type of problem. In this case, VERIFY<br />
can correct HURBA and verify the open-for-output bit.<br />
► Different time stamps; Open does not abend your task, so continuation or<br />
abend of the application depends on the program that issues the OPEN. In<br />
general, it will keep processing, but another problem is likely to occur.<br />
We suggest you run VERIFY (to be sure and document the mismatch) and<br />
then run EXAMINE to guarantee no structural damage exists for KSDS and<br />
VRRDS, with a test for the index option only (INDEXTEST).<br />
Completion of EXAMINE without error proves that there are no structural<br />
damages. If the index component shows damage at this point, it must be<br />
restored before further use. Refer to 3.4.4, “Broken Index scenario” on
3.2.4 Hardware errors<br />
page 169, to get some information on doing that. Note that EXAMINE may<br />
provide messages containing only informational data that may not require<br />
restoring the cluster.<br />
► HURBA and HARBA not correctly updated.<br />
If the HURBA is not updated, when the data set is subsequently opened and<br />
the user's program attempts to process records beyond end-of-data or<br />
end-of-key range, a read operation results in a “no record found” error, and a<br />
write operation might write records over previously written records. To avoid<br />
this, you can use the VERIFY command which corrects the catalog<br />
information.<br />
► Open-for-output bit on for a closed cluster.<br />
At next OPEN, <strong>VSAM</strong> implicitly issues a VERIFY command, when it detects<br />
an open-for-output indicator on and issues an informational message (maybe<br />
the one that you are seeing) stating whether the VERIFY command is<br />
successful.<br />
If a subsequent OPEN is issued for output, <strong>VSAM</strong> turns off the<br />
open-for-output indicator at successful CLOSE. If the data set is opened for<br />
input, however, the open-for-output indicator is left on.<br />
Messages that indicate hardware errors include:<br />
► IOS000I dev,chp,err,cmd,stat, dcbctfd,ser,mbe,eod, jobname,sens text<br />
The system found an uncorrectable I/O error in device error recovery. Text is<br />
one of the following types:<br />
– Channel interface, or protocol error<br />
– Device has exceeded long busy timeout<br />
– Permanent error — volume fenced<br />
– Permanent error — device reported unknown message code = cde<br />
– Channel control, data, chaining, program, protection, interface check<br />
– Unable to obtain sense data from the device<br />
► IDC3351I ** <strong>VSAM</strong> {OPEN|CLOSE|I/O} RETURN CODE IS return-code<br />
– 184 (Open): An uncorrectable I/O error occurred while <strong>VSAM</strong> was<br />
completing outstanding I/O requests.<br />
– 246 (Close): The compression management services (CMS) close<br />
function failed.<br />
– 184 (Open): An uncorrectable I/O error occurred while <strong>VSAM</strong> was<br />
completing an I/O request.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 147
148 <strong>VSAM</strong> <strong>Demystified</strong><br />
– 245 (I/O): A severe error was detected by the compression management<br />
services (CMS) during compression processing).<br />
– 246 (I/O): A severe error was detected by the compression management<br />
services (CMS) during decompression processing.<br />
– 250 (I/O): A valid dictionary token does not exist for the compressed data<br />
set. The data record cannot be decompressed.<br />
What happened?<br />
Hardware I/O errors usually mean that the I/O hardware (channel, controller,<br />
device) had a problem executing that I/O. For compressed <strong>VSAM</strong> data sets, you<br />
may have hardware problems with the CPU compression assist function.<br />
The first thing to do is break down the message to get more details on the error.<br />
An IDCAMS LISTCAT (if possible) of the data set is also helpful to give the<br />
attributes of the file in the logical 3390/3380, such as: the physical record size,<br />
the device type and the CCHH of all extents. LOGREC output is also valuable. A<br />
GTF CCW trace may be necessary to run DIAGNOSE on the problem, however,<br />
for such tools, you may need to recreate the situation.<br />
VERIFY IGGCSIVS is a program from SYS1.SAMPLIB accessing Catalog<br />
Search Interface (CSI) which produces a list of data set names defined in a given<br />
catalog that reside on a specific volume. Such a list might be helpful in a recovery<br />
situation affecting that volume.<br />
When accessing with <strong>VSAM</strong> macros, a <strong>VSAM</strong> data set where a physical error<br />
was detected, the register 15 comes with return code equal to 12.<br />
What to do for recovery?<br />
In the case of a media error, do not use ICKDFS to run an Analyze and Inspect<br />
function. The characteristics of the physical devices that make up the RAID<br />
devices family do not allow the use of the ICKDSF commands that perform<br />
installation, media maintenance and problem determination functions, such as<br />
Install, Analyze, and Inspect.<br />
If the problem happens with the compress assist feature, run the program again,<br />
switching off data compression in the data class.<br />
What to do to avoid future problems?<br />
If the error is in the DASD controller, keep a log of such type of occurrences to<br />
force a better quality of the manufacturer or change to other. Another solution (for<br />
some media problems) is to implement RAID-1 dual copy (in the same controller)<br />
or remote copy (in two controllers), mainly for your most critical data, such as<br />
logs.
3.2.5 Bad data or bad channel program<br />
The following message may indicate bad data or bad channel program:<br />
IDC3351I ** <strong>VSAM</strong> {OPEN|CLOSE|I/O} RETURN CODE IS return-code<br />
► 140 (Open): The catalog indicates this data set has an incorrect physical<br />
record size.<br />
► 16 (I/O): Record not found.<br />
► 88 (EOV): A previous extend error has occurred during EOV processing of the<br />
data set.<br />
What happened?<br />
This problem may be pervasive, but in general, it is usually caused by two major<br />
reasons:<br />
► Duplicate VVRs<br />
► A bad channel, causing data overlays and corrupting indexes<br />
The existence of damaged or duplicate VVRs on a volume may cause data sets<br />
to be overlaid with data from other data sets.<br />
<strong>VSAM</strong> volume record (VVR) is a logical record within <strong>VSAM</strong> volume data set<br />
(VVDS). VVDS is a data set that describes the dynamic characteristics of <strong>VSAM</strong><br />
and system-managed data sets residing on a given DASD volume. Together with<br />
the BCS, it is a part of an integrated catalog facility.<br />
There are many things that can cause the channel program to be bad. The most<br />
common causes of a bad channel program is that the data that describes the<br />
data set is bad. If a bad VVR is picked up at Open time, <strong>VSAM</strong> may try to access<br />
cylinder and tracks that do not belong to the data set getting various I/O errors.<br />
If another program overlays the <strong>VSAM</strong> data set, this can cause the channel<br />
program to fail at that spot where the other data exists. For instance, if the CI size<br />
of the <strong>VSAM</strong> file that is broken is 4 KB, the channel program is built to read<br />
records of that size. If another program has overlaid the file with records of, say,<br />
16 KB size, the channel programs for the record size of 4 KB fails on all<br />
cylinder/tracks/heads that do not have this record size. This situation is usually<br />
referred to as bad data.<br />
Theoretically, system code problems can cause <strong>VSAM</strong> to build channel program<br />
incorrectly, or in some cases they may be built correctly, but they are getting<br />
modified incorrectly and redriven by ERP or even third party products. Luckily,<br />
these reasons are not too common, even with new device types.<br />
In regard to corrupted indexes, refer to 3.2.6, “Structural damage” on page 150.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 149
150 <strong>VSAM</strong> <strong>Demystified</strong><br />
With problems like these, it is important to get as much information about the<br />
data set as you can before the customer restores it. We suggest using:<br />
► LISTCAT or CSI.<br />
► DFSMSdss (PRINT command) or Ditto to print the 3390/3380 logical<br />
cylinder/track/head that the I/O error is occurring. It can indicate whether<br />
there is any data at all on the track, or if the data that is there belongs to a<br />
different data set.<br />
► SMF records, mainly the type 6x connected to catalog and <strong>VSAM</strong> data sets.<br />
After the data set has been recovered, the only “history” that can be EXAMINEed<br />
is the SMF records. If the problem “clears up” after the data set is closed, but<br />
without the data set being recovered, you might suspect a problem with an<br />
internal control block being overlaid, rather than something on DASD.<br />
What to do for recovery?<br />
This overlay is a hard failure and the data set has to be manually restored from a<br />
backup. Often, in this case, the bad data itself gives a clue as to what data set or<br />
application has caused the overlay. Trying to avoid the restore for a bad KSDS<br />
data component, you may try to skip past the bad data records, and recover only<br />
those records that can be properly read.<br />
A DIAGNOSE command even after the data set has been recovered can check<br />
for this problem (since only a DELETE VVR can get rid of an orphan after one<br />
occurs). Luckily, many enhancements have been introduced to Catalog and<br />
Open processes in the last few years to check for duplicate VVRs at OPEN time,<br />
so this should be less of a problem.<br />
What to do to avoid future problems?<br />
Experience has shown that the majority of such errors are caused by improper<br />
sharing. If you are sharing your <strong>VSAM</strong> data set, refer to 3.2.7, “Improper sharing”<br />
on page 153.<br />
Because such types of errors may also be caused by system errors, you may<br />
want to investigate the possibility of APARs and PTFs related to the problem.<br />
3.2.6 Structural damage<br />
The following message may indicate structural damage:<br />
IDC3351I ** <strong>VSAM</strong> {OPEN|CLOSE|I/O} RETURN CODE IS return-code<br />
► 128 (Close): Index search horizontal chain pointer loop encountered.<br />
► 190 (Open): An incorrect high-allocated RBA was found in the catalog entry<br />
for this data set. The catalog entry is bad and will have to be restored.
► 76 (Open): Attention message: The interrupt recognition flag (IRF) was<br />
detected for a data set opened for input processing. This indicates that<br />
DELETE processing was interrupted.<br />
► 4 (I/O): End of data set encountered (during sequential retrieval), or the<br />
search argument is greater than the high key of the data set. Either no<br />
EODAD routine is provided, or one is provided and it returned to <strong>VSAM</strong> and<br />
the processing program issued another GET.<br />
► 32 (I/O): An RBA specified that does not give the address of any data record<br />
in the data set<br />
► 128 (I/O)): A loop exists in the index horizontal pointer chain during index<br />
search processing.<br />
► 144 (I/O): Incorrect pointer (no associated base record) in an alternate index.<br />
► 156 (I/O): An addressed GET UPD request failed because the control interval<br />
flag was on, or an incorrect control interval was detected during keyed<br />
processing. In the latter case, the control interval is incorrect for one of the<br />
following reasons:<br />
– A key is not greater than the previous key.<br />
– A key is not in the current control interval.<br />
– A spanned record RDF is present.<br />
– A free space pointer is incorrect.<br />
– The number of records does not match a group RDF record count.<br />
– A record definition field is incorrect.<br />
– An index CI format is incorrect (logical I/O error)<br />
What happened to cause this problem?<br />
KSDS or VRRDS <strong>VSAM</strong> data set organizations can “break” in more ways than<br />
other data sets, because they have an index component with logical pointers to<br />
other data and index CIs. If these pointers become corrupted, data can be lost or<br />
duplicated.<br />
Also, much structural information about such data sets is located in the ICF<br />
catalog. For example, two RBA fields in the VVR are very important in accessing<br />
a KSDS data set, for example:<br />
► If the RBA of the high-level index CI is corrupted, you are not be able to<br />
perform direct requests against the data set.<br />
► If the RBA of the sequence set index CI is corrupted, you are not able to<br />
perform sequential access.<br />
Refer to 3.8, “IDCAMS LISTCAT output fields” on page 187, for more information<br />
about RBA data in the VVDS catalog.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 151
152 <strong>VSAM</strong> <strong>Demystified</strong><br />
Then, if these fields are corrupted, errors may prevent you from accessing the<br />
data even though the data is intact. Also, it is possible that the index CI’s<br />
horizontal chain is destroyed, inhibiting the access to the data. One common way<br />
these fields can get corrupted is due to overlays of the AMDSB control block<br />
while the data set was open, which then get updated back to the VVDS at close<br />
time. Another way is through improper sharing of the data set during initial load<br />
mode processing.<br />
Because these fields are stored in the ″Statistics Block″ (AMDSB), jobs that only<br />
opened the data set for input still update this information at close time and for<br />
that reason do not dismiss any possibilities just because the job was not updating<br />
the file.<br />
SMF records are very helpful when diagnosing VVR damage. By investigating<br />
the SMF records (for example, type 60, 62 and 64) from all systems, improper<br />
access of the data set can be identified as well as the time frame of the<br />
corruption.<br />
What to do for recovery?<br />
When dealing with KSDS/VRRDS, it is crucial that EXAMINE is run on the data<br />
set as part of the diagnosis. Also, the sooner the EXAMINE is run after the data<br />
set is broken, the better, since some types of damage can actually cause more<br />
breakage until the data set is so badly broken it is impossible to tell what actually<br />
happened first. Remember that the EXAMINE command provides details about<br />
the nature of data set damage.<br />
Sometimes, the IDCAMS DIAGNOSE command can be used to check the data<br />
set for structural error in the catalog itself.<br />
When losing the index in a KSDS/VRRDS, one possible recovery path is to read<br />
the data (in physical sequential mode) via its data component. Here you may use<br />
an assembler program (MACRF=ADR in ACB and OPTCD=ADR in RPL), or by<br />
IDCAMS Repro. Then, classify by the key and use an IDCAMS Define and<br />
REPRO to recreate the KSDS. Refer to 3.4.4, “Broken Index scenario” on<br />
page 169 for more details.<br />
What to do to avoid future problems?<br />
Experience has shown that some of such errors are caused by improper sharing.<br />
If you are sharing your <strong>VSAM</strong> data set, refer to 3.2.7, “Improper sharing” on<br />
page 153.<br />
Because such types of errors maybe caused by system errors, you may want to<br />
investigate the possibility of APARs and PTFs related to the problem.
3.2.7 Improper sharing<br />
The following message may indicate improper sharing:<br />
► IDC3351I ** <strong>VSAM</strong> {OPEN|CLOSE|I/O} RETURN CODE IS return-code<br />
– 16 (I/O): Record not found.<br />
– 20 (I/O): Record already held in exclusive control by another requester.<br />
– 28 (I/O): Data set cannot be extended because <strong>VSAM</strong> cannot allocate<br />
additional DASD space.<br />
– 88 (Open): A previous extend error has occurred during EOV processing<br />
of the data set.<br />
– 96 (Open): Attention message: an unusable data set was opened for input.<br />
– 116 (Open): Attention message: the data set was not properly closed or<br />
was not opened. If the data set was not properly closed, then data may be<br />
lost if processing continues. The data set was not properly closed.<br />
– 236 (I/O): Validity check error for SHAREOPTIONS 3 or 4.<br />
► IDC11705I INDEX RECORD CONTAINS DUPLICATE INDEX POINTERS<br />
pointer-value<br />
What happened?<br />
Improper sharing is one of the most common causes of broken data sets. This<br />
section covers some of the things to check for, to make sure the share options<br />
are proper. Refer to “<strong>VSAM</strong> SHAREOPTIONS” on page 223, for information on<br />
share options. Here are some causes of sharing problems:<br />
► Sharing a data set across regions (cross-region) or across systems<br />
(cross-system) without using proper enqueuing procedures to protect data set<br />
integrity. For shareoptions shr(3 3) shr(4 3) shr(3 4) see related information in<br />
OY36328.<br />
► Sharing a data set across systems — even using the appropriated share<br />
option — but without propagating ENQ name SYS<strong>VSAM</strong> around the GRS<br />
ring. This is the *most* common user error. It results in duplicate index<br />
pointers in the high level index records. See message IDC11705I.<br />
► When a data set is defined using the model parameter, and the original data<br />
set has SPEED as an attribute of the index, data set damage can occur.<br />
<strong>VSAM</strong> does not support speed as an attribute for the index (speed is only<br />
supported for the data).<br />
► Another area related to broken data sets that is specific to CBUF processing<br />
is the VSI control block. Every time a data set is opened on a system for<br />
CBUF processing, a VSI is built for the data set and added to the VSI chain.<br />
This control block is then updated by the user to communicate information<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 153
154 <strong>VSAM</strong> <strong>Demystified</strong><br />
from one region to another. If the user does this improperly, a broken data set<br />
can result. Refer to 4.3.6, “Protecting <strong>VSAM</strong> data set through DISP<br />
parameter” on page 227, for more information.<br />
Documentation is of paramount importance to address sharing problems. The<br />
necessary documents should be obtained at each system (or address space)<br />
accessing the troubled data set. The major document needed here is the<br />
IDCAMS LISTC or CSI report. List the catalog entry for the affected data set to<br />
show the allocation and RBA data (beware OY61232).<br />
The SMF 62 and 64 records can help you determine if the users have the data<br />
set open for output from different applications at the same time. A common user<br />
error in this area is applications or ISV products that were not intended to be run<br />
from multiple systems (and so they have no logic to serialize updates), but the<br />
customer is using them in this manner.<br />
What to do for recovery?<br />
Here is a list of recovery options:<br />
Use the Access Method Services VERIFY command to attempt to close the data<br />
set properly. In a cross-system shared DASD environment, the ACBERFLG =<br />
116 may mean the data set was not properly closed. The warning "data set not<br />
properly closed" may indicate an error in a <strong>VSAM</strong> data set. It may mean one of<br />
the following:<br />
► The "end of the data set" indicators (data set high-used RBA/CI) and so on)<br />
may be invalid.<br />
► There may be missing records.<br />
► There may be duplicate records.<br />
► The data set statistics fields in the catalog may be invalid.<br />
If <strong>VSAM</strong> OPEN cannot successfully do a VERIFY then a user cannot do a<br />
VERIFY either.<br />
► Execute the IDCAMS EXAMINE command on the data set. Completion of<br />
EXAMINE without error proves that damage did not occur in a previous job. If<br />
the data set shows damage at this point, it must be restored before further<br />
use.<br />
► Proceed with the application job execution.<br />
► Execute IDCAMS EXAMINE on the data set when the job completes.<br />
► If damage to the cluster has occurred, run EXAMINE on SMF records from all<br />
systems which do have the ability to access the DASD volume. If shared<br />
access to the data set has occurred, correct or eliminate the contention for the<br />
data set.
What to do to avoid future problems?<br />
You should issue the VERIFY command every time you open a <strong>VSAM</strong> cluster<br />
that is shared across systems or address spaces. Read carefully 4.3, “Sharing<br />
<strong>VSAM</strong> data sets” on page 212 and use all the serializing techniques to avoid the<br />
structural damage and the data integrity of your data set.<br />
3.2.8 Mismatch between catalog and VTOC<br />
In this book we do not cover much catalog recovery; however, some of the<br />
catalog problems are mentioned as the ones associated with the IDC3009I<br />
message. Refer to 3.7, “IDC3009I message” on page 181, where a more detailed<br />
description of the return and reason codes from this message are presented.<br />
IDC3351I ** <strong>VSAM</strong> {OPEN|CLOSE|I/O} RETURN CODE IS return-code<br />
– 132 (Open): One of the following errors occurred:<br />
Unable to read JFCB or Scheduler Work Block<br />
Unable to connect to redo log during DFSMStvs open<br />
The forward recovery log associated with the data set was altered.<br />
DFSMStvs failed to write a record to the forward recovery log.<br />
Caller TASK cancelled<br />
The data set is in a forward recovery required state.<br />
► IDC3009I <strong>VSAM</strong> CATALOG RETURN CODE IS return-code — REASON CODE IS<br />
IGGOCLaa — reason-code<br />
3.2.9 <strong>VSAM</strong> does not produce expected output<br />
Incorrect output failures can be identified by the following results:<br />
► Expected output is missing.<br />
► Output is different than expected.<br />
► Output should not have been generated.<br />
► System indicates damage to the VTOC or VTOC index.<br />
► ISMF panel information or flow is erroneous.<br />
Incorrect output can be the result of a previous failure and can often be difficult to<br />
analyze because the component affected might not be the one that caused the<br />
problem. Review previous messages, abends, console logs, or other system<br />
responses. They could indicate the source of the failure.<br />
Accumulating as much information as possible<br />
It can help you isolate or resolve your problem, and the IBM Support Center will<br />
request it if trap or trace information is needed, such as the following.<br />
► When was the problem first noticed?<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 155
156 <strong>VSAM</strong> <strong>Demystified</strong><br />
► How was the problem identified (good output versus bad output)?<br />
► Were any system changes or maintenance recently applied? For example, a<br />
new device, software product, APAR, or PTF?<br />
► Does the problem occur with a specific data set, device, time of day, and so<br />
forth?<br />
► Does the problem occur in batch or TSO mode?<br />
► Is the problem solid or intermittent?<br />
► Can the problem be re-created?<br />
► EXAMINE the system and console logs for failure-related abends, messages,<br />
or return codes. A damaged <strong>VSAM</strong> data set can also cause incorrect output.<br />
► Add any failure-related return codes to the keyword string, exactly as the<br />
system presents them. You can also add the abend or message<br />
type-of-failure keywords to the incorrect output keyword string to define the<br />
symptoms more closely:<br />
► Determine whether failure-related record management return codes and<br />
reason codes exist.<br />
<strong>VSAM</strong> provides return codes in register 15 and reason codes in either the<br />
access method control block (ACB) or the request parameter list (RPL).<br />
Reason codes in the ACB indicate <strong>VSAM</strong> open or close errors. Reason codes<br />
in the RPL indicate <strong>VSAM</strong> record management error indications returned to<br />
the caller of record management. Reason codes returned to the caller of<br />
record management in the RPL indicate <strong>VSAM</strong> record management errors.<br />
► Determine whether you have a damaged <strong>VSAM</strong> data set.<br />
Some incorrect output failures involve a damaged <strong>VSAM</strong> data set. To<br />
determine whether you have a damaged data set, use the IDCAMS<br />
EXAMINE command as described in the chapter on functional command<br />
format in DFSMS/MVS Access Method Services for ICF and the chapter on<br />
checking a <strong>VSAM</strong> key-sequenced data set cluster for structural errors in<br />
DFSMS/MVS Using Data Sets. The EXAMINE command provides details<br />
about the nature of data set damage. If these service aids indicate that the<br />
data set is not damaged, inform the IBM Support Center if you call for<br />
assistance. If they indicate that the data set is damaged, keep a copy of the<br />
output for possible use by the IBM Support Center. Be prepared to describe<br />
the type of data set damage. You should attempt to recover the data set and<br />
rerun the failing job to determine whether the problem is resolved.<br />
3.2.10 <strong>VSAM</strong> RLS problems<br />
This is described in 5.5, “RLS problem determination and recovery” on page 266
3.2.11 <strong>VSAM</strong> and DFSMStvs considerations<br />
3.2.12 OEM problems<br />
Refer to Chapter 6, “DFSMStvs” on page 323.<br />
Overlay of control blocks, abends, loops, deadlocks and performance problems<br />
can occur due to errors in the use of <strong>VSAM</strong> data sets. A large number of<br />
problems have been reported by many IBM products and non-IBM products that<br />
use <strong>VSAM</strong> data sets. These problems are described in a number of information<br />
APARs in IBMLINK. At the time of writing this book, 270 problems have been<br />
documented in these APARs as follows.<br />
► II10001 - Problems 1-60<br />
► II11013 - Problems 61-104<br />
► II11513 - Problems 105-157<br />
► II12140 - Problems 158-200<br />
► II12615 - Problems 201-238<br />
► II13278 - Problems 239-270<br />
3.2.13 Enqueue issues<br />
OPEN message IEC161I 052-084 is a common informational message. Most<br />
often it simply means that another job already has the dataset open when this job<br />
is trying to open it. As it usually indicates a scheduling problem rather than a<br />
system problem. In this section we provide information on how to determine what<br />
jobs are in contention for the same dataset.<br />
<strong>VSAM</strong> OPEN processing determines this condition by checking the GRS data.<br />
Depending on the shareoptions (SHR) of the dataset, and the attributes of the<br />
OPEN, <strong>VSAM</strong> will enqueue against major name SYS<strong>VSAM</strong> with a minor name of<br />
the dataset name/catalog name plus other information. Thus, GRS is the<br />
mechanism OPEN processing uses to insure serialization of the OPEN process<br />
itself as well as the shareoptions of the file.<br />
When <strong>VSAM</strong> issues an ENQUEUE for a SYS<strong>VSAM</strong> resource, <strong>VSAM</strong> will add an<br />
ENQRNIND indicator to the wanted resource name:<br />
► ENQRNIND = B = BUSY<br />
► ENQRNIND = I = INPUT<br />
► ENQRNIND = N = Non RLS Open<br />
► ENQRNIND = O = OUTPUT<br />
► ENQRNIND = R = RESERVE<br />
► ENQRNIND = S = Sphere<br />
► ENQRNIND = C = CLOSE<br />
► ENQRNIND = R = RLS Read<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 157
158 <strong>VSAM</strong> <strong>Demystified</strong><br />
► ENQRNIND = W = RLS Write<br />
The ENQ for BUSY will be held throughout the period of the initial operation<br />
being performed, that is, OPEN, EOV, CLOSE, TCLOSE or CHECKPOINT<br />
RESTART. When the operation is complete or is failed, then, the 'B' resource will<br />
be dequeued. Example:<br />
► ENQ DATASET/CAT/B (OPEN) EXCLUSIVE<br />
► ENQ DATASET/CAT/O<br />
► DEQ DATASET/CAT/B (process data)<br />
► ENQ DATASET/CAT/B (CLOSE) EXCLUSIVE<br />
► DEQ DATASET/CAT/O<br />
► DEQ DATASET/CAT/B<br />
The first place to look to determine which job is enqueued on the dataset is GRS<br />
data. You can view this data with the DISPLAY GRS command or through a<br />
monitor program. Look at both the global and local queues under the major name<br />
of SYS<strong>VSAM</strong> for the dataset that is getting the OPEN failure. Unfortunately, the<br />
GRS data is transient and may well change before you can find the job that was<br />
responsible for the message, but, do try the GRS command. Issue this GRS<br />
command from all systems that can share the DASD:<br />
D GRS,RES=(SYS<strong>VSAM</strong>,*)<br />
Note: If you are using IPCS to view GRSDATA remember that SYS<strong>VSAM</strong> will<br />
be there twice, once for Local System Resources and a second time for<br />
Global Systems Resources.<br />
The next place to look is the console log. You may be able to determine if there<br />
were any backups/copies/dumps being taken at the time or even if there were<br />
unexpected batch jobs running at the time.<br />
Another place to look for information is the SMF type 62 (SMF62) and SMF64<br />
records. This will show what jobs were accessing the dataset at the time of the<br />
error. This also may not be conclusive since some access of the dataset will not<br />
produce SMF records (that is, Media Manager, DB2, DFSMS/dss).<br />
Ensure the availability of the resource by means of JCL DD statements. This<br />
means, check your JCL and ensure that you have requested the proper<br />
disposition, that is, DISP=SHR.<br />
Use the AMS command ALTER, to reset the Update Inhibit indicator in the data<br />
set's catalog record then, rerun the job. This means, run LISTC against the failed<br />
cluster, check for an attribute of INH-UPDATE. If found ON, then this dataset is in<br />
READONLY mode and will fail an OPEN for UPDATE request. Use the AMS<br />
command 'ALTER UNINHIBIT' to place the file in READ/WRITE mode, then,
erun the job. Example 3-1 shows a sample job for Cluster DFP1.JIMONE.KSDS<br />
(on a D/T3390 with volser=339000).<br />
Example 3-1 Sample AMS JCL<br />
//SYSIN DD *<br />
PRINT INDATASET(SYS1.VVDS.V339000) DUMP<br />
ALTER DFP1.JIMONE.KSDS.DATA UNINHIBIT<br />
ALTER DFP1.JIMONE.KSDS.INDEX UNINHIBIT<br />
VERIFY DATASET(DFP1.JIMONE.KSDS)<br />
LISTC ENT(DFP1.JIMONE.KSDS) ALL<br />
/*<br />
In a <strong>VSAM</strong> catalog, INHIBIT UPDATE bit is in the BCS DINC record. In an ICF<br />
catalog, INHIBIT UPDATE bit is in the VVDS VVR record.<br />
If you are NOT able to determine what job is the cause of the IEC161I message,<br />
open a problem record with the Support Center and include your RMID of<br />
IDA0192B. You will be given a SLIP to capture a dump (which includes the<br />
GRSQ data) at the time the message is issued.<br />
The SLIP will be set in CSECT IDA0192B of load module IDA0192A upon entry<br />
to a procedure named, PROBDT2B. IBM will need to know the PTF level of<br />
IDA0192B in order to resolve the offset of xxx in the SLIP. The user will need an<br />
AMBLIST of IDA0192A. A sample of the slip is shown in Example 3-2.<br />
Example 3-2 SLIP to determine the job causing IEC16I<br />
SLIP SET,IF,A=SYNCSVCD,L=(IDA0192A,xxx),DATA=(13R?+F8,EQ,34),<br />
SDATA=(ALLNUC,CSA,GRSQ,LPA,LSQA,RGN,SQA,SUM,TRT),END<br />
IDA0192B is an offset into load module IDA0192A and PROBDT2B is an offset<br />
into IDA0192B. xxx is the sum of these 2 offsets. The value of xxx and values<br />
specified in the SLIP DATA parms may change with different releases and<br />
maintenance levels of CSECT IDA0192B. Be sure to check with IBM Support<br />
Personnel to ensure an accurate SLIP for your level.<br />
3.2.14 Migration issues<br />
Please refer to the relevant migration manuals to be aware of changes you need<br />
to make when you migrate to a new release of z/OS.<br />
Enhancements to calculation of default CISIZE is an example. This is described<br />
in 4.2, “New Index CI size calculation algorithm” on page 208.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 159
3.2.15 Performance considerations<br />
3.2.16 Deadlocks<br />
160 <strong>VSAM</strong> <strong>Demystified</strong><br />
In a sense a performance problem may appear as a lack of availability. Refer to<br />
Chapter 2, “Performance” on page 43, to see several aspects of <strong>VSAM</strong><br />
performance and specifically to 2.9, “Performance monitors” on page 136, to<br />
learn about performance monitors.<br />
Deadlocks are a performance and also a problem determination subject.<br />
Here we cover define a deadlock, how to prevent them, how to detect a deadlock<br />
and what to do when we have one.<br />
What is a deadlock?<br />
Locks are used in <strong>VSAM</strong> by the DFSMS lock manager when the same control<br />
block structures are shared by strings in task programs. In such a case, Share<br />
Options do not apply. Refer to “Sharing data in a single <strong>VSAM</strong> control block<br />
structure” on page 218. If the <strong>VSAM</strong> data set is processed in non-RLS mode<br />
there is one lock per CI, when in RLS there is a lock per each logical record.<br />
Then, contention for <strong>VSAM</strong> CIs locks (or logical records locks) can lead to<br />
deadlocks, as such: A delays B in one lock and B delays A in other lock.<br />
How to prevent a deadlock<br />
The major rule is try to avoid to lock more than one logical records concurrently.<br />
Also a key recommendation is to avoid consistent reads (CR). If the RLS<br />
exploiter cannot follow such rules, it could create a hierarchy of locks. Then,<br />
when more than one lock is required concurrently, they need to be required in a<br />
pre-determined sequence.<br />
How to detect a deadlock<br />
The DFSMS lock manager provides a deadlock detection routine, the frequency<br />
with which it runs is determined by the installation. This routine considers a string<br />
task program in a deadlock situation, if it is waiting for a lock for more than an<br />
installation specified amount of time. There are two deadlock detection routines:<br />
► Deadlocks within a system<br />
► Deadlocks between systems<br />
The frequencies of the deadlock detection routines are specified in GDSMSxx<br />
parameter of Sys1.Parmlib.<br />
In a Sysplex, the first system that is initialized with an IGDSMSxx member having<br />
a valid DEADLOCK_DETECTION specification determines this keyword for the
other systems in the Sysplex. You can change this value through the SETSMS or<br />
SET SMS commands.<br />
This keyword specifies the intervals for running local and global deadlock<br />
detection routine.<br />
The first subparameter nnnn is the local deadlock detection cycle and specifies<br />
the interval in seconds for detecting deadlocks within a system.<br />
The second subparameter is the global deadlock detection cycle and specifies<br />
the interval for detecting deadlocks between systems. This value is specified as<br />
the number of local detection cycles that occur before global deadlock detection<br />
is initiated.<br />
To determine if a string task program is in a dead lock situation DFSMS lock<br />
manager compares the RLSTMOUT keyword with the amount of time a string<br />
task program is waiting for a lock.<br />
RLSTMOUT({nnnn|0})<br />
Specifies the maximum time, in seconds, that a <strong>VSAM</strong> RLS request must wait<br />
for a required lock before the request is assumed to be in deadlock.<br />
You can specify a value between 0 to 9999 (in seconds). A value of 0 means<br />
that the <strong>VSAM</strong> RLS request has no time out value and the request waits for as<br />
long as necessary to obtain the required lock.<br />
RLSTMOUT can be specified only once in a sysplex and applies across all<br />
systems in the sysplex.<br />
What to do when a deadlock is detected<br />
When a lock request is found in a deadlock, <strong>VSAM</strong> rejects the request in wait.<br />
This results in the <strong>VSAM</strong> request completing with a deadlock error response.<br />
Your applications must be prepared to accept locking error return codes that may<br />
be returned on GET or POINT NRI requests. However, normally such errors do<br />
not occur.<br />
3.2.17 Beware of some <strong>VSAM</strong> restrictions<br />
Keep this important restriction in mind when using the REPRO command.<br />
REPRO to empty <strong>VSAM</strong> data set<br />
If you try to repro into an empty <strong>VSAM</strong> data set, you will get an error IDC3351I **<br />
<strong>VSAM</strong> OPEN RETURN CODE =160. This is a permanent restriction of <strong>VSAM</strong>.<br />
One work-around is to "prime" the dataset by adding and deleting one record.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 161
162 <strong>VSAM</strong> <strong>Demystified</strong><br />
This will increment the HI-U-RBA to a value other than zero, and allow the<br />
REPRO to proceed.<br />
3.3 What documentation to collect<br />
First familiarize yourself with getting the required documentation, such as logs,<br />
dumps, traces, and messages associated with errors. There is an information<br />
APAR II12927 in IBMLINK that tells you what information you need to collect for<br />
general <strong>VSAM</strong> problems.<br />
Note: It is generally a good idea to include an AMBLIST of the <strong>VSAM</strong> load<br />
modules IDA019L1 and IDA0192A when sending a <strong>VSAM</strong> problem to IBM<br />
level2 support.<br />
3.3.1 Catalog performance problems<br />
Here is the information to collect and questions to consider.<br />
► Provide a clear and adequate description<br />
► What is not performing properly?<br />
► What is the basis for the performance expectation?<br />
► What changes appear to trigger the performance change?<br />
► Maintenance, release, application?<br />
► Dump of CAS (and associated user ASIDs)<br />
► Recovery actions (if Catalog is involved)<br />
► Performance report<br />
► Comparison report (what was performing in the last release?)<br />
For details see information APAR II10752.<br />
3.3.2 <strong>VSAM</strong> RLS problems<br />
You would need to collect dumps of SMS<strong>VSAM</strong> and other address spaces<br />
depending on the problem. You may require the following documentation:<br />
► A dump of SMS<strong>VSAM</strong> ASIDs on all systems at the same time. See<br />
Example 3-3.<br />
► A dump SMS<strong>VSAM</strong> and XCF on all the systems in the sysplex See<br />
Example 3-4.<br />
► A dump of the SMS<strong>VSAM</strong> ASID, SMS<strong>VSAM</strong> data spaces and CICS regions<br />
involved. See Example 3-5.
Example 3-3 Dump SMS<strong>VSAM</strong> ASIDs on all systems<br />
DUMP COMM=(Some meaningful dump title),<br />
R nn,JOBNAME=(SMS<strong>VSAM</strong>),CONT<br />
R nn,SDATA=(GRSQ,RGN,ALLNUC,LPA,LSQA,CSA,PSA,SQA,SUM,SWA,TRT),<br />
R nn,DSPNAME=('SMS<strong>VSAM</strong>',*),<br />
R nn,REMOTE=(SYSLIST=*('SMS<strong>VSAM</strong>'),DSPNAME,SDATA),END<br />
Example 3-4 Dump SMS<strong>VSAM</strong> and XCF on all systems<br />
DUMP COMM=(SMS<strong>VSAM</strong> and XCF)<br />
R XX,JOBNAME=(SMS<strong>VSAM</strong>,XCFAS),DSPNAME=('XCFAS'.*,'SMS<strong>VSAM</strong>'.*),CONT<br />
R YY,SDATA=(GRSQ,RGN,ALLNUC,LPA,LSQA,CSA,PSA,SQA,SUM,SWA,TRT), CONT<br />
R ZZ,REMOTE=(SYSLIST=(*,('XCFAS','SMS<strong>VSAM</strong>',DSPNAME,SDATA)))<br />
Example 3-5 Dump of SMS<strong>VSAM</strong> and CICS<br />
DUMP COMM=(CICS & SMS<strong>VSAM</strong> HANG)<br />
R nn,JOBNAME=(SMS<strong>VSAM</strong>, CICS1, CICS2, CICS3, ETC),<br />
R nn,DSPNAME=('SMS<strong>VSAM</strong>'.*),<br />
R nn,SDATA=(PSA,NUC,SQA,LSQA,SUM,RGN,GRSQ,LPA,TRT,CSA),CONT<br />
R nn,REMOTE=(SYSLIST=*('SMS<strong>VSAM</strong>'),DSPNAME,SDATA),END<br />
where CICS1, CICS2, CICS3, ETC are the names of the CICS regions.<br />
3.3.3 IDCAMS problems<br />
The following are documentation requirements for IDCAMS problems:<br />
► Syslog (including all messages, JCL and commands)<br />
► VERIFY output<br />
► LISTCAT ALL output<br />
► EXAMINE (ITEST and DTEST)<br />
► DIAGNOSE<br />
3.3.4 Broken <strong>VSAM</strong> data set<br />
You will need to collect the following documentation:<br />
► SYSLOG/JOBLOG (including all messages, JCL and commands)<br />
► EXAMINE (both ITEST and DTEST) output<br />
► LISTCAT ALL output<br />
► DIAGNOSE output<br />
Please see information APAR II08859 for more details.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 163
3.3.5 Broken catalog<br />
164 <strong>VSAM</strong> <strong>Demystified</strong><br />
Collect the following documentation for this error condition:<br />
► LISTCAT ENT(catname)ALL CATALOG(catname)<br />
► DIAGNOSE vvds<br />
► DIAGNOSE bcs<br />
► DIAGNOSE COMPARE vvds to bcs<br />
► DIAGNOSE COMPARE bcs to vvds<br />
► EXAMINE (both ITEST and DTEST)<br />
► Any error messages from joblog<br />
3.3.6 How to obtain <strong>VSAM</strong> record management trace?<br />
Sometimes you may need to collect <strong>VSAM</strong> record management traces. This<br />
section describes how to collect <strong>VSAM</strong> record management traces.<br />
1. GTF must be activated before you allocate the data set that is being traced.<br />
Start GTF with TRACE=USRP,USR=FF5, END<br />
2. The SYS1.TRACE data set should be approximately 100 cylinders, or larger if<br />
the space is available. If, however, the activity on this file will be quite heavy<br />
there is a possibility of "lost trace entries." This means that the amount of<br />
trace records coming in is more than GTF can keep up with. Splitting the<br />
SYS1.TRACE data set into multiple data sets usually prevents this. See the<br />
informational APAR II10072 for further information. An example has also been<br />
provided following #5 (below).<br />
3. Place an AMP=('TRACE=(subparameters)') on the DD statement of the data<br />
set that you want to trace. <strong>VSAM</strong> Level 2 will provide you with the coding of<br />
the AMP parameter.<br />
Note: If the data set being traced is dynamically allocated a usermode must<br />
be provided from L2 and applied to your system. For example:<br />
//ddname DD ...,<br />
// AMP=('TRACE=(PARM1=64C4A1802000,HOOK=(0,1,3,9,10,11,25,26))')<br />
4. Restart applicable CICS region(s), run batch jobs, and so on. It is important<br />
that GTF be started BEFORE any data set allocation occurs, otherwise, the<br />
control blocks for tracing will not be built and no tracing will occur.<br />
5. Recreate the problem.<br />
6. Stop trace as soon as job terminates.An example of JCL that can be used to<br />
send the GTF output to more than one data set is shown in Example 3-6. This<br />
is often necessary on high output traces:
Example 3-6 Sampler JCL for GTF trace<br />
//GTFABC PROC MEMBER=GTFPARM<br />
//IEFPROC EXEC PGM=AHLGTF,REGION=2880K,TIME=1440,<br />
// PARM=('MODE=EXT,DEBUG=NO,TIME=NO')<br />
//IEFRDER DD DSNAME=SYS1.GTFTRC,UNIT=SYSDA,<br />
// SPACE=(4096,20),DISP=(NEW,KEEP)<br />
//SYSLIB DD DSN=SYS1.PARMLIB(&MEMBER),DISP=SHR<br />
//GTFOUT1 DD DSNAME=SYS1.TRACE1,UNIT=SYSDA,DISP=(NEW,KEEP)<br />
//GTFOUT2 DD DSNAME=SYS1.TRACE2,UNIT=SYSDA,DISP=(NEW,KEEP)<br />
//GTFOUT3 DD DSNAME=SYS1.TRACE3,UNIT=SYSDA,DISP=(NEW,KEEP)<br />
GTF would be started with: S GTFABC.<br />
SYS1.PARMLIB(GTFPARM) would be the parmlib member that contains the<br />
trace parms to be used, TRACE=USRP,USR=(FF5),END.<br />
3.4 How to recover a damaged <strong>VSAM</strong> data set<br />
IDCAMS has three important commands used to recover <strong>VSAM</strong> clusters and<br />
catalogs. They are: EXAMINE, DIAGNOSE, and VERIFY.<br />
3.4.1 EXAMINE command<br />
EXAMINE is an IDCAMS command that allows the user to analyze and collect<br />
information on the structural consistency of KSDS data set clusters and of a<br />
VVRDS data set cluster. In addition, EXAMINE can analyze and report on the<br />
structural integrity of the basic catalog structure (BCS) of an ICF catalog. This<br />
function cannot share a cluster opened for output or update by other task.<br />
The EXAMINE function executes two possible tests:<br />
► Test the Index portion (INDEXTEST), the default<br />
Evaluates the full index component of the KSDS/VRRDS cluster by<br />
cross-checking vertical and horizontal pointers contained within the index<br />
control intervals, and by performing analysis of the index information. Usually<br />
is a medium to small resource consuming task.<br />
► Test the Data portion (DATATEST)<br />
Evaluates the index sequence set and data component of the key-sequenced<br />
data set cluster by sequentially reading all data control intervals, including<br />
free space control intervals. Tests are then carried out to ensure record and<br />
control interval integrity, free space conditions, spanned record update<br />
capacity, and the integrity of various internal <strong>VSAM</strong> pointers contained within<br />
the control interval. Usually this is a long resource consuming task.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 165
166 <strong>VSAM</strong> <strong>Demystified</strong><br />
You can also limit the number of error messages generated (ERRORLIMIT) by<br />
EXAMINE. Refer to “Broken data set” on page 179 for information about what to<br />
do whether EXAMINE is reporting errors in the Index or Data portion. Refer also<br />
to “IDCAMS EXAMINE messages” on page 420.<br />
3.4.2 DIAGNOSE command<br />
To analyze a catalog for synchronization errors, you can use the IDCAMS<br />
DIAGNOSE command. With this command, you can analyze the content of<br />
catalog records in the BCS and VVDS, and compare VVDS information with<br />
DSCB information in the VTOC. Besides checking for synchronization errors,<br />
DIAGNOSE also checks for invalid data, or invalid relationships between entries.<br />
Because the DIAGNOSE command checks the content of the catalog records,<br />
and the records might, for example, contain damaged length field values, there is<br />
a possibility that the DIAGNOSE job will abend. For detailed information on using<br />
DIAGNOSE, see DFSMS/MVS Managing Catalogs, SC26-4914.<br />
3.4.3 VERIFY command<br />
Some clarification of the word VERIFY is necessary in many cases. VERIFY is a<br />
record management macro (just like GET or PUT). It can be used with certain<br />
types of opened <strong>VSAM</strong> data sets to ensure that various fields in the <strong>VSAM</strong><br />
control blocks in catalog are accurate. It checks the ICF catalog against the<br />
<strong>VSAM</strong> clusters.<br />
What record management does on receiving this macro is to start reading the<br />
data set CI by CI starting with the current high used RBA value stored in a<br />
memory control block. If the data set is a KSDS, then both the index and the data<br />
are VERIFYed.<br />
VERIFY is also an IDCAMS command. In this case, IDCAMS opens the<br />
requested data set for output, issue the record management VERIFY macro and<br />
then close the data set. When the data set is closed, <strong>VSAM</strong> Close processing<br />
uses its catalog interface to call Catalog to update the VVR information from the<br />
new information in the <strong>VSAM</strong> control blocks. It is important to understand that<br />
IDCAMS is neither updating <strong>VSAM</strong> control blocks nor the catalog directly.<br />
Clusters, alternate indexes, entry-sequenced data sets, and catalogs can be<br />
verified. Paths over an alternate index and linear data sets cannot be verified,<br />
and the same is true of data sets in RLS mode. Paths defined directly over a<br />
base cluster can be verified.
When a data set is closed, its end-of-data and end-of-key-range information is<br />
used to update the data sets cataloged information (located in the VVR AMDSB<br />
cell). Among other fields, we have:<br />
► High used RBA/CI for the data set<br />
► High key RBA/CI<br />
► Number of index levels<br />
► RBA and the CI number of the first sequence set record<br />
► System time stamp<br />
Refer to 3.8, “IDCAMS LISTCAT output fields” on page 187, for more information.<br />
A successful VERIFY means:<br />
► The "end of the data set" indicators (data set high-used RBA/CI) etc.) are<br />
probably valid.<br />
► There may be missing records.<br />
► There may be duplicate records.<br />
► The data set statistics fields in the catalog may be invalid.<br />
The recovery actions should be the same for a <strong>VSAM</strong> data set not properly<br />
closed, whether VERIFY runs successfully or not.<br />
Implicit VERIFY versus explicit VERIFY<br />
Another area that is confusing when talking about VERIFY involves the terms<br />
“explicit VERIFY” and “implicit VERIFY”. An explicit VERIFY refers to the user<br />
initiating the VERIFY himself by issuing an IDCAMS VERIFY job against the data<br />
set. An implicit VERIFY refers to <strong>VSAM</strong> Open processing internally issuing the<br />
VERIFY macro against the data set when it determines that the data set was not<br />
previously closed properly; this means that a previous job which had the data set<br />
open for output has either abended or failed to close the data set for some<br />
reason.<br />
Open processing uses a bit in the catalog to determine this. When a job opens a<br />
data set for output processing, this bit (the “open for output” bit) is turned on. It is<br />
not turned off until the job closes the data set normally. Open processing, if it<br />
finds this bit on in a subsequent open, uses GRS (enqueueing against the data<br />
set name) to determine if the data set is currently open for output. If not, then it<br />
concludes that the last close was abnormal and issues the VERIFY before<br />
completing the Open process. It also issues IEC161I messages (rc56 and rc62)<br />
to indicate that it has done this. All Open jobs against the data set will get this<br />
implicit VERIFY and the associated messages until the data set is opened for<br />
Output.<br />
<strong>VSAM</strong> OPEN will NOT do an "implicit verify" for the following OPENs:<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 167
168 <strong>VSAM</strong> <strong>Demystified</strong><br />
► The data set is being opened for input<br />
► The data set is being opened for RESET processing<br />
► The user requested verify to be suppressed<br />
► The data set is being opened for Improved control interval processing<br />
► The data set is being opened for RESTART processing<br />
► The data set is being opened for non-ESDS create mode processing<br />
► The data set is a Linear data set<br />
<strong>VSAM</strong> OPEN will do an "implicit verify" or without issuing a message when the<br />
ACB being opened is the first open for output connecting to an existing control<br />
block structure and shareoptions=2,x.<br />
Implicit VERIFY problems<br />
Here we discuss a couple of problems with the implicit VERIFY that are not<br />
inherently obvious.<br />
Normally, a VERIFY does not take much overhead because it is reading in CI<br />
mode from the HURBA in the catalog to the “real” HURBA. However, if the data<br />
set had much activity in the output job before it abended (for example, a log file<br />
that was being loaded), then the VERIFY could take many minutes, as it basically<br />
reads the entire file. This could also be a severe impact if there were many files<br />
open in the application.<br />
CICS provides a good example of this problem. If the CICS region comes down<br />
hard (for example, if a CEMT P SHUT IMM is issued), then all TCBs are<br />
abended, and all files open for output at the time will have the “open for output”<br />
bit on in the VVR. This will means they will all need to be implicitly VERIFY'd as<br />
the region is brought back up. If this is the case, you need to have a procedure in<br />
place to explicitly VERIFY the important files in the case of an abend situation so<br />
that the system can come up and the important applications can start running<br />
immediately.<br />
ACTION=REFRESH<br />
One addition which was made to <strong>VSAM</strong> quite some time ago was the<br />
ACTION=REFRESH parameter of the VERIFY macro. Without this parameter,<br />
the VERIFY macro will only read up to the current HARBA of the data set (as set<br />
in <strong>VSAM</strong> control block). Since this value could have changed since the last time<br />
the data set was opened by the current job, this facility allows the control blocks<br />
for a data set to be updated to reflect the current structure of the data or index<br />
(from the values in the catalog/VVR). To accomplish this, record management<br />
through EOV uses catalog interface to update the in storage control blocks with<br />
the current boundaries of the data set.
Use the cluster or alternate index name as the target of your VERIFY command.<br />
Although the data and index components of a key-sequenced cluster or alternate<br />
index can be verified, the timestamps of the two components are different<br />
following the separate Verifies, possibly causing further OPEN errors.<br />
The following sections provide some real life scenarios covering the rise and fall<br />
of a <strong>VSAM</strong> data set.<br />
3.4.4 Broken Index scenario<br />
In this scenario, you observe the following conditions:<br />
► You have a program which opens a KSDS data set for update. The access<br />
argument is through RBA. However, by mistake, someone has prepared JCL<br />
pointing to the index name instead of cluster name or data name.<br />
► The program finishes with a return code equal to zero, but with an unknown<br />
damaged index. However, the index time stamp is now different from the one<br />
in the data component, as LISTCAT shows. Nevertheless, RACF does not<br />
prohibit this action, because the user is the owner of the cluster. See<br />
Figure 3-1.<br />
//*JCL -------------------------------------<br />
//SEQ EXEC PGM=TSTIDX<br />
//<strong>VSAM</strong> DD DSN=KSDS.K4REP.INDEX,DISP=SHR<br />
TSTIDX PROGRAM:<br />
ACB,DDNAME=<strong>VSAM</strong>,MACRF=(ADR,SEQ,OUT)<br />
RPL,ACB=(R2),OPTCD=(ADR,SEQ,UPD,MVE)<br />
SYSOUT MESSAGE:<br />
JOBNAME STEPNAME PROCSTEP RC<br />
TSTIDX SEQ 00<br />
LISTCAT ENTRY(‘KSDS.K4REP’) ALL:<br />
DATA: SYSTEM-TIMESTAMP: X'B3E245958A0845C4'<br />
INDEX: SYSTEM-TIMESTAMP: X'B3E278BEC0D91601'<br />
Figure 3-1 JCL, program, message and catalog entry<br />
► The next time that you open the cluster or the data, the following happens:<br />
– At open, the message IEC161I 058(018)-061 is issued and the OPEN<br />
return code is 4. The processing continues. See the message at<br />
Figure 3-2.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 169
170 <strong>VSAM</strong> <strong>Demystified</strong><br />
IEC161I 058(018)-061:<br />
058 The time stamp for the index does not match the time stamp for<br />
the data set. This could occur if the data set was updated<br />
without the index being open.<br />
to 108.<br />
System Action: OPEN processing continues. The error flags<br />
in the ACB (access method control block) for the data set are set<br />
Programmer Response: You can continue to process the data<br />
set, but errors can occur if the data set and index do not<br />
correspond. Check for possible duplicate VVRs.<br />
Figure 3-2 IEC161I message<br />
– Going on with the processing, in a GET or PUT, the program receives a<br />
return code 8, reason code X’9C’, indicating that an invalid control interval<br />
was detected. The program reading the data issues a message indicating<br />
the error. When the program is IDCAMS, the processing stops and the<br />
messages below (Figure 3-3) are issued in the SYSPRINT ddname file. If<br />
the data set is open for output, the timestamp is corrected, but the I/O error<br />
remains, once the index is damaged.<br />
IDC3300I ERROR OPENING KSDS.K4REP<br />
IDC3351I ** <strong>VSAM</strong> OPEN RETURN CODE IS 108<br />
IDC3302I ACTION ERROR ON KSDS.K4REP<br />
IDC3351I ** <strong>VSAM</strong> I/O RETURN CODE IS 156 - RPLFDBWD = X'D708009C'<br />
IDC31467I MAXIMUM ERROR LIMIT REACHED.<br />
Figure 3-3 IDC message in the console<br />
► You run an EXAMINE IDCAMS command, getting back the messages shown.<br />
In our test, we caused the error by filling the first control interval with X‘00’:<br />
See Figure 3-4.<br />
► For recovering the index:<br />
– Use the REPRO Command to copy just the data component of the KSDS<br />
to a sequential data set. Specify the data component name (not the<br />
Cluster Name) in the REPRO INFILE parameter.<br />
– Sort the sequential data set by key.<br />
– DELETE and reDEFINE the damaged Cluster.<br />
– REPRO from the Sorted Sequential File to the newly defined Cluster.<br />
Record Management will rebuild the Index Component.
Note: This method does not work for a <strong>VSAM</strong> Catalog, Integrated Catalog (ICF),<br />
or for a Spanned KSDS.<br />
INDEXTEST BEGINS<br />
HIGH-LEVEL INDEX CI EXPECTED BUT NOT ACQUIRED<br />
CURRENT INDEX LEVEL IS 3<br />
INDEX CONTROL INTERVAL DISPLAY AT RBA/CI 245760 FOLLOWS<br />
000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br />
000000<br />
00 *................................*<br />
000020 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br />
000000<br />
...<br />
ERROR LOCATED AT OFFSET 00000010<br />
MAJOR ERRORS FOUND BY INDEXTEST<br />
LASTCC=8<br />
Figure 3-4 Examine messages<br />
3.4.5 Abend task scenario<br />
At task abend, RTM does not properly close the <strong>VSAM</strong> data set, then:<br />
► Buffers are not flushed (with the exception of cross systems shareoptions 4)<br />
and the HURBA is not updated in the catalog. In Language Environment there<br />
is an option (TRAP ON) which forces the close (with flush and HURBA<br />
actualization), using a STAE exit.<br />
If the HURBA was not updated, when the data set is subsequently opened<br />
and the user's program attempts to process records beyond end-of-data or<br />
end-of-key range, a read operation results in a “no record found” error, and a<br />
write operation might write records over previously written records. To avoid<br />
this, you can use the VERIFY command, which corrects the catalog<br />
information. For additional information about recovering a data set, see<br />
DFSMS/MVS Managing Catalogs, SC26-4914-04.<br />
► If the data set was opened for output, the open-for-output indicator is left on.<br />
In this case, at next Open, <strong>VSAM</strong> implicitly issues a VERIFY command, when<br />
it detects an open-for-output indicator on and issues an informational<br />
message stating whether the VERIFY command is successful. However, a<br />
successful VERIFY does not mean that the data set is error free.<br />
If a subsequent Open is issued for update, <strong>VSAM</strong> turns off the<br />
open-for-output indicator at successful Close. If the data set is opened for<br />
input, however, the open-for-output indicator is left on. Refer to 3.2.3,<br />
“Mismatch between catalog and data set” on page 145, for more information.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 171
3.4.6 Recovering damaged BCS entries<br />
172 <strong>VSAM</strong> <strong>Demystified</strong><br />
To recover damaged BCS entries, follow these steps:<br />
1. Remove the sphere or base record, if it exists.<br />
The damage detected might not be in a sphere or base record. If it is not, the<br />
entry name of the sphere or base record is indicated in messages IDC21364I<br />
and IDC21365I.<br />
2. Remove any remaining association records.<br />
You can re-execute the DIAGNOSE command after you remove the sphere or<br />
base record to identify any unwanted truename or association entries in the<br />
BCS. You can remove these entries by using the DELETE command with the<br />
TRUENAME parameter.<br />
3. Reintroduce the removed entries into the catalog.<br />
After the damaged entries have been removed, you can redefine the data<br />
sets. For <strong>VSAM</strong> and SMS-managed non-<strong>VSAM</strong> data sets, you should specify<br />
the RECATALOG option of the DEFINE command.<br />
If you are recovering generation data group entries, use the same procedure.<br />
However, you must reintroduce the current generation data sets into the catalog<br />
in the proper order after the generation data group has been redefined. You can<br />
use the LISTCAT command to determine the current generation data sets.<br />
3.4.7 Recovering damaged VVDS entries<br />
To recover damaged VVDS entries, complete these steps:<br />
1. Remove the entries in the BCS for the data set, if they exist.<br />
Before the damaged VVDS records can be removed, you must remove the<br />
entries in the BCS. See 3.4.6, “Recovering damaged BCS entries” on<br />
page 172, for more details on removing BCS entries.<br />
2. Remove the damaged VVDS records.<br />
After you have removed the BCS entries, you can remove the VVDS records<br />
by using the Delete command and specifying VVR or NVR. Delete VVR or<br />
NVR also removes the Format 1 DSCB from the VTOC.<br />
3. Recover the data set from a backup copy.<br />
If a backup copy of the data set does not exist and the data set can be opened,<br />
you can attempt to recover some of the data. Depending on the extent and type<br />
of damage in the VVDS record, you might be unable to recover any data. The<br />
data that you do recover might be damaged or out of sequence.
3.5 Prevention is better than cure<br />
You can take a number of actions to prevent <strong>VSAM</strong> problems. Here we provide<br />
some recommendations.<br />
3.5.1 Back up your <strong>VSAM</strong> data sets<br />
► Back up all your critical data by using methods such as:<br />
– SMS management class with ABARS for backups, to allow restore of your<br />
data in the case of a hardware error and/or application error, and for use in<br />
disaster recovery.<br />
– Remote copy for disaster recovery.<br />
Here, we discuss some backup issues you need to consider<br />
IDCAMS export and import<br />
First, we explain some of the unique characteristics of the EXPORT and IMPORT<br />
commands:<br />
► The EXPORT command either exports a cluster or an alternate index or<br />
creates a backup copy of an integrated catalog facility catalog.<br />
Exporting means to store the cluster or AIX data in other media in a<br />
non-processable format, together with catalog information about the data set.<br />
An empty candidate volume cannot be exported. Access Method Services<br />
acknowledge and preserve the SMS classes during EXPORT.<br />
Figure 3-5 is an example in which a key-sequenced cluster,<br />
ZZZ.EXAMPLE.KSDS1, is exported from a user catalog, HHHUCAT1. The<br />
cluster is copied to a portable file, TAPE2, and its catalog entries are modified<br />
to prevent the cluster's data records from being updated, added to, or erased.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 173
174 <strong>VSAM</strong> <strong>Demystified</strong><br />
//EXPORT1 JOB ...<br />
//STEP1 EXEC PGM=IDCAMS<br />
//RECEIVE DD DSNAME=TAPE2,UNIT=(TAPE,,DEFER),<br />
// DISP=NEW,VOL=SER=003030,<br />
// DCB=(BLKSIZE=6000,DEN=3),LABEL=(1,SL)<br />
//SYSPRINT DD SYSOUT=A<br />
//SYSIN DD *<br />
EXPORT -<br />
ZZZ.EXAMPLE.KSDS1 -<br />
OUTFILE(RECEIVE) -<br />
TEMPORARY -<br />
INHIBITSOURCE<br />
/*<br />
Figure 3-5 Exporting KSDS<br />
► IMPORT is the opposite operation to EXPORT. Here, you reload the cluster or<br />
AIX data and recatalog its catalog information in an active catalog.<br />
Figure 3-6 is an example in which a key-sequenced cluster,<br />
BCN.EXAMPLE.KSDS1, that was previously EXPORTed, is IMPORTed. The<br />
OUTFILE and its associated DD statement are provided to allocate the data<br />
set. The original copy of BCN.EXAMPLE.KSDS1 is replaced with the<br />
imported copy, TAPE2. Access Method Services finds and deletes the<br />
duplicate name, BCN.EXAMPLE.KSDS1, in the catalog VCBUCAT1.<br />
A duplicate name exists because TEMPORARY was specified when the<br />
cluster was exported. Access Method Services then redefines<br />
BCN.EXAMPLE.KSDS1, using the catalog information from the portable file<br />
TAPE2.<br />
//IMPORT2 JOB ...<br />
//STEP1 EXEC PGM=IDCAMS<br />
//SOURCE DD DSNAME=TAPE2,UNIT=(TAPE,,DEFER),<br />
// VOL=SER=003030,DISP=OLD,<br />
// DCB=(BLKSIZE=6000,LRECL=479,DEN=3),LABEL=(1,SL)<br />
//SYSPRINT DD SYSOUT=A<br />
//SYSIN DD *<br />
IMPORT -<br />
INFILE(SOURCE) -<br />
OUTDATASET(BCN.EXAMPLE.KSDS1) -<br />
CATALOG(VCBUCAT1)<br />
/*<br />
Figure 3-6 IMPORT of KSDS cluster
Backup while open considerations<br />
Backup-while-open (BWO) allows DFSMSdss logical dump for an IMS or a<br />
CICS/<strong>VSAM</strong> data set while open-for-update. BWO works with Concurrent Copy<br />
(in 9390), or Snapshot (in RVAs), or Flashcopy (in ESS). The <strong>VSAM</strong> data set<br />
must be SMS managed.<br />
The DFSMSdss BWO function does not apply to: Catalogs, VVDSs, LDSs,<br />
physical dump, and restore.<br />
When you define the cluster with IDCAMS, you must declare it as a BWO. The<br />
options are:<br />
► TYPECICS<br />
Use the TYPECICS parameter to specify BWO in a CICS environment. For<br />
RLS processing, this activates BWO processing for CICS. For non-RLS<br />
processing, CICS determines whether to use this specification or the<br />
specification in the CICS control data named FCT.<br />
Note: If CICS determines that it uses the specification in the CICS FCT, the<br />
specification might override the TYPECICS or NO parameters.<br />
► TYPEIMS<br />
If you want to use BWO processing in an IMS environment, use the TYPEIMS<br />
parameter.<br />
► NO<br />
Use this parameter when BWO does not apply to the cluster.<br />
To have BWO with total security and integrity, the following products are<br />
modified:<br />
► DFSMSdfp, where catalog services have been changed to prevent<br />
unauthorized alterations of BWO indicators. DFSMSdfp does not allow<br />
deletion of a data set that DFSMSdss dumps as a BWO data set.<br />
► DFSMSdss enqueue serialization has been changed to prevent data integrity<br />
exposures when performing defrag, dump, or restore operations.<br />
► DFSMShsm, used for incremental backups and aggregate backups of a data<br />
set, invokes DFSMSdss to perform BWO.<br />
In the catalog the following fields are referring to BWO:<br />
► BWO: Data set is enabled for backup-while-open.<br />
► BWO STATUS: Indicates the status of the data set. Status can be:<br />
– Data set is enabled for backup-while-open.<br />
– Control interval or control area split is in progress.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 175
176 <strong>VSAM</strong> <strong>Demystified</strong><br />
– Data set has been restored and is down level. It might need to be updated<br />
with forward recovery logs.<br />
► BWO TIMESTAMP: A CICS timestamp that indicates the time from which<br />
forward recovery logs have to be applied to a restored copy of the data set.<br />
Space constraint relief<br />
Before we start explaining more complicated recovery situations, let us address a<br />
common abend situation prior to DFSMS/MVS 1.4.<br />
Users occasionally encounter data set allocation or extension failures (the X37<br />
type of abends), because there is not enough space available on a volume to<br />
satisfy the request. Incidentally, <strong>VSAM</strong> does not externalize an X37 abend. You<br />
recognize the out-of-space condition by the message IEC070I 203-204, where<br />
203 is the reason code. You find the explanation in the message IEC161I, return<br />
code 203, when no secondary space allocation quantity was specified. Return<br />
code 204 is issued when a new extend was attempted, but the maximum number<br />
of extents was reached.<br />
SMS alleviates this out-of-space situation to some extent by performing volume<br />
selection, checking all candidate volumes before failing an allocation.<br />
With DFSMS/MVS 1.4, you can also use the Space Constraint Relief and<br />
Reduce Space Up To (%) attributes in the data class to request that an allocation<br />
be retried if it fails due to space constraints. SMS retries the allocation by<br />
combining any of the following:<br />
► Spreading the requested quantity over multiple volumes<br />
► Allocating a percentage of the requested quantity<br />
► Using more than 5 extents<br />
Space Constraint Relief specifies whether or not to retry an allocation that was<br />
unsuccessful due to space constraints on the volume. Note that allocation is<br />
attempted on all candidate volumes before it is retried. This attribute applies only<br />
to system-managed data sets, and is limited to new data set allocations, and<br />
while extending the data set on new volumes.<br />
Out-of-space conditions are now further reduced for new volume processing of<br />
SMS-managed data sets. <strong>VSAM</strong> and non-<strong>VSAM</strong> data sets can now acquire up to<br />
123 extents instead of just 5 extents on a volume. Multivolume <strong>VSAM</strong> data sets<br />
can now have a maximum of 255 extents across volumes for each component,<br />
but no more than 123 extents per volume.<br />
Two new parameters, Space Constraint Relief and Reduce Space Up To (%), are<br />
added to the SMS data class definition for this support.
Reduce Space Up to (%) specifies the amount by which you want to reduce the<br />
requested space quantity when the allocation is retried. You must specify Y for<br />
the Space Constraint Relief attribute. Valid values are 0 to 99.<br />
If you specify Y for Space Constraint Relief, SMS begins the retry process. This<br />
is a one or two-step process, depending on the volume count you specified. For<br />
JCL allocations, SMS determines the volume count by taking the maximum of the<br />
unit, volume, or volser count. If these are not specified, SMS picks up a volume<br />
count from the data class. If there is no data class, SMS defaults the volume<br />
count to one:<br />
► If the volume count is one (one-step process):<br />
SMS retries the allocation after reducing the requested space quantity based<br />
on the Reduce Space Up To attribute. SMS simultaneously removes the<br />
5-extent limit, so that SMS can use as many extents as the data set type<br />
allows<br />
► If the volume count is greater than one (two-step process):<br />
First, SMS uses a best-fit volume selection method to spread the primary<br />
quantity over more than one volume (up to the volume count). If this fails,<br />
SMS continues with the best fit method after reducing the primary quantity<br />
and removing the 5-extent limit.<br />
If you request Space Constraint Relief but do not specify a percentage value<br />
(either 0 or blank), SMS does not reduce the requested space quantity. This<br />
implies your application cannot tolerate a reduction in the space to be allocated,<br />
so you want to remove the 5-extent limit, thereby allowing SMS to use more than<br />
5 extents.<br />
For extends to new volumes, Space Constraint Relief is strictly a one-step<br />
process. If regular volume selection has failed to allocate space, SMS reduces<br />
space or removes the 5-extent limit, but does not try the best-fit method.<br />
The number of extents vary depending on data set type, as follows:<br />
► Non-<strong>VSAM</strong>, non-extended format data sets, up to 16 extents on the volume<br />
► Non-<strong>VSAM</strong>, extended format data sets, up to 123 extents<br />
► PDSE, up to 123 extents on the volume<br />
► <strong>VSAM</strong> data sets, up to 255 extents per component but only up to 123 extents<br />
per volume per component<br />
When you request Space Constraint Relief in one or more data classes, you<br />
might notice any of the following:<br />
► Very large allocations might succeed if a sufficiently large volume count is<br />
specified in the data class or through JCL.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 177
178 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Existing data sets might end up with less space than initially requested on<br />
extents.<br />
► The space allocated for new data sets might be less than requested.<br />
► The number of extents used during initial allocation might result in fewer<br />
extents being subsequently available. For example, if the primary space<br />
allocation uses 10 extents when allocating a physical sequential data set,<br />
then only 6 extents are left for allocation of the secondary quantity.<br />
► You might observe fewer X37 abends.<br />
3.5.2 Keep your system at current maintenance levels<br />
Keep your system at a current maintenance level. Apply PTF selective service in<br />
your operating system, especially the ones associated with <strong>VSAM</strong>. To find fixes<br />
associated with broken <strong>VSAM</strong> data sets, use the search word 'dsbreaker' in<br />
either retain or through ibmlink (askq).<br />
3.5.3 Use Resource Recovery Management Services (RRMS)<br />
RRMS is an z/OS component that allows you to coordinate resource recovery.<br />
Please refer to 3.10, “RRMS and <strong>VSAM</strong>” on page 199 for details.<br />
3.6 Where to look for more information<br />
Here we list documents and APARS that you may find helpful for further<br />
information.<br />
3.6.1 IBM manuals and sources of relevant information<br />
► ICF catalogs. Refer to Integrated Catalog Facility Backup and Recovery,<br />
SG24-5644-00.<br />
► <strong>VSAM</strong> data sets in Record Level Sharing (RLS) mode. Refer to CICS/ <strong>VSAM</strong><br />
Record Level Sharing: Recovery Considerations, SG24-4768.<br />
► <strong>VSAM</strong> Knowledge Database, which is an interactive diagnostic tool. It is a<br />
question-and-answer driven knowledge database that resides on the<br />
DFSMS/MVS Technical Support Web site under “Technical Database” at:<br />
http://knowledge.storage.ibm.com/<br />
► APAR, II08859 which has a methodology to assist you in fixing broken <strong>VSAM</strong><br />
clusters.<br />
► DFSMS/MVS DFSMSdfp Diagnosis Reference, LY27-9606-05.
3.6.2 Information APARs from IBMLINK on <strong>VSAM</strong> problems<br />
There are several APARs in IBMLINK that provide useful information to assist<br />
you with <strong>VSAM</strong> problem determination.<br />
We provide here a list of such APARs:<br />
► II12927 - GUIDELINES FOR DOCO NEEDED BY <strong>VSAM</strong> LEVEL2<br />
► II08859 - BROKEN DATASET - <strong>VSAM</strong> KSDS<br />
► II10752 - ICF CATALOG PERFORMANCE PROBLEMS<br />
► II12603 - SMS<strong>VSAM</strong> INITIALIZATION AND RECOVERY CONSIDERATIONS<br />
► II12243 - MISC ABEND0F4 IN SMS<strong>VSAM</strong> FOLLOWING 'V XCF,'SYSNAME''<br />
► II10001 - Document problems in <strong>VSAM</strong>, IDCAMS, and Catalog<br />
► II13326 - COMMON PROBLEMS FROM SHCDS DEFINITION AND USAGE<br />
► II02490 - Broken Data Set (see also II08859)<br />
► II02516 - ATTACH macro<br />
► II03551 - RPL error RC8 RSN28 (x'1C')<br />
► II04390 - BLSR<br />
► II05222 - Media Manager<br />
► II05789 - Overlay by CCHH data<br />
► II06620 - LSR<br />
► II06778 - Hiperbatch<br />
► II06941 - RNL<br />
► II07664 - Enqueue<br />
► II08631 - Compression Information<br />
► II08685 - Compression Maintenance<br />
► II08859 - Broken Data Set (see also II02490)<br />
► II10001 - OEM BUGS IN <strong>VSAM</strong>, CATALOG & IDCAMS<br />
► II11013 - OEM BUGS IN <strong>VSAM</strong>, CATALOG & IDCAMS<br />
► II11513 - OEM BUGS IN <strong>VSAM</strong>, CATALOG & IDCAMS<br />
► II12140 - OEM BUGS IN <strong>VSAM</strong>, CATALOG & IDCAMS<br />
► II12615 - OEM BUGS IN <strong>VSAM</strong>, CATALOG & IDCAMS<br />
► II13278 - OEM BUGS IN <strong>VSAM</strong>, CATALOG & IDCAMS<br />
► II07664 - DIAGNOSTIC TIPS <strong>VSAM</strong>INFO : ENQUEUE<br />
3.6.3 Information APARs on specific problems<br />
Broken data set<br />
► II08859<br />
► II11955<br />
► II08859<br />
► II02490<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 179
ICF catalogs<br />
► II10752<br />
180 <strong>VSAM</strong> <strong>Demystified</strong><br />
RLS<br />
► II13326 - COMMON PROBLEMS FROM SHCDS DEFINITION AND USAGE<br />
► II12603 - SMS<strong>VSAM</strong> INITIALIZATION AND RECOVERY CONSIDERATIONS<br />
► II12243 - MISC ABEND0F4 IN SMS<strong>VSAM</strong> FOLLOWING 'V XCF,'SYSNAME''<br />
TVS<br />
OEM and other IBM products<br />
► II10001<br />
► II11013<br />
► II11513<br />
► II12140<br />
► II12615<br />
► II13278<br />
Lock problems<br />
► BDC000022923 - Loop if locksize is too large<br />
► RTA000141603 - Rebuild of IGWLOCK00<br />
► BDC000018772 - MAX IGWLOCK00<br />
► BDC000011289 - VIOPLUS<br />
Export / Import tips<br />
► II07902<br />
Memory shortage<br />
► BDC000013015<br />
► II05506<br />
3.6.4 <strong>VSAM</strong> information on the Internet<br />
<strong>VSAM</strong> Knowledge base<br />
http://knowledge.storage.ibm.com/<br />
DFSMS support sites<br />
http://ssddom02.storage.ibm.com/techsup/webnav.nsf/support/dfsms<br />
Flashes<br />
http://www-1.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/Flashes
3.7 IDC3009I message<br />
Table 3-1 IDC3009I message<br />
Return<br />
Code<br />
When working with catalogs and <strong>VSAM</strong> data sets, the IDC3009I message is<br />
probably the most common message you receive. IDC3009I is issued as a result<br />
of a catalog error or exceptional condition involving a catalog.<br />
The format of this message is shown here:<br />
IDC3009I <strong>VSAM</strong> CATALOG RETURN CODE IS return-code — REASON CODE IS IGGOCLaa —<br />
reason-code<br />
The message specifies a return code and a reason code, and they are described<br />
in OS/390 MVS System Messages, Vol 3 (GDE-IEB), GC28-1786. The return<br />
codes are as listed in Table 3-1. The table is not intended to replace the<br />
messages manual, but rather to serve as a quick reference.<br />
A brief explanation<br />
4 Error while performing open/close to a <strong>VSAM</strong> catalog. See reason code, can be either a small<br />
region size.<br />
8 The specified entry does not exist if locate was the action or<br />
the entry already exists, if action is one which adds an entry to a catalog.<br />
10 An incorrect record type was found in the catalog.<br />
12 The component was not found. It can be an AIX, a data or an index, depending on reason code.<br />
14 Catalog cell not found.: Run the Access Method Services DIAGNOSE command to check for<br />
additional information.<br />
16 Request is not supported for SMS managed volumes.<br />
18 ALTER for a backup or migrated data set failed.<br />
20 <strong>VSAM</strong> catalog has run out-of-space.<br />
22 Catalog field vector table (FVT) is zero or an incorrect FVT field was found.<br />
24 Permanent read error in <strong>VSAM</strong> catalog.<br />
26 ICF catalog: <strong>VSAM</strong> record management error (catalog record too big or too small).<br />
28 Permanent I/O error in <strong>VSAM</strong> catalog. Messages IEC331I, IEC332I, and<br />
IEC333I have been printed to aid in determining the cause of the error and where the error<br />
occurred.<br />
30 Automated Tape Library DataServer (ATLDS) processing error.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 181
Return<br />
Code<br />
A brief explanation<br />
32 Error in the <strong>VSAM</strong> catalog parameter list and indicates an internal error in Access Method<br />
Services.<br />
36 Data set not found or DSCB indicates a <strong>VSAM</strong> data set.<br />
38 Error found in a catalog installation error (user or DFHSM supplied) while processing a<br />
CATALOG, INDEX or LOCATE macro. If DFHSM, messages (ARCxxxI) are issued before.<br />
40 Two or more tasks are modifying a catalog entry, causing it to be extended in size, and one task<br />
finds that it was unable to specify sufficient virtual storage for catalog management's new<br />
requirements.<br />
42 A DADSM error occurred on branch entry to DADSM back end (DADSM rename, locate or<br />
scratch, according to reason code).<br />
44 The caller's work area is too small.<br />
48 Incorrect <strong>VSAM</strong> catalog function.<br />
50 An error has been detected in VVDS manager error.<br />
52 Permanent I/O error on user volume. An attempt to run a direct execute channel program<br />
(EXCP) write of a DSCB to the VTOC failed. The reason codes are the event control block (ECB)<br />
completion codes returned after the EXCP write and you can the meaning in “Event Control<br />
Block Fields”,DFSMS/MVS DFSMSdfp Advanced Services, SC26-4921.<br />
54 Incorrect use of JOBCAT or STEPCAT with SMS data sets.<br />
56 A security verification failed.<br />
58 Error while reading a DSCB into a work area. Reason code is DADSM OBTAIN Return Code<br />
and you can find in “Return Codes from OBTAIN”, DFSMS/MVS DFSMSdfp Advanced<br />
Services, SC26-4921.<br />
60 Incorrect entry type for requested action.<br />
62 Error while initializing the extension of a data set. The reason codes are the complement of the<br />
error codes returned from the DADSM extend routine; refer to DFSMSdfp Diagnosis Reference,<br />
LY27-9606.<br />
64 <strong>VSAM</strong> catalog cannot find either a data or an index entry which is associated with a cluster or<br />
alternate index entry.<br />
66 Bad DADSM parameter list. The reason code is the DADSM return code, and you can find in<br />
DFSMSdfp Diagnosis Reference, LY27-9606.<br />
68 No space is available on the user volume for the ICF catalog. Only the<br />
primary volume will be used.<br />
70 A generation data set component was not found in the GDG sphere record.<br />
182 <strong>VSAM</strong> <strong>Demystified</strong>
Return<br />
Code<br />
A brief explanation<br />
72 The user volume is not mounted. The reason codes are from <strong>VSAM</strong> open/close/end-of-volume,<br />
volume mount and verify routine IDA0192V.<br />
74 Catalog Cell not found. Different reasons codes from those specified in return code 14.<br />
76 No unit available for mounting or volume not mounted.<br />
78 Subrecord move error. It can be: Catalog management was unable to obtain enough virtual<br />
storage to contain the catalog record with the addition of the subrecord or verification record<br />
was not within the length range of 1 to 256.<br />
80 The object specified in the RELATE parameter of a DEFINE command does not exist, or is<br />
improper for the type of object being defined.<br />
82 The number of data set entries passed exceeds the allowed maximum for the catalog name<br />
locate.<br />
84 Date error: a DELETE to a data set with an unexpired purge date and PURGE was not specified<br />
or there are conflicting date format (rc=2).<br />
86 Recatalog error, reason vary according to reason codes.<br />
88 Error with a catalog recovery area (CRA) define operation: The total space specified was not<br />
able to contain the size specified for the catalog and<br />
the one cylinder of space required for the CRA.<br />
90 Delete error.<br />
92 The maximum number of extents was reached.<br />
94 A DADSM OBTAIN request failed during a <strong>VSAM</strong> catalog delete request. The reason code is<br />
the OBTAIN return code and you can find out its meaning in “DADSM OBTAIN Function Return<br />
Codes”, DFSMSdfp Diagnosis Reference, LY27-9606.<br />
96 An error occurred in specifying key length, key position or record size for an alternate index or<br />
spanned cluster.<br />
98 An unusual condition occurred during an ALTER name of a unique or non-<strong>VSAM</strong> data set. The<br />
reason code is status byte returned by the DADSM RENAME function. See the meaning in<br />
“Status Codes from RENAME”, DFSMSdfp Diagnosis Reference, LY27-9606.<br />
102 A DADSM SCRATCH request failed during a <strong>VSAM</strong> catalog delete request. for a unique or<br />
non-<strong>VSAM</strong> data set. The reason code is status byte returned by the DADSM SCRATCH<br />
function. See the meaning in “Status Codes from SCRATCH”, DFSMSdfp Diagnosis Reference,<br />
LY27-9606.<br />
104 A DEFINE command is attempting to define a second <strong>VSAM</strong> master catalog when a <strong>VSAM</strong><br />
master catalog already exists and is open.<br />
106 A format-4 DSCB processing error was encountered.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 183
Return<br />
Code<br />
A brief explanation<br />
108 An incorrect field name was found in the field parameter list. The field name passed by AMS<br />
does not exist in the <strong>VSAM</strong> catalog management dictionary. The message indicates that the<br />
caller's AMS release level or maintenance level is different from the CATALOG level that is being<br />
called.<br />
110 Unable to modify or delete RACF profile. It does not exist (but has RACF indicator (reason 4) or<br />
a rename processing for a RACF-protected data set failed because as a result of the new name,<br />
the data set cannot be defined to the security subsystem.<br />
112 Incorrect Catalog field parameter list (FPL).<br />
114 As a result of an IMPORT, IMPORTRA, or DEFINE command, <strong>VSAM</strong> has attempted to establish<br />
a RACF profile for a cluster/alternate index, data, or index object (reason codes 0, 4, and 8<br />
respectively). This failed because a profile with the same name already exists.<br />
116 <strong>VSAM</strong> catalog records are incorrect. The reason code explain for what kind of object the record<br />
can not be obtained.<br />
118 The data set name is ineligible for RACF definition. User does not have authority (reason code<br />
0) or RACF inactive (reason code 12).<br />
120 Attempt to modify the non-existent or system field. This is a system error.<br />
124 Incorrect control interval number.<br />
126 Alter new name of a GDS, non-<strong>VSAM</strong> or cluster failed because an ACS service returns a<br />
non-zero return code. ACS reason code = catalog reason<br />
code + 1000. services reason codes from 1000 to 1255. The ACS<br />
services return and reason codes are documented in the DFSMSdfp Diagnosis Reference,<br />
LY27-9606.<br />
128 A user-provided storage is outside the user region. Probable system error.<br />
130 An ALTER RENAME recatalog error. Reason code explains why.<br />
132 Incorrect pointer value in argument list. Probable system error.<br />
136 Required parameters not supplied. Probable system error.<br />
138 DADSM RENAME error. Reason code is the volume status code returned from DADSM.<br />
142 DADSM OBTAIN error. Reason code is the return code from OBTAIN and you find in DFSMSdfp<br />
Advanced Services, SC26-4921.<br />
144 An incorrect entry name format or the name has an initial character as a numeric or used a<br />
restricted name. See reason code.<br />
148 Volume already owned by another <strong>VSAM</strong> catalog. Specify a different volume or use the Access<br />
Method Services ALTER REMOVEVOLUMES command to reset the volume ownership if a<br />
catalog should not own the volume.<br />
184 <strong>VSAM</strong> <strong>Demystified</strong>
Return<br />
Code<br />
A brief explanation<br />
150 Name length error for an SMS construct. Storage class (reason code 2) or data class (4) or<br />
management class (6).<br />
152 A non-empty catalog cannot be deleted. If the catalog and all of its<br />
entries are to be deleted specify the FORCE parameter on the Access Method Services<br />
DELETE CATALOG command.<br />
156 The volume does not contain a data space for another <strong>VSAM</strong> data set. There is insufficient<br />
space in the data spaces allocated on the volume to satisfy a request for suballocation.<br />
160 DELETE space is requested for a volume containing a catalog. See explanation and<br />
programmer response in reason code.<br />
164 There is insufficient virtual storage available for <strong>VSAM</strong> catalog management. Increase the<br />
region size available to the step.<br />
168 Unsupported device type.<br />
172 A DEFINE command specifies the name of a data set, with the UNIQUE attribute, but there is<br />
already a data set on the specified volume with that name.<br />
176 There is no space in the VTOC for a DSCB. Delete any unneeded data sets or data spaces from<br />
the volume or recreate the volume with a larger VTOC.<br />
178 An error occurred during ICF catalog processing of a <strong>VSAM</strong> partial release request.<br />
180 Data space name not found. Probable system error. The catalog or a volume may have been<br />
totally or partially destroyed.<br />
182 Bad DADSM UPDATE parameter list. The reason code is the Volume status code from DADSM.<br />
You can see a volume status using ISMF.<br />
184 The data set is currently open and cannot be deleted or altered.<br />
186 Error attempting to lock a catalog or access a locked catalog.<br />
188 Catalog unavailable. See return code in the messages manual.<br />
190 Authorization error on a facility class function applied to SMS data sets. The user need read<br />
access authority to 'STGADMIN.IGG.LIBRARY'.<br />
192 Maximum logical record length specified is greater than 32,761 for a non-spanned data set.<br />
194 An error occurred during multi-level alias (MLA) facility processing. See reason code in the<br />
message manual.<br />
196 The data component control interval size specified is greater than 32,767.<br />
198 An attempt has been made to use an unsupported feature. Related to a UCB’s device defined<br />
above 16M, which resides a <strong>VSAM</strong> catalog.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 185
Return<br />
Code<br />
A brief explanation<br />
200 The specified or defaulted control interval size of the index component is greater than the<br />
maximum block size of the index device. Reduce the control interval or use a device with a larger<br />
maximum block size.<br />
202 Storage management subsystem call error. Redefine the data set with a management class<br />
with no retention limit or with a specified retention value equal to or exceeding the date specified<br />
in the ALTER command.<br />
204 Key specification extends beyond end of maximum logical record. Reduce the key length,<br />
change the key position, or increase the logical record length.<br />
208 The buffer space specified is too small. Do not specify BUFFERSPACE, let the default value.<br />
210 Subsystem call error. Reason code is the return code from Subsystem call.<br />
212 Control interval size calculation unsolvable. See reason code.<br />
214 Subsystem call error. Reason code is the return code from Subsystem call.<br />
216 The volume's VTOC is not interpretable. An incorrect VTOC was deleted during update extend<br />
processing for a <strong>VSAM</strong> data set. Restore the volume in order to correct the VTOC.<br />
220 A DOS VTOC cannot be converted to an OS VTOC. Restore the volume in order to correct the<br />
VTOC.<br />
222 Alter new name of a GDS, non-<strong>VSAM</strong> or cluster failed because an ACS service returns a<br />
non-zero return code. ACS reason code = catalog reason code + decimal 256. ACS services<br />
return and reason codes are documented in DFSMSdfp Diagnosis Reference, LY27-9606.<br />
224 A field in a catalog entry has exceeded the maximum allowable number of repetitions. For<br />
example, trying to add more than 255 volumes or more than 125 alternate indexes in the<br />
upgrade set.<br />
226 The caller is not authorized to perform the requested function. The caller must be running in key<br />
0 - 7, must be in supervisor state, or must be APF authorized.<br />
228 An error occurred while processing an Enhanced Catalog Sharing (ECS) request. Refer to<br />
reason code in the message manual to correct the problem.<br />
230 <strong>VSAM</strong> catalog retrieve of a control interval failed to get a low range record from the <strong>VSAM</strong><br />
catalog. Probable system error.<br />
232 An error was encountered while <strong>VSAM</strong> Catalog Management was performing SMF processing.<br />
Use the reason code as a return code to IDC3009I to find out the reason of the error.<br />
234 End of data encountered while reading the low data key range of the <strong>VSAM</strong> catalog. Probable<br />
system error.<br />
236 An error was encountered in space-map. This condition arises when the catalog's volume entry<br />
is incorrect. Reconstruct the volume entry record. If that is not possible, restore the catalog.<br />
186 <strong>VSAM</strong> <strong>Demystified</strong>
Return<br />
Code<br />
A brief explanation<br />
238 No user catalog entry in the master catalog for Convert Volume processing.<br />
240 Required DD statement not supplied. See reason code in the message manual.<br />
242 A physical I/O error occurred trying to erase the data set being deleted. The reason code<br />
correspond to the <strong>VSAM</strong> Record Management error codes. See “Record Management Return<br />
and Reason Codes” in DFSMS/MVS Macro Instructions for Data Sets, SC26-4913. Run the job<br />
again with the NOERASE option. The data set cannot be deleted.<br />
244 Erase action failed. The <strong>VSAM</strong> Catalog Management is unable to open the <strong>VSAM</strong> data set<br />
being deleted. The reason codes correspond to the <strong>VSAM</strong> OPEN error codes. See “OPEN<br />
Return Codes” in DFSMS/MVS Macro Instructions for Data Sets, SC26-4913. Alternatively, you<br />
run the DELETE command again with the NOERASE option.<br />
246 CAS service task abended or detected an abnormal condition. See reason code in the<br />
messages manual.<br />
248 A function requires a volume that is not owned by the <strong>VSAM</strong> catalog being<br />
used.<br />
250 <strong>VSAM</strong> Record Management has found a logical error during erase processing while deleting<br />
a <strong>VSAM</strong> data set. The reason codes correspond to the <strong>VSAM</strong> record management logical error<br />
code. See “Record Management Return and Reason Codes” in DFSMS/MVS Macro<br />
Instructions for Data Sets, SC26-4913. Alternatively, you run the DELETE command again with<br />
the NOERASE option.<br />
254 An error was encountered during catalog reorientation. The reason code indicates in what part<br />
the error was found: close (reason code 0), open (2), allocation (4) or an unexpected error (6).<br />
Note: Reason codes, explanations, system actions and programmers response are described in<br />
z/OS V1R4.0 MVS System Messages, Vol 6 (GOS-IEA) under IDC3009I message.<br />
3.8 IDCAMS LISTCAT output fields<br />
In the ICF catalog, <strong>VSAM</strong> maintains special RBA, CI, and Key values together<br />
with time stamps, which are very important in accessing a <strong>VSAM</strong> cluster. The<br />
most important ones are located in the VVR AMDSB in the VVDS cell and are<br />
updated only at Close time.<br />
IDCAMS LISTCAT command displays this information, which is key to<br />
diagnosing what caused the error. The screen below shows some JCL you need<br />
in order to issue the LISTCAT command via BATCH. You can issue the same<br />
command under TSO/ISPF.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 187
188 <strong>VSAM</strong> <strong>Demystified</strong><br />
//LISTCAT JOB 'LISTCCAT EXAMPLE',NOTIFY=&SYSUID<br />
//*--------------------------------------------------------------*<br />
//EXAMPLE EXEC PGM=IDCAMS<br />
//SYSPRINT DD SYSOUT=*<br />
//SYSIN DD *<br />
LISTC ENTRY(DAWN.KSDSEXG) ALL<br />
The output from the LISTCAT command is:<br />
1IDCAMS SYSTEM SERVICES TIME:<br />
21:15:46 04/20/00 PAGE 1<br />
0<br />
LISTC ENTRY(DAWN.KSDSEXG) ALL<br />
00044403<br />
0CLUSTER ------- DAWN.KSDSEXG<br />
IN-CAT --- MCAT.SANDBOX.R9.VSBOX11<br />
HISTORY<br />
DATASET-OWNER-----(NULL) CREATION--------2000.108<br />
RELEASE----------------2 EXPIRATION------0000.000<br />
SMSDATA<br />
STORAGECLASS -----STRIPE MANAGEMENTCLASS---MCDB22<br />
DATACLASS ------KEYEDEXG LBACKUP ---0000.000.0000<br />
BWO STATUS------00000000 BWO TIMESTAMP---00000 00:00:00.0<br />
BWO---------------(NULL)<br />
RLSDATA<br />
LOG ----------------(NULL) RECOVERY REQUIRED --(NO)<br />
<strong>VSAM</strong> QUIESCED -------(NO) RLS IN USE ---------(NO)<br />
0 LOGSTREAMID-----------------------------(NULL)<br />
RECOVERY TIMESTAMP LOCAL-----X'0000000000000000'<br />
RECOVERY TIMESTAMP GMT-------X'0000000000000000'<br />
PROTECTION-PSWD-----(NULL) RACF----------------(NO)<br />
ASSOCIATIONS<br />
DATA-----DAWN.KSDSEXG.DATA<br />
INDEX----DAWN.KSDSEXG.INDEX<br />
0 DATA ------- DAWN.KSDSEXG.DATA<br />
IN-CAT --- MCAT.SANDBOX.R9.VSBOX11<br />
HISTORY<br />
DATASET-OWNER-----(NULL) CREATION--------2000.108<br />
RELEASE----------------2 EXPIRATION------0000.000<br />
ACCOUNT-INFO-----------------------------------(NULL)<br />
PROTECTION-PSWD-----(NULL) RACF----------------(NO)<br />
ASSOCIATIONS<br />
CLUSTER--DAWN.KSDSEXG<br />
ATTRIBUTES<br />
KEYLEN-----------------8 AVGLRECL-------------300<br />
BUFSPACE-----------10240 CISIZE--------------4096
RKP--------------------0 MAXLRECL-------------300<br />
EXCPEXIT----------(NULL) CI/CA----------------192<br />
STRIPE-COUNT-----------4<br />
SHROPTNS(1,3) RECOVERY UNIQUE NOERASE INDEXED<br />
NOWRITECHK NOIMBED NOREPLICAT<br />
UNORDERED NOREUSE NONSPANNED EXTENDED<br />
STATISTICS<br />
REC-TOTAL---------321595 SPLITS-CI-----------6466<br />
EXCPS--------------82682<br />
REC-DELETED-------173530 SPLITS-CA-------------42<br />
EXTENTS----------------4<br />
REC-INSERTED-------45123 FREESPACE-%CI---------10<br />
SYSTEM-TIMESTAMP:<br />
REC-UPDATED--------56016 FREESPACE-%CA---------10<br />
X'B3ECB2FDD72E7785'<br />
REC-RETRIEVED----3186326 FREESPC--------610766848<br />
ALLOCATION<br />
SPACE-TYPE---------TRACK HI-A-RBA-------736100352<br />
SPACE-PRI-----------3744 HI-U-RBA-------203685888<br />
SPACE-SEC------------624<br />
VOLUME<br />
1IDCAMS SYSTEM SERVICES TIME:<br />
21:15:46 04/20/00 PAGE 2<br />
0 VOLSER------------SBOX31 PHYREC-SIZE---------4096<br />
HI-A-RBA-------736100352 EXTENT-NUMBER----------1<br />
DEVTYPE------X'3010200F' PHYRECS/TRK-----------12<br />
HI-U-RBA-------203685888 EXTENT-TYPE--------X'00'<br />
VOLFLAG------------PRIME TRACKS/CA--------------4<br />
STRIPE-NUMBER----------1<br />
EXTENTS:<br />
LOW-CCHH-----X'000A000A' LOW-RBA----------------0<br />
TRACKS--------------3744<br />
HIGH-CCHH----X'01040003' HIGH-RBA-------736100351<br />
VOLUME<br />
VOLSER------------SBOX30 PHYREC-SIZE---------4096<br />
HI-A-RBA-------736100352 EXTENT-NUMBER----------1<br />
DEVTYPE------X'3010200F' PHYRECS/TRK-----------12<br />
HI-U-RBA---------------0 EXTENT-TYPE--------X'40'<br />
VOLFLAG------------PRIME TRACKS/CA--------------4<br />
STRIPE-NUMBER----------2<br />
EXTENTS:<br />
LOW-CCHH-----X'0104000B' LOW-RBA----------------0<br />
TRACKS--------------3744<br />
HIGH-CCHH----X'01FE0004' HIGH-RBA-------736100351<br />
VOLUME<br />
VOLSER------------MHLV14 PHYREC-SIZE---------4096<br />
HI-A-RBA-------736100352 EXTENT-NUMBER----------1<br />
DEVTYPE------X'3010200F' PHYRECS/TRK-----------12<br />
HI-U-RBA---------------0 EXTENT-TYPE--------X'40'<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 189
190 <strong>VSAM</strong> <strong>Demystified</strong><br />
VOLFLAG------------PRIME TRACKS/CA--------------4<br />
STRIPE-NUMBER----------3<br />
EXTENTS:<br />
LOW-CCHH-----X'0103000B' LOW-RBA----------------0<br />
TRACKS--------------3744<br />
HIGH-CCHH----X'01FD0004' HIGH-RBA-------736100351<br />
VOLUME<br />
VOLSER------------SBOX28 PHYREC-SIZE---------4096<br />
HI-A-RBA-------736100352 EXTENT-NUMBER----------1<br />
DEVTYPE------X'3010200F' PHYRECS/TRK-----------12<br />
HI-U-RBA---------------0 EXTENT-TYPE--------X'40'<br />
VOLFLAG------------PRIME TRACKS/CA--------------4<br />
STRIPE-NUMBER----------4<br />
EXTENTS:<br />
LOW-CCHH-----X'0103000B' LOW-RBA----------------0<br />
TRACKS--------------3744<br />
HIGH-CCHH----X'01FD0004' HIGH-RBA-------736100351<br />
0 INDEX ------ DAWN.KSDSEXG.INDEX<br />
IN-CAT --- MCAT.SANDBOX.R9.VSBOX11<br />
HISTORY<br />
DATASET-OWNER-----(NULL) CREATION--------2000.108<br />
RELEASE----------------2 EXPIRATION------0000.000<br />
PROTECTION-PSWD-----(NULL) RACF----------------(NO)<br />
ASSOCIATIONS<br />
CLUSTER--DAWN.KSDSEXG<br />
ATTRIBUTES<br />
KEYLEN-----------------8 AVGLRECL---------------0<br />
BUFSPACE---------------0 CISIZE--------------2048<br />
RKP--------------------0 MAXLRECL------------2041<br />
EXCPEXIT----------(NULL) CI/CA-----------------21<br />
SHROPTNS(1,3) RECOVERY UNIQUE NOERASE NOWRITECHK<br />
NOIMBED NOREPLICAT UNORDERED<br />
NOREUSE EXTENDED<br />
STATISTICS<br />
REC-TOTAL------------263 SPLITS-CI-------------42<br />
EXCPS--------------39045 INDEX:<br />
REC-DELETED------------0 SPLITS-CA--------------1<br />
EXTENTS----------------2 LEVELS-----------------3<br />
REC-INSERTED-----------0 FREESPACE-%CI----------0<br />
SYSTEM-TIMESTAMP: ENTRIES/SECT----------13<br />
REC-UPDATED--------21884 FREESPACE-%CA----------0<br />
X'B3ECB2FDD72E7785' SEQ-SET-RBA------------0<br />
REC-RETRIEVED----------0 FREESPC------------63488<br />
HI-LEVEL-RBA------436224<br />
1IDCAMS SYSTEM SERVICES TIME:<br />
21:15:46 04/20/00 PAGE 3<br />
0 ALLOCATION<br />
SPACE-TYPE---------TRACK HI-A-RBA----------602112<br />
SPACE-PRI-------------12 HI-U-RBA----------538624
SPACE-SEC--------------2<br />
VOLUME<br />
VOLSER------------SBOX31 PHYREC-SIZE---------2048<br />
HI-A-RBA----------602112 EXTENT-NUMBER----------2<br />
DEVTYPE------X'3010200F' PHYRECS/TRK-----------21<br />
HI-U-RBA----------538624 EXTENT-TYPE--------X'00'<br />
VOLFLAG------------PRIME TRACKS/CA--------------1<br />
EXTENTS:<br />
LOW-CCHH-----X'00000002' LOW-RBA----------------0<br />
TRACKS----------------12<br />
HIGH-CCHH----X'0000000D' HIGH-RBA----------516095<br />
LOW-CCHH-----X'01040004' LOW-RBA-----------516096<br />
TRACKS-----------------2<br />
HIGH-CCHH----X'01040005' HIGH-RBA----------602111<br />
VOLUME<br />
VOLSER------------SBOX30 PHYREC-SIZE---------2048<br />
HI-A-RBA---------1032192 EXTENT-NUMBER----------1<br />
DEVTYPE------X'3010200F' PHYRECS/TRK-----------21<br />
HI-U-RBA---------------0 EXTENT-TYPE--------X'40'<br />
VOLFLAG-------CAND-SPACE TRACKS/CA--------------1<br />
EXTENTS:<br />
LOW-CCHH-----X'01FE0005' LOW-RBA-----------516096<br />
TRACKS----------------12<br />
HIGH-CCHH----X'01FF0001' HIGH-RBA---------1032191<br />
VOLUME<br />
VOLSER------------MHLV14 PHYREC-SIZE---------2048<br />
HI-A-RBA---------1548288 EXTENT-NUMBER----------1<br />
DEVTYPE------X'3010200F' PHYRECS/TRK-----------21<br />
HI-U-RBA---------------0 EXTENT-TYPE--------X'40'<br />
VOLFLAG-------CAND-SPACE TRACKS/CA--------------1<br />
EXTENTS:<br />
LOW-CCHH-----X'01FD0005' LOW-RBA----------1032192<br />
TRACKS----------------12<br />
HIGH-CCHH----X'01FE0001' HIGH-RBA---------1548287<br />
VOLUME<br />
VOLSER------------SBOX28 PHYREC-SIZE---------2048<br />
HI-A-RBA---------2064384 EXTENT-NUMBER----------1<br />
DEVTYPE------X'3010200F' PHYRECS/TRK-----------21<br />
HI-U-RBA---------------0 EXTENT-TYPE--------X'40'<br />
VOLFLAG-------CAND-SPACE TRACKS/CA--------------1<br />
EXTENTS:<br />
LOW-CCHH-----X'01FD0005' LOW-RBA----------1548288<br />
TRACKS----------------12<br />
HIGH-CCHH----X'01FE0001' HIGH-RBA---------2064383<br />
1IDCAMS SYSTEM SERVICES TIME:<br />
21:15:46 04/20/00 PAGE 4<br />
0 THE NUMBER OF ENTRIES PROCESSED WAS:<br />
AIX -------------------0<br />
ALIAS -----------------0<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 191
192 <strong>VSAM</strong> <strong>Demystified</strong><br />
CLUSTER ---------------1<br />
DATA ------------------1<br />
GDG -------------------0<br />
INDEX -----------------1<br />
NON<strong>VSAM</strong> ---------------0<br />
PAGESPACE -------------0<br />
PATH ------------------0<br />
SPACE -----------------0<br />
USERCATALOG -----------0<br />
TAPELIBRARY -----------0<br />
TAPEVOLUME ------------0<br />
TOTAL -----------------3<br />
0 THE NUMBER OF PROTECTED ENTRIES SUPPRESSED WAS 0<br />
0IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0<br />
0<br />
0IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0<br />
Use the output from the LISTCAT command listed above to follow the<br />
explanations about the most key catalog fields shown by LISTCAT.<br />
3.8.1 High used RBA value (HURBA) for KSDS<br />
There are two HURBAs per KSDS cluster: the data HURBA, and the index<br />
HURBA:<br />
► Data HURBA<br />
This is the RBA of the physically highest record in data CI (it does not imply<br />
the highest key, because the existence of splits). In other words, it points to<br />
the end of the last CA which ever, at any time, contained data. It is<br />
incremented by one CA, if a CA split or add-to-the-end in a new CA occurs. It<br />
is always on a CA boundary.<br />
If all logical records are deleted the HURBA does not turn to zero — only via<br />
create or resetting. Also, if the data set was defined with the Reuse option, in<br />
this case at Open time, HURBA is reset to zero.<br />
When share option cross-system 4 is set to the data set, this value cannot be<br />
modified.<br />
If a data set has HURBA=0, it cannot be opened for input.<br />
► Index HURBA<br />
This points to the end of the last index CI written. It is incremented by one CI<br />
if a new record is added to the index. Separate HURBA values are maintained<br />
for the imbedded sequence set, and the high level index if IMBED is used.<br />
Index HURBA is always on a CI boundary.
There are also two types of data components:<br />
► ESDS data component<br />
The HURBA points to the end of the last CI which contains data. It is<br />
incremented by one CI, if a new CI is entered via add-to-end processing.<br />
It is always on a CI boundary.<br />
► RRDS data component<br />
The HURBA points to the end of the last CA which ever contained data. It is<br />
incremented by add-to-end processing which enters a new CA, or by direct<br />
insert of a record whose slot number resolves to a new CA.<br />
It is always on a CA boundary.<br />
The name, HURBA, does not mean that every byte up to the HURBA is used.<br />
There may be imbedded free space due to distributed space, record deletion,<br />
slots which have never been used (RRDS) as well as unused space at the end of<br />
the CI or CA. The HARBA is an RBA pointer to the end of the last current extent<br />
of that cluster component. Until the HURBA equals the HARBA for that<br />
component, another extent will not be taken.<br />
3.8.2 High allocated RBA value (HARBA)<br />
3.8.3 FREESPC<br />
3.8.4 High key RBA/CI<br />
This is the highest RBA available within allocated space to store the data<br />
component, its key range, the index component, or the sequence set records of a<br />
key range. KSDS has two HARBAs: one for the index; another for data.<br />
The difference (HARBA - HURBA) is the amount of space ready to be freed by<br />
the free space release option after close. It includes all the CAs in the physical<br />
end of the data sets with only free CIs.<br />
This is the actual number of bytes of free space in the total amount of space<br />
allocated to the data or index component. Free space in partially used control<br />
intervals is not included in this statistic.<br />
It is the RBA of the logically highest data CI (the one with the record with the<br />
highest key). When the cross-system SHAREOPTION 4 is set to the data set,<br />
this value cannot be modified.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 193
3.8.5 High-level index RBA value<br />
194 <strong>VSAM</strong> <strong>Demystified</strong><br />
Any time the data set is accessed directly through a key, <strong>VSAM</strong> uses this value to<br />
find the highest level index record to start the search through lower levels.<br />
If the high-level index RBA is corrupted, the user will not be able to perform direct<br />
requests against the data set.<br />
3.8.6 Sequence set first RBA value<br />
If the data set is being read sequentially, from start to finish (for example,<br />
REPRO), <strong>VSAM</strong> uses this value to go directly to the first sequence set record. If<br />
Sequence Set RBA is corrupted sequential access will not be possible.<br />
3.8.7 Number of index levels<br />
3.8.8 Time stamps<br />
The number of levels of index records in the index. for an KSDS/VRRDS cluster.<br />
If this number is greater than four (meaning a very big data set), maybe it is an<br />
indication for reorganization increasing the size of the CI index.<br />
At close time, if the cluster is open for output, the KSDS time stamps are updated<br />
with the current system time (same value for both data and index). However,<br />
each component¢s individual time stamp is updated in the catalog only if it is<br />
greater than the component's time stamp currently in the catalog. Prior to<br />
updating time stamps IN THE CATALOG, Close writes SMF record type 64. The<br />
time stamp ordering the SMF record should slightly precede that in the catalog.<br />
At Open time, if the time stamp of the index component is less than that of the<br />
data component, the data component is updated separately and after the index<br />
component, or vice-versa.<br />
3.9 SMF record types related to <strong>VSAM</strong> data sets<br />
Following are the SMF records related to <strong>VSAM</strong> recovery and <strong>VSAM</strong><br />
performance.<br />
3.9.1 SMF record type 60<br />
Record type 60 is written when a record is inserted, updated, or deleted from a<br />
<strong>VSAM</strong> Volume Data Set (VVDS). For example, when a <strong>VSAM</strong> cluster is defined,<br />
closed, or deleted.
VVDS is a part of ICF catalog structure (the other is BCS), located in the volume<br />
which contains the described data sets. It contains dynamic information, as<br />
statistics, about these data sets. <strong>VSAM</strong> data sets and SMS data sets must be<br />
cataloged in an ICF catalog. The record related to a <strong>VSAM</strong> data set is a <strong>VSAM</strong><br />
Volume Record (VVR), while the record related to non-<strong>VSAM</strong> data sets is a<br />
Non-<strong>VSAM</strong> Volume Record (NVR).<br />
One type 60 record is written for each VVR or NVR written or deleted. This<br />
record:<br />
► Identifies the VVDS in which the VVR or NVR is written or deleted.<br />
► Gives the new, updated, or deleted VVR or NVR.<br />
► Identifies the job by job log and user identifiers.<br />
3.9.2 SMF record type 61<br />
One type 61 record is written for each record inserted or updated in a catalog.<br />
This record:<br />
► Identifies the entry being defined and the catalog in which the catalog record<br />
is written.<br />
► Gives the new or updated catalog record.<br />
► Identifies the job by job log and user identifiers.<br />
3.9.3 SMF record type 62<br />
Record type 62 is written at the successful or unsuccessful opening of a <strong>VSAM</strong><br />
component or cluster. The record:<br />
► Identifies the <strong>VSAM</strong> component or cluster.<br />
► Indicates whether it was successfully opened.<br />
► Names the <strong>VSAM</strong> catalog in which the object is defined and the volumes on<br />
which the catalog and object are stored.<br />
► It identifies the job that issued the OPEN macro by job log identification and<br />
user identification.<br />
This record is not generated when a system task issues the OPEN macro.<br />
3.9.4 SMF record type 63<br />
Record type 63 is written when a <strong>VSAM</strong> catalog entry (a component, cluster,<br />
catalog, alternate index, path, or non-<strong>VSAM</strong> data set) is defined by the DEFINE<br />
Access Method Services command and when that definition is altered. For<br />
example, when a <strong>VSAM</strong> catalog entry is altered with new space allocation<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 195
196 <strong>VSAM</strong> <strong>Demystified</strong><br />
information (that is, when the <strong>VSAM</strong> End-Of-Volume (EOV) routine extends the<br />
entries object) or, if the entry is changed by the Alter Access Method Services<br />
command. One record type 63 is written for each newly created or altered entry.<br />
This record is not written when a <strong>VSAM</strong> catalog is renamed. In that case record<br />
type 68 is written. This record:<br />
► Identifies the catalog in which the object is defined.<br />
► Gives the catalog record for the newly defined object, and, for an alteration,<br />
gives the parts of the old catalog record before they were altered.<br />
► Identifies the job and the user that caused the record to be written. If it was<br />
caused by a system task, the job-name and the user-identification fields<br />
contain blanks and the time and date fields contain zeros.<br />
3.9.5 SMF record type 64<br />
Record type 64 is written when:<br />
► A <strong>VSAM</strong> component or cluster is closed.<br />
► <strong>VSAM</strong> must switch to another volume to continue to read or write.<br />
► The component ran out of space and EOV is called to extend the component.<br />
When a cluster is closed, one record is written for each component in the SMF<br />
record type 64. The reason why the record was created is indicated in the record.<br />
SMF record type 64 description<br />
The record describes the device and volume(s) on which the object is stored, and<br />
gives the extents of the object on the volume(s). It gives statistics about various<br />
processing events that have occurred since the object was defined, such as the<br />
number of records in the data component, the number of records that were<br />
inserted, and the number of control intervals that were split.<br />
The record written when the <strong>VSAM</strong> component or cluster is closed contains<br />
changes in statistics from OPEN to time of EOV and CLOSE.<br />
SMF64 sample program<br />
The IDCAMS LISTCAT command shows the cumulative number of EXCPs, since<br />
the initial load. Sometimes is more important to know the number of EXCPs<br />
executed between OPEN and CLOSE, mainly when you are doing tuning in<br />
buffering. The section “Sample programs extract from SMF record type 64” on<br />
page 367, contains sample source assembler code. It can be used for showing<br />
more information about your <strong>VSAM</strong> data sets. By using JCL parameters, you can<br />
determine an EXCPs threshold. Then, the program only shows data covering the<br />
data sets with equal or more EXCPS than the threshold that occurred between<br />
open and close. The report generated is based on the SMF 64 record, generated
each time a <strong>VSAM</strong> data set is closed. It can help you to determine the<br />
characteristics of the data sets with high I/O activity. To reduce the I/O activity:<br />
► You can use SMB if the data sets are already in extended format.<br />
► You can convert data sets to extended format and then use SMB.<br />
► In the case of LSR buffering and direct access, you can find out if the data<br />
sets are using defer write, and if not, whether they could be.<br />
► You can determine whether the <strong>VSAM</strong> buffers are below 16 MB, and whether<br />
to move them above 16 MB.<br />
► For KSDS and VRRDS data sets, when the total number of free control<br />
intervals is much higher than free space defined to the data set consider<br />
reorganization. Do not reorganize data sets if it is not necessary.<br />
► When doing changes in buffering, you can use the report to see how the<br />
numbers of EXCPs decreased.<br />
For a description of SMF type 64 fields, refer to OS/390 MVS System<br />
Management Facilities (SMF), GC28-1783.<br />
3.9.6 SMF record type 65<br />
Record type 65 is written during any processing that results in a DELETE request<br />
to Catalog management services, such as:<br />
► IDCAMS DELETE<br />
► IEHPROGM UNCATLG<br />
One type 65 record is written for each record updated or deleted from a catalog.<br />
The record:<br />
► Identifies the entry being deleted.<br />
► Identifies the catalog in which the catalog record is updated or deleted.<br />
► Gives the updated or deleted catalog record.<br />
► Indicates whether a <strong>VSAM</strong> cluster or non-<strong>VSAM</strong> data set was scratched, or<br />
whether only catalog information was deleted.<br />
► Identifies the job and the user. If a system task caused the record to be<br />
written, the job name and user identification fields contain blanks, and the<br />
time and date fields contain zeros.<br />
3.9.7 SMF record type 66<br />
Record type 66 is written during any processing that results in an ALTER request<br />
to Catalog Management Services, such as IDCAMS ALTER.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 197
198 <strong>VSAM</strong> <strong>Demystified</strong><br />
One type 66 record is written for each record written or deleted from a catalog.<br />
The record:<br />
► Identifies the entry being altered.<br />
► Identifies the catalog in which the catalog record is written or deleted.<br />
► Gives the new, updated, or deleted catalog record.<br />
► Indicates if the entry was renamed and, if so, gives the old and new names of<br />
the entry.<br />
► Identifies the job and the user. If a system task caused the record to be<br />
written, the job name and user identification fields contain blanks and the time<br />
and date fields contain zeros.<br />
3.9.8 SMF record type 67<br />
Record type 67 is written when a <strong>VSAM</strong> catalog entry (a component, cluster,<br />
catalog, alternate index, path, or non-<strong>VSAM</strong> data set) is deleted. A record is<br />
written for each entry affected by the DELETE Access Method Services<br />
command. For example, three records are written for an indexed cluster; one for<br />
the relationship between the components of the cluster, one for the data<br />
component, and one for the index component. The record:<br />
► Identifies the deleted entry.<br />
► Identifies the <strong>VSAM</strong> catalog in which the entry was defined.<br />
► Gives the total logical <strong>VSAM</strong> catalog record.<br />
► Identifies the job and user that caused the record to be written. If it was<br />
caused by a system task the job-name and the user-identification fields<br />
contain blanks and the time and date fields contain zeroes.<br />
3.9.9 SMF record type 68<br />
Record type 68 is written when a <strong>VSAM</strong> catalog entry (a component, cluster,<br />
catalog, alternate index, path, or non-<strong>VSAM</strong> data set) is renamed using the<br />
ALTER Access Method Services command. This record:<br />
► Identifies the <strong>VSAM</strong> catalog in which the object is defined.<br />
► Gives the old and new names for the object.<br />
► Identifies the job and user that renamed the data set. If a system task caused<br />
the record to be written, the job-name and user-identification fields contain<br />
blanks and the time and date fields contain zeros.
3.9.10 SMF record type 69<br />
Record type 69 is written when a <strong>VSAM</strong> data space is defined, extended, or<br />
deleted using the DEFINE or DELETE Access Method Services commands.<br />
Record type 69 is not written when a catalog or a unique data set is defined or<br />
deleted. This record:<br />
► Identifies the catalog in which the data space is defined.<br />
► Identifies the volume on which it is (or was) allocated.<br />
► Gives the number of free data space extents and the amount of unallocated<br />
space on the affected volume after the definition, extension, or deletion.<br />
► Identifies the job and the user that caused the record to be written. If it is<br />
caused by a system task, the job-name and user-identification fields contain<br />
blanks and the time and date fields.<br />
3.9.11 SMF record type 42<br />
This record provides <strong>VSAM</strong> record level sharing (RLS) statistics.<br />
3.10 RRMS and <strong>VSAM</strong><br />
S/390 provides Resource Recovery Management Services (RRMS), comprising:<br />
► Resource Recovery Services (RRS), which provide sync-point services.<br />
► Registration Services, which allow a resource manager to define itself to the<br />
operating system.<br />
► Context services, which allow a resource manager to indicate interest in a<br />
work context. A context represents the resources for a work request; a context<br />
consists of the application program requesting the work and the protected<br />
resources involved in the work. A context represents a business unit of work:<br />
one or more units of recovery with the associated application programs,<br />
resource managers, and protected resources.<br />
RRS is an OS/390 component capable to coordinate Resource Recovery in<br />
MVS.<br />
Resource recovery includes a set of APIs and protocols allowing a transaction<br />
executing an application program to modify consistently multiple protected<br />
resources. The most common is 2-phase commit protocol.<br />
Among these resources, we may have databases, <strong>VSAM</strong> data sets, and any<br />
product specific resource, managed by distinct resource managers. These<br />
resource managers maybe located in different systems.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 199
200 <strong>VSAM</strong> <strong>Demystified</strong><br />
Resource recovery scenarios has three agents:<br />
► Application Program (AP): Requests the changes.<br />
► Resource Manager (RM): Controls the access to the resource, for example,<br />
Data Manager (DB2, DL/I, <strong>VSAM</strong>) and Work Manager (CICS, IMS/DC).<br />
► Synchpoint Manager (SM) guarantees resource recovery by the<br />
implementation of 2-phase commit. RRS is an example of an SM.<br />
When an AP is running the same unit of work (transaction) under CICS and<br />
IMS/DC, it is able to update multiple data located in DB2, DL/I, <strong>VSAM</strong> files. In this<br />
case, there is not a need for RRS, because the SM role is executed by CICS or<br />
IMS/DC through the Commit and Rollback functions.<br />
RRS allows Resource Recovery (2-phase commit) when an unit of work crosses<br />
multiple subsystems (MQSeries®, CICS, IMS) and multiple OS/390 images.<br />
Unit of recovery (UR) is a set of changes that all must be done or none is done. It<br />
guarantees the integrity of the updates.<br />
Two-Phase Commit Protocol aims the execution of an UR, that is, all or nothing.<br />
Has two phases:<br />
► Phase 1:<br />
– App informs the changes to RMs.<br />
– RMs log the old (UNDO) and the new (REDO) data.<br />
– AP asks a commit to Synchpoint Manager.<br />
– Synchpoint Manager asks RMs if they can commit (prepare commit). If all<br />
say “yes”, then Synchpoint Manager hardens the commit in its journal. If<br />
not all say “yes”, the commit is not hardened, and the backout is<br />
commanded at once to the RMs (erase the log) at phase-2.<br />
► Phase 2:<br />
– Synchpoint Manager orders the commit (if hardened) or the backout<br />
(if not hardened) of the changes represented by the UR.<br />
– If all RMs return OK, Synchpoint Manager returns a return code<br />
committed to the AP. If not, then application changes will be made during<br />
restart.<br />
Then, along a 2-phase commit, we may have two functions: commit or backout.<br />
In a pure <strong>VSAM</strong> application guaranteeing the APIs for a 2-phase commit when<br />
you want to implement a unit of recovery, due to updates in multiple <strong>VSAM</strong> data<br />
sets, you will find the RRs to be very helpful.
For more information, refer to OS/390 V2R8.0 MVS Programming: Resource<br />
Recovery, GC28-1739.<br />
Chapter 3. <strong>VSAM</strong> problem determination and recovery 201
202 <strong>VSAM</strong> <strong>Demystified</strong>
4<br />
Chapter 4. Managing your <strong>VSAM</strong> data<br />
sets<br />
In this chapter we provide practical tips related to the daily maintenance of your<br />
<strong>VSAM</strong> data sets:<br />
► Reorganization<br />
► <strong>VSAM</strong> data sharing<br />
► Extended Addressability<br />
► Processing <strong>VSAM</strong> data sets: Media Manager, OPEN, CLOSE<br />
► Record Management: GET, PUT, EOV routine<br />
► <strong>VSAM</strong> using real address above 2 GB<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 203
4.1 Reorganization considerations<br />
4.1.1 CI/CA splits<br />
204 <strong>VSAM</strong> <strong>Demystified</strong><br />
The new DASD storage technology is characterized by:<br />
► Numerous high-capacity, small-size FBA, SCSI/SSA disks<br />
► Redundancy in different types of RAID<br />
► Generous amounts of cache, mainly to avoid the write penalty caused by<br />
RAID<br />
► Plenty of microcode in order to support RAID, cache algorithms, the mapping<br />
between the disks and the logical 3390/3380 volumes (as seen by z/OS), and<br />
in the RVA case, the virtualization of the 3390/3380<br />
Because of that, all the old considerations to avoid long seeks and RPS misses<br />
in a 3390/3380 logical volume are out of date. Does this apply to <strong>VSAM</strong> KSDS<br />
need of reorganization? Let us look at all the performance reasons (old and new)<br />
justifying the <strong>VSAM</strong> reorganization.<br />
Consider CI/CA splits, causing long seeks in the data set — this reason does not<br />
hold true in the new disk controller scenario. Do not reorganize your KSDS or<br />
VRRDS data set to avoid long seeks.<br />
Usually, the worst part of the split is when it occurs. After that, the data set has<br />
more space for insertions and normally the quantity of splits tend to decrease.<br />
Try to avoid splits, if not possible, do not reorganize only because splits occurred.<br />
Monitor the response time and the growing in the number of CA splits. Chances<br />
are that, after reorganization, the number of splits will increase.<br />
4.1.2 The loss of useful space in Data CA<br />
The reasons causing this type of waste are:<br />
► There is no CA reclaim in <strong>VSAM</strong> KSDS/VRRDS for those CAs that became<br />
free before HURBA. Let’s see why in Figure 4-1 on page 205<br />
In the Index set, each CI has only one record. Each record has a pointer to<br />
the highest possible key in an index record in the next lower level, and a<br />
pointer to the beginning of that index record.<br />
The sequence set is the lower level of the index, where the pointers are to<br />
data CI. In the sequence set, each index CI contains only one record. Each<br />
record governs one CA and has pointers to each used data CI, its higher<br />
possible key value (in compressed form) and pointers to free data CI in the<br />
data CA.
Index<br />
Component<br />
H<br />
D<br />
R<br />
Data<br />
Component<br />
Control<br />
Interval<br />
Figure 4-1 Indexes of KSDS<br />
Then, for example, if at load time an specific data CA was loaded with records<br />
belonging to a specific key range and later on the majority of them are deleted<br />
(and not re-utilized, as a timestamp key), the CA is underpopulated, and this<br />
free space is not reclaimed. The free space pointers are in the index<br />
sequence set records, but can be used only by keys in that range.<br />
7 11 14 21 30 38<br />
2 5 7<br />
8 9<br />
HDR 38 67<br />
H<br />
D<br />
R<br />
12 13 14<br />
15 16 19<br />
22 23 26<br />
31 35 38<br />
Control Area<br />
43 50 54 57 64 67<br />
HDR 67 348<br />
H<br />
D<br />
R<br />
39 41 43<br />
44 45 46<br />
51 53 54<br />
55 56 57<br />
58 61 62<br />
65 66 67<br />
HDR 95 348<br />
71 75 78 85 92 95<br />
H<br />
D<br />
R<br />
Sequence<br />
Set<br />
68 69<br />
72 73 74<br />
76 77 78<br />
79 80 85<br />
86 89<br />
93 94 95<br />
Control Area Control Area<br />
Index<br />
Set<br />
How do we measure that? To answer this question, refer to 3.8, “IDCAMS<br />
LISTCAT output fields” on page 187, and the diagram shown in Figure 4-2, as<br />
you follow along with our explanation.<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 205
Type text Type text<br />
Type text Type text<br />
Type text Type text<br />
FR EE FREE<br />
Figure 4-2 HARBA, HURBA, and free space<br />
206 <strong>VSAM</strong> <strong>Demystified</strong><br />
Type text Type text<br />
FREE<br />
Type text<br />
FREE<br />
Type text Type text<br />
FREE<br />
FR EE FREE<br />
CI size = 4k<br />
HARBA = 16 x 4k = 64k<br />
HURBA = 12 x 4k= 48k<br />
HARBA - HURBA = 16k<br />
FREESPACE = 11 x 4k = 44k<br />
44k - 16k = 28k (7 CIs)<br />
28/48 x 100 > > 25%<br />
WHEN TO REORGANIZE<br />
58% > > 25% THEN, REORG<br />
From this diagram showing HARBA, HURBA, and free space, you can see:<br />
The subtraction, HARBA - HURBA = X, gives the amount of free bytes in the<br />
free CIs allocated in the CAs beyond HURBA.<br />
If you subtract FREESPC - X = Y, it gives the amount of free bytes in free CIs<br />
embedded in CAs included in HURBA.<br />
Y includes the CA Freespace%, 25%, for example.<br />
If (Y / HURBA) * 100 is consistently greater than CA Freespace% (25%), and<br />
the number of deleted records (in catalog) is a large figure, it means that it is<br />
time to reorganize due to non-reclaimed CAs.<br />
Here is a numeric example:<br />
HI-A-RBA-------184320000 (HARBA)<br />
HI-U-RBA-------176209920 (HURBA)<br />
FREESPACE-%CA---------10<br />
FREESPC---------89616384<br />
Type text Type text<br />
Type text Type text<br />
FREE<br />
Type text Type text<br />
FR EE FREE<br />
HURBA<br />
HARBA<br />
Type text Type text<br />
FREE<br />
Type text Type text<br />
FREE<br />
Type text Type text<br />
FREE<br />
FR EE FREE
In view of these figures, is it time for a reorganization?<br />
A strong argument to reorganize is the knowledge that those deleted keys are<br />
not going to be inserted again.<br />
► Another reason to reorganize, is when the Index CI size is defined too small<br />
and is not big enough to contain information about all the data CIs in the data<br />
CA. An example is shown in Figure 4-3. In this case the CA is truncated and<br />
the rest is unused. In such a case, you have to redefine the data set with a<br />
larger index CI size.<br />
H<br />
D<br />
R<br />
H<br />
D<br />
R<br />
50 95<br />
8 9 11 12 13 14<br />
15 17 18 20 21 23<br />
25 26 27 28 29 30<br />
31 32 33 35 36 FS<br />
39 40 41 42 43 44<br />
45 46 47 48 49 50<br />
Lost<br />
Space<br />
in CA<br />
H<br />
D<br />
R<br />
14 23 30 37 44 50<br />
F<br />
r<br />
e<br />
e<br />
S<br />
p<br />
a<br />
c<br />
e<br />
57 68 77 83 89 95<br />
51 52 53 54 55 57<br />
58 59 61 65 66 68<br />
72 73 74 75 76 77<br />
78 79 80 81 82 83<br />
84 85 86 87 88 89<br />
90 91 92 93 94 95<br />
Control Information<br />
Free Space<br />
Figure 4-3 Lost space in data CA due to Index CI size too small<br />
H<br />
D<br />
R<br />
Index Record<br />
Sequence<br />
Set<br />
How do we measure that? The only way to distinguish between wasted CAs<br />
due to smaller index CIs or due to deletions is the previous knowledge of the<br />
deletions. Then:<br />
– If (Y / HURBA) * 100 is consistently greater than CA Freespace% and the<br />
number of deleted records in the catalog is a small figure, it is time to<br />
reorganize, due to the small size of the index CIs. The index CI size must<br />
be re-specified as a larger value.<br />
– DFSMShsm issues message ARC0909E advising that is time to<br />
reorganize the <strong>VSAM</strong> data set, due to a free space threshold being<br />
reached.<br />
Index<br />
Set<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 207
208 <strong>VSAM</strong> <strong>Demystified</strong><br />
► In z/OS V1 R3, <strong>VSAM</strong> changed the algorithm to calculate the KSDS and<br />
VRRDS index component minimum CI size, when the Index CI size is not<br />
informed in DEFINE command. The higher key value in a data CI is stored in<br />
compressed format in the Index CI record. The previous algorithm assumed<br />
that, after compression, the keys would reduce the size of keys to<br />
approximately 5 bytes. With this assumption, for data sets with large keys, the<br />
index CI records are bigger and the Index CI size may not be enough to point<br />
all Data CIs in a Data CA. In such case, the Data CA is under utilized. Since<br />
z/OS V1 R3, <strong>VSAM</strong> assumes that keys have a compression rate 3:1. Then,<br />
for example, a key with 21 bytes, after compression has 7 bytes, and so on.<br />
For those data sets defined before z/OS V1 R3 and having large keys, you<br />
can have data CA under utilized. How do you find these data sets? IBM<br />
supplied a tool to help migration to z/OS V1 R3. This IBM tool searches the<br />
catalog information for those data sets whose mask is passed in SYSIN DD<br />
statement and reports, by data set name, the current index CI size and the<br />
new index CI size according to new algorithm.<br />
For more information about changes in the index CI size calculation, refer to<br />
“New Index CI size calculation algorithm” on page 208.<br />
4.1.3 CI/CA splits causing free space increase<br />
After CI and or CA splits the free space per CI (excluding the totally freed) tends<br />
to increase. In sequential read processing there is some impact on performance<br />
because more free bytes are moved to storage. Refer to 2.7.4, “I/O service time<br />
(connect) for <strong>VSAM</strong> data sets” on page 129.<br />
How do we measure that? By the number of CI and CA splits in the catalog,<br />
together with the free space information.<br />
A general comment about CI/CA splits is that their number usually grows steady,<br />
after reorganization. But do not be surprised if, after reorganization, the number<br />
of splits increases. It means that before reorganization, the data set had better<br />
CI/CA space for insertions.<br />
4.2 New Index CI size calculation algorithm<br />
Use your automation console function to detect the message in Figure 4-4,<br />
generating an alert.
IDC3351I ** <strong>VSAM</strong> I/O RETURN CODE IS 212<br />
Unable to split index; increase index CI size<br />
Figure 4-4 Message due to index CI size too small<br />
After that, carefully read this topic.<br />
<strong>VSAM</strong> uses a default minimum value for index CI size, if it determines that the<br />
one specified by you is not large enough. The algorithm that calculates this value<br />
was changed in z/OS V1 R3.<br />
This change was to increase the likelihood that the index CI would be large<br />
enough to hold all the keys that can exist in a data CA. In a number of situations<br />
the default value calculated was not large enough. Because of this, there was a<br />
lot of space wasted in the <strong>VSAM</strong> data set that cannot be used. Also, this forced<br />
unnecessary increase in index levels and impacted the performance.<br />
As you know, <strong>VSAM</strong> compresses the key value when stored the key in the index<br />
record. The previous algorithm for determining the minimum size always<br />
assumed that all data keys compressed to 5 bytes; in reality they were often<br />
much larger. The new algorithm assumes a 3:1 compression of the keys, for<br />
example that 45-byte keys compress to 15 bytes in the index record. So the<br />
newly computed CI sizes will be higher.<br />
This change does not bring impact on existing data sets. But the new default<br />
value is used for any new <strong>VSAM</strong> data set created under z/OS 1.3 or higher. This<br />
also applies to any data sets created because of backup-restore or migrate-recall<br />
operations.<br />
The main implication of this change is for applications that open data sets in LSR<br />
mode. <strong>VSAM</strong> data sets opened in LSR mode, might fail with IEC161I 120-053, if<br />
the buffer pool created by BLDVRP macro is not large enough to contain the<br />
increased CI sizes.<br />
CICS and IMS open <strong>VSAM</strong> data sets in LSR mode. You may need to review<br />
LSRPOOL definition for CICS and DFS<strong>VSAM</strong>P definition for IMS. Both CICS and<br />
IMS use these definitions to determine the size of the buffer pool to be created by<br />
BLDVRP. This could lead to database open failures or poor performance.<br />
If you are using <strong>VSAM</strong> RLS, there is not such issue because in RLS, SMS<strong>VSAM</strong><br />
builds it's own pools for data sets.<br />
If you are letting CICS calculate the number of buffers in your LSR buffer pools,<br />
then you should have no problem. If you are explicitly coding the number of<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 209
210 <strong>VSAM</strong> <strong>Demystified</strong><br />
buffers of each size in the LSRPOOL then you should review the number of<br />
buffers you specify.<br />
4.2.1 Analyze existing data sets<br />
You need to analyze your <strong>VSAM</strong> data sets and compare the current index CI size<br />
with the new value computed by z/OS V1 R3. We recommend you specify CI<br />
sizes for both index and data components of your <strong>VSAM</strong> data sets and compute<br />
the new value for the index CI size. If you do not do it, the index CI size of your<br />
<strong>VSAM</strong> data sets will change to the new value when they get redefined.<br />
Sample program to identify LSR mode data sets<br />
You need to identify all applications that open <strong>VSAM</strong> data sets in LSR mode and<br />
review the possibility of change in index CI size. To identify data sets opened in<br />
LSR mode, you can use the SMF 62 and 64 records. The fields SMF62MC3 and<br />
SMF64MC3 hold a one byte value. If the byte is in the format B'x1xxxxxx' then<br />
this indicates the data set was opened or closed in LSR mode. These records<br />
also include the data set name and jobname. You may also use the sample code<br />
In the “SMFLSR sample program” on page 380, to generate a list of data sets<br />
opened in LSR mode.<br />
IBM CI sizer tool<br />
IBM provides a tool to analyze your existing <strong>VSAM</strong> data sets. This tool gives a<br />
report showing:<br />
► Data set name<br />
► Current index CI size<br />
► Minimum (default) index CI size<br />
► Data CI size<br />
► Data set creation date<br />
See Figure 4-5 for a sample output of this tool.
LISTING FOR FILTER KEY: U705040.**<br />
DATA SET NAME CURRENT PRE-1.3 1.3+<br />
DATA CI CREDT<br />
U705040.DDIR 512 512 2560<br />
18432 2001.114<br />
U705040.INFI.SDIDS 2560 2560 3072<br />
2048 1989.278<br />
U705040.INFO420.SDIDS 4096 4096 5120<br />
1024 1991.260<br />
THE NUMBER OF ENTRIES PROCESSED WAS:<br />
TOTAL CLUSTERS: 24<br />
TOTAL AIX: 0<br />
KSDS PROCESSED: 20<br />
INDEX CISIZE CHANGE: 3<br />
SKIPPED DUE TO ERRORS: 0<br />
SKIPPED (OFFLINE): 0<br />
SKIPPED DUE TO FIELDS: 0<br />
Figure 4-5 Sample output of the CISIZE tool<br />
The tool name is INDXCISZ and can be downloaded to your MVS system from<br />
IBM FTP site as follows:<br />
► Allocate a data set with LRECL=1024,BLKSIZE=6144,RECFM=FB,<br />
DSORG=PS and RECFM=FB.<br />
► Enter the TSO ftp command.<br />
► At the Connect to? prompt, enter: ftp.software.ibm.com<br />
► At the NAME prompt, enter: anonymous<br />
► At the PASSWORD prompt, enter your e-mail address.<br />
► At the Command prompt, enter: cd s390/mvs/tools<br />
► At the Command prompt, enter: binary<br />
► At the Command prompt, enter: get INDXCISZ.JCL.TRSD 'your data set’<br />
► Once the file is placed on your MVS system, you need to unterse it.<br />
► You need to use TRSMAIN program to unterse the file.<br />
► The TRSMAIN program can be downloaded from:<br />
http://techsupport.services.ibm.com/390/trsmain.html<br />
You can also download it using a batch job. For a sample job to download the tool<br />
and unterse it, see Figure 4-6.<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 211
212 <strong>VSAM</strong> <strong>Demystified</strong><br />
//MHLRES1E JOB (999,POK),MSGLEVEL=1,NOTIFY=MHLRES1<br />
//ALLOC EXEC PGM=IEFBR14<br />
//SYSPRINT DD SYSOUT=(*)<br />
//DD1T DD DISP=(NEW,CATLG,KEEP),SPACE=(CYL,(2,1),RLSE),<br />
// DCB=(LRECL=1024,BLKSIZE=6144,RECFM=FB),UNIT=SYSDA,<br />
// DSORG=PS,<br />
// DSN=MHLRES1.INDXCISZ.TERSED<br />
//DD1U DD DISP=(NEW,CATLG,KEEP),SPACE=(CYL,(2,1),RLSE),UNIT=SYSDA,<br />
// DSORG=PS,<br />
// DSN=MHLRES1.INDXCISZ<br />
//FTP EXEC PGM=FTP,REGION=4096K,<br />
// PARM='FTP.SOFTWARE.IBM.COM (TIMEOUT 720 EXIT'<br />
//SYSMDUMP DD SYSOUT=*<br />
//SYSPRINT DD SYSOUT=*<br />
//INPUT DD *<br />
ANONYMOUS<br />
xxxx@yyy.zzz.com<br />
binary<br />
CD /s390/mvs/tools/<br />
dir<br />
binary<br />
get INDXCISZ.JCL.TRSD 'MHLRES1.INDXCISZ.TERSED' (replac<br />
quit<br />
/*<br />
//TRSMAIN EXEC PGM=TRSMAIN,PARM='UNPACK',TIME=1440<br />
//SYSPRINT DD SYSOUT=*<br />
//SYSIN DD DUMMY<br />
//INFILE DD DISP=SHR,DSN=MHLRES1.INDXCISZ.TERSED<br />
//OUTFILE DD DISP=SHR,DSN=MHLRES1.INDXCISZ<br />
Figure 4-6 Job to download the CISIZE tool<br />
The untersed file contains instructions for link editing and executing the tool. It<br />
will tell you the current CI size and recommended CI size for your selected <strong>VSAM</strong><br />
data sets.<br />
4.3 Sharing <strong>VSAM</strong> data sets<br />
In this section we discuss the sharing of <strong>VSAM</strong> data sets from one address<br />
space throughout a Parallel Sysplex® and what that it implies, such as level of<br />
data integrity, MVS enqueues, <strong>VSAM</strong> mechanisms to protect data integrity, and<br />
SHAREOPTIONS.<br />
To protect the integrity of your <strong>VSAM</strong> data sets, <strong>VSAM</strong> uses internal locks and<br />
issues ENQs in SYS<strong>VSAM</strong> major name, which invokes the MVS Enqueue
Manager routine to serialize the resource locally. To serialize the full cluster<br />
across systems, it is required to have the Global Resource Serialization (GRS) or<br />
an equivalent product with the caution of not placing SYS<strong>VSAM</strong> resource name<br />
in RNL exclusion list.<br />
Some of the consequences of placing SYS<strong>VSAM</strong> in the exclusion list include:<br />
loss of records, overlaid records, duplicate records, invalid index structures,<br />
invalid catalog records, invalid data set dumps, backups, restores, or migrations,<br />
incorrect extends of the data set, and incorrect release of space in the data set.<br />
The major name SYS<strong>VSAM</strong> is used to serialize lots of resources in <strong>VSAM</strong>, Here<br />
are some examples:<br />
► Enforce <strong>VSAM</strong> SHAREOPTIONS.<br />
– <strong>VSAM</strong> no longer determines whether any user has a data set open on<br />
other systems.<br />
► Serialize OPENS, CLOSES, or EOVs.<br />
– Multiple OPENS, CLOSES, or EOV requests can now occur at the same<br />
time on multiple systems.<br />
– Multiple extends of a data set can now occur on multiple systems.<br />
► Serialize dynamic string addition.<br />
– It is no longer possible to serialize dynamic string additions with other<br />
dynamic string additions and with OPEN/CLOSE/EOV.<br />
► Serialize catalog updates.<br />
– A user can no longer determine if the data set is open on another system<br />
so that the catalog can be correctly updated.<br />
– Users cannot correctly serialize catalog updates of data set compression<br />
tokens.<br />
► You cannot correctly determine the status of a data set for DELETE and<br />
RENAME processing.<br />
► HSM cannot correctly serialize migrations with <strong>VSAM</strong> OPEN/CLOSE/EOV.<br />
► Serialize DFDSS dump/restores. DSS cannot correctly serialize<br />
DUMP/BACKUP/RESTORE with <strong>VSAM</strong> OPEN/CLOSE/EOV.<br />
► Partial release. <strong>VSAM</strong> CLOSE cannot determine when the last user for a data<br />
set is closing the data set in order to correctly implement PARTIAL RELEASE.<br />
► Recognize close failures in order to warn the user.<br />
– <strong>VSAM</strong> OPEN cannot determine whether the data set was improperly<br />
closed.<br />
– May not warn users of a close failure.<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 213
214 <strong>VSAM</strong> <strong>Demystified</strong><br />
– May not attempt to determine correct end of the data set.<br />
► Support <strong>VSAM</strong> Record Level Sharing (RLS). Unable to enforce RLS/non-RLS<br />
sharing rules.<br />
Returning to sharing, you can share <strong>VSAM</strong> data sets between:<br />
► Many task programs running in different address spaces, in a single operating<br />
system. Some tasks may be running the same program, accessing the same<br />
<strong>VSAM</strong> data set. For example, data set Teka in Figure 4-7.<br />
► Many task programs running in the same address space. Multiples ACBs<br />
pointing to same <strong>VSAM</strong> data set, like data set Tita, in Figure 4-7.<br />
► One ACB shared in a task or different subtasks, in the same address space,<br />
as an example, with multistring processing.<br />
► Different tasks in different z/OS images. As an example, data set Prica in<br />
Figure 4-7.<br />
SYSA SYSB<br />
OPEN ACB1<br />
OPEN ACB2<br />
OPEN ACB3<br />
//ACB1 DD DSN=TITA,DISP=SHR<br />
//ACB2 DD DSN=NINA,<br />
// DISP=SHR,RLS=CR<br />
//ACB3 DD DSN=TITA,DISP=SHR<br />
JOB 1<br />
CICS A<br />
OPEN ACB4<br />
ACB4 MACR=GSR<br />
OPEN ACB11<br />
//ACB4 DD DSN=TEKA,DISP=SHR<br />
//ACB11 DD DSN=PRICA,<br />
// DISP=SHR<br />
JOB 2<br />
OPEN ACB5<br />
OPEN ACB6<br />
ACB6 MACRF=GSR<br />
//ACB5 DD DSN=NINA,<br />
// DISP=SHR,RLS=CR<br />
//ACB6 DD DSN=TEKA,DISP=SHR<br />
coupling<br />
Facility<br />
TITA<br />
NINA<br />
TEKA<br />
PRICA<br />
Figure 4-7 Sharing <strong>VSAM</strong> data sets in the Parallel Sysplex<br />
CICS B<br />
OPEN ACB7<br />
OPEN ACB8<br />
ACB8 MACRF=GSR<br />
//ACB7 DD DSN=NINA,<br />
// DISP=SHR,RLS=CR<br />
//ACB8 DD DSN=NINA,DISP=SHR<br />
JOB 3<br />
OPEN ACB9<br />
OPEN ACB10<br />
//ACB9 DD DSN=NINA,<br />
// DISP=SHR,RLS=CR<br />
//ACB10 DD DSN=PRICA,<br />
// DISP=SHR<br />
The Enqueue Manager is an MVS component. It does not care about the nature<br />
of the resource but only about its symbolic name, that is formed by its Major (also<br />
known as Qname) and Minor name (Rname). The serialization is done in the<br />
resource symbolic name and the type of serialization indicates the protection of<br />
the resource:
► When SHARED, any other shared access is permitted and any exclusive<br />
access is denied or queued until the resource becomes available.<br />
► When EXCLUSIVE, the Enqueue Manager guarantees only the task owning<br />
the resource can use it. Any other request to the same resource, no matter if<br />
it is exclusive or shared, it is denied.<br />
The scope of the enqueue indicates if the resource is serialized at address space<br />
level (scope STEP), at system image level (scope SYSTEM) or sysplex wide<br />
(scope SYSTEMS), which implies GRS.<br />
Before you define the level of sharing for a <strong>VSAM</strong> data set, you must evaluate the<br />
consequences of reading incorrect data (a loss of read integrity) and writing<br />
incorrect data (a loss of write integrity). These are situations that can result when<br />
one or more of the data set's users do not adhere to guidelines recommended for<br />
accessing shared data sets. On the other hand, it is important to avoid the<br />
unnecessary use of certain serialization functions which may cause a<br />
performance degradation.<br />
4.3.1 Write and read integrity<br />
When you share a <strong>VSAM</strong> data set in the same task program, or among task<br />
programs running in same or different address spaces, from the same or different<br />
z/OS images, there is a need to inform what type of integrity (read and/or write) is<br />
required.<br />
Write integrity<br />
Write I/O operation should guarantee integrity for non-atomic writes (the writes<br />
executed in multiple I/O operations), for example:<br />
► Logical record update in-place, where a record is read, updated in memory<br />
and written back<br />
► CI index updates due to CI data insertions and deletions (KSDS/VRRDS)<br />
► CI and CA splits, which involves several write I/O operations<br />
► Data set and catalog (usually VVDS) synchronous updates<br />
► Debit and credit writes program<br />
To have write integrity, when several tasks are accessing the same data set,<br />
<strong>VSAM</strong> (and you) must guarantee that all the non-atomic writes are executed<br />
without being pre-empted. This means that no other related intervening write I/O<br />
operation should be executed.<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 215
216 <strong>VSAM</strong> <strong>Demystified</strong><br />
Read integrity<br />
Read integrity guarantees that the record you read is the most current copy<br />
available. It implies:<br />
► Within non atomic writes, the related read I/O operation is suspended.<br />
► The read I/O operation is able to find the most current copy of the logical<br />
record, meaning:<br />
– If the data is in the buffer pool, <strong>VSAM</strong> must guarantee the most current<br />
copy to satisfy the read (also called buffer pool coherency). In a shared<br />
environment with different z/OS images accessing the data set, there are<br />
two ways of doing this: through Parallel Sysplex RLS cross invalidation or<br />
by <strong>VSAM</strong> refreshing the buffer at every read request (specified with<br />
SHAREOPTION 4 which we discuss later).<br />
– The write operation must send the current copy to where the next read can<br />
access it, even in a multiple z/OS image system (to shared DASD or with<br />
Parallel Sysplex RLS, to the coupling facility).<br />
4.3.2 <strong>VSAM</strong> sharing mechanisms<br />
Before talking about the sharing mechanisms, let us introduce the concept of the<br />
<strong>VSAM</strong> control block structure.<br />
The <strong>VSAM</strong> control block structure is formed by the input/output buffers and a set<br />
of <strong>VSAM</strong> control blocks, created at open time, that holds informations related to<br />
the data set being opened, like space available, type of <strong>VSAM</strong> data set, buffering<br />
technique, and so on. The control block structure is deleted when the last close<br />
of the data set is issued on this system.<br />
A <strong>VSAM</strong> control block structure can be shared by more than one OPEN of the<br />
same <strong>VSAM</strong> data set. To be shared, the structure must be compatible and<br />
accessible.<br />
To understand the meaning of compatible, let’s see what happens when a <strong>VSAM</strong><br />
data set is opened. To open a <strong>VSAM</strong> data set, an ACB is used and some<br />
information about the ACB goes to the <strong>VSAM</strong> control block structure. For a new<br />
ACB to use an existing <strong>VSAM</strong> control block structure, the new ACB must be<br />
compatible with the existing control block structure. That means it must be<br />
consistent in its specification of the following processing options:<br />
► Data set specifications: For example, a <strong>VSAM</strong> control block structure created<br />
when opening an index of a KSDS data set as an ESDS is not consistent with<br />
a control block structure as when opening a KSDS data set such as a KSDS.<br />
► The ACB MACRF options: DFR, UBF, ICI, CBIC, LSR, and GSR must be<br />
consistent.
For more information about ACB, refer to “ACB control block” on page 235.<br />
Now, let us see how a <strong>VSAM</strong> control block structure can be accessible. To access<br />
a <strong>VSAM</strong> control block structure depends on it is located:<br />
► When using NSR or LSR, the <strong>VSAM</strong> control block structure is located in the<br />
address space private area and can be accessed by tasks running programs<br />
in the same address space.<br />
► For GSR, the <strong>VSAM</strong> control block structure is located is Common Storage<br />
Area (CSA) and can be accessed by task running programs in other address<br />
spaces in the same system image.<br />
For more information about NSR, LSR, GSR and RLS refer to Chapter 4,<br />
“Managing your <strong>VSAM</strong> data sets” on page 203.<br />
At open time, before creating a control block structure, <strong>VSAM</strong> verifies if already<br />
an accessible and compatible <strong>VSAM</strong> control block structure of the data set exists:<br />
► If so <strong>VSAM</strong> uses the same control block structure and the serialization to<br />
guarantee data integrity in done at CI level.<br />
► If one does not exist, <strong>VSAM</strong> creates the control block structure for the data<br />
set. Also <strong>VSAM</strong> uses the SHAREOPTIONS value to determine the level of<br />
data set sharing to implement protection through enqueue (ENQ) in<br />
SYS<strong>VSAM</strong>.<br />
► If it already exists in the Parallel Sysplex, it is not compatible or not<br />
accessible, <strong>VSAM</strong> use the SHAREOPTIONS value to determine whether<br />
creating a new control block structure would violate the SHAREOPTIONS<br />
rules. If so, the OPEN fails, otherwise the OPEN is successful.<br />
<strong>VSAM</strong> verifies if a control block structure exists in the Parallel Sysplex testing<br />
enqueue in SYS<strong>VSAM</strong> to resources representing input and output control blocks<br />
<strong>VSAM</strong> data set components.<br />
<strong>VSAM</strong> uses two basic implementations to control data sharing:<br />
► <strong>VSAM</strong> lock mechanism controls data sharing in a single control block<br />
structure. <strong>VSAM</strong> has two lock mechanisms according to the mode being<br />
used: RLS and non-RLS.<br />
► Enqueue in SYS<strong>VSAM</strong> name, issued by <strong>VSAM</strong>, for resources representing<br />
input and output <strong>VSAM</strong> control blocks for the data set components, based on<br />
data set SHAREOPTIONS.<br />
The <strong>VSAM</strong> control block structure plays a decisive role in <strong>VSAM</strong> data sharing.<br />
When the sharing of a <strong>VSAM</strong> data set is done using a single and only <strong>VSAM</strong><br />
control block structure, <strong>VSAM</strong> guarantees read and write integrity at CI level,<br />
independent of the SHAREOPTIONS or DISP specifications.<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 217
218 <strong>VSAM</strong> <strong>Demystified</strong><br />
When the data set is accessed throughout different <strong>VSAM</strong> control block<br />
structures at the same time, <strong>VSAM</strong> cannot ensure who has exclusive use of the<br />
data because the control block structure is not the same. In this case <strong>VSAM</strong><br />
applies SHAREOPTIONS rules, serializing at data set component level.<br />
When the SHAREOPTIONS being used do not protect the data set, the user<br />
application programs must provide data set integrity by the use of ENQUEUE or<br />
RESERVE macros.<br />
There are five important ways to implement <strong>VSAM</strong> data set integrity according to<br />
how the data set is shared:<br />
► Internal locks for non-RLS access, when using a single <strong>VSAM</strong> control block<br />
structure.<br />
► Global lock for RLS access, a very sophisticated mechanism using the<br />
coupling facility. RLS can be used when sharing a data set throughout the<br />
Parallel Sysplex. SHAREOPTIONS does not apply to <strong>VSAM</strong> data sets in RLS<br />
mode because it uses a single control block structure through the sysplex.<br />
About sharing <strong>VSAM</strong> data sets in RLS mode refer to Chapter 5, “<strong>VSAM</strong><br />
Record Level Sharing” on page 243.<br />
► SYS<strong>VSAM</strong> ENQ issued by <strong>VSAM</strong>, according to the data set<br />
SHAREOPTIONS, for non-RLS access having multiple <strong>VSAM</strong> control block<br />
structures.<br />
► The ENQ serialization function issued by the data set allocation routine,<br />
according to data set disposition informed. The Qname is SYSDSN and the<br />
Rname is the data set name. The scope of the serialization is sysplex wide<br />
and the resource Status is shared for SHR data set disposition and exclusive<br />
for NEW, OLD or MOD disposition.<br />
► The ENQ serialization function can also be implemented by the user<br />
application program.<br />
4.3.3 Sharing data in a single <strong>VSAM</strong> control block structure<br />
When the sharing of a <strong>VSAM</strong> data set is done using a single and only <strong>VSAM</strong><br />
control block structure throughout the Parallel Sysplex, <strong>VSAM</strong> guarantees read<br />
and write integrity independent of the SHAREOPTIONS or JCL DISP<br />
specifications.<br />
Table 4-1 presents the way you can implement <strong>VSAM</strong> data sharing with read and<br />
write integrity in the Parallel Sysplex.
Table 4-1 One <strong>VSAM</strong> Control Block Structure<br />
Buffering Technique One Control Block structure in the Parallel Sysplex<br />
NSR/LSR All OPENs to data set issued in the same address space<br />
GSR All OPENs to data set issued in the same system image<br />
RLS Anywhere<br />
With NSR or LSR, many jobs concurrently OPEN to same data set can use only<br />
one <strong>VSAM</strong> control block structure, since issued by task(s) in the same address<br />
space.<br />
The ability to perform multiple OPENs to the same data set within a task or from<br />
different tasks in a single address space sharing a single <strong>VSAM</strong> control block<br />
structure is called inter-address space sharing, also referred as subtask sharing.<br />
Subtask sharing allows many logical views of the data set while maintaining a<br />
single <strong>VSAM</strong> control block structure. With a single control block structure, you<br />
can ensure that you have exclusive control of the buffer when updating a CI. An<br />
example of the use of single <strong>VSAM</strong> control block structure is in Figure 4-7 on<br />
page 214, the data set “Tita”, in CICS-A, is accessed by ACB1 and ACB3, both<br />
pointing to same data set.<br />
When using GSR, the same <strong>VSAM</strong> control block structure can be used by<br />
address spaces in the same system image, because the structure is in the CSA. In<br />
Figure 4-7 on page 214, JOB 1 and JOB 2 are using GSR in the same system<br />
image, accessing the same data set. They are using the same <strong>VSAM</strong> control<br />
block structure for access the data set “Teka”, that is the only <strong>VSAM</strong> control block<br />
structure in the Parallel Sysplex. Before using GSR, refer to “Global Shared<br />
Resources (GSR)” on page 80, for its disadvantages. We strongly recommend<br />
you to use RLS instead of GSR.<br />
Let us see how <strong>VSAM</strong> guarantees read and write integrity, in multiple string<br />
processing. In this processing environment there can be multiple independent<br />
and concurrently requests (RPLs) for the same data set, using a single <strong>VSAM</strong><br />
control block structure:<br />
► When your program issues a GET nonupdate request, <strong>VSAM</strong> first tries to<br />
locate the control interval in buffers attached to its string and obtain a copy of<br />
the CI (with NSR) or shares the same copy in the buffer (LSR). If <strong>VSAM</strong> does<br />
not find in buffers, it reads the control interval from DASD.<br />
► For GET update requests, the CI is obtained in exclusive control, through<br />
<strong>VSAM</strong> lock mechanism, and then read the control interval from the device for<br />
the latest copy of the data. If the buffer is already in exclusive control of<br />
another string, the request fails with an exclusive control feedback code. The<br />
rules for exclusive control are:<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 219
220 <strong>VSAM</strong> <strong>Demystified</strong><br />
a. If a given string obtains a record with a GET for update request, the control<br />
interval is not available for update or insert processing by another string.<br />
b. If a given string is in the process of a control area split caused by an<br />
update with length change or an insert, that string obtains exclusive<br />
control of the entire control area being split. Other strings cannot process<br />
insert or update requests against this control area until the split is<br />
complete.<br />
An exclusive control conflict happens when a request is made for a resource that<br />
is in exclusive control of an other request. <strong>VSAM</strong> treats in two different ways,<br />
according buffering mode being used:<br />
► With LSR or GSR, <strong>VSAM</strong> handles the request according to the information in<br />
the MACRF parameter in ACB:<br />
– LEW: The request is queued, placing the requiring task in wait until the<br />
resource become available. This is the default.<br />
– NLW: <strong>VSAM</strong> returns exclusive control error return code X’14’ to the<br />
application program, then the application program is able to determine the<br />
next action.<br />
► With NSR, <strong>VSAM</strong> does not queue requests that have exclusive control<br />
conflicts. <strong>VSAM</strong> returns a logical error return code, and you must stop activity<br />
and clear the conflict. If the RPL that caused the conflict had exclusive control<br />
of a control interval from a previous request, the application program issue an<br />
ENDREQ before attempting to clear the conflict and avoid a dead lock. The<br />
Conflict can be solved in one of three ways, at application program level:<br />
a. Queue until the RPL holding exclusive control of the control interval<br />
releases that control and then reissue the request.<br />
b. For Assembler language, issue an ENDREQ against the RPL holding<br />
exclusive control to force it to release control immediately.<br />
c. When using LSR and Assembler source program, release the buffer<br />
issuing MRKBFR MARK=RLS.<br />
If the RPL includes MSGAREA and MSGLEN, the address of the RPL holding<br />
exclusive control is provided in the first word of the MSGAREA. The RPL field,<br />
RPLDDDD, contains the RBA of the requested control interval.<br />
Sometimes this locking in a CI basis done by <strong>VSAM</strong> may cause contention and<br />
even deadlocks. There are no deadlock detection and prevention algorithms<br />
implemented in <strong>VSAM</strong>, except in an RLS environment. If you are facing these<br />
drawbacks a recommendation is to have less logical records in a data control<br />
interval, or in other words to have better lock granularity.
Using a single <strong>VSAM</strong> control block structure<br />
The three methods of achieving a single <strong>VSAM</strong> control block structure for a<br />
<strong>VSAM</strong> data set while processing multiple concurrent requests are:<br />
1. A single access method control block (ACB) and a STRNO>1. Refer to z/OS<br />
DFSMS Using Data Sets, SC26-7410, to get more information about STRNO.<br />
2. DD name sharing: When multiple ACBs, all and located in the same address<br />
space, pointing to a single DD statement. You have this when multiple tasks,<br />
in the same address space, are executing the same program concurrently or<br />
as in the example below, in assembler language, multiple tasks executing<br />
different programs, but pointing to same DD:<br />
Example 4-1 DD name sharing pointing to a single DD statement<br />
JCL:<br />
//DD1 DD DSN=ABC<br />
task A executing PGM1:<br />
PGM1: OPEN ACB1<br />
ACB1 ACB DDNAME=DD1<br />
task B executing PGM2:<br />
PGM2: OPEN ACB2<br />
ACB2 ACB DDNAME=DD1<br />
3. Data set name sharing, with multiple ACBs pointing to multiple DD statements<br />
with different DDnames, but with the same DSname. The data set names are<br />
related with an ACB open specification (MACRF=DSN). This MACRF option<br />
means that subtask shared control block connection is based on common<br />
data set names. For example:<br />
Example 4-2 DD name sharing with different DD names<br />
JCL:<br />
//DD1 DD DSN=ABC<br />
//DD2 DD DSN=ABC<br />
task A executing PGM1:<br />
PGM1: OPEN ACB1<br />
ACB1 ACB DDNAME=DD1,MACRF=DSN<br />
task B executing PGM2:<br />
PGM2: OPEN ACB2<br />
ACB2 ACB DDNAME=DD2,MACRF=DSN<br />
Now, talking about data sets with AIX, <strong>VSAM</strong> connects an ACB to an existing<br />
<strong>VSAM</strong> control block structure for data set name sharing only when the base of<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 221
222 <strong>VSAM</strong> <strong>Demystified</strong><br />
the sphere is the same for both ACBs. In Example 4-3, supposing no <strong>VSAM</strong><br />
block structures exist:<br />
► When task A issues OPEN to the cluster, <strong>VSAM</strong> creates block structure for<br />
the cluster and for the alternate index. <strong>VSAM</strong> knows by the catalog the name<br />
of the AIX.<br />
► When task B issues OPEN to the PATH, <strong>VSAM</strong> adds to existing structure for<br />
the cluster and the alternate index, because the base of the sphere is the<br />
same, the cluster.<br />
► When task C issues OPEN to the alternate index, <strong>VSAM</strong> creates new control<br />
block structure for the alternate index. <strong>VSAM</strong> does not add to existing<br />
structure as the base of the sphere is not the same. SHAREOPTIONS are<br />
enforced for AIX_A data set name since multiple control block structures exist.<br />
Example 4-3 Two <strong>VSAM</strong> control blocks structure to same data set<br />
JCL:<br />
//DD1 DD DSN=CLUSTER_A<br />
//DD2 DD DSN=PATH CONNECTING AIX_A TO CLUSTER_A<br />
//DD3 DD DSN=AIX_A<br />
task A executing PGM1:<br />
PGM1: OPEN ACB1<br />
ACB1 ACB DDNAME=DD1,MACRF=DSN<br />
task B executing PGM2:<br />
PGM2: OPEN ACB2<br />
ACB2 ACB DDNAME=DD2,MACRF=DSN<br />
task C executing PGM3:<br />
PGM3: OPEN ACB3<br />
ACB3 ACB DDNAME=DD3,MACRF=DSN<br />
To a new ACB use an existing <strong>VSAM</strong> control block structure, the new ACB must<br />
be compatible with the existing control block structure, if compatibility cannot be<br />
established, OPEN tries (within the limitations of the share options specified<br />
when the data set was defined) to build a new control block structure. If it cannot,<br />
OPEN fails.<br />
When implementing intra-address space sharing, it is necessary that when<br />
attaching new subtasks, the subpool zero must be shared by mother and<br />
daughter tasks in order to shared the RP control blocks (SZERO=YES in the<br />
ATTACH macro).<br />
A subtask has an opened ACB which shares a control block structure that can<br />
have been previously used. If this subtask now issues the POINT macro to obtain
the position for the data set, it should not be assumed that positioning is at the<br />
beginning of the data set, as in a more normal situation.<br />
When <strong>VSAM</strong> can not use an existing control block structure for a data set, <strong>VSAM</strong><br />
uses the SHAREOPTIONS. Refer to “<strong>VSAM</strong> SHAREOPTIONS” on page 223.<br />
4.3.4 Sharing data with many <strong>VSAM</strong> control block structures<br />
In this section we discuss about sharing data sets throughout the Parallel<br />
Sysplex when more than one <strong>VSAM</strong> control block structure can exist. This<br />
happens when an OPEN to a data set cannot use an existing <strong>VSAM</strong> control block<br />
structure.<br />
<strong>VSAM</strong> SHAREOPTIONS<br />
<strong>VSAM</strong> SHAREOPTIONS play an important role in <strong>VSAM</strong> integrity. They specify<br />
whether and to what extent data is to be shared among tasks in one or multiple<br />
z/OS task programs the Parallel Sysplex. When you define <strong>VSAM</strong> data sets, you<br />
specify how the data is to be shared through the use of SHAREOPTIONS<br />
parameter of DEFINE command.<br />
The share options are specified as SHAREOPTIONS(x,y). Improperly stated, x and<br />
y are referred as cross-region and cross-system, respectively. However, share<br />
options are sysplex wide. We keep using the names cross-region, cross-system<br />
to avoid confusion, but keep in mind that they do not mean that.<br />
The sharing is controlled throughout <strong>VSAM</strong> control block structures. <strong>VSAM</strong> uses<br />
the SHAREOPTIONS values to determine whether creating a new control block<br />
structure would violate the SHAREOPTIONS rules. If so, the OPEN fails,<br />
otherwise the OPEN is successful.<br />
<strong>VSAM</strong> uses enqueue to implement the level of sharing requested in<br />
SHAREOPTIONS, when creating a new control block structure at OPEN time.<br />
<strong>VSAM</strong> issues enqueues to the major name SYS<strong>VSAM</strong>.<br />
When a cluster has an alternate index:<br />
► If the data set opened is the path or the cluster, <strong>VSAM</strong> creates control block<br />
structure for:<br />
– The cluster components. For example, if the data set is KSDS, <strong>VSAM</strong><br />
creates control block structure for the data and for the index component.<br />
– The alternate index components.<br />
► If the data set opened is the alternate index, <strong>VSAM</strong> issues enqueue only to<br />
the alternate index components (for example, data and index).<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 223
224 <strong>VSAM</strong> <strong>Demystified</strong><br />
For each <strong>VSAM</strong> control block structure created, <strong>VSAM</strong> issue enqueue to<br />
enforce SHAREOPTIONS.<br />
When the <strong>VSAM</strong> data set is empty and is being open for OUTPUT, no matter the<br />
SHAREOPTIONS, only one <strong>VSAM</strong> OUTPUT control block structure can exist<br />
throughout the Parallel Sysplex, <strong>VSAM</strong> process the data set as having<br />
SHAREOPTIONS(1,x).<br />
When a data set is allocated with OLD disposition, <strong>VSAM</strong> treats the data set as<br />
having SHAREOPTIONS(1,x).<br />
Cross-region options<br />
The meanings of the options listed below are valid also in the Parallel Sysplex.<br />
(1): This SHAREOPTIONS means that can be only one <strong>VSAM</strong> OUTPUT<br />
control block structure throughout the Parallel Sysplex or any <strong>VSAM</strong> INPUT<br />
control block structures in the Parallel Sysplex.<br />
Except for those OPENs using the same <strong>VSAM</strong> control block structure,<br />
<strong>VSAM</strong> ensures only one OPEN for output or many OPENs for input only.<br />
Any other OPEN fails with a return code in ACB. That means, if the data set<br />
is open for input, other OPEN creating a new control block structure can<br />
open the same data set for input successfully. If the intention to open the<br />
data set is for output, the open fails with a return code in ACB. In other<br />
words, <strong>VSAM</strong> is insuring total read and write integrity. The intention of<br />
input or output is declared in the ACB MACRF parameter, not in the OPEN<br />
input or output options.<br />
For output, <strong>VSAM</strong> issues exclusive enqueue for the input and output <strong>VSAM</strong><br />
control blocks structure for each <strong>VSAM</strong> component, guaranteeing just one<br />
control block structure in the Parallel Sysplex. If an other OPEN is issued<br />
against the same data set, not using the same control block structure,<br />
<strong>VSAM</strong> does not queue the open, but fails it.<br />
For input, <strong>VSAM</strong> issues shared enqueue only for input <strong>VSAM</strong> control<br />
blocks structure for each <strong>VSAM</strong> component. OPENs for input are allowed. If<br />
an OPEN for output is issued against the same data set, not using the<br />
same control block structure, <strong>VSAM</strong> does not queue the open, but fails it.<br />
(2): <strong>VSAM</strong> ensures that only one <strong>VSAM</strong> control block structure for output in the<br />
Parallel Sysplex and many <strong>VSAM</strong> control block structures for input. In other<br />
words, <strong>VSAM</strong> is insuring write integrity. If you require read integrity (with a<br />
better performance due to higher granularity than cross-regions (1), it is<br />
your responsibility to use the ENQ and DEQ macros appropriately to<br />
provide read integrity for the data the program obtains.<br />
<strong>VSAM</strong> fails the OPEN OUTPUT when already exist in the Parallel Sysplex<br />
an output <strong>VSAM</strong> control block structure to the same data set.
(3): <strong>VSAM</strong> allows many OPENs to the data set for output and/or input. The<br />
user application programs must ensure both read and write integrity<br />
through their own ENQs (including Open and Close processing on them).<br />
(4): <strong>VSAM</strong> allows many OPENs to the data set for output and/or input. The<br />
user application programs must ensure both read and write integrity<br />
through their own ENQs (including Open and Close processing on them).<br />
<strong>VSAM</strong> refreshes the data and index components buffer pools for direct<br />
processing (the sequence set is not refreshed), to guarantee the coherency<br />
of the data in the buffer pool. Coherency in this case means that the task<br />
gets the most updated contents of the requested record.<br />
Cross-system options<br />
As we said before, the name cross-system is improper stated, since<br />
SHAREOPTIONS is sysplex wide. Cross-system options provide the same<br />
capability as cross-region 3 and 4. So, they are just a way to provide data sets<br />
using cross-region options 1 and 2 with the capabilities of 3 or 4. That means,<br />
you can use cross-systems options to have SHAREOPTIONS 1 or 2 with (4) or<br />
without (4) buffers refreshment. The cross-system value can be:<br />
(3): <strong>VSAM</strong> does not refresh the buffer pools for direct processing. When<br />
SHAREOPTIONS(3,3) or SHAREOPTIONS(4,3) is used, <strong>VSAM</strong> provides a<br />
Control Block Update Facility (CBUF).<br />
CBUF is active, whenever a data set is opened with DISP=SHR, and<br />
SHAREOPTIONS(3,3) or SHAREOPTIONS(4,3). In this case, <strong>VSAM</strong> record<br />
management maintains a copy of the critical control block data in z/OS<br />
common storage. Obviously, this common storage is available only to<br />
address spaces within your operating system. Passing this information to<br />
another operating system is your responsibility. CBUF eliminates the<br />
restriction that prohibits control area splits. However, under share options 4<br />
these restrictions still exist.<br />
Cross-systems sharing with CA splits can be accomplished (with integrity)<br />
by sending the <strong>VSAM</strong> shared information (VSI) blocks to the other host at<br />
the conclusion of each output request. Every time a data set is opened on a<br />
system for CBUF processing, a VSI is built for the data set and added to the<br />
VSI chain. This control block is then updated by the user to communicate<br />
information from one address space to another. Generally, the VSIs sent to<br />
other z/OS images has not changed and only a check occurs. Refer to the<br />
Appendix , “Accessing the <strong>VSAM</strong> Shared Information (VSI)” on page 366,<br />
where there is an example about how to get the VSI.<br />
About sending the VSI to the other z/OS image, you may choose:<br />
XRC APIs, as: IXCCONN, IXCMSGO, IXCMSGI<br />
APPC VTAM® LU 6.2, as: RECEIVE_AND_WAIT and SEND_DATA<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 225
226 <strong>VSAM</strong> <strong>Demystified</strong><br />
Remember that you still must continue to provide read and write integrity.<br />
Although <strong>VSAM</strong> ensures that tasks have correct control block information if<br />
serialization is done correctly. Also, the option 3, does not cause buffer pool<br />
invalidation as in option 4.<br />
Because programs in many regions can share the same data set, an error<br />
that occurs in one region can affect programs in other regions that share<br />
the same data set. If a logical error (register 15=8) or physical error<br />
(register 15=12) is detected, any control block changes made before the<br />
error was detected will be propagated to the shared information in common<br />
storage.<br />
The section “Techniques of Data Sharing” in z/OS DFSMS Using Data Sets,<br />
SC26-7410, contains examples about how to implement <strong>VSAM</strong> sharing with<br />
integrity.<br />
4.3.5 General share options: Considerations<br />
User tasks running user programs that ignore the write integrity guidelines in<br />
share options 3 and 4 can cause <strong>VSAM</strong> program checks, lost or inaccessible<br />
records, uncorrectable data set failures, and other unpredictable results. This<br />
option places responsibility on each user application program sharing the data<br />
set. Refer to 3.3.4, “Broken <strong>VSAM</strong> data set” on page 163.<br />
User programs that ignore the read integrity guidelines in share options 2, 3 and<br />
4 results in down-level data records and erroneous no-record-found conditions.<br />
As stated before in cross-region option 4 and cross-system option 4, buffers for<br />
direct processing are refreshed by <strong>VSAM</strong> for each request (or in other words,<br />
buffering is not saving I/O operations). Here are more details on this:<br />
► Each PUT request results in the appropriate buffer being written immediately<br />
into the <strong>VSAM</strong> object's DASD. <strong>VSAM</strong> writes out the buffer in the user's<br />
address space that contains the new or updated data record. The data and<br />
sequence-set control interval buffers are marked invalid following the I/O<br />
operation to DASD.<br />
► Each GET request results in all the user's input buffers being refreshed. The<br />
contents of each data and index buffer used by the user's program is retrieved<br />
from the <strong>VSAM</strong> object's direct access device.<br />
► GRS serialization<br />
Open/Close/EOV routines use ENQ/DEQ in SYS<strong>VSAM</strong>.dsn.catname.I|O|B, to<br />
implement serialization when processing a <strong>VSAM</strong> data set, as well as to<br />
ensure proper sharing based on share options. To avoid integrity exposures,<br />
never add SYS<strong>VSAM</strong> Qname to the GRS RNL exclusion list.
► Pay attention that during load mode processing, you cannot share data sets.<br />
Share options are overridden during load mode processing to (1 3). Refer to<br />
2.6.11, “Initial load option” on page 59.<br />
Data and sequence sets buffers for direct processing (for reads and writes) are<br />
refreshed for each request (index buffers are not). Output processing is<br />
limited to update and add processing that does not change either the<br />
high-used RBA or the RBA of the high key data control interval. Then, control<br />
area splits and the addition of a new high-key record for a new control interval<br />
that results from a control interval split are not allowed. <strong>VSAM</strong> returns a<br />
logical error to the user's program when this condition occurs. If the task<br />
running your program does not satisfy the requirements described above, you<br />
require cross-system option 3, where due to CBUF, CA splits and addition of a<br />
new high-key record are allowed.<br />
Table 4-2 contains a summary of the share options.<br />
Table 4-2 Relationship between share options and <strong>VSAM</strong> functions<br />
Share Options (DISP=SHR) <strong>VSAM</strong> function provided<br />
(3 3) CBUF and no buffer refresh<br />
(3 4) Data/Seq Set buffers invalidate. No CA<br />
splits<br />
(4 3) Data/Index buffers invalidate. CBUF<br />
(4 4) Data/Seq Set/lndex buffers invalidate. No<br />
CA splits<br />
4.3.6 Protecting <strong>VSAM</strong> data set through DISP parameter<br />
When a data set is allocated, the data set disposition provokes an enqueue in the<br />
major name SYSDSN, minor name data set name. The scope of the enqueue is<br />
throughout the Parallel Sysplex (unless the data set name is the GRS exclusion<br />
list). The enqueue is SHARED for shared data set disposition and EXCLUSIVE<br />
for OLD, MOD or NEW data set disposition.<br />
If you intend to protect your <strong>VSAM</strong> data sets using its disposition, be aware of:<br />
► The enqueue is done only for the data set name, not for the sphere<br />
components.<br />
► When OLD data set disposition is used, <strong>VSAM</strong> treats the data set as having<br />
SHAREOPTIONS(1,x).<br />
In Example 4-4, the enqueues in SYSDSN issued due to allocation are in two<br />
different resource names: PATH_OF_CLUSTER_A, and CLUSTER_A. The OLD<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 227
228 <strong>VSAM</strong> <strong>Demystified</strong><br />
disposition does not avoid allocating CLUSTER_A in JOB 02. But with the OLD<br />
disposition in JOB 01, <strong>VSAM</strong> treats as SHAREOPTIONS(1,x). Then, while JOB<br />
01 is running with DD1 opened, if JOB 02 starts and tries to open the data set, it<br />
receives and OPEN error, because already exists one RP control block for<br />
OUTPUT.<br />
Example 4-4 <strong>VSAM</strong> data set allocated with DISP=OLD<br />
SPHERE: CLUSTER_A (Base of the sphere)<br />
AIX_OF_CLUSTER_A<br />
PATH_CLUSTERA (Connecting the alternate index to the base cluster)<br />
JOB 01 OPEN FOR OUTPUT:<br />
//DD1 DD DSN=PATH_OF_CLUSTER_A,DISP=OLD<br />
JOB 02:<br />
//DD2 DD DSN=CLUSTER_A,DISP=SHR<br />
Before using DISP=OLD to protect <strong>VSAM</strong> data sets, refer to “Using a single<br />
<strong>VSAM</strong> control block structure” on page 221, to understand how <strong>VSAM</strong> creates<br />
control block structure according to the component being opened. If you intend to<br />
use DISP=OLD, do not forget to allocate the <strong>VSAM</strong> data set components with<br />
DISP=OLD too.<br />
4.4 Extended addressability (EA)<br />
Extended addressability (EA) was introduced in DFSMS/MVS 1.3, for KSDS data<br />
sets. Since DFSMS/MVS 1.4, EA is supported in record level sharing (RLS). With<br />
DFSMS/MVS 1.5, support for extended addressability is extended to all other<br />
<strong>VSAM</strong> record organizations.<br />
With EA, the 4G architectural limit for data set size imposed by using the 4-byte<br />
field for the relative byte address (RBA) was eliminated.<br />
It is important to state that extended addressability and extended format are not<br />
the same concept. Extended format is a way of storing data in a 3390/3380<br />
logical volume. Extended addressability is the ability of allowing larger <strong>VSAM</strong><br />
data sets. However, extended format is a pre-prerequisite for extended<br />
addressability.<br />
Using EA, the size limit for a <strong>VSAM</strong> data set is determined by either:<br />
► CI size multiplied by 4 GB<br />
► The volume size multiplied by 59
A 4K CI size yields a maximum data set size of 16 TB, while a 32 KB CI size<br />
yields a maximum data set size of 128 TB. A 4K CI size is preferred by many<br />
applications for performance reasons. No increase in processing time is<br />
expected for extended format data sets that grow beyond 4 GB.<br />
To use EA, the data set must be:<br />
► SMS-managed<br />
► Defined as extended format<br />
EA is available to a data sets associated to a data class defined with:<br />
► DSNTYPE=EXT<br />
► EXTENDED ADDRESSABILITY=Y<br />
Figure 4-8 shows the ISMF panel where you specify EF and EA when you define<br />
or alter a data class.<br />
DATA CLASS DEFINE Page 2 of 4<br />
Command ===><br />
SCDS Name . . . : SYS1.SMS.SCDS<br />
Data Class Name : MHLEXTN<br />
To DEFINE Data Class, Specify:<br />
Data Set Name Type . . . . . . EXT (EXT, HFS, LIB, PDS or blank)<br />
If Ext . . . . . . . . . . . R (P=Preferred, R=Required or blank)<br />
Extended Addressability . . . Y (Y or N)<br />
Record Access Bias . . . . . (S=System, U=User or blank)<br />
Space Constraint Relief . . . . (Y or N)<br />
Reduce Space Up To (%) . . . (0 to 99 or blank)<br />
Dynamic Volume Count . . . . (1 to 59 or blank)<br />
Compaction . . . . . . . . . . (Y, N, T, G or blank)<br />
Spanned / Nonspanned . . . . . (S=Spanned, N=Nonspanned or blank)<br />
Figure 4-8 DATA CLASS DEFINE ISMF panel<br />
After creating a data class with the attributes above, users can code the<br />
DATACLAS value on their DD statements or let the ACS routines assign the<br />
appropriate data class for their eligible data. Another method in which JCL can<br />
be used to create a KSDS with extended addressability is through the DD<br />
statement keyword LIKE.<br />
Applications that access a <strong>VSAM</strong> extended format KSDS through a<br />
user-specified key can take advantage of having very large <strong>VSAM</strong> components<br />
without making JCL or code changes.<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 229
230 <strong>VSAM</strong> <strong>Demystified</strong><br />
To support EA, many DFSMS macros and commands have changed. To take<br />
advantage of extended addressability, new macro parameters and<br />
sub-parameters related to RBA have been added.<br />
► RPL macro, added the XRBA subparameter to the OPTCD parameter to<br />
indicate that extended addressability is be used. It must be used when<br />
processing a data set by its RBA. For example, OPTCD=(ADR,DIR,XRBA)<br />
instead of OPTCD=(ADR,DIR,RBA).<br />
► TESTCB macro, added XADDR as a possible value to ATRB. It can be used<br />
to test if the data set is in extended addressability format.<br />
► SHOWCB macro, added:<br />
– XAVSPAC parameter to obtain the amount of available space in the data<br />
component or index component, in bytes.<br />
– XENDRBA, to obtain the high-used RBA (HURBA)<br />
– XHALCRBA, to obtain the high-allocated RBA (HARBA)<br />
The fields above use 8 bytes to return the information, instead of 4 bytes used<br />
for non-EA data sets.<br />
Applications that process an EF data set by RBA must provide an 8-byte RBA<br />
when the data set is defined for EA. Special provisions are allowed for certain<br />
types of requests (for example GET SEQ,ADR or GET ADR,DIR,LRD).<br />
A major idea in the EA design is to make applications, such as backup,<br />
transparent to the function. That is, we do not require an extended field (8-bytes)<br />
XRBA, unless it is a positioning request. In the case of a backup when the data<br />
set is to be just read sequentially from the beginning, requiring no positioning, the<br />
extended field is not required. Also, RLS processing does not support any use of<br />
RBA or XRBA access to an EA data set.<br />
With DB2 V1.6 and later, EA can be used for very large DB2 table spaces.<br />
A <strong>VSAM</strong> EF KSDS defined for EA must not be shared with any system running a<br />
release prior to DFSMS/MVS 1.3. Toleration maintenance is available for<br />
DFSMS/MVS 1.2 systems which support <strong>VSAM</strong> extended format data sets<br />
without EA. A DFSMSdfp toleration PTF allows systems at this level to issue an<br />
error message if any attempt is made to open a <strong>VSAM</strong> KSDS with extended<br />
addressability. DFSMSdss provides a toleration PTF so that an error message is<br />
issued when a logical DUMP, RESTORE, or COPY operation is attempted on a<br />
KSDS with extended addressability.<br />
DB2 data warehousing projects that require table spaces larger than 4 GB can<br />
use the EA support for linear data sets provided in DFSMS/MVS 1.5. To do this,<br />
assign a data class with the extended addressability attribute to the data set
when it is defined. The data class should have the following attributes specified<br />
for it:<br />
Recorg = LS<br />
Data Set Name Type = Extended<br />
IF Extended = Required<br />
Extended Addressability = Yes<br />
Then make sure your data class ACS routine for DB2 permits the use of the data<br />
class created.<br />
The message IDC3351I ** <strong>VSAM</strong> {OPEN|CLOSE|I/O} RETURN CODE IS 116 is<br />
produced when you try to go beyond 4 GB in a <strong>VSAM</strong> data set without EA.<br />
4.5 Catalog Search Interface<br />
4.5.1 CSI setup<br />
The Catalog Search Interface (CSI) is shipped as a component of base since<br />
DFSMS/MVS 1.5. As its use is not wide spread, we take this opportunity to<br />
remind you of its availability and to point out its advantages over other methods<br />
of obtaining catalog information. The following section describes:<br />
► CSI setup<br />
– CSI programming considerations<br />
– IBM supplied sample program<br />
The CSI is a general-use programming interface for obtaining information from<br />
ICF catalogs. It provides great flexibility in specifying the selection criteria for the<br />
data that is to be returned. The CSI may be invoked by assembler programs,<br />
high-level language programs and REXX execs. See the appendix in Managing<br />
Catalogs, SC26-4914, for a complete description of the interface. We present an<br />
sample REXX using CSI in “SMFLSR sample program” on page 380.<br />
Much of the information you can obtain from the CSI you could also obtain using<br />
an IDCAMS LISTCAT command. However, there are some advantages using<br />
CSI that you may want to consider when accessing catalog information:<br />
► Using a Generic Filter Key:<br />
When requesting information from the CSI for specific catalog entries, you<br />
may specify a generic filter key. This key can contain the following symbols<br />
used to filter the entry names:<br />
* A single asterisk represents one or more characters within a qualifier<br />
** A double asterisk represents zero or more qualifiers<br />
% A percent sign represents one alphanumeric or national character<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 231
232 <strong>VSAM</strong> <strong>Demystified</strong><br />
%%... Up to eight characters can be specified in one qualifier<br />
► Using selection criteria fields<br />
When requesting information from the CSI for specific catalog fields, you may<br />
specify a list of field names. For example, if you were only interested in the<br />
volume and the file sequence number for specific data sets, you could specify<br />
the catalog field names VOLSER and FILESEQ in the field name list when<br />
calling the CSI. Obtaining this information from IDCAMS would require you to<br />
use the IDCAMS LISTCAT ALL command and to scan the output to retrieve<br />
the desired information.<br />
► Performance benefits<br />
Using the CSI generally results in significantly better performance compared<br />
to using IDCAMS LISTCAT, which does a catalog call for each entry<br />
processed. The flexibility in requesting only the information that you are<br />
interested in using the CSI results in additional performance improvements,<br />
since you eliminate the retrieval of unneeded information.<br />
► CSI programming considerations<br />
The CSI is distributed as load module IGGCSI00 in SYS1.LINKLIB. It is<br />
reentrant and reusable, can be invoked in 24-bit or 31-bit addressing mode, in<br />
any PSW key, and in either problem or supervisor state.<br />
CSI requires three parameters to process your request:<br />
– A 4-byte reason area used to return error or status information<br />
– A variable length selection criteria list (for input)<br />
– Work area used to return the requested catalog data<br />
► IBM supplied sample programs<br />
IBM provides three sample assembler programs and one REXX exec in<br />
SYS1.SAMPLIB. Here we provide a short summary of their functions:<br />
► IGGCSILK produces output similar to that of an IDCAMS LISTCAT<br />
CAT(catname) command.<br />
► IGGCSIVG identifies unused space at the end of <strong>VSAM</strong> data sets defined in a<br />
given catalog. This is calculated as the difference of the high-allocated and<br />
the high-used relative byte address (HARBA-HURBA)<br />
► IGGCSIVS produces a list of data set names defined in a given catalog that<br />
reside on a specific volume. Such a list might be helpful in a volume recovery<br />
situation.<br />
► IGGCSIRX is a REXX exec that produces a list of data set names matching a<br />
generic filter key. When you call it from a TSO/E session, it will prompt you for<br />
the filter key, and return matching data set names, their type, and volume<br />
definition.
4.6 Major sources of <strong>VSAM</strong> processing options<br />
The <strong>VSAM</strong> cluster processing options and characteristics come from different<br />
sources, for example, JCL, SMS data classes, or macro parameters. The source<br />
of the processing options can be confusing since the same parameter can be<br />
specified in more than one source. In this case, there is an order of precedence<br />
that, when not understood, may give logically unexpected results. Table 4-3 lists<br />
the processing options and the characteristics and their sources, indicating the<br />
precedency by the highest number. The underlined value in MACRF indicates<br />
the default. The Type explains if the parameter is related to a data set<br />
characteristic (C) or processing option (P).<br />
Table 4-3 <strong>VSAM</strong> Data Set Parameters and Processing Options<br />
Parameter Type ACB DD Defi<br />
ne<br />
ACCBIAS P - 2 - 1 a<br />
AVGREC (RECORDS) C - 2 2 1<br />
BUFSP P 2 b 3b 1 c -<br />
BUFND,BUFNI P 2 3 1 -<br />
BWO P - - 2 1<br />
CATALOG C - - 1 -<br />
COMPACTION C - - - 1<br />
CISZ C 2 1<br />
DATACLAS (DATACLASS) d C - 1 1 -<br />
DDNAME P 1 - - -<br />
DYNAMIC VOLUME COUNT P - - - 1<br />
ERASE/NOERASE P - - 1 -<br />
EXCEPTIONEXIT P - - 1 -<br />
EXLST P 1 2 e - -<br />
EXPDT C - 2 2 f<br />
EXTENDED ADDRESSABILITY C - - - 1<br />
EXTENDED FORMAT C - - - 1<br />
FREESPACE C - - 2 1<br />
SMB<br />
DC<br />
1,3 g<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 233
234 <strong>VSAM</strong> <strong>Demystified</strong><br />
Parameter Type ACB DD Defi<br />
ne<br />
FRLOG P - 3 2 1<br />
LIKE C - 1 1 h<br />
KEYLEN C - 2 2 1<br />
KEYOFF C - 2 2 1<br />
LOG P - - 2 1<br />
LOGSTREAMID P - 2 2 i<br />
LRECL (RECORDSIZE) j C - 2 2 1<br />
MGMTCLAS (MANAGEMENTCLASS) d k P - 1 1 -<br />
MACRF=[ NSR | LSR | GSR | RLS] P 1<br />
l<br />
-<br />
1<br />
- -<br />
MACRF=[ ADR,CNV,KEY ] P 1 - - -<br />
MACRF=[ CFX l NFX ] P 1 - - -<br />
MACRF=[ DIR ][,SEQ ][,SKP ] P 1 - - -<br />
MACRF=[ DFR l NDF ] P 1 - - -<br />
MACRF=[ DDN l DSN ] P 1 - - -<br />
MACRF=[ IN,OUT ] P 1 - - -<br />
MACRF=[ ICI l NCI ] P 1 - - -<br />
MACRF=[ LEW l NLW ] P 1 - - -<br />
MACRF=[ NIS l SIS ] P 1 - - -<br />
MACRF=[ NRM l AIX ] P 1 - - -<br />
MACRF=[ NRS l RST ] P 1 - - -<br />
MACRF=[ NUB l UBF ] P 1 - - -<br />
OWNER C - - 1 -<br />
RECATALOG/NORECATALOG C - - 1 -<br />
RECORG C - 1 1 -<br />
RETPD C - 2 2 m 1,3 n<br />
REUSE/NOREUSE P - - 2 1<br />
SMB<br />
DC
4.6.1 ACB control block<br />
Parameter Type ACB DD Defi<br />
ne<br />
RLS CF Cache Value P - - - 1<br />
RLSREAD={NR |CR NORD}] P 1 l - -<br />
RMODE31 P 1 2 - -<br />
SHAREOPTIONS C - - 2 1<br />
SPACE (CYL, KB, MB, REC, TRK) P - 2 2 1<br />
SPACE CONSTRAINT RELIEF P - - - 1<br />
SPANNED/NONSPANNED C - - 2 1<br />
SPEED/RECOVERY P - - 2 1<br />
STORCLAS (STORAGECLASS) d P - 1 1 -<br />
STRNO P 1 2 - -<br />
VOLUME P - 2 o 2 1<br />
WRITECHECK P - - 1 -<br />
a. Correspond to Record Access Bias in Data Class<br />
b. Specifies the maximum space for buffers<br />
c. Specifies the minimum space for buffers<br />
d. Can be overridden by the ACS routines<br />
e. Through the AMP, SYNAD parameter<br />
f. TO(x) FOR(x) of DEFINE command<br />
g. When specified in MANAGEMENT CLASS, can not be overridden<br />
h. Correspond to MODEL in DEFINE command<br />
i. LGSTREAM JCL parameter<br />
j. LRECL does not apply to LINEAR data sets<br />
k. Overrides Data Class parameters EXPDT RETPD<br />
l. RLS=(NRI or CR) when in ACB RLSREAD=NORD or does not specifies RLS.<br />
m. TO(x) FOR(x) of DEFINE command<br />
n. When specified in MANAGEMENT CLASS, can not be overriden<br />
o. Only when Storage Class with Guaranteed Space= yes<br />
SMB<br />
DC<br />
The ACB is a control block within the application program. The ACB is to <strong>VSAM</strong><br />
as the DCB is to other access methods. In its fields, the ACB contains logical<br />
information about the <strong>VSAM</strong> cluster. The ACB information is used by Open,<br />
Close and <strong>VSAM</strong> routines. The way that the ACB is created depends on the<br />
source language of the application program:<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 235
236 <strong>VSAM</strong> <strong>Demystified</strong><br />
► In Assembler through the ACB macro at assemble time or GENCB at<br />
execution time.<br />
► In Cobol through the File Description.<br />
► In through DCL statement.<br />
The source of ACB fields can be:<br />
– From keywords in macro ACB at compile or assembler time.<br />
– At allocation, with ACB parameters coming from AMP parameter, in the<br />
DD statement.<br />
– From keywords in macro GENCB at execution time by the application<br />
program.<br />
Here is a list of the ACB fields. The ones starting with an asterisk indicate that<br />
they can also be entered in the JCL DD statement:<br />
– DDName, which is the link with the DD statement. The DD statement<br />
besides its optional complementary ACB information, describes the<br />
physical characteristics of the cluster, as VOLSER, device type.<br />
– The size (or the maximum size) of the I/O buffer virtual storage space<br />
and/or the number of I/O buffers to process data and index records.<br />
– The chosen buffering technique, such as: NSR, LSR, GSR, RLS.<br />
– The defer write option, that is to delay the buffer destage.<br />
– The processing options that you plan to use:<br />
Keyed, RBA, RRN<br />
Sequential, direct, or skip sequential access, or a combination. This<br />
field is just an intention<br />
Retrieval, storage, or update (including deletion), or a combination<br />
Shared or nonshared resources<br />
– The address of an exit list for your exit routines. Use the EXLST macro to<br />
construct the list.<br />
– What to do when lock contention arises.<br />
– Read integrity options for RLS GETs.<br />
– If you are processing concurrent requests, the number of requests<br />
(STRNO).<br />
– The address and length of an area for error messages from <strong>VSAM</strong>.<br />
– RMODE of the buffers and <strong>VSAM</strong> control blocks.
– Address of the <strong>VSAM</strong> GET/PUT routine. This field is filled by the OPEN<br />
macro function.<br />
4.6.2 DD statement keywords<br />
Please refer to the MVS JCL Reference, SA22-7597-04, to get information about<br />
all the generic DD Statement keywords which apply to <strong>VSAM</strong>. Here are <strong>VSAM</strong><br />
specific parameters not present in the ACB:<br />
– Options for controlling System Managed Buffering (SMB) named<br />
ACCBIAS in the AMP keyword<br />
– Logstream option for RLS and Transactional <strong>VSAM</strong><br />
4.6.3 Catalog BCS and VVDS entries<br />
4.6.4 SMS constructs<br />
The catalog entry for a <strong>VSAM</strong> cluster or a component has the attributes usually<br />
needed to create this <strong>VSAM</strong> entity. Those attributes are entered in the catalog<br />
through the IDCAMS DEFINE/ALLOCATE/ALTER commands:<br />
► Primary and secondary space information<br />
► CI size<br />
► Free space percentages<br />
► Logical record size<br />
► Cluster organization data set (KSDS, RRDS,ESDS, LDS, VRRDS)<br />
► Key length and key offset<br />
► Name of SMS constructs, as DC, SC, M C<br />
► Retention period<br />
► Share options: cross region and cross system<br />
► Spanned records<br />
► Backup while open (BWO) options<br />
► The minimum buffer space size<br />
► Expiration date<br />
► Initial load options (SPEED and RECOVERY)<br />
Here are the SMS constructs that effect <strong>VSAM</strong> attributes.<br />
Data Class construct<br />
The data class construct has almost the same options of the IDCAMS define<br />
command. The practical difference is that, with a data class, you do not need to<br />
define all the IDCAMS keywords. You just point to the data class name. Also,<br />
these options are centralized and controlled through the SMS storage<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 237
238 <strong>VSAM</strong> <strong>Demystified</strong><br />
administrator. The Following options in data class are not present in the IDCAMS<br />
DEFINE, and are not stored in the catalog:<br />
– To use or not the primary size in a secondary volume<br />
– Maximum number of volumes<br />
– Extended format<br />
– Extended addressability<br />
– Options for controlling System Managed Buffering (SMB) named<br />
RECORD_ACCESS_BIAS<br />
– Space constraint relief<br />
– Data Compression<br />
– RLS use of the CF cache structure<br />
Storage Class<br />
The storage class SMS construct has parameters to control:<br />
► Performance as:<br />
– How the I/O operation uses the controller cache<br />
– Are the CIs stripped?<br />
– CF structure name to be used as a cache by <strong>VSAM</strong> RLS<br />
► Availability as:<br />
– Guarantee to the <strong>VSAM</strong> cluster a controller with RAID<br />
– Guarantee to the <strong>VSAM</strong> cluster a controller with T0 copy and remote copy<br />
Management Class<br />
The management class SMS construct has parameters to control <strong>VSAM</strong> clusters<br />
expiration, partial release, GDG, backups and migration.<br />
4.7 Media Manager, Open, Close, EOV in <strong>VSAM</strong><br />
Media Manager is the I/O driver code. It stands between the access method and<br />
the Input Output Supervisor. <strong>VSAM</strong> has two I/O drivers depending on the<br />
required function:<br />
► Block Processor (SVC 121), that is old and there is a SOD for being<br />
inactivated. Since z/OS V1R4 DFSMS Block Processor is being used only for<br />
Improved Control Interval processing (ICI).<br />
► Media Manager, which is modern. There is a trend to all access methods to<br />
use Media Manager. Media Manager has the I/O channel program support for<br />
implementing Extended Format.
4.7.1 OPEN macro<br />
4.7.2 CLOSE macro<br />
Media Manager executes all these functions:<br />
► Creates Channel Programs with virtual addresses (this was done before by<br />
<strong>VSAM</strong>)<br />
► Page-Fix (or Page-Free) buffers<br />
► Verifies that buffers are accessible in user key<br />
► Translates virtual addresses to/from real addresses in the channel program<br />
► Validates that RBA is within data set<br />
► Re-drives Channel Programs to IOS (through STARTIO macro)<br />
► Provides for DCME statistics<br />
► Invokes SMFIOCNT<br />
Before an application program can access a data set, it must first issue the<br />
OPEN macro to open the data set for processing. The OPEN is issued against a<br />
user Access method Control Block (ACB). Opening a data set causes <strong>VSAM</strong> to:<br />
► Verify that the data set matches the description specified in the ACB or<br />
GENCB macro. For example, MACRF=KEY implies that the data set is KSDS.<br />
► Construct the internal control blocks and buffer pools that <strong>VSAM</strong> needs to<br />
process your requests for access to the data.<br />
► Load the access method (based in the ACB information) placing the address<br />
in the ACB for the next GET or PUT.<br />
► Check your program security authorization (RACF).<br />
The CLOSE macro disconnects your program from the data set. <strong>VSAM</strong> does the<br />
following during CLOSE:<br />
► Writes any unwritten data or index records whose contents have changed.<br />
► Writes SMF records if using SMF.<br />
► Updates the catalog entry for the data set. Updates the data set’s high-used<br />
RBA (HURBA).<br />
► Restores control blocks to the status they had before the data set was<br />
opened.<br />
► Releases virtual storage obtained during OPEN processing for additional<br />
<strong>VSAM</strong> control blocks and <strong>VSAM</strong> routines.<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 239
240 <strong>VSAM</strong> <strong>Demystified</strong><br />
► For extended format KSDS, releases all space between HURBA and HARBA<br />
if partial release was specified at OPEN.<br />
If an abend happens during CLOSE, the HURBA which is updated during<br />
CLOSE processing, may be incorrect because the catalog was not updated.<br />
The next <strong>VSAM</strong> OPEN performs an implicit VERIFY. If the VERIFY is not<br />
successful, <strong>VSAM</strong> OPEN passes a return code and reason code.<br />
You can issue a CLOSE TYPE=T or a temporary CLOSE. This causes <strong>VSAM</strong> to<br />
complete any outstanding I/O operation, update the catalog, and write any<br />
required SMF records. Then processing can continue without issuing an OPEN<br />
macro.<br />
4.7.3 End-of-Volume (EOV)<br />
EOV function is invoked by <strong>VSAM</strong> Record Management, when a <strong>VSAM</strong> data set<br />
requires additional space. The lack of this additional space is perceived by:<br />
► High-used RBA (HURBA) = High-allocated RBA (HARBA)<br />
► RBA of next CI/CA greater than HARBA during create<br />
► No extent in the current volume contains a specific searched RBA<br />
Then, EOV acquires new extents interfacing with DADSM, updates the <strong>VSAM</strong><br />
control block structure for the data set with the new extent information, and<br />
updates the critical control block data in common storage and in the catalog, so<br />
that this new space is accessible by all regions using this <strong>VSAM</strong> data set.<br />
4.8 <strong>VSAM</strong> and 64 bits<br />
Since z/OS V1R4 DFSMS, <strong>VSAM</strong> supports 64 bits of real storage. Some <strong>VSAM</strong><br />
functions was modified to can use real storage address:<br />
► Media Manager:<br />
– Now performs I/O to all <strong>VSAM</strong> data sets, except when using ICI<br />
processing.<br />
– Full support for ESS-2105 (SHARK), allowing Read Track Data, Write<br />
Track Data and Write Full Tack.<br />
– Support for 64-bit real addresses used to back 31 bit virtual addresses.<br />
► OPEN routine:<br />
– Obtains buffers in 64-bit real storage in all cases.
– Eliminates all control blocks and data from CSA and SQA, except when<br />
GSR and ICI is being used. The data and control blocks now use private<br />
storage area.<br />
– Initializes a protected field for the high allocated CI, for being later updated<br />
by the EOV routine when extending the data set.<br />
► Record Management:<br />
– Uses the information of the high allocated CI, stored in a protected page,<br />
to search the index. It avoids loops when a pointer is corrupted.<br />
► <strong>VSAM</strong> Hiperbatch:<br />
– Now supports <strong>VSAM</strong> extended format data set<br />
► Checkpoint/Restart:<br />
– Now supports <strong>VSAM</strong> extended format data set<br />
► EOV routine:<br />
– EOV does not support ORDERED parameter. If space is not available on<br />
the next candidate volume, a different candidate volume is used.<br />
4.9 Special considerations for COBOL users and SMB<br />
This was added to provide some insight for COBOL users.<br />
4.9.1 COBOL users take note<br />
Note: This information was provided by Helen Witter.<br />
Try to keep in mind is that COBOL is written for NSR processing. If anything is<br />
done to switch the processing to LSR (whether OEM, SMB or BLSR), the<br />
program or COBOL may not be able to handle it. The good news is that SMB can<br />
be disabled for a particular program by coding an override on the DD card and<br />
letting other files that access the dataset continue to use SMB. The most<br />
common problem is a positioning error. With NSR processing, implicit positioning<br />
by <strong>VSAM</strong> to the first record in the file is done on the first sequential GET. Many<br />
programs (especially older ones) take advantage of this and do not explicitly<br />
position to the first record of the file. With LSR, there is no implicit positioning<br />
done so if the program does not position, the same GET that worked with NSR<br />
will be returned with a rc58. This translates into a COBOL SK30. This should be<br />
minimal since SMB won't decide to do DO processing on a file that is opened<br />
with sequential. The other very common problem is waits/hangs. This is also due<br />
to the inherent differences between NSR and LSR. With NSR you may have<br />
multiple requests in the pool accessing the same data CI, because a copy of the<br />
CI will be given to each request. In LSR, you can have multiple requests reading<br />
Chapter 4. Managing your <strong>VSAM</strong> data sets 241
242 <strong>VSAM</strong> <strong>Demystified</strong><br />
the same CI (they will all share the same buffer rather than get their own copy),<br />
but a request for update of that CI must wait until all the readers have finished<br />
with it. This can cause hangs. There are a number of possible circumvention for<br />
this. It depends on what the program is doing and in what order. If, for example, if<br />
the program has two ACB's, it could open the sequential ACB first then DO would<br />
not be selected. Another possible problem could be very old programs that were<br />
written for ISAM datasets. If the customer has been using the <strong>VSAM</strong>/ISAM<br />
interface to continue to use these programs, they must continue to use NSR.<br />
Again, the impact should be minimal as the ACB probably has sequential<br />
specified. Some SMB users, not just COBOL, are finding that they need to<br />
increase their region size when running SMB because of the extra storage<br />
required to optimize the buffering. This is especially true on large files or<br />
programs that open many SMB <strong>VSAM</strong> files. In general, SMB is pretty "smart" and<br />
the user should see a good deal of performance benefits from using SMB,<br />
however, it still comes down to some applications might need minor JCL or<br />
coding changes to use SMB.
Chapter 5. <strong>VSAM</strong> Record Level Sharing<br />
This chapter introduces <strong>VSAM</strong> Record Level Sharing (RLS) concepts and<br />
describes how to implement RLS.<br />
The topics cover:<br />
► Introducing RLS<br />
► RLS terminology<br />
► Planning for RLS<br />
► Implementing RLS<br />
► MVS commands for RLS<br />
► RLS problem determination and recovery<br />
► RLS enhancements<br />
► RLS performance considerations<br />
5<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 243
5.1 Introducing <strong>VSAM</strong> RLS<br />
244 <strong>VSAM</strong> <strong>Demystified</strong><br />
In this section we introduce the basic concepts of <strong>VSAM</strong> RLS mode.<br />
5.1.1 What is <strong>VSAM</strong> RLS?<br />
5.1.2 Why RLS?<br />
<strong>VSAM</strong> RLS is another mode of managing buffer pools, which allows any number<br />
of users within your Parallel Sysplex to share your existing <strong>VSAM</strong> spheres. It<br />
provides full data integrity (read and write). The serialization is at record level.<br />
However to implement recoverable spheres the user must have its own backout<br />
log, as CICS has.<br />
<strong>VSAM</strong> RLS does not introduce new types of <strong>VSAM</strong> clusters; rather, it introduces<br />
a new way of accessing existing data sets. Apart from the need to open data sets<br />
in RLS mode, the same <strong>VSAM</strong> record management interfaces (get, put, point,<br />
erase) are used.<br />
You can specify the RLS mode in the MACRF parameter of the ACB macro that<br />
you use to open the data set in your program. You can also specify the RLS<br />
mode, in the new keyword ‘RLS’ in your DD card that points to your <strong>VSAM</strong> data<br />
set in your JCL.<br />
RLS mode maybe used with KSDS, RRDS, VRRDS, and ESDS <strong>VSAM</strong> spheres.<br />
PATH access for KSDS and ESDS's is allowed with RLS. Extended format,<br />
extended addressibility, spanned, and compression are also supported with RLS.<br />
RLS and non-RLS <strong>VSAM</strong> data sets can co-exist.<br />
RLS allows concurrent access, in a sysplex, to your <strong>VSAM</strong> data sets at record<br />
level, while maintaining data integrity.<br />
<strong>VSAM</strong> RLS also addresses other <strong>VSAM</strong> issues, mainly in the CICS environment.<br />
Refer to “CICS and <strong>VSAM</strong> RLS” on page 246.<br />
5.1.3 How does RLS work?<br />
RLS logic is implemented in programs running in a <strong>VSAM</strong> address space named<br />
SMS<strong>VSAM</strong>, these programs gain the control from the RLS requesters through<br />
cross memory (PC instruction). The major difference between RLS and non-RLS<br />
modes is that the <strong>VSAM</strong> sphere control block structure is located in a CF cache<br />
structure and it is shared by all string task programs (also called users) in RLS
mode. Refer to “<strong>VSAM</strong> sharing mechanisms” on page 216 for details of control<br />
block structures.<br />
Figure 5-1 shows in a very simplified form how a <strong>VSAM</strong> spheres is shared<br />
between various address spaces (CICS and Batch jobs) across a Parallel<br />
Sysplex. Each z/OS system in the sysplex has an SMS<strong>VSAM</strong> address space to<br />
co-ordinate the sharing. Shared Control Data Set (SHCDS) contains critical<br />
information that is used by various SMS<strong>VSAM</strong> address spaces for RLS. The<br />
coupling facility contains:<br />
► Lock structure IGWLOCK00 which contains global locks to serialize at record<br />
level and to serialize functions as splits.<br />
► Cache structures used to hold shared data and control block structures.<br />
z/OS SYSTEM 1<br />
SMS<strong>VSAM</strong><br />
Figure 5-1 RLS in Sysplex<br />
5.1.4 RLS in a single system (monoplex)<br />
SHCDS<br />
Shared DASD<br />
cache<br />
cache<br />
cache cache<br />
IGWLOCK00<br />
<strong>VSAM</strong><br />
Shared DASD<br />
z/OS SYSTEM 2<br />
CICS BATCH1 BATCH2 CICS BATCH1 BATCH2<br />
Coupling Facility<br />
SMS<strong>VSAM</strong><br />
You may access <strong>VSAM</strong> sphere in RLS mode by users running in just one z/OS<br />
image. However, even in a monoplex environment a Coupling facility is required.<br />
Figure 5-2 shows an example of such a setup.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 245
246 <strong>VSAM</strong> <strong>Demystified</strong><br />
The reason for doing that is to exploit the better serialization provided by RLS.<br />
For example, in a non-RLS mode two jobs trying to access for update a cluster<br />
with total read and write integrity, that is, SHAREOPTIONS (1,3), just one can<br />
open the cluster. The other needs to wait for the first to close the cluster. The<br />
granularity of the serialization is at cluster level.<br />
If the two jobs access the cluster in RLS mode, then both the OPENs will<br />
succeed, and both in parallel can update the cluster. The serialization is at logical<br />
record level.<br />
Figure 5-2 RLS in Monoplex<br />
5.1.5 CICS and <strong>VSAM</strong> RLS<br />
z / O S S Y S T E M<br />
C I C S B A T C H 1 B A T C H 2<br />
S M S V S A M<br />
S H C D S<br />
c a c h e<br />
c a c h e<br />
c a c h e c a c h e<br />
IG W L O C K 0 0<br />
C o u p lin g F a c ilit y<br />
V S A M<br />
Without <strong>VSAM</strong> RLS, CICS uses a process known as function shipping to share<br />
spheres between CICS systems. Function shipping is implemented by using a<br />
single CICS region known as a File Owning Region (FOR) to own a data set. All<br />
access to the data set was through the corresponding FOR, a focal point for<br />
<strong>VSAM</strong> access. The role of the FOR is simply to provide file access; the CICS<br />
transactions run elsewhere in Application Owning Regions (AORs). These<br />
regions run programs which, when they want to access a shared <strong>VSAM</strong> sphere,
ship the access request off to the FOR for that sphere and await the reply from<br />
the FOR. This is illustrated in Figure 5-3.<br />
This implementation has several problems as:<br />
► Function shipping between AORs and FORs in distinct systems, consuming<br />
resources.<br />
► The FOR is a single point of failure and can also be a CPU bottleneck<br />
► Locks are held by CICS/FOR. An in-doubt lock held by a CICS task can cause<br />
an integrity problem if FOR fails. In this case, there is no way to prevent other<br />
applications from accessing uncommitted data. With RLS, locks are held by<br />
SMS<strong>VSAM</strong> (not by CICS/FOR). Then the locks held by an in-doubt CICS task<br />
can be held if a CICS fails, preventing other applications from accessing<br />
uncommitted data until CICS is restarted or the locks are released by an<br />
operator command.<br />
► Need of committing remotely.<br />
► HURBA/HARBA are updated only when CICS closes the data set, causing<br />
conflicts along shared updates.<br />
These problems are fully addressed by <strong>VSAM</strong> RLS.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 247
248 <strong>VSAM</strong> <strong>Demystified</strong><br />
Application Owning Region<br />
CICS<br />
AOR<br />
CICS<br />
FOR<br />
<strong>VSAM</strong><br />
CICS<br />
AOR<br />
Problems:<br />
CICS FOR is a single point of failure<br />
Multiple system performance is no acceptable (uses VTAM or XCF cross<br />
system)<br />
No exploitation of System/390 Parallel Sysplex<br />
Figure 5-3 CICS before <strong>VSAM</strong> RLS<br />
File Owning Region<br />
CICS<br />
AOR<br />
CICS<br />
AOR<br />
z/OS 1 z/OS n<br />
CICS with <strong>VSAM</strong> RLS is shown in Figure 5-4. The RLS data sharing environment<br />
is designed to support sharing of <strong>VSAM</strong> spheres among multiple cloned AORs.<br />
With <strong>VSAM</strong> RLS, we no longer need file-owning regions (FOR). Each copy of<br />
z/OS contains an SMS<strong>VSAM</strong> address space which manages locks within a<br />
coupling facility. Coupling facility configurations can be designed to be highly<br />
available. As we no longer have file owning regions, we have removed the single<br />
point of failure. We can also scale by adding z/OS systems to the parallel<br />
sysplex, with each new system running a SMS<strong>VSAM</strong> address space.
CICS<br />
AOR<br />
Figure 5-4 CICS after <strong>VSAM</strong> RLS<br />
For more details about <strong>VSAM</strong> RLS and CICS refer to the following publications:<br />
► CICS and <strong>VSAM</strong> Record Lavel Sharing: Implementation Guide, SG24-4766<br />
► CICS and <strong>VSAM</strong> Record Lavel Sharing: Planning Guide, SG24-4765<br />
► CICS <strong>VSAM</strong> Recovery User’s Guide and Reference, SH26-4127<br />
5.1.6 RLS restrictions<br />
<strong>VSAM</strong> RLS<br />
instance 1<br />
CICS<br />
AOR<br />
Data Locks Caches<br />
Data Caches<br />
CICS<br />
AOR<br />
Attention: The version of CICS supporting RLS is CICS/TS.<br />
CICS<br />
AOR<br />
<strong>VSAM</strong> RLS<br />
instance n<br />
z/OS 1 z/OS n<br />
Locks<br />
Data Cache<br />
Coupling Facility<br />
There are restrictions that need to be considered before implementing RLS.<br />
► To share a <strong>VSAM</strong> sphere under RLS, the sphere must be SMS managed<br />
► IDCAMS currently does not have access to the control blocks in SYS<strong>VSAM</strong><br />
address space. You will not be able to use IDCAMS to obtain information<br />
pertaining to RLS.<br />
► Linear, keyrange, and temporary data sets are not supported under RLS.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 249
250 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Because the control block structure is shared, RLS does not use share<br />
options.<br />
► RLS does not support data striping.<br />
5.2 RLS terminology<br />
The terminology used in RLS books is sometimes different from the terms used<br />
more widely in z/OS and SMS. Therefore, it is worthwhile to define the RLS<br />
terms to avoid confusion.<br />
SMS<strong>VSAM</strong><br />
This is the z/OS jobname of the RLS address space. This is created on each<br />
z/OS image according to PARMLIB specifications. It is responsible for<br />
centralizing in one z/OS all processing necessary for cross system sharing, that<br />
is, the access to the CF (with data, control block structures and locks) and<br />
connect among its peers through XCF.<br />
<strong>VSAM</strong> sphere<br />
A sphere is the name used to represent the components (data/index) and all the<br />
AIX of several related <strong>VSAM</strong> clusters.<br />
RLS client<br />
This is any address space which invokes a RLS function which results in a PC to<br />
the SMS<strong>VSAM</strong> address space. Examples of RLS functions are: OPENs,<br />
CLOSEs, GETs, PUTs, DELETEs, and so on. Examples of RLS client spaces<br />
are CICS, "batch jobs", CATALOG, DSS, HSM, and so on.<br />
Subsystem<br />
This is an RLS client space that "registers" with the SMS<strong>VSAM</strong> address space as<br />
an address space that provides recovery (that is, forward/backward logging).<br />
CICS is an example of recoverable subsystem.<br />
Batch<br />
This is an RLS client address space that does not first register with SMS<strong>VSAM</strong><br />
as a recoverable subsystem (that is, does not provide logging). Examples of<br />
batch address spaces are: non-CICS <strong>VSAM</strong> applications, Batch, CATALOG,<br />
DSS, HSM, and so on).
Record lock<br />
This is an XES lock resource obtained by SMS<strong>VSAM</strong> on behalf of a user and<br />
associated with a logical record. The lock resource name is based on a 16 byte<br />
hashed version of the record's key (or RBA, or RRN), as well as the sphere name<br />
and component name. There are also other locks to serialize splits, for example.<br />
True contention<br />
This is when two different "users" attempt to access the same record lock at the<br />
same time. Reported as true contention on the D SMS,CFLS command and in<br />
RMF reports. You need to tune your application if you have high true contention<br />
rates, or use NRI for reads.<br />
False contention<br />
This is when <strong>VSAM</strong> RLS assigns locked resources to an entry value in the lock<br />
table, and uses this entry value to quickly check whether a resource is already<br />
locked. If the lock structure (and thus the lock table) is too small, many locks can<br />
be represented by a single value, making "false" lock contention possible. False<br />
lock contention occurs when two different locks on different resources attempt to<br />
use the same lock entry. The second lock requester is suspended until <strong>VSAM</strong><br />
RLS determines that there is no real lock contention on the resource.<br />
This is reported as false contention on the D SMS,CFLS command. For high<br />
false contention rates need to create a larger lock structure.<br />
True/False or False/False contention<br />
This occurs when either true contention or false contention occurs, and the<br />
holder releases the record before the RLS contention exit runs. At this point RLS<br />
cannot tell between true or false contention. This type of contention is reported<br />
as false contention on the D SMS,CFLS. See Figure 5-13.<br />
Deadlocks<br />
This occurs when two different transactions, each holding a record lock, attempt<br />
to obtain the other transactions record lock. SMS<strong>VSAM</strong> abnormally terminates<br />
one of the waiting lock requests (RPL RC=8 RSN=21), based on the<br />
Deadlock_detection value in your IGDSMSxx. Refer to 3.2.16, “Deadlocks” on<br />
page 160.<br />
Read integrity<br />
SMS<strong>VSAM</strong> allows the user to decide about read integrity through parameters in<br />
DD card or ACB macro. If the option is consistent read (CR), logical records locks<br />
are required in shared mode for reads. If the option is no read integrity (NRI), no<br />
locks are required along reads.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 251
252 <strong>VSAM</strong> <strong>Demystified</strong><br />
Retained lock<br />
This is a record lock obtained by a recoverable subsystem such as CICS, which<br />
was still held at the time of a failure in: CICS, IGWLOCK00, CF, z/OS, other<br />
SMS<strong>VSAM</strong>, or Indoubt transactions. A job can be cancelled without retained<br />
locks because this job dose not register, as subsystem with SMS<strong>VSAM</strong>.<br />
Lost Locks<br />
A sphere is said to be in "Lost Locks" if the sphere was being accessed by a<br />
recoverable subsystem when a failure to the lock structure occurs at the same<br />
time as a failure in at least one of the SMS<strong>VSAM</strong> address spaces (double failure<br />
scenario). Use the IDCAMS SHCDS LISTSUBSYS(ALL) command to list CICS<br />
subsystems holding retained or lost locks. This situation can be avoided by<br />
duplexing or failure isolation.<br />
Recoverable sphere<br />
This is a <strong>VSAM</strong> sphere which is accessed by a recoverable subsystem (that is,<br />
CICS) which provides logging for the sphere. A recoverable sphere is defined by<br />
the LOG(UNDO/ALL) attribute in the catalog.<br />
Non-recoverable sphere<br />
This is a <strong>VSAM</strong> sphere for which no logging is required. A non-recoverable<br />
sphere is defined with the LOG(NONE) attribute in the catalog.<br />
Quiesce a sphere<br />
There is a special interface provided by RLS for CICS to close a sphere across<br />
the sysplex. QUIESCE = YES is set in the catalog following the quiesce request.<br />
There is a command “D SMS,SMS<strong>VSAM</strong>,QUIESCE” on page 275, that shows<br />
the quiesce state of a sphere.<br />
Quiesce transactions<br />
There is a special interface provided to CICS and DSS, to temporarily halt<br />
transactions for a given sphere in order for DSS to take a sharp copy (also called<br />
a T0 copy).<br />
Quiesce a volume or a cache<br />
There is a command to SMS<strong>VSAM</strong> to stop new opens for RLS to a particular<br />
volume or cache. The formats are as follows:<br />
V SMS,CFVOL(volid),QUIESCE<br />
V SMS,CFCACHE(cachename),QUIESCE
Sharing control<br />
This is a set of routines executing in the SMS<strong>VSAM</strong> address space which open,<br />
format, read and write to the Sharing Control data sets (SHCDS). SHCDS -<br />
Linear data sets, accessed by SMS<strong>VSAM</strong> in non-RLS mode which contain<br />
"state" type information about RLS client spaces and <strong>VSAM</strong> spheres accessed<br />
by SMS<strong>VSAM</strong>.<br />
RLS mode<br />
A sphere is said to be in RLS mode when it was last accessed by RLS. RLS<br />
mode is indicated by the RLS-IN-USE indicator in the catalog.<br />
5.3 Planning for RLS<br />
This topic covers planning activities needed to implement RLS.<br />
5.3.1 Hardware requirements<br />
<strong>VSAM</strong> RLS uses the coupling facility (CF) to perform sphere level locking, record<br />
locking, and data caching. If your system is running in a sysplex you already have<br />
the necessary hardware to implement <strong>VSAM</strong> RLS.<br />
If you are going to implement system-managed duplexing for RLS lock structure<br />
for improved availability, then you would require additional CF storage, CF<br />
processor capacity, and z/OS-to-CF link capacity in order to accommodate<br />
duplexed <strong>VSAM</strong> RLS lock structure instances, and the duplexed <strong>VSAM</strong> RLS lock<br />
structure operations to them from each participating z/OS image.<br />
Note: If you want to implement <strong>VSAM</strong> RLS on a standalone z/OS system, to<br />
share <strong>VSAM</strong> across multiple address spaces, then you must not run in<br />
XCFLOCAL mode. A coupling facility is still needed for the lock structures<br />
even though there is only a single z/OS image.<br />
5.4 Implementing <strong>VSAM</strong> RLS<br />
We describe the step-by-step procedure to implement <strong>VSAM</strong> RLS.<br />
5.4.1 Define Sharing Control Data Set (SHCDS)<br />
Here we give some considerations and examples to define SHCDS.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 253
254 <strong>VSAM</strong> <strong>Demystified</strong><br />
What is its function?<br />
The SHCDS is critical to maintaining data integrity in the event of the failures of<br />
the Parallel Sysplex, SMS<strong>VSAM</strong> address space or the CF lock structure.<br />
The SHCDS contains the name of the CF lock structure in use, a list of<br />
subsystems, the status of the subsystems, a list of open spheres using the CF<br />
and other information.<br />
How do I define it?<br />
You must use the following naming convention when defining your SHCDSs:<br />
SYS1.DFPSHCDS.qualifier.Vvolser<br />
Where:<br />
qualifier is a 1 to 8 character qualifier.<br />
volser is the volume serial number. The V prefix allows you to specify numeric<br />
volume serial numbers.<br />
Important: The SHCDS naming convention depends on the volume to match<br />
the SHCDS name. So do not move SHCDS across volumes.<br />
How much space to allocate for SHCDS?<br />
Use the following formula to calculate the size of your SHCDS:<br />
S = (16 + (N * (16 + C/10))) kilobytes<br />
Where:<br />
S is the space required for the SHCDS.<br />
N is the number of systems.<br />
C is the number of concurrent OPEN requests that you expect.<br />
Sample JCL to allocate SHCDS<br />
The SHCDS may be defined using IDCAMS. See Example 5-1.<br />
Example 5-1 Allocate SHCDS by IDCAMS<br />
//ALLOCLD1 EXEC PGM=IDCAMS<br />
//SYSPRINT DD SYSOUT=*<br />
//SYSIN DD *<br />
DEFINE CLUSTER (NAME(SYS1.DFPSHCDS.PRIMARY.VSMS001) LINEAR -<br />
STORCLAS(GSPACE) -<br />
SHAREOPTIONS(3 3) CYL(10 10) VOLUME(SMS001) )<br />
DEFINE CLUSTER (NAME(SYS1.DFPSHCDS.SECONDARY.VSMS002) LINEAR -<br />
STORCLAS(GSPACE) -<br />
SHAREOPTIONS(3 3) CYL(10 10) VOLUME(SMS002) )
DEFINE CLUSTER (NAME(SYS1.DFPSHCDS.SPARE.VSMS003) LINEAR -<br />
STORCLAS(GSPACE) -<br />
SHAREOPTIONS(3 3) CYL(10 10) VOLUME(SMS003) )<br />
/*<br />
Example 5-2 shows how you can also use DD statements in JCL to allocate<br />
these spheres. Use a data class defined with a cross-region share options value<br />
of 3 and a cross-system share options value of 3.<br />
Example 5-2 Allocating SHCDS using JCL DD statements<br />
//PRISHCDS DD DSN=SYS1.DFPSHCDS.PRIMARY.VSMS001,SPACE=(1,(10,10)),<br />
// RECORG=LS,STORCLAS=GSPACE,VOL=SER=SMS001,AVGREC=M,<br />
// DISP=(NEW,CATLG)<br />
//SECSHCDS DD DSN=SYS1.DFPSHCDS.SECONDRY.VSYS002,SPACE=(1,(10,10)),<br />
// RECORG=LS,VOL=SER=SYS002,AVGREC=M,<br />
// DISP=(NEW,CATLG)<br />
//SPRSHCDS DD DSN=SYS1.DFPSHCDS.SPARE.VSMS003,SPACE=(1,(10,10)),<br />
// RECORG=LS,STORCLAS=GSPACE,VOL=SER=SMS003,AVGREC=M,<br />
// DISP=(NEW,CATLG)<br />
/*<br />
SHCDS considerations<br />
► At a minimum, define and activate two SHCDSs and at least one spare<br />
SHCDS for recovery purposes.<br />
► Because the contents of these data sets are highly dynamic, we do not<br />
recommend backup and restore functions for these data sets.<br />
► The SHCDS is a <strong>VSAM</strong> linear data set.<br />
► The CISIZE for SHCDS must be 4096.<br />
► When defined, the SHCDS does not need to be catalogued on all systems in<br />
the sysplex. If it is cataloged, it must be in a catalog available when<br />
SMS<strong>VSAM</strong> initializes.<br />
► If the SYS1.DFPSHCDS.qualifier.Vvolser cannot be catalogued into the<br />
MCAT, use the multi level alias (MLA) facility (2 levels at least) and define a<br />
SYS1.DFPSHCDS as alias in the MCAT.<br />
► Place the SHCDSs on volumes with global connectivity.<br />
► The share options for SHCDSs must be set to (3,3) so that each system in the<br />
Parallel Sysplex can properly share the data sets.<br />
► Use storage classes defined with the guaranteed space attribute.<br />
► Avoid placing SHCDSs on volumes for which there might be extensive volume<br />
reserve activity.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 255
256 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Secondary space definition is strongly recommended. All extents for each<br />
data set must be on the same volume.<br />
► SMS<strong>VSAM</strong> remembers the SHCDSs from one SMS<strong>VSAM</strong> recycle to the<br />
next. Do not delete or redefine an active or spare SHCDS without first telling<br />
SMS<strong>VSAM</strong>. Use the command V SMS,SHCDS(shcdsname),DELETE.<br />
► SMS<strong>VSAM</strong> must be RACF authorized to update SYS1.DFPSHCDS.* data<br />
sets. Refer to “Security definitions” on page 263.<br />
► For some SHCDS errors, an IPL would NOT help because SHCDS is<br />
remembered from one IPL to another. FALLBACK procedure documented in<br />
“SHCDS FALLBACK procedure” on page 267 is the only way to correct the<br />
problem. If you get repeated abends with the prefix '67' in the RSN code, then<br />
you know it's time to do a FALLBACK.<br />
Important: Use the FALLBACK procedure only as the last resort when<br />
everything else fails.<br />
5.4.2 Define CF cache structures<br />
<strong>VSAM</strong> RLS uses the Coupling Facility (CF) which is accessible from all the z/OS<br />
systems in the sysplex to maintain cache and lock structures to administer <strong>VSAM</strong><br />
RLS. You can define several cache structures but just one lock structure.<br />
What is its function?<br />
The CF cache structure maintains RLS local buffer pool consistency at the<br />
control interval (CI) level of all SMS<strong>VSAM</strong> instances in a Parallel Sysplex. CF<br />
cache structures contains the control block structure, being used as a system<br />
buffer pool for <strong>VSAM</strong> RLS, providing a level of storage hierarchy between local<br />
storage buffers and DASD cache. That is, RLS uses the cache structure for<br />
store-through caching; along writes data is written from local buffer pool to DASD<br />
as well as to the cache structure.<br />
How to define it?<br />
You use the IXCM2APU utility program to define the cache structures in the<br />
CFRM couple data set. You should coordinate this activity with your z/OS<br />
systems programmer. See the sample JCL in Example 5-3 to define the cache<br />
structures.<br />
Example 5-3 JCL to define RLS cache structures<br />
//STEP01 EXEC PGM=IXCM2APU<br />
//STEPLIB DD DSN=SYS1.MIGLIB,DISP=SHR<br />
//SYSPRINT DD SYSOUT=H<br />
//SYSIN DD *
*<br />
DATA TYPE(CFRM) REPORT(YES)<br />
DEFINE POLICY NAME(yourpolicy) REPLACE(YES)<br />
STRUCTURE NAME(CACHE01)<br />
SIZE(4000)<br />
INITSIZE(3000)<br />
PREFLIST(yourCF1)<br />
STRUCTURE NAME(CACHE02)<br />
SIZE(4000)<br />
INITSIZE(3000)<br />
PREFLIST(yourCF2)<br />
How to determine the cache size?<br />
The total size of the cache structures should ideally be equal to the sum of the<br />
local <strong>VSAM</strong> LSR buffer pool sizes. After you get that figure, you should divide this<br />
size among the structures that will be defined. You can use the sizing tool<br />
available at the following IBM site.<br />
http://www-1.ibm.com/servers/eserver/zseries/cfsizer/vsamrls.html<br />
Multiple cache structures<br />
Once you have determined the total CF cache required, you may need to break<br />
this down into individual cache structures. You can define multiple SMS<strong>VSAM</strong><br />
cache structures on different CFs and assign one or more CF cache structures to<br />
each cache set associated with a storage class.<br />
To make it simple, (1) the sphere points to a storage class; (2) the storage class<br />
has the cache set name; (3) the cache set (in base SMS ACDS) has the name(s)<br />
of the structure(s).<br />
Having multiple cache sets allows you to provide different performance attributes<br />
for spheres with distinct performance requirements. When more than one CF<br />
cache structure is assigned to a cache set, spheres within that storage class are<br />
cached in each CF structure in turn, in an effort of SMS<strong>VSAM</strong> to balance the<br />
load.<br />
Considerations<br />
Cache structures are built at open time and they remain even after the close of a<br />
sphere due to performance reasons (kept attribute). RLS uses LRU algorithms to<br />
release the structures.<br />
Cache must be large enough for the CF cache directories to contain an entry for<br />
each of the <strong>VSAM</strong> RLS local buffers across all instances of the RLS server.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 257
258 <strong>VSAM</strong> <strong>Demystified</strong><br />
Enhancements allow <strong>VSAM</strong> spheres with a CI size greater than 4 KB records to<br />
be cached.<br />
5.4.3 Define CF lock structures<br />
Here we explain how to define the lock structures.<br />
What is its function?<br />
The CF lock structure maintains the record-level locks and sphere-level locks to<br />
enforce global serialization. The CF lock structure includes two parts:<br />
► The lock table, which is used to determine whether there is R/W interest<br />
among systems on a particular resource<br />
► Record table space to keep track of information for retained locks and<br />
spheres which have been processed by <strong>VSAM</strong> RLS<br />
How do I define it?<br />
The CF lock structure is named IGWLOCK00. You can use the same IXCMIAPU<br />
utility that you used for CF cache structure to define the lock structure in the<br />
CFRM couple data set, as well. See Figure 5-5 for sample jcl.<br />
//STEP01 EXEC PGM=IXCMIAPU<br />
//STEPLIB DD DSN=SYS1.MIGLIB,DISP=SHR<br />
//SYSPRINT DD SYSOUT=H<br />
//SYSIN DD *<br />
DATA TYPE(CFRM) REPORT(YES)<br />
DEFINE POLICY NAME(CONFIG1) REPLACE(YES)<br />
STRUCTURE NAME(IGWLOCK00)<br />
SIZE(4000)<br />
PREFLIST(yourCF01)<br />
Figure 5-5 An example of defining a CF lock structure<br />
How to determine the lock structure size?<br />
You can use the following formula to estimate an initial size for the lock structure.<br />
Size in Mega Bytes=10 * number_of_systems * lock_entry_size<br />
The lock_entry_size depends on the MAXSYSTEM value defined for the sysplex<br />
couple data set when it was initially defined by the IXCL1DSU format utility. The<br />
MAXSYSTEM value represents the maximum number of systems that can be<br />
exist in the Parallel Sysplex.
The lock_entry_size is 2 if the MAXSYSTEM is 7 or less. It is 4 if MAXSYSTEM<br />
>= 8 and < 24 and will be 8 if MAXSYSTEM >= 24 and
5.4.4 SMS definitions<br />
260 <strong>VSAM</strong> <strong>Demystified</strong><br />
This section defines which CF cache structures can be used to assign a <strong>VSAM</strong><br />
sphere.<br />
Define the CF cache structures names to SMS<br />
SMS<strong>VSAM</strong> uses the SMS storage class construct, that you define, to determine<br />
which CF cache structures (varying sizes and performance levels) can be used<br />
to assign a <strong>VSAM</strong> sphere to a CF cache structure. Refer to Figure 5-7 and<br />
Figure 5-8.<br />
Based on this you would then group similar (1 to 255) cache structures into<br />
cache sets. The storage classes SC54GRT and SCRLS have a pointer to a<br />
“cache set” named CSERLS.<br />
These cache sets are defined in the BASE SMS construct and contains a list of<br />
CF cache structures, in the example: RLS_CACHE1 and RLS_CACHE2.<br />
A <strong>VSAM</strong> sphere opened in RLS mode must have a storage class assigned to it.<br />
The first time an RLS <strong>VSAM</strong> sphere is opened in the Sysplex, SM<strong>VSAM</strong> picks<br />
the best cache structure to use for the requested <strong>VSAM</strong> sphere and attempts to<br />
connect with it.
Panel List Utilities Scroll Help<br />
------------------------------------------------------------------------------<br />
STORAGE CLASS LIST<br />
Command ===> Scroll ===> HALF<br />
Entries 11-21 of 28<br />
View in Use<br />
CDS Name : SYS1.SMS.SCDS<br />
Enter Line Operators below:<br />
LINE STORCLAS SUSTAINED DATA CF CACHE CF DIRECT CF SEQUENTIAL<br />
OPERATOR NAME RATE (MB/SEC) SET NAME WEIGHT WEIGHT<br />
---(1)---- --(2)--- -----(15)----- --(16)-- --(17)--- ----(18)-----<br />
SCRLS --- CSERLS 6 6<br />
SCSDR1 --- -------- -- --<br />
SCSDR12 12 -------- -- --<br />
SCSDR32 32 -------- -- --<br />
SCTEST --- -------- -- --<br />
SC54GRT --- CSERLS 5 3<br />
SC54LOW --- -------- -- --<br />
SC54STD --- -------- -- --<br />
SC54TAPE --- -------- -- --<br />
STANDARD --- -------- -- --<br />
STRIPE 7 -------- -- --<br />
Figure 5-7 CF cache set in Storage Class<br />
CF CACHE SET DISPLAY PAGE 1 OF 1<br />
Command ===><br />
SCDS Name : SYS1.SMS.SCDS<br />
Cache Set CF Cache Structure Names<br />
CSERLS RLS_CACHE1 RLS_CACHE2<br />
Figure 5-8 Cache Set assignment<br />
( 001 Cache Sets Currently Defined )<br />
Use UP/DOWN Command to View other Pages when multiple Pages are Shown;<br />
Use HELP Command for Help; Use END Command to Exit.<br />
There is also a weight storage class attribute indicating the data’s relative<br />
importance in the CF DIRECT WEIGHT or the CF SEQUENTIAL WEIGHT fields.<br />
Use the CF DIRECT WEIGHT field for direct data; use the CF SEQUENTIAL<br />
WEIGHT field for sequential data. The default is a weight value of 6. You can<br />
specify a value from 1 to 11, with 11 indicating the highest relative importance.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 261
262 <strong>VSAM</strong> <strong>Demystified</strong><br />
The greater the weight value, the more important it is that the data be assigned<br />
more cache resources less stealing), thereby improving cache hit rates for the<br />
data.<br />
Attention: SMS<strong>VSAM</strong> at z/OS 1.3 DFSMS only supports the default value. All<br />
data is assigned a weight value of 6 regardless of the value you specify.<br />
5.4.5 Modifying the PARMLIB IGDSMSxx Member<br />
In IGDSMSxx member you specify options for SYS<strong>VSAM</strong>.<br />
Note: There is one SMS<strong>VSAM</strong> address space in each image of z/OS.<br />
Example 5-4 shows the RLS parameters in bold.<br />
Example 5-4 IGDSMSxx parmlib member<br />
SMS ACDS(SYS1.SMS.ACDS)<br />
COMMDS(SYS1.SMS.COMMDS)<br />
INTERVAL(15)<br />
DINTERVAL(150)<br />
DEADLOCK_DETECTION(15,4)<br />
SMF_TIME(YES)<br />
CF_TIME(1800)<br />
RLSINIT(YES)<br />
RLS_MAX_POOL_SIZE(100)<br />
REVERIFY(NO)<br />
ACSDEFAULTS(NO)<br />
PDSESHARING(EXTENDED)<br />
TRACE(ON)<br />
SIZE(128K)<br />
TYPE(ALL)<br />
JOBNAME(*)<br />
ASID(*)<br />
SELECT(ALL)<br />
OAMPROC(OAM)<br />
RLSINIT<br />
To use <strong>VSAM</strong> RLS, the SMS<strong>VSAM</strong> address space should be up and running. If<br />
you specify RLSINIT=YES, the SMS<strong>VSAM</strong> address space starts as part of your<br />
system initialization at IPL. If you specify NO, you need to start it later via the<br />
VARY SMS<strong>VSAM</strong>,ACTIVE command. The default is NO.
CF_TIME<br />
Here you specify at what interval you want to collect SMF type 42 records<br />
containing information and statistics on CF cache and lock structures. The<br />
default is 3600 (one hour). Refer to “SMF record 42” on page 321.<br />
DEADLOCK_DETECTION<br />
This parameter specifies how frequently the dead lock detection routine is<br />
invoked to check for local and global deadlocks. The the local deadlock detection<br />
interval default is 15 seconds.<br />
It also specifies the number of local deadlock cycles that must expire before<br />
global deadlock detection is run, as a one to four digit numeric value in the range<br />
1-9999. The default is 4 cycles. Refer to “What is a deadlock?” on page 160.<br />
RLS_MAX_POOL_SIZE<br />
This is the maximum buffer pool size SMS<strong>VSAM</strong> can use in MB. The default is<br />
100 MB.<br />
SMF_TIME<br />
For systems running DFSMS/MVS Version 1.3 or later, this keyword specifies<br />
whether DFSMS is to use SMF timing; that is, whether SMF type 42 records are<br />
to be created at the expiration of the SMF interval period, synchronized with SMF<br />
and RMF data intervals.<br />
5.4.6 Security definitions<br />
This section provides security definitions for access to the SHCDS data set and<br />
access to use VARY SHCDS command.<br />
Access to SHCDS<br />
You should provide update access for SMS<strong>VSAM</strong> to the SCHCDS data set.<br />
SMS<strong>VSAM</strong> should be authorized to update SYS1.DFPSHCDS.* data sets. If you<br />
protect SYS1.* data sets, be sure that the userid associated with SMS<strong>VSAM</strong> is<br />
able to access SYS1.DFPSHCDS.* for update.<br />
You can issue the RACF command RLIST STARTED SMS<strong>VSAM</strong>,ALL to find out<br />
the userid associated with SMS<strong>VSAM</strong>.<br />
Use the following RACF command to give SMS<strong>VSAM</strong> access to SHCDS:<br />
PERMIT SYS1.DFPSHCDS.* ACCESS(UPDATE) ID(smsvsam_userid)<br />
Figure 5-9 shows the error messages you will get due to SHCDS access failure.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 263
264 <strong>VSAM</strong> <strong>Demystified</strong><br />
Attention: If you do not provide the necessary RACF access authority to<br />
SMS<strong>VSAM</strong> it will fail to initialize.<br />
Access to use VARY SHCDS command<br />
To use the SHCDS command you should have should have access to the facility<br />
class STGADMIN.IGWSHCDS.*. You can use the following RACF command to<br />
provide this access.<br />
PERMIT STGADMIN.IGWSHCDS.* CLASS(FACILITY) ID(youruserid)<br />
ICH408I JOB(SMS<strong>VSAM</strong> ) STEP(SMS<strong>VSAM</strong> ) 744<br />
SYS1.DFPSHCDS.WTSCPLX2.VSBOX52 CL(DATASET ) VOL(SBOX52)<br />
INSUFFICIENT ACCESS AUTHORITY<br />
FROM SYS1.DFPSHCDS.* (G)<br />
ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE )<br />
IEF196I IEC161I 040(056,006,IGG0CLFT)-002,IEESYSAS,SMS<strong>VSAM</strong>,SYS00<br />
IEC161I 040(056,006,IGG0CLFT)-002,IEESYSAS,SMS<strong>VSAM</strong>,SYS00001,,,<br />
IEF196I IEC161I SYS1.DFPSHCDS.WTSCPLX2.VSBOX52<br />
IEC161I SYS1.DFPSHCDS.WTSCPLX2.VSBOX52<br />
IEA794I SVC DUMP HAS CAPTURED: 760<br />
DUMPID=001 REQUESTED BY JOB (SMS<strong>VSAM</strong> )<br />
DUMP TITLE=COMPID=DF122,CSECT=IGWXSI20+0490,DATE=04/16/00,MAINT<br />
ID= NONE ,ABND=0F4,RC=00000024,RSN=67510404<br />
RSN67510404 67510404<br />
Figure 5-9 SMS<strong>VSAM</strong> errors due to SHCDS access failure<br />
5.4.7 Using a <strong>VSAM</strong> sphere in RLS mode<br />
When all the above actions are implemented, the system is ready for <strong>VSAM</strong> RLS<br />
processing.<br />
To enable a <strong>VSAM</strong> sphere for RLS the following actions need to be taken:<br />
► LOG parameter (NONE, UNDO or ALL) must be specified on the DEFINE<br />
CLUSTER or the ALTER CLUSTER command for the sphere. Or you may<br />
select one of the data classes containing such parameter.<br />
► Option RLS in MACRF keyword in ACB (refer to “ACB control block” on<br />
page 235) needs to be set. There is also the option RLSREAD keyword in<br />
ACB where you indicate the type of read integrity (NRI or CR). Another way is<br />
using the keyword RLS= (NRI / CR) in the DD card defining the sphere.
Attention: Your RLS specification about read integrity on the ACB<br />
(RLSREAD) overrides the RLS specification on your JCL, if you specify in both<br />
places.<br />
Figure 5-10 shows the messages presented in the MVS console when a job<br />
using RLS starts.<br />
IEF403I MHL#64C5 - STARTED - TIME=22.10.03 - ASID=0027 - SC64<br />
ICH70001I MHLRES2 LAST ACCESS AT 21:53:13 ON FRIDAY, MARCH 14, 2003<br />
$HASP373 MHL#63C5 STARTED - INIT 2 - CLASS A - SYS SC63<br />
IGW500I DFSMS CACHE CHARACTERISTICS FOR 705<br />
<strong>VSAM</strong> COMPONENT NAME: MHLRES2.<strong>VSAM</strong>.RLSEXT.INDEX<br />
DFSMS CF CACHE STRUCTURE NAME: RLS_CACHE<br />
CI SIZE: 1536<br />
CF CACHING SIZE: 2048<br />
DFSMS DATACLASS NAME: RMMCDS<br />
DFSMS RLSCFCACHE DATACLASS KEYWORD VALUE: ALL<br />
IGW500I DFSMS CACHE CHARACTERISTICS FOR 706<br />
<strong>VSAM</strong> COMPONENT NAME: MHLRES2.<strong>VSAM</strong>.RLSEXT.DATA<br />
DFSMS CF CACHE STRUCTURE NAME: RLS_CACHE<br />
CI SIZE: 4096<br />
CF CACHING SIZE: 4096<br />
DFSMS DATACLASS NAME: RMMCDS<br />
DFSMS RLSCFCACHE DATACLASS KEYWORD VALUE: ALL<br />
Figure 5-10 MVS messages for a JOB using RLS<br />
5.4.8 RLS Recoverable spheres<br />
A recoverable sphere has an associated log and in a problem appearance it can<br />
be processed for undo and also for redo. This attribute set in the catalog entry, by<br />
DEFINE/ ALTER LOG keyword, is referred to a <strong>VSAM</strong> cluster.<br />
The LOG keyword has the following options: NONE, UNDO or ALL (UNDO plus<br />
REDO), with the following properties:<br />
NONE means that the sphere is non-recoverable implying no logging. When this<br />
option is used neither backout nor forward recovery logging is performed. If either<br />
software or hardware damages the cluster, it will not be possible to recover the<br />
cluster.<br />
The other two options (UNDO or ALL) imply that the accessing application uses<br />
a commit protocol allowing a recovery function through a log, in this case the<br />
CICS log.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 265
266 <strong>VSAM</strong> <strong>Demystified</strong><br />
UNDO means that transactional recovery is required. To support this option, the<br />
accessing application must support a two phase commit and backout protocol.<br />
During the life of a transaction, changes are protected by record level locks which<br />
prevent the changes from being seen by other applications that also support<br />
locking.<br />
REDO means a forward recovery capability in the case of a lost or overlaid<br />
sphere. If you do not have an application that can perform forward recovery of the<br />
<strong>VSAM</strong> sphere, such as CICS/VR, there is no point in specifying LOG(ALL). It<br />
generates the overhead of creating the redo images of the records, but no ability<br />
to do anything with that information.<br />
5.5 RLS problem determination and recovery<br />
In this section we describe common problems with RLS and suggest some<br />
actions. There are a number of information APARs in IBMLINK that describe<br />
common problems in <strong>VSAM</strong> and what you can do resolve them. These APARs<br />
also tell you what documents you should collect before reporting the problem to<br />
IBM. Please review APAR II12927 as a starting point.<br />
5.5.1 Problems with SHCDS<br />
Please review “SHCDS considerations” on page 255 to ensure that you have<br />
taken care of those issues when you defined your SHCDS. Refer to information<br />
APAR II13326 (“II13326 - Common problems with SHCDS” on page 444) for<br />
guidelines to diagnose SHCDS problems. Also review IBMLINK items<br />
BDC000010564 (“BDC000010564” on page 451) and BDC000007033<br />
(“BDC000007033” on page 459).<br />
5.5.2 Problems with SMS<strong>VSAM</strong><br />
You can get into SMS<strong>VSAM</strong> initialization problems due to various reasons. One<br />
of the most common causes is when SMS<strong>VSAM</strong> does not have access to your<br />
SHCDS. Information APAR II12603 (“II12603” on page 465) gives you some tips<br />
to diagnose and recover from SMS<strong>VSAM</strong> problems. APAR II12243 (“II12243” on<br />
page 467) tells you how to properly terminate SMS<strong>VSAM</strong>.<br />
5.5.3 Problems with locks<br />
Please remember that if an SMS<strong>VSAM</strong> is holding a lock only that SMS<strong>VSAM</strong> can<br />
release it. If you get into locking problems, even an IPL may not resolve the<br />
problem if the lock is held by another SMS<strong>VSAM</strong> on another system in the<br />
sysplex. IBMLINK has some information that will help you with lock problems.
IBMLINK entry BDC000022923 (“BDC000022923” on page 468) describes a<br />
looping problem if you define a very large size for your lock structure. Item<br />
RTA000141603 (“RTA000141603” on page 475) show how resolve IGWLOCK00<br />
rebuild problems due to loss of connectivity to the sysplex.<br />
5.5.4 SHCDS FALLBACK procedure<br />
5.5.5 RLS rules<br />
For some SHCDS errors, FALLBACK is the only way to correct the problem and<br />
to get the SMS<strong>VSAM</strong> to initialize successfully again. If you get repeated abends<br />
with the prefix “67” in the RSN code, you may have to rely on FALLBACK as the<br />
last resort. The following errors might require FALLBACK:<br />
► Abend0F4 RC24 RSN675D0355<br />
► Abend0F4 RC24 RSN67260989<br />
► Abend0F4 RC24 RSN675F0398<br />
Attention: If you have serious problems with SHCDS an IPL would NOT fix<br />
the problem because SHCDS name is remembered from one IPL to another<br />
FALLBACK procedure is documented in z/OS V1R3.0 DFSMSdfp Storage<br />
Administration Reference. In a nutshell, FALLBACK reformats the SHCDS and<br />
therefore clears all the errors.<br />
FALLBACK involves:<br />
► Terminate all SMS<strong>VSAM</strong>s in the sysplex by issuing using the command:<br />
VARY SMS,SMS<strong>VSAM</strong>,TERMINATESERVER<br />
► Then issue the command: VARY SMS,SMS<strong>VSAM</strong>,FALLBACK<br />
► Reply Yes, to the WTOR that you are sure you want to FALLBACK<br />
► Reactivate SMS<strong>VSAM</strong> using the command: VARY SMS,SMS<strong>VSAM</strong>,ACTIVE<br />
On the first system, you will be asked to specify 2 ACTIVE and 1 SPARE<br />
SHCDS.<br />
To add an active SHCDS issues the command:<br />
VARY SMS,SHCDS(SHCDS_name),NEW<br />
To add a spare SHCDS issues the command:<br />
VARY SMS,SHCDS(SHCDS_name),NEWSPARE<br />
RLS enforces some rules when you have sphere open in RLS and non-RLS<br />
modes.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 267
268 <strong>VSAM</strong> <strong>Demystified</strong><br />
RLS open rules<br />
► RLS OPENs for input/output fails, if the sphere is already opened for non-RLS<br />
output.<br />
► RLS OPENs for input/output fails, if the sphere is already opened for non-RLS<br />
input, except if the sphere has been defined as SHAREOPTION(2,x). The<br />
non-RLS inputter does not have read integrity.<br />
► RLS OPENs for output of a recoverable sphere by a batch client fails.<br />
► RLS OPENs for a sphere which is either quiesced (or is quiescing) will be<br />
failed (QUIESCE=YES in catalog).<br />
► RLS OPENs for a sphere that has not been assigned a CF cache via the SMS<br />
STORCLAS construct fails.<br />
► Empty KSDSs - RLS allows opening of an empty KSDS without first loading<br />
the data set. In other modes (NSR, RLS) this is not possible.<br />
► Positioning - RLS does not do implicit positioning to the beginning of the data<br />
set for SEQ processing. An explicit POINT is required.<br />
Close and delete rules<br />
► A RLS CLOSE is “not successful” if the SMS<strong>VSAM</strong> address space has<br />
recycled since the ACB was opened. One of the following messages are<br />
presented: IEC251I 16-0608 or IEC251I 16-0609.<br />
► A Catalog DELETE deletes all retained or lost locks, if the owner is not an<br />
RLS subsystem. Refer to “RLS terminology” on page 250 to see the definition<br />
of an RLS subsystem. The DELETE does not delete CICS log records,<br />
because CICS is a subsystem.<br />
5.5.6 MVS commands for RLS<br />
Here are some commands to become familiar with. They have been changed or<br />
added to support RLS.<br />
D XCF,STR,STRNAME=IGWLOCK00<br />
Use this command to display the lock structure. See Figure 5-11 and Figure 5-12<br />
for sample output of the command.
D XCF,STR,STRNAME=IGWLOCK00<br />
IXC360I 19.59.09 DISPLAY XCF 097<br />
STRNAME: IGWLOCK00<br />
STATUS: REASON SPECIFIED WITH REBUILD START:<br />
OPERATOR INITIATED<br />
DUPLEXING REBUILD<br />
METHOD : SYSTEM-MANAGED<br />
AUTO VERSION: B8FC8279 72B01005<br />
REBUILD PHASE: DUPLEX ESTABLISHED<br />
POLICY INFORMATION:<br />
POLICY SIZE : 28600 K<br />
POLICY INITSIZE: 14300 K<br />
POLICY MINSIZE : 0 K<br />
FULLTHRESHOLD : 80<br />
ALLOWAUTOALT : NO<br />
REBUILD PERCENT: 75<br />
DUPLEX : ALLOWED<br />
PREFERENCE LIST: CF01 CF02<br />
ENFORCEORDER : NO<br />
EXCLUSION LIST IS EMPTY<br />
DUPLEXING REBUILD NEW STRUCTURE<br />
-------------------------------<br />
ALLOCATION TIME: 02/15/2003 11:16:05<br />
CFNAME : CF02<br />
COUPLING FACILITY: 002064.IBM.02.000000010ECB<br />
PARTITION: D CPCID: 00<br />
ACTUAL SIZE : 14336 K<br />
STORAGE INCREMENT SIZE: 256 K<br />
PHYSICAL VERSION: B8FC827A A4E7CF02<br />
LOGICAL VERSION: B8FC73F0 F2A13441<br />
SYSTEM-MANAGED PROCESS LEVEL: 8<br />
XCF GRPNAME : IXCLO001<br />
DISPOSITION : KEEP<br />
ACCESS TIME : NOLIMIT<br />
NUMBER OF RECORD DATA LISTS PER CONNECTION: 16<br />
MAX CONNECTIONS: 4<br />
# CONNECTIONS : 3<br />
CONNECTION NAME ID VERSION SYSNAME JOBNAME ASID STATE<br />
---------------- -- -------- -------- -------- ---- ----------------<br />
SC63 01 0001006E SC63 SMS<strong>VSAM</strong> 0009 ACTIVE NEW,OLD<br />
SC64 03 00030079 SC64 SMS<strong>VSAM</strong> 0009 ACTIVE NEW,OLD<br />
SC65 02 0002007A SC65 SMS<strong>VSAM</strong> 0009 ACTIVE NEW,OLD<br />
Figure 5-11 Display the lock structure<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 269
270 <strong>VSAM</strong> <strong>Demystified</strong><br />
DUPLEXING REBUILD OLD STRUCTURE<br />
-------------------------------<br />
ALLOCATION TIME: 02/15/2003 10:11:03<br />
CFNAME : CF01<br />
COUPLING FACILITY: 002064.IBM.02.000000010ECB<br />
PARTITION: E CPCID: 00<br />
ACTUAL SIZE : 14336 K<br />
STORAGE INCREMENT SIZE: 256 K<br />
PHYSICAL VERSION: B8FC73F0 F2A13441<br />
LOGICAL VERSION: B8FC73F0 F2A13441<br />
SYSTEM-MANAGED PROCESS LEVEL: 8<br />
XCF GRPNAME : IXCLO001<br />
ACCESS TIME : NOLIMIT<br />
NUMBER OF RECORD DATA LISTS PER CONNECTION: 16<br />
MAX CONNECTIONS: 4<br />
# CONNECTIONS : 3<br />
Figure 5-12 Display the lock structure (continued)<br />
D SMS,CFLS<br />
This command displays the following information about the CF lock structure:<br />
► Size<br />
► Status<br />
► Contention rate<br />
► False contention rate<br />
See Figure 5-13 for a sample output of the command.
-D SMS,CFLS<br />
IEE932I 236<br />
IGW320I 14:52:52 Display SMS,CFLS<br />
PRIMARY STRUCTURE:IGWLOCK00 VERSION:B8FC73F0F2A13441 SIZE:14336K<br />
RECORD TABLE ENTRIES:36258 USED:3<br />
SECONDARY STRUCTURE:IGWLOCK00 VERSION:B8FC827AA4E7CF02 SIZE:14336K<br />
RECORD TABLE ENTRIES:36258 USED:3<br />
LOCK STRUCTURE MODE: DUPLEXED<br />
System Interval LockRate ContRate FContRate WaitQLen<br />
14:52:52 Display SMS,CFLS<br />
SC64 1 Minute 3.3 25.969 0.000 0.33<br />
SC64 1 Hour 84.0 4.797 0.416 0.10<br />
SC64 8 Hour 17.8 1.004 0.092 0.01<br />
SC64 1 Day 7.7 0.354 0.044 0.00<br />
(03) 1 Minute 2.2 17.714 0.000 0.19<br />
(03) 1 Hour 56.0 3.220 0.282 0.05<br />
(03) 8 Hour 11.4 0.671 0.059 0.00<br />
(03) 1 Day 4.5 0.236 0.024 0.00<br />
***************** LEGEND ******************<br />
LockRate = number of lock requests per second<br />
***************** LEGEND ******************<br />
LockRate = number of lock requests per second<br />
CONTRATE = % of lock requests globally managed<br />
FCONTRATE = % of lock requests falsely globally managed<br />
WaitQLen = Average number of requests waiting for locks<br />
Figure 5-13 Sample output of D SMS,CFLS<br />
D SMS,CFCACHE(structurename or *)<br />
This command displays information about cache structures in the CF. See<br />
Figure 5-14 for a sample output.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 271
272 <strong>VSAM</strong> <strong>Demystified</strong><br />
-D SMS,CFCACHE(*)<br />
IEE932I 035<br />
IGW530I DFSMS CF STRUCTURES<br />
DFSMS CF CACHE STRUCTURE TO SYSTEM CONNECTIVITY<br />
SYSTEM ==> 00000000011111111112222222222333<br />
IDENTIFIER ==> 12345678901234567890123456789012<br />
RLS_CACHE ++..............................<br />
................ ................................<br />
SYSTEM 1 = SC64 SYSTEM 2 = SC65 SYSTEM 3 = ........<br />
SYSTEM 4 = ........ SYSTEM 5 = ........ SYSTEM 6 = ........<br />
SYSTEM 7 = ........ SYSTEM 8 = ........ SYSTEM 9 = ........<br />
SYSTEM 10 = ........ SYSTEM 11 = ........ SYSTEM 12 = ........<br />
SYSTEM 13 = ........ SYSTEM 14 = ........ SYSTEM 15 = ........<br />
SYSTEM 16 = ........ SYSTEM 17 = ........ SYSTEM 18 = ........<br />
SYSTEM 19 = ........ SYSTEM 20 = ........ SYSTEM 21 = ........<br />
SYSTEM 22 = ........ SYSTEM 23 = ........ SYSTEM 24 = ........<br />
SYSTEM 25 = ........ SYSTEM 26 = ........ SYSTEM 27 = ........<br />
SYSTEM 28 = ........ SYSTEM 29 = ........ SYSTEM 30 = ........<br />
SYSTEM 31 = ........ SYSTEM 32 = ........<br />
DFSMS CF CACHE TOTAL SPHERES ACTIVE CACHE<br />
STRUCTURE STATUS: CONNECTED: FEATURE LEVEL:<br />
RLS_CACHE = CF_ENABLED - -NONE-<br />
................ = ............ -<br />
................ = ............ -<br />
DFSMS CF CACHE FEATURE STATUS:<br />
A = SMS RlsCfCache Data Class values honored<br />
Figure 5-14 Sample of CFCACHE display<br />
Attention: If there is the name of the structure without the system names, it<br />
means that the structure is defined in SMS but does not exist in the CF.<br />
D SMS,CFVOL(volid)<br />
This command will display a list of coupling facilities cache structures that contain<br />
data for the specified volume (volid) and the status of the volume.
D SMS, MONDS(specmask or *)<br />
This command will display the sphere specifications eligible for coupling facilities<br />
statistics monitoring. This monitoring is activated by the command; see “VARY<br />
SMS,MONDS(dsname{,dsname...}),ON|OFF” on page 276. You can specify a full<br />
or partial sphere name (specmask) to view a subset of the sphere specifications.<br />
You must specify at least one high level qualifier. A wildcard in the sphere name<br />
cannot be followed by additional qualifiers. Specify ‘*’ to display all the sphere<br />
specifications eligible for coupling facilities statistics monitoring.<br />
D SMS,SHCDS<br />
This command will display the following information about the sharing control<br />
data sets.<br />
► Name<br />
► Size<br />
► Amount of free space for the active and spare SHCDS<br />
► Whether the data set is usable<br />
See Figure 5-15 for a sample output. Please note that it displays only the last two<br />
qualifiers of the SHCDS names. You should read it as<br />
SYS1.DFPSHCDS.WTSCPLX2.VSBOX48 and so on.<br />
-D SMS,SHCDS<br />
IEE932I 045<br />
IGW612I 19:01:43 DISPLAY SMS,SHCDS<br />
Name Size %UTIL Status Type<br />
WTSCPLX2.VSBOX48 10800Kb 4% GOOD ACTIVE<br />
WTSCPLX2.VSBOX52 10800Kb 4% GOOD ACTIVE<br />
WTSCPLX2.VSBOX49 10800Kb 4% GOOD SPARE<br />
----------------- 0Kb 0% N/A N/A<br />
----------------- 0Kb 0% N/A N/A<br />
----------------- 0Kb 0% N/A N/A<br />
----------------- 0Kb 0% N/A N/A<br />
----------------- 0Kb 0% N/A N/A<br />
----------------- 0Kb 0% N/A N/A<br />
----------------- 0Kb 0% N/A N/A<br />
Figure 5-15 Sample output of D SMS,SHCDS<br />
D SMS, SMS<strong>VSAM</strong> [,ALL]<br />
This will display the status of the SMS<strong>VSAM</strong> server on this system or all the<br />
SMS<strong>VSAM</strong> servers and lock table connection status.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 273
274 <strong>VSAM</strong> <strong>Demystified</strong><br />
.<br />
-D SMS,SMS<strong>VSAM</strong>,ALL<br />
IEE932I 049<br />
IGW420I DISPLAY SMS,SMS<strong>VSAM</strong>,ALL<br />
DISPLAY SMS,SMS<strong>VSAM</strong> - SERVER STATUS<br />
SYSNAME: SC64 AVAILABLE ASID: 0009 STEP: SmsVsamInitComplete<br />
SYSNAME: SC65 AVAILABLE ASID: 0009 STEP: SmsVsamInitComplete<br />
SYSNAME: SC63 AVAILABLE ASID: 0009 STEP: SmsVsamInitComplete<br />
DISPLAY SMS<strong>VSAM</strong> - JOB STATUS<br />
SUBSYSTEMS CONNECTED: 0 BATCH: 3<br />
DISPLAY SMS<strong>VSAM</strong> - LOCK TABLE STATUS (IGWLOCK00)<br />
CONNECT STATUS:<br />
SYSNAME: SC64 ACTIVE RSN: 02010407 RbldNotActive<br />
SYSNAME: SC65 ACTIVE RSN: 02010407 RbldNotActive<br />
SYSNAME: SC63 ACTIVE RSN: 02010407 RbldNotActive<br />
COMPOSITE STATUS:<br />
ORIGINAL STRUCTURE: NOT VOLATILE NOT FAILURE ISOLATED<br />
NEW STRUCTURE: NOT VOLATILE NOT FAILURE ISOLATED<br />
STRUCTURE STATUS:<br />
SYSNAME: SC64 Duplex<br />
SYSNAME: SC65 Duplex<br />
SYSNAME: SC63 Duplex<br />
DISPLAY SMS,SMS<strong>VSAM</strong> - SMF RECORD 42 STATUS<br />
SMF_TIME CF_TIME ----- SUB-TYPE SUMMARY -----<br />
15 16 17 18 19<br />
SYSNAME: SC64 YES- 3 1800- 3 YES YES YES YES YES<br />
SYSNAME: SC65 YES- 2 1800- 2 YES YES YES YES YES<br />
SYSNAME: SC63 *YES- 1 1800- 1 YES YES YES YES YES<br />
SYSNAME: ........ ....-.. ......-.. ... ... ... ... ...<br />
*SMS<strong>VSAM</strong> SMF 42 RECORDS ARE WRITTEN FROM THIS SYSTEM.<br />
RECORDS ARE WRITTEN WHEN SMF GLOBAL INTERVAL EXPIRES.<br />
DISPLAY SMS,SMS<strong>VSAM</strong> - GLOBAL CACHE FEATURE PARMLIB VALUES<br />
MAXIMUM CF CACHE FEATURE LEVEL = Z<br />
DISPLAY SMS,SMS<strong>VSAM</strong> - CACHE FEATURE CODE LEVEL VALUES<br />
SYSNAME: SC63<br />
CACHE FEATURE CODE LEVEL = A<br />
SYSNAME: SC65<br />
CACHE FEATURE CODE LEVEL = A<br />
SYSNAME: SC64<br />
CACHE FEATURE CODE LEVEL = A<br />
SYSNAME: ........<br />
CACHE FEATURE CODE LEVEL = .................................<br />
CACHE FEATURE LEVEL DESCRIPTION:<br />
Z = No Caching Advanced functions are available<br />
A = Greater than 4K Caching code is available<br />
Figure 5-16 Output of D SMS,<strong>VSAM</strong>,ALL
D SMS,SMS<strong>VSAM</strong>,QUIESCE<br />
This will display the status of all active <strong>VSAM</strong> record-level sharing (<strong>VSAM</strong>/RLS)<br />
sphere quiesce events on the system that the command is entered. (This is not a<br />
Sysplex-wide command.)<br />
SETSMS RLS_MAXCFFEATURELEVEL({A|Z})<br />
This command specifies the method that <strong>VSAM</strong> RLS uses to determine the size<br />
of the data that is placed in the CF cache structure. If you specify A, caching<br />
proceeds using the RLSCFCACHE keyword characteristics that are specified in<br />
the SMS data class that is defined for the <strong>VSAM</strong> sphere. If you do not specify a<br />
value, or if you specify Z, then only <strong>VSAM</strong> RLS data that have a Control Interval<br />
(CI) value of 4K or less are placed in the CF cache structure. The default is Z.<br />
Refer to “Modifying the PARMLIB IGDSMSxx Member” on page 262 for more<br />
information.<br />
SETSMS BMFTIME(nnnnn)<br />
This command specifies that SMS is to allow nnnnn seconds (1 to 86399) to<br />
elapse between the production of SMS BMF records. The default is 3600<br />
seconds.<br />
SETSMS LRUCYCLES(cycles)<br />
This will specify the maximum number of times (5 to 240) that the buffer<br />
management facility (BMF) least recently used (LRU) routine will pass over<br />
inactive buffers before making them available for reuse. While this parameter<br />
sets the maximum value, BMF will dynamically change the actual number of<br />
times it passes over inactive buffers.<br />
SETSMS LRUTIME(seconds)<br />
This command specifies the number of seconds (5 to 60) that the buffer<br />
management facility (BMF) will wait between calls to the BMF data space cache<br />
least recently used (LRU) routine. That routine releases inactive buffers in the<br />
BMF data space that are used to cache partitioned data set extended (PDSE)<br />
directory data. LRUTIME is related to LRUCYCLES. A change to the LRUTIME<br />
value introduced by this parameter will take effect on the next execution of the<br />
LRU routine. Most installations should use the default value. In some very high<br />
data rate situations you may want to tune this value. You should monitor the SMF<br />
42 type 1 record to determine the amount of caching activity in the BMF data<br />
space. See z/OS MVS System Management Facilities (SMF) for information<br />
about the buffer management statistics recorded in SMF record type 42. The<br />
default value is 15 seconds.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 275
276 <strong>VSAM</strong> <strong>Demystified</strong><br />
SETSMS CF-TIME(nnn or 3600)<br />
This command specifies the number of seconds between recording SMF 42<br />
records related to SMS<strong>VSAM</strong> coupling facility use (subtypes 15, 16, 17 and 18).<br />
SMF_TIME(YES) overrides this parameter.<br />
SETSMS DEADLOCK_DETECTION(iiii,kkkk)<br />
This command specifies the deadlock detection intervals used by SMS.<br />
iiii is a 1 to 4 digit numeric value in the range 1-9999 that specifies the length in<br />
seconds of the local deadlock detection interval. The default for iiii is 15 seconds.<br />
kkkk 1 to 4 digit numeric value in the range 1-9999 that specifies the number of<br />
local deadlock cycles that must expire before global deadlock detection is<br />
performed. The default for kkkk is 4 local cycles.<br />
VARY SMS,CFCACHE(structurename)<br />
Issue this command to change the state of a cache structure and specify the<br />
name of the cache structure.<br />
If you specify ENABLE, <strong>VSAM</strong> RLS data can be stored in cache structure. This is<br />
the normal state of operations and the state the coupling facility cache structure<br />
is in after sysplex IPL. If you specify QUIESCE, you cannot store any <strong>VSAM</strong> RLS<br />
data in the cache structure. The QUIESCE operation is not complete until the<br />
state of the volume is quiesced. Use the D SMS,CFVOL to determine the state of<br />
the volume.<br />
VARY SMS,CFVOL(volid)<br />
Use this command to change the state of a volume as it relates to coupling<br />
facility cache structures, specify the volume (volid). If you specify ENABLE, data<br />
contained on this volume can be stored in a coupling facility cache structure. This<br />
is the normal state of operations. If you specify QUIESCE, you cannot store any<br />
data from the volume on the coupling facility cache structure.<br />
Note: If you specify QUIESCE, SMS may still select the volume during data set<br />
allocation. To stop SMS from selecting this volume, see “Changing the SMS<br />
Status of a Storage Group or Volume” on page 575.<br />
VARY SMS,MONDS(dsname{,dsname...}),ON|OFF<br />
This will specify the data set name (dsname) or data set names<br />
(dsname{,dsname...}). If you want to be eligible for coupling facility statistical<br />
monitoring, specify ON. Now, the commands are generic for the CF structures.<br />
To indicate that the specified data set is no longer eligible for statistical<br />
monitoring, specify OFF. Monitoring is tracked through SMF record 42 subtype
16. You can specify a full or partial data set name with at least one high level<br />
qualifier. An asterisk cannot be followed by other qualifiers. You can specify up to<br />
16 data set names with each command. This command affects activity for the<br />
specified data sets across all systems in the sysplex.<br />
VARY SMS,SHCDS(shcdsname)<br />
Issue this command to add or delete a sharing control data set (SHCDS), specify<br />
the name of the SHCDS. If you specify NEW, a new active SHCDS named<br />
(shcdsname) will be added. If you specify NEWSPARE, a new spare SHCDS<br />
named (shcdsname) will be added. If you specify DELETE, a SHCDS named<br />
(shcdsname) will be deleted. This SHCDS can be either an active or a spare<br />
SHCDS. Note: The sharing control data set (SHCDS) is identified by the dsname<br />
SYS1.DFPSHCDS.qualifier.Vvolser. When specifying its name (shcdsname) in<br />
this command, do not use the fully-qualified name. Use only qualifier.Vvolser as<br />
the shcdsname, without the SYS1.DFPSHCDS prefix, when specifying the name<br />
of the SHCDS.<br />
VARY SMS,SMS<strong>VSAM</strong>, xxxxx<br />
Use this command to manage SMS<strong>VSAM</strong> data sets or the SMS<strong>VSAM</strong> address<br />
space, specify one of the following parameters where xxxxx is:<br />
► ACTIVE. Restarts the SMS<strong>VSAM</strong> server and re-enables the automatic restart<br />
facility for the server. This command will not function if the SMS<strong>VSAM</strong><br />
address space was terminated with a FALLBACK command.<br />
► SPHERE. Clears the <strong>VSAM</strong>-quiesced state for the specified sphere.<br />
Normally, this operation is done under application program control. This<br />
command is required only in rare circumstances.<br />
► FALLBACK. Is used as the last step in the disablement procedure to fall back<br />
from SMS<strong>VSAM</strong> processing. For the SMS<strong>VSAM</strong> fallback procedure, see<br />
z/OS DFSMSdfp Storage Administration Reference.<br />
► TERMINATESERVER. Abnormally terminates an SMS<strong>VSAM</strong> server. The<br />
server will not automatically restart after the termination. After some recovery<br />
action is complete, you can restart the SMS<strong>VSAM</strong> server with the V<br />
SMS,SMS<strong>VSAM</strong>,ACTIVE command. Use this command only for specific<br />
recovery scenarios that require the SMS<strong>VSAM</strong> server to be down and not to<br />
restart automatically.<br />
► FORCEDELETELOCKSTRUCTURE. Deletes the lock structure from the<br />
coupling facility and deletes any data in the lock structure at the time the<br />
command is issued. You must reply to the confirmation message with the<br />
response, FORCEDELETELOCKSTRUCTURESMS<strong>VSAM</strong>YES, before the<br />
command takes effect. Use this command only in the event of a volume loss.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 277
5.6 RLS enhancements<br />
278 <strong>VSAM</strong> <strong>Demystified</strong><br />
What follows is a list of RLS enhancements. The majority of them are introduced<br />
in z/OS DFSMS 1.3. Refer to “<strong>VSAM</strong> functions by release level” on page 2.<br />
5.6.1 RLS/KSDS extended addressability<br />
When <strong>VSAM</strong> RLS support was announced with DFSMS/MVS V1R3, it did not<br />
support <strong>VSAM</strong> KSDS extended addressability (EA) format. In other words <strong>VSAM</strong><br />
RLS component retained the 4 GB architectural limit for the component size<br />
imposed by using the 4-byte field for the relative byte address (RBA) addressing<br />
mechanism. DFSMS/MVS V1R4 removed this restriction by supporting RLS EA<br />
for <strong>VSAM</strong> KSDSs, and therefore <strong>VSAM</strong> RLS now supports <strong>VSAM</strong> KSDSs up to<br />
the current multivolume limit of 59 DASD volumes.<br />
As in <strong>VSAM</strong> non-RLS extended addressability, a <strong>VSAM</strong> RLS extended<br />
addressability KSDS must have its data class defined with:<br />
Data Set Name Type =EXT<br />
If Ext =P or R<br />
Extended Addressability =Y<br />
5.6.2 <strong>VSAM</strong> RLS CF structure duplexing and rebuild<br />
<strong>VSAM</strong> RLS goes to lost locks state when the CF lock structure is lost and a<br />
system is also lost — a disruptive condition.<br />
This process consists of the lock structure rebuild with all of the active <strong>VSAM</strong><br />
RLS instances with the steps of allocating a new structure instance, propagating<br />
the lock data to the new structure, and switching over to using the new structure<br />
instance.<br />
Currently, z/OS supports four types of lock structure rebuild processes. They are<br />
► User-managed rebuild<br />
► User-managed duplexing rebuild<br />
► System-managed rebuild<br />
► System-managed duplexing rebuild<br />
User-managed rebuild<br />
This enhancement to the current user-managed rebuild process will minimize the<br />
possibility of running out of record table space. Prior to this enhancement, if<br />
record space is exhausted, either an 0F4 abend or a record management error<br />
will occur. This enhancement adds a new validation check function during the
user-managed rebuild process for the lock structure. When rebuild tries to<br />
change a lock structure and the size of the record table is greater than 50%, this<br />
new function will determine if the new table has enough space for all existing<br />
record table entries, plus enough empty space for future locking processes<br />
(120%). If the answer is no, then the rebuild request is rejected and a new<br />
IGW457I message will be displayed.<br />
System-managed duplexing rebuild<br />
This support is available from z/OS V1R4 DFSMS. The <strong>VSAM</strong> RLS duplexing<br />
support only applies to the lock structure and not the cache structures.<br />
What is it?<br />
This facility is a hardware-assisted mechanism for <strong>VSAM</strong> RLS duplexing CF lock<br />
structure data, and provides a robust recovery mechanism for failure scenarios<br />
such as a loss of a CF, or loss of connectivity to a single CF.<br />
► Provides quick recovery from RLS lock structure failure<br />
► Reduces lost lock conditions<br />
► Minimizes running out of record table space<br />
► Eliminates 0F4 abends<br />
Attention: When the lock structure is in duplex mode, user command rebuild<br />
requests are rejected. You must use the alter function to change the lock<br />
structure.<br />
How to set it up?<br />
To use the new <strong>VSAM</strong> RLS system-managed duplexing function the following<br />
tasks are required:<br />
Review CF configuration<br />
Evaluate the CF configuration (storage, links, processor capacity) and make any<br />
necessary configuration changes to accommodate the new <strong>VSAM</strong> RLS lock<br />
structure instances resulting from system-managed duplexing.<br />
Migrate to z/OS V1 R4 or later<br />
All systems in the sysplex that use this function will need to be upgraded to this<br />
level that supports System-managed duplexing.<br />
Install hardware CFCC level 12 or later<br />
CF Duplexing requires CFCC Level 12 for implementation on IBM ~<br />
zSeries servers. For G5/G6 Servers and the stand alone CF 9672-R06, CF<br />
Duplexing function requires CFCC Level 11.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 279
280 <strong>VSAM</strong> <strong>Demystified</strong><br />
Attention: The lock structure (IGWLOCK00) should not be defined in the<br />
CFRM policy as duplexed before all of the <strong>VSAM</strong> RLS instances on all system<br />
have been upgraded to the level that supports System-Managed duplexing.<br />
(Once the lock structure is duplexed, down-level <strong>VSAM</strong> RLS instances that do<br />
not provide the support for System-managed duplexing will be unable to<br />
connect to duplexed lock structure).<br />
Format the CFRM couple data set<br />
Format this as system-managed, duplexing-capable, and bring that CFRM<br />
couple data set into use in the sysplex, to enable CFRM for system-managed<br />
duplexing.<br />
Modify the CFRM policy<br />
Modify this to control the sizing, placement (through the CF preference list) and<br />
the DUPLEX parameter indication for the <strong>VSAM</strong> RLS lock structure, which is<br />
duplexed via system-managed duplexing, and activating this CFRM policy.<br />
5.6.3 RLS CF caching enhancements<br />
This support is available in z/OS V1 R3.<br />
What is it?<br />
There are two RLS caching enhancements, respectively:<br />
► Dynamic cache reassignment<br />
► For the CF structure rebuild process to work, extra space in a CF must be<br />
reserved, if not it fails. Then all I/O requests for those <strong>VSAM</strong> spheres fail.<br />
► DFSMS dynamic cache reassignment allows the customer to better utilize the<br />
CF resources.<br />
► If the rebuild fails, SMS<strong>VSAM</strong> Dynamic cache reassignment code examines<br />
each <strong>VSAM</strong> sphere that is assigned to the failing cache. Those spheres that<br />
are assigned to a storage class that point to 'cache set' where there are more<br />
than one cache structure names are reassigned. The same algorithm used in<br />
the original allocation of the sphere is used. For the <strong>VSAM</strong> sphere that were<br />
able to be reassigned, all requests continue to work. For the <strong>VSAM</strong> spheres in<br />
which the reassignment failed, those requests are failed with a reason code<br />
“cache not available”.<br />
► Data CIs larger than 4KB in cache structure. The initial version of SMS<strong>VSAM</strong><br />
support did not cache RLS data CI that was greater than 4 KB, for<br />
performance reasons. However, since 9672 G4 machines, due to the faster<br />
CF links and CF CPU, there are performance gains in keeping larger than
4 KB data CIs in the CF cache structure. With this support you can cache all,<br />
some, or none of the <strong>VSAM</strong> RLS data in the CF cache structures defined to<br />
SMS<strong>VSAM</strong> — through the RLSCFCACHE keyword. The <strong>VSAM</strong> index<br />
structure is ALWAYS cached. The directory entry for a CF data entry also is<br />
always cached, regardless of what option is specified.<br />
How to set it up?<br />
Here are the steps to take.<br />
Migrate to z/OS V1 R3 or later<br />
You must be at this level or higher.<br />
Update SYS1.PARMLIB member IGDSMSxx<br />
There are two new keywords in IGDSMSxx. They are:<br />
► RLS_DynamicCfCacheReassign(YES|NO).<br />
This keyword controls, at the sysplex level, whether RLS dynamic cache<br />
reassignment is active or not.<br />
► RLS_MAXCFFEATURELEVEL({Z|A})keyword<br />
This specifies the method that <strong>VSAM</strong> RLS should use to determine the size of<br />
the data that is placed in the CF cache structure. You can use the<br />
RLS_MAXCFFEATURELEVEL keyword to limit the connect level when the<br />
sysplex has a mixed level of releases and maintenance. If you do not specify<br />
a value, or if you specify Z, then only <strong>VSAM</strong> RLS data that has a Control<br />
Interval (CI) value of 4K or less is placed in the CF cache structure. If you<br />
specify A, caching proceeds using the RLSCFCACHE keyword<br />
characteristics that are specified in the SMS data class that is defined for the<br />
<strong>VSAM</strong> sphere.<br />
RLS_MAXCFFEATURELEVEL is a sysplex wide value. The first system<br />
activated in the sysplex will set the value; all other systems will use the value<br />
set by the first system. Default: Z.<br />
– RLS_MaxCfFeatureLevel(A) indicates that <strong>VSAM</strong> RLS caching uses the<br />
characteristics specified in the SMS DATACLASS defined for the <strong>VSAM</strong><br />
sphere.<br />
– RLS_MaxCfFeatueLevel(B) indicates that DynamicCfCacheReassignment<br />
is installed. This feature is active if the<br />
RLS_DynamicCfCacheReassign(YES) is specified in the active SMS<br />
parmlib member.<br />
– RLS_MaxCfFeatureLevel(AB) indicates that both features may be<br />
activated.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 281
282 <strong>VSAM</strong> <strong>Demystified</strong><br />
Update data class<br />
The new caching characteristics are defined in the DATACLASS SMS construct.<br />
A new field is added to the ISMF DATACLASS construct called RLSCFCACHE.<br />
The values are NONE, UPDATESONLY, and ALL(default).<br />
5.7 RLS performance<br />
Even knowing that the major reason for implementing RLS is availability, in this<br />
topic we discuss the performance considerations caused by such migration, that<br />
is, from non-RLS to RLS mode.<br />
Performance is a matter of subjectivity and relativity. In each performance<br />
evaluation task, we need to have very clear objectives and to what objectives we<br />
should relate the measured numbers. Here in this topic, we have two types of<br />
goals:<br />
► Compare theoretically — although supported by IBM experiences — a<br />
CICSPlex® without RLS data sharing with the same environment but with<br />
RLS. Refer to “CICSPlex RLS performance comparison” on page 299.<br />
► Compare practically (with experiments) batch workload accessing <strong>VSAM</strong><br />
clusters in non-RLS and in RLS mode. Refer to “Batch RLS performance<br />
experiments and comparison” on page 300.<br />
Our performance monitor is Resource Measurement Facility together with a hand<br />
full of MVS commands and SMF records reports related to RLS performance.<br />
It is clear that one big difference in these two modes (RLS and non-RLS) is the<br />
use of the coupling facility (CF) by RLS, which implies performance losses and<br />
gains. The losses could be the time the transaction needs to wait for CF link<br />
transport and CFCC processing, for guaranteeing integrity, for example. The<br />
gains could be the use of CF caching capabilities to avoid an I/O operation,<br />
improving throughput.<br />
In this topic we also explain major RMF fields covering RLS and the SMF records<br />
created on the subject.<br />
5.7.1 Factors affecting RLS data sharing performance<br />
Here, we cover all the factors introduced by RLS data sharing, which could affect<br />
the performance of a <strong>VSAM</strong> I/O request. Some of them are connected to specific<br />
ways of implementing data sharing. After the description of the factor, we<br />
recommend how to improve performance in the factor realm.
Speed of the CF hardware and software<br />
RLS data sharing performance is directly affected by the speed of the hardware<br />
associated with the coupling facility (CF), as follows:<br />
► Here is the relationship between the CF and host CPU speeds:<br />
– The faster the CF CPU, the less overhead in the host CPU. This is crystal<br />
clear, host CPU waits less.<br />
– The faster the host CPU, the higher the overhead, because for the time<br />
waiting for the CF CPU, MIPS are not being productively used by the host<br />
CPU.<br />
► Dedicated or shared CF CPUs: Here we admit they are dedicated, as is<br />
strongly recommended in production environments.<br />
► As for the number of CF CPUs in the CF logical partition, two is better than<br />
one.<br />
► The CF type of link, such as IC, ISC or ICB, will effect the rate (MB/sec).<br />
The other factor is the load submitted to the above mentioned hardware, for<br />
example:<br />
► Total demand in the CF and CF links, which may cause high queue time.<br />
► How heavy is the actual RLS request, which may cause high service time.<br />
Refer to “Coupling Facility Usage Summary report” on page 311, and “Coupling<br />
Facility structure activity report” on page 314 to learn how to evaluate the<br />
performance of your CF hardware.<br />
Recommendations<br />
This recommendation is very easy to make. If you see performance problems in<br />
the CF through RMF analysis, buy the faster hardware for this CF:<br />
► Faster and more than one (if needed) dedicated CF CPUs<br />
► Faster links: ICs or ICBs, if possible<br />
► Do not overload the CF and CF links capacity<br />
DASD performance of the SHCDS data sets<br />
The DASD performance of the SHCDS data sets is important, to have a good<br />
general RLS performance. Refer to “Define Sharing Control Data Set (SHCDS)”<br />
on page 253 to get more about the role played by this data set in SMS<strong>VSAM</strong>.<br />
To be sure that the I/Os towards SHCDS is performing well, go through the<br />
explanations in “Performance scenario using RMF reports” on page 115.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 283
284 <strong>VSAM</strong> <strong>Demystified</strong><br />
Recommendation<br />
Allocate them in faster controllers with lots of cache, small capacity disks, with<br />
high RPM, accessed by FICON channels<br />
CF synchronous and asynchronous requests<br />
A key XES question effecting performance, is what to do with the MVS CPU<br />
when CFCC is processing the request. There are two possibilities:<br />
► With synchronous processing, the MVS CPU is placed in a loop by XES,<br />
waiting for the completion of the CF request. The synchronism referred to<br />
here is between the requiring task (not placed in wait state) and the execution<br />
of the request in the CF. Some observations on this are:<br />
– It is efficient because the requesting CP spins until response is received<br />
from CF, saving overhead of task being undispatched, saving status,<br />
swapping registers, being dispatched again, and so on.<br />
– This can burn MIPS if CF takes a long time to respond.<br />
This should be used for short requests.<br />
► Asynchronous processing: Instead of holding the MVS CPU, XES releases it<br />
once the CF requests have been sent. Here are some observations on this<br />
approach:<br />
– This will consume less CPU time than very long running synch requests.<br />
– This frees up CPU for other work while the request is processed.<br />
– This uses instructions in the dispatcher component because the task must<br />
be undispatched then later re-dispatched.<br />
This should be used for long requests.<br />
Usually the CF requests for the IGWLOCK00 are synchronous.<br />
In z/OS 1.2 the CF Synch/Asynch heuristic algorithm is introduced, where XES<br />
selects the most efficient way (in terms of used machine cycles) of handling each<br />
request. This is based on:<br />
► The current actual synch response times for each CF request type. For<br />
duplexed structures, XES keeps the time from the start of the first operation to<br />
the end of the last one.<br />
► The speed of the CPU that z/OS is running on, which determines the number<br />
of instructions that could be executed while CP spins on synch request.<br />
Recommendations<br />
► Install z/OS 1.2 to have the new CF Synch/Asynch heuristic algorithm.
► Learn RMF reports covering synchronous and asynchronous requests, and<br />
refer to “Speed of the CF hardware and software” on page 283, to improve the<br />
performance of Synch/Asynch CF requests. By the way, you cannot influence<br />
the decision between one type and the other.<br />
SMS<strong>VSAM</strong> buffering and caching<br />
An application program GET can be served by SMS<strong>VSAM</strong> in three places: local<br />
buffer pools, SYS<strong>VSAM</strong> CF cache structure, or DASD I/O.<br />
► Local buffer pool: The needed data CI is there and valid. No I/O is necessary.<br />
Each buffer in this buffer pool has the size of a CI. It is possible to have 16<br />
different types of buffer pools varying the CI size, from 2 KB to 32 KB.<br />
These SMS<strong>VSAM</strong> buffers CI contents are managed by Buffer Management<br />
Facility (BMF) an SMS<strong>VSAM</strong> component, using a least recently used (LRU)<br />
algorithm. By the way, there is not a sequential look-ahead for any type of RLS<br />
access. LRU keeps in the buffer pool the CIs most referenced, or the best<br />
selection of CIs, as direct access is concerned. The number of buffers in the<br />
buffer pool varies dynamically, it increases when a buffer is needed by an<br />
incoming CI and decreases when a CI is deleted or stolen by the LRU algorithm.<br />
Time driven — the least referenced CIs are stolen by an LRU buffer aging<br />
routine. This routine runs with a dynamic frequency. At a higher frequency more<br />
CIs are stolen, less exact is their measured unreferenced pattern, and more CPU<br />
cycles are spent.<br />
The full LRU algorithm is controlled by the Parmlib member IGDSMSxx, where<br />
the installation sets a goal limit for the local buffer pool size, through the<br />
RLS_MAX_POOL_SIZE keyword (defaults of 100 MB and limit of 1.5 GB). This<br />
parameter when you are migrating to RLS, should have the same magnitude of<br />
the size of the CICS/FOR (LSR and NSR) buffers. Also at IGDSMSxx (LRUTIME<br />
keyword), the installation defines the frequency of the LRU cycle routine.<br />
At every invocation of the LRU cycle routine, it verifies if the local buffer pool size<br />
is:<br />
► Equal or below the goal, then the buffer aging routine is slowed down.<br />
► Over the goal, then the buffer aging routine is accelerated increasing the<br />
stealing of CIs. This state is named accelerated.<br />
► Five times over the goal, or reaches the 1.5 GB limit, BMF energetically starts<br />
stealing (reclaiming) the buffers without waiting for the aging routine. This<br />
state is named reclaimed.<br />
► If the local buffer pool appears as over the goal (status Accelerated or<br />
Reclaimed), you could adapt the goal in Parmlib member IGDSMSxx by<br />
increasing the RLS_MAX_POOL_SIZE value at a price of increasing the use<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 285
286 <strong>VSAM</strong> <strong>Demystified</strong><br />
of central storage. If you do not have enough central storage, the option is to<br />
decrease the level of RLS activity. Also, this case guarantees that the CF<br />
cache structure is able to keep the records that overflow from local buffers in<br />
order to avoid DASD I/O.<br />
In conclusion, we say that for direct access, RLS BMF manages its buffers more<br />
efficiently than local shared resources (LSR) pools. Then, the buffer pool hit<br />
ratios are better for the RLS managed buffers than for LSR pools, in direct<br />
accesses.<br />
However, because the local buffer pools managed by BMF does not implement<br />
look ahead along read sequential access, avoid batch sequential RLS<br />
processing. If there is a reading JOB accessing the CICS/RLS spheres, it is<br />
recommended to use SHROPT(2,n) and no RLS mode.<br />
► As for the SYS<strong>VSAM</strong> cache structure in the CF, it is used when the data CI is<br />
not in local buffer pool or is there but invalid, due to cross invalidation. No I/O<br />
is necessary.<br />
To use the cache structure with data CIs, you may use at data class (DC) the<br />
RLSCFCACHE keyword to control who is going to the cache:<br />
► For the ALL keyword, all data CIs read into or updated in local buffers are<br />
copied in CF cache structure. This is the default.<br />
► For the UPDATESONLY keyword, only data CIs updated in local buffers are<br />
copied in CF cache structure.<br />
► For the NONE keyword, no data CIs are copied to the CF cache structure.<br />
The CF cache structure is only used, through its directory for cross<br />
invalidation.<br />
Note that this keyword is per DC, consequently each cluster can have a different<br />
value.<br />
Before z/OS1.3 DFSMS only data CIs less or equal 4 KB were candidates to be<br />
located in the CF cache structure.<br />
The CF cache structure is also managed by an LRU algorithm, trying to keep the<br />
most referenced CIs. However, there are the DIRECT WEIGHT and<br />
SEQUENTIAL WEIGHT keywords fields, designed to protect some clusters<br />
relatively from others against stealing. Refer to “Define the CF cache structures<br />
names to SMS” on page 260.<br />
To increase the probability of finding the CI in this cache, you may allow big<br />
cache structures, at least the sum of all the local RLS buffers. We recommend a<br />
few cache sets, with each one pointing to only two CF same size structures in<br />
distinct CFs. Refer to “Define CF cache structures” on page 256. It seems that
the use of weights is not fully implemented, because all the weights are forced to<br />
the value six.<br />
► DASD device: The data CI is not in the cache structure.<br />
RMF has a set of reports covering this subject. Refer to “RMF and <strong>VSAM</strong> RLS”<br />
on page 306.<br />
Recommendations<br />
► If the local buffer pool is accelerated or reclaimed, as shown in RMF, increase<br />
RLS_MAX_POOL_SIZE, if you have enough central storage. If you do not<br />
have such storage or increase the size of the cache CF structure or decrease<br />
the RLS load at measured interval. Also decrease the LRU_TIME keyword to<br />
the LRU routine to be invoked more often.<br />
► Avoid batch reading sequentially in RLS mode, there is not look-ahead.<br />
Change the mode, if you want performance and you do not care about read<br />
integrity.<br />
► If READ CF% in RMF is low, increase cache structures size, at least to the<br />
sum of all the local RLS buffers. We recommend a few cache sets, with each<br />
one pointing to only two CF same size structures in distinct CFs.<br />
► Re-visit the value of RLSCFCACHE keyword, which the default is ALL. Maybe<br />
your I/O workload is cache unfriendly for reads. Then, you are polluting the<br />
cache with data that is not used later. Think about changing for<br />
OPDATESONLY.<br />
Control Interval cross invalidation<br />
Buffer coherency must be maintained when sharing data. There are two things<br />
that drive this coherency and they are:<br />
► The SMS<strong>VSAM</strong> address space must to be updated to reflect that a CI located<br />
in its local buffer was updated by other SMS<strong>VSAM</strong>, that is, that the CI is no<br />
longer valid.<br />
► There must be a place where any SMS<strong>VSAM</strong> can find the most current copy<br />
of a CI located in its local buffer pool<br />
To address these problems the following CF logic is implemented; refer to<br />
Figure 5-17.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 287
SMS<strong>VSAM</strong>1<br />
288 <strong>VSAM</strong> <strong>Demystified</strong><br />
HSA<br />
ABC<br />
4<br />
Coupling Links<br />
Figure 5-17 Cross invalidation and locks<br />
ABC<br />
4 3<br />
2<br />
7<br />
5<br />
1<br />
ABC<br />
Coupling Links<br />
HSA<br />
ABC<br />
The numbers below refer to the numbers in the figure:<br />
► 1. Every time a CI enters a local buffer pool, SMS<strong>VSAM</strong> indicates its interest<br />
on the CI to CFCC. So there are entries in the directory not pointing to a<br />
cache element, but to a specific SMS<strong>VSAM</strong>. The ratio between the number of<br />
directory entries and cache elements is determined by the first SMS<strong>VSAM</strong> to<br />
connect to the structure through the IXLCONN macro. The ABC control<br />
interval is in both local buffers.<br />
► 2. A transaction in system 1 is requiring an update to a record located in ABC<br />
control interval. The lock is required by SMS<strong>VSAM</strong>1 to CFCC and granted.<br />
► 3. SMS<strong>VSAM</strong>1 verifies that the copy in local buffer pool is valid by inspecting<br />
the HSA valid bit.<br />
► 4. The CI is modified in a local buffer pool, the CI is copied in DASD<br />
(store-through) and optionally in a CF cache element.<br />
► 5. and 6. CFCC is informed by SMS<strong>VSAM</strong>1 about the change. By searching<br />
the directory, CFCC discovers the other SMS<strong>VSAM</strong>s that manifested interest<br />
in such CI — in other words, the ones that now have an out of date copy of the<br />
6<br />
1<br />
SMS<strong>VSAM</strong>2
ABC updated control interval. CFCC switches on the invalid bit accordingly,<br />
using IXLVECTR XES service. This action is called a cross invalidation (XI).<br />
► There is an unusual case of XI called directory reclaims XI. It happens when<br />
a directory entry is needed and there is no one available. To reclaim an entry<br />
its previous content is released and the corresponding pair SMS<strong>VSAM</strong>/CI<br />
affected has the HSA invalid bit set to on. This is not because the copy of the<br />
affected CI is not valid anymore, but just because CFFC is not able to track it.<br />
RMF shows these figures in “Coupling Facility structure activity report” on<br />
page 314.<br />
Later an SMS<strong>VSAM</strong>2 receives a transaction request, to be filled by the modified<br />
CI. The old copy is still in local buffer pool, but SMS<strong>VSAM</strong>2 detects the invalid bit<br />
on, using the IXLVECTR local vector service TestLocalCache. We have a cross<br />
invalidation and the SMS<strong>VSAM</strong> searches by the fresh copy in the CF cache<br />
elements or in DASD. When found, the new copy is brought to local buffer and<br />
made available to the transaction.<br />
Recommendations<br />
The “<strong>VSAM</strong> RLS Monitor III reports: RLSLRU” on page 306 shows the XI figures.<br />
If these figures are too big (above 10%), you may try to:<br />
► Avoid directory reclaims XIs caused by CF cache directory shortages. Verify if<br />
the APAR OW23008 is applied. It causes SMS<strong>VSAM</strong> to constantly adjust the<br />
data-to-directory ratio to minimize the number of buffer invalidation due to a<br />
shortage of directory entries. In our experiments, it seems that this function is<br />
not active due to the huge amount (25%) of directory reclaims XI observed in<br />
the RMF report.<br />
► Increase the size of the CF Cache structure to avoid that the directory<br />
reclaims XI cause an I/O DASD operation.<br />
► Decrease the size of local buffer pools, this is trade off between buffer hits and<br />
cross invalidations.<br />
► When using CICSplex dynamic workload balancing, temporarily make<br />
transactions connected to a certain type of data to bias the workload to a<br />
specific system.<br />
True and false contention in lock structures<br />
Usually we have many more records (many millions), in a medium to large data<br />
set, to serialize through global locks, than the number of entries (many<br />
thousands) in the CF structure lock table. The reason for this is the impossibility<br />
of having enormous lock structures in the CF.<br />
The solution is to share the same lock entry with several logical records locks.<br />
Refer to Figure 5-18. A hashing algorithm applied in the Key, RBA, or RRN is<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 289
290 <strong>VSAM</strong> <strong>Demystified</strong><br />
used to map a lock associated with the record to a lock entry. When more than<br />
one lock register maps to the same lock table entry (synonyms), there is a false<br />
contention.<br />
In the example, it is a false contention because the lock table entry #2 is held by<br />
an exploiter in SMS<strong>VSAM</strong>1 due to a logical record 2723 lock. Another exploiter in<br />
SMS<strong>VSAM</strong>2 requires a logical record 8627 lock. It cannot get the lock because<br />
the common entry is held by the first (false contention). In this case there is a<br />
performance penalty, the second lock requester is suspended until this<br />
SMS<strong>VSAM</strong>2 determines through XCF conversation (using the XCF group name<br />
IXCLO001) with SMS<strong>VSAM</strong>1, that there is no real lock contention on the<br />
resource. If the contention is true the requesting task still stays in wait state; if<br />
false it is placed immediately in ready state.<br />
1<br />
2<br />
SMS<strong>VSAM</strong> 1<br />
SET LOCK 2723<br />
HASH<br />
2723<br />
3 6<br />
Lock Table<br />
in CF<br />
Figure 5-18 Example of two locks synonyms<br />
HASH<br />
XCF<br />
LR 1<br />
8623<br />
LR 2<br />
8627<br />
SET LOCK 8627<br />
To avoid such performance degradation due to false contention (should be less<br />
than 0.1% for iGWLOCK00), you might decrease the possibility of synonyms.<br />
This can be done in two ways:<br />
► Decrease the length of each lock table entry, by decreasing MAXSYSTEMS<br />
(parameter used along formatting the Sysplex Couple data set) to a number 7<br />
0<br />
1<br />
24 2<br />
4<br />
5<br />
6<br />
SMS<strong>VSAM</strong> 2<br />
HASH<br />
XCF TALK<br />
8627
or less — if you do not have more than 7 systems in your sysplex. If you have<br />
more than 7, define MAXSYSTEMS as less than 24.<br />
► Increase the size of the lock table. There is a formula to calculate its size:<br />
10M *number_of_systems *lock_entry_size<br />
The the loc_entry_size depends on the MAXSYSTEM value as we saw in the<br />
previous topic:<br />
7 or less: 2 bytes<br />
>= 8 and < 24: 4 bytes<br />
>= 24 and
292 <strong>VSAM</strong> <strong>Demystified</strong><br />
Serialization at record level<br />
This function has no direct relation with the use of CF, however it is a key<br />
modification in the way <strong>VSAM</strong> serialize its data. In non-RLS mode, the level of<br />
serialization used by DFSMS lock manager is:<br />
► At sphere level (at OPEN time), using share options.<br />
► At CI level (at GET/PUT time) using intra-address space sharing.<br />
Refer to “<strong>VSAM</strong> sharing mechanisms” on page 216, for more information.<br />
Now returning to RLS mode, let us compare the pros and cons of serializing a<br />
logical record level with CI level.<br />
The serialization at logical record level (instead at CI level) has the following<br />
important advantage:<br />
► Significantly decreases the real contention due to a higher granularity.<br />
And, here are the disadvantages:<br />
► Increases the number of locks and the associated effort to manage them.<br />
► Due to more locks, the number of false contentions should be higher than if<br />
the serialization would be done at CI level, because more locks are used.<br />
Generally speaking, the serialization at logical record favors the smaller<br />
components.<br />
However, pay attention that the cross invalidation process as described in<br />
“Control Interval cross invalidation” on page 287, is still done at CI level. Then the<br />
following scenario may happen:<br />
Two different logical records in the same CI could be updated at the same time<br />
on two different SMS<strong>VSAM</strong> (X and Y), and this is good. X updated the first logical<br />
record in a CI holding its lock. The same CI is in the local buffer pool of Y. When<br />
Y tries to update the second logical record (also holding its lock), it detects that<br />
the buffer is now invalid, although the second logical record was not updated by<br />
X. The CI is reread by Y from DASD (or CF). The new CI, containing both<br />
updated records, is now written by Y to the CF and then to DASD, the invalid bit is<br />
set in X.<br />
Please note that a logical record lock is only free at commit time and not at end of<br />
the logical processing.<br />
Recommendations<br />
Read the recommendations of “Control Interval cross invalidation” on page 287,<br />
if you are facing high level of real and false contentions. Do not forget the<br />
possibility of using NRI.
Effect of a write dominant I/O workload<br />
Writes are always a source of performance, integrity, and availability problems in<br />
data processing. Nevertheless, because there’s no such thing as a full read-only<br />
environment, let’s explore this some more.<br />
A write dominant I/O workload may cause performance degradation because of<br />
the following reasons:<br />
► Excess of CI cross invalidations; refer to “Control Interval cross invalidation”<br />
on page 287.<br />
► All the random writes against a CI in the local buffer pool are in store-through<br />
mode. This means that the DASD I/O operation is always executed, there is<br />
no option of a defer write (store-in mode). In CICS FOR there is such an<br />
option. On the other hand, the store-through mode favors a faster recovery.<br />
The performance gets worse, because:<br />
– The requesting task waits till the end of the DASD I/O operation.<br />
– If the same CI is updated N times, when in the buffer pool, with the<br />
store-through mode we have N I/O operations; but with defer write we<br />
have just one I/O operation, therefore saving N-1 I/O operations.<br />
► Lots of locks held in exclusive mode (because of the writes), causing more<br />
real contention at logical record level.<br />
Recommendations<br />
► If you have to face lots of DASD I/O writes, then improve the performance of<br />
your volume, such as: allocate the <strong>VSAM</strong> cluster it in a fast controller with lots<br />
of cache, RAID10 (instead of RAID5), small capacity disks and high RPM<br />
disks. Refer to “Performance scenario using RMF reports” on page 115, to<br />
improve the performance of your DASD I/Os.<br />
► Refer to “Control Interval cross invalidation” on page 287, for<br />
recommendations about how to decrease XIs.<br />
RLS lock structure duplexing<br />
An error in software or hardware may destroy the contents of a CF structure or<br />
can make it inaccessible due to the lack of CF links. IGWLOCK00 is sensitive to<br />
structure failures and its demands, to keep continuous availability, by<br />
implementing one of these features: Failure Isolation or System Managed<br />
Duplexing. Refer to “<strong>VSAM</strong> RLS CF structure duplexing and rebuild” on<br />
page 278, for more information.<br />
In this topic, we discuss the performance aspects of System Managed (SM)<br />
duplexing the IGWLOCK00 structure.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 293
294 <strong>VSAM</strong> <strong>Demystified</strong><br />
Cost of SM duplexing differs depending on structure type, usage, and the percent<br />
of requests that get duplexed. When duplexing IGWLOCK00 all the writes are<br />
duplexed.<br />
Performance impact of implementing SM duplexing is more likely to be a lack of<br />
capacity in the CF, than a transaction response time (in MVS CPU time<br />
component).<br />
Here is a list of such costs:<br />
► The MVS CPU cost: 3 to 4 times the CPU consumption of a simplex request<br />
(but may save CPU associated with DASD I/O). Refer to “CF access time” on<br />
page 295, to understand how this figure is derived.<br />
► The subchannel cost: 6 to 8 times that of a simplex request (2 subchannels<br />
tied up, each 3-4 times longer than before).<br />
► The link cost: Cannot directly measure, unlikely to be an issue CF CPU cost<br />
— 4 to 5 times that of a simplex request (across both CFs).<br />
All of these assume minimal distance between the CPCs and CFs and between<br />
the two CFs.<br />
There is no additional cost for simplex requests, because your system has the<br />
SM duplexing capability.<br />
Recommendations<br />
► Review the recommendations stated in “Speed of the CF hardware and<br />
software” on page 283, to improve the performance of the CF hardware in<br />
order to absorb the load generated by duplexing.<br />
► If you do not have CF and CF Links capacity for implementing duplex with<br />
acceptable performance, then you may want to implement Failure Isolation<br />
instead.<br />
Recoverable <strong>VSAM</strong> spheres<br />
Recovery does affect performance due to extra work that needs to be done to<br />
allow a cluster to be recoverable. We strongly recommend, if you do not have the<br />
procedures in place and the recovery products, such as CICS/VR, to implement,<br />
for instance, forward recovery (REDO), there is no point in specifying LOG(ALL).<br />
This option generates the overhead of creating record images for UNDO/REDO<br />
in the forward recovery log, but does not provide the ability to do anything with<br />
such information. Refer to “Recoverable sphere” on page 252 for more<br />
information.
5.7.2 CF access time<br />
Recommendations<br />
Do not declare your <strong>VSAM</strong> cluster recoverable, if you do not have products to<br />
enforce this recoverability.<br />
Dealing with deadlocks<br />
Deadlocks are a performance and also a problem determination subject. Refer to<br />
3.2.16, “Deadlocks” on page 160. When in CICS RLS, messages start to pop up<br />
telling about transactions time out, one reason could be RLS <strong>VSAM</strong> deadlocks.<br />
You may try to avoid deadlocks by changing the way programs are written, such<br />
as:<br />
► Avoid to lock more than one logical records concurrently.<br />
► Create a hierarchy of locks. Then, when more than one lock is required, they<br />
need to be required in a pre-determined sequence, as defined by such<br />
hierarchy.<br />
Your installation may activate the deadlock detection routine through the<br />
IGDSMSxx keywords: DEADLOCK_DETECTION(nnnn|15,kkkk|4) and<br />
RLSTMOUT({nnnn|0}).<br />
The default for DEADLOCK_DETECTION is (15,4). You may want to change<br />
these values to (1,1) to minimize the time required to detect a deadlock condition.<br />
Obviously there is a trade off between CPU time spent detecting deadlocks and<br />
the effect that deadlocks are causing to applications. Carefully monitor these<br />
effects in your environment before making changes to the supplied defaults.<br />
Recommendations<br />
► Avoid deadlocks by enforcing the NRI option, or implementing a lock<br />
hierarchy, or never asking for more than one lock concurrently.<br />
► Activate the deadlock detection routine more often, if you are facing several<br />
deadlock situations.<br />
Now that we covered the majority of items affecting the RLS data sharing<br />
performance, we introduce a process to measure numerically some of those<br />
overheads.<br />
As we said earlier in this chapter, the use of the CF by SMS<strong>VSAM</strong> implies in<br />
losses and gains. Here we start accounting the losses in MVS CPU in RLS<br />
caused by the access to the CF in a MIPS scale. Our calculation applies to our<br />
test machine, the 2064-1C7 CEC. You must scale to your processor's “per CPU”<br />
speed. One of the reasons for such a calculation is to help you to implement<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 295
296 <strong>VSAM</strong> <strong>Demystified</strong><br />
some CPU Capacity Planning due to migration from CICS/FOR to<br />
CICS/SMS<strong>VSAM</strong>.<br />
However, before you get concerned about this MVS CPU overhead, we’ll make a<br />
few comments:<br />
► How much of a 0.5 seconds (500,000 microseconds) CICS response time is<br />
spent waiting on the CF? Maybe 500 microseconds (0.1%)?<br />
► Even if you quadruple the CF time component, does anyone notice the extra<br />
1.5 milliseconds?<br />
► Remember that many large CICS customers still use DASD-only logging with<br />
response times around 2000 microseconds (2 millisecond) and still provide<br />
acceptable transaction response times.<br />
The numeric approach has two parts: for synchronous and asynchronous<br />
requests, respectively:<br />
Synchronous requests formula<br />
Refer to “CF synchronous and asynchronous requests” on page 284. Here we<br />
state the rule-of-thumb, that the MVS CPU time overhead for such types of<br />
requests is made:<br />
► Software CPU time which includes the exploiter (SMS<strong>VSAM</strong>) plus XES. It<br />
varies by structure type and exploiter and follows the rules of thumb:<br />
– Lock: Average 11 microseconds on 2064-1C7<br />
– Cache/List: Average 18 microseconds on 2064-1C7<br />
► Hardware dwell CPU time which includes:<br />
– The time for the MSMG instruction in MVS CPU<br />
– The CF link transmission time (back and forth)<br />
– CFCC processing<br />
This time is reported in RMF CF Activity report as SYNC SERV TIME. Refer<br />
to “Coupling Facility structure activity report” on page 314, to see the report.<br />
Asynchronous requests formula<br />
The MVS CPU time overhead for such requests consists of:<br />
► Software CPU time which includes the exploiter plus XES plus the code to<br />
execute a task switch:<br />
– Any type of structure (cache, list or lock): average 54 microseconds on<br />
2064-1C7<br />
► Hardware dwell CPU time is zero because the it asynchronous and the MVS<br />
CPU is not placed in a loop.
Lock contention event software CPU time<br />
There is another type of MVS CPU overhead that occurs when we have lock<br />
contention. To find out if the contention is real or false, <strong>VSAM</strong> RLS instances talk<br />
through XCF paths. It averages: 360 microseconds on 2064-1C7.<br />
SM Duplexing MVS CPU cost<br />
MVS CPU cost: 3 to 4 times the CPU consumption of a simplex request.<br />
So let’s make the calculation for structure IGWLOCK00 as an example. The<br />
numbers are based in the report shown in Figure 5-22 on page 315.<br />
Example: MVS CPU Time to access IGWLOCK00<br />
Due to the fact that the requests to IGWLOCK00 are synchronous, we use the<br />
numbers shown in “Synchronous requests formula” on page 296. To get the<br />
hardware dwell time and the frequency of access, we look at “Coupling Facility<br />
structure activity report” on page 314, in the SC63 system.<br />
► Software time = 11.0 microseconds.<br />
► Hardware dwell time (SYNC SERV TIME) = 50.4 microseconds.<br />
► Frequency of access = 215.6 locks /second<br />
► IGWLOCK00 structure consumption = 215.6 x (11.0 + 50.4) = 13.23<br />
milliseconds per second of MVS CPU 1C7.<br />
► Lock Contention using XCF = 360 x Contention rate =<br />
360 x 44K/ 1200= 13.20 milliseconds per second of MVS CPU 1C7.<br />
► The RMF interval duration where 44K contentions were found equaled 20<br />
minutes or 1200 seconds.<br />
► Total MVS CPU TIME in IGWLOCK (no duplexing) = 13.23 + 13.20 = 26.43<br />
ms per second of MVS CPU 1C7, that is, 2.6% of one 1C7 CPU.<br />
► Total MVS CPU TIME in IGWLOCK (duplexing) = 26.43 x 3.5 = 92.50 ms<br />
per second of MVS CPU 1C7, that is, 9.25% of one 1C7 CPU. Maybe you can<br />
convert to MIPS if it suits you.<br />
5.7.3 RLS performance gains<br />
Now here’s the good news. The performance gains are coming from data sharing<br />
and the use of CF.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 297
298 <strong>VSAM</strong> <strong>Demystified</strong><br />
Balancing the system through dynamic workload distribution<br />
In the case of CICS/RLS, the major performance objective (besides availability)<br />
is to balance the load between several MVS images sharing the same data and<br />
consequently to provide better overall response time and throughput.<br />
The queuing theory shows that two images at 80% and 20% busy have a much<br />
longer average queue time than two images at 50% busy each. Then, in a<br />
controlled test environment, the <strong>VSAM</strong> “I/O time” (includes here the buffer and<br />
cache hits and the real I/O) may get worse (bigger) with RLS than without RLS,<br />
due to CF overhead caused by cross invalidation and locking. However, the<br />
caching function saves read access to DASD. Nevertheless, if the results are not<br />
that bad (after tuning) chances are that in a production environment the bottom<br />
line result implies a better performance, due to subsystems balance.<br />
In a batch environment, throughput tends to be better, because a much larger<br />
level of parallelism is obtained with RLS. Before RLS data sharing, to guarantee<br />
integrity, just one updater could open the same cluster at a time. The serialization<br />
was at cluster level. With RLS the serialization is at record level and many<br />
updaters can, at same time, access concurrently the same cluster at different<br />
logical records.<br />
Using the CF cache structure as a buffer<br />
Due to the better load balance of the systems accessing a <strong>VSAM</strong> cluster in RLS<br />
mode and the inexistence of the FOR bottleneck a major rate of GET/PUT<br />
requests per second is expected. These GET/PUT requests can be served out of<br />
DASD, in local buffers and in the cache. The discussion here is to address<br />
whether or not this large rate causes an increased number of DASD I/Os per<br />
second.<br />
The number of DASD I/Os is dependent on the local buffer hit ratio. The buffer<br />
pool hit ratio is dependent on the type of workload and the read/write ratio.<br />
Remember that each write causes an I/O. To avoid growth in I/Os when adding<br />
systems, you should scale the buffer pool and coupling facility cache size to<br />
maintain a constant hit ratio in the buffer pool, refer to “SMS<strong>VSAM</strong> buffering and<br />
caching” on page 285. If the cache size is set up correctly for a read load, one<br />
should experience a drop in the DASD I/O rate per transaction improving the<br />
overall performance. If the Coupling Facility cache is sized large enough to avoid<br />
reclaims, the XIs due to updates do not cause an increase in the DASD I/O rate,<br />
because the updated record can still be found in the CF. Because the RLS buffer<br />
manager manages its buffers more efficiently than local shared resource (LSR)<br />
pools, the buffer pool hit ratios are better for the RLS managed buffers than for<br />
LSR pools.
5.7.4 CICSPlex RLS performance comparison<br />
The paramount question as far as CICS is concerned is: What will happen with<br />
your transaction response time and throughput (number of transactions per<br />
second) when you migrate from a CICS/ <strong>VSAM</strong> non-shared environment to a<br />
<strong>VSAM</strong> RLS?<br />
As a general statement, we may say that running transactions under CICS TS in<br />
CICSPlex (multiple z/OS) accessing <strong>VSAM</strong> cluster in RLS mode, did not degrade<br />
transaction response time at all. Experiences have shown that response time<br />
remained the same and the total throughput was linear from one image, two<br />
images, three images, that is, it doubled and tripled from one to two and two to<br />
three images. What follows are some theoretical reasons supporting the above<br />
statements:<br />
CICSPlex dynamic workload balance<br />
Balancing the load across AORs located in different z/OS images in a Parallel<br />
Sysplex is beneficial for CICS performance in general. Read “Balancing the<br />
system through dynamic workload distribution” on page 298.<br />
No more CICS function shipping<br />
Let’s review the environment CICSPlex without RLS.<br />
The CICS transactions coming from VTAM are welcomed by a TOR address<br />
space and based in WLM suggestion is sent to an AOR, where the transaction<br />
logic is executed by a program. If such logic requires a <strong>VSAM</strong> logical record,<br />
through a CICS function shipping mechanism (through XCF, if the FOR is<br />
remote), the request is sent to a FOR address space. FOR is in charge of<br />
accessing non-RLS <strong>VSAM</strong> spheres on behalf of CICS transactions.<br />
However, function shipping has a price. IBM benchmarks suggest an increase of<br />
about 16% to 20% in the CPU time used by CICSPlex compared with just one<br />
system. This increase is due to function shipping between the AOR and the FOR.<br />
With <strong>VSAM</strong> RLS such overhead vanishes, due to the fact that AOR passes the<br />
control to SMS<strong>VSAM</strong> in its own system. So, this gain may counterbalance the<br />
MVS CPU cycles for accessing the CF.<br />
No file owning region bottleneck<br />
Without RLS all the flow of CICS requests to the <strong>VSAM</strong> cluster is through file<br />
owning region (FOR). This address space is mono task and it can be a<br />
bottleneck, performance wise, and a single point of failure as availability is<br />
concerned. With RLS the FOR is replaced by several SM<strong>VSAM</strong> address spaces,<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 299
300 <strong>VSAM</strong> <strong>Demystified</strong><br />
one per system in the Parallel Sysplex. Then, as you see, RLS addresses both<br />
problems of performance and availability.<br />
Avoiding remote two phase commit<br />
Before SMS<strong>VSAM</strong>, it was possible for a unit of recovery to be formed by updates<br />
in <strong>VSAM</strong> data sets, accessed by different CICS FOR address spaces. In this<br />
case the synch point manager (CICS) needs to implement a remote two phase<br />
commit, a lengthy process, causing a transaction response time to increase. With<br />
SMS<strong>VSAM</strong> all the writes from the same recovery unit maybe executed in the<br />
same SMS<strong>VSAM</strong> eliminating this performance problem.<br />
Avoiding I/O because of the CF cache structure<br />
The RLS cache structures in the CF, may avoid a large number of read I/O<br />
operations. Refer to “Using the CF cache structure as a buffer” on page 298.<br />
5.7.5 Batch RLS performance experiments and comparison<br />
We made several measurements with batch jobs accessing <strong>VSAM</strong> clusters in<br />
RLS mode. The hardware and software description of our lab is in “Our test<br />
environment” on page 396. Here, we describe unique aspects related to the RLS<br />
experiments:<br />
► A master file implemented in a KSDS cluster with 2M of logical records,<br />
freespace is (10,20).<br />
► A sequential file with 200 K logical records not sorted by key. Causing 50%<br />
inserts and 50% reads in the master. There are no records with identical keys<br />
on purpose. This workload is clearly what the storage people call a “cache<br />
unfriendly” workload. The reasons for that are:<br />
– There is contention caused by locks not connected to logical records, as<br />
the locks are serializing CI and CA splits.<br />
– And the RLS behavior in a cache unfriendly (no re-visits) workload.<br />
► The logic is to:<br />
– Read a record in the sequential file.<br />
– Randomly, try a key match in the master, with a GET:<br />
If no match, insert the logical record in the KSDS (50%).<br />
If it matches, just read the master record and do not update it (50%).<br />
As we said, the keys in the sequential file were prepared to deliver 50% of<br />
matches. Then we have 100 K reads and 100 K insert writes. There are not<br />
update writes.
► After execution we have:<br />
– Data component: one extent, about 20800 CI splits and no CA splits<br />
– Index Component: one extent and no splits at all<br />
► At every run the master is re-created again.<br />
Test case description<br />
1. One job in SMB mode processing 200 K records.<br />
2. Two jobs in SMB mode in the same system processing 100 K records each,<br />
with read and write integrity (SHROPT=(1,3)), then one runs serially after the<br />
other.<br />
3. Two jobs in RLS mode, in the same system processing 100 K records each<br />
No RLS tuning.<br />
4. Two jobs in RLS mode, two systems processing 100 K records each. No RLS<br />
tuning.<br />
5. Three jobs in RLS mode, three systems processing 100 K / 3 records each.<br />
No RLS tuning.<br />
6. Three jobs in RLS mode, three systems processing 100 K / 3 records each.<br />
Some RLS performance tuning, including stopping duplex.<br />
In all the described RLS experiences, the IGWLOCK00 is duplexed, with the<br />
exception of run 6. Always, the read integrity (CR option) is used.<br />
Measurements of interest<br />
► Number of EXCPs in the master KSDS cluster: In <strong>VSAM</strong> this figure is the<br />
same as the number of I/O operations or SSCHs.<br />
► Total connect time in the master KSDS cluster: Less total connect time means<br />
less I/O operations (for direct access) and more efficiency in the executed I/O<br />
(for sequential access).<br />
► Total CPU time: The programs running in the JOBs do not process the data,<br />
so the CPU time (TCB plus SRB) is only for GET/PUT processing.<br />
► Elapsed time: The wall clock time to process all the 200 K records. However,<br />
we do not have a totally controlled environment, and chances are that the<br />
elapsed time may depend on other types of loads of the three logical<br />
partitions.<br />
► In run 5, we capture other RMF metrics to tune RLS and prepare run 6. These<br />
metrics are described in “RMF and <strong>VSAM</strong> RLS” on page 306. The values we<br />
got are shown in “Tuning run 5 with RLS parameters” on page 304.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 301
302 <strong>VSAM</strong> <strong>Demystified</strong><br />
Table results<br />
These are the numbers we got from the runs.<br />
Table 5-1 Batch RLS results<br />
Run<br />
Description<br />
1. One Job,<br />
one system<br />
2. Two Jobs,<br />
one system,<br />
no RLS<br />
3. Two Jobs,<br />
one system,<br />
RLS<br />
4. Two Jobs,<br />
two systems,<br />
RLS<br />
5. Three Jobs<br />
three systems,<br />
RLS<br />
6. Three Jobs,<br />
three systems,<br />
RLS, tuning<br />
Number of<br />
EXCPs<br />
Total Conn<br />
Time (sec)<br />
CPU Time<br />
(sec)<br />
280,276 62.518 19.3 204<br />
283,880 63.285 19.3 208<br />
Elapsed Time<br />
(sec)<br />
263,268 58.923 158.9 212 longest<br />
270,673 60.626 149.1 203 longest<br />
278,005 80.893 153.1 160 longest<br />
270,804 78.281 113.4 145 longest<br />
Comments about runs 1 to 5<br />
Here are some comments explaining the numbers captured for these runs:<br />
► Run 1 was to calibrate run 2. Run 2 is important because when we move to<br />
run 3, we may see the difference caused by a local RLS (just one system).<br />
The difference between the numbers in run 1 and run 2 are meaningless and<br />
we have no further comments.<br />
► Comparing run 3 with run 2, we see:<br />
– Less EXCPs and less connect time. For random access (as ours), this<br />
means that the savings in connect time are caused only by a decrease in<br />
the number of EXCPs. This decrease is caused by better local buffering<br />
(compared with SMB) and the existence of CF caching. However, pay<br />
attention that these gains are only for reads, because all writes in <strong>VSAM</strong><br />
RLS forces an I/O operation.<br />
– Huge increase in the CPU time, that is the price we pay for better I/O.<br />
Remember that we do not process the logical record read from master on
purpose (read and forget mode). So, the CPU time (TCB plus SRB) is only<br />
consumed for the GET/PUT request. In RLS mode, there are more CPU<br />
time per GET/PUT request due to the CF access (refer to “CF access<br />
time” on page 295). This explains the high percentage figure in the CPU<br />
time increase. Do not forget that the IGWLOCK00 structure is duplexed in<br />
run 3, and this feature consumes more CPU time.<br />
– The elapsed time is almost the same. Here we have a conflict between two<br />
forces. One in run 3 due to parallelism and less I/O, and the other in run 2<br />
due to less CPU (however, lots of CPU cycles are available) consumption<br />
and no lock contention. The final result, as elapsed time (an important<br />
metric for IT managers) is a tied game. Maybe some external effects, such<br />
as different external load in each run, may bias such metric. In<br />
comparison, we observe that the longest of the two JOBs is the one with<br />
more insertions (52841 against 47158) causing more delays due to CI<br />
splits. Then, we have a queue effect which makes the comparison a little<br />
unfair.<br />
► Comparing run 4 with run 3, we see:<br />
– More EXCPs and more connect time. This increase is caused by worse<br />
local buffering and worse caching. The major contributor is the Cross<br />
Invalidation (XI) event, around 12% in run 4. In run 3 there are no XIs<br />
because there is just one local buffer pool.<br />
– Little decrease in the CPU time. The cache and the lock structure are<br />
slightly less used. This justifies the observed CPU decrease.<br />
– The elapsed time is almost the same. We may expect a little higher for run<br />
4 due to slightly worse I/O and caching. Maybe some external effects as<br />
different external load in each run may bias such metric. In comparison,<br />
both the longest JOB is the one with more insertions, which makes the<br />
comparison fair.<br />
► Comparing run 5 with run 4, we see:<br />
– More EXCPs and more connect time. This increase is caused by more<br />
unfavorable local buffering. The cache is used a little more than in run 4.<br />
The major contributor for less hits for reads in the local buffer pool is again<br />
the Cross Invalidation (XI) event. It is around 20% in run 5. The higher<br />
level of XIs in run 5 is caused by having three (instead of two) local buffer<br />
pools. Then increasing the chance of XIs.<br />
– Little increase in the CPU time. The cache and the lock structure are<br />
slightly more used. This justifies the observed CPU increase.<br />
– The elapsed time is less than in run 4. We do not have a clear explanation<br />
for such behavior. So, let’s go traditional: maybe some external effects,<br />
such as different loads in each run, may bias such metric.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 303
304 <strong>VSAM</strong> <strong>Demystified</strong><br />
Tuning run 5 with RLS parameters<br />
When running run 5 (three JOBs, three systems, RLS, no tuning), we observe<br />
other RMF measurements, that were not presented in Table 5-1 on page 302:<br />
► BMF LRU algorithm accelerated at 75% of the measurement interval.<br />
► Maximum BMF pool size was around 145 MB, the RLS_MAX_POOL_SIZE is<br />
100 MB (default).<br />
► Average I/O response time per GET/PUT was 0.001 second, including the<br />
requests served in cache and buffers.<br />
► Data reads found in the BMF is 58.0%, index reads 97.0 percent.<br />
► CPU time consumed by BMF to manage the buffers is 387.3 milliseconds.<br />
► Data reads found in the CF is 10.0%, index reads is 2.6 percent.<br />
► Data reads found in DASD is 31.8%, index reads is 0.5 percent.<br />
► DASD device with four static PAV aliases allowing 528 IO/second with an<br />
average response time of 0.8 ms and average connect time of 0.5<br />
millisecond.<br />
► Cross invalidation was 20%, without directory reclaims XI.<br />
► Real lock contention is 4.2% and less than 0.1 false contention in<br />
IGWLOCK00. This contention is not cause by logical records being accessed<br />
by two JOBs at same time (there are no repetition of keys in the sequential<br />
file), so the contention is caused by locks used to serialize splits.<br />
► CF performance is outstanding with no queues at all.<br />
► WLM service class had a current execution velocity of 85%, that is very good.<br />
► CI Splits in all runs around 21K, and no CA splits.<br />
Modifications<br />
► Increase RLS_MAX_POOL_SIZE to 180 MB.<br />
► Increase the size of the cache from 38 MB to 45 MB to improve the<br />
percentage of hits in the cache. We use the command:<br />
SETXCF START,ALTER,STRNM=RLS_CACHE,SIZE=45000<br />
► Stop duplexing through the use of the following command:<br />
SETXCF STOP,RB,DUPLEX,STRNM=IGWLOCK00, KEEP=OLD<br />
► Do not do anything about cross invalidation.<br />
► Do not do anything to decrease the splits, we are only changing the<br />
parameters directly affecting RLS behavior.
Modification results<br />
When performing run 6 (three JOBs, three systems, RLS, RLS tuning), we<br />
observe the following aspects in several RMF reports:<br />
► BMF LRU algorithm is not increased.<br />
► Maximum BMF pool size is around 168 MB (it was 145 MB), the<br />
RLS_MAX_POOL_SIZE is 180 MB. No paging is observed.<br />
► Average I/O response time per GET/PUT was 0.001 second, including the<br />
requests served in cache and buffers. The accuracy of the measurement<br />
does not allow comparison with the previous value (also 0.001 second).<br />
► Data reads found in the BMF is 62% (it was 58%), index reads 98% (it was<br />
97%), this is good.<br />
► CPU time consumed by BMF to manage the local buffers is 337.0 ms (it was<br />
387.3 ms).<br />
► Data reads found in the CF is 9.4% (it was 10.0%), index reads 1.7% (it was<br />
2.6%).<br />
► Data reads found in DASD is 28.8% (it was 31.8%), index read is 0.7% (it was<br />
0.5%), this is good.<br />
► DASD device with four static PAV aliases, allowing 451 IO/second (it was 528<br />
IO/second) with an average response time of 0.6 ms (it was 0.8) and average<br />
connect time of 0.3 (it was 0.5 ms).<br />
► Cross invalidation is 20% (it was 20%), without directory reclaims XI.<br />
► Real lock contention is 3.8 (it was 4.2%) and less than 0.1 false contention in<br />
IGWLOCK00.<br />
► CF performance was outstanding with no queues at all.<br />
► WLM service class had a current execution velocity of 87.8% (it was 85%),<br />
that is very good.<br />
► CI Splits in all runs around 21K (it was 21K), and no CA splits.<br />
► Comparing run 6 with run 5, we see:<br />
– Less EXCPs and less connect time. This decrease is caused by better<br />
local buffering. Data reads in the BMF is 62% (it was 58%). Allowing less<br />
I/Os, 451 IO/second (it was 528 IO/second). The cache is used in the<br />
same amount as in run 5, even with a larger cache. It indicates no<br />
contention in the cache. Also remember that all the writes must have an<br />
I/O operation.<br />
– Medium decrease in the CPU time. The major reason for that is the lack of<br />
duplexing. Better buffering only decreases the CPU time in BMF code by<br />
50 ms (387 - 337).<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 305
306 <strong>VSAM</strong> <strong>Demystified</strong><br />
– The elapsed time is less because less I/O and less CPU consumption.<br />
Final comments on our experiments<br />
The results show that with a certain security margin, we may state that the<br />
introduction of <strong>VSAM</strong> RLS will not harm your performance. It may produce, even<br />
deliver, better performance. Compare the results of run 2 and run 6. Discarding<br />
the expected cost of CPU, we have a significant improvement in the elapsed<br />
time. Refer to “CICSPlex RLS performance comparison” on page 299 to be<br />
reassured that the same scenario could happen with CICS.<br />
Using RLS mode in an ESDS organization<br />
Usually the first implementations of RLS mode in customers are done in KSDS<br />
spheres. There are some concerns in exploiting RLS in other <strong>VSAM</strong> data<br />
organizations such as ESDS, RRDS. It was tested by IBM and works as<br />
described in manuals.<br />
However, there is a performance recommendation for ESDS, to avoid heavy<br />
direct insert rate (at end of the ESDS). Because of integrity reasons, a lock is<br />
held during the I/O operation for inserts. Depending on the rate, we may observe<br />
the building up of a queue. Before planning to access ESDS or RRDS in RLS<br />
mode, we recommend that you refer to APAR OA01932.<br />
5.7.6 RMF and <strong>VSAM</strong> RLS<br />
Refer to “Resource measurement facility” on page 136 for more information on<br />
this product. There are several RMF reports picturing the <strong>VSAM</strong> RLS<br />
performance such as Monitor III: RLSLRU, RLSSC and RLSDS. There are also<br />
the traditional CF reports that describe generically the CF structures and their<br />
links. There we look for information about the SYS<strong>VSAM</strong> structures, such as<br />
IGWLOCK00 and the RLS cache structures.<br />
We now describe each of these reports, stressing the keys aspects towards<br />
performance management of each field.<br />
<strong>VSAM</strong> RLS Monitor III reports: RLSLRU<br />
The RLSLRU report provides Local Buffer Manager LRU statistics for each<br />
system. The data in this report can help you in adjusting the goal / limit for the<br />
local buffer pool. Before going through this report, which pictured in Figure 5-19<br />
on page 308, refer to 5.1.3, “How does RLS work?” on page 244.<br />
So first, let’s go to the fields in RLSLRU report, that need additional explaining:<br />
► Avg CPU Time: This is the average CPU time spent by BMF LRU processing<br />
during each reporting interval in milliseconds. We guess that this field could<br />
be used for comparison along different RLS workloads. These workloads can
e more or less buffer friendly, or to produce more cross invalidation causing<br />
a change in CPU consumption.<br />
► Buffer Size Goal: This is the buffer size goal (bytes) as stated in IGDSMSxx<br />
RLS_MAX_POOL_SIZE. If goal is greater than 1.5 GB, then the word MAX is<br />
displayed.<br />
► Buffer Size High: This is the buffer size actual high value (bytes).<br />
Cursor-sensitive control on a system line displays a pop-up panel with buffer<br />
counts by pool for the selected system. There are sixteen storage pools<br />
(2K, 4K,..., 32K) available. Each one is presented with the low, high and<br />
average number of buffers.<br />
► Accel%: This is the percentage of Buffer Manager LRU cycle routine, when<br />
local buffer pool size is over the goal and buffer aging algorithms were<br />
accelerated.<br />
► Reclaim%: This is the percentage of Buffer Manager LRU cycle routine, when<br />
BMF was five times over the goal and buffer aging algorithms were bypassed<br />
to reclaim buffers.<br />
► BMF Read%: This is the percentage of GET hits in local buffer pool, the CI is<br />
in local buffer pool and valid. Refer to “Control Interval cross invalidation” on<br />
page 287 to understand the meaning of valid. The recommendation here is<br />
around 80% for direct. Less than this, you should evaluate the level of cross<br />
invalidation, if it is OK, maybe we suggest to increase your local buffer pool<br />
maximum size, if have enough virtual storage. If it is not OK refer to the<br />
recommendations displayed in “Control Interval cross invalidation” on<br />
page 287. Chances are that your workloads be cache unfriendly with re-visits<br />
to the same data.<br />
► Cache Read%: This is the percentage of GET hits in the CF cache structure.<br />
Recommended value around 15%, if less maybe to increase the size of the<br />
CF cache structure.<br />
► DASD Read%: This is the percentage of GET I/O requests in DASD.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 307
308 <strong>VSAM</strong> <strong>Demystified</strong><br />
RMF V1R2 <strong>VSAM</strong> LRU Overview - SANDBOX Line 1 of 3<br />
Command ===> Scroll ===><br />
CSR<br />
Samples: 100 Systems: 3 Date: 03/12/03 Time: 13.33.20 Range: 100<br />
Sec<br />
MVS Avg CPU - Buffer Size - Accel Reclaim ------ Read -----<br />
System Time Goal High % % BMF% CF% DASD%<br />
SC63 13.08 100M 31M 0.0 0.0 33.3 0.4 66.4<br />
SC64 8.441 100M 23M 0.0 0.0 68.2 0.1 31.6<br />
SC65 11.95 100M 30M 0.0 0.0 33.6 0.4 66.0<br />
Figure 5-19 RLSLRU report<br />
<strong>VSAM</strong> RLS Monitor III reports: RLSSC and RLSDS<br />
RLSSC and RLSDS reports show the same fields. The difference is the scope.<br />
RLSSC groups data in storage classes and RLSDS groups it in <strong>VSAM</strong> data sets<br />
terms. Both reports cover the use of local buffers and CF cache. Refer to “How<br />
does RLS work?” on page 244.<br />
To gather the data about data sets the option <strong>VSAM</strong>RLS must be set in Monitor<br />
III ERBRMFxx Parmlib member:<br />
<strong>VSAM</strong>RLS ADD(data set name mask)<br />
DELETE(data set name mask)<br />
This option controls the collection of <strong>VSAM</strong> RLS activity data. When you specify<br />
<strong>VSAM</strong>RLS or allow the default value to take effect, activity data is gathered for<br />
<strong>VSAM</strong> RLS by storage class. In addition, data set masks can be specified to<br />
collect data by <strong>VSAM</strong> spheres, too. To suppress the gathering of <strong>VSAM</strong> RLS<br />
data, specify NO<strong>VSAM</strong>RLS.
RMF V1R2 <strong>VSAM</strong> RLS Activity - SANDBOX Line 1 of 7<br />
Command ===> Scroll ===> CSR<br />
Samples: 100 Systems: 3 Date: 03/12/03 Time: 13.33.20 Range: 100 Sec<br />
LRU Status : Good<br />
Contention % : 0.0<br />
False Cont % : 0.0<br />
Sphere/DS Access Resp -------- Read ---------- ------ BMF ------- Write<br />
Time Rate BMF% CF% DASD% Valid% False Inv% Rate<br />
MHLRES2.<strong>VSAM</strong>.RLSEXT<br />
MHLRES2.<strong>VSAM</strong>.RLSEXT.DATA<br />
DIR 0.109 726.6 17.8 0.3 81.9 44.3 55.75 294.0<br />
SEQ 0.000 0.00 0.0 0.0 0.0 0.0 0.00 0.00<br />
MHLRES2.<strong>VSAM</strong>.RLSEXT.INDEX<br />
DIR 0.002 43.92 68.0 0.0 32.0 78.7 21.21 6.76<br />
SEQ 0.000 0.00 0.0 0.0 0.0 0.0 0.00 0.00<br />
Figure 5-20 RLSSDS<br />
The collection of <strong>VSAM</strong> RLS activity data by <strong>VSAM</strong> spheres can be controlled by<br />
following sub options:<br />
► ADD: Start collection for all <strong>VSAM</strong> data sets which are covered by the mask.<br />
► DEL: Stop collection for all <strong>VSAM</strong> data sets which are covered by the mask.<br />
If by any reason, you stop and start SMS<strong>VSAM</strong>, then RMF Monitor III Data<br />
gatherer (RMGAT) must be restarted to capture <strong>VSAM</strong> RLS data again.<br />
These reports provide <strong>VSAM</strong> RLS activity regarding GET and PUT requests<br />
accessing the local buffers, the CF cache structures and DASD. This data might<br />
help you in answering important questions like:<br />
► Are there problems with Least Recently Used algorithms (LRU) or buffer pool<br />
sizes?<br />
► Are the CF cache structures too small?<br />
So now, let’s go to the fields presented in Figure 5-20 for additional explaining:<br />
► LRU status: This indicates the status of local buffers controlled by BMF.<br />
SMS<strong>VSAM</strong>, where the LRU algorithm is used. The size of this buffer pool is<br />
dynamically trimmed by SMS<strong>VSAM</strong> accordingly with installation parameter<br />
RLS_MAX_POOL_SIZE in IGDSMSxx member in Parmlib. Refer to 5.1.3,<br />
“How does RLS work?” on page 244.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 309
310 <strong>VSAM</strong> <strong>Demystified</strong><br />
► We have three statuses:<br />
– Good. The local buffer pool size is below its goal on all systems.<br />
– Accelerated. The local buffer pool size is over the goal on at least one<br />
system, and the buffer aging algorithms are accelerated. It means<br />
practically that the buffer pool is loosing its efficiency and the CIs are<br />
existing less time in such buffers. Maybe it is time to think about increasing<br />
the local buffer pool, if you have enough central storage to avoid paging. If<br />
you do not have enough central storage, let’s hope that at the next level of<br />
buffering, the cache structure will do the job of avoiding I/O.<br />
– Reclaimed. The local buffer pool size is over the goal on at least one<br />
system, and the buffer aging algorithms were bypassed to reclaim buffers.<br />
The same as accelerated, but much more dramatic.<br />
► Contention%: This is the percentage of true lock contentions, the percentage<br />
of requests issued by exploiters delayed due to real contention on a lock in<br />
relation to the total number of requests. It does not include false contention.<br />
The recommendation is less than 2.0%. Refer to “Coupling Facility structure<br />
activity report” on page 314, to see other RMF reports showing such<br />
contention.<br />
► False Contention%: This is the percentage of false LOCK contentions, the<br />
percentage of requests issued by exploiters delayed due to false contention<br />
on a lock in relation to the total number of requests. The recommended value<br />
here is around 0.1% (for IGWLOCK00). Refer to “Coupling Facility structure<br />
activity report” on page 314, to see other RMF reports showing such<br />
contention.<br />
► Resp Time: This is average I/O response time of all I/O requests generated by<br />
the line portrayed entity, such as: storage class, data set, system (cache<br />
structure) in seconds. It includes IOSQ time, pending time, disconnect and<br />
connect time.<br />
► Read: This describes the behavior of GET I/O operations. Shows the rate and<br />
the distribution of where the GET is served: local buffer pool, SYS<strong>VSAM</strong><br />
cache structure in the CF, or DASD. Follows the sub-headings:<br />
– Rate: This is the average number of logical records read through a GET,<br />
per second.<br />
– BMF%: This is the percentage of GET hits in a local buffer pool, the CI is in<br />
local buffer pool and valid. Refer to “Control Interval cross invalidation” on<br />
page 287 to understand the meaning of valid. Pay attention to the fact that<br />
sometimes the CI is invalid because another logical record (not the one<br />
required) was updated by another SMS<strong>VSAM</strong>. The recommendation here<br />
is around 80% for direct. If it’s less than this, you should evaluate the level<br />
of cross invalidation. If such a figure is normal, we suggest that you
increase your local buffer pool maximum size, if have enough virtual<br />
storage.<br />
– CF%: This is the percentage of GET hits in the CF cache structure. The<br />
recommended value is approximately 15%; if less, increase the size of the<br />
CF cache structure.<br />
– DASD%: This is the percentage of GET I/O requests in DASD.<br />
► BMF:<br />
– VALID%: This is the percentage of BMF GETs hits that were valid. If a<br />
buffer is found in the local cache and is determined to be valid according to<br />
the information in local control blocks, this counts as a BMF valid READ<br />
hit.<br />
– FALSE INV%: This is the percentage of READ requests when the copy in<br />
the BMF local cache was invalid, because the coupling facility has lost<br />
track of the integrity status of the buffer.<br />
► WRITE RATE: This is the total number of BMF PUTs requests per second.<br />
Coupling Facility RMF Post Processor reports<br />
These reports are created by RMF monitor III data gatherer in an SMF record<br />
format. Later these records are processed by the Postprocessor generating the<br />
sysout reports. There are also CF reports online produced by RMF Monitor III<br />
data gatherer and shown under TSO Monitor III data reporter. These reports are<br />
not covered here, because their fields are a repetition of the Post Processor<br />
fields.<br />
The CF Postprocessor reports are generic showing the performance aspects of<br />
all the CFs and all the structures. Here, we only covered the fields and the<br />
examples about RLS structures. The reports are modified on purpose to highlight<br />
such structures only. For a full description of all fields, we recommend reading<br />
OS/390 MVS Parallel Sysplex Capacity Planning, SG24-4680.<br />
Coupling Facility Usage Summary report<br />
This report shows the use of the CF in number of requests, storage and<br />
processor. You can use this section to evaluate the status of all structures and<br />
how the CF as a whole is being utilized. Refer to Figure 5-21.<br />
Structure Summary<br />
The structure summary lists all structures ordered by type and name. For each<br />
structure the status at the end of the RMF data collection interval is presented:<br />
► ACTIVE: Storage is allocated and there is connection to at least one system.<br />
There is also the information about duplexing such as primary (PRIM) or<br />
secondary (SEC).<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 311
312 <strong>VSAM</strong> <strong>Demystified</strong><br />
► INACTV: Storage is allocated but there is no connection to any system, these<br />
structures are called persistent. IGWLOCK00 is persistent.<br />
► UNALLOC: The structure was active at some point in time during the interval<br />
and did not exist at the end of the RMF interval.<br />
C O U P L I N G F A C I L I T Y A C T I V I T Y<br />
z/OS V1R4 SYSPLEX SANDBOX START 03/15/2003-15.10.00 INTERVAL 000.20.00<br />
RPT VERSION V1R2 RMF END 03/15/2003-15.30.00 CYCLE 01.000 SECONDS<br />
Figure 5-21 CF Usage Summary report<br />
PAGE 1<br />
------------------------------------------------------------------------------------------------------------------------------<br />
COUPLING FACILITY NAME = CF02<br />
TOTAL SAMPLES(AVG) = 599 (MAX) = 600 (MIN) = 599<br />
------------------------------------------------------------------------------------------------------------------------------<br />
COUPLING FACILITY USAGE SUMMARY<br />
------------------------------------------------------------------------------------------------------------------------------<br />
STRUCTURE SUMMARY<br />
------------------------------------------------------------------------------------------------------------------------------<br />
% OF % OF AVG LST/DIR DATA LOCK DIR REC/<br />
STRUCTURE ALLOC CF # ALL REQ/ ENTRIES ELEMENTS ENTRIES DIR REC<br />
TYPE NAME STATUS CHG SIZE STORAGE REQ REQ SEC TOT/CUR TOT/CUR TOT/CUR XI'S<br />
LOCK IGWLOCK00 ACTIVE 14M 1.5 767562 32.7 639.63 36K 0 2097K N/A<br />
SEC 2 0 85 N/A<br />
CACHE RLS_CACHE ACTIVE X 10M 1.0 1499K 63.8 1249.1 25K 778 N/A 254K<br />
25K 393 N/A 254K<br />
PROCESSOR SUMMARY<br />
------------------------------------------------------------------------------------------------------------------------------<br />
COUPLING FACILITY 2064 MODEL 1C7 CFLEVEL 12<br />
AVERAGE CF UTILIZATION (% BUSY) 3.7 LOGICAL PROCESSORS: DEFINED 2 EFFECTIVE 2.0<br />
For each active structure, the section shows the allocated structure size, the total<br />
number of requests (issued by the exploiter to the XES API for the structure), and<br />
the average number of requests/second.<br />
There is also the last four columns in the report. The information in these<br />
columns can be used to validate the size of various types of structures. The<br />
TOT/CUR (total/current) in-use values indicate for each entity described in the<br />
column how many of those are allocated (TOT) and how many are in use (CUR)<br />
at end of the RMF interval, so it is not a high water mark. Some knowledge of the<br />
structure is required to interpret these data.<br />
► Cache structures (as RLS_CACHE)<br />
– DIR ENTRIES informs how many cache directory entries are<br />
allocated/in-use. In the report you may see that the RLS_CACHE directory<br />
is full with 25K entries.<br />
– DATA ELEMENTS informs how many cache elements (data) are<br />
allocated/in-use. Here you can see any mis-proportioned in terms of<br />
entry-to-element ratio (one never fills up but the other does). In the report
you may see that the RLS_CACHE has 778 elements allocated and 393<br />
used.<br />
– The DIR RECLAIMS can be used as an indicator whether the directory of<br />
a cache structure is over-committed. Whenever a shortage of directory<br />
entries occurs, the CF reclaims in-use directory entries associated with<br />
unchanged data. These reclaimed items are used to satisfy new requests<br />
for directory entries by the database manager. All users of the data item<br />
represented by the directory entry must be notified that their copy of the<br />
data item is invalid. When the database manager needs access to the now<br />
invalidated data item, the item must be reread from DASD and registered<br />
with the CF.<br />
Avoid Directory Reclaims, this activity results in increased I/O activity to the<br />
cluster to reacquire a referenced data item. To reacquire data items and to<br />
re-register them to the CF may result in increased CPU utilization and<br />
prolonged transaction response times whenever a read miss occurs in the<br />
local buffer pool.<br />
Directory reclaims can be eliminated by increasing the number of directory<br />
entries for a particular structure. This can be accomplished by:<br />
– Increasing the size of the structure. For structures as IGWLOCK00 with<br />
data elements and directory entries, both increases in the ratio are<br />
specified by SMS<strong>VSAM</strong>.<br />
– Changing the proportion of the structure. Some cache structure exploiters<br />
allow the installation to specify the ratio of directory elements to data<br />
elements (DB2, IMS). IGWLOCK00 does not have this capability, it is said<br />
that it constantly adjusts the data-to-directory ratio to minimize the number<br />
of buffer invalidation.<br />
► Lock structures (IGWLOCK00)<br />
LST ENTRIES informs how many lock lists (point to the lock data) are<br />
allocated/in-use. In the report you may see that the IGWLOCK00 is almost<br />
totally empty with 36K allocated and only 2 used.<br />
LOCK ENTRIES contains record data entries. In the report you may see that<br />
the IGWLOCK00 has 2097K record data allocated and only 85 in use.<br />
However, the critical data about lock structures you may find at the FALSE<br />
CONTENTION data for the lock structure in “Coupling Facility structure<br />
activity report” on page 314.<br />
Processor Summary<br />
The processor summary section shows the CF model and version.<br />
Average CF Utilization: This indicates the real CP utilization (discarding the<br />
CFCC ethernal loop effect) of the LP that hosts the CF.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 313
314 <strong>VSAM</strong> <strong>Demystified</strong><br />
Logical processors:<br />
► Defined: How many logical processors are defined to this CF.<br />
► Effective: Number of effective available logical processors in a shared<br />
environment. CFCC measures the time of real command execution as well as<br />
the time waiting for work. The reported value shows the ratio between the<br />
LPAR dispatch time (CFCC execute and loop time) and the RMF interval<br />
length.<br />
Coupling Facility structure activity report<br />
The structure activity report in Figure on page 314 presents, for all structures:<br />
► In the REQUESTS columns, the number of synchronous (SYNC),<br />
asynchronous (ASYNC) and changed (CHNGD) requests (refer to “CF<br />
synchronous and asynchronous requests” on page 284) and the average<br />
service times and standard deviation for these requests (SERV TIME(MIC)).<br />
The CHNGD line applies to the synch requests changed to asynch because<br />
the subchannel was busy.<br />
The service times of approximately 50 microseconds shown in the report<br />
indicates a fast CF hardware.<br />
► In the DELAYED REQUESTS columns, the number requests that were<br />
delayed due to the following conditions:<br />
– NO SCH: Subchannel contention. The number of asynchronous requests<br />
that were delayed due to subchannel busy conditions.<br />
– PR WT: Peer subchannel wait contention. Applies to duplexed requests,<br />
which always require two subchannels. Number of requests a subchannel<br />
for the operation targeted to the peer (secondary) structure was not<br />
available. Only in the primary structure. Always about 100% for secondary<br />
monitor delay times.<br />
– PR CMP: Waiting-for-peer-completion contention. Applies to duplexed<br />
requests, which always require two subchannels. Number of requests that<br />
one of the two duplexed operations has completed, but the completed<br />
subchannel remains unavailable for use until the peer operation<br />
completes. It shows disparity in response times of CFs.<br />
– DUMP: Waiting for the DUMP structure serialization. The contents of the<br />
other are dumped in this structure, to reduce the serialization time of the<br />
structure being dumped.<br />
The /DEL field indicates the average delay time for each delayed request, and<br />
/ALL the average delay time taking in consideration all the requests (including the<br />
ones which do not suffer delay).
The EXTERNAL REQUEST CONTENTIONS gives information on lock<br />
contention for serialized list and lock structures, as well as data access statistics<br />
for cache structures. A discussion for the SMS<strong>VSAM</strong> structures follows:<br />
C O U P L I N G F A C I L I T Y A C T I V I T Y<br />
z/OS V1R4 SYSPLEX SANDBOX START 03/15/2003-15.10.00 INTERVAL 000.20.00<br />
RPT VERSION V1R2 RMF END 03/15/2003-15.30.00 CYCLE 01.000 SECONDS<br />
Figure 5-22 CF Structure Activity report (IGWLOCK00)<br />
PAGE 13<br />
------------------------------------------------------------------------------------------------------------------------------<br />
COUPLING FACILITY NAME = CF01<br />
------------------------------------------------------------------------------------------------------------------------------<br />
COUPLING FACILITY STRUCTURE ACTIVITY<br />
------------------------------------------------------------------------------------------------------------------------------<br />
STRUCTURE NAME = IGWLOCK00 TYPE = LOCK STATUS = ACTIVE PRIMARY<br />
# REQ -------------- REQUESTS ------------- -------------- DELAYED REQUESTS -------------<br />
SYSTEM TOTAL # % OF -SERV TIME(MIC)- REASON # % OF ---- AVG TIME(MIC) ----- EXTERNAL REQUEST<br />
NAME AVG/SEC REQ ALL AVG STD_DEV REQ REQ /DEL STD_DEV /ALL CONTENTIONS<br />
SC63 259K SYNC 259K 33.4 50.4 123.1 NO SCH 0 0.0 0.0 0.0 0.0 REQ TOTAL 249K<br />
215.8 ASYNC 252 0.0 152.7 144.6 PR WT 256K 99.0 3.8 5.3 3.8 REQ DEFERRED 44K<br />
CHNGD 0 0.0 INCLUDED IN ASYNC PR CMP 150K 57.9 6.5 22.3 3.8 -CONT 44K<br />
-FALSE CONT 1439<br />
SC64 257K SYNC 257K 33.1 51.0 126.5 NO SCH 0 0.0 0.0 0.0 0.0 REQ TOTAL 250K<br />
214.1 ASYNC 249 0.0 446.6 525.8 PR WT 255K 99.1 3.7 4.7 3.7 REQ DEFERRED 46K<br />
CHNGD 0 0.0 INCLUDED IN ASYNC PR CMP 149K 57.9 6.7 23.7 3.9 -CONT 46K<br />
-FALSE CONT 1869<br />
SC65 259K SYNC 259K 33.4 49.6 115.9 NO SCH 0 0.0 0.0 0.0 0.0 REQ TOTAL 249K<br />
215.8 ASYNC 251 0.0 236.1 154.0 PR WT 256K 99.0 3.9 29.7 3.9 REQ DEFERRED 45K<br />
CHNGD 0 0.0 INCLUDED IN ASYNC PR CMP 148K 57.2 6.5 19.3 3.7 -CONT 45K<br />
-FALSE CONT 1594<br />
------------------------------------------------------------------------------------------------------------------------------<br />
TOTAL 775K SYNC 774K 100 50.3 121.9 NO SCH 0 0.0 0.0 0.0 0.0 REQ TOTAL 749K<br />
645.8 ASYNC 752 0.1 277.8 348.5 PR WT 768K 99.0 3.8 17.6 3.8 REQ DEFERRED 136K<br />
CHNGD 0 0.0 PR CMP 447K 57.7 6.6 21.9 3.8 -CONT 135K<br />
-FALSE CONT 4902<br />
Lock Structures for External Requests Contentions<br />
RMF reports in REQ TOTAL, the number of requests issued by SMS<strong>VSAM</strong> to the<br />
XES API for the IGWLOCK00 structure, and in REQ DEFERRED the number of<br />
requests deferred due to contention. REQ TOTAL must be numerically close to #<br />
REQ in the same report, the difference is explained by the way XES account<br />
requests for unlocking.<br />
A request can be deferred due to:<br />
► True lock contention, measured by (CONT - FALSE CONT)<br />
► False lock contention measured by FALSE CONT<br />
► XES internal processing delays - if REQ DEFERRED is equal to CONT, there<br />
is no such type of delay.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 315
316 <strong>VSAM</strong> <strong>Demystified</strong><br />
As a result of lock contention you may see increased XCF activity caused by<br />
SMS<strong>VSAM</strong>s negotiating the lock status.<br />
IGWLOCK00 shows 18% (135/749) for true lock contention. This is too much; the<br />
rule is 2 percent. True contention is application dependent; therefore, it is<br />
necessary to identify the workload using the lock structure. For example,<br />
long-running batch jobs that do not commit the locks can cause high true<br />
contention on lock structures.<br />
The false lock contention is a little bit more than 1% (4/268) of the deferred<br />
requests, but the recommended value for IGWLOCK00 is 0.1 percent. This true<br />
contention should be further investigated. Refer to “True and false contention in<br />
lock structures” on page 289.<br />
Cache Structures for Data Access<br />
For this analysis, in Figure 5-23 on page 317, review the data about the<br />
RLS_CACHE structure.<br />
By the way, the service time is approximately 20 microseconds for this structure,<br />
which indicates a fast CF hardware.<br />
DATA ACCESS statistics for cache structures are acquired from counters in the<br />
CF; they cannot be broken down into individual systems. Only SMS<strong>VSAM</strong> knows<br />
how efficiently the local buffer and cache structure are being used. Depending on<br />
the cache structure implementation, one or more counts can be zero.<br />
► READS and WRITES indicate how often the CFCC returned data to<br />
SMS<strong>VSAM</strong> (read) and how often SMS<strong>VSAM</strong> placed changed data into the<br />
RLS_CACHE structure. If you observe a high number of WRITES and a small<br />
number of READS (as our case), it means that the efficiency of the cache is<br />
low and something needs to be done. Read “SMS<strong>VSAM</strong> buffering and<br />
caching” on page 285.<br />
► CASTOUTS is a count of the number of times an explorer (demanded by<br />
CFCC) retrieves a changed data entry, writes the data to DASD causing the<br />
changed attribute to be reset to unchanged in the structure. This happens<br />
when the structure occupancy reaches a CFCC internal threshold. As<br />
SMS<strong>VSAM</strong> uses a store-through algorithm no DASD castouts are needed to<br />
make room in the structure.<br />
► XIs shows the number of times a data item residing in a local buffer pool was<br />
marked invalid by the CF during the RMF interval. The counter reflects the<br />
amount of data sharing among the users of the cache structure and the<br />
amount of write/update activity against the databases. Refer to “Control<br />
Interval cross invalidation” on page 287.
STRUCTURE NAME = RLS_CACHE TYPE = CACHE STATUS = ACTIVE<br />
# REQ -------------- REQUESTS ------------- -------------- DELAYED REQUESTS -------------<br />
SYSTEM TOTAL # % OF -SERV TIME(MIC)- REASON # % OF ---- AVG TIME(MIC) -----<br />
NAME AVG/SEC REQ ALL AVG STD_DEV REQ REQ /DEL STD_DEV /ALL<br />
1<br />
SC63 527K SYNC 527K 35.1 21.7 135.5 NO SCH 0 0.0 0.0 0.0 0.0<br />
439.0 ASYNC 0 0.0 0.0 0.0 PR WT 0 0.0 0.0 0.0 0.0<br />
CHNGD 0 0.0 INCLUDED IN ASYNC PR CMP 0 0.0 0.0 0.0 0.0<br />
DUMP 0 0.0 0.0 0.0 0.0<br />
SC64 535K SYNC 535K 35.7 21.6 123.0 NO SCH 0 0.0 0.0 0.0 0.0<br />
445.7 ASYNC 0 0.0 0.0 0.0 PR WT 0 0.0 0.0 0.0 0.0<br />
CHNGD 0 0.0 INCLUDED IN ASYNC PR CMP 0 0.0 0.0 0.0 0.0<br />
DUMP 0 0.0 0.0 0.0 0.0<br />
SC65 437K SYNC 437K 29.2 21.4 102.7 NO SCH 0 0.0 0.0 0.0 0.0<br />
364.4 ASYNC 250 0.0 411.0 342.9 PR WT 0 0.0 0.0 0.0 0.0<br />
CHNGD 0 0.0 INCLUDED IN ASYNC PR CMP 0 0.0 0.0 0.0 0.0<br />
DUMP 0 0.0 0.0 0.0 0.0<br />
------------------------------------------------------------------------------------------------------------------------------<br />
TOTAL 1499K SYNC 1499K 100 21.5 122.2 NO SCH 0 0.0 0.0 0.0 0.0 -- DATA ACCESS ---<br />
1249 ASYNC 250 0.0 411.0 342.9 PR WT 0 0.0 0.0 0.0 0.0 READS 79246<br />
CHNGD 0 0.0 PR CMP 0 0.0 0.0 0.0 0.0 WRITES 572353<br />
DUMP 0 0.0 0.0 0.0 0.0 CASTOUTS 0<br />
Figure 5-23 CF Structure Activity report (RLS_CACHE)<br />
Subchannel Activity report<br />
This report is presented in Figure 5-24. Before we start, here is a recapitulization<br />
of CF hardware.<br />
A CF request is first processed by XES, then transferred to the CF, if there is a<br />
free link, processed by a CF CP, and sent back to OS/390 via the CF link. This<br />
report discusses the possible delays for those requests.<br />
Each CF link in peer mode has seven subchannels, and seven buffers, per each<br />
image that it is serving (MIF). Subchannels are busy from the time MVS sends<br />
the request until the time MVS processes the response. Links are only busy for<br />
the time it takes for the data to travel between CPCs.<br />
CF Links do not support CPMF, so there is no reporting anywhere of actual CF<br />
link utilization. Actual link utilization is rarely an issue.<br />
The count used to build this report are not available on a per structure basis.<br />
Some of the fields have the same meaning as the ones found in the report shown<br />
in Figure 5-23. Here, we only mention the fields with a more complete<br />
comprehension:<br />
► PTH BUSY: Measures the number of times that a synchronous request gets a<br />
free subchannel but encounters all path busy condition. This situation can<br />
occur because the CF link is shared (MIF) between several z/OS images. The<br />
request “spins” until the link becomes available. If this figure is far from zero,<br />
you should dedicate the CF link to the LP. Our number is zero.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 317
318 <strong>VSAM</strong> <strong>Demystified</strong><br />
► DELAYED REQUESTS: These columns have the same meaning of the CF<br />
Structure report, but organized by the type of the structures.<br />
C O U P L I N G F A C I L I T Y A C T I V I T Y<br />
z/OS V1R4 SYSPLEX SANDBOX START 03/15/2003-15.10.00 INTERVAL 000.20.00<br />
RPT VERSION V1R2 RMF END 03/15/2003-15.30.00 CYCLE 01.000 SECONDS<br />
Figure 5-24 Subchannel Activity report<br />
CF to CF Activity report<br />
This report is presented in Figure 5-25.<br />
PAGE 11<br />
------------------------------------------------------------------------------------------------------------------------------<br />
COUPLING FACILITY NAME = CF02<br />
------------------------------------------------------------------------------------------------------------------------------<br />
SUBCHANNEL ACTIVITY<br />
------------------------------------------------------------------------------------------------------------------------------<br />
# REQ ----------- REQUESTS ----------- ------------------ DELAYED REQUESTS --------------<br />
SYSTEM TOTAL -- CF LINKS -- PTH # -SERVICE TIME(MIC)- # % OF ------ AVG TIME(MIC) ------<br />
NAME AVG/SEC TYPE GEN USE BUSY REQ AVG STD_DEV REQ REQ /DEL STD_DEV /ALL<br />
SC63 814343 ICP 2 2 0 SYNC 783206 32.9 132.6 LIST/CACHE 0 0.0 0.0 0.0 0.0<br />
678.6 SUBCH 28 14 ASYNC 22124 306.4 415.3 LOCK 0 0.0 0.0 0.0 0.0<br />
CHANGED 0 INCLUDED IN ASYNC TOTAL 0 0.0<br />
UNSUCC 0 0.0 0.0<br />
SC64 821174 ICP 2 2 0 SYNC 789697 32.9 125.6 LIST/CACHE 0 0.0 0.0 0.0 0.0<br />
684.3 SUBCH 28 14 ASYNC 21817 232.8 435.0 LOCK 0 0.0 0.0 0.0 0.0<br />
CHANGED 0 INCLUDED IN ASYNC TOTAL 0 0.0<br />
UNSUCC 0 0.0 0.0<br />
SC65 741811 ICP 2 2 0 SYNC 693791 33.8 109.2 LIST/CACHE 0 0.0 0.0 0.0 0.0<br />
618.2 SUBCH 28 14 ASYNC 37460 161.3 313.0 LOCK 0 0.0 0.0 0.0 0.0<br />
CHANGED 0 INCLUDED IN ASYNC TOTAL 0 0.0<br />
UNSUCC 0 0.0 0.0<br />
This report is introduced because of SM duplexing. In such type of duplexing<br />
there is a conversation between the two CFs. The fields pictured in the report<br />
show details of the conversation. All of them are already covered in this topic in<br />
other reports.
C O U P L I N G F A C I L I T Y A C T I V I T Y<br />
z/OS V1R4 SYSPLEX SANDBOX START 03/15/2003-15.10.00 INTERVAL 000.20.00<br />
RPT VERSION V1R2 RMF END 03/15/2003-15.30.00 CYCLE 01.000 SECONDS<br />
Figure 5-25 CF to CF report<br />
PAGE 12<br />
------------------------------------------------------------------------------------------------------------------------------<br />
COUPLING FACILITY NAME = CF02<br />
------------------------------------------------------------------------------------------------------------------------------<br />
CF TO CF ACTIVITY<br />
------------------------------------------------------------------------------------------------------------------------------<br />
# REQ ----------- REQUESTS ----------- -------------- DELAYED REQUESTS --------------<br />
PEER TOTAL -- CF LINKS -- # -SERVICE TIME(MIC)- # % OF ------ AVG TIME(MIC) ------<br />
CF AVG/SEC TYPE USE REQ AVG STD_DEV REQ REQ /DEL STD_DEV /ALL<br />
CF01 1536K ICP 2 SYNC 1536K 2.1 1.4 SYNC 0 0.0 0.0 0.0 0.0<br />
1279.8<br />
CF02 0 ICP 2 SYNC 0 0.0 0.0 SYNC 0 0.0 0.0 0.0 0.0<br />
0.0<br />
XCF Activity Report (XCF Usage by Member)<br />
This report shows the XCF activity caused by SMS<strong>VSAM</strong>. The majority of this<br />
activity is caused by the conversation among SMS<strong>VSAM</strong>s to verify if a lock<br />
contention is true or false. The name of the group used by SYS<strong>VSAM</strong> is<br />
IXCLOxxx. We have the impression that the number in the reports do not need<br />
further explanation. For example, the SMS<strong>VSAM</strong> running in SC63 sends 11890<br />
messages to SMS<strong>VSAM</strong> running in SC64 (both in IXCLO001 group). See<br />
Figure 5-26.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 319
X C F A C T I V I T Y<br />
PAGE 3<br />
z/OS V1R4 SYSTEM ID SC63 START 03/17/2003-18.30.00 INTERVAL 000.10.00<br />
RPT VERSION V1R2 RMF END 03/17/2003-18.40.00 CYCLE 1.000 SECONDS<br />
-<br />
XCF USAGE BY MEMBER<br />
------------------------------------------------------------------------------------------------------------------------------------<br />
MEMBERS COMMUNICATING WITH SC63 MEMBERS ON SC63<br />
----------------------------------------------------------------- -------------------------------------------------------<br />
REQ REQ<br />
FROM TO REQ REQ<br />
GROUP MEMBER SYSTEM SC63 SC63 GROUP MEMBER OUT IN<br />
IXCLO001 M166 SC64 11,890 11,960 IXCLO001 M167 31,872 31,897<br />
M168 SC65 11,493 11,448 ---------- ----------<br />
---------- ---------- TOTAL 31,872 31,897<br />
TOTAL 23,383 23,408<br />
IXCLO004 M759 SC64 80 63 IXCLO004 M760 185 195<br />
M761 SC65 46 73 ---------- ----------<br />
---------- ---------- TOTAL 185 195<br />
TOTAL 126 136<br />
IXCLO005 M193 SC64 0 0 IXCLO005 M194 0 0<br />
M195 SC65 0 0 ---------- ----------<br />
---------- ---------- TOTAL 0<br />
0<br />
TOTAL 0 0<br />
IXCLO026 M132 SC64 0 0 IXCLO026 M133 0 0<br />
---------- ---------- ---------- ----------<br />
TOTAL 0 0 TOTAL 0<br />
Figure 5-26 XCF Activity report<br />
5.7.7 MVS commands about RLS performance<br />
320 <strong>VSAM</strong> <strong>Demystified</strong><br />
There are several commands covering RLS performance aspects. The most<br />
important one is the following:<br />
D SMS,CFLS<br />
This command shows details about lock contention in RLS locks. Refer to its<br />
output in Figure 5-27.<br />
There is one line per each time interval where the data is averaged.<br />
► LockRate: The number of locks required per second (shared and exclusive)<br />
► ContRate: % of lock requests globally managed in the CF, if you are running<br />
your RLS sphere in just one system, this number is zero.<br />
► FContRate: % of lock requests falsely globally managed. It indicates the<br />
percentage of false contention in the IGWLOCK00 structure<br />
► WaitQLen: The average of the total number of waiters for any lock. We should<br />
expect this field to increase when LockRate increases passing from a larger<br />
period of observation to a small period (1 hour to 1 minute, for example). If<br />
WaitQueue increases just by itself, it indicates a performance problem.
System Interval LockRate ContRate FContRate WaitQLen<br />
MZ1A 1 Minute 1569.1 0.000 0.000 246.30<br />
MZ1A 1 Hour 1358.8 0.000 0.000 30.38<br />
MZ1A 8 Hour 887.0 0.000 0.000 7.81<br />
MZ1A 1 Day 717.3 0.000 0.000 8.47<br />
(03) 1 Minute 523.0 0.000 0.000 82.10<br />
(03) 1 Hour 452.9 0.000 0.000 10.13<br />
(03) 8 Hour 295.7 0.000 0.000 2.60<br />
(03) 1 Day 239.1 0.000 0.000 2.82<br />
***************** LEGEND ******************<br />
LockRate = number of lock requests per second<br />
CONTRATE = % of lock requests globally managed<br />
00 FCONTRATE = % of lock requests falsely globally managed<br />
WaitQLen = Average number of requests waiting for locks<br />
Figure 5-27 D SMS, CFLS command output<br />
5.7.8 SMF records covering <strong>VSAM</strong> RLS<br />
There are two SMF records covering <strong>VSAM</strong> RLS statistical performance data:<br />
SMF record type 42 and 64. Here we just describe the fields associated with<br />
<strong>VSAM</strong> RLS. Refer to “SMF record types related to <strong>VSAM</strong> data sets” on page 194<br />
for additional information. Through TDS (grandson of SLR) product you can<br />
create graphical reports relating the SMF reported information. Refer to “Tivoli<br />
Decision Support (TDS)” on page 137.<br />
SMF record 42<br />
This record can be created on a timed interval or whenever the SMF timer ends.<br />
You can specify SMF_TIME in IGDSMSxx to synchronize SMF type 42 data with<br />
SMF and RMF data intervals. SMF record type 42 has many subtypes, some of<br />
them have RLS cache structure statistics. This data includes information for each<br />
system and a sysplex-wide summary:<br />
► Subtype 15 collects data about storage class response time.<br />
► Subtype 16 collects data about data set response time.<br />
► Subtype 17 collects data about coupling facility lock structure usage.<br />
► Subtype 18 collects data about coupling facility cache partition usage.<br />
Because data is collected across the sysplex, it is unnecessary to merge SMF<br />
records from all the systems in the sysplex.<br />
Chapter 5. <strong>VSAM</strong> Record Level Sharing 321
322 <strong>VSAM</strong> <strong>Demystified</strong><br />
SMF record 64<br />
SMF writes a record type 64 when a cluster is closed or processed by EOV. SMF<br />
writes one record for each component in the cluster. SMF record type 64 has no<br />
subtypes. New sections were added to give CF cache information and some<br />
fields were modified to reflect RLS use of the cluster or component. Field<br />
SMF64RLS tells you if the <strong>VSAM</strong> cluster or component was opened for RLS.<br />
Refer to Appendix A, “Sample code” on page 363, where you will find a source<br />
code to read the SMF 64 selecting the RLS information only. The following report<br />
is produced by such code.<br />
1 <strong>VSAM</strong> RLS - CF STRUCTURE STATISTICS SINCE LAST OPEN<br />
SYSID JOBNAME START DT/TIME DDNAME DATA SET NAME<br />
SC63 MHLSC63 03071 12:03:11 <strong>VSAM</strong>RLSU MHLRES2.<strong>VSAM</strong>.RLSEXT.DATA<br />
LOCAL BP HIT: 51988 CF CACHE HIT: 20831 I/O DASD: 0<br />
INS: 32799 DEL: 0 UPDT: 32694 READ: 32781 CI-SPLT: 233 CA-SPLT: 0<br />
SC64 MHLSC64 03071 11:29:38 <strong>VSAM</strong>RLSU MHLRES2.<strong>VSAM</strong>.RLSEXT<br />
LOCAL BP HIT: 368 CF CACHE HIT: 14 I/O DASD: 0<br />
INS: 14 DEL: 0 UPDT: 0 READ: 0 CI-SPLT: 0 CA-SPLT: 0<br />
SC64 MHLSC64 03071 12:03:11 <strong>VSAM</strong>RLSU MHLRES2.<strong>VSAM</strong>.RLSEXT.DATA<br />
LOCAL BP HIT: 46933 CF CACHE HIT: 20162 I/O DASD: 0<br />
INS: 32427 DEL: 0 UPDT: 22640 READ: 22742 CI-SPLT: 230 CA-SPLT: 0<br />
SC65 MHLSC65 03071 12:03:11 <strong>VSAM</strong>RLSU MHLRES2.<strong>VSAM</strong>.RLSEXT.DATA<br />
LOCAL BP HIT: 66836 CF CACHE HIT: 20998 I/O DASD: 0<br />
INS: 33348 DEL: 0 UPDT: 33246 READ: 33384 CI-SPLT: 235 CA-SPLT: 1<br />
SC63 MHLSC63 03071 13:03:19 <strong>VSAM</strong>RLSU MHLRES2.<strong>VSAM</strong>.RLSEXT.DATA<br />
LOCAL BP HIT: 52135 CF CACHE HIT: 20529 I/O DASD: 0<br />
INS: 32436 DEL: 0 UPDT: 32341 READ: 32429 CI-SPLT: 229 CA-SPLT: 0<br />
SC63 MHLSC63 03071 13:33:15 <strong>VSAM</strong>RLSU MHLRES2.<strong>VSAM</strong>.RLSEXT.DATA<br />
LOCAL BP HIT: 52172 CF CACHE HIT: 20462 I/O DASD: 0<br />
INS: 32419 DEL: 0 UPDT: 32341 READ: 32411 CI-SPLT: 228 CA-SPLT: 0<br />
SC64 MHLSC64 03071 13:03:19 <strong>VSAM</strong>RLSU MHLRES2.<strong>VSAM</strong>.RLSEXT.DATA<br />
LOCAL BP HIT: 51012 CF CACHE HIT: 20576 I/O DASD: 0<br />
INS: 32783 DEL: 0 UPDT: 22906 READ: 23004 CI-SPLT: 233 CA-SPLT: 0<br />
SC64 MHLSC64 03071 13:33:15 <strong>VSAM</strong>RLSU MHLRES2.<strong>VSAM</strong>.RLSEXT.DATA<br />
LOCAL BP HIT: 49596 CF CACHE HIT: 20474 I/O DASD: 0<br />
INS: 32679 DEL: 0 UPDT: 22826 READ: 22922 CI-SPLT: 231 CA-SPLT: 0<br />
SC65 MHLSC65 03071 13:33:15 <strong>VSAM</strong>RLSU MHLRES2.<strong>VSAM</strong>.RLSEXT.DATA<br />
LOCAL BP HIT: 61560 CF CACHE HIT: 21085 I/O DASD: 0<br />
INS: 33270 DEL: 0 UPDT: 33199 READ: 33337 CI-SPLT: 237 CA-SPLT: 0<br />
Figure 5-28 Output from SMF64<br />
For more detailed information about SMF records, refer to z/OS MVS System<br />
Management Facilities (SMF), SA22-7630.
Chapter 6. DFSMStvs<br />
In this chapter we cover DFSMStvs. Note that there is an IBM Redbook available<br />
titled, DFSMStvs: Overview and Planning Guide, SG24-5741. We do not intend<br />
to duplicate the material covered in that publication but rather, document our<br />
hands-on experiences with TVS.<br />
The topics cover:<br />
► TVS introduction<br />
► Implementing TVS<br />
► Exploiters of TVS<br />
► Changes to system commands, JCL, parmilb member IGDSMSxx<br />
► TVS problem determination and recovery<br />
6<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 323
6.1 Introducing DFSMStvs<br />
324 <strong>VSAM</strong> <strong>Demystified</strong><br />
In this chapter we look briefly at the recent enhancements to <strong>VSAM</strong> and show<br />
how DFSMStvs is a natural extension to the functions provided by <strong>VSAM</strong> Record<br />
Level Sharing.<br />
The key functions in DFSMStvs are that <strong>VSAM</strong> will provide locking, two-phase<br />
commit, backout, and logging facilities that allow multiple batch update jobs to<br />
run concurrently with CICS access to the same data sets while maintaining<br />
integrity and recoverability.<br />
We also introduce some of the terms that are used throughout this book.<br />
6.2 Why DFSMStvs?<br />
In the past, it was often acceptable for a CICS system to be available during<br />
normal daytime business hours, perhaps for a total of twelve hours. This left<br />
plenty of time for the CICS system or application to be shut down and for<br />
supporting batch work to be run. There was no requirement to make business<br />
data available on the Internet.<br />
CICS typically is active and then shut down in preparation for running batch work<br />
for some period of time each day. As soon as CICS has stopped, backups are<br />
taken of key data sets as a point of recovery. Then, batch jobs can be scheduled<br />
to run. If we have several jobs that update the same data set, they will run<br />
sequentially, because they could not share the data set for update. After the<br />
batch updates are complete, there may be a job to read the updated data and<br />
produce reports. Probably, another backup will be done at this stage. When this<br />
is complete, CICS can be restarted and will be active again. DFSMStvs allows us<br />
to extend the CICS window of availability.<br />
6.2.1 How to extend CICS availability<br />
There is increasing pressure to extend the availability of CICS systems. This is<br />
because of the need for better customer service which in turn requires longer<br />
service hours, or because 24 hours per day Internet access to core business<br />
applications is desirable to improve competitiveness, extend the range of<br />
customers served, or reduce costs.<br />
You will probably start to use DFSMStvs so that you can meet new or changing<br />
business objectives. These objectives might include:<br />
► Extending service hours for automated teller machines<br />
► Providing kiosk access to your applications for your customers
► Linking your applications with your suppliers or customers<br />
► Web-enabling applications for direct customer use<br />
► Allowing batch reruns to be done during the online day<br />
In each case, there will be new pressures on availability of your systems. One<br />
consequence of the need for greater availability will be that you cannot afford the<br />
CICS down-time caused by your existing batch window. The actions that you will<br />
need to take will depend on whether you can still tolerate a batch window<br />
(although it will be a shorter window) or whether you must aim for continuous<br />
availability: 24 hours a day, 7 days a week.<br />
6.2.2 Reducing the batch window<br />
There are several techniques to reduce the batch window, but each has<br />
drawbacks.<br />
You can use the External CICS Interface (EXCI), which allows a non-CICS<br />
application program to call a CICS program. You would change application<br />
programs to use EXCI to pass data to a CICS server transaction, which would<br />
then perform the updates with all the facilities available to CICS. However, this<br />
needs major application changes, and requires that you provide a server<br />
transaction, but it does completely remove work from a batch window.<br />
You can remove a data set from CICS file control while CICS is still running. You<br />
use the CEMT transaction to close the data set and re-open it as read-only. You<br />
could then copy the file and make batch updates to the copy while still providing<br />
read access to the original. After the updates are completed, you deallocate the<br />
old version and allocate the new, updated version to CICS. This does not remove<br />
work from the batch window, but does offer limited (read-only) access while<br />
updates are being done.<br />
You can force <strong>VSAM</strong> to allow sharing by using SHAREOPTIONS (3) or<br />
SHAREOPTIONS(4) but all integrity and recovery issues concerning locking and<br />
logging become an application responsibility. The application changes needed to<br />
give you complete integrity and recoverability are probably too large to<br />
contemplate. For example, you would need to provide logging, locking, and<br />
commit, backout protocols such that a CICS transaction backout would not<br />
remove updates that were performed correctly by a batch job.<br />
Finally, you can change transactions to collect updates while a data set is being<br />
updated in batch and apply the changes later. A memo file is used to collect new<br />
records, and transactions are changed to switch between the main file and the<br />
memo file when the main file is not available for updates or additions.<br />
Chapter 6. DFSMStvs 325
326 <strong>VSAM</strong> <strong>Demystified</strong><br />
Inquiries must also check the memo file first. When the main file update or<br />
reorganization is complete, the contents of the memo file are copied into the<br />
main file and the switch is reset so that all accesses are now performed solely<br />
against the main file. This may have integrity problems depending on the<br />
functions that you provide. Adding new records may be safe, but updating<br />
existing records opens up the possibility of updating a record that has been<br />
updated elsewhere.<br />
These methods provide some relief at the expense of added complication or<br />
reduced integrity and recoverability. It is clear that a more general solution to the<br />
problems of running batch updates for CICS <strong>VSAM</strong> data is needed.<br />
6.3 Some definitions<br />
If you are interested in DFSMStvs as a storage administrator, you may not be<br />
familiar with some of the terms and concepts that will be used throughout this<br />
book. This section offers some brief definitions.<br />
6.3.1 Backward recovery<br />
If a transaction fails, it may leave data in an inconsistent state. Perhaps one<br />
update has been requested, but the program failed before requesting a related<br />
update.<br />
The process of removing changes which are possibly inconsistent is variously<br />
called backward recovery, rollback, or backout. It requires the use of a log that<br />
holds images of the records before they were updated. This log is called an undo<br />
log. In CICS terminology, the records are known as before images.<br />
6.3.2 Forward recovery<br />
6.3.3 Atomic updates<br />
If a data set is lost, a common way of getting the data back is to recover from a<br />
backup copy and then to apply all the changes that were made after the backup<br />
copy was taken.<br />
This process is called forward recovery. It requires a log of the changes made to<br />
a data set together with a date and time stamp. This log is called a redo or<br />
forward recovery log.<br />
By atomic updates, we mean an indivisible group of updates so that either all<br />
updates are made or none are made; it would not be possible for some updates
to be made but for others to fail and still maintain data integrity. This property is<br />
an absolute requirement for integrity. Let us illustrate the need for atomic updates<br />
by the simple example of a transfer of money between two bank accounts, as<br />
shown in Figure 6-1.<br />
Figure 6-1 An atomic update example<br />
Clearly, either both changes must be made, or neither can be made. If only the<br />
addition or credit is made, the bank has given the customer money; if only the<br />
subtraction or debit is made, the bank has taken money from the customer.<br />
Making final changes to the data is called committing. Only the application itself<br />
knows when data should be committed and it will request that the data be<br />
committed at an appropriate point in the processing flow. For example, the<br />
application described in Figure 6-1 would request a commit when the updates for<br />
both accounts had been done. It would not make sense to commit if only one<br />
update had been done, as an integrity exposure would be created.<br />
6.3.4 Unit of work and unit of recovery<br />
Before After Before After<br />
$200 $100<br />
-$100<br />
+$100<br />
$700 $800<br />
Transaction to<br />
transfer $100<br />
$200 $200<br />
+$100<br />
$700 $800<br />
Incom plete<br />
transaction<br />
A unit of work (UOW) is the term used in CICS publications for a set of updates<br />
which are treated as an atomic set of changes. The z/OS Resource Recovery<br />
Services (RRS) use unit of recovery to mean much the same thing. So, a unit of<br />
recovery is the set of updates between synchronization points. There are implicit<br />
synchronization points at the start of a transaction. There should also be explicit<br />
synchronization points requested by an application within a transaction or batch<br />
job. It is preferable to use explicit synchronization for greater control of the<br />
number of updates in a unit of recovery.<br />
Changes to data are durable after a synchronization point. That means that the<br />
changes survive any subsequent failure.<br />
Figure 6-2 shows the units of recovery (noted as A, B, and C) in a job or<br />
transaction. Notice that the points of synchronization are shown, whether<br />
Chapter 6. DFSMStvs 327
328 <strong>VSAM</strong> <strong>Demystified</strong><br />
explicitly requested by a commit or implicitly at the start and end of the<br />
transaction.<br />
Figure 6-2 Unit of recovery examples<br />
Figure 6-2 demonstrates what could happen, but this is not actually what we<br />
would recommend. For reasons described later, we recommend that there<br />
should be an explicit commit done before a data set is closed.<br />
Unfortunately, the z/OS RRS and DFSMStvs documentation draw a distinction<br />
between unit of work and unit of recovery. In this case, unit of work has its MVS<br />
definition (a task running under its own TCB) and can refer to more than one unit<br />
of recovery. In Figure 6-2, the sequence of three units of recovery between the<br />
start and end of the transaction is a unit of work.<br />
We apologize to the reader for this conflict in terms and, for consistency, will use<br />
the z/OS definition of a unit of recovery in this book.<br />
6.3.5 Two-phase commit<br />
Start of program synchronized implicit<br />
update 1<br />
update 2<br />
commit synchronized explicit<br />
update 3<br />
update 4<br />
update 5<br />
}<br />
}<br />
A<br />
B<br />
commit synchronized explicit<br />
update 6<br />
End of program } C<br />
synchronized implicit<br />
Two-phase commit is a technique that is widely used by database management<br />
systems to provide an atomic update capability. It is necessary when there are
multiple resource managers involved and we have what is known as a distributed<br />
unit of work.<br />
Two-phase commit requires that there be a coordinator who is called at<br />
synchronization points. In the first phase, the coordinator asks the individual<br />
resource managers (such as DFSMStvs) to prepare to commit the changes that<br />
they have made. The resource managers must reply to the coordinator to say<br />
that they are ready to commit. When they do so, the coordinator will, as the<br />
second phase, tell the updaters to make the changes permanent.<br />
In the case of DFSMStvs, z/OS RRS plays the coordinating role. Commit<br />
requests are generated implicitly at the successful end of a job step and should<br />
also be done explicitly by inserting commit calls in the program logic.<br />
6.3.6 In-flight and in-doubt<br />
6.3.7 Repeatable read<br />
A unit of recovery is described as being in-flight if it has made changes to a<br />
record in a recoverable data set, but has not yet committed or backed out the<br />
changes.<br />
A unit of recovery is described as being in-doubt in the brief period of time<br />
between DFSMStvs agreeing to an RRS request for a commit, and the signal<br />
from RRS that all the commit participants have agreed and that the commit<br />
should be done.<br />
With batch programs using RLS, you have a choice of two ways of handling read<br />
integrity. The default is no read integrity (NRI) where record locks are not<br />
obtained for a read. This means that you may read a record and get uncommitted<br />
data that may be backed out. This is sometimes called a dirty read. The other<br />
option is to ask for a consistent read. In this case, RLS ensures that the read<br />
request waits until updates for that record have been committed.<br />
DFSMStvs adds a third option, repeatable read (also known as consistent read<br />
explicit). This provides a way of ensuring that a record cannot be changed by<br />
someone else until the requester of repeatable read either commits or backs out,<br />
thereby releasing the lock preventing others from updating the record. It also<br />
gives your program isolation from other changes; it cannot see updates made by<br />
other programs which have not been committed and so it is a form of consistent<br />
read.<br />
The difference between a consistent read and a repeatable read is that a<br />
repeatable read keeps a lock on the record read until the unit of recovery<br />
requesting the read commits or backs out. Hence, a consistent read gives us a<br />
Chapter 6. DFSMStvs 329
330 <strong>VSAM</strong> <strong>Demystified</strong><br />
consistent view of data where all associated updates have been committed, but<br />
does not maintain that view; a repeatable read allows the requester to maintain<br />
that consistent view of the data so that future reads will get the same data until<br />
the requester itself decides to commit.<br />
6.3.8 Recoverable data sets<br />
RLS introduced the concept of recoverable and non-recoverable data sets to<br />
<strong>VSAM</strong> itself. Previously, CICS file control supported recoverable <strong>VSAM</strong> data sets<br />
but only for access from CICS transactions.<br />
A recoverable data set must be accessed by a system that can perform<br />
two-phase commit and backout of failed updates. The <strong>VSAM</strong> cluster must be<br />
defined with either the LOG(UNDO) or LOG(ALL) attributes to be recoverable.<br />
If LOG(UNDO) is specified, backout can be done but not forward recovery. This<br />
means that the image of a record before it was changed is logged so that the log<br />
entry can be used to undo a change in the event of failure.<br />
If LOG(ALL) is specified, both backout and forward recovery can be done.<br />
Forward recovery requires that the image of a record after a change be stored so<br />
that the log entry can be used to redo a change.<br />
A non-recoverable data set is defined with either the LOG(NONE) attribute or<br />
without the log attribute being specified. Neither a backout nor a forward recovery<br />
capability exists for a non-recoverable data set. As these capabilities do not exist,<br />
they cannot be compromised by batch updates, so batch updating is allowed for<br />
non-recoverable data sets.<br />
6.4 CICS support for recoverable <strong>VSAM</strong><br />
You can define <strong>VSAM</strong> data sets to CICS as recoverable resources. This definition<br />
is in the CICS file resource definition or the ICF catalog. For RLS and DFSMStvs,<br />
the definition must be in the ICF catalog.<br />
CICS can provide logging for both backward and forward recovery. Backward<br />
recovery supports transaction backout by writing a copy of a record before it was<br />
updated to a log, sometimes called an undo log. CICS performs backwards<br />
recovery itself. Forward recovery adds the ability to take a backup copy of a<br />
<strong>VSAM</strong> data set and use logged updates to reapply changes to that data set to<br />
bring it up to date. This is also referred to as a redo log. CICS does not do<br />
forward recovery; a program such as CICSVR is needed to use the redo logs to<br />
provide forward recovery.
If a transaction ends in error, CICS will back out the changes made by that<br />
transaction. CICS provides a commit mechanism used when a logical set of<br />
updates has completed. When changes are committed they cannot be backed<br />
out.<br />
You have long been able to share <strong>VSAM</strong> data between CICS systems by using<br />
function shipping between Application Owning Regions (AORs) and a File<br />
Owning Region (FOR), as shown in Figure 6-3.<br />
CICS<br />
AOR<br />
Figure 6-3 Sharing <strong>VSAM</strong> data through a CICS file owning region<br />
There are several drawbacks with this approach:<br />
► The file owning region is a single point of failure.<br />
► If the workload of the file owning region increases, it may become a<br />
performance bottleneck. You do not have the ability to use Parallel Sysplex<br />
horizontal growth to provide a growth path.<br />
► Transactions are shipped to the system with the file owning region from other<br />
systems using XCF links or VTAM. These can impose performance costs.<br />
6.5 DFSMStvs overview<br />
CICS<br />
FOR<br />
<strong>VSAM</strong><br />
CICS<br />
AOR<br />
CICS<br />
AOR<br />
CICS<br />
AOR<br />
OS/390 1 OS/390 n<br />
This section provides an overview of DFSMStvs including its relationship with<br />
RLS.<br />
Chapter 6. DFSMStvs 331
6.5.1 The RLS connection<br />
332 <strong>VSAM</strong> <strong>Demystified</strong><br />
As we saw in the previous chapter on RLS, which was introduced in<br />
DFSMS/MVS 1.3, RLS provides for a new mode of access to <strong>VSAM</strong> data. Also,<br />
we learned that RLS uses the System/390® Coupling Facility to provide the lock<br />
structures and data caching abilities to manage and ensure data integrity when<br />
<strong>VSAM</strong> data is shared. This is the reason that a Coupling Facility is required for<br />
RLS even if you want to share <strong>VSAM</strong> data in a monoplex. DFSMStvs extends the<br />
sharing of data to CICS and batch level sharing similarly maintaining data<br />
integrity for reads and updates. To accomplish this, DFSMStvs must provide the<br />
same abilities that CICS provides, such as logging for forward and backward<br />
recovery, backout, and a two-phase commit process.<br />
6.5.2 DFSMStvs locking<br />
When a <strong>VSAM</strong> application issues a GET or a PUT (or the high-level language<br />
equivalent of these <strong>VSAM</strong> macros), <strong>VSAM</strong> RLS will acquire locks on behalf of the<br />
application. A coupling facility is used to hold the locks so that they can be shared<br />
by all the SMS<strong>VSAM</strong> address spaces in a sysplex.<br />
In general, <strong>VSAM</strong> RLS will obtain share locks for read requests and exclusive<br />
locks for update or delete requests. It will wait for a certain period of time if<br />
another task holds the required locks. A share lock may be obtained for a<br />
resource if there is no lock for that resource or there are share locks held. An<br />
exclusive lock may only be obtained if no other locks are held. Note that CICS<br />
publications refer to share locks as shared locks.<br />
The DFSMStvs access mode uses <strong>VSAM</strong> RLS locking and so it is compatible<br />
with CICS locking.<br />
6.5.3 DFSMStvs logging<br />
The z/OS system logger is used to provide the logging functions that are needed<br />
to ensure data consistency after failure. The redo log name is held as an attribute<br />
of a recoverable data set while the undo log name is fixed. Forward recovery<br />
logging will be done by both CICS and DFSMStvs to the same redo log. CICS will<br />
log changes made by CICS transactions while DFSMStvs will log changes made<br />
by its callers as shown in Figure 6-4.
CICS using<br />
<strong>VSAM</strong> RLS<br />
Cluster<br />
ClusterA<br />
MVS System Logger<br />
Log<br />
stream<br />
LogA<br />
Figure 6-4 Merged forward recovery log<br />
DEFINE CLUSTER -<br />
(NAME(ClusterA) -<br />
LOG(ALL) -<br />
LOGSTREAMID(LogA)<br />
Transactional<br />
<strong>VSAM</strong><br />
The system logger is used because it can merge log entries from many z/OS<br />
images to a single log stream, where a log stream is simply a set of log entries. A<br />
single log stream across a sysplex eases management and protects data<br />
integrity.<br />
This ability to merge log entries is used for the forward recovery logs to ease<br />
recovery. The system logger writes log entries to the coupling facility, disk or<br />
both. However, note that each instance of DFSMStvs has a private undo log; the<br />
undo logs are not shared. An instance of DFSMStvs is the single version of<br />
DFSMStvs running in one z/OS image and defined by the IGDSMSxx PARMLIB<br />
member for that z/OS image.<br />
DFSMStvs uses these log streams:<br />
1. Primary, also called backout or undo log stream<br />
There is one backout log stream for each instance of DFSMStvs<br />
(SMS<strong>VSAM</strong>). It is not shared between SMS<strong>VSAM</strong>s. The name of the backout<br />
log stream is constructed from the unique name for an instance of DFSMStvs<br />
which you define in SYS1.PARMLIB(IGDSMSxx).<br />
Chapter 6. DFSMStvs 333
334 <strong>VSAM</strong> <strong>Demystified</strong><br />
It is named tvsname.IGWLOG.SYSLOG, where tvsname is of the form<br />
IGWTVnnn.<br />
2. Secondary, also called shunt log stream<br />
There is one shunt log stream for each instance of DFSMStvs. It is not shared<br />
between SMS<strong>VSAM</strong>s. The name of the shunt log stream is constructed using<br />
the unique name for an instance of DFSMStvs that you define in<br />
SYS1.PARMLIB(IGDSMSxx).<br />
It is named tvsname.IGWSHUNT.SHUNTLOG, where tvsname is of the form<br />
IGWTVnnn.<br />
The shunt log is used when backout requests fail and for long running units of<br />
recovery. In these cases log records are moved so that DFSMStvs can better<br />
manage space in the primary log.<br />
3. Forward recovery log streams<br />
Forward recovery logs are used by data sets for which LOG(ALL) is specified.<br />
When LOG(ALL) is specified you must also specify LOGSTREAMID to<br />
provide the name of the forward recovery logstream. This logstream is used<br />
by all instances of DFSMStvs and CICS to provide forward recovery<br />
capability.<br />
4. Log of logs<br />
This is an optional log stream, it is specified in SYS1.PARMLIB(IGDSMSxx). If<br />
it is defined, it contains copies of log records that are used to automate<br />
forward recovery.<br />
Although the log of logs is optional, we recommend that it be used if you want<br />
to use forward recovery at all. However, when you define a log of logs, it must<br />
be present otherwise DFSMStvs fails.<br />
Figure 6-5 shows a simple example with undo and redo logging. The vertical<br />
arrow shows the commit point at which time the undo log records are effectively<br />
forgotten. Note that the undo log records show how the records existed before<br />
the transaction, while the redo log records show how the records exist after they<br />
are updated. The log records are prefixed with header information used for<br />
recovery or backout.
<strong>VSAM</strong><br />
data set<br />
Undo log<br />
Redo log<br />
Figure 6-5 Undo and redo logging<br />
6.5.4 Recovery coordination<br />
Account 1<br />
$200<br />
Commit point<br />
{ Account 2 Account 2<br />
$700 $800<br />
h<br />
d<br />
r<br />
Account 1 h Account 2<br />
$200 $700<br />
Account 1<br />
$100<br />
Account 1<br />
$100<br />
Account 2<br />
$800<br />
In the case of DFSMStvs, the resources that are being protected are the records<br />
within recoverable <strong>VSAM</strong> data sets. There are three types of participants in<br />
resource recovery:<br />
1. Application: The application program requests the use of resources, in this<br />
case records. It is responsible for requesting that changes be committed to<br />
make them permanent or that they be backed out to remove them and<br />
thereby return the records to their previous state.<br />
2. Resource Manager: DFSMStvs uses the <strong>VSAM</strong> provided interfaces for<br />
two-phase commit and backout. These interfaces allow for:<br />
– Reading records<br />
– Updating records<br />
– Insertion of records<br />
– Erasure of records<br />
3. Syncpoint manager: RRS is the syncpoint manager. It is responsible for<br />
providing a single point of coordination for the commit processing of<br />
resources owned by different resource managers. It provides the interfaces<br />
that an application uses to:<br />
– Commit changes<br />
– Back out changes<br />
d<br />
r<br />
h<br />
d<br />
r<br />
h<br />
d<br />
r<br />
Chapter 6. DFSMStvs 335
336 <strong>VSAM</strong> <strong>Demystified</strong><br />
z/OS Recoverable Resource Services are used to coordinate commit and<br />
backout requests from applications and any other resource managers that<br />
may be needed. Apart from DFSMStvs, other resource managers using z/OS<br />
RRS are DB2 UDB, IMS and MQSeries. This means that an application can<br />
use a combination of <strong>VSAM</strong>, IMS, DB2 UDB and MQSeries services and<br />
have commit and backout performed atomically for all these resources.<br />
Transactional<br />
<strong>VSAM</strong><br />
Figure 6-6 RRS as the sync point manager<br />
z/OS<br />
RRS<br />
Commit processing<br />
MQ Series DB2 UDB<br />
Start transaction<br />
- Update <strong>VSAM</strong> record<br />
- Insert row in DB2 table<br />
- Queue message<br />
- Commit<br />
End transaction<br />
The DFSMStvs code calls RRS to register its interest in a unit of recovery. A unit<br />
of recovery represents the set of changes made by an application to a resource<br />
since the last commit (implicit or explicit) or backout. Each unit of recovery is<br />
associated with a context.<br />
DFSMStvs writes a copy of an unmodified record (the record as it existed before<br />
an update) to the undo log and, when the data set’s log attribute is set to ALL,<br />
writes a copy of the modified record (as it exists after an update) to the forward<br />
recovery log.<br />
When an application requests either a commit or a backout, z/OS RRS will call<br />
DFSMStvs to do the commit or backout on behalf of the application. The<br />
processing flow is shown here in a simplified form for a successful commit:
Application Resource Syncpoint<br />
Managers Manager<br />
Process updates 1<br />
Request commit<br />
Prepare resources<br />
Request prepare<br />
2<br />
Confirm commit<br />
Request commit<br />
3<br />
Continue<br />
4<br />
Confirm commit<br />
Figure 6-7 Commit processing participants<br />
In Step 1, the application decides that it is ready to commit changes. It requests a<br />
commit and that request is passed to the syncpoint manager. The syncpoint<br />
manager sees what resources are involved and, in Step 2, asks each resource<br />
manager that has expressed interest in this unit of recovery to prepare to commit<br />
and notify it of readiness. If all the resource managers reply that they are ready to<br />
commit, the syncpoint manager tells them to complete the process in Step 3.<br />
When that is done, the syncpoint manager can then confirm that the commit has<br />
completed to the application in Step 4.<br />
6.6 Our experiences with implementation<br />
You must have <strong>VSAM</strong> RLS already set up before you can implement TVS. For<br />
details about setting up <strong>VSAM</strong> RLS, refer to “Implementing <strong>VSAM</strong> RLS” on<br />
page 253.<br />
Once RLS is set up, you would already have defined the necessary lock and<br />
cache structures in the coupling facility. Now you need to go through the following<br />
steps to implement TVS.<br />
► Define list structures in the coupling facility<br />
► Define the log streams in the coupling facility<br />
► Define DASD staging data sets<br />
► Set up the security definitions<br />
► Define the SMS classes<br />
► Modify SYS1..PARMLIB(IGDSMSxx)<br />
Chapter 6. DFSMStvs 337
338 <strong>VSAM</strong> <strong>Demystified</strong><br />
The rest of this section describes each of these steps.<br />
6.6.1 Define list structures in the CFRM policy<br />
You have to define the list structures in the coupling facility resource<br />
management (CFRM) policy. The list structures contain the various log streams<br />
used by TVS. For details, see “Define the log structures and log streams in<br />
LOGR policy” on page 340.<br />
Figure 6-8 provides sample JCL to define the list structures. Four list structures<br />
are defined by this job.
LstStruc JOB (999,POK),'CFRM',CLASS=A,REGION=4096K,<br />
// MSGCLASS=X,TIME=10,MSGLEVEL=(1,1),NOTIFY=&SYSUID<br />
//STEP1 EXEC PGM=IXCMIAPU<br />
//SYSPRINT DD SYSOUT=*<br />
//SYSABEND DD SYSOUT=*<br />
//SYSIN DD *<br />
DATA TYPE(CFRM) REPORT(YES)<br />
DEFINE POLICY NAME(CFRM21) REPLACE(YES)<br />
CF NAME(CF01) DUMPSPACE(2048) PARTITION(E) CPCID(00)<br />
TYPE(002064) MFG(IBM) PLANT(02) SEQUENCE(000000010ECB)<br />
CF NAME(CF02) DUMPSPACE(2048) PARTITION(D) CPCID(00)<br />
TYPE(002064) MFG(IBM) PLANT(02) SEQUENCE(000000010ECB)<br />
STRUCTURE NAME(LOG_IGWLOG_001)<br />
INITSIZE(8192)<br />
SIZE(16384)<br />
PREFLIST(CF02,CF01)<br />
ALLOWAUTOALT(YES)<br />
DUPLEX(ALLOWED)<br />
STRUCTURE NAME(LOG_IGWSHUNT_001)<br />
INITSIZE(8192)<br />
SIZE(16384)<br />
PREFLIST(CF01,CF02)<br />
ALLOWAUTOALT(YES)<br />
DUPLEX(ALLOWED)<br />
STRUCTURE NAME(LOG_FORWARD_001)<br />
INITSIZE(8192)<br />
SIZE(16384)<br />
PREFLIST(CF01,CF02)<br />
ALLOWAUTOALT(YES)<br />
DUPLEX(ALLOWED)<br />
STRUCTURE NAME(LOG_IGWLGLGS_001)<br />
INITSIZE(8192)<br />
SIZE(16384)<br />
PREFLIST(CF02,CF01)<br />
ALLOWAUTOALT(YES)<br />
DUPLEX(ALLOWED)<br />
Figure 6-8 Define list structures in the CFRM policy for TVS<br />
Chapter 6. DFSMStvs 339
6.6.2 Define the log structures and log streams in LOGR policy<br />
340 <strong>VSAM</strong> <strong>Demystified</strong><br />
The definitions for log structures and log streams are done in the system LOGR<br />
policy. Their definitions refer to the list structures you defined in the previous step.<br />
A sample JCL is provided in Figure 6-9. In this job we define the log structures<br />
first. Then in these log structures, we define the log streams for SYSLOG and<br />
SHUNTLOG for three z/OS systems in our sysplex. Finally, we define the log<br />
streams for FR.LOG and LOG.OF.LOGS.
TVSLOG JOB (999,POK),'LOGR RRS',CLASS=A,REGION=4M,<br />
// MSGCLASS=T,TIME=10,MSGLEVEL=(1,1),NOTIFY=&SYSUID<br />
//STEP1 EXEC PGM=IXCMIAPU<br />
//SYSPRINT DD SYSOUT=*<br />
//SYSABEND DD SYSOUT=*<br />
//SYSIN DD *<br />
DATA TYPE(LOGR) REPORT(YES)<br />
DEFINE STRUCTURE NAME(LOG_IGWLOG_001) LOGSNUM(5)<br />
MAXBUFSIZE(64000) AVGBUFSIZE(2048)<br />
DEFINE STRUCTURE NAME(LOG_IGWSHUNT_001) LOGSNUM(5)<br />
MAXBUFSIZE(64000) AVGBUFSIZE(2048)<br />
DEFINE STRUCTURE NAME(LOG_FORWARD_001) LOGSNUM(10)<br />
MAXBUFSIZE(64000) AVGBUFSIZE(2048)<br />
DEFINE STRUCTURE NAME(LOG_IGWLGLGS_001) LOGSNUM(1)<br />
MAXBUFSIZE(64000) AVGBUFSIZE(2048)<br />
DEFINE LOGSTREAM<br />
NAME(IGWTV063.IGWLOG.SYSLOG)<br />
STRUCTNAME(LOG_IGWLOG_001)<br />
LS_DATACLAS(SHARE33)<br />
HLQ(LOGR) MODEL(NO) LS_SIZE(1180)<br />
LOWOFFLOAD(15) HIGHOFFLOAD(95)<br />
STG_DUPLEX(YES) DUPLEXMODE(COND)<br />
STG_DATACLAS(SHARE33)<br />
DIAG(YES)<br />
DEFINE LOGSTREAM<br />
NAME(IGWTV064.IGWLOG.SYSLOG)<br />
STRUCTNAME(LOG_IGWLOG_001)<br />
LS_DATACLAS(SHARE33)<br />
HLQ(LOGR) MODEL(NO) LS_SIZE(1180)<br />
LOWOFFLOAD(15) HIGHOFFLOAD(95)<br />
STG_DUPLEX(YES) DUPLEXMODE(COND)<br />
STG_DATACLAS(SHARE33)<br />
DIAG(YES)<br />
Figure 6-9 Define the log structures and log streams for TVS<br />
Chapter 6. DFSMStvs 341
342 <strong>VSAM</strong> <strong>Demystified</strong><br />
DEFINE LOGSTREAM<br />
NAME(IGWTV065.IGWLOG.SYSLOG)<br />
STRUCTNAME(LOG_IGWLOG_001)<br />
LS_DATACLAS(SHARE33)<br />
HLQ(LOGR) MODEL(NO) LS_SIZE(1180)<br />
LOWOFFLOAD(15) HIGHOFFLOAD(95)<br />
STG_DUPLEX(YES) DUPLEXMODE(COND)<br />
STG_DATACLAS(SHARE33)<br />
DIAG(YES)<br />
DEFINE LOGSTREAM<br />
NAME(IGWTV063.IGWSHUNT.SHUNTLOG)<br />
STRUCTNAME(LOG_IGWSHUNT_001)<br />
LS_DATACLAS(SHARE33)<br />
HLQ(LOGR) MODEL(NO) LS_SIZE(100)<br />
LOWOFFLOAD(15) HIGHOFFLOAD(95)<br />
STG_DUPLEX(YES) DUPLEXMODE(COND)<br />
STG_DATACLAS(SHARE33)<br />
DIAG(YES)<br />
DEFINE LOGSTREAM<br />
NAME(IGWTV064.IGWSHUNT.SHUNTLOG)<br />
STRUCTNAME(LOG_IGWSHUNT_001)<br />
LS_DATACLAS(SHARE33)<br />
HLQ(LOGR) MODEL(NO) LS_SIZE(100)<br />
LOWOFFLOAD(15) HIGHOFFLOAD(95)<br />
STG_DUPLEX(YES) DUPLEXMODE(COND)<br />
STG_DATACLAS(SHARE33)<br />
DIAG(YES)<br />
DEFINE LOGSTREAM<br />
NAME(IGWTV065.IGWSHUNT.SHUNTLOG)<br />
STRUCTNAME(LOG_IGWSHUNT_001)<br />
LS_DATACLAS(SHARE33)<br />
HLQ(LOGR) MODEL(NO) LS_SIZE(100)<br />
LOWOFFLOAD(15) HIGHOFFLOAD(95)<br />
STG_DUPLEX(YES) DUPLEXMODE(COND)<br />
STG_DATACLAS(SHARE33)<br />
DIAG(YES)<br />
Figure 6-10 Define the log structures and log streams for TVS (cont)
DEFINE LOGSTREAM<br />
NAME(IGWTVS.FR.LOG001)<br />
STRUCTNAME(LOG_FORWARD_001)<br />
LS_DATACLAS(SHARE33)<br />
HLQ(LOGR) MODEL(NO) LS_SIZE(100)<br />
LOWOFFLOAD(0) HIGHOFFLOAD(80)<br />
STG_DUPLEX(NO)<br />
DEFINE LOGSTREAM<br />
NAME(IGWTVS.LOG.OF.LOGS)<br />
STRUCTNAME(LOG_IGWLGLGS_001)<br />
LS_DATACLAS(SHARE33)<br />
HLQ(LOGR) MODEL(NO) LS_SIZE(1180)<br />
LOWOFFLOAD(0) HIGHOFFLOAD(80)<br />
STG_DUPLEX(NO)<br />
Figure 6-11 Define the log structures and log streams for TVS (cont)<br />
Note: IBM recommends that users specify DIAG(YES) for any TVS undo and<br />
shunt logs. This will cause the system logger to take a dump in the event of<br />
errors such as a lost block.<br />
Chapter 6. DFSMStvs 343
344 <strong>VSAM</strong> <strong>Demystified</strong><br />
//DEFCFRPK JOB (999,POK),'CFRM',CLASS=A,REGION=4096K,<br />
// MSGCLASS=X,TIME=10,MSGLEVEL=(1,1),NOTIFY=&SYSUID<br />
//STEP1 EXEC PGM=IXCMIAPU<br />
//SYSPRINT DD SYSOUT=*<br />
//SYSABEND DD SYSOUT=*<br />
//SYSIN DD *<br />
DATA TYPE(CFRM) REPORT(YES)<br />
DEFINE POLICY NAME(CFRM21) REPLACE(YES)<br />
CF NAME(CF01) DUMPSPACE(2048) PARTITION(E) CPCID(00)<br />
TYPE(002064) MFG(IBM) PLANT(02) SEQUENCE(000000010ECB)<br />
CF NAME(CF02) DUMPSPACE(2048) PARTITION(D) CPCID(00)<br />
TYPE(002064) MFG(IBM) PLANT(02) SEQUENCE(000000010ECB)<br />
/*-----------------------------------------------------*/<br />
/* RRS STRUCTURES FOR LOGSTREAMS */<br />
/*-----------------------------------------------------*/<br />
STRUCTURE NAME(RRS_ARCHIVE_1)<br />
INITSIZE(8000)<br />
SIZE(16000)<br />
PREFLIST(CF01,CF02)<br />
REBUILDPERCENT(5)<br />
STRUCTURE NAME(RRS_RMDATA_1)<br />
INITSIZE(8000)<br />
SIZE(16000)<br />
PREFLIST(CF01,CF02)<br />
REBUILDPERCENT(5)<br />
STRUCTURE NAME(RRS_MAINUR_1)<br />
INITSIZE(8000)<br />
SIZE(16000)<br />
PREFLIST(CF01,CF02)<br />
REBUILDPERCENT(5)<br />
STRUCTURE NAME(RRS_DELAYEDUR_1)<br />
INITSIZE(8000)<br />
SIZE(16000)<br />
PREFLIST(CF01,CF02)<br />
REBUILDPERCENT(5)<br />
STRUCTURE NAME(RRS_RESTART_1)<br />
INITSIZE(8000)<br />
SIZE(16000)<br />
PREFLIST(CF01,CF02)<br />
REBUILDPERCENT(5)<br />
Figure 6-12 Sample JCL to define Log Streams
RDEFINE LOGSTRM IGWTV001.** UACC(NONE)<br />
Granting access to the log streams:<br />
PERMIT IGWTV001.** CLASS(LOGSTRM) ACCESS(UPDATE) ID(smsvsam_userid)<br />
PERMIT IGWTV001.** CLASS(LOGSTRM) ACCESS(READ) ID(authorized_browsers)<br />
PERMIT IGWTV001.** CLASS(LOGSTRM) ACCESS(UPDATE) ID(archive_userid)<br />
RDEFINE LOGSTRM FORWARD.RECOVERY.** UACC(NONE)<br />
RDEFINE LOGSTRM FR.LOG.** UACC(NONE)<br />
RDEFINE LOGSTRM LOG.OF.LOGS UACC(NONE)<br />
PERMIT FORWARD.RECOVERY.** CLASS(LOGSTRM) ACCESS(UPDATE) ID(smsvsam_userid)<br />
PERMIT FR.LOG.** CLASS(LOGSTRM) ACCESS(UPDATE) ID(smsvsam_userid)<br />
PERMIT LOG.OF.LOGS CLASS(LOGSTRM) ACCESS(UPDATE) ID(smsvsam_userid)<br />
Permit all DFSMStvs instances access to each other's system logs<br />
Do the following for each instance:<br />
PERMIT IGWTV001.** CLASS(LOGSTRM) ACCESS(UPDATE) ID(smsvsam_userid)<br />
PERMIT IGWTV002.** CLASS(LOGSTRM) ACCESS(UPDATE) ID(smsvsam_userid)<br />
PERMIT IGWTV003.** CLASS(LOGSTRM) ACCESS(UPDATE) ID(smsvsam_userid)<br />
Etc.<br />
Figure 6-13 DFSMStvs Sample RACF Definitions<br />
6.6.3 Define SMS constructs for DFSMStvs<br />
► Explicit definition of DATACLAS and STORCLAS<br />
► May also want to specify MGMTCLAS<br />
► Log archiving<br />
► Log data back up<br />
► Log migration<br />
► Log stream and log stream staging data sets are single extent <strong>VSAM</strong> linear<br />
data sets (shareoptions '3,3')<br />
► Requires an active SMS address space<br />
► All data sets and logs must be accessible to all members of the sysplex that<br />
are required for, or may perform, peer recovery.<br />
6.7 DFSMStvs problem determination tips<br />
Here we provide some tips on how you can determine the cause of an error,<br />
condition, or problem.<br />
Chapter 6. DFSMStvs 345
6.7.1 How to take a dump of the problem?<br />
346 <strong>VSAM</strong> <strong>Demystified</strong><br />
TVS uses a function called CER_ProcessErrorAndContinue when it encounters<br />
an error which recycling the server would not resolve.<br />
► Mechanism for taking a dump without terminating the thread or the server<br />
► It manifests as an 0F4 in module IGWFCPER but it is really generated by the<br />
calling module<br />
6.7.2 Classes of errors<br />
► RRS errors (for example, when attempting to register)<br />
► System logger errors (for example, a log stream has become unavailable)<br />
► When all locks should have been released but some are left orphaned<br />
► When locks should have been marked retained but are not<br />
► When an attempt to ENDREQ an RPL fails<br />
► When an attempt to allocate or deallocate a data set fails<br />
► When end of volume fails during backout<br />
6.7.3 Determining the Failing Module<br />
► Go into IPCS and open the dump.<br />
► Go to IPCS option 6 and enter SUMMARY FORMAT.<br />
► Find the failing TCB (start by going to the bottom and finding the one with a<br />
completion code of 0F4).<br />
► Find the RTM2 work area and extract the value in register 13.<br />
► On the command line enter IP IGWVRNSA .<br />
► This displays a summary of the calling chain by running the save areas.<br />
► The failing module is the one in front of IGWFCPER.<br />
► Any module name beginning with IGW8 or IGW9 is a DFSMStvs module and<br />
the part of TVS responsible for expressing interest in units of recovery,<br />
commit and backout.<br />
► Modules beginning with IGW8 are part of recoverable file services.<br />
► Modules beginning with IGW9 are part of the DFSMStvs logger.<br />
► Reason codes in the form of 6Fxxxxxx are from recoverable file services.<br />
► Reason codes in the form of 70xxxxxx are from the DFSMStvs logger.
6.7.4 Apparent batch job hangs<br />
6.7.5 Other hangs<br />
This may be caused by many different reasons other than TVS. If you feel that a<br />
batch has become hung, it could be from several reasons including:<br />
► RLS or DFSMStvs<br />
► Catalog<br />
► The system logger<br />
► RRS<br />
► Anyone else with whom the batch job may have been communicating<br />
Start by dumping both SMS<strong>VSAM</strong> and the batch job.<br />
Using IPCS option 6 and SUMMARY FORMAT, find the hung TCB (usually the<br />
batch job's last TCB).<br />
Determine with who it was cross memory using the linkage stack and dump that<br />
as well.<br />
Here are some actions that you can take to try to analyze the cause of hang<br />
scenarios:<br />
► First check for GRS contention: D GRS,C<br />
► Next take a dump of SMS<strong>VSAM</strong>, including its data spaces<br />
► Go into IPCS and enter on the command line: IP IGWVIPCS<br />
– Select option 1: TCB analysis<br />
The bottom of the report should list the holders of latches and who wants them.<br />
Identify any waiters or holders of latches who are currently suspended.<br />
6.7.6 Quiescing a data set<br />
To quiesce a data set you need to first display the jobs that are using the data set<br />
using the following commands:<br />
DISPLAY SMS,DSNAME<br />
IDCAMS SHCDS LISTDS(dsname),JOBS<br />
Once you have identified the jobs then allow them to either complete or cancel<br />
them.<br />
To quiesce the data set use the following command:<br />
Chapter 6. DFSMStvs 347
348 <strong>VSAM</strong> <strong>Demystified</strong><br />
VARY SMS,SMS<strong>VSAM</strong>,SPHERE<br />
Perform the operations which required the data set to be quiesced.<br />
Enable the data set for RLS and DFSMStvs use:<br />
VARY SMS,SMS<strong>VSAM</strong>,SPHERE<br />
6.7.7 Close/delete/rename of data set with inflight UR<br />
Closing the data set could allow any of the following to occur:<br />
► The data set can be deleted<br />
► The data set can be renamed<br />
► A PermitNonRLSUpdate can be done<br />
► The data set can be quiesced<br />
► The locks associated with the data set can become retained<br />
Do not delete/rename data sets with an outstanding inflight UR, if backout is<br />
required, UR will be shunted.<br />
Do not delete/rename data sets with shunted log records and retained locks; it<br />
can cause loss of association between the data set and its log records and locks.<br />
A new data set could be allocated with the old name.<br />
6.7.8 New and changed system level commands for DFSMStvs<br />
Several commands have been either added or changed to support DFSMStvs.<br />
DISPLAY SMS,TRAN<strong>VSAM</strong>,ALL<br />
This command displays information about the instance of DFSMStvs on this<br />
system, or on all systems in the sysplex when the ALL keyword is specified. The<br />
output includes the following information:<br />
► The activity keypoint (AKP) trigger, which is the number of logging operations<br />
between the taking of keypoints<br />
► The status of this instance of DFSMStvs (initializing, active, quiescing,<br />
quiesced, disabling, disabled)<br />
► How DFSMStvs started:<br />
– Cold start<br />
The log data was not read, and any old data was discarded.<br />
– Warm start<br />
The log data was read and processed.
► DFSMStvs status with respect to resource recovery services (RRS)<br />
► The quiesce timeout value<br />
► All logs known to this instance of DFSMStvs, including the log of logs if one is<br />
in use<br />
► The number of active units of recovery<br />
Figure 6-14 is the output of the command from our test system.<br />
Chapter 6. DFSMStvs 349
350 <strong>VSAM</strong> <strong>Demystified</strong><br />
IEE932I 319<br />
IGW800I 16.32.01 DISPLAY SMS,TRANSACTIONAL <strong>VSAM</strong>,ALL<br />
DISPLAY SMS,TRANSACTIONAL <strong>VSAM</strong>,ALL - SERVER STATUS<br />
System TVSNAME State Rrs #Urs Start AKP QtimeOut<br />
-------- -------- ------ ----- -------- --------- -------- --------<br />
SC63 IGWTV063 ACTIVE REG 0 WARM/WARM 1000 300<br />
SC65 IGWTV065 ACTIVE REG 0 WARM/WARM 1000 300<br />
SC64 IGWTV064 ACTIVE REG 0 WARM/WARM 1000 300<br />
DISPLAY SMS,TRANSACTIONAL <strong>VSAM</strong>,ALL LOGSTREAM STATUS<br />
LogStreamName: IGWTV063.IGWLOG.SYSLOG<br />
System TVSNAME State Type Connect Status<br />
-------- -------- ------------ ---------- --------------<br />
SC63 IGWTV063 Enabled UnDoLog Connected<br />
LogStreamName: IGWTV063.IGWSHUNT.SHUNTLOG<br />
System TVSNAME State Type Connect Status<br />
-------- -------- ------------ ---------- --------------<br />
SC63 IGWTV063 Enabled ShuntLog Connected<br />
LogStreamName: IGWTVS.LOG.OF.LOGS<br />
System TVSNAME State Type Connect Status<br />
-------- -------- ------------ ---------- --------------<br />
SC63 IGWTV063 Enabled LogOfLogs Connected<br />
SC64 IGWTV064 Enabled LogOfLogs Connected<br />
SC65 IGWTV065 Enabled LogOfLogs Connected<br />
LogStreamName: IGWTV065.IGWLOG.SYSLOG<br />
System TVSNAME State Type Connect Status<br />
-------- -------- ------------ ---------- --------------<br />
SC65 IGWTV065 Enabled UnDoLog Connected<br />
LogStreamName: IGWTV065.IGWSHUNT.SHUNTLOG<br />
System TVSNAME State Type Connect Status<br />
-------- -------- ------------ ---------- --------------<br />
SC65 IGWTV065 Enabled ShuntLog Connected<br />
LogStreamName: IGWTV064.IGWLOG.SYSLOG<br />
System TVSNAME State Type Connect Status<br />
-------- -------- ------------ ---------- --------------<br />
SC64 IGWTV064 Enabled UnDoLog Connected<br />
LogStreamName: IGWTV064.IGWSHUNT.SHUNTLOG<br />
System TVSNAME State Type Connect Status<br />
-------- -------- ------------ ---------- --------------<br />
SC64 IGWTV064 Enabled ShuntLog Connected<br />
Figure 6-14 Output of D SMS, TRANS<strong>VSAM</strong>,ALL<br />
DISPLAY SMS,SHUNTED, {SPHERE(sphere)|UR({urid|ALL})}<br />
This command displays the entries currently contained in the shunt logs of the<br />
systems in the sysplex. Entries are moved to the shunt log when DFSMStvs is
unable to finish processing a syncpoint, for example, due to an I/O error. As long<br />
as a shunted entry exists, the locks associated with that entry are retained.<br />
These types of information can be displayed in response to this command. When<br />
neither the SPHERE nor URID keyword is specified, this command results in a<br />
list of systems in the sysplex and the number of units of recovery which that<br />
system has shunted:<br />
► When the SPHERE keyword is specified, this command results in a list of<br />
shunted work for the sphere specified for all of the systems in the sysplex.<br />
► When the URID keyword is specified, this command results in a list of<br />
shunted work for the unit of recovery specified for all of the systems in the<br />
sysplex. When ALL is specified, this command results in a list of shunted work<br />
for all shunted units of recovery for all the systems in the sysplex. To avoid<br />
flooding the console, DFSMStvs writes out 255 lines and then issues a WTOR<br />
to determine whether or not to continue.<br />
If the error is correctable, the installation might choose to fix the problem and<br />
then request that DFSMStvs again attempt processing of the entry by issuing the<br />
SHCDS RETRY command. If the data set cannot be restored to a point where it<br />
is consistent with the log entries, so that it does not make sense to attempt<br />
processing of the log entry again, the installation might choose to discard the log<br />
entry by issuing the SHCDS PURGE command.<br />
Figure 6-15 is the output of the command showing that there are no shunted<br />
units of work currently in the DFSMStvs shunt log.<br />
IEE932I 452<br />
IGW803I 17.19.03 DISPLAY SMS,SHUNTED (Summary Data)<br />
SysName # Urid(s) SysName # Urid(s) SysName # Urid(s)<br />
-------- -------- -------- -------- -------- --------<br />
SC63 0 SC64 0 SC65 0<br />
Figure 6-15 Output of the D SMS,SHUNTED(ALL) command<br />
DISPLAY SMS,JOB(jobname)<br />
Displays information about a particular job that is using DFSMStvs services on<br />
one of the systems in the sysplex. The output includes:<br />
► The name of the current step within the job<br />
► The current URID for the job<br />
► The status of the unit of recovery (in-reset, in-flight, in-prepare, in-commit,<br />
in-backout, indoubt)<br />
Chapter 6. DFSMStvs 351
352 <strong>VSAM</strong> <strong>Demystified</strong><br />
DISPLAY SMS,URID(urid |ALL)<br />
This command displays information about a particular unit of recovery currently<br />
active within the sysplex or about all units of recovery currently active on the<br />
system, on which the command was issued, on whose behalf DFSMStvs has<br />
performed any work. This parameter does not include information about work<br />
that has been shunted, because you can use the DISPLAY SMS,SHUNTED<br />
command to display that information. This parameter also does not include<br />
information about units of recovery that might be in restart processing as a result<br />
of an earlier failure. This work is not considered to be currently active, because it<br />
is not associated with any batch job, and the units of recovery associated with the<br />
work will end as soon as commit or backout processing for them can be<br />
completed. The output includes this information:<br />
► The age of the unit of recovery<br />
► The name of the job with which the unit of recovery is associated<br />
► The name of the current step within the job<br />
► The status of the unit of recovery (in-reset, in-flight, in-prepare, in-commit,<br />
in-backout, indoubt)<br />
► The user ID associated with the job<br />
Figure 6-16 shows the output from the command.<br />
RESPONSE=SC63<br />
IEE932I 489<br />
IGW802I DFSMS REQUEST TO DISPLAY ACTIVE TRANSACTIONAL <strong>VSAM</strong> UR(s)<br />
WAS REJECTED, SPECIFIED URID(s) ARE NOT ACTIVE<br />
ON ANY TRANSACTIONAL <strong>VSAM</strong> INSTANCE IN THE SYSPLEX.<br />
Figure 6-16 Output of D SMS,URID(ALL) cDFSMStvsommandDFSMStvs<br />
DISPLAY SMS,LOG(logstreamid|ALL)<br />
This command displays information about a log stream that DFSMStvs is<br />
currently using on one of the systems in the sysplex. If ALL is specified,<br />
information is displayed about all of the logs in use on the entire sysplex. The<br />
output includes the status of the log stream (failed or available), type of log (undo,<br />
shunt, forward recovery, or log of logs), the job name and URID of the oldest unit<br />
of recovery using the log, and a list of all DFSMStvs instances that are using the<br />
log.<br />
If information about a specific log stream is requested and the log stream is<br />
either a system log or a forward recovery log, the output includes the names of<br />
the jobs using the log stream.
This command might be issued to determine why a log stream is increasing in<br />
size. If a unit of recovery is long running, DFSMStvs would be unable to delete<br />
any log blocks that contain data associated with the unit of recovery, which in turn<br />
would make truncation of the log stream impossible.<br />
Figure 6-17 shows the output of this command using a specific logstream name,<br />
IGWTV063.IGWLOG.SYSLOG.<br />
RESPONSE=SC63<br />
IEE932I 512<br />
IGW804I 17.54.29 DISPLAY SMS,LOG<br />
DISPLAY SMS,LOG - LOG STREAM STATUS<br />
Name: IGWTV063.IGWLOG.SYSLOG State: Enabled Type: UnDo<br />
System TVSNAME JobName Urid of Oldest Log Block<br />
-------- -------- -------- --------------------------------<br />
SC63 IGWTV063 **NONE** --------- NO ACTIVE UR ---------*<br />
DISPLAY SMS,LOG - LOG STREAM USAGE<br />
LogStreamName: IGWTV063.IGWLOG.SYSLOG<br />
System TVSNAME JobName JobName JobName JobName JobName<br />
-------- -------- -------- -------- -------- -------- --------<br />
SC63 IGWTV063 **NONE**<br />
*OLDEST URID ACROSS ALL SYSTEMS IN THE SYSPLEX<br />
Figure 6-17 Output of D SMS,LOG(IGWTV063.IGWLOG.SYSLOG command<br />
DISPLAY SMS,DSNAME(dsn)<br />
For a given fully qualified data set name, this command displays the jobs<br />
currently accessing the data set using DFSMStvs on the systems within the<br />
sysplex. Figure 6-18 shows that the specified data set is not open for DFSMStvs<br />
access.<br />
IGW805I DFSMS REQUEST TO DISPLAY TRANSACTIONAL <strong>VSAM</strong> USAGE OF<br />
DATASET: IGWTV063.IGWLOG.SYSLOG WAS REJECTED.<br />
DATASET NOT KNOWN TO TRANSACTIONAL <strong>VSAM</strong>.<br />
Figure 6-18 Output of the D SMS, DSNAME(dsn) commandDFSMStvs<br />
DISPLAY SMS,OPTIONS<br />
This command displays all of the SMS parameters and their status at the time<br />
this command is issued. The display indicates whether each option is on or off,<br />
what data sets are being used, the size of regions, the time interval for recording<br />
data, and all other parameter specifics. When DFSMStvs is running on the<br />
system, the output of this command includes DFSMStvs-related information. In<br />
the output shown in Figure 6-19, we only show the DFSMStvs related information<br />
Chapter 6. DFSMStvs 353
354 <strong>VSAM</strong> <strong>Demystified</strong><br />
|<br />
IGD002I 18:31:24 DISPLAY SMS 578<br />
/* This output has been edited to remove all non DFSMStvs related data*/<br />
LOCAL_DEADLOCK = 15<br />
GLOBAL_DEADLOCK = 4<br />
REVERIFY = NO<br />
ACSDEFAULTS = NO<br />
DSNTYPE = PDS<br />
PDSESHARING = EXTENDED<br />
RLS_MAX_POOL_SIZE = 100MB<br />
RLSINIT = YES<br />
RLSTMOUT = 0<br />
COMPRESS = GENERIC<br />
LOG_OF_LOGS = IGWTVS.LOG.OF.LOGS<br />
QTIMEOUT = 300<br />
TVSNAME = 063<br />
AKP = 1000<br />
TV_START_TYPE = WARM<br />
MAXLOCKS = (0,0)<br />
CICSVR_INIT = YES<br />
CICSVR_DSNAME_PREFIX = DWWUSER.V3R1M0<br />
Rls_MaxCfFeatureLevel = Z<br />
PDSE_MONITOR = (YES,0,0)<br />
Figure 6-19 Modified Output from the D SMS,OPTIONS command<br />
6.7.9 SET SMS and SETSMS commands<br />
The SET SMS command and the SETSMS command use the same<br />
subparameters as the new DISPLAY command subparameter described above.<br />
► SET SMS<br />
This command, with the subparameters supplied, prepares the storage<br />
management subsystem environment.<br />
► SETSMS<br />
This command, with the subparameters supplied, activates the storage<br />
management subsystem environment.<br />
6.7.10 VARY SMS command<br />
The VARY SMS command, with the subparameters supplied, changes the state<br />
of the storage management subsystem environment.
Note: When using the VARY SMS for TVS, the following subparameters are<br />
valid:<br />
► LOG<br />
► SMS<strong>VSAM</strong>,SPHERE<br />
► TRAN<strong>VSAM</strong><br />
► TRAN<strong>VSAM</strong>(nnn),PEERRECOVERY<br />
► Log<br />
This enables, quiesces, or disables DFSMStvs access to a log stream.<br />
► SMS<strong>VSAM</strong>,SPHERE<br />
This quiesces or unquiesces a data set for DFSMStvs or RLS access.<br />
► TRAN<strong>VSAM</strong><br />
This enables, quiesces, or disables a DFSMStvs instance or all DFSMStvs<br />
instances in the sysplex.<br />
► TRAN<strong>VSAM</strong>(nnn),PEERRECOVERY<br />
This starts or stops peer recovery processing for a failed instance of<br />
DFSMStvs.<br />
For more detailed information on new and changed system level commands, see<br />
z/OS, V1R4 DFSMStvs Planning and Operating Guide, GC26-7485.<br />
6.7.11 SYS1.PARMLIB changes<br />
IFAPRDxx member of PARMLIB needs to be updated to reflect the addition of the<br />
priced feature DFSMStvs.<br />
Important: DFSMStvs is a priced feature of DFSMS. To be able to initialize<br />
DFSMStvs, users must update the IFAPRDxx member of PARMLIB<br />
Here is an example of the entry to IFAPRDxx that was used on our test system;<br />
PRODUCT OWNER('IBM CORP')<br />
NAME('Z/OS')<br />
ID(5694-A01)<br />
VERSION(*) RELEASE(*) MOD(*)<br />
FEATURENAME(DFSMSTVS)<br />
STATE(ENABLED)<br />
Figure 6-20 Sample IFAPRDxx parmlib member to enable DFSMStvs<br />
Chapter 6. DFSMStvs 355
356 <strong>VSAM</strong> <strong>Demystified</strong><br />
Figure 6-21 shows sample IGDSMSxx member in SYS1.PARMLIB. The<br />
parameters relevant to DFSMStvs are in bold letters. Each variable is described<br />
below.<br />
SMSACDS(acds)<br />
COMMDS(commds)<br />
INTERVAL(nnn|15)<br />
DINTERVAL(nnn|150)<br />
REVERIFY(YES|NO)<br />
ACSDEFAULTS(YES|NO)<br />
SYSTEMS(8|32)<br />
TRACE(OFF|ON)<br />
SIZE(nnnnnK|M)<br />
TYPE(ALL|ERROR)<br />
JOBNAME(jobname|*)<br />
ASID(asid|*)<br />
SELECT(event,event....)<br />
DESELECT(event,event....)<br />
DSNTYPE(LIBRARY|PDS)<br />
RLSINIT(NO|YES)<br />
RLS_MAX_POOL_SIZE(nnn|100)<br />
SMF_TIME(NO|YES)<br />
CF_TIME(nnn|3600)<br />
BMFTIME(nnn|3600)<br />
CACHETIME(nnn|3600)<br />
DEADLOCK_DETECTION(iii|15,kkk|4)<br />
RLSTMOUT(nnn|0)<br />
SYSNAME(sys1,sys2....)<br />
TVSNAME(nnn1,nnn2....)<br />
TV_START_TYPE(WARM|COLD,WARM|COLD...)<br />
AKP(nnn|1000,nnn|1000)<br />
LOG_OF_LOGS(logstream)<br />
QTIMEOUT(nnn|300)<br />
MAXLOCKS(max|0,incr|0)<br />
Figure 6-21 Sample SYS1.PARMLIB(IGDSMSxx) member<br />
► RLSINIT(NO|YES)<br />
This is used to activate the SMS<strong>VSAM</strong> address space.<br />
► RLS_MAX_POOL_SIZE(nnn|100)<br />
This specifies the maximum size, in megabytes, of the SMS<strong>VSAM</strong> local buffer<br />
pool.<br />
► SMF_TIME(NO|YES)<br />
This is used to align the interval-type SMF 42 records for DFSMS with the<br />
SMF_TIME interval.
► CF_TIME(nnn|3600)<br />
This is used to align creation of all CF related SMF 42 subtypes.<br />
► BMFTIME(nnn|3600)<br />
This specifies the number of seconds that SMS is to wait between recording<br />
SMF records for buffer management facility (BMF) cache use. You can specify<br />
a value from 1 to 86399 (23 hours, 59 minutes, 59 seconds), and the default is<br />
3600 (one hour). The SMF_TIME keyword, if set to YES, overrides the<br />
BMFTIME keyword.<br />
► CACHETIME(nnn|3600)<br />
This specifies the number of seconds between recording SMF records for<br />
device cache use. The CACHETIME parameter applies only to the volumes<br />
behind an IBM 3990 Storage Control with cache unit. You can specify a value<br />
from 1 to 86399 (23 hours, 59 minutes, 59 seconds), and the default is 3600<br />
(one hour). The SMF_TIME keyword, if set to YES, overrides the CACHETIME<br />
keyword.<br />
► DEADLOCK_DETECTION(iii|15,kkk|4)<br />
This specifies the interval for detecting deadlocks between systems.<br />
► RLSTMOUT(nnn|0)<br />
This specifies a timeout value for DFSMStvs requests for required locks.<br />
► SYSNAME(sys1,sys2....)<br />
This specifies the name or names of the systems on which DFSMStvs<br />
instances are to run.<br />
► TVSNAME(nnn1,nnn2....)<br />
This specifies the identifier or identifiers of DFSMStvs instances that are to<br />
run in the sysplex.<br />
► TV_START_TYPE(WARM|COLD,WARM|COLD...)<br />
This specifies the type of start that each instance of DFSMStvs is to perform.<br />
► AKP(nnn|1000,nnn|1000)<br />
This specifies the activity keypoint trigger value, which is the number of<br />
logging operations between taking keypoints, for one or more.<br />
► LOG_OF_LOGS(logstream)<br />
This specifies the log stream that is to be used as the log of logs.<br />
► QTIMEOUT(nnn|300)<br />
This specifies the quiesce exit timeout value.<br />
Chapter 6. DFSMStvs 357
358 <strong>VSAM</strong> <strong>Demystified</strong><br />
► MAXLOCKS(max|0,incr|0)<br />
Specifies the maximum number of unique lock requests that a single unit of<br />
recovery can make.<br />
For more detailed information about new and changed subparameters in<br />
IGDSMSxx, see z/OS DFSMStvs Planning and Operating Guide, SC26-7348.<br />
6.7.12 Changes to Job Control Language (JCL)<br />
Here is a list of the JCL changes to support DFSMStvs.<br />
► RLSTMOUT<br />
This subparameter of the EXEC statement specifies a timeout value for<br />
DFSMStvs requests for required locks.<br />
– CRE<br />
This subparameter of the RLS statement obtains a shared lock for <strong>VSAM</strong><br />
record-level sharing (RLS).<br />
For more detailed information on these changes, see z/OS DFSMStvs Planning<br />
and Operating Guide, SC26-7348.<br />
6.7.13 Changes to IDCAMS<br />
There are numerous changes and additions to IDCAMS commands. Here are<br />
some of the modifications.<br />
► ALLOCATE<br />
Here is a list of changes to the ALLOCATE command.<br />
– BWO(TYPECICS)<br />
The TYPECICS option of the BWO parameter specifies<br />
backup-while-open (BWO) in a DFSMStvs environment. For RLS<br />
processing, this parameter activates BWO processing for DFSMStvs.<br />
– DATACLASS CISIZE<br />
For DFSMStvs, specification of n*2K avoids wasting space in the coupling<br />
facility cache structure.<br />
– SHAREOPTIONS<br />
When you use DFSMStvs access, DFSMS assumes that the value of<br />
SHAREOPTIONS is (3,3).<br />
► ALTER<br />
Here is a list of changes to the ALTER command.
– BWO(TYPECICS)<br />
The TYPECICS option of the BWO parameter specifies<br />
backup-while-open (BWO) in a DFSMStvs environment. For RLS<br />
processing, this activates BWO processing for DFSMStvs.<br />
– LOG(UNDO)<br />
This specifies that changes to the sphere accessed in DFSMStvs mode<br />
can be backed out using an external log. DFSMStvs considers the sphere<br />
recoverable.<br />
– LOG(ALL)<br />
This specifies that changes to the sphere accessed in DFSMStvs mode<br />
can be backed out and is also forward recovered using external logs.<br />
DFSMStvs considers the sphere recoverable. LOGSTREAMID must also<br />
be defined.<br />
– LOGSTREAMID<br />
This changes or adds the name of the DFSMStvs forward-recovery log<br />
stream, for all components in the <strong>VSAM</strong> sphere.<br />
► DEFINE ALTERNATEINDEX<br />
The changes to this command are listed below.<br />
– BUFFERSPACE<br />
When you use DFSMStvs access, DFSMS ignores the BUFFERSPACE<br />
parameter.<br />
– CONTROLINTERVALSIZE<br />
For DFSMStvs, specification of n*2K avoids wasting space in the coupling<br />
facility cache structure.<br />
– KEYRANGES<br />
You cannot open key range data sets for RLS or DFSMStvs processing<br />
because DFSMS no longer supports this parameter (as of V1R3).<br />
– SHAREOPTIONS<br />
When you use DFSMStvs access, DFSMS assumes that the value of<br />
SHAREOPTIONS is (3,3).<br />
– WRITECHECK<br />
When you use DFSMStvs access, DFSMS ignores the WRITECHECK<br />
parameter.<br />
► DEFINE CLUSTER<br />
Changes to the DEFINE CLUSTER are described below.<br />
Chapter 6. DFSMStvs 359
360 <strong>VSAM</strong> <strong>Demystified</strong><br />
– BUFFERSPACE<br />
When you use DFSMStvs access, DFSMS ignores the BUFFERSPACE<br />
parameter.<br />
– BWO(TYPECICS)<br />
The TYPECICS option of the BWO parameter specifies<br />
backup-while-open (BWO) in a DFSMStvs environment. For RLS<br />
processing, this activates BWO processing for DFSMStvs.<br />
– CONTROLINTERVALSIZE<br />
For DFSMStvs, specification of n*2K avoids wasting space in the coupling<br />
facility cache structure.<br />
– KEYRANGES<br />
You cannot open key range data sets for RLS or DFSMStvs processing,<br />
because DFSMS no longer supports this parameter (as of V1R3).<br />
– LOG(UNDO)<br />
This specifies that changes to the sphere accessed in DFSMStvs mode<br />
can be backed out using an external log. DFSMStvs considers the sphere<br />
recoverable.<br />
– LOG(ALL)<br />
This specifies that changes to the sphere accessed in DFSMStvs mode<br />
can be backed out and it is also forward recovered using external logs.<br />
DFSMStvs considers the sphere recoverable. LOGSTREAMID must also<br />
be defined. If you use LOG(NONE), DFSMStvs considers the sphere to be<br />
nonrecoverable.<br />
– LOGSTREAMID<br />
Changes or adds the name of the DFSMStvs forward-recovery log stream,<br />
for all components in the <strong>VSAM</strong> sphere.<br />
– SHAREOPTIONS<br />
When you use DFSMStvs access, DFSMS assumes that the value of<br />
SHAREOPTIONS is (3,3).<br />
– WRITECHECK<br />
When you use RLS or DFSMStvs access, DFSMS ignores the<br />
WRITECHECK parameter.<br />
► DEFINE PATH<br />
Here are the changes to the DEFINE PATH command.<br />
– NOUPDATE<br />
This has the same meaning for DFSMStvs as it does for RLS.
► SHCDS<br />
Here are the changes to the SHCDS command.<br />
– LISTDS<br />
A new, optional JOBS keyword returns a list of the jobs that currently<br />
access the data set in DFSMStvs mode.<br />
– LISTSHUNTED<br />
This lists information about work that was shunted due to an inability to<br />
complete a syncpoint (commit or backout) for a data set, a unit of recovery,<br />
or all shunted units of recovery.<br />
– PURGE<br />
This discards log entries and releases the associated locks, for use when<br />
a data set is damaged and you cannot restore it to a state that is<br />
consistent with the log entries.<br />
– RETRY<br />
This retries the syncpoint; it is for use when you can restore a data set to a<br />
state that is consistent with the log entries.<br />
6.7.14 Messages and codes<br />
For DFSMStvs descriptions of <strong>VSAM</strong> return and reason codes, see DFSMStvs<br />
Administration Guide, GC26-7483.<br />
For descriptions of new and changed DFSMSdfp messages and return and<br />
reason codes for DFSMStvs, refer to z/OS V1R4 DFSMStvs Messages and<br />
Codes.<br />
For a listing of other new and changed DFSMSdfp messages and return and<br />
reason codes, see z/OS Summary of Message Changes.<br />
6.7.15 Macros that have been changed to support DFSMStvs<br />
Several macros have been changed to add new subparameters in support of<br />
DFSMStvs. Here is a list of the macros that have either changed or that you need<br />
to understand if your application is going to be DFSMStvs enabled:<br />
► The ACB Macro<br />
► The GENCB Macro<br />
Refer to this publication for detailed information: z/OS DFSMStvs Planning and<br />
Operating Guide, SC26-7348.<br />
Chapter 6. DFSMStvs 361
362 <strong>VSAM</strong> <strong>Demystified</strong>
Appendix A. Sample code<br />
A<br />
This appendix contains useful JCL and code samples that can be modified and<br />
used in your installation.<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 363
JRIO API examples<br />
364 <strong>VSAM</strong> <strong>Demystified</strong><br />
Here some examples of JRIO APIs for accessing <strong>VSAM</strong> data sets:<br />
Locate a record by key in keyed access record file<br />
IKeyedAccessRecordFile karf =<br />
new KeyedAccessRecordFile("//JOE.KSDS",<br />
; JRIO_READ_MODE);<br />
IRecordFile index = karf.getPrimaryIndex();<br />
karf.positionForward(index, key);<br />
karf.read(index, buffer);<br />
karf.close();<br />
Position to a record in a random access record file<br />
IRandomAccessRecordFile rarf =<br />
new RandomAccessRecordFile("//JOE.KSDS",<br />
; JRIO_READ_MODE);<br />
rarf.read(buffer); // reads the first record (record 0)<br />
rarf.positionLast();<br />
rarf.positionPrev();<br />
rarf.read(buffer); // reads the last record (record n-1)<br />
rarf.positionFirst();<br />
rarf.positionNext();<br />
rarf.read(buffer); // reads the second record (record 1)<br />
rarf.seek(5L);<br />
rarf.read(buffer); // reads the sixth record (record 5)<br />
rarf.close();<br />
Read a record from a keyed access record file<br />
IKeyedAccessRecordFile karf =<br />
new KeyedAccessRecordFile("//JOE.KSDS");<br />
IRecordFile index = karf.getPrimaryIndex();<br />
// or: IRecordFile index =<br />
// karf.getAlternateIndex("//JOE.KSDS.AIX");<br />
byte[ ] buffer = new byte[JRIO_MAX_RECORD_LENGTH];<br />
for(;;)
{<br />
// optional: karf.positionForward(key);<br />
// or: karf.positionForwardGE(key);<br />
int bytesRead = karf.read(index, buffer);<br />
if (bytesRead != JRIO_READ_EOF)<br />
{<br />
// process(buffer);<br />
}<br />
else<br />
{<br />
break;<br />
}<br />
}<br />
karf.close();<br />
Read a record from a random access record file<br />
IRandomAccessRecordFile rarf =<br />
new RandomAccessRecordFile("//JOE.SEQ");<br />
byte[ ] buffer = new byte[JRIO_MAX_RECORD_LENGTH];<br />
for(;;)<br />
{<br />
// rarf.seek(recNo);<br />
int bytesRead = rarf.read(buffer);<br />
if (bytesRead != JRIO_READ_EOF)<br />
{<br />
// process(buffer);<br />
}<br />
else<br />
{<br />
break;<br />
}<br />
}<br />
rarf.close();<br />
Update a record in a keyed access record file<br />
IKeyedAccessRecordFile karf =<br />
new KeyedAccessRecordFile("//JOE.KSDS",<br />
; JRIO_READ_WRITE_MODE);<br />
IRecordFile index = karf.getPrimaryIndex();<br />
karf.read(index, buffer);<br />
// modify non-key field(s) in buffer<br />
Appendix A. Sample code 365
366 <strong>VSAM</strong> <strong>Demystified</strong><br />
karf.update(index, buffer);<br />
karf.close();<br />
Accessing the <strong>VSAM</strong> Shared Information (VSI)<br />
You can code the following instructions to get the length and address of VSI the<br />
data to be sent to anotherOS/390 image:<br />
► Load ACB address into register RY.<br />
► To locate the VSI for a data component:<br />
L RX,04(,RY) Put AMBL address into register RX<br />
L 1,52(,RX) Get data AMB address<br />
L 1,68(,1) Get VSI address<br />
LH 0,62(,1) Load data length<br />
LA 1,62(,1) Point to data to be communicated<br />
► To locate the VSI information for an index component of a key-sequenced<br />
data set:<br />
L RX,04(,RY) Put AMBL address into register RX<br />
L 1,56(,RX) Get index AMB address<br />
L 1,68(,1) Get VSI address<br />
LH 0,62(,1) Load data length<br />
LA 1,62(,1) Point to data to be communicated<br />
Similarly, the location of the VSI on the receiving processor can be located. The<br />
VSI level number must be incremented in the receiving VSI to inform the<br />
receiving processor that the VSI has changed. To update the level number,<br />
assuming the address of the VSI is in register 1:<br />
LA 0,1 Place increment into register 0<br />
AL 0,64(,1) Add level number to increment<br />
ST 0,64(,1) Save new level number<br />
All processing of the VSI must be protected by using ENQ/DEQ to prevent<br />
simultaneous updates to the transmitted data.
Sample programs extract from SMF record type 64<br />
SMF64 sample code<br />
In this section we provide two sample programs:<br />
1. SMF64 that helps you identify <strong>VSAM</strong> data sets with heavy access and good<br />
candidates for SMB.<br />
2. SMFLSR helps you identify <strong>VSAM</strong> data sets opened in LSR mode. Once they<br />
are identified, you can use the data set names as input to IBM tool to see the<br />
probable change in CIsize with the new CI size calculation algorithm.<br />
The sample in Example A-1 can be used to find more information about jobs<br />
using heavily <strong>VSAM</strong> data sets. It is based on SMF record type 64 issued when<br />
data set component is closed.<br />
See the documentation inside the Example A-1 for:<br />
► The parms you can use to extract information<br />
► The JCL you use to extract SMF records from SYS1.MAN*<br />
► The JCL to execute the sample program<br />
► The report description fields<br />
Example: A-1 SMF64 sample code<br />
//*------------------------------------------------------------------*<br />
//* JCL: *<br />
//* //RELAT EXEC PGM=SMF64,PARM=SEE_BELOW *<br />
//* //STEPLIB DD DSN=LOAD_LIBRARY,DISP=SHR *<br />
//* //SMF DD DISP=SHR,DSN=QSAM_SMFDUMP *<br />
//* //REPORT DD SYSOUT=*,LRECL=133 *<br />
//* *<br />
//* THE PARM IS OPTIONAL: DEFAULT(EXCP=10000) *<br />
//* ==> YOU CAN USE **ONLY** 1 OF 3 LISTED BELOW *<br />
//* DSN=DATA_SET_NAME *<br />
//* LISTS INFORMATION ABOUT <strong>VSAM</strong> DATA SETS WHOSE NAME BEGINS *<br />
//* WITH "DATA_SET_NAME". *<br />
//* EX.: ’DSN=MY.DATA’ LISTS INFORMATION ABOUT ALL <strong>VSAM</strong> DATA *<br />
//* BEGINING WITH MY.DATA* *<br />
//* EX.: ’DSN=MY.DATA ’ LIST ONLY DATA SET MY.DATA *<br />
//* *<br />
//* JOB=MYJOB *<br />
//* LISTS ACCESS TO <strong>VSAM</strong> DATA SETS DONE BY ALL JOBS MYJOB* *<br />
//* EX: PARM=’JOB=MY.JOB’ LIST ALL JOBS MYJOB* *<br />
//* EX: PARM=’JOB=MYJOB ’ LIST ONLY ABOUT MYJOB *<br />
//* *<br />
//* EXCP=MAX_6_BYTES LIST ONLY FOR DATA SET WITH EXCP>=PARM_EXCP *<br />
//* *<br />
Appendix A. Sample code 367
368 <strong>VSAM</strong> <strong>Demystified</strong><br />
//* ==> YOU CAN A DATE AND/OR AN INTERVAL TO LIST *<br />
//* JD=AADDD JULIAN DATE *<br />
//* BH=HH INTERVAL BEGINING HOUR *<br />
//* EH=HH INTERVAL FINAL HOUR *<br />
//* *<br />
//* EXAMPLES: *<br />
//* PARM=’DSN=XXX,BH=07,EH=10’ *<br />
//* PARM=’DSN=XXX,JD=02360’ *<br />
//* PARM=’EXCP=NNNN’ *<br />
//* PARM=’JOB=JJJ,JD=02360,BH=07,EH=07’ (FROM 07:00 TO 07:59) *<br />
//* --------------------------------------------------------- *<br />
//* --------------------------------------------------------- *<br />
//* JCL: DUMP SMF 64 RECORD FROM SYS1.MAN *<br />
//* //STEP1 EXEC PGM=IFASMFDP<br />
//* //INDD DD DISP=SHR,DSN=SYS1.MAN?????<br />
//* //DUMPOUT DD DSN=QSAM_SMFDUMP_TYPE64,DISP=(,CATLG),<br />
//* // SPACE=(CYL,(10,10),RLSE),RECFM=VBS,UNIT=SYSDA<br />
//* //SYSPRINT DD SYSOUT=A<br />
//* //SYSIN DD *<br />
//* INDD(INDD,OPTIONS(DUMP))<br />
//* OUTDD(DUMPOUT,TYPE(64:64)) *<br />
//* *<br />
//* REPORT DESCRIPTION *<br />
//* XF=EXTENDED FORMAT DATA SET N-XF(NON EXTENDED FORMAT) *<br />
//* XP=COMPRESSED FORMAT DATA SET N-XP(NON COMPRESSED) *<br />
//* XA=EXTENDED ADDRESSABLE DATA SET N-XA(NON EXTENDED ADDRESSAB.) *<br />
//* INSERT,DELETE,READ,UPDATE,GET, EXCP, CA AND CI SPLITS ARE FROM *<br />
//* OPEN TO CLOSE (ARE NOT ACCUMULATED) *<br />
//* ACCESS BY; KEY, RBA, SEQ, DIR, SKIP *<br />
//* PROCESSING OPTIONS: *<br />
//* CNV: CONTROL INTERVAL ACCESS *<br />
//* IN: INPUT *<br />
//* OUT: OUTPUT *<br />
//* ICI: IMPROVED CONTROL INTERVAL PROCESSING *<br />
//* DW: DEFERRED WRITE *<br />
//* SIS: SEQUENTIAL INSERT STRATEGY *<br />
//* UB: USER MANAGED BUFFERING *<br />
//* CBSHR: <strong>VSAM</strong> STRUCTURE CONTROL BLOCK SHARED *<br />
//* CBFIX: <strong>VSAM</strong> CONTROL BLOCKS AND BUFFERS FIXED IN REAL STORAGE *<br />
//* BUFFERING MANAGEMENT: LSR, GSR, NSR, RLS *<br />
//* BUFF31: 31-BIT ADDRESSING MODE FOR BUFFERS *<br />
//* BUFF24: 24-BIT ADDRESSING MODE FOR BUFFERS *<br />
//* SMB: OPTIMIZATION USED:DO,DW,SO,SW,(OR CO,CR WHEN LOAD) *<br />
//* VSP: USER SPECIFIED AMOUNT OF VIRTUAL STORAGE THRU SMBVSP *<br />
//* HWT: USER SPECIFIED HIPERSPACE BUFFER SMBHWT *<br />
//* BUFF31: SMB USED 31-BIT ADDRESSING MODE FOR BUFFERS *<br />
//* CB31: SMB USED 31-BIT ADDRESSING MODE FOR CONTROL BLOCKS *<br />
//* IR: INSUFFICIENT VIRTUAL STORAGE FOR DO PROCESSING *<br />
//*------------------------------------------------------------------*
COMP EXEC ASMACL,DPRTY=9,<br />
// PARM.L=’LIST,LET,XREF,MAP,AMODE=31,RMODE=24’<br />
//C.SYSLIB DD DISP=SHR,DSN=SYS1.MACLIB<br />
//C.SYSIN DD *<br />
TITLE ’ SMF - RECORD TYPE 64 - <strong>VSAM</strong> STATS’<br />
SMF64 CSECT<br />
SMF64 AMODE 31<br />
SMF64 RMODE 24<br />
STM R14,R12,12(R13) * LINKAGE CONVENTION<br />
LR R12,R15 * R12 BASE<br />
USING SMF64,R12<br />
LA R15,SAVE<br />
ST R15,8(R13)<br />
ST R13,SAVE+4<br />
LR R13,R15<br />
L R7,LIM_EXCP * DEFAULT EXCPS<br />
LA R6,RECORD * REPORT MAPPING<br />
L R5,0(R1) * PARM<br />
LH R4,0(R5) * LENGTH<br />
LTR R4,R4 * NO PARM?<br />
BZ DO_OPEN * YES, USE DEFAULT<br />
BCTR R4,0 * -1 EXECUTE<br />
LA R5,2(,R5) *<br />
LA R14,DO_OPEN<br />
SEARCHP EX R4,TRT_PARM<br />
BNZ CALC_LEN<br />
LR R1,R4<br />
LA R4,0<br />
B ID_PARM<br />
*<br />
CALC_LEN LA R8,1(,R1)<br />
SR R1,R5<br />
SR R4,R1<br />
BCTR R1,0<br />
BAS R14,ID_PARM<br />
LTR R4,R4<br />
BZ DO_OPEN<br />
LR R5,R8<br />
BCTR R4,0<br />
B SEARCHP<br />
*<br />
ID_PARM CLC 0(4,R5),=C’DSN=’<br />
BNE PARMJOB<br />
LA R3,4<br />
SR R1,R3<br />
BZR R14<br />
LR R11,R1<br />
EX R1,MVDSN<br />
OI FLAG,X’01’ * SELECT BY DSN<br />
Appendix A. Sample code 369
370 <strong>VSAM</strong> <strong>Demystified</strong><br />
MVI TIT_OPT,X’40’<br />
MVC TIT_OPT+1(L’TIT_OPT-1),TIT_OPT<br />
MVC TIT_OPT(4),=C’DSN:’<br />
MVC TIT_OPT+4(L’RDSN),RDSN<br />
BR R14<br />
*<br />
PARMJOB CLC 0(4,R5),=C’JOB=’<br />
BNE PARMEXCP<br />
LA R3,4<br />
SR R1,R3<br />
BNPR R14<br />
LR R11,R1<br />
EX R1,MVJOBN<br />
OI FLAG,X’02’ * SELECT BY JOBN<br />
MVI TIT_OPT,X’40’<br />
MVC TIT_OPT+1(L’TIT_OPT-1),TIT_OPT<br />
MVC TIT_OPT(8),=C’JOBNAME:’<br />
MVC TIT_OPT+9(L’RJOB),RJOB<br />
BR R14<br />
*<br />
PARMEXCP CLC 0(5,R5),=C’EXCP=’<br />
BNE PARMJD<br />
LA R3,5<br />
SR R1,R3<br />
BNPR R14<br />
MVI T_EXCP,X’40’<br />
MVC T_EXCP+1(L’T_EXCP-1),T_EXCP<br />
EX R1,MVEXCP<br />
EX R1,PACK<br />
CVB R7,DOUBLE<br />
ST R7,LIM_EXCP<br />
BR R14<br />
*<br />
PARMJD CLC 0(3,R5),=C’JD=’<br />
BNE PARMBH<br />
LA R3,7<br />
CR R1,R3<br />
BNER R14 * INVALID. IGNORES<br />
PACK DATAJ,3(5,R5)<br />
OI DATAJ+3,X’0F’<br />
OI FLAG,X’04’<br />
BR R14<br />
*<br />
PARMBH CLC 0(3,R5),=C’BH=’<br />
BNE PARMEH * INVALID, IGNORES<br />
LA R3,4<br />
CR R1,R3<br />
BNER R14 * INVALID. IGNORES<br />
TM 3(R5),X’F0’
BNOR R14<br />
TM 4(R5),X’F0’<br />
BNOR R14<br />
PACK DOUBLE,3(2,R5)<br />
CVB R3,DOUBLE<br />
LTR R3,R3<br />
BZR R14<br />
M R2,F3600 * SECONDS<br />
M R2,F100 * SECONDS * 100<br />
ST R3,T_INIT<br />
OI FLAG,X’08’ * FLAG INITIAL INTERVAL<br />
BR R14<br />
*<br />
PARMEH CLC 0(3,R5),=C’EH=’<br />
BNER R14<br />
LA R3,4<br />
CR R1,R3<br />
BNER R14 * INVALID. IGNORES<br />
TM 3(R5),X’F0’<br />
BNOR R14<br />
TM 4(R5),X’F0’<br />
BNOR R14<br />
PACK DOUBLE,3(2,R5)<br />
CVB R3,DOUBLE<br />
LTR R3,R3<br />
BZR R14<br />
LA R3,1(,R3) * HOUR LIMIT FOR COMPARATION<br />
M R2,F100 *<br />
M R2,F3600 * SECONDS * 100<br />
BCTR R3,0 *<br />
ST R3,T_FIM<br />
OI FLAG,X’80’ * FINAL INTERVAL FLAG<br />
BR R14<br />
*<br />
DO_OPEN OPEN (SMFDUMP,,REC,(OUTPUT))<br />
LTR R15,R15<br />
BNZ ABEND<br />
LA R8,0 * TITLE CONTROL<br />
NUMLIN LA R9,55 * 55 LINES PER PAGE<br />
READ GET SMFDUMP<br />
LR R10,R1 * IDASMF64<br />
USING SMFRCD64,R10<br />
CLC SMF64LEN,HDUMP<br />
BNH READ<br />
CLI SMF64RTY,64 * 64?<br />
BNE READ<br />
CLI 2(R10),X’00’<br />
BNE READ<br />
TM SMF64RIN,X’80’ * COMPONENT CLOSE?<br />
Appendix A. Sample code 371
372 <strong>VSAM</strong> <strong>Demystified</strong><br />
BZ READ<br />
TM SMF64DTY,X’80’ * DATA SET?<br />
BNO READ<br />
LA R1,0<br />
ICM R1,B’0011’,SMF64ESL<br />
LA R15,0(R1,R10)<br />
TM FLAG,X’01’ * DSN?<br />
BO PR_DSN<br />
TM FLAG,X’02’ * JOB?<br />
BNO PR_EXCP<br />
*<br />
PR_JOB EQU *<br />
EX R11,CPJOB * JOBNAME MATCHES?<br />
BNE READ<br />
B COMMON<br />
*<br />
PR_DSN EQU *<br />
EX R11,CPDSN * DSN MATCHES?<br />
BNE READ<br />
B COMMON<br />
*<br />
PR_EXCP EQU *<br />
DROP R10<br />
USING SMFRCD64,R15<br />
L R3,SMF64DEP EXCP FOR DATA SET<br />
CR R3,R7 COMPARE WITH LIMIT<br />
BL READ<br />
B COMMON<br />
DROP R15<br />
*<br />
COMMON DS 0H<br />
USING SMFRCD64,R10 SMF RECORD MAPPING<br />
MVC R_SYSID,SMF64SID SYSID<br />
MVC R_JOB,SMF64JBN JOBNAME<br />
TM FLAG,X’04’ DATE?<br />
BNO MV_DATA<br />
CP SMF64DTE+1(3),DATAJ+1(3) COMPARE DATE<br />
BNE READ<br />
MV_DATA UNPK DATA,SMF64DTE<br />
TM FLAG,X’88’ INTERVAL SELECTION?<br />
BNO MV_TME IGNORES IF NOT COMPLETE INTERVAL<br />
CLC SMF64TME,T_INIT<br />
BL READ<br />
CLC SMF64TME,T_FIM<br />
BH READ<br />
MV_TME ICM R3,B’1111’,SMF64TME<br />
L R1,F100<br />
LA R2,0<br />
DR R2,R1 * SECONDS
L R1,F3600 * SECONDS IN HOURS<br />
LA R2,0<br />
DR R2,R1 * HOUR EM R3<br />
CVD R3,DOUBLE<br />
UNPK HH,DOUBLE+6(2)<br />
OI HH+1,X’F0’<br />
L R1,F60<br />
LR R3,R2 * REMAINING<br />
LA R2,0<br />
DR R2,R1 * MINUTS<br />
CVD R3,DOUBLE<br />
UNPK MM,DOUBLE+6(2)<br />
OI MM+1,X’F0’<br />
CVD R2,DOUBLE * REMAINING SECOUNDS<br />
UNPK SS,DOUBLE+6(2)<br />
OI SS+1,X’F0’<br />
LA R4,R_ACCESS<br />
TM SMF64DTY,X’20’ EXTENDED FORMAT?<br />
BNO N_XF DOES NOT USES EXT FACILITIES<br />
MVC 0(L’XF,R4),XF<br />
LA R4,L’XF+1(,R4)<br />
TM SMF64DTY,X’10’ * COMPRESSED?<br />
BNO IF_XA NO. JUMP<br />
MVC 0(2,R4),=C’XP’ SET COMPRESSED<br />
LA R4,3(,R4)<br />
IF_XA TM SMF64DTY,X’02’ EXTENDED ADDRESS DATA SET?<br />
BNO N_XA<br />
MVC 0(L’XA,R4),XA SET EXTENDED ADDRESSABILITY<br />
LA R4,L’XA+1(,R4)<br />
B IF_RLS<br />
*<br />
N_XF MVC 0(L’NXF,R4),NXF SET NON EXTENDED FORMAT<br />
LA R4,L’NXF+1(,R4)<br />
*<br />
N_XA MVC 0(L’NXA,R4),NXA SET NON EXTENDED ADDRESS DATA<br />
LA R4,L’NXA+1(,R4)<br />
IF_RLS TM SMF64DTY,X’08’ RECORD LEVEL SHARED?<br />
BNO M_EXCP<br />
MVC 0(L’RLS,R4),RLS SET RLS<br />
LA R4,L’RLS+1(,R4)<br />
*<br />
DROP R10<br />
USING SMFRCD64,R15<br />
*<br />
M_EXCP L R3,SMF64DEP EXCPS<br />
CVD R3,DOUBLE ZONED DECIMAL<br />
MVC EXCPS,MODEL<br />
ED EXCPS,DOUBLE+2<br />
MVC R_DDN,SMF64DDN * DDNAME<br />
Appendix A. Sample code 373
374 <strong>VSAM</strong> <strong>Demystified</strong><br />
MVC R_DSN,SMF64CLN * CLUSTER NAME<br />
L R3,SMF64DIN * INSERTIONS<br />
CVD R3,DOUBLE<br />
MVC INSERT,MODEL<br />
ED INSERT,DOUBLE+2<br />
L R3,SMF64DDE * RECORDS DELETED<br />
CVD R3,DOUBLE<br />
MVC DELETE,MODEL<br />
ED DELETE,DOUBLE+2<br />
L R3,SMF64DUP * RECORDS UPDATED<br />
CVD R3,DOUBLE<br />
MVC UPDATE,MODEL<br />
ED UPDATE,DOUBLE+2<br />
L R3,SMF64DRE * RECORDS RETRIEVED<br />
CVD R3,DOUBLE<br />
MVC READS,MODEL<br />
ED READS,DOUBLE+2<br />
L R3,SMF64DCS * CONTROL INTERVAL SPLITS<br />
CVD R3,DOUBLE<br />
MVC CI_SPLIT,MODEL<br />
ED CI_SPLIT,DOUBLE+2<br />
L R3,SMF64DAS * CONTROL AREA SPLITS<br />
CVD R3,DOUBLE<br />
MVC CA_SPLIT,MODEL<br />
ED CA_SPLIT,DOUBLE+2<br />
TM SMF64MC1,X’80’ * KEY ACCESS?<br />
BNO IF_RBA<br />
MVC 0(3,R4),=C’KEY’<br />
LA R4,4(R4)<br />
B TYPEACC<br />
*<br />
IF_RBA TM SMF64MC1,X’40’ * RBA?<br />
BNO IF_CI<br />
MVC 0(3,R4),=C’RBA’<br />
LA R4,4(R4)<br />
B TYPEACC<br />
*<br />
IF_CI TM SMF64MC1,X’20’ * ACCESS BY CONTROL INTERVAL?<br />
BNO TYPEACC<br />
MVC 0(3,R4),=C’CNV’<br />
LA R4,4(R4)<br />
B TYPEACC<br />
*<br />
TYPEACC TM SMF64MC1,X’10’ * SEQUENTIAL ACCESS?<br />
BNO IF_DIR<br />
MVC 0(3,R4),=C’SEQ’<br />
LA R4,4(R4)<br />
*<br />
IF_DIR TM SMF64MC1,X’08’ * DIRECT?
BNO IF_INP<br />
MVC 0(3,R4),=C’DIR’<br />
LA R4,4(R4)<br />
IF_INP TM SMF64MC1,X’04’ * INPUT?<br />
BNO IF_OUT<br />
MVC 0(2,R4),=C’IN’<br />
LA R4,3(R4)<br />
*<br />
IF_OUT TM SMF64MC1,X’02’ * OUTPUT?<br />
BNO IF_UBUF<br />
MVC 0(3,R4),=C’OUT’<br />
LA R4,4(R4)<br />
IF_UBUF TM SMF64MC1,X’01’ * USER MANAGED BUFFERING<br />
BNO MC2<br />
MVC 0(2,R4),=C’UB’<br />
LA R4,3(R4)<br />
MC2 TM SMF64MC2,X’10’ SKIP SEQUENTIAL?<br />
BNO IF_CBS<br />
MVC 0(4,R4),=C’SKIP’<br />
LA R4,5(R4)<br />
IF_CBS TM SMF64MC2,X’02’ SHARED CONTROL BLOCKS?<br />
BNO IF_LSR<br />
MVC 0(5,R4),=C’CBSHR’<br />
LA R4,6(R4)<br />
IF_LSR TM SMF64MC3,X’40’ LSR?<br />
BNO IF_GSR<br />
MVC 0(3,R4),=C’LSR’<br />
LA R4,4(R4)<br />
B IF_DW<br />
*<br />
IF_GSR TM SMF64MC3,X’20’ GSR<br />
BNO IF_ICI<br />
MVC 0(3,R4),=C’GSR’<br />
LA R4,4(R4)<br />
B IF_DW<br />
*<br />
IF_ICI TM SMF64MC3,X’10’ IMPROVED CONTROL-INTERVAL<br />
BNO NSR<br />
MVC 0(3,R4),=C’ICI’<br />
LA R4,4(R4)<br />
B IF_DW<br />
*<br />
NSR MVC 0(3,R4),=C’NSR’<br />
LA R4,4(R4)<br />
*<br />
IF_DW TM SMF64MC3,X’08’ DEFERRED-WRITE?<br />
BNO IF_SIS<br />
MVC 0(2,R4),=C’DW’<br />
LA R4,3(R4)<br />
Appendix A. Sample code 375
376 <strong>VSAM</strong> <strong>Demystified</strong><br />
IF_SIS TM SMF64MC3,X’04’ SEQUENTIAL INSERT STRATEGY?<br />
BNO IF_FIX<br />
MVC 0(3,R4),=C’SIS’<br />
LA R4,4(R4)<br />
*<br />
IF_FIX TM SMF64MC3,X’02’ CB FIXED IN REAL?<br />
BNO IF_BUFF<br />
MVC 0(5,R4),=C’CBFIX’<br />
LA R4,6(R4)<br />
*<br />
IF_BUFF MVC 0(6,R4),BUFF31<br />
TM SMF64MC3,X’01’ BUFFERS ABOVE?<br />
BO IF_SMB<br />
MVC 0(6,R4),BUFF24<br />
IF_SMB LA R4,7(,R4)<br />
TM SMF64SMB,X’80’ SMB USED?<br />
BNO PUTREC<br />
MVC 0(3,R4),=C’SMB’<br />
LA R4,4(,R4)<br />
TM SMF64SMB,X’02’ LOAD OPTIMIZED FOR SPEED?<br />
BNO IF_CR<br />
MVC 4(2,R4),=C’CO’<br />
B IF_DO<br />
IF_CR TM SMF64SMB,X’01’ LOAD OPTIMIZED FOR RECOVERY?<br />
BNO IF_CR<br />
MVC 4(2,R4),=C’CR’<br />
IF_DO LA R4,3(,R4)<br />
TM SMF64SMB,X’20’ DO BIAS USED?<br />
BNO IF_SO<br />
MVC 4(2,R4),=C’DO’<br />
B IF_VSP<br />
IF_SO TM SMF64SMB,X’10’ SO BIAS USED?<br />
BNO IF_SW<br />
MVC 4(2,R4),=C’SO’<br />
B IF_VSP<br />
IF_SW TM SMF64SMB,X’08’ SW BIAS USED?<br />
BNO IF_DFW<br />
MVC 4(2,R4),=C’SW’<br />
B IF_VSP<br />
IF_DFW TM SMF64SMB,X’04’ DW BIAS USED?<br />
BNO IF_VSP<br />
MVC 4(2,R4),=C’DW’<br />
B TM_VSP<br />
IF_VSP LA R4,3(,R4)<br />
TM_VSP TM SMF64RSC,X’80’ AMOUNT OF VIRTUAL BUFFER INFORMED<br />
BNO IF_HWT<br />
MVC 0(3,R4),VSP<br />
LA R4,4(,R4)<br />
IF_HWT TM SMF64RSC,X’40’ USED HIPERSPACE BUFFERS?
BNO IF_RE31<br />
MVC 0(3,R4),HWT<br />
LA R4,4(,R4)<br />
IF_RE31 TM SMF64RSC,X’20’ RMODE31=BUFF USED<br />
BNO IF_CB31<br />
MVC 0(7,R4),BUFF31<br />
IF_CB31 TM SMF64RSC,X’10’ RMODE31=CB USED<br />
BNO IF_878<br />
MVC 0(5,R4),CB31<br />
IF_878 TM SMF64RSC,X’10’ RMODE31=CB USED<br />
BNO PUTREC<br />
MVC 0(5,R4),IREG<br />
*<br />
PUTREC LTR R8,R8 TITLE?<br />
BNZ GR_REC<br />
PUT REC,TIT<br />
PUT REC,CAB<br />
LA R8,15<br />
GR_REC PUT REC,RECORD<br />
PUT REC,REGL2<br />
PUT REC,REGL3<br />
MVI R_ACCESS,C’ ’<br />
MVC R_ACCESS+1(L’R_ACCESS-1),R_ACCESS<br />
BCT R9,READ<br />
PUT REC,TIT<br />
PUT REC,CAB<br />
B NUMLIN<br />
DROP R15<br />
*<br />
GOBACK CLOSE (SMFDUMP,,REC)<br />
SVC 3<br />
ABEND LR R7,R15<br />
WTO ’OPEN ERROR’,ROUTCDE=11<br />
ABEND 1000,DUMP,STEP<br />
*<br />
*---------------------------------------------------------------------*<br />
* EXECUTE INSTRUCTIONS<br />
*---------------------------------------------------------------------*<br />
MVDSN MVC RDSN(0),4(R5)<br />
MVJOBN MVC RJOB(0),4(R5)<br />
MVEXCP MVC T_EXCP(0),5(R5)<br />
PACK PACK DOUBLE,5(0,R5)<br />
USING SMFRCD64,R10<br />
CPJOB CLC RJOB(0),SMF64JBN<br />
DROP R10<br />
USING SMFRCD64,R15<br />
CPDSN CLC RDSN(0),SMF64CLN<br />
DROP R15<br />
TRT_PARM TRT 0(0,R5),TBVIRG<br />
Appendix A. Sample code 377
378 <strong>VSAM</strong> <strong>Demystified</strong><br />
*---------------------------------------------------------------------*<br />
* DCBS<br />
*---------------------------------------------------------------------*<br />
SMFDUMP DCB DSORG=PS,EODAD=GOBACK,MACRF=(GL),DDNAME=SMF<br />
REC DCB DSORG=PS,MACRF=(PM),DDNAME=REPORT,LRECL=133<br />
*---------------------------------------------------------------------*<br />
* WORK AREA<br />
*---------------------------------------------------------------------*<br />
SAVE DC 18F’0’ LINKAGE CONVENTION AREA<br />
SPANNED DC F’0’<br />
DOUBLE DS D<br />
LIM_EXCP DC F’10000’<br />
HDUMP DC H’18’ SKIP DUMP AND TRAILER SMF RECORD<br />
F3600 DC F’3600’<br />
F100 DC F’100’<br />
F60 DC F’60’<br />
FLAG DC X’00’<br />
TIT DC 134C’ ’<br />
ORG TIT<br />
DC C’1’<br />
ORG TIT+10<br />
DC C’<strong>VSAM</strong> - ACCESS STATISTICS ’<br />
TITEXCP DC C’EXCP COUNT >= ’<br />
T_EXCP DC C’10000 ’<br />
ORG TIT+36<br />
TIT_OPT DS CL54<br />
ORG ,<br />
CAB DS 0CL134<br />
DC 134C’ ’<br />
ORG CAB+1<br />
DC C’JOBNAME’<br />
DS CL2<br />
DC C’DATA SET NAME’<br />
DS CL32<br />
DC C’DDNAME’<br />
DS CL3<br />
DC C’SYS’<br />
DS CL2<br />
DC C’TIMESTAMP’<br />
DS CL6<br />
DC C’MISCELLANEOUS: ACCESS, STATS SINCE LAST OPEN’<br />
ORG ,<br />
DS 0F<br />
RECORD DS 0CL134<br />
DC 134C’ ’<br />
ORG RECORD+1<br />
R_JOB DS CL8<br />
DS CL1<br />
R_DSN DS CL44
DS CL1<br />
R_DDN DS CL8<br />
DS CL1<br />
R_SYSID DS CL4<br />
DS CL1<br />
R_STAMP DS 0CL14<br />
DATA DS CL5<br />
DS CL1<br />
HH DS CL2<br />
DC C’:’<br />
MM DS CL2<br />
DC C’:’<br />
SS DS CL2<br />
ORG ,<br />
REGL2 DS 0CL134<br />
DC 134C’ ’<br />
ORG REGL2+1<br />
DC C’EXCPS:’<br />
EXCPS DS CL12<br />
DS CL1<br />
R_ACCESS DS CL114<br />
ORG ,<br />
REGL3 DS 0CL134<br />
DC 134C’ ’<br />
ORG REGL3+1<br />
DC C’INSERTS:’<br />
INSERT DS CL12<br />
DS CL1<br />
DC C’DELETES:’<br />
DELETE DS CL12<br />
DS CL1<br />
DC C’UPDATES:’<br />
UPDATE DS CL12<br />
DS CL1<br />
DC C’READ:’<br />
READS DS CL12<br />
DS CL1<br />
DC C’CI-SPLIT:’<br />
CI_SPLIT DS CL12<br />
DS CL1<br />
DC C’CA-SPLIT:’<br />
CA_SPLIT DS CL12<br />
ORG ,<br />
MODEL DC X’402020202020202020202120’<br />
RDSN DS 0CL44<br />
DC 44C’ ’<br />
RJOB DS 0CL8<br />
DC 8C’ ’<br />
NXF DC CL4’N-XF’<br />
Appendix A. Sample code 379
380 <strong>VSAM</strong> <strong>Demystified</strong><br />
ORG NXF+2<br />
XF DS CL2<br />
ORG ,<br />
NXA DC CL4’N-XA’<br />
ORG NXA+2<br />
XA DS CL2<br />
ORG ,<br />
RLS DC C’RLS’<br />
DATAJ DS XL4<br />
DS 0F<br />
T_INIT DS X’00000000’<br />
T_FIM DS X’00000000’<br />
BUFF31 DC C’BUFF31’<br />
BUFF24 DC C’BUFF24’<br />
CB31 DC C’CB31’<br />
VSP DC C’VSP’<br />
HWT DC C’HWT’<br />
IREG DC C’IR’<br />
TBVIRG DC 256X’00’<br />
ORG TBVIRG+C’,’<br />
DC X’01’<br />
ORG ,<br />
*---------------------------------------------------------------------*<br />
* DUMMIES E EQUATES<br />
*---------------------------------------------------------------------*<br />
LTORG<br />
YREGS<br />
DSECT<br />
IDASMF64<br />
END SMF64<br />
//*------------------------------------------------------------------*<br />
//L.SYSLMOD DD DISP=SHR,DSN=LOAD_LIBRARY<br />
//L.SYSLIB DD DISP=SHR,DSN=LOAD_LIBRARY<br />
//L.SYSIN DD *<br />
ENTRY SMF64<br />
NAME SMF64(R)<br />
/*<br />
SMFLSR sample program<br />
Since z/OS V1 R3, the algorithm to calculate the minimum index CI size<br />
changed. The assembler sample code in Example A-2 helps you identify the<br />
<strong>VSAM</strong> data sets opened in LSR mode. With the change in calculation, you can<br />
face problems when:<br />
► Under CICS, if you are explicitly coding the number of buffers of each size in<br />
the LSRPOOL, two things can happen:
– The amount of buffers for the new size is not enough leading to<br />
performance problems<br />
– Buffers for the new index CI size do not exist causing the open to fail. The<br />
buffer size must be the same size of the index CI size or larger.<br />
► Under other applications, when the CI index size buffer is defined in BLDVRP<br />
and is lower than the new index CI size calculation.<br />
Example: A-2<br />
//*------------------------------------------------------------------*<br />
//* JCL: *<br />
//* //RELAT EXEC PGM=SMFLSR *<br />
//* //STEPLIB DD DSN=LOAD_LIBRARY,DISP=SHR *<br />
//* //SMF DD DISP=SHR,DSN=QSAM_SMFDUMP *<br />
//* //REPORT DD SYSOUT=*,LRECL=133 *<br />
//* *<br />
//* REPORT DESCRIPTION: *<br />
//* SYSID JOBNAME DDNAME DATASET NAME CI-SIZE KEY-LENGTH *<br />
//* *<br />
//* RETURN CODES: *<br />
//* 0 - FOUND DATA SETS IN LSR MODE *<br />
//* 4 - NO FOUND *<br />
//*==================================================================*<br />
//* *<br />
//* JCL: DUMP SMF 64 RECORD FROM SYS1.MAN *<br />
//* *<br />
//* //STEP1 EXEC PGM=IFASMFDP *<br />
//* //INDD DD DISP=SHR,DSN=SYS1.MAN????? *<br />
//* //DUMPOUT DD DSN=QSAM_SMFDUMP_TYPE64,DISP=(,CATLG), *<br />
//* // SPACE=(CYL,(10,10),RLSE),RECFM=VBS,UNIT=SYSDA *<br />
//* //SYSPRINT DD SYSOUT=A *<br />
//* //SYSIN DD * *<br />
//* INDD(INDD,OPTIONS(DUMP)) *<br />
//* OUTDD(DUMPOUT,TYPE(64:64)) *<br />
//* *<br />
//*------------------------------------------------------------------*<br />
//COMP EXEC ASMACL,DPRTY=9,<br />
// PARM.L='LIST,LET,XREF,MAP,AMODE=31,RMODE=24'<br />
//C.SYSLIB DD DISP=SHR,DSN=SYS1.MACLIB<br />
//C.SYSIN DD *<br />
TITLE ' SMF - RECORD TYPE 64 - <strong>VSAM</strong> OPEN FOR LSR MODE'<br />
SMFLSR CSECT<br />
SMFLSR AMODE 31<br />
SMFLSR RMODE 24<br />
STM R14,R12,12(R13) * LINKAGE CONVENTION<br />
LR R12,R15 * R12 BASE<br />
USING SMFLSR,R12<br />
LA R15,SAVE * END SAVE DESTE PGM<br />
Appendix A. Sample code 381
382 <strong>VSAM</strong> <strong>Demystified</strong><br />
ST R15,8(R13)<br />
ST R13,SAVE+4 * SALVA END SAVE ANTERIOR<br />
LR R13,R15<br />
LA R6,4 * RC NOT FOUND<br />
DO_OPEN OPEN (SMFDUMP,,REC,(OUTPUT))<br />
LTR R15,R15<br />
BNZ ABEND<br />
SET_TIT LA R8,0 * TITLE CONTROL<br />
LA R9,66 * 66 LINES PER PAGE<br />
READ GET SMFDUMP<br />
LR R10,R1 * IDASMF64<br />
USING SMFRCD64,R10<br />
CLC SMF64LEN,HDUMP<br />
BNH READ<br />
CLI SMF64RTY,64 * 64?<br />
BNE READ<br />
CLI 2(R10),X'00' * DISCARD SPANNED RECORDS<br />
BNE READ<br />
TM SMF64RIN,X'E0' * CLOSE,VOL SWITCH,OUT OF SPACE<br />
BZ READ * NO. DISCARD<br />
TM SMF64DTY,X'40' * INDEX?<br />
BNO READ * NO.DISCARD<br />
LA R1,0<br />
ICM R1,B'0011',SMF64ESL<br />
LA R15,0(R1,R10)<br />
DROP R10<br />
USING SMFRCD64,R15<br />
TM SMF64MC3,X'40' LSR?<br />
BNO READ NO, DISCARD<br />
TM SMF64SMB,X'80' SMB USED?<br />
BO READ YES. DISCARD. SMB BUILDS BUFFER POOL<br />
DROP R15 ACCORDING TO CISIZE<br />
*<br />
USING SMFRCD64,R10 SMF RECORD MAPPING<br />
MVC R_SYSID,SMF64SID SYSID<br />
MVC R_JOB,SMF64JBN JOBNAME<br />
*<br />
DROP R10<br />
USING SMFRCD64,R15<br />
*<br />
MVC R_DDN,SMF64DDN * DDNAME<br />
MVC R_DSN,SMF64CLN * CLUSTER NAME<br />
L R3,SMF64DCI * CI-SIZE<br />
CVD R3,DOUBLE<br />
MVC R_CI,MODEL<br />
ED R_CI,DOUBLE+4<br />
LA R3,0<br />
ICM R3,B'0011',SMF64DKL * KEY-SIZE<br />
CVD R3,DOUBLE
MVC R_KEY,MODEL+4<br />
LTR R8,R8 TITLE?<br />
BNZ GR_REC<br />
PUT REC,TIT<br />
PUT REC,CAB<br />
LA R8,15<br />
GR_REC PUT REC,RECORD<br />
LA R6,0<br />
BCT R9,READ<br />
B SET_TIT<br />
DROP R15<br />
*<br />
GOBACK CLOSE (SMFDUMP,,REC)<br />
LR R15,R6 RETURN CODE<br />
L R13,SAVE+4 LINKAGE CONVENTION<br />
L R14,12(R13)<br />
LM R0,R12,20(R13)<br />
BR R14<br />
*<br />
ABEND LR R7,R15<br />
WTO 'OPEN ERROR',ROUTCDE=11<br />
ABEND 1000,DUMP,STEP<br />
*<br />
*---------------------------------------------------------------------*<br />
* DCBS<br />
*---------------------------------------------------------------------*<br />
SMFDUMP DCB DSORG=PS,EODAD=GOBACK,MACRF=(GL),DDNAME=SMF<br />
REC DCB DSORG=PS,MACRF=(PM),DDNAME=REPORT,LRECL=133<br />
*---------------------------------------------------------------------*<br />
* WORK AREA<br />
*---------------------------------------------------------------------*<br />
SAVE DC 18F'0' LINKAGE CONVENTION AREA<br />
SPANNED DC F'0'<br />
DOUBLE DS D<br />
HDUMP DC H'18' SKIP DUMP AND TRAILER SMF RECORD<br />
TIT DC 134C' '<br />
ORG TIT<br />
DC C'1'<br />
ORG TIT+10<br />
DC C'<strong>VSAM</strong> - DATA SET WITH LSR ACCESS'<br />
ORG ,<br />
CAB DS 0CL134<br />
DC 134C' '<br />
ORG CAB+1<br />
DC C'SYSTEM '<br />
DS CL2<br />
DC C'JOBNAME'<br />
DS CL3<br />
DC C'DDNAME'<br />
Appendix A. Sample code 383
384 <strong>VSAM</strong> <strong>Demystified</strong><br />
DS CL4<br />
DC C'DATA SET NAME'<br />
DS CL32<br />
DC C'KEY SIZE'<br />
DS CL2<br />
DC C'INDEX CI SIZE'<br />
ORG ,<br />
DS 0F<br />
RECORD DS 0CL134<br />
DC 134C' '<br />
ORG RECORD+1<br />
R_SYSID DS CL4<br />
DS CL5<br />
R_JOB DS CL8<br />
DS CL2<br />
R_DDN DS CL8<br />
DS CL2<br />
R_DSN DS CL44<br />
DS CL1<br />
R_KEY DS CL6<br />
DS CL4<br />
R_CI DS CL6<br />
ORG ,<br />
MODEL DC X'402020202120'<br />
*---------------------------------------------------------------------*<br />
* DUMMIES E EQUATES<br />
*---------------------------------------------------------------------*<br />
LTORG<br />
YREGS<br />
DSECT<br />
IDASMF64<br />
END SMFLSR<br />
//*------------------------------------------------------------------*<br />
//L.SYSLMOD DD DISP=SHR,DSN=LOAD_DATA_SET<br />
//L.SYSLIB DD DISP=SHR,DSN=LOAD_DATA_SET<br />
//L.SYSIN DD *<br />
ENTRY SMFLSR<br />
NAME SMFLSR(R)<br />
/*<br />
REXX code to list compression ratio<br />
Compression is useful when the compression rate is high, to compensate for the<br />
CPU used to perform the compress. The compression rate depends on the data.
You can use the REXX in Example A-4 to list the compress ratio for:<br />
► All data sets (<strong>VSAM</strong> KSDS or non-<strong>VSAM</strong>) from a catalog.<br />
► An specific data set<br />
You can execute the REXX via:<br />
► TSO. or<br />
► Batch, using the JCL shown in Example A-3<br />
Example: A-3 Sample JCL for running REXX in batch<br />
//REXX EXEC PGM=IRXJCL,<br />
// PARM='REXX_NAME +UCAT.VSBOX01'<br />
//SYSTSPRT DD SYSOUT=*<br />
//SYSEXEC DD DISP=SHR,DSN=PDS_REXX<br />
//SYSTSIN DD DUMMY<br />
Example: A-4<br />
/* REXX */<br />
/*TRACE R */<br />
/********************************************************************/<br />
/* FUNCTION: */<br />
/* DISPLAY THE COMPRESSION RATIO FOR: */<br />
/* 1 - DATA SET: EXEC REXX_NAME 'DATA_SET_NAME' */<br />
/* OR, WHEN THE PARM IS PREFIXED BY "+": */<br />
/* 2 - FOR ALL COMPRESSED DATA SETS FROM A CATALOG: */<br />
/* EXEC REXX_NAME '+CATALOG_NAME' */<br />
/********************************************************************/<br />
PARSE UPPER ARG DSN<br />
IF DSN = '' THEN<br />
DO<br />
SAY "NO DSN OR CATALOG INFORMED. "<br />
EXIT<br />
END<br />
PARSE VAR DSN '+' CAT<br />
IF CAT /= '' THEN DSN = '**'<br />
ELSE CAT = ' '<br />
MODRSNRC = SUBSTR(' ',1,4)<br />
CSIFILTK = SUBSTR(DSN,1,44)<br />
CSICATNM = SUBSTR(CAT,1,44)<br />
CSIRESNM = SUBSTR(' ',1,44)<br />
CSIDTYPS = SUBSTR(' ',1,16)<br />
/* OPTIONS */<br />
CSICLDI = SUBSTR(' ',1,1)<br />
CSIRESUM = SUBSTR(' ',1,1) /* RESUME FLAG */<br />
CSIS1CAT = SUBSTR('Y',1,1) /* SEARCH MORE THAN 1 CATALOG */<br />
CSIRESRV = SUBSTR(' ',1,1)<br />
Appendix A. Sample code 385
386 <strong>VSAM</strong> <strong>Demystified</strong><br />
CSINUMEN = '0003'X<br />
CSIFLD1 = SUBSTR('COMPIND COMUDSIZUDATASIZ',1,24)<br />
CSIOPTS = CSICLDI || CSIRESUM || CSIS1CAT || CSIRESRV<br />
CSIFIELD = CSIFILTK || CSICATNM || CSIRESNM || CSIDTYPS || CSIOPTS<br />
CSIFIELD = CSIFIELD || CSINUMEN || CSIFLD1<br />
WORKLEN = 1024<br />
DWORK = '00000400'X || COPIES('00'X,WORKLEN-4)<br />
FOUND = 0<br />
NUMERIC DIGITS 16<br />
RESUME = 'Y'<br />
DO WHILE RESUME = 'Y'<br />
ADDRESS LINKPGM 'IGGCSI00 MODRSNRC CSIFIELD DWORK'<br />
LCC = RC<br />
IF LCC ¬= 0 THEN<br />
DO<br />
REASON = C2X(MODRSNRC)<br />
SAY 'IGGCSI00 NOT OK RC:' LCC 'REASON:' REASON<br />
EXIT<br />
END<br />
RESUME = SUBSTR(CSIFIELD,150,1) /* RESUME FLAG LOOP CTL */<br />
USEDLEN = C2D(SUBSTR(DWORK,9,4)) /* USED WORK AREA LENGTH */<br />
POS1=15 /* AREA INFO ENTRY */<br />
/****************************************************************/<br />
/* PROCESS WORK AREA DATA */<br />
/****************************************************************/<br />
DO WHILE POS1 < USEDLEN /* PROCESS WORK AREA */<br />
IF SUBSTR(DWORK,POS1+1,1) = '0' THEN POS1 = POS1 + 50<br />
ELSE<br />
DO<br />
CSIEFLAG = SUBSTR(DWORK,POS1,1)<br />
X = BITAND(CSIEFLAG,'20'X) /* VALID? */<br />
IF X /= '20'X THEN POS1 = POS1 + 50<br />
ELSE<br />
DO<br />
X = BITAND(SUBSTR(DWORK,POS1+56,1),'60'X)<br />
TOTDATA = C2D(SUBSTR(DWORK,POS1+46,2))<br />
IF X = '60'X THEN<br />
DO<br />
X = BITAND(SUBSTR(DWORK,POS1+57,1),'FF'X)<br />
IF X /= 'FF'X THEN<br />
DO<br />
FOUND = 1<br />
DSN = SPACE(SUBSTR(DWORK,POS1+2,44),0)<br />
STLEN = C2D(SUBSTR(DWORK,POS1+50,2))<br />
NDLEN = C2D(SUBSTR(DWORK,POS1+52,2))
RDLEN = C2D(SUBSTR(DWORK,POS1+54,2))<br />
USIZE = C2D(SUBSTR(DWORK,POS1+65,RDLEN))<br />
XPRESS = C2D(SUBSTR(DWORK,POS1+57,NDLEN))<br />
RATIO = SPACE(FORMAT((1-(XPRESS/USIZE))*100,16,2),0)<br />
SAY "COMPRESSION RATIO OF " DSN ": " RATIO "%"<br />
END<br />
END<br />
POS1 = POS1 + TOTDATA + 46<br />
END<br />
END<br />
END<br />
ENDIF FOUND = 0 THEN SAY "NO COMPRESSED DATA SETS FOUND "<br />
SMFRLS Sample program<br />
(*)<br />
Example: A-5<br />
//*------------------------------------------------------------------*<br />
//* FUNCTION: *<br />
//* RLS CF STRUCTURE AND I/O STATISTICS *<br />
//* *<br />
//*------------------------------------------------------------------*<br />
//* REPORT DESCRIPTION *<br />
//* # OF REQUESTS WHERE DATA WAS OBTAINED FROM THE LOCAL *<br />
//* SHARED BUFFER POOL *<br />
//* # OF REQUESTS WHERE DATA WAS OBTAINED FROM DE CF CACHE *<br />
//* # OF REQUESTS WHERE DATA WAS OBTAINED FROM DASD *<br />
//* # OF UPDATES, INSERTS, DELETES, READS, SPLITS CI AND CA *<br />
//* SYSTEM ID, JOBNAME, DATE AND TIME WHEN JOB STARTED, DDNAME AND *<br />
//* DATA SET NAME *<br />
//*------------------------------------------------------------------*<br />
//* JCL: *<br />
//* //RELAT EXEC PGM=SMFRLS *<br />
//* //STEPLIB DD DSN=LOAD_LIBRARY,DISP=SHR *<br />
//* //SMF DD DISP=SHR,DSN=QSAM_SMFDUMP *<br />
//* //REPORT DD SYSOUT=*,LRECL=133 *<br />
//* *<br />
//* PARM: NO PARM USED *<br />
//* --------------------------------------------------------- *<br />
//* JCL DUMP SMF 64 RECORD FROM SYS1.MAN *<br />
//* //STEP1 EXEC PGM=IFASMFDP<br />
//* //INDD DD DISP=SHR,DSN=SYS1.MAN?????<br />
//* //DUMPOUT DD DSN=QSAM_SMFDUMP_TYPE64,DISP=(,CATLG),<br />
//* // SPACE=(CYL,(10,10),RLSE),RECFM=VBS,UNIT=SYSDA<br />
//* //SYSPRINT DD SYSOUT=A<br />
//* //SYSIN DD *<br />
Appendix A. Sample code 387
388 <strong>VSAM</strong> <strong>Demystified</strong><br />
//* INDD(INDD,OPTIONS(DUMP))<br />
//* OUTDD(DUMPOUT,TYPE(64:64)) *<br />
//*------------------------------------------------------------------*<br />
//COMP EXEC ASMACL,DPRTY=9,<br />
// PARM.L='LIST,LET,XREF,MAP,AMODE=31,RMODE=24'<br />
//C.SYSLIB DD DISP=SHR,DSN=SYS1.MACLIB<br />
//C.SYSIN DD *<br />
TITLE ' SMF - RECORD TYPE 64 - RLS HITS STATS'<br />
SMFRLS CSECT<br />
SMFRLS AMODE 31<br />
SMFRLS RMODE 24<br />
STM R14,R12,12(R13) * LINKAGE CONVENTION<br />
LR R12,R15 * 12 BASE REGISTER<br />
USING SMFRLS,R12<br />
LA R15,SAVE<br />
ST R15,8(R13)<br />
ST R13,SAVE+4<br />
LR R13,R15<br />
*<br />
DO_OPEN OPEN (SMFDUMP,,REC,(OUTPUT))<br />
LTR R15,R15<br />
BNZ ABEND<br />
SET_TIT LA R8,0 * TITLE CONTROL<br />
LA R9,14 * 60 LINES PER PAGE<br />
READ GET SMFDUMP<br />
LR R10,R1 * IDASMF64<br />
USING SMFRCD64,R10<br />
CLC SMF64LEN,HDUMP<br />
BNH READ<br />
CLI SMF64RTY,64 * 64?<br />
BNE READ<br />
CLI 2(R10),X'00'<br />
BNE READ<br />
TM SMF64RIN,X'80' * COMPONENT CLOSE?<br />
BZ READ<br />
TM SMF64DTY,X'80' * DATA SET?<br />
BNO READ<br />
TM SMF64DTY,X'08' RECORD LEVEL SHARED?<br />
BNO READ<br />
USING SMFRCD64,R10 SMF RECORD MAPPING<br />
MVC R_SYSID,SMF64SID SYSID<br />
MVC R_JOB,SMF64JBN JOBNAME<br />
MVC R_DSN,SMF64DNM * COMPONENT NAME<br />
MV_DATA UNPK DATE,SMF64RSD JOB START DATE (JULIAN)<br />
MV_TME ICM R3,B'1111',SMF64RST TIME HUNDREDTHS OF SECONDS<br />
L R1,F100 SINCE MIDNIGHT<br />
LA R2,0<br />
DR R2,R1 * SECONDS<br />
L R1,F3600 * SECONDS IN HOURS
*<br />
LA R2,0<br />
DR R2,R1 * HOUR EM R3<br />
CVD R3,DOUBLE<br />
UNPK HH,DOUBLE+6(2)<br />
OI HH+1,X'F0'<br />
L R1,F60<br />
LR R3,R2 * REMAINING<br />
LA R2,0<br />
DR R2,R1 * MINUTS<br />
CVD R3,DOUBLE<br />
UNPK MM,DOUBLE+6(2)<br />
OI MM+1,X'F0'<br />
CVD R2,DOUBLE * REMAINING SECOUNDS<br />
UNPK SS,DOUBLE+6(2)<br />
OI SS+1,X'F0'<br />
LA R1,0<br />
ICM R1,B'0011',SMF64ESL<br />
LA R15,0(R1,R10)<br />
DROP R10<br />
USING SMFRCD64,R15<br />
MVC R_DDN,SMF64DDN * DDNAME<br />
L R3,SMF64DIN * INSERTIONS<br />
CVD R3,DOUBLE<br />
MVC INSERT,MODEL<br />
ED INSERT,DOUBLE+2<br />
L R3,SMF64DDE * RECORDS DELETED<br />
CVD R3,DOUBLE<br />
MVC DELETE,MODEL<br />
ED DELETE,DOUBLE+2<br />
L R3,SMF64DUP * RECORDS UPDATED<br />
CVD R3,DOUBLE<br />
MVC UPDATE,MODEL<br />
ED UPDATE,DOUBLE+2<br />
L R3,SMF64DRE * RECORDS RETRIEVED<br />
CVD R3,DOUBLE<br />
MVC READS,MODEL<br />
ED READS,DOUBLE+2<br />
L R3,SMF64DCS * CONTROL INTERVAL SPLITS<br />
CVD R3,DOUBLE<br />
MVC CI_SPLIT,MODEL2<br />
ED CI_SPLIT,DOUBLE+4<br />
L R3,SMF64DAS * CONTROL AREA SPLITS<br />
CVD R3,DOUBLE<br />
MVC CA_SPLIT,MODEL2<br />
ED CA_SPLIT,DOUBLE+4<br />
L R3,SMF64BMH * HIT LOCAL SHARED BUFFER POOL<br />
CVD R3,DOUBLE<br />
MVC HITLBP,MODEL<br />
Appendix A. Sample code 389
390 <strong>VSAM</strong> <strong>Demystified</strong><br />
ED HITLBP,DOUBLE+2<br />
L R3,SMF64CFH * HIT CF CACHE STRUCTURE<br />
CVD R3,DOUBLE<br />
MVC HITCF,MODEL<br />
ED HITCF,DOUBLE+2<br />
L R3,SMF64RIO * DATA RECORDS FROM DASD<br />
CVD R3,DOUBLE<br />
MVC DASD,MODEL<br />
ED DASD,DOUBLE+2<br />
*<br />
PUTREC LTR R8,R8 TITLE?<br />
BNZ GR_REC<br />
LA R8,1<br />
PUT REC,TIT<br />
PUT REC,REC_SPC<br />
PUT REC,HEADER<br />
PUT REC,REC_SPC<br />
LA R15,0<br />
ST R15,RC<br />
GR_REC PUT REC,REC_JOB<br />
PUT REC,REC_RLS<br />
PUT REC,REC_IO<br />
PUT REC,REC_SPC<br />
BCT R9,READ<br />
B SET_TIT<br />
DROP R15<br />
*<br />
GOBACK CLOSE (SMFDUMP,,REC)<br />
L R13,SAVE+4<br />
L R14,12(R13)<br />
L R15,RC<br />
LM R0,R12,20(R13)<br />
BR R14<br />
*<br />
ABEND LR R7,R15<br />
WTO 'OPEN ERROR',ROUTCDE=11<br />
ABEND 1000,DUMP,STEP<br />
*<br />
*---------------------------------------------------------------------*<br />
* EXECUTE INSTRUCTIONS<br />
*---------------------------------------------------------------------*<br />
PACK PACK DOUBLE,5(0,R5)<br />
*---------------------------------------------------------------------*<br />
* DCBS<br />
*---------------------------------------------------------------------*<br />
SMFDUMP DCB DSORG=PS,EODAD=GOBACK,MACRF=(GL),DDNAME=SMF<br />
REC DCB DSORG=PS,MACRF=(PM),DDNAME=REPORT,LRECL=133<br />
*---------------------------------------------------------------------*<br />
* WORK AREA
*---------------------------------------------------------------------*<br />
SAVE DC 18F'0' LINKAGE CONVENTION AREA<br />
SPANNED DC F'0'<br />
DOUBLE DS D<br />
HDUMP DC H'18' SKIP DUMP AND TRAILER SMF RECORD<br />
F3600 DC F'3600'<br />
F100 DC F'100'<br />
F60 DC F'60'<br />
RC DC F'4'<br />
TIT DC 134C' '<br />
ORG TIT<br />
DC C'1'<br />
ORG TIT+10<br />
DC C'<strong>VSAM</strong> RLS - CF STRUCTURE STATISTICS '<br />
DC C'SINCE LAST OPEN'<br />
ORG ,<br />
HEADER DC 134C' '<br />
ORG HEADER+1<br />
DC C'SYSID'<br />
DS CL1<br />
DC C'JOBNAME'<br />
DS CL2<br />
DC C'START DT/TIME'<br />
DS CL2<br />
DC C'DDNAME'<br />
DS CL3<br />
DC C'DATA SET NAME'<br />
ORG ,<br />
DS 0F<br />
REC_JOB DS 0CL134<br />
DC 134C' '<br />
ORG REC_JOB+1<br />
R_SYSID DS CL4 1<br />
DS CL2 5<br />
R_JOB DS CL8 7<br />
DS CL1 15<br />
DATE DS CL5 16<br />
DS CL1 21<br />
HH DS CL2 22<br />
DC C':' 24<br />
MM DS CL2 25<br />
DC C':' 27<br />
SS DS CL2 28<br />
DS CL1 30<br />
R_DDN DS CL8 31<br />
DS CL1 39<br />
R_DSN DS CL44 36<br />
ORG ,<br />
REC_RLS DC 134C' '<br />
Appendix A. Sample code 391
392 <strong>VSAM</strong> <strong>Demystified</strong><br />
ORG REC_RLS+1<br />
DC C'LOCAL BP HIT:' 1<br />
HITLBP DS CL12 14<br />
DS CL1 26<br />
DC C'CF CACHE HIT:' 27<br />
HITCF DS CL12 40<br />
DS CL1 52<br />
DC C'I/O DASD:' 53<br />
DASD DS CL12 62<br />
ORG ,<br />
REC_IO DS 0CL134<br />
DC 134C' '<br />
ORG REC_IO+1<br />
DC C'INS:' 23<br />
INSERT DS CL12 27<br />
DS CL1 39<br />
DC C'DEL:' 40<br />
DELETE DS CL12 44<br />
DS CL1 56<br />
DC C'UPDT:' 57<br />
UPDATE DS CL12 62<br />
DS CL1 74<br />
DC C'READ:' 75<br />
READS DS CL12 80<br />
DS CL1 92<br />
DC C'CI-SPLT:' 93<br />
CI_SPLIT DS CL6 101<br />
DS CL1 107<br />
DC C'CA-SPLT:' 108<br />
CA_SPLIT DS CL6 116<br />
ORG ,<br />
REC_SPC DC 134C' '<br />
MODEL DC X'402020202020202020202120'<br />
MODEL2 DC X'402020202120'<br />
*---------------------------------------------------------------------*<br />
* DUMMIES E EQUATES<br />
*---------------------------------------------------------------------*<br />
LTORG<br />
YREGS<br />
DSECT<br />
IDASMF64<br />
END SMFRLS<br />
//*------------------------------------------------------------------*<br />
//L.SYSLMOD DD DISP=SHR,DSN=LOAD_LIBRARY<br />
//L.SYSLIB DD DISP=SHR,DSN=LOAD_LIBRARY<br />
//L.SYSIN DD *<br />
ENTRY SMFRLS<br />
NAME SMFRLS(R)<br />
/*
GTF procedure example<br />
Example: A-6 GTF Procedure example<br />
//*------------------------------------------------------------------*<br />
//* TRACE START: UNDER SDSF ==> /S GTFIO<br />
//* REPLY:<br />
//* NN AHL125A RESPECIFY TRACE OPTIONS OR REPLY U<br />
//* TO USE OPTIONS ==> NN,U<br />
//* TO CHANGE OPTIONS ==> NN,TRACE=SSCHP,IOP,PCI,CCWP,JOBNAMEP<br />
//* ANSWER THE REPLY:<br />
//* NN AHL101A SPECIFY TRACE EVENT KEYWORDS SSCHP IOP CCWP,JOBNAMEP<br />
//* WITH ==><br />
//* NN,SSCH=(ADRS),CCW=(SI,CCWN=512,DATA=16,PCITAB=5),JOBNAME=JJJJ<br />
//* ADRS; DEVICES ADDRESS TILL 128: ADDI-ADDF<br />
//* NEW REPLY: RR AHL102A CONTINUE TRACE DEFINITION OR REPLY END<br />
//* ANSWER ==> RR,END<br />
//* AGAIN REPLY MSG AHL125A, ---------> N,U<br />
//* TO STOP THE TRACE, COMMAND ---------> /S NNNNN<br />
//* NNNNN IS THE STEPNAME SHOWN IN "DA" SDSF OPTION<br />
//*==================================================================<br />
//* MEMBER MHL CONTAINS THE GTF TRACE OPTIONS:<br />
//* TRACE=SSCHP,IOP,PCI,CCWP,JOBNAMEP<br />
//*==================================================================<br />
//GTFIO PROC MEMBER=GTF<strong>VSAM</strong>,M=MHL<br />
//IEFPROC EXEC PGM=AHLGTF,PARM='MODE=EXT,DEBUG=NO,TIME=YES',<br />
// TIME=1440,REGION=6M<br />
//IEFRDER DD DSNAME=SYS1.&M..TRACE,UNIT=SYSDA,SPACE=(CYL,(150)),<br />
// DISP=(NEW,CATLG)<br />
//SYSLIB DD DSNAME=MHLRES2.TESTS.JCL(&MEMBER),DISP=SHR<br />
Appendix A. Sample code 393
394 <strong>VSAM</strong> <strong>Demystified</strong>
B<br />
Appendix B. Miscellaneous performance<br />
items<br />
In this appendix, we describe the lab environment used for our measurements<br />
throughout the book, and have a general discussion on caching, and common<br />
error messages indicating broken data sets and output from the EXAMINE<br />
command.<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 395
Our test environment<br />
396 <strong>VSAM</strong> <strong>Demystified</strong><br />
We ran a few experiments to clarify some performance and usability aspects of<br />
<strong>VSAM</strong>. However, it happened in a non-controlled environment, where we cannot<br />
guarantee the same level of multiprogramming, and the same load in our DASD<br />
controller. Nevertheless, the results are sound, if you take into consideration such<br />
variables as number of EXCPs, I/O Connect time, and CPU time to compare the<br />
runs.<br />
The jobs are totally I/O bound due to read-and-forget and write-from-thin-air.<br />
Hardware configuration<br />
The CEC is a 2064 z900-1C7. Our three LPs (SC63, SC64, SC65) have 1.5 GB<br />
each of central storage and are located in the same CEC.<br />
The two CF images have 1.0 GB each of central storage, also located in the<br />
above referenced in CECCF. The links to the CFs and between the CFs (for SM<br />
duplexing) are all IC peer-to-peer links. There are 2 shared links between each<br />
z/OS and each CF, and f links between the CFs (for duplexing).<br />
You have 8 FICON paths to an ESS model 800 controller (not turbo) with a small<br />
I/O load.<br />
Software configuration<br />
All tests were done under z/OS V1 R4.<br />
General lab description<br />
The data for our tests were generated using IEBDG utility. The JCL and<br />
commands used are shown in Example B-1. We generated 2M records to create<br />
a master KSDS cluster, with random binary key. The data was the same for all<br />
tests, except for those tests compared with the data of first edition of this book.<br />
The type of data and the number of records are not the same as that used in the<br />
first edition of this redbook. We increased the number of records and types of<br />
data due to changes in CPU velocity, data rate (like FICON) and enhancements<br />
in ESS (SHARK).
Example: B-1 JCL for data test<br />
//CREATE EXEC PGM=IEBDG<br />
//SYSPRINT DD SYSOUT=*<br />
//TESTOUT DD DSN=MHLRES2.DATA.<strong>VSAM</strong>,DISP=(,CATLG),UNIT=SYSDA,<br />
// LRECL=300,RECFM=FB,SPACE=(CYL,(500,500),RLSE),<br />
// VOL=SER=(DJL001,DJL002)<br />
//SYSIN DD *<br />
DSD OUTPUT=(TESTOUT)<br />
FD NAME=KEY1,LENGTH=4,FORMAT=RA<br />
FD NAME=KEY2,LENGTH=4,FORMAT=RA<br />
FD NAME=DATA1,LENGTH=30,FORMAT=AL,ACTION=RP<br />
FD NAME=DATA2,LENGTH=30,PICTURE=15,P'941246876976215',ACTION=RP<br />
FD NAME=DATA3,LENGTH=100,FORMAT=AN<br />
FD NAME=DATA4,LENGTH=100,FORMAT=CO<br />
FD NAME=DATA5,LENGTH=32,FORMAT=RA<br />
CREATE QUANTITY=2000000,NAME=(KEY1,KEY2,DATA1,DATA2,DATA3,DATA4,DATA5)<br />
The sequencial access tests were done using an assembler program that opens<br />
the <strong>VSAM</strong> data set and reads it all. No others processing are done with the<br />
records.<br />
The direct access tests were done using an assembler program. The kind of<br />
tests with direct access was two:<br />
► Read direct: Read a sequencial file with 200,000 keys to read in direct access<br />
in the <strong>VSAM</strong> data set. The keys in the sequencial file are not in key sequence.<br />
► Inserts: Read a sequencial file with 200,000 keys to read in direct access in<br />
the <strong>VSAM</strong> data set. If the keys does not exits, inserts the new key in the<br />
<strong>VSAM</strong> data set. The keys in the sequencial file are not in key sequence and<br />
100,000 are insertions to the <strong>VSAM</strong> data set.<br />
The load of the data set was done using IDCAMS.<br />
The jobs access a KSDS master cluster with the following characteristics:<br />
► LRECL = 300 bytes<br />
► Key length = 8 bytes<br />
► Number of records = 2,000,000 (not uniform key values distribution)<br />
► Free Space = (10,20)<br />
► Data component CI size 4096<br />
► Index component CI size chosen by <strong>VSAM</strong><br />
There is also a physical sequential file where the 300-bytes records represents<br />
inclusions or reads in the master, with no repeated keys.<br />
► DIRECT GET: 199,998 records, 10%<br />
Appendix B. Miscellaneous performance items 397
What do we measure?<br />
398 <strong>VSAM</strong> <strong>Demystified</strong><br />
► GET SEQUENTIAL: Reads sequentially all records of the <strong>VSAM</strong> data set<br />
(2,000,000 records), with minimum record processing.<br />
► INSERTIONS: 99,999 records (5%). Splits after insertions:<br />
– Data component:<br />
Control interval: 20,810<br />
Control Area: 0<br />
– Index component:<br />
Control interval: 0<br />
Control area: 0<br />
To compare the performance results among the runs, we select the following<br />
variables:<br />
► Total I/O connect time<br />
Connect time is when the channel is transferring data from or to the cache. As<br />
we keep in all the experiences, always the same volume located in the same<br />
controller and accessed by the same channel type (so, always the same data<br />
rate), the connect time is an indirect measurement about how many bytes<br />
were transferred along the I/O operations. Then, the only way of decreasing<br />
the total I/O connect time is by moving less data to or from storage.<br />
Variations in the load of the controller should not affect this value.<br />
The total connect time was captured with GTF.<br />
► Total I/O Disconnect time<br />
Disconnect time occurs when the channel is not doing activities related to the<br />
execution of the channel program along the I/O operation. It means that the<br />
target record for a read is not in the cache and the disk access is a must.<br />
Then, the only ways of decreasing the total I/O disconnect time is by moving<br />
less data to or from storage or improving the use of the cache<br />
Variations in the load of the controller should affect this value.<br />
The total disconnect time was captured with GTF.<br />
► Number of EXCPs<br />
In SMF account information for SAM data sets, one EXCP equates one<br />
physical block transfer.<br />
For <strong>VSAM</strong> data sets one EXCP equates to one real I/O operation for data or<br />
index. It is not true, that the number of EXCPs for <strong>VSAM</strong> measures the<br />
number of transferred CIs. One EXCP in may mean more than one CI being<br />
transferred. The number of CIs per I/O depends very much in the number of
RLS experiments<br />
DASD cache concepts<br />
buffers and in the buffering technique. Consequently, the number of EXCPs is<br />
not repetitive, that is, the same job reading the same data set may present a<br />
different number of EXCPs. The reasons justifying the number of I/O<br />
operations instead of CIs are:<br />
– We can measure the <strong>VSAM</strong> capacity in saving I/O operations and<br />
consequently saving TCB and SRB time.<br />
– The number of I/O transferred CIs can be cached from LISTC in the<br />
catalog or from SMF record 64<br />
In our measurements, the number of EXCPs corresponds to the number of<br />
I/O operations.Variations in the load of the controller should not affect this<br />
value.<br />
► Elapsed time<br />
Elapsed time is the wall clock time to run the job used in the test. If the I/O is<br />
faster, in I/O bound job the elapsed time should be less.<br />
Variations in the load of the controller and the system should affect this value.<br />
► Total CPU time (TCB and SRB)<br />
All the runs are totally I/O bound, meaning no processing at all. Then the TCB<br />
time can be charged to the preparation of the I/O operation, including <strong>VSAM</strong><br />
buffer pool management. SRB time here is spent along I/O interrupts<br />
processing only.<br />
Variations in the load of the controller and system should affect very mildly<br />
this value.<br />
Refer to “Batch RLS performance experiments and comparison” on page 300.<br />
A cache is a fast storage (no mechanical movement) located in the DASD<br />
controller with two functions: to minimize access to disks (by having hits) and to<br />
serve as a speed matching buffer to synchronize elements with different speeds<br />
as channels and disks in a cache miss. In this appendix the word disk does not<br />
have the same meaning of DASD. Disk implies RAID media (FBA, SSA or SCSI)<br />
used by modern controllers. DASD still means the logical 3390/3380.<br />
To have random hits (saving disk access) for reads and writes, the I/O workload<br />
must revisit its data, however in certain cases it does not happen. In this case<br />
such workloads are called cache unfriendly. Usually, we may have two types of<br />
hits for <strong>VSAM</strong> data, when the application revisits:<br />
Appendix B. Miscellaneous performance items 399
400 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Exactly the same logical record in a CI already in cache<br />
► The same data CI (already in cache) because other logical record (a sort of<br />
lucky)<br />
For sequential access, it is important to say that, cache does not save data CI<br />
disks I/O operations. The cache only tries to match the speed of the disks and<br />
channels.<br />
With the new controllers a cache miss implies accessing the RAID disks and not<br />
the logical 3390/3380 device (which do not exist physically). Because the<br />
mapping between the 3390/3380 tracks to the FBA RAID disks is not<br />
externalized, it is not important anymore the relative location of files in order to<br />
avoid long Seeks or even RPS misses.<br />
It is interesting to note that heavy cache access reduces DASD skew (unequal<br />
3390/3380 device utilization) because data formerly in heavily used devices now<br />
became electronically accessible due to the LRU algorithm. Refer th the DASD<br />
Activity report in Figure B-1.<br />
I=92% DEV ACTV RESP IOSQ ---DELAY--- PEND DISC CONN<br />
VOLSER NUM MX LCU RATE TIME TIME DPB CUB DB TIME TIME TIME<br />
TOTTSJ 256C 005A 0.024 11 0 0.0 0.0 0.0 0.2 8.2 2.2<br />
TOTJS1 250C 0059 5.764 6 0 0.0 0.0 1.2 1.5 0.1 4.7<br />
TSMS50 650D 4 0144 139.6 1 0 0.0 0.0 0.0 0.3 0.0 0.7<br />
Figure B-1 DASD Activity Report<br />
Increasing the I/O rate, decreases the disconnect time (less the disconnect more<br />
hits in cache) due to the LRU algorithm is keeping in cache the most used<br />
elements.<br />
There are two types of cache: volatile and non-volatile (NVS). NVS is used to<br />
keep DFW, dual copy and XRC remote copy records. In this chapter we use the<br />
word cache meaning the volatile cache and NVS for the non-volatile.<br />
The cache is made of CMOS DRAM storage for Data and Directory. The<br />
directory entries describes the data elements (4 KB in ESS) and are ordered in<br />
the following queues:<br />
► LRU (pointing to active data elements)<br />
► Free (available for staging from disk or writes)<br />
► Pinned (changed data in cache and the respective disk is not available)<br />
► Defective
Destage is the movement from cache to disk caused by previous DFW and CFW<br />
writes (to be covered later) and it is asynchronous with the I/O operation which<br />
executed the writes. By the way, demotion is not a synonym of destaging.<br />
Demotion means to take a data element out from cache. If there is a valid copy in<br />
disk there is not a destage. If not, a destage is done. There are three types of<br />
destaging:<br />
► To relieve contention, when NVS or Cache become full. Controlled by<br />
modified LRU algorithms, when the percentage of NVS occupancy is greater<br />
than X%. If greater than Y% (Y>X), then the DFW I/O operation bypass the<br />
NVS cache going synchronously from volatile cache to disk (called DFW<br />
bypass)<br />
► Done in background by the controller when the percentage of NVS occupancy<br />
is above another threshold Z% (Z < X)<br />
► Forced by Z EOD command or by an hardware error<br />
The amount of data destaged is usually more than one 3390/3380 track. A smart<br />
controller can Identify other records changed in adjacent tracks of the record to<br />
be destaged and destage all of them. It saves rotational delays in the disks and<br />
bypass the RAID write penalty.<br />
Stage is the movement from DASD to cache, it can be synchronous (a read miss)<br />
for a random request or asynchronous for a sequential look ahead read. Pay<br />
attention that random and direct have the same meaning.<br />
A cache hit may overlap with staging/destaging operations, for the same<br />
3390/3380 logical device. It is possible to have concurrent access to same<br />
3390/3380 device data but not in the same track, for example, one hit in the<br />
cache and an asynchronous destage in the disks back storage (not in the same<br />
3390/3380 track). This is not the ESS PAV feature, because here there is just one<br />
active I/O operation, that is the one with the hits in the cache, the destage is just<br />
controller housekeeping.<br />
Controller accounts data about number of I/O operations, hits, misses, destages,<br />
in a volume or in a data set basis. These values are shown by IDCAMS<br />
LIISTDATA command, by RMF Cache report and used in SMS for Dynamic<br />
Caching for data sets.<br />
Set Subsystem CCW activates the use of caching in the controller (subsystem)<br />
and in individual volumes. This CCW allows cache modes as normal, DFW and<br />
CFW. All these modes may be asked explicitly by software through the Define<br />
Extent CCW (per each I/O operation), in some cases the controller can<br />
adaptively change the mode due to the observed pattern of access. Following is<br />
the description of such CCW.<br />
Appendix B. Miscellaneous performance items 401
Cache Modes<br />
402 <strong>VSAM</strong> <strong>Demystified</strong><br />
Define Extent CCW provides a 16 bytes parameters, which define limits on<br />
subsequent operations (extent information, avoidance of writes, for example),<br />
provide a blocksize value, and specify caching control mode (or hints) for the<br />
channel program. The caching mode have the granularity of I/O operation. These<br />
modes are not totally mutual exclusive, and the same I/O operation may have<br />
more than one mode. The modes are:<br />
► Track Level Cache (TLC)<br />
► Record Level Cache (RLC)<br />
► Sequential:<br />
– Reads:<br />
Sequential Access<br />
Sequential Pre-stage<br />
– Writes<br />
► Least Recently Used (LRU)<br />
► Normal Caching<br />
► CFW<br />
► DFW<br />
– With the possibility of Quick Writes<br />
► Bypass Cache<br />
► Inhibit Cache Loading<br />
An explanation of these modes is:<br />
► Track Level Cache (TLC)<br />
In TLC the unit of transport between cache and disks are the 3390/3380<br />
tracks. TLC is more adequate to sequential. When in TLC mode the<br />
3390/3380 track is staged in cache in one pass (if first miss is in record zero<br />
(R0)) or in two pass (if first miss is not in R0). RVA only has track level cache<br />
because the compact/compress data cause little traffic when moving logical<br />
3390/3380 tracks.<br />
► Record Level Cache (RLC)<br />
In RLC the unit is the referred logical 3390/3380 physical record. RLC is very<br />
adequate to random (also called direct) processing.<br />
Let us explain what do we mean by “logical 3390/3380 physical record”. The<br />
word logical indicates that the 3390/3380 does not real exist. The word<br />
physical indicates that we are talking about the physical record (the block) in<br />
the logical 3390/3380 track...
RLC improves performance for applications that do not exhibit good locality of<br />
reference and where the cost of track caching out weights the benefits. RLC<br />
reduces the costs associated with cache miss I/Os by staging less data into<br />
cache (less cache pollution), which frees the volume and other activity more<br />
quickly. Reading less data into cache also enables data to stay in cache<br />
longer, which increases the chances of future cache hits.<br />
ESS controller is able to switch from one to the other depending on the<br />
access pattern, independently of the Define Extent CCW.<br />
RLC is mutually exclusive from TLC<br />
RLC can be activated for <strong>VSAM</strong> SMS managed maybe-cache data sets. SMS<br />
via DCME decides in Define Extent when to use RLC for reads. Refer to ,<br />
“Using cache in an SMS data set” on page 409. In addition to deciding to<br />
enable or to disable the cache for maybe-cache SMS data sets, SMS picks up<br />
between RLC or TLC for reads.<br />
► Sequential<br />
When in sequential mode, the controller uses the cache just as a speed<br />
matching buffer, to synchronize different speeds. There are two types.<br />
In sequential read mode, the controller does the pre-staging of a certain<br />
number of future referenced logical 3390/3380 tracks. After used, the tracks<br />
are or not demoted from cache depending on the sub mode:<br />
– Sequential Access: The used data is a strong candidate to be demoted<br />
– Sequential Pre-stage: The used data is protected by the LRU algorithm.<br />
Sequential read can be activated:<br />
– Explicitly by software through Define Extent CCW (also called sequential<br />
hint), as declared by <strong>VSAM</strong> ESDS for Sequential Access. KSDS/VRRDS<br />
in certain conditions declare Sequential Pre-stage.<br />
– By sequential detect, where the controller detects sequential access (six<br />
sequential referred logical 3390/3380 physical tracks in the ESS).<br />
Because KSDS/VRRDS <strong>VSAM</strong> organizations (in certain conditions) do not<br />
use the Define Extent. Then, in this case, it is interesting to avoid CI /CA<br />
splits in data sets usually processed sequentially. Splits make the logical<br />
sequence different from the physical sequence, and the controllers only<br />
detect the physical sequence pattern.<br />
► Least Recently Used (LRU)<br />
LRU is not properly a mode, but a technique to maintain in the cache the most<br />
referenced elements. It is the major algorithm to control cache demoting,<br />
admitting that, if an element was referenced in the past, it is going to be again<br />
in the future. LRU is automatically set off when sequential caching, inhibit<br />
cache load and bypass cache modes are active<br />
Appendix B. Miscellaneous performance items 403
404 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Normal Caching<br />
In this mode the NVS cache is not used. There are four cases to consider in<br />
this mode:<br />
– For a read hit, there is a data transfer from cache to channel followed by a<br />
channel end (CE)/ device end (DE) I/O interrupt. The directory entry is<br />
LRU update (meaning that the data is to be kept in cache for a while).<br />
– For a read miss, the channel is disconnected, the disk is accessed to<br />
stage data to cache (here, we may have the delay caused by the disk<br />
being already busy or all lower interfaces are busy). After that, the channel<br />
is reconnected and the data is transferred to channel from cache, CE/DE<br />
I/O interrupt, stage rest of track (if in track mode), LRU update.<br />
If all the serving channels are busy, there is not an RPS miss, because the<br />
data is already in the cache. With the new controllers, RPS misses only<br />
occur when the internal path to disks are busy and the disk needs a new<br />
revolution.<br />
– For a write hit, because the NVS cache is not used, it is like a miss. The<br />
channel moved data to volatile cache and disconnects. The disk is<br />
accessed synchronously to write data (here, we may have the delay<br />
caused by the disk being already busy or all lower interfaces are busy).<br />
The word synchronously means that the write to disk is done without the<br />
end of the I/O operation be posted to the application.<br />
After the write to disk, the channel is reconnected and CE/DE I/O interrupt<br />
is presented. LRU update (meaning that the data is to be kept in cache for<br />
a while)<br />
– For a write miss the channel move data to cache and disconnects. The<br />
disk is accessed synchronously to write data (here, we may have the delay<br />
caused by the disk being already busy or all lower interfaces are busy).<br />
The word synchronously means that the write to disk is done without the<br />
end of the I/O operation be posted to the application.<br />
After the write to disk, the channel is reconnected and CE/DE I/O interrupt<br />
is presented. No LRU update, meaning that the cache copy if the data is<br />
ready to be demoted<br />
► Cache Fast Write (CFW)<br />
Is used for temporary data sets and consequently does not use the NVS for<br />
writes. It must be allowed by the Set Subsystem CCW issued by IDCAMS.<br />
– For reads and write misses is identical to normal caching.<br />
– For a write hit, the data is transfer from the channel to the cache followed<br />
by a CE/DE I/O interrupt and the directory entry is LRU update (meaning
that the data is to be kept in cache for a while). Later on asynchronously<br />
the data will be destaged to disks.<br />
Used by Sort for temporary files and for creating PDSE members (before the<br />
Stow) when the Hiperspace is full. The exploiter must declare CFW in the<br />
Define Extent CCW.<br />
► DASD Fast Write (DFW)<br />
DFW allows the use of the NVS cache for writes. It avoids accessing disks for<br />
a write hit. It must be allowed by the Set Subsystem CCW issued by IDCAMS.<br />
– For reads is identical to Normal Caching.<br />
– For a write hit, the data is transfer from the channel to the cache and NVS,<br />
followed by a CE/DE I/O interrupt and the directory entry is LRU update<br />
(meaning that the data is to be kept in cache for a while). Some modern<br />
controllers as ESS sends the CE/DE earlier with one copy of the data in<br />
the NVS (other copy in the channel adapter buffer) doing the copy to the<br />
volatile cache immediately after the CE/DE.<br />
Later on and asynchronously the data will be destaged to disks. However,<br />
if the NVS cache is under stress the controller is smart enough in sending<br />
the data from volatile cache directly to disks (synchronously). This<br />
situation is called DFW bypass and the channel stays disconnected along<br />
this data transfer. If you recall the dam story is like creating a bypass in the<br />
dam.<br />
► Almost 100% DFW Hits (Quick writes)<br />
This mode allows the use of the NVS cache for writes. It avoids accessing<br />
disks for a write hit and almost 100% of the write misses. In certain<br />
controllers, its logic is included in the RLC licensed internal code (LIC).<br />
Almost 100% DFW hits is also called "quick writes". It allows a DFW miss turn<br />
to a hit (provided that adequate NVS space is available).<br />
The reason causing the access of disks for a write data miss in a DFW mode<br />
is the verification of the record length. To clarify this point refer to Figure B-2<br />
and follow the description of the existent two types of write CCWs.<br />
– Write format, also called write count-key-data, formats the 3390/3380<br />
track by overlaying the old records in the track and creating a count with<br />
the respective data (usually with a zero content), the rest of the track is<br />
erased. The length of the data record is included in the write<br />
count-key-data CCW and copied in the count. In this case, the previous<br />
record data length is not important because it is overlaid.<br />
All the write format I/O operations are considered a write hit.<br />
– Write modified, also called write data, change the contents of the data<br />
portion of a pre-formatted record which length is already described in the<br />
Appendix B. Miscellaneous performance items 405
406 <strong>VSAM</strong> <strong>Demystified</strong><br />
count. The length of the data record is also included in the write data<br />
CCW. Any mismatch between this length and the one already specified in<br />
the count of the formatted record is posted by the channel (to the<br />
application) and in some cases, it may stop the execution of the channel<br />
program. Then is clear the need of accessing the 3390/3380 track in a<br />
DFW write modified miss because the controller is not able to verify (and<br />
compare) the length in the write modified CCW and the count. On the<br />
other hand is now clear why the write format is always a hit, because there<br />
is no need of such verification.<br />
Write Format (CKD)<br />
Write Modified (D)<br />
Figure B-2 Types of writes<br />
R0 R1<br />
HA C D C D<br />
R0 R1 R2<br />
HA C D C D C D<br />
Always<br />
Hit!<br />
I need to<br />
match the<br />
length in disk<br />
Controller<br />
Controller<br />
Write<br />
Format<br />
Write<br />
Modified<br />
Channel<br />
Cache<br />
Channel<br />
For quick writes the controller must know or be able to predict the length of<br />
the record avoiding the access to the disks.<br />
Quick writes is implemented in two sub-modes associated with record level<br />
cache. Remember that in some IBM controllers, quick writes are associated<br />
with the record level cache LIC:<br />
– Record Level Cache I:<br />
It is a joint <strong>VSAM</strong>/controller implementation.<br />
D<br />
Cache<br />
D<br />
C D<br />
(C & D)<br />
NVS<br />
D<br />
NVS<br />
(D)
Because <strong>VSAM</strong> is a trusted partner (regular data format) all writes<br />
become quick writes, that is, the controller decides not to go to disk to<br />
verify the data record length. This function benefits IMS, DB2 and CICS<br />
users of <strong>VSAM</strong>. The data set could be SMS or not, it requires<br />
DFSMS/MVS 1.2 or PTF equivalent.<br />
– Record Level Cache II:<br />
It is non-adaptive (the controller does by itself), with no Define Extent<br />
CCW software intervention. When RLC II is activated it cannot be<br />
disabled. In the first access to the record there is a disk access (miss) and<br />
the record length is moved and kept in cache for the future requests. It<br />
aims to reach "almost 100% writes hits". The controller automatically<br />
determines whether to use the track cache algorithm as it processes I/Os<br />
to the volumes with cache active. RLC II requires:<br />
Volume behind a controller with RLC II installed<br />
TLC enabled for that volume<br />
DFW enabled for that volume<br />
► Inhibit Cache Load (ICL)<br />
If a read hit occurs read from cache and LRU update. If a read miss or a write<br />
access the disks through volatile cache, no LRU update. Then, cache space<br />
is not allocated for any new tracks from DASD. Write operations that do not<br />
require access to DASD are not inhibited by this setting.<br />
Used by DFDSS, DFSORT (Sortin), SMS (never-cache and some of the<br />
maybe-cache data sets). As a general rule, it maybe used by an application<br />
which knows that the record to be requested is not going to be used in the<br />
near future (as for cache unfriendly accesses).<br />
Ignore ICL is an option set in VPD, when your workload is not aware of a huge<br />
cache size<br />
► Bypass Cache<br />
Where the I/O request must be executed in the disks (even if the data is in the<br />
cache). However, the data always pass through cache without LRU update,<br />
consequently the copy is ready to be demoted. If a hit in the cache, the LRU is<br />
updated. Cache images of tracks modified on the device will be invalidated.<br />
Tracks modified in cache but not on DASD are destaged to DASD before<br />
access is allowed. For Duplex volumes this includes destaging to both<br />
devices. DASD Fast Write operation is disabled with this attribute active.<br />
It is used by ICKDSF, paging, and Write Check access method option.<br />
Ignore BYP is an option set in VPD, being used when your workload is not<br />
aware of a huge cache size.<br />
Appendix B. Miscellaneous performance items 407
Using cache modes in a non-SMS data set<br />
Figure B-4 Cache activity report<br />
408 <strong>VSAM</strong> <strong>Demystified</strong><br />
An I/O operation towards a non-SMS data set is able to use some of the cache<br />
modes. In order to do that, you must use IDCAMS Setcache command to<br />
activate:<br />
► Globally in the controller:<br />
– Cache in general<br />
– DFW (or the use of NVS)<br />
– CFW<br />
RMF in cache subsystem status reporting Figure B-3 shows the result of such<br />
operation:<br />
----------------------------------------------------------------------------<br />
CACHE SUBSYSTEM STATUS<br />
----------------------------------------------------------------------------<br />
SUBSYSTEM STORAGE NON-VOLATILE STORAGE STATUS<br />
CONFIGURED 256.0M CONFIGURED 8.0M CACHING<br />
AVAILABLE 254.9M PINNED 0.0 NON-VOLATILE<br />
STORAGE<br />
PINNED 0.0 CACHE FAST WRITE<br />
OFFLINE 0.0 IML DEVICE AVAILABLE<br />
Figure B-3 Cache Subsystem Status report<br />
► Locally in each volume:<br />
– Normal cache<br />
– DFW (or the use of NVS)<br />
– Dual Copy<br />
RMF in Cache Activity report in Figure B-4 shows the result of such operation:<br />
VOLSER D83STE NUM 0D84<br />
----------------------------------------------------------------------------<br />
CACHE DEVICE STATUS<br />
----------------------------------------------------------------------------<br />
CACHE STATUS DUPLEX PAIR STATUS<br />
CACHING - ACTIVE DUPLEX PAIR - NOT ESTABLISHED<br />
DASD FAST WRITE - ACTIVE STATUS - N/A<br />
PINNED DATA - NONE DUAL COPY VOLUME
These options are passed to the controller by IDCAMS. Without SMS all the data<br />
sets in volume follow these rules (normal or DFW). The other cache modes must<br />
be declared explicitly by the requester through an IOS, which builds the define<br />
extent CCW.<br />
Using cache in an SMS data set<br />
SMS uses the define extent CCW to set some cache modes along the I/O<br />
operation for an SMS data set. If there is a conflict between Define Extent and<br />
IDCAMS volume setting the more restrictive option prevails.<br />
For example: IDCAMS says non-DFW for the volume and define extent says<br />
DFW for the I/O operation, then it will be non-DFW.<br />
However, there are certain cache modes not set by SMS as bypass cache and<br />
CFW. In this case the requester should use interface directly with IOS in order to<br />
have theses options in the define extent CCW.<br />
Cache usage attributes<br />
An opened SMS data set may have one of three cache usage attributes, in<br />
regard to DASD cache:<br />
► Must-cache data set: Uses cache/NVS for the I/O operations.<br />
► Never-cache data set: Does not use cache (only for buffering) and does not<br />
use NVS. The ICL mode is requested in Define Extent CCW.<br />
► May-cache data set: Uses cache/NVS depending on the cache/NVS<br />
constraints.<br />
The same data set may have one of the above attributes for sequential accessing<br />
mode and a different one for direct accessing mode. This is also true for read<br />
access and write access. These attributes are based in the SMS storage class<br />
(SC) installation parameters (MSR for Direct, MSR for sequential or BIAS<br />
respectively). MSR is the desired I/O service time in milliseconds and BIAS the<br />
expected dominance of reads or writes operations.<br />
The cache usage attributes are assumed at open time, for a data set. These<br />
cache attributes are kept constant until the data set is closed.<br />
Dynamic Cache Management Enhanced (DCME)<br />
DCME is a function in the controller able to produce cache information in a<br />
system and in a data set basis. SMS uses data from DCME in order to adjust the<br />
use of the cache for may-cache data sets. With DCME, SMS distinguishes<br />
between good (cache-friendly) and poor cache (cache unfriendly) candidate data<br />
sets when deciding which I/Os to which data sets should be cached.<br />
Appendix B. Miscellaneous performance items 409
410 <strong>VSAM</strong> <strong>Demystified</strong><br />
DCME produces two key measurements:<br />
► Data set cache behavior:<br />
DCME maintains information about the hit ratios achieved by I/Os to each<br />
may-cache data set. DCME continuously updates this information so that it<br />
can make decisions on which I/Os to which data sets should be cached,<br />
based on the most recent I/O activity.<br />
When considering whether or not to cache I/Os to a data set, two controller<br />
resources must be accounted for: the cache and the NVS. A data set might<br />
very well be a good user of the cache and a poor user of the NVS. SMS,<br />
therefore, maintains two criteria: one general (for all I/Os) and one specific for<br />
writes.<br />
Two data set related indicators are calculated:<br />
– Overall Hit Ratio: Reads Hits + Writes Hits / Cachable IOs<br />
Used to decide to cache a Read request.<br />
– Write Hit Ratio: Write Hits / Write IOs<br />
Used to decide to cache a Write request.<br />
A hit is perceived by a disconnect time less that 0.5 ms.<br />
These indicators are weighed averages of previous values to avoid sudden<br />
changes.<br />
► Subsystem load (here the word subsystem means DASD controller)<br />
The DCME in controller produces global data about the cache usage.<br />
A Subsystem Threshold (ST) indicator is timely calculated by SMS from the<br />
global DCME data. Higher the ST more cache contention. These statistics are<br />
periodically collected by SMS. The time is controlled by DINTERVAL at<br />
IGDSMSxx Parmlib (default 150 seconds).<br />
ST reflects the DASD cache performance and is composed by the figures of<br />
Read Hit Ratios and DFW bypass for all the cached volumes in the DASD<br />
subsystem.<br />
The DFW bypass occurs when a DFW hit request requires NVS, but this storage<br />
is not available due to contention. In this case, the I/O request will bypass the<br />
NVS and is executed directly from the volatile cache to the disks.<br />
Also, based on the statistics, SMS maintains two global average indicators:<br />
► Cache Control Indicator (CCI), the percent of may-cache I/O requests allowed<br />
to use cache.
► NVS Control Indicator (NVSCI), the percent of may-cache DFW I/O requests<br />
allowed to use NVS.<br />
These values used for this caculation can be displayed using the D SMS,CACHE<br />
command (Figure B-5).<br />
IGD002I 18:09:11 DISPLAY SMS 276<br />
SSID DEVS READ WRITE HIT RATIO FW BYPASSES<br />
00FF 5 N/A N/A 97% 0<br />
8900 8 N/A N/A 98% 0<br />
8902 5 N/A N/A 98% 0<br />
8904 4 N/A N/A 99% 0<br />
8903 7 N/A N/A 99% 0<br />
8901 4 N/A N/A 98% 0<br />
000A 8 N/A N/A 99% 0<br />
3000 21 N/A N/A 99% 0<br />
8905 6 N/A N/A 97% 0<br />
6004 8 N/A N/A 90% 0<br />
0028 4 N/A N/A 98% 24<br />
00FD 7 N/A N/A 98% 0<br />
00FC 4 N/A N/A 99% 0<br />
00FE 1 N/A N/A 98% 0<br />
Figure B-5 D SMS,CACHE output<br />
The following legend explains the columns in Figure B-5:<br />
► Ssid = Subsystem Identifier<br />
► Devs = Number of managed devices attached to subsystem<br />
► Read = Percent of data on managed devices eligible for caching<br />
► Write = Percent of data on managed devices eligible for DFW<br />
► Hit Ratio = Percent of reads with cache hits<br />
► Fw Bypasses = Number of fast write bypasses due to NVS overload<br />
An I/O operation for a may-cache data set has three states:<br />
► Normal, the data set I/O is allowed to use the cache through the define extent<br />
CCW.<br />
► Inhibit, the data set I/O does not use the cache that is, the Inhibit Cache Load<br />
bit is set on the define extent first CCW of a Read channel program, in order<br />
to inhibit the staging of the cache. In the case of a Write channel program, the<br />
Inhibit DFW bit is set on the define extent first CCW of a Write channel<br />
program, to inhibit DFW, and consequently the staging of NVS.<br />
► Force, the data set I/O is cached so that the indicators can be evaluated.<br />
Appendix B. Miscellaneous performance items 411
412 <strong>VSAM</strong> <strong>Demystified</strong><br />
The logic is:<br />
► After open for the first 100 I/Os and the first 100 Writes the I/Os are forced.<br />
► The data set indicator is compared with subsystem threshold. If does not<br />
exceed, the data set I/Os are going to be inhibited for the next 5000 I/Os. If<br />
exceeds, the data set I/Os are going to be normal for a certain amount of<br />
time, where the comparison is going to be done again.<br />
So, if the ST indicator is going up, the exclusion from cache for may-cache data<br />
sets is gradual. No sudden and dramatic changes in the DASD subsystem<br />
performance are caused.<br />
As a DCME by-product DFSM I/O statistics (I/O rates, I/O response time, I/O<br />
service time components, caching statistics for reads and writes) are collected in<br />
new SMF records in data set and storage class basis.<br />
Never-cache candidates data sets<br />
There are some data sets that are not good candidates for DASD caching, such<br />
as:<br />
► Data sets that are processed track-by-track, as the input to the dump function<br />
of DFDSS itself. However, in this case the installation does not need to care<br />
about this, because DFDSS uses the adequate option (inhibit cache load) in<br />
the Define Extent command.<br />
► Data sets which have a very poor direct revisit pattern.<br />
► ASM paging data sets.<br />
Share options analogy<br />
Refer to Figure B-6, to follow this explanation:<br />
Once upon a time, there were two lands (MVS A and MVS B) separated by a<br />
river. All the culture accumulated by the people living there was stored in two<br />
shared <strong>VSAM</strong> data sets strategically located in the middle of the separating river.<br />
In each land, there were two sets of people, the round-head and the square-head<br />
(pay attention that each set lives on both sides of the river). Each head shaped<br />
people used their own data set (black data set for the square and white data set<br />
for the round head). The data sets were accessed by students, the readers (for<br />
read) and by the professors, the updaters (for writes).
MVS A MVS B<br />
Updater<br />
Updater<br />
<strong>VSAM</strong><br />
Updater<br />
Updater<br />
Local<br />
ENQ<br />
Updater<br />
Figure B-6 Sharing <strong>VSAM</strong> data sets<br />
Updater<br />
Reader<br />
(23)<br />
(33)<br />
Global<br />
GRS<br />
Updater<br />
Updater<br />
Updater<br />
The square-heads (from the both lands) care about write integrity and not about<br />
read integrity, so they choose shareoptions (2 3) for their data set and they use<br />
GRS adequately for their purpose.<br />
The round-heads (from the both lands) cared about write and read integrity. They<br />
decided to implement that through GRS/ENQ mechanism only. The shareoptions<br />
of the round-head data set is (3 3).<br />
The picture is showing what finally happened:<br />
► In the square-head story, we may see, updaters being held by the <strong>VSAM</strong> gate<br />
in both sides of the river. This was caused by cross region 2 in shareoptions.<br />
Only one updater succeeds in passing the gate (in each side). All others open<br />
for output fail with a return code in ACB. However, the reader in MVS A was<br />
not blocked by <strong>VSAM</strong> gate (no read integrity).<br />
Local<br />
ENQ<br />
<strong>VSAM</strong><br />
Appendix B. Miscellaneous performance items 413
414 <strong>VSAM</strong> <strong>Demystified</strong><br />
To guarantee write integrity between updaters from the two lands, a global<br />
GRS/ENQ is implemented guaranteeing that a second updater (from MVS B<br />
in the picture) which arrived last, be held at the GRS gate.<br />
► For the round-head story, there are no <strong>VSAM</strong> gates for the round-heads<br />
because of cross region option 3. In both sides they implement a local ENQ<br />
gate to guarantee read and write integrity. That is, only one updater or several<br />
readers from each MVS are allowed to the round-head data set.<br />
However, they did not read the GRS Primer book. The ENQ name is not<br />
made global to GRS, and then two updaters (each from each land) are<br />
allowed to update concurrently the round-head data set, then blowing up the<br />
integrity.<br />
Symptoms (messages) from a broken data set<br />
The most common messages associated with broken data sets events are:<br />
► IDC3302I ACTION ERROR ON dsname<br />
Explanation: An error was detected while attempting to access the data set.<br />
See the associated message in the program listing for explanation.<br />
► IDC3308I ** DUPLICATE RECORD xxx<br />
Explanation: The output data set of a Repro command already contains a<br />
record with the same key or record number. In the message text:<br />
– xxx For an indexed data set, the first five bytes of the duplicate key, in<br />
hexadecimal format. For a relative record data set, the relative record<br />
number (in decimal) of the duplicate record.<br />
– System Action: The system does not write the record. The system<br />
continues processing with the next record, unless this is a copy catalog<br />
and a duplicate record is encountered or there has been a total of four<br />
errors. The system ends in either case. For example, if a duplicate record<br />
is encountered while Repro is copying a catalog, the system ends<br />
processing.<br />
If the record in the input file with the duplicated key is to replace the one in the<br />
data set, you should specify the replace option. If not, check your Repro input.<br />
► IDC3314I RECORD xxx OUT OF SEQUENCE<br />
Explanation: The key of the record to be written is less than or equal to the<br />
key of the last record written. In the message text:<br />
– xxx The first five bytes in hexadecimal format of the key of the record<br />
that is out of sequence.
– System Action: If the output data set is a virtual storage access method<br />
(<strong>VSAM</strong>) data set, the system ends processing of the command after four<br />
errors.<br />
– Application Programmer Response: Rearrange the records to be written<br />
so that they are in ascending key sequence. The record can be written to<br />
the data set using skip sequential processing. Run the job again and the<br />
output data set will be opened for skip sequential processing (because<br />
data already exists in the data set) and records that were out of sequence<br />
will be written.<br />
► IDC3351I ** <strong>VSAM</strong> {OPEN|CLOSE|I/O} RETURN CODE IS return-code<br />
{RPLFDBWD=nnnnnnnn}<br />
An error was encountered during <strong>VSAM</strong> open, close, or action request<br />
processing, as indicated in the text of the message:<br />
nnnnnnnn The meaning can be found in DFSMS/MVS Macro Instructions for<br />
Data Sets.<br />
rc The return code, as follows:<br />
– For CLOSE errors, we present only the return codes associated with<br />
broken data set situation:<br />
128 Index search horizontal chain pointer loop<br />
encountered.<br />
136 Not enough virtual storage was available in the<br />
program's address space for a work area for<br />
CLOSE.<br />
184 An uncorrectable I/O error occurred while <strong>VSAM</strong><br />
was completing outstanding I/O requests.<br />
246 The compression management services (CMS)<br />
close function failed.<br />
– For OPEN errors, we present only the return codes associated with broken<br />
data set situation:<br />
76 Attention message: The interrupt recognition flag<br />
(IRF) was detected for a data set opened for input<br />
processing<br />
This indicates that DELETE processing was<br />
interrupted. The structure of the data set is<br />
unpredictable; the access method services<br />
DIAGNOSE command may be used to check the<br />
data set for structural errors.<br />
Appendix B. Miscellaneous performance items 415
416 <strong>VSAM</strong> <strong>Demystified</strong><br />
88 A previous extend error has occurred during EOV<br />
processing of the data set.<br />
96 Attention message: an unusable data set was<br />
opened for input.<br />
104 Attention message: the time stamp of the volume<br />
on which a data set is stored doesn't match the<br />
system time stamp in the volume record in the<br />
catalog; this indicates that extent information in the<br />
catalog record may not agree with the extents<br />
indicated in the volume's VTOC.<br />
108 Attention message: the time stamps of a data<br />
component and an index component do not match;<br />
this indicates that either the data or the index has<br />
been updated separately from the other. Check for<br />
possible duplicate VVRs.<br />
116 Attention message: the data set was not properly<br />
closed or was not opened. If the data set was not<br />
properly closed, then data may be lost if processing<br />
continues. Use the access method services<br />
VERIFY command to attempt to close the data set<br />
properly. In a cross-system shared DASD<br />
environment, a return code of 116 can have two<br />
meanings:<br />
- The data set was not properly closed.<br />
- The data set is opened for output on another<br />
processor.<br />
Note: If you use the VERIFY command, this<br />
message can appear again when VERIFY<br />
processing opens the data set. If VERIFY<br />
processing then successfully closes the data set,<br />
VERIFY processing issues condition code 0 at the<br />
end of its processing. In addition, an empty cluster<br />
cannot be verified.<br />
132 One of the following errors occurred:<br />
- Not enough storage was available for work areas.<br />
- The format-1 DSCB or the catalog cluster record<br />
is incorrect.<br />
136 Not enough virtual-storage space is available in the<br />
program's address space for work areas, control<br />
blocks, or buffers.
140 The catalog indicates this data set has an incorrect<br />
physical record size.<br />
160 The operands specified in the ACB or GENCB<br />
macro are inconsistent with each other or with the<br />
information in the catalog record. This error can<br />
also occur when the <strong>VSAM</strong> cluster being opened is<br />
empty.<br />
164 An uncorrectable I/O error occurred while <strong>VSAM</strong><br />
was reading the volume label.<br />
168 The data set is not available for the type of<br />
processing specified, or an attempt was made to<br />
open a reusable data set with the reset option while<br />
another user had the data set open.<br />
184 An uncorrectable I/O error occurred while <strong>VSAM</strong><br />
was completing an I/O request.<br />
190 An incorrect high-allocated RBA was found in the<br />
catalog entry for this data set. The catalog entry is<br />
bad and will have to be restored.<br />
192 An unusable data set was opened for output.<br />
193 The interrupt recognition flag (IRF) was detected<br />
for a data set opened for output processing.<br />
194 Direct access of a compressed data component is<br />
not allowed.<br />
200 Volume is unusable.<br />
212 The ACB MACRF specification is GSR or LSR and<br />
the data set requires create processing.<br />
232 Reset (ACB MACRF=RST) was specified for a<br />
nonreusable data set and the data set is not empty.<br />
240 Format-4 DSCB and catalog time stamp verification<br />
failed during volume mount processing for output<br />
processing.<br />
– For a Logical I/O Error<br />
4 End of data set encountered (during sequential<br />
retrieval), or the search argument is greater than<br />
the high key of the data set. Either no EODAD<br />
routine is provided, or one is provided and it<br />
returned to <strong>VSAM</strong> and the processing program<br />
issued another GET.<br />
Appendix B. Miscellaneous performance items 417
418 <strong>VSAM</strong> <strong>Demystified</strong><br />
8 You attempted to store a record with a duplicate<br />
key, or there is a duplicate record for an alternate<br />
index with the unique key option.<br />
12 You attempted to store a record out of ascending<br />
key sequence in skip-sequential mode; record had<br />
a duplicate key; for skip-sequential processing,<br />
your GET, PUT, and POINT requests are not<br />
referencing records in ascending sequence; or, for<br />
skip-sequential retrieval, the key requested is lower<br />
than the previous key requested. For shared<br />
resources, buffer pool is full.<br />
16 Record not found.<br />
20 Record already held in exclusive control by another<br />
requester.<br />
28 Data set cannot be extended because <strong>VSAM</strong><br />
cannot allocate additional direct-access storage<br />
space. Either there is not enough space left to<br />
make the secondary allocation request, you<br />
attempted to increase the size of a data set while<br />
processing with SHROPT=4 and DISP=SHR, or<br />
the index CI is not large enough to hold the entire<br />
CA. This error could also be due to a data set trying<br />
to extend beyond 4GB on a system that does not<br />
support extended addressability.<br />
32 An RBA specified that does not give the address of<br />
any data record in the data set.<br />
40 Insufficient virtual storage in the user's address<br />
space to complete the request.<br />
116 During initial data set loading (that is, when records<br />
are being stored in the data set the first time it's<br />
opened), GET, POINT, ERASE, direct PUT, and<br />
skip-sequential PUT with OPTCD=UPD are not<br />
allowed. During initial data set loading, VERIFY is<br />
not allowed except for an entry-sequenced data set<br />
(ESDS) defined with the RECOVERY option. For<br />
initial loading of a relative record data set, the<br />
request was other than a PUT insert.<br />
128 A loop exists in the index horizontal pointer chain<br />
during index search processing.<br />
144 Incorrect pointer (no associated base record) in an<br />
alternate index.
156 An addressed GET UPD request failed because<br />
the control interval flag was on, or an incorrect<br />
control interval was detected during keyed<br />
processing. In the latter case, the control interval is<br />
incorrect for one of the following reasons:<br />
- A key is not greater than the previous key.<br />
- A key is not in the current control interval.<br />
- A spanned record RDF is present.<br />
- A free space pointer is incorrect.<br />
- The number of records does not match a group<br />
RDF record count.<br />
- A record definition field is incorrect.<br />
- An index CI format is incorrect.<br />
212 Unable to split index; increase index CI size.<br />
236 Validity check error for SHAREOPTIONS 3 or 4.<br />
245 A severe error was detected by the compression<br />
management services (CMS) during compression<br />
processing.<br />
246 A severe error was detected by the compression<br />
management services (CMS) during<br />
decompression processing.<br />
250 A valid dictionary token does not exist for the<br />
compressed data set. The data record cannot be<br />
decompressed.<br />
254 I/O activity on the data set was not quiesced before<br />
the data set was closed.<br />
► IDC3350I synad[SYNAD]message[from <strong>VSAM</strong>]<br />
Explanation: An I/O error occurred for a <strong>VSAM</strong> data set. The message text,<br />
format, and explanation of <strong>VSAM</strong> I/O errors are provided in DFSMS/MVS<br />
Macro Instructions for Data Sets.<br />
► IEC070I rc[(sfi)]- ccc,jjj,sss,ddname, dev,ser,xxx,dsname,cat<br />
Explanation: An error occurred during EOV (end-of-volume) processing for a<br />
<strong>VSAM</strong> data set. In the message text:<br />
rc Reason code. This field indicates the reason for the<br />
error. The reason codes, their meanings, and the<br />
corresponding system action and required responses<br />
are listed under message IEC161I.<br />
sfi Subfunction information (error information returned by<br />
another subsystem or component). This field appears<br />
Appendix B. Miscellaneous performance items 419
420 <strong>VSAM</strong> <strong>Demystified</strong><br />
only for certain return codes, and its format is shown<br />
with those codes to which it applies.<br />
ccc Problem Determination (PDF) Function code. The<br />
PDF code is for use by IBM if further problem<br />
determination is required. If the PDF code has<br />
meaning for the user, it will be documented with the<br />
corresponding Reason Code (rc).<br />
IEC070I RC32 , RC202 , RC8 , RC18 , RC24 , RC104 , RC203 MSGIEA000I<br />
IOS000I CMD REJ, COMMAND REJECT<br />
ADR970E HSM MISSING CI within SEQUENCE SET TRACK TRACKS TRK TRKS TRKS=0<br />
TRACKS=0 EXTENT<br />
IDCAMS EXAMINE messages<br />
The most frequent error messages issued by EXAMINE command are:<br />
IDC01714I ERROR LOCATED at OFFSET xxx<br />
IDC01720I INDEX CONTROL INTERVAL DISPLAY at RBA xxx FOLLOWS<br />
IDC11703I DUPLICATE KEYS in INDEX<br />
IDC11704I INDEX KEYS are NOT in SEQUENCE<br />
IDC11705I INDEX RECORD CONTAINS DUPLICATE INDEX POINTERS<br />
IDC11707I DUPLICATE INDEX POINTERS FOUND in SEQUENCE SET<br />
IDC11711I INDEX CONTROL INTERVAL COUNT ERROR<br />
IDC11715I INDEX HIGH-USED RBA is NOT a MULTIPLE of CI SIZE IDC11724I DATA<br />
COMPONENT CA NOT KNOWN to SEQUENCE SET IDC11725I SEQUENCE SET RBA<br />
INCONSISTENT with <strong>VSAM</strong>- MAINTAINED RBA<br />
IDC11727I INDEX HIGH-USED RBA GREATER THAN HIGH-ALLOCATED<br />
IDC11728I DATA FOUND in EMPTY CI<br />
IDC11733I DATA COMPONENT KEY SEQUENCE ERROR MSGIDC11758I SOFTWARE EOF FOUND<br />
in INDEX CI<br />
IDC11763I RBA of INDEX CI GREATER THAN HIGH-USED RBA IDC11771I INVALID RBA<br />
GENERATED<br />
IDC11772I HORIZONTAL POINTER CHAIN LOOP
Appendix C. Catalog performance<br />
C<br />
In this appendix we discuss various aspects of catalog performance:<br />
► Catalog performance<br />
► Catalog CPU consumption<br />
► Hints and tools to analyse performance problems related with catalogs.<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 421
Performance<br />
422 <strong>VSAM</strong> <strong>Demystified</strong><br />
As the number of systems sharing resources grow in today's parallel sysplex<br />
environment, contention for resources can increase resulting in slower response<br />
times or reduced throughput. One of the resources that could have increased<br />
contention is a catalog. Elongation of catalog requests has the potential to not<br />
only effect the performance of work within the system performing the request, but<br />
can effect other systems in the sysplex as well.<br />
There have been performance enhancements made to the catalog sharing<br />
protocol and to the component that manages these requests, Global Resource<br />
Serialization (GRS). These should be investigated if they have not already been<br />
implemented as they were designed for environments where there are many<br />
systems sharing resources.<br />
Enhanced Catalog Sharing<br />
DFSMS/MVS V1R5 introduced Enhanced Catalog Sharing (ECS) which offered<br />
an alternative to the VVDS mode of sharing that was introduced in DFP V3. If<br />
catalog sharing is done in VVDS mode, information is read from the VVDS on the<br />
volume where the catalog is allocated to see if the catalog has been changed by<br />
another system since the last time it was accessed by the system wanting to<br />
access the catalog. This requires multiple ENQs and I/O. With ECS, the VVDS is<br />
moved into a coupling facility reducing the serialization and I/O requirements that<br />
VVDS mode has.<br />
GRS configuration<br />
GRS Star configuration was introduced in OS/390 V1R2 and is an excellent<br />
alternative to GRS Ring configuration.<br />
In a GRS Ring configuration, the sharing systems communicate with each other<br />
via channel-to-channel connections or use XCF. The primary means for passing<br />
information is the ring system authority message (RSA-message). The<br />
RSA-message contains the information each system needs to protect the<br />
integrity of resources. The RSA-message passes from one system in the ring to<br />
another. No system can grant a request for a global resource until the other<br />
systems in the ring know about the request. With this architecture, ENQ delay<br />
time will increase every time a new system is added.<br />
The introduction of GRS Star Topology provides an environment where additional<br />
systems can be introduced into a parallel sysplex with minimal impact to
esource serialization performance. GRS Star utilizes the coupling facility in a<br />
parallel sysplex and uses it as the hub of the star. Thus, rather than passing the<br />
RSA-message around the ring to all of the systems before a serialization request<br />
is granted, serialization information is stored in a central location (the coupling<br />
facility). This eliminates the overhead of communicating with all of the systems<br />
that used to make up the Ring.<br />
Diagnosing prolonged catalog ENQ times<br />
When analyzing prolonged catalog ENQ times, verify:<br />
► LPAR definition<br />
► GRS configuration<br />
► Catalog workload<br />
► I/O response time and workload<br />
Since elongation of catalog requests could be the result of increased workload,<br />
historical data is required to determine if workload has actually increased. SMF<br />
records 70-79 and F CATALOG,REPORT,PERFORMANCE command output can provide<br />
information concerning workload trends and system utilization.<br />
Prior to any diagnosis, the following tasks should be performed to gather the data<br />
that will be required for diagnosing a perceived catalog performance problem:<br />
► Document LPAR configuration: This can be obtained from the RMF Partition<br />
Data Report.<br />
► RMF records 70-79: Insure that SMFPRMxxXnn in PARMLIB includes SMF<br />
records 70-79. Include type 79 subtype (7) for SENQ reports. Refer to z/OS<br />
MVS System Management Facitilies (SMF), SA22-7630.<br />
► Set up and start RMF reporting. Refer to the RMF User's Guide, SC33-7990<br />
for setting up RMF Post Processor, Monitor II, and Monitor III sessions.<br />
Specify ENQ(DETAIL) to report job names owning the resource, have the<br />
longest period of contention, and who are waiting for a resource.<br />
► Insure that the dispatching priority for CAS and GRS has been allowed to<br />
default.<br />
► If GRS is in ring mode:<br />
– Insure that SYSIGGV2 is converted and SYSZVVDS is not converted.<br />
– Set RESMIL to one.<br />
– Run GENQRESP found in SYS1.SAMPLIB(ISGNQRSP) to determine<br />
base response time for a GRS ENQ/DEQ request.<br />
Appendix C. Catalog performance 423
424 <strong>VSAM</strong> <strong>Demystified</strong><br />
► Implement ENQ/RESERVE/DEQ Monitor described in chapter 3 of the z/OS<br />
MVS Planning: Global Resource, SA22-7600 manual.<br />
► For catalog, periodically issue the following series of commands (possibly at<br />
the beginning of each shift):<br />
– F CATALOG,REPORT to display CAS specifications.<br />
– F CATALOG,REPORT,CACHE to display catalog cache hits.<br />
– F CATALOG,LIST to display waits, etc.<br />
– F CATALOG,REPORT,PERFORMANCE to record number of entries into catalog,<br />
number of ENQs, etc.<br />
– F CATALOG,REPORT,PERFORMANCE(RESET) to reset counters.<br />
Catalog LOCATE Flow<br />
If you suspect that catalog contention is causing bad system performance, an<br />
understanding of how a catalog request is processed and the components<br />
involved is needed.<br />
The scenarios described below assume VVDS mode sharing and a GRS Ring<br />
environment, although GRS Star could be in use. Example C-1 is the output from<br />
a GTF trace during a catalog LOCATE request:<br />
Example: C-1 Flow of a Catalog LOCATE request<br />
SVC 26<br />
SVC 56 SYSZTIOT<br />
SVC 48 SYSZTIOT<br />
SVC 56 SYSIGGV2 CATALOG.MVSICFM.VMASTER<br />
SVC 56 SYSZVVDS CATALOG.MVSICFM.VMASTER<br />
SVC 56 SYSZVVDS VOLA<br />
SSCH 72C6<br />
IO 72C6<br />
SVC 48 SYSZVVDS VOLA<br />
SVC 48 SYSZVVDS CATALOG.MVSICFM.VMASTERSVC 48 SYSIGGV2 CATALOG.MVSICFM.VMASTER<br />
SVC 56 SYSZPCCB PCCB<br />
SVC 48 SYSZPCCB PCCB<br />
SVC 56 SYSIGGV2 CAT1.UCAT<br />
SVC 56 SYSZVVDS CAT1.UCAT<br />
SVC 56 SYSZVVDS VOLB<br />
SSCH 7526<br />
IO 7526<br />
SVC 48 SYSZVVDS VOLB<br />
SVC 48 SYSZVVDS CAT1.UCAT<br />
SVC 48 SYSIGGV2 CAT1.UCAT
LPAR considerations<br />
The trace entries listed above are:<br />
► SVC 26: LOCATE<br />
► SVC56: ENQ<br />
► SVC48: DEQ<br />
► SSCH: Start subchannel<br />
► IO: I/O to the device<br />
The trace shows the resources being serialized and when I/O is performed to<br />
obtain the requested catalog entry. The number of Locates issued and the length<br />
of time it takes to process ENQ requests are the primary factors that determine<br />
how long it will take to return a catalog request.<br />
When there are systems in the parallel sysplex that are running in LPAR mode<br />
and there are multiple partitions in one CEC competing for resources, the LPAR<br />
definitions should be examined. The reason for this is that before CAS or GRS<br />
can do any work, they have to be dispatched in their z/OS or OS/390 image and<br />
the partition they are running in has to be dispatched to a physical processor. To<br />
insure that the partitions are given enough access to the physical processors:<br />
► Check logical CP configuration<br />
– Number of CPs available to partition's operating system<br />
– Operating system dispatches work to a logical processor<br />
– LPAR associates a physical processor to a logical processor to execute<br />
work<br />
► Weight and capping:<br />
– Weight specifies the amount of capacity guaranteed to partition at time of<br />
high CPU utilization<br />
– Capping specifies the amount of capacity that the partition is not allowed<br />
to exceed even if their are processor resources available<br />
– Number of logical CPUs and weight are static parameters entered on<br />
LPAR definition panels<br />
► Review RMF CPU and Partition reports for partition performance. The RMF<br />
Partition Data Report can be used to gather information concerning LPAR<br />
A situation which could cause perceived bad performance is an LPAR<br />
environment referred to as having 'short' engines. For example, consider you<br />
have a CEC that has 4 physical CPs, each having a capacity of 25 MIPs:<br />
Appendix C. Catalog performance 425
GRS environment<br />
426 <strong>VSAM</strong> <strong>Demystified</strong><br />
► There are 2 partitions defined each with 3 logical CPs sharing the 4 physical<br />
CPs.<br />
– Partition 1 has a weight of 75 and<br />
– Partition 2 has been defined with a weight of 25 (the weight of the partition<br />
is less than the total MIPs of the logical processors assigned to it).<br />
Assume that this a period of time where there is high CPU activity for both<br />
partitions.<br />
– Partition 2 is dispatched and GRS is dispatched to one of the physical<br />
CPs.<br />
– Partition 2 reaches its weight limit and partition 1 requires a CP.<br />
– The physical CP that had been assigned to partition 2 and had GRS<br />
dispatched is taken away from partition 2 and assigned to partition 1.<br />
The z/OS or OS/390 image that is running in partition 2 is not aware that the<br />
physical processor has been taken away from it and the work GRS was to<br />
perform has to wait.<br />
The work GRS was to perform could be a serialization request from another<br />
system that was to be passed onto another system. This serialization request<br />
isl not granted until the GRS in partition 2 is once again assigned a physical<br />
processor. This impacts the length of time it takes for a request to be granted<br />
and if it is a serialization request for a catalog or VVDS, could elongate the<br />
elapsed time of a LOCATE request.<br />
Catalog requests could be prolonged due to a poorly tuned GRS configuration or<br />
application contention for the resource. General tuning information for GRS ring<br />
and star configurations can be found in the chapter 10 of z/OS MVS Planning:<br />
Global Resource, SA22-7600 manual. The following information are excerpts<br />
taken from the manual. For more detail and complete information, you should<br />
refer to z/OS MVS Planning: Global Resource, SA22-7600.<br />
The first step in determining what actions to take is to discriminate between a<br />
problem with the global resource serialization complex and the applications it<br />
serves. There are several kinds of problems that can occur which will affect<br />
global resource serialization processing:<br />
1. Tuning:<br />
A poorly tuned system can elongate global resource serialization requests<br />
(ENQ and DEQ). An example of a poorly tuned system could be<br />
a. In a GRS Ring complex: Where some of the systems have too high a<br />
RESMIL value.<br />
b. In a GRS Star complex: Where the lock structure is too small, causing<br />
excessive false contention in the lock structure.
Tuning the complex will alleviate these problems.<br />
2. Intersystem communication breakdown:<br />
Global resource serialization relies on inter-system communication, through<br />
XCF communication facilities, which can be either CTCs or coupling facility<br />
signaling structures. Communication failures or delays may cause global<br />
resource serialization to take recovery actions which can delay and/or<br />
elongate ENQ and DEQ request processing.<br />
3. Coupling facility availability:<br />
The loss of a coupling facility may cause problems with a global resource<br />
serialization ring. In star mode, if the ISGLOCK structure fails or the<br />
containing coupling facility is lost, the systems in the sysplex cooperate to<br />
rebuild the structure.<br />
4. Resource allocation:<br />
Even if your global resource serialization complex is well tuned, a combination<br />
of applications, system utilities, and online users can impede workload<br />
progress due to the use of resources. For example, a long running job or<br />
utility can hold data sets exclusively, effectively blocking other jobs and users<br />
from proceeding. In more extreme cases, it is possible that a set of requests<br />
can cause a deadlock for resource requests by causing a situation where a<br />
set of users requires resources held by other users. This situation can only<br />
be remedied by breaking the deadlock, usually by canceling one or more of<br />
the jobs in the deadlock.<br />
To determine what the GRS configuration or environment is, issue D GRS,ALL. It<br />
displays:<br />
► System information<br />
► CTC link information<br />
► Resource contention information<br />
► RNL change information<br />
► The contents of all the RNLs<br />
A subset of the D GRS,ALL command can be used to determine if the GRS<br />
complex is operating normally. D GRS,SYSTEM displays:<br />
► System name of each system in the GRS complex<br />
► The state of each system in the GRS star complex<br />
– Connecting<br />
– Connected<br />
– Rebuilding<br />
► The state of each system in the GRS ring complex<br />
– Active<br />
Appendix C. Catalog performance 427
Catalog contention<br />
428 <strong>VSAM</strong> <strong>Demystified</strong><br />
– Inactive<br />
– Quiesced<br />
– Joining<br />
– Restarting<br />
– Migrating<br />
► The communication status of each system in the GRS complex<br />
– For a ring complex:<br />
Whether or not there is a functioning CTC link between this system and<br />
the system name whose information is being displayed<br />
When using XCF signaling, the XCF paths being used<br />
– For a star complex:<br />
The coupling facility structure name for the GRS lock structure<br />
In aGRS Ring configuration, if the GRS complex is running without disruption,<br />
slowdowns are usually caused by an improperly tuned ring. Delays of the<br />
RSA message can become pronounced on larger complexes, delaying the<br />
initiation of new workload. To speed up the ring, the installation can take one,<br />
two, or all of the following actions:<br />
– Speed up the RSA: Speed of the RSA message is dependent upon the<br />
RESMIL value. Try using a RESMIL of 1 or 2 on all of the systems<br />
– Use ring acceleration:<br />
Reduces the number of systems that must see an ENQ before the issuing<br />
system may grant ownership of a resource. There are possible integrity<br />
concerns but the opportunity for such failures is small. Specifying<br />
ACCELSYS(2) can reduce the overall response time for an ENQ/DEQ<br />
request<br />
– Use GRS Star configuration: Star configuration outperforms any ring<br />
complex by orders of magnitude.<br />
There is more information in the z/OS MVS Planning: Global Resource,<br />
SA22-7600 manual concerning:<br />
► Ring disruption recovery<br />
► GRS ring rebuild<br />
► XCF/XES connectivity and performance<br />
► ISGLOCK structure request processing<br />
If system performance appears to be bad, RMF is good place to start with your<br />
investigation. From the ISPF TSO command shell (option 6), enter the RMF
command. This command presents you a screen with the various RMF reporting<br />
options, as shown in In Figure C-1.<br />
RMF - Performance Management z/OS V1R2 RMF<br />
Selection ===><br />
Enter selection number or command on selection line.<br />
1 Postprocessor Postprocessor reports for Monitor I, II, and III (PP)<br />
2 Monitor II Snapshot reporting with Monitor II (M2)<br />
3 Monitor III Interactive performance analysis with Monitor III (M3)<br />
U USER User-written applications (add your own ...) (US)<br />
R RMFPP Performance analysis with the Spreadsheet Reporter<br />
P RMF PM RMF PM Java Edition<br />
N News What's new in z/OS V1R2 RMF<br />
Figure C-1 RMF Monitor panel<br />
T TUTORIAL X EXIT<br />
RMF Home Page: http://www.ibm.com/servers/eserver/zseries/rmf/<br />
5694-A01 (C) Copyright IBM Corp. 1994, 2001. All Rights Reserved<br />
Licensed Materials - Property of IBM<br />
If the application work is running slower than it was before, it could be caused by<br />
delays. These delays could be caused by a unit of work waiting for requests to be<br />
processed by DFSMShsm, JES, Operator Reply, GRS, and several other system<br />
functions. From the RMF Monitor Panel, select option 3, for Monitor III. Then<br />
Monitor III options are shown in Figure C-2.<br />
Appendix C. Catalog performance 429
430 <strong>VSAM</strong> <strong>Demystified</strong><br />
RMF Monitor III Primary Menu z/OS V1R2 RMF<br />
Selection ===><br />
Enter selection number or command on selection line.<br />
S SYSPLEX Sysplex reports and Data Index (SP)<br />
1 OVERVIEW WFEX, SYSINFO, and Detail reports (OV)<br />
2 JOBS All information about job delays (JS)<br />
3 RESOURCE Processor, Device, Enqueue, and Storage (RS)<br />
4 SUBS Subsystem information for HSM, JES, and XCF (SUB)<br />
U USER User-written reports (add your own ...) (US)<br />
O OPTIONS T TUTORIAL X EXIT<br />
5694-A01 (C) Copyright IBM Corp. 1986, 2001. All Rights Reserved<br />
Licensed Materials - Property of IBM<br />
Figure C-2 RMF Monitor III Primary Menu<br />
If a particular job is perceived to be running slowly, you can use the option 2 to<br />
display information concerning what could be causing a job to be delayed. If it is<br />
because of catalog ENQ contention, it will be shown RMF Job Report Selection<br />
report. Selecting option 2 from the RMF Monitor III Primary Menu displays the<br />
panel shown in Figure C-3.
Selection ===><br />
RMF Job Report Selection Menu<br />
Enter selection number or command and jobname for desired job report.<br />
Jobname ===> MYJOB___<br />
1 DEVJ Delay caused by devices (DVJ)<br />
1A DSNJ .. Data set level (DSJ)<br />
2 ENQJ Delay caused by ENQ (EJ)<br />
3 HSMJ Delay caused by HSM (HJ)<br />
4 JESJ Delay caused by JES (JJ)<br />
5 JOB Delay caused by primary reason (DELAYJ)<br />
6 MNTJ Delay caused by volume mount (MTJ)<br />
7 MSGJ Delay caused by operator reply (MSJ)<br />
8 PROCJ Delay caused by processor (PJ)<br />
9 QSCJ Delay caused by QUIESCE via RESET command (QJ)<br />
10 STORJ Delay caused by storage (SJ)<br />
11 XCFJ Delay caused by XCF (XJ)<br />
Figure C-3 RMF III Job Selection Menu<br />
Then select option 2. This will tell you if ENQs are causing the delays for this<br />
particular job.<br />
If heavy contention for a catalog resource is suspected after using RMF, you<br />
could use D GRS commands to further investigate. You can issue commands to<br />
see if there is contention and if contention exists, which job is blocking other<br />
requesters for a particular resource.<br />
By itself, resource contention is not a sign of a problem. However, contention held<br />
for a long period of time among the same resources and requesters may be an<br />
indication of a problem.<br />
GRS provides diagnostic commands to help you determine the source of<br />
contention:<br />
► DISPLAY GRS,CONTENTION<br />
Provides an alphabetized list of all visible ENQ resources that are in<br />
contention. Each resource is reported with the owners and waiters of the<br />
resource.<br />
The DISPLAY GRS,CONTENTION command only reports contention for<br />
SCOPE=SYSTEM resources that are allocated on the system where the<br />
command executed. It does not report contention for SCOPE=SYSTEM<br />
resources on other systems in the Complex.<br />
Appendix C. Catalog performance 431
432 <strong>VSAM</strong> <strong>Demystified</strong><br />
► DISPLAY GRS,ANALYZE,WAITER<br />
Provides a list of requesters that have been waiting the longest for ENQ<br />
resources. Each waiter is reported with:<br />
– The resource name and scope.<br />
– The count of waiters and blockers of the resource.<br />
– The top blocker of the resource.<br />
Each waiter is reported with its wait time, system resource that it was ENQed<br />
on, and the type of access (shared or exclusive) requested. The counts of<br />
waiters and blockers are explicitly returned only when the count is greater<br />
than one.<br />
► DISPLAY GRS,ANALYZE,BLOCKER<br />
Provides a list of the requesters that have been blocking ENQ resources for<br />
the longest time. Each blocker is reported with:<br />
– Resource name and scope.<br />
– The count of waiters and blockers of the resource.<br />
The block time, system the blocker ENQed from, jobname, and the type of<br />
access requested are also reported.<br />
► DISPLAY GRS,ANALYZE,DEPENDENCY<br />
Provides resource allocation dependency analysis:<br />
a. Starting with each of the longest ENQ waiters, an analysis is performed,<br />
iteratively chaining from waiter to top blocker until either a request that is<br />
not waiting is found, or a resource allocation deadlock is detected.<br />
b. Starting with the top blockers of a specified resource, an analysis is<br />
performed, iteratively chaining from waiter to top blocker until either a<br />
request that is not waiting is found, or a resource allocation deadlock is<br />
detected.<br />
The various forms of the DISPLAY GRS,ANALYZE command are available on<br />
OS/390 Release 3 and higher with APAR OW38979 installed on the system.<br />
The z/OS MVS Planning: Global Resource, SA22-7600manual, in chapter 10,<br />
demonstrates how these command can be used to diagnosis suspected<br />
contention problems.<br />
Once it has been determined that catalog contention exists, the next step is to<br />
determine whether it's due to the length of time it takes to satisfy a catalog<br />
request, an increase in CAS workload, or a combination of both. The use of GRS<br />
ENQ/RESERVE/DEQ Monitor and F CATALOG,REPORT PERFORMANCE commands<br />
are useful tools for determining the length of ENQs and how many are being<br />
issued.
To implement the ENQ/RESERVE/DEQ Monitor, refer to chapter 2 of the z/OS<br />
MVS Planning: Global Resource, SA22-7600manual. Once invoked, the panel<br />
shown in Figure C-4 is displayed:<br />
Select an option:<br />
ENQ/DEQ Monitor - Main Menu<br />
__ 1. MAJOR Names Date & Time : 2001.341 11:56<br />
2. Resource Name List Monitor started at : 2001.341 11:55<br />
3. Volume List Elapsed seconds : 22<br />
4. Filter List SMF System ID : WSCM<br />
------------------------------------------------------------------------------<br />
GRS Ring -> From: To: This: WSCSYSA NUMSYS: 1<br />
------------------------------------------------------------------------------<br />
Time of Delay High. . : 2001.341 11:55<br />
Global Requests . . . : 132 Enqueue Delay Hi - Low: 1 1<br />
Local Requests . . . : 174 Enqueue Delay msec: 1<br />
Major Names . . . . . : 25 ACCELSYS. . . . . . . : 0<br />
Minor Names . . . . . : 63 RESMIL . . . . . msec: 0<br />
Volumes . . . . . . . : 19 Data Space Used .bytes: 12529 0 %<br />
Number of Events. . . : 633 Active Filter. . . . .: 08<br />
Lost Events . . . . . : 0 Events Rate . . . . .: 263<br />
Command ===> __________________________________________________________________<br />
Figure C-4 ENQ / DEQ Main Menu Panel<br />
The Main Menu panel summarizes the active GRS options and activity. Selecting<br />
option 1, The Monitor shows the ENQ activities listed by major names, RNL<br />
action and the number of global and local ENQs if global resource serialization is<br />
active, as shown in Figure C-5.<br />
Appendix C. Catalog performance 433
434 <strong>VSAM</strong> <strong>Demystified</strong><br />
ENQ/DEQ Monitor - Major Name List Row 1 to 14 of 46<br />
Enter S to select a Major Name for details .<br />
L major on command line to locate a Major. Elapsed seconds: 732<br />
Sel. ---------- ----- ---- ----- ------- -Average- -Reserved-<br />
Field Major Name Scope Exit RNL Counter msec seconds<br />
_ ARCENQG SYSS 27<br />
_ ARCENQL SYS 1<br />
_ ARCGPA RES FORCE 281 34 9<br />
_ ARCGPA SYS 7<br />
_ BLXDASDS SYS 165<br />
_ CHANGEQU SYSS 74<br />
_ DVG221 SYS 84<br />
_ DVG221QH SYS 42<br />
_ IGDCDSXS RES FORCE 49 49 2<br />
_ SIBIXFP SYS 21<br />
_ SPFEDIT RES FORCE 25 460 10<br />
_ SPFEDIT SYSS 60<br />
_ SYSDSN SYS 331<br />
_ SYSIEFSD SYS 1292<br />
Command ===> L SYSIGGV2<br />
Figure C-5 ENQ / DEQ Monitor: Major Name List Option<br />
Once the Major Name List panel is displayed, you can use L SYSIGGV2 to find if<br />
there are any ENQs for catalog resources. Select the Major name SYSIGGV2,<br />
see Figure C-6.<br />
ENQ/DEQ Monitor - Major Name List Row 16 to 29 of 46<br />
Enter S to select a Major Name for details .<br />
L major on command line to locate a Major. Elapsed seconds: 732<br />
Sel. ---------- ----- ---- ----- ------- -Average- -Reserved-<br />
Field Major Name Scope Exit RNL Counter msec seconds<br />
s SYSIGGV2 RES FORCE 1362 8 10<br />
_ SYSIKJBC SYS 28<br />
_ SYSIKJPL SYS 431<br />
_ SYS<strong>VSAM</strong> SYSS 14<br />
_ SYSVTOC RES FORCE 96 27 2<br />
_ SYSZ#SSI SYS NO 5<br />
_ SYSZALCF SYS 3<br />
Figure C-6 ENQ / DEQ Monitor: locating a major name
After selecting major name SYSIGGV2 a minor name list is displayed, as shown<br />
in Figure C-7.<br />
ENQ/DEQ Monitor - Minor Name List Row 1 to 8 of 24<br />
Minor Name list for: Major Name : SYSIGGV2<br />
RNL . . . . : FORCED<br />
Scope . . . : RESERVE<br />
Reserved sec: 10 Avg msec: 8<br />
Enter S to select a Minor Name for Jobnames .<br />
L min. on command line to locate a Minor. Elapsed seconds: 732<br />
Interval<br />
- --Rate- ----- ------ ------------------------ ------------ Time ------------<br />
S min. Count Volume Minor name (max 24 char) Avg ms Min ms Max ms Tot sec<br />
s 0 4 DB2710 CATALOG.DB2710 6 6 8 0<br />
_ 0 3 CICSTS ICFCAT.CICSTS 24 6 61 0<br />
_ 5 56 SMSN01 ICFCAT.IBMBOOKS 6 5 30 0<br />
_ 164 1 IMS610 ICFCAT.IMS610 62 62 62 0<br />
_ 1 29 SMS019 ICFCAT.SMSUCAT1 6 6 8 0<br />
_ 22 663 SMS011 ICFCAT.SMSUCAT2 8 6 147 5<br />
_ 10 257 SMS015 ICFCAT.SMSUCAT3 10 6 121 2<br />
Figure C-7 ENQ / DEQ Monitor: Minor Name List<br />
Selecting a minor name will display the job and program names with an<br />
indication of exclusive or shared use:<br />
ENQ/DEQ Monitor - Jobname List Row 1 to 1 of 1<br />
List for Major Name : SYSIGGV2<br />
Minor Name : CATALOG.DB2710<br />
Minor Length: 20<br />
-------- -------- ---------- -------- --- ----------<br />
Job_name User_ID Enqs x Job Pgm_name E/S Enqs x PGM<br />
CATALOG * 6 IGGPACDV S 6<br />
******************************* Bottom of data ********************************<br />
Figure C-8 ENQ / DEQ Monitor: Jobname List<br />
From these displays, you can find which catalogs have high activity and how long<br />
it takes to process ENQ serialization requests for these catalogs.<br />
In addition to RMF and the ENQ/RESERVE/DEQ Monitor, the F<br />
CATALOG,REPORT,PERFORMANCE command can provide data concerning the<br />
number of entries into the catalog address space, the number of serialization<br />
Appendix C. Catalog performance 435
436 <strong>VSAM</strong> <strong>Demystified</strong><br />
requests CAS has issued, and how long these requests take before being<br />
granted. Figure C-9 shows part of the output of the command:<br />
F CATALOG,REPORT,PERFORMANCE<br />
IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE<br />
IEC359I CATALOG PERFORMANCE REPORT 913<br />
*CAS***************************************************<br />
* -----CATALOG EVENT---- --COUNT-- ---AVERAGE--- *<br />
* Entries to Catalog 80,789 17.716 MSEC *<br />
* BCS ENQ Shr Sys 105,214 0.223 MSEC *<br />
* BCS ENQ Excl Sys 1,673 0.455 MSEC *<br />
* BCS DEQ 125,748 0.155 MSEC *<br />
* VVDS RESERVE CI 5,199 1.302 MSEC *<br />
* VVDS DEQ CI 5,199 0.192 MSEC *<br />
* VVDS RESERVE Shr 135,295 0.188 MSEC *<br />
* VVDS RESERVE Excl 392 0.217 MSEC *<br />
* VVDS DEQ 135,687 0.150 MSEC *<br />
Figure C-9 F CATALOG,REPORT, PERFORMANCE output<br />
There is more information returned from the command but the above data is what<br />
is pertinent to diagnosing catalog contention. This report tells you how many<br />
entries have been made into CAS, how many exclusive and shared ENQs have<br />
been issued to catalogs and VVDSs since the counters were last reset with F<br />
CATALOG,REPORT,PERFORMANCE(RESET). If the command has been issued over a<br />
period of time, the report reveals workload and ENQ response time trends.<br />
Catalog Contention Summary<br />
After reviewing the RMF reports, output of the D GRS and the F CATALOG<br />
commands, it should be possible to determine if ENQ response times and/or<br />
CAS workload have increased. If efforts to tune GRS do not result in lower or<br />
acceptable ENQ response times, or if the GRS ring is operating as efficiently as<br />
possible and the elongation is due to increased CAS activity for a particular<br />
catalog, the only option available is to investigate the possibility of splitting the<br />
catalog in question.<br />
You use automation to issue F CATALOG commands in interval time, saving the<br />
output in data sets (using Generation Data Group), and then analyze<br />
the outputs. To save the command output in a data set you can use<br />
two ways:<br />
1. SDSF batch, see sample in Figure C-10. Refer to z/OS SDSF Operation an<br />
Customization, SA22-7670 for more information about SDSF batch.
SDSF EXEC PGM=SDSF,PARM='++60,132'<br />
//ISFOUT DD SYSOUT=A<br />
//OUTPUT DD DSN=...<br />
//ISFIN DD *<br />
ULOG<br />
/F CATALOG,REPORT,PERFORMANCE<br />
REFRESH<br />
REFRESH<br />
REFRESH<br />
REFRESH<br />
REFRESH<br />
PRINT FILE OUTPUT<br />
PRINT<br />
PRINT CLOSE<br />
Figure C-10 F CATALOG Command in SDSF batch<br />
2. For REXX, see samples in Example C-2, Example C-4 on page 440,<br />
Example C-5 on page 440, and the JCL in Example C-3 on page 439. You<br />
can customize these samples REXX and JCL and use a scheduler, like OPC,<br />
to run periodically and collect catalog performance data.<br />
Example: C-2 CATPERF REXX to issue F CATALOG command<br />
/* REXX */<br />
/* THIS IS A REXX EXEC TO ISSUE F CATALOG,REPORT,PERFORMANCE */<br />
/* COMMANDS AND WRITE THE OUTPUT TO A DATA SET */<br />
/* */<br />
/*************************************************************/<br />
'ALLOC F(OUTP) DA(REPORT.OUT) OLD'<br />
SOLD=0<br />
UNSOLD=0<br />
X=MSG("ON")<br />
/************************************************************/<br />
/* REXX */<br />
/* THIS will check CONSPROF profile and enter CONSOLE */<br />
/* mode to issue F CATALOG,REPORT commands. */<br />
/************************************************************/<br />
X=OUTTRAP('CONDIS.','*')<br />
"CONSPROF"<br />
X=OUTTRAP('OFF')<br />
IF RC > 0 THEN DO<br />
SAY "ERROR IN CONSPROF."<br />
EXIT<br />
END<br />
PARSE VAR CONDIS.1 W1 W2 W3 W4 W5<br />
IF SUBSTR(W1,1,3) = 'IKJ' THEN<br />
DO<br />
Appendix C. Catalog performance 437
438 <strong>VSAM</strong> <strong>Demystified</strong><br />
IF RIGHT(W2,4)="YES)" THEN<br />
DO<br />
ADDRESS "TSO" "CONSPROF SOLDISPLAY(NO)"<br />
SOLD=1<br />
END<br />
IF RIGHT(W4,4)="YES)" THEN<br />
DO<br />
ADDRESS "TSO" "CONSPROF UNSOLDISPLAY(NO)"<br />
UNSOLD=1<br />
END<br />
END<br />
IF SUBSTR(W1,1,3) 'IKJ' THEN<br />
DO<br />
IF RIGHT(W2,4)="YES)" THEN<br />
DO<br />
ADDRESS "TSO" "CONSPROF SOLDISPLAY(NO)"<br />
SOLD=1<br />
END<br />
IF RIGHT(W4,4)="YES)" THEN<br />
DO<br />
ADDRESS "TSO" "CONSPROF UNSOLDISPLAY(NO)"<br />
UNSOLD=1<br />
END<br />
END<br />
X=MSG('off')<br />
z=0<br />
"CONSOLE ACTIVATE"<br />
ADDRESS CONSOLE "F CATALOG,REPORT,PERFORMANCE"<br />
DO WHILE rc = 0<br />
rc='GETMSG'(MVSCMD.,,,,5)<br />
IF rc = 0 THEN DO<br />
I = 1<br />
DO I = 1 TO MVSCMD.0<br />
IF z = 0 THEN<br />
DO<br />
date = mvscmd.mdbgdstp<br />
time = mvscmd.mdbgtimh<br />
QUEUE "Date: "||date||" Time: "||time<br />
END<br />
QUEUE mvscmd.i<br />
z = 1<br />
END<br />
END<br />
END<br />
DO i = 1 to queued()<br />
ADDRESS MVS 'EXECIO 1 DISKW OUTP'<br />
END<br />
ADDRESS MVS 'EXECIO 0 DISKW OUTP (FINIS'<br />
X=MSG('ON')
'FREE FI(OUTP)'<br />
"CONSOLE DEACTIVATE"<br />
IF SOLD=1 THEN ADDRESS "TSO" "CONSPROF SOLDISPLAY(YES)"<br />
IF UNSOLD=1 THEN ADDRESS "TSO" "CONSPROF UNSOLDISPLAY(YES)"<br />
EXIT<br />
Example: C-3 JCL to run REXX in batch and copy the output to a GDG<br />
//jobname JOB jobcard info<br />
//TSOCMD1 EXEC PGM=IKJEFT01,REGION=4096K<br />
//SYSTSPRT DD SYSOUT=*<br />
//SYSTSIN DD *<br />
EXEC 'userid.CATREP.PERF(CATDATE)'<br />
/*<br />
//IEBGEN1 EXEC PGM=IEBGENER,COND=(1,NE)<br />
//SYSPRINT DD SYSOUT=X<br />
//SYSIN DD DUMMY<br />
//SYSUT1 DD DSN=userid.REPORT.OUT,DISP=SHR<br />
//SYSUT2 DD DSN=userid.CATREP.OUT(+1),DISP=(NEW,CATLG),<br />
// LIKE=userid.REPORT.OUT<br />
//TSOCMD2 EXEC PGM=IKJEFT01,REGION=4096K<br />
//SYSTSPRT DD SYSOUT=*<br />
//SYSUADS DD DSN=SYS1.UADS,DISP=SHR<br />
//SYSUADN DD DSN=SYS1.UADS,DISP=SHR<br />
/*<br />
//IEBGEN1 EXEC PGM=IEBGENER,COND=(1,NE)<br />
//SYSPRINT DD SYSOUT=X<br />
//SYSIN DD DUMMY<br />
//SYSUT1 DD DSN=userid.REPORT.OUT,DISP=SHR<br />
//SYSUT2 DD DSN=userid.CATREP.OUT(+1),DISP=(NEW,CATLG),<br />
// LIKE=userid.REPORT.OUT<br />
//TSOCMD2 EXEC PGM=IKJEFT01,REGION=4096K<br />
//SYSTSPRT DD SYSOUT=*<br />
//SYSUADS DD DSN=SYS1.UADS,DISP=SHR<br />
//SYSUADN DD DSN=SYS1.UADS,DISP=SHR<br />
//SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR<br />
//SYSTSIN DD *<br />
EXEC 'userid.CATREP.PERF(CATPERF)'<br />
/*<br />
Appendix C. Catalog performance 439
440 <strong>VSAM</strong> <strong>Demystified</strong><br />
Example: C-4 CATDATE REXX<br />
/* rexx */<br />
date = date('j')<br />
'ALLOC F(OUTP) DA(REPORT.OUT) SHR'<br />
ADDRESS MVS 'EXECIO * DISKR OUTP (FINIS'<br />
DO x = 1 to queued()<br />
PARSE PULL record<br />
IF SUBSTR(record,1,4) = 'Date' THEN DO<br />
rdate = SUBSTR(record,9,5)<br />
IF rdate ¬= date THEN CODE=1<br />
END<br />
END<br />
'FREE FI(OUTP)'<br />
IF CODE = 1 THEN EXIT 1<br />
EXIT<br />
Example: C-5 CATDATE REXX<br />
/* rexx */<br />
date = date('j')<br />
'ALLOC F(OUTP) DA(REPORT.OUT) SHR'<br />
ADDRESS MVS 'EXECIO * DISKR OUTP (FINIS'<br />
DO x = 1 to queued()<br />
PARSE PULL record<br />
IF SUBSTR(record,1,4) = 'Date' THEN DO<br />
rdate = SUBSTR(record,9,5)<br />
IF rdate ¬= date THEN CODE=1<br />
END<br />
END<br />
'FREE FI(OUTP)'<br />
IF CODE = 1 THEN EXIT 1<br />
EXIT
Appendix D. Information APARs<br />
D<br />
In this appendix we list several information APARs that deal with <strong>VSAM</strong> data<br />
collection and problem determination.<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 441
II12927 - Documentation for <strong>VSAM</strong> problems<br />
442 <strong>VSAM</strong> <strong>Demystified</strong><br />
Item II12927<br />
APAR Identifier ...... II12927 Last Changed ........ 02/11/14<br />
INFO APAR TO PROVIDE GUIDELINES FOR DOCUMENTATION NEEDED BY <strong>VSAM</strong><br />
CATALOG, IDCAMS LEVEL2 TO SOLVE COMMON CATEGORIES OF PROBLEMS.<br />
Symptom ...... DD DOC Status ........... INTRAN<br />
Severity ................... 4 Date Closed .........<br />
Component .......... INFOV2LIB Duplicate of ........<br />
Reported Release ......... 001 Fixed Release ............<br />
Component Name V2 LIB INFO ITE Special Notice<br />
Current Target Date .. Flags<br />
SCP ...................<br />
Platform ............<br />
Status Detail: Not Available<br />
PE PTF List:<br />
PTF List:<br />
Parent APAR:<br />
Child APAR list:<br />
ERROR DESCRIPTION:<br />
This info apar outlines the documentation requirements for <strong>VSAM</strong>,<br />
CATALOG, RLS and IDCAMS L2 diagnosis of general problems.<br />
Specific problem scenarios may require additional documentation.<br />
This is designed to assist customers in determining what<br />
documentation to gather before reporting the problem to IBM.<br />
#############################################<br />
Questions before the documentation-gathering process:<br />
1. Did this problem just occur "out of the blue" or did<br />
something recently change in your environment, such as the<br />
installation of software or hardware maintenance?<br />
2. Did the problem occur only one time?<br />
3. Can you recreate the problem?<br />
.<br />
.<br />
The following are documentation requirements for CATALOG<br />
problems:<br />
ABENDS<br />
- SVC dump of the abend
- Syslog (at the time of the abend)<br />
.<br />
BROKEN DATA SET<br />
(Please see II08859 for more details)<br />
.<br />
- SYSLOG/JOBLOG (including all messages, JCL and commands)<br />
- EXAMINE (both ITEST and DTEST) output<br />
- LISTCAT ALL output<br />
- DIAGNOSE output<br />
.<br />
.<br />
BROKEN CATALOG<br />
- LISTCAT ENT(catname)ALL CATALOG(catname)<br />
- DIAGNOSE vvds<br />
DIAGNOSE bcs<br />
DIAGNOSE COMPARE vvds to bcs<br />
DIAGNOSE COMPARE bcs to vvds<br />
***Please see Chapter 22 of the DFSMS/MVS<br />
ACCESS METHOD SERVICES for the INTEGRATED<br />
CATALOG FACILITY for DIAGNOSE examples***<br />
- EXAMINE (both ITEST and DTEST)<br />
- any error messages from joblog<br />
.<br />
The following are documentation requirements for <strong>VSAM</strong> problems:<br />
.<br />
PERFORMANCE<br />
See II10752.<br />
- provide a clear and adequate description<br />
- what is not performing properly<br />
- what is the basis for the performance expectation<br />
- what changes appear to trigger the performance change<br />
* maintenance, release, application?<br />
- dump of CAS (and associated user ASIDs) before any<br />
recovery actions...if Catalog is involved<br />
- performance report<br />
- comparison report (what was performing in the last release)<br />
*** We will only diagnose if the problem is defect-related ***<br />
.<br />
HANG/WAIT/LOOP<br />
- dump of CAS (and associated ASIDs)...if Catalog is involved<br />
- dump from all the systems in the sysplex<br />
.<br />
The following are DOC requirements for RLS (SMS<strong>VSAM</strong>) problems:<br />
.<br />
1. To dump SMS<strong>VSAM</strong> ASIDs on all systems at the same time.<br />
.<br />
Appendix D. Information APARs 443
444 <strong>VSAM</strong> <strong>Demystified</strong><br />
DUMP COMM=(Some meaningful dump title),<br />
Rnn,JOBNAME=(SMS<strong>VSAM</strong>),CONT<br />
Rnn,SDATA=(GRSQ,RGN,ALLNUC,LPA,LSQA,CSA,PSA,SQA,SUM,SWA,TRT)<br />
Rnn,DSPNAME=('SMS<strong>VSAM</strong>',*),<br />
Rnn,REMOTE=(SYSLIST=*('SMS<strong>VSAM</strong>'),DSPNAME,SDATA),END<br />
2. This will dump SMS<strong>VSAM</strong> and XCF on the local system and dump<br />
SMS<strong>VSAM</strong> XCF w/ DSPNAME and SDATA on all the systems in the<br />
sysplex.<br />
DUMP COMM=(SMS<strong>VSAM</strong> and XCF)<br />
RXX,JOBNAME=(SMS<strong>VSAM</strong>,XCFAS),DSPNAME=('XCFAS'.*,'SMS<strong>VSAM</strong>'.*),CONT<br />
RYY,SDATA=(GRSQ,RGN,ALLNUC,LPA,LSQA,CSA,PSA,SQA,SUM,SWA,TRT), CONT<br />
R ZZ,REMOTE=(SYSLIST=(*,('XCFAS','SMS<strong>VSAM</strong>',DSPNAME,SDATA)))<br />
.<br />
To DUMP the SMS<strong>VSAM</strong> asid, SMS<strong>VSAM</strong> data spaces and CICS regions<br />
involved.<br />
.<br />
DUMP COMM=(CICS & SMS<strong>VSAM</strong> HANG)<br />
R nn,JOBNAME=(SMS<strong>VSAM</strong>, CICS1, CICS2, CICS3, ETC),<br />
R nn,DSPNAME=('SMS<strong>VSAM</strong>'.*), END<br />
R nn,SDATA=(PSA,NUC,SQA,LSQA,SUM,RGN,GRSQ,LPA,TRT,CSA),CONT<br />
R nn,REMOTE=(SYSLIST=*('SMS<strong>VSAM</strong>'),DSPNAME,SDATA),END<br />
where CICS1, CICS2, CICS3, ETC are the names of the CICS regions.<br />
.<br />
The following are documentation requirements for IDCAMS problems:<br />
.<br />
- Syslog (including all messages, JCL and commands) from the batch job that<br />
received the OPEN error<br />
- VERIFY output<br />
- LISTCAT ALL output<br />
- EXAMINE (ITEST and DTEST)<br />
- DIAGNOSE<br />
II13326 - Common problems with SHCDS<br />
Item II13326<br />
APAR Identifier ...... II13326 Last Changed ........ 02/11/04<br />
COMMON PROBLEMS FROM SHCDS DEFINITION AND USAGE. PLEASE REVIEW<br />
THIS INFO APAR IF RECEIVE ABEND0F4 RSN673F0614 673F0614.<br />
Symptom ...... IN INCORROUT Status ........... INTRAN<br />
Severity ................... 4 Date Closed .........<br />
Component .......... INFOV2LIB Duplicate of ........<br />
Reported Release ......... 001 Fixed Release ............<br />
Component Name V2 LIB INFO ITE Special Notice<br />
Current Target Date .. Flags
SCP ...................<br />
Platform ............<br />
Status Detail: Not Available<br />
PE PTF List:<br />
PTF List:<br />
Parent APAR:<br />
Child APAR list:<br />
ERROR DESCRIPTION:<br />
Due to a number of problems we've been seeing in the field<br />
from new customers, we decide to put together this informational<br />
APAR to help guide you through the process of setting up and<br />
trouble-shooting problems with SMS<strong>VSAM</strong>/RLS shared control<br />
dataset (SHCDS).<br />
.<br />
PART 1: SHCDS DEFINITION<br />
.<br />
Here is a checklist that you need to run through to make sure<br />
you have defined your SHCDS properly:<br />
1- See 14.1.6 Defining Sharing Control Data Sets in DFSMSdfp<br />
Storage Admin. Reference for details. Also see section<br />
14.1.10 Establishing Authorization for <strong>VSAM</strong> RLS in DFSMSdfp<br />
Storage Administration Reference.<br />
2- SHCDS must be a <strong>VSAM</strong> Linear data set.<br />
3- CISIZE for SHCDS must be 4096. Make sure that if you are<br />
using a Dataclass you are getting 4096.<br />
4- Shareoptions must be (3,3).<br />
5- Secondary extents are strongly recommended.<br />
6- Initial size of the SHCDS needs to be large enough.<br />
7- When defined, the SHCDS does not need to be catalogued on<br />
all systems in the sysplex. If it is cataloged, it must be in<br />
a catalog available when SMS<strong>VSAM</strong> initializes. The user<br />
may issue the command, Vary SMS,SHCDS(dsname),NEW<br />
and Vary SMS,SHCDS(dsname),NEWSPARE from any<br />
system in the sysplex, not just from the system where the<br />
SHCDS was defined and catalogued originally. SMS<strong>VSAM</strong><br />
will attempt to re-catalog the SHCDS if it cannot find the<br />
SHCDS in a catalog on that system.<br />
8- SMS<strong>VSAM</strong> must be authorized to update SYS1.DFPSHCDS.*<br />
data sets.<br />
If you protect SYS1.* data sets be sure SMS<strong>VSAM</strong> is<br />
able to access SYS1.DFPSHCDS.* for update.<br />
9- Follow the SHCDS naming convention. The SHCDS name must<br />
Appendix D. Information APARs 445
446 <strong>VSAM</strong> <strong>Demystified</strong><br />
match the volume that it resides on. That is,<br />
SYS1.DFPSHCDS.firstnam.Vvolser resides on volume volser<br />
Note: APAR OW49746 prevents addition of a SHCDS if the SHCDS is<br />
not linear or if the CISIZE is not 4096.<br />
.<br />
The SHCDS may be defined using IDCAMS. Here is an example:<br />
//*------------------------------------------------------<br />
//* ALLOCATE ON XP0301 - GUARANTEED SPACE IS SXPXXS04<br />
//*------------------------------------------------------<br />
//ALLOCLD1 EXEC PGM=IDCAMS<br />
//SYSPRINT DD SYSOUT=*<br />
//SYSIN DD *<br />
DEFINE CLUSTER (NAME(SYS1.DFPSHCDS.ACTIVE3.VXP0301) LINEAR -<br />
STORCLAS(SXPXXS04) -<br />
SHAREOPTIONS(3 3) CYL(20 20) VOLUME(XP0301) )<br />
/*<br />
.<br />
PART 2: COMMON USAGE PROBLEMS<br />
.<br />
For suspected problems with the SHCDS, look for messages<br />
starting with IGW6, such as IGW615I. Also look for messages<br />
that indicate a security problem with your SHCDS.<br />
.<br />
A- Problem: Sharing Control Data Sets are added, but when<br />
when SMS<strong>VSAM</strong> is recycled or the system is IPLed, the SHCDS<br />
are deleted during initialization.<br />
Possible solutions:<br />
1- SHCDS is not correctly defined. See "SHCDS Definition"<br />
above. Redefine SHCDS.<br />
2- SMS<strong>VSAM</strong> does not have proper access to the SHCDS.<br />
Examine the Syslog for error messages indicating problems<br />
with the SYS1.DFP. Set up access properly.<br />
B- Problem: SMS<strong>VSAM</strong> initialization is not proceeding.<br />
Use the command, D SMS,SMS<strong>VSAM</strong>. If the response indicates<br />
that SMS<strong>VSAM</strong> is in SHC_Ph2_Init:<br />
.<br />
IGW420I DISPLAY SMS,SMS<strong>VSAM</strong><br />
DISPLAY SMS,SMS<strong>VSAM</strong> - SERVER STATUS<br />
SYSNAME: SYSTEM2 UNAVAILABLE ASID: 00FC STEP: SHC_Ph2_Init<br />
.<br />
You should have received some IGW6* messages, such as<br />
IGW611A or IGW609A, prior to this point. Look for these<br />
messages in the Syslog. Issue the command, D SMS,SHCDS.<br />
Examine the "Status" column. Make sure that you have at least<br />
2 active SHCDS and 1 Spare SHCDS. A common error is to forget<br />
to add a Spare SHCDS or to add three actives instead of<br />
2 actives and a spare.
.<br />
PART 3: COMMON TASKS<br />
.<br />
You may want to swap in a new set of SHCDS, because you want to<br />
increase the size of the SHCDS or you want to change the volume<br />
where the SHCDS resides. You must use the VARY SMS,SHCDS<br />
command when making changes to the SHCDS in order for SMS<strong>VSAM</strong><br />
to know about the SHCDS. Do not delete an active or spare SHCDS<br />
even if SMS<strong>VSAM</strong> is not active. Do not move a SHCDS from one<br />
volume to another, because the SHCDS naming convention depends<br />
on the volume to match the SHCDS name.<br />
.<br />
NOTE: Do not delete and redefine an active or spare SHCDS<br />
without first deleting the SHCDS from SMS<strong>VSAM</strong> using the<br />
command - V SMS,SHCDS(shcdsname),DELETE. SMS<strong>VSAM</strong> remembers<br />
the SHCDSs from one SMS<strong>VSAM</strong> recycle to the next. You must<br />
tell SMS<strong>VSAM</strong> that the SHCDS is no longer an active or<br />
spare SHCDS.<br />
.<br />
A common error is to delete and redefine the SHCDS without<br />
deleting the SHCDS from SMS<strong>VSAM</strong> - for example, when<br />
SMS<strong>VSAM</strong> is not active. The correct way to communicate<br />
changes for the SHCDS is through the command - V SMS,SHCDS.<br />
Once you have deleted a SHCDS using the command<br />
V SMS,SHCDS(shcdsname),DELETE, you can then safely use<br />
IDCAMS DELETE and DEFINE to modify your SHCDS.<br />
.<br />
NOTE: Do not move a SHCDS from one volume to another,<br />
because the SHCDS naming convention depends on the volume<br />
to match the SHCDS name.<br />
Remember that once you've added 2 Active SHCDS and 1 Spare SHCDS<br />
you will not be allowed delete them when using the command, Vary<br />
SMS,SHCDS(dsname),delete. To make a swap, you must add the new<br />
SHCDS first and delete the old SHCDS to make sure you stay<br />
within criteria. For example, if you have:<br />
.<br />
16.40.09 SYSTEM1 d sms,shcds<br />
IGW612I 16:40:10 DISPLAY SMS,SHCDS<br />
Name Size %UTIL Status Type<br />
TOOSMALL.VXP0301 7200Kb 5% GOOD ACTIVE<br />
TOOSMALL.VXP0302 7200Kb 5% GOOD ACTIVE<br />
WRONGVOL.VXP0201 7200Kb 5% GOOD SPARE<br />
.<br />
Issue these commands:<br />
V SMS,SHCDS(JUSTRITE.VXP0301),NEW<br />
V SMS,SHCDS(JUSTRITE.VXP0302),NEW<br />
V SMS,SHCDS(RIGHTVOL.VXP0202),NEWSPARE<br />
Appendix D. Information APARs 447
448 <strong>VSAM</strong> <strong>Demystified</strong><br />
.<br />
Now you have:<br />
SYSTEM1 d sms,shcds<br />
IGW612I 16:45:49 DISPLAY SMS,SHCDS<br />
Name Size %UTIL Status Type<br />
TOOSMALL.VXP0301 7200Kb 5% GOOD ACTIVE<br />
TOOSMALL.VXP0302 7200Kb 5% GOOD ACTIVE<br />
JUSTRITE.VXP0301 14400Kb 2% GOOD ACTIVE<br />
JUSTRITE.VXP0302 14400Kb 2% GOOD ACTIVE<br />
WRONGVOL.VXP0201 7200Kb 5% GOOD SPARE<br />
RIGHTVOL.VXP0202 7200Kb 5% GOOD SPARE<br />
.<br />
Then you can issue:<br />
V SMS,SHCDS(TOOSMALL.VXP0301),DELETE<br />
V SMS,SHCDS(TOOSMALL.VXP0302),DELETE<br />
V SMS,SHCDS(WRONGVOL.VXP0201),DELETE<br />
.<br />
Which will leave you with:<br />
SYSTEM1 d sms,shcds<br />
IGW612I 16:47:07 DISPLAY SMS,SHCDS<br />
Name Size %UTIL Status Type<br />
JUSTRITE.VXP0301 14400Kb 2% GOOD ACTIVE<br />
JUSTRITE.VXP0302 14400Kb 2% GOOD ACTIVE<br />
RIGHTVOL.VXP0202 7200Kb 5% GOOD SPARE<br />
See 4.56.12 Changing the State of Coupling Facility Cache<br />
Structures and Volumes in MVS System Commands for information<br />
on the VARY command.<br />
.<br />
PART 4: SYMTOMS OF HAVING PROBLEMS WITH SHCDS DEFINITION/USAGE<br />
.<br />
The following symptoms result from this set of steps.<br />
Please note that this is NOT a valid way to change the<br />
way the SHCDSs are defined. See the section above for the<br />
recommended way of redefining your SHCDS.<br />
- Terminate SMS<strong>VSAM</strong><br />
- Delete all SHCDSs (could also happen if delete some SHCDSs)<br />
- Redefine SHCDSs<br />
- Bring up SMS<strong>VSAM</strong><br />
.<br />
DUMP00 TITLE=COMPID=DF122,CSECT=IGWXSS90+0890,DATE=10/13/01,<br />
MAINTID= NONE ,ABND=0F4,RC=00000024,RSN=67260989<br />
.<br />
DUMP01 TITLE=COMPID=DF122,CSECT=IGWXSS91+0628,DATE=10/13/01,<br />
MAINTID= NONE ,ABND=0F4,RC=00000024,RSN=67610382<br />
RSN67610382 67610382<br />
.<br />
--------------------------------------------------------------
SHCDS has CISIZE=6K and is added successfully.<br />
Things can go along fine for a while and then you get :<br />
DUMP00 TITLE=COMPON=MEDIA MANAGER, COMPID=DF106, ISSUER=ICYFRR<br />
DUMP TAKEN TIME=15.06.59 DATE=05/31/2002<br />
SYSTEM ABEND CODE=0C4 REASON CODE=00301314<br />
MODULE=IEANUC01 CSECT=ICYSTOR<br />
--------------------------------------------------------------<br />
Non-linear SHCDS - defined as a PS or whatever is default:<br />
On system2:<br />
15.46.35 SYSTEM2 IGW602E ADD SHARE CONTROL DATA SET FAILED,<br />
SYS1.DFPSHCDS.NONLINNC.VSPLXP2 IS NOT A <strong>VSAM</strong> LINEAR DATA SET<br />
On system1:<br />
15.46.35 SYSTEM2 IGW602E ADD SHARE CONTROL DATA SET FAILED,<br />
SYS1.DFPSHCDS.NONLINNC.VSPLXP2 IS NOT A <strong>VSAM</strong> LINEAR DATA SET<br />
.<br />
then later:<br />
DUMP00 TITLE=COMPON=MEDIA MANAGER, COMPID=DF106, ISSUER=ICYFRR<br />
SYSTEM ABEND CODE=0C4 REASON CODE=00301314<br />
MODULE=IEANUC01 CSECT=ICYSTOR<br />
--------------------------------------------------------------<br />
During Server initialization, insufficient access authority<br />
to SHCDS. Previously defined SHCDS are deleted.<br />
ICH408I JOB(SMS<strong>VSAM</strong> ) STEP(SMS<strong>VSAM</strong> ) 744<br />
SYS1.DFPSHCDS.ACTIVE2.VSPLXPK CL(DATASET ) VOL(USRPAK)<br />
INSUFFICIENT ACCESS AUTHORITY<br />
FROM SYS1.DFPSHCDS.* (G)<br />
ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE )<br />
IEF196I IEC161I 040(056,006,IGG0CLFT)-002,IEESYSAS,SMS<strong>VSAM</strong>,SYS00<br />
IEC161I 040(056,006,IGG0CLFT)-002,IEESYSAS,SMS<strong>VSAM</strong>,SYS00001,,,<br />
IEF196I IEC161I SYS1.DFPSHCDS.ACTIVE2.VSPLXPK<br />
IEC161I SYS1.DFPSHCDS.ACTIVE2.VSPLXPK<br />
.<br />
IEA794I SVC DUMP HAS CAPTURED: 760<br />
DUMPID=001 REQUESTED BY JOB (SMS<strong>VSAM</strong> )<br />
DUMP TITLE=COMPID=DF122,CSECT=IGWXSI20+0490,DATE=04/16/00,MAINT<br />
ID= NONE ,ABND=0F4,RC=00000024,RSN=67510404<br />
RSN67510404 67510404<br />
.<br />
*IGW611A SHARE CONTROL DATA SET NEVER ASSIGNED<br />
*IGW609A NO SPARE SHARE CONTROL DATA SETS EXIST. IMMEDIATE ACTIO<br />
REQUIRED<br />
----------------------------------------------------------------<br />
During Server initialization, insufficient access to SHCDS<br />
During initialization on a new system, a previously defined<br />
SHCDS might be deleted.<br />
With OW49746, we will fail the initialization process.<br />
IEF196I IEF237I 081F ALLOCATED TO SYS00002<br />
Appendix D. Information APARs 449
450 <strong>VSAM</strong> <strong>Demystified</strong><br />
IEF196I ICH408I JOB(IEESYSAS) STEP(SMS<strong>VSAM</strong> )<br />
IEF196I SYS1.MVSRES.MASTCAT CL(DATASET ) VOL(USRPAK)<br />
IEF196I INSUFFICIENT ACCESS AUTHORITY<br />
IEF196I ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE )<br />
ICH408I JOB(IEESYSAS) STEP(SMS<strong>VSAM</strong> ) 785<br />
SYS1.MVSRES.MASTCAT CL(DATASET ) VOL(USRPAK)<br />
INSUFFICIENT ACCESS AUTHORITY<br />
ACCESS INTENT(UPDATE ) ACCESS ALLOWED(NONE )<br />
IGW601E ADD SHARE CONTROL DATA SET FAILED, 790<br />
UNABLE TO ALLOCATE SYS1.DFPSHCDS.ACTIVE.VSPLXPK<br />
----------------------------------------------------------------<br />
During initialization on a new system, a previously defined<br />
SHCDS might be deleted.<br />
Instead, we will fail the initialization process.<br />
IGW619I ACTIVE SHARE CONTROL DATA SET 949<br />
SYS1.DFPSHCDS.ACTIVE2.VSPLXPK ADDED.<br />
IEF196I IEF237I 081F ALLOCATED TO SYS00002<br />
IGW619I ACTIVE SHARE CONTROL DATA SET 951<br />
SYS1.DFPSHCDS.ACTIVE.VSPLXPK ADDED.<br />
IGW601E ADD SHARE CONTROL DATA SET FAILED, 952<br />
UNABLE TO ALLOCATE SYS1.DFPSHCDS.SPARE.VXP0201<br />
IEF196I IEF237I 081F ALLOCATED TO SYS00003<br />
IGW619I SPARE SHARE CONTROL DATA SET 954<br />
SYS1.DFPSHCDS.SPARE.VSPLXPK ADDED.<br />
----------------------------------------------------------------<br />
During initialization on a new system, a SHCDS that is on an<br />
offline volume, will be deleted.<br />
14.33.02 SYSTEM1 *IGW615W SHARE CONTROL DATA SET<br />
SYS1.DFPSHCDS.ACTIVE4.VXP0302 HAS FAILED<br />
.<br />
PART 5: FALLBACK PROCEDURE<br />
.<br />
For some SHCDS errors, FALLBACK is the only way to correct the<br />
problem and to get the SMS<strong>VSAM</strong> to intialize successfully again.<br />
If you get repeated abends with the prefix '67' in the RSN code,<br />
then you know it's time to do a FALLBACK.<br />
.<br />
NOTE: *** IPL would NOT help because SHCDS is remembered from<br />
one IPL to another ***<br />
.<br />
FALLBACK procedure is documented in z/OS V1R3.0 DFSMSdfp Storage<br />
Administration Reference. In a nutshell, FALLBACK will reformat<br />
the SHCDS and hence clear all the errors.<br />
FALLBACK involves:<br />
- Terminate all servers in the plex using the command<br />
"VARY SMS,SMS<strong>VSAM</strong>,TERMINATESERVER"<br />
- Issue "VARY SMS,SMS<strong>VSAM</strong>,FALLBACK"<br />
- Reply to the WTOR that you are sure you want to do FALLBACK<br />
- Reactivate the server one at a time using -
"VARY SMS,SMS<strong>VSAM</strong>,ACTIVE"<br />
One the first system, you will be asked to specify 2 ACTIVE<br />
and 1 SPARE SHCDS.<br />
To add an active SHCDS: "VARY SMS,SHCDS(SHCDS_name),NEW"<br />
To add a spare SHCDS: "VARY SMS,SHCDS(SHCDS_name),NEWSPARE"<br />
.<br />
So far, we know the following errors would require FALLBACK:<br />
- Abend0F4 RC24 RSN675D0355<br />
- Abend0F4 RC24 RSN67260989<br />
- Abend0F4 RC24 RSN675F0398<br />
LOCAL FIX:<br />
BDC000010564<br />
--------------------------------------------------------------------------------<br />
Item BDC000010564<br />
Source..........: PDDB0 PDDB0<br />
Last updated....: 10/26/1998<br />
Abstract........: <strong>VSAM</strong>RLS MIXED ENVIRONMENT<br />
USERS: VRLs<br />
PROBLEM SUMMARY:<br />
SMS<strong>VSAM</strong> address space hangs. Vary S active also hangs. Display of<br />
server shows SHV PH2 Init step<br />
SOLUTION:<br />
One of the systems was missing catalog entry for the SHCDS shared<br />
control datasets.<br />
PROBLEM DETAILS:<br />
TYPE: USER<br />
COMPID: 5695DF122<br />
RELEASE: 1D0<br />
CUSTOMER:<br />
We are using <strong>VSAM</strong> RLS across two systems. One is 5.2.2 (SMS 1.2) the<br />
other was just upgraded from OS/390 1.3 (SMS 1.3) to OS/390 2.5 (SMS<br />
1.4). We cannot get SMS<strong>VSAM</strong> to come available. I forced the SMS<strong>VSAM</strong><br />
Appendix D. Information APARs 451
452 <strong>VSAM</strong> <strong>Demystified</strong><br />
address space down on the 5.2.2 system to try to recover it, but this<br />
did not help.<br />
CUSTOMER:<br />
We tried applying UW48355 to our 5.2.2 system to see if that would<br />
help, to no avail.<br />
IBM STATUS:<br />
I left a voice message requesting that the pmr be updated with additional<br />
info.<br />
1. Does the RLSINIT parm specify YES<br />
2. What is being displayed from the D SMS,SMS<strong>VSAM</strong>,ALL<br />
3. Has RLS ever been intialized before on these systems?<br />
4. Were there any messages or Abends<br />
5. How are the SHCDS defined (make sure there are 2 active and 1 spare)<br />
6. Does Vary SMS,SMS<strong>VSAM</strong>,ACTIVE abend/message or hangs.........<br />
Please update the pmr with as much info as possible.<br />
CUSTOMER:<br />
As I stated earlier, these are NOT new systems, just that one was upgraded,<br />
so all the definitions are still there. The parmlib members<br />
were copied over.<br />
D SMS,SMS<strong>VSAM</strong>,ALL<br />
IGW420I DISPLAY SMS,SMS<strong>VSAM</strong> 934<br />
DISPLAY SMS,SMS<strong>VSAM</strong> - SERVER STATUS<br />
SYSNAME: ESAJ UNAVAILABLE ASID: 000A STEP: SHC_Ph2_Init<br />
SYSNAME: SYSI UNAVAILABLE ASID: 000A STEP: SHC_Ph2_Init<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
DISPLAY SMS<strong>VSAM</strong> - JOB STATUS<br />
SUBSYSTEMS CONNECTED: 0 BATCH: 0
DISPLAY SMS<strong>VSAM</strong> - LOCK TABLE STATUS (IGWLOCK00)<br />
CONNECT STATUS:<br />
SYSNAME: ESAJ ................. RSN: 00000000 RbldNotActive<br />
SYSNAME: SYSI ................. RSN: 00000000 RbldNotActive<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
This is what we get when we do a display. We receive no error message<br />
on doing the V SMS,SMS<strong>VSAM</strong>,ACTIVE.<br />
IBM STATUS:<br />
From the status of each status it appears that the step phase is stuck<br />
in SHC_PH2_Init which is dealing with the SHCDS (Share Control<br />
Datasets).<br />
1. How are the SHCDS defined (esp shareoptions)<br />
2. Please issue D SMS,SHCDS and paste text in pmr.<br />
3. Is this the first time that the server has been re-activated since<br />
it has been up on both systems?<br />
CUSTOMER:<br />
Yes, I believe that this has not worked since the upgrade. Here's the<br />
output:<br />
D SMS,SMS<strong>VSAM</strong>,ALL<br />
IGW420I DISPLAY SMS,SMS<strong>VSAM</strong> 934<br />
DISPLAY SMS,SMS<strong>VSAM</strong> - SERVER STATUS<br />
SYSNAME: ESAJ UNAVAILABLE ASID: 000A STEP: SHC_Ph2_Init<br />
SYSNAME: SYSI UNAVAILABLE ASID: 000A STEP: SHC_Ph2_Init<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
Appendix D. Information APARs 453
454 <strong>VSAM</strong> <strong>Demystified</strong><br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
DISPLAY SMS<strong>VSAM</strong> - JOB STATUS<br />
SUBSYSTEMS CONNECTED: 0 BATCH: 0<br />
DISPLAY SMS<strong>VSAM</strong> - LOCK TABLE STATUS (IGWLOCK00)<br />
CONNECT STATUS:<br />
SYSNAME: ESAJ ................. RSN: 00000000 RbldNotActive<br />
SYSNAME: SYSI ................. RSN: 00000000 RbldNotActive<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
CUSTOMER:<br />
Sorry, I pasted the wrong stuff:<br />
D SMS,SHCDS<br />
IEE932I 692<br />
IGW612I 14:26:23 DISPLAY SMS,SHCDS<br />
Name Size %UTIL Status Type<br />
-----------------0Kb 0% N/A N/A<br />
-----------------0Kb 0% N/A N/A<br />
-----------------0Kb 0% N/A N/A<br />
-----------------0Kb 0% N/A N/A<br />
-----------------0Kb 0% N/A N/A<br />
-----------------0Kb 0% N/A N/A<br />
-----------------0Kb 0% N/A N/A<br />
-----------------0Kb 0% N/A N/A<br />
-----------------0Kb 0% N/A N/A
IBM STATUS:<br />
In the D SMS,SHCDS output it is not showing the names of your Share<br />
control datasets. Did you erase them from the output or is this the<br />
output pasted from the console? If so, it appears that there are no<br />
SHCDS listed for this system. Can you see them from a listcat?<br />
CUSTOMER:<br />
Since one of the systems was not upgraded, are these defined in both<br />
sides?<br />
IBM STATUS:<br />
There should be only 1 set of Share control datasets. It sounds as if<br />
the XCF strucutre was deleted and redefined. This is one of the ways<br />
that the names of the SHCDS files are dropped. Also I noticed in your<br />
first update that you have an DFSMS R120 MVS 5.2.2 system. Maybe this<br />
was a typo, but RLS cannot be activated on a DFSMS R1B0 system.<br />
CUSTOMER:<br />
That DFSMS is R130 on MVS 5.2.2.<br />
CUSTOMER:<br />
We recataloged the datasets. Tried 'cycling' SMS<strong>VSAM</strong> to no avail.<br />
IPLd both systems last night. The user tried one immediately and all<br />
is well, the other I'm still waiting on an answer. So looks as though<br />
the datasets got uncataloged on the conversion. Of course no one<br />
knows how. Is there a way to decipher what the error codes mean so<br />
that the next time something like this happens we can find it easier?<br />
IBM STATUS:<br />
The reason codes are not documented but a clue is when the steps of<br />
the D SMS,SMS<strong>VSAM</strong>,ALL show SHC_PH2_INIT or anything with SHC means<br />
that the share control datasets were not recognized.<br />
CUSTOMER:<br />
I displayed the shcds's and show three (3) active shcds's. When I do<br />
the display on smsvsam,all, i show one active and one unavailable system.<br />
The unavailable system is in the shc_ph2_init state. I varied<br />
SMS<strong>VSAM</strong> active (v sms,smsvsam,active) and the status did not change,<br />
i.e. one available and one unavailable. My commands were issued on<br />
the unavailable system. Do you have any further suggestions on getting<br />
it to activate? I noticed Monday am following IPL's of both systems<br />
over the weekend that both showed active, but somehow one of the systems<br />
evidently fell out. The SHCDS datasets are all cataloged on that<br />
system and add successfully when added via command.<br />
IBM STATUS:<br />
Can you paste the output from D SMS,SHCDS issued on the unavailable<br />
system in the PMR?<br />
Appendix D. Information APARs 455
456 <strong>VSAM</strong> <strong>Demystified</strong><br />
CUSTOMER:<br />
98244 10:52:23.16 CSTMXE4 00000290 D SMS,SHCDS<br />
98244 10:52:23.22 01000090 IEE932I 264<br />
264 00000090 IGW612I 10:52:23 DISPLAY<br />
SMS,SHCDS<br />
264 00000090 Name Size %UTIL<br />
Status Type<br />
264 00000090 ACTIVE.VAFXBDD 2880Kb 8% GOOD<br />
ACTIVE<br />
264 00000090 -----------------0Kb 0% N/A<br />
N/A<br />
264 00000090 -----------------0Kb 0% N/A<br />
N/A<br />
264 00000090 -----------------0Kb 0% N/A<br />
N/A<br />
264 00000090 -----------------0Kb 0% N/A<br />
N/A<br />
264 00000090 -----------------0Kb 0% N/A<br />
N/A<br />
264 00000090 -----------------0Kb 0% N/A<br />
N/A<br />
264 00000090 -----------------0Kb 0% N/A<br />
N/A<br />
264 00000090 -----------------0Kb 0% N/A<br />
N/A<br />
264 00000090 -----------------0Kb 0% N/A<br />
N/A D SMS,SMS<strong>VSAM</strong>,ALL<br />
98244 10:57:08.14 STC01761 00000090 SQAMON - SQA SIZE - 6756K; SPILL=<br />
5140K<br />
98244 10:57:08.95 01000290 IXL014I IXLCONN REQUEST FOR<br />
STRUCTURE IGWLO<br />
503 00000090 JOBNAME: SMS<strong>VSAM</strong> ASID: 000A<br />
CONNECTOR NAME:<br />
503 00000090 CFNAME: CFPART01<br />
98244 10:57:08.95 01000290 IXL030I CONNECTOR STATISTICS FOR<br />
LOCK STRUC<br />
504 00000090 CONNECTOR SYSI:<br />
504 00000090 000200F6<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
504 00000090 00000001 00000000 00000000<br />
00000000<br />
504 00000090 00000000 00000000 00000000<br />
00000000
504 00000090 00000000 00000000 00000000<br />
00000000<br />
504 00000090 00000002 00000000 00000000<br />
00000000<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
98244 10:57:08.95 01000290 IXL031I CONNECTOR CLEANUP FOR LOCK<br />
STRUCTUR<br />
505 00000090 CONNECTOR SYSI, HAS COMPLETED. D<br />
SMS,SMS<strong>VSAM</strong>,ALL<br />
98244 10:57:08.14 STC01761 00000090 SQAMON - SQA SIZE - 6756K; SPILL=<br />
5140K<br />
98244 10:57:08.95 01000290 IXL014I IXLCONN REQUEST FOR<br />
STRUCTURE IGWLO<br />
503 00000090 JOBNAME: SMS<strong>VSAM</strong> ASID: 000A<br />
CONNECTOR NAME:<br />
503 00000090 CFNAME: CFPART01<br />
98244 10:57:08.95 01000290 IXL030I CONNECTOR STATISTICS FOR<br />
LOCK STRUC<br />
504 00000090 CONNECTOR SYSI:<br />
504 00000090 000200F6<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
504 00000090 00000001 00000000 00000000<br />
00000000<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
504 00000090 00000002 00000000 00000000<br />
00000000<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
504 00000090 00000000 00000000 00000000<br />
00000000<br />
98244 10:57:08.95 01000290 IXL031I CONNECTOR CLEANUP FOR LOCK<br />
STRUCTUR<br />
505 00000090 CONNECTOR SYSI, HAS COMPLETED.<br />
00200F6 00000000 00000000 00000000 00000000 00000000<br />
0090 IGW420I DISPLAY SMS,SMS<strong>VSAM</strong> 506<br />
0090 DISPLAY SMS,SMS<strong>VSAM</strong> - SERVER STATUS<br />
0090 SYSNAME: ESAJ AVAILABLE ASID: 000A STEP:<br />
SmsVsamInitComplete<br />
Appendix D. Information APARs 457
458 <strong>VSAM</strong> <strong>Demystified</strong><br />
0090 SYSNAME: SYSI UNAVAILABLE ASID: 000A STEP: SHC_Ph2_Init<br />
0090 SYSNAME: ........ ........... ASID: .... STEP:<br />
....................<br />
0090 SYSNAME: ........ ........... ASID: .... STEP:<br />
....................<br />
0090 SYSNAME: ........ ........... ASID: .... STEP:<br />
....................<br />
0090 SYSNAME: ........ ........... ASID: .... STEP:<br />
....................<br />
0090 SYSNAME: ........ ........... ASID: .... STEP:<br />
....................<br />
0090 SYSNAME: ........ ........... ASID: .... STEP:<br />
....................<br />
0090<br />
0090 DISPLAY SMS<strong>VSAM</strong> - JOB STATUS<br />
0090 SUBSYSTEMS CONNECTED: 0 BATCH: 1<br />
0090<br />
0090 DISPLAY SMS<strong>VSAM</strong> - LOCK TABLE STATUS (IGWLOCK00)<br />
0090 CONNECT STATUS:<br />
0090 SYSNAME: ESAJ ACTIVE RSN: 02010407<br />
RbldNotActive<br />
0090 SYSNAME: SYSI ................. RSN: 00000000<br />
RbldNotActive<br />
When SYSI fails to connect, like this display, it's always in the<br />
SHC_PH2_INIT status. Attempting to v sms,smsvsam,active has no positve<br />
results. If an IPL takes place, it will normally sync up. One other<br />
note: At IPL when it doesn't sync up, we get the message that the<br />
SHCDS is not duplexed; immediate action is required. Adding another<br />
or tow SHCDS's does not change the status, i.e. it does not activate.<br />
IBM STATUS:<br />
It appears from the output from the D SMS,SHCDS display that only 1<br />
SHCDS exist. Now this is strange when there should be at least 3<br />
share control datasets(2 active and 1 spare). As for system SYSI it<br />
appears to be stuck in share control phase init which means that the<br />
Share control datasets are not being recognized to that system.<br />
Do both systems diplay the same ouput for the D SMS,SHCDS? If not,<br />
please update etr with output for both systems. Are there 3 SHCDS defined?<br />
CUSTOMER:<br />
IBM:<br />
Getting back to problem.<br />
Today I issued some SMS display commands and one of the two systems<br />
showed available and one showed unavailable. I display the SHCDS's<br />
and only one showed active. I added a second (duplex) and then a<br />
third (spare) which then caused smsvsam to activate and now shows to
BDC000007033<br />
be available on both systems. I have a user currently testing and<br />
should have results fairly soon. How does SMS acquire the SHCDS datasets?<br />
Since the name is SYS1.DFPSHCDS, does it look for those names?<br />
Once I activate the SHCDS's, do I need to activate them each time<br />
SMS<strong>VSAM</strong> is stopped (i.e. IPL)?<br />
IBM UPDATE:<br />
The short answers to your question is-<br />
Yes,SMS does look for the data set names.<br />
No,you do not need to activate the Share Control Data Sets every time<br />
a SMS<strong>VSAM</strong> is stopped.<br />
After talking to Renee it seems that something keeps taking your SC<br />
data sets out of commission and that you're trying to pinpoint whytrue?<br />
IBM STATUS:<br />
One of the systems was missing Catalog entry for shared D/S.<br />
Item BDC000007033<br />
Source..........: PDDB0 PDDB0<br />
Last updated....: 02/26/1998<br />
Abstract........: SMS<strong>VSAM</strong> address space does not complete initialization<br />
USERS: VRLS<br />
PROBLEM SUMMARY:<br />
Delete / Moved SHCDS share control ds SMS<strong>VSAM</strong> would not initialize<br />
SOLUTION:<br />
Applied uw42626 and issued FALLBACKSMS<strong>VSAM</strong>YES<br />
PROBLEM DETAILS:<br />
TYPE: N/A<br />
COMPID: 5695DF122<br />
RELEASE: 1C0<br />
CUSTOMER:<br />
Running OS390 R3 at 9710 put level. Any attempt to bring up<br />
the SMS<strong>VSAM</strong> address space and it never seems to complete initialization.<br />
Display it you get the following:<br />
DISPLAY SMS,SMS<strong>VSAM</strong> - SERVER STATUS<br />
SYSNAME: TLP1 UNAVAILABLE ASID: 000A STEP: SHC_Ph2_Init<br />
SYSNAME: ........ ........... ASID: .... STEP: .............<br />
Appendix D. Information APARs 459
460 <strong>VSAM</strong> <strong>Demystified</strong><br />
DISPLAY SMS<strong>VSAM</strong> - JOB STATUS<br />
SUBSYSTEMS CONNECTED: 0 BATCH: 0<br />
DISPLAY SMS<strong>VSAM</strong> - LOCK TABLE STATUS (IGWLOCK00)<br />
CONNECT STATUS:<br />
SYSNAME: TLP1 ................. RSN: 00000000 RbldNotActive<br />
SYSNAME: ........ ................. RSN: ........ ..............<br />
Here are the SMS parms.<br />
IGD031I SMS PARAMETERS 483<br />
ACDS = SCS5.DFSMS.ACDS<br />
COMMDS = SCS5.DFSMS.COMMDS<br />
INTERVAL = 15 DINTERVAL = 150<br />
BMFTIME = 3600 CACHETIME = 3600<br />
SMF_TIME = YES CF_TIME = 3600<br />
LOCAL_DEADLOCK = 30 GLOBAL_DEADLOCK = 10<br />
REVERIFY = NO ACSDEFAULTS = NO<br />
DSNTYPE = PDS USE_RESOWNER = YES<br />
PDSESHARING = NORMAL<br />
OVRD_EXPDT = NO RLS_MAX_POOL_SIZE = 50MB<br />
SYSTEMS = 8 RLSINIT = YES<br />
HSP_SIZE = 256MB<br />
TRACE = OFF SIZE = 128K TYPE = ERROR<br />
JOBNAME = * ASID = *<br />
TRACING EVENTS:<br />
MODULE = ON SMSSJF = ON SMSSSI = ON ACSINT = ON<br />
OPCMD = ON CONFC = ON CDSC = ON CONFS = ON<br />
MSG = ON ERR = ON CONFR = ON CONFA = ON<br />
ACSPRO = ON IDAX = ON DISP = ON CATG = ON<br />
VOLREF = ON SCHEDP = ON SCHEDS = ON VTOCL = ON<br />
VTOCD = ON VTOCR = ON VTOCC = ON VTOCA = ON<br />
RCD = ON DCF = ON DPN = ON TVR = ON<br />
DSTACK = ON<br />
Used the command: V SMS,SMS<strong>VSAM</strong>,ACTIVE<br />
IBM STATUS:<br />
When the Vary SMS,SMS<strong>VSAM</strong>,ACTIVE command is issued what are the messages<br />
received? Issue a Display SMS,SHCDS this will<br />
tell if any Share control datasets were defined and what is the status.<br />
Are there 2 primary and 1 spare SHCDS?<br />
CUSTOMER:<br />
System was IPLed this morning and the SMS<strong>VSAM</strong> address space is up<br />
and is getting CPU time. No messages seen.<br />
A D SMS,SHCDS and it never comes back. Looking through the console<br />
log at ipl time it does show the share datasets:<br />
IEF196I IEF237I 09BB ALLOCATED TO SYS00001<br />
IGW619I ACTIVE SHARE CONTROL DATA SET 162
SYS1.DFPSHCDS.PRIMARY.VSYSP16 ADDED.<br />
IEF196I IEF237I 09BC ALLOCATED TO SYS00002<br />
IGW619I ACTIVE SHARE CONTROL DATA SET 164<br />
SYS1.DFPSHCDS.SECONDRY.VSYSP17 ADDED.<br />
IEF196I IEF237I 09BD ALLOCATED TO SYS00003<br />
IGW619I ACTIVE SHARE CONTROL DATA SET 166<br />
SYS1.DFPSHCDS.SPARE.VSYSP18 ADDED.<br />
A V SMS,SMS<strong>VSAM</strong>,ACTIVE and nothing comes back.<br />
A D SMS,SMS<strong>VSAM</strong>,ALL and no messages or displays are shown .<br />
CUSTOMER:<br />
Just to give you a little more background. Previously the SMS<strong>VSAM</strong><br />
address space use to come up and get Abend0e0, but would never fully<br />
initialize. However we always could do various displays with no problem.<br />
This changed to our current problem after we deleted our coupling<br />
facility datasets and reallocated them. We changed the MAXSYSTEM<br />
parm from 8 to 4, that's why we did it. This morning we wanted to<br />
changeour share datasets because we want to move them. I turned<br />
RLSINIT to NO abd then did FORCE SMS<strong>VSAM</strong>,ARM to shutdown theSMS<strong>VSAM</strong><br />
address space and this all worked. I turned RLSINIT to YES and then<br />
did V SMS, SMS<strong>VSAM</strong>, ACTIVE. SMS<strong>VSAM</strong> took the abend0e0:<br />
SYSTEM COMPLETION CODE=0E0 REASON CODE=00000030<br />
TIME=09.29.25 SEQ=00135 CPU=0041 ASID=0020<br />
PSW AT TIME OF ERROR 075C1000 81E76252 ILC 4 INTC 30<br />
NO ACTIVE MODULE FOUND<br />
NAME=UNKNOWN<br />
DATA AT PSW 01E7624C - 47F0F006 063AB240 00E05180<br />
GPR 0-3 00000200 7F148470 FF147028 7F147028<br />
GPR 4-7 FF147028 00000000 00000050 007DE920<br />
GPR 8-11 81E7625C 00000050 7F148420 01EA079F<br />
GPR 12-15 20000000 00000000 81E768C8 01E7624C<br />
END OF SYMPTOM DUMP<br />
It took 2 of these abends. The SMS<strong>VSAM</strong> address space shows up and<br />
getting CPU time. We do not see any other messages. I then try to<br />
add one of the new share datasets: V SMS,SHCDS(PRIMARY.VSCSPX1),NEW.<br />
Nothing comes back and no matter what displays I put in they don't<br />
come back. This is where we stand.<br />
IBM STATUS:<br />
From the indication of your messages It is because you do not have a<br />
SPARE Share control dataset recognized. The msgs following would indicate<br />
that a SPARE exist;<br />
IGW619I ACTIVE SHARE CONTROL DATA SET 060<br />
===========>SYS1.DFPSHCDS.prime.V603RES ADDED.<br />
IEF196I IEF237I 023D ALLOCATED TO SYS00002<br />
IGW619I ACTIVE SHARE CONTROL DATA SET 062<br />
===========>SYS1.DFPSHCDS.SECON.V603LIB ADDED.<br />
IEF196I IEF237I 0230 ALLOCATED TO SYS00003<br />
Appendix D. Information APARs 461
462 <strong>VSAM</strong> <strong>Demystified</strong><br />
******>IGW619I SPARE SHARE CONTROL DATA SET 064<br />
===========>SYS1.DFPSHCDS.SPARE.V603RES ADDED.<br />
It will indicate SPARE. The messages in your previous update display<br />
ACTIVE. So what needs to be done is that one of the SHCDS needs to be<br />
deactivated and reactivated as a SPARE with the Vary command using the<br />
Newspare keyword...<br />
CUSTOMER:<br />
When we shutdown SMS<strong>VSAM</strong> this morning and then came back and got the<br />
Abend0E0, here are the messages received:<br />
IGW619I ACTIVE SHARE CONTROL DATA SET 734<br />
SYS1.DFPSHCDS.PRIMARY.VSYSP16 ADDED.<br />
IEF196I IEF237I 09BC ALLOCATED TO SYS00002<br />
IGW619I ACTIVE SHARE CONTROL DATA SET 736<br />
SYS1.DFPSHCDS.SECONDRY.VSYSP17 ADDED.<br />
IEF196I IEF237I 09BD ALLOCATED TO SYS00003<br />
IGW619I SPARE SHARE CONTROL DATA SET 738<br />
SYS1.DFPSHCDS.SPARE.VSYSP18 ADDED.<br />
IEF196I IEA995I SYMPTOM DUMP OUTPUT<br />
IEF196I SYSTEM COMPLETION CODE=0E0 REASON CODE=00000030<br />
So the system does recognize the spare and looking back at ipl time it<br />
also shows the SPARE message, my cut and paste probably is bad.<br />
IBM UPDATE:<br />
I discussed this problem with my developer and he can see from your<br />
update a couple of things.<br />
1. Need to make sure that the PTFs UW42626 and UW39292 are both applied.<br />
2. Also the way that the SHCDS were moved was incorrect. Due to the<br />
info that is kept in the SHCDS and on the system, SMS<strong>VSAM</strong> will<br />
look for those same SHCDS. The proper way would be to add in the<br />
new dataset and spares (using Vary command) and then delete the<br />
old ones(using Vary Command). Do all of this while the SMS<strong>VSAM</strong><br />
server is active.<br />
Please verify that these PTFs are applied.<br />
CUSTOMER:<br />
PTFs, UW42626 and UW39292 are on. We have used the VARY command for<br />
the SHCDSes. We have just ipled our system with RLSINIT(YES), so<br />
SMS<strong>VSAM</strong> was active. I did a D SMS,SHCDS and the display never came<br />
back. I then reset RLSINIT(NO) and did a FORCE SMS<strong>VSAM</strong>,ARM and this<br />
shutdown the address space. I then did a VARY SMS,SMS<strong>VSAM</strong>,FALLBACK<br />
and replied to the message FALLBACKSMS<strong>VSAM</strong>YES. I then received the<br />
following:<br />
IGW524I SMS<strong>VSAM</strong> FALLBACK PROCESSING IS NOW COMPLETE<br />
IEF196I IGW523A SMS<strong>VSAM</strong> ADDRESS SPACE FALLBACK IS REQUESTED. REPLY<br />
IEF196I 'CANCEL' TO ABORT, 'FALLBACKSMS<strong>VSAM</strong>YES' TO PROCEED.<br />
*19 IGW523A SMS<strong>VSAM</strong> ADDRESS SPACE FALLBACK IS REQUESTED. REPLY 'CANCEL'
TO ABORT, 'FALLBACKSMS<strong>VSAM</strong>YES' TO PROCEED.<br />
I replied FALLBACKSMS<strong>VSAM</strong>YES and received the message:<br />
IGW524I SMS<strong>VSAM</strong> FALLBACK PROCESSING IS NOW COMPLETE<br />
I set SMS to RLSINIT(YES) and that is where we sit. I'm waiting for<br />
the person in charge of this project to come in to run some commands<br />
and we are probably going to try to vary the new SHCDS datasets on.<br />
Before we do anything, is there something you want me to do?<br />
CUSTOMER:<br />
We did V SMS,SMS<strong>VSAM</strong>,ACTIVE and received:<br />
IGW415I SMS<strong>VSAM</strong> SERVER ADDRESS SPACE HAS FAILED AND IS RESTARTING<br />
Next we did:<br />
D SMS,SHCDS<br />
IEE932I 708<br />
IGW612I 12:54:16 DISPLAY SMS,SHCDS<br />
Name Size %UTIL Status Type<br />
-----------------0Kb 0% N/A N/A<br />
-----------------0Kb 0% N/A N/A<br />
-----------------0Kb 0% N/A N/A<br />
-----------------0Kb 0% N/A N/A<br />
Then we varied the SHCDS:<br />
V SMS,SHCDS(PRIMARY.VSCSPX1),NEW<br />
IGW619I ACTIVE SHARE CONTROL DATA SET 798<br />
SYS1.DFPSHCDS.PRIMARY.VSCSPX1 ADDED.<br />
V SMS,SHCDS(SECONDRY.VSCSPX2),NEW<br />
IGW619I ACTIVE SHARE CONTROL DATA SET 838<br />
SYS1.DFPSHCDS.SECONDRY.VSCSPX2 ADDED.<br />
V SMS,SHCDS(SPARE.VSCSPX3),NEWSPARE<br />
IGW619I SPARE SHARE CONTROL DATA SET 863<br />
SYS1.DFPSHCDS.SPARE.VSCSPX3 ADDED.<br />
IXL014I IXLCONN REQUEST FOR STRUCTURE IGWLOCK00 WAS SUCCESSFUL. 865<br />
JOBNAME: SMS<strong>VSAM</strong> ASID: 00BE CONNECTOR NAME: TLP1<br />
CFNAME: SCSCF1<br />
IXL015I STRUCTURE ALLOCATION INFORMATION FOR 866<br />
STRUCTURE IGWLOCK00, CONNECTOR NAME TLP1<br />
CFNAME ALLOCATION STATUS/FAILURE REASON<br />
-------- ---------------------------------<br />
SCSCF1 STRUCTURE ALLOCATED<br />
IGW453I SMS<strong>VSAM</strong> ADDRESS SPACE HAS SUCCESSFULLY 867<br />
CONNECTED TO DFSMS LOCK STRUCTURE IGWLOCK00<br />
STRUCTURE VERSION:AFD504C2A838AA03 SIZE:20224K bytes<br />
MAXIMUM USERS:4 REQUESTED:4<br />
LOCK TABLE ENTRIES:4194304 REQUESTED:4194304<br />
RECORD TABLE ENTRIES:83481 USED:0<br />
IGW321I No retained locks<br />
IGW321I No Spheres in Lost Locks<br />
IGW414I SMS<strong>VSAM</strong> SERVER ADDRESS SPACE IS NOW ACTIVE.<br />
Appendix D. Information APARs 463
464 <strong>VSAM</strong> <strong>Demystified</strong><br />
IGW467I DFSMS RLS_MAX_POOL_SIZE PARMLIB VALUE SET DURING 877<br />
SMS<strong>VSAM</strong> ADDRESS SPACE INITIALIZATION ON SYSTEM: TLP1<br />
CURRENT VALUE: 40 1<br />
IGW467I DFSMS DEADLOCK_DETECTION PARMLIB VALUE SET DURING 878<br />
SMS<strong>VSAM</strong> ADDRESS SPACE INITIALIZATION ON SYSTEM: TLP1<br />
THIS SYSTEM IS OPERATING AS A LOCAL DEADLOCK PROCESSOR.<br />
CURRENT VALUE: 30 10 1<br />
IGW467I DFSMS SMF_TIME PARMLIB VALUE SET DURING 879<br />
SMS<strong>VSAM</strong> ADDRESS SPACE INITIALIZATION ON SYSTEM: TLP1<br />
CURRENT VALUE: YES 1<br />
IGW467I DFSMS CF_TIME PARMLIB VALUE SET DURING 880<br />
SMS<strong>VSAM</strong> ADDRESS SPACE INITIALIZATION ON SYSTEM: TLP1<br />
CURRENT VALUE: 3600 1<br />
Then we did a D SMS,SHCDS<br />
IGW612I 12:57:32 DISPLAY SMS,SHCDS<br />
Name Size %UTIL Status Type<br />
PRIMARY.VSCSPX1 10800Kb 2% GOOD ACTIVE<br />
SECONDRY.VSCSPX2 10800Kb 2% GOOD ACTIVE<br />
SPARE.VSCSPX3 10800Kb 2% GOOD SPARE<br />
-----------------0Kb 0% N/A N/A<br />
D SMS,SMS<strong>VSAM</strong>,ALL<br />
IGW420I DISPLAY SMS,SMS<strong>VSAM</strong> 915<br />
DISPLAY SMS,SMS<strong>VSAM</strong> - SERVER STATUS<br />
SYSNAME: TLP1 AVAILABLE ASID: 00BE STEP: SmsVsamInitComplete<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
SYSNAME: ........ ........... ASID: .... STEP: ....................<br />
DISPLAY SMS<strong>VSAM</strong> - JOB STATUS<br />
SUBSYSTEMS CONNECTED: 0 BATCH: 1<br />
DISPLAY SMS<strong>VSAM</strong> - LOCK TABLE STATUS (IGWLOCK00)<br />
CONNECT STATUS:<br />
SYSNAME: TLP1 ACTIVE RSN: 00000000 RbldNotActive<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
SYSNAME: ........ ................. RSN: ........ ................<br />
We did other displays and they all come back. These new SHCDS datasets<br />
were allocated on the same system that we brought up SMS<strong>VSAM</strong> on.<br />
This system is an OS390 R3 put level 9710 system. Before the datasets<br />
were allocated on another system in the SYSPLEX. This system is<br />
an OS390 R2 put level 9605+ system. The SHCDS datasets were then recataloged<br />
to the system that SMS<strong>VSAM</strong> was started on. These 2 systems<br />
do not share a master catalog, but they share DASD. What solved this<br />
problem this time around?<br />
IBM STATUS:<br />
The Fallback is kind of like a reset for SMS<strong>VSAM</strong>. All of the infolike<br />
name of SHCDS and lock structure status is all deleted. SO when this
II12603<br />
completes SMS<strong>VSAM</strong> can be activated and will retrieve all new info.<br />
Understand that this is to be used as a last resort, because a lot of<br />
pertinent info is deleted like the lock structure data. It appears<br />
from the displays and the messages that eveything is working.<br />
CUSTOMER:<br />
We seem to have every working. When I brought up out other system in<br />
OS390 R3 and had the SHCDS datasets cataloged everything seemed to<br />
work fine.<br />
Item II12603<br />
APAR Identifier ...... II12603 Last Changed ........ 02/07/21<br />
<strong>VSAM</strong> RECORD-LEVEL SHARING, RLS SMS<strong>VSAM</strong> INITIALIZATION AND<br />
RECOVERY CONSIDERATIONS<br />
Symptom ...... IN INCORROUT Status ........... INTRAN<br />
Severity ................... 3 Date Closed .........<br />
Component .......... INFOV2LIB Duplicate of ........<br />
Reported Release ......... 001 Fixed Release ............<br />
Component Name V2 LIB INFO ITE Special Notice<br />
Current Target Date .. Flags<br />
SCP ...................<br />
Platform ............<br />
Status Detail: Not Available<br />
PE PTF List:<br />
PTF List:<br />
Parent APAR:<br />
Child APAR list:<br />
ERROR DESCRIPTION:<br />
When planning to implement vsam record-level sharing, rls, or<br />
when planning a smsvsam recovery strategy please carefully<br />
review the following documentation.<br />
(SC264920) 'OS390 DFSMSDFP Storage Administration Reference'<br />
Chapter 14: Administering Vsam Record-Level Sharing<br />
(SG242073) 'Getting the Most Out of a Parallel Sysplex'<br />
Section 6.3.4: Batch With CICS and Vsam-RLS<br />
Section 7.3.1: CICS and Vsam-RLS Considerations<br />
(Sy277611) 'OS390 DFSMSDFP Diagnosis Reference'<br />
Appendix D. Information APARs 465
466 <strong>VSAM</strong> <strong>Demystified</strong><br />
Section 20.5: Vsam RLS Diagnostic Aids<br />
(GA227286) 'Parallel Sysplex Recovery'<br />
Section 2.8: Recovering From a Vsam Rls Address Space<br />
Failure<br />
(SC264919) 'DFSMS/MVS Planning for Installation'<br />
Chapter 6: Vsam Record Level Sharing<br />
(GC331681) 'Installation Guide'<br />
Chapter 18: Preparing for Vsam-RLS<br />
(sc267344) 'OS390 DFSMS Introduction'<br />
Chapter 4: Using Vsam Record-Level Sharing<br />
LOCAL FIX:<br />
-----------<br />
INITIALIZATION<br />
The smsvsam server address space may be set to initialize<br />
during ipl or can be activated by means of the<br />
'V SMS,SMS<strong>VSAM</strong>,ACTIVE' command.<br />
The documentation above outlines what must be setup before<br />
smsvsam can initialize. If the address space fails to come up<br />
successfully, use the following display commands to ascertain<br />
the nature of the initialization problem.<br />
'D SMS,SMS<strong>VSAM</strong>,ALL' To display smsvsam status within the<br />
sysplex.<br />
'D SMS,SHCDS' To display the status of the shcds files.<br />
'D XCF' To display coupling facility status information.<br />
.<br />
RECOVERY AND DIAGNOSIS<br />
If the SMS<strong>VSAM</strong> server abnormally terminates a svcdump will be<br />
written to the SYS1.DUMP dataset and the server should<br />
automatically restart. If the server does not restart, use<br />
'V SMS,SMS<strong>VSAM</strong>,ACTIVE' to force the server to reinitialise.<br />
The dump should be used to analyze and resolve the abnormal<br />
termination condition.<br />
It may become apparent that there is a non-terminating problem<br />
with the SMS<strong>VSAM</strong> server. 'Display GRS' command may display<br />
resource contention involving SMS<strong>VSAM</strong>. Workload directed to the<br />
SMS<strong>VSAM</strong> server may not be completing causing slow downs or work<br />
stoppage in jobs utilizing RLS.<br />
When such a hang condition is detected, it is essential to<br />
obtain dumps from every system in the sysplex on which SMSVXAM<br />
is active. These dumps are required by IBM to analyze product<br />
defects leading to the hang condition.<br />
The following example slip can be set disabled and enabled when<br />
a hang condition arises requiring dumps to SMS<strong>VSAM</strong>. When this<br />
slip matches all systems in the sysplex will produce SVCDumps.<br />
SLIP SET,IF,A=SVCD,N=(IEAVEDS0,0000,7FFF),<br />
JOBLIST=(GRS,CATALOG,SMS<strong>VSAM</strong>),<br />
DSPNAME('GRS'.*,'CATALOG'.*,'SMS<strong>VSAM</strong>'.*),
II12243<br />
SDATA=(PSA,SQA,CSA,LPA,TRT,SUM,LSQA,RGN,GRSQ,NUC,XESDATA),<br />
REMOTE=(JOBLIST,DSPNAME,SDATA),END.<br />
As each system in the sysplex will produce a SVCDump<br />
you must ensure the availability of adaquately large sys1.dump<br />
data sets on all systems.<br />
Once the dumps have been taken it may be necessary to terminate<br />
the smsvsam server by use of the 'V SMS,SMS<strong>VSAM</strong>,TERMINATESERVER'<br />
command. Attempt to identify the system most likely to be the<br />
root of the hang condition and terminate it first. It may be<br />
necessary to terminate additional or even all servers before the<br />
hang is resolved. Each terminated server should automatically<br />
restart or may be activated by means of the 'V<br />
SMS,SMS<strong>VSAM</strong>,ACTIVE' command. It may be necessary to terminate<br />
additional or all servers before a terminated server can<br />
successfully restart. You may make use of information returned<br />
from the 'D SMS,SMS<strong>VSAM</strong>' commands to anallyze initialization<br />
problems.<br />
If the system does not respond to the terminateserver command,<br />
issue 'FORCE SMS<strong>VSAM</strong>,ARM' to force the address space down.<br />
SMSvsam should be restarted as if terminateserver had been<br />
successful. A re-ipl should be necessary in only the most severe<br />
situations and attempted only as a last resort.<br />
Item II12243<br />
APAR Identifier ...... II12243 Last Changed ........ 00/08/10<br />
MISC ABEND0F4 IN SMS<strong>VSAM</strong> FOLLOWING 'V XCF,'SYSNAME''<br />
<strong>VSAM</strong>RLS INFOAPAR<br />
Symptom ...... AB ABEND0F4 Status ........... INTRAN<br />
Severity ................... 4 Date Closed .........<br />
Component .......... INFOV2LIB Duplicate of ........<br />
Reported Release ......... 001 Fixed Release ............<br />
Component Name V2 LIB INFO ITE Special Notice<br />
Current Target Date .. Flags<br />
SCP ...................<br />
Platform ............<br />
Status Detail: Not Available<br />
PE PTF List:<br />
PTF List:<br />
Appendix D. Information APARs 467
BDC000022923<br />
468 <strong>VSAM</strong> <strong>Demystified</strong><br />
Parent APAR:<br />
Child APAR list:<br />
ERROR DESCRIPTION:<br />
The command 'v sms,smsvsam,terminateserver' must be issued to<br />
terminate the smsvsam address space prior to partitioning a<br />
system from the sysplex. If a 'v xcf,'sysname'' is issued while<br />
the smsvsam address space is active miscelaneous abend0f4s can<br />
result. Examples of these abends include:<br />
abend0f4 rc24, rc00000024, rsn62020071 rc62020071 idavstai<br />
abend0f4 rc14, rc00000014 rsn00001122 rc00001122 idavqini<br />
Additional keywords:<br />
msgigw416i<br />
Item BDC000022923<br />
Source..........: PDDB0 PDDB0<br />
Last updated....: 04/29/2002<br />
Abstract........: SMS<strong>VSAM</strong> address looping during connect to IGWLOCK00<br />
USERS: ALL DFSMS SMS<strong>VSAM</strong> users<br />
PROBLEM SUMMARY:Loop issuing the following messages:<br />
msgixc579i pending deallocation for structure IGWLOCK00<br />
msgigw469i no suitable coupling facility<br />
msgixl013i IXLCONN failed rc0c rsn02010c08.<br />
These messages flood the console<br />
SOLUTION: User specified incorrect structure size<br />
PROBLEM DETAILS:<br />
TYPE:<br />
COMPID: 5695DF122<br />
RELEASE: 1F0<br />
Customer :<br />
Hi Brought up SMS<strong>VSAM</strong> for the 1st time on Friday. After issuing the<br />
V SMS,SMS<strong>VSAM</strong>,Active command, SMS<strong>VSAM</strong> loops trying to connect to the<br />
IGWLOCK00 structure. There was not enough space in the CF to define<br />
the IGWLOCK00 structure.<br />
I have FTPed dump and SYSLOG..<br />
IBM DFP:<br />
Hello
The dump does not contain all that much of the storage for the address<br />
space. I see we issue the following messages over and over from about<br />
12:15 to 12:55 when you forced SMS<strong>VSAM</strong> address space.<br />
msgixc579i pending deallocation for structure IGWLOCK00<br />
msgigw469i no suitable coupling facility<br />
msgixl013i IXLCONN failed rc0c rsn02010c08.<br />
The trace table is insufficient to determine where the loop lies also.<br />
The WTO appears to be issued from 5e25bc0. This is also not in the<br />
dump nor is the parameter list so I cannot confirm this is where the<br />
problem is. I can tell you this address is in IGDZILLA+x'34bco' . If<br />
you could get an AMBLIST of IGDZILLA and send it I can then check to<br />
what module we are in and see if that will help.<br />
Is this recreatable?<br />
If so, I can put together some information to capture better doc.<br />
Customer<br />
Hi AMBLIST sent<br />
I believe we can recreate .<br />
IBM DFP:<br />
received the amblist. Module is IGDMCSI2 +x'f0' which is the module<br />
that issues all IGW messages. Not too helpful. I will check the code<br />
around the SVC 35 to see where we were at that time. Will update later.<br />
Customer:<br />
HI Is there any other info you need. ? I away on holidays until<br />
next year. In the meantime the DFHSM folks would like to continue with<br />
TESTING..<br />
IBM DFP:<br />
Hello<br />
I am still working on this with the MVS folks. I will update when I<br />
have more information. Who in the HSM group will be working on this<br />
just in case I need to contact them?<br />
IBM:<br />
thanks for the update. we are still trying to figure this out and<br />
hopefully will have something for you today.<br />
IBM DFP:<br />
Hello <strong>VSAM</strong><br />
I am not sure if you guys are the right people for this or if there is<br />
another queue for SMS<strong>VSAM</strong> stuff. Please forward to the correct queue if<br />
it is not you guys.<br />
Please take a look at my update on page 4 of the pmr. SMS<strong>VSAM</strong> could not<br />
connect to IGWLOCK00 because the CF structure was full. However we<br />
continued looping trying to connect. I am sending the syslog to you<br />
via FTP per II03855. This should be easy enough to recreate I suspect.<br />
Appendix D. Information APARs 469
470 <strong>VSAM</strong> <strong>Demystified</strong><br />
If there is anything further that you require let me know.<br />
Requeueing to the RLS queue for diagnosis.<br />
<strong>VSAM</strong> L2:<br />
Hi<br />
By design, SMS<strong>VSAM</strong> will continue attempting to connect to the lock<br />
structure. If there is no room in the coupling facility, room needs to<br />
be made, or the CFRM needs to be changed.<br />
IBM DFP:<br />
Hello<br />
This is totally unreasonable. How are the operators supposed to take<br />
any action when SMS<strong>VSAM</strong> is looping trying to connect to the CF? This<br />
is like saying you shouldn't do anything when you get an X37 abend, just<br />
keep trying eventually the PUT will work? This is ludicrous. IF there<br />
is no space in the CF then fail the request and allow the operators<br />
time to correct it and try again.<br />
Please adddress this as a defect in the code.<br />
Thanks,<br />
action plan: sending to <strong>VSAM</strong> RLS level 2.<br />
Vsam L2<br />
Development looked through the code involved. It is not in a loop.<br />
If SMS<strong>VSAM</strong> cannot connect to the lock structure during initialization<br />
it will go into a wait after issuing the IGW469i. It is notified every<br />
time a change is made to the CF and will attempt to re-allocate the<br />
lock structure. If unsuccessful, it will issue the message and go into<br />
a wait again. It is our opinion that changing the design to terminate<br />
is not in the best interest for all customers.<br />
Regards,<br />
IBM DFP:<br />
I took another look at the dump and do see that we are waiting and then<br />
being woken up every once in awhile. I have asked MVS to take a look<br />
at the trace to see if she can figure out what XCF is changing that is<br />
causing SMS<strong>VSAM</strong> to wake up and try the connect again.<br />
IBM MVS:<br />
To C/T:<br />
The customer got the following sequence of messages after issuing<br />
a V SMS,SMS<strong>VSAM</strong>,Active command:<br />
IXC579I PENDING DEALLOCATION FOR STRUCTURE IGWLOCK00 IN<br />
COUPLING FACILITY 009672.IBM.02.000000049747<br />
PARTITION: 2 CPCID: 00<br />
HAS BEEN COMPLETED.<br />
PHYSICAL STRUCTURE VERSION: B6D0D708 14576381<br />
INFO116: 13060020 01 6A00 0000000B
TRACE THREAD: 00000DE0.<br />
IXC579I PENDING DEALLOCATION FOR STRUCTURE IGWLOCK00 IN<br />
COUPLING FACILITY 009672.IBM.02.000000049748<br />
PARTITION: 2 CPCID: 00<br />
HAS BEEN COMPLETED.<br />
PHYSICAL STRUCTURE VERSION: B6D0D70A A2CCF662<br />
INFO116: 13060020 01 6A00 00000003<br />
TRACE THREAD: 00000DE0.<br />
IGW469I NO SUITABLE COUPLING FACILITY, 779<br />
NUMSYSTEMS:11 STRUCTURESIZE:500000 LOCKENTRIES:34217728<br />
IXL013I IXLCONN REQUEST FOR STRUCTURE IGWLOCK00 FAILED.<br />
JOBNAME: SMS<strong>VSAM</strong> ASID: 006D CONNECTOR NAME: K300<br />
IXLCONN RETURN CODE: 0000000C, REASON CODE: 02010C08<br />
IXL015I STRUCTURE ALLOCATION INFORMATION FOR<br />
STRUCTURE IGWLOCK00, CONNECTOR NAME K300<br />
CFNAME ALLOCATION STATUS/FAILURE REASON<br />
-------- ---------------------------------<br />
CF6L2 INSUFFICIENT SPACE<br />
CF5L2 INSUFFICIENT SPACE<br />
These messages were repeated over and over again appearing to be in<br />
a loop so the customer took a dump of the situation. From the dump<br />
(and with assistance from the <strong>VSAM</strong> c/t) we have determined that<br />
IGWLNI01 repeatedly issues the IXLCONN to connect to IGWLOCK00.<br />
IGWLNI01 checks the return code from the IXLCONN and since it is<br />
non zero it issues IGW469I and then waits on an ECB that is posted<br />
by their ENF35 exit. I have looked at their ENF35 exit (IGWSSEN2)<br />
and it simply causes the ECB to be posted when it is given control.<br />
It appears that the ENF35 exit is being driven frequently. This is<br />
why they continually keep trying to issue the IXLCONN. I have<br />
reviewed all the reasons why the ENF35 exit is given control and<br />
I cannot determine from the dump exactly why the exit is being<br />
driven so frequently. I wasn't sure why the IXC579I messages were<br />
being issued everytime we did the IXLCONN but INFO116 indicates<br />
that module IXCl2ASR is the module that is driving IXCXRHT so<br />
I think these messages are probably normal. I cannot see why<br />
these would trigger the ENF35...<br />
Also - in the SYSXES GLOBAL component trace just prior to<br />
the IXCASR COMPLETE entry - I see several HWLAYER entries for<br />
ENTRY TO IXLERREC but I cannot tie these into the ENF35 signal.<br />
Any ideas?? Thanks<br />
MVS C/T:<br />
Hi<br />
You can send us the dump if you like.<br />
IBM DFP:<br />
Hello<br />
I have ftp'd the tersed dump and syslog to you. Let me know if you need<br />
anything further.<br />
Appendix D. Information APARs 471
Thanks<br />
472 <strong>VSAM</strong> <strong>Demystified</strong><br />
MVS C/T:<br />
Reveiwing doc.<br />
Can we find out who is at LMOD IXCI2PVT+027A78?<br />
Thanks<br />
IBM MVS:<br />
Hi we are trying to solve this mystery but we need an AMBLIST<br />
of IXCI2PVT that matches the dump that was taken on K300 on Nov. 30th<br />
at 12:52:42. I know we are a little late in asking but if you haven't<br />
down any maintenance to XCF load libraries on that system since<br />
Nov. 30th then we should be ok. You can send it to me<br />
IBM C/T:<br />
Trying to determine what would cause the apparent repeated ENF35,<br />
though as MVS and I discussed, we cannot see any remnants of them<br />
(ie. no storage containig the ENF plist) in the dump.<br />
At this point I suspect that the deallocation seen in the MSGIXC579I<br />
is relevant. L2ASR does an IXCXRHT, and I think IXCL2RHT is doing an<br />
IXCXLSIG(NEWRESOURCEAVAIL) which will result in an ENF35. What is not<br />
clear at this point is why the str is being deallocated since the<br />
externals indicate it was not allocated because of insufficient CF<br />
space.<br />
There are some CFRM trace entries that look relevant, and also<br />
some system trace entries where it appears that IXCL2ALF is doing<br />
PC B15. The lmod map previously requested should help clarify these.<br />
Action Plan:<br />
Continue on Monday.<br />
Action Taken:<br />
From discussion with development, this may involve MINSIZE. The<br />
str may actually get allocated at the size of whatever is available in<br />
the CF, but if it does not meet the MINSIZE requirement, it is then<br />
deallocated.<br />
Action Plan:<br />
Check STBL in dump for MINSIZE value and review L2ALF code.<br />
Hello MVS.<br />
Any luck with the lmod map? I also want to know what if anything<br />
is specified in the CFRM policy for the MINSIZE keyword on defintion<br />
of IGWLOCK00.<br />
Thanks<br />
Customer:<br />
Sorry for the delay. AMBLIST has been XMITTED to TORIBM.CS32587.<br />
The IXCI2PVT was last updated as follows.
Entry Type: MOD Zone Name: MVSSAQ<br />
Entry Name: IXCI2PVT Zone Type: TARGET<br />
FMID: HBB7703 LASTUPD: HBB7703<br />
RMID: JNLSHRK DISTLIB: AOSXCF<br />
-------- -------- -------- -------- -------- -------- --------<br />
MOD IXCI2PVT<br />
SECTS IXCI2PVT<br />
The JNLSHRK is a usermod provided by Dave Sherman to allow us to SHRINK<br />
our CFRM dataset dynamically. This did not change since dump...<br />
Yes the structure was defined as follows but with 2 or 3 extra zeros<br />
for the various size fields. ie SIZE(5000000)<br />
STRUCTURE NAME(IGWLOCK00) SIZE(5000)<br />
INITSIZE(2000)<br />
MINSIZE(1000)<br />
FULLTHRESHOLD(80)<br />
ALLOWAUTOALT(YES)<br />
REBUILDPERCENT(1)<br />
PREFLIST(CF5L2, CF6L2)<br />
Hope this helps.<br />
IBM MVS:<br />
Received the AMBLIST from Deo into dataset 'isc.pmr07201.b057.amblist'.<br />
MVS C/T it is on it's way to you......thanks again for the help.<br />
IBM MVS:<br />
What the customer says about the policy does not coincide with what<br />
I see in the dump which shows that SIZE, MINSIZE, and INITSIZE were<br />
all 500000.<br />
Based on what is in the dump, the flow appears to be that there is<br />
not enough space in the CF to allocate 500000 so L2ALF allocates a<br />
structure at whatever size is avaialble. But since the allocated size<br />
is less than MINSIZE, the structure gets dealloacted in L2RHT when<br />
L2ASR does an IXCXRHT to clean the checkpoint. L2RHT also issues the<br />
MSGIXC579I and does an IXCXLSIG(NEWRESOURCEAVAIL) which ultimately<br />
results in L2MSG doing the ENF35.<br />
I'm reviewing this scenario with development. I'll keep a secondary<br />
on our queue and provide a further update when I hear back.<br />
Regards<br />
Customer:<br />
Hi sorry to mislead you. What I meant was the various sizes were<br />
greater by 2 or 3 zeros..<br />
MVS C/T:<br />
Hi IBM MVS<br />
Appendix D. Information APARs 473
474 <strong>VSAM</strong> <strong>Demystified</strong><br />
I saw the comment (which is also what I understood from a prior<br />
update), but it still does not make sense since SIZE, INITSIZE, and<br />
MINSIZE are all the same in the dump. At this point I don't think it<br />
is relevant to the problem that occurred, so let's just see what<br />
response I get from development.<br />
Regards,<br />
IBM MVS:<br />
Hi MVS C/T.....did you hear back from development?<br />
MVS C/T:<br />
Hi IBM MVS.<br />
Yes, they say this is user error and the code is working as it should.<br />
If the ENF was not issued, then a hang could occur because the<br />
connector has no initiative to ever try to get connected.<br />
Regards<br />
IBM MVS:<br />
Talked with IBM DFP In this case the 'user' of the XCF<br />
services is SMS which continually retries the IXLCONN when it receives<br />
the ENF35. The IXLCONN could never have been satisfied because<br />
the MINSIZE was too large. They will investigate if the SMS code<br />
could detect the situation.<br />
IBM DFP:<br />
Hello MVS C/T:<br />
We have been able to determine why this appears to be looping. What is<br />
occurring is is <strong>VSAM</strong> issues the CONNECT to connect to the structure.<br />
XCF attempts to allocate the structure but there is not enough room<br />
even to allocate the MINSIZE that was specified. So XCF then does a<br />
deallocate to unallocate the space that was successfully allocated for<br />
this request.<br />
Since the allocated size is less than MINSIZE, the structure gets<br />
deallocated in IXCL2RHT when IXCL2ASR does an IXCXRHT to clean the<br />
checkpoint. L2RHT also issues the msgixc579i and then does an<br />
IXCXLSIG(NEWRESOURCEAVAIL) which ultimately results in IXCL2MSG doing<br />
the ENF35. XCF has to do this in order to tell all listeners that<br />
there is now space available in the CF.<br />
The problem is SMS<strong>VSAM</strong> just keeps reissuing the CONNECT so it appears<br />
that we are looping when in fact we really are not. What SMS<strong>VSAM</strong><br />
should do is attempt the CONNECT again (maybe a couple of times) and<br />
then give up. Otherwise we would be doing this forever, since in this<br />
specific situation the ral problem was the size that was specified in<br />
the structure was incorrect (and way too big).<br />
Do you think it would be reasonable that we should only retry some<br />
finite number of times and then give up?<br />
Thanks
RTA000141603<br />
Hello MVS DFP:<br />
I discussed this with Terri again. We feel that it is best to leave<br />
the code unchanged. Since RLSINIT(YES) was specified in PARMLIB,<br />
we assume that the user intended SMS<strong>VSAM</strong> to start up<br />
at IPL and had planned accordingly.<br />
Regards,<br />
MVS DFP:<br />
I discussed the resolution of this problem with Customer and he agreed<br />
to leave the code as is. He agreed to close the ETR.<br />
Item RTA000141603<br />
Source..........: PDDB0 PDDB0<br />
Last updated....: 09/26/2000<br />
Abstract........: Rebuild of IGWLOCK00 stalled after loss of coupling facility.<br />
USERS: <strong>VSAM</strong><br />
PROBLEM SUMMARY:<br />
Rebuild of IGWLOCK00 stalled after loss of coupling facility.<br />
SMS<strong>VSAM</strong> unable to re-INIT on all systems.<br />
SOLUTION:<br />
Issue V SMS,SMS<strong>VSAM</strong>,FORCEDELETELOCKSTRUCTURE comand.<br />
PROBLEM DETAILS:<br />
TYPE: WAD<br />
COMPID: 5695DF122<br />
RELEASE: 1D0<br />
CUSTOMER:<br />
Lost the CF on which the IGWLOCK00 structure resided.<br />
While the structure was being rebuilt, also lost the SMS<strong>VSAM</strong><br />
server on N7B. This caused all the other SMS<strong>VSAM</strong> servers<br />
to kill themselves (as expected). However, once they<br />
restarted, the rebuild of IGWLOCK00 was either stalled<br />
or stopped. In any event, the structure did not rebuild<br />
onto the surviving CF, and all the connection to the<br />
structure were listed as FAILED-PERSISTENT. Took a sysplexwide<br />
dump of SMS<strong>VSAM</strong> to help determine what happened to the<br />
rebuild. (Just as a side note, once I recovered the CF,<br />
the structure was successfully recovered).<br />
Appendix D. Information APARs 475
476 <strong>VSAM</strong> <strong>Demystified</strong><br />
The same information could have been gotten with the D SMS,SMS<strong>VSAM</strong> or<br />
via the D XCF,STR,STRNAME=IGWLOCK00 commands.<br />
The systems will only be able to start if the current copy of IGWLOCK00<br />
recovers from its connectivity problem or if the current structure copy<br />
of IGWLOCK00 is destroyed. This could be done with the command:<br />
V SMS,SMS<strong>VSAM</strong>,FORCEDELETELOCKSTRUCTURE<br />
or by using the appropriate XCF commands.<br />
This is working as designed. If connectivity is reestablished everyone<br />
should take off. If the lock structure is deleted, then all currently<br />
open <strong>VSAM</strong> data sets will go into LOST LOCKS state.<br />
CUSTOMER:<br />
Ok. I'll rerun the scenario with the extra step of deleting the lock<br />
structure and I'll let you know what happens.<br />
CUSTOMER:<br />
Re-executed the scenario with the additional step (of deleting<br />
the lock structure). As seemed to work well.<br />
Additional search words:<br />
LVL1PDDB (DMD)<br />
50566,180 <strong>VSAM</strong><br />
VRLSPDDB97
Glossary<br />
Access method control block (ACB). A control<br />
block that links an application to a <strong>VSAM</strong> data set<br />
Active control data set (ACDS). A <strong>VSAM</strong> linear<br />
data set that controls the storage management<br />
policy for an installation. It is shared by each<br />
system that is using the same SMS configuration<br />
to manage storage.<br />
Active lock. A lock obtained by an executing<br />
subsystem. Requests for locks incompatible with<br />
a held active lock are queued. See also retained<br />
lock.<br />
Alternate index. A key-sequenced data set<br />
containing index entries organized by the<br />
alternate keys of its associated base data<br />
records. It provides an alternative way of locating<br />
records in the data set on which the alternate<br />
index is based.<br />
Application owning region (AOR). A CICS<br />
region that does not own terminals or files but<br />
which purely runs CICS transactions, relying<br />
upon terminal-owning and file-owning regions for<br />
terminal and file access.<br />
Automatic class selection (ACS). A facility that<br />
allows a DFSMS system to decide which<br />
constructs (data class, storage class,<br />
management class or storage group) should be<br />
associated with a data set based on definition<br />
attributes.<br />
Automatic restart manager (ARM). An OS/390<br />
component that provides recovery and restart<br />
capabilities.<br />
Back-out. Undo all changes made to a<br />
protected resource since the previous sync point.<br />
Basic sequential access method (BSAM). An<br />
access method for sequentially organized<br />
non-<strong>VSAM</strong> data that relies on an application<br />
program to block and unblock data records.<br />
CEMT. A CICS-supplied transaction used to<br />
invoke all the master terminal functions. These<br />
functions include inquiring and changing the<br />
value of parameters used by CICS, altering the<br />
status of system resources, terminating tasks and<br />
shutting down CICS.<br />
Cluster. A named <strong>VSAM</strong> structure consisting of a<br />
group of one or more related components.<br />
Consistent read (CR). A read operation where a<br />
share lock is obtained and released as part of the<br />
read process. This ensures that the reader sees<br />
the latest committed copy of the record as at the<br />
time of the read.<br />
Consistent read explicit (CRE). A share lock is<br />
obtained as part of the read process and held<br />
until explicitly released. This ensures that a<br />
subsequent read while the lock is still held will<br />
always return the same version of the data.<br />
Control area (CA). A fixed-size area in which<br />
<strong>VSAM</strong> stores control intervals. It is the unit of<br />
allocation for <strong>VSAM</strong> data.<br />
Control interval (CI). A fixed-length area in<br />
which <strong>VSAM</strong> stores records. It is the unit of<br />
transfer between <strong>VSAM</strong> and disk storage.<br />
Coupling facility (CF). The hardware that<br />
provides services to support data shared<br />
between OS/390 systems.<br />
Coupling facility control code (CFCC). The<br />
software running within a Coupling Facility that<br />
provides Coupling Facility services.<br />
Cross-system coupling facility (XCF). An MVS<br />
component that provides services for the<br />
exchange of messages between members of a<br />
sysplex.<br />
DFHLSCU. A CICS-supplied utility to calculate<br />
space needed and average buffer size for log<br />
streams.<br />
DFR. An ACB parameter affecting buffer writing<br />
when a data set is opened for LSR or GSR. It<br />
defers the writing of a buffer until explicitly<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 477
equested to do so or until a buffer is needed for a<br />
read request.<br />
DFSMS. OS/390 component replacing<br />
DFSMS/MVS.<br />
DFSMS/MVS. A System/390 licensed program<br />
that provides storage data and device<br />
management functions. It comprises DFSMSdfp,<br />
DFSMSdss, DFSMShsm and DFSMSrmm.<br />
Entry-sequenced data set (ESDS). A data set<br />
whose records are loaded without regard to their<br />
contents and whose relative byte addresses<br />
cannot change. New records are added at the<br />
end of the data set.<br />
Exclusive lock. A lock used to permit a resource<br />
to be updated. An exclusive lock can only be<br />
obtained if no other user holds a lock on the<br />
resource. See also share lock.<br />
External CICS interface (EXCI). A method of<br />
invoking CICS services from outside CICS, for<br />
example, by batch jobs.<br />
File owning region (FOR). A CICS region that is<br />
configured so that its only function is to own and<br />
access CICS files on behalf of other CICS<br />
regions.<br />
Forward recovery. The process of applying the<br />
records contained in a redo log to redo the<br />
changes made to a data set in the event that a<br />
data set is lost or damaged and must be<br />
recovered from a backup copy.<br />
GET NUP. A macro that reads a record from a<br />
<strong>VSAM</strong> data set and, through specifications in the<br />
RPL parameters, informs <strong>VSAM</strong> that the record<br />
will not be updated or deleted.<br />
GET UPD. A macro that reads a record from a<br />
<strong>VSAM</strong> data set and, through specifications in the<br />
RPL parameters, informs <strong>VSAM</strong> that the record<br />
will be updated or deleted so that <strong>VSAM</strong> can<br />
obtain the appropriate locks.<br />
GETIX. A <strong>VSAM</strong> macro that allows you to read an<br />
index control interval directly. It is normally used<br />
only for index maintenance and repair.<br />
Global resource serialization (GRS). A<br />
component of OS/390 used for serializing the use<br />
of system resources.<br />
478 <strong>VSAM</strong> <strong>Demystified</strong><br />
Global shared resources (GSR). A form of<br />
<strong>VSAM</strong> processing that uses a buffer pool that is<br />
shared dynamically between users in several<br />
address spaces. The buffer pool is used to satisfy<br />
I/O requests without a physical I/O.<br />
Harden. Write to a non-volatile medium such as<br />
disk or a log stream.<br />
Integrated catalog facility (ICF). A cataloging<br />
scheme that comprises basic catalog structure<br />
(BCS) catalogs and multiple <strong>VSAM</strong> volume data<br />
sets (VVDSs).<br />
Integrated cluster bus (ICB). A form of link<br />
between a processor and a Coupling Facility.<br />
Internal coupling channel (IC). A link between<br />
OS/390 and a Coupling Facility running in the<br />
same physical processor complex.<br />
IDCAMS. A utility program that provides<br />
services in support of <strong>VSAM</strong> data sets.<br />
Instance. An instance of DFSMStvs is the single<br />
version ofDFSMStvs running in one z/OS image<br />
and defined by the IGDSMSxx PARMLIB member<br />
for that z/OS image.<br />
Inter-system coupling (ISC). A old type of link<br />
between a processor and a Coupling Facility,<br />
superseded by an ICB link for distances below<br />
seven meters with suitable processors.<br />
Java Database Connection (JDBC). A set of<br />
interfaces and protocols originally designed for<br />
Java applications to be able to access relational<br />
databases.<br />
Key-sequenced data set (KSDS). A <strong>VSAM</strong> data<br />
set whose records are loaded by ascending key<br />
sequence and controlled by an index.Records are<br />
retrieved and stored by keyed access or<br />
addressed access and new records are inserted<br />
in key sequence because of free space allocated<br />
within the data set. Relative byte addresses of<br />
records can change because of control interval or<br />
control area splits.<br />
Logical partition. A subset of the processor<br />
hardware that is defined to support an operating<br />
system.<br />
Local shared resources (LSR). A form of <strong>VSAM</strong><br />
processing that uses a buffer pool that is shared
dynamically between all users in one address<br />
space. The buffer pool is used to satisfy I/O<br />
requests without a physical I/O.<br />
MIPS. Million Instructions per second.<br />
NDF. Not deferred. See DFR.<br />
No read integrity (NRI). A form of read operation<br />
performed without locking so that the record<br />
returned may contain uncommitted data.<br />
Note string position (NSP). For direct access to<br />
<strong>VSAM</strong> data sets, this RPL parameter requests<br />
that <strong>VSAM</strong> remembers the position in the data set<br />
for subsequent sequential access.<br />
Non-shared resources (NSR). A form of <strong>VSAM</strong><br />
processing that provides static buffering on a per<br />
data set basis.<br />
OS/390. OS/390 is an operating system for<br />
System/390 processors consisting of more than<br />
50 base elements and integrated optional<br />
features including MVS and DFSMS.<br />
Parallel sysplex. A sysplex with at least one<br />
coupling facility.<br />
POINT. A macro that allows you to position to a<br />
specified record within a <strong>VSAM</strong> data set in<br />
preparation for a subsequent read or write.<br />
Processor resource/system manager<br />
(PR/SM). The feature that allows a processor<br />
to use several OS/390 images simultaneously by<br />
providing logical partitions.<br />
PUTIX. A macro that allows you to write a <strong>VSAM</strong><br />
index control interval directly. It is normally used<br />
only for index maintenance and repair.<br />
Queued sequential access method (QSAM).<br />
An access method for sequentially organized<br />
non-<strong>VSAM</strong> data that automatically blocks and<br />
unblocks data records on behalf of an application<br />
program.<br />
Record level sharing. A <strong>VSAM</strong> extension that<br />
provides direct access to a <strong>VSAM</strong> data set from<br />
multiple systems, providing cross system locking<br />
and buffer invalidation.<br />
Resource recovery services (RRS). An MVS<br />
component that provides sync point management<br />
facilities to coordinate resource recovery for<br />
programs that issue commit and back-out<br />
requests to participating resource managers.<br />
Redo. See forward recovery.<br />
Relative record data set (RRDS). A type of<br />
<strong>VSAM</strong> data set containing fixed length records<br />
which are accessed by relative record number.<br />
Request parameter list (RPL). A macro that is<br />
used by programs to specify parameters for I/O<br />
requests to <strong>VSAM</strong> data sets identified by an ACB.<br />
Resource access control facility (RACF). An<br />
IBM licensed program which is a base element of<br />
OS/390 and provides access control by<br />
identifying and verifying users, authorizing<br />
access to protected resources, logging detected<br />
unauthorized attempts to enter the system, and<br />
logging detected accesses to protected<br />
resources.<br />
Retained lock. The status of a lock when the<br />
subsystem executing a transaction fails. A<br />
request incompatible with a retained lock is<br />
rejected, rather than queued as would be the<br />
case for an active (not retained) lock. Retained<br />
status should be cleared when recovery is<br />
complete.<br />
Share lock. A lock used to serialize read access<br />
with update access to the same resource. Many<br />
users can hold a share lock, denoting that they<br />
are all reading the resource. If there is an<br />
exclusive lock held for a resource, a request for a<br />
share lock is queued. If there is an share lock<br />
held for a resource, another request for a share<br />
lock is granted. See also exclusive lock.<br />
Sharing control data set (SHCDS). The<br />
repository for data required to ensure the integrity<br />
of a data sharing environment in the event of the<br />
loss of a coupling facility cache or lock structure.<br />
Shunt. The process of putting aside a unit of<br />
recovery that can neither committed not backed<br />
out due to an error (such as an I/O error on one of<br />
the data sets involved).<br />
Shunt log. A secondary undo log in which a<br />
record of the before image of records in data sets<br />
are written before changing those records.<br />
Records are moved to the secondary undo log<br />
from the primary undo log when DFSMStvs is<br />
Glossary 479
unable to complete back-out processing for them,<br />
usually because a resource is unavailable.<br />
Sphere. A logical group of related <strong>VSAM</strong><br />
components containing both data and index.<br />
SOD. Statement of Direction.<br />
Storage Management Subsystem (SMS). An<br />
operating environment that helps to automate<br />
and centralize the management of storage. SMS<br />
provides a storage administrator with control over<br />
data class, storage class, management class,<br />
storage group and ACS routine definitions.<br />
Sysplex. A collection of MVS or OS/390 systems<br />
with a single common time reference that<br />
cooperate to process work and communicate<br />
using XCF.<br />
Terminal owning region (TOR). A CICS region<br />
that is configured to act only as the interface<br />
between terminals (or distributed systems<br />
appearing as CICS terminals) and an application<br />
owning region<br />
Unit of recovery. Work done by or on behalf of a<br />
context between one point of consistency and<br />
another.<br />
Unit of recovery ID (URID). The unique<br />
identification of a unit of recovery.<br />
UPAD. <strong>VSAM</strong> exit for user processing during a<br />
<strong>VSAM</strong> request.<br />
Variable relative record data set (VRRDS). A<br />
type of <strong>VSAM</strong> data set containing fixed or<br />
variable length records which are accessed by<br />
relative record number.<br />
Virtual storage access method (<strong>VSAM</strong>). If you<br />
need to check this, stop reading the book.<br />
XCF. See Cross-system coupling facility.<br />
480 <strong>VSAM</strong> <strong>Demystified</strong>
Related publications<br />
IBM Redbooks<br />
The publications listed in this section are considered particularly suitable for a<br />
more detailed discussion of the topics covered in this redbook.<br />
For information on ordering these publications, see “How to get IBM Redbooks”<br />
on page 482. Note that some of the documents referenced here may be available<br />
in softcopy only.<br />
► CICS and <strong>VSAM</strong> Record Lavel Sharing: Implementation Guide, SG24-4766<br />
► CICS and <strong>VSAM</strong> Record Lavel Sharing: Planning Guide, SG24-4765<br />
► CICS and <strong>VSAM</strong> Record Lavel Sharing: Recovery Considerations,<br />
SG24-4768<br />
► DFSMS/MVS V1R4 Technical Guide, SG24-4892<br />
► Transactional <strong>VSAM</strong> Application Migration Guide, SG24-6145<br />
► OS/390 Parallel Sysplex Configuration: Overview, Volume 1, SG24-5637<br />
► OS/390 Parallel Sysplex Configuration Cook Book, Volume 2, SG24-5638<br />
► OS/390 Parallel Sysplex Configuration: Connectivity, Volume 3, SG24-5639<br />
Other publications<br />
These publications are also relevant as further information sources:<br />
► z/OS DFSMS Managing Catalogs, SC26-7409<br />
► z/OS DFSMS Using Data Sets, SC26-7410<br />
► z/OS DFSMSdfp Storage Administration Reference, SC26-7402<br />
► z/OS DFSMS Access Method Services for Catalogs, SC26-7394<br />
► z/OS MVS Setting Up a Sysplex, SA22-7625<br />
► z/OS MVS Programming: Resource Recovery, SA22-7616<br />
► z/OS MVS Diagnosis: Tools and Service Aids, GA22-7589<br />
► z/OS MVS Programming: MVS Assembler Services Guide, SA22-7605<br />
► z/OS MVS Programming: Authorized Assembler Services, SA22-7610<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 481
Online resources<br />
482 <strong>VSAM</strong> <strong>Demystified</strong><br />
► z/OS DFSMStvs Planning and Operating Guide, SC26-7348<br />
► CICS <strong>VSAM</strong> Recovery Implementation Guide, SH26-4126<br />
► CICS Recovery and Restart Guide, SC33-1698<br />
► DFSMStvs Administration Guide, GC26-7483<br />
These Web sites and URLs are also relevant as further information sources<br />
► IBM Storage Web site<br />
http://www.storage.ibm.com/software/sms/details.html#RLS<br />
► IBM Coupling Facility sizer<br />
http://www-1.ibm.com/servers/eserver/zseries/cfsizer/vsamrls.html<br />
► z/OS RMF<br />
http://www.ibm.com/servers/eserver/zseries/rmf<br />
► Catalog and <strong>VSAM</strong> Knowledge Base<br />
http://knowledge.storage.ibm.com<br />
► DFSMS Technical Support<br />
http://ssddom02.storage.ibm.com/techsup/webnav.nsf/support/dfsms<br />
► TRSMAIN Utility<br />
http://techsupport.services.ibm.com/390/trsmain.html<br />
► Flashes<br />
http://www-1.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/Flashes<br />
How to get IBM Redbooks<br />
You can search for, view, or download Redbooks, Redpapers, Hints and Tips,<br />
draft publications and Additional materials, as well as order hardcopy Redbooks<br />
or CD-ROMs, at this Web site:<br />
ibm.com/redbooks
Help from IBM<br />
IBM Support and downloads<br />
ibm.com/support<br />
IBM Global Services<br />
ibm.com/services<br />
Related publications 483
484 <strong>VSAM</strong> <strong>Demystified</strong>
Index<br />
Numerics<br />
64 bit 240<br />
A<br />
ACB 235<br />
ACCBIAS 233<br />
access method control block 239<br />
access method services 33<br />
access to SHCDS 263<br />
access types 4<br />
active lock 477<br />
ADR 230<br />
AIX 14<br />
AKP 357<br />
algorithm 208<br />
ALLOCATE 237, 358<br />
allocate 254<br />
allocate SHCDS 254<br />
ALLOCATE TSO command 32<br />
ALTER 237, 358<br />
alternate index 14–15<br />
AMS 10, 14<br />
Analyze 210<br />
AOR<br />
See Application Owning Region 331<br />
API examples 364<br />
application 335<br />
Application Owning Region 331<br />
Application programming interfaces 39<br />
asynchronous 284<br />
atomic updates 326<br />
ATRB 230<br />
AVGREC 233<br />
B<br />
backward recovery<br />
definition 326<br />
base cluster 68<br />
batch local shared resources 92<br />
BCS 172, 237<br />
BDC000022923 267<br />
BLDINDEX 14<br />
BLDVRP macro 77<br />
BMFTIME 275, 357<br />
broken index 169<br />
BSAM 26<br />
buffer pools 119<br />
buffering 119<br />
buffers 65<br />
BUFND 67, 233<br />
BUFNI 67, 233<br />
BUFSP 67, 233<br />
BWO 175, 233, 237, 358–359<br />
C<br />
CA 10<br />
cache 126<br />
cache candidates 412<br />
cache modes 402<br />
cache structures<br />
defining 256<br />
mulitple 257<br />
cache usage attributes 409<br />
CACHETIME 357<br />
calculation 208<br />
CATALOG 233<br />
catalog LOCATE 424<br />
catalog management 4<br />
catalog performance 162, 421<br />
catalog contention 424<br />
catalog LOCATE 424<br />
ENQ times 423<br />
GRS configuration 426<br />
LPAR considerations 425<br />
catalog recovery 155<br />
catalog search interface 141, 231<br />
catalogs 102<br />
CBUF 225, 227<br />
CCHHR 19<br />
CCW 9, 142<br />
CEMT 325<br />
CF cache 300<br />
CF cache structures<br />
defining to SMS 260<br />
CF hardware 283<br />
© Copyright IBM Corp. 2001, 2003. All rights reserved. 485
CF lock structures 258<br />
defining 258<br />
CF Structure<br />
System managed duplexing rebuild 279<br />
User-managed rebuild 278<br />
CF_TIME 263, 357<br />
CFCACHE 271, 276<br />
CFCC 279<br />
CFLS 270<br />
CFRM 280<br />
CF-TIME 276<br />
CFVOL 272, 276<br />
checkpoint restart 29<br />
CI 8<br />
CI/CA splits 204<br />
CICS 40<br />
CICS application 33<br />
CICS environment 244<br />
CICSVR 330<br />
CISIZE 10<br />
CISZ 233<br />
CKD 7, 28<br />
Close 235, 238<br />
CLOSE macro 239<br />
cluster 13–14<br />
COBOL 241<br />
SMB 241<br />
commands<br />
AMS DEFINE PATH 15<br />
BLDINDEX 14, 20<br />
D GRS 431<br />
D SMS,CFLS 251<br />
DIAGNOSE 150, 152, 166<br />
DISPLAY GRS,ANALYZE 432<br />
DISPLAY GRS,CONTENTION 431<br />
EXAMINE 152, 156, 165<br />
EXPORT 173<br />
F CATALOG,REPORT PERFORMANCE 432<br />
IDCAMS DEFINE 20<br />
IDCAMS EXAMINE 154<br />
IMPORT 174<br />
LISTCAT 187, 196<br />
PRINT 141<br />
REPRO 144<br />
VERIFY 146, 148, 154, 166<br />
Commit<br />
definition 327<br />
Commit coordinator 329<br />
COMPACTION 233<br />
486 <strong>VSAM</strong> <strong>Demystified</strong><br />
component 10<br />
compression dictionaries 95<br />
compression ratio, sample code 384<br />
concurrent access 244<br />
considerations 257<br />
consistent read 329, 477<br />
Consistent read explicit<br />
See Repeatable read 329<br />
consistent read explicit 477<br />
context 336<br />
control area 10<br />
splits 15<br />
control block 223<br />
control block structures 223<br />
control Interval 8<br />
control interval<br />
format 9<br />
control interval definition field 9<br />
controlled buffer pools 119<br />
count key data 7<br />
CRE 358<br />
cross invalidation 287<br />
Cross-region 224<br />
Cross-region options 224<br />
Cross-system options 225<br />
CSI 231<br />
D<br />
DADSM 240<br />
DASD 16<br />
data buffers 71<br />
Data Class construct 237<br />
data component 11<br />
data compression 28, 94<br />
data decompression 99<br />
data in virtual 24<br />
data set<br />
recoverable 330<br />
data set organizations 16<br />
data set recovery 140<br />
data sharing 226, 282<br />
data striping 28, 30, 103<br />
implementing 106<br />
JCL 107<br />
multi-layering 105<br />
recommendations 114<br />
DATACLAS 229, 233, 345<br />
DATACLASS CISIZE 358
DB2 39<br />
DCME 239, 409<br />
DDNAME 233<br />
DEADLOCK_DETECTION 263, 276, 295, 357<br />
Deadlocks 160<br />
defer write requests 80<br />
DEFINE 10, 22<br />
define 258<br />
DFR 477<br />
DFSMS 2, 230<br />
DFSMS/MVS 1.3 228<br />
DFSMS/MVS 1.4 228<br />
DFSMS/MVS 1.5 228<br />
DFSMS/MVS V1R5 2<br />
DFSMSdss 141<br />
DFSMShsm 40<br />
DFSMSrmm 40<br />
DFSMStvs 323<br />
catalog contention 428<br />
catalog performance 421<br />
catalog sharing 422<br />
defining list structures 336<br />
defining the log structures 336<br />
definitions and terms 325<br />
documentation for level 2 441<br />
GRS config 422<br />
GRS environment 426<br />
IDCAMS changes 358<br />
implementation experiences 336<br />
information APARs 441<br />
JCL changes 355<br />
locking 332<br />
logging 332<br />
LPAR considerations 422<br />
macro changes 361<br />
Messages and codes 361<br />
miscellaneous performance items 395<br />
New and changed system level commands 348<br />
overview 331<br />
problem determination 345<br />
Quiescing a Data Set 347<br />
recoverable data sets 328<br />
recovery coordination 335<br />
reducing the CICS batch window 325<br />
Sample RACF commands 345<br />
SMS constructs 345<br />
SYS1.PARMLIB changes 355<br />
the RLS connection 332<br />
using cache 409<br />
DIAGNOSE 166<br />
DIAGNOSE command 141<br />
DIR 230<br />
direct access 18–19<br />
DIRECT WEIGHT 286<br />
dirty read<br />
See No Read Integrity 329<br />
disconnect time 129<br />
DISP 227<br />
DITTO 35<br />
DIV 24<br />
DIV ACCESS 24<br />
DIV IDENTIFY 24<br />
DIV MAP 24<br />
DIV RESET 24<br />
DIV SAVE 24<br />
DO 87<br />
dump 346<br />
DYNALLOC 32<br />
Dynamic allocation 32<br />
dynamic cache management enhanced 409<br />
DYNAMIC VOLUME COUNT 233<br />
dynamic workload 299<br />
E<br />
EA 228, 230<br />
end-of-volume macro 240<br />
enhanced catalog sharing 422<br />
Enqueue 157<br />
Enqueue Manager 214<br />
entry sequenced data set 19<br />
EOV 238, 240<br />
ERASE 233<br />
ESDS 10, 27, 237<br />
types of access<br />
sequential access 19<br />
ESS 134<br />
EXAMINE 140, 165<br />
EXCEPTIONEXIT 233<br />
EXCI<br />
See also External CICS Interface<br />
Exclusive lock 332, 478<br />
EXLST 233<br />
EXPDT 233<br />
EXTENDED ADDRESSABILITY 233<br />
extended addressability 28–29, 228, 278<br />
macros 230<br />
EXTENDED FORMAT 233<br />
Index 487
extended format 28, 134<br />
extended format data set 230<br />
External CICS Interface 325<br />
F<br />
Failing Module 346<br />
FALLBACK 267<br />
False contention 251<br />
False/False contention 251<br />
File Owning Region 331<br />
file owning region 248<br />
FOR 247<br />
See File Owning Region 331<br />
Forward recovery 478<br />
definition 326<br />
free space 208<br />
FREESPACE 56, 233<br />
FRLOG 234<br />
FTP 211<br />
functions by release level 2<br />
G<br />
General share options 226<br />
Generalized Trace Facility 137<br />
generic compression 97<br />
generic key 18<br />
GET 5, 241<br />
global shared resources 80<br />
GRS 226<br />
GRS configuration 422, 426<br />
GRS Ring configuration 422<br />
GRS Star configuration 422<br />
GSR 80, 219<br />
GTF 137<br />
GTF procedure example 387<br />
H<br />
Hangs 347<br />
HARBA 6, 193, 240<br />
haring Control 253<br />
HFS 39<br />
files, accessing 39<br />
hierarchical file system 39<br />
High allocated RBA 6<br />
high used RBA 6, 53<br />
hiperbatch 121<br />
hiperspace 85<br />
488 <strong>VSAM</strong> <strong>Demystified</strong><br />
history 2<br />
HSMplex 40<br />
HURBA 6, 192, 240<br />
I<br />
I/O 119<br />
I/O Service Time 129<br />
ICF 4<br />
ICF catalog 330<br />
IDCAMS 22, 27, 32–33, 163<br />
using to define a <strong>VSAM</strong> data set 32<br />
IDCAMS DEFINE 32, 237<br />
IDCAMS LISTCAT 148<br />
IEC161I 10<br />
IFAPRDxx 355<br />
IGDMSMSxx<br />
DEADLOCK_DETECTION 262<br />
IGDSMSxx 262, 281<br />
RLS_MAX_POOL_SIZE 263<br />
IGGCSILK 232<br />
IGGCSIRX 232<br />
IGGCSIVG 232<br />
IGGCSIVS 141, 232<br />
IGW8 346<br />
IGW9 346<br />
IGWLOCK00 268, 293<br />
IGWVRNSA 346<br />
II08859 APAR 178<br />
index 11<br />
index component 11<br />
index marker 7<br />
index options 58<br />
index set 12<br />
In-doubt unit of recovery 329<br />
INDXCISZ 211<br />
inflight 348<br />
In-flight and in-doubt 329<br />
In-flight unit of recovery 329<br />
information APARs 441<br />
initial load 59, 144<br />
initial load mode 59, 73<br />
Instance 478<br />
Transactional <strong>VSAM</strong> 333<br />
integrated catalog facility 4<br />
integrity 216<br />
invalid rules-of-thumb 48<br />
IOSQ 125<br />
IXCCONN 225
IXCMSGI 225<br />
IXCMSGO 225<br />
IXLVECTR 289<br />
J<br />
JCL 242<br />
JCL DD 32<br />
JCL DISP 218<br />
JRIO 40<br />
K<br />
key field 6<br />
key range 29, 58<br />
KEYEDEXG 108<br />
KEYEDEXT 111<br />
KEYLEN 234<br />
KEYOFF 234<br />
knowledge database 178<br />
KSDS 10, 27, 229, 237, 278<br />
L<br />
lab environment 395<br />
cache concepts 399<br />
LDS 10, 23, 28, 237<br />
LIKE 234<br />
linear data set 23<br />
LISTCAT command 141<br />
local buffer pool 285<br />
local shared resources 77<br />
lock contentions 259<br />
lock structure size 258<br />
lock structures 289<br />
Locks 266<br />
Exclusive 332<br />
Share 332<br />
LOG 234, 359<br />
Log 355<br />
Log of logs 334<br />
LOG(ALL) attribute 330<br />
LOG(NONE) 330<br />
LOG(UNDO) 330<br />
LOG_OF_LOGS 357<br />
logical record 5<br />
ways to identify 6<br />
LOGREC 142<br />
LOGSTREAMID 234, 359<br />
logstreamid 352<br />
Lost Locks 252<br />
LRD 230<br />
LRECL 234<br />
LRUCYCLES 275<br />
LRUTIME 275<br />
LSR 77, 79, 241<br />
LSR buffering 79<br />
M<br />
MACRF 66, 234<br />
macros 230<br />
Management Class 238<br />
MANAGEMENTCLASS 234<br />
Managing 203<br />
Mapping 24<br />
MAXLOCKS 358<br />
Media Manager 238, 240<br />
messages<br />
ARC0909E 207<br />
IDC11709I 145<br />
IDC11712I 145<br />
IDC11727I 146<br />
IDC3009I 181<br />
IDC3308I 144<br />
IDC33351I 61<br />
IDC3350I 146<br />
IDC3351I 143–145, 147, 149–150, 153, 155,<br />
231<br />
IEC070I 141<br />
IEC161I 143<br />
IOS000 141<br />
IOS000I 147<br />
MGMTCLAS 234, 345<br />
MIPS 297<br />
MONDS 273<br />
MVS Commands<br />
RLS 268<br />
N<br />
no read integrity 329<br />
NOERASE 233<br />
Non-recoverable data set 330<br />
Non-recoverable sphere 252<br />
non-RLS 214<br />
non-shared resources 68, 70, 74<br />
NORECATALOG 234<br />
NOREUSE 234<br />
NRI<br />
Index 489
See No Read Integrity 329<br />
NSR 70, 74, 241<br />
NUMBERED 22<br />
O<br />
OEM 241<br />
online transaction program 78<br />
OPEN 240<br />
Open 235, 238<br />
OPEN macro 239<br />
OPTCD 230<br />
P<br />
Parallel Sysplex 214<br />
parameters<br />
ACB 66<br />
buffer allocation 65<br />
BUFFERSPACE 67<br />
BUFND 67<br />
BUFNI 67<br />
BUFSP 67<br />
FREESPACE 56<br />
MACRF 66<br />
performance 49<br />
SHAREOPTIONS 58<br />
STRNO 75<br />
PARMLIB 355<br />
partial release 53<br />
partial space release 28<br />
path 15<br />
PEERRECOVERY 355<br />
performance 43, 282, 297<br />
BSLR 92<br />
buffer allocation 68<br />
buffer location 81<br />
buffering options 63<br />
buffering techniques 68<br />
buffers 71<br />
CA size 113<br />
CI size 54<br />
compression 100–101<br />
connect time 130<br />
constraint Relief 54<br />
control area 52<br />
control interval 54<br />
data buffers 73<br />
data compression 94<br />
data striping 31, 103, 114<br />
490 <strong>VSAM</strong> <strong>Demystified</strong><br />
global shared resources 80<br />
guaranteed space 50<br />
HARBA 53<br />
I/O 46<br />
I/O response time 64<br />
index buffers 75<br />
index component buffers 77<br />
index I/O buffer 72<br />
IOS queue time 125<br />
KSDS 75<br />
lab environment 398<br />
management 46–47<br />
optimizing CA size 52<br />
parameters 49<br />
REGION 63<br />
resource pool 64<br />
response time 132<br />
RMF 115<br />
rule-of-thumb 48<br />
service level agreement<br />
SLA 44<br />
SMB 83<br />
transaction 44<br />
physical record 7<br />
Planning for RLS 253<br />
PRINT command 141<br />
problem determination 139<br />
processing<br />
direct 19<br />
direct access 18<br />
KSDS 17<br />
relative record 22<br />
sequential 19<br />
sequential access 17<br />
processing options 233<br />
Q<br />
QSAM 26<br />
QTIMEOUT 357<br />
QUIESCE 275<br />
Quiesce 252<br />
Quiesce a volume or a cache 252<br />
Quiesce transactions 252<br />
R<br />
RACF 121, 263<br />
SHCDS considerations 263<br />
RAID 52, 238
andom access 4<br />
RBA 6, 236, 239<br />
RDF 9, 21<br />
Read Integrity 251<br />
RECATALOG 234<br />
record definition field 9<br />
record definition fields 9<br />
Record Level Sharing 214<br />
record management 5, 241<br />
RECORDSIZE 234<br />
RECORG 234<br />
recoverable 330<br />
Recoverable data set 330<br />
RECOVERY 60, 125<br />
recovery 139, 327<br />
scenarios 169<br />
task abend 171<br />
VVDS records 172<br />
recovery termination manager 64<br />
Redbooks Web site 482<br />
Contact us xxiii<br />
Redo log 326<br />
Relative byte address 6<br />
relative byte address<br />
HARBA 6<br />
HURBA 6<br />
relative record data set 21<br />
relative record number 6–7<br />
Reorganization 204<br />
Repeatable read 329<br />
Resource Manager 335<br />
Resource Measurement Facility 282<br />
resource recovery management services 199<br />
restrictions 249<br />
Retained lock 479<br />
RETPD 234<br />
REUSE 234<br />
REXX 231–232<br />
RLIST 263<br />
RLS 2, 162, 214, 235, 244, 278<br />
batch performance 300<br />
cache size 257<br />
CF access time 295<br />
CF cache structures 256<br />
CF lock structures 258<br />
CF structure duplexing 278<br />
CICSPlex performance 299<br />
Deadlocks 295<br />
enhancements 278<br />
I/O workload 293<br />
IGDSMSxx parmlib member 262<br />
implementing 253<br />
lock structure duplexing 293<br />
MVS commands 268<br />
performance 282<br />
recoverable spheres 265<br />
Recoverable <strong>VSAM</strong> spheres 294<br />
RMF 306<br />
SHCDS 253<br />
SMF records 321<br />
RLS rules 267<br />
RLS_DynamicCfCacheReassign 281<br />
RLS_MAX_POOL_SIZE 356<br />
RLS_MAXCFFEATURELEVEL 275, 281<br />
RLSINIT 356<br />
RLSREAD 235<br />
RLSTMOUT 357–358<br />
RMF 115, 136, 428<br />
RMF reporting options 429<br />
RMODE31 81, 235<br />
RNL 226<br />
RNN 21<br />
ROT (rule of thumb) 47<br />
RRDS 10, 22, 27, 237<br />
RRN 7, 236<br />
RTA000141603 267<br />
rule of thumb (ROT) 47<br />
S<br />
sample code 363<br />
extract data from SMF 64 record 367<br />
JRIO APIs 364<br />
<strong>VSAM</strong> shared information 366<br />
Sample JCL 254<br />
Sample program to extract information 367<br />
Secondary space allocations 124<br />
See External CICS Interface<br />
SEQ 230<br />
sequence set 11<br />
sequential access 4<br />
SEQUENTIAL WEIGHT 286<br />
Serialization 292<br />
serialization at record level 292<br />
SET SMS 354<br />
SETSMS 275, 354<br />
Share lock 332, 479<br />
SHAREOPTION 235<br />
Index 491
SHAREOPTIONS 58, 72, 218, 224–225, 325, 358<br />
sharing<br />
global resource sharing 226<br />
options 226<br />
sharing mechanisms 216<br />
SHCDS 266, 273, 277, 283<br />
considerations 255<br />
defining 253<br />
RACF 263<br />
space allocation 254<br />
SHCDS RACF considerations 263<br />
SHR options 58<br />
Shunt 479<br />
Shunt log 334<br />
SHUNTED 350<br />
sizer tool 210<br />
skip sequential access 4<br />
SMB 2, 82, 237<br />
SMBDFR 85<br />
SMBHWT 85<br />
SMBVSP 85<br />
SMF 102, 194<br />
SMF_TIME 356<br />
SMFIOCNT 239<br />
SMFLSR 380<br />
SMFRLS, sample program 387<br />
SMS constructs 237, 345<br />
SMS definitions 260<br />
SMS managed 73<br />
SMS<strong>VSAM</strong> 250, 263, 266, 273, 277, 285<br />
bufferring and caching 285<br />
SPACE 235<br />
SPACE CONSTRAINT RELIEF 235<br />
space constraint relief 176<br />
spanned records 10<br />
Special Considerations 241<br />
SPEED 60<br />
SPHERE 355<br />
sphere 14, 264<br />
splits 15, 124<br />
FREESPACE parameter 56<br />
STARTIO 239<br />
Statement of Direction (SOD) 238<br />
Storage Class 238<br />
STORCLAS 345<br />
Subsystem 250<br />
SVC 121 238<br />
Synchronization point 327<br />
Synchronous 284<br />
492 <strong>VSAM</strong> <strong>Demystified</strong><br />
Syncpoint manager 335<br />
SYS1.PARMLIB 281<br />
SYS1.SAMPLIB 232<br />
SYSDSN 218, 227<br />
SYSNAME 357<br />
Sysplex 217<br />
System Logger 332<br />
system managed buffering 82, 237<br />
system-managed buffering 28<br />
system-managed duplexing rebuild 279<br />
SYS<strong>VSAM</strong> 226<br />
T<br />
tailored compression 97<br />
TDS 137<br />
TESTCB 230<br />
Tivoli Decision Support 137<br />
TRAN<strong>VSAM</strong> 348, 355<br />
TRSMAIN 211<br />
True/False contention 251<br />
TV_START_TYPE 357<br />
TVSNAME 357<br />
Two-phase commit 328<br />
U<br />
UNDO attribute 330<br />
Undo log 326<br />
Unit of recovery 327, 480<br />
Unit of work 327<br />
V<br />
variable relative record 22<br />
variable relative record data set 22<br />
VARY SHCDS 263–264<br />
VERIFY 166<br />
VERIFY command 140<br />
virtual storage 143<br />
VRRDS 10, 27, 208, 237<br />
<strong>VSAM</strong> 2<br />
access types 4<br />
Accessing <strong>VSAM</strong> cluster 33<br />
Allocating a <strong>VSAM</strong> cluster 31<br />
alternate indexes 14<br />
buffering 133<br />
catalog management 4<br />
cluster 13–14<br />
Comparing <strong>VSAM</strong> data set organizations 24
data set organizations 16<br />
data set recovery 140<br />
Data striping 30<br />
defining clusters 32<br />
entry sequenced data set 19<br />
exploiters 38–39<br />
extended addressability 29, 228<br />
extended format 28<br />
Extended format data set 28<br />
functions by release level 2<br />
history 2<br />
integrity 58<br />
key field 6<br />
keyed sequenced data set 16<br />
linear data set 23<br />
logical record 5<br />
managing data sets 203<br />
non-shared resources 68, 74<br />
organizations 26<br />
performance 43<br />
performance management 115<br />
physical record 7<br />
record management 5<br />
recovery 145–146, 148, 150, 152, 154<br />
relative record number 21<br />
sharing 153<br />
SMB 82<br />
structural damage 150<br />
terminology and concepts 5<br />
VRRDS 22<br />
<strong>VSAM</strong> buffering 16<br />
<strong>VSAM</strong> Shared Information 366<br />
<strong>VSAM</strong>/ISAM 242<br />
VSI 225, 366<br />
VTAM 331<br />
VTOC 10, 102<br />
VVDS entries 237<br />
W<br />
WLM 44<br />
Workload Manager 44<br />
Write and read integrity 215<br />
Write checks 124<br />
X<br />
XADDR 230<br />
XAVSPAC 230<br />
XCF 331<br />
XENDRBA 230<br />
XHALCRBA 230<br />
XRBA 230<br />
Z<br />
z/OS V1 R3 208, 210<br />
z/OS V1 R4 or later 279<br />
z/OS V1R4 DFSMS 238, 240<br />
zFS<br />
zSeries file system 39<br />
Index 493
494 <strong>VSAM</strong> <strong>Demystified</strong>
(1.0” spine)<br />
0.875”1.498”<br />
460 788 pages<br />
<strong>VSAM</strong> <strong>Demystified</strong>
<strong>VSAM</strong> <strong>Demystified</strong><br />
Learn the latest<br />
<strong>VSAM</strong> functions and<br />
manage <strong>VSAM</strong> data<br />
Understand,<br />
evaluate, and use<br />
<strong>VSAM</strong> properly<br />
Problem<br />
determination and<br />
recommendations<br />
SG24-6105-01 ISBN 0738453234<br />
Back cover<br />
Virtual Storage Access Method (<strong>VSAM</strong>) is one of the<br />
access methods used to process data. Many of us have<br />
used <strong>VSAM</strong> and work with <strong>VSAM</strong> data sets daily, but<br />
exactly how it works and why we use it instead of<br />
another access method is a mystery.<br />
This book helps to demystify <strong>VSAM</strong> and gives you the<br />
information necessary to understand, evaluate, and use<br />
<strong>VSAM</strong> properly. It clarifies <strong>VSAM</strong> functions for<br />
application programmers who work with <strong>VSAM</strong>. The<br />
practical, straightforward approach should dispel much<br />
of the complexity associated with <strong>VSAM</strong>. Wherever<br />
possible an example is used to reinforce a description<br />
of a <strong>VSAM</strong> function.<br />
This IBM Redbook is intended as a supplement to<br />
existing product manuals. It is intended to be used as<br />
an initial point of reference for <strong>VSAM</strong> functions.<br />
This book also builds upon the subject of Record Level<br />
Sharing and the new z/OS feature called DFSMStvs.<br />
INTERNATIONAL<br />
TECHNICAL<br />
SUPPORT<br />
ORGANIZATION<br />
®<br />
BUILDING TECHNICAL<br />
INFORMATION BASED ON<br />
PRACTICAL EXPERIENCE<br />
IBM Redbooks are developed by<br />
the IBM International Technical<br />
Support Organization. Experts<br />
from IBM, Customers and<br />
Partners from around the world<br />
create timely technical<br />
information based on realistic<br />
scenarios. Specific<br />
recommendations are provided<br />
to help you implement IT<br />
solutions more effectively in<br />
your environment.<br />
For more information:<br />
ibm.com/redbooks