Merging Systems Into A Sysplex Ibm Redbooks

download

https://ebookbell.com/product/merging-systems-into-a-sysplex-ibm-
redbooks-51388446

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Designing Enterprise Information Systems Merging Enterprise Modeling

And Software Specification Boris Shishkov

https://ebookbell.com/product/designing-enterprise-information-
systems-merging-enterprise-modeling-and-software-specification-boris-
shishkov-10581850

Stochastic Systems In Merging Phase Space V S Koroliuk N Limnios

https://ebookbell.com/product/stochastic-systems-in-merging-phase-
space-v-s-koroliuk-n-limnios-4108094

Merging Optimization And Control In Power Systems Physical And Cyber

Restrictions In Distributed Frequency Control And Beyond 1st Edition
Feng Liu

https://ebookbell.com/product/merging-optimization-and-control-in-
power-systems-physical-and-cyber-restrictions-in-distributed-
frequency-control-and-beyond-1st-edition-feng-liu-45413710

Merging Wright Road Trips Romance Lb Dunbar

https://ebookbell.com/product/merging-wright-road-trips-romance-lb-
dunbar-46532052
Merging With Iva Hinduisms Contemporary Metaphysics Satguru Sivaya
Subramuniyaswami

https://ebookbell.com/product/merging-with-iva-hinduisms-contemporary-
metaphysics-satguru-sivaya-subramuniyaswami-2367838

Merging Processes In Galaxy Clusters Softcover Reprint Of Hardcover

1st Ed 2002 L Feretti

https://ebookbell.com/product/merging-processes-in-galaxy-clusters-
softcover-reprint-of-hardcover-1st-ed-2002-l-feretti-2624902

Merging With Siva Hinduisms Contemporary Metaphysics Sixth Satguru

Sivaya Subramuniyaswami

https://ebookbell.com/product/merging-with-siva-hinduisms-
contemporary-metaphysics-sixth-satguru-sivaya-
subramuniyaswami-34586390

Merging Numeracy With Literacy Practices For Equity In Multilingual

Early Year Settings Robyn Jorgensen

https://ebookbell.com/product/merging-numeracy-with-literacy-
practices-for-equity-in-multilingual-early-year-settings-robyn-
jorgensen-37244434

Merging Processes In Galaxy Clusters 1st Edition Craig L Sarazin Auth

https://ebookbell.com/product/merging-processes-in-galaxy-
clusters-1st-edition-craig-l-sarazin-auth-4490682
 Front cover

Merging Systems
ms into
a Sysplex
ex
Position for PSLC and WLC benefits

Exploit System-level Resource

Sharing

Maximize the benefits of

sysplex

Frank Kyne
Jeff Belot
Grant Bigham
Alberto Camara Jr.
Michael Ferguson
Gavin Foster
Roger Lowe
Mirian Minomizaki Sato
Graeme Simpson
Valeria Sokal
Feroni Suhood

ibm.com/redbooks
International Technical Support Organization

Merging Systems into a Sysplex

December 2002

SG24-6818-00
 Take Note! Before using this information and the product it supports, be sure to read the general
information in “Notices” on page xi.

First Edition (December 2002)

This edition applies to Version 1 Release 3 of z/OS.

Comments may be addressed to:

IBM Corporation, International Technical Support Organization
Dept. HYJ Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in
any way it believes appropriate without incurring any obligation to you.

© Copyright International Business Machines Corporation 2002. All rights reserved.

Note to U.S Government Users - Documentation related to restricted rights - Use, duplication or disclosure is subject to restrictions set
forth in GSA ADP Schedule Contract with IBM Corp.
Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Chapter 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Why this book was produced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Starting and ending points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 BronzePlex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 GoldPlex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 PlatinumPlex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Structure of each chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Are multiple subplexes supported or desirable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Considerations checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 Implementation methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.4 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Terminology and assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.1 ‘Plexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 “Gotchas” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.1 Duplicate data set names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.2 Duplicate volsers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.3 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.4 System Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.5 Sysplex HFS sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.6 Legal implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 Updates to this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Chapter 2. Sysplex infrastructure considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1 One or more XCF subplexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 CDS considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 MAXSYSTEM CDS parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2 General CDS guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Cross-System Coupling Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Considerations for merging XCFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Coupling Facility Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.1 Considerations for merging CFRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Sysplex Failure Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5.1 Considerations for merging SFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6 Automatic Restart Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6.1 Considerations for merging ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.7 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 3. System Logger considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1 One or more LOGRplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Considerations for merging System Loggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.1 System Logger fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.2 Considerations for different target environments . . . . . . . . . . . . . . . . . . . . . . . . . 39

© Copyright IBM Corp. 2002 iii

 3.2.3 Considerations for the merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Methodology for merging System Loggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Chapter 4. WLM considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1 One or more WLMplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1.1 Compatibility mode considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1.2 Configuration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 Merging WLMplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Considerations for merging WLMplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 Methodology for merging WLMplexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Chapter 5. GRS considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.1 One or more GRSplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.1 Star complex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.2 Ring complex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.3 Target environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.4 Why convert to a Star complex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 Considerations for merging GRSplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3 Methodology for merging GRSplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3.1 Merging into a Star complex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3.2 Merging into a Ring complex (sysplex matches complex) . . . . . . . . . . . . . . . . . . 80
5.3.3 Merging into a Ring complex (mixed GRS complex) . . . . . . . . . . . . . . . . . . . . . . 81
5.4 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.4.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.4.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Chapter 6. SMF considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.1 Managing your SMF data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.2 Considerations when merging systems into a sysplex . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.3 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.3.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.3.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Chapter 7. JES2 considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.1 JES2 configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.2 Methodology for merging JESplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.3 Moving to a multi-JESplex environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.4 Moving to a single JES2plex environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.4.1 SDSF considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.5 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Chapter 8. Shared HFS considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

8.1 One or more HFSplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.2 Considerations for merging HFSplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.3 Methodology for merging HFSplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.4 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.4.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.4.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Chapter 9. Language Environment considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

iv Merging Systems into a Sysplex

9.1 Language Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
9.2 LE considerations when merging systems into a sysplex . . . . . . . . . . . . . . . . . . . . . . 137
9.3 Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
9.3.1 Upward compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
9.3.2 Downward compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
9.4 LE run-time options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
9.4.1 Displaying the run-time values in batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
9.4.2 Obtaining the run-time values in CICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
9.5 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
9.5.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
9.5.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Chapter 10. System data set considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
10.2 System symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
10.3 Sharing sysres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
10.3.1 Considerations for merging sysres’. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
10.3.2 Methodology for moving to a shared sysres . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
10.4 Sharing Master Catalogs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
10.4.1 Considerations for merging Master Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . 153
10.4.2 Methodology for merging Master Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.5 Sharing Parmlib. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
10.5.1 MSTJCLxx Parmlib member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
10.5.2 COMMNDxx Parmlib member. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
10.5.3 Merging Parmlibs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
10.6 Proclibs and TSO-related files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
10.6.1 Merging Proclibs and TSO-related files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
10.7 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
10.7.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
10.7.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Chapter 11. VTAM considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

11.1 Overview of scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
11.1.1 VTAM’s job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
11.1.2 Subarea networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
11.1.3 APPN networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
11.1.4 How VTAM uses XCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
11.1.5 VTAM Generic Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
11.1.6 MultiNode Persistent Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
11.2 One or more VTAMplexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
11.3 Considerations for merging VTAMplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
11.4 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Chapter 12. TCP/IP considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

12.1 One or more TCPplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
12.1.1 Target environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
12.2 TCP/IP in a sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
12.2.1 DYNAMICXCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
12.2.2 Routing in a sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
12.2.3 Dynamic VIPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
12.2.4 DNS/WLM - Connection Optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
12.2.5 External IP workload balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
12.2.6 Sysplex Distributor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
12.2.7 TCPplex prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Contents v
 12.3 Considerations for merging TCPplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
12.4 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Chapter 13. RACF considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

13.1 One or more RACFplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
13.2 Considerations for merging RACFplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
13.3 Methodology for merging RACFplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
13.3.1 Before you start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
13.3.2 RACF exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
13.3.3 Synchronize RACF options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
13.3.4 Synchronize the Class Descriptor Table (ICHRRCDE). . . . . . . . . . . . . . . . . . . 198
13.3.5 Synchronize the router table (ICHRFR01) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
13.3.6 Global Access Checking Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
13.3.7 RACF database merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
13.3.8 Things not handled by DBSYNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
13.3.9 Password synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
13.3.10 Cutover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
13.3.11 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
13.4 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
13.4.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
13.4.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Chapter 14. SMS considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

14.1 One or more SMSplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
14.2 Considerations for merging SMSplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
14.3 Methodology for merging SMSplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
14.4 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Chapter 15. DFSMShsm considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

15.1 One or more HSMplexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
15.2 Considerations for merging HSMplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
15.3 Methodology for merging HSMplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
15.3.1 Merging the CDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
15.3.2 Backout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
15.4 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Chapter 16. DFSMSrmm considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

16.1 One or more RMMplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
16.2 Considerations for merging RMMplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
16.3 Methodology for merging RMMplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
16.3.1 Merging the CDSs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
16.3.2 Backout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
16.4 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
16.4.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
16.4.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Chapter 17. OPC considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

17.1 One or more OPCplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
17.2 Considerations for merging OPCplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
17.2.1 General notes about the merge project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
17.3 Methodology for merging OPCplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
17.3.1 Merging OPC system-related definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
17.3.2 Merging the OPC databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
17.4 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

vi Merging Systems into a Sysplex

 17.4.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
17.4.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Chapter 18. System Automation for OS/390 considerations . . . . . . . . . . . . . . . . . . . 291

18.1 One or more SA/390 environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
18.2 Checklist of considerations for merging SA/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
18.3 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
18.3.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
18.3.2 Documents and References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
18.3.3 Group forums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Chapter 19. Operations considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

19.1 One or more HMCplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
19.1.1 Considerations for merging HMCplexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
19.1.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
19.1.3 Optical and I/O error analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
19.1.4 Remote access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
19.1.5 Methodology for merging HMCplexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
19.2 Consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
19.2.1 EMCS security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
19.2.2 Systems Network Architecture (SNA) MCS . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
19.2.3 Console recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
19.2.4 Considerations for merging consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
19.2.5 Console philosophy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
19.3 General operations procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
19.3.1 IPL procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
19.3.2 Sysplex Failure Management and Automatic Restart Manager . . . . . . . . . . . . 321
19.3.3 Operational Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
19.3.4 JES2 Multi-Access Spool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
19.3.5 WLM-Managed Initiators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
19.3.6 Automatic Tape Switching (ATS Star). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
19.3.7 Shared sysres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
19.3.8 Useful Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
19.3.9 Housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
19.4 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
19.4.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
19.4.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Chapter 20. Hardware configuration considerations. . . . . . . . . . . . . . . . . . . . . . . . . . 327

20.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
20.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
20.3 Considerations when merging systems into a sysplex . . . . . . . . . . . . . . . . . . . . . . . 328
20.4 Single or multiple production IODFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
20.4.1 How many master IODFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
20.4.2 How many cloned IODFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
20.5 HCD and I/O Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
20.5.1 HCD and I/O Operations relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
20.6 Activating a new I/O configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
20.6.1 Performing the dynamic I/O reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
20.6.2 Dynamic I/O reconfiguration with more than one sysplex . . . . . . . . . . . . . . . . . 339
20.6.3 CONFIGxx Parmlib member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
20.7 IOCDS management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
20.8 Duplicate device numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
20.9 NIP console requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

Contents vii
 20.10 Eligible Device Table and esoterics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
20.11 Single or multiple OS Configs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
20.12 ESCON logical paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
20.12.1 DASD control unit considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
20.12.2 Tape control unit considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
20.12.3 Non-IBM hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
20.12.4 Switch (ESCON/FICON) port considerations . . . . . . . . . . . . . . . . . . . . . . . . . 344
20.13 CF connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
20.14 FICON/ESCON CTCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
20.14.1 ESCON CTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
20.14.2 FICON CTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
20.14.3 Differences between ESCON and FICON CTC . . . . . . . . . . . . . . . . . . . . . . . 346
20.15 Sysplex Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
20.15.1 LPAR Sysplex ETR support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
20.15.2 Parmlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
20.16 Console connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
20.17 Hardware Management Console (HMC) connectivity . . . . . . . . . . . . . . . . . . . . . . . 348
20.18 Tools and Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
20.18.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
20.18.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

Chapter 21. System exits and usermod considerations . . . . . . . . . . . . . . . . . . . . . . . 351

21.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
21.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
21.3 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
21.4 Reviewing system modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
21.5 Supporting system modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
21.5.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
21.5.2 Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
21.6 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
21.7 Useful exits and usermods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
21.7.1 Duplicate TSO logons in a JES2 MAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
21.7.2 ISPF Exit 16: Log, List, and Temporary Data Set Allocation Exit . . . . . . . . . . . 356
21.7.3 PDF Data Set Name Change Exit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
21.7.4 JES2 Exit 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

Chapter 22. Maintenance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

22.1 Controlling service, releases, and propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
22.2 Considerations when merging systems into a sysplex . . . . . . . . . . . . . . . . . . . . . . . 367
22.3 Coexistence levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
22.4 Maintenance strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
22.4.1 Maintenance options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
22.4.2 Consolidated Service Test (CST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
22.4.3 Recommended Service Upgrade (RSU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
22.4.4 How to obtain the required maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
22.4.5 Enhanced HOLDDATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
22.5 The maintenance environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
22.5.1 Suggested structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
22.5.2 HFS considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
22.5.3 Cross-product and cross-system requisite checking. . . . . . . . . . . . . . . . . . . . . 384
22.5.4 Propagation of service and releases within the sysplex . . . . . . . . . . . . . . . . . . 385
22.6 Methodology for merging maintenance environments . . . . . . . . . . . . . . . . . . . . . . . 392
22.6.1 Merge global zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

viii Merging Systems into a Sysplex

22.7 Tools and documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
22.7.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
22.7.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Appendix A. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
System requirements for downloading the Web material . . . . . . . . . . . . . . . . . . . . . . . 395
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

Contents ix
x Merging Systems into a Sysplex
Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and
distribute these sample programs in any form without payment to IBM for the purposes of developing, using,
marketing, or distributing application programs conforming to IBM's application programming interfaces.

© Copyright IBM Corp. 2002. xi

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks(logo)™ FICON™ RACF®
AIX® GDPS® RAMAC®
BatchPipes® Hiperbatch™ Redbooks™
C/MVS™ IBM® RMF™
C/2™ IMS™ S/390®
CICS® IMS/ESA® SOM®
CICSPlex® Language Environment® SOMobjects®
CUA® MQSeries® Sysplex Timer®
DB2® MVS™ TCS®
DFS™ MVS/ESA™ Tivoli®
DFSMS/MVS® NetView® TME®
DFSMSdfp™ OpenEdition® VTAM®
DFSMSdss™ OS/2® WebSphere®
DFSMShsm™ OS/390® z/Architecture™
DFSMSrmm™ PAL® z/OS™
DFSORT™ Parallel Sysplex® zSeries™
Enterprise Storage Server™ Perform™
ESCON® PR/SM™

The following terms are trademarks of other companies:

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United
States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems,
Inc. in the United States, other countries, or both.

C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic
Transaction LLC.

Other company, product, and service names may be trademarks or service marks of others.

xii Merging Systems into a Sysplex

Preface

This IBM Redbook provides information to help Systems Programmers plan for merging
systems into a sysplex. zSeries systems are highly flexibile systems capable of processing
many workloads. As a result, there are many things to consider when merging independent
systems into the more closely integrated environment of a sysplex. This book will help you
identify these issues in advance and thereby ensure a successful project.

The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the
International Technical Support Organization, Poughkeepsie Center.

Frank Kyne is a Senior I/T Specialist at the International Technical Support Organization,
Poughkeepsie Center. He has been an author of a number of other Parallel Sysplex
Redbooks. Before joining the ITSO four years ago, Frank worked in IBM Global Services in
Ireland as an MVS Systems Programmer.

Jeff Belot is an OS/390 Technical Consultant at IBM Global Services Australia. He has 28
years experience in the mainframe operating systems field. His areas of expertise include
sysplex, performance and security.

Grant Bigham is a Senior OS/390 Technical Specialist in Australia. He has 10 years of

experience in mainframe systems programming, the last 4 of which have been in IBM Global
Services. More recently, Grant has worked as a Technical Consultant within IBM GSA. His
areas of expertise include z/OS, OS/390, and Enterprise Linux.

Alberto Camara Jr. is a Customer Support Representative working for Computer Associates
in Brazil. He has 15 years of experience in operating systems and mainframe field. His areas
of expertise include storage, performance and security.

Michael Ferguson is a Senior I/T specialist in the IBM Support centre in Australia. He has 16
years of experience in the OS/390 software field. His areas of expertise include Parallel
Sysplex, OS/390 and Tivoli OPC. He has been an author of a number of Parallel Sysplex
Redbooks. Michael teaches both Parallel Syplex and Tivoli OPC courses in the Asia Pacific
region, as well as providing consulting services to customers in these areas.

Gavin Foster is an OS/390 Technical Consultant working for IBM Global Services in
Australia. He has 16 years of experience in the mainframe operating systems field. His areas
of expertise include systems programming and consultancy on system design, upgrade
strategies and platform deployment.

Roger Lowe is a Senior S/390 Technical Consultant in the Professional Services division of
Independent Systems Integrators, an IBM Large Systems Business Partner in Australia. He
has 18 years of experience in the operating systems and mainframe field. His areas of
expertise include the implementation and configuration of the OS/390 and z/OS operating
system and Parallel Sysplex.

Mirian Minomizaki Sato is a Customer Support Representative working for Computer

Associates in Brazil. She has 12 years of experience in operating systems and mainframe
field. She holds a degree in Data Processing from Faculdade de Tecnologia de Sao Paulo.
Her area of expertise is life cycle management.

© Copyright IBM Corp. 2002 xiii

 Graeme Simpson is a Senior OS390 Technical Specialist in Australia. He has 23 years of
experience in mainframe systems programming. He has worked at IBM Global Services for 7
years. His areas of expertise include OS/390 and IBM Storage Products.

Valeria Sokal is a System Programmer in a large IBM customer in Brazil. She has 12 years of
experience working on many aspects of MVS, including building and managing very large
sysplexes. She has been involved in writing a number of other IBM Redbooks.

Feroni Suhood is a Senior Performance Analyst at IBM Global Services Australia. He has 20
years experience in the mainframe operating systems field. His areas of expertise include
sysplex, performance and hardware evaluation.

Thanks to the following people for their contributions to this project:

Rich Conway
International Technical Support Organization, Poughkeepsie Center

Robert Haimowitz
International Technical Support Organization, Poughkeepsie Center

Jay Aiken
IBM USA

Cy Atkinson
IBM USA

Paola Bari
IBM USA

Frank Becker
Sparkassen-Informatik-Services West GmbH, Germany

Charlie Burger
IBM USA

Jose Castano
IBM USA

Angelo Corridori
IBM USA

Vic Cross
Independent Systems Integrators, Australia

Greg Daynes
IBM USA

Jerry Dearing
IBM USA

Dave Draper
IBM UK

Scott Fagen
IBM USA

Kingsley Furneaux
IBM UK

xiv Merging Systems into a Sysplex

Sue Hamner
IBM USA

Johnathan Harter
IBM USA

Evan Haruta
IBM USA

Axel Hirschfeld
IBM Germany

Gayle Huntling
IBM USA

Michael P Kasper
IBM USA

John Kinn
IBM USA

Paul M. Koniar
Metavante Corporation, USA

Matti Laakso
IBM Finland

Tony Langan
IBM Canada

Jim McCoy
IBM USA

Jeff Miller
IBM USA

Bruce Minton
CSC USA

Marcy Nechemias
IBM USA

Mark Noonan
IBM Australia

Bill Richardson
IBM USA

Alvaro Salla
Maffei Informática, Brazil

Sim Schindel
IBM Turkey

Norbert Schlumberger
IBM Germany

Preface xv
 William Schoen
IBM USA

Gregory Silliman
IBM USA

Nat Stephenson III

IBM USA

Dave Sudlik
IBM USA

Kenneth Trowell
IBM Australia

Susan Van Berkel

IBM Canada

Geert Van de Putte

IBM Belgium

Tom Wasik
IBM USA

Bob Watling
IBM UK

Gail Whistance
IBM USA

Mike Wood
IBM UK

Bob Wright
IBM USA

Dave Yackel
IBM USA

Comments welcome
Your comments are important to us!

We want our Redbooks to be as helpful as possible. Send us your comments about this or
other Redbooks in one of the following ways:
򐂰 Use the online Contact us review redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an Internet note to:
[email protected]
򐂰 Mail your comments to the address on page ii.

xvi Merging Systems into a Sysplex

 1

Chapter 1. Introduction
This chapter discusses the reason for producing this book and introduces the structure used
in most of the subsequent chapters. It also describes some terms used throughout the book,
and some assumptions that were used in its production. Summary information is provided
about which system components must be merged as a set, and the sequence of those
merges.

© Copyright IBM Corp. 2002 1

1.1 Why this book was produced
As customer implementation of the sysplex concept has become widespread, together with
the acceptance that S/390, and subsequently zSeries, provides an outstanding general
purpose computing platform, both for legacy and e-business applications, there has been a
growing trend to consolidate into smaller numbers of single system images. In this context, a
“single system image” may consist of a single OS/390 or z/OS system, or a number of
systems in a sysplex.

While no two consolidation exercises are identical, there are a number of aspects that apply
to many, if not all, situations. This book was produced in an effort to make these
consolidations easier to plan and implement, and to avoid customers having to constantly
“reinvent the wheel”.

This document discusses the things to be considered when an existing system (or group of
systems) is to be moved into an existing sysplex. It does not cover the considerations for
moving applications from one system image to another. Such moves are more common and
generally less complex than moving a complete system into a sysplex.

1.2 Starting and ending points

There are many things to consider when moving a system into a sysplex. While it is not
possible to cover every consideration for every consolidation project, we have attempted to
address issues that are likely to arise in most projects. In this document, we discuss product
merges, such as when merging two RACF databases, as well as more ephemeral aspects,
such as data set naming conventions.

There are endless ways to configure z/OS environments, and it is unlikely that any two
customer’s environments are exactly the same. However, in order to write this book, we had
to make some assumptions about the starting configuration, and the objectives for doing the
merge.

We have assumed that the current configuration is as follows:

򐂰 An existing sysplex, configured as a single system image. By this we mean that all the
systems are sharing a single sysres, a single catalog structure, a single security database,
and so on. Throughout this document we use the term “target sysplex” to refer to this set
of systems.
򐂰 Another system that currently does not share anything with the target sysplex. This system
may run on another CPC in the same installation and has its own sysres, catalogs,
security database, and so on. We use the term “incoming system” to refer to this system.
If the incoming system is part of a sysplex, we assume that all those systems are in a
single system image, and therefore can be moved as if they were one system. If the
systems are not in a single system image (that is, they each have their own security
database and so on), then you will need to go through this exercise separately for each
individual system.

Before you can proceed with the merge project, there is a very fundamental decision that
needs to be made: are you going to share all your user data between all the systems? This
decision needs to be based on many criteria, including:
򐂰 Who uses the system? For example, if the users of the incoming system work for a
different company than the current users of the target sysplex systems, you will probably
not want to share data between the different systems.

2 Merging Systems into a Sysplex

򐂰 Do you plan on implementing data sharing and workload balancing across all the systems
in the target sysplex, either now or at some time in the future? If so, you would need to
have all DASD volumes accessible to all systems.
򐂰 Are there duplicate high level qualifiers on the user volumes? The easiest way to check
this is to do an IDCAMS LISTCAT ALIAS against the Master Catalogs of the incoming
system and the target sysplex, and check for duplicate HLQs that are not referring to the
same files. This should be obvious if the same alias in the two Master Catalogs points to
two different user catalogs. Obviously you will have some duplicates for system files, but
you must check for user data. If there are duplicates, this will make it more complex to
share all volumes, especially if there are many duplicates. This is discussed in more detail
in 10.4, “Sharing Master Catalogs” on page 150.
򐂰 If you are going to share all the volumes between all systems, realize that this means that
you are probably also going to need a single security environment, single JESplex, single
HSM, and single SMS. A single Master Catalog is desirable, but not a necessity.
򐂰 Having access to all DASD from all systems gives you the capability to potentially restart
any work on any system. If there is a planned outage, the applications from the affected
system can be moved and run on one of the other systems. If you are not exploiting data
sharing, this is an attractive way of minimizing the impact of planned (or unplanned)
outages. If you want this capability, all DASD must be accessible from all systems.

An additional important consideration that we have to point out is that the original concept of a
sysplex is a group of systems with similar characteristics, similar service level objectives, and
similar workloads, sharing data between the systems and doing dynamic workload balancing
across all systems. While this is the ideal Parallel Sysplex implementation which will allow a
customer to derive maximum benefit fromt the technology,, we realize that many customers
may not, for business or technical reasons, be able to implement it. Therefore, asymmetric
configurations where some of the workloads on each system are not shared are certainly
supported. However, if you find that you have a Parallel Sysplex in which the majority of
systems and/or workloads are completely disjoint that—that is, they have nothing in
common—then you should give additional consideration as to whether those systems should
really reside in the same sysplex.

Specifically, sysplex was not designed to support subplexes—that is, subsets of the sysplex
that have nothing in common with the other members of the sysplex except that they share
the sysplex couple data sets and Sysplex Timer. For example, the design point is not to have
development and production systems in the same sysplex. While some products do support
the idea of subplexes (DFSMShsm, for example), others do not (TCP/IP, for example).

While Parallel Sysplex provides the capability to deliver higher application availability than any
other solution, the closer relationship between the systems in a sysplex mean that it is
possible for a problem on one system to have an impact on other members of the sysplex.
Such problems, while rare, are more likely to arise if the sysplex consists of widely disparate
systems (for example, test and production). For the highest levels of availability, therefore, we
recommend against mixing very different types of systems, that are completely unrelated, in
the same sysplex.

On the other hand, the pricing mechanisms implemented through Parallel Sysplex License
Charging (PSLC) and Workload License Charging (WLC) do unfortunately provide a financial
incentive to place as many systems as possible in the same sysplex.

At the end of the day, if you are in the position of deciding whether to merge a completely
unrelated system into a sysplex, you need to balance the financial and technical (if any)
benefits of the merge against the possible impact such a move could have on the availability
of all the systems in the sysplex.

Chapter 1. Introduction 3
 Similarly, if the merge would result in a very large number of systems in the sysplex (and
those systems are not all related to each other), you need to consider the impact to your
business if a sysplex outage were to take out all those systems. While the software savings
could be significant (and are easily calculated), the cost of the loss of all systems could also
be significant (although more difficult to calculate, unfortunately).

Once you have decided how the user DASD are going to be handled, and have satisfied
yourself with the availability and financial aspects, you are in a position to start planning for
the merge. This document is designed to help you through the process of merging each of the
affected components. However, because there are so many potential end points (ranging
from sharing nothing to sharing everything), we had to make some assumptions about the
objective for doing the merge, and how things will be configured when the exercise is
complete. We describe these assumptions in the following sections.

1.2.1 BronzePlex
Some customers will want to move systems that are completely unrelated into a sysplex
simply to get the benefits of PSLC or WLC charging. In this case, there will be practically no
sharing between the incoming system and the other systems in the target sysplex. This is a
typical outsourcing configuration, where the sysplex consists of systems from different
customers, and there is no sharing of anything (except the minimal sharing required to be part
of a sysplex) between the systems. We have used the term “BronzePlex” to describe this type
of sysplex.

1.2.2 GoldPlex
Other customers may wish to move the incoming system into the sysplex, and do some fairly
basic sharing, such as sharing of sysres volumes, for example. In this case, the final
configuration might consist of more than one JES2 MAS, and two logical DASD pools, each of
which is only accessed by a subset of the systems in the sysplex. We have included in this
configuration all of the components that can easily be merged, and do not require a number of
other components to be merged at the same time. This configuration provides more benefits,
in terms of improved system management, than the BronzePlex, so we have called this
configuration a “GoldPlex”.

1.2.3 PlatinumPlex
The third configuration we have considered is where the objective is to maximize the benefits
of sysplex. In this case, after the merge is complete, the incoming system will be sharing
everything with all the other members of the sysplex. So there will be a single shared sysres
between all the systems, a single JES MAS, a single security environment, a single
automation focal point, and basically just one of everything in the sysplex. This configuration
provides the maximum in systems management benefits and efficiency, so we have called it
the “PlatinumPlex”.

Depending on which type of plex you want to achieve and which products you use, some or all
of the chapters in this book will apply to you. Table 1-1 contains a list of the topics addressed
in the chapters and indicates which ones apply to each plex type. However, we recommend
that even if your objective is a BronzePlex you should still read all the chapters that address
products in your configuration, to be sure you have not overlooked anything that could impact
your particular environment.

4 Merging Systems into a Sysplex

Table 1-1 Product considerations by target environment type
Component BronzePlex GoldPlex PlatinumPlex

Couple data sets and Coupling Facilities X X X

System Logger X X X

WLM X X X

GRS X X X

Language Environment X X

SMF X X

JES2 X X

Shared HFS X

Parmlib/Proclib X X

VTAM X X X

TCP X X X

RACF X

SMS X

HSM X

RMM X

OPC X X X

Automated operations X X X

Physical considerations X X X

Data Set Naming conventions X X

Software Licensing X X X

Operations X X X

Maintenance X X X

Exits and usermods X X X

In addition, in each chapter there is a table of considerations specific to that topic. One of the
columns in that table is headed “TYPE”, and the meaning of the symbols in that column are
as follows:
B This consideration applies if the target environment is a BronzePlex.
G This consideration applies if the target environment is a GoldPlex.
P This consideration applies if the target environment is a PlatinumPlex.

Some considerations apply across all target environments, and some only apply to a subset
of environments.

We also thought it would be helpful to identify up front a suggested sequence for merging the
various components. For example, for some components, most of the merge work can and
should be done in advance of the day the system is actually moved into the sysplex. The
merge of other components must happen immediately prior to the system joining the sysplex.

Chapter 1. Introduction 5
 And still others can be merged at some time after the system joins the sysplex. In Table 1-2
on page 6, we list each of the components addressed in this book, and indicate when the
merge work can take place. This table assumes that your target environment is a
PlatinumPlex. If your target is one of the other environments, refer to the specific chapter for
more information.

Table 1-2 Timing of merge activities by component

Component Sequence

Couple Data Sets and CFs Before

System Logger Before and immediately preceding

WLM Before

GRS Before

Language Environment Before

SMF Before and after

JES2 Before and immediately preceding

Shared HFS After

Shared system data sets Before

VTAM Before

TCP Before

RACF Before and immediately preceding

SMS Before and immediately preceding

HSM Before and immediately preceding

RMM Before and immediately preceding

OPC Before and after

Automated operations Before

Physical considerations Before

Data Set Naming conventions Before

Software Licensing Before

Operations Before and immediately preceding

Maintenance Before

Exits and usermods Before

In Table 1-2 on page 6, the entries in the “Sequence” column have the following meanings:
Before The bulk of the work required to merge these components can and
should be carried out in the weeks and months preceding the day
the incoming system is brought up as a member of the target
sysplex.
Immediately preceding At least some of the work to merge this component must be done
in the short period between when the incoming system is shut
down, and when it is IPLed as a member of the target sysplex.

6 Merging Systems into a Sysplex

 After The work required to complete the merge for this component can
actually be postponed until after the incoming system is IPLed into
the target sysplex.

Note: Regardless of whether your target environment is a BronzePlex, a GoldPlex, or a

PlatinumPlex, the incoming system must be IPLed to join the sysplex for the first time.
However, as long as you have done the required planning and preparation work, there
should be no need to IPL any of the existing systems in the target sysplex in order to bring
the incoming system into the sysplex.

1.3 Structure of each chapter

There are basically two types of chapters in this book. A number are product-related,
discussing, for example, how you would move to a single RACFplex. To make this document
more consistent and easier to use, we have tried to use a single format for those chapters.

The other chapters are not related to a specific product, and may address something more
esoteric, like data set naming conventions, or operator procedures. It does not make sense to
apply the same structure to those chapters as to the product ones, so each of those chapters
will be structured in a way that is suitable for that particular topic.

The product chapters each consist of four sections as described below.

1.3.1 Are multiple subplexes supported or desirable

For some products, such as RACF, it is possible to have a sysplex with more than one subplex
(called a RACFplex in the case of RACF, for example). In some cases, this may be a perfectly
acceptable way to run on an ongoing basis. In some other cases, it simply may not be
possible to have more than one subplex per sysplex—GRSplex is an example, where only
one GRS complex can exist within a sysplex.

In this section in each of the relevant chapters, we discuss whether it is possible to run with
multiple subplexes, and if so, the advantages and disadvantages of running one or multiple
subplexes.

1.3.2 Considerations checklist

Assuming that you decide to run with just one subplex, this section in each chapter provides a
checklist of things to consider. We felt that a checklist format is easier to use in helping to
quickly identify any areas that may be a concern in your environment.

The checklist is followed by explanatory notes where required.

1.3.3 Implementation methodology

There are often a number of ways of moving to a single shared environment. Some of these
may be safer to implement, or require fewer steps. This section provides a recommended
methodology for merging disparate environments into a single shared environment. An
example might be a tape management system—you might merge them by adding entries
from one tape management system to the other, or you might effect the merge by offloading
the databases, doing a merge of the flat files using special utilities, then reloading the
resulting files into a new database. Both methods may be valid, but one may be a lower risk
approach. In this section, we allow you to benefit from the experience of those that have been
through this process before.

Chapter 1. Introduction 7
1.3.4 Tools and documentation
In this section, we describe tools that may be available to help you do the merge, and tell you
where they may be obtained. In addition, if there is other documentation that would be useful
during this exercise, we provide a list of those sources.

1.4 Terminology and assumptions

The majority of this book applies equally to OS/390 and z/OS. However, to make the book
easier to read, we will simply say z/OS (as in, “IPL the z/OS systems”) when discussing
something that applies to both z/OS and OS/390. If a particular point applies specifically to
OS/390 or z/OS, we will state that clearly at the time.

This book discusses the considerations for merging existing systems into a sysplex. A sysplex
is the set of systems that share a common sysplex CDS, and all have the same sysplex
name. A subplex is a subset of those systems that have something in common. Throughout
this document, you will see a lot of use of the term plex. The following section discusses the
subplexes that we talk about, and the terms that we use to refer to them.

1.4.1 ‘Plexes
In this document we frequently talk about the set of systems that share a particular resource.
In order to avoid repetitive use of long-winded terms like “all the systems in the sysplex that
share a single Master Catalog”, we have coined terms like CATALOGplex to describe this set
of systems. The following are some of these terms we use later in this document:
CATALOGplex The set of systems in a sysplex that share a set of user catalogs.
DASDplex The set of systems in a sysplex that all share the same DASD
volumes.
ECSplex The set of systems that are using Enhanced Catalog Sharing (ECS) to
improve performance for a set of shared catalogs. All the systems
sharing a given catalog with ECS must be in the same GRSplex.
GRSplex The set of systems that are in a single GRS complex and serialize a
set of shared resources using either a GRS Ring or using the GRS
Star structure in the Coupling Facility (CF).
JESplex The set of systems, either JES2 or JES3, that share a single spool. In
JES2 terms, this would be a single MAS. In JES3 terms, this would be
a Global/Local complex.
HFSplex An HFSplex is a collection of z/OS systems that share the OMVS
Couple Data Set (CDS). The OMVS CDS contains the sysplex-wide
mount table and information about all participating systems, and all
mounted file systems in the HFSplex.
HMCplex The set of Central Processing Complexes (CPCs—also sometimes
referred to as a CEC or CPU) that can be controlled from a single
HMC. It is possible to have just one sysplex in a HMCplex, or many
sysplex per HMCplex, or more than one HMCplex per sysplex.
HSMplex The set of systems that share a set of DFSMShsm Journals and
CDSs.
OAMplex The set of OAM instances that are all in the same XCF group. The
scope of the OAMplex must be the same as the DB2 data sharing

8 Merging Systems into a Sysplex

 group that contains the information about the OAM objects used by
those instances.
OPCplex The set of systems whose batch work is managed from a single OPC
Controller. The OPCplex may consist of systems in more than one
sysplex, and may even include non-MVS systems.
RACFplex The set of systems in a sysplex that share a single logical RACF
database.
RMFplex The set of systems in a sysplex that are running RMF and are using
the RMF sysplex data server. All such RMF address spaces in a
sysplex will connect to the same XCF group and therefore be in the
same RMFplex.
RMMplex The set of systems in a sysplex that share a single RMM CDS.
SMSplex The set of systems in a sysplex that share a single SMS ACDS,
SCDS, and COMMDS.
TCPplex The set of systems in a sysplex whose TCP/IP stacks are connected
to each other.
VTAMplex The set of systems in a sysplex that have active VTAM
subsystems—in other words, the set of systems in the VTAMplex is the
same as the set of systems in the sysplex (assuming that VTAM is
active on every system).
WLMplex The set of systems in a sysplex that share the WLM CDS.

Table 1-3 summarizes how many of each of these ‘plexes are possible in a single sysplex.
Note that there are often relationships between various plexes - for example, if you have a
single SMSplex, you would normally also have a single RACFplex. These relationships are
discussed in more detail in the corresponding chapters of this book.

Table 1-3 Number of subplexes per sysplex

‘Plex 1 per sysplex >1 per sysplex

CATALOGplex X

DASDplex X

ECSplex X

GRSplex X

JESplex X

HFSplex (if using sysplex HFS sharing) X

HMCplex X

HSMplex X

OAMplex X

OPClpex X

RACFplex X

RMFplex X

RMMplex X

SMSplex X

Chapter 1. Introduction 9
 ‘Plex 1 per sysplex >1 per sysplex

TCPplex X

VTAMplex X

WLMplex X

There are also other plexes, which are not covered in this book, such as BatchPipesPlex,
CICSplex, DB2plex, IMSplex, MQplex, TapePlex, VSAM/RLSplex, and so on. However, we
felt that data sharing has been adequately covered in other books, so we did not include
CICS, DB2, IMS, MQSeries, or VSAM/RLS in this book.

1.5 “Gotchas”
While adding completely new systems to an existing sysplex is a relatively trivial task, adding
an existing system (complete with all its workloads and customization) to an existing sysplex
can be quite complex. And you do not have to be aiming for a PlatinumPlex for this to be the
case. In some ways, trying to establish a BronzePlex can be even more complex, depending
on how your systems are set up prior to the merge and how stringent the requirements are to
keep them apart.

In this section, we review some situations that can make the merge to a BronzePlex or
GoldPlex configuration difficult or maybe even impossible. We felt it was important to highlight
these situations up front, so that if any of them apply to you, you can investigate these
particular aspects in more detail before you make a final decision about how to proceed.

1.5.1 Duplicate data set names

In principle, all system programmers know that duplicate data set names are bad news. They
can lead to mistakes, complexity, and potentially even security or integrity problems. However,
if the systems containing the duplicate names are completely separated, at least the problem
can be contained.

However, what happens if the systems are no longer completely separated? Let’s look at a
BronzePlex (apparently the simplest of the three configurations) situation. In a BronzePlex,
the systems in the two subplexes cannot see each other’s DASD, and there are completely
separate catalog structures, RACF databases, production control systems, and so on.
However, we need to look at what is not separate.

The first thing is GRS. In a multi-system environment, you would always treat data sets as
global resources, meaning that any time you want to update a data set, GRS will check that
no one else in the GRSplex (either on the same system or another system) is using that data
set. However, what happens if you have a situation like that shown in Figure 1-1?

10 Merging Systems into a Sysplex

 GRS
12
11 1
10 2

SUBPLEXA
9
8
7 5
4
3
SUBPLEXB
6

SYSA SYSB FRED

CICS EXEC PGM=... COMPRESS EXEC PGM=IEBCOPY
STEPLIB DD DSN=BIG.PAY.LOAD INOUT DD DSN=BIG.PAY.LOAD

BIG.PAY.LOAD
BIG.PAY.LOAD

Figure 1-1 Multiple subplexes within a sysplex

In this case, systems SYSA and SYSB are in one subplex, SUBPLEXA (these might be the
original target sysplex systems). System FRED is in another subplex, SUBPLEXB (this might
be what was the incoming system). There are two data sets called BIG.PAY.LOAD, one that is
used by system FRED, and another that is shared between systems SYSA and SYSB.

If the SYSA version of the data set is being updated by a job on SYSA, and someone on
system FRED tries to update the FRED version of the data set, GRS will make the FRED
update wait because it thinks someone on SYSA is already updating the same data set.

This is called false contention, and while it can potentially happen on any resource that is
serialized by GRS, it is far more likely to happen if you have many duplicate data set names,
or even if you have a small number of duplicate names, but those data sets are used very
frequently.

To identify if this is likely to cause a problem in your installation, the first thing to do is to size
the magnitude of the problem. A good place to start is by looking for duplicate aliases in the
Master Catalogs. If you do not have a “clean” Master Catalog (that is, the Master Catalog
contains many data sets other than those contained on the sysres volumes), then you should
also check for duplicate data set entries in the Master Catalogs. If these checks indicate that
duplicates may exist, further investigation is required. You might try running DCOLLECT
against all the volumes in each subplex and all the DFSMShsm Migration Control Data Sets
in each subplex, then use something like ICETOOL to display any duplicate records. While
this is not ideal (it only reflects the situation at the instant the job is run, and it does not read
information from the catalogs, such as for tape data sets), at least it will give you a starting
place. For more information about the use of DCOLLECT, refer to z/OS DFSMS Access
Methods Services for Catalogs, SC26-7394.

Chapter 1. Introduction 11
1.5.2 Duplicate volsers
Just as duplicate data set names are something you should avoid at all costs, a similar
concern is duplicate volsers, whether they are on DASD or tape. The chapters on merging
DFSMShsm and DFSMSrmm discuss this further; however, if your target environment is a
BronzePlex or a GoldPlex, you may not be merging those components and therefore may not
read that material. Duplicate volsers can cause confusion, operational errors, delayed IPLs
(because of duplicate volser messages, each of which must be responded to manually), and
potentially, integrity problems.

Another concern with duplicate volsers is in relation to PDSE extended sharing. Depending
on how the library is being accessed, there will be normal ENQ-type serialization
mechanisms—PDF, for example, serializes on the data set and member name. However, the
PDSE code has its own serialization mechanism in addition to any used by the application.

Unlike PDF, however, the PDSE code does not use the data set name for serialization; rather,
it uses the volser and the TTR of the DSCB to serialize access to the data set during create,
delete, and member update-in-place processing. Therefore, it is possible that two different
PDSE data sets, with different names, that reside on the same place on volumes with
duplicate volsers could experience false contention during certain processes.

1.5.3 TCP/IP
There have been many enhancements to TCP/IP in an OS/390 and z/OS environment to
improve both performance and availability. Many of these enhancements depend on a TCP/IP
capability known as Dynamic XCF.

In addition to enabling these new enhancements, however, Dynamic XCF also automatically
connects all TCP/IP stacks that indicate that they wish to use this feature. If you do not wish
the TCP/IP stack on the incoming system to connect to the TCP/IP stacks on the target
sysplex systems, then you cannot use Dynamic XCF on the incoming system. If the “incoming
system” is actually just a single system, then this may not be a significant problem, however if
the “incoming system” actually consists of more than one system, and you would like to use
the TCP/IP sysplex enhancements between those systems, then this may be an issue.

If this is a potential concern to you, refer to Chapter 12, “TCP/IP considerations” on page 175
before proceeding.

1.5.4 System Logger

In a BronzePlex, you typically wish to share as little as possible. In general, the only DASD
people plan on sharing in this environment are the volumes containing the CDSs.

However, there is another consideration you must plan for if you have any Logger structures
(note that we said structures, not logstreams) that are connected to both subplexes. For most
logstreams, you can specify any name you like for the logstream, so it should be possible to
set up Logger structures so that all the connectors are in a single subplex. For example,
structure SUBA_CICS_DFLOG could contain all the CICS DFHLOG logstreams from
SUBPLEXA, and structure SUBB_CICS_DFHLOG could contain all the CICS DFHLOG
logstreams from SUBPLEXB. In a BronzePlex and maybe in a GoldPlex, the only structures
that would be connected to by members of both subplexes should be those containing
logstreams that have a fixed name, and therefore you can only have one per sysplex—at the
time of writing, the only such logstreams are SYSPLEX.OPERLOG and
SYSPLEX.LOGREC.ALLRECS.

12 Merging Systems into a Sysplex

 The reason for avoiding multiple subplexes being connected to a single Logger structure is
that it is possible for any system that is connected to a Logger structure to do offload
processing for a logstream in that structure. Therefore, the DASD volumes that will contain
the offload data sets for those logstreams must also be shared by all systems in the sysplex.
And because the offload data sets must be cataloged, the user catalog or catalogs that will
contain the data set entries must also be shared.

An additional consideration is how do you manage the offload data sets. You can’t use
DFSMShsm to migrate them unless you have a single HSMplex, and you would normally only
have a single HSMplex in a PlatinumPlex. The reason for this is that if DFSMShsm in
SUBPLEXA migrates the data set, the catalog will be updated to change the volser of the
migrated data set to MIGRAT. If a system in SUBPLEXB needs to access data in the migrated
offload data set, it will see the catalog entry indicating that the data set has been migrated,
call DFSMShsm on that system to recall it, and the recall will fail because the data set was
migrated by a DFSMShsm in a different HSMplex. If you wish to use DFSMShsm to manage
the Logger offload data sets, all systems that are connected to a Logger structure must be in
the same HSMplex.

Furthermore, if you currently place your offload data sets on SMS-managed volumes (as
many customers do), you will have to discontinue this practice if all the systems in the new
enlarged sysplex will not be in the same SMSplex.

Therefore, if you are considering a BronzePlex or a GoldPlex configuration, you must give
some thought to how your Logger structures will be used (especially for OPERLOG and
LOGREC), and how the offloaded Logger data will be managed.

1.5.5 Sysplex HFS sharing

UNIX Systems Services uses a fixed XCF group name to implement sysplex HFS sharing
(introduced in OS/390 2.9). As a result, all the systems that enable this feature can
immediately see all the HFSs mounted on any other system in the sysplex that also has this
feature enabled. If your target environment is a PlatinumPlex, this is exactly what you want,
because in this environment, you want full sharing. However, if your target environment is a
BronzePlex or a GoldPlex, where you do not want to share user data between the different
systems, then this could present a problem.

If the incoming system is a single system, and you are moving into a BronzePlex or a
GoldPlex, you should not have a problem. In this case, there is no reason to enable sysplex
HFS sharing on the incoming system, so it will only be able to see its own HFSs, and the
systems in the target sysplex will only be able to see their HFSs, even if they have enabled
sysplex HFS sharing.

However, if the incoming system is actually a multi-system sysplex and you want to share the
HFSs in that sysplex using sysplex HFS sharing, then you could have a problem if the
systems in the target sysplex also want to use sysplex HFS sharing to share their HFSs. The
fact that the DASD containing the incoming system’s HFSs are offline to the target sysplex
systems does not provide any protection because all I/Os for a given HFS (that is being
shared using sysplex HFS sharing) are issued from a single system. So conceivably, you
could have the volume containing all your HFSs online to just one system, but every system in
the sysplex could still read and write to those HFS if all systems have enabled sysplex HFS
sharing.

Therefore, there can only be one HFSplex per sysplex, and systems whose HFS data sets
should not be accessible from other systems must not enable sysplex HFS sharing.

Chapter 1. Introduction 13
1.5.6 Legal implications
Even in a BronzePlex environment, where the incoming system can only see its own DASD,
and the original members of the target sysplex can only see their own DASD, the fact that all
systems are in the same sysplex means that some information is available to all members of
the systems. One example is syslog data. The current design of z/OS is such that all
messages from every system get sent to every other system in the sysplex. Another example
is RMF—because RMF uses a fixed XCF group name, every RMF in the sysplex will
automatically communicate with every other RMF in the sysplex. This means that if you are
logged on to SYSA and have access to RMF, you can potentially get performance information
about any of the other members of the sysplex.

In most situations, this visibility of information is not a problem. However, if the two systems
belong to different companies, possibly in the defense or finance industries, there may be
legal restrictions on this level of access to information from the other company.

1.6 Updates to this document

It is our hope that this document will become the definitive place that people refer to should
they need to merge a system into a sysplex, or just merge some of the components that we
cover. If you find any additional considerations that we have not covered in this book, send an
e-mail to [email protected], providing the number of this manual (SG24-6818), and as
much detail as possible about your finding. While we cannot guarantee it, we will attempt to
include that information in any subsequent updates to this book.

14 Merging Systems into a Sysplex

 2

Chapter 2. Sysplex infrastructure

considerations
This chapter discusses the following aspects of moving a system into an existing sysplex:
򐂰 Is it necessary to merge sysplex infrastructure (that is, XCF) environments and definitions,
or is it possible to have more than one XCFplex in a single sysplex?
򐂰 A checklist of things to consider when merging a system into a sysplex.
򐂰 A methodology for doing the merge.
򐂰 A list of tools and documentation that can assist with this exercise.

© Copyright IBM Corp. 2002 15

2.1 One or more XCF subplexes
It is not possible to have more than one XCF environment in a sysplex. The definition of a
sysplex is: the set of systems that all have the same sysplex name, have XCF communication
between the systems, and share a common set of sysplex CDSs (and sysplex-related CDSs,
such as ARM, CFRM, and so on). Therefore, when you move a system into a sysplex, it must
have the same sysplex name as the other systems, and it must share the same sysplex
CDSs—you cannot continue to use any other sysplex CDSs that the system might have been
using previously.

2.2 CDS considerations

There are some characteristics and considerations that apply across all the CDSs, and we
will address these here, before we move on to more specific issues relating to each of the
sysplex components.

One of the parameters used when allocating any CDS (ARM, CFRM, LOGR, sysplex, OMVS,
WLM) is the number of systems in the sysplex. If you are increasing the number of systems in
the sysplex, you need to review all of the CDSs to check the current setting of the
MAXSYSTEM parameter, which can be different for each CDS. To check the setting of the
parameter, issue the D XCF,C,TYPE=cdstype command, as shown in Figure 2-1, for each type
of CDS in use in the target sysplex.

D XCF,C,TYPE=SYSPLEX
IXC358I 22.55.49 DISPLAY XCF 534
SYSPLEX COUPLE DATA SETS
PRIMARY DSN: SYS1.XCF.CDS01
VOLSER: #@$#X1 DEVN: 37AC
FORMAT TOD MAXSYSTEM MAXGROUP(PEAK) MAXMEMBER(PEAK)
05/15/2002 22:09:38 8 100 (52) 203 (12)
ADDITIONAL INFORMATION:
ALL TYPES OF COUPLE DATA SETS SUPPORTED
GRS STAR MODE IS SUPPORTED
ALTERNATE DSN: SYS1.XCF.CDS02
VOLSER: #@$#X2 DEVN: 37AD
FORMAT TOD MAXSYSTEM MAXGROUP MAXMEMBER
05/15/2002 22:09:43 8 100 203
ADDITIONAL INFORMATION:
ALL TYPES OF COUPLE DATA SETS SUPPORTED
GRS STAR MODE IS SUPPORTED

Figure 2-1 Displaying MAXSYSTEM value for sysplex CDS

2.2.1 MAXSYSTEM CDS parameter

Be aware that increasing the MAXSYSTEM value in the sysplex CDS can have an effect on
the size of the XCF signalling structures and the VSAM/RLS lock structure. For the
VSAM/RLS lock structure, the size of each lock entry depends on the MAXSYSTEM value in
this CDS, not on the number of systems actually active in the sysplex. For the XCF structures,
the number of lists in the structures increases as the value of MAXSYSTEM increases. The
size of the GRS lock structure is related to the MAXSYSTEM value in the CFRM CDS. In
order to determine the correct sizes for these structures, you should use the CFSizer tool,
using the new MAXSYSTEM value as the number of systems in the sysplex. The CFSizer tool
can be found at the following URL:
http://www.ibm.com/servers/eserver/zseries/cfsizer/

16 Merging Systems into a Sysplex

2.2.2 General CDS guidelines
The CDSs already exist in the target sysplex before the merge, but here are some points that
you should keep in mind before you continue with the merge:
򐂰 CDSs are allocated and formatted using the CDS format utility (IXCL1DSU).
򐂰 The ARM, CFRM, LOGR, and SFM CDSs are customized using the IXCMIAPU utility.
򐂰 For every primary CDS there should be an alternate of the same size or larger (but not
smaller).
򐂰 It is highly recommended to also have a spare CDS for every primary CDS.
When an alternate CDS replaces a primary, the original primary data set is deallocated,
and there is no longer an alternate CDS. Because you should always have an alternate
CDS, you should have a spare CDS (one for each CDS you plan to use) that can be added
in as the new alternate as soon as the old alternate becomes the primary.
Note that the spare CDSs should be formatted with size parameters at least equal to the
larger of the two that are being used for primary and alternate. That way, the spare will
always be large enough so that it can be brought into use as an alternate, when needed.
򐂰 The CDS cannot exist prior to formatting.
The format utility will not reformat an existing data set. This prevents the accidental
re-formatting of an active CDS. If you wish to reformat an existing CDS, you must first
delete the existing data set before trying to format one with that name.
򐂰 To set up a new CDS, you must use the IXCL1DSU utility—never try to create a new CDS
by copying an existing one.
򐂰 CDSs cannot expand into multiple extents.
򐂰 A CDS cannot span volumes because XCF does not support multi-volume data sets.
򐂰 A CDS can be used by only one sysplex.
򐂰 A CDS can share a volume with other data sets. However, if you decide to allocate a CDS
on a volume with other data sets:
– Avoid any volume that has RESERVEs issued against it.
– Avoid volumes with data sets that have high I/O rates.
򐂰 Review the following performance and availability considerations:
The placement of CDSs can affect performance, as well as availability. For maximum
performance and availability, the CDS volumes should only contain CDSs.
– The primary sysplex CDS should be on a different volume than the primary CFRM
CDS. During CF recover processing, these two data sets get extremely busy. Placing
them on the same volume can impact the elapsed time for recovery from a CF failure.
– All other primary CDSs can reside on one volume, and all other alternate CDSs can
reside on another volume, as shown in Example 2-1 on page 18. However, be sure to
monitor these data sets, and consider placing any high-activity data set on its own
volume. (For example, the LOGR CDS might be a candidate for its own volume.).

Chapter 2. Sysplex infrastructure considerations 17

 Example 2-1 Placement of Couple Data Sets
Volume X Couple Data Sets Volume Y Couple Data Sets Volume Z Couple Data Sets
------------------------ ------------------------- -------------------------
Sysplex (Primary) Sysplex (Alternate) Sysplex (Spare)
CFRM (Alternate) CFRM (Primary) CFRM (Spare)
SFM (Primary) SFM (Alternate) SFM (Spare)
WLM (Primary) WLM (Alternate) WLM (Spare)
ARM (Primary) ARM (Alternate) ARM (Spare)
LOGR (Spare) LOGR (Alternate) LOGR(Primary)
...and so forth ...and so forth ...and so forth

– Place CDSs on volumes that are not subject to reserve/release contention or

significant I/O contention from sources not related to the CDSs. This is true even if the
I/O contention is sporadic.
Note: it is vital that this recommendation is followed.
– Do not excessively over-specify parameter values when formatting CDSs, as this can
result in larger-than-necessary CDSs. Large CDSs can elongate IPL times and cause
performance problems during recovery processing. This recommendation covers the
MAXSYSTEM, ITEM(GROUP) and ITEM(MEMBER) values.
– You can non-disruptively switch to a CDS that is the same size or larger at any time
using the SETXCF COUPLE,PSWITCH command. However, if you wish to switch to a
smaller CDS, a sysplex-wide IPL is required.
– Some sysplex monitoring tools may generate a large amount of I/O to the CFRM CDS,
which may affect system performance. When using this type of tool, be aware of the
performance implications.
– If a system cannot access a CDS for an extended period of time (for example, if the
volume on which it resides is reserved by another system), z/OS switches to its
alternate CDS. To minimize sysplex disruption, when you use DFDSS (or another data
mover) to back up a volume with a CDS, it is recommended that you:
• Convert the SYSVTOC reserves on the volume to global enqueues by creating an
entry in the RESERVE conversion RNL for QNAME(SYSVTOC) RNAME(volser).
For more information, see z/OS MVS Planning: Global Resource Serialization,
SA22-7600.
• Use logical volume backup processing so that the backups are done on a data set
level, rather than on a track-image level. For more information, see z/OS
DFSMSdss Storage Administration Guide, SC35-0423.
򐂰 Security considerations
It is the responsibility of the installation to provide the security environment for the CDSs.
Consider setting up a security profile specifically for the CDSs, and do not give any TSO
users access to the profile. This protects against accidental deletion of CDSs.

2.3 Cross-System Coupling Facility

The Cross-System Coupling Facility (XCF) is a z/OS component that provides facilities for
authorized programs to communicate with other programs on the same or different systems
that are in the same sysplex. XCF is also used to control certain shared resources.

18 Merging Systems into a Sysplex

 Authorized programs can join XCF groups and use XCF facilities to communicate with other
group members. In addition to providing the communication facilities, XCF also informs
members of the group when a member joins or leaves the group. XCF provides a relatively
simple and high performance mechanism for programs to communicate with other programs
resident in the same sysplex. As a result, there are many users of XCF, both IBM and
non-IBM products.

A program on any system in the sysplex can communicate with another program on any other
member of the sysplex as long as they are both connected to the same XCF group. Some
products provide the ability to specify the name of the XCF group they will use, or provide the
ability to control whether they connect to the group or not. Other products do not provide this
level of control. This is an important consideration when determining whether your target
sysplex will be a BronzePlex, a GoldPlex, or a PlatinumPlex—if you wish to maintain
maximum separation between the incoming system and the other systems in the target
sysplex, how products use XCF may have a bearing on that decision.

If your target environment is a BronzePlex, the incoming system must share the sysplex
CDSs and take part in XCF signalling with the systems in the target sysplex. In fact, even if
you share absolutely nothing else, to be a member of the sysplex, the incoming system must
share the sysplex CDSs.

If your target environment is a GoldPlex, the incoming system will share the sysplex CDSs
and take part in XCF signalling with the systems in the target sysplex.

Finally, if your target environment is a PlatinumPlex, the incoming system will again share the
sysplex CDSs and take part in XCF signalling with the systems in the target sysplex.

2.3.1 Considerations for merging XCFs

This section contains, in checklist format, a list of items that must be considered when you
decide to merge two or more XCFs.

Table 2-1 Considerations for merging XCF

Consideration Note Type Done

Check MAXSYSTEM, GROUP, and MEMBER values 1 B, G, P

Check COUPLExx member on incoming system 2 B, G, P

Check XCF performance 3 B, G, P

Check and update transport class definitions 4 B, G, P

Understand who is using XCF groups 5 B, G, P

Review XCF signalling path methods 6 B, G, P

The “Type” specified in Table 2-1 relates to the sysplex target environment—B represents a
BronzePlex, G represents a GoldPlex, and P represents a PlatinumPlex.

Notes indicated in Table 2-1 are described below:

1. If you need to increase the MAXSYSTEM value in the sysplex CDS, you will need to
allocate a new CDS using the IXCL1DSU program. This is discussed in 2.2, “CDS
considerations” on page 16.

Chapter 2. Sysplex infrastructure considerations 19

 In addition to the MAXSYSTEM value, there are other relevant attributes of the sysplex
CDSs that need to be considered:
– ITEM NAME(GROUP) NUMBER( ) Specifies that the sysplex CDS supports group
data. The NUMBER value includes not only the number of XCF groups needed for
multisystem applications, but also the number of XCF groups that z/OS system
components need. To determine the number of z/OS system groups currently in use,
issue the DISPLAY XCF,G command on both the incoming system and the target
sysplex. It is advisable to add a contingent number of groups for future growth.
(Default=50, Minimum=10, Maximum=2045).
– ITEM NAME(MEMBER) NUMBER( ) Specifies that the sysplex CDS supports member
data. The NUMBER value specifies the largest number of members allowed in a single
group. Determine which group has the largest number of members and specify a value
somewhat larger than this amount, allowing for the fact that bringing the incoming
system into the target sysplex will probably increase the number of members in most, if
not all, XCF groups. To verify the number of members in your groups at the moment,
issue the D XCF,G command on both the incoming system and the target sysplex, as
shown in Figure 2-2 on page 20. The number contained in brackets after the group
name is the number of members in that group. In this example, the largest number of
members in a group is 8, for the SYSMCS and SYSMCS2 groups. In a normal
production environment, the groups with the largest numbers of members are usually
those associated with CICS, JES3, and CONSOLE. (Minimum=8, Maximum=1023). To
find out who is connected to a given group, use the D XCF,GROUP,groupname,ALL
command.

D XCF,G
IXC331I 23.35.26 DISPLAY XCF 568
GROUPS(SIZE): ATRRRS(3) COFVLFNO(3) CSQGMQ$G(3)
CSQGPSMG(3) D#$#(3) DR$#IRLM(3)
DSNGSGA(3) EZBTCPCS(3) IDAVQUI0(3)
IGWXSGIS(5) INGXSGA0(2) IRRXCF00(3)
ISTCFS01(3) ISTXCF(3) ITSOIMS(1)
IXCLO00C(3) IXCLO00D(3) IXCLO001(3)
IXCLO004(3) SYSBPX(3) SYSDAE(7)
SYSENF(3) SYSGRS(3) SYSGRS2(1)
SYSIEFTS(3) SYSIGW00(4) SYSIGW01(4)
SYSIGW02(3) SYSIGW03(3) SYSIKJBC(3)
SYSIOS01(3) SYSJES(3) SYSMCS(8)
SYSMCS2(8) SYSRMF(3) SYSTTRC(3)
SYSWLM(3) XCFJES2A(3) XCFJES2K(1)

Figure 2-2 Displaying XCF group information

2. If your target environment is a BronzePlex, you will not be sharing the Master Catalog, so
you must ensure that the CDSs are in the Master Catalog of each system. Remember that
when the incoming system joins the target sysplex, it should use the same COUPLExx
Parmlib member as the systems in the target sysplex, or at least use a member that is
identical to the COUPLExx member used by those systems. If your target environment is a
GoldPlex or a PlatinumPlex, you will be sharing SYS1.PARMLIB, so all systems should
share the same COUPLExx member.
3. Prior to the merge, you should review your XCF performance in the target sysplex to
ensure there are no hidden problems that could be exacerbated by adding another system
to the sysplex. You should use WSC Flash 10011, Parallel Sysplex Performance: XCF
Performance Considerations, to help identify the fields in RMF reports to check. If any
problems are identified, they should be addressed prior to the merge.

20 Merging Systems into a Sysplex

 After the merge, you should again use the XCF Activity Report to check the XCF
performance in the target sysplex. Once again, if any problems are identified, they should
be addressed now. In addition to the WSC Flash, you can use Chapter 6, “Tuning a
Sysplex”, in z/OS MVS Setting Up a Sysplex, SA22-7625 to help with tuning XCF.
4. A transport class is z/OS's way of enabling you to associate XCF messages (based on
similar signaling requirements) and then assign them signaling resources (signaling paths
and message buffers). A transport class allows you to segregate message traffic
according to the XCF group a message is related to, or according to the length of the
message, or both. In general, we recommend using transport classes for one of the
following reasons:
– To assign signalling resources to groups of messages based on the message sizes;
this ensures the most efficient use of the signalling resources.
– To get information about the number of messages and the size of the messages
associated with a given XCF group. We recommend that once you have obtained the
required information, you remove the transport class and group the associated
messages in with all other messages based solely on their size.
For instance, you can define a transport class that optimizes signaling resources for XCF
messages of a certain size. Messages larger than this size can still be processed,
however, there may be an overhead in processing those messages. While it is possible to
assign messages to a transport class based on their XCF group, we recommend using the
message size rather than the XCF group as the mechanism to assign messages to a
given transport class. The following are examples of how you would define two transport
classes and assign all messages to one or the other based purely on message size
(specifying GROUP(UNDESIG) indicates that messages from all XCF groups are
candidates for selection for this message class):
CLASSDEF CLASS(DEFSMALL) CLASSLEN(956) GROUP(UNDESIG)
CLASSDEF CLASS(DEFAULT) CLASSLEN(16316) GROUP(UNDESIG)
Transport classes are defined independently for each system in the sysplex using the
CLASS keyword of the CLASSDEF statement or, after IPL, using the SETXCF
START,CLASSDEF command.

Example 2-2 Syntax for CLASSDEF Statement of COUPLExx Parmlib Member

[CLASSDEF ]
[ CLASS(class-name) ]
[ [CLASSLEN(class-length) ] ]
[ [GROUP(group-name[,group-name]...)] ]
[ [MAXMSG(max-messages) ] ]

On a system, each transport class must have a unique name. The class name is used in
system commands and shown in display output and reports.
By explicitly assigning an XCF group to a transport class, you give the group priority
access to the signaling resources (signaling paths and message buffer space) of the
transport class. All groups assigned to a transport class have equal access to the
signaling resources of that class.
You should check to see if any transport classes are defined in either the incoming system
or in the target sysplex. If there are, first check to see if they are still required—as a
general rule, we recommend against having many transport classes unless absolutely
necessary. If you determine that the transport classes are still necessary, you should then
assess the impact of the incoming system, and make sure you add the appropriate
definitions to the COUPLExx member that will be used by that system after it joins the
sysplex.

Chapter 2. Sysplex infrastructure considerations 21

 5. Table 2-2 contains a list of XCF groups with the owner of each. The corresponding notes
indicate whether the group name is fixed or not, and if not, where the group name is
specified. If your target environment is a BronzePlex and you want to maintain strict
segregation of the workloads, you should pay special attention to any exploiters that have
fixed group names.

Table 2-2 XCF groups in the sysplex

Owner of the group XCF group name Note

APPC, ASCH SYSATBxx A

CICS MRO DFHIR000 B

CICS VR DWWCVRCM C

CICSplex System Manager Name not fixed D

Console services SYSMCS, SYSMCS2 E

DAE SYSDAE F

DB2 Name not fixed G

DFSMS and PDSE sharing SYSIGW00, SYSIGW01 H

ENF SYSENF I

Global Resource Serialization (GRS) SYSGRS, SYSGRS2 J

HSM ARCxxxxxx K

IMS Names not fixed L

I/O Operations component of SA/390 ESCM M

IOS SYSIOSxx N

IRLM Name not fixed O

JES2 Multi-Access Spool (MAS) Name not fixed P

JES3 complex Name not fixed Q

MQSeries CSQGxxxx R

Object Access Method (OAM) xxxxxxxx S

OMVS SYSBPX T

RACF IRRXCF00 U

RMF SYSRMF V

RRS ATRRRS W

System Automation for OS/390 V2 INGXSGxx X

Tape Sharing SYSIEFTS Y

TCP/IP EZBTCPCS Z

Tivoli Workload Scheduler (previously OPC) Name not fixed aa

Trace SYSTTRC ab

TSO Broadcast SYSIKJBC ac

22 Merging Systems into a Sysplex

 Owner of the group XCF group name Note

VLF COFVLFNO ad

VSAM/RLS IDAVQUI0, IGWXSGIS, ae

SYSIGW01, SYSIGW02,
SYSIGW03

VTAM, TCP/IP ISTXCF, ISTCFS01 af

WLM SYSWLM ag

XES IXCLOxxx ah

The notes in Table 2-2 on page 22 refer to the following points:

a. APPC has a unique group for each system in the sysplex, and only one system is in
each group. The system generates the group name, which is in the format SYSATBxx.
The APPC Component Control Block, ATBAPPCA, contains the group name for each
system.
b. CICS will automatically connect to the DFHIR000 XCF group for MRO communications
between systems. This mechanism is described in CICS TS Installation Guide,
GC33-1681. The name of the XCF group used by CICS/MRO is fixed, so all the CICS
regions in the sysplex using XCF for MRO communications will connect to the same
group.
c. CICS VSAM Recovery connects to an XCF group with a fixed name of DWWCVRCM.
It uses this group to gather information from other CICS VR address spaces in the
sysplex in response to a D SMS,CICSVR,ALL or D SMS,CICSVR,LOGSTREAMS command.
d. CICSplex System Manager uses XCF to communicate between the CAS address
spaces. The group name can be specified during customization of CICSplex SM, but
the default is BBGROUP. For more information, refer to CICSplex System Manager
Setup and Administration-Volume 1, SC33-0784.
e. MVS console services use two XCF groups—SYSMCS and SYSMCS2. SYSMCS is
used to send WTOs, DOMs, and commands across systems, as well as to send data
about types of consoles (MCS, SMCS, EMCS, and subsystem), and some
miscellaneous data that CONSOLE needs on each system in the sysplex. SYSMCS2
is used for REPLYID processing, to keep track of which reply IDs are in use by each
system in the sysplex.
f. The SYSDAE group is used by the Dump Analysis and Elimination component of MVS
to pass information between systems about dumps that have been captured. This
information is used to ensure that identical dumps are not captured multiple times
across different systems in the sysplex.
g. DB2 uses its data sharing group name as the name of the XCF group that it joins. This
name is defined during DB2 setup and must be unique within the sysplex.
h. DFSMS uses two XCF groups in support of sysplex sharing of PDSE data sets. The
SYSIGW00 group is used for lock negotiation, and the SYSIGW01 group is used for
status monitoring. The SMXC address space on each system attaches to these two
groups.
i. The MVS Event Notification Facility (ENF) uses the SYSENF XCF group to send ENF
signals from every system to every other system in the sysplex. The IEFSCHAS
address space on every system automatically joins this group, and you have no control
over the group name.

Chapter 2. Sysplex infrastructure considerations 23

 j. When GRS is operating in Ring mode, the SYSGRS group is used to communicate the
RSA, acknowledgement signals, GRS join requests, and ECA requests. In this mode,
there is no SYSGRS2 group.
When GRS is operating in Star mode, the SYSGRS group is used to communicate
GQSCAN requests and ECA requests. In this mode, the SYSGRS2 group only
contains a list of the members of the GRSplex—it is not used for signalling.
k. HSM Secondary Host Promotion uses an XCF group to notify the members of the HSM
XCF group should one of the members fail. The group name is ARCxxxxx, with the
xxxxx value being specified via the HSM SETSYS PLEXNAME command. The default
group name is ARCPLEX0. For more information, refer to DFSMShsm Implementation
and Customization Guide, SC35-0418.
l. IMS OTMA uses XCF to communicate between IMS and the OTMA clients. The name
of the XCF group used for this communication. The name is installation-dependent,
and is specified on the GRNAME parameter in the IMS startup JCL.
IMS also uses an XCF group to allow the Fast Database Recovery (FDBR) region to
monitor the IMS regions it is responsible for. The group name is installation-dependent,
and is specified on the GROUPNAME parameter in the IMS startup JCL. If not
specified, if defaults to FDRimsid, where imsid is the IMSID of the IMS region that is
being tracked.
If using IMS Shared Message Queues, IMS also has an XCF group that is used by the
IMS regions in the Shared Queues group. The name of the group is CSQxxxxx, where
xxxxx is a one-to-five character value that is specified on the SQGROUP parameter in
the DFSSQxxx Proclib member.
m. The I/O Operations component of System Automation for OS/390 (previously ESCON
Manager) attaches to a group with a fixed name of ESCM. All commands passed
between I/O Ops on different systems are actually passed via VTAM (because I/O Ops
supports systems spread over multiple sysplexes), however within a sysplex, I/O Ops
uses the ESCM group to determine the VTAM name of the I/O Ops component on each
system.
n. The I/O Supervisor component of MVS, via the IOSAS address space, connects to an
XCF group with a name of SYSIOSxx. The xx suffix is determined dynamically when
the system is IPLed. There is one SYSIOSxx group per LPAR cluster—so, if you had
three LPAR clusters in the sysplex, there would be three SYSIOSxx groups. These
groups are used by DCM to coordinate configuration changes across the systems in
the LPAR cluster.
o. IRLM uses an XCF group to communicate between the IRLM subsystems in the data
sharing group. The name of the IRLM XCF group is specified on the IRLMGRP
parameter in the IRLM started task JCL. This can be any 8-character name you wish.
p. JES2 uses two XCF groups.
One group is used for communicating between the members of the JES2 MAS. The
default name for this group is the local node name defined on the NAME parameter of
the local NODE(nnnn) initialization statement. We recommend that the default name
be used, unless it conflicts with an existing XCF group name. Alternately, the XCF
group name used by JES can be specified on the XCFGRPNM parameter of the
MASDEF macro.
The other group, with a fixed name of SYSJES, is used for collecting and sharing
diagnostic information about JES/XCF interactions. It is also used in conjunction with
TSO Generic Resource support.

24 Merging Systems into a Sysplex

q. JES3 also uses two XCF groups.
One group is used for communicating between the members of the JES3 complex. The
default name of this group is the node name defined by the NAME= keyword on the
NJERMT initialization statement for the home node (HOME=YES), if one exists. If you
have not defined any NJERMT statements, the default is N1. You can use the
XCFGRPNM keyword of the OPTIONS initialization statement to override the default
JES3 XCF group name.
The other group, with a fixed name of SYSJES, is only used for collecting and sharing
diagnostic information about JES/XCF interactions.
r. If you are using the MQSeries Shared Queues feature (available in MQ V5.2 and later),
MQSeries joins an XCF group called CSQGxxxx, where xxxx is the MQ Shared
Queues Group name. If there were two MQ Shared Queue Groups within the sysplex,
there would be two XCF groups, and each MQ would only be attached to one of the
groups.
s. DFSMS 1.5 introduced the concept of an OAMplex. By using this facility, a number of
systems can access a shared set of objects, and provide the ability for one of the
members of the OAMplex to take over ownership of the 3995 should the current owning
system fail. The name of the OAMplex XCF group and the XCF member name of each
OAM instance are both specified in the CBROAMxx member of Parmlib, and can be
anything you wish.
For more information about OAMplex support, refer to z/OS DFSMS Object Access
Method Planning, Installation, and Storage Administration Guide for Tape Libraries,
SC35-0427.
t. The UNIX System Services component uses an XCF group called SYSBPX to pass
requests between systems that are sharing their HFSs using the Sysplex HFS Sharing
capability introduced in OS/390 2.9. If the BPXPRMxx member used at IPL specifies
SYSPLEX(YES), UNIX System Services will automatically join this group. If it specifies
SYSPLEX(NO), it will not join the group, and that system will not be able to participate
in the shared HFS group. The name of this group is fixed, so you can only have one
HFS sharing group per sysplex. For more information on HFS sharing, refer to
Chapter 8, “Shared HFS considerations” on page 115.
u. RACF optionally uses an XCF group to communicate between members of the RACF
sysplex database sharing group. The name of this group is IRRXCF00 and is fixed, so
there can only be one RACF sysplex database sharing group in the sysplex. Whether a
given RACF instance joins the group or not is controlled by a setting in the ICFRDSNT
module. This is discussed further in Chapter 13, “RACF considerations” on page 189.
v. RMF uses an XCF group called SYSRMF to pass performance information between all
the RMF address spaces in the sysplex. This gives you the ability to be logged on to
one system, but still see RMF information about any of the other systems in the
sysplex. The name of the group is fixed, and RMF automatically joins the group. So,
from any system in the sysplex, you could potentially see what is happening in any
other system.
w. MVS Resource Recovery Services (RRS) uses an XCF group with a fixed name of
ATRRRS to communicate between RRS instances on each system in the sysplex
where RRS is started.
x. System Automation for OS/390 connects to an XCF group called INGXSGxx, where
the xx suffix is defined using the GRPID parameter in the HSAPRMxx member of
SYS1.PARMLIB. In addition, in System Automation for OS/390 V2, the Automation
Manager address space connects to the same group. The suffix for the group must be
specified in the INGXINIT member of DSIPARM for the Automation Agents. If there is

Chapter 2. Sysplex infrastructure considerations 25

 more than one System Automation for OS/390 instance in a single MVS system, each
instance must have connect to a unique XCF group.
y. The automatic tape sharing feature of z/OS (in z/OS 1.2 and later) uses an XCF group
with a fixed name of SYSIEFTS to pass information about tape drive allocations
between all the members of the sysplex. You cannot control the name of the group, nor
can you stop any system from connecting to the group.
z. All the TCP stacks in the sysplex join an XCF group called EZBTCPCS. This group is
used by the stacks to exchange all the information they need to share for all the sysplex
functions like Dynamic XCF, Dynamic VIPAs, Sysplex Distributor, and the like. The
name of this group is fixed, so all the TCPs in the sysplex will potentially be able to
communicate with each other using this group. This is discussed further in Chapter 12,
“TCP/IP considerations” on page 175.
aa.The Tivoli Workload Scheduler for z/OS connects to one, or optionally, two XCF
groups. One of the groups is used to communicate between the controller and trackers,
and can be used to submit workload and control information to the trackers connected
to the same group. The trackers use XCF services to transmit events back to the
controller. The same group is used to give you the ability to define a hot-standby
controller that takes over when XCF notifies it that the previous controller has failed.
In addition, if you are using the data store feature, you need a separate XCF group.
The XCF Group names are specified on the XCFOPTS and DSTGROUP initialization
statements. More information about these features can be found in Tivoli Workload
Scheduler for z/OS V8R1 Installation Guide, SH19-4543.
ab.The MVS transaction trace facility uses an XCF group with a fixed name of SYSTTRC.
Transaction trace provides a consolidated trace of key events for the execution path of
application- or transaction-type work units running in a multi-system application
environment. TRACE TT commands issued on any system in the sysplex affect all
systems. The same filter sets are made active throughout the sysplex as a
consequence of TRACE TT commands, and the systems using those filter sets are
displayed in the output from the DISPLAY TRACE,TT command. The TRACE address
space in every system in the sysplex automatically connects to the SYSTTRC XCF
group, and the XCF group is used to communicate filter set information to all the
systems in the sysplex. However, no trace data is sent over the XCF group, so it is
unlikely that there are any security concerns due to the fact that all systems are
connected to the same group.
ac. The SYSIKJBC XCF group, which has a fixed name, is used to send information to all
the systems in the sysplex about whether the SYS1.BRODCAST data set is shared or
not, and also to notify systems whenever there is an update to that data set. No actual
data, such as the text of messages, for example, is passed through the group.
ad.The MVS Virtual Lookaside Facility (VLF) is used, together with LLA, to improve the
performance of loading frequently used load modules and PDF members. During
initialization, VLF on each system connects to an XCF group called COFVLFNO. This
group is used by VLF to notify VLF on other systems when a member in a
VLF-managed PDS is changed, thus ensuring that the other systems do not use
in-storage, but downlevel versions of the member.
ae.VSAM/RLS uses a number of XCF groups, all of which have names that are
determined by the system and cannot be controlled by the user. The IDAVQUIO group
is used for RLS Quiesce Functions. The SYSIGW02 group is used for RLS Lock
Manager Functions. The SYSIGW03 and IGWXSGIS groups are used for RLS Sharing
Control Functions, and the SYSIGW01 group is for a common lock manager service
which is used by both RLS and PDSE. These XCF groups are used to send messages
around the sysplex in order to allow all of the SMSVSAM address spaces to
communicate with each other. The groups will be connected to by any system where

26 Merging Systems into a Sysplex

 VSAM/RLS is started. Note that you can only have one VSAM/RLS data sharing group
per sysplex, because the lock structure and the XCF group names are all fixed.
af. VTAM joins an XCF group called ISTXCF to communicate with other VTAMs in the
sysplex. There is no way to change the name of the group that VTAM joins, so if you
have two independent groups of VTAMs in a single sysplex (for example, a production
network and a test network), they will automatically communicate. The ISTXCF group
is also used for TCP/IP session traffic between stacks in the same sysplex.
VTAM also joins a second XCF group called ISTCFS01. ISTCFS01 is used to
determine when another VTAM's address space terminates so the VTAM CF structures
can be cleaned up. This structure is also used by MultiNode Persistent Session
support to send messages for planned takeovers. Even if XCFINIT=NO is specified,
VTAM will still join the ISTCFS01 group.
More information about the interaction between VTAM and XCF is provided in
Chapter 11, “VTAM considerations” on page 167.
ag.Every WLM in the sysplex joins an XCF group called SYSWLM. This group is used by
all the WLMs to exchange information about service classes, service class periods,
goal attainment, and so on. The name is fixed, and every WLM automatically connects
to it, even when WLM is running in compatibility mode. This means that every WLM in
the sysplex has information about what is happening on every other system in the
sysplex. This is discussed further in Chapter 4, “WLM considerations” on page 51.
ah.XES creates one XCF group for each serialized list or lock structure that it connects to.
The name of each group is IXCLOxxx, where xxx is a printable hex number. There is
one member per structure connection.
6. It is possible to use both CF structures and CTCs for XCF signalling. If using CTCs, you
must keep in mind that the formula for the number of the CTC definitions is n x (n-1),
where n is the number of systems in the sysplex. For example, a sysplex composed of 12
systems has to define 132 CTCs (12 x 11).
Another issue that should be considered is performance. Generally speaking, the
performance of CF structures for XCF signalling is equivalent to that of CTCs, especially
for XCF message rates below 1000 messages per second. If most XCF messages are
large, CF structures may provide a performance benefit over CTCs. On the other hand, if
most XCF messages are small, CTCs may provide better performance.
Given that the performance for most environments is roughly equivalent, the use of CF
structures for XCF signalling has one significant advantage—CF structures are far easier
to manage than CTCs. To add another image to the sysplex, all you have to do is use the
existing COUPLExx member on the new member, and possibly increase the size of the
XCF CF structures. This will take a couple of minutes, compared to hours of work
arranging the hardware cabling, updating HCD definitions, and setting up and updating
COUPLExx members to add the new CTC definitions. If you decide to use CF structures
instead of CTCs, just remember that you should have two CFs, and you should never
place all your XCF structures in the same CF.

2.4 Coupling Facility Resource Management

The CFRM policy contains the definitions for the CFs used by the sysplex, and the structures
within those CFs.

CFRM policies are stored in the CFRM CDS. In addition to the policies, the CDS also
contains status information about the CFs.

Chapter 2. Sysplex infrastructure considerations 27

 The most complex scenario, from the point of view of merging the incoming system, is if the
incoming system is attached to a CF and has some structures in that CF. In reality, it is
unlikely that a standalone system would be attached to a CF, but we will cater for that situation
in this section.

If your target environment is a BronzePlex, the incoming system’s use of the CF is likely to be
limited to sharing the XCF structures, IEFAUTOS for tape sharing (for systems prior to z/OS
1.2), and the GRS Star structure. You may also wish to use the OPERLOG and
SYSTEM_LOGREC facilities, in which case you should refer to 1.5.4, “System Logger” on
page 12. In addition, if the incoming system is using any CF structures prior to the merge, you
will probably set up those in the CF, with only the incoming system using those structures.

If your target environment is a GoldPlex, the incoming system will probably share at least the
XCF and GRS structures. It may also share other structures like the Enhanced Catalog
Sharing structure, OPERLOG and LOGREC, JES2 checkpoint, and so on. Once again, if you
are considering using OPERLOG and/or LOGREC, you should refer to 1.5.4, “System
Logger” on page 12. In addition, if the incoming system is using any CF structures prior to the
merge, you will probably set up those in the CF—in this case, it may or may not share those
structures with the other systems in the target sysplex.

If your target environment is a PlatinumPlex, the incoming system will probably share all the
structures in the CF with the other systems in the target sysplex. In addition, if the incoming
system is using any CF structures prior to the merge, you will probably set up those in the
CF—in this case, it may or may not share those structures with the other systems in the target
sysplex.

2.4.1 Considerations for merging CFRM

This section contains, in checklist format, a list of items that must be considered when you
decide to merge two or more sysplexes, at least one of which is using a CF prior to the merge.

Table 2-3 Considerations for merging CFRM

Consideration Note Type Done

Ensure all systems in the sysplex have at least two links to all B, G, P
attached CFs.

Check that the CFs have enough storage, and enough white B, G, P
space, to handle the additional structures as well as existing
structures that will increase in size.

Check link utilization if you are going to be sharing existing CF 1 B, G, P

links.

Check that performance of CFs are acceptable and that CFs have 2 B, G, P
sufficient spare capacity to handle the increased load.

Ensure target sysplex CFs have the appropriate CF Levels. 3 B, G, P

Check that the CFRM CDS has an appropriate MAXSYSTEM 4 B, G, P

value.

Check the size of all structures that will be used by the incoming 5 B, G, P
system.

Ensure the target sysplex CFRM supports the same level of 6 B, G, P

functionality as the CFRM in use in the incoming system.

28 Merging Systems into a Sysplex

 Consideration Note Type Done

Move structure definitions from the incoming system CFRM policy 7 B, G, P

to the target sysplex CFRM policy as appropriate.

Check the options on any duplicate structures to ensure they are 8 B, G, P

consistent.

Consider the impact for structures that have fixed names. 9 B, G, P

Do not merge Logger structures unless your target environment 10 B, G, P

is a PlatinumPlex.

The “Type” specified in Table 2-3 on page 28 relates to the sysplex target environment—B
represents a BronzePlex, G represents a GoldPlex, and P represents a PlatinumPlex.

Notes indicated in Table 2-3 on page 28 are described below:

1. If the incoming system resides in an LPAR on a CPC that already contains other members
of the target sysplex, it is likely that you will use MIF (Multiple Image Facility, formerly
known as EMIF) to share the existing CF links between the incoming system and those
other members. In this case, you should check the utilization of those links in advance of
the merge. You use the PTH BUSY field in the RMF CF Subchannel Activity Report as an
indicator of CF link utilization—the percentage of PTH BUSYs should not exceed 10%.
After the merge, you should review the RMF reports again to check contention for CF
paths. If the percentage of PTH BUSYs exceeds 10%, you should consider dedicating the
CF links to each image or adding additional CF links.
2. Prior to the merge, check the performance of all the CFs in the target sysplex. We
recommend that average utilization of CFs should not exceed 50%. This caters for the
situation where you have to failover all your structures into a single CF, and you need to
maintain acceptable performance in that situation. You want to ensure that not only is the
current performance acceptable, but also that there is spare capacity sufficient to handle
the estimated increase in utilization after the merge. For more information, refer to OS/390
Parallel Sysplex Configuration Volume 2: Cookbook, SG24-5638.
After the merge, you should once again check the performance of all CFs to ensure the
performance is still acceptable.
3. If the incoming system is using a CF prior to the merge, you must ensure that the CFs in
the target sysplex have at least the same CF Level as those in use by the incoming system
today. The CF Level dictates the functions available in the CF—for example, MQSeries
shared queues require CF Level 9. More information about CF Levels, including which
levels are supported on various CPC types is available at:
http://www.ibm.com/servers/eserver/zseries/pso/cftable.html
4. If you need to increase the MAXSYSTEM value in the CFRM CDS, you will need to
allocate a new CDS using the IXCL1DSU program. This is discussed in 2.2, “CDS
considerations” on page 16.
5. In order to provide optimal performance and availability, it is important that all CF
structures have appropriate sizes. Some structures are sensitive to the number of
connected systems, or the MAXSYSTEM value as specified in the sysplex CDS.
Therefore, you should review the structure sizes in any of the following situations:
– A change in the number of connected systems
– A change in the MAXSYSTEM value in the sysplex CDS
– A significant change in workload

Chapter 2. Sysplex infrastructure considerations 29

 – A change in the CF Level—as additional functions are delivered, structure sizes tend to
increase, so any time you change the CF Level you should review the structure sizes.
The only way to get an accurate size for a structure is to use the CFSizer tool available at:
http://www.ibm.com/servers/eserver/zseries/cfsizer/
Note: The PR/SM Planning Guide no longer can be used to calculate structure sizes. The
formulas in that document have not been updated since CF Level 7, and will not give
correct values for any CF Level higher than that. Also, the recommended structure values
in the IBM Redbook OS/390 Parallel Sysplex Configuration Volume 2: Cookbook,
SG24-5638 should also be ignored as they are based on old CF Levels.
6. If the incoming system is already using a CF before the merge, make sure the functions
being used in that environment are also available in the target sysplex. The functions are
usually specified in the CFRM CDS, and may have co-requisite CF Level requirements.
You should list the options specified in the CFRM CDS in both incoming system and target
sysplex. Compare the options that have been specified (System Managed Rebuild,
System Managed Duplexing, and so on) and make sure the target sysplex will provide the
required level of functionality. The sample job in Example 2-3 shows how the options are
listed, and shows the available options.

Example 2-3 List of CFRM Couple Data Set

//ITSO01A JOB (ITSO01),'ITSO-LSK051-R',
// CLASS=A,NOTIFY=&SYSUID
//LOGDEFN EXEC PGM=IXCMIAPU
//SYSPRINT DD SYSOUT=*
DATA TYPE(CFRM) REPORT(YES)

DATA TYPE(CFRM)
ITEM NAME(POLICY) NUMBER(5)
ITEM NAME(STR) NUMBER(200)
ITEM NAME(CF) NUMBER(8)
ITEM NAME(CONNECT) NUMBER(32)
ITEM NAME(SMREBLD) NUMBER(1)
ITEM NAME(SMDUPLEX) NUMBER(1)
...

7. If the incoming system is using structures that are not being used in the target sysplex,
those structures (for example, the structure for a DB2 in the incoming system) must be
added to the CFRM policy in the target sysplex.
Other structures that may be in use in the incoming system, like the XCF structures, will
not be moved over to the target sysplex because they will be replaced with shared ones
that are already defined in the target sysplex. In that case, you must update any
references to those structure names in the incoming system.
8. For structures that existed in both the incoming system and the target sysplex, like the
XCF structures, make sure that the definition of those structures in the target sysplex is
compatible with the definitions in the incoming system. For example, if the incoming
system uses Auto Alter for a given structure and the target sysplex does not, you need to
investigate and make a conscious decision about which option you will use.
9. Some structures have fixed names that you cannot control. Therefore, every system in the
sysplex that wants to use that function must connect to the same structure instance. At the
time of writing, the structures with fixed names are:
– OPERLOG
– LOGREC
– GRS Lock structure, ISGLOCK

30 Merging Systems into a Sysplex

 – VSAM/RLS Lock structure, IGWLOCK00
– RACF database sharing structures, IRRXCF00_B00n, IRRXCF00_P00n
– Tape sharing (prior to z/OS 1.2), IEFAUTOS
– Enhanced Catalog Sharing, SYSIGGCAS_ECS
– WLM Multi-System Enclaves
– WLM LPAR Cluster
If you use any of these structures in the incoming system, you need to assess the impact
of moving the incoming system into the sysplex, especially in a BronzePlex environment.
Additionally, for the Logger structures with fixed names (OPERLOG and LOGREC), if you
are moving to a BronzePlex or a GoldPlex, you should review the discussion about shared
DASD considerations in 1.5.4, “System Logger” on page 12.
10.If your target environment is a BronzePlex or a GoldPlex, you need to ensure that each
Logger structure (except OPERLOG and LOGREC, as noted above) is only connected to
by systems that are in the same subplex. Therefore, when merging your CFRM policies,
pay particular heed not to merge Logger structures except if your target environment is a
PlatinumPlex. This is discussed further in Chapter 3, “System Logger considerations” on
page 37.

2.5 Sysplex Failure Management

Sysplex Failure Management (SFM) allows you to define a sysplex-wide policy that specifies
the actions that z/OS is to take when certain failures occur in the sysplex. A number of
situations might occur during the operation of a sysplex when one or more systems need to
be removed so that the remaining sysplex members can continue to do work. The goal of
SFM is to allow these reconfiguration decisions to be made and carried out with little or no
operator involvement.

Some SFM actions are specified on the sysplex level, while others can be specified for
individual systems. SFM controls actions for three scenarios:
1. If there is a loss of XCF signalling connectivity between a subset of the systems, SFM can
decide, based on the weights you specify for the systems, which systems must be
removed from the sysplex in order to restore full connectivity. This is controlled by the
CONNFAIL keyword, and is enabled or disabled at the entire sysplex level.
2. In the event of the loss of a system, SFM can automatically partition that system out of the
sysplex, releasing any resources it was holding, and allowing work on other systems to
continue. This action can be specified at the individual system level. For example, you can
tell SFM to automatically partition SYSA out of the sysplex if it fails, however to prompt the
operator in case SYSB fails. This is controlled via the ISOLATETIME and PROMPT
keywords. As a general rule however, we recommend that ISOLATETIME is always
specified so that dead systems can be partitioned out of the sysplex as quickly as
possible.
3. If you use PR/SM reconfiguration to move processor storage from one LPAR to another, in
the event of a system failing, SFM will control that processing if you provide the
appropriate definitions.

Chapter 2. Sysplex infrastructure considerations 31

 If your target environment is a BronzePlex, you need to decide how you want to use SFM. In a
sysplex environment, it is vital that dead systems are partitioned out of the sysplex as quickly
as possible. On the other hand, if a subset of the systems in the sysplex are running work that
is completely independent of the other systems in the sysplex, you may prefer to have more
control over what happens in the case of a failure. You may decide to specify CONNFAIL NO
in this situation, which will cause the operator to be prompted to decide which system should
be removed from the sysplex.

Figure 2-3 shows a typical configuration, where systems SYSA and SYSB were in the original
target sysplex, and SYSC is the incoming system which is now a member of the sysplex. If
the link between systems SYSB and SYSC fail, the sysplex can continue processing with
SYSA and SYSB, or SYSA and SYSC. If the applications in SYSA and SYSB support data
sharing and workload balancing, you may decide to remove SYSB as the applications from
that system can continue to run on SYSA. On the other hand, if SYSA and SYSB contain
production work, and SYSC only contains development work, you may decide to remove
SYSC.

SYSA SYSB

SYSC

Figure 2-3 SFM CONNFAIL scenario

You can see that the decision about how to handle this scenario depends on your specific
configuration and availability requirements. For each system, you then need to carefully
evaluate the relative weight of that system within the sysplex, and whether you wish SFM to
automatically partition it out of the sysplex (by specifying ISOLATETIME), or you wish to
control that process manually (by specifying PROMPT). If you can assign a set of weights that
accurately reflect the importance of the work in the sysplex, we recommend that you use
ISOLATETIME.

If your target environment is a GoldPlex, your SFM decision will be based on the level or
workload sharing across the systems in the sysplex. Once again, you want to partition dead
systems out of the sysplex as quickly as possible. If the work is spread across all the systems
in the sysplex, we recommend that you specify CONNFAIL YES, to quickly remove any

32 Merging Systems into a Sysplex

Random documents with unrelated
content Scribd suggests to you:
WHEELER, EVERETT PEPPERRELL. Sixty years of American life,
Taylor to Roosevelt, 1850 to 1910. il *$2.50 Dutton 329 17-3602
“This book is not a volume of personal or social memoirs. It is true
that the author has much to say of the great figures in the
country’s history during these sixty years. He has, for example, an
interesting chapter on ‘Presidents I have known,’ and another on
‘Changes in sixty years.’ And scattered throughout his record are
many delightful personal touches, that seem to slip in almost
unaware. But the book as a whole is a study of political activity. Mr
Wheeler has taken an especially important part in the work of civil
service and in tariff reform. He has always been, as well, intimately
concerned with the municipal problems of New York city
government. And these are the matters that, readably and in
valuable detail, are emphasized in his book.”—N Y Times
+ A L A Bkl 13:335 My ‘17

+ Boston Transcript p6 F 17 ‘17 700w

“The chapters on the tariff and on municipal reform appeared in
the New York Evening Post and the Outlook.”
+ Cleveland p71 My ‘17 40w

+ Ind 91:76 Jl 14 ‘17 50w

“An inspiring book it is in every way, breathing through its five
hundred pages an unshaken loyalty to the principles of democratic
government, yet demonstrating how much one man can do,
through inconspicuous channels, towards making that scheme of
government measure up to its ideals.”
+ Nation 104:582 My 10 ‘17 280w

N Y Br Lib News 4:39 Mr ‘17

 “Offers a valuable and unusual addition to our knowledge of our
country’s internal history.”
+ N Y Times 22:49 F 11 ‘17 600w

Pittsburgh 22:685 O ‘17 70w

+ R of Rs 55:444 Ap ‘17 120w

St Louis 15:154 My ‘17

“One wishes that Mr Wheeler had injected more of that fervor of
impressionistic memory that made the late Justin McCarthy’s
‘Reminiscences,’ for instance, such delightful reading. The
reprinting of bits of speeches in themselves lend little color to the
relation of the struggle for civil-service reform in which Mr Wheeler
was so eminently engaged. ‘Presidents I have known’ is
disappointingly most impersonal.”
+ Springf’d Republican p17 Je 3 ‘17 300w
—

WHEELER, WILLIAM REGINALD, ed. Book of verse of the great

war. *$2 Yale univ. press 821.08 17-30693
“During the past two years and a half the compiler of this volume
has resided in Europe, America and Asia and has endeavored to
choose the most worthy expressions of sentiment concerning the
war which have come from these three continents.” (Editor’s
preface) He has excluded those poems which seemed inspired by
the extreme animosities of the war, holding to this principle in the
hope that the book “may contribute in some small measure to a
renewal of the fellowship of the universal community of mankind.”
Among the poets represented are: Laurence Binyon, Dana Burnet,
Emile Cammaerts, Gilbert Frankau, John Galsworthy, W. W. Gibson,
Thomas Hardy, W. M. Letts, Josephine Preston Peabody, and
 Rabindranath Tagore. There is a foreword by Charlton M. Lewis,
professor of English literature at Yale.
A L A Bkl 14:159 F ‘18

Cleveland p5 Ja ‘18 130w

“The principles of selection shown in this collection are judicious,
but it is to be regretted that the poems for the most part chosen
have appeared in another book which is less expensive, easier to
hold and more attractive to the eye.”
+ Springf’d Republican p13 Ja 20 ‘18 130w
—

WHERRY, EDITH. Wanderer on a thousand hills. *$1.40 (2c) Lane

17-11706
The first part of this story tells the tragedy of little Tung Mei,
Winter Almond. An only child, she had been educated by her
father in defiance of Chinese custom. But the only fate for a
Chinese girl, even one who can read the classics, is marriage, and
marriage means slavery under the domination of a mother-in-law.
In bearing a girl child, Tung Mei is disgraced. She is held
responsible for her husband’s sudden death, her baby is murdered
and she is driven out into a storm. The second part of the story
begins with her finding of little Carl Osborne, the child of
missionary parents. Like herself he is lost in the storm, and Tung
Mei in her distraught state looks on him as a gift from heaven to
assuage her woe. She brings him up as her own, and it is not till
he reaches young manhood that he learns that he is not of
Chinese birth. He tries unsuccessfully to adapt himself to foreign
ways, and later becomes the fanatic known as the wanderer on a
thousand hills.
“A grievous and dismal tale with hardly any relief and with extreme
attention paid to the particulars of Chinese superstition and the
 delusions of Chinese fanaticism.”
— Boston Transcript p6 Je 20 ‘17 100w

+ Dial 62:528 Je 14 ‘17 50w

“The book has dramatic quality and atmosphere.”
+ Ind 90:295 My 12 ‘17 160w
“It shows, as did ‘Kim,’ that a story, void of the master passion,
may yet command a breathless interest. ... As we read, we are
conscious of more than intellectual enjoyment; we are tarrying a
while at the Interpreter’s house.”
+ N Y Times 22:183 My 6 ‘17 500w
“By a Canadian writer—the wife of a Montreal physician.”
+ Ontario Library Review 1:121 My ‘17 70w
“A tragic and often painful story.”
Outlook 116:74 My 9 ‘17 60w
“Interesting psychological study contrasting the oriental and
western ideals.”
+ Pratt p32 O ‘17 10w
“The story intimately pictures the human side of the Chinese, and
should go far in helping the unprejudiced westerner to a truer
understanding of these people. These pictures contain, perhaps,
more than a dash of idealism, suggested by the author’s obviously
sympathetic attitude.”
+ Springf’d Republican p13 Je 17 ‘17 500w

WHETHAM, CATHERINE DURNING (HOLT) (MRS WILLIAM

CECIL DAMPIER WHETHAM). Upbringing of daughters.
 *$1.75 (2c) Longmans 173 17-28870
This book by an Englishwoman has chapters on: The creation of
the home; The life of the family; Household duties; Health; Dress;
Outdoor life and games; General education; Scholastic instruction;
The arts; Holidays and entertainments; Books to read; Money
matters; Professions for daughters; Conduct; Religion; The
abdication of the parent. The discussions touch on many other
subjects than that suggested by the title, altho the author writes
always from the viewpoint of a housewife and mother. On matters
pertaining to education, professional careers for women, etc., she
is conservative.
“Concerning education she would, no doubt, be classed by many
as a hopeless reactionary. But Mrs Whetham’s restatements are of
the kind that make old things new. ... Though the book is close,
earnest reading, it is neither heavy nor pedagogic; it appeals to all
who take interest in intelligent defence of the standards by which
alone any true progress has been or ever can be made.”
+ Cath World 105:833 S ‘17 300w

WHIPPLE, GEORGE CHANDLER. State sanitation; a review of the

work of the Massachusetts State board of health, 1869-1914. 2v
*$2.50 Harvard univ. press 614.09 (17-13246)
Two volumes devoted to this subject have been issued. The first
volume “is in two parts. Part 1 first sketches the early history of
public health work in Massachusetts to the beginning of the board
in 1869. It then outlines the history and the work of the board and
its divisions, including the world-famous Lawrence experiment
station for the study of water purification and sewage treatment
and the engineering work of the board. There is also a chapter of
biographical sketches; a chapter on the state department of
health, 1914-16, and one on state sanitation in general. Part 2 is
an able condensation of the lengthy ‘Report of the Massachusetts
sanitary commission of Massachusetts’ which under the leadership
of Lemuel Shattuck worked out a detailed plan for a ‘sanitary
survey’ of the state—really a scheme for state and local health
work.” (Engin News-Rec) “The second volume contains in some
cases reprints and in other cases abridgments of the more
important articles or studies which have appeared in the
publications of the Massachusetts state board of health during the
past forty-seven years. Included also are chronological abstracts of
the board’s annual reports.” (Am Pol Sci R) “Extracted from the
1878 report of the board is a paper entitled ‘The filtration of
potable water,’ written by Prof. Wm. Ripley Nichols. This is one of
many classics on water and sewage treatment which are reprinted
in full or abstract in this volume.” (Engin News-Rec)
“Professor Whipple’s keen eye for the things that are interesting
has enabled him to make his book readable throughout. That it will
be of great service to special students of the subject is beyond
question.”
+ Am Pol Sci R 11:791 N ‘17 170w (Review of v
1)
“Many of these writings represent pioneer achievement in the
domain of public health administration, and taken as a whole they
afford an interesting history of the stages through which that
science has developed during the last half century.”
+ Am Pol Sci R 12:158 F ‘18 90w (Review of v
2)
“An interesting and stimulating record of American progress in
state and municipal sanitation and preventive medicine.”
+ Dial 63:165 Ag 30 ‘17 230w (Review of v 1)
“Professor Whipple is rendering a notable service. The pleasurable
task he is doing so well is one for which he is well qualified
through long acquaintance with members of the board and of its
staff and through service on the Massachusetts public health
council since 1914.”
 + Engin News-Rec 79:130 Jl 19 ‘17 300w
(Review of v 1)

+ Engin News-Rec 80:130 Ja 17 ‘18 450w

(Review of v 2)
“A book of general as well as technical interest.”
+ Springf’d Republican p6 O 15 ‘17 400w
(Review of v 1).

WHITE, ALBERT CLEMENT, ed. Little book of Irish verse. *60c

Dutton 821.08
“The profits from the sale of ‘A little book of Irish verse’ are
destined to add to the comfort of Irish troops, wounded or in the
field. Tho this collection cannot bear comparison with that in
Yeats’s ‘Book of Irish verse,’ it still contains verses by some of the
best Irish poets of the day. Irish war poems are in evidence, but
not less so lyrics on themes quite unconnected with the present
conflict.”—Ind
+ Ind 89:196 Ja 29 ‘17 100w
“Mr White, who is editor of the Ulster Guardian, has made careful
selection from the verse of some of the best known of the modern
Irish poets and in the main, as has been suggested, has chosen
poems with a war-time theme.”
+ Springf’d Republican p6 Ja 30 ‘17 250w

WHITE, VILLETTE HUTCHINS.[2] Mental control of the body; or,

Health through self-conquest. *$1 (4c) Clode, E: J. 131 17-
21698
Aims to show the way to bodily healing thru an intelligent
understanding of a few basic facts, a vital faith in the possibility of
 cure and a disciplined will to realize upon that faith. It differs from
Christian science healing in its conscious effort to treat disease as
a reality—to be met by bringing all the bodily forces and functions
under one’s control thru the will. The writer once establishing the
theory of her health scheme proceeds to give a simple practical
method of application by which the reader may find health.

WHITE, WILLIAM ALANSON.[2] Mechanisms of character

formation. *$1.75 (3c) Macmillan 130 16-22292
For descriptive note see Annual for 1916.
“On the whole, Dr White’s book shows wide learning and offers
much interesting material, but lacks logical coherence and
exactness of terminology and is marred occasionally by slovenly
English. In spite of its subtitle, ‘An introduction to psychoanalysis,’
it hardly meets that need as successfully as Hitschmann’s ‘Freud’s
theories of the neuroses,’ recently made accessible to English
readers, neither does it possess the incisiveness and clarity of
Professor Holt’s brilliant little book, ‘The Freudian wish.’ The chief
attraction of the book is the note of broad and sympathetic
humanism running through it.” J: M. Mecklin
+ J Philos 14:715 D 20 ‘17 750w
—
“We have apprehended no real ‘message’ in this book, either to
the medical student or to the general reader; it seems to us to get
nowhere in particular.”
– Nation 104:584 My 10 ‘17 200w
+
“The criticism which applies to all Freudian psychologists applies to
the present author as well. They assume much and interpret much
on slender evidence.”
— Springf’d Republican p6 O 30 ‘17 200w
 “Its teaching is rather obscured than clarified by the vague
philosophy of life and of the universe which the author, in common
with many of the school, delights in spinning about the facts of
their practice.” R. S. Woodworth
– Survey 38:361 Jl 21 ‘17 110w
+

WHITEHEAD, HENRY, bp. of Madras. Village gods of South India.

il *85c Oxford 229 17-3158
“This is the first of a series of small volumes dealing with the
Religious life of India, under the editorship of Mr J. N. Farquhar,
literary secretary, Y. M. C. A. in India. The volume under review is
by the Bishop of Madras. ... He shows how the village gods
symbolize the facts of village life, and suggests the hypothesis that
the form of their worship, viz., animal sacrifice, is a survival of
totemism from a time when the people lived a nomadic life. ... The
fact that women perform so much of the agricultural work among
primitives suggests an explanation for the fact that the majority of
the South Indian deities are female.”—Bib World
“Gives a mass of new material for the study of comparative
religion.” W. D. S.
+ Am J Theol 21:157 Ja ‘17 200w
“The book is deserving of a hearty reception by students of the
history of religion.”
+ Bib World 49:48 Ja ‘17 200w
“It is a needed volume, handy, straightforward, and not
antipathetic.”
+ Lit D 54:913 Mr 31 ‘17 140w
“A glossary of Indian terms, a list of gods, male and female, and a
geographical index to the ethnological divisions, all provided with
 diacritical marks, promise well for the series.”
+ Nation 103:615 D 28 ‘16 400w

+ Spec 117:136 Jl 29 ‘16 140w

“Mr J. N. Farquhar is entirely competent. Successive volumes,
some in preparation and others in projection, are to be written by
authorities who have every reason and opportunity for full
investigation upon the spot.”
+ The Times [London] Lit Sup p412 Ag 31
‘16 90w

WHITING, LILIAN. Adventure beautiful. il *$1 (2c) Little 134 17-

25596
The author has taken Charles Frohman’s words: “Death is the most
beautiful adventure in life,” for the text of her first essay. The
present appalling sacrifice of life leads her to look for spiritual
compensations and to contemplate the possibility of immortality
and its evidences. The remaining essays of the book are: The
reality of the unseen; Twenty years in retrospect; Some psychical
experiences; Powers of the ethereal body; The nature of the
ethereal world; Creative agencies of the spiritual life; Make room
for happiness; Also the Holy Ghost, the Comforter.
“Miss Whiting has made a genuine contribution to the discussion of
a theme which must more and more command the world’s
attention.”
+ Boston Transcript p9 D 5 ‘17 300w

+ Lit D 56:36 Ja 26 ‘18 130w

“Miss Whiting has much to say of the sort of spiritualism taught by
Professor Hyslop. With this spookery she mingles fragments of
mysticism caught from anywhere in the Orient. The effect of the
 mixture upon one soul at least is not exalting, but there are
readers who enjoy Miss Whiting’s rhapsodies more than does this
reviewer.”
— Nation 105:517 N 8 ‘17 200w
“One can hardly lay down her book without feeling more hopeful
of happiness in the world beyond.”

+ N Y Times 22:498 N 25 ‘17 400w

WHITING, LILIAN. Canada, the spellbinder. il *$2.50 Dutton 917.1

17-22084
“A brief survey of the ‘creative forces’ of Canada, those explorers,
missionaries, adventurers, pioneers, traders, scientists and
statesmen who from the sixteenth to the twentieth centuries have
explored and developed her picturesque and fruitful domains, is
followed by detailed studies of various localities.” (Boston
Transcript) “Beginning with ‘Quebec and the picturesque maritime
region,’ Miss Whiting travels slowly westward, describing the chief
cities, the summer resorts, visiting Cobalt and the silver mines,
and so going on through Winnipeg and Edmonton to the western
coast. There is a chapter on ‘Prince Rupert and Alaska,’ and
another describing the journey from Prince Rupert by way of
Vancouver, Victoria, and Seattle to San Francisco, where another
section is devoted to Canada in the Panama-Pacific exposition.” (N
Y Times) “There is a chapter on the poets of Canada, C. G. D.
Roberts, Bliss Carman, W. H. Drummond, and others.” (Spec) “The
book incorporates portions of Miss Whiting’s articles which
appeared in the Sunday Springfield Republican in 1916.” (Springf’d
Republican)
A L A Bkl 14:57 N ‘17
“The interest of this readable volume is increased by numerous
fine illustrations in colour and monotone.”
+ Ath p315 Je ‘17 40w
“Miss Whiting reviews for us not only the development of those
Canadian cities and provinces of which we already have a
superficial knowledge, but also such places as Winnipeg and Prince
Rupert.”
+ Boston Transcript p6 Ag 1 ‘17 420w
“She lacks great power of description, but to offset this, falls back
upon scores of writers and poets who have written of the scenes
she visits.”
+ Cath World 106:546 Ja ‘18 90w
—

+ Cleveland p12 Ja ‘18 40w

“Lilian Whiting’s enthusiasm of spirit and glow of language are at
their usual high level in ‘Canada the spellbinder.’”
+ Nation 105:18 Jl 5 ‘17 180w
—
+ N Y Times 22:236 Je 17 ‘17 250w

Pittsburgh 22:677 O ‘17 70w

+ Spec 118:593 My 26 ‘17 70w

“A very happy specimen of globe-trotting literature taken in serious
vein. ... Journalists and readers who are interested in journalism
will note with special attention Miss Whiting’s comment on the
founder of the Toronto Globe.”
+ Springf’d Republican p10 O 4 ‘17 480w
WHITMAN, SIDNEY. Things I remember. *$2.50 (3½c) Stokes 17-
8078
The subtitle describes this book as “The recollections of a political
writer in the capitals of Europe.” The author was for many years
special correspondent for the New York Herald. His recollections go
back to the early nineties. Among other things he writes of:
Vienna; Salonica and Constantinople; The Spanish-American war;
Bismarck’s death; Warsaw in revolt; Berlin during the Algeciras
conference; W. T. Stead; James Gordon Bennett.
A L A Bkl 13:352 My ‘17

+ Pittsburgh 22:406 My ‘17 50w

“Mr Whitman, well known for his travels over Europe and his
intercourse with great and formidable people for the benefit of the
‘New York Herald,’ has revived some of his memories in a pleasant
and easy narrative. ... We have much to learn concerning
Germany, and Mr Whitman is well qualified to teach us.”
+ Sat R 122:461 N 11 ‘16 750w
“A most interesting book, and one which deserves the attention of
all those who desire to understand the inner working of German
policy.”
+ Spec 117:554 N 4 ‘16 750w
“One of the best books of memoirs which have recently appeared.”
+ The Times [London] Lit Sup p494 O 19 ‘16
650w

WHITTON, FREDERICK ERNEST.[2] History of Poland from the

earliest times to the present day. *$3 Scribner 943.8
“Major Whitton traces the record of ‘the most unfortunate and not
the least noble of European peoples,’ the rise and fall of their great
kingdom. Naturally our interest centres in events since the
beginning of the famous partitions, and in the fate of Poland under
Russian, Prussian, and Austrian rule. The story of the partitions is
told in detail, with significant sketches of the characters of the
rulers involved—Catherine the Great of Russia, first Frederick the
Great and then Frederick William of Prussia, and first Maria
Theresa and then Francis of Austria.” (N Y Times) “In his story of
the famous partitions Colonel Whitton follows Lord Eversley fairly
closely, but he has been preserved by study of the cold-blooded
‘Cambridge modern history’ from being too pronounced a partisan
of the Poles. He is fully alive to the weak points in their national
character and to the viciousness of their system of government.”
(Spec)
+ Ath p531 O ‘17 220w
“His narrative is interesting, readable, and to the point. But the
book suffers from two weaknesses—a marked insufficiency of
dates and a remissness in dealing with the life of the common
people.”
+ Ath p585 N ‘17 570w
—

Boston Transcript p6 Ja 16 ‘18 490w

“‘A history of Poland’ is not only a presentation of valuable and
pertinent facts, but is written with a simplicity and vividness that
make the book thoroughly interesting.”
+ N Y Times 23:2 Ja 6 ‘18 360w
“He would, we are sure, lay no claim to be an original historian; he
has not added anything to the sum of knowledge. Nevertheless,
we can cordially recommend his book.”
+ Spec 119:358 O 6 ‘17 820w
 “The author gives a clear but not very well balanced account of
the Polish kingdom under its successive monarchs. It must be
confessed, that the earlier part of the book is unsatisfactory,
especially chapters 1 and 3, and contains actual mistakes. The
best part of Major Whitton’s book is certainly its later portion.”
+ The Times [London] Lit Sup p511 O 25 ‘17
— 1500w

WHITTON, FREDERICK ERNEST. Marne campaign. (Campaigns

and their lessons) maps *$4 (5c) Houghton 940.91 17-24849
For years before the outbreak of the European war, Major Whitton
points out in his preface, military experts of all countries had been
considering the problem of handling the huge armies which a
modern war would demand. In the campaigns of the Marne
theories were put to a practical test, and it is from this point of
view, that of military strategy, that the battle is here studied. “The
battle of the Marne furnishes the military student with a signal
example of the strategical counter-attack on a great scale.” Eight
folding maps are provided at the end and there is a bibliography.
A L A Bkl 14:91 D ‘17
“Will be useful to civilian and military readers alike. Eight clear
maps illustrate the book.”
+ Ath p260 My ‘17 140w
“The book contains an excellent map of the alignments of the
armies, numbered according to their corps, divisions and brigades
upon the most reliable up-to-date information.”
+ Ind 91:477 S 22 ‘17 170w
“The present volume tells this story in a particularly masterly
manner, and is perhaps the best documented and most
circumstantial account of the great battle. None, in fact, that has
 been issued is comparable to it, except Mr Belloc’s volume of about
a year ago.”
+ Lit D 55:38 O 13 ‘17 580w

N Y Times 22:323 S 2 ‘17 250w

+ R of Rs 56:213 Ag ‘17 130w

“He is clear and concise, and his book gives a much better general
impression of the battle of the Marne than any other we know.”
+ Sat R 123:284 My 24 ‘17 250w
“A very useful and well-written narrative. There have been two
rival theories of the Marne. The common view is that General
Maunoury’s flank attack on the Ourcq upon General von Kluck,
who commanded on the German right was the deciding factor.
Major Whitton adopts this theory, and supports it by a good deal
of evidence.”
* + Spec 119:143 Ag 11 ‘17 1350w
“Considering that Major Whitton’s narrative is built throughout of
similar and not more stable material, we are half inclined to mourn
over the labour which he has expended upon it. For the author has
not done his work ill. He writes good, clear, and vigorous English;
and his summary of the military and naval resources of the
combatants and of the operations preceding the battle of the
Marne is, so far as his information goes, terse and pointed.”
+ The Times [London] Lit Sup p195 Ap 26
— ‘17 1450w

WHYTE, ADAM GOWANS. World’s wonder stories. il *$1.75 (2½c)

Putnam 500 18-2983
A book of rather miscellaneous information about the universe,
together with a discussion of ethical problems, designed for young
readers. Contents: How was the world made? Where did the plants
and animals come from? Nature’s family tree; Who was the first
man? Who was the greatest grandfather of creation? Where did all
the religions come from? Where did the Bible come from? Where
did right and wrong come from? How do things happen? There are
many illustrations.
“It is that rare thing, a book written for children without being in
some sense written down to them,—and therefore a delight to the
reader of any age.” J: Walcott
+ Bookm 46:497 D ‘17 120w

Ind 92:449 D 1 ‘17 30w

“The information is correct and modern; and the language is
dignified and circumspect. Orthodox teachers and parents whose
teaching of morality follows conventional lines would undoubtedly
derive benefit from the method of presentation adopted, while no
child could read the book without understanding something of the
scientific method and what it has accomplished.”
+ Nature 98:208 N 16 ‘16 160w
“A vast amount of valuable information is included in the volume.”
+ Springf’d Republican p8 D 21 ‘17 110w
“We began the book with misgiving, as the style seemed to
foreshadow that lisping sing-song which is the form of address so
often deemed appropriate in modern children’s books. But we
proceeded with growing pleasure, and finally devoured all the
wonders with relish. It is a delightful book. ... We may add as a
parting criticism that we doubt whether it was well advised to
include the picture of ‘what our great-grandfathers and great-
grandmothers looked like in the days when the ape-men were
slowly changing into men.’”
 + The Times [London] Lit Sup p609 D 14 ‘16
— 380w

WIDDEMER, MARGARET. Factories. *$1.25 Holt 811 17-23582

This book was first published in 1915 under the title, “Factories,
with other lyrics”; and has been for some time out of print. The
publisher states that the book has been reset for this new edition,
and that the author has made some changes in the original text as
well as added a number of new poems. The poems, with the
exception of the title poem, are grouped under the headings:
Poems of now; The wandering singer; Youth learns; Greek folk
songs; Love songs; The border country.

WIDDEMER, MARGARET. Winona of Camp Karonya. il *$1.25

(1½c) Lippincott 17-28799
The story opens with the breaking up of camp and the return of
the Camp Karonya girls to town. During the winter following they
assume responsibility for a family of neglected children and plan a
pageant, in addition to carrying on the usual Camp fire activities.
The story has two mysteries, one concerning a lost boy, who
seems to have strayed over from the war zone, the other
connected with a lost baby.
“The main thing is less the plot than the atmosphere of
unselfishness and right feeling with which, without sentimental
strain, the writer surrounds her story.” J: Walcott
+ Bookm 46:499 D ‘17 140w
“The author of this book understands the Camp fire girl movement
thoroughly. Her one endeavor throughout is to show the effect
that Camp fire virtues have on a group of very healthy girls.”
+ Lit D 55:60 D 8 ‘17 33w
“A nice, long worth-while story.”
 + N Y Times 22:466 N 11 ‘17 120w

WIDDEMER, MARGARET. Wishing-ring man. il *$1.35 (2c) Holt

17-25082
Joy Hayenith, nineteen and beautiful, is kept a child by her famous
and egoistical grandfather, the poet. She meets a young doctor
who finds out that Joy is longing for pleasure and adventure, and
tells her that if she keeps on believing things will happen that very
belief may bring her what she wants “like a wishing-ring.” In order
to get permission to visit Phyllis and Allan Harrington, of “The rose
garden husband,” Joy lies to her grandfather, telling him that she is
engaged to the Harrington’s friend and neighbor, Dr John Hewitt.
Hewitt appears on the scene unexpectedly and accepts the
situation. The story goes on to picture the consequences of this
word spoken in jest. All misunderstandings are finally cleared up,
and the book ends happily.
A L A Bkl 14:99 D ‘17
“We enter the land of romance when we read one of these novels
of Miss Widdemer’s. Reality is there too, but it is a guest rather
than the ruler of the kingdom. The bits of humor help toward this
perfect welding of romance and reality.” D. L. M.
+ Boston Transcript p9 O 27 ‘17 780w
“Margaret Widdemer has given us an impossible book—a naïve
book—a book that reminds us, in its simplicity, of the days when
we read and enjoyed ‘The five little Peppers,’” D: P. Berenberg
— N Y Call p15 N 11 ‘17 460w
“A charming, slight little tale, written with vivacity and with ever-
bubbling humor.”
+ N Y Times 22:397 O 14 ‘17 320w
 “It is the purpose to make ‘The wishing-ring man’ a sequel to ‘The
rose garden husband.’ But structural similarity makes this only a
weak and frankly artificial echo of the other charming romance.”
– Springf’d Republican p17 D 9 ‘17 200w
+

WIER, ALBERT E. Grand opera with a victrola. *75c Appleton

782.1 16-4756
A book “containing the stories, the most popular music, and the
Victor record numbers of Aïda, Faust, Carmen, Tannhäuser,
Lohengrin, Cavalleria rusticana, Rigoletto, Il trovatore, The
Bohemian girl, Tales of Hoffman, Hansel and Gretel, Lucia di
Lammermoor; arranged for playing, singing and the selection of
Victor records.”—N Y Br Lib News
A L A Bkl 13:388 Je ‘17

N Y Br Lib News 4:73 My ‘17

St Louis 15:173 Je ‘17

Wis Lib Bul 13:62 F ‘17 70w

WIERS-JENSSEN, HANS. Anne Pedersdotter. *$1 Little 839.8 17-

24983
The author is a Danish dramatist. The English version of “Anne
Pedersdotter” is by John Masefield. The play has been produced
both in England and America. The action takes place in Bergen in
the year 1574, and concerns a case of witchcraft in which Anne
Pedersdotter, wife of Absolon Beyer, palace chaplain, is the central
figure. The first three acts are laid in Absolon’s house, the last in
the choir of the cathedral.
 Reviewed by Algernon Tassin
+ Bookm 46:349 N ‘17 110w

Cleveland p135 D ‘17 50w

“It is a drama of great possibilities; but the tragic, unexpected
climax will prevent it from ever becoming popular and makes it a
play to be read rather than acted.”
+ New Repub 13:sup16 N 17 ‘17 210w
—
“The trial scene for dramatic power must stand with the great
scenes of modern drama.”
+ R of Rs 57:109 Ja ‘18 150w
“Apparently the morbid horror of numerous situations is the only
raison d’etre of the piece.”
— Springf’d Republican p17 N 18 ‘17 220w

WIGMORE, JOHN HENRY, ed. Science and learning in France;

with a survey of opportunities for American students in French
universities. il $1.50 Soc. for American fellowships in French
universities, J. H. Wigmore, ed., 31 Lake st., Chicago; for sale by
McClurg 378 17-26896
This volume of over 400 pages, the work of nearly 100 leading
American scholars and members of college and university faculties,
takes up some 22 subjects—medicine, engineering, philology,
chemistry, geology, archæology, etc. The general editor is John H.
Wigmore of Northwestern university, and associated with him as
vice chairman of the Author’s committee is Charles H. Grandgent
of Harvard university. “As stated in its preface, its purpose is to put
before the American public the contributions of France in all fields
of scientific knowledge, and to show her status in the forefront of
the world’s progress, thus furnishing to American university
students an incentive to pursue graduate work in France. Each
chapter sets forth briefly for a particular field the notable
achievements and eminent leaders of French scholarship during
the past century; and the courses of instruction given now or
recently at the French universities, especially at the University of
Paris, with the facilities available for study and research. There is
also an introduction, by President Emeritus Eliot of Harvard, on the
intellectual inspiration of Paris and France.” (Cath World) “The first
of the three appendices contains an article by James Geddes, Jr.,
which narrates the history of the intellectual sympathies and
university relations between France and America. ... The other two
appendices contain much practical information for students
intending to take advanced work in France.” (N Y Times)
“No thinking person, however prejudiced, could read this record of
scholarly and scientific accomplishment without realizing the sober
intellectual power, the strong moral fibre of the French people, and
no one who had grasped that fact before the war could have
talked glibly, as many did, of France regenerated by the ordeal of
battle.” C. H. Van Tyne
+ Am Hist R 23:391 Ja ‘18 1300w
“As a handbook for American students who contemplate study
abroad the book will be indispensable.” C: A. Ellwood
+ Am J Soc 23:412 N ‘17 350w

A L A Bkl 14:78 D ‘17

Am Pol Sci R 12:155 F ‘18 100w

“The volume, besides being a revelation to most of us, is also a
beautiful testimonial to the modesty of the French scholar who
made so little effort to claim the applause of the world. The one
criticism that can be made is that names occur to one’s mind
constantly which might have been included. The chapter on law is
too short.” Albert Schinz
+ Bookm 46:445 D ‘17 3050w
—
“On the whole, the appreciation of Catholic scholars is just. ...
There are occasional omissions of names which might be
expected, such as Branly, of the Catholic institute of Paris, the
discoverer of the principle of the wireless. ... The paper on religion
deals almost exclusively with the history of religions, and is written
with a carefulness apparently designed to avoid points of
controversy. In the list of libraries, that of the Catholic institute of
Paris should certainly have been mentioned, and even that of the
Seminary of St Sulpice, which has a recognized standing.”
+ Cath World 105:840 S ‘17 390w
“There is not a hint of propagandist ardor in ‘Science and learning
in France.’ Such ardor would be an insult to France, which needs
no commendation beyond the simple record of achievement.
Everywhere in this book western culture is recognized as
international—a growth to which all the peoples have made
important contributions. ... It is a compendious introduction to the
intellectual world of France, intended to serve as a guide for
students who may be planning to work for a doctorate abroad. But
it should serve the broader purpose of acquainting the general
public with the brilliant achievements of contemporary France. ... I
think there is some need for Americans to read ‘Science and
learning in France.’” C. H.
+ Dial 63:159 Ag 30 ‘17 1350w
Reviewed by Ferdinand Baldensperger
+ Nation 106:37 Ja 10 ‘18 2600w
“Such books as this will be especially useful in bringing Americans
to realize the importance of a section of French life and effort of
 which too many have known little and thought less.”
+ N Y Times 22:277 Jl 29 ‘17 1800w
“The publication of this book coincides with the establishment of
an American university union in Paris, cementing the bond
between American students and French universities.”
+ Outlook 117:103 S 19 ‘17 320w
“Although the disparagement of German learning and research
may be carried to absurd extremes in these days of war-time
passions, this book should prove a valuable aid toward opening the
treasure-house of French learning to the American students.”
+ Springf’d Republican p8 N 23 ‘18 280w

WILBUR, MARY ARONETTA. Child’s religion. *$1 (4c) Houghton

377 17-9361
A series of papers on the religious training of children, some of
them reprinted from the Churchman. The author’s attitude is
expressed in a quotation from another religious teacher: “You
cannot give your children religion; that is not your province. Your
work is to keep the child in position before God.” Contents: A
child’s religion; The child and the church; Children and missions;
The song and the child; The child and his book; On telling Bible
stories; A Sunday-school teacher’s biography; The childlike
teacher; The old Bible and the new child.
A L A Bkl 13:379 Je ‘17

N Y Br Lib News 4:95 Je ‘17

+ R of Rs 55:553 My ‘17 40w

WILCOX, EARLEY VERNON. Tropical agriculture. *$2.50 Appleton
630 16-22335
“The author has had in mind the general reader in writing this
work, not the farmer of the tropics. ... Climate, soil, agricultural
methods, live stock and economic conditions are briefly discussed.
The larger part of the volume deals with a description of the
nature, source and commercial importance of about 350 tropical
products, including sugar cane, nuts, fruits, starchy foods, tobacco,
fiber plants, rubber, gum, drugs, tans, dyes, spices, flavorings,
perfumes, oils, timber and woods.”—Ann Am Acad
“Good illustrations and a bibliography of books and periodicals. For
reference rather than for general reading.”
+ A L A Bkl 13:339 My ‘17
“He is especially clear in discussing economic conditions not to
overestimate the opportunities for the small farmer but shows that
it is the large owner who reaps his profit from low-priced labor or
the middle man who has made great profits. ... The appendix, with
reviews of the literature related to the subject, and a full
bibliography of the periodicals from all parts of the world, are
especially good.” C. W. Larson
+ Ann Am Acad 70:319 Mr ‘17 480w
“Dr Wilcox, who is now an administrative assistant in the States
relation service of the United States Department of agriculture,
was for six years in charge of the Hawaii experiment station. His
book is the first real American contribution to cover the whole
subject of crops, cultural methods and live stock in the tropics.”
+ Boston Transcript p7 Je 20 ‘17 200w
“The opening chapters on tropical climate, soils, agricultural
methods, etc., might with great advantage be carefully revised and
reconsidered. ... The reader is disappointed to note a lack of
proportion, an utter disregard of uniformity in treatment, and an
 entire absence of method—qualities essential in a book of
reference. The plates serve a pictorial rather than a practical
purpose. ... The book, as it stands, cannot become a textbook for
either the merchant or the student. It needs drastic revision.”
— Nature 99:183 My 3 ‘17 650w

+ N Y Times 22:220 Je 3 ‘17 50w

WILD, LAURA HULDA. Evolution of the Hebrew people and their

influence on civilization. *$1.50 (1½c) Scribner 220.9 17-24078
The author is professor of biblical history and literature in Mt.
Holyoke college, and this book is the result of several years of
teaching pupils “who come to college with no adequate conception
of what the Bible stands for.” It is a work for beginners and
attempts “to relate Bible study to the great fields of knowledge
that command a modern student’s attention, to show something of
the fascination of Bible study pursued in this way, and to leave a
positive conviction of the surpassing value of the great prophetic
thoughts handed down to us.” (Preface) The book is divided into
five parts: The cultural background of Hebrew life; A sketch of the
development of religious ideas; The influence of physical
environment upon the development of the Hebrew race; Israel’s
economic and social development; The place in world thought of
the great Hebrew prophetic teachers. There are two maps, a
bibliography and an index.
A L A Bkl 14:111 Ja ‘18
“The book ought to serve its purpose well. It does not make too
great demands of the beginner. It meets him at least half-way. It
ranges about freely through the whole biblical world seeking out
the interesting and attractive spots and finding them.”
+ Bib World 51:47 Ja ‘18 210w
 “There is much interesting and valuable material in the book.”
+ Lit D 55:52 D 1 ‘17 380w

WILDE, PERCIVAL. Unseen host, and other war plays. *$1.25

Little 812 17-25290
These five one-act plays survey the present war from many
angles. The “Unseen host” is based upon the legend of the “Angels
of Mons”; “Mothers of men” is an interview between two women
whose sons are at the front; “Pawns” is the story of some Russian
and Austrian peasants living as neighbors on the frontier and
summoned to mobilize, quite ignorant of what mobilization means;
“In the ravine” is a conversation between an Italian professor of
biology and an Austrian forger, who have been fighting on the
heights; and “Valkyrie” is a conversation on the battlefield between
two wounded officers, one German and the other British and a
common soldier.
“‘Mother of men’ and ‘Pawns’ are both powerful, thoroughly
realised achievements. He displays no weakness anywhere, is rich
in dramatic device, nervous yet natural in dialogue, frugal in
means, strong in concentration.” Algernon Tassin
+ Bookm 46:349 N ‘17 40w
“His new volume shows growth in Mr Wilde, especially in his
understanding of the springs of human emotion. Of the new series
the title play, a fine and effective use of the legend of the angels
at the battle of the Marne, is the best, but he almost duplicates
the success of this difficult piece of work in his German version of
a similar theme, ‘Valkyrie.’ Taken together these are the finest
dramas the war has inspired in America.” Williams Haynes
+ Dial 63:586 D 6 ‘17 560w
“The point of view is cosmopolitan rather than simply patriotic, and
the dialogs between enemies who have found out that, after all,
 they share a common humanity light up the tragedy and absurdity
of war with far greater skill than any deliberately purposed
pacifistic play could hope to attain.”
+ Ind 92:63 O 6 ‘17 60w

+ R of Rs 57:101 Ja ‘18 100w

WILKINS, ERNEST HATCH; COLEMAN, ALGERNON, and

HUSE, HOWARD RUSSELL. First lessons in spoken French for
men in military service. *50c Univ. of Chicago press 448 17-
19499
“The purpose of this book is to help men in American military
service (1) to understand what may be said to them in French; (2)
to make themselves understood in French; (3) to understand
printed French. The facts and words of French are presented
consistently in terms of sound. ... For the representation of the
French sounds we have used a set of phonetic symbols for which
we claim at least the merit of simplicity. It coincides to a
considerable degree with the set used in Grandgent’s ‘Short French
grammar.’ We have deliberately ignored certain differentiations in
sound which are commonly taught, and which should be taught
under normal circumstances. ... The words chosen for the word-
lists have been selected with reference to the particular needs of
men in the service.” (Preface)
“An excellent textbook for oral work. Word lists and order of the
lessons are well chosen. Index and table of word lists, no
vocabulary.”
+ A L A Bkl 14:10 O ‘37

Pittsburgh 22:694 O ‘17

WILKINSON, ANDREWS. Boy holidays in the Louisiana wilds. il
*$1.50 (2c) Little 17-24284
This book will introduce new types of adventure to northern boy
readers. Capturing alligators, hunting the marsh lynx, and fishing
in the bayous of lower Louisiana are the pastimes of its three
young heroes. Woven in with the recital of their real exploits are
the tales told by Uncle Jason, tales of the Uncle Remus variety,
with such titles as, The wise coon that got away, How the squirrel-
jay war began, How Mr Turkey Buzzard became bald. There are
also attractive pictures of home life on a big plantation and
descriptions of the country bordering the lower Mississippi.
“Children who love Uncle Remus’s stories will be glad of Andrews
Wilkinson’s ‘Boy holidays in the Louisiana wilds’ with its effective
pictures.”
+ Ind 92:447 D 1 ‘17 30w
“Their adventures are entertaining, and there are good
descriptions of southern scenery and life. But this is a book of
stories rather than adventure, and the interest centers in Uncle
Jason, a second Uncle Remus.”
+ Springf’d Republican p13 D 16 ‘17 110w

WILKINSON, MRS MARGUERITE OGDEN (BIGELOW),[2] comp.

Golden songs of the Golden state. *$1.50 McClurg 811.08 17-
31452
A California anthology. There are included in it poems by California
writers and by others who have fallen under California’s charm.
The compiler says, “I have felt that in a sense California belongs to
us all—not only to the native sons and daughters, but to the many
who have been refreshed and strengthened and healed by
sojourning there. ... But whenever it has been possible I have
given the preference to poems by western poets who have made
their reputations in the West or who are now living there and
 definitely associated with the West.” The book is made up of three
parts: Pioneer voices; Voices of the great singers; Living voices.

WILLCOX, CORNÉLIS DE WITT. War French. *75c Macmillan 448

17-24091
The author, a colonel in the United States army, is professor of
modern languages at the West Point military academy. Contents:
Part 1, The French language; part 2, The French army; part 3,
Passages for translation into English. About fifty pages of part 1
are devoted to the verb. A few pages of vocabularies and
conversations follow. The army information in part 2 is also
followed by vocabularies and conversations. Following part 3 are
French-English and English-French vocabularies.
+ Ind 92:343 N 17 ‘17 50w

Pittsburgh 22:835 D ‘17 50w

WILLIAMS, ALBERT RHYS. In the claws of the German eagle. il

*$1.50 (3c) Dutton 940.91 17-12508
The entertaining quality which this book of war-time adventures
undoubtedly has, is due largely to its revelation of the author’s
personality. He writes with humor and sympathy, and without
prejudice. “To myself,” he writes, “out of these insights into the
great calamity, there has come reinforcement to my belief in the
essential greatness of the human stuff in all nations. Along with
this goes a faith that in the new internationalism mankind will lay
low the military Frankenstein that he has created, and realize the
triumphant brotherhood of all human souls.” The book consists of
four parts: The spy-hunters of Belgium; On foot with the German
army; With the war photographers in Belgium; Love among the
ruins. The author is the socialist pastor of a church in East Boston
who was traveling in Europe when the war broke out. His articles
on the war were first contributed to the Outlook.
+ A L A Bkl 13:446 Jl ‘17

Boston Transcript p6 My 12 ‘17 130w

“The volume before us, however, has some noteworthy differences
from the general run. In the first place, the author was not a
professional war correspondent when the war began. Hence his
narrative possesses a certain freshness of outlook and naiveté of
presentation. Secondly, as he tells us, ‘there is no culling out of
just those episodes which support a particular theory, such as the
total and complete depravity of the German race. ... So I am not to
blame whether those episodes damn the Germans or bless them.
Some do, and some don’t. What one ran into was largely a matter
of luck.’ There is a very human note running through the book.”
+ Cath World 105:699 Ag ‘17 260w
+
—
“A vividly interesting account.”
+ Cleveland p102 S ‘17 50w
“Accounts of frightfulness might have added to the attractiveness
of his story for those who enjoy shuddering, but Mr Williams finds
himself unable, as an eye-witness, to record any such atrocities,
and so very wisely leaves them for others to write down. Yet it is
no flattering picture he paints of German conduct in Belgium.”
+ Dial 64:82 Ja 17 ‘18 80w
“His book is worth more than a dozen snap-shot records.”
+ Ind 91:72 Jl 14 ‘17 230w
“The book is gossipy, interesting and good humoured, though by
no means flippant in tone, and the writer seems unprejudiced and
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com