bshined's picture
From bshined rss RSS  subscribe Subscribe

Introduction to the new mainframe z/OS basics 

Introduction to the new mainframe z/OS basics

 

 
 
Tags:  wireless credit card machine  legacy 
Views:  759
Published:  October 05, 2011
 
0
download

Share plick with friends Share
save to favorite
Report Abuse Report Abuse
 
Related Plicks
g r O w

g r O w

From: amu95
Views: 167 Comments: 0

 
Towards a High-Bandwidth, Low-Carbon Future

Towards a High-Bandwidth, Low-Carbon Future

From: ante39
Views: 389 Comments: 0

 
See all 
 
More from this user
Synopsis of Causation

Synopsis of Causation

From: bshined
Views: 88
Comments: 0

FDI in Russia

FDI in Russia

From: bshined
Views: 1130
Comments: 0

Fundraising on Facebook: A Case-Study on Cause-Related Marketing

Fundraising on Facebook: A Case-Study on Cause-Related Marketing

From: bshined
Views: 811
Comments: 0

Connecting With Brand Savvy Moms Q2 2011

Connecting With Brand Savvy Moms Q2 2011

From: bshined
Views: 155
Comments: 0

Up Ar 06e  I P C

Up Ar 06e I P C

From: bshined
Views: 644
Comments: 0

hp pavilion dm4 1277sb 14-inch notebook pc - silver

hp pavilion dm4 1277sb 14-inch notebook pc - silver

From: bshined
Views: 162
Comments: 0

See all 
 
 
 URL:          AddThis Social Bookmark Button
Embed Thin Player: (fits in most blogs)
Embed Full Player :
 
 

Name

Email (will NOT be shown to other users)

 

 
 
Comments: (watch)
 
 
Notes:
 
Slide 1: Front cover Draft Document for Review February 26, 2011 8:33 am SG24-6366-02 Introduction to the New Mainframe z/OS Basics Basic mainframe concepts, including usage and architecture z/OS fundamentals for students and beginners Mainframe hardware and peripheral devices Mike Ebbers John Kettner Wayne O’Brien Bill Ogden ibm.com/redbooks
Slide 3: Draft Document for Review February 26, 2011 8:32 am zos-edno.fm International Technical Support Organization Introduction to the New Mainframe: z/OS Basics March 2011 SG24-6366-02
Slide 4: zos-edno.fm Draft Document for Review February 26, 2011 8:32 am Note: Before using this information and the product it supports, read the information in “Notices” on page xi. Third Edition (March 2011) © Copyright International Business Machines Corporation 2006, 2009, 2011. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Slide 5: Draft Document for Review February 26, 2011 8:32 am zos-TOC.fm Contents Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii How this text is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv How each chapter is organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv The team who wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . xix Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi March 2011, Third Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi August 2009, Second Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Part 1. Introduction to z/OS and the mainframe environment Chapter 1. Introduction to the New Mainframe. . . . . . . . . . . . . . . . . . . . . . . 3 1.1 The New Mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 The S/360: A turning point in mainframe history . . . . . . . . . . . . . . . . . . . . . 4 1.3 An evolving architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Mainframes in our midst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5 What is a mainframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.6 Who uses mainframe computers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.7 Factors contributing to mainframe use . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.8 Typical mainframe workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.9 Roles in the mainframe world . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.10 z/OS and other mainframe operating systems . . . . . . . . . . . . . . . . . . . . 37 1.11 Introducing the IBM zEnterprise System . . . . . . . . . . . . . . . . . . . . . . . . . 40 1.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 1.13 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 1.14 Topics for further discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Chapter 2. Mainframe hardware systems and high availability . . . . . . . . 45 2.1 Introduction to mainframe hardware systems . . . . . . . . . . . . . . . . . . . . . . 46 2.2 Early system design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.3 Current design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 © Copyright IBM Corp. 2006, 2009, 2011. All rights reserved. iii
Slide 6: zos-TOC.fm Draft Document for Review February 26, 2011 8:32 am 2.4 Processing units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.5 Multiprocessors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.6 Disk devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.7 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 2.8 Basic shared DASD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 2.9 What is a sysplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 2.10 Intelligent Resource Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 2.11 Platform Performance Management with zEnterprise . . . . . . . . . . . . . . . 75 2.12 Typical mainframe system growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 2.13 Continuous availability of mainframes. . . . . . . . . . . . . . . . . . . . . . . . . . . 77 2.14 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 2.15 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 2.16 Topics for further discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 2.17 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Chapter 3. z/OS overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.1 What is an operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 3.2 What is z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 3.3 Overview of z/OS facilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3.4 Virtual storage and other mainframe concepts . . . . . . . . . . . . . . . . . . . . 101 3.5 What is workload management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 3.6 I/O and data management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 3.7 Supervising the execution of work in the system . . . . . . . . . . . . . . . . . . 132 3.8 Cross-memory services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 3.9 Defining characteristics of z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 3.10 Understanding system and product messages . . . . . . . . . . . . . . . . . . . 145 3.11 Predictive failure analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 3.12 z/OS and other mainframe operating systems . . . . . . . . . . . . . . . . . . . 151 3.13 A brief comparison of z/OS and UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . 152 3.14 Additional software products for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 155 3.15 Middleware for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 3.16 The new face of z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 3.17 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 3.18 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 3.19 Topics for further discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Chapter 4. TSO/E, ISPF, and UNIX: Interactive facilities of z/OS . . . . . . 165 4.1 How do we interact with z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 4.2 Time Sharing Option/Extensions overview . . . . . . . . . . . . . . . . . . . . . . . 166 4.3 ISPF overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 4.4 z/OS UNIX interactive interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 iv Introduction to the New Mainframe: z/OS Basics
Slide 7: Draft Document for Review February 26, 2011 8:32 am zos-TOC.fm 4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 4.6 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 4.7 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Chapter 5. Working with data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 5.1 What is a data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 5.2 Where are data sets stored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 5.3 What are access methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 5.4 How are DASD volumes used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 5.5 Allocating a data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 5.6 How data sets are named . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 5.7 Allocating space on DASD volumes through JCL . . . . . . . . . . . . . . . . . . 208 5.8 Data set record formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 5.9 Types of data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 5.10 What is VSAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 5.11 Catalogs and VTOCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 5.12 Role of DFSMS in managing space . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 5.13 z/OS UNIX file systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 5.14 Working with a zFS file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 5.15 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 5.16 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 5.17 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 5.18 Listing a data set and other ISPF 3.4 options . . . . . . . . . . . . . . . . . . . . 236 Chapter 6. Using JCL and SDSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 6.1 What is JCL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 6.2 JOB, EXEC, and DD parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 6.3 Data set disposition, DISP parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 6.4 Continuation and concatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 6.5 Why z/OS uses symbolic file names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 6.6 Reserved DDNAMES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 6.7 JCL procedures (PROCs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 6.8 Understanding SDSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 6.9 Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 6.10 System libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 6.11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 6.12 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 6.13 Topics for further discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 6.14 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Chapter 7. Batch processing and JES. . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 7.1 What is batch processing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 7.2 What is JES?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 7.3 What does an initiator do?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Contents v
Slide 8: zos-TOC.fm 7.4 7.5 7.6 7.7 7.8 7.9 Draft Document for Review February 26, 2011 8:32 am Job and output management with JES and initiators . . . . . . . . . . . . . . . 274 Job flow through the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 JES2 compared to JES3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Part 2. Application programming on z/OS Chapter 8. Designing and developing applications for z/OS . . . . . . . . . 295 8.1 Application designers and programmers. . . . . . . . . . . . . . . . . . . . . . . . . 296 8.2 Designing an application for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 8.3 Application development life cycle: An overview . . . . . . . . . . . . . . . . . . . 299 8.4 Developing an application on the mainframe . . . . . . . . . . . . . . . . . . . . . 305 8.5 Going into production on the mainframe . . . . . . . . . . . . . . . . . . . . . . . . . 313 8.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 8.7 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Chapter 9. Using programming languages on z/OS. . . . . . . . . . . . . . . . . 317 9.1 Overview of programming languages . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 9.2 Choosing a programming language for z/OS . . . . . . . . . . . . . . . . . . . . . 319 9.3 Using Assembler language on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 9.4 Using COBOL on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 9.5 HLL relationship between JCL and program files . . . . . . . . . . . . . . . . . . 330 9.6 Using PL/I on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 9.7 Using C/C++ on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 9.8 Using Java on z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 9.9 Using CLIST language on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 9.10 Using REXX on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 9.11 Compiled versus interpreted languages . . . . . . . . . . . . . . . . . . . . . . . . 342 9.12 What is z/OS Language Environment? . . . . . . . . . . . . . . . . . . . . . . . . . 343 9.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 9.14 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 9.15 Topics for further discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Chapter 10. Compiling and link-editing a program on z/OS . . . . . . . . . . 355 10.1 Source, object, and load modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 10.2 What are source libraries? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 10.3 Compiling programs on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 10.4 Creating load modules for executable programs. . . . . . . . . . . . . . . . . . 374 10.5 Overview of compilation to execution . . . . . . . . . . . . . . . . . . . . . . . . . . 378 10.6 Using procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 10.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 10.8 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 vi Introduction to the New Mainframe: z/OS Basics
Slide 9: Draft Document for Review February 26, 2011 8:32 am zos-TOC.fm 10.9 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Part 3. Online workloads for z/OS Chapter 11. Transaction management systems on z/OS. . . . . . . . . . . . . 391 11.1 Online processing on the mainframe. . . . . . . . . . . . . . . . . . . . . . . . . . . 392 11.2 Example of global online processing - the new big picture . . . . . . . . . . 392 11.3 Transaction systems for the mainframe . . . . . . . . . . . . . . . . . . . . . . . . 394 11.4 What is CICS?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 11.5 What is IMS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 11.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 11.7 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 11.8 Exercise: Create a CICS program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Chapter 12. Database management systems on z/OS . . . . . . . . . . . . . . . 421 12.1 Database management systems for the mainframe . . . . . . . . . . . . . . . 422 12.2 What is a database? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 12.3 Why use a database? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 12.4 Who is the database administrator? . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 12.5 How is a database designed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 12.6 What is a database management system? . . . . . . . . . . . . . . . . . . . . . . 429 12.7 What is DB2? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 12.8 What is SQL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 12.9 Application programming for DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 12.10 Functions of the IMS Database Manager . . . . . . . . . . . . . . . . . . . . . . 449 12.11 Structure of the IMS Database subsystem . . . . . . . . . . . . . . . . . . . . . 449 12.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 12.13 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 12.14 Exercise 1 -- Use SPUFI in a COBOL program . . . . . . . . . . . . . . . . . 455 Chapter 13. z/OS HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 13.1 Introduction to Web-based workloads on z/OS . . . . . . . . . . . . . . . . . . . 464 13.2 What is z/OS HTTP Server? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 13.3 HTTP Server capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 13.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 13.5 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 13.6 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474 Chapter 14. WebSphere Application Server on z/OS . . . . . . . . . . . . . . . . 477 14.1 What is WebSphere Application Server for z/OS? . . . . . . . . . . . . . . . . 478 14.2 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 14.3 Nodes (and node agents) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 14.4 Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 14.5 J2EE application model on z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 Contents vii
Slide 10: zos-TOC.fm 14.6 14.7 14.8 14.9 Draft Document for Review February 26, 2011 8:32 am Running WebSphere Application Server on z/OS. . . . . . . . . . . . . . . . . 483 Application server configuration on z/OS . . . . . . . . . . . . . . . . . . . . . . . 488 Connectors for Enterprise Information Systems . . . . . . . . . . . . . . . . . . 490 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 Chapter 15. Messaging and queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 15.1 What WebSphere MQ is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 15.2 Synchronous communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 15.3 Asynchronous communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 15.4 Message types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 15.5 Message queues and the queue manager . . . . . . . . . . . . . . . . . . . . . . 501 15.6 What is a channel? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 15.7 How transactional integrity is ensured. . . . . . . . . . . . . . . . . . . . . . . . . . 503 15.8 Example of messaging and queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . 504 15.9 Interfacing with CICS, IMS, batch, or TSO/E . . . . . . . . . . . . . . . . . . . . 506 15.10 Sysplex support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 15.11 Java Message Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 15.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 15.13 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 Part 4. System programming on z/OS Chapter 16. Overview of system programming . . . . . . . . . . . . . . . . . . . . 513 16.1 The role of the system programmer . . . . . . . . . . . . . . . . . . . . . . . . . . . 514 16.2 What is meant by separation of duties . . . . . . . . . . . . . . . . . . . . . . . . . 515 16.3 Customizing the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516 16.4 Managing system performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 16.5 Configuring I/O devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528 16.6 Following a process of change control . . . . . . . . . . . . . . . . . . . . . . . . . 529 16.7 Configuring consoles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532 16.8 Initializing the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535 16.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543 16.10 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544 16.11 Topics for further discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544 16.12 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545 Chapter 17. Using SMP/E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547 17.1 What is SMP/E? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 17.2 The SMP/E view of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 17.3 Changing the elements of the system . . . . . . . . . . . . . . . . . . . . . . . . . . 550 17.4 Introducing an element into the system. . . . . . . . . . . . . . . . . . . . . . . . . 552 17.5 Preventing or fixing problems with an element . . . . . . . . . . . . . . . . . . . 554 17.6 Fixing problems with an element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555 17.7 Customizing an element - USERMOD SYSMOD . . . . . . . . . . . . . . . . . 556 viii Introduction to the New Mainframe: z/OS Basics
Slide 11: Draft Document for Review February 26, 2011 8:32 am zos-TOC.fm 17.8 Keeping track of the elements of the system . . . . . . . . . . . . . . . . . . . . 557 17.9 Tracking and controlling requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559 17.10 How does SMP/E work? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560 17.11 Working with SMP/E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562 17.12 Data sets used by SMP/E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571 17.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574 17.14 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574 17.15 Topics for further discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575 Chapter 18. Security on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 18.1 Why security? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578 18.2 Security facilities of z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578 18.3 Security roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 18.4 The IBM Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 18.5 Security administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583 18.6 Operator console security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584 18.7 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584 18.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587 18.9 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 18.10 Topics for further discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 18.11 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590 Chapter 19. Network Communications on z/OS . . . . . . . . . . . . . . . . . . . 593 19.1 Communications in z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594 19.2 Brief history of data networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595 19.3 z/OS Communications Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598 19.4 TCP/IP overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599 19.5 VTAM overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603 19.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610 19.7 Questions for review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611 19.8 Demonstrations and exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611 Appendix A. A brief look at IBM mainframe history. . . . . . . . . . . . . . . . . 613 Appendix B. DB2 sample tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623 Department table (DEPT). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623 Employee table (EMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625 Appendix C. Utility programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629 Basic utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630 System-oriented utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637 Application-level utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639 Appendix D. EBCDIC - ASCII table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641 Contents ix
Slide 12: zos-TOC.fm Draft Document for Review February 26, 2011 8:32 am Appendix E. Class Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 COBOL-CICS-DB2 program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 COBOL-Batch-VSAM program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653 DSNTEP2 utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660 QMF batch execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661 Batch C program to access DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662 Java Servlet access to DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666 C program to access MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668 Java program to access MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731 x Introduction to the New Mainframe: z/OS Basics
Slide 13: Draft Document for Review February 26, 2011 8:32 am zos-spec.fm 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 illustrate 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. © Copyright IBM Corp. 2006, 2009, 2011. All rights reserved. xi
Slide 14: zos-spec.fm Draft Document for Review February 26, 2011 8:32 am Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Advanced Peer-to-Peer Networking® AD/Cycle® AIX® C/370™ CICS® CICSPlex® Domino® DB2® DFS™ DFSMSdfp™ DFSMSdss™ DFSMShsm™ DFSORT™ DRDA® Encina® Enterprise Storage Server® Enterprise Systems Architecture/390® ECKD™ ESCON® FlashCopy® FICON® Geographically Dispersed Parallel Sysplex™ GDDM® GDPS® HiperSockets™ IBM® IMS™ Language Environment® Lotus® Multiprise® MVS™ MVS/ESA™ MVS/XA™ NetRexx™ NetView® Open Class® OS/390® Parallel Sysplex® Processor Resource/Systems Manager™ PR/SM™ QMF™ Redbooks™ RACF® RMF™ S/360™ S/370™ S/390® Sysplex Timer® System z9™ System/360™ System/370™ System/390® SAA® Tivoli® VisualAge® VSE/ESA™ VTAM® WebSphere® z/Architecture™ z/OS® z/VM® z/VSE™ zSeries® z9™ The following terms are trademarks of other companies: EJB, Java, JDBC, JMX, JSP, JVM, J2EE, RSM, Sun, Sun Java, Sun Microsystems, VSM, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Visual Basic, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Intel, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. xii Introduction to the New Mainframe: z/OS Basics
Slide 15: Draft Document for Review February 26, 2011 8:32 am pref.fm Preface This IBM® Redbooks publication provides students of information systems technology with the background knowledge and skills necessary to begin using the basic facilities of a mainframe computer. It is the first in a planned series of textbooks designed to introduce students to mainframe concepts and help prepare them for a career in large systems computing. For optimal learning, students are assumed to have successfully completed an introductory course in computer system concepts, such as computer organization and architecture, operating systems, data management, or data communications. They should also have successfully completed courses in one or more programming languages, and be PC literate. This textbook can also be used as a prerequisite for courses in advanced topics or for internships and special studies. It is not intended to be a complete text covering all aspects of mainframe operation or a reference book that discusses every feature and option of the mainframe facilities. Others who will benefit from this course include experienced data processing professionals who have worked with non-mainframe platforms, or who are familiar with some aspects of the mainframe but want to become knowledgeable with other facilities and benefits of the mainframe environment. As we go through this course, we suggest that the instructor alternate between text, lecture, discussions, and hands-on exercises. Many of the exercises are cumulative, and are designed to show the student how to design and implement the topic presented. The instructor-led discussions and hands-on exercises are an integral part of the course material, and can include topics not covered in this textbook. In this course, we use simplified examples and focus mainly on basic system functions. Hands-on exercises are provided throughout the course to help students explore the mainframe style of computing. At the end of this course, you will know: Basic concepts of the mainframe, including its usage, and architecture Fundamentals of z/OS®, a widely used mainframe operating system Mainframe workloads and the major middleware applications in use on mainframes today The basis for subsequent course work in more advanced, specialized areas of z/OS, such as system administration or application programming © Copyright IBM Corp. 2006, 2009, 2011. All rights reserved. xiii
Slide 16: pref.fm Draft Document for Review February 26, 2011 8:32 am How this text is organized This text is organized in four parts, as follows: Part 1, “Introduction to z/OS and the mainframe environment” on page 1 provides an overview of the types of workloads commonly processed on the mainframe, such as batch jobs and online transactions. This part of the text helps students explore the user interfaces of z/OS, a widely used mainframe operating system. Discussion topics include TSO/E and ISPF, UNIX® interfaces, job control language, file structures, and job entry subsystems. Special attention is paid to the users of mainframes and to the evolving role of mainframes in today’s business world. Part 2, “Application programming on z/OS” on page 293 introduces the tools and utilities for developing a simple program to run on z/OS. This part of the text guides the student through the process of application design, choosing a programming language, and using a runtime environment. Part 3, “Online workloads for z/OS” on page 389 examines the major categories of interactive workloads processed by z/OS, such as transaction processing, database management, and web serving. This part includes discussions about several popular middleware products, including IBM DB2®, CICS®, and IBM WebSphere® Application Server. Part 4, “System programming on z/OS” on page 511 provides topics to help the student become familiar with the role of the z/OS system programmer. This part of the text includes discussions of system libraries, starting and stopping the system, security, network communications, and the clustering of multiple systems. We also provide an overview of mainframe hardware systems, including processors and I/O devices. In this text, we use simplified examples and focus mainly on basic system functions. Hands-on exercises are provided throughout the text to help students explore the mainframe style of computing. Exercises include entering work into the system, checking its status, and examining the output of submitted jobs. How each chapter is organized Each chapter follows a common format: Objectives for the student Topics that teach a central theme related to mainframe computing Summary of the main ideas of the chapter A list of key terms introduced in the chapter xiv Introduction to the New Mainframe: z/OS Basics
Slide 17: Draft Document for Review February 26, 2011 8:32 am pref.fm Questions for review to help students verify their understanding of the material Topics for further discussion to encourage students to explore issues that extend beyond the chapter objectives Hands-on exercises to help students reinforce their understanding of the material The team who wrote this book John Kettner revised the second edition of this text. He is a Consulting Software Architect in the WebSphere sales group. He has 35 years of mainframe experience and holds a Bachelor of Science degree in Computer Science from L.I.U. His specialties are IBM System z internals, WebSphere product integration, and capacity planning. John has written several IBM Redbooks and contributes to various education programs throughout IBM. Special thanks to the following advisors: Rick Butler, Bank of Montreal Timothy Hahn, IBM Raleigh Pete Siddall, IBM Hursley The first edition of this text was produced by technical specialists working at the International Technical Support Organization, Poughkeepsie Center: Mike Ebbers has worked with mainframe systems at IBM for 32 years. For part of that time, he taught hands-on mainframe classes to new hires just out of college. Mike currently creates IBM Redbooks™, a popular set of product documentation that can be found at: http://www.ibm.com/redbooks Wayne O’Brien is an Advisory Software Engineer at IBM Poughkeepsie. Since joining IBM in 1988, he has developed user assistance manuals and online help for a wide variety of software products. Wayne holds a Master of Science degree in Technical Communications from Rensselaer Polytechnic Institute (RPI) of Troy, New York. Bill Ogden is a retired IBM Senior Technical Staff Member. He holds a Bachelor of Science degree in Electrical Engineering and a Master of Science degree in Computer Science. He has worked with mainframes since 1962 and with z/OS since it was known as OS/360 Release 1/2. Since joining the ITSO in 1978, Bill has specialized in encouraging users new to the operating system and associated hardware. Preface xv
Slide 18: pref.fm Draft Document for Review February 26, 2011 8:32 am Acknowledgements The following people are gratefully acknowledged for their contributions to this project: Dan Andrascik is a senior at the Pennsylvania State University, majoring in Information Science and Technology. Dan is proficient in computer languages (C++, Visual Basic®, HTML, XML, and SQL), organizational theory, database theory and design, and project planning and management. During his internship with the ITSO organization at IBM Poughkeepsie, Dan worked extensively with elements of the IBM eServer zSeries® platform. Rama Ayyar is a Senior IT Specialist with the IBM Support Center in Sydney, Australia. He has 20 years of experience with the MVS™ operating system and has been in the IT field for over 30 years. His areas of expertise include TCP/IP, security, storage management, configuration management, and problem determination. Rama holds a Master’s degree in Computer Science from the Indian Institute of Technology, Kanpur. Emil T. Cipolla is an information systems consultant in the United States with 40 years of experience in information systems. He holds Master’s degrees in Mechanical Engineering and Business Administration from Cornell University. Emil is currently an adjunct instructor at the college level. Mark Daubman is a senior at St. Bonaventure University, majoring in Business Information Systems with a minor concentration in Computer Science. As part of his internship with IBM, Mark worked extensively with many of the z/OS interfaces described in this textbook. After graduation, Mark plans to pursue a career in mainframes. Myriam Duhamel is an IT Specialist in Belgium. She has 20 years of experience in application development and has worked at IBM for 12 years. Her areas of expertise include development in different areas of z/OS (such as COBOL, PL/I, CICS, DB2, and WebSphere MQ). Myriam currently teaches courses in DB2 and WebSphere MQ. Per Fremstad is an IBM-certified I/T Specialist from the IBM Systems and Technology group in IBM Norway. He has worked for IBM since 1982 and has extensive experience with mainframes and z/OS. His areas of expertise include the web, WebSphere for z/OS, and web enabling of the z/OS environment. He teaches frequently on z/OS, zSeries, and WebSphere for z/OS topics. Per holds a Bachelor of Science degree from the University of Oslo, Norway. xvi Introduction to the New Mainframe: z/OS Basics
Slide 19: Draft Document for Review February 26, 2011 8:32 am pref.fm Luis Martinez Fuentes is a Certified Consulting IT Specialist (Data Integration discipline) with the Systems and Technology Group, IBM Spain. He has 20 years of experience with IBM mainframes, mainly in the CICS and DB2 areas. He is currently working in technical sales support for new workloads on the mainframe. Luis is a member of the Iberia Technical Expert Council, which is affiliated with the IBM Academy of Technology. Luis teaches about mainframes at two universities in Madrid. Miriam Gelinski is a staff member of Maffei Consulting Group in Brazil, where she is responsible for supporting customer planning and installing mainframe software. She has five years of experience in mainframes. She holds a Bachelor's degree in Information Systems from Universidade São Marcos in Sao Paulo. Her areas of expertise include the z/OS operating system, its subsystems, and TSO and ISPF. Michael Grossmann is an IT Education specialist in Germany with nine years of experience as a z/OS system programmer and instructor. His areas of expertise include z/OS education for beginners, z/OS operations, automation, mainframe hardware, and Parallel Sysplex®. Olegario Hernandez is a former IBM Advisory Systems Engineer in Chile. He has more than 35 years of experience in application design and development projects for mainframe systems. He has written extensively on the CICS application interface, systems management, and grid computing. Olegario holds a degree in Chemical Engineering from Universidad de Chile. Roberto Yuiti Hiratzuka is an MVS system programmer in Brazil. He has 15 years of experience as a mainframe system programmer. Roberto holds a degree in Information Systems from Faculdade de Tecnologia Sao Paulo (FATEC-SP). John Kettner is a Consulting Software Architect in the WebSphere sales group. He has 35 years of mainframe experience and holds a Bachelor of Science degree in Computer Science from L.I.U. His specialties are IBM System z internals, WebSphere product integration, and capacity planning. John has written several IBM Redbooks and contributes to various education programs throughout IBM. Georg Müller is a student at the University of Leipzig in Germany. He has three years of experience with z/OS and mainframe hardware. He plans to complete his study with a Master's degree in Computer Science next year. For this textbook, Georg wrote topics about WebSphere MQ and HTTP Server, coded sample programs, and helped to verify the final sequence of learning modules. Preface xvii
Slide 20: pref.fm Draft Document for Review February 26, 2011 8:32 am Rod Neufeld is a Senior Technical Services Professional in Canada. He has 25 years of experience in MVS and z/OS system programming. His areas of expertise include z/OS systems software and support, Parallel Sysplex, and business continuance and recovery. Rod holds an Honors Bachelor of Science degree from the University of Manitoba. Paul Newton is a Senior Software Engineer in the Dallas, Texas, IBM Developer Relations Technical Support Center. He has 25 years of experience with IBM mainframe operating systems, subsystems, and data networks. Paul holds a degree in Business Administration from the University of Arizona. Bill Seubert is a zSeries Software Architect in the United States. He has over 20 years experience in mainframes and distributed computing. He holds a Bachelor’s degree in Computer Science from the University of Missouri, Columbia. His areas of expertise include z/OS, WebSphere integration software, and software architecture. Bill speaks frequently to IBM clients about integration architecture and enterprise modernization. Henrik Thorsen is a Senior Consulting IT Specialist at IBM Denmark. He has 25 years of mainframe experience and holds an Master of Science degree in Engineering from the Technical University in Copenhagen and a Bachelor of Science degree in Economics from Copenhagen Business School. His specialties are z/OS, Parallel Sysplex, high availability, performance, and capacity planning. Henrik has written several IBM Redbooks and other documents and contributes to various education programs throughout IBM and the zSeries technical community. Andy R. Wilkinson is an IT Specialist in the United Kingdom. He has 25 years of experience in reservation systems and z/OS system programming, and has worked at IBM for six years. His areas of expertise include hardware configuration and SMP/E. Andy holds a degree in Materials Science and Technology from the University of Sheffield and a degree in Computing from the Open University. Lastly, special thanks to the editors at the ITSO center in Poughkeepsie, New York: Terry Barthel Ella Buslovich and Linda Robinson (graphics) Alfred Schwab xviii Introduction to the New Mainframe: z/OS Basics
Slide 21: Draft Document for Review February 26, 2011 8:32 am pref.fm Now you can become a published author, too! Here’s an opportunity to spotlight your skills, grow your career, and become a published author - all at the same time! Join an ITSO residency project and help write a book in your area of expertise, while honing your experience using leading-edge technologies. Your efforts will help to increase product acceptance and customer satisfaction, as you expand your network of technical contacts and relationships. Residencies run from two to six weeks in length, and you can participate either in person or as a remote resident working from your home base. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html Comments welcome Your comments are important to us! We want our books to be as helpful as possible. Send us your comments about this book or other IBM Redbooks publications in one of the following ways: Use the online Contact us review Redbooks form found at: ibm.com/redbooks Send your comments in an email to: redbooks@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYJ Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400 Stay connected to IBM Redbooks Find us on Facebook: http://www.facebook.com/IBMRedbooks Follow us on Twitter: http://twitter.com/ibmredbooks Preface xix
Slide 22: pref.fm Look for us on LinkedIn: Draft Document for Review February 26, 2011 8:32 am http://www.linkedin.com/groups?home=&gid=2130806 Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks weekly newsletter: https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm Stay current on recent Redbooks publications with RSS Feeds: http://www.redbooks.ibm.com/rss.html xx Introduction to the New Mainframe: z/OS Basics
Slide 23: Draft Document for Review February 26, 2011 8:32 am 6366chang.fm Summary of changes This section describes the technical changes made in this edition of the book and in previous editions. This edition might also include minor corrections and editorial changes that are not identified. Summary of Changes for SG24-6366-02 for Introduction to the New Mainframe: z/OS Basics as created or updated on February 26, 2011. March 2011, Third Edition This revision reflects the addition, deletion, or modification of new and changed information described below. New and changed information This edition adds information about the IBM System z Enterprise hardware. August 2009, Second Edition This revision reflects the addition, deletion, or modification of new and changed information described below. New and changed information Chapters 1 through 3 were updated with the latest System z hardware and software information. Chapter 8 received additional information about application development on the mainframe. Added Appendix F, which includes the Console Operator commands. © Copyright IBM Corp. 2006, 2009, 2011. All rights reserved. xxi
Slide 24: 6366chang.fm Draft Document for Review February 26, 2011 8:32 am xxii Introduction to the New Mainframe: z/OS Basics
Slide 25: Draft Document for Review February 26, 2011 8:32 am Part 1.fm Part 1 Part 1 Introduction to z/OS and the mainframe environment Welcome to mainframe computing! We begin this text with an overview of the mainframe computer and its place in today’s information technology (IT) organization. We explore the reasons why public and private enterprises throughout the world rely on the mainframe as the foundation of large-scale computing. We discuss the types of workloads that are commonly associated with the mainframe, such as batch jobs and online or interactive transactions, and the unique manner in which this work is processed by a widely used mainframe operating system, that is, z/OS. Throughout this text, we pay special attention to the people who use mainframes and to the role of the New Mainframe in today’s business world. © Copyright IBM Corp. 2006, 2009, 2011. All rights reserved. 1
Slide 26: Part 1.fm Draft Document for Review February 26, 2011 8:32 am 2 Introduction to the New Mainframe: z/OS Basics
Slide 27: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm 1 Chapter 1. Introduction to the New Mainframe Objective: As a technical professional in the world of mainframe computing, you need to understand how mainframe computers support your company’s IT infrastructure and business goals. You also need to know the job titles of the various members of your company’s mainframe support team. After completing this chapter, you will be able to: List ways in which the mainframes of today challenge the traditional thinking about centralized computing versus distributed computing. Explain how businesses make use of mainframe processing power, the typical uses of mainframes, and how mainframe computing differs from other types of computing. Outline the major types of workloads for which mainframes are best suited. Name five jobs or responsibilities that are related to mainframe computing. Identify four mainframe operating systems. Describe how IBM zEnterprise System is used to address IT problems. Refer to Table 1-1 on page 42 for a list of key terms used in this chapter. © Copyright IBM Corp. 2006, 2009, 2011. All rights reserved. 3
Slide 28: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am 1.1 The New Mainframe Today, mainframe computers play a central role in the daily operations of most of the world’s largest corporations, including many Fortune 1000 companies. While other forms of computing are used extensively in various business capacities, the mainframe occupies a coveted place in today’s e-business environment. In banking, finance, health care, insurance, public utilities, government, and a multitude of other public and private enterprises, the mainframe computer continues to form the foundation of modern business. e-business: The transaction of business over an electronic medium, such as the Internet. The long-term success of mainframe computers is without precedent in the information technology (IT) field. Periodic upheavals shake world economies and continuous, often wrenching, change in the Information Age has claimed many once-compelling innovations as victims in the relentless march of progress. As emerging technologies leap into the public eye, many are just as suddenly rendered obsolete by some even newer advancement. Yet today, as in every decade since the 1960s, mainframe computers and the mainframe style of computing dominate the landscape of large-scale business computing. Why has this one form of computing taken hold so strongly among so many of the world’s corporations? In this chapter, we look at the reasons why mainframe computers continue to be the popular choice for large-scale business computing. 1.2 The S/360: A turning point in mainframe history Mainframe development occurred in a series of generations starting in the 1950s. First generation systems, such as the IBM 705 in 1954 and its successor System/360: generation, the IBM 1401 in 1959, were a far cry from the enormously powerful The first general and economical machines that were to follow, but they clearly had characteristics purpose of mainframe computers. The IBM 1401 was called the Model T of the computer computer, introduced in business, because it was the first mass-produced digital, all-transistorized, 1964. business computer that could be afforded by many businesses worldwide. These computers were sold as business machines and served then, as now, as the central data repository in a corporation's data processing center. In the 1960s, the course of computing history changed dramatically when mainframe manufacturers began to standardize the hardware and software they offered to customers. The introduction of the IBM System/360™ (or S/360™) in 1964 signaled the start of the third generation: the first general purpose computers. Earlier systems were dedicated to either commercial or scientific computing. The revolutionary S/360 could perform both types of computing, as long as the customer, a software company, or a consultant provided the 4 Introduction to the New Mainframe: z/OS Basics
Slide 29: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm programs to do so. In fact, the name S/360 refers to the architecture’s wide scope: 360 degrees to cover the entire circle of possible uses. System/360 naming: The System /360 was named for its scope: 360 degrees of The S/360 was also the first of these computers to use microcode to implement many of its machine instructions, as opposed to having all of its machine instructions hardwired into its circuitry. Microcode (or firmware) consists of stored microinstructions, not available to users, that provide a functional layer between hardware and software. The advantage of microcoding is flexibility, where any correction or new function can be implemented by just changing the existing microcode, rather than replacing the computer. Over the passing decades, mainframe computers have steadily grown to achieve enormous processing capabilities. Today’s mainframes have an unrivaled ability to serve users by the tens of thousands, manage petabytes1 of data, and reconfigure hardware and software resources to accommodate changes in workload, all from a single point of control. 1.3 An evolving architecture An architecture is a set of defined terms and rules that are used as instructions to build products. In computer science, an architecture describes the organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components, and subsystems. Architecture: Describes the organizational structure of a system. Starting with the first large machines, which arrived on the scene in the 1960s and became known as “Big Iron” (in contrast to smaller departmental systems), each new generation of mainframe computers has included improvements in one or more of the following areas of the architecture:2 More and faster processors More physical memory and greater memory addressing capability Dynamic capabilities for upgrading both hardware and software Increased automation along with hardware error checking and recovery Enhanced devices for input/output (I/O) and more and faster paths (channels) between I/O devices and processors 1 2 Quadrillions of bytes. Since the introduction of the S/360 in 1964, IBM has significantly extended the platform roughly every ten years: System/370™ in 1970, System/370 Extended Architecture (370-XA) in 1983, Enterprise Systems Architecture/390® (ESA/390) in 1990, and z/Architecture™ in 2000. For more information about earlier mainframe hardware systems, see Appendix A, “A brief look at IBM mainframe history” on page 613. Chapter 1. Introduction to the New Mainframe 5
Slide 30: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am More sophisticated I/O attachments, such as LAN adapters with extensive inboard processing A greater ability to divide the resources of one machine into multiple, logically independent and isolated systems, each running its own operating system Advanced clustering technologies, such as Parallel Sysplex, and the ability to share data among multiple systems Emphasis on utility savings with power and cooling reduction An expanded set of application runtime environments, including support for POSIX applications, C, C++, Java, PHP, web applications, SOA3, and web services Despite the continual changes, mainframe computers remain the most stable, secure, and compatible of all computing platforms. The latest models can handle the most advanced and demanding customer workloads, yet continue to run applications that were written in the 1970s or earlier. How can a technology change so much yet remain so stable? It evolved to meet new challenges. In the early 1990s, the client-server model of computing, with its distributed nodes of less powerful computers, emerged to challenge the dominance of mainframe computers. In response, mainframe designers did what they have always done when confronted with changing times and a growing list of user requirements: They designed new mainframe computers to meet the demand. With the expanded functions and added tiers of data processing capabilities, such as web serving, autonomics, disaster recovery, and grid computing, the mainframe computer is poised to ride the next wave of growth in the IT industry. Today’s mainframe generation provides a significant increase in system scalability over the previous mainframe servers. With increased performance and total system capacity, customers continue to consolidate diverse applications on a single platform. New innovations help to ensure it is a security-rich platform that can help maximize the resources and their utilization, and can help provide the ability to integrate applications and data across a single infrastructure. The current mainframe is built using a modular design that supports a packaging concept based on books. One to four books can be configured, each containing a processor housing that hosts the central processor units, memory, and high speed connectors for I/O. This approach enables many of the high-availability, nondisruptive capabilities that differentiate it from other platforms. 3 Service-oriented architecture 6 Introduction to the New Mainframe: z/OS Basics
Slide 31: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm Figure 1-1 on page 7 shows the mainframe’s continued growth improvements in all directions. Although some of the previous generation of machines have grown more along one graphical axis for a given family, later families focus on the other axes. The balanced design of today’s mainframe achieves improvement equally along all four axes. System I/O Bandwidth 288 GB/Sec* 172.8 GB/sec* 96 GB/sec 24 GB/sec Memory 3 TB** 1.5 TB** 512 GB 256 64 GB GB 16-way 300 450 600 920 ITR for 1-way ~1200 32-way z196 z10 EC z9 EC zSeries 990 54-way 64-way * Servers exploit a subset of its designed I/O capability ** Up to 1 TB per LPAR 96-way Processors zSeries 900 Figure 1-1 Growth of the mainframe and its components The evolution continues. Although the mainframe computer has retained its traditional, central role in the IT organization, that role is now defined to include being the primary hub in the largest distributed networks. In fact, the Internet itself is based largely on numerous, interconnected mainframe computers serving as major hubs and routers. Today’s mainframe has taken on an additional critical role as an energy efficient system. As energy costs are increasing at a rate of 2.8% per year, energy costs to power equipment often exceed the purchase cost of the hardware itself. Chapter 1. Introduction to the New Mainframe 7
Slide 32: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am Market researchers, such as International Data Corporation (IDC), have conducted studies that compare the total worldwide server spending to total server power and cooling expenditure on a global basis and found that customers are spending more than twice as much on power and cooling as they are spending on total server purchases. The power and cooling issues that data center managers face are not stand-alone challenges. These issues can have a cascading impact on other facilities issues, such as wiring, floor space, and lighting. The mainframe also contains an “energy meter.” The mainframe’s power consumption today is 0.91 watts per MIPS and is expected to decrease with future models. As such, the mainframe has become an environmentally friendly platform to run a business with on a global basis. As the image of the mainframe computer continues to evolve, you might wonder: Is the mainframe computer is a self-contained computing environment, or is it one part of the puzzle in distributed computing? The answer is that the New Mainframe is both. It is a self-contained processing center, powerful enough to process the largest and most diverse workloads in one secure “footprint.” It is also just as effective when implemented as the primary server in a corporation’s distributed server farm. In effect, the mainframe computer is the definitive platform in the client-server model of computing. 1.4 Mainframes in our midst Despite the predominance of mainframes in the business world, these machines are largely invisible to the general public, the academic community, and indeed many experienced IT professionals. Instead, other forms of computing attract more attention, at least in terms of visibility and public awareness. That this is so is perhaps not surprising. After all, who among us needs direct access to a mainframe? And, if we did, where would we find one to access? The truth, however, is that we are all mainframe users, whether we realize it or not (more on this later). Most of us with some personal computer (PC) literacy and sufficient funds can purchase a notebook computer and quickly put it to good use by running software, browsing websites, and perhaps even writing papers for college professors to grade. With somewhat greater effort and technical prowess, we can delve more deeply into the various facilities of a typical Intel®-based workstation and learn its capabilities through direct, hands-on experience, with or without help from any of a multitude of readily available information sources in print or on the web. 8 Introduction to the New Mainframe: z/OS Basics
Slide 33: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm Mainframes, however, tend to be hidden from the public eye. They do their jobs dependably (indeed, with almost total reliability) and are highly resistant to most forms of insidious abuse that afflict PCs, such as email-borne viruses and trojan horses. By performing stably, quietly, and with negligible downtime, mainframes are the example by which all other computers are judged. But at the same time, this lack of attention tends to allow them to fade into the background. Furthermore, in a typical customer installation, the mainframe shares space with many other hardware devices: external storage devices, hardware network routers, channel controllers, and automated tape library “robots,” to name a few. The mainframe is physically no larger than many of these devices and generally does not stand out from the crowd of peripheral devices. There are different classes of mainframe to meet diverse needs of customers. The mainframe can grow in capacity as businesses grow. So, how can we explore the mainframe’s capabilities in the real world? How can we learn to interact with the mainframe, learn its capabilities, and understand its importance to the business world? Major corporations are eager to hire new mainframe professionals, but there is a catch: some previous experience would help. 1.5 What is a mainframe First, let us review terminology. Today, computer manufacturers do not always use the term mainframe to refer to mainframe computers. Instead, most have taken to calling any commercial-use computer, large or small, a server, with the mainframe simply being the largest type of server in use today. We use the term mainframe in this text to mean computers that can support thousands of applications and input/output devices to simultaneously serve thousands of users. Servers are proliferating. A business might have a large server collection that includes transaction servers, database servers, email servers, and web servers. Large collections of servers are sometimes called server farms (in fact, some data centers cover areas measured in acres). The hardware required to perform a server function can range from little more than a cluster of rack-mounted personal computers to the most powerful mainframes manufactured today. Server farm: A large collection of servers. A mainframe is the central data repository, or hub, in a corporation’s data processing center, linked to users through less powerful devices such as workstations or terminals. The presence of a mainframe often implies a centralized form of computing, as opposed to a distributed form of computing. Chapter 1. Introduction to the New Mainframe 9
Slide 34: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am Centralizing the data in a single mainframe repository saves customers from having to manage updates to more than one copy of their business data, which increases the likelihood that the data is current. The distinction between centralized and distributed computing, however, is rapidly blurring, as smaller machines continue to gain in processing power and mainframes become ever more flexible and multi-purpose. Market pressures require that today’s businesses continually reevaluate their IT strategies to find better ways of supporting a changing marketplace. As a result, mainframes are now frequently used in combination with networks of smaller servers in a multitude of configurations. The ability to dynamically reconfigure a mainframe’s hardware and software resources (such as processors, memory, and device connections), while applications continue running, further underscores the flexible, evolving nature of the modern mainframe. Although mainframe hardware has become harder to pigeon-hole, so, too, have the operating systems that run on mainframes. Years ago, in fact, the terms defined each other: a mainframe was any hardware system that ran a major IBM operating system.4 This meaning has been blurred in recent years because these operating systems can be run on small systems. Platform: A computer architecture (hardware and software). Computer manufacturers and IT professionals often use the term platform to refer to the hardware and software that are associated with a particular computer architecture. For example, a mainframe computer and its operating system (and their predecessors5) are considered a platform. UNIX on a Reduced Instruction Set Computer (RISC) system is considered a platform somewhat independently of exactly which RISC machine is involved. Personal computers can be seen as several different platforms, depending on which operating system is being used. So, let us return to our question: What is a mainframe? Today, the term mainframe can best be used to describe a style of operation, applications, and operating system facilities. Here is a working definition, “A mainframe is what businesses use to host the commercial databases, transaction servers, and applications that require a greater degree of security and availability than is commonly found on smaller-scale machines.” The name was also traditionally applied to large computer systems that were produced by other vendors. 5 IBM System/390® (S/390®) refers to a specific series of machines, which have been superseded by the IBM System z machines. Nevertheless, many S/390 systems are still in use. Therefore, keep in mind that although we discuss the System z in this course, almost everything discussed also applies to S/390 machines. One major exception is 64-bit addressing, which is used only with System z. 4 10 Introduction to the New Mainframe: z/OS Basics
Slide 35: Draft Document for Review February 26, 2011 8:32 am Mainframe: A highly secured computer system designed to continuously run large, mixed workloads at high levels of utilization while meeting user-defined service level objectives. Chap1 mainframe intro.fm Early mainframe systems were housed in enormous, room-sized metal boxes or frames, which is probably how the term mainframe originated. The early mainframe required large amounts of electrical power and air-conditioning, and the room was filled mainly with I/O devices. Also, a typical customer site had several mainframes installed, with most of the I/O devices connected to all of the mainframes. During their largest period, in terms of physical size, a typical mainframe occupied 2,000 to 10,000 square feet (200 to 1000 square meters). Some installations were even larger. Starting around 1990, mainframe processors and most of their I/O devices became physically smaller, while their functionality and capacity continued to grow. Mainframe systems today are much smaller than earlier systems, and are about the size of a large refrigerator. In some cases, it is now possible to run a mainframe operating system on a PC that emulates a mainframe. Such emulators are useful for developing and testing business applications before moving them to a mainframe production system. Clearly, the term mainframe has expanded beyond merely describing the physical characteristics of a system. Instead, the word typically applies to some combination of the following attributes: Compatibility with System z operating systems, applications, and data. Centralized control of resources. Hardware and operating systems that can share access to disk drives with other systems, with automatic locking and protection against destructive simultaneous use of disk data. A style of operation, often involving dedicated operations staff who use detailed operations procedure books and highly organized procedures for backups, recovery, training, and disaster recovery at an alternative location. Hardware and operating systems that routinely work with hundreds or thousands of simultaneous I/O operations. Chapter 1. Introduction to the New Mainframe 11
Slide 36: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am Clustering technologies that allow the customer to operate multiple copies of the operating system as a single system. This configuration, known as Parallel Sysplex, is analogous in concept to a UNIX cluster, but allows systems to be added or removed as needed, while applications continue to run. This flexibility allows mainframe customers to introduce new applications, or discontinue the use of existing applications, in response to changes in business activity. Additional data and resource sharing capabilities. In a Parallel Sysplex, for example, it is possible for users across multiple systems to access the same databases concurrently, with database access controlled at the record level. Optimized for I/O for business-related data processing applications supporting high speed networking and terabytes of disk storage. As the performance and cost of such hardware resources as the central processing unit (CPU) and external storage media improve, and the number and types of devices that can be attached to the CPU increase, the operating system software can more fully take advantage of the improved hardware. 1.6 Who uses mainframe computers So, who uses mainframes? Just about everyone has used a mainframe computer at one point or another. If you ever used an automated teller machine (ATM) to interact with your bank account, you used a mainframe. Today, mainframe computers play a central role in the daily operations of most of the world’s largest corporations. While other forms of computing are used extensively in business in various capacities, the mainframe occupies a coveted place in today’s e-business environment. In banking, finance, health care, insurance, utilities, government, and a multitude of other public and private enterprises, the mainframe computer continues to be the foundation of modern business. Until the mid-1990s, mainframes provided the only acceptable means of handling the data processing requirements of a large business. These requirements were then (and are often now) based on large and complex batch jobs, such as payroll and general ledger processing. The mainframe owes much of its popularity and longevity to its inherent reliability and stability, which is a result of careful and steady technological advances that have been made since the introduction of the System/360 in 1964. No other computer architecture can claim as much continuous, evolutionary improvement, while maintaining compatibility with previous releases. 12 Introduction to the New Mainframe: z/OS Basics
Slide 37: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm Because of these design strengths, the mainframe is often used by IT organizations to host the most important, mission-critical applications. These applications typically include customer order processing, financial transactions, production and inventory control, payroll, and many other types of work. One common impression of a mainframe’s user interface is the 80x24-character “green screen” terminal, named for the old cathode ray tube (CRT) monitors from years ago that glowed green. In reality, mainframe interfaces today look much the same as those for personal computers or UNIX systems. When a business application is accessed through a web browser, there is often a mainframe computer performing crucial functions “behind the scene.” Many of today’s busiest websites store their production databases on a mainframe host. New Mainframe hardware and software products are ideal for web transactions because they are designed to allow huge numbers of users and applications to rapidly and simultaneously access the same data without interfering with each other. This security, scalability, and reliability is critical to the efficient and secure operation of contemporary information processing. Corporations use mainframes for applications that depend on scalability and reliability. For example, a banking institution could use a mainframe to host the database of its customer accounts, for which transactions can be submitted from any of thousands of ATM locations worldwide. Businesses today rely on the mainframe to: Perform large-scale transaction processing (thousands of transactions per second)6 Support thousands of users and application programs concurrently accessing numerous resources Manage terabytes of information in databases Handle large-bandwidth communication The roads of the information superhighway often lead to a mainframe. 1.6.1 Two mainframe models Mainframes are available with a variety of processing capabilities to suit the requirements of most business organizations. In the case of IBM, for example, each mainframe model provides for subcapacity processors from granular processing requirements up to the full range of high-end computing. 6 The IBM series of mainframe computers, for example, the IBM System z10 Enterprise Class (EC), can process over a staggering one billion transactions per day. Chapter 1. Introduction to the New Mainframe 13
Slide 38: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am Let’s look at two recent entries from IBM (Figure 1-2): System z Business Class (BC) System z Enterprise Class (BC) Figure 1-2 System z Business Class and Enterprise Class The System z Business Class (BC) could be said to be intended for small to midrange enterprise computing, and delivers an entry point with granular scalability and a wide range of capacity settings to grow with the workload. The BC provides for a maximum of up to 10 configurable PUs. The BC shares many of the characteristics and processing traits of its larger sibling, the Enterprise Class (EC). This model provides granular scalability and capacity settings on a much larger scale and is intended to satisfy high-end processing requirements. As a result, the EC has a larger frame to house the extensive capacity that supports greater processing requirements. The EC offers up to 64 configurable CPs. 1.7 Factors contributing to mainframe use The reasons for mainframe use are many, but most generally fall into one or more of the following categories: Reliability, availability, and serviceability Security Scalabilty 14 Introduction to the New Mainframe: z/OS Basics
Slide 39: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm Continuing compatibility Evolving architecture Extensibility Lower total cost of ownership (TCO) Environmental friendliness Let us look at each of these categories in more detail. 1.7.1 Reliability, availability, and serviceability The reliability, availability, and serviceability (RAS) of a computer system have always been important factors in data processing. When we say that a particular computer system “exhibits RAS characteristics”, we mean that its design places a high priority on the system remaining in service at all times. Ideally, RAS is a central design feature of all aspects of this computer system, including the applications. RAS is ubiquitous in the mainframe. RAS has become accepted as a collective term for many characteristics of hardware and software that are prized by mainframe users. The terms are defined as follows: Reliability The system’s hardware components have extensive self-checking and self-recovery capabilities. The system’s software reliability is a result of extensive testing and the ability to make quick updates for detected problems. One of the operating system’s feature is a Health Checker that identifies potential problems before they impact availability or, in worst cases, cause system or application outages. Availability: The ability to recover from the failure of a component without impacting the rest of the running system. Availability The system can recover from a failed component without impacting the rest of the running system. This applies to hardware recovery (the automatic replacing of failed elements with spares) and software recovery (the layers of error recovery that are provided by the operating system). The highest levels of availability are obtained with DB2 and the Parallel Sysplex on the System z architecture. Serviceability The system can determine why a failure occurred. This allows for the replacement of hardware and software elements while impacting as little of the operational system as possible. This term also implies well-defined units of replacement, either hardware or software. Chapter 1. Introduction to the New Mainframe 15
Slide 40: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am A computer system is available when its applications are available. An available system is one that is reliable, that is, it rarely requires downtime for upgrades or repairs. And, if the system is brought down by an error condition, it must be serviceable, that is, easy to fix within a relatively short period of time. Mean time between failure (MTBF) refers to the availability of a computer system. The New Mainframe and its associated software have evolved to the point that customers often experience months or even years of system availability between system downtimes. Moreover, when the system is unavailable because of an unplanned failure or a scheduled upgrade, this period is typically short. The remarkable availability of the system in processing the organization’s mission-critical applications is vital in today’s 24x7 global economy. Along with the hardware, mainframe operating systems exhibit RAS through such features as storage protection and a controlled maintenance process. System z servers are among the most secure servers on the market, with mean time between failures (MTBF) measured in decades. In fact, the System z is designed for up to 99.999% availability with Parallel Sysplex clustering. The System z is designed to provide superior qualities of service to help support high volume, transaction-driven applications, and other critical processes. It supplies tremendous power and throughput for information-intensive computing requirements. Beyond RAS, a state-of-the-art mainframe system might be said to provide high availability and fault tolerance. Redundant hardware components in critical paths, enhanced storage protection, a controlled maintenance process, and system software designed for unlimited availability all help to ensure a consistent, highly available environment for business applications in the event that a system component fails. Such an approach allows the system designer to minimize the risk of having a single point of failure (SPOF) undermine the overall RAS of a computer system. Enterprises many times require an on demand operating environment that provides responsiveness, resilience, and a variable cost structure to provide maximum business benefits. The mainframe’s Capacity on Demand (CoD) solutions offer permanent or temporary increases in processor capacity and additional memory. This robust serviceability allows for on going upgrades during concurrent workload execution. 16 Introduction to the New Mainframe: z/OS Basics
Slide 41: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm 1.7.2 Security One of a firm’s most valuable resources is its data: customer lists, accounting data, employee information, and so on. This critical data needs to be securely managed and controlled, and, simultaneously, made available to those users authorized to see it. The mainframe computer has extensive capabilities to simultaneously share, but still protect, the firm’s data among multiple users. In an IT environment, data security is defined as protection against unauthorized access, transfer, modification, or destruction, whether accidental or intentional. To protect data and to maintain the resources necessary to meet the security objectives, customers typically add a sophisticated security manager product to their mainframe operating system. The customer’s security administrator often bears the overall responsibility for using the available technology to transform the company’s security policy into a usable plan. A secure computer system prevents users from accessing or changing any objects on the system, including user data, except through system-provided interfaces that enforce authority rules. The mainframe provides a secure system for processing large numbers of heterogeneous applications that access critical data. The mainframe's built-in security throughout the software stack means that z/OS, due to its architecture design and use of registries, will not suffer from buffer overflow related problems caused by virii that are characteristic of many distributed environments. Hardware enabled security offers unmatched protection for workload isolation, storage protection, and secured communications. Built-in security embedded throughout the operating system, network infrastructure, middleware, application and database architectures deliver secured infrastructures and secured business processing, which fosters compliance. The mainframe’s cryptography executes at multiple layers of the infrastructure, which ensures protection of data throughout its life cycle. In this course, we discuss one example of a mainframe security system in Chapter 18, “Security on z/OS” on page 577. The IBM System z joins previous IBM mainframes as the world's only servers with the highest level of hardware security certification, that is, Common Criteria Evaluation Assurance Level 5 (EAL5). The EAL5 ranking gives companies confidence that they can run many different applications running on different operating systems, such as z/OS, z/VM, z/VSE, z/TPF and Linux-based applications containing confidential data, such as payroll, human resources, e-commerce, ERP and CRM systems, on one System z divided into partitions that keep each application's data secure and distinct from the others. Chapter 1. Introduction to the New Mainframe 17
Slide 42: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am That is, the System z architecture is designed to prevent the flow of information among logical partitions on a single system. Data is the key to running your business. DB2 and zSeries hardware and software give you the controls to safely and effectively administer it. DB2 uses security functions in the operating system. With multilevel security, users can implement sophisticated security in their DB2 applications without writing their own code and be better positioned to obtain auditor certification. DB2 uses cryptographic functions in the hardware. Both security and cryptographic functions enable delivery of leading-edge security at low levels of granularity, for example, individual rows and columns instead of tables. EAL5 certification for zSeries and z/Os demonstrates that the zSeries can be an essential building block for server consolidation and the integration of on demand applications and traditional corporate workloads on a single server. This is desirable for reasons of economy, flexibility, security, or management. 1.7.3 Scalability It has been said that the only constant is change. Nowhere is that statement truer than in the IT industry. In business, positive results can often trigger a growth in IT infrastructure to cope with increased demand. The degree to which the IT organization can add capacity without disruption to normal business processes or without incurring excessive overhead (nonproductive processing) is largely determined by the scalability of the particular computing platform. Scalability: Scalability is a desirable property of a system, which indicates its ability to either handle growing amounts of work in a graceful manner or to be readily enlarged. By scalability, we mean the ability of the hardware, software, or a distributed system to continue to function well as it changes in size or volume, for example, the ability to retain performance levels when adding processors, memory, and storage. A scalable system can efficiently adapt to more work, with larger or smaller networks performing tasks of varying complexity. The mainframe provides functionality for both vertical and horizontal scaling, where software and hardware collaborate to accommodate various application requirements. As a company grows in employees, customers, and business partners, it usually needs to add computing resources to support business growth. One approach is to add more processors of the same size, with the resulting overhead, to manage this more complex setup. A company can consolidate its many smaller processors into fewer, larger systems because the mainframe is a shared everything (SE) architecture. This is different from a shared nothing architecture. Through the shared everything design, you have near-continuous availability for your business applications, which gives you a competitive advantage, allowing you to grow your business on demand. 18 Introduction to the New Mainframe: z/OS Basics
Slide 43: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm Mainframes exhibit scalability characteristics in both hardware and software, with the ability to run multiple copies of the operating system software as a single entity called a system complex, or sysplex. We further explore mainframe clustering technology and its uses in 2.9, “What is a sysplex” on page 68. The ease of this platform’s scalability is due to the mainframe’s inherent virtualization capability, which has evolved over several decades through its balanced synergy design. 1.7.4 Continuing compatibility Mainframe customers tend to have a large financial investment in their applications and data. Some applications have been developed and refined over decades. Some applications were written many years ago, while others may have been written “yesterday.” The ability of an application to work in the system or its ability to work with other devices or programs is called compatibility. Compatibility: The ability of a system both to run software requiring new hardware instructions and to run older software requiring the original hardware instructions. The need to support applications of varying ages imposes a strict compatibility demand on mainframe hardware and software, which have been upgraded many times since the first System/360 mainframe computer was shipped in 1964. Applications must continue to work properly. Thus, much of the design work for new hardware and system software revolves around this compatibility requirement. The overriding need for compatibility is also the primary reason why many aspects of the system work as they do, for example, the syntax restrictions of the job control language (JCL) that is used to control job scheduling and execution. Any new design enhancements made to the JCL must preserve compatibility with older jobs so that they can continue to run without modification. The desire and need for continuing compatibility is one of the defining characteristics of mainframe computing. Absolute compatibility across decades of changes and enhancements is not possible, of course, but the designers of mainframe hardware and software make it a top priority. When an incompatibility is unavoidable, the designers typically warn users at least a year in advance that software changes might be needed. 1.7.5 Evolving architecture Technology has always accelerated the pace of change. New technologies enable new ways of doing business, shifting markets, changing customer expectations, and redefining business models. Each major enhancement to technology presents opportunities. Companies that understand and prepare for changes can gain advantage over competitors and lead their industries. To support an on demand business, the IT infrastructure must evolve to support it. Chapter 1. Introduction to the New Mainframe 19
Slide 44: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am At its heart, the data center must transition to reflect these needs, the data center must be responsive to changing demands, it must be variable to support the diverse environment, it must be flexible so that applications can run on the optimal resources at any point in time, and it must be resilient to support an always open for business environment. For over four decades, the mainframe has been the leading technology in data and transaction serving. Each new generation of this platform provides a strong combination of past mainframe characteristics plus new functions designed around scalability, availability, and security. 1.7.6 Extensibility In software engineering, extensibility is a system design principle where the implementation takes future growth into consideration. It is a systemic measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be added through the addition of new functionality or through modification of existing functionality. The mainframe’s central theme is to provide for change while minimizing impact to existing system functions. The mainframe, as it becomes more autonomic, takes on tasks not anticipated in its original design. Its ultimate aim is to create the definitive self-managing computer environment to overcome its rapidly growing maturity and to facilitate expansion. Many built-in features perform software management, runtime health checking, and transparent hardware hot-swapping. Also, extensibility comes in the form of cost containment and has been with the mainframe for a long time in different forms. One aspect is that it is a share-everything architecture. Its component and infrastructure reuse is characteristic of its design. 1.7.7 Total cost of ownership Many organizations are under the false impression that the mainframe is a server that will be accompanied by higher overall software, hardware, and people costs. Most organizations do not accurately calculate the total costs of their server proliferation, largely because chargeback mechanisms do not exist, because only incremental mainframe investment costs are compared to incremental distributed costs, or because total shadow costs are not weighed in. Many organizations also fail to recognize the path length delays and context switching of running workloads across many servers, which typically adds up to a performance penalty that is non-existent on the mainframe. Also, the autonomic capabilities of the mainframe (reliability, scalability, and self-managing design) may not be taken into consideration. Distributed servers encounter an efficiency barrier where adding incremental servers after a certain point fails to add 20 Introduction to the New Mainframe: z/OS Basics
Slide 45: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm efficiency. The total diluted cost of the mainframe is not used correctly in calculations; rather, the delta costs attributed to an added workload often make the comparisons erroneous. In distributed servers, the cost per unit of work never approximates the incremental cost of a mainframe. However, over time, it is unlikely that a server farm could achieve the economies of scale associated with a fully loaded mainframe regardless of how many devices are added. In effect, there is a limit to the efficiencies realizable in a distributed computing environment. These inefficiencies are due to shadow costs, execution of only one style of workload versus a balanced workload, underutilization of CPUs, people expenses, and real estate cost of a distributed operations management. 1.7.8 Environmentally friendly Refurbishing existing data centers can also prove cost-prohibitive, such as installing new cooling units that require reconfigured floors. The cost of power over time must also be considered in data center planning. With the rising trends in energy costs is an accompanying trend towards high density distributed servers that stress the power capacity of today’s environment. However, this trend has been met with rising energy bills, and facilities that do not accommodate new energy requirements. Distributed servers result in power and cooling requirements per square foot that stress current data center power thresholds. Because these servers have an attractive initial price point, their popularity has increased. At the same time, their heat has created a problem for data centers whose total utility usage is consumed entirely by the energy proliferating servers. The mainframe’s virtualization uses the power of many servers using a small hardware footprint. Today’s mainframe reduces the impact of energy cost to a near-negligible value when calculated on a per logical server basis because more applications, several hundred of them, can be deployed on a single machine. With mainframes, fewer physical servers running at a near constant energy level can host multiple virtual software servers. This setup allows a company to optimize the utilization of hardware, and consolidate physical server infrastructure by hosting servers on a small number of powerful servers. With server consolidation onto a mainframe, often using Linux, companies can achieve better hardware utilization, and reduce floor space and power consumption, thus driving down costs. Chapter 1. Introduction to the New Mainframe 21
Slide 46: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am The mainframe is designed to scale up and out, for example, by adding more processors to an existing hardware frame, and using existing MIPS, which retain their value during upgrades. (With distributed systems, the hardware and processing power is typically replaced after just three to four years of use.) By adding MIPS to the existing mainframe, more workloads can be run more cost-effectively without changing the footprint. There is no need for another server that would in turn require additional environmental work, network, and cooling. For example, the IBM System z Integrated Facility for Linux (IFL) CPUs can easily run hundreds of instances of Linux at an incremental cost of 75 watts of power. 1.8 Typical mainframe workloads Most mainframe workloads fall into one of two categories: batch processing or online transaction processing, which includes web-based applications (Figure 1-3). Application program Batch job Input data Processes data to perform a particular task Output data Application program Query Reply Accesses shared data on behalf of an online user Online (interactive) transaction Figure 1-3 Typical mainframe workloads These workloads are discussed in several chapters in this text; the following sections provide an overview. 22 Introduction to the New Mainframe: z/OS Basics
Slide 47: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm 1.8.1 Batch processing One key advantage of mainframe systems is their ability to process terabytes of data from high-speed storage devices and produce valuable output. For example, mainframe systems make it possible for banks and other financial institutions to perform end-of-quarter processing and produce reports that must be sent to customers (for example, quarterly stock statements or pension statements) or to the government (for example, financial results). With mainframe systems, retail stores can generate and consolidate nightly sales reports for review by regional sales managers. Batch processing: The running of jobs on the mainframe without user interaction. The applications that produce these statements are batch applications, that is, they are processed on the mainframe without user interaction. A batch job is submitted on the computer, reads and processes data in bulk (perhaps terabytes of data), and produces output, such as customer billing statements. An equivalent concept can be found in a UNIX script file or a Windows® command file, but a z/OS batch job might process millions of records. While batch processing is possible on distributed systems, it is not as commonplace as it is on mainframes, because distributed systems often lack: Sufficient data storage Available processor capacity, or cycles Sysplex-wide management of system resources and job scheduling Mainframe operating systems are typically equipped with sophisticated job scheduling software that allows data center staff to submit, manage, and track the execution and output of batch jobs.7 Batch processes typically have the following characteristics: Large amounts of input data are processed and stored (perhaps terabytes or more), large numbers of records are accessed, and a large volume of output is produced. Immediate response time is usually not a requirement. However, batch jobs often must complete within a “batch window,” a period of less-intensive online activity, as prescribed by a service level agreement (SLA). This window is shrinking, and batch jobs are now often designed to run concurrently with online transactions with minimal resource contention. 7 In the early days of the mainframe, punched cards were often used to enter jobs into the system for execution. “Keypunch operators” used card punches to enter data, and decks of cards (or batches) were produced. These were fed into card readers, which read the jobs and data into the system. As you can imagine, this process was cumbersome and error-prone. Nowadays, it is possible to transfer the equivalent of punched card data to the mainframe in a PC text file. We discuss various ways of introducing work into the mainframe in Chapter 7, “Batch processing and JES” on page 269. Chapter 1. Introduction to the New Mainframe 23
Slide 48: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am Information is generated about large numbers of users or data entities (for example, customer orders or a retailer’s stock on hand). A scheduled batch process can consist of the execution of hundreds or thousands of jobs in a pre-established sequence. During batch processing, multiple types of work can be generated. Consolidated information, such as profitability of investment funds, scheduled database backups, processing of daily orders, and updating of inventories, are common examples. Figure 1-4 on page 25 shows a number of batch jobs running in a typical mainframe environment. Consider the following elements at work in the scheduled batch process: 1. At night, numerous batch jobs running programs and utilities are processed. These jobs consolidate the results of the online transactions that take place during the day. 2. The batch jobs generate reports of business statistics. 3. Backups of critical files and databases are made before and after the batch window. 4. Reports with business statistics are sent to a specific area for analysis the next day. 5. Reports with exceptions are sent to the branch offices. 6. Monthly account balance reports are generated and sent to all bank customers. 7. Reports with processing summaries are sent to the partner credit card company. 8. A credit card transaction report is received from the partner company. 9. In the production control department, the operations area is monitoring the messages on the system console and the execution of the jobs. 10.Jobs and transactions are reading or updating the database (the same one that is used by online transactions) and many files are written to tape. 24 Introduction to the New Mainframe: z/OS Basics
Slide 49: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm Residence Branch offices Main office Account balances, bills, etc. 5 CREDIT CARD 6 Reports Statistics, 1234 5678 9012 VALID FROM GOOD THRU PAUL FISCHER XX/XX/XX XX/XX/XX XX/XX/XX XX/XX/XX PAUL FISCHER Processing 7 reports 4 summaries, exceptions Mainframe Processing batch jobs Reports Partners and clients exchange information 8 1 2 Reports Backup 3 s Data update Tape storage 10 Sequential data sets 9 Disk storage databases Production control System operator Figure 1-4 Typical batch use Attention: Today’s mainframes can run standard batch processing, such as COBOL, and UNIX and Java programs. These run times can execute either as stand-alone jobs or participate collaboratively within a single job stream. This makes batch processing extremely flexible when integrating different execution environments centrally on a single server. Chapter 1. Introduction to the New Mainframe 25
Slide 50: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am 1.8.2 Online transaction processing Transaction processing that occurs interactively with the user is referred to as online transaction processing (OLTP). Typically, mainframes serve a vast number of transaction systems. These systems are often mission-critical applications that businesses depend on for their core functions. Transaction systems must be able to support an unpredictable number of concurrent users and transaction types. Most transactions are executed in short time periods (fractions of a second in some cases). One of the main characteristics of a transaction system is that the interactions between the user and the system are short. The user performs a complete business transaction through short interactions, with an immediate response time required for each interaction. These systems are currently supporting mission-critical applications; therefore, continuous availability, high performance, and data protection and integrity are required. Online transactions are familiar to most people. Examples include: Online transaction ATM machine transactions, such as deposits, withdrawals, inquiries, and processing transfers (OLTP): Transaction Supermarket payments with debit or credit cards processing that occurs Purchase of merchandise over the Internet interactively with the user. For example, inside a bank branch office or on the Internet, customers are using online services when checking an account balance or directing fund balances. In fact, an online system performs many of the same functions as an operating system: Managing and dispatching tasks Controlling user access authority to system resources Managing the use of memory Managing and controlling simultaneous access to data files Providing device independence Some industry uses of mainframe-based online systems include: Banks: ATMs, teller systems for customer service, and online financial systems Insurance: Agent systems for policy management and claims processing Travel and transport: Airline reservation systems Manufacturing: Inventory control and production scheduling Government: Tax processing, and license issuance and management 26 Introduction to the New Mainframe: z/OS Basics
Slide 51: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm How might the users in these industries interact with their mainframe systems? Multiple factors can influence the design of a company’s transaction processing system, including: Number of users interacting with the system at any one time. Number of transactions per second (TPS). Availability requirements of the application. For example, must the application be available 24 hours a day, seven days a week, or can it be brought down briefly one night each week? Before personal computers and intelligent workstations became popular, the most common way to communicate with online mainframe applications was with 3270 terminals. These devices were sometimes known as “dumb” terminals, but they had enough intelligence to collect and display a full screen of data rather than interacting with the computer for each key stroke, saving processor cycles. The characters were green on a black screen, so the mainframe applications were nicknamed “green screen” applications. Based on these factors, user interactions vary from installation to installation. For many of the applications now being designed, many installations are reworking their existing mainframe applications to include web browser-based interfaces for users. This work sometimes requires new application development, but can often be done with vendor software purchased to “re-face” the application. Here, the user often does not realize that there is a mainframe behind the scenes. In this book, there is no need to describe the process of interacting with the mainframe through a web browser, as it is exactly the same as any interaction a user would have through the web. The only difference is the machine at the other end. Online transactions usually have the following characteristics: A small amount of input data, a few stored records accessed and processed, and a small amount of data as output Immediate response time, usually less than one second A large numbers of users involved in large numbers of transactions Round-the-clock availability of the transactional interface to the user Assurance of security for transactions and user data In a bank branch office, for example, customers use online services when checking an account balance or making an investment. Chapter 1. Introduction to the New Mainframe 27
Slide 52: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am Figure 1-5 on page 28 shows a series of common online transactions using a mainframe. ATMs Account activities 1 Branch office automation systems SNA or TCP/IP network 4 Requests Branch offices 2 3 Office automation systems Queries and updates Mainframe Accesses database 5 6 Central office Business analysts Inventory control Disk storage controller Stores database files Figure 1-5 Typical online use Where: 1. A customer uses an ATM, which presents a user-friendly interface for various functions: withdrawal, query account balance, deposit, transfer, or cash advance from a credit card account. 2. Elsewhere in the same private network, a bank employee in a branch office performs operations, such as consulting, working with fund applications, and money ordering. 3. At the bank’s central office, business analysts tune transactions for improved performance. Other staff use specialized online systems for office automation to perform customer relationship management, budget planning, and stock control. 4. All requests are directed to the mainframe computer for processing. 28 Introduction to the New Mainframe: z/OS Basics
Slide 53: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm 5. Programs running on the mainframe computer perform updates and inquiries to the database management system (for example, DB2). 6. Specialized disk storage systems store the database files. 1.8.3 Speciality engines to characterize workload The mainframe provides customers with the capability to characterize their server configuration to the type of workload they elect to run on it. The mainframe can configure CPUs as speciality engines to off load specific work to separate processors, which alleviates the general CPUs to continue processing standard workloads, increasing the overall ability of the mainframe to complete more batch jobs or transactions. In these scenarios, the customer can benefit from greater throughput, which eases the overall total cost of ownership. These speciality processors are described in Chapter 2, “Mainframe hardware systems and high availability” on page 45. 1.9 Roles in the mainframe world Mainframe systems are designed to be used by large numbers of people. Most of those who interact with mainframes are users, that is, people who use the applications that are hosted on the system. However, because of the large number of users, applications running on the system, and the sophistication and complexity of the system software that supports the users and applications, a variety of roles are needed to operate and support the mainframe system. Chapter 1. Introduction to the New Mainframe 29
Slide 54: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am Figure 1-6 shows the many roles in the mainframe environment. Mainframe jobs Application developer Production control analyst Operator End user System z Business Class and Enterprise Class System programmer System administrator Figure 1-6 Who’s who in the mainframe world In the IT field, these roles are referred to by a number of different titles. This text uses the following: System programmers System administrators (for example, DBA, storage, network, security, and performance) Application designers and programmers System operators Production control analysts In a distributed systems environment, many of the same roles are needed as in the mainframe environment. However, the job responsibilities are often not as well defined. Since the 1960s, mainframe roles have evolved and expanded to provide an environment on which the system software and applications can function smoothly and effectively and serve many thousands of users efficiently. 30 Introduction to the New Mainframe: z/OS Basics
Slide 55: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm Although it may seem that the size of the mainframe support staff is large and unwieldy, the numbers become comparatively small when one considers the number of users supported, the number of transactions run, and the high business value of the work that is performed on the mainframe. This situation relates to the cost containment mentioned earlier. This book is concerned mainly with the system programmer and application programmer roles in the mainframe environment. There are, however, several other important jobs involved in the upkeep of the mainframe, and we touch on some of these roles to give you a better idea of what is going on behind the scene. Mainframe activities, such as the following, often require cooperation among the various roles: Installing and configuring system software Designing and coding new applications to run on the mainframe Introduction and management of new workloads on the system, such as batch jobs and online transaction processing Operation and maintenance of the mainframe software and hardware In the following sections, we describe each role in more detail. Important: A feature of the mainframe is it requires fewer personnel to configure and run it than another server environment. Many of the administration roles are automated and offer the means to incorporate rules, allowing the system to run autonomously with no manual intervention. These rules are based on installation policies that become integrated with the configuration. 1.9.1 Who is the system programmer In a mainframe IT organization, the system programmer plays a central role. The system programmer installs, customizes, and maintains the operating system, and also installs or upgrades products that run on the system. The system programmer might be presented with the latest version of the operating system to upgrade the existing systems, or the installation might be as simple as upgrading a single program, such as a sort application. The system programmer performs the following tasks: Planning hardware and software system upgrades and changes in configuration Training system operators and application programmers System programmer: The person who installs, customizes, and maintains the operating system. Chapter 1. Introduction to the New Mainframe 31
Slide 56: Chap1 mainframe intro.fm Automating operations Draft Document for Review February 26, 2011 8:32 am Performing capacity planning Running installation jobs and scripts Performing installation-specific customization tasks Integration-testing the new products with existing applications and user procedures System-wide performance tuning to meet required levels of service The system programmer must be skilled at debugging problems with system software. These problems are often captured in a copy of the computer's memory contents called a dump, which the system produces in response to a failing software product, user job, or transaction. Armed with a dump and specialized debugging tools, the system programmer can determine where the components have failed. When the error has occurred in a software product, the system programmer works directly with the software vendor’s support representatives to discover whether the problem’s cause is known and whether a patch is available. System programmers are needed to install and maintain the middleware on the mainframe, such as database management systems, online transaction processing systems, and web servers. Middleware is a software “layer” between the operating system and the user or user application. It supplies major functions that are not provided by the operating system. Major middleware products such as DB2, CICS, and IMS™ can be as complex as the operating system itself, if not more so. Attention: For large mainframe shops, it is not unusual for system programmers to specialize in specific products, such as CICS, IMS or DB2. 1.9.2 Who is the system administrator The distinction between system programmer and system administrator varies widely among mainframe sites. In smaller IT organizations, where one person might be called upon to perform several roles, the terms may be used interchangeably. System administrator: The person who maintains the critical business data that resides on the mainframe. In larger IT organizations with multiple departments, the job responsibilities tend to be more clearly separated. System administrators perform more of the day-to-day tasks related to maintaining the critical business data that resides on the mainframe, while the system programmer focuses on maintaining the system itself. 32 Introduction to the New Mainframe: z/OS Basics
Slide 57: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm One reason for the separation of duties is to comply with auditing procedures, which often require that no one person in the IT organization be allowed to have unlimited access to sensitive data or resources. Examples of system administrators include the database administrator (DBA) and the security administrator. Although system programmer expertise lies mainly in the mainframe hardware and software areas, system administrators are more likely to have experience with the applications. They often interface directly with the application programmers and users to make sure that the administrative aspects of the applications are met. These roles are not necessarily unique to the mainframe environment, but they are key to its smooth operation nonetheless. In larger IT organizations, the system administrator maintains the system software environment for business purposes, including the day-to-day maintenance of systems to keep them running smoothly. For example, the database administrator must ensure the integrity of, and efficient access to, the data that is stored in the database management systems. Other examples of common system administrator tasks can include: Installing software Adding and deleting users and maintaining user profiles Maintaining security resource access lists Managing storage devices and printers Managing networks and connectivity Monitoring system performance In matters of problem determination, the system administrator generally relies on the software vendor support center personnel to diagnose problems, read dumps, and identify corrections for cases in which these tasks are not performed by the system programmer. 1.9.3 Who are the application designers and programmers The application designer and application programmer (or application developer) design, build, test, and deliver mainframe applications for the company’s users and customers. Based on requirements gathered from business analysts and users, the designer creates a design specification from which the programmer constructs an application. The process includes several iterations of code changes and compilation, application builds, and unit testing. Chapter 1. Introduction to the New Mainframe 33
Slide 58: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am During the application development process, the designer and programmer must interact with other roles in the enterprise. For example, the programmer often works on a team with other programmers who are building code for related application program modules. When completed, each module is passed through a testing process that can include function, integration, and system-wide tests. Following the tests, the application programs must be acceptance tested by the user community to determine whether the code actually satisfies the original user requirement. In addition to creating new application code, the programmer is responsible for maintaining and enhancing the company’s existing mainframe applications. In fact, this is often the primary job for many of today’s mainframe application programmers. Although mainframe installations still create new programs with Common Business Oriented Language (COBOL) or PL/I, languages such as Java™ and C/C++ have become popular for building new applications on the mainframe, just as they have on distributed platforms. Widespread development of mainframe programs written in high-level languages such as COBOL and PL/I continues at a brisk pace, despite rumors to the contrary. Many thousands of programs are in production on mainframe systems around the world, and these programs are critical to the day-to-day business of the corporations that use them. COBOL and other high-level language programmers are needed to maintain existing code and make updates and modifications to existing programs. Also, many corporations continue to build new application logic in COBOL and other traditional languages, and IBM continues to enhance their high-level language compilers to include new functions and features that allow those languages to continue to take advantage of newer technologies and data formats. These programmers can benefit from state-of-the-art integrated development environments (IDEs) to enhance their productivity. These IDEs include support for sophisticated source code search and navigation, source code re-factoring, and syntax highlighting. IDEs also assist with defining repeatable build processing steps and identifying dependent modules that must be re-built after changes to source code have been developed. We look at the roles of application designer and application programmer in more detail in Part 2, “Application programming on z/OS” on page 293. 34 Introduction to the New Mainframe: z/OS Basics
Slide 59: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm 1.9.4 Who is the system operator The system operator monitors and controls the operation of the mainframe hardware and software. The operator starts and stops system tasks, monitors the system consoles for unusual conditions, and works with the system programming and production control staff to ensure the health and normal operation of the systems. As applications are added to the mainframe, the system operator is responsible System for ensuring that they run smoothly. New applications from the Applications operator: The person who Programming Department are typically delivered to the Operations Staff with a monitors and run book of instructions. A run book identifies the specific operational controls the requirements of the application, which operators need to be aware of during job operation of the execution. Run book instructions might include, for example, application-specific mainframe hardware and console messages that require operator intervention, recommended operator software. responses to specific system events, and directions for modifying job flows to accommodate changes in business requirements8. The operator is also responsible for starting and stopping the major subsystems, such as transaction processing systems, database systems, and the operating system itself. These restart operations are not nearly as commonplace as they once were, as the availability of the mainframe has improved dramatically over the years. However, the operator must still perform an orderly shutdown and startup of the system and its workloads, when it is required. In case of a failure or an unusual situation, the operator communicates with system programmers, who assist the operator in determining the proper course of action, and with the production control analyst, who works with the operator to make sure that production workloads are completing properly. 1.9.5 Who is the production control analyst Production control analyst: The person who ensures that batch workloads run to completion without error or delay. The production control analyst is responsible for making sure that batch workloads run to completion without error or delay. Some mainframe installations run interactive workloads for online users, followed by batch updates that run after the prime shift when the online systems are not running. While this execution model is still common, worldwide operations at many companies with live, Internet-based access to production data are finding the “daytime online/night time batch” model to be obsolete. However batch workloads continue to be a part of information processing, and skilled production control analysts play a key role. 8 Console messages were once so voluminous that operators often had a difficult time determining whether a situation was really a problem. In recent years, tools to reduce the volume of messages and automate message responses to routine situations have made it easier for operators to concentrate on unusual events that might require human intervention. Chapter 1. Introduction to the New Mainframe 35
Slide 60: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am A common complaint about mainframe systems is that they are inflexible and hard to work with, specifically in terms of implementing changes. The production control analyst often hears this type of complaint, but understands that the use of well-structured rules and procedures to control changes, a strength of the mainframe environment, helps prevent outages. In fact, one reason that mainframes have attained a strong reputation for high levels of availability and performance is that there are controls on change and it is difficult to introduce change without proper procedures. 1.9.6 What role do vendors play A number of vendor roles are commonplace in the mainframe shop. Because most mainframe computers are sold by IBM, and the operating systems and primary online systems are also provided by IBM, most vendor contacts are IBM employees. However, independent software vendor (ISV) products are also used in the IBM mainframe environment, and customers use original equipment manufacturer (OEM) hardware, such as disk and tape storage devices, as well. Typical vendor roles are: Hardware support or customer engineer Hardware vendors usually provide onsite support for hardware devices. The IBM hardware maintenance person is often referred to as the customer engineer (CE). The CE provides installation and repair service for the mainframe hardware and peripherals. The CE usually works directly with the operations teams if hardware fails or if new hardware is being installed. Software support A number of vendor roles exist to support software products on the mainframe9. IBM has a centralized Support Center that provides entitled and extra-charge support for software defects or usage assistance. There are also information technology specialists and architects who can be engaged to provide additional pre- and post-sales support for software products, depending upon the size of the enterprise and the particular customer situation. Field technical sales support, systems engineer, or client representative For larger mainframe accounts, IBM and other vendors provide face-to-face sales support. The vendor representatives specialize in various types of hardware or software product families and call on the part of the customer organization that influences the product purchases. 9 This text does not examine the marketing and pricing of mainframe software. However, the availability and pricing of middleware and other licensed programs is a critical factor affecting the growth and use of mainframes. 36 Introduction to the New Mainframe: z/OS Basics
Slide 61: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm At IBM, the technical sales specialist is referred to as the field technical sales support (FTSS) person, or by the older term, systems engineer (SE). For larger mainframe accounts, IBM frequently assigns a client representative, who is attuned to the business issues of a particular industry sector, to work exclusively with a small number of customers. The client representative acts as the general single point of contact (SPOC) between the customer and the various organizations within IBM. 1.10 z/OS and other mainframe operating systems Much of this text is concerned with teaching you the fundamentals of z/OS, which is the foremost IBM mainframe operating system. We begin discussing z/OS concepts in Chapter 3, “z/OS overview” on page 91. It is useful for mainframe students, however, to have a working knowledge of other mainframe operating systems. One reason is that a given mainframe computer might run multiple operating systems. For example, the use of z/OS, z/VM®, and Linux® on the same mainframe is common. Mainframe operating systems are sophisticated products with substantially different characteristics and purposes, and each could justify a separate book for a detailed introduction. Besides z/OS, four other operating systems dominate mainframe usage: z/VM, z/VSE™, Linux on IBM System z, and z/TPF. 1.10.1 z/VM z/Virtual Machine (z/VM) has two basic components: a control program (CP) and a single-user operating system (CMS). As a control program, z/VM is a hypervisor because it runs other operating systems in the virtual machines it creates. Any of the IBM mainframe operating systems such as z/OS, Linux on System z, z/VSE, and z/TPF can be run as guest systems in their own virtual machines, and z/VM can run any combination of guest systems. The control program artificially creates multiple virtual machines from the real hardware resources. To users, it appears as though they have dedicated use of the shared real resources. The shared real resources include printers, disk storage devices, and the CPU. The control program ensures data and application security among the guest systems. The real hardware can be shared among the guests, or dedicated to a single guest for performance reasons. The system programmer allocates the real devices among the guests. For most customers, the use of guest systems avoids the need for larger hardware configurations. Chapter 1. Introduction to the New Mainframe 37
Slide 62: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am z/VM’s other major component is the Conversational Monitor System (CMS). This component of z/VM runs in a virtual machine and provides both an interactive user interface and the general z/VM application programming interface. 1.10.2 z/VSE z/Virtual Storage Extended (z/VSE) is popular with users of smaller mainframe computers. Some of these customers eventually migrate to z/OS when they grow beyond the capabilities of z/VSE. Compared to z/OS, the z/VSE operating system provides a smaller, less complex base for batch processing and transaction processing. The design and management structure of z/VSE is excellent for running routine production workloads consisting of multiple batch jobs (running in parallel) and extensive, traditional transaction processing. In practice, most z/VSE users also have the z/VM operating system and use this as a general terminal interface for z/VSE application development and system management. z/VSE was originally known as Disk Operating System (DOS), and was the first disk-based operating system introduced for the System/360 mainframe computers. DOS was seen as a temporary measure until OS/360 would be ready. However, some mainframe customers liked its simplicity (and small size) and decided to remain with it after OS/360 became available. DOS became known as DOS/VS (when it started using virtual storage), then VSE/SP, and later VSE/ESA™, and most recently z/VSE. The name VSE is often used collectively to refer to any of the more recent versions. 1.10.3 Linux on IBM System z Several (non-IBM) Linux distributions can be used on a mainframe. There are two generic names for these distributions: Linux on S/390 (uses 31-bit addressing and 32-bit registers) Linux on System z (uses 64-bit addressing and registers) The phrase Linux on System z is used to refer to Linux running on an S/390 or System z system, when there is no specific need to refer explicitly to either the 31-bit version or the 64-bit version. We assume students are generally familiar with Linux and therefore we mention only those characteristics that are relevant for mainframe usage. These include the following: Linux uses traditional count key data (CKD)10disk devices and SAN-connected SCSI-type devices. Other mainframe operating systems can 38 Introduction to the New Mainframe: z/OS Basics
Slide 63: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm recognize these drives as Linux drives, but cannot use the data formats on the drives, that is, there is no sharing of data between Linux and other mainframe operating systems. Linux does not use 3270 display terminals, while all other mainframe operating systems use 3270s as their basic terminal architecture.11 Linux uses X Window System based terminals or X Window System emulators on PCs; it also supports typical ASCII terminals, usually connected through the telnet protocol. The X Window System is the standard for graphical interfaces in Linux. It is the middle layer between the hardware and the window manager. With the proper setup, a Linux system under z/VM can be quickly cloned to make another, separate Linux image. The z/VM emulated LAN can be used to connect multiple Linux images and to provide an external LAN route for them. Read-only file systems, such as a typical /usr file system, can be shared by Linux images. Linux on a mainframe operates with the ASCII character set, not the (Extended Binary Coded Decimal Interchange Code) EBCDIC12 form of stored data that is typically used on mainframes. Here, EBCDIC is used only when writing to such character-sensitive devices as displays and printers. The Linux drivers for these devices handle the character translation. 1.10.4 z/TPF The z/Transaction Processing Facility (z/TPF) operating system is a special-purpose system that is used by companies with high transaction volume, such as credit card companies and airline reservation systems. z/TPF was once known as Airline Control Program (ACP). It is still used by airlines and has been extended for other large systems with high-speed, high-volume transaction processing requirements. 10 CKD devices are formatted such that the individual data pieces can be accessed directly by the read head of the disk. 11 There is a Linux driver for minimal 3270 operation, in restrictive modes, but this is not commonly used. 3270 terminals were full-screen buffered non-intelligent terminals, with control units and data streams to maximize efficiency of data transmission. 12 EBCDIC is a coded character set of 256 8-bit characters that was developed for the representation of textual data. EBCDIC is not compatible with ASCII character coding. For a handy conversion table, see Appendix D, “EBCDIC - ASCII table” on page 641. Chapter 1. Introduction to the New Mainframe 39
Slide 64: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am z/TPF can use multiple mainframes in a loosely-coupled environment to routinely handle tens of thousands of transactions per second, while experiencing uninterrupted availability that is measured in years. Large terminal networks, including special-protocol networks used by portions of the reservation industry, are common. 1.11 Introducing the IBM zEnterprise System Multitier workloads and their deployment on heterogeneous infrastructures are commonplace today. Creating and maintaining these high-level qualities of service from a large collection of distributed components demands significant knowledge and effort. It implies acquiring and installing extra equipment and software to ensure availability and security, monitoring, and managing. Additional manpower and skills are required to configure, administer, troubleshoot, and tune such a complex set of separate and diverse environments. Due to platform functional differences, the resulting infrastructure will not be uniform regarding those qualities of service or serviceability. IBM introduced zEnterprise System, which is the first of its kind. It was purposefully designed to help overcome fundamental problems of today's IT infrastructures and simultaneously provide a foundation for the future. The zEnterprise System brings about a revolution in the end-to-end management of diverse systems, while offering expanded and evolved traditional System z capabilities. With zEnterprise, a system of systems can be created where the virtualized resources of both the zEnterprise 196 (z196) and selected IBM blade-based servers, housed in the zEnterprise BladeCenter Extension (zBX), are pooled together and jointly managed. End-to-end solutions based on multi-platform workloads can be deployed across the zEnterprise System structure and benefit from System z’s traditional qualities of service, including high availability, and simplified and improved management of the virtualized infrastructure. Because many mission-critical workloads today have one or more components on System z, using System z environments for z/OS databases and other capabilities, the ability to co-locate all of the workload components under the same management platform and thereby benefit from uniformly high qualities of service should be quite appealing and provide tangible benefits and a rapid return on investment (ROI). 40 Introduction to the New Mainframe: z/OS Basics
Slide 65: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm For the first time it is possible to deploy an integrated hardware platform that brings mainframe and distributed technologies together, producing a system that can start to replace individual islands of computing and that can work to reduce complexity, improve security, and bring applications closer to the data they need. 1.12 Summary Today, mainframe computers play a central role in the daily operations of most of the world’s largest corporations, including many Fortune 1000 companies. Although other forms of computing are used extensively in business in various capacities, the mainframe occupies a coveted place in today’s e-business environment. In banking, finance, health care, insurance, utilities, government, and a multitude of other public and private enterprises, the mainframe computer continues to form the foundation of modern business. The New Mainframe owes much of its popularity and longevity to its inherent richness in reliability and stability, a result of continuous technological advances since the introduction of the IBM System/360 in 1964. No other computer architecture in existence can claim as much continuous, evolutionary improvement, while maintaining compatibility with existing applications. The term mainframe has gradually moved from a physical description of the IBM larger computers to the categorization of a style of computing. One defining characteristic of the mainframe has been a continuing compatibility that spans decades. The roles and responsibilities in a mainframe IT organization are wide and varied. It takes skilled staff to keep a mainframe computer running smoothly and reliably. It might seem that there are far more resources needed in a mainframe environment than for small, distributed systems. But, if roles are fully identified on the distributed systems side, a number of the same roles exist there as well. Several operating systems are currently available for mainframes. This text concentrates on one of these, z/OS. However, mainframe students should be aware of the existence of the other operating systems and understand their positions relative to z/OS. Chapter 1. Introduction to the New Mainframe 41
Slide 66: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am Table 1-1 lists the key terms used in this chapter. Table 1-1 Key terms used in this chapter architecture mainframe availability online transaction processing (OLTP) System/360 batch processing platform compatibility production control analyst e-business run book scalability system operator system programmer zEnterprise System 1.13 Questions for review To help test your understanding of the material in this chapter, perform the following tasks: 1. List ways in which the mainframe of today challenges the traditional thinking about centralized computing versus distributed computing. 2. Explain how businesses make use of mainframe processing power, and how mainframe computing differs from other types of computing. 3. List some of the factors that contribute to mainframe use. 4. List three strengths of mainframe computing, and outline the major types of workloads for which mainframes are best suited. 5. Name five jobs or responsibilities that are related to mainframe computing. 6. This chapter mentioned at least five operating systems that are used on the mainframe. Choose three of them and describe the main characteristics of each one. 1.14 Topics for further discussion 1. What is a mainframe today? How did the term arise? Is it still appropriate? 2. Why is it important to maintain system compatibility for older applications? Why not simply change existing application programming interfaces whenever improved interfaces become available? 3. Describe how running a mainframe can be cost effective, given the large number of roles needed to run a mainframe system. 42 Introduction to the New Mainframe: z/OS Basics
Slide 67: Draft Document for Review February 26, 2011 8:32 am Chap1 mainframe intro.fm 4. What characteristics, good or bad, exist in a mainframe processing environment because of the roles that are present in a mainframe shop? (Efficiency? Reliability? Scalability?) 5. Describe some similarities and differences between application development for mainframe systems compared to other systems. 6. Most mainframe shops have implemented rigorous systems management, security, and operational procedures. Have these same procedures been implemented in distributed system environments? Why or why not? 7. Can you find examples of mainframe use in your everyday experiences? Describe them and the extent to which mainframe processing is apparent to users. Examples might include the following: a. Popular websites that rely on mainframe technology as the back-end server to support online transactions and databases. b. Multitiered applications that interface with mainframe resources. c. Mainframes used in your locality. These might include banks and financial centers, major retailers, transportation hubs, and the health and medical industries. 8. Can you find examples of distributed systems in everyday use? Could any of these systems be improved through the addition of a mainframe? How? 9. How is today’s mainframe environment-friendly? Discuss with examples. Chapter 1. Introduction to the New Mainframe 43
Slide 68: Chap1 mainframe intro.fm Draft Document for Review February 26, 2011 8:32 am 10. 44 Introduction to the New Mainframe: z/OS Basics
Slide 69: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm 2 Chapter 2. Mainframe hardware systems and high availability Objective: As a new z/OS system programmer, you need to develop a thorough understanding of the hardware that runs the z/OS operating system. z/OS is designed to make full use of mainframe hardware and its many sophisticated peripheral devices. You should also understand how the hardware and software achieves near-continuous availability through concepts such as Parallel Sysplex and “no single points of failure.” After completing this chapter, you will be able to: Discuss S/360 and System z hardware design. Explain processing units and disk hardware. Explain how mainframes differ from PC systems in data encoding. List some typical hardware configurations. Describe platform performance management features. Explain how Parallel Sysplex can achieve continuous availability. Explain dynamic workload balancing. Explain the single system image. Refer to Table 2-1 on page 87 for a list of key terms used in this chapter. © Copyright IBM Corp. 2006, 2009, 2011. All rights reserved. 45
Slide 70: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am 2.1 Introduction to mainframe hardware systems This chapter provides an overview of mainframe hardware systems, with most of the emphasis on the processor “box.” For detailed descriptions of the major facilities of z/Architecture, the book z/3 Principles of Operation is the standard reference. You can find this and other IBM publications at the z/OS Internet Library website at the following address: http://www-03.ibm.com/systems/z/os/zos/bkserv/ Let us begin this chapter with a look at the terminology associated with mainframe hardware. Knowing the various meanings of the terms systems, processors, CPs, and so on, is important for your understanding of mainframe computers. CPU: Synonymous with processor. In the early S/360 days, a system had a single processor, which was also known as the central processing unit (CPU). The terms system, processor, and CPU were used interchangeably. However, these terms became confusing when systems became available with more than one processor. Today the mainframe has a rich heritage of terms, as shown in Figure 2-1. Past: • Box • CEC • CPC • CPU • Machine • Processor • Sysplex • System Present: • Processors • CPUs • Engines • PUs • CPs (IFLs, ICFs, SAPs, zAAPs, zIIPs, spares) Note: LPAR may be referred to as an “image” or “server” Figure 2-1 Terminology overlap The term box may refer to the entire machine or model; the expression refers to its shape. The abbreviation CPC is used for the Central Processor Complex that houses the central processing units (CPUs). 46 Introduction to the New Mainframe: z/OS Basics
Slide 71: Draft Document for Review February 26, 2011 8:32 am CPC: The physical collection of hardware that includes main storage, one or more central processors, timers, and channels. Chap2 hardware intro.fm Processor and CPU can refer to either the complete system box, or to one of the processors within the system box. Although the meaning may be clear from the context of a discussion, even mainframe professionals must clarify which processor or CPU meaning they are using in a discussion. System programmers use the term CPC to refer to the mainframe “box” or centralized processing hub. In this text, we use the term CPC to refer to the physical collection of hardware that includes main storage, one or more central processors, timers, and channels. Partitioning and some of the terms in Figure 2-1 on page 46 are discussed later in this chapter, although the term sysplex is an idiom made up of two words: system and complex, which suggests multiple systems. Briefly, all the S/390 or z/Architecture processors within a CPC are processing units (PUs). When IBM delivers the CPC, the PUs are characterized as CPs (for normal work), Integrated Facility for Linux (IFL), Integrated Coupling Facility (ICF) for Parallel Sysplex configurations, and so on. In this text, we hope the meanings of system and processor are clear from the context. We normally use system to indicate the hardware box, a complete hardware environment (with I/O devices), or an operating environment (with software), depending on the context. We normally use processor to mean a single processor (CP) within the CPC. In some text, you may see a logical partition (LPAR) defined as an image or server. This represents an operating system instance, such as z/OS, z/VM, or Linux. You can run several different operating systems within a single mainframe by partitioning the resources into isolated servers. The term LPAR is covered in more detail later in this chapter. 2.2 Early system design The central processor box contains the processors, memory,1 control circuits, and interfaces for channels. A channel provides an independent data and control path between I/O devices and memory. Early systems had up to 16 channels; the largest mainframe machines at the time of this writing can have over 1000 channels. A channel can be considered as a high speed data bus. Channels connect to control units. A control unit contains logic to work with a particular type of I/O device. A control unit for a printer would have much different internal circuitry and logic than a control unit for a tape drive, for example. Some control units can have multiple channel connections providing multiple paths to the control unit and its devices. 1 Some S/360s had separate boxes for memory. However, this is a conceptual discussion and we ignore such details. Chapter 2. Mainframe hardware systems and high availability 47
Slide 72: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am Today’s channel paths are dynamically attached to control units as the workload demands. This provides a form of virtualizing access to devices. We will discuss this topic later in the chapter. Control units connect to devices, such as disk drives, tape drives, communication interfaces, and so on. The division of circuitry and logic between a control unit and its devices is not defined, but it is usually more economical to place most of the circuitry in the control unit. Figure 2-2 on page 48 shows a conceptual diagram of a S/360 system. Current systems are not connected this way. However, this figure helps explain the background terminology that permeates mainframe discussions. CPUs CPUs CPUs Parallel Channels Channel Subsystem Main Storage Runs the Input/Output 1 5 6 A B Control Unit 3 Disk Devices Control Unit 2 Control Unit 1 0 1 Channels 3 2 0 3 Y 0 1 Z X Control Unit CD Communication Line 7 9 Another System Figure 2-2 Simple Conceptual S/360 The channels in Figure 2-2 are parallel channels (also known as bus and tag channels, named for the two heavy copper cables they use). A bus cable carries information (one byte each way), and a tag cable indicates the meaning of the data on the bus cable. The maximum data rate of the parallel channel is up to 4.5 MBps when in streaming mode, and the maximum distance achieved with a parallel channel interface is up to 122 meters (400 feet). Attention: Parallel channels are no longer used by the latest mainframes and are mentioned here for completeness of this topic. 48 Introduction to the New Mainframe: z/OS Basics
Slide 73: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm Each channel, control unit, and device has an address, expressed as a hexadecimal number. The disk drive marked with an X in Figure 2-2 has address 132, as shown in Figure 2-3 on page 49. Address: 1 3 2 Channel number Figure 2-3 Device address Control unit number Device number The disk drive marked with a Y in the figure can be addressed as 123, 523, or 623, because it is connected through three channels. By convention, the device is known by its lowest address (132), but all three addresses could be used by the operating system to access the disk drive. Multiple paths to a device are useful for performance and for availability. When an application wants to access disk 123, the operating system will first try channel 1. If it is busy (or not available), it will try channel 5, and so on. Figure 2-2 contains another S/360 system with two channels connected to control units used by the first system. This sharing of I/O devices is common in all mainframe installations because the mainframe is a share-everything architecture. Tape drive Z is address A11 for the first system, but is address 911 for the second system. Sharing devices, especially disk drives, is not a simple topic and there are hardware and software techniques used by the operating system to control exposures, such as updating the same disk data at the same time from two independent systems. Attention: A technique used to access a single disk drive by multiple systems is called multiple allegiance. As mentioned, current mainframes are not used exactly as shown in Figure 2-2 on page 48. Differences include: Parallel channels are not available on the newest mainframes and are slowly being displaced on older systems. They are described here for the completeness of the topic. ESCON: Enterprise Systems Connection Parallel channels have been replaced with Enterprise Systems CONnection (ESCON®) and FIber CONnection (FICON®) channels. These channels connect to only one control unit or, more likely, are connected to a director (switch) and are optical fibers. Current mainframes can have over one thousand channels and use two hexadecimal digits as the channel portion of an address. Chapter 2. Mainframe hardware systems and high availability 49
Slide 74: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am Channels are generally known as channel path identifiers (CHPIDs) or physical channel identifiers (PCHIDs) on later systems, although the term channel is also correct. The channels are all integrated in the main processor box. The device address seen by software is more correctly known as a device number (although the term address is still widely used) and is indirectly related to the control unit and device addresses. For more information about the development of the IBM mainframe since 1964, see Appendix A, “A brief look at IBM mainframe history” on page 613. 2.3 Current design Current CPC designs are considerably more complex than the early S/360 design. This complexity includes many areas: I/O connectivity and configuration I/O operation Partitioning of the system I/O channels are part of the channel subsystem (CSS). They provide connectivity for data exchange between servers, or between servers and external control units (CU) and devices, or networks. 2.3.1 I/O connectivity Figure 2-4 on page 51 shows a recent configuration. A real system would have more channels and I/O devices, but this figure illustrates key concepts. Partitions, ESCON channels, and FICON channels are described later. 50 Introduction to the New Mainframe: z/OS Basics
Slide 75: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm CEC box Partition 1 Partition 2 I/O Processing Channels (CHPIDs or PCHIDs) 01 O 02 E ... 40 E 41 E 42 E ... Other systems ... A0 F A1 F ... ... LAN 01 Control Unit ESCON Director (switch) FICON switch Control unit addresses (CUA) C0 Control Unit C1 Control Unit 01 Control Unit 02 Control Unit Unit addresses (UA) 0 1 0 1 0 1 0 1 E - ESCON channel F - FICON channel O - OSA-Express channel Figure 2-4 Recent system configuration Briefly, partitions create separate logical machines (servers) in the CPC. ESCON and FICON channels are logically similar to parallel channels, but they use fibre connections and operate much faster. A modern system might have 300 - 500 channels or CHPIDs.2 Key concepts partly illustrated here include the following: ESCON and FICON channels connect to only one device or one port on a switch. Most modern mainframes use switches between the channels and the control units. The switches are dynamically connected to several systems, sharing the control units and some or all of its I/O devices across all the systems. 2 The more recent mainframe machines can have up to a maximum of 1024 channels, but an additional setup is needed. The channels are assigned in a way that only two hexadecimal digits are needed for CHPID addresses. Chapter 2. Mainframe hardware systems and high availability 51
Slide 76: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am CHPID addresses are two composed of two hexadecimal digits. CHPID: Channel path identifier Multiple partitions can sometimes share CHPIDs. This is known as spanning. Whether this is possible depends on the nature of the channel type and control units used through the CHPIDs. In general, CHPIDs used for disks can be shared. An I/O subsystem layer exists between the operating systems in partitions (or in the basic machine if partitions are not used) and the CHPIDs. The largest machine today can support up to four Logical Channel Subsystems (LCSSs), each having a maximum of 256 channels. InfiniBand (IFB) is used as the pervasive, low-latency, and high-bandwidth interconnect that has low processing impact and is ideal for carrying multiple traffic types. Beginning with the z10, it replaces the Self Timed Interface (STI) cable. An ESCON director or FICON switch is a sophisticated device that can sustain high data rates through many connections. (A large director might have 200 connections, for example, and all of them can be passing data at the same time.) The director or switch must keep track of which CHPID (and partition) initiated which I/O operation so that data and status information is returned to the right place. Multiple I/O requests, from multiple CHPIDs attached to multiple partitions on multiple systems, can be in progress through a single control unit. The I/O control layer uses a control file known as an I/O Control Data Set (IOCDS) that translates physical I/O addresses (composed of CHPID numbers, switch port numbers, control unit addresses, and unit addresses) into device numbers that are used by the operating system software to access devices. These numbers are loaded into a special storage area called the Hardware Save Area (HSA) at power-on. The HSA is not addressable by users and is a special component of the mainframe central storage area. A device number looks like the addresses we described for early S/360 machines except that it can contain three or four hexadecimal digits. Many users still refer to these as “addresses” even though the device numbers are 16-bit (2 byte) arbitrary numbers between x'0000' and x’FFFF’. The newest mainframes, at the time of the writing of this book, have two layers of I/O address translations between the real I/O elements and the operating system software. The second layer was added to make migration to newer systems easier. Modern control units, especially for disks, often have multiple channel (or switch) connections and multiple connections to their devices. They can handle multiple data transfers at the same time on the multiple channels. Each disk device unit is represented by a unit control block (UCB) in each z/OS image. 52 Introduction to the New Mainframe: z/OS Basics
Slide 77: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm The UCB is a small piece of virtual storage describing the characteristics of a device to the operating system and contains the device address to denote status as well as tracking the progress of the I/O to the device. As an example, under certain conditions, if a disk device is busy servicing an I/O, another I/O to the same device is queued up with a “device busy” condition recorded within the UCB. Attention: There is a feature to allow multiple I/Os to execute concurrently against the same disk device without queuing. This functionality allows a device to contain more than one access path using a base address along with aliases. It is implemented through the Enterprise Storage System (ESS) using a feature called Parallel Access Volumes (PAVs). Figure 2-5 shows an overview of device addressing. External device label Four hex digits in range 0000-FFFF Assigned by the system programmer Used in JCL, commands and messages FF00 6830 6831 6832 6833 683F HSA LPAR B Central Storage LPAR A Central Storage UCB 2001 UCB 2000 UCB 183F FF03 C40 2000 2001 2002 FF01 2003 2004 2005 2006 FF02 2007 2008 2009 200A 200B 200C 200D 200E 200F V 200A,ONLINE IEE302I 200A ONLINE V 200B,ONLINE Figure 2-5 Device addressing Chapter 2. Mainframe hardware systems and high availability 53
Slide 78: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am 2.3.2 System control and partitioning There are many ways to illustrate a mainframe’s internal structure, depending on what we want to emphasize. Figure 2-6 on page 54, while highly conceptual, shows several of the functions of the internal system controls on current mainframes. The internal controllers are microprocessors, but use a much simpler organization and instruction set than mainframe processors. They are usually known as controllers to avoid confusion with mainframe processors. Specialized microprocessors for internal control functions LPAR1 LPAR2 LPAR3 Memory System Control HMC SE CP CP CP CP Processors PC ThinkPads System Control Located in operator area Located inside CEC but can be used by operators Channels CHPID CHPID CHPID CHPID CHPID CHPID CHPID Figure 2-6 System control and partitioning The IBM mainframe can be partitioned into separate logical computing systems. System resources (memory, processors, and I/O devices) can be divided or shared among many such independent logical partitions (LPARs) under the control of the LPAR hypervisor, which comes with the standard Processor Resource/ Systems Manager (PR/SM) feature on all mainframes. The hypervisor is a software layer to manage multiple operating systems running in a single central processing complex. The mainframe uses a Type 1 hypervisor. Each LPAR supports an independent operating system (OS) loaded by a separate initial program load (IPL) operation. 54 Introduction to the New Mainframe: z/OS Basics
Slide 79: Draft Document for Review February 26, 2011 8:32 am Logical partition: A subset of the processor hardware that is defined to support an operating system. Chap2 hardware intro.fm For many years, there was a limit of 15 LPARs in a mainframe; today’s machines can be configured with up to 60 logical partitions. Practical limitations of memory size, I/O availability, and available processing power usually limit the number of LPARs to less than these maximums. Each LPAR is considered an isolated and distinct server that supports an instance of an operating system (OS). The operating system can be any version or release supported by the hardware. In essence, a single mainframe can support the operation of several different OS environments, as shown in Figure 2-7 on page 55. Attention: A Type 1 (or native) hypervisor is software that runs directly on a given hardware platform (as an operating system control program). A Type 2 (or hosted) hypervisor is software that runs within an operating system environment such as VMWare. PR/SM CPUs Storage Channels LPAR1 LPAR2 LPAR3 LPARn LPARn LPARn z/OS V1.8 z/VM V5.2 Linux V4.4 Up to 60 LPARs *** z/OS V1.9 z/OS V1.7 Linux V4.3 Figure 2-7 Logical partitions System administrators assign portions of memory to each LPAR; memory also known as central storage (CSTOR) cannot be shared among LPARs. CSTOR, which in the past was also referred to as main storage, provides the system with directly addressable, fast-access electronic storage of data. Both data and programs must be loaded into central storage (from input devices) before they can be processed by the CPU. The maximum central storage size is restricted by hardware and system architecture. Chapter 2. Mainframe hardware systems and high availability 55
Slide 80: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am Attention: Prior to the current storage addressing scheme (64-bit), z/OS used another form of storage called Expanded Storage (ESTOR). This form of electronic storage is addressable in 4 KB blocks. Expanded storage was originally intended to bridge the gap in cost and density between main storage and auxiliary media by serving as a high-speed backing store for paging and for large data buffers. It is mentioned here for completeness because other operating systems on the mainframe still use this form of storage. The system administrators can assign dedicated processors (noted as CPs in Figure 2-6 on page 54) to specific LPARs or they can allow the system to share and dispatch any or all the processors to the LPARs using an internal load-balancing algorithm. Channels serve as a communication path from the mainframe to an external device such as disk or tape. I/O devices are attached to the channel subsystem through control units. The connection between the channel subsystem and a control unit is called a channel path. Channels Path Identifiers (CHPIDs) are assigned to specific LPARs or can be shared by multiple LPARs, depending on the nature of the devices on each channel. A mainframe with a single processor (CP processor) can serve multiple LPARs. PR/SM has an internal dispatcher (Hipervisor) that can allocate a portion of the processor to each LPAR, much as an operating system dispatcher allocates a portion of its processor time to each process, thread, or task. An LPAR can be assigned a dedicated processor or dedicated several processors. Alternatively, an LPAR can share processors with other LPARS. The latter is the configuration norm. Partitioning control specifications are, in part, contained in an input/output control data set (IOCDS) and are partly contained in a system profile. The IOCDS and profile both reside in the Support Element (SE), which is simply a mobile computer inside the system. The SE can be connected to one or more Hardware Management Consoles (HMCs), which are desktop personal computers used to HMC: A console used monitor and control hardware, such as the mainframe microprocessors. An HMC to monitor and is more convenient to use than an SE and can control several different control hardware, mainframes. such as the mainframe microprocessors. Working from an HMC, an operator prepares a mainframe for use by selecting and loading a profile and an IOCDS. These create LPARs and configure the channels with device numbers, LPAR assignments, multiple path information, and so on. This is known as a Power-on Reset (POR). By loading a different profile and IOCDS, the operator can completely change the number and design of LPARs and the appearance of the I/O configuration. In some circumstances, this can be nondisruptive to running operating systems and applications. 56 Introduction to the New Mainframe: z/OS Basics
Slide 81: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm 2.3.3 Characteristics of LPARs Logical partitions are, in practice, equivalent to separate mainframes. Each LPAR runs its own operating system (OS). This OS can be any mainframe operating system; there is no need to run z/OS, for example, in each LPAR. The installation planners may elect to share I/O devices across several LPARs, but this is a local decision. The system administrator can assign one or more system processors for the exclusive use of an LPAR. Alternately, the administrator can allow all processors to be used on some or all LPARs. Here, the system control functions (often known as microcode or firmware) provide a dispatcher to share the processors among the selected LPARs. The administrator can specify a maximum number of concurrent processors executing in each LPAR. The administrator can also provide weightings for different LPARs, for example, specifying that LPAR1 should receive twice as much processor time as LPAR2. The operating system in each LPAR is performs an IPL separately, has its own copy3 of its operating system, has its own operator console (if needed), and so on. If the system in one LPAR fails or is taken down for maintenance, it has no effect on the other LPARs. In Figure 2-7 on page 55, for example, we might be running a production z/OS in LPAR1, a test version of z/VM in LPAR2, and Linux on System z in LPAR3. If our total system has 8 GB of memory, we might assign 4 GB to LPAR1, 1 GB to LPAR2, 1 GB to LPAR3, and keep 2 GB in reserve for future use. The operating system consoles for the two z/OS LPARs might be in completely different locations.4 There is no practical difference between, for example, three separate mainframes running z/OS (and sharing most of their I/O configuration) and three LPARs on the same mainframe doing the same thing. In general, neither z/OS, the operators, or the applications, can detect the difference. Minor differences include the ability of z/OS (if permitted when the LPARs were defined) to obtain performance and utilization information across the complete mainframe system and to dynamically shift resources (processors and channels) among LPARs to improve performance. Note: There is an implementation using a SYStem comPLEX (SYSPLEX) where LPARs can communicate and collaborate sharing resources. 3 4 Most, but not all, of the z/OS system libraries can be shared. Linux does not have an operator console in the sense of the z/OS consoles. Chapter 2. Mainframe hardware systems and high availability 57
Slide 82: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am 2.3.4 Consolidation of mainframes There are fewer mainframes in use today than there were 20 years ago because of corporate mergers and data center consolidations. In some cases, applications were moved to other types of systems, because there is no such thing as a “one size fits all” solution. However, in most cases the reduced number is due to consolidation, that is, several smaller mainframes have been replaced with a fewer but larger systems. Today’s mainframe is considerably more powerful than past generations. An additional reason for consolidation is that mainframe software (from many vendors) can be expensive, often costing more than the mainframe hardware. It is usually less expensive to replace multiple software licenses for smaller machines with one or two licenses for larger machines. Software license costs are often linked to the power of the system, yet the pricing curves favor a small number of large machines. Software license costs for mainframes have become a dominant factor in the growth and direction of the mainframe industry. There are several factors that make software pricing difficult. We must remember that mainframe software is not a mass market item like PC software. The growth of mainframe processing power in recent years has been exponential rather than linear. The relative power needed to run a traditional mainframe application (a batch job written in COBOL, for example) is far less than the power needed for a new application (with a GUI interface, written in C and Java). The consolidation effect has produced powerful mainframes, which might need only 1% of their power to run an older application, but the application vendor often sets a price based on the total power of the machine, even for older applications. As an aid to consolidation, the mainframe offers software virtualization, through z/VM. z/VM’s extreme virtualization capabilities, which have been perfected since its introduction in 1967, make it possible to virtualize thousands of distributed servers on a single server, resulting in the significant reduction in the use of space and energy. Mainframes require fewer staff when supporting hundreds of applications. Because centralized computing is a major theme when using the mainframe, many of the configuration and support tasks are implemented by writing rules or creating a policy that manages the infrastructure automatically. This is a tremendous savings in time, resources, and cost. 58 Introduction to the New Mainframe: z/OS Basics
Slide 83: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm 2.4 Processing units Figure 2-1 on page 46 lists several different types of processors in a system. z/Architecture: These are all z/Architecture processors that can be used for different workload characterization purposes.5 Several of these purposes are related to software An IBM architecture for cost control, while others are more fundamental. mainframe computers and peripherals. The System z family of servers uses this architecture. All these start as equivalent processor units6 (PUs) or engines. A PU is a processor that has not been characterized for use. Each of the processors begins as a PU and is characterized by IBM during installation or at a later time. The potential characterizations are: Central Processor (CP) This is a processor available to the general operating system and application software. System Assistance Processor (SAP) Every modern mainframe has at least one SAP; larger systems may have several. The SAPs execute internal code7 to drive the I/O subsystem. A SAP, for example, translates device numbers and real addresses of CHPIDs, control unit addresses, and device numbers. It manages and schedules an I/O by selecting an available path to control units. It also has a supplementary role during error recovery. Operating systems and applications cannot detect SAPs, and SAPs do not use any “normal” memory. SAPs are considered co-processors or input /output processors (IOP) because you cannot perform an IPL from this engine type. Integrated Facility for Linux (IFL) This is a processor used exclusively by a Linux LPAR or Linux running under z/VM. An IPL of the LPAR performed only to run either operating environment. This processor type is accompanied with special user licensing incentives. Because these incentives reduce cost, they are not counted towards the overall capacity of the machine.8 This can make a substantial difference in software costs. Note: A Linux LPAR can use general central processors, but licensing incentives do not apply. 5 Do not confuse these processors with the controller microprocessors. The processors discussed in this section are full, standard mainframe processors. 6 This discussion applies to the current System z machines at the time of the writing of this book. Earlier systems had fewer processor characterizations, and even earlier systems did not use these techniques. 7 IBM refers to this as Licensed Internal Code (LIC). It is often known as microcode (which is not technically correct) or as firmware. It is not user code. 8 Some systems do not have different models; in this case, a capacity model number is used. Chapter 2. Mainframe hardware systems and high availability 59
Slide 84: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am z/OS Application Assist Processor (zAAP) The z/OS Application Assist Processor (zAAP) provides for license incentives that allow you to run Java applications at a reduced cost. You can integrate and run e-business Java workloads on the same LPAR as your database, helping to simplify and reduce the infrastructure required for web applications. zAAP runs with general CPs in a z/OS LPAR. When Java code is detected, z/OS switches that instruction set to the zAAP processor, freeing up the general CP to perform other, non-Java work. This potentially offers a means to provide greater throughput. The zAAP engine is not counted towards the capacity of the model machine. With later versions of z/OS, all XML System Services validation and parsing that execute in TCB mode (which is problem state mode, as in most application workloads) might be eligible for zAAP processing, meaning that middleware and applications requesting z/OS XML System Services can have z/OS XML System Services processing execute on the zAAP. z/OS Integrated Information Processor (zIIP) The z/OS Integrated Information Processor (zIIP) provides for license incentives allowing you to optimize certain database workload functions at a reduced cost, such as business intelligence (BI), enterprise resource planning (ERP), and customer relationship management (CRM). When certain database code is detected, z/OS switches that instruction set to the zIIP processor, freeing up the general CP to perform other work. The zIIP runs with general CPs in a z/OS LPAR and is not counted towards the capacity of a machine model. z/OS Communications Server uses the zIIP for eligible IPSec network encryption workloads as well as XML System Services that are enabled to take additional advantage of the zIIP for preemptable SRB eligible XML workloads. Attention: Specialty engines may be used further as new releases of z/OS are announced. Integrated Coupling Facility (ICF) This Integrated Coupling Facility processor exclusively uses the Coupling Facility Control Code (CFCC) and License Internal Code (LIC). A coupling facility is, in effect, a large memory scratch pad used by multiple systems to coordinate work by sharing resources between LPARs or used for workload balancing when configured for a Parallel Sysplex. ICFs must be assigned to separate LPARs that then become coupling facilities. The ICF are not visible to normal operating systems or applications. 60 Introduction to the New Mainframe: z/OS Basics
Slide 85: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm Spare An uncharacterized PU functions as a “spare.” If the system controllers detect a failing CP or SAP, it can be replaced with a spare PU. In most cases, this can be done without any system interruption, even for the application running on the failing processor. Various forms of Capacity on Demand (CoD) and similar arrangements exist whereby a customer can enable additional CPs at certain times (for example, unexpected peak loads or year end processing requirements). 2.4.1 Subcapacity processors Some mainframes have models that can be configured to operate slower than the potential speed of their CPs. This is widely known as running subcapacity; IBM uses the term capacity setting. Subcapacity processors allow customers to choose a server size to best meet business requirements. Smaller incremental steps between capacity settings can allow customers to manage their growth, and their costs, in smaller increments. This task is accomplished by using microcode to insert null cycles into the processor instruction stream. The purpose, again, is to control software costs by having the minimum mainframe model that meets the application requirements. Specialty engines such as IFLs, SAPs, zAAPs, zIIPs, and ICFs are not eligible for this feature and always function at the full speed of the processor because these processors “do not count” in software pricing calculations.9 2.5 Multiprocessors All the earlier discussions and examples assume that more than one processor (CP) is present in a system (and perhaps in an LPAR). It is possible to purchase a current mainframe with a single processor (CP), but this is not a typical 10 Multiprocessor: system. The term multiprocessor means several processors (CP processors) A CPC that can be and implies that several processors are used by a copy of z/OS. The term also physically refers to the ability of a system to support more than one processor and the partitioned to form ability to allocate tasks between them. two operating processor. complexes. All operating systems today, from PCs to mainframes, can work in a multiprocessor environment. However, the degree of integration of the multiple processors varies considerably. For example, pending interrupts in a system (or This is true for IBM software but may not be true for all software vendors. All current IBM mainframes also require at least one SAP, so the minimum system has two processors: one CP and one SAP. However, the use of “processor” in the text usually means a CP processor usable for applications. Whenever discussing a processor other than a CP, we always make this clear. 10 9 Chapter 2. Mainframe hardware systems and high availability 61
Slide 86: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am in an LPAR) can be accepted by any processor in the system (or working in the LPAR). Any processor can initiate and manage I/O operations to any channel or device available to the system or LPAR. Channels, I/O devices, interrupts, and memory are owned by the system (or by the LPAR) and not by any specific processor. This multiprocessor integration appears simple on the surface, but its implementation is complex. For maximum performance, the ability of any processor to accept any interrupt sent to the system (or to the LPAR) is especially important. Each processor in a system (or in an LPAR) has a small private area of memory (8 KB starting at real address 0 and always mapped to virtual address 0) that is unique to that processor. This is the Prefix Storage Area (PSA) and it is used for instruction execution, interrupts, and error handling. A processor can access another processor’s PSA through special programming, although this is normally done only for error recovery purposes. A processor can interrupt other processors by using a special instruction (SIGP, for Signal Processor). Again, this is typically used only for error recovery. 2.6 Disk devices IBM 3390 disk drives are commonly used on current mainframes. Conceptually, this is a simple arrangement, as shown in Figure 2-8. IBM 3390 Disk Unit IBM 3990 Control Unit Channels Figure 2-8 Initial IBM 3390 disk implementation 62 Introduction to the New Mainframe: z/OS Basics
Slide 87: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm The associated control unit (3990) typically has up to four Fibre Channel connections connected to one or more processors (probably with a switch), and the 3390 unit typically has eight or more disk drives. Each disk drive has the characteristics explained earlier. This illustration shows 3990 and 3390 units, and it also represents the concept or architecture of current devices. The current equivalent device is an IBM 2105 Enterprise Storage Server®, which is shown in Figure 2-9 on page 63. Host Adapters (2 channel interfaces per adapter) HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA Common Interconnect (across clusters) Cluster Processor Complex Cache DA DA DA NVS DA Cluster Processor Complex Cache DA DA DA NVS DA RAID array RAID array Device Adapters Figure 2-9 Current 3390 implementation IBM has a wide range of product offerings that are based on open standards and that share a common set of tools, interfaces, and innovative features. The IBM TotalStorage DS family and its member, the DS8000, gives customers the freedom to choose the right combination of solutions for their current needs and the flexibility for the infrastructure to evolve as their needs change. The TotalStorage DS family is designed to offer high availability and multi-platform support, which helps cost-effectively adjust to an evolving business world. The 2105 unit is a sophisticated device. It emulates a large number of control units and 3390 disk drives. It contains up to 11 TB of disk space, has up to 32 channel interfaces, 16 GB cache, and 284 MB of non-volatile memory (used for write queuing). The Host Adapters appear as control unit interfaces and can connect up to 32 channels (ESCON or FICON). Chapter 2. Mainframe hardware systems and high availability 63
Slide 88: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am The physical disk drives are commodity SCSI-type units (although a serial interface, known as SSA, is used to provide faster and redundant access to the disks). A number of internal arrangements are possible, but the most common involves many RAID 5 arrays with hot spares. Practically everything in the unit has a spare or fallback unit. The internal processing (to emulate 3990 control units and 3390 disks) is provided by four high-end RISC processors in two processor complexes; each complex can operate the total system. Internal batteries preserve transient data during short power failures. A separate console is used to configure and manage the unit. The 2105 offers many functions not available in real 3390 units, including FlashCopy®, Extended Remote Copy, Concurrent Copy, Parallel Access Volumes, Multiple Allegiance, a huge cache, and so on. A simple 3390 disk drive (with control unit) has different technology from the 2105 just described. However, the basic architectural appearance to software is the same. This allows applications and system software written for 3390 disk drives to use the newer technology with no revisions.11 There have been several stages of new technology implementing 3390 disk drives; the 2105 is the most recent of these. The process of implementing an architectural standard (in this case, the 3390 disk drive and associated control unit) with newer and different technology while maintaining software compatibility is characteristic of mainframe development. As we mentioned, maintaining application compatibility over long periods of technology change is an important characteristic of mainframes. 2.7 Clustering Clustering has been done on mainframes since the early S/360 days, although the term cluster is seldom used in terms of mainframes. A clustering technique can be as simple as a shared DASD configuration where manual control or planning is needed to prevent unwanted data overlap. Additional clustering techniques have been added over the years. In the following sections, we discuss three levels of clustering: Basic Shared DASD CTC rings Parallel Sysplex. 11 Some software enhancements are needed to use some of the new functions, but these are compatible extensions at the operating system level and do not affect application programs. 64 Introduction to the New Mainframe: z/OS Basics
Slide 89: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm Most z/OS installations today use one or more of these levels; a single z/OS installation is relatively rare. In this discussion, we use the term “image”. A z/OS server (with one or more processors) is a z/OS image. A z/OS image might exist on a mainframe (with other LPARs), or it might run under z/VM (a hypervisor operating system mentioned in 1.10, “z/OS and other mainframe operating systems” on page 37). A system with six LPARs, each a separate z/OS system, has six z/OS images. 2.8 Basic shared DASD A basic shared DASD environment is shown in Figure 2-10 on page 65. The figure shows z/OS images, but these could be any earlier version of the operating system. This could be two LPARs in the same system or two separate systems; there is absolutely no difference in the concept or operation. Mainframe LPAR z/OS Channels Mainframe LPAR z/OS Channels stra Illu tion Control Unit Control Unit Figure 2-10 Basic shared DASD The capabilities of a basic shared DASD system are limited. The operating systems automatically issue RESERVE and RELEASE commands to a DASD before updating the volume table of contents (VTOC) or catalog. (As we discuss in Chapter 5, “Working with data sets” on page 201, the VTOC and catalog are structures that contain metadata for the DASD, indicating where various data sets reside.) The RESERVE command limits access to the entire DASD to the system issuing the command, and this lasts until a RELEASE command is issued. These commands work well for limited periods (such as updating metadata). Applications can also issue RESERVE/RELEASE commands to protect their data sets for the duration of the application. This is not automatically done in this environment and is seldom done in practice because it would lock out other systems’ access to the DASD for too long. Chapter 2. Mainframe hardware systems and high availability 65
Slide 90: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am A basic shared DASD system is typically used where the operations staff controls which jobs go to which system and ensures that there is no conflict, such as both systems trying to update the same data at the same time. Despite this limitation, a basic shared DASD environment is useful for testing, recovery, and careful load balancing. Other types of devices or control units can be attached to both systems. For example, a tape control unit, with multiple tape drives, can be attached to both systems. In this configuration, the operators can then allocate individual tape drives to the systems as needed. 2.8.1 CTC rings The channel-to-channel (CTC) function simulates an input/output (I/O) device that can be used by one system control program (SCP) to communicate with another SCP. It provides the data path and synchronization for data transfer. When the CTC option is used to connect two channels that are associated with different systems, a loosely coupled multiprocessing system is established. The CTC connection, as viewed by either of the channels to which it connects, has the appearance of an unshared input/output (I/O) device. Figure 2-11 shows the next level of clustering. This level has the same shared DASD as discussed previously, but also has two channel-to-channel (CTC) connections between the systems. This is known as a CTC ring. (The ring aspect is more obvious when more than two systems are involved.) Mainframe LPAR z/OS Channels CTC Mainframe LPAR z/OS Channels CTC Control Unit Control Unit Can have more systems in the CTC ring Figure 2-11 Basic sysplex 66 Introduction to the New Mainframe: z/OS Basics
Slide 91: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm z/OS can use the CTC ring to pass control information among all systems in the ring. The information that can be passed this way includes: Usage and locking information for data sets on disks. This allows the system to automatically prevent unwanted duplicate access to data sets. This locking is based on JCL specifications provided for jobs sent to the system, as explained in Chapter 6, “Using JCL and SDSF” on page 239. Job queue information, such that all the systems in the ring can accept jobs from a single input queue. Likewise, all systems can send printed output to a single output queue. Security controls that allow uniform security decisions across all systems. Disk metadata controls, so that RESERVE and RELEASE disk commands are not necessary. To a large extent, batch jobs and interactive users can run on any system in this configuration because all disk data sets can be accessed from any z/OS image. Jobs (and interactive users) can be assigned to whichever system is most lightly loaded at the time. When the CTC configurations were first used, the basic control information shared was locking information. As we discuss in 3.7.5, “Serializing the use of resources” on page 140, the z/OS component performing this function is called the global resource serialization (GRS) function; this configuration is called a GRS ring. The primary limitation of a GRS ring is the latency involved in sending messages around the ring. CTC connection: A connection between two CHPIDs on the same or different processors, either directly or through a switch. A different CTC configuration was used before the ring technique was developed. This required two CTC connections from every system to every other system in the configuration. When more than two or three systems were involved, this became complex and required a considerable number of channels. The earlier CTC configurations (every-system-to-every-system or a ring configuration) were later developed into a basic sysplex configuration, which includes control data sets on the shared DASD. These data sets are used for consistent operational specifications for all systems and to retain information over system restarts. Configurations with shared DASD, CTC connections, and shared job queues are known as loosely coupled systems. (Multiprocessors, where several processors are used by the operating system, are sometimes contrasted as tightly coupled systems, but this terminology is seldom used. These are also known as Symmetrical MultiProcessors (SMPs); the SMP terminology is common with RISC systems, but is not normally used for mainframes.) Chapter 2. Mainframe hardware systems and high availability 67
Slide 92: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am 2.9 What is a sysplex A systems complex, commonly called a sysplex, is one or more (up to 32 LPARs) z/OS images joined into a cooperative single unit using specialized hardware and software. It uses unique messaging services and can share special file structures contained within couple facility (CF) data sets. A sysplex is an instance of a computer system running on one or more physical partitions where each can run a different release of a z/OS operating system. Sysplexes are often isolated to a single system, but Parallel Sysplex technology allows multiple mainframes to act as one. It is a clustering technology that can provide near-continuous availability. A conventional large computer system also uses hardware and software products that cooperate to process work. A major difference between a sysplex and a conventional large computer system is the improved growth potential and level of availability in a sysplex. A sysplex generally provides for resource sharing between communicating systems (tape, consoles, catalogues, and so on). The sysplex increases the number of processing units and z/OS operating systems that can cooperate, which in turn increases the amount of work that can be processed. To facilitate this cooperation, new products were developed and past products were enhanced. 2.9.1 Parallel Sysplex Parallel Sysplex: A sysplex that uses one or more coupling facilities. A Parallel Sysplex is a symmetric sysplex using multisystem data-sharing technology. This is the mainframe’s clustering technology. It allows direct, concurrent read/write access to shared data from all processing servers in the configuration without impacting performance or data integrity. Each LPAR can concurrently cache shared data in the CF processor memory through hardware-assisted, cluster-wide serialization and coherency controls. As a result, when applications are “enabled” for this implementation, the complete benefits of the Parallel Sysplex technology are made available. Work requests that are associated with a single workload, such as business transactions or database queries, can: Dynamically be balanced across systems with high performance Improve availability for both planned and unplanned outages Provide for system or application rolling maintenance Offer scalable workload growth both vertically and horizontally View multiple-system environments as a single logical resource 68 Introduction to the New Mainframe: z/OS Basics
Slide 93: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm An important design aspect of a Parallel Sysplex is synchronizing the TOD clocks of multiple servers, which allows events occurring on different servers to be properly sequenced in time. As an example, when multiple servers update the same database and database reconstruction is necessary, all updates are required to be time stamped in proper sequence. In the past, a separate device known as the Sysplex Timer was required to keep the TOD clocks of all participating servers synchronized with each other to within a small number of microseconds. It was dictated by the fastest possible passing of data from one server to another through the Coupling Facility (CF) structure. Today's implementation uses the Server Time Protocol (STP), which is a server-wide facility that is implemented in the Licensed Internal Code (LIC). STP presents a single view of time to Processor Resource/Systems Manager™ (PR/SM™), and is designed to provide the capability for multiple mainframe servers to maintain time synchronization with each other. It is the follow-up to the Sysplex Timer. The Sysplex Timer distributes time to multiple servers in a star pattern, that is, the Sysplex Timer is the star, and its time signals distribute out from it to all attached servers. The signals from the Sysplex Timer are used to increment or step the TOD clocks in the attached server. Unlike the Sysplex Timer, STP passes time messages in layers, or strata. The top layer (Stratum 1) distributes time messages to the layer immediately below it (Stratum 2). Stratum 2 in turn distributes time messages to Stratum 3 and so on. In a timing network based on STP, a stratum is used as a means to define the hierarchy of a server in the timing network. A Stratum 1 server is the highest level in the hierarchy in the STP network. Chapter 2. Mainframe hardware systems and high availability 69
Slide 94: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am Figure 2-12 on page 70 shows the hardware components of a Parallel Sysplex that make up the key aspects in its architecture. It includes several system files or data sets placed on direct access storage devices (DASD). ETS HMC Mainframe Preferred Time Server Stratum 1 Mainframe Backup Time Server Stratum 2 DASD P1 Mainframe Stratum 2 P2 Mainframe (Business Class) Arbiter Stratum 2 Coupling facility: A special logical partition that provides high-speed caching, list processing, and locking functions in a sysplex. P3 Represents Coupling Facility P4 Figure 2-12 Sysplex hardware overview 2.9.2 What is a Coupling Facility A Parallel Sysplex relies on one or more coupling facilities (CFs). A coupling facility enables high performance multisystem data sharing. The CF contains one or more mainframe processors and a special licensed built-in operating system. 70 Introduction to the New Mainframe: z/OS Basics
Slide 95: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm A CF functions largely as a fast scratch pad. It is used for three purposes: Locking information that is shared among all attached systems Cache information (such as for a data base) that is shared among all attached systems Data list information that is shared among all attached systems z/OS applications on different LPARs often need to access the same information, sometimes to read it and other times to update it. Sometimes several copies of the data exist and with that comes the requirement of keeping all the copies identical. If the system fails, customers need a way to preserve the data with the most recent changes. Linking a number of images together brings with it special considerations, such as how the servers communicate and how they cooperate to share resources. These considerations affect the overall operation of z/OS systems. Implementing a sysplex significantly changes the way z/OS systems share data. As the number of systems increase, it is essential to have an efficient means to share data across systems. The coupling facility enables centrally accessible, high performance data sharing for authorized applications, such as subsystems and z/OS components, that are running in a sysplex. These subsystems and components then transparently extend the benefits of data sharing to their applications. Use of the Coupling Facility (CF) significantly improves the viability of connecting many z/OS systems together in a sysplex to process work in parallel. Data validity is controlled by a data management system such as IMS or DB2. Within a single z/OS system, the data management system keeps track of which piece of data is being accessed or changed by which application in the system. It is the data management system’s responsibility to capture and preserve the most recent changes to the data, in case of system failure. When two or more z/OS systems share data, each system contains its own copy of a data management system. Communication between the data management systems is essential. Therefore, multisystem data sharing centers on high performance communication to ensure data validity among multiple data management systems requiring high speed data accessing methods implemented through the Coupling Facility feature. The information in the CF resides in memory and a CF typically has a large memory. A CF can be a separate system or an LPAR can be used as a CF. Chapter 2. Mainframe hardware systems and high availability 71
Slide 96: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am Figure 2-13 on page 72 shows a small Parallel Sysplex with two z/OS images. Again, this whole configuration could be in three LPARs on a single system, in three separate systems, or in a mixed combination. Separate machine or LPAR Coupling Facility CF Channels LPAR z/OS Channels LPAR z/OS Channels CTC CTC Control Unit Control Unit Figure 2-13 Parallel Sysplex In many ways, a Parallel Sysplex system appears as a single large system. It has a single operator interface (that controls all systems). With proper planning and operation, complex workloads can be shared by any or all systems in the Parallel Sysplex, and recovery (by another system in the Parallel Sysplex) can be automatic for many workloads. Note: The Coupling Facility is usually illustrated as a triangle in the diagrams used in IBM publications. 2.9.3 Clustering technologies for the mainframe Parallel Sysplex technology helps ensure continuous availability in today’s large systems environments. A Parallel Sysplex allows the linking up to 32 servers with near linear scalability to create a powerful commercial processing clustered system. Every server in a Parallel Sysplex cluster can be configured to share access to data resources, and a “cloned” instance of an application might run on every server. 72 Introduction to the New Mainframe: z/OS Basics
Slide 97: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm Parallel Sysplex design characteristics help businesses run continuously, even during periods of dramatic change. Sysplex sites can dynamically add and change systems in a sysplex, and configure the systems for no single points of failure. Through this state-of-the-art cluster technology, multiple z/OS systems can be made to work in concert to more efficiently process the largest commercial workloads. Shared data clustering Parallel Sysplex technology extends the strengths of IBM mainframe computers by linking up to 32 servers with near linear scalability to create a powerful commercial processing clustered system. Every server in a Parallel Sysplex cluster has access to all data resources, and every “cloned” application can run on every server. Using mainframe coupling technology, Parallel Sysplex technology provides a “shared data” clustering technique that permits multi-system data sharing with high performance read/write integrity. This “shared data” (as opposed to “shared nothing”) approach enables workloads to be dynamically balanced across servers in the Parallel Sysplex cluster. It enables critical business applications to take advantage of the aggregate capacity of multiple servers to help ensure maximum system throughput and performance during peak processing periods. In the event of a hardware or software outage, either planned or unplanned, workloads can be dynamically redirected to available servers, thus providing near-continuous application availability. Nondisruptive maintenance Another unique advantage of using Parallel Sysplex technology is the ability to perform hardware and software maintenance and installation in a nondisruptive manner. Through data sharing and dynamic workload management, servers can be dynamically removed from or added to the cluster, allowing installation and maintenance activities to be performed while the remaining systems continue to process work. Furthermore, by adhering to the IBM software and hardware coexistence policy, software and hardware upgrades can be introduced one system at a time. This capability allows customers to roll changes through systems at a pace that makes sense for their business. The ability to perform rolling hardware and software maintenance in a nondisruptive manner allows businesses to implement critical business functions and react to rapid growth without affecting customer availability. Chapter 2. Mainframe hardware systems and high availability 73
Slide 98: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am 2.10 Intelligent Resource Director Intelligent Resource Director can be viewed as Stage 2 of Parallel Sysplex. Stage 1 provides facilities to let you share your data and workload across multiple system images. As a result, applications that support data sharing could potentially run on any system in the sysplex, thus allowing you to move your workload to where the processing resources were available. However, not all applications support data sharing, and there are many applications that have not been migrated to data sharing for various reasons. For these applications, IBM has provided Intelligent Resource Director, which gives you the ability to move the resource to where the workload is. Intelligent Resource Director uses facilities in z/OS Workload Manager (WLM), Parallel Sysplex, and PR/SM to help you derive greater value from your mainframe investment. Compared to other platforms, z/OS with WLM already provides benefits, such as the ability to drive a processor at 100% while still providing acceptable response times for your critical applications. Intelligent Resource Director amplifies this advantage by helping you make sure that all those resources are being used by the right workloads, even if the workloads exist in different logical partitions (LPARs). Intelligent Resource Director is not actually a product or a system component; rather, it is three separate but mutually supportive functions: WLM LPAR CPU Management This function provides the means to modify an LPAR weight to a higher value to move logical CPUs to an LPAR that is missing its service level goal. Dynamic Channel-path Management (DCM) Dynamic Channel-path Management is designed to dynamically adjust the channel configuration in response to shifting workload patterns. DCM is implemented by exploiting functions in software components, such as WLM, I/O, and hardware configuration. This supports DASD controller to have the system automatically manage the number of I/O paths available to disk devices. Channel Subsystem I/O Priority Queueing (CSS IOPQ) z/OS uses this function to dynamically manage the channel subsystem priority of I/O operations for given workloads based on the performance goals for these workloads as specified in the WLM policy. The Channel Subsystem I/O Priority Queueing works at the channel subsystem level, and affects every I/O request (for every device, from every LPAR) on the CPC. 74 Introduction to the New Mainframe: z/OS Basics
Slide 99: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm Note: I/O prioritization occurs in a microcode queue within the System Assist Processor (SAP). 2.11 Platform Performance Management with zEnterprise A key strength of the mainframe is its ability to run multiple workloads concurrently across multiple system images, and you learn how to manage those workloads according to performance goals that you set. With the IBM zEnterprise System (zEnterprise) mainframe, this concept is extended to include performance management capability for both traditional System z and the IBM zEnterprise BladeCenter Extension (zBX) hardware environments. For multitier applications that span System z hardware and zBX hardware, this extended capability enables dynamic adjustments to CPU allocations to ensure that those applications are provided with sufficient resources. To manage work on these attached platforms (known as an ensemble), you classify the workload running into service classes and set its level of importance by defining goals for it that express the expectation of how the work should perform using performance policies. Attention: An ensemble is a collection of one or more zEnterprise nodes (including any attached zBX) that are managed as a single logical virtualized system by the zManager, through the use of a Hardware Management Console. The IBM zEnterprise Unified Resource Manager (zManager) uses these policy definitions to manage the resources for each workload in an ensemble. In contrast, for z/OS workload management (WLM), which you will read about in Chapter 3, “z/OS overview” on page 91, a workload is a customer-defined collection of work to be tracked, managed, and reported as a unit. So for z/OS workload management, a workload is not an amount of work, but rather a type of work that is meaningful to customers. Customers use business goals or functions to define z/OS WLM workloads, for example, a z/OS WLM workload might represent all the work started by a particular business application, or all the work created by one company group, such as sales or software development, or all the work processed by a subsystem, such as DB2 for z/OS. Chapter 2. Mainframe hardware systems and high availability 75
Slide 100: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am The Unified Resource Manager performance policies do not replace the z/OS WLM policy. The performance monitoring and management done by the zManager performance management function is at a different scope than z/OS WLM and the policies are separate. The major performance management functions of zManager are: The ability to define Platform Workloads, which is a grouping of the virtual servers (AIX partitions on POWER blades, z/VM virtual machines, and PR/SM LPARs) that support business applications. Consider a three-tiered application with a web server running on a POWER blade, IBM WebSphere Application Server running in a Linux on System z z/VM guest, and DB2 in a z/OS partition. The workload would be the three virtual servers. The ability to define a performance policy for a Platform Workload that is used to monitor and manage the virtual servers in that Platform Workload. This performance policy allows goal-oriented performance objectives and workload importance to be set for the virtual servers in the Platform Workload. Provide performance monitoring in the context of the Platform Workload. This monitoring indicates whether the virtual servers in the Platform Workload are achieving their goals. If not, it helps determine which virtual servers are contributing to the performance problem. 2.12 Typical mainframe system growth An integral characteristic of the mainframe is extensibility. This is a system design principle where the implementation takes into consideration future ease of growth to extend a system's infrastructure. Extensions can be made through the addition of new functionality or through modification of existing functionality. The central objective is to provide for change while minimizing the impact to existing system functions. You will see this design theme throughout this publication. Today’s mainframe supports size and capacity in various ways. It is difficult to provide a definitive set of guidelines to portray what are considered small, medium, and large mainframe shops, because infrastructure upgrades can be readily made. IBM further enhances the capabilities of the mainframe by using optimized capacity settings with subcapacity central processors. There is great granularity by using subcapacity engines and high scalability (with up to 64 engines on a single server). 76 Introduction to the New Mainframe: z/OS Basics
Slide 101: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm Here are a few other examples: Customer Initiated Upgrade (CIU): The CIU feature enables a customer to order permanent capacity upgrades rapidly and download them without disrupting applications already running on the machine. When extra processing power becomes necessary, an administrator simply uses a two step process: a. Navigates to special web-based link to order an upgrade. b. Uses the Remote Service Facility on the Hardware Management Console (HMC) to download and activate preinstalled inactive processors (uncharacterized engines) or memory. On/Off Capacity on Demand (On/Off CoD): This feature is available through CIU, and uses On/Off CoD for temporary increases in processor capacity. With temporary processor capacity, customers manage both predictable and unpredictable surges in capacity demands. They can activate and deactivate quickly and efficiently as the demands on their organization dictates to obtain additional capacity that they need, when they need it, and the machine will keep track of its usage. On/Off CoD provides a cost-effective strategy for handling seasonal or period-end fluctuations in activity and may enable customers to deploy pilot applications without investing in new hardware. Free tests are available for this feature. Capacity Backup (CBU): Customers can use CBU to add temporary processing capacity to a backup machine in the event of an unforeseen loss of server capability because of an emergency. With CBU, customers can divert entire workloads to backup servers for up to 90 days. 2.13 Continuous availability of mainframes Parallel Sysplex technology is an enabling technology, allowing highly reliable, redundant, and robust mainframe technologies to achieve near-continuous availability. A properly configured Parallel Sysplex cluster is designed to remain available to its users and applications with minimal downtime. Here are some examples: Hardware and software components provide concurrency to facilitate nondisruptive maintenance, such as Capacity Upgrade on Demand, which allows processing or coupling capacity to be added one engine at a time without disruption to running workloads. In addition, CP sparing is used if there is a processor failure (another one is brought online transparently). DASD subsystems employ disk mirroring or RAID technologies to help protect against data loss, and exploit technologies to enable point-in-time backup, without the need to shut down applications. Chapter 2. Mainframe hardware systems and high availability 77
Slide 102: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am Networking technologies deliver functions such as VTAM® Generic Resources, Multi-Node Persistent Sessions, Virtual IP Addressing, and Sysplex Distributor to provide fault-tolerant network connections. I/O subsystems support multiple I/O paths and dynamic switching to prevent loss of data access and improved throughput. z/OS software components allow new software releases to coexist with lower levels of those software components to facilitate rolling maintenance. Business applications are “data sharing-enabled” and cloned across servers to allow workload balancing to prevent loss of application availability in the event of an outage. Operational and recovery processes are fully automated and transparent to users, and reduce or eliminate the need for human intervention. z/OS has a Health Checker to assist in avoiding outages. This uses “best practices,” identifying potential problems before they impact availability. It produces output in the form of detailed messages and offers suggested actions to take. Parallel Sysplex is a way of managing this multi-system environment, providing such benefits as: No single points of failure Capacity and scaling Dynamic workload balancing Systems management technologies Single system image Compatible change and nondisruptive growth Application compatibility Disaster recovery These benefits are described in the remaining sections of this chapter. 2.13.1 No single points of failure In a Parallel Sysplex cluster, it is possible to construct a parallel processing environment with no single points of failure. Because all of the systems in the Parallel Sysplex can have concurrent access to all critical applications and data, the loss of a system due to either hardware or software failure does not necessitate loss of application availability. 78 Introduction to the New Mainframe: z/OS Basics
Slide 103: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm Peer instances of a failing subsystem executing on remaining healthy system nodes can take over recovery responsibility for resources held by the failing instance. Alternatively, the failing subsystem can be automatically restarted on still-healthy systems using automatic restart capabilities to perform recovery for work in progress at the time of the failure. While the failing subsystem instance is unavailable, new work requests can be redirected to other data-sharing instances of the subsystem on other cluster nodes to provide continuous application availability across the failure and subsequent recovery. This provides the ability to mask planned as well as unplanned outages to the user. Because of the redundancy in the configuration, there is a significant reduction in the number of single points of failure. Without a Parallel Sysplex, the loss of a server could severely impact the performance of an application, as well as introduce system management difficulties in redistributing the workload or reallocating resources until the failure is repaired. In a Parallel Sysplex environment, it is possible that the loss of a server may be transparent to the application, and the server workload can be redistributed automatically within the Parallel Sysplex with little performance degradation. Therefore, events that otherwise would seriously impact application availability, such as failures in central processor complex (CPC) hardware elements or critical operating system components, would, in a Parallel Sysplex environment, have reduced impact. Even though they work together and present a single image, the nodes in a Parallel Sysplex cluster remain individual systems, making installation, operation, and maintenance nondisruptive. The system programmer can introduce changes, such as software upgrades, one system at a time, while the remaining systems continue to process work. This allows the mainframe IT staff to roll changes through its systems on a schedule that is convenient to the business. 2.13.2 Capacity and scaling The Parallel Sysplex environment can scale nearly linearly from 2 to 32 systems. This can be a mix of any servers that support the Parallel Sysplex environment. The aggregate capacity of this configuration meets every processing requirement known today. The mainframe offers subcapacity settings for general CPs. If you do not need the full strength of a full cycle CP, you have the option for a smaller setting. There are ranges of subcapacity settings, as defined by the model of the machine. Chapter 2. Mainframe hardware systems and high availability 79
Slide 104: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am 2.13.3 Dynamic workload balancing The entire Parallel Sysplex cluster can be viewed as a single logical resource to users and business applications. Just as work can be dynamically distributed across the individual processors within a single SMP server, so too can work be directed to any node in a Parallel Sysplex cluster having available capacity. This capability avoids the need to partition data or applications among individual nodes in the cluster or to replicate databases across multiple servers. Workload balancing also permits a business to run diverse applications across a Parallel Sysplex cluster while maintaining the response levels critical to a business. The mainframe IT director selects the service level agreements required for each workload, and the workload management (WLM) component of z/OS, along with subsystems such as CP/SM or IMS, automatically balance tasks across all the resources of the Parallel Sysplex cluster to meet these business goals. The work can come from a variety of sources, such as batch, SNA, TCP/IP, DRDA®, or WebSphere MQ. There are several aspects to consider for recovery. First, when a failure occurs, it is important to bypass it by automatically redistributing the workload to use the remaining available resources. Secondly, it is necessary to recover the elements of work that were in progress at the time of the failure. Finally, when the failed element is repaired, it should be brought back into the configuration as quickly and transparently as possible to again start processing the workload. Parallel Sysplex technology enables all these tasks. Workload distribution After the failing element has been isolated, it is necessary to non-disruptively redirect the workload to the remaining available resources in the Parallel Sysplex. In the event of failure in the Parallel Sysplex environment, the online transaction workload is automatically redistributed without operator intervention. Generic resource management Generic resource management provides the ability to specify a common network interface to VTAM. This ability can be used for CICS terminal owning regions (TORs), IMS Transaction Manager, TSO, or DB2 DDF work. If one of the CICS TORs fails, for example, only a subset of the network is affected. The affected terminals are able to immediately log on again and continue processing after being connected to a different TOR. 80 Introduction to the New Mainframe: z/OS Basics
Slide 105: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm 2.13.4 Systems management technologies The Parallel Sysplex solution satisfies a major customer requirement for 24x7 availability, while providing techniques for achieving enhanced Systems Management consistent with this requirement. Some of the features of the Parallel Sysplex solution that contribute to increased availability also help to eliminate some Systems Management tasks. Examples include: Workload management component Sysplex Failure Manager Automatic Restart Manager Cloning and symbolics z/OS resource sharing Workload management component The idea of z/OS Workload Manager (WLM) is to make a contract between the installation (user) and the operating system. The installation classifies the work running on the z/OS operating system in distinct service classes and defines goals for them that express the expectation of how the work should perform. WLM uses these goal definitions to manage the work across all systems. The workload management component of z/OS provides sysplex-wide throughput management capabilities based on installation-specified performance policy goals written as rules. These rules define the business importance of the workloads. WLM attains the performance goals through dynamic resource distribution. This is one of the major strengths of z/OS. WLM provides the Parallel Sysplex cluster with the intelligence to determine where work needs to be processed and in what priority. The priority is based on the customer's business goals and is managed by sysplex technology. Sysplex Failure Manager The Sysplex Failure Management (SFM) policy allows the installation to specify failure detection intervals and recovery actions to be initiated in the event of the failure of a system in the sysplex. Without SFM, when one of the systems in the Parallel Sysplex fails, the operator is notified and prompted to take some recovery action. The operator may choose to partition the non-responding system from the Parallel Sysplex, or to take some action to try to recover the system. This period of operator intervention might tie up critical system resources required by the remaining active systems. Chapter 2. Mainframe hardware systems and high availability 81
Slide 106: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am Sysplex Failure Manager allows the installation to code a policy to define the recovery actions to be initiated when specific types of problems are detected, such as fencing off the failed image that prevents access to shared resources, logical partition deactivation, or central storage and expanded storage acquisition, to be automatically initiated following detection of a Parallel Sysplex failure. ARM: A system recovery function that improves the availability of batch jobs and started tasks. Automatic Restart Manager Automatic Restart Manager (ARM) enables fast recovery of subsystems that might hold critical resources at the time of failure. If other instances of the subsystem in the Parallel Sysplex need any of these critical resources, fast recovery makes these resources available more quickly. Even though automation packages are used today to restart the subsystem to resolve such deadlocks, ARM can be activated closer to the time of failure. ARM reduces operator intervention in the following areas: Detection of the failure of a critical job or started task Automatic restart after a started task or job failure After an abend of a job or started task, the job or started task can be restarted with specific conditions, such as overriding the original JCL or specifying job dependencies, without relying on the operator. Automatic redistribution of work to an appropriate system following a system failure This action removes the time-consuming step of human evaluation of the most appropriate target system for restarting work. Cloning and symbolics Cloning refers to replicating the hardware and software configurations across the different physical servers in the Parallel Sysplex, that is, an application that takes advantage of parallel processing might have identical instances running on all images in the Parallel Sysplex. The hardware and software supporting these applications could also be configured identically on all systems in the Parallel Sysplex to reduce the amount of work required to define and support the environment. The concept of symmetry allows new systems to be introduced and enables automatic workload distribution in the event of failure or when an individual system is scheduled for maintenance. It also reduces the amount of work required by the system programmer in setting up the environment. 82 Introduction to the New Mainframe: z/OS Basics
Slide 107: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm Note that symmetry does not preclude the need for systems to have unique configuration requirements, such as the asymmetric attachment of printers and communications controllers, or asymmetric workloads that do not lend themselves to the parallel environment. System symbolics are used to help manage cloning. z/OS provides support for the substitution values in startup parameters, JCL, system commands, and started tasks. These values can be used in parameter and procedure specifications to allow unique substitution when dynamically forming a resource name. z/OS resource sharing A number of base z/OS components have discovered that the IBM coupling facility shared storage provides a medium for sharing component information for the purpose of multi-system resource management. This medium, called IBM z/OS Resource Sharing, enables sharing of physical resources, such as files, tape drives, consoles, and catalogs, with improvements in cost, performance, and simplified systems management. This is not to be confused with Parallel Sysplex data sharing by the database subsystems. Resource Sharing delivers immediate value even for customers who are not using data sharing, through native system usage delivered with the base z/OS software stack. One of the goals of the Parallel Sysplex solution is to provide simplified systems management by reducing complexity in managing, operating, and servicing a Parallel Sysplex, without requiring an increase in the number of support staff and without reducing availability. 2.13.5 Single system image Even though there could be multiple servers and z/OS images in the Parallel Sysplex and a mix of different technologies, the collection of systems in the Parallel Sysplex should appear as a single entity to the operator, the user, the database administrator, and so on. A single system image brings reduced complexity from both operational and definition perspectives. Regardless of the number of system images and the complexity of the underlying hardware, the Parallel Sysplex solution provides for a single system image from several perspectives: Data access, allowing dynamic workload balancing and improved availability Dynamic Transaction Routing, providing dynamic workload balancing and improved availability A user interface, allowing logon to a logical network entity Operational interfaces, allowing easier Systems Management Chapter 2. Mainframe hardware systems and high availability 83
Slide 108: Chap2 hardware intro.fm Single point of control: A sysplex characteristic; when you can accomplish a given set of tasks from a single workstation. Draft Document for Review February 26, 2011 8:32 am Single point of control It is a requirement that the collection of systems in the Parallel Sysplex can be managed from a logical single point of control. The term “single point of control” means the ability to access whatever interfaces are required for the task in question, without reliance on a physical piece of hardware. For example, in a Parallel Sysplex of many systems, it is necessary to be able to direct commands or operations to any system in the Parallel Sysplex, without the necessity for a console or control point to be physically attached to every system in the Parallel Sysplex. Persistent single system image across failures Even though individual hardware elements or entire systems in the Parallel Sysplex fail, a single system image must be maintained. This means that, as with the concept of single point of control, the presentation of the single system image is not dependent on a specific physical element in the configuration. From the user point of view, the parallel nature of applications in the Parallel Sysplex environment must be transparent. An application should be accessible regardless of which physical z/OS image supports it. 2.13.6 Compatible change and nondisruptive growth A primary goal of Parallel Sysplex is continuous availability. Therefore, it is a requirement that changes, such as new applications, software, or hardware, be introduced non-disruptively, and that they be able to coexist with current levels. In support of compatible change, the hardware and software components of the Parallel Sysplex solution allow the coexistence of two levels, that is, level N and level N+1. This means, for example, that no IBM software product will make a change that cannot be tolerated by the previous release. 2.13.7 Application compatibility A design goal of Parallel Sysplex clustering is that no application changes be required to take advantage of the technology. For the most part, this has held true, although some affinities need to be investigated to get the maximum advantage from the configuration. From the application architects’ point of view, three major points might lead to the decision to run an application in a Parallel Sysplex: Technology benefits Scalability (even with nondisruptive upgrades), availability, and dynamic workload management are tools that enable an architect to meet customer needs in cases where the application plays a key role in the customer’s business process. 84 Introduction to the New Mainframe: z/OS Basics
Slide 109: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm With the multisystem data sharing technology, all processing nodes in a Parallel Sysplex have full concurrent read/write access to shared data without affecting integrity and performance. Integration benefits Because many applications are historically S/390- and z/OS-based, new applications on z/OS get performance and maintenance benefits, especially if they are connected to existing applications. Infrastructure benefits If there is already an existing Parallel Sysplex, it needs little infrastructure work to integrate a new application. In many cases, the installation does not need to integrate new servers. Instead, it can use the existing infrastructure and make use of the strengths of the existing sysplex. With Geographically Dispersed Parallel Sysplex™ (GDPS®) connecting multiple sysplexes in different locations, the mainframe IT staff can create a configuration that is enabled for disaster recovery. 2.13.8 Disaster recovery GDPS: An application that improves application availability and disaster recovery in a Parallel Sysplex. Geographically Dispersed Parallel Sysplex (GDPS) is the primary disaster recovery and continuous availability solution for a mainframe-based multisite enterprise. GDPS automatically mirrors critical data and efficiently balances workload between the sites. GDPS also uses automation and Parallel Sysplex technology to help manage multisite databases, processors, network resources, and storage subsystem mirroring. This technology offers continuous availability, efficient movement of workload between sites, resource management, and prompt data recovery for business-critical mainframe applications and data. With GDPS, the current maximum distance between the two sites is 100 km (about 62 miles) of fibre, although there are some other restrictions. This provides a synchronous solution that helps ensure that there is no loss of data. There is also GDPS/XRC, which can be used over extended distances and should provide a recovery point objective of less than two minutes (that is, a maximum of two minutes of data would need to be recovered or is lost). This disaster recovery (DR) solution across two sites can be separated by virtually unlimited distance. Today’s DR implementations provide several types of offerings, including two and three site solutions. The code has been developed and enhanced over a number of years, to use new hardware and software capabilities, to reflect best practices based on IBM experience with GDPS customers since its inception, and to address the constantly changing requirements of clients. Chapter 2. Mainframe hardware systems and high availability 85
Slide 110: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am 2.14 Summary Being aware of various meanings of the terms systems, processors, CPs, and so on is important to understanding mainframe computers. The original S/360 architecture, based on CPUs, memory, channels, control units, and devices, and the way these are addressed, is fundamental to understanding mainframe hardware, even though almost every detail of the original design has been changed in various ways. The concepts and terminology of the original design still permeate mainframe descriptions and designs. zAAP/zIIP: Specialized processing assist units configured for running selective programming on the mainframe. The ability to partition a large system into multiple logical partitions (LPARs) is now a core requirement in practically all mainframe installations. The flexibility of the hardware design, allowing any processor (CP) to access and accept interrupts for any channel, control unit, and device connected to a given LPAR, contributes to the flexibility, reliability, and performance of the complete system. The availability of a pool of processors (PUs) that can be configured (by IBM) as customer processors (CPs), I/O processors (SAPs), dedicated Linux processors (IFLs), dedicated Java-type processors (zAAPs), specialized services for DB2/XML (zIIPs) and spare processors is unique to mainframes and, again, provides great flexibility in meeting customer requirements. Some of these requirements are based on the cost structures of some mainframe software. In addition to the primary processors just mentioned (the PUs, and all their characterizations), mainframes have a network of controllers (special microprocessors) that control the system as a whole. These controllers are not visible to the operating system or application programs. Since the early 1970s, mainframes have been designed as multiprocessor systems, even when only a single processor is installed. All operating system software is designed for multiple processors; a system with a single processor is considered a special case of a general multiprocessor design. All but the smallest mainframe installations typically use clustering techniques, although they do not normally use the terms cluster or clustering. As stated previously, a clustering technique can be as simple as a shared DASD configuration where manual control or planning is needed to prevent unwanted data overlap. More common today are configurations that allow sharing of locking and enqueueing controls among all systems. Among other benefits, this automatically manages access to data sets so that unwanted concurrent usage does not occur. 86 Introduction to the New Mainframe: z/OS Basics
Slide 111: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm The most sophisticated of the clustering techniques is a Parallel Sysplex. This technology allows the linking up to 32 servers with near linear scalability to create a powerful commercial processing clustered system. Every server in a Parallel Sysplex cluster has access to all data resources, and every “cloned” application can run on every server. When used with coupling technology, Parallel Sysplex provides a “shared data” clustering technique that permits multisystem data sharing with high performance read/write integrity. Sysplex design characteristics help businesses run continuously, even during periods of dramatic change. Sysplex sites can dynamically add and change systems in a sysplex, and configure the systems for no single points of failure. Through this state-of-the-art cluster technology, multiple z/OS systems can be made to work in concert to more efficiently process the largest commercial workloads. Table 2-1 lists the key terms used in this chapter. Table 2-1 Key terms used in this chapter Automatic Restart Manager (ARM) channel path identifier (CHPID) ESCON channel logical partition (LPAR) single point of control central processing complex (CPC) channel-to-channel (CTC) connection Geographically Dispersed Parallel Sysplex (GDPS) multiprocessor z/Architecture central processing unit (CPU) coupling facility Hardware Management Console (HMC) Parallel Sysplex System z Specialty Processors. 2.15 Questions for review To help test your understanding of the material in this chapter, answer the following questions: 1. Why does software pricing for mainframes seem so complex? 2. Why does IBM have so many models (or “capacity settings”) for recent mainframe machines? 3. Why does the power needed for a traditional COBOL application not have a linear relationship with the power needed for a new Java application? 4. Multiprocessing means running several processors simultaneously (available to the operating system and applications). What does multiprogramming mean? Chapter 2. Mainframe hardware systems and high availability 87
Slide 112: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am 5. What are the differences between loosely coupled systems and tightly coupled systems? 6. What z/OS application changes are needed for it to work in an LPAR? 7. What z/OS application changes are needed to work in a Parallel Sysplex? 8. How do specialty processors help applications? 9. How do disaster recovery solutions benefit a global business? 2.16 Topics for further discussion Visit a mainframe installation, if possible. The range of new, older, and much older systems and devices found in a typical installation is usually interesting and helps to illustrate the sense of continuity that is so important to mainframe customers. Then consider the following questions: 1. What are the advantages of a Parallel Sysplex presenting a single image externally? Are there any disadvantages? 2. Why is continuous availability required in today’s marketplace? 3. How might someone justify the cost of the “redundant” hardware and the cost of the software licences required to build a Parallel Sysplex? 2.17 Exercises Here are some exercises you can perform: To display the CPU configuration: a. Access SDSF from the ISPF primary option menu. b. In the command input field, enter /D M=CPU and press Enter. c. Use the ULOG option in SDSF to view the command display result. To display the page data set usage: a. In the command input field, enter /D ASM and press Enter. b. Press PF3 to return to the previous screens. To display information about the current Initial Program Load (IPL): a. Use ULOG option in SDSF to view the command display result. b. In the command input field, enter /D IPLINFO and press Enter. Attention: The forward slash is the required prefix for entering operator commands in SDSF. 88 Introduction to the New Mainframe: z/OS Basics
Slide 113: Draft Document for Review February 26, 2011 8:32 am Chap2 hardware intro.fm Chapter 2. Mainframe hardware systems and high availability 89
Slide 114: Chap2 hardware intro.fm Draft Document for Review February 26, 2011 8:32 am 90 Introduction to the New Mainframe: z/OS Basics
Slide 115: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm 3 Chapter 3. z/OS overview Objective: As the newest member of your company’s mainframe IT group, you need to know the basic functional characteristics of the mainframe operating system. The operating system taught in this course is z/OS, a widely used mainframe operating system. z/OS is known for its ability to serve thousands of users concurrently and for processing large workloads in a secure, reliable, and expedient manner. After completing this chapter, you will be able to: List several defining characteristics of the z/OS operating system. Give examples of how z/OS differs from a single-user operating system. List the major types of storage used by z/OS. Explain the concept of virtual storage and its use in z/OS. State the relationship between pages, frames, and slots. List several software products used with z/OS to provide a complete system. Describe several differences and similarities between the z/OS and UNIX operating systems. Understand z/OS Workload Manager concepts. Describe features to optimize workloads. Refer to Table 3-2 on page 160 for a list of key terms used in this chapter. © Copyright IBM Corp. 2006, 2009, 2011. All rights reserved. 91
Slide 116: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am 3.1 What is an operating system In simplest terms, an operating system is a collection of programs that manage the internal workings of a computer system. Operating systems are designed to make the best use of the computer’s various resources, and ensure that the maximum amount of work is processed as efficiently as possible. Although an operating system cannot increase the speed of a computer, it can maximize its use, thereby making the computer seem faster by allowing it to do more work in a given period of time. A computer’s architecture consists of the functions the computer system provides. The architecture is distinct from the physical design, and, in fact, different machine designs might conform to the same computer architecture. In a sense, the architecture is the computer as seen by the user, such as a system programmer. For example, part of the architecture is the set of machine instructions that the computer can recognize and execute. In the mainframe environment, the system software and hardware comprise a highly advanced computer architecture, the result of decades of technological innovation. 3.2 What is z/OS The operating system we discuss in this course is z/OS1, a widely used mainframe operating system. z/OS is designed to offer a stable, secure, continuously available, and scalable environment for applications running on the mainframe. z/OS today is the result of decades of technological advancement. It evolved from an operating system that could process only a single program at a time to an operating system that can handle many thousands of programs and interactive users concurrently. To understand how and why z/OS functions as it does, it is important to understand some basic concepts about z/OS and the environment in which it functions. This chapter introduces some of the concepts that you need to understand the z/OS operating system. In most early operating systems, requests for work entered the system one at a time. The operating system processed each request or job as a unit, and did not start the next job until the one being processed had completed. This arrangement worked well when a job could execute continuously from start to completion. But often a job had to wait for information to be read in from, or written out to, a device such as a tape drive or printer. 1 z/OS is designed to take advantage of the IBM System z architecture, or z/Architecture, which was introduced in the year 2000. The z in the name was selected because these systems often have zero downtime. 92 Introduction to the New Mainframe: z/OS Basics
Slide 117: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm Input and output (I/O) take a long time compared to the electronic speed of the processor. When a job waited for I/O, the processor was idle. Finding a way to keep the processor working while a job is waiting would increase the total amount of work the processor could do without requiring additional hardware. z/OS gets work done by dividing it into pieces and giving portions of the job to various system components and subsystems that function interdependently. At any point in time, one component or another gets control of the processor, makes its contribution, and then passes control along to a user program or another component. Today’s z/OS operating system is a share-everything runtime environment that provides for resource sharing through its heritage of virtualization technology. It uses special hardware and software to access and control the use of those resources, ensuring that there is little underutilization of its components. Further optimization for specific workloads The latest z/OS provides for optional optimization features to accelerate processing of specific workloads. This functionality is provided by blade extension servers. A blade server is a stripped down server computer with a modular design optimized to minimize the use of physical space and energy. The common theme with these specialized hardware components is their relatively seamless integration within the mainframe and operating system environments. IBM has introduced the IBM zEnterprise BladeCenter Extension (zBX), which is a heterogeneous hardware infrastructure that consists of a BladeCenter chassis attached to a IBM zEnterprise 196 (z196). A BladeCenter chassis can contain IBM blades or optimizers. The zBX components are configured, managed, and serviced the same way as the other components of the System z server. Despite the fact that the zBX processors are not System z PUs and run purpose- specific software, the zBX software does not require any additional administration effort or tuning by the user. In short, zBX further extends the degree of integration in the mainframe. zBX provides, within the System z infrastructure, a cost optimized solution for running data warehouse and business intelligence queries against DB2® for z/OS®, with fast and predictable response times, while retaining the data integrity, data management, security, availability, and other qualities of service of System z. Chapter 3. z/OS overview 93
Slide 118: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am 3.2.1 Hardware resources used by z/OS The z/OS operating system executes in a processor and resides in processor storage during execution. z/OS is commonly referred to as the system software or base control program (BCP). Mainframe hardware consists of processors and a multitude of peripheral devices such as disk drives (called direct access storage devices (DASD)), magnetic tape drives, and various types of user consoles; see Figure 3-1. Tape and DASD are used for system functions and by user programs executed by z/OS. z/OS Hardware Master Console (controls mainframe hardware) Mainframe Computer (CPU, processor storage) Operator Console (controls z/OS) Tape Drive Tape Cartridges DASD Controller Disk Storage (DASD volumes) Figure 3-1 Hardware resources used by z/OS Today’s z/OS provides a new disk device geometry called Extended Address Volume (EAV) that enables support for over 223 gigabytes (262,668 cylinders) per disk volume in its initial offering. This helps many larger customers that have the 4-digit device number limitation begin consolidation of disk farms. 94 Introduction to the New Mainframe: z/OS Basics
Slide 119: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm The mainframe offers several types of I/O adapter cards that include open standards, allowing flexibility for configuring high bandwidth for any device type. All hardware components offer built-in redundancy, ensuring reliability and availability, from memory sparing to cooling units. Today’s mainframe also has a capacity provisoning capability to monitor z/OS utilization of system workloads. This feature allows CPUs to be turned on and off dynamically. To fulfill a new order for a z/OS system, IBM ships the system code to the customer through the Internet or (depending on the customer’s preference) on physical tape cartridges. At the customer site, a person, such as the z/OS system programmer, receives the order and copies the new system to DASD volumes. After the system is customized and ready for operation, system consoles are required to start and operate the z/OS system. The z/OS operating system is designed to make full use of the latest IBM mainframe hardware and its many sophisticated peripheral devices. Figure 3-1 presents a simplified view of mainframe concepts that we build upon throughout this course: Software: The z/OS operating system consists of load modules or executable code. During the installation process, the system programmer copies these load modules to load libraries (files) residing on DASD volumes. Hardware: The system hardware consists of all the channels2, control units3, devices, and processors that constitute a mainframe environment. Peripheral devices: These devices include tape drives, DASD, and consoles. There are many other types of devices, some of which were discussed in Chapter 2, “Mainframe hardware systems and high availability” on page 45. Processor storage: Often called real or central storage (or memory), this is where the z/OS operating system executes. Also, all user programs share the use of processor storage with the operating system. Figure 3-1 is not a detailed picture. Not shown, for example, are the hardware control units that connect the mainframe to the other tape drives, and consoles. The standard reference for descriptions of the major facilities of z/Architecture is z/Architecture Principles of Operation. You can find this and related publications at the z/OS Internet Library website: http://www.ibm.com/servers/eserver/zseries/zos/bkserv/ 2 A channel is the communication path from the channel subsystem to the connected control unit and I/O devices. 3 A control unit provides the logical capabilities necessary to operate and control an I/O device. Chapter 3. z/OS overview 95
Slide 120: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am 3.2.2 Multiprogramming and multiprocessing The earliest operating systems were used to control single-user computer systems. In those days, the operating system would read in one job, find the data and devices the job needed, let the job run to completion, and then read in another job. In contrast, the computer systems that z/OS manages are capable of multiprogramming, or executing many programs concurrently. With multiprogramming, when a job cannot use the processor, the system can suspend, or interrupt4, the job, freeing the processor to work on another job. z/OS makes multiprogramming possible by capturing and saving all the relevant information about the interrupted program before allowing another program to execute. When the interrupted program is ready to begin executing again, it can resume execution just where it left off. Multiprogramming allows z/OS to run thousands of programs simultaneously for users who might be working on different projects at different physical locations around the world. z/OS can also perform multiprocessing, which is the simultaneous operation of two or more processors that share the various hardware resources, such as memory and external disk storage devices. The techniques of multiprogramming and multiprocessing make z/OS ideally suited for processing workloads that require many input/output (I/O) operations. Typical mainframe workloads include long-running applications that write updates to millions of records in a database, and online applications for thousands of interactive users at any given time. In contrast, consider the operating system that might be used for a single-user computer system. Such an operating system would need to execute programs on behalf of one user only. In the case of a personal computer (PC), for example, the entire resources of the machine are often at the disposal of one user. Multiprocessing: The simultaneous operation of two or more processors that share the various hardware resources. Many users running many separate programs means that, along with large amounts of complex hardware, z/OS needs large amounts of memory to ensure suitable system performance. Large companies run sophisticated business applications that access large databases and industry-strength middleware products. Such applications require the operating system to protect privacy among users, as well as enable the sharing of databases and software services. Thus, multiprogramming, multiprocessing, and the need for a large amount of memory mean that z/OS must provide function beyond simple, single-user applications. The sections that follow explain, in a general way, the attributes that enable z/OS to manage complex computer configurations. Subsequent portions of this text explore these features in more detail. 4 Interrupt capability permits the CP to switch rapidly to another program in response to exception conditions and external stimuli. 96 Introduction to the New Mainframe: z/OS Basics
Slide 121: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm 3.2.3 Modules and macros z/OS is made up of programming instructions that control the operation of the computer system. These instructions ensure that the computer hardware is being used efficiently and is allowing application programs to run. z/OS includes sets of instructions that, for example, accept work, convert work to a form that the computer can recognize, keep track of work, allocate resources for work, execute work, monitor work, and handle output. A group of related instructions is called a routine or module. A set of related modules that make a particular system function possible is called a system component. The workload management (WLM) component of z/OS, for example, controls system resources, while the recovery termination manager (RTM) handles system recovery. Grouping of sequences of instructions that perform frequently-used system or application functions can be invoked with executable macro5 instructions, or macros. z/OS has macros for functions such as opening and closing data files, loading and deleting programs, and sending messages to the computer operator. 3.2.4 Control blocks As programs execute work on a z/OS system, they keep track of this work in storage areas called control blocks. Controls blocks contain status data, tables, or queues. In general, there are four types of z/OS control blocks: System-related control blocks Resource-related control blocks Job-related control blocks Task-related control blocks Each system-related control block represents one z/OS system and contains system-wide information, such as how many processors are in use. Each resource-related control block represents one resource, such as a processor or storage device. Each job-related control block represents one job executing on the system. Each task-related control block represents one unit of work. Control block: A data structure that serves as a vehicle for communication in z/OS. Control blocks serve as vehicles for communication throughout z/OS. Such communication is possible because the structure of a control block is known to the programs that use it, and thus these programs can find needed information about the unit of work or resource. Control blocks representing many units of the same type may be chained together on queues, with each control block pointing to the next one in the chain. The operating system can search the queue to find information about a particular unit of work or resource, which might be: 5 Macros provide predefined code used as a callable service within z/OS or application programs. Chapter 3. z/OS overview 97
Slide 122: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am An address of a control block or a required routine Actual data, such as a value, a quantity, a parameter, or a name Status flags (usually single bits in a byte, where each bit has a specific meaning) z/OS uses a huge variety of control blocks, many with specialized purposes. This chapter discusses three of the most commonly used control blocks: Task control block (TCB): Represents a unit of work or task. It serves as a repository for information and pointers associated with a task. Various components of the z/OS place information in the TCB and obtain information from the TCB. Service request block (SRB): Represents a request for a system service. It is used as input to the SCHEDULE macro when scheduling a routine for asynchronous execution. Address space control block (ASCB): Represents an address space. It contains information and pointers needed for Address Space Control. 3.2.5 Physical storage used by z/OS Conceptually, mainframes and all other computers have two types of physical storage6: Central storage: Physical storage on the processor. Physical storage located on the mainframe processor itself. This is memory, often called processor storage, real storage, or central storage (CSTOR). Physical storage external to the mainframe, including storage on direct access devices, such as disk drives, and tape drives. For z/OS usage, this storage is called page storage or auxiliary storage. 6 Many computers also have a fast memory, local to the processor, called the processor cache. The cache is not visible to the programmer or application programs or even the operating system directly. 98 Introduction to the New Mainframe: z/OS Basics
Slide 123: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm One difference between the two kinds of storage relates to the way in which they are accessed, as follows: Central storage is accessed synchronously with the processor, that is, the processor must wait while data is retrieved from central storage7. Auxiliary storage: Physical storage external to the mainframe, including storage on direct access devices, such as disk drives and tape drives. Auxiliary storage is accessed asynchronously. The processor accesses auxiliary storage through an input/output (I/O) request, which is scheduled to run amid other work requests in the system. During an I/O request, the processor is free to execute other, unrelated work. As with memory for a personal computer, mainframe central storage is tightly coupled with the processor itself, whereas mainframe auxiliary storage is located on (comparatively) slower, external disk and tape drives. Because central storage is more closely integrated with the processor, it takes the processor much less time to access data from central storage than from auxiliary storage. Auxiliary storage, however, is less expensive than central storage. Most z/OS installations use large amounts of both. Note: There is another form of storage called expanded storage (ESTOR). Expanded storage was offered as a relatively inexpensive way of using high speed processor storage to minimize I/O operations. Since the introduction of z/OS with 64-bit addressing, this form of storage was not required anymore, but other operating systems, such as z/VM, still use it. 3.3 Overview of z/OS facilities An extensive set of system facilities and unique attributes makes z/OS well suited for processing large, complex workloads, such as those that require many I/O operations, access to large amounts of data, or comprehensive security. Typical mainframe workloads include long-running applications that update millions of records in a database and online applications that can serve many thousands of users concurrently. 7 Some processor implementations use techniques such as instruction or data prefetching or “pipelining” to enhance performance. These techniques are not visible to the application program or even the operating system, but a sophisticated compiler can organize the code it produces to take advantage of these techniques. Chapter 3. z/OS overview 99
Slide 124: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am Figure 3-2 provides a “snapshot” view of the z/OS operating environment. Address spaces Operator communication AUX REAL Physical storage Reliability, availability, and serviceability Paging Data integrity AUX REAL Figure 3-2 z/OS operating environment These facilities are explored in greater depth in the remaining portions of this book, but are summarized here: An address space describes the virtual storage addressing range available to a user or program. The address space is an area of contiguous virtual addresses available to a program (or set of programs) and its data requirements. The range of virtual addresses available to a program starts at 0 and can go to the highest address permitted by the operating system architecture. This virtual storage is available for user code and data. Because it maps all of the available addresses, an address space includes system code and data and user code and data. Thus, not all of the mapped addresses are available for user code and data. Two types of physical storage are available: central storage and auxiliary storage (AUX). Central storage is also referred to as real storage or real memory. – The Real Storage Manager (RSM™) controls the allocation of central storage during system initialization, and pages8 in user or system functions during execution. 8 See 3.4, “Virtual storage and other mainframe concepts” on page 101. 100 Introduction to the New Mainframe: z/OS Basics
Slide 125: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm – The auxiliary storage manager controls the use of page and swap data sets. z/OS moves programs and data between central storage and auxiliary storage through processes called paging and swapping. z/OS dispatches work for execution (not shown in the figure), that is, it selects programs to be run based on priority and the ability to execute and then loads the program and data into central storage. All program instructions and data must be in central storage when executing. An extensive set of facilities manages files stored on direct access storage devices (DASDs) or tape cartridges. Operators use consoles to start and stop z/OS, enter commands, and manage the operating system. z/OS is further defined by many other operational characteristics, such as security, recovery, data integrity, and workload management. 3.4 Virtual storage and other mainframe concepts z/OS uses both types of physical storage (central and auxiliary) to enable another kind of storage called virtual storage. In z/OS, each user has access to virtual storage, rather than physical storage. This use of virtual storage is central to the unique ability of z/OS to interact with large numbers of users concurrently, while processing the largest workloads. 3.4.1 What is virtual storage Virtual storage means that each running program can assume it has access to all of the storage defined by the architecture’s addressing scheme. The only limit is the number of bits in a storage address. This ability to use a large number of storage locations is important because a program may be long and complex, and both the program’s code and the data it requires must be in central storage for the processor to access them. z/OS supports a 64-bit addressing scheme, which allows an address space (see 3.4.2, “What is an address space” on page 102) to address, theoretically, up to 16 exabytes9 of storage locations. In reality, the mainframe will have much less central storage installed. How much less depends on the model of the computer and the system configuration. 9 An exabyte is slightly more than one billion gigabytes. Chapter 3. z/OS overview 101
Slide 126: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am To allow each user to act as though this much storage really exists in the computer system, z/OS keeps only the active portions of each program in central storage. It keeps the rest of the code and data in files called page data sets on auxiliary storage, which usually consists of a number of high-speed direct access storage devices (DASDs). Virtual storage, then, is this combination of real and auxiliary storage. z/OS uses a series of tables and indexes to relate locations on auxiliary storage to locations in central storage. It uses special settings (bit settings) to keep track of the identity and authority of each user or program. z/OS uses a variety of storage manager components to manage virtual storage. This chapter briefly covers the key points in the process. This process is shown in more detail in 3.4.4, “Virtual storage overview” on page 107. Terms: Mainframe workers use the terms central storage, real memory, real storage, and main storage interchangeably. Likewise, they use the terms virtual memory and virtual storage synonymously. 3.4.2 What is an address space The range of virtual addresses that the operating system assigns to a user or separately running program is called an address space. This is the area of contiguous virtual addresses available for executing instructions and storing data. The range of virtual addresses in an address space starts at zero and can extend to the highest address permitted by the operating system architecture. For a user, the address space can be considered as the runtime container where programs and their data are accessed. z/OS provides each user with a unique address space and maintains the distinction between the programs and data belonging to each address space. Within each address space, the user can start multiple tasks by using task control blocks (TCBs) that allow multiprogramming. Address space: The range of virtual addresses that the operating system assigns to a user or program. In other ways, a z/OS address space is like a UNIX process, and the address space identifier (ASID)10 is like a process ID (PID). Further, TCBs are like UNIX threads in that each operating system supports processing multiple instances of work concurrently. 10 An ASID is a 2-byte numeric identifier assigned to the Address Space Control Block. 102 Introduction to the New Mainframe: z/OS Basics
Slide 127: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm However, the use of multiple virtual address spaces in z/OS holds some special advantages. Virtual addressing permits an addressing range that is greater than the central storage capabilities of the system. The use of multiple virtual address spaces provides this virtual addressing capability to each job in the system by assigning each job its own separate virtual address space. The potentially large number of address spaces provides the system with a large virtual addressing capacity. With an address space, errors are confined to that address space, except for errors in commonly addressable storage, thus improving system reliability and making error recovery easier. Programs in separate address spaces are protected from each other. Isolating data in its own address space also protects the data. z/OS uses address spaces for its own services that are working on behalf of executing applications. There is at least one address space for each job in progress and one address space for each user logged on through TSO, telnet, rlogin, or FTP (users logged on z/OS through a major subsystem, such as CICS or IMS, are using an address space belonging to the subsystem, not their own address spaces). There are many address spaces for operating system functions, such as operator communication, automation, networking, security, and so on. Address space isolation The use of address spaces allows z/OS to maintain the distinction between the programs and data belonging to each address space. The private areas11 in one user’s address space are isolated from the private areas in other address spaces, and this provides much of the operating system’s security. There are two private areas: One below the 16 MB line (for 24-bit addressing) and one above the 16 MB line (for 31-bit addressing), as shown in Figure 3-12 on page 120. Each address space also contains a common area that is accessible to every other address space. Because it maps all of the available addresses, an address space includes system code and data and user code and data. Thus, not all of the mapped addresses are available for user code and data. The ability of many users to share the same resources implies the need to protect users from one another and to protect the operating system itself. Along with such methods as storage keys12 for protecting central storage, data files, and programs, separate address spaces ensure that users’ programs and data do not overlap. The private area of an address space is where user application programs execute, as opposed to the common area, which is shared across all address spaces. 12 Keys are bit settings within the program status word (the currently executing instruction) used by z/OS to compare storage being accessed by the program. 11 Chapter 3. z/OS overview 103
Slide 128: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am Important: Storage protection is one of the mechanisms implemented by z/Architecture to protect central storage. With multiprocessing, hundreds of tasks can run programs accessing physically any piece of central storage. Storage protection imposes limits on what a task can access (for read or write) within central storage locations with its own data and programs, or, if specifically allowed, to read areas from other tasks. Any violation of this rule causes the CP to generate a program interrupt or storage exception. All real addresses manipulated by CPs must go through the storage protection verification before being used as an argument to access the contents of central storage. For each 4 KB block of central storage, there is a 7-bit control field called a storage key. Address space communication In a multiple virtual address space environment, applications need ways to communicate between address spaces. z/OS provides two methods of inter-address space communication: Scheduling a service request block (SRB), which is an asynchronous process Using cross-memory services and access registers, which is a synchronous process A program uses an SRB to initiate a process in another address space or in the same address space. The SRB is asynchronous in nature and runs independently of the program that issues it, thereby improving the availability of resources in a multiprocessing environment. We discuss SRBs further in “What is a service request block” on page 136. A program uses cross-memory services to access another user’s address spaces directly (see 3.8, “Cross-memory services” on page 143 for more information). You might compare z/OS cross-memory services to the UNIX Shared Memory functions, which can be used on UNIX without special authority. Unlike UNIX, however, z/OS cross-memory (XM) services require the issuing program to have special authority, controlled by the authorized program facility (APF). This method allows efficient and secure access to data owned by others, data owned by the user but stored in another address space for convenience, and for rapid and secure communication with services, such as transaction managers and database managers. Cross memory is also implemented by many z/OS subsystems13 and products. 13 A subsystem is middleware used by applications to perform certain system services. Subsystem examples are DB2, IMS, and CICS. 104 Introduction to the New Mainframe: z/OS Basics
Slide 129: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm Cross memory can also be synchronous, enabling one program to provide services coordinated with other programs. In Figure 3-3, synchronous cross-memory communication takes place between Address Space 2, which gets control from Address Space 1 when the program call (PC) is issued. Address Space 1 had previously established the necessary environment before the PC instruction transferred control to an Address Space 2 called a PC routine. The PC routine provides the requested service and returns control to Address Space 1. (User) Data MVCP (Service Provider) Data Move Data MVCS Address Space 1 Address Space 2 PC PR Pass Control Address Space 1 1 2 3 Address Space 2 oper1 oper2 oper3 Instructions here, Operands there Figure 3-3 Synchronous cross memory The user program in Address Space 1 and the PC routine can execute in the same address space, as shown in Figure 3-3, or in different address spaces. In either case, the PC routine executes under the same TCB as the user program that issued the PC. Thus, the PC routine provides the service synchronously. Chapter 3. z/OS overview 105
Slide 130: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am Cross memory is an evolution of virtual storage and has three objectives: Move data synchronously between virtual addresses located in distinct address spaces. Pass control synchronously between instructions located in distinct address spaces. Execute one instruction located in one address space while its operands are located in another address space. Important: Address spaces are distinct runtime containers that are isolated from one another through the z/OS architecture. Cross-memory services, used to access another address space, are performed under special authorized instructions and access privileges used only by certain system functions. Using cross-memory services is described in z/OS MVS Programming: Extended Addressability Guide. You can find this and related publications at the z/OS Internet Library website: http://www.ibm.com/servers/eserver/zseries/zos/bkserv/ 3.4.3 What is dynamic address translation Dynamic address translation (DAT) is the process of translating a virtual address during a storage reference into the corresponding real address. If the virtual address is already in central storage, the DAT process may be accelerated through the use of translation lookaside buffers. If the virtual address is not in central storage, a page fault interrupt occurs, and z/OS is notified and brings the page in from auxiliary storage. Looking at this process more closely reveals that the machine can present any one of a number of different types of storage faults.14 A type, region, segment, or page fault is presented depending on at which point in the DAT structure invalid entries are found. The faults repeat down the DAT structure until a page fault is presented and the virtual page is brought into central storage either for the first time (there is no copy on auxiliary storage) or by bringing the page in from auxiliary storage. DAT is implemented by both hardware and software through the use of page tables, segment tables, region tables, and translation lookaside buffers. DAT allows different address spaces to share the same program or other data that is for read only. This is because virtual addresses in different address spaces can be made to translate to the same frame of central storage. 14 An address not in real storage. 106 Introduction to the New Mainframe: z/OS Basics
Slide 131: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm Otherwise, there would have to be many copies of the program or data, one for each address space. Address Space P0 P1 P266 P0 P1 P266 80 Central Storage F0 F1 F2 F3 F4 81 (Number of pages equal to the number of frames) Page Table 256 Entries . . . Segment Table 80 81 DAT 8 4A8 4A6C8A28 100000 C8A28 4A8 (# SEGM) C8A28 1000 A28 C8 (# Page) Page Table 256 Entries • Receive an address from the CP. • Divide the address by 1 MB. The quotent is the number of the segment (S) and the remainder is the displacement within the segment (D1). • Find the correspondent entry in the segment table to obtain the pointer of the corresponding page table. • Divide the D1 by 4K. The quotent is the number of the page (P) and the rest is the displacement within page (D2). Find the corresponding entry for P2 in the page table, getting the location of the corresponding frame. • Add D2 with the frame location and pass back this result to the CP to allow access to the memory contents (i.e., x'4A6C8A28'). Page Table Location = 8000 + A26 = 8A26 (the location 8000 was taken from the page table entry) PG C8 8000 See "Format of a Virtual Address" in the next section Figure 3-4 Dynamic Address Translation 3.4.4 Virtual storage overview Recall that for the processor to execute a program instruction, both the instruction and the data it references must be in central storage. The convention of early operating systems was to have the entire program reside in central storage when its instructions were executing. However, the entire program does not really need to be in central storage when an instruction executes. Instead, by bringing pieces of the program into central storage only when the processor is ready to execute them, and moving them out to auxiliary storage when it does not need them, an operating system can execute more and larger programs concurrently. How does the operating system keep track of each program piece? How does it know whether it is in central storage or auxiliary storage, and where? It is important for z/OS professionals to understand how the operating system makes this happen. Chapter 3. z/OS overview 107
Slide 132: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am Physical storage is divided into areas, each the same size and accessible by a unique address. In central storage, these areas are called frames; in auxiliary storage, they are called slots. Similarly, the operating system can divide a program into pieces the size of frames or slots and assign each piece a unique address. This arrangement allows the operating system to keep track of these pieces. In z/OS, the program pieces are called pages. These topics are discussed further in “Frames, pages, and slots” on page 111. Pages are referenced by their virtual addresses and not by their real addresses. From the time a program enters the system until it completes, the virtual address of the page remains the same, regardless of whether the page is in central storage or auxiliary storage. Each page consists of individual locations called bytes, each of which has a unique virtual address. Format of a virtual address As mentioned, virtual storage is an illusion created by the architecture, in that the system seems to have more memory than it really has. Each user or program gets an address space, and each address space contains the same range of storage addresses. Only those portions of the address space that are needed at any point in time are actually loaded into central storage. z/OS keeps the inactive pieces of address spaces in auxiliary storage. z/OS manages address spaces in units of various sizes. DAT may use from two to five levels of tables and is broken down as follows: Page Segment Address spaces are divided into 4 KB units of virtual storage called pages. Address spaces are divided into 1 MB units called segments. A segment is a block of sequential virtual addresses spanning megabytes, beginning at a 1 MB boundary. A 2 GB address space, for example, consists of 2048 segments. Address spaces are divided into 2 - 8 GB units called regions. A region is a block of sequential virtual addresses spanning 2 - 8 GB, beginning at a 2 GB boundary. A 2 TB address space, for example, consists of 2048 regions. Region A virtual address, accordingly, is divided into four principal fields: bits 0 - 32 are called the region index (RX), bits 33 - 43 are called the segment index (SX), bits 44 - 51 are called the page index (PX), and bits 52 - 63 are called the byte index (BX). 108 Introduction to the New Mainframe: z/OS Basics
Slide 133: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm A virtual address has the format shown in Figure 3-5. / RX / 0 33 SX 44 PX 52 BX 63 Figure 3-5 Virtual address format As determined by its address-space-control element, a virtual address space can be a 2 GB space consisting of one region, or as large as a 16 EB space. The RX part of a virtual address for a 2 GB address space must be all zeros; otherwise, an exception is recognized. The RX part of a virtual address is itself divided into three fields. Bits 0 - 10 are called the region first index (RFX), bits 11 - 21 are called the region second index (RSX), and bits 22 - 32 are called the region third index (RTX). Bits 0 - 32 of the virtual address have the format shown in Figure 3-6. RFX 0 11 RSX 22 RTX 33 Figure 3-6 Virtual address format of bits 0 - 32 A virtual address in which the RTX is the left most significant part (a 42-bit address) is capable of addressing 4 TB (4096 regions), one in which the RSX is the left most significant part (a 53-bit address) is capable of addressing 8 PB (four million regions), and one in which the RFX is the left most significant part (a 64-bit address) is capable of addressing 16 EB (8 billion regions). How virtual storage addressing works in z/OS As stated previously, the use of virtual storage in z/OS means that only the pieces of a program that are currently active need to be in central storage at processing time. The inactive pieces are held in auxiliary storage. Chapter 3. z/OS overview 109
Slide 134: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am Figure 3-7 on page 110 shows the virtual storage concept at work in z/OS. Virtual Storage User A address space Real Storage xyx 00971000 Real address 10254000 Virtual address 0014A000 Real address abc 4k User B address space 10254000 Virtual address Auxiliary Storage Figure 3-7 Real and auxiliary storage combine to create the illusion of virtual storage In Figure 3-7, observe the following: An address is an identifier of a required piece of information, but not a description of where in central storage that piece of information is. This allows the size of an address space (that is, all addresses available to a program) to exceed the amount of central storage available. For most user programs, all central storage references are made in terms of virtual storage addresses.15 Dynamic address translation (DAT) is used to translate a virtual address during a storage reference into a physical location in central storage. As shown in Figure 3-7, the virtual address 10254000 can exist more than once, because each virtual address maps to a different address in central storage. When a requested address is not in central storage, a hardware interruption is signaled to z/OS and the operating system pages in the required instructions and data to central storage. 15 Some instructions, primarily those used by operating system programs, require real addresses. 110 Introduction to the New Mainframe: z/OS Basics
Slide 135: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm Frames, pages, and slots When a program is selected for execution, the system brings it into virtual storage, divides it into pages of 4 KB, and transfers the pages into central storage for execution. To the programmer, the entire program appears to occupy contiguous space in storage at all times. Actually, not all pages of a program are necessarily in central storage, and the pages that are in central storage do not necessarily occupy contiguous space. The pieces of a program executing in virtual storage must be moved between real and auxiliary storage. To allow this action, z/OS manages storage in units, or blocks, of 4 KB. The following blocks are defined: A block of central storage is a frame. A block of virtual storage is a page. A block of auxiliary storage is a slot. A page, a frame, and a slot are all the same size: 4 KB. An active virtual storage page resides in a central storage frame. A virtual storage page that becomes inactive resides in an auxiliary storage slot (in a paging data set). Figure 3-8 on page 111 shows the relationship of pages, frames, and slots. In Figure 3-8, z/OS is performing paging for a program running in virtual storage. The lettered boxes represent parts of the program. In this simplified view, program parts A, E, F, and H are active and running in central storage frames, while parts B, C, D, and G are inactive and have been moved to auxiliary storage slots. All of the program parts, however, reside in virtual storage and have virtual storage addresses. Frame: In central storage, areas of equal size that are accessible by a unique address. Slot: In auxiliary storage, areas of equal size that are accessible by a unique address. VIRTUAL REAL AUXILIARY F A H E C G A E B F D H B DG C SLOTS FRAMES PAGES Figure 3-8 Frames, pages, and slots Chapter 3. z/OS overview 111
Slide 136: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am 3.4.5 What is paging As stated previously, z/OS uses a series of tables to determine whether a page is in real or auxiliary storage, and where. To find a page of a program, z/OS checks the table for the virtual address of the page, rather than searching through all of physical storage for it. z/OS then transfers the page into central storage or out to auxiliary storage as needed. This movement of pages between auxiliary storage slots and central storage frames is called paging. Paging is key to understanding the use of virtual storage in z/OS. z/OS paging is transparent to the user. During job execution, only those pieces of the application that are required are brought in, or paged in, to central storage. The pages remain in central storage until no longer needed, or until another page is required by the same application or a higher-priority application and no empty central storage is available. To select pages for paging out to auxiliary storage, z/OS follows a “Least Used” algorithm, that is, z/OS assumes that a page that has not been used for some time will probably not be used in the near future. How paging works in z/OS In addition to the DAT hardware, and the segment and page tables required for address translation, paging activity involves a number of system components to handle the movement of pages and several additional tables to keep track of the most current version of each page. To understand how paging works, assume that DAT encounters an invalid page table entry during address translation, indicating that a page is required that is not in a central storage frame. To resolve this page fault, the system must bring the page in from auxiliary storage. First, however, it must locate an available central storage frame. If none is available, the request must be saved and an assigned frame freed. To free a frame, the system copies its contents to auxiliary storage and marks its corresponding page table entry as invalid. This operation is called a page-out. After a frame is located for the required page, the contents of the page are copied from auxiliary storage to central storage and the page table invalid bit is set off. This operation is called a page-in. Paging can also take place when z/OS loads an entire program into virtual storage. z/OS obtains virtual storage for the user program and allocates a central storage frame to each page. Each page is then active and subject to the normal paging activity, that is, the most active pages are retained in central storage while the pages not currently active might be paged out to auxiliary storage. 112 Introduction to the New Mainframe: z/OS Basics
Slide 137: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm Page stealing z/OS tries to keep an adequate supply of available central storage frames on hand. When a program refers to a page that is not in central storage, z/OS uses a central storage page frame from a supply of available frames. When this supply becomes low, z/OS uses page stealing to replenish it, that is, it takes a frame assigned to an active user and makes it available for other work. The decision to steal a particular page is based on the activity history of each page currently residing in a central storage frame. Pages that have not been active for a relatively long time are good candidates for page stealing. Unreferenced interval count z/OS uses a sophisticated paging algorithm to efficiently manage virtual storage based on which pages were most recently used. An unreferenced interval count indicates how long it has been since a program referenced the page. At regular intervals, the system checks the reference bit for each page frame. If the reference bit is off, that is, the frame has not been referenced, the system adds to the frame’s unreferenced interval count. It adds the number of seconds since this address space last had the reference count checked. If the reference bit is on, the frame has been referenced, and the system turns it off and sets the unreferenced interval count for the frame to zero. Frames with the highest unreferenced interval counts are the ones most likely to be stolen. z/OS also uses various storage managers to keep track of all pages, frames, and slots in the system. These storage managers are described in 3.4.8, “Role of storage managers” on page 115. 3.4.6 Swapping and the working set Swapping: The process of transferring an entire address space between central storage and auxiliary storage. Swapping is the process of transferring all of the pages of an address space between central storage and auxiliary storage. A swapped-in address space is active, having pages in central storage frames and pages in auxiliary storage slots. A swapped-out address space is inactive; the address space resides on auxiliary storage and cannot execute until it is swapped in. While only a subset of the address space’s pages (known as its working set) would likely be in central storage at any time, swapping effectively moves the entire address space. It is one of several methods that z/OS uses to balance the system workload and ensure that an adequate supply of available central storage frames is maintained. Swapping is performed by the System Resource Manager (SRM) component, in response to recommendations from the Workload Manager (WLM) component. WLM is described in 3.5, “What is workload management” on page 126. Chapter 3. z/OS overview 113
Slide 138: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am 3.4.7 What is storage protection Up to now, we have discussed virtual storage mostly in the context of a single user or program. In reality, of course, many programs and users are competing for the use of the system. z/OS uses the following techniques to preserve the integrity of each user’s work: A private address space for each user Page protection Low-address protection Multiple storage protect keys How storage protect keys are used Under z/OS, the information in central storage is protected from unauthorized use by means of multiple storage protect keys. A control field in storage called a key is associated with each 4 K frame of central storage. When a request is made to modify the contents of a central storage location, the key associated with the request is compared to the storage protect key. If the keys match or the program is executing in key 0, the request is satisfied. If the key associated with the request does not match the storage key, the system rejects the request and issues a program exception interruption. When a request is made to read (or fetch) the contents of a central storage location, the request is automatically satisfied unless the fetch protect bit is on, indicating that the frame is fetch-protected. When a request is made to access the contents of a fetch-protected central storage location, the key in storage is compared to the key associated with the request. If the keys match, or the requestor is in key 0, the request is satisfied. If the keys do not match, and the requestor is not in key 0, the system rejects the request and issues a program exception interruption. 114 Introduction to the New Mainframe: z/OS Basics
Slide 139: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm How storage protect keys are assigned z/OS uses 16 storage protect keys. A specific key is assigned according to the type of work being performed. As Figure 3-9 shows, the key is stored in bits 8 through 11 of the program status word (PSW). A PSW is assigned to each job in the system. Control Information bits 0 to 32 Key P Instruction address Problem state bit 15 = '1'b PSW key – 0 to 15 bits 8 to 11 Figure 3-9 Location of the storage protect key Storage protect keys 0 through 7 are used by the z/OS base control program (BCP) and various subsystems and middleware products. Storage protect key 0 is the master key. Its use is restricted to those parts of the BCP that require almost unlimited store and fetch capabilities. In almost any situation, a storage protect key of 0 associated with a request to access or modify the contents of a central storage location means that the request will be satisfied. Storage protect keys 8 through 15 are assigned to users. Because all users are isolated in private address spaces, most users (those whose programs run in a virtual region) can use the same storage protect key. These users are called V=V (virtual = virtual) users and are assigned a key of 8. Some users, however, must run in a central storage region. These users are known as V=R (virtual = real) users and require individual storage protect keys because their addresses are not protected by the DAT process that keeps each address space distinct. Without separate keys, V=R users might reference each other’s code and data. These keys are in the range of 9 through 15. 3.4.8 Role of storage managers Central storage frames and auxiliary storage slots, and the virtual storage pages that they support, are managed by separate components of z/OS. These components are known as the real storage manager (not central storage manager), the auxiliary storage manager, and the virtual storage manager. Here, we describe the role of each briefly. Chapter 3. z/OS overview 115
Slide 140: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am Real storage manager The real storage manager (RSM) keeps track of the contents of central storage. It manages the paging activities described earlier, such as page-in, page-out, and page stealing, and helps with swapping an address space in or out. RSM also performs page fixing (marking pages as unavailable for stealing). Auxiliary storage manager The auxiliary storage manager (ASM) uses the system’s page data sets, to keep track of auxiliary storage slots, specifically: Slots for virtual storage pages that are not in central storage frames. Slots for pages that do not occupy frames, but, because the frame’s contents have not been changed, the slots are still valid. When a page-in or page-out is required, ASM works with RSM to locate the proper central storage frames and auxiliary storage slots. Virtual storage manager The virtual storage manager (VSM) responds to requests to obtain and free virtual storage. VSM also manages storage allocation for any program that must run in real storage, rather than virtual storage. Real storage is allocated to code and data when they are loaded in virtual storage. As they run, programs can request more storage by means of a system service, such as the GETMAIN macro. Programs can release storage by using the FREEMAIN macro. VSM keeps track of the map of virtual storage for each address space. It sees an address space as a collection of 256 subpools, which are logically related areas of virtual storage identified by the numbers 0 to 255. Being logically related means the storage areas within a subpool share characteristics, such as: Storage protect key Whether they are fetch protected, pageable, or swappable Where they must reside in virtual storage (above or below 16 MB) Whether they can be shared by more than one task Some subpools (numbers 128 to 255) are predefined by use by system programs. Subpool 252, for example, is for programs from authorized libraries. Others (numbered 0 to 127) are defined by user programs. Attention: Every address space has the same virtual storage mapping. z/OS creates a segment table for each address space. 116 Introduction to the New Mainframe: z/OS Basics
Slide 141: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm 3.4.9 A brief history of virtual storage and 64-bit addressability Addressability: A program's ability to reference all of the storage associated with an address space. In 1970, IBM introduced System/370 (S/370), the first of its architectures to use virtual storage and address spaces. Since that time, the operating system has changed in many ways. One key area of growth and change is addressability. A program running in an address space can reference all of the storage associated with that address space. In this text, a program's ability to reference all of the storage associated with an address space is called addressability. S/370 defined storage addresses as 24 bits in length, which meant that the highest accessible address was 16,777,215 bytes (or 224-1 bytes).16 The use of 24-bit addressability allowed MVS/370, the operating system at that time, to allot to each user an address space of 16 MB. Over the years, as MVS/370 gained more functions and was asked to handle more complex applications, even access to 16 MB of virtual storage fell short of user needs. With the release of the System/370-XA architecture in 1983, IBM extended the addressability of the architecture to 31 bits. With 31-bit addressing, the operating system (now called MVS Extended Architecture (MVS/XA)) increased the addressability of virtual storage from 16 MB to 2 GB. In other words, MVS/XA provided an address space for users that was 128 times larger than the address space provided by MVS/370. The 16 MB address became the dividing point between the two architectures and is commonly called the line (see Figure 3-10 on page 117). 2GB The “Bar” 31-bit addressing (MVS/XA) 24-bit addressing (MVS) The “Line” 16 MB Figure 3-10 31-bit addressability allows for 2 GB address spaces in MVS/XA 16 Addressing starts with 0, so the last address is always one less than the total number of addressable bytes. Chapter 3. z/OS overview 117
Slide 142: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am The new architecture did not require customers to change existing application programs. To maintain compatibility for existing programs, MVS/XA remained compatible for programs originally designed to run with 24-bit addressing on MVS/370, while allowing application developers to write new programs to use the 31-bit technology. To preserve compatibility between the different addressing schemes, MVS/XA did not use the high-order bit of the address (Bit 0) for addressing. Instead, MVS/XA reserved this bit to indicate how many bits would be used to resolve an address: 31-bit addressing (Bit 0 on) or 24-bit addressing (Bit 0 off). With the release of IBM eServer zSeries mainframes in 2000, IBM further extended the addressability of the architecture to 64 bits. With 64-bit addressing, the potential size of a z/OS address space expands to a size so vast we need new terms to describe it. Each address space, called a 64-bit address space, is 16 EB in size (an exabyte is slightly more than one billion gigabytes). 118 Introduction to the New Mainframe: z/OS Basics
Slide 143: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm The new address space has logically 264 addresses. It is 8 billion times the size of the former 2 GB address space, or 18,446,744,073,709,600,000 bytes (Figure 3-11 on page 119). 16 EB 64-bit addressing (z/OS) 2GB The “Bar” 31-bit addressing (MVS/XA) 24-bit addressing (MVS) The “Line” 16 MB Figure 3-11 64-bit addressability allows for 16 EB of addressable storage We say that the potential size is 16 EB because z/OS, by default, continues to create address spaces with a size of 2 GB. The address space exceeds this limit only if a program running in it allocates virtual storage above the 2 GB address. If so, z/OS increases the storage available to the user from 2 GB to 16 EB. Chapter 3. z/OS overview 119
Slide 144: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am A program running on z/OS and the zSeries mainframe can run with 24-, 31-, or 64-bit addressing (and can switch among these if needed). To address the high virtual storage available with the 64-bit architecture, the program uses 64-bit-specific instructions. Although the architecture introduces the unique 64-bit instructions, the program can use both 31-bit and 64-bit instructions as needed. For compatibility, the layout of the storage areas for an address space is the same below 2 GB, providing an environment that can support both 24-bit and 31-bit addressing. The area that separates the virtual storage area below the 2 GB address from the user private area is called the bar, as shown in Figure 3-12. The user private area is allocated for application code rather than operating system code. 16 exabytes User Extended Private Area 512 terabytes Shared Area 2 terabytes User Extended Private Area 2 gigabytes The “Bar” 16 megabyte Common Area User Private Area The “Line” 0 Figure 3-12 Storage map for a 64-bit address space 0 to 231 231 to 232 The layout is the same; see Figure 3-12. From 2 GB to 4 GB is considered the bar. Below the bar can be addressed with a 31-bit address. Above the bar requires a 64-bit address. 120 Introduction to the New Mainframe: z/OS Basics
Slide 145: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm 232 - 241 241 - 250 250 - 264 The low non-shared area (user private area) starts at 4 GB and extends to 241 . Shared area (for storage sharing) starts at 241 and extends to 250 or higher, if requested. High non-shared area (user private area) starts at 250 or wherever the shared area ends, and goes to 264 . In a 16 EB address space with 64-bit virtual storage addressing, there are three additional levels of translation tables, called region tables: region third table (R3T), region second table (R2T), and region first table (R1T). The region tables are 16 KB in length, and there are 2048 entries per table. Each region has 2 GB. Segment tables and page table formats remain the same as for virtual addresses below the bar. When translating a 64-bit virtual address, after the system has identified the corresponding 2 GB region entry that points to the Segment table, the process is the same as that described previously. 3.4.10 What is meant by below-the-line storage z/OS programs and data reside in virtual storage that, when necessary, is backed by central storage. Most programs and data do not depend on their real addresses. Some z/OS programs, however, do depend on real addresses and some require these real addresses to be less than 16 MB. z/OS programmers refer to this storage as being “below the 16 MB line.” In z/OS, a program’s attributes include one called residence mode (RMODE), which specifies whether the program must reside (be loaded) in storage below 16 MB. A program with RMODE(24) must reside below 16 MB, while a program with RMODE(31) can reside anywhere in virtual storage. Examples of programs that require below-the-line storage include any program that allocates a data control block (DCB). Those programs, however, often can be 31-bit residency mode (RMODE(31)), as they can run in 31-bit addressing mode (AMODE(31)). z/OS reserves as much central storage below 16 MB as it can for such programs and, for the most part, handles their central storage dependencies without requiring them to make any changes. Thousands of programs in use today are AMODE(24) and therefore RMODE(24). Every program written before MVS/XA was available, and not subsequently changed, has that characteristic. There are relatively few reasons these days why a new program might need to be AMODE(24), so a new application likely has next to nothing that is RMODE(24). Chapter 3. z/OS overview 121
Slide 146: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am 3.4.11 What is in an address space Another way of thinking of an address space is as a programmer’s map of the virtual storage available for code and data. An address space provides each programmer with access to all of the addresses available through the computer architecture (earlier, we defined this characteristic as addressability). z/OS provides each user with a unique address space and maintains the distinction between the programs and data belonging to each address space. Because it maps all of the available addresses, however, an address space includes system code and data and user code and data. Thus, not all of the mapped addresses are available for user code and data. 122 Introduction to the New Mainframe: z/OS Basics
Slide 147: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm Understanding the division of storage areas in an address space is made easier with a diagram. The diagram shown in Figure 3-13 is more detailed than needed for this part of the course, but is included here to show that an address space maintains the distinction between programs and data belonging to the user, and those belonging to the operating system. Private Shared Area Low User Private High User Region Default Shared Memory Addressing Low User Region 16 EB 512TB 2TB 4G Reserved 2G Extended LSQA/SWA/229/230 Extended Private Extended User Region Extended CSA Extended Common Extended PLPA/FLPA/MLPA Extended SQA Extended Nucleus Nucleus SQA PLPA/FLPA/MLPA CSA LSQA/SWA/229/230 16 Mb Common Private User Region 24K System Region 8K 0 Common PSA Figure 3-13 Storage areas in an address space Chapter 3. z/OS overview 123
Slide 148: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am Figure 3-13 shows the major storage areas in each address space. These are described briefly as follows: All storage above 2 GB This area is called high virtual storage and is addressable only by programs running in 64-bit mode. It is divided by the high virtual shared area, which is an area of installation-defined size that can be used to establish cross-address space viewable connections to obtained areas within this area. Extended areas above 16 MB This range of areas, which lies above the line (16 MB) but below the bar (2 GB), is a kind of “mirror image” of the common area below 16 MB. They have the same attributes as their equivalent areas below the line, but because of the additional storage above the line, their sizes are much larger. Nucleus This is a key 0, read-only area of common storage that contains operating system control programs. System queue area (SQA) This area contains system level (key 0) data accessed by multiple address spaces. The SQA area is not pageable (fixed), which means that it resides in central storage until it is freed by the requesting program. The size of the SQA area is predefined by the installation and cannot change while the operating system is active. Yet it has the unique ability to “overflow” into the CSA area as long as there is unused CSA storage that can be converted to SQA. Pageable link pack area (PLPA), fixed link pack area (FLPA), and modified link pack area (MLPA) This area contains the link pack areas (the pageable link pack area, fixed link pack area, and modified link pack area), which contain system level programs that are often run by multiple address spaces. For this reason, the link pack areas reside in the common area that is addressable by every address space, therefore eliminating the need for each address space to have its own copy of the program. This storage area is below the line and is therefore addressable by programs running in 24-bit mode. CSA This portion of common area storage (addressable by all address spaces) is available to all applications. The CSA is often used to contain data frequently accessed by multiple address spaces. The size of the CSA area is established at system initialization time (IPL) and cannot change while the operating system is active. 124 Introduction to the New Mainframe: z/OS Basics
Slide 149: Draft Document for Review February 26, 2011 8:32 am Chap3 zos intro.fm LSQA/SWA/subpool 228/subpool 230 This assortment of subpools, each with specific attributes, is used primarily by system functions when the functions require address space level storage isolation. Being below the line, these areas are addressable by programs running in 24-bit mode. User Region This area is obtainable by any program running in the user’s address space, including user key programs. It resides below the line and is therefore addressable by programs running in 24-bit mode. System Region This small area (usually only four pages) is reserved for use by the region control task of each address space. Prefixed Save Area (PSA) This area is often referred to as “Low Core.” The PSA is a common area of virtual storage from address zero through 8191 in every address space. There is one unique PSA for every processor installed in a system. The PSA maps architecturally fixed hardware and software storage locations for the processor. Because there is a unique PSA for each processor, from the view of a program running on z/OS, the contents of the PSA can change any time the program is dispatched on a different processor. This feature is unique to the PSA area and is accomplished through a unique DAT manipulation technique called prefixing. Given the vast range of addressable storage in an address space, the drawing in Figure 3-13 on page 123 is not to scale. Each address space in the system is represented by an address space control block (ASCB). To represent an address space, the system creates an ASCB in common storage (system queue area (SQA)), which makes it accessible to other address spaces. 3.4.12 System address spaces and the master scheduler Many z/OS system functions run in their own address spaces. The master scheduler subsystem, for example, runs in the address space called *MASTER* and is used to establish communication between z/OS and its own address spaces. When you start z/OS, master initialization routines initialize system services, such as the system log and communication task, and start the master scheduler address space. Then, the master scheduler may start the job entry subsystem (JES2 or JES3). JES is the primary job entry subsystem. Chapter 3. z/OS overview 125
Slide 150: Chap3 zos intro.fm Draft Document for Review February 26, 2011 8:32 am On many production systems JES is not started immediately; instead, the automation package starts all tasks in a controlled sequence. Then other subsystems are started. Subsystems are defined in a special file of system settings called a parameter library (PARMLIB). These subsystems are secondary subsystems. Each address space created has a number associated with it, called the address space ID (ASID). Because the master scheduler is the first address space created in the system, it becomes address space number 1 (ASID=1). Other system address spaces are then started during the initialization process of z/OS. At this point, you need only understand that z/OS and its related subsystems require address spaces of their own to provide a functioning operating system. A short description of each type of address space follows: System z/OS system address spaces are started after initialization of the master scheduler. These address spaces perform functions for all the other types of address spaces that start in z/OS. Subsystem z/OS requires the use of various subsystems, such as a primary job entry subsystem (JES) (described in Chapter 7, “Batch processing and JES” on page 269). Also, there are address spaces for middleware products, such as DB2, CICS, and IMS. Besides system address spaces, there are, of course, typically many address spaces for users and separately running programs, for example: TSO/E address spaces are created for every user who logs on to z/OS (described in Chapter 4, “TSO/E, ISPF, and UNIX: Interactive facilities of z/OS” on page 165). An address space is created for every batch job that runs on z/OS. Batch job address spaces are started by JES. 3.5 What is workload management For z/OS, the management of system resources is the responsibility of the workload management (WLM) component. WLM manages the processing of workloads in the system according to the company’s business goals, such as response time. WLM also manages the use of system resources, such as processors and storage, to accomplish these goals. 126 Introduction to the New Mainframe: z/OS Basics

   
Time on Slide Time on Plick
Slides per Visit Slide Views Views by Location