z/OS

Version 2 Release 3

MVS System Commands

IBM

SA38-0666-30
 Note
Before using this information and the product it supports, read the information in “Notices” on page
803.

This edition applies to Version 2 Release 3 of z/OS (5650-ZOS) and to all subsequent releases and modifications until
otherwise indicated in new editions.
Last updated: 2019-06-24
© Copyright International Business Machines Corporation 1988, 2018.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with
IBM Corp.
Contents

Figures............................................................................................................... xiii

Tables..................................................................................................................xv

About this information........................................................................................ xix

Who should use this information.............................................................................................................. xix
How to use this information...................................................................................................................... xix
z/OS information........................................................................................................................................xix

How to send your comments to IBM.....................................................................xxi

If you have a technical problem................................................................................................................ xxi

Summary of changes......................................................................................... xxiii

Summary of changes in z/OS Version 2 Release 3 (V2R3)..................................................................... xxiii
Summary of changes for z/OS Version 2 Release 2 (V2R2) as updated December 2016......................xxv
Summary of changes for z/OS Version 2 Release 2 (V2R2) as updated June 2016.............................. xxv
Summary of changes for z/OS Version 2 Release 2 (V2R2) as updated March 2016............................ xxv
Summary of changes for z/OS Version 2 Release 2 (V2R2) as updated December 2015......................xxv
Summary of changes in z/OS Version 2 Release 2 (V2R2)..................................................................... xxvi
Summary of changes for z/OS Version 2 Release 1 (V2R1), as updated February 2015..................... xxvii
Summary of changes for z/OS Version 2 Release 1 (V2R1), as updated March 2014.......................... xxix
z/OS Version 2 Release 1 summary of changes......................................................................................xxix

Chapter 1. System operations................................................................................ 1

Starting, loading, and initializing the system.............................................................................................. 2
Starting the system.................................................................................................................................2
Preparing the system hardware............................................................................................................. 3
Loading the system software................................................................................................................. 3
Initializing the system software............................................................................................................. 6
Logging on to the system........................................................................................................................7
Starting and specifying parameters for the job entry subsystem......................................................... 9
Controlling the system................................................................................................................................. 9
Displaying current system status........................................................................................................... 9
Displaying the status of devices and availability of paths..................................................................... 9
Sending commands to systems in a sysplex....................................................................................... 10
Using commands that have sysplex scope.......................................................................................... 10
Sharing system commands.................................................................................................................. 13
Setting the time and changing the system parameters...................................................................... 17
Using the system restart function........................................................................................................17
Responding to IEA502A.......................................................................................................................18
Responding to BLW004A..................................................................................................................... 18
Activating a workload management service policy............................................................................. 19
Controlling time-sharing............................................................................................................................19
Controlling jobs.......................................................................................................................................... 19
Starting a job.........................................................................................................................................20
Stopping a job.......................................................................................................................................20
Cancelling a job.................................................................................................................................... 20
Passing information to a job.................................................................................................................20
Restarting a job.....................................................................................................................................20

iii
 Deferred restart.................................................................................................................................... 21
Controlling started tasks............................................................................................................................21
Controlling system information recording.................................................................................................22
System management facilities.............................................................................................................22
System trace.........................................................................................................................................23
The generalized trace facility............................................................................................................... 24
Master trace..........................................................................................................................................24
Component trace..................................................................................................................................24
Logrec recording medium.................................................................................................................... 24
Controlling automatic tape switching........................................................................................................24
Defining automatically switchable devices......................................................................................... 25
Displaying information about automatically switchable devices........................................................25
Interacting with system functions.............................................................................................................26
Device allocation.................................................................................................................................. 26
Hot I/O detection..................................................................................................................................28
Device boxing....................................................................................................................................... 28
Command flooding.....................................................................................................................................32
Class M1 commands............................................................................................................................ 32
Class M2 commands............................................................................................................................ 33
Class M3 commands............................................................................................................................ 35
Class C1 commands............................................................................................................................. 35
Class C2 commands............................................................................................................................. 35
Class C3 commands............................................................................................................................. 35
Inline commands..................................................................................................................................35
Setting up hardware event data collection............................................................................................... 36
Accessing the output from a hardware event data collection run............................................................39
Interpreting the z/OS UNIX system services output files................................................................... 41
HISSERV service overview.........................................................................................................................46
Bypassing HIS to exploit the CPU Measurement Facility......................................................................... 46
Responding to failing devices.................................................................................................................... 47
Quiescing the system.................................................................................................................................48
Stopping the system.................................................................................................................................. 48
Recovery from hardware problems........................................................................................................... 48
Hardware problems..............................................................................................................................48
Information provided with machine checks........................................................................................ 49
CPU errors.............................................................................................................................................49
Service processor damage................................................................................................................... 52
Storage errors.......................................................................................................................................52
Channel subsystem errors................................................................................................................... 53
I/O device errors...................................................................................................................................56
Diagnosing problems in a switched fabric........................................................................................... 64
Additional recovery actions..................................................................................................................77

Chapter 2. System Reconfiguration...................................................................... 79

Dynamic I/O configuration.........................................................................................................................79
Logical and physical reconfiguration......................................................................................................... 80
Reconfiguration support according to processor types............................................................................80
Uniprocessor (UP)................................................................................................................................ 80
Multiprocessor (MP)............................................................................................................................. 80
Reconfiguring a central processor.............................................................................................................80
Actions to reconfigure a central processor offline.............................................................................. 80
Reconfiguring a central processor with an ICRF................................................................................. 81
Actions to bring online a central processor and its ICRF.................................................................... 81
Removing the last ICRF........................................................................................................................82
Actions to take offline a central processor and its ICRF..................................................................... 82
Reconfiguring central storage....................................................................................................................82
Physical view of central storage...........................................................................................................82

iv
 Specifying the RSU parameter............................................................................................................. 83
Reconfiguring channel paths..................................................................................................................... 86
Actions to reconfigure channel paths.................................................................................................. 86
Reconfiguring I/O devices..........................................................................................................................87
Reconfiguring a coupling facility................................................................................................................87

Chapter 3. z/OS operator console operations........................................................ 89

Console characteristics and operations.................................................................................................... 89
General characteristics of display consoles........................................................................................ 89
Operations on display consoles in full-capability mode..................................................................... 93
Handling consoles in error conditions............................................................................................... 101
Placing a console in offline status..................................................................................................... 105
Interchanging your consoles on a control unit..................................................................................105
Defining and changing console characteristics...................................................................................... 105
Using operator commands to change CONSOLxx statements......................................................... 105
Changing console characteristics...................................................................................................... 110
Controlling system messages and commands..................................................................................125
Defining program function keys (PFKs)............................................................................................. 131
Processing hardcopy.......................................................................................................................... 134

Chapter 4. MVS system commands reference......................................................137

Command syntax notation...................................................................................................................... 151
How to read syntax conventions........................................................................................................151
System command formats...................................................................................................................... 153
Typical format.....................................................................................................................................153
A second format................................................................................................................................. 154
ACTIVATE command................................................................................................................................154
Restrictions........................................................................................................................................ 154
Syntax................................................................................................................................................. 154
Parameters......................................................................................................................................... 155
CANCEL command...................................................................................................................................158
Syntax................................................................................................................................................. 159
Parameters......................................................................................................................................... 159
CHNGDUMP command............................................................................................................................ 163
Dump options and modes.................................................................................................................. 163
Changing the dump mode and options..............................................................................................163
Scope in a sysplex.............................................................................................................................. 164
Syntax variations for CHNGDUMP..................................................................................................... 164
Removing options from or resetting the system dump options lists................................................ 164
Parameters......................................................................................................................................... 164
Options for SDUMP, SYSABEND, SYSUDUMP, and SYSMDUMP........................................................ 166
Resetting dump mode to add and the dump options to initial values.............................................. 172
Example: How CHNGDUMP commands affect dump modes and options....................................... 172
Setting the dump modes and options............................................................................................... 174
CMDS command...................................................................................................................................... 183
Syntax................................................................................................................................................. 183
Parameters......................................................................................................................................... 184
CONFIG command...................................................................................................................................186
Syntax................................................................................................................................................. 186
Reconfiguring the system directly..................................................................................................... 186
Reconfiguring the system with a CONFIGxx parmlib member......................................................... 197
Reconfiguring the system in response to a configuration display.................................................... 197
CONTROL command................................................................................................................................ 198
Scope in a sysplex.............................................................................................................................. 200
Syntax................................................................................................................................................. 200
Changing out of line display area specifications............................................................................... 200
Deleting retained action messages................................................................................................... 201

v
 Halting the printing or the display of a status display.......................................................................202
Controlling displays in areas.............................................................................................................. 203
Removing information from the screen............................................................................................. 204
Activating, deactivating, or displaying the status of the action message retention facility.............205
Changing or displaying the number of allowed WTL SYSLOG buffers.............................................. 206
Changing or displaying the number of allowed WTO and WTOR message buffers..........................206
Changing the time the system waits for ROUTE command responses............................................ 207
Increasing the maximum number of reply IDs................................................................................. 208
Changing or displaying the status of WTO installation exit IEAVMXIT ............................................ 208
Displaying the SMCS APPLID of the current system and VTAM generic resource name for SMCS. 209
Setting the APPLID of the system......................................................................................................209
Setting or turning off the VTAM generic resource name for SMCS................................................... 210
Changing a PFK definition.................................................................................................................. 211
Deleting message queues..................................................................................................................213
Changing or displaying message deletion and format specifications.............................................. 213
Changing the operating mode of a console....................................................................................... 217
Selecting the message levels for a console.......................................................................................217
DEVSERV command.................................................................................................................................219
Using the DEVSERV QDASD option.................................................................................................... 220
Using the DEVSERV QTAPE option.....................................................................................................220
Using the DEVSERV QPAVS option.....................................................................................................221
Using the DEVSERV QLIB option........................................................................................................221
Syntax................................................................................................................................................. 221
Parameters......................................................................................................................................... 222
DISPLAY command..................................................................................................................................239
Scope in a sysplex.............................................................................................................................. 242
Syntax................................................................................................................................................. 243
Displaying MVS device allocation group locks information.............................................................. 244
Displaying MVS device allocation settings information.................................................................... 244
Displaying MVS device allocation IGDE information.........................................................................245
Displaying APPC/MVS information.................................................................................................... 246
Displaying ASCH configuration information...................................................................................... 250
Displaying auxiliary storage information........................................................................................... 252
Displaying auto-reply policy and WTORs information...................................................................... 254
Displaying the current system-level Language Environment runtime options................................ 255
Displaying CONTROL command functions........................................................................................ 257
Displaying attached coupling facility information............................................................................. 257
Displaying console group definitions.................................................................................................258
Displaying console status information.............................................................................................. 258
Displaying DIAG parmlib information................................................................................................262
Displaying data lookaside facility information.................................................................................. 263
Displaying dump options or dump data set status............................................................................265
Displaying extended MCS information.............................................................................................. 268
Displaying the timer synchronization mode and ETR ports.............................................................. 273
Displaying function enablement state information .......................................................................... 274
Displaying global resource serialization information........................................................................ 276
Displaying Generic Tracker information............................................................................................ 288
Displaying hardware event data collection status............................................................................ 295
Displaying Basic HyperSwap information......................................................................................... 298
Displaying ICSF information.............................................................................................................. 299
Displaying the data set optimization configuration...........................................................................299
Displaying TSO/E parmlib information.............................................................................................. 302
Displaying I/O configuration information.......................................................................................... 303
Displaying captured UCB information............................................................................................... 304
Displaying IOS control unit group information..................................................................................304
Displaying dynamic channel path management information........................................................... 305
Displaying encryption key manager (EKM) status.............................................................................305
Displaying zHPF facility status...........................................................................................................307

vi
 Displaying FICON switch data information....................................................................................... 307
Displaying IOS group information......................................................................................................307
Displaying IOS HYPERPAV information............................................................................................. 308
Displaying the IBM zHyperWrite data replication status.................................................................. 308
Displaying MIDAW facility status.......................................................................................................308
Displaying MIH and I/O timing limits.................................................................................................309
Displaying IOS recovery options .......................................................................................................312
Displaying the IOSSPOF system service options ............................................................................. 312
Displaying IOS storage residency information.................................................................................. 312
Displaying the devices stopped by the IOACTION command.......................................................... 313
Displaying the current status of the zHyperLink facility................................................................... 313
Displaying IPL information.................................................................................................................313
Displaying PCIE-related parameters................................................................................................. 315
Displaying system activity..................................................................................................................315
Displaying started task status........................................................................................................... 324
Displaying library lookaside information........................................................................................... 326
Displaying the system logger and its log streams............................................................................. 328
Displaying the logrec recording medium...........................................................................................337
Displaying system configuration information....................................................................................338
Displaying message flood automation information.......................................................................... 345
Displaying MVS message service status and languages................................................................... 346
Displaying message suppression, retention, color, intensity, and highlighting options...................347
Displaying OAM component information...........................................................................................348
Displaying status of z/OS UNIX System Services .............................................................................349
Displaying operator information (OPDATA)....................................................................................... 368
Displaying PCIE information.............................................................................................................. 369
Displaying PARMLIB information.......................................................................................................369
Displaying commands defined for PFKs............................................................................................372
Displaying PPTs.................................................................................................................................. 373
Displaying registered products.......................................................................................................... 375
Displaying entries in the list of APF-authorized libraries..................................................................376
Displaying PROG defaults.................................................................................................................. 377
Displaying dynamic exits....................................................................................................................378
Displaying LNKLST information......................................................................................................... 380
Displaying LPA information................................................................................................................ 381
Displaying the status of the REFRPROT option................................................................................. 381
Displaying the status of the TRACKDIRLOAD option........................................................................ 382
Displaying system requests............................................................................................................... 382
Displaying resource recovery services (RRS) information................................................................ 387
Displaying SLIP trap information....................................................................................................... 390
Displaying SMF data...........................................................................................................................391
Displaying the in-storage copy of the SMF limits.............................................................................. 392
Displaying storage management subsystem information.................................................................395
Displaying information about all subsystems................................................................................... 411
Displaying static system symbols......................................................................................................414
Displaying the local and coordinated universal time and date......................................................... 415
Displaying component or transaction trace status........................................................................... 415
Displaying device status and allocation............................................................................................ 419
Displaying Unicode services.............................................................................................................. 421
Displaying virtual storage information...............................................................................................424
Displaying workload manager information........................................................................................424
Displaying cross system coupling facility (XCF) information............................................................ 430
DUMP command...................................................................................................................................... 441
Wildcards............................................................................................................................................441
Syntax................................................................................................................................................. 441
Parameters......................................................................................................................................... 442
Specifying dump options................................................................................................................... 443
DUMPDS command..................................................................................................................................459

vii
 Syntax................................................................................................................................................. 460
Adding system dump resources........................................................................................................ 460
Enabling and disabling automatic dump data set allocation............................................................ 463
Making dump data sets ready to receive dumps...............................................................................464
Deleting system dump resources...................................................................................................... 464
Setting the name-pattern for dump data sets...................................................................................466
FORCE command..................................................................................................................................... 467
Considerations................................................................................................................................... 468
Syntax................................................................................................................................................. 469
Parameters......................................................................................................................................... 469
HALT command........................................................................................................................................471
Syntax................................................................................................................................................. 472
IOACTION command............................................................................................................................... 472
Syntax................................................................................................................................................. 472
Parameters......................................................................................................................................... 473
LIBRARY command................................................................................................................................. 474
LOG command......................................................................................................................................... 474
Syntax................................................................................................................................................. 474
Parameters......................................................................................................................................... 474
LOGOFF command...................................................................................................................................474
Syntax................................................................................................................................................. 474
LOGON command.................................................................................................................................... 475
Syntax................................................................................................................................................. 476
Parameters......................................................................................................................................... 476
MODE command...................................................................................................................................... 477
Syntax................................................................................................................................................. 478
Controlling the recording of hard machine check interruptions....................................................... 480
Controlling the recording of system recovery and degradation machine check interruptions........481
Displaying recording and monitoring status......................................................................................483
MODIFY command...................................................................................................................................483
Summary of MODIFY..........................................................................................................................483
Using asterisks in MODIFY commands..............................................................................................485
MODIFY command syntax................................................................................................................. 486
Syntax................................................................................................................................................. 486
Parameters......................................................................................................................................... 487
Passing information to a z/OS UNIX System Services application................................................... 488
Controlling the CIM server................................................................................................................. 488
Modifying TSO/VTAM time sharing.................................................................................................... 489
Communicating with System REXX................................................................................................... 490
Controlling z/OS UNIX System Services (z/OS UNIX)....................................................................... 492
Communicating with the catalog address space.............................................................................. 498
Processing the common event adapter (CEA) parameters...............................................................498
Refreshing the common event adapter (CEA) component information........................................... 499
Displaying the common event adapter (CEA) component TSO/E address space information........ 499
Managing common event adapter (CEA) REXX exec tracing ............................................................500
Displaying the common event adapter (CEA) environment.............................................................. 500
Disconnecting the common event adapter (CEA) from the IPCS sysplex dump directory data set 502
Adjusting the common event adapter (CEA) mode of operation...................................................... 502
Communicating with the device manager address space................................................................ 503
Changing the DLF processing mode.................................................................................................. 507
Changing the DLF parameters........................................................................................................... 507
Displaying DLF status.........................................................................................................................508
Starting, configuring, and stopping hardware event data collection................................................508
Building and replacing library lookaside directories.........................................................................519
Operating with the network file system server................................................................................. 520
Managing the object access method (OAM)...................................................................................... 520
Recycling z/OS UNIX System Services (z/OS UNIX)......................................................................... 520
Dynamically activating maintenance for z/OS UNIX System Services (z/OS UNIX)........................ 521

viii
 Stopping a physical file system (PFS) through a logical file system (LFS) interface........................ 522
Passing a MODIFY command string to a physical file system (PFS) through a logical file system
(LFS).............................................................................................................................................. 522
Replacing the sysplex root file system in the shared file system configuration (z/OS UNIX)..........523
Stopping a temporary file system (TFS)............................................................................................ 524
Changing the virtual lookaside facility (VLF) parameters................................................................. 524
Enabling and disabling the Application Response Measurement (ARM) services........................... 524
Changing workload manager resource states................................................................................... 525
Specifying data set selection criteria for an external writer............................................................. 525
Causing an external writer to pause.................................................................................................. 527
MODIFY (F) JES3 commands.............................................................................................................529
MONITOR command................................................................................................................................529
Scope in a sysplex.............................................................................................................................. 530
Syntax................................................................................................................................................. 530
Parameters......................................................................................................................................... 530
MOUNT command................................................................................................................................... 531
Scope in a sysplex.............................................................................................................................. 531
Syntax................................................................................................................................................. 531
Parameters......................................................................................................................................... 531
Tape library dataserver considerations............................................................................................. 532
Tape multi-volume considerations.................................................................................................... 532
PAGEADD command................................................................................................................................ 533
Syntax................................................................................................................................................. 534
Parameters......................................................................................................................................... 534
PAGEDEL command.................................................................................................................................534
Syntax................................................................................................................................................. 535
Parameters......................................................................................................................................... 535
QUIESCE command................................................................................................................................. 536
Syntax................................................................................................................................................. 537
REPLY command......................................................................................................................................537
Using system symbols in REPLY commands..................................................................................... 538
Scope in a sysplex.............................................................................................................................. 538
Syntax................................................................................................................................................. 538
Replying to system information requests..........................................................................................538
Replying to system requests during recovery processing.................................................................539
Replying to system security WTORs.................................................................................................. 539
Setting the time-of-day clock............................................................................................................ 539
Specifying component trace options................................................................................................. 541
Specifying dump options................................................................................................................... 541
Specifying SMF options......................................................................................................................542
Specifying system parameters.......................................................................................................... 542
RESET command..................................................................................................................................... 543
Scope in a sysplex.............................................................................................................................. 544
Syntax................................................................................................................................................. 544
Forcing a hung console offline or freeing console resources............................................................544
Changing service classes or quiescing work..................................................................................... 545
ROUTE command.....................................................................................................................................547
Restrictions........................................................................................................................................ 547
How MVS displays aggregated response from ROUTE..................................................................... 548
Using system symbols in ROUTE commands.................................................................................... 549
Syntax................................................................................................................................................. 549
Parameters......................................................................................................................................... 550
SEND command....................................................................................................................................... 553
Scope in a sysplex.............................................................................................................................. 554
Syntax................................................................................................................................................. 554
Communicating with other operators................................................................................................554
Communicating with specified users.................................................................................................555
Communicating with all logged-on terminal users........................................................................... 556

ix
 Saving messages in the broadcast data set...................................................................................... 557
Listing the notices section of the broadcast data set....................................................................... 558
Deleting a message from the broadcast data set (notices section)................................................. 558
SET command.......................................................................................................................................... 559
Scope in a sysplex.............................................................................................................................. 560
Syntax................................................................................................................................................. 561
Parameters......................................................................................................................................... 562
SETALLOC command............................................................................................................................... 571
Syntax................................................................................................................................................. 571
Parameters......................................................................................................................................... 573
SETAPPC command................................................................................................................................. 582
Syntax................................................................................................................................................. 583
Parameters......................................................................................................................................... 583
SETAUTOR command.............................................................................................................................. 587
Syntax................................................................................................................................................. 587
Parameters......................................................................................................................................... 588
Examples............................................................................................................................................ 588
SETCEE command................................................................................................................................... 588
Syntax................................................................................................................................................. 588
Parameters......................................................................................................................................... 589
SETCON command...................................................................................................................................589
Scope in a sysplex.............................................................................................................................. 590
Syntax................................................................................................................................................. 590
Parameters......................................................................................................................................... 590
SETETR command................................................................................................................................... 590
Syntax................................................................................................................................................. 591
Parameters......................................................................................................................................... 591
SETFXE command................................................................................................................................... 591
Syntax................................................................................................................................................. 591
Parameters......................................................................................................................................... 591
SETGRS command................................................................................................................................... 593
Syntax................................................................................................................................................. 593
Parameters......................................................................................................................................... 593
SETGTZ command................................................................................................................................... 597
Syntax................................................................................................................................................. 597
SETGTZ TRACKING command........................................................................................................... 598
SETGTZ CLEAR command.................................................................................................................. 598
SETGTZ EXCLUDE command............................................................................................................. 598
SETGTZ DEBUG command................................................................................................................. 603
SETGTZ DIAGNOSE command...........................................................................................................604
SETGTZ PERSIST command.............................................................................................................. 604
SETHS command..................................................................................................................................... 605
Syntax................................................................................................................................................. 605
SETICSF command.................................................................................................................................. 606
SETIOS command....................................................................................................................................607
Syntax................................................................................................................................................. 607
Parameters......................................................................................................................................... 609
SETLOAD command.................................................................................................................................617
Syntax................................................................................................................................................. 617
SETLOGRC command.............................................................................................................................. 618
SETOMVS command................................................................................................................................ 619
Syntax................................................................................................................................................. 619
Parameters......................................................................................................................................... 620
SETPROG command................................................................................................................................ 630
Updating dynamic exits......................................................................................................................631
Updating LNKLST concatenations..................................................................................................... 635
Tracking directed load modules........................................................................................................ 639
SETSMF command...................................................................................................................................639

x
SETSMS command...................................................................................................................................639
Parameters......................................................................................................................................... 641
SETSSI command.................................................................................................................................... 654
SETUNI command................................................................................................................................... 654
Parameters......................................................................................................................................... 654
SLIP command.........................................................................................................................................665
Syntax................................................................................................................................................. 665
Using SLIP commands....................................................................................................................... 666
Processing of SLIP commands.......................................................................................................... 666
Coding SLIP command parameters................................................................................................... 666
Setting a SLIP trap..............................................................................................................................669
Modifying an existing SLIP trap......................................................................................................... 727
Deleting an existing SLIP trap............................................................................................................727
START command......................................................................................................................................727
Starting a system task from a console...............................................................................................728
Starting the APPC/MVS address space..............................................................................................732
Starting the APPC/MVS transaction scheduler address space.........................................................733
Starting the Common Event Adapter address space........................................................................ 733
Starting the Generalized Trace Facility..............................................................................................734
Starting IBM Generic Tracker for z/OS.............................................................................................. 735
Starting hardware instrumentation services (HIS) ...........................................................................736
Starting the Base Control Program internal interface (BCPii) address space after BCPii has
been terminated............................................................................................................................736
Starting IBM Health Checker for z/OS............................................................................................... 737
Starting the library lookaside (LLA) address space...........................................................................737
Starting the Object Access Method (OAM)........................................................................................ 738
Starting Resource Recovery Services (RRS)......................................................................................738
Starting the System Object Model (SOM) subsystem....................................................................... 739
Starting TSO/VTAM time-sharing.......................................................................................................740
Starting the virtual lookaside facility or data lookaside facility........................................................ 741
Starting an external writer................................................................................................................. 742
STOP command....................................................................................................................................... 743
Stopping a running program.............................................................................................................. 743
Stopping an ASCH initiator.................................................................................................................744
Stopping the data lookaside facility (DLF).........................................................................................744
Stopping the generalized tracking facility......................................................................................... 744
Stopping the hardware instrumentation services (HIS) ...................................................................744
Stopping the Base Control Program internal interface (BCPii) address space................................ 745
Stopping IBM Health Checker for z/OS............................................................................................. 745
Stopping the library lookaside (LLA) address space......................................................................... 746
Stopping the Object Access Method (OAM) Address Space............................................................. 746
Stopping a System Object Model (SOM)............................................................................................746
Stopping a temporary file system (TFS)............................................................................................ 747
Stopping the virtual lookaside facility (VLF)......................................................................................747
SWAP command...................................................................................................................................... 747
Operator-requested DDR................................................................................................................... 748
System-initiated DDR.........................................................................................................................749
TRACE command..................................................................................................................................... 749
Specifying TRACE CT options.............................................................................................................749
VARY command....................................................................................................................................... 751
Controlling problem determination mode for the system console...................................................753
Controlling hardcopy processing....................................................................................................... 754
Placing a console online or offline..................................................................................................... 757
Processing devices or a path to devices attached to a control unit..................................................758
Defining a tape device as automatically switchable......................................................................... 759
Placing an I/O device or a range of I/O devices online or offline......................................................759
Allowing or preventing allocation from using an offline tape device................................................763
Controlling a global resource serialization complex......................................................................... 764

xi
 Placing an I/O Path or Paths Online or Offline.................................................................................. 765
Changing the zHyperLink eligibility of a data set.............................................................................. 768
Changing the state of coupling facility cache structures and volumes............................................ 769
Placing an optical drive or library online or offline............................................................................771
Placing a system-managed tape library online or offline..................................................................772
Analyzing the state of the PDSE subsystem...................................................................................... 772
Releasing PDSE latches..................................................................................................................... 772
Modifying processing of PDSE monitor..............................................................................................772
Display current state of the PDSE monitor........................................................................................ 773
Changing the SMS status of a storage group or volume....................................................................773
Updating space statistics for volumes in the SMS configuration......................................................775
Controlling DFSMStvs processing......................................................................................................776
Placing a switch port online or offline............................................................................................... 783
Controlling an application environment............................................................................................ 784
Activating a service policy..................................................................................................................784
Removing a System from the XCF Sysplex........................................................................................ 785

Chapter 5. System REXX commands reference................................................... 789

Displaying real storage memory statistics.............................................................................................. 789

Appendix A. HIS MAP format............................................................................. 791

Appendix B. Accessibility...................................................................................799
Accessibility features.............................................................................................................................. 799
Consult assistive technologies................................................................................................................ 799
Keyboard navigation of the user interface.............................................................................................. 799
Dotted decimal syntax diagrams.............................................................................................................799

Notices..............................................................................................................803
Terms and conditions for product documentation................................................................................. 804
IBM Online Privacy Statement................................................................................................................ 805
Policy for unsupported hardware............................................................................................................805
Minimum supported hardware................................................................................................................ 806

Index................................................................................................................ 807

xii
Figures

1. Format of the LOAD parameter..................................................................................................................... 4

2. Example of a Successful Response to a DISPLAY AUTOSWITCH Command............................................ 26

3. Boxed device recovery procedure.............................................................................................................. 31

4. Data structure of a guest program parameter under a TCB.......................................................................45

5. Data structure of a guest program parameter under an SRB.....................................................................45

6. DASD Devices shared between two systems............................................................................................. 55

7. DASD device shared by three systems....................................................................................................... 64

8. Example of a switched fabric...................................................................................................................... 65

9. Example of source and destination directors.............................................................................................66

10. Example of static routing in a switched fabric......................................................................................... 67

11. Example of dynamic routing in a switched fabric.................................................................................... 67

12. Example of link aggregation......................................................................................................................68

13. Example of static routing with aggregate links........................................................................................ 71

14. Example of dynamic routing..................................................................................................................... 72

15. Comparison of the display screens of full-capability and output-only display consoles....................... 92

16. DISPLAY CONSOLES,BACKLOG command output.................................................................................104

17. DISPLAY CONSOLES,ROUT=5 command output................................................................................... 109

18. Format of a console screen in message stream mode.......................................................................... 124

19. Typical system command format........................................................................................................... 153

20. System command format required for some commands...................................................................... 154

21. Display output illustration (column descriptions)..................................................................................325

22. Display output from D A,WTOR (Membername).................................................................................... 325

23. Display output for D A,WTOR (Membername and Identifier)................................................................ 325

xiii
 24. Display output for D A,WTOR (Membername and JOBNAME).............................................................. 326

25. Display output from D A,SYM1............................................................................................................... 326

26. Display output from D A,SYMTEST......................................................................................................... 326

27. Display output from D A,SYMBOLS........................................................................................................ 326

28. Sample output for the DISPLAY SMFLIM,S command...........................................................................393

29. Sample output for the DISPLAY SMFLIM,R command.......................................................................... 394

30. Output of DISPLAY SMFLIM,R,MEMBER=SMFLIMU6,RULE=1 .............................................................394

31. DISPLAY SMS command syntax............................................................................................................. 396

32. Output for SET SMFLIM=(S1,S2,C) ........................................................................................................ 571

33. IEAVTSZR procedure example............................................................................................................... 677

xiv
Tables

1. Possible values for IMS characters............................................................................................................... 5

2. MVS system commands with sysplex scope.............................................................................................. 11

3. Correcting boxed conditions....................................................................................................................... 31

4. z/OS UNIX files generated by the HIS Profiler........................................................................................... 41

5. IBM Defaults for PFKs................................................................................................................................. 96

6. Checking the Commands Defined for Each PFK.........................................................................................96

7. Comparison of system commands and CONSOLE parameters in CONSOLxx.........................................106

8. Comparison of system commands and INIT statements in CONSOLxx..................................................107

9. Comparison of VARY HARDCPY commands and HARDCOPY statements in CONSOLxx........................ 108

10. Command groups used to determine command authority....................................................................111

11. MVS Commands, RACF Access Authorities, and Resource Names.......................................................112

12. Message Routing Codes..........................................................................................................................126

13. System command summary................................................................................................................... 138

14. Syntax conventions.................................................................................................................................152

15. Specifying FORCE with EMIF.................................................................................................................. 157

16. CANCEL Command Tasks....................................................................................................................... 158

17. Summary of common CHNGDUMP tasks............................................................................................... 163

18. Affects on the CSA storage captured in an SVC dump...........................................................................167

19. Example of how CHNGDUMP commands affect dump modes and options......................................... 172

20. Summary of the CONFIG Command...................................................................................................... 186

21. Summary of the CONTROL Command....................................................................................................199

22. Sysplex Scope for CONTROL Command.................................................................................................200

23. Summary of the DISPLAY command...................................................................................................... 239

xv
 24. Sysplex Scope for DISPLAY Command.................................................................................................. 242

25. Summary of the Display GTZ Command................................................................................................ 288

26. Displaying System Activity: Information for the LIST Operand.............................................................317

27. Displaying System Activity: Information for the ALL Operand.............................................................. 318

28. Displaying System Activity: Information for a Specific Name............................................................... 320

29. Examples of START Commands to Start Jobs........................................................................................322

30. Examples of DISPLAY Commands..........................................................................................................322

31. Affects on the CSA storage captured in an SVC dump...........................................................................448

32. Summary of the DUMPDS Command..................................................................................................... 459

33. FORCE command tasks...........................................................................................................................468

34. Summary of the MODE Command..........................................................................................................478

35. MODE parameters allowed for machine check interruptions................................................................479

36. Summary of the MODIFY command.......................................................................................................483

37. Examples of START commands to start jobs......................................................................................... 486

38. Examples of MODIFY commands........................................................................................................... 486

39. Possible Volume and Device Combinations on MOUNT Command.......................................................532

40. Summary of the REPLY Command..........................................................................................................537

41. Summary of the RESET Command......................................................................................................... 543

42. Summary of the SEND Command...........................................................................................................554

43. Sysplex Scope for SET Command...........................................................................................................560

44. Syntax for the SET command................................................................................................................. 561

45. Summary of the SETGTZ command....................................................................................................... 597

46. SETGTZ TRACKING command................................................................................................................598

47. SETGTZ CLEAR command.......................................................................................................................598

48. SETGTZ EXCLUDE command.................................................................................................................. 599

xvi
49. SETGTZ DEBUG command......................................................................................................................603

50. SETGTZ DIAGNOSE command............................................................................................................... 604

51. SETGTZ PERSIST command................................................................................................................... 605

52. One-character parameter limit multipliers............................................................................................ 620

53. Comparison of SET SMS with SETSMS................................................................................................... 641

54. Incorrect Combinations of SETSMS Parameters................................................................................... 641

55. Summary of the SLIP Command............................................................................................................ 665

56. Affects on the CSA storage captured in an SVC dump...........................................................................720

57. Summary of the START command..........................................................................................................727

58. Summary of the STOP Command........................................................................................................... 743

59. Summary of the SWAP Command.......................................................................................................... 748

60. Summary of the VARY Command........................................................................................................... 751

61. General map record header format........................................................................................................791

62. Type I - Information record.................................................................................................................... 791

63. Type B = Boundary record...................................................................................................................... 792

64. Type A = Address Space record .............................................................................................................793

65. Type M = Module record......................................................................................................................... 793

66. Type C= CSECT record............................................................................................................................ 795

67. Type E = Entry Point ............................................................................................................................... 797

xvii
xviii
About this information
This information describes how to use MVS™ system operator commands for the z/OS operating system.
Although you can also perform many of the tasks described in this information using JES2 or JES3
commands, this information describes only the MVS (base control program) system commands. For
information about commands for other z/OS elements, such as z/OS Communications Server (IP and
SNA), DFSMS, JES2, JES3, and RACF®, see z/OS Information Roadmap. For information about commands
for other software products that run on z/OS, see z/OS Software Products Collection, SK3T-4270.

Who should use this information

This information is intended for anyone using a console and system commands to control the operating
system. This information assumes that the user understands the hardware controls and features of the
installation. It also assumes that the user understands the general organization and functions of a z/OS
operating system.

How to use this information

To describe the basic tasks within these general tasks and to provide a convenient system commands
reference, this information is organized as follows:
• Chapter 1, “System operations,” on page 1, describes the tasks of running the system from the time
the system comes up to the time the system goes down for a normal or abnormal reason.
• Chapter 2, “System Reconfiguration,” on page 79, describes the reconfiguration actions of hardware
units and partitions. It also shows how to physically or logically reconfigure the hardware units of a
system; and for a partitionable processor complex, how to partition the complex into two sides or merge
the two sides together.
• Chapter 3, “z/OS operator console operations,” on page 89, describes the consoles that MVS supports
as operators' consoles. “Console characteristics and operations” on page 89 describes the operations
and characteristics that you cannot define, including the operations that are common on all operator's
consoles.“Defining and changing console characteristics” on page 105 describes the console
characteristics that you can define, including the commands that operators and system programmers
can use to tailor the consoles and console operations to the installation's requirements. “Defining and
changing console characteristics” on page 105 also describes how to restrict the use of system
commands based on which operator issues the command and/or which MCS, HMCS or SMCS console
the operator uses.
• Chapter 4, “MVS system commands reference,” on page 137, summarizes the function, syntax, and
parameters of all the MVS system commands that you can use to control the system.

z/OS information
This information explains how z/OS references information in other documents and on the web.
When possible, this information uses cross document links that go directly to the topic in reference using
shortened versions of the document title. For complete titles and order numbers of the documents for all
products that are part of z/OS, see z/OS Information Roadmap.
To find the complete z/OS® library, go to IBM Knowledge Center (www.ibm.com/support/
knowledgecenter/SSLTBW/welcome).

© Copyright IBM Corp. 1988, 2018 xix

xx z/OS: MVS System Commands
How to send your comments to IBM
We invite you to submit comments about the z/OS product documentation. Your valuable feedback helps
to ensure accurate and high-quality information.
Important: If your comment regards a technical question or problem, see instead “If you have a technical
problem” on page xxi.
Submit your feedback by using the appropriate method for your type of comment or question:
Feedback on z/OS function
If your comment or question is about z/OS itself, submit a request through the IBM RFE Community
(www.ibm.com/developerworks/rfe/).
Feedback on IBM® Knowledge Center function
If your comment or question is about the IBM Knowledge Center functionality, for example search
capabilities or how to arrange the browser view, send a detailed email to IBM Knowledge Center
Support at [email protected].
Feedback on the z/OS product documentation and content
If your comment is about the information that is provided in the z/OS product documentation library,
send a detailed email to [email protected]. We welcome any feedback that you have, including
comments on the clarity, accuracy, or completeness of the information.
To help us better process your submission, include the following information:
• Your name, company/university/institution name, and email address
• The following deliverable title and order number: z/OS MVS System Commands, SA38-0666-30
• The section title of the specific information to which your comment relates
• The text of your comment.
When you send comments to IBM, you grant IBM a nonexclusive right to use or distribute the comments
in any way appropriate without incurring any obligation to you.
IBM or any other organizations use the personal information that you supply to contact you only about the
issues that you submit.

If you have a technical problem

If you have a technical problem or question, do not use the feedback methods that are provided for
sending documentation comments. Instead, take one or more of the following actions:
• Go to the IBM Support Portal (support.ibm.com).
• Contact your IBM service representative.
• Call IBM technical support.

© Copyright IBM Corp. 1988, 2018 xxi

xxii z/OS: MVS System Commands
Summary of changes
This information includes terminology, maintenance, and editorial changes. Technical changes or
additions to the text and illustrations for the current edition are indicated by a vertical line to the left of
the change.

Summary of changes in z/OS Version 2 Release 3 (V2R3)

The following changes were made to this information in z/OS Version 2 Release 3 (V2R3).
The most recent changes are listed at the top of each section.

New
• Added new DEVSUP(FLASHCOPYTOXRC) keywords to the MODIFY DEVNAME command, and a new
FLASHCOPYTOXRC keyword to the MODIFY DEVMAN,ENABLE and MODIFY DEVMAN,DISABLE
commands. For details, see “Communicating with the device manager address space” on page 503.
• For APAR OA53111, new TPNAME parameter for SETLOGR MONITOR ZAI command. See Syntax and
Parameters.
• For APAR OA54822, updates to the following commands for zHyperLink storage support:
– New VARY SMS,DSNAME parameter in “Changing the zHyperLink eligibility of a data set” on page
768.
– Updated DISPLAY SMS,DSNAME parameter in “Displaying storage management subsystem
information” on page 395.
• New TVSAMCOM parameter on the SETSMS command, to enable DFSMStvs automatic commit and
specify the minimum and the maximum for a range of number of update requests that DFSMStvs uses.
For details, see “SETSMS command” on page 639.
• For APAR OA54279, updates to QHA option of DEVSERV QDASD command. See “QDASD or QD” on page
223.
• For APAR OA34502, updates to DISPLAY U. See “Displaying device status and allocation” on page 419.
• For APAR OA53660, updates to DISPLAY FXE in “Displaying function enablement state information ” on
page 274.
• Updates to the following commands for APAR OA50653 for zHyperlink support:
– New ZHYPERLINK parameter in “Displaying system configuration information” on page 338.
– New ZHYPERLINK parameter on DISPLAY IOS, see “Displaying the current status of the zHyperLink
facility” on page 313.
– New ZHYPERLINK parameter in the “SETIOS command” on page 607.
• Updates to RESET command for a colocated Tailored Fit Pricing (formerly Container Pricing) solution
(APAR OA52312). See “Changing service classes or quiescing work” on page 545.
• The SC_EXITTTABLE keyword was added to the SETOMVS command to enable pre-system call and
post-system call exit routines for select z/OS UNIX callable services. See “SETOMVS command” on
page 619 and “Displaying status of z/OS UNIX System Services ” on page 349.
• The optional UNMOUNT|NOUNMOUNT attribute was added to the VERSION statement. See “SETOMVS
command” on page 619 and “Parameters” on page 620.
• The XPAV keyword was added to the SETIOS HYPERPAV command. For details, see “SETIOS command”
on page 607.
• New DISPLAY FXE command, “Displaying function enablement state information ” on page 274.

© Copyright IBM Corp. 1988, 2018 xxiii

 • Created new DISPLAY OAM,CONFIG command. For details, see “Displaying OAM component
information” on page 348.
• Added new DISPLAY OAM,CONFIG command to table. For details, see “DISPLAY command” on page
239.
• New parameters added to DISPLAY XCF for display of the encryption state of coupling facility
structures. See “Displaying cross system coupling facility (XCF) information” on page 430.
• New SDUMP,MAXTNDSP option added to the CHGDUMP command to allow you to specify the maximum
time an SVC dump keeps critical, important, and normal tasks non-dispatchable. For more information,
see “Setting the dump modes and options” on page 174.
• New SDUMP,TYPE=XMEMT support for adding cross-memory ASIDs of the originally requested, non-
exempt target ASIDs to console initiated dumps. For more information, see “Setting the dump modes
and options” on page 174.
• New keyword, XMEMT = YES or NO, is supported on the reply to the DUMP command. For more
information, see “Specifying dump options” on page 443.
• New “SETFXE command” on page 591.
• New FXE parameter on the “SET command” on page 559.
• New parameters USEOFFLOADMIN and USESTAGINGMIN are added to SETLOGR MANAGE command.
• New parameter ENCRYPTKEY to generate encryption keys for coupling facility structures, see SETXCF
MODIFY command.

Changed
• For APAR OA55545, updated CHNGDUMP and DUMP commands. See “Options for SDUMP, SYSABEND,
SYSUDUMP, and SYSMDUMP” on page 166 and “Specifying dump options” on page 443.
• For APAR OA54807, updated DISPLAY IPLINFO. See “Displaying IPL information” on page 313.
• For APAR OA54790, updated the LOGON command. See “LOGON command” on page 475.
• Updated the DISPLAY command. See “Displaying system activity” on page 315 and “Displaying started
task status” on page 324.
• For APAR OA53272, updated DISPLAY XCF. See “Displaying cross system coupling facility (XCF)
information” on page 430.
• Added information about read-only devices in “Device assignment” on page 27, “Responding to failing
devices” on page 47, “DEVSERV command” on page 219, and “Examples” on page 233.
• Updated “Displaying storage management subsystem information” on page 395 with information
regarding OAM in both classic and multiple OAM configurations.
• Changed to add entry to DISPLAY OAM command. For details, see “MVS commands, RACF access
authorities, and resource names” on page 112.
• Changed to include support for modifying an OAM configuration using the F OTIS command. For details,
see “Managing the object access method (OAM)” on page 520.
• Updated the LFAREA section for “Displaying virtual storage information” on page 424.
• Changed to add Unicode 9.0 support to the SETUNI command. For more information, see “SETUNI
command” on page 654 and “Parameters” on page 654.

Deleted
• Information relating to GPMP has been removed from “Displaying workload manager information” on
page 424 and “Enabling and disabling the Application Response Measurement (ARM) services” on page
524.
• Information relating to shared mode for consoles was removed from “Displaying console status
information” on page 258, “Displaying operator information (OPDATA)” on page 368, “SETCON
command” on page 589, and “VARY command” on page 751.

xxiv z/OS: MVS System Commands

Summary of changes for Version 2 Release 2 (V2R2), as updated December
2016
The following changes are made for z/OS V2R2 as updated December 2016.

New
• The M parameter has been added in “Displaying SMF data” on page 391.
• The DEVSUP(FLASHCOPYTOXRC) keyword has been added to the MODIFY DEVNAME command, and a
new FLASHCOPYTOXRC keyword has been added to the MODIFY DEVMAN,ENABLE and MODIFY
DEVMAN,DISABLE commands. For details, see “Communicating with the device manager address
space” on page 503.

Summary of changes for Version 2 Release 2 (V2R2), as updated June 2016

The following changes are made for z/OS V2R2 as updated June 2016.

New
• The LINKINFO parameter has been added to the DISPLAY M command.
• The M parameter has been added to the DISPLAY SMF command.
• Chapter 5, “System REXX commands reference,” on page 789 has been added, which includes
“Displaying real storage memory statistics” on page 789.

Summary of changes for Version 2 Release 2 (V2R2), as updated March 2016

The following changes are made for z/OS V2R2 as updated March 2016.

Changed
• “Communicating with System REXX” on page 490 is updated to include several new parameters.
• Information about PROGxx is updated. See “Updating LNKLST concatenations” on page 635.
• Information about the SET TIMEZONE command is updated. See “SET command” on page 559.
• Information about using the HMCS console for initialization is updated. See “Starting the system” on
page 2 and “Preparing the system hardware” on page 3.

Summary of changes for Version 2 Release 2 (V2R2), as updated December

2015
The following changes are made for z/OS V2R2 as updated December 2015.

New
• DISPLAY ICSF command: Use this command to display certain ICSF options, status for available
cryptographic devices, information about network-attached open cryptographic servers (remote
devices), information pertaining to active key data sets (KDS), status of the master key registers for the
available cryptographic devices, and list the systems that are available to participate in commands with
a SYSPLEX scope.
• The DISPLAY IEFOPZ command was added. See “Displaying the data set optimization configuration” on
page 299 for more information.

Summary of changes xxv

 • DISPLAY SMFLIM command: Use this command to display the storage limits that are specified in the in-
storage copy of the SMFLIMxx parmlib members.
• SETICSF command: Use this command to perform specific ICSF administration functions.
• The SET IEFOPZ command was added. See “Displaying the data set optimization configuration” on page
299 for more information.
• SET SMFLIM command: Use this command to update the in-storage copy of the SMF limit rules with the
values specified in the SMFLIMxx parmlib members.

Changed
• The MODIFY LLA command was updated to support updating an entire LLA managed library or updating
a specific member of that library. See “Building and replacing library lookaside directories” on page 519
for more information.
• The SETLOGR MANAGE command was updated to support the act of preventing a z/OS image from
accessing LOGR couple data sets. See Syntax and Parameters for information.

Summary of changes in z/OS Version 2 Release 2 (V2R2)

The following changes were made to this information in z/OS Version 2 Release 2 (V2R2).

New
• The MANAGE option was added to the IXGCNF parameter of the DISPLAY LOGGER command as
described in “Displaying the system logger and its log streams” on page 328.
• “Displaying status of z/OS UNIX System Services ” on page 349 was updated.
– An example was provided that shows a sample display when the KERNELSTACKS(ABOVE) option is
specified for the BPXPRMxx parmlib statement.
– A new option, PROCESSES, was added to the DISPLAY OMVS,STORAGE command.
• New ALERT parameter on the DISPLAY SMS command, to display storage groups that have reached
thresholds. For details, refer to “Displaying storage management subsystem information” on page 395.
• New SYMNAME parameter on the DISPLAY SYMBOLS command displays all system symbols matching
the symbol name specified. See “Displaying static system symbols” on page 414.
• You can pass a MODIFY command to a PFS through an LFS interface, as described in “Passing a MODIFY
command string to a physical file system (PFS) through a logical file system (LFS)” on page 522.
• New keyword GRSMON=xx on the SETGRS command, to specify a GRSMONxx parmlib member.
• New sub-command SETGTZ PERSIST was added to operator command SETGTZ as described in
“SETGTZ PERSIST command” on page 604.
• The IOTTAPE class keyword was added to the SETIOS MIH command in “SETIOS command” on page
607.
• New parameters DEALLOCCURDS and DEALLOC added to the SETLOGR FORCE command as described
in SETLOGR FORCE command.
• Added new SETLOGR MANAGE command as described in SETLOGR MANAGE command.
• New DELETEFORCE and SERVICEMASK parameters on the SETPROG EXIT command, as described in
“Updating dynamic exits” on page 631.
• New USER_ACSVAR parameter on the SETSMS command, to specify values for the ACS read-only
variable USER_ACSVAR.
• The DELETE parameter to dynamically deactivate and delete a subsystem was added in “SETSSI
command” on page 654.
• “Indirect Addresses” on page 666 was updated to indicate changes to the displacement element of an
indirect address.

xxvi z/OS: MVS System Commands

 • The START GTZ command was added in “Starting IBM Generic Tracker for z/OS” on page 735.
• The START hzsproc command was added in “Starting IBM Health Checker for z/OS” on page 737.
• The STOP GTZ command was added in “Stopping the generalized tracking facility” on page 744.
• The STOP hzsproc command was added in “Stopping IBM Health Checker for z/OS” on page 745.
• The TIMEOUT parameter was added in VARY CN command, along with information about automatic
timeout for consoles.

Updated
• Information has been updated in “Setting up hardware event data collection” on page 36, “Accessing
the output from a hardware event data collection run” on page 39, and “Interpreting the z/OS UNIX
system services output files” on page 41.
• The example command output has been updated in “Displaying hardware event data collection status”
on page 295.
• The range of acceptable pfid values has been updated in “Displaying PCIE information” on page 369.
• The rules for subsystem name (subname) for the SETSSI commands has been added in “MVS
commands, RACF access authorities, and resource names” on page 112.
• The following commands, which previously required that DFSMStvs was installed, now display
information about forward recovery when DFSMStvs is not installed:
– DISPLAY SMS,DSNAME(datasetname)
– DISPLAY SMS,LOG(logstreamid|ALL)
– VARY SMS,LOG(logstreamid),QUIESCE|DISABLE|ENABLE
For more information, refer to “Displaying storage management subsystem information” on page 395
and “VARY command” on page 751.
• The DISPLAY SYMBOLS SUMMARY command now displays longer symbol names and substitution text.
See “Displaying static system symbols” on page 414.
• Information about automatic logoff (TIMEOUT) has been added in “Logging on to the system” on page
7, “LOGON command” on page 475, and “LOGOFF command” on page 474.
• Information about concurrent logon has been added in “Logging on to the system” on page 7 and
“LOGON command” on page 475.
• The MODIFY CEA,DISPLAY command now provides an example of the F CEA,D,PARMS command, which
displays the current settings for each statement in the CEAPRMxx parmlib member.
• Table 36 on page 483 was updated to include the new MODIFY OMVS,PFS command.
• Syntax and parameter information has been updated in “Starting, configuring, and stopping hardware
event data collection” on page 508.
• The DEVSUP parameter on the SET command was updated to accept multiple DEVSUPxx parmlib
member names, to be processed on the same command. For details, see “Parameters” on page 562.
• You can now use the SETLOGRC command to specify a data set name or log stream name, and you can
also switch to using a new data set without issuing an IPL. For details, see “SETLOGRC command” on
page 618.

Summary of changes for z/OS Version 2 Release 1 (V2R1), as updated

February 2015
The following changes are made for z/OS Version 2 Release 1 (V2R1), as updated February 2015.

New
• The following new SDUMP, SYSABEND, SYSUDUMP, and SYSMDUMP options were added for the
“CHNGDUMP command” on page 163:

Summary of changes xxvii

 – HCSAByASID
– HCSANoOwner
– HCSASysOwner
• The NAME parameter has been added to the DISPLAY HS,CONFIG command in “Displaying Basic
HyperSwap information” on page 298 and to the SETHS SWAP command in “SETHS command” on page
605.
• The DISPLAY IOS, HYPERWRITE command has been added in “Displaying the IBM zHyperWrite data
replication status” on page 308.
• The DISPLAY IQP command has been added in “Displaying PCIE-related parameters” on page 315.
• The following new SDATA options were added for the “DUMP command” on page 441:
– HCAS
– HCNO
– HCSY
• A new UNFENCE parameter has been added for the “SETHS command” on page 605.
• A new FABRICPRTY parameter has been added for the “SETIOS command” on page 607.
• The following new SDATA options were added for the “SLIP command” on page 665:
– HCSAByASID
– HCSANoOwner
– HCSASysOwner

Changed
• In “Counter sets output in a .CNT file” on page 41, the multithreading (MT) utilization counter set is
added.
• The following commands are updated for multithreading (MT) support:
– DISPLAY - See“Displaying hardware event data collection status” on page 295. The description is
extended to cover all subtypes of SMF record type 113.
– MODIFY - See “Starting, configuring, and stopping hardware event data collection” on page 508. The
description is extended to cover all subtypes of SMF record type 113.
– START - See “Starting hardware instrumentation services (HIS) ” on page 736. The description is
extended to cover all subtypes of SMF record type 113.
• The descriptions of the CSA, LSQA, RGN, and SQA options have been updated in “CHNGDUMP
command” on page 163 and “DUMP command” on page 441.
• The ARM and ARMRESTART parameters, which were omitted in previous editions, have been restored in
the syntax diagram and parameter description in “FORCE command” on page 467.
• Under the SLIP command, the topic formerly entitled, "Keeping PER Traps from Slowing System
Performance," has been updated and replaced by “Performance considerations for designing a SLIP
trap” on page 671.
• The rules for using wildcard characters with the VARY SMS,MONDS command have been updated in
“Changing the state of coupling facility cache structures and volumes” on page 769.

xxviii z/OS: MVS System Commands

Summary of changes for z/OS Version 2 Release 1 (V2R1), as updated March
2014
The following changes are made for z/OS Version 2 Release 1 (V2R1) as updated March 2014.

New
• The topic, “Diagnosing problems in a switched fabric” on page 64, provides guidance for problem
determination.
• In “MVS commands, RACF access authorities, and resource names” on page 112, the SETGRS CNS
command also requires CONTROL access to the MVS.SETGRS.GRS resource in the OPERCMDS class.
• A note about command format has been added to the "Syntax" topics of the DISPLAY GTZ and SETGTZ
commands.
• Information about the PWT parameter is added to the SETOMVS command.
• In “Starting a system task from a console” on page 728, guidance has been added to the description of
the SUB=subsystemname parameter about not specifying SUB=MSTR unless a program specifically
supports it.
• The VARY SMS,…,SPACE command allows you to update space statistics in the ACDS for a pool storage
group or a DASD volume. For details, see “Updating space statistics for volumes in the SMS
configuration” on page 775.
• Various new and changed topics document support for the new XCF Note Pad Service function. The XCF
Note Pad Service is a new application programming interface that allows programs to manipulate notes
in an XCF note pad. A note pad is an abstraction layered on top of the existing coupling facility list
structure interfaces. You can use the new IXCNOTE macro to manipulate data in a coupling facility list
structure, provided the note pad abstraction meets the needs of the application.

z/OS Version 2 Release 1 summary of changes

See the Version 2 Release 1 (V2R1) versions of the following publications for all enhancements related to
z/OS V2R1:
• z/OS Migration
• z/OS Planning for Installation
• z/OS Summary of Message and Interface Changes
• z/OS Introduction and Release Guide

Summary of changes xxix

xxx z/OS: MVS System Commands
Chapter 1. System operations

The tasks of starting, running, and stopping the MVS operating system involve controlling the MVS system
software and most of the installation's hardware, including processors, channel paths, and I/O devices.
This book is for people who need reference information about these tasks and the MVS system
commands. They include:
• Those who develop procedures for the daily operations, including system programmers and lead
operators
• Operators who want to learn how to use a console to control MVS and how to change some of the
console's characteristics
System planners and system programmers should refer to the z/OS MVS Planning: Operations for
information on planning:
• System and sysplex operation management
• MCS (multiple console support) consoles
• HMCS (HMC multiple console support) consoles
• SMCS (SNA multiple console support) consoles
• Extended MCS (Extended multiple console support) consoles
This chapter describes how to operate an MVS system using MVS system commands. Subsystem (JES2 or
JES3) commands can perform many of the same functions as MVS system commands but are described
in z/OS JES2 Commands and z/OS JES3 Commands.
The tasks of operating the MVS system that are described in this chapter include:
• “Starting, loading, and initializing the system” on page 2
• “Controlling the system” on page 9
• “Controlling time-sharing” on page 19
• “Controlling jobs” on page 19
• “Controlling started tasks” on page 21
• “Controlling system information recording” on page 22
• “Controlling automatic tape switching” on page 24
• “Interacting with system functions” on page 26
• “Command flooding” on page 32
• “Setting up hardware event data collection” on page 36
• “Accessing the output from a hardware event data collection run” on page 39
• “Responding to failing devices” on page 47
• “Quiescing the system” on page 48
• “Stopping the system” on page 48
• “Recovery from hardware problems” on page 48
Controlling MVS involves issuing commands on a console and responding to messages that appear on the
console screen. Other books that describe controlling MVS include:
• z/OS MVS JCL Reference, which documents two job control language statements (the COMMAND
statement and the JCL command statement) that you can use to enter system commands through the
input job stream.
• z/OS MVS Planning: Operations, which contains information about using MCS, HMCS, SMCS and
extended MCS consoles as well as MVS message and command processing.

© Copyright IBM Corp. 1988, 2018 1

 • z/OS MVS Planning: Global Resource Serialization, which contains information about controlling a global
resource serialization (GRS) ring.

Starting, loading, and initializing the system

Before the system can do work, you must:
1. Start the system.
2. Prepare the system hardware.
3. Load the system software.
4. Initialize the system software. At this point, your installation might require you to logon to the console.
See “Logging on to the system” on page 7.
5. Set the time and date, as required.
6. Start the job entry subsystem (JES2 or JES3).
7. Specify all job entry subsystem parameters.
The following sections describe in detail how to start, load, and initialize the system.

Starting the system

You must decide which console to use to start your system:

Using the HMCS console for initialization

The HMCS console can be used to IPL z/OS. Use of the system console or NIP consoles defined in HCD is
not required when using HMCS consoles to IPL. If the HMCS console is not available, z/OS looks in the
IODF for devices to be used as NIP consoles.
Important: If automation is used to remotely IPL the z/OS system, the nucleus initialization program
(NIP) console must be powered off or disconnected from the z/OS partition that is to be IPLed, before the
IPL is initiated. Failure to do so will prevent automation from receiving messages issued during the IPL
and prevent automation from taking any appropriate actions.

Using the MCS console for initialization

In HCD, you can specify a list of device numbers to use as NIP consoles. The initialization programs use
the first online and ready device in the list. NIP consoles must be devices that are locally connected to the
system using control units that do not support systems network architecture (SNA) protocols. This means
that SMCS consoles cannot be used as NIP consoles. If that device is also specified on a CONSOLE
statement in CONSOLxx, it is initialized as an MCS console and appears to change to an MCS console
when console initialization is complete. If no NIP consoles are defined, or no NIP consoles are online
when MVS is loaded, MVS tries to use the system console during initialization.
Important: If automation is used to remotely IPL the z/OS system, the system console (the "Operating
System Messages" window located on the Hardware Management Console) must be used to IPL the
system. The HMCS console (the "Integrated 3270 Console" located on the Hardware Management
Console) or the NIP Console must be powered down or disconnected or from the z/OS partition that is to
be IPLed, before the IPL is initiated. Failure to do so will prevent automation from receiving messages
issued during the IPL and prevent automation from taking any appropriate actions.

Using the system console for initialization

If neither the HMCS or MCS console is available, the system console is used to initialize the system. The
system console is located on the Hardware Management Console (HMC), where you load the system
software and specify the LOAD parameter. Then you use this console to initialize the system. The
initialization programs might require setting initial values, specifying an alternate master catalog, and
setting the time and date.

2 z/OS: MVS System Commands

Preparing the system hardware
To prepare the system hardware for work:
1. Turn on power for the processor.
2. Perform the initial microprogram load (IML) function for the processor.
3. Specify the central storage configuration.
4. Ensure that all volumes required by the system are online.
5. If necessary, ensure that the console device is powered on and connected to the system. To use an
HMCS to IPL the system, ensure that the Integrated 3270 Console icon is set to connect to the
appropriate LPAR.
Important: If automation is used to remotely IPL the z/OS system, the HMCS console (the "Integrated
3270 Console" located on the Hardware Management Console) must be disconnected from the z/OS
partition that is to be IPLed, before the IPL is initiated. Failure to do so will prevent automation from
receiving messages issued during the IPL and prevent automation from taking any appropriate actions.
6. Switch into the configuration all control units for devices that the system needs.
For more information on these procedures, see the processor operator's guide or your installation's
operations procedures.

Loading the system software

Once the system hardware is ready, you can use the hardware management console (HMC) to load the
system software. Consider the following information for loading system software through the HMC:
1. This task is available in Operator, Advanced Operator, System Programmer, or Service Representative
mode.
2. Other products and documentation may refer to this operation as an initial program load (IPL).
3. For daily or routine loading of images, you can customize activation profiles to specify how you want to
load images, then use a profile with the Activate task to perform all the operations necessary to make
an image operational, including loading it with a control program.
Load (except for a coupling facility image) causes a program to be read from a designated device and
initiates the execution of that program. If the CPC is operating in logically partitioned (LPAR) mode, the
logical partition is the target of the load. Otherwise, if the CPC is operating in basic mode, the CPC is the
target of the load.
You can monitor IPL messages from the system, MCS (via a NIP console) or HMCS console. If you are
loading the system software from an HMCS, you must first activate the HMCS by connecting the
Integrated 3270 icon to the appropriate LPAR.
To perform a load, do the following:
1. Open the Task List from the Views area.
2. Open CPC Recovery from the Task List Work Area.
3. Open Groups from the Views area.
4. Open the group that contains the CPC image that you want to load.
5. Select one object.
Load is considered a disruptive task. If the object is locked, you must unlock it before continuing.
6. Drag and drop the selected object on Load in the CPC Recovery tasks area. The Load window is
displayed with the information that was last used when the CPC image was loaded.
7. Review the information on the window to verify that the object you will load is the correct one. If the
information is correct, select the OK push button. The Load Task Confirmation window is displayed.
8. Review the information on the window to verify that the object you will load is the correct one. If the
information is correct, select the Yes push button. The Load Progress window displays indicating the
progress of the load and the outcome.

System operations 3
 9. Select the OK push button to close the window when the load completes successfully. Otherwise, if
the load does not complete successfully, follow the directions on the window to determine the
problem and how to correct it.
Use the online help to get additional information for loading a CPC image.

Explanation of the A=INITIALIZE SYSTEM CONTROL PROGRAM, A2 Field

This field specifies the LOAD parameter. The format of the LOAD parameter is:

Figure 1. Format of the LOAD parameter

The LOAD parameter is eight characters long and contains the following information:
1. The first four characters (characters 1 through 4 of the LOAD parameter) specify the hexadecimal
device number for the device that contains the I/O definition file (IODF) VSAM data set. This is also the
device on which the search for the LOADxx member of SYSn.IPLPARM or SYS1.PARMLIB begins. The
device number can be in the range X'0000' to X'FFFF'. If the number is less than 4 digits, specify
leading zeros before the device number. This device must be in the same subchannel set as the IPL
device. If you do not specify the device number, the system uses the device number of the system
residence (SYSRES) volume.
2. The next two characters (characters 5 and 6 of the LOAD parameter) specify the suffix of the LOADxx
parmlib member that the system is to use. The LOADxx member contains information about the name
of the IODF data set, which master catalog to use, and which IEASYSxx members of SYS1.PARMLIB to
use.
The default for the LOADxx suffix is zeros. The system reads the LOADxx and NUCLSTxx members from
SYSn.IPLPARM or SYS1.PARMLIB on the volume specified on the LOAD parameter (or the SYSRES
volume, if a volume is not specified). Once the system opens the master catalog, the system reads all
other members from the SYS1.PARMLIB data set that is pointed to by the master catalog. This
SYS1.PARMLIB might be different from the SYS1.PARMLIB data set to which the LOAD parameter
points.
For more information about LOADxx, see the description of LOADxx in z/OS MVS Initialization and
Tuning Reference.
3. The next character (character 7 of the LOAD parameter) specifies the prompting and message
suppression characteristics that the system is to use at IPL. This character is commonly known as an
initialization message suppression indicator (IMSI).
Suppressing Informational Messages: Some IMSI characters suppress informational messages from
the system console, which can speed up the initialization process and reduce message traffic to the
console. It can also cause you to miss some critical messages, so you should always review the
hardcopy log after initialization is complete.
When the system suppresses informational messages, it displays the following messages:
• Messages with descriptor codes 1, 2, 3, 11, or 12.
• Write-to-operator with reply (WTOR) messages.
• Command responses.
• Synchronous messages that can indicate problems during initialization.
It does not display the contents of a parmlib member, even if the L option has been specified.
Prompting for Operator Responses: You can specify an IMSI character that tells the system to issue a
MASTER CATALOG prompt, a SYSTEM PARAMETERS prompt, both, or none:

4 z/OS: MVS System Commands

 • If the system issues a MASTER CATALOG prompt, the operator response overrides the values that
are specified on the SYSCAT parameter in the LOADxx parmlib member.
• If the system issues a SYSTEM PARAMETERS prompt, the operator response overrides the values
that are specified on the SYSPARM parameter in LOADxx. Also, if LOADxx specifies the IEASYMxx
parameter which in turn specifies a SYSPARM parameter for IEASYSxx, then the operator response
also overrides the values that the SYSPARM parameter in IEASYMxx specifies.
• If the system does not prompt the operator, the system uses the values specified in LOADxx. If the
SYSCAT and SYSPARM statements are not specified in LOADxx, the system issues one or both
prompts to obtain the missing information.
Prompting for the Name of the Master Catalog: If you choose an IMSI character that tells the system
not to prompt for the master catalog name, the system uses the name specified on the SYSCAT
parameter in the LOADxx parmlib member.
The default for the system parameter prompt is to use IEASYS00 in SYS1.PARMLIB, and the default for
the master catalog prompt is to use SYSCATLG in SYS1.NUCLEUS.
The following table shows the possible values for the IMSI character. The default value is period (.).

Table 1. Possible values for IMS characters

IMSI Display informational Prompt for master catalog Prompt for system
character messages response parameters Response
period (.) or No No No
blank
A Yes Yes Yes
C No Yes No
D Yes Yes No
M Yes No No
P No Yes Yes
S No No Yes
T Yes No Yes
4. The last character (character 8 of the LOAD parameter) specifies the alternate nucleus identifier (0-9).
Use this character at the system programmer's direction. If you do not specify an alternate nucleus
identifier, the system loads the standard (or primary) nucleus (IEANUC01) and an architectural
extension of the nucleus (IEANUC11 or IEANUC21), unless the NUCLEUS statement is specified in the
LOADxx member. For more information, see z/OS MVS Initialization and Tuning Reference.
Also consider the following:
1. Decide whether to accept the system prompt indicator default. The default causes the system to
suppress messages and not prompt the operator. You might miss critical messages during
initialization, so you should review the hardcopy log.
New installations might want to select prompt feature A (display all messages and prompt the
operator) or M (display all messages but do not prompt operator) on the Hardware Management
Console while validating changes and analyzing system errors during the initialization process.
Specifying either A or M might increase message traffic.
2. Omit the LOAD parameter when you accept all the IBM-supplied defaults.
3. Each character in the LOAD parameter is positional. If you change any of the defaults you must retype
the characters or use periods (....) to hold the positions.
4. You cannot leave any leading spaces blank, unless the defaults are accepted for the rest of the LOAD
parameter.

System operations 5
 Explanation of the A=INITIALIZE SYSTEM CONTROL PROGRAM, A3 Field
This field specifies the operator load function to IPL the MVS operating system.
Selecting the operator load function causes the hardware to read an IPL (initial program loader) program
into storage from the system residence volume. For this reason, loading and initializing the system is often
called the “IPL procedure” or just “IPL”. Likewise, “IPLing” the system means loading and initializing the
system.
The IPL program is what actually loads the system software; if the IPL program does not get into storage
or does not receive control properly, the entire load process stops and the processor pauses. If the IPL
program does not finish properly, it puts the system into a disabled wait state with an error code in the
low-order 12 bits of the program status word (PSW). To continue loading the system, display the PSW,
note the error code, and follow the instructions for that code given in z/OS MVS System Codes. The
processor operations documentation tells you how to display the PSW.

Initializing the system software

Once the software is loaded into storage, it must be given specific starting values before it can do work.
These values are supplied through a LOADxx parmlib member specified by the LOAD parameter through
the Hardware Management Console, HMCS, system console or the NIP console during the initialization
process.
In certain situations, the system prompts you to specify an alternate master catalog; then it prompts for
system parameters that are not specified in LOADxx. The following sections explain how to respond to
those prompts.

Specifying an Alternate Master Catalog

During system initialization, unless the SYSCAT parameter is specified in the LOAD parameter, the system
issues the following message:

IEA347A SPECIFY MASTER CATALOG PARAMETER

You must respond to this message. You can respond in one of two ways:
• If your installation uses the default member of SYS1.NUCLEUS, SYSCATLG, to find the master catalog,
press the ENTER key.
• If your installation uses an alternate member of SYS1.NUCLEUS, SYSCATnn, to find an alternate master
catalog, enter two characters for nn.

Specifying System Parameters Not Defined in LOADxx

The LOAD parameter can supply values not defined at system installation time. If this is not done, you
must supply them as system parameters in response to the following system message:

IEA101A SPECIFY SYSTEM PARAMETERS FOR product-name

You must respond to this message. You can respond with specific system parameters, such as

REPLY 00,CLPA,SYSP=83,LNK=(04,05,PQ),SYSNAME=AQ

However, a typographical error made in this response can lead to undesirable system operation. To help
avoid this situation, the system programmer can specify system parameters in IEASYSxx parmlib
members. If this has been done, you can respond to message IEA101A in one of the following ways:
• To use the system parameters specified in the IEASYS00 parmlib member, press the ENTER key.
• To use system parameters specified by IEASYSxx parmlib members along with IEASYS00, use the SYSP
operand on the REPLY command to specify the 2-character suffixes that identify the IEASYSxx parmlib
members.

6 z/OS: MVS System Commands

 For example, to use the parameters specified in parmlib members IEASYSAA and IEASYSBB along with
IEASYS00, enter:

REPLY 00,SYSP=(AA,BB)

Note: Depending on the specific system parameter, a parameter value specified in the alternate parmlib
members supplements or overrides the value specified in IEASYS00.
If the reply is longer than one line (there are 80 characters per line), you can follow the last parameter
with a comma or a blank and CONT. For details on how to continue system parameters, see “Specifying
system parameters” on page 542 in the description of the REPLY command in this book.
For details about parmlib members, see z/OS MVS Initialization and Tuning Reference.

Setting the Time and Date

If the time-of-day (TOD) clock on the target processor is not set or if your installation specifies the
OPERATOR PROMPT parameter in the CLOCKxx member of SYS1.PARMLIB that the system uses for
initialization, the system prompts you during initialization to set the correct time and date with message
IEA886A and/or message IEA888A. Message IEA886A asks you to specify values for the time and date.
Message IEA888A displays the time and date and lets you accept or change these values. In response to
either message, set an accurate time and date according to your installation's requirements.
For example, suppose the system issues:

IEA888A UTC DATE=1991.301,CLOCK=22.31.53

*00 IEA888A LOCAL DATE=1991.301,CLOCK=17.31.53 REPLY U, OR UTC/LOCAL TIME

The values in this message indicate that the local time is 5:31:53 P.M. on October 28, 1991 and that
Coordinated Universal Time (UTC) is five hours later than local time in your time zone. If the local time at
your installation is really 8:00:00 A.M. on October 29, 1991, reply as follows:

R 00,DATE=1991.302,CLOCK=13.00.00,GMT

The system responds with:

IEA888A UTC DATE=1991.302,CLOCK=13.00.00

*00 IEA888A LOCAL DATE=1991.301,CLOCK=08.00.00 REPLY U, OR UTC/LOCAL TIME

Note that the system sets the local time but not the local date from the time and date you specify. To set
the local date, reply as follows:

R 00,DATE=1991.302

If the new UTC and local time values are still not accurate enough, you can reply with new UTC time
values now (and as many times as you need) to bring the system's values closer to what your installation
requires. When you are satisfied with the system's values, reply as follows:

R 00,U

See “REPLY command” on page 537.

Initializing MCS, HMCS and SMCS consoles

Message IEE612I appears on an MCS, HMCS and SMCS console when it completes initialization.
If you enter the command DISPLAY C,K (or D C,K), the system displays a summary of the CONTROL
commands. You can use these commands to change the characteristics of the console. See “Displaying
CONTROL command functions” on page 257 for information about the DISPLAY C,K command.

Logging on to the system

Your installation can control the use of the system commands and access to MCS, HMCS and SMCS
consoles through the system authorization facility (SAF) and the Resource Access Control Facility (RACF).

System operations 7
 Your installation can require operators to use the LOGON command to log on to the system and identify
themselves.
Your installation can specify the LOGON attribute for MCS, HMCS and SMCS consoles in two ways. First, a
default LOGON attribute can be specified for all consoles active on a system by specifying the LOGON
keyword on the DEFAULT statement in the CONSOLxx parmlib member. Second, individual consoles can
override the default LOGON attribute by specifying the LOGON keyword on the CONSOLE statement in the
CONSOLxx parmlib member. For more information on specifying LOGON consult z/OS MVS Planning:
Operations and z/OS MVS Initialization and Tuning Reference.
The security administrator can enable consoles password phrase support on a system by defining a
security profile to cover the MVS.CONSOLE.PASSWORDPHRASE.CHECK resource in the OPERCMDS class.
There is no authority access checking from a user ID perspective. The consoles function checks for the
existence of the profile and, if the profile exists, the new LOGON panel display is revealed which will allow
for either the new password phrase input or the standard eight (8) character password.
Your installation can specify that LOGON is required by specifying LOGON(REQUIRED) on the DEFAULT
statement (for all MCS, HMCS and SMCS consoles) or on the CONSOLE statement (for a single console).
When LOGON is a system requirement, you can issue commands only through a master authority console
until RACF is fully initialized and able to process logon requests. Until RACF is initialized, you cannot issue
any commands from any non-master authority console.
Once RACF is fully initialized, all operators are required to logon. The IEE187I message prompts you for a
user ID and password. Optionally, you might enter a group id and a security label. See “LOGON command”
on page 475 for more information.
IBM suggests that SMCS consoles be LOGON(REQUIRED), either using the system-wide DEFAULT LOGON
specification or the CONSOLE LOGON specification of the console.
A TIMEOUT value may be specified for a console. If an operator has logged on to the console with a user
ID, the system will automatically log the user ID off after the number of minutes specified by TIMEOUT
have elapsed without any console input activity (pressing an attention-generating key, such as Enter, PA1,
PA2, or a PFK).
Your installation can specify that LOGON is automatic by specifying LOGON(AUTO) on the DEFAULT
statement (for all MCS, HMCS and SMCS consoles) or on the CONSOLE statement (for a single console).
When LOGON is not a system requirement, after the security product is fully initialized, the system will
automatically issue an MCS LOGON command to each active MCS, HMCS or SMCS console; system
operators may log on to these consoles but are not required to do so. Automatic logon affects only full
capability consoles. If a TIMEOUT value is specified for a console, it will be ignored when the user ID
matches the console name and the console is in LOGON(AUTO) mode.
Your RACF administrator creates RACF user profiles for each operator. Each operator can have access to
different commands, consoles, data sets, and other RACF-protected resources, according to the person's
responsibilities. The RACF administrator also creates RACF resource profiles that protect all operator
commands. If you need more information on creating profiles for operators, consoles, MVS commands,
and other resources, see the z/OS Security Server RACF Security Administrator's Guide.
Your installation can specify that LOGON is optional by specifying LOGON(OPTIONAL) on the DEFAULT
statement (for all consoles on the system) or on the CONSOLE statement (for a single console). Code the
OPTIONAL parameter when your installation has selected consoles defined in RACF to allow the operator
to log on.
z/OS MVS Planning: Operations has more information about controlling system commands and consoles in
a secure environment.
Typically, an operator logs on to a single console. If your installation wishes to allow an operator to be
concurrently logged on to multiple consoles within a system or sysplex, your security administrator can
allow this. When the security profile MVS.MULTIPLE.LOGON.CHECK is defined in the OPERCMDS class, an
operator may log on to multiple consoles. Defining this profile allows all operators to be able to log on
multiple times. There is no limit to the number of consoles to which an operator may be logged on.
Operators are still required to provide a password while logging on to each console.

8 z/OS: MVS System Commands

Starting and specifying parameters for the job entry subsystem
Even after the system is initialized, it cannot accept work until the job entry subsystem (JES2 or JES3) is
started. The system automatically starts JES2 or JES3 if your installation provides this capability.
Otherwise, you must issue the START command. For further information about starting JES, see either
z/OS JES2 Commands or z/OS JES3 Commands.See “START command” on page 727.

Controlling the system

Controlling the operating system effectively, includes the following tasks:
• Display current system status, such as the number of active jobs and teleprocessing functions, so you
can take appropriate actions to operate the system efficiently and to correct potential problems
• Display the status of devices and availability of paths.
• Communicate among several consoles.
• Communicate within a sysplex. In a sysplex, several MVS systems function together to process work,
and you might need to know about the operations of more than one system in a sysplex.
• Set the time and change the system parameters.
• Use the system restart function to control certain system functions.
• Respond to message IEA502A.
• Respond to message BLW004A.
• Activate a workload management service policy for a sysplex.
MVS provides system and subsystem commands that display job and system status either when
requested or continually at a regular interval. Other commands route status information to one or more
consoles and provide communication among operators in a multiple-console environment, as well as
communication with time-sharing users. Many commands let you display information about all the
systems in a sysplex, and some commands allow you to control any target system in the sysplex.
The following sections describe in detail how to control the system.

Displaying current system status

Using the DISPLAY command, you can display overview information about all current system activity and
detailed information about active batch jobs, started tasks, system address spaces, and/or logged-on
time-sharing users. (The DISPLAY command in Chapter 4, “MVS system commands reference,” on page
137 describes the overview and detailed information you can display.) The command produces a one-
time display of status as it is at the time you enter the command.
To help you keep up with the system's needs, you can enter the DISPLAY R command to display system
requests waiting for replies or actions, mount requests not yet fulfilled, and devices waiting for operator
intervention. You can use the information in the display to take any necessary actions. See “Displaying
system requests” on page 382 for information about the DISPLAY R command.
Using the MONITOR command, you can keep track of jobs starting and stopping. In response to the
MONITOR command, the system displays the job identification whenever a job starts or stops. Using this
command, you can also request that the system notify you of TSO logons, JCL failures, and data set
allocations. See “MONITOR command” on page 529. You can also use the SETCON MONITOR command
to enable or disable monitoring messages for jobs, TSO/E sessions, and data set allocations. See
“SETCON command” on page 589.

Displaying the status of devices and availability of paths

There are three commands that you can use to display the status of devices and the availability of the
paths these devices are on.
The DISPLAY U command allows you to keep track of the availability for allocation of the following
devices attached to the system:

System operations 9
 • Channel-to-channel (CTC) links
• Direct access storage devices (DASDs)
• Graphic devices
• Magnetic tape units
• Communication equipment
• Unit record devices
This command displays device status and the job names and ASIDs of device users. Knowing what jobs
and ASIDs are using a particular device allows you to determine whether you can take the device offline.
See “Displaying device status and allocation” on page 419 for information about the DISPLAY U
command.
The DISPLAY M command allows you to keep track of the availability of channel paths and devices on
these paths. See “Displaying system configuration information” on page 338 for information about the
DISPLAY M command.
The DEVSERV PATHS command can help you solve hardware or configuration problems. The display
includes the status of paths, the channel path ids, the logical mode of devices, the number of data sets
allocated on volumes, and volume serial labels. Because the DEVSERV command causes the system to
issue an I/O request on paths to a device or devices, the resulting display reflects the current physical
state of the path. Comparable displays from the DISPLAY M command reflect less recent information from
the last use of MVS control blocks. For example, assume that an I/O device is performing below normal
and you suspect that some paths to the device are offline. The DISPLAY M command might tell you that
there are four paths online to the device. The DEVSERV PATHS command might tell you that there is
actually only one online path. The DEVSERV command is more current and thus more accurate. See
“DEVSERV command” on page 219 for information about the DEVSERV command.

Sending commands to systems in a sysplex

You can use the CONTROL V command to direct commands from a console to a specific system in a
sysplex. The CMDSYS parameter on the CONTROL V command specifies which system receives all
commands (not specifically routed elsewhere by the ROUTE command) entered from a particular console.
See “CONTROL command” on page 198.
You can use the ROUTE command to send commands to be processed on other systems in the sysplex.
See “ROUTE command” on page 547.
You can use the VARY CN command to specify from what systems in a sysplex a specified console
receives unsolicited messages. Use the MSCOPE, AMSCOPE, and DMSCOPE parameters for purposes of
control. See VARY CN command.
Some commands have an L=name parameter. You can use this parameter to specify the name of a
console on a different system in the sysplex. These commands can communicate with the named console
and receive messages from that system.

Using commands that have sysplex scope

Commands that have sysplex scope have the following characteristics:
• They affect resources that are shared throughout the sysplex. Examples of such resources include the
Sysplex Timer, the coupling facility, couple data sets, and certain DASD volumes.
• You can issue them from any system in the sysplex; the results are identical.
• The results of issuing them are sysplex wide without the need to use ROUTE *ALL. You should not use
any form of the ROUTE command to issue a command with sysplex scope because doing so is
redundant. Here's why:
– You use ROUTE to have a command that is issued on a particular system, group of systems, or all
systems in the sysplex. Using the ROUTE command is the logical equivalent of walking up to a
console attached to each system you route to, and issuing the command from that console.

10 z/OS: MVS System Commands

 – You do not need to issue a command with sysplex scope on a particular system, group of systems, or
all systems in the sysplex. You issue the command once from any system.
Note that a command can have sysplex scope when you use particular parameters, and not have sysplex
scope when you use other parameters.
Commands that have sysplex scope are so noted in the documentation for that command, and include
those in the following table. If a command has All under “Conditions”, then the command has sysplex
scope under all circumstances and for all variations.

Table 2. MVS system commands with sysplex scope

Command Conditions
CHNGDUMP Has sysplex scope only when all systems are connected to the same
coupling facilities, and you specify ,SDUMP,SYSFAIL,STRLIST=.
CONTROL C,A All
CONTROL C,D Has sysplex scope only when you specify L=.
CONTROL M Has sysplex scope only when you do not specify MLIM, UEXIT,
LOGLIM, or APPLID.
CONTROL other Other parameters of CONTROL have sysplex scope only when you
specify L=.
DISPLAY CF Has sysplex scope only when displaying information about the
coupling facility and only for those systems connected to the
coupling facility. Does not have sysplex scope when displaying an
individual system's coupling facility configuration information
(coupling facility channels and paths).
DISPLAY CNGRP All
DISPLAY CONSOLES Has sysplex scope unless you specify DISPLAY C,B or DISPLAY C,U.
DISPLAY DUMP Has sysplex scope only when you issue the OPTIONS parameter to
display the results of a CHNGDUMP ...SDUMP,SYSFAIL,STRLIST=
command.
DISPLAY EMCS Has sysplex scope, except when you specify STATUS=B or
STATUS=ERR. When you specify STATUS=FULL, consoles from all
systems will be displayed (for consoles that are not active on the
system where this command is processed, some information will not
be displayed).
DISPLAY GRS Has sysplex scope unless you specify SUSPEND. Also, note the
following about DISPLAY GRS,C and DISPLAY GRS,RES: the output
that is generated by these commands includes both system-specific
information (S=SYSTEM) and sysplex information (S=SYSTEMS). The
S=SYSTEM information is valid only for the system on which you
issue the command. The S=SYSTEMS information is identical
regardless of the system on which you issue the command.
DISPLAY GRS,ANALYZE Has sysplex scope for Enqs, but can be limited to a system.
Note that D GRS,ANALYZE,LATCH only returns latch analyze
information for the system the command is running in.

DISPLAY LOGGER Has sysplex scope when you use either L or C,SYSPLEX options.

System operations 11
 Table 2. MVS system commands with sysplex scope (continued)
Command Conditions
DISPLAY OPDATA Has sysplex scope for the PREFIX operand, the MODE operand, and
the MONITOR operand (except for SPACE and DSNAME, and all
MONITOR operands issued from a TSO user).
DISPLAY PFK Has sysplex scope only when you specify CN=.
DISPLAY R Has sysplex scope, but the output might be different on different
consoles, because the output of DISPLAY R is dependent on the
routing criteria for the console specified by CN=. If you do not specify
CN=, the routing criteria of the console issuing the command is used.
If you issue the command in a program (by using the MGCRE macro)
the console you specify in the macro is used. If you specify a console
ID of 0, all retained messages are included in the command
response.
DISPLAY WLM All
DISPLAY XCF,ARMSTATUS Has sysplex scope provided all systems are using the same ARM
couple data set.
DISPLAY XCF,CF Has sysplex scope provided all systems in the sysplex are connected
to the same coupling facilities.
DISPLAY XCF,COUPLE Has sysplex scope as long as all systems are using the same types of
couple data sets, as specified on the TYPE parameter (SYSPLEX,
ARM, CFRM, SFM, LOGR, and WLM.) If you do not specify the TYPE
parameter, only system-specific data is displayed.
DISPLAY XCF,GROUP All
DISPLAY XCF,POLICY Has sysplex scope as long as all systems are using the same types of
couple data sets, as specified on the TYPE parameter (ARM, CFRM,
SFM, and LOGR.)
DISPLAY XCF,STRUCTURE Has sysplex scope provided all systems in the sysplex are connected
to the same coupling facilities.
DISPLAY XCF,SYSPLEX All
MONITOR Has sysplex scope only when you specify L=.
MOUNT Has sysplex scope only when you issue the command against an
automatically switchable tape device.
REPLY All
RESET CN Issue the command from the system where the console was active
to avoid inconsistent sysplex results.
SEND Has sysplex scope only when sending to consoles; does not have
sysplex scope when sending to TSO users.
SET CNGRP Has sysplex scope provided all systems are sharing the same
parmlib data set.
SET CON Has sysplex scope when adding a sysplex accessible console (SMCS,
subsystem), or when changing the value that is associated with a
sysplex scope CONSOLxx keyword.
SET DAE Has sysplex scope only when all systems are sharing the same DAE
data set and the same parmlib data set.

12 z/OS: MVS System Commands

 Table 2. MVS system commands with sysplex scope (continued)
Command Conditions
SET GRSRNL Has sysplex scope only when all systems are sharing the same
parmlib data set.
SET SMS Has sysplex scope when you are issuing the command to change the
name of the ACDS or COMMDS. All systems in the sysplex must be in
the same SMS complex, and using the same parmlib data set. If you
are issuing the command to start or restart SMS on a system, only
the system on which you issue the command is affected.
SETCON DELETE All
SETLOGR FORCE Has sysplex scope when you use DELETE,LSName options.
SETSMS Has sysplex scope only if you are changing the SCDS, ACDS, or
COMMDS, and only if all systems in the sysplex are in the same SMS
complex.
SETXCF FORCE Has sysplex scope only when all systems are connected to the same
coupling facility.
SETXCF COUPLE Has sysplex scope only when you specify PSWITCH, ACOUPLE, or
PCOUPLE, and all systems have access to the specified couple data
set.
SETXCF START|STOP Have sysplex scope only when you specify POLICY or REBUILD.
STOPMN Has sysplex scope only when you specify L=.
UNLOAD Has sysplex scope only when you issue the command against an
automatically switchable tape device.
VARY CN Has sysplex scope unless all of the following are true:
• You issue VARY CN(conspec),ONLINE without specifying SYSTEM=.
• You do not specify SYSTEM= in the CONSOLxx parmlib member
that defines this console.
• The console has never been active in the sysplex.

VARY SMS, STORGRP|VOLUME Has sysplex scope under these conditions only:
• You specify (storgrp|volume,ALL) and all systems in the sysplex are
in the same SMS complex.
• You specify (storgrp|volume system) where system is a system
group, and the system group exactly matches the sysplex (that is,
none of the systems in the sysplex is explicitly defined to SMS).

VARY SWITCH Logical partition cluster scope -- see the "Intelligent Resource
Director" chapter in z/OS MVS Planning: Workload Management for
more information.
VARY XCF All
VARY WLM All

Sharing system commands

MVS allows two or more systems in a multisystem environment to share commands while retaining
unique values in those commands. When two or more systems share commands, you can view a

System operations 13
 multisystem environment as a single system image from which you can perform operations for several
different systems.
This section explains how to share system commands in a multisystem environment, using:
• System symbols, which represent unique values in shared commands
• Wildcards, which identify multiple resource names in commands.

Using system symbols in commands

System symbols represent the values in shared commands that are unique on different systems. Each
system defines its own values to system symbols, and replaces the system symbols with those values
when processing shared commands.
To use system symbols in system commands, first see the section that describes system symbols in z/OS
MVS Initialization and Tuning Reference to understand the types of system symbols, the elements that
comprise them, and the general rules for using them. Second, see the section on sharing system
commands in z/OS MVS Planning: Operations for information about planning to share commands. Then
read the rest of this section.

Display static system symbols

You can enter the DISPLAY SYMBOLS command to display the static system symbols and associated
substitution texts that are in effect for a system. See “Displaying static system symbols” on page 414 for
more information.

Know the rules for using system symbols

The system enforces the following rules when you use system symbols in system commands. They apply
in addition to the general rules for system symbols that are described in z/OS MVS Initialization and
Tuning Reference.
1. Substitution in a command begins after the command name. This means that you cannot use symbolic
variables to resolve to a command prefix or to a command name. The command “&Asyspref &mycmd”
would result in an error message, for example.
2. If the issuing console has command association (CMDSYS) to another system, the issuing system first
transports the command to the associated system. Substitution of any symbolic variables takes place
on the receiving system.
3. If a command has a prefix defined with the command prefix facility (CPF), the issuing system first
transports the command to the system defined for that prefix. Substitution of any symbolic variables
takes place on the receiving system.
4. After echoing and logging a command, the system examines the command name. Certain commands
receive special treatment:
• The system will not perform substitution for symbolics in a VARY CN(*),ACTIVATE command.
• A DUMPDS command will not undergo substitution. The DUMPDS command processor handles its
own substitutions, at the time when it actually takes a dump.
• For security reasons, the LOGON command does not support symbolic substitution.
• For a REPLY command, substitution of any symbolic variables in the reply text takes place on the
system originally issuing the WTOR.
However, if the WTOR is synchronous (SYNCH = YES was specified, and the synchronous WTO/R
service displays the WTOR), the system does not perform substitution of the reply text.
But, if the system issues the WTOR early during the initial program load (IPL), that is, while the
nucleus initialization program (NIP) is still in use:
– The system performs substitution after it processes the requested symbolics it reads from the
parmlib. This means that the system will substitute symbolic variables in replies to WTORs it
issues after issuing the IEA347A SPECIFY MASTER CATALOG PARAMETER message.

14 z/OS: MVS System Commands

 – The system will not issue message IEE295I for NIP-time replies that are changed by symbolic
substitution. Message IEE600I will reflect the changed text.
• For a ROUTE command, the system issuing the command performs the substitutions up through the
specification of the destination system(s). Each destination system completes the substitution of the
text for the command.
For example, if you code the command

RO T=&T1,&SYSGRP1,F JOB&SYSCLONE,parms

the system issuing that ROUTE command will substitute the variables

&T1 and &SYSGRP1

and each system in the system group that &SYSGRP1 names will issue the command

F JOB&SYSCLONE,parms

and each of those receiving systems will substitute its own value for &SYSCLONE. See “Using System
Symbols in ROUTE Commands.”
• You cannot use symbolic variables on an “L=” operand to aggregate the command response when
sending a command to more than one system. The system will not substitute for the “L=” operand.
• For commands other than REPLY and ROUTE, the system issuing the command performs the
substitution for the text after the command name, including comments.
5. You cannot use system symbols in commands that control batch jobs. Consider converting batch jobs
to started tasks, which can specify system symbols.
6. If substitution results in changing any command text, the system logs the “new” text again and issues
message IEE295I.
The system makes the original (pre-substitution) command text available to the command installation
exits and the subsystem interface (SSI). However, current programs, if not modified, will see the
substituted text.
When the system calls the command installation exits or SSI, if those exits make any change to the
command text, the system logs them again and issues message IEE295I. However, it does not perform
substitution again. It frees the original command text, which means that it is no longer available in the
system.

Cautions in using system symbols

The preceding rules mean that some forms of command input will probably not produce the results you
want:
1. Symbolic variables before or in a command name remain unsubstituted. The system will process the
command with the “&variable;“ in the text, and probably generate a “COMMAND INVALID” error
message.
2. If a command exit changes the text and adds a new symbolic variable, the system executes the
command before substituting for the variable.
3. The following considerations apply when a command affects systems other than the one issuing it:
• Except for REPLY, the substitution will reflect the issuing system. For example, if

SYSVAR1 = (1,2)

on the system issuing the following VARY command, but

SYSVAR1 = (3,4)

on a system with the console “consname” attached, the command

VARY CN(consname),ROUT=&SYSVAR1

System operations 15
 would result in the console “consname” receiving codes 1 and 2. If this (unlikely) command is what
you want, you should ROUTE it to the system with consname attached.
• The same logic applies to commands that accept the “L=name-a” parameter, that is, where you want
the command output messages directed to a console (and display area) other than the one issuing
the commands. Substitution of symbolic variables in commands occur on the systems where the
commands are issued, not where the “L=” console is attached.
• Do not use symbolic variables in the “L=” parameter on the ROUTE command. See the ROUTE
command description in this manual.
• Understand the implications of using system symbols in commands that flow through several
systems in a multisystem environment. See “Sharing Commands That Flow Through Multiple
Systems” in z/OS MVS Planning: Operations for more information.

Determine where to use system symbols

System symbols offer the greatest advantage when two or more systems require different resources. This
section provides examples of how to specify system symbols when naming resources in system
commands.
Data sets:
Assume that you want to display, on all systems in a sysplex, the local page data sets that fit the following
naming convention:

SY&SYSCLONE..PAGE.LOCAL

Instead of entering a different command to display the unique page data sets on each system, you could
enter the following command to display all the data sets that fit the naming convention:

ROUTE *ALL,D ASM,PAGE=SY&SYSCLONE..PAGE.LOCAL

When each system processes the command, it substitutes the text that it has defined for the &SYSCLONE
system symbol. For example, if a sysplex consists of two systems named SYS1 and SYS2, accepting the
default value for &SYSCLONE produces the following data sets:

D ASM,PAGE=SYS1.PAGE.LOCAL on system SYS1

D ASM,PAGE=SYS2.PAGE.LOCAL on system SYS2

Jobs:
When specifying system symbols in the source JCL for job names, first determine if the jobs run as batch
jobs or started tasks. If a job is a started task, you can specify system symbols in the source JCL. If a job
runs in batch, you cannot specify system symbols in the source JCL; consider changing the job to run as a
started task.
Then, if a started task is to have multiple instances, determine if you want the started task to have a
different name for each instance. If each instance of a task has a different name, your installation can
easily identify the system on which each instance runs.
For started tasks, you can also specify system symbols on the JOBNAME parameter on the START
command that starts the task. For more information about using system symbols in START commands,
see “START command” on page 727.

Using wildcards in commands

Wildcards allow you to use a single specification to indicate a number of resources whose names match
the wildcard pattern.
System commands use three kinds of wildcards:
• Multiple-character trailing asterisk (*): The * indicates zero, one, or more characters, up to the
maximum length of the string. This * must be at the end and cannot appear alone. For example, ABC*
matches ABC or ABCVWXYZ or ABC1 or ABCZZZ. Use this wildcard in:

16 z/OS: MVS System Commands

 – CANCEL
– DISPLAY
– MODIFY
– SETPROG
– SLIP parameters, as indicated in their descriptions
– STOP
• Multiple-character asterisk (*) within the value: The * indicates zero, one, or more characters, up to
the maximum length of the string. This * can be in any position and can appear alone to indicate all
values. For example:
– A*BC matches ABC or ACBC or AWXYZBC or A3BC
– * matches all values
– *BC matches BC or WXYZBC or ZZZBC
Use this wildcard in the JOBLIST and DSPNAME parameters of the SLIP command.
• Single-character question mark (?): The ? indicates any single character. The ? can be in any position.
For example:
– A?C matches ABC or A1C
– ABC?E?? matches ABCXEYZ or ABC1E23
– ?BC matches ABC and ZBC
Use this wildcard in SLIP parameters, as indicated in their descriptions.
In some SLIP command parameters, you can use more than one type of wildcard. For example:
• A?C* matches ABC or AXCYZ or A5CZ2
• A*C? matches ABCD or AZZZZC1 or A123CZ or ACD
You can use wild cards to reduce the number of system commands needed for a task. For example, you
can enter one command to display information about all jobs and started tasks beginning with the
characters XYZ:

DISPLAY A,XYZ*

Setting the time and changing the system parameters

Using the SET command, you can set the local time and date and change some system parameters. See
“SET command” on page 559.

Using the system restart function

You can use the system restart function to:
• Restart the system after you have entered a QUIESCE command. (See “Quiescing the system” on page
48.)
• Restart the system from a restartable wait state that is specified in z/OS MVS System Codes.
• Restart the system when it behaves abnormally and you cannot terminate the suspected unit of work
with the CANCEL or FORCE commands. A system behaving abnormally may be one that enters a
nonvalid wait state or a disabled loop. A nonvalid wait state exists when the wait state code in the PSW
(IC) is not listed in z/OS MVS System Codes and is not in the range of wait state codes (FF0-FFE)
reserved for other authorized applications. Symptoms of a disabled loop are:
– Nonproductive processing occurs and the PSW (IC) frequently displays the same addresses.
– All I/O and external interrupts are masked off for the system.

System operations 17
 System restart procedure
To initiate the system restart function press the RESTART key on the hardware operator's console or
specify one of several restart actions on an operator frame. Refer to the hardware documentation for your
system for more detailed information about your configuration. If the system has been quiesced or is in a
valid restartable wait state, the system restarts and continues processing the interrupted unit of work. If
the system had not been quiesced or is not in a valid restartable wait state then, depending upon your
system configuration, the system displays either message IEA502A or BLW004A.
If the system does not recover as a result of your restart actions, follow your installation's procedures for
recording system problems. When you have recorded the system information, consult with your system
programmer before taking further action.

Responding to IEA502A
Reply reason code ‘0’ when you suspect that a unit of work is causing a wait state that is not valid or a
disabled loop and you cannot terminate the suspected unit of work by using the CANCEL or FORCE
commands.
1. The system displays message IEA500A and waits for operator response. IEA500A supplies
information about the unit of work in progress.
2. Reply ABEND to abnormally terminate the interrupted program and invoke the necessary recovery
routines if the information describes the unit of work you suspect has a problem.
3. Reply RESUME to end further restart processing and allow the interrupted work to continue if the
information does not describe the unit of work that you suspect has a problem.
Repeat this process of invoking restart with REASON 0 until you interrupt the work you suspect. Only then
should you reply ABEND to abnormally terminate the current work.
Note: The system terminates the work in progress without displaying any information about it if you
request the restart function with REASON 0 on a processor that cannot communicate with an operator.
Reply reason code ‘1’ when you suspect a system problem that is not related to the work currently in
progress. The system diagnoses and repairs some problems that might be causing it to behave
abnormally. Among its actions, the system:
• Makes itself dispatchable.
• Checks the number of message buffers. The system notifies you if the maximum number of buffers has
been exceeded.
• Checks system activity. The system notifies you if there are no batch jobs or time-sharing users.
• Restarts I/O on all channel paths.
• Checks and repairs critical data areas.
Note: Using reason code ‘1’ might cause the system to immediately terminate some address spaces. Use
reason code ‘1’ only under the direction of a system programmer.
Normally, the system notifies you of anything it diagnoses or repairs when you request the restart function
with reason code ‘1’. You only get this information on a processor that can communicate with an operator.

Responding to BLW004A
The system displays message BLW004A and waits for operator response. BLW004A supplies information
about the unit of work in progress.
1. Reply ABEND to abnormally terminate the interrupted program and invoke the necessary recovery
routines if the information describes the unit of work you suspect has a problem.
Repeat this process of invoking restart procedure replying to BLW004A until you interrupt the work
that has the problem.
2. Reply RESUME to end further restart processing and allow the interrupted work to continue if the
message indicates that there are no batch jobs or time-sharing users.

18 z/OS: MVS System Commands

 3. Reply RESUME to end further restart processing and allow the interrupted work to continue if the
message indicates that the WTO buffer limit has been exceeded.
4. Reply REPAIR if you suspect a system problem that is not related to the work currently in progress.
The system diagnoses and repairs some problems that might be causing the abnormal behavior.
Note: Replying REPAIR might cause the system to immediately terminate some address spaces. Reply
REPAIR only at the direction of the system programmer.

Activating a workload management service policy

You can use the VARY WLM command to activate a named service policy for a sysplex. The service policy
must be defined in the workload management service definition and must have been previously installed
on the WLM couple data set.
You can also activate a workload management service policy by using the online ISPF administrative
application. Refer to z/OS MVS Planning: Workload Management for more information or see your service
administrator.
This command activates the named service policy on all systems in the sysplex.
For complete information on how to use the VARY command to activate a workload management service
policy, see “Activating a service policy” on page 784.

Controlling time-sharing
Time-sharing allows programmers at remote terminals to develop, test, and execute programs without
the turnaround delays that occur when they submit jobs to a computer center. With time-sharing, a large
number of jobs can share the resources of a system concurrently, and remote terminal users can exercise
primary control over the execution of their jobs. Therefore, we can define time-sharing as the shared,
conversational, and concurrent use of a computing system by a number of users at remote terminals.
Time-sharing in z/OS is provided by TSO/E. For more information about TSO/E see z/OS TSO/E User's
Guide.
You can display information about logged-on time-sharing users by using the DISPLAY command. You can
keep track of terminal users logging on and off the system by using the MONITOR command. In response
to the MONITOR command, the system displays the user id for each LOGON and LOGOFF. To stop the
system's monitoring of terminal use, issue the STOPMN command.
To communicate with time-sharing users you can use the SEND command to:
• Send messages to specific users or all users who are receiving messages
• Send messages to specific users or to all users logging on to the system
• Save messages in the broadcast data set
• List messages in the broadcast data set
• Delete messages from the broadcast data set
The broadcast data set, SYS1.BRODCAST, has mail and notices sections.

Controlling jobs
A job is the basic unit of work for the system. Job control language (JCL) identifies a job to an operating
system and describes the job's resource requirements. The JOB JCL statement identifies a job's beginning
and contains such information as:
• Job name
• Job account number
• Job class

System operations 19
 • Job priority.
Using job-related commands, you can start, stop, or cancel a job. You can also modify a job's parameters
and restart a job that has failed. There are two kinds of jobs in the system: queued jobs and jobs that are
selected on demand. Queued jobs are managed by JES. Jobs that are selected on demand (referred to as
demand-selected) are created as the result of START, MOUNT, and LOGON commands.

Starting a job
Using the START command, you can start jobs from the console. You can also use the START command to
cause the JES internal reader facility to read a job from a tape or direct access volume.

Stopping a job
Using the STOP command, you can stop a job if the programmer has coded a stop routine in the program.

Cancelling a job
Using the CANCEL and FORCE commands, you can cancel a job that is executing. If the job is not currently
executing, use a subsystem command to cancel it.

Passing information to a job

Use the MODIFY command to pass information to a job. This information may be used by the currently
running program. Note that you can only pass information that is already defined in the currently running
program.
Note to Programmers: For more information, see the section on communicating with a program using
EXTRACT or QEDIT in z/OS MVS Programming: Authorized Assembler Services Guide.

Restarting a job
Once a job is executing, it might end abnormally because of a hardware, programming, or system error.
This might happen any time during program execution. Valuable machine time would be lost if an
abnormal end occurred during one of the last job steps of a multistep program or in the middle of a long
job step, and execution had to start again at the first job step. There are two ways of avoiding this
problem: automatic restart and deferred restart.
For JES2 jobs and JES3 jobs, the checkpoint/restart feature of the system allows a job that ends
abnormally to restart either at the beginning of a job step or at a checkpoint within the current step. The
programmer submitting the job provides for an automatic restart or a deferred restart.

Automatic restart
If the programmer submitting the job has provided for an automatic restart and the job ends abnormally,
you receive the following system message:

* id IEF225D SHOULD jobname.stepname.procedure checkid RESTART

This message allows you to prevent repeated restarts at the same checkpoint or job step.
When this message appears, use the REPLY command to respond YES, HOLD, or NO, as follows:
• Reply YES if the restart is to be performed at a specific checkpoint or job step for the first time. (If it is a
job step restart and the step to be restarted used a card input data set that was not part of the SYSIN
stream, you must return to the appropriate hoppers all cards read by the job step before it ended
abnormally. If it is a checkpoint restart, follow the programmer's instructions for replacing the input
cards.)
• Reply HOLD if you want to defer the restart: for example, to permit another job to run first. You must
issue the appropriate subsystem command when you are ready to restart the job. Also, if you want, you

20 z/OS: MVS System Commands

 can cancel the job. However, cancelling the job can cause unrecoverable paging space or the failure of
certain data sets to be deleted if the job was using virtual I/O.
• Reply NO if a restart at a specific checkpoint or job step has been requested repeatedly. When your
reply is NO, and the programmer wants a restart to be performed, he must resubmit the job for a
deferred restart.
If the programmer specifies VIRTUAL=REAL (V=R), the job is processed entirely in central storage; it is not
paged out. For a V=R job, the restart might be delayed while the system waits for the allocation of storage.
If another job is using the required storage, you get no message, only a delay. Enter the DISPLAY A,L
command to see if a system task or another job is using the storage required by the job with a V=R region.
You can then stop or cancel the conflicting task or job.
Note: Any operator commands in the input stream of the job step being restarted are not executed.

Deferred restart
If the programmer submitting the job has provided for a deferred restart and the job ends abnormally, the
programmer must resubmit the job for the deferred restart. To restart the job, the programmer must
provide a restart deck for submission to the system through the system input reader. The JCL statements
to be included in the restart deck are described in detail in z/OS MVS JCL User's Guide.
If you change the device configuration of your system after a job ends abnormally, restart the job carefully.
For example, enough devices must be available to satisfy the needs of the job step being restarted. The
system under which a step restart is run need not be the same as it was for the job's original execution.
However, a checkpoint restart should be run under the original system unless the alternate system can
meet the following restrictions:
• The job entry subsystem is the same.
• The release number is the same.
• The link pack area modules in use at the checkpoint reside in the same storage locations.
• An area of storage identical to the original area is available to a V=R job.
If the required storage is not available, the system cancels the restart and you receive the following
message:

IEF209I VIRTUAL STORAGE UNAVAILABLE FOR jobname.stepname.procedure

Required storage might not be available for one of the following reasons:
• The link pack area expands into the required storage. This expansion can occur if an IPL has been
performed between the original execution of the job and the restart. If it does occur, contact your
system programmer for a respecification of the system parameters and reIPL using the new values.
• The system storage area expands into the required storage. When this expansion occurs, contact your
system programmer for a respecification of the SQA and CSA system parameter and reIPL using the new
values.
When a job restarts correctly, you receive two messages: IEF006I JOB RESTARTING and IEF008I JOB
RESTARTED. If, for V=R jobs, these messages do not appear, enter DISPLAY A,L to see if a system task or
other job is using the required storage. You can then stop or cancel the conflicting job. The system might
ask you to mount data volumes other than those required at the beginning of the job. In addition, any card
input data sets that have been used by the failing job step must again be made available to the system.
For more information on deferred restart, see z/OS DFSMSdfp Checkpoint/Restart.

Controlling started tasks

A started task, like a job, is a basic unit of work for the system. However, started tasks differ from jobs in
that started tasks are always demand-selected; that is, the operator or a program must take action to
initiate a started task.

System operations 21
 There are several ways to initiate started tasks:
• With a START command, described in Chapter 4 of this book.
• Via TSO/E logons. For information on using TSO/E logons, refer to the TSO/E publications.
• With ASCRE (address space create) macros in programs. For information on how to use the ASCRE
macro, refer to z/OS MVS Programming: Extended Addressability Guide.
Both the START command and the ASCRE macro create an address space. A START command and an
ASCRE macro started via a START command each will look for a program that has a procedure in
SYS1.PROCLIB; that program will be the first to run in the ASCRE-created address space. Essentially,
using ASCRE is similar to a started task.
For a started task, the system:
• Locates the JCL that starts the task
• Defines the task's address space
• Processes the JCL.
For a started task, operators can do the following:

Task For information, refer to:

Cancel the started task “CANCEL command” on page 158
Display status about the started task “DISPLAY command” on page 239
Force the started task “FORCE command” on page 467
Modify the started task “MODIFY command” on page 483
Name the started task "START Command" “Starting a system task from a
console” on page 728 (JOBNAME= parameter)
Start the started task "START Command" “Starting a system task from a
console” on page 728
Stop the started task “STOP command” on page 743

Controlling system information recording

The system records information that is later used for billing, accounting, or diagnostics. Among the
facilities that record system information are:
• System management facilities (SMF)
• System trace
• The generalized trace facility (GTF)
• Master trace
• Component trace
• The logrec recording medium
The system also records information in the system log and/or the operations log. See z/OS MVS Planning:
Operations for more information.
In addition to these facilities, JES2 and JES3 have their own event trace facilities. These trace facilities
are described in detail in z/OS JES2 Commands and z/OS JES3 Commands.

System management facilities

System management facilities (SMF) consists of system routines and optional user-written exit routines
that collect, format, and record system and job-related information.

22 z/OS: MVS System Commands

 The information gathered by SMF and user-written exit routines is recorded on direct access volumes in
one of the SMF data sets. These data sets, called primary and secondary data sets, must be online at
system initialization. At that time, SMF uses the primary data set as the active recording data set unless it
is full. If the primary data set is full, SMF checks each data set in the order it is listed until it finds one that
is not full. SMF then uses this data set as the active recording data set and requests that the operator
dump all data sets that are not empty.
When the active recording data set becomes full, SMF automatically switches recording from the active
SMF data set to an empty secondary SMF data set, passes control to the SMF dump exit, IEFU29, and
issues a message to indicate that the data set needs to be dumped. Use the SMF dump program,
IFASMFDP, to dump the full SMF data set and to reset the status of the dumped data set to empty so that
it can be used again for recording.
Error Recovery:
If an I/O error occurs while SMF is writing to one of the SMF data sets, you receive a message and SMF
switches to one of the empty secondary data sets.
Switching the SMF Data Sets:
To prepare an SMF data set for dumping before it becomes full, the operator normally uses the SWITCH
SMF command to switch from the current data set to another data set. For the switch to be successful,
there must be an inactive data set that is empty. Therefore, use the DISPLAY SMF command to verify that
there is at least one alternate data set before issuing the SWITCH or HALT command.
The HALT EOD command also prepares an SMF data set for dumping, but use it only when you intend to
quiesce the system in preparation to shut down. Do not use HALT when you intend to keep the system
running. HALT EOD will close the system log and stop SMF recording.
Restarting SMF:
Because SMF runs in its own address space, you can restart SMF with the SET SMF command. When you
enter that command, this message appears:

IEE980I SMF IS BEING RESTARTED

When the restart is complete and recording starts, the following message appears:

IEE360I SMF NOW RECORDING ON SYS1.MANx

If the SET SMF command abends while updating the SMF parameters, it might be necessary to terminate
the SMF address space and restart SMF. If the system programmer determines that it is necessary to
terminate the address space, issue:

FORCE SMF,ARM

To restart SMF after the SMF address space terminates, issue the SET SMF command again, specifying a
SMFPRMxx parmlib member containing different parameters.

System trace
System trace is a part of the operating system that records, for diagnostic purposes, events that occur
during system initialization and operation. To record events, system trace provides three types of tracing:
address space, branch, and explicit tracing. System trace can be used between subsystem initialization
and the start of the generalized trace facility (GTF). For information on controlling system trace, see
“TRACE command” on page 749.

System operations 23
The generalized trace facility
The generalized trace facility (GTF), like system trace, gathers information used to determine and
diagnose problems that occur during system operation. Unlike system trace, however, GTF can be tailored
to record very specific system and user program events. For information about starting and stopping GTF,
see “START command” on page 727 and “STOP command” on page 743. For information about using GTF,
see z/OS MVS Diagnosis: Tools and Service Aids.

Master trace
Master trace is a diagnostic aid that maintains a trace table of console messages in virtual storage. When
master trace is active, the master trace table is embedded in dumps that have the TRT option or contain
the master scheduler's private address space. Master trace can eliminate the need to submit a portion of
the system log to IBM if there are problems in message processing. It also can ensure that the messages
accompanying a dump are the ones that correspond to the problem. The TRACE command controls
master trace. For a more detailed description of master trace, see z/OS MVS Diagnosis: Tools and Service
Aids.

Component trace
Component trace is a diagnostic aid that system programmers can use to trace the action of certain
system components. Component trace enables the programmer to use the TRACE command to start and
stop component trace. The components that use the component trace command must first invoke the
define component trace service and define the name of the component requesting the service and the
name of the start/stop routine that will get control when the TRACE operator command is issued.

Logrec recording medium

When an error occurs, the system records information about the error in either the logrec data set or a
logrec log stream. The diagnostic information provides a history of all hardware failures, selected software
errors, and selected system conditions.
Use the records in the logrec data set or the logrec log stream as a companion to dump data. The
information in the records will point the system programmer in the right direction while supplying
symptom data about the failure.
For more information about log streams, see z/OS MVS Setting Up a Sysplex . For more information about
initializing a logrec data set or setting up a logrec log stream, see z/OS MVS Diagnosis: Tools and Service
Aids.

Controlling automatic tape switching

In a sysplex, there are MVS operational considerations for two types of tape devices:
• A dedicated tape device is varied online to one system at a time. For a second system to use that same
device, an operator issues VARY commands (first VARY OFFLINE, then VARY ONLINE) to make the
device available to the second system.
• An automatically switchable tape device can be online to more than one system at a time. For one
system to use an automatically switchable tape device, then another system to use the same device, an
operator does not have to issue any VARY commands. In many ways, automatically switchable tape
devices are similar to JES3-managed devices. They require that the systems in the sysplex
communicate with each other.
Through system commands, the operations staff plays a key role in setting up and maintaining automatic
tape switching (that is, using automatically switchable tape devices). For example, a device is
automatically switchable after the following operational actions are taken:
1. The device is defined as automatically switchable.

24 z/OS: MVS System Commands

 The VARY AUTOSWITCH command, as described in “Defining automatically switchable devices” on
page 25, turns the AUTOSWITCH attribute on and off.
2. The device is varied online through the VARY ONLINE command.
3. Before z/OS Release 2, the connection between participating systems and the coupling facility is active
and an IEFAUTOS structure is defined in the active coupling facility resource management (CFRM)
policy.
Systems in a sysplex store the status of online automatically switchable tape devices in IEFAUTOS.
With z/OS Release 2 and higher, the ATS STAR design improves the availability and system
management characteristics of the previous automatic tape switching function. ATS STAR does not use
the IEFAUTOS structure but instead uses global resource serialization and XCF services to maintain
serialization when it allocates shared tape devices. To maximize the performance of the ATS STAR
function, use the global resource serialization STAR configuration rather than the ring configuration.

Defining automatically switchable devices

To define a device as automatically switchable, the device must be in a varied-offline state. Use the
following command:

VARY device,AUTOSWITCH,ON

The detailed description of this command is in “Defining a tape device as automatically switchable” on
page 759.
The AUTOSWITCH definition lasts for the duration of the IPL. Only if the device has been defined through
HCD does the definition persist longer than the duration of the IPL. If HCD turns the attribute on, and the
VARY AS command turns the attribute off, the attribute will be on again at the next reIPL.
The ESCON manager and the IEEVARYD programmable interface can also set the AUTOSWITCH attribute
on and off.

Displaying information about automatically switchable devices

The DISPLAY U,,AUTOSWITCH command summarizes the status of automatically switchable devices. The
display includes the following information:
• The name of the system to which the device is allocated
• The name of the job
• Volume serial number, if one is mounted and the device is allocated.
If a device is offline to the issuing system, the display shows “OFFLINE” in the status field and the display
provides no other information about the device.
The following example shows information that appears in response to DISPLAY U,,AUTOSWITCH. Ten
devices are defined automatically switchable in the sysplex. Four of those devices (identified by “A” in
STATUS column) are allocated to jobs running on SYS5 and SYS6; two of the devices (identified by
“OFFLINE” in the STATUS column) are varied offline to the issuing system; and the status of the other four
devices is not known.

System operations 25
 - d u,,as
IEE343I 12.24.59 UNIT STATUS FRAME LAST F *E SYS=ALLOC5
UNIT TYPE STATUS SYSTEM JOBNAME ASID VOLSER VOLSTATE
05A8 348S A SYS5 TAPE02 0012 PUB/REMOV
05A9 348S A SYS5 TAPE02 0012 PUB/REMOV
05AA 3480 OFFLINE
05AB 3480 /REMOV
05AC 3480 /REMOV
05B8 349S A -CA SYS6 TAPE01 012E PUB/REMOV
05B9 349S A SYS6 TAPE01 012E PUB/REMOV
05BA 3490 OFFLINE
05BB 3490 /REMOV
05BC 3490 /REMOV

Figure 2. Example of a Successful Response to a DISPLAY AUTOSWITCH Command

The syntax of the DISPLAY U,,AUTOSWITCH command is in “Displaying device status and allocation” on
page 419.
If you want to find out the status of a device that is assigned to a nonparticipating system, issue the
DISPLAY U,,, command on each system that could have varied the device online, including the
participating systems.

Interacting with system functions

Most resource allocation, error recovery, and system monitoring functions in MVS are automatic.
Sometimes, however, the system requests your assistance, takes certain actions that you must
understand and/or correct, or issues messages that make you aware of internal processing. So that you
can plan your actions carefully and respond appropriately to system messages, you need to know how to
interact with the following system functions:
• Device allocation
• Hot I/O detection
• Device boxing

Device allocation
Device allocation is the assignment of input/output devices and volumes to job steps. Requests for device
allocation come from data definition (DD) statements and dynamic device allocation requests.
Data definition (DD) statements can be entered into the system by:
• Job input to the JES reader
• Jobs submitted through the TSO SUBMIT command
• Started tasks
• The MOUNT command
• TSO LOGONs
• APPC transactions
Dynamic device allocation/unallocation requests, in contrast, originate within executing programs.
While performing device allocations, the system might ask you to:
• Mount or dismount volumes
• Make decisions (for example, to bring a device online immediately or to wait)
To control the amount of work you have to do related to device allocation, you might want to restrict
device allocation requests.
To control device allocation requests from data definition (DD) statements, you might restrict each of the
forms of input for these statements (for example, by holding the reader, or by setting a maximum LOGON

26 z/OS: MVS System Commands

count). Because they originate within executing programs, however, you cannot control dynamic device
allocation/unallocation requests.

Device assignment
Operationally, the assignment of devices is influenced by:
• The online/offline status of the device. Generally, to be allocated to job steps, devices must be online.
Exceptions are (1) when the online test executive program (OLTEP) or a similar testing program is
running and (2) when teleprocessing devices are allocated. You can bring offline devices online with the
VARY command or in response to the allocation recovery message, IEF238D.
• The MOUNT attribute. The MOUNT attribute, which applies only to tape or DASD devices, is influenced
by the MOUNT and UNLOAD system commands, and, during initialization, by entries in the VATLSTxx
parmlib member. Allocation requests that can be satisfied by mounted devices are processed quickly
and without your intervention.
• The USE attribute. A parameter of the MOUNT command, the USE attribute affects the type of data sets
that can be allocated on a tape or DASD volume. The USE attribute can also be set during initialization
by entries in the VATLSTxx member of parmlib. Having a proper mix of volumes with various USE
attributes reduces the amount of volume mounting.
• The READ-ONLY attribute of the device. A DASD volume defined with the READ-ONLY attribute will not
be allocated for DISP=NEW or to extend a data set.
The information from data definition (DD) statements determines the input/output resources to assign to
a job or job step and the volumes that are required. If a requested volume is not mounted, the system
issues a mount message asking you to mount a specific volume or scratch volume. If you mount the
wrong volume, the system finds out as soon as it reads the volume label. The system unloads the volume
and repeats the mount message.
When you know that several jobs are going to need a volume, use the MOUNT command to reserve that
volume on a device. Allocation processing is faster when the required volume is reserved rather than
removable. The system does not demount volumes reserved by a MOUNT command until you issue an
UNLOAD command.
Note: Do not use the MOUNT command for devices managed by JES3. See z/OS JES3 Commands.
Never mount a blank tape volume unless specifically directed to do so because the system scans the
entire volume for a tape label and this scanning wastes time. If an unlabeled tape is needed, write a
tapemark to avoid unnecessary scanning. After you mount the tape volume and ready the drive, the
system reads the volume label. If an incorrect volume is mounted, the system unloads the incorrect
volume and repeats the mounting message.
Note:
1. Occasionally, you receive two mount messages for the same volume, one starting with IEF and the
other with IEC. Treat the two messages as though they were one. The second is a reminder.
2. When referring to I/O devices in the devnum parameter of system commands, use the unique 3-digit or
4-digit device number for each device. You can precede the device number with a slash (/). The slash is
optional on many commands, but required for 4-digit device numbers on some commands, such as
MOUNT and START.
3. Your installation can define symbolic group names of one to eight characters to be used by
programmers in data definition (DD) statements. The number of devices associated with a symbolic
name can range from one to the total number of devices in your installation. The symbolic name allows
the devices to be grouped according to the attributes your installation considers significant. Do not use
these symbolic names in system commands.
4. Make sure there are sufficient work volumes available to satisfy requests for temporary data sets at
peak loads. A shortage of work volumes can cause the system to request additional scratch volumes.
Balance work volumes across channel paths to increase system efficiency.

System operations 27
 Automatic volume recognition
Automatic volume recognition (AVR) allows you to mount labeled volumes on unused drives not managed
by JES3. The system recognizes and remembers these volumes, and assigns the drives to later job steps
as required.

Device allocation and system commands

Many system commands run in the master scheduler's address space. Some of these commands allocate
data sets as part of their processing.
The TIOT size for the master scheduler address space is 12K, which allows for approximately 600 unit
allocations. Data sets that reside on multiple volumes or that have a data class with a dynamic volume
count greater than 1 use more TIOT space than single volume data sets, reducing the number of data sets
that can be allocated.
For more information about TIOT space calculations, see the description of the TIOT SIZE parameter for
the ALLOCxx parmlib member in z/OS MVS Initialization and Tuning Reference.

Hot I/O detection

Hot I/O refers to the repeated I/O interruptions that result from hardware malfunctions. Because it can
cause the system to loop or to fill the system queue area with I/O control blocks, hot I/O needs to be
detected quickly and corrected.
When the number of repeated interruptions exceeds an installation-defined threshold value, the system
assumes there is a hot I/O condition. If your installation has set up hot I/O recovery defaults that the
system can use, the system issues message IOS109E and attempts to recover from the hot I/O condition.
(See the IECIOSxx parmlib member in z/OS MVS Initialization and Tuning Reference.) If your installation
has not set up hot I/O recovery defaults, the system issues one of the following messages, if possible, or
loads one of the following restartable wait states and prompts you to take action:

IOS118A or IOS111D — HOT NON-RESERVED DIRECT ACCESS DEVICE

(Wait state 111)
IOS119A or IOS112D — HOT RESERVED DIRECT ACCESS DEVICE
(Wait state 112)
IOS117A or IOS110D — HOT NON-DIRECT ACCESS DEVICE
(Wait state 110)

When you take action, try to solve the problem at the lowest possible level. That is, try to correct the
problem at the device first and then at the control unit. You could power the device off and on. If that does
not help, you could reset the control unit if the affected device is not a direct access device. If these
actions do not correct the problem, you might have to physically disconnect the device or control unit.
Whatever action you take, tell the system what you are doing by responding to the prompting message or
restartable wait state. See z/OS MVS System Messages, Vol 9 (IGF-IWM) for information about IOS
messages, and z/OS MVS System Codes for a detailed explanation of the restartable wait states and your
response to them.
“Hot I/O” on page 58 describes how z/OS handles a hot I/O condition.

Device boxing
In certain error recovery situations and in response to certain commands, the MVS system can “box” an
I/O device. Once a device enters a boxed state, the system:
• Immediately terminates I/O in progress on the device
• Rejects future I/O requests (by a user or by the system) to the device as permanent I/O errors
• Rejects any attempts to allocate the device
• Puts the device in pending-offline status
The system boxes a device:
• When it detects hot I/O on the device and the device cannot be recovered

28 z/OS: MVS System Commands

• When, because of a channel path error, it takes the last path to the device offline
• When, because of a channel path error, it releases a reserve or assign on the device
• When it releases an unconditional reserve for the device
• When you issue a VARY OFFLINE command with the FORCE option for the device
• When you issue a CONFIG OFFLINE command with the FORCE option for a channel path, and the
command releases a hardware reserve or assign, or removes the last path to the device
Note:
1. Because you might release a reserve or assign on a device and cause a data integrity exposure, be sure
to use the VARY OFFLINE and CONFIG OFFLINE commands with FORCE only in emergency situations.
2. When you fix whatever caused the system to box a device, you can take the device out of the boxed
state at any time by issuing VARY device ONLINE. Once the VARY command takes effect, the device is
again available for IOS and any subsequent allocations (i.e., an allocation done in another step or job,
or another dynamic allocation). Note that after the VARY command takes effect, the device is not
considered for the current allocation.
You can make a boxed alias unit control block (UCB) of a parallel access volume available using the
DEVSERV, QPAVS command.
3. You cannot take a boxed device out of the boxed state by replying with the device name to the
allocation recovery message, IEF238D.

Boxed device - operator actions

Device boxing is used by the MVS system during error recovery as a means of maintaining data integrity
and preventing data corruption. A device is also boxed if the operator issues the VARY
devnum,OFFLINE,FORCE command. When a device is boxed, all outstanding I/O operations for the device
are ended with permanent error status, and no new allocations to the device are allowed.
It is very important to understand that in the case of shared DASD, the boxed device is boxed only to the
system that originated the boxing. The device is still accessible from other systems. This may lead to
incorrect (or incomplete) data on the DASD volume. Such a situation must be reported to the owner of
the data on the boxed-DASD.
• If the data-files are shared with other systems, it is recommended to put the device in offline status on
all the sharing systems. Use VARY OFFLINE or OFFLINE,FORCE commands.
• After the data sets are checked and recovered, the DASD volume may be put back online.
A device that is boxed and offline can be brought back online with the VARY devnum,ONLINE command.
This will enable the UCW and perform online processing to the device. Assuming that the error condition
has been resolved, the device will come online. If the error condition still exists, the device may remain in
the boxed state.
A device that is allocated boxed may be brought back online with the VARY devnum,ONLINE,UNCOND
command, if account procedures allow. Note that in this case, if the boxed device is DASD, volume
verification (that is, VOLSER checking) is not performed. In this case, the VOLSER information can be
obtained by entering a VARY devnum,ONLINE command to the DASD device or then entering a MOUNT
command.
A DASD device that was offline (either boxed or not boxed) has the VOLSER details obtained from the
device through the VARY devnum,ONLINE command. The VOLSER information is placed in the UCB as part
of the vary online operation, if the vary online is successful, that is, that no out-of-line situations exist, for
example, it is not a duplicate volume.

Recovery for a failing alias unit control block (UCB)

For a parallel access volume, the status of a base UCB affects the status of its alias UCBs. The status of an
alias UCB, however, might not affect the status of its base UCB. When the system detects a problem with
an alias UCB, a recovery action applies to the base and its alias UCBs. If an alias UCB becomes boxed, you
can unbox the alias with the following DEVSERV command:

System operations 29
 DEVSERV QPAVS,devn,UNBOX

Error messages that display in the following situations are the only indication that an alias UCB is boxed:
• The device is varied online
• A hardware change is activated
• The system is in recovery

Boxed tapes under tape management system control

If a boxed tape drive is controlled by a tape management system, the drive will remain in the A-BOX state.
Unless the tape management system is taken down, the VARY devnum,ONLINE,UNCOND command must
be used to return the tape drive to the online state.

Tape boxed due to lost assign

If tape CHPIDs, control unit, switches, or ESCON connections are incorrectly handled, a tape ASSIGN may
be reset (lost). When this occurs on the last path to the tape drive, the MVS system will box the device.
If an ASSIGN lost condition occurs while a tape was loaded, the MVS system may not be able to unload
the tape. If this happens, as indicated by the cartridge remaining in the drive after the job has completed,
perform the following actions at the tape unit:
• Place the READY/NOT READY switch to the NOT READY position.
• Toggle the UNLOAD switch, and the tape should unload.

Printer boxed due to lost assign

If printer CHPID, control unit, switch, or ESCON connections are incorrectly handled, a printer ASSIGN
might be reset (lost). If this occurs on the last path to the printer, the MVS system will box the device.

30 z/OS: MVS System Commands

1. Locate the device boxed message to determine one of the following causes of the BOX condition:
• I/O Error
• Lost Reserve or Lost Assign
• Lost Last Path (No Paths)
• UR Boxed
• Subchannel Recovery
• Vary Force
• Hot I/O
2. Correct the cause of the BOX condition before proceeding, as described in Table 3 on page 31.
3. Recover the boxed device:
Issue the 'D U,,,devnum,1' command to determine device status.

Figure 3. Boxed device recovery procedure

The following procedures are recommended for use when a boxed condition is reported:

Table 3. Correcting boxed conditions

Cause Operator Action
I/O Error Correct the cause of the I/O error condition and then attempt to bring the
device online

System operations 31
 Table 3. Correcting boxed conditions (continued)
Cause Operator Action
Lost Reserve or Assign For tape, if mount status=private, determine if any jobs were run or accesses
made to the volume from any other system while it is in the boxed state.
If yes, an integrity problem may exist and the device should not be varied
online until the integrity of the volume can be assured.
If no, you may attempt to un-BOX the device by varying it online.
If the printer Assign was lost, it is possible the printer was assigned to
another host. If so, first vary the printer offline from the other host and then
vary online the printer to this host. Otherwise, attempt to vary the printer
online to this host.

Lost Last Path Return the paths to an operational state and then vary the device online.
Subchannel Recovery Identify and repair resource, then vary the device online
U/R ‘Boxed’ Correct the cause of the I/O error condition and then attempt to bring the
device online.
VARY FORCE command Determine why the operator entered the VARY devnum,OFFLINE,FORCE
command. Correct the condition on the system and vary the device back
online.
Hot I/O Identify and repair device, then vary the device back online.
Shared Tapes Identify and repair device, then enter VARY devnum,ONLINE,UNCOND to
unbox the device and bring it online

Command flooding
Commands that run in the *MASTER* or CONSOLE address space are divided into six command classes.
In each class, only 50 commands can execute at one time. Any additional commands in that class must
wait for execution.
To manage the number of commands that are awaiting execution, the system operator can issue the
CMDS command to display the status of commands, remove selected commands that are awaiting
execution, or cancel commands that are executing. When a command is removed before execution, the
command issuer receives message IEE065I COMMAND NOT EXECUTED, CMD=command instead of the
usual command response message. When a command is canceled, the command is terminated with an
ABEND code 422, reason code 00010301.

Class M1 commands
Class M1 commands are commands that are attached in the *MASTER* address space, and are
considered essential to clearing a backlog of other commands:
• DISPLAY AUTOR
• DISPLAY GRS
• DISPLAY MPF
• DISPLAY MSGFLD
• DISPLAY SLIP
• DISPLAY XCF
• DUMP
• DUMPDS

32 z/OS: MVS System Commands

 • QUIESCE
• SET
• SETMF
• SETXCF
• SLIP
• VARY XCF

Class M2 commands
Class M2 commands are ordinary attached commands that run in the *MASTER* address space:
• ACTIVATE
• CONFIG
• DEVSERV
• DISPLAY ALLOC
• DISPLAY APPC
• DISPLAY ASCH
• DISPLAY ASM
• DISPLAY CEE
• DISPLAY CF
• DISPLAY CNGRP
• DISPLAY DIAG
• DISPLAY DLF
• DISPLAY DUMP
• DISPLAY ETR
• DISPLAY GTZ
• DISPLAY HIS
• DISPLAY IEFOPZ
• DISPLAY IQP
• DISPLAY IOS
• DISPLAY IKJTSO
• DISPLAY IPLINFO
• DISPLAY LLA
• DISPLAY LOGGER
• DISPLAY LOGREC
• DISPLAY MATRIX
• DISPLAY MMS
• DISPLAY OMVS
• DISPLAY PCIE
• DISPLAY PARMLIB
• DISPLAY PPT
• DISPLAY PROD
• DISPLAY PROG
• DISPLAY RRS
• DISPLAY SMF

System operations 33
 • DISPLAY SMFLIM
• DISPLAY SMS
• DISPLAY SSI
• DISPLAY SYMBOLS
• DISPLAY TCPIP
• DISPLAY TRACE
• DISPLAY U
• DISPLAY UNI
• DISPLAY VIRTSTOR
• DISPLAY WLM
• HALT EOD
• IOACTION
• LIBRARY
• LOGON (not MCS)
• MOUNT
• PAGEADD
• PAGEDEL
• RESET jobname
• SETALLOC
• SETAPPC
• SETCEE
• SETETR
• SETGRS
• SETGTZ
• SETIOS
• SETLOGR
• SETLOAD
• SETLOGRC
• SETOMVS
• SETPROG
• SETSMF
• SETSMS
• SETSSI
• SETUNI
• START
• SWAP
• SWITCH SMF
• TRACE
• UNLOAD
• VARY CU
• VARY GRS
• VARY ONLINE / OFFLINE
• VARY PATH

34 z/OS: MVS System Commands

 • VARY SMS
• VARY SWITCH
• VARY TCPIP
• VARY WLM

Class M3 commands
Class M3 commands are ordinary attached commands that run in the *MASTER* address space. These
commands can take a long time to execute, thus they require a command class different from Class M2:
• SEND

Class C1 commands
Class C1 commands are commands that are attached in the CONSOLE address space, and are considered
essential to clearing a backlog of other commands:
• DISPLAY CONSOLES
• DISPLAY EMCS
• DISPLAY R
• LOGOFF
• LOGON (MCS)
• REPLY
• SETAUTOR
• VARY CN
• VARY CONSOLE

Class C2 commands
Class C2 commands are ordinary attached commands that run in the CONSOLE address space:
• CHNGDUMP
• CONTROL M
• DISPLAY A
• DISPLAY C,K
• DISPLAY JOBS
• DISPLAY OPDATA
• DISPLAY PFK
• DISPLAY TS
• RESET CN
• SETCON

Class C3 commands
Class C3 commands are ordinary attached commands that run in the CONSOLE address space. These
commands can take a long time to execute, thus they require a different command class than Class C2:
• ROUTE

Inline commands
Inline commands are not attached, but execute under the SVC 34 issuer's task. These are not subject to
the limits, and cannot be displayed, removed, or canceled, using the CMDS command:
• CANCEL

System operations 35
 • CMDS
• CONTROL (except K M)
• DISPLAY NET
• DISPLAY T
• DISPLAY TP
• FORCE
• HALT NET
• HOLD TP
• LOG
• MODE
• MODIFY
• MONITOR
• RELEASE TP
• STOP
• STOPMN
• VARY NET
• WRITELOG

Setting up hardware event data collection

Hardware instrumentation services (HIS) is a function that collects hardware event data for IBM System
z10 or later machines.
Before you start the HIS data collection, you may first need to authorize to the sampling facilities and
counter set types you want to use through the support element (SE) console. For information about how
to set up the authorization of the sampling facilities and counter sets, see Support Element Operations
Guide for your machine type on the Resource Link home page (www.ibm.com/servers/resourcelink).
In addition, with the enhanced-monitor facility hardware released with z196 machines, the HIS function
expands into a z/OS software event data collector that will be used by IBM for improved problem analysis.
The z/OS event counters are viewed as an additional hardware counter set, and there is no authorization
required to use the hardware.
The HIS function will not work if your z/OS operating system is running as a z/VM guest.
With HIS, you can either collect instrumentation data in z/OS UNIX files and SMF buffers through the HIS
profiler, controlled through the MODIFY hisproc,BEGIN command, or you can collect instrumentation
data dynamically through the HISSERV service. See “HISSERV service overview” on page 46. Both
services require initialization of the HIS address space.
If you plan to collect sampling or load map files, you must have z/OS UNIX System Services active, and
you must perform all of the steps in “Steps for starting the HIS address space” on page 37. If you only
plan to collect hardware or software (or both) counter sets into SMF type 113 records (and not z/OS UNIX
files), then you can perform only the required steps according to the following guidelines:
• Step 1 is always required (RACF definition).
• Step 2 is only required if creating z/OS UNIX output files.
• Step 3 is only required if creating z/OS UNIX output files.
• Step 4 is always required (SMF enablement), especially if not collecting z/OS UNIX output files, as this is
the only alternative output.
• Step 5 is always required.

36 z/OS: MVS System Commands

Steps for starting the HIS address space
Follow these steps to set up hardware event data collection:
1. Define the HIS-started task to RACF.
To set up the HIS-started task to RACF, you must define a profile for it to the RACF generic resource
class called STARTED by using the RDEFINE command.
Note: If the STARTED class is not active, RACLISTed, and GENERIC profile checking is not activated,
use the RACF SETROPTS command to activate (CLASSACT), RACLIST, and GENERIC the STARTED
class first before you can define a new profile to it. In most environments, this might already have been
done. Therefore, you might not have to include the SETROPTS command to CLASSACT, RACLIST, and
GENERIC the STARTED class. In this example, these SETROPTS commands are shown for
completeness. Running these commands when the STARTED class is already activated has no effect.
Example 1: RACF commands to define HIS-started task to RACF:

//DAEMONS EXEC PGM=IKJEFT01

//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
SETROPTS CLASSACT(STARTED)
SETROPTS RACLIST(STARTED)
SETROPTS GENERIC(STARTED)
RDEFINE STARTED HIS.* STDATA(USER(HIS) TRUSTED(YES))
SETROPTS RACLIST(STARTED) REFRESH
SETROPTS GENERIC(STARTED) REFRESH

2. Define a user ID for the HIS started task with an OMVS segment that specifies:
• Any UID
• A default HOME directory
For example, you might define the user ID as follows:

adduser HIS omvs(uid(25) home('HIS'))

where UID(25) is the OMVS uid and /HIS is the default home directory.
Note: While OMVS access is required, there is no special authorization needed. Also, any directory can
be used for the HOME directory.
Example 2: Defining a HIS user ID for the HIS started task:

//DAEMONS EXEC PGM=IKJEFT01

//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
ADDUSER HIS OMVS(UID(12) HOME('/HIS'))
SETROPTS NOCLASSACT(SECLABEL) NORACLIST(SECLABEL)
ALTGROUP SYS1 OMVS(GID(0))

Example 3: RACF commands to perform steps 1 and 2 in one job:

//DAEMONS EXEC PGM=IKJEFT01

//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
SETROPTS CLASSACT(STARTED)
SETROPTS RACLIST(STARTED)
SETROPTS GENERIC(STARTED)
RDEFINE STARTED HIS.* STDATA(USER(HIS) TRUSTED(YES))
SETROPTS RACLIST(STARTED) REFRESH
SETROPTS GENERIC(STARTED) REFRESH
ADDUSER HIS OMVS(UID(12) HOME('/HIS'))
SETROPTS NOCLASSACT(SECLABEL) NORACLIST(SECLABEL)
ALTGROUP SYS1 OMVS(GID(0))

System operations 37
 3. Create the HOME directory in a local z/OS UNIX file system by issuing the mkdir command under z/
OS UNIX. Also assign read/write/exec authority (making a HIS data collection directory):

omvs
tso omvs
mkdir /HIS

In this example, /HIS will be the default directory where the HIS output file will be stored. IBM may
request this data and the SMF records for problem diagnosis. This directory is used only for the HIS
profiler.
Note: If you plan to capture lots of sample data, this output directory for HIS data needs to be large
enough.
For sample data, a directory with 1 GB available is recommended. For more information about
calculating the disk space for sampling output, see “Sampling function output in a .SMP file” on page
45.
4. If you would like SMF records also, enable SMF record type 113 using either the SET SMF or SETSMF
command. For example, you might enable SMF record type 113 as follows:
a. Issue SET SMF=xx to select the SMFPRMxx parmlib member you want to update with information
for SMF record type 113.
b. Reply to the message issued in response to the SET SMF=xx command to change any SMFPRMxx
parameters. For example, you might reply with the following information:

nn,sys(type(113)),intval(01),maxdorm(0100)

Then, reply nn,U to continue.

This reply will prompt the system to collect type 113 records, give you one minute collection intervals,
and the data will only stay in the buffers for one minute before being written to the MANA or MANB
data set. You can change other SMFPRMxx parameters on the SET SMF command response or the
SETSMF command. See z/OS MVS Initialization and Tuning Reference.
5. Start the HIS started task with the following command. A hisproc procedure is delivered in PROCLIB as
member HIS.

START hisproc

This command does the following:

• Starts the hardware instrumentation services address space for the system
• Creates a new instrumentation started task, hisproc for the system
• Initializes the HISSERV service and allows profilers to request authorization and collect
instrumentation data through the HISSERV interface.
See “Starting hardware instrumentation services (HIS) ” on page 736 for complete information about
the START hisproc command.
Note that it is important to assign a sufficiently high dispatch priority to the instrumentation started
task hisproc, so that the task can write sampling data to the .SMP output files in a timely manner.

Steps to use the HIS profiler for hardware data collection

• To configure and start a run of data collection on a system, issue one of the following commands:
– If you want to collect sampling and counter counter-set data, issue the following command to
configure and start a run of data collection on a system:

MODIFY hisproc,BEGIN

This data will be stored in the z/OS UNIX files and SMF data sets.

38 z/OS: MVS System Commands

 – If you want to collect counter-set data and only want the results to be output as SMF type 113
records (and not into a z/OS UNIX file), issue the following command to configure and start a run of
data collection on a system:

MODIFY hisproc,BEGIN,CNTONLY,CNTFILE=NO

Note that you must explicitly start each run of hardware data collection.
You can specify in advance the duration of a run of data collection you want by using the DURATION
parameter on the MODIFY hisproc,BEGIN command.
If you configure a new processor online in a system after you have already issued the MODIFY
hisproc,BEGIN command to start a data collection run for that system, HIS will enable resources
(counters/samplib) for that CPU. The system does not collect data on a processor that is configured
offline.
Note that z/OS IRD processor management can configure processors offline or online automatically. A
processor is online at the start of the instrumentation run, but it might be configured offline (and
sometimes online again) during the run. The system does not collect data on the offline processor.
See “Starting, configuring, and stopping hardware event data collection” on page 508 for complete
information about the MODIFY hisproc command.
• To explicitly stop a HIS profiler on a system, issue the following command:

MODIFY hisproc,END

Alternatively, you can use the DURATION parameter on the MODIFY hisproc,BEGIN command to
specify when you want a data collection run to end.
The system writes all the collected data to the z/OS UNIX output files at the path specified and to the
SMF data set that is set up by the installation, depending on the parameters provided on the F
hisproc,BEGIN command.
You can also use the STOP hisproc command to stop a run of data collection. Note that if you use the
STOP command, you must restart the address space again with the START command before starting the
next run of data collection. However, use of the STOP command may result in a non-reusable address
space; therefore, the MODIFY command is the preferred means for ending a run of data collection.
See “Starting, configuring, and stopping hardware event data collection” on page 508 for complete
information about the MODIFY hisproc command.

Accessing the output from a hardware event data collection run

For authorized programs using the HISSERV interface, output from a collection run is delivered in storage.
See z/OS MVS Programming: Authorized Assembler Services Reference EDT-IXG for details about the
HISSERV interface. During a HIS Profiler run that requested counter-set data collection, the system writes
the raw data to SMF record type 113, subtypes 1 and 2, at an interval defined by the CNTINTVAL
parameter on the MODIFY hisproc,BEGIN command. The HIS Profiler may also write data to one or more
of the following z/OS UNIX System Services (z/OS UNIX) output files:
• Delta counter data file, which is optional. The system writes the delta data to the z/OS UNIX .CNT output
file at the end of the run. The delta data is the data from the time when the instrumentation run was
initiated until the end of the run, showing the delta incremental values of the instrumentation run on the
specified processor. You can request that the system not create the .CNT file by specifying the
CNTFILE=NO parameter on the MODIFY hisproc,BEGIN command.
• Load map file, which is optional. The system creates one .MAP file, if requested, at the end of the data
collection run. This file contains the load module mapping information for the active system on which
the data collection was done. The results will be more complete if the tracking of directed load modules
is enabled with the SETPROG TRACKDIRLOAD command. See “Tracking directed load modules” on
page 639.

System operations 39
 • Sample data files, which are optional. The system creates one .SMP sample file for each active logical
processor in the system. Sample data contains the addresses of the instructions being executed and the
state information about a specific logical processor. Sample data is written out continuously when the
data collection buffers become full.
For each data collection run, the system may generate one or more z/OS UNIX output files in the HOME
directory or the user-specified directory that follow the naming conventions:
SYSHISyyyymmdd.hhmmss.xxx.CNT
SYSHISyyyymmdd.hhmmss.xxx.MAP
SYSHISyyyymmdd.hhmmss.xxx.SMP.cpu#
The files generated by your data collection run will depend on the MODIFY hisproc parameters you
specify when you start the run.
yyyymmdd
The year, month, and day when the MODIFY hisproc command was processed.
hhmmss
The hour, minute, and second when the MODIFY hisproc command was processed.
xxx
The sequence number of the collection run interval. This starts at 000 and is incremented by one for
every state change detected during a collection run when the action specified for a detected state
change is SAVE. For more information about collection run intervals, see the STATECHANGE parameter
in “Starting, configuring, and stopping hardware event data collection” on page 508.
CNT | MAP | SMP.cpu#
Identifies the file, as follows:
• CNT identifies a counter set data file.
• MAP identifies a load module mapping output file.
• SMP.cpu# identifies a sampling function data file. cpu# is the CPU number, in hexadecimal. There is
one .SMP file for each active CPU.
Example: The system creates the following z/OS UNIX files for a system with three CPUs at 11:30:16 on
2015/05/18:

SYSHIS20150518.113016.000.CNT
SYSHIS20150518.113016.000.MAP
SYSHIS20150518.113016.000.SMP.0000 (for CPU 0)
SYSHIS20150518.113016.000.SMP.0001 (for CPU 1)
SYSHIS20150518.113016.000.SMP.0002 (for CPU 2)

Table 4 on page 41 shows when the HIS Profiler generates the .CNT, .MAP, and .SMP files, based on the
parameters you specify on the MODIFY hisproc,BEGIN command:

40 z/OS: MVS System Commands

 Table 4. z/OS UNIX files generated by the HIS Profiler
.CNT file .MAP file .SMP file
By default, the HIS Profiler The HIS Profiler generates By default, the HIS Profiler
generates a .CNT file, unless you a .MAP file if you use any of the generates a .SMP file unless you
specify CNT=NO, CNTFILE=NO, or following parameters on the specify SMP=NO, CNTONLY, or
MAPONLY. MODIFY hisproc,BEGIN MAPONLY.
command:
Notes:
• MAPASID
1. The HIS Profiler generates
only the .CNT file, and does • MAPJOB
not generate .SMP and .MAP • MAPONLY The the HIS Profiler
output files, if you specify does not generate .SMP
CNTONLY. and .CNT output files if you
2. The HIS Profiler will not specify MAPONLY.
generate the .CNT, .SMP, A .MAP file is only generated
and .MAP output files if you during the last collection run
specify interval of a collection run.
CNTONLY,CNTFILE=NO.

To access the output generated by the HIS Profiler in your z/OS UNIX file system in your HOME directory
or a user-specified directory, use the OBROWSE command on the file, or else use the OGET command to
copy the files to MVS and access the output data there.
Note: When programmatically accessing the output generated by the HIS Profiler, the format of the file
name may change.

Interpreting the z/OS UNIX system services output files

This information describes how to interpret the contents of the .CNT, .MAP, and .SMP output files.

Counter sets output in a .CNT file

The system may generate a .CNT output file after the data collection run. You can request the system to
generate only the delta counter data information in your data collection run by specifying the CNTONLY
parameter on the MODIFY hisproc,BEGIN command. Unless you have specified the CNTFILE=NO
parameter on the MODIFY hisproc,BEGIN command, the HIS Profiler returns the delta data in a z/OS
UNIX output file (SYSHISyyyymmdd.hhmmss.xxx.CNT) in your HOME directory or the user-specified
directory.
The following counter sets can be collected in the .CNT output files:
• Basic counter set
• Problem state counter set
• Extended counter set
• Crypto activity counter set
• z/OS counter set
• MT-diagnostic counter set
See “Starting, configuring, and stopping hardware event data collection” on page 508 for more
information about how to select the type of the counter data set on the MODIFY hisproc command.
The Basic, Problem, Extended, and Crypto activity counter sets require the CPU Measurement Facility to
be installed on the machine and available for any authorized program. The z/OS counter set is used for
IBM diagnostic purposes and requires the Enhanced Monitor Facility to be installed on the machine.
The MT-diagnostic counter set is available only when PROCVIEW CORE is specified in the LOADxx parmlib
member and when running on hardware that supports multithreading (MT).

System operations 41
 The following example shows a .CNT output file that is embedded in the message text of HIS019I. The
output contains counter values for the BASIC, PROBLEM-STATE, CRYPTO-ACTIVITY, EXTENDED, and MT-
DIAGNOSTIC counter sets on a system with two processors (one core). MT-diagnostic counter set data is
reported from one CPU on each core.

HIS019I EVENT COUNTERS INFORMATION VERSION 3

FILE NAME: SYSHIS20100301.161406.000.CNT
COMMAND: MODIFY HIS,B,CNTONLY,CNTSET=ALL
STATE CHANGE: NO MODEL: 2097-710 SEQCODE: 1234567812345678
COUNTER VERSION NUMBER 1: 1 COUNTER VERSION NUMBER 2: 1

COUNTER SET= BASIC

COUNTER IDENTIFIERS:
0: CYCLE COUNT
1: INSTRUCTION COUNT
2: L1 I-CACHE DIRECTORY-WRITE COUNT
3: L1 I-CACHE PENALTY CYCLE COUNT
4: L1 D-CACHE DIRECTORY-WRITE COUNT
5: L1 D-CACHE PENALTY CYCLE COUNT

START TIME: 2010/03/01 16:14:06 START TOD: C59D40379C44268E

END TIME: 2010/03/01 16:16:41 END TOD: C59D40CB3551AAAB
COUNTER VALUES (HEXADECIMAL) FOR CPU 00 (CPU SPEED = 2455 CYCLES/MIC):
0- 3 00000013CBAA4CD7 0000000333EA30C9 000000000A4BCF64 0000000157C1BB9E
4- 7 000000000BF8AE6C 0000000A31F8354C ---------------- ----------------

START TIME: 2010/03/01 16:14:06 START TOD: C59D40379C5A930E

END TIME: 2010/03/01 16:16:41 END TOD: C59D40CB3553932B
COUNTER VALUES (HEXADECIMAL) FOR CPU 01 (CPU SPEED = 2455 CYCLES/MIC):
0- 3 0000004068D6004A 00000011F3F57DE5 000000000BB82A62 000000021A79D610
4- 7 0000000012AFD068 0000001577743AC1 ---------------- ----------------

COUNTER SET= PROBLEM-STATE

COUNTER IDENTIFIERS:
32: PROBLEM-STATE CYCLE COUNT
33: PROBLEM-STATE INSTRUCTION COUNT
34: PROBLEM-STATE L1 I-CACHE DIRECTORY-WRITE COUNT
35: PROBLEM-STATE L1 I-CACHE PENALTY CYCLE COUNT
36: PROBLEM-STATE L1 D-CACHE DIRECTORY-WRITE COUNT
37: PROBLEM-STATE L1 D-CACHE PENALTY CYCLE COUNT

START TIME: 2010/03/01 16:14:06 START TOD: C59D40379C44268E

END TIME: 2010/03/01 16:16:41 END TOD: C59D40CB3551AAAB
COUNTER VALUES (HEXADECIMAL) FOR CPU 00 (CPU SPEED = 2455 CYCLES/MIC):
32- 35 00000000FAB630CB 0000000025556804 000000000082BA33 0000000022DC4926
36- 39 00000000009BABE1 0000000074579FA8 ---------------- ----------------

START TIME: 2010/03/01 16:14:06 START TOD: C59D40379C5A930E

END TIME: 2010/03/01 16:16:41 END TOD: C59D40CB3553932B
COUNTER VALUES (HEXADECIMAL) FOR CPU 01 (CPU SPEED = 2455 CYCLES/MIC):
32- 35 000000006F30CE68 00000000100B5233 00000000003D9C8B 00000000150917D0
36- 39 0000000000432F96 0000000031EBD508 ---------------- ----------------

COUNTER SET= CRYPTO-ACTIVITY

COUNTER IDENTIFIERS:
64: PRNG FUNCTION COUNT
65: PRNG CYCLE COUNT
66: PRNG BLOCKED FUNCTION COUNT
67: PRNG BLOCKED CYCLE COUNT
68: SHA FUNCTION COUNT
69: SHA CYCLE COUNT
70: SHA BLOCKED FUNCTION COUNT
71: SHA BLOCKED CYCLE COUNT
72: DEA FUNCTION COUNT
73: DEA CYCLE COUNT
74: DEA BLOCKED FUNCTION COUNT
75: DEA BLOCKED CYCLE COUNT
76: AES FUNCTION COUNT
77: AES CYCLE COUNT
78: AES BLOCKED FUNCTION COUNT
79: AES BLOCKED CYCLE COUNT

START TIME: 2010/03/01 16:14:06 START TOD: C59D40379C44268E

END TIME: 2010/03/01 16:16:41 END TOD: C59D40CB3551AAAB
COUNTER VALUES (HEXADECIMAL) FOR CPU 00 (CPU SPEED = 2455 CYCLES/MIC):
64- 67 0000000000000000 0000000000000000 0000000000000000 0000000000000000
68- 71 00000000005ABB5D 00000012EE9487DF 0000000000000000 0000000000000000
72- 75 0000000005E0C165 0000000632A0775E 0000000000000000 0000000000000000
76- 79 0000000000ACF18D 0000002085B30F22 0000000000000000 0000000000000000

42 z/OS: MVS System Commands

 START TIME: 2010/03/01 16:14:06 START TOD: C59D40379C5A930E
END TIME: 2010/03/01 16:16:41 END TOD: C59D40CB3553932B
COUNTER VALUES (HEXADECIMAL) FOR CPU 01 (CPU SPEED = 2455 CYCLES/MIC):
64- 67 0000000000000000 0000000000000000 0000000000000000 0000000000000000
68- 71 00000000005F8B20 00000013F0CA4C6D 000000000001B7CA 0000000040FA5733
72- 75 00000000060F2989 00000007812E3E13 0000000000063797 000000011E3A6AFA
76- 79 0000000000B2557F 00000023091B160E 000000000005C644 00000000B63559A2

COUNTER SET= EXTENDED

COUNTER IDENTIFIERS:
MODEL DEPENDENT INFORMATION NOT AVAILABLE

START TIME: 2010/03/01 16:14:06 START TOD: C59D40379C44268E

END TIME: 2010/03/01 16:16:41 END TOD: C59D40CB3551AAAB
COUNTER VALUES (HEXADECIMAL) FOR CPU 00 (CPU SPEED = 2455 CYCLES/MIC):
128-131 0000000009EA3C93 00000000060172E5 0000000000592F82 00000000041C7A16
132-135 000000000000B0D4 00000000001E1B43 00000000004E23B8 000000000002A288
136-139 000000000096A725 00000000001F46C9 0000000000E71233 0000000002C1FCBF
140-143 000000000151A506 0000000000475EF6 00000000000339DD 0000000000000000
144-147 0000000000000000 00000000454D1FEF 000000025439A8B5 00000000981D8BD6
148-151 0000000000000000 0000000000000000 0000000000000000 0000000000000000

START TIME: 2010/03/01 16:14:06 START TOD: C59D40379C5A930E

END TIME: 2010/03/01 16:16:41 END TOD: C59D40CB3553932B
COUNTER VALUES (HEXADECIMAL) FOR CPU 01 (CPU SPEED = 2455 CYCLES/MIC):
128-131 000000000ABE9264 0000000007A04424 0000000000DAA195 00000000069AE0F4
132-135 000000000003D1DD 00000000004C9BE6 0000000000BAFFD3 0000000000043A8F
136-139 00000000010E0561 000000000067A15E 0000000000FFF2A3 00000000054C2E8C
140-143 0000000002894CF7 00000000007DE480 000000000005BBAA 0000000000000000
144-147 0000000000000000 000000007015060C 00000008427EA97D 00000001C5B9F720
148-151 0000000000000000 0000000000000000 0000000000000000 0000000000000000

COUNTER SET= MT-DIAGNOSTIC

COUNTER IDENTIFIERS:
MODEL DEPENDENT INFORMATION NOT AVAILABLE

START TIME: 2010/03/01 16:14:06 START TOD: C59D40379C44268E

END TIME: 2010/03/01 16:16:41 END TOD: C59D40CB3551AAAB
COUNTER VALUES (HEXADECIMAL) FOR CPU 0000 (CPU SPEED = 2950 CYCLES/MIC):
448- 451 000000000008CFDC 0000000000119FB8 0000000000000015 0000000000000015
452- 455 000000000001720B 000000000003EC8E 0000000000000015 0000000000000015
456- 459 0000000000000015 ---------------- ---------------- ----------------

Note: If programmatically parsing the .CNT file, the format of the output file is loosely structured. For
example, a parser cannot rely on the number of spaces between text to determine the value of a certain
field.
For significant changes, the version number of the .CNT file will be incremented. The first line of the .CNT
file will always be HIS019I EVENT COUNTERS INFORMATION VERSION x, where x is the version
number of the .CNT file. Any change to the version number will be an indication that the structure of the
file has been altered and parsing rules for previous versions may no longer be applicable. An example of a
significant change is the addition of an extra line.

Load module mapping output in a .MAP file

You can request load module mapping output information in your data collection run using any of the
following parameters on the F hisproc,BEGIN command:
• MAPONLY
• MAPASID
• MAPJOB
HIS returns the load module mapping data in a z/OS UNIX System Services output file
(SYSHISyyyymmdd.hhmmss.xxx.MAP) in your HOME directory or the user-specified directory.
This load module mapping data contains information about the virtual address ranges of various modules
loaded on the system. You can request this module address information for one address space, for several
address spaces, or for all active address spaces using the F hisproc,BEGIN MAPASID and MAPJOB
parameters. The .MAP file also provides information about the virtual addresses of Nucleus CSECTs, and
modules loaded into LPA. Modules may also be further divided into CSECTs.

System operations 43
 When a module is directed to a specified storage address (called a directed load), the mapping
information about the module includes the date and time of the directed load. This additional mapping
information about directed loads is provided only when the TRACKDIRLOAD option is in effect either
through the TRACKDIRLOAD statement of the PROGxx member of parmlib or the TRACKDIRLOAD
parameter of the SETPROG system command. A module that is directed into common storage is mapped
only for the address space in which the load occurred. Modules that are directed into 64-bit storage are
not mapped. The size of the storage area used to store mapping information about directed loads is not
configurable. If several directed loads occur in a single address space causing the mapping storage area
to become full, information about earlier directed loads might be discarded and might not appear in
the .MAP file.
The data in a .MAP file is useful for understanding the other information HIS returns in data collection
runs. For example, the HIS Profiler generates .SMP files containing virtual addresses. The module map
allows you to determine how many of these samples are associated with a specific module, which helps
you estimate the relative amount of activity in the module. For example, assume that module A is an LPA
module that starts at X'00CC7000' and ends at X'00CC73FF'. When you look at the sample data
provided by HIS, you may see that 50,000 of the 1,000,000 samples provided by HIS have virtual
addresses between X'00CC7000' and X'00CC73FF'. Based on this, you can estimate that 5 percent of
the CPU time is spent in module A during the time that HIS is capturing data.
The following example shows the important portions of a sample .MAP output file:

I SYS SY1
I SMFIIBM2
I OS z/OS
I FMIDHBB7790
I DATE13007
I TIME13245916
I MAP 02.01
I MODE64-BIT
I LPID00000000
I MACH00002817
B BDY PRIVATE 000000000000000000000000008FFFFF
B BDY CSA 00000000009000000000000000B9CFFF
. . .
CNNUC IECVPRNT0000000000FD60000000000000FD64F7
ENNUC PRTDSE 0000000000FD6006
ENNUC PRTSIO 0000000000FD600C
. . .
MCCOMMIGE0001C0000000000B910000000000000B913EF120040001500000000DZDR21
0CSYS1.LINKLIB
CCCOMMIEC2540A0000000000B910000000000000B913EF
. . .
MPPLPAIGG019KO0000000000BD00200000000000BD040F120040000900000000CLPALST
CPPLPAIGG019KO0000000000BD00200000000000BD02D7
CPPLPAIGG019LA0000000000BD02D80000000000BD0409
. . .
MMMLPAAIRMSRB 00000000059DF00000000000059DF71F120040001800000000DBPXLK10
FUSER.ID.LOADLIB
CMMLPAAIRMSRB 00000000059DF00000000000059DF71F
. . .
AX0002PCAUTH
MX0002IEAVXMAS00000000257000000000000025702047120040001500000000DZDR21
0CSYS1.NUCLEUS
CX0002IEAVXMAS00000000257000000000000025701147
CX0002IEAVXSEM00000000257011480000000025702047
. . .
AX0010RESOLVER
MC0010EZBRESRV0000000024D7B0000000000024E18ECF120040001700570010DZDR21
0ETCPIP.SEZALOADCABC72F11295D766
CC0010EZBRESMT0000000024D7B0000000000024D7B397
. . .
AX0023USERSID5
MX0023*PATHNAM0000000025708000000000002570AFFF120040001C00000000P0017/
gettesttest/gettest001
CX0023CEESTART0000000025708000000000002570807B
CX0023EDCOEXTS00000000257098780000000025709883
CX0023 000000002570808000000000257085A70A0038000Cgettest001#C

See Appendix A, “HIS MAP format,” on page 791 for an example .MAP file.

44 z/OS: MVS System Commands

Sampling function output in a .SMP file
The system generates one .SMP file for each active logical processor. You can choose the sampling
function type that the system performs during a data collection run by specifying the SAMPTYPE
parameter on the F hisproc,BEGIN command. The system can perform two types of sampling
functions:
• Basic sampling
• Diagnostic sampling
See “Starting, configuring, and stopping hardware event data collection” on page 508 for more
information about how to specify the sampling function type on the MODIFY hisproc command.
The HIS Profiler returns sampling data entries in a z/OS UNIX System Services output file
(SYSHISyyyymmdd.hhmmss.xxx.SMP.cpu#) in the HOME directory or the user-specified directory.
The .SMP files are not printable.
If collecting .SMP files, large amounts of space might be needed in the file system containing the .SMP
files. You might need to specify the disk space needed for the file system that the sampling data is written
in when you set up a hardware event data collection. Sampling buffers are 4KB in size. The last 64 bytes
of each buffer are reserved for system use. A basic sample is 32 bytes in length. A diagnostic sample is 64
bytes in length. The required disk space depends on the amount of samples that need to be captured.
For basic sampling, the number of samples that fit in each 4KB buffer is (4096 − 64) / 32 = 126. If only
the basic sampling is requested, the disk space can be calculated by the formula: (Number of basic
samples / 126) × 4K
If diagnostic sampling is requested, basic sampling is also automatically included. Hence a combined
basic and diagnostic sampling takes three times as much disk space as basic sampling alone.
Basic sampling entry
The basic sampling function is the standard part of the CPU-measurement sampling facility and is the
default sampling function type. If the system performs basic sampling function, HIS returns the basic
sampling entry data in a .SMP output file. See the "Basic-Sampling Data Entry" section of The Load-
Program-Parameter and CPU-Measurement Facilities (www.ibm.com/support/docview.wss?
uid=isg26fcd1cc32246f4c8852574ce0044734a) for more information about the format of the entry.
The z/OS dispatcher stores the 8–byte guest program parameter instruction at each dispatch to
identify the currently executing address space or task to the hardware. This program parameter with
the address space or task ID is included in the basic sampling output.
Note: The z/OS system only uses the guest program parameter. The key fields in the guest program
parameter are: Wait (W), SRB mode (S), TCB address, WEB address, and HOME ASN. The Task ID
token and Partial WEB Address fields provide additional information for identifying the dispatched
work units (task or SRB).
If running under a TCB , the data structure of the guest program parameter is shown as follows:

Figure 4. Data structure of a guest program parameter under a TCB

If running under an SRB, the data structure of the guest program parameter is shown as follows:

Figure 5. Data structure of a guest program parameter under an SRB

In the structure of a guest program parameter:

W (1 bit)
Wait is dispatched. The processor is going into a waiting state.

System operations 45
 TCB address (24 bits)
The address of the TCB for which the instruction address is being recorded in the sample entry.
S (1 bit)
SRB mode. If the value of S is one, the work is processed in SRB mode. This bit is always zero
when running in task mode.
Home ASN (15 bits)
The HOME ASID of the task or SRB for which the instruction address is being sampled.
Task ID token (16 bits)
The Task ID token provides additional identify information on the task to differentiate it from other
tasks within the same ASID.
WEB address (32 bits)
WEB address of the SRB for which the instruction address is being recorded in the sample entry.
Partial WEB address (16 bits)
Partial WEB address provides additional identify information on the SRB to better differentiate it
from other SRBs within the same ASID.
Diagnostic sampling entry
The diagnostic sampling function is optional. The diagnostic sampling function provides details of the
internal hardware design. If you want to use the diagnostic sampling function, you must first authorize
to the diagnostic sampling function on the SE console. When diagnostic sampling is requested, basic
sampling is also automatically selected. A basic sampling entry is automatically written ahead of each
diagnostic sampling entry. The HIS Profiler returns both the basic sampling entry data and the
diagnostic sampling entry data in a .SMP output file. The data format of a diagnostic sampling entry
varies on different models. See the "Diagnostic-Sampling Data Entry" section of The Load-Program-
Parameter and CPU-Measurement Facilities (www.ibm.com/support/docview.wss?
uid=isg26fcd1cc32246f4c8852574ce0044734a) for more information about the format of the entry.

HISSERV service overview

The HISSERV service can be used by authorized products to retrieve hardware instrumentation event and
sampling data directly from storage.
Although individual products can query the service for any subset of event types they desire, the sampling
parameters are global to every product that intends to collect sampling data. The global sampling
parameters, or service parameters are set by the most recent MODIFY HIS,BEGIN or MODIFY
HIS,SERVICE command. A profiler chooses how often to collect event type data and how much time is
spent processing sampling data, but the frequency is global for all profiler's collecting sampling data. Any
of these might cause a performance degradation to the system and should be carefully decided.
For details, see the HISSERV service interface in z/OS MVS Programming: Authorized Assembler Services
Reference EDT-IXG, and for information on the MODIFY HIS,BEGIN or MODIFY HIS,SERVICE
commands, see “Starting, configuring, and stopping hardware event data collection” on page 508.

Bypassing HIS to exploit the CPU Measurement Facility

HIS is designed to have exclusive access to the CPU Measurement Facility (CPU/MF). The HISSERV
service interface is provided to allow authorized programs to collect instrumentation data using HIS
functions and should be used by exploiters. There is no need to bypass HIS. See “HISSERV service
overview” on page 46. Other programs which use instructions provided by the CPU/MF must be careful
not to interfere with HIS processing. For example, if a system is running HIS and another program is
executing CPU/MF instructions, HIS may believe the counters are enabled when the other program has
disabled them. Also turning on the sampling facility will cause external interrupts as sampling buffers are
filled, which might not be properly handled due to the illicit enablement. For these reasons, the HISSERV
service interface should be used. If execution of the instructions by the CPU/MF is still desired, the
following guidelines should be used.

46 z/OS: MVS System Commands

 Instructions that may be used:
These instructions are typically query instructions which do not change the state of the system. There will
be no side effects if multiple programs issue these instructions.
• ECA (Extract Coprocessor Group Address)
• ECCTR (Extract CPU Counter)
• EPCTR (Extract Peripheral Counter)
• QCTRI (Query Counter Information)
• QSI (Query Sampling Information)
Instructions that should not be used:
These instructions change the state of the system, executing them will cause side effects to any other
program using the CPU/MF. It is recommended these instructions not be executed.
• SCCTR (Set CPU Counter)
• SCCTL (Set CPU Counter Set Controls)
• SPCTR (Set Peripheral Counter)
• SPCTL (Set Peripheral Counter Controls)
• SSCTL (Set Sampling Controls)

Responding to failing devices

Whenever a device fails, you can use the SWAP command to invoke dynamic device reconfiguration
(DDR), which allows you to move or swap a demountable volume from the device.
Using the SWAP command, you can also turn on or off system-initiated swapping requests. When DDR is
on, the system dynamically performs the swapping function whenever the originally-allocated device
encounters device errors. DDR tells you to mount the volume on another available device. When the
swapping function is turned off, you can invoke operator-initiated DDR by issuing the SWAP command and
specifying the “from” and “to” device numbers. (See the SWAP command in Chapter 4, “MVS system
commands reference,” on page 137.)
When swapping tape devices, the “from” and “to” devices should have the same density whenever
possible. Swapping devices of unlike but compatible densities (for example, 1600 and 1600/6250) can
cause the failure of jobs that are in device allocation at the time of the swap.
On JES3 systems, DDR interfaces with JES3 to ensure that the “to” device has not been assigned to
another job or function. When the swap is complete, DDR notifies JES3.
The following devices are supported by DDR:
• 3400 series tape drives.
• 2501, 2540, 3505, 3525, 1403, and 3211 unit record devices. These devices are not swapped by
system-initiated DDR; you must issue the SWAP command to swap these devices.
The following devices are not supported by DDR:
• Graphic or teleprocessing devices.
• Shared DASD devices, unless the device is swapped to itself.
• DASD devices defined with the READ-ONLY attribute.
• Any device holding a permanently-resident volume, such as a system residence or page data set
volume.

System operations 47
Quiescing the system
Issuing the QUIESCE command causes the system to suspend the processing of all active jobs and to
prevent the starting of any new ones. The system enters the MANUAL state, the MANUAL indicator is on,
and no processing is being done. Quiescing the system does not affect any job step timings (for
accounting purposes). Issue the QUIESCE command from any console with MASTER authority. You can
continue processing by performing the restart function.
Do not issue a SYSTEM RESET after quiescing the system if you intend to issue a RESTART after the
quiesce. Issuing a SYSTEM RESET will cause the system to enter an enabled wait state.

Stopping the system

When all processing (including subsystem processing) has finished, use the HALT command to ensure
that all system statistics and data records in storage are collected for system recording facilities.

Recovery from hardware problems

Recovery is the attempt by the hardware, operating system, operator, automation, or any combination of
these, to correct system malfunctions and return the system to a state in which it can do productive work.
Recovery from some hardware errors is automatic; that is, the hardware recovers without any actions
from the operating system or intervention by the operator or automation. Recovery from other hardware
errors requires overt actions from the operating system, operator, and/or automation. For example, to
keep the system in operation, the operator or the system can configure offline a failing unit, such as a
storage element, a processor, or a channel path. The system continues processing, possibly with some
degradation.
The process of recovery includes the following:
• Hardware to operating system communication and corrective actions
• Operator to operating system communication and recovery actions

Hardware problems
This chapter describes the following categories of hardware malfunctions:
• Central processor (CPU) errors
• Service processor damage
• Storage errors
• Channel subsystem errors
• I/O device errors
For each of these categories, the discussion includes the effect on system operation and the recovery
actions taken, if any. This chapter also presents some additional recovery actions.

Hardware to operating system recovery actions

When CPU errors, service processor damage, storage errors, or channel subsystem errors occur, except
for some I/O errors, the hardware notifies the operating system with a machine check interruption.
Machine check interruptions fall into one of three classes depending on the severity of the error. The
classes are:
• Soft (or repressible) errors: Least severe type. Generally these errors do not affect the operation of the
task currently in control. Soft errors can be disabled (repressed) so that they do not cause a machine
check interruption.
• Hard errors: Malfunctions that affect the processing of the current instruction or make incorrect the
contents of hardware areas, such as registers.

48 z/OS: MVS System Commands

 • Terminating error
• s: Malfunctions that affect the operation of a CPU.
Hard and terminating errors are also referred to as exigent errors.

Information provided with machine checks

When the hardware detects a failure, it stores the following information about the failure:
• The machine check interrupt code (MCIC), which contains:
– Information about the severity of the error
– The time of the error, in relation to the current instruction stream
– An indication of whether the processor has successfully stored additional information about the error
The MCIC is the major interface between the hardware and the operating system, which uses the MCIC
to determine what action to take.
• The save areas that contain the values of the general, floating point, control, and access registers, the
CPU timer, and the clock comparator.
• The machine check old program status word (PSW), which contains the PSW at the time of error.
• The fixed logout area, which is implemented on only some processor complex models.
See the Principles of Operation for the format and content of the MCIC, register and timer save areas,
extended interrupt information, machine check old PSW, and fixed logout area.

CPU errors
CPU errors result from a malfunction of a hardware element, such as a timing facility, instruction-
processing hardware, or microcode. When a CPU error occurs, the recovery processing has, in general,
two stages depending on the severity and type of error:
1. When possible, the hardware retries the failing operation a certain number of times. If the retry works,
the hardware may issue a recovery machine check interruption, which is repressible, so that the
operating system can record the error in the logrec data set. After recording, the operating system
returns control to the interrupted task.
2. If the error is too severe for hardware retry or the retries fail, the hardware issues either a hard or
ending machine check interruption. The system determines the severity of the error and takes the
appropriate action, which may range from ending the interrupted task to ending the entire system.
The next topics describe the following CPU errors:
• Soft CPU errors
• Hard CPU errors
• Ending CPU errors
Then the recovery actions of alternate CPU recovery (ACR) are described.

Soft CPU errors

The CPU errors that can result in a soft machine check are:
• System Recovery (SR): A malfunction has occurred, but the hardware has successfully corrected or
circumvented it.
• Degradation (DG): A continuous degradation of system performance has been detected.
The operating system does not inform the operator about the occurrence of soft machine checks until the
threshold for a given type is reached. The default threshold set for an SR machine check is 50, and for a
DG machine check it is 1. When a threshold for a type of machine check is reached, the system issues
message IGF931E.

System operations 49
 The MODE command allows the operator to change the threshold value for either SR or DG machine
checks, and to specify what processing should be done when the threshold is reached.
• The operator can specify that at the threshold the CPU be disabled for that type of machine check, that
is, be put in quiet mode.
• If the MODE command specifies RECORD=ALL for a particular type of machine check, the system does
not enter quiet mode; it records all instances of the specified type of machine check in the logrec data
set. The operating system issues message IGF931E when the number of machine checks reaches a
multiple of the threshold. For example, if REPORT=3 is specified, message IGF931E appears after the
third, sixth, ninth, twelfth machine checks, and so on.
Numerous IGF931E messages appearing on the console might indicate a performance degradation. In
this case, the installation might want to configure offline the processor that is experiencing the errors.
Hardware support personnel can repair the offline processor.

Hard CPU errors

A hard machine check indicates that the current instruction could not complete. The system records the
error in the logrec data set. Then the system either abnormally ends the interrupted task or retries the
interrupted task at a predefined retry point. Even though the task may be ended, the system usually
continues to run.
The CPU errors that cause hard machine checks are:
• System Damage (SD): A malfunction has caused the processor to lose control over the operation it was
performing to the extent that the cause of the error cannot be determined.
• Instruction Processing Damage (PD): A malfunction has occurred in the processing of an instruction.
• Invalid PSW or Registers (IV): The hardware was unable to store the PSW or registers at the time of
error, as indicated by validity bits in the MCIC. Any error, even a soft machine check, associated with
these validity bits is treated as a hard machine check because the operating system does not have a
valid address to use to resume operation. The error goes through recovery processing.
• Timing Facility Damage: Damage to the following has been detected:
– TOD clock (TC)
– Processor timer (PT)
– Clock comparator (CC)
– External Time Reference (ETR)
The four types of ETR-related machine checks are: primary synchronization damage, ETR attachment
damage, switch to local, and ETR synchronization check.
To overcome the effects of numerous hard machine checks, the MODE command allows the operator to
define machine check thresholds for each type. When reached, the thresholds cause the failing processor
to be configured offline by alternate CPU recovery (ACR). Thus, the operator can control whether, and to
what extent, the system monitors the frequency of hard machine checks, and can define a separate
threshold and time interval for each.
The default threshold value for most hard machine checks is 5. The default for PD machine checks is 16.
The default for ETR machine checks is 5 in 300 seconds.

Terminating errors on CPUs

A terminating machine check occurs when the operating system or the hardware considers a failure
severe enough that a processor cannot continue operation.
In a uniprocessor (UP), the operating system enters a disabled non-restartable wait state, such as X'A01'
or X'A26', and issues the following message:

IGF910W UNRECOVERABLE MACHINE FAILURE, RE-IPL SYSTEM

In a multiprocessor (MP), the action taken is as follows:

50 z/OS: MVS System Commands

• If the hardware determines that a processor cannot continue operation, it places the processor in a
check-stop state and attempts to signal the other processor(s) by issuing a malfunction alert (MFA)
external interruption. The hardware issues an MFA when:
– It cannot store the machine check logout data about the error.
– It cannot load the machine check new PSW.
– It is disabled for hard machine checks when a hard error is detected.
• If the operating system determines that a processor cannot continue operation, it attempts to signal the
other processor(s) by issuing a Signal Processor (SIGP) instruction to cause an emergency-signal (EMS)
external interruption. The operating system issues an SIGP instruction when:
– The system is processing one machine check when another machine check occurs that cannot be
handled.
– A hard-machine-check threshold, which is an installation option established by entering the MODE
command, has been reached.
– Channel subsystem damage is detected.
– The content of the MCIC is incorrect.
When a processor receives either an MFA or EMS external interruption for these conditions, the system
receives control. The system, in turn, invokes ACR processing, which takes the malfunctioning processor
offline and initiates recovery processing for that processor.
In a multiprocessor environment, an MFA or EMS is received by all the other online processors. On the
first processor to receive the signal, the system tests and sets a flag before starting to process the error.
When the other processors receive the interruption, the system sees that the error is already being
processed and returns to the interrupted task.

Terminating errors on multiprocessors

In a multiprocessor, failure of some hardware elements may cause a terminating error on more than one
CPU. It is possible that a terminating error may occur on a CPU while alternate CPU recovery (ACR) is still
processing a terminating error on another CPU. In either case, the system puts the system into non-
restartable wait state X'050'.

Alternate CPU recovery (ACR)

ACR is a function that is initiated on an operative CPU when that CPU receives a signal that another CPU
has had an ending error. ACR has two major functions:
• To configure offline the malfunctioning CPU
• To initiate the release of system resources held on the malfunctioning CPU
If the failing CPU has an Integrated Cryptographic Feature (ICRF), the ICRF is also taken offline.
ACR initiates the release of any resources held on the failing CPU by causing control to pass to the
recovery routines for the work on the failing CPU. ACR allows the operating system to continue its normal
operation on the remaining CPU(s), although the task that was interrupted by the error on the failing CPU
might be ended.
When ACR is complete, it issues message IEA858E stating that ACR is complete and identifying the CPU
that was configured offline. At this point, the operator can try to configure the failing CPU back online
using a CONFIG CPU(x),ONLINE command. The configuration online might, or might not, be successful
depending on the error that caused the CPU to be configured offline.
Some hardware malfunctions might cause a subsequent CONFIG CPU(x),ONLINE command to that CPU to
fail, or might cause the problem to recur when the CPU is brought back online. In these cases, hardware
support personnel need to service the CPU before it can be successfully brought back into the system.
However, if a CPU was configured offline because a threshold was reached or because of an operating
system problem, a subsequent request to configure the CPU back online might work.

System operations 51
Service processor damage
Permanent failure
When the system detects that the service processor is permanently, completely failing, the system
receives a service processor damage machine check. The system also notifies subsystems about the
damage.
For a permanent failure, the system issues the following message:

ISN000E THE PROCESSOR CONTROLLER HAS FAILED. SOME CRITICAL SYSTEM

FUNCTIONS HAVE BEEN DISABLED. AN ORDERLY SHUTDOWN OF THE
ENTIRE SYSTEM SHOULD IMMEDIATELY BE ATTEMPTED IN ORDER TO
MINIMIZE THE IMPACT OF THIS FAILURE

After this message, the operator can optionally perform an orderly shutdown of the system. Processing
can continue, but when a function of the service processor is required, the system may become
inoperative. To recover, the operator then performs an initial microprogram load (IML).

Temporary failure
If a service processor fails temporarily or partially and is in I/O Support Processor (IOSP) concurrent
maintenance mode, the system continues operating but cannot perform certain functions.
For a temporary failure, a message with the prefix ARRP is issued to the operator.
In IOSP concurrent maintenance mode, certain functions of the operating system will not work or will
work incompletely.

Storage errors
The hardware detects and corrects storage errors where possible. The system is informed of the error by a
machine check interrupt. The system invokes recovery routines.
If the storage error is detected during an I/O operation, however, the operation is ended with either a
channel data check or a channel control check, depending on whether the error was encountered during
data transfer or fetching of the channel control word (CCW) and indirect data address word (IDAW). No
machine check interrupt is generated in this case. Error recovery procedures (ERPs) recover from this type
of error.

Soft storage errors

The soft storage errors are system recovery (SR) errors with the storage error corrected flag set in the
MCIC to indicate that the storage controller was able to repair the error.
When a storage error corrected (SC) condition occurs, along with storage degradation (DS), the system
attempts to stop using the affected frame. This action eliminates performance degradation that would
result from hardware correction of later occurrences of the same error. It also minimizes the chance that
the same problem will later occur as a storage error uncorrected.
If the frame contains pageable data, the system moves that data to another frame, and the original frame
is marked offline. If the data in the frame cannot be moved, the frame is marked pending offline, and is
subsequently taken offline if the frame is released or if its contents are made pageable. Note that, before
the system takes a frame offline, it tests the frame; if it has no errors, the frame is returned to available
status.
The threshold for SR machine checks affects the ability of the system to deal with storage error corrected
conditions. The default threshold is 50 SR machine checks. The operator can change the SR threshold
with the MODE operator command. When the threshold is reached, the system disables SR machine
checks. This action prevents a subsequent storage error corrected from being presented. The system
then does not take any action to remove the affected frame.

Hard storage errors

This section deals with these types of hard storage errors:

52 z/OS: MVS System Commands

 • Storage error uncorrected: Indicates that the hardware could not repair a storage error.
• Key in storage error uncorrected: Indicates that the hardware could not repair a storage key that was
in error.
When a hard storage error occurs, the operating system attempts recovery. For a storage key problem in a
frame containing a virtual page, the operating system tries to reset the key. If the reset fails and the page
is not fixed, the operating system moves the page to a new fame, setting the key in the new frame as
required.
If recovery cannot repair the error, the operating system either takes the storage frame offline or marks it
pending offline. Pending offline means that the operating system will take the frame offline when the
frame becomes free.
A storage error uncorrected condition represents the potential loss of critical data. When this condition
occurs with a PD machine check, the system in most cases ends the affected unit of work. If the recovery
routines complete successfully so that the affected storage frame is freed, the frame is marked offline and
system processing continues. The recovery processing, however, could try to refer to the storage that
originally caused the machine check, thus causing further errors. Such action could result in the PD
threshold for machine checks being reached, thus taking a CPU offline.
The default threshold for PD machine checks is 16 in 5 minutes. The operator can change this threshold
by means of the MODE operator command.

Effects of storage errors

Errors in critical areas of storage may cause the hardware system or the operating system to become
inoperative. Those areas of storage and the effect of an error are as follows:
• Hardware storage area (HSA): An uncorrectable storage error in the HSA causes the system to enter a
check-stop state. The system can be recovered by two actions:
1. Power-on reset (POR) or a SYSIML CLEAR service language command
2. IPL
• Nucleus: A storage error in nucleus pages requires an IPL for recovery. If the IPL fails, recovery requires
either a power-on reset or a SYSIML CLEAR, followed by an IPL.
• Link pack area (LPA), system queue area (SQA), and local SQA (LSQA): A storage error in SQA could
have the same effects as a nucleus storage error.
For a storage error in LPA, the operating system handles recovery. Normally, only the associated job is
ended with the remainder of the system unaffected.

High speed buffer (Cache)

A processor cache error can result in the loss of the processor and possibly the system. The storage frame
corresponding to any changed data in the cache is marked with an uncorrectable storage error. Because
the cache might contain critical system data, recovery might require an IPL.

Channel subsystem errors

If the channel subsystem fails, the hardware generates a channel subsystem damage machine check
interrupt. The resultant processing enters the entire system into non-restartable wait state X'A19' and
issues message IOS019W.

Channel report words (CRWs)

When the channel subsystem detects an error, it does the following:
• Builds a CRW that describes the error
• Queues the CRW for retrieval by the operating system
• Generates a machine check interrupt with the CRW pending indicator set in the machine check
interrupt code (MCIC)

System operations 53
 The operating system records the CRW in a logrec data set error record. The CRW contains a code that
indicates the source of the error: the channel path, the subchannel, channel configuration alert, or the
monitoring facility.
See Principles of Operation for additional information on CRWs.

Channel path recovery

If the CRW indicates that a channel path caused the machine check, the system attempts to recover the
channel path or route I/O down an alternate channel path. If multiple CRWs indicate errors on different
channel paths, a failure in the hardware elements common to those channel paths may be indicated.
The channel path conditions fall into two categories:
• Expected: An expected channel path condition occurs as a result of a previous recovery action taken for
an unexpected channel path error, and indicates the result of the action.
• Unexpected: An unexpected channel path error occurs with no warning.
The channel path conditions indicated in a CRW are:
• A terminating error condition on the channel path.
• A permanent error on the channel path; a system reset to the channel path has not been done.
• A permanent error on the channel path; a system reset to the channel path has been done.
• An initialized condition on a channel path, that is, an error recovered by the channel subsystem; a
system reset to the channel path has been done.

Terminating error
A terminating error condition is unexpected only; it is never the result of a previous recovery action. A
terminating error condition indicates that the channel path is not permanently lost, but cannot be used
until the error condition is reset. In this case, the system attempts to reset the channel path. The CRW
that results from this reset is an expected CRW, and it will indicate whether the reset corrected the
problem in the channel path.
For a failing channel path that has a device with an outstanding reserve, the system handles the condition
in three different ways, depending on whether the device supports dynamic pathing, supports
unconditional reserve, or does not support unconditional reserve. The system actions are:
• For a dynamic pathing device with multiple paths, no action is taken until the expected CRW is received.
• For a non-dynamic pathing device that supports unconditional reserve, such as a 3350 Direct Access
Storage, the system issues an unconditional reserve command to the device to move the reserve to an
alternate path.
• For a non-dynamic pathing device that does not support unconditional reserve, such as a 3330 Disk
Storage, or for a reserved/assigned device with only one path, the system issues message IOS063E (or
IOS062E) to request that the operator stop I/O to the shared devices (see Figure 6 on page 55 and the
accompanying description). The system then tries to recover the channel path.
Note: Since stopping I/O to shared devices may require a certain level of multi-system disruption and
coordination, users may wish to avoid this processing. Through the use of the TERMINAL
BOX_LP(device_class1,...device_classN) statement in the IECIOSxx Parmlib member, users can cause
devices in the specified device class to be BOXED rather than having to undergo multi-system disruption
to recover the channel path to the device. For more information on the use of the TERMINAL statement in
IEAIOSxx, see z/OS MVS Initialization and Tuning Reference.

54 z/OS: MVS System Commands

Figure 6. DASD Devices shared between two systems

Figure 6 on page 55 shows two DASD devices that are shared between two systems. When system 1
encounters a channel path error on channel path 01, indicated by message IOS063E (or IOS62E), the
operator should stop I/O to the shared devices from system 2 to maintain data integrity during recovery of
the channel path.

Recovery actions for a channel path error with shared DASD or assignable devices

1. Identify which devices on channel path 01 on system 1 are shared with system 2.
2. Enter the IOACTION STOP command on system 2 to stop I/O on the shared devices. The device
numbers may not be the same on both systems.
3. Restart system 1.
4. Wait for the system to issue message IOS204E (or IOS201E), indicating that channel path recovery is
complete.
5. Enter the IOACTION RESUME command on system 2 to allow I/O to resume to the shared devices.

Note:
1. Do not leave devices in the stopped state any longer than necessary to perform recovery. A shortage of
SQA storage can result from stopping I/O for extended periods.
2. Before stopping a device, enter the D U,DASD,ALLOC,xxx command to determine which system
resource's I/O will be affected. If any system oriented I/O will be stopped, the system could appear
frozen. This situation will last until I/O resumes to the device.

Permanent error condition

A permanent error condition, whether expected following a Reset to a channel path in an ending condition
or unexpected, results in the system taking that channel path offline. Any active I/O requests are retried

System operations 55
 on alternate paths if available. If the failing channel path was the last path to any devices, those devices
are boxed. Boxing means:
• The operating system ends I/O to the device.
• Any new I/O request for the device causes a permanent I/O error.
• The operating system does not allocate the device.
• If the device was online, the operating system marks it pending offline. A pending offline device goes
offline when the following occur, in this order:
1. The device becomes no longer allocated to any job.
2. The operating system allocates any device.
If the device was offline, it remains offline.

Initialized condition
An initialized condition means that a previous recovery action has successfully recovered the channel
path and the channel path is available for use. This condition can be expected only. The initialized
condition indicates that the channel subsystem has been successful in recovering the channel path to a
state where it is again usable.
For devices that support the Dynamic Path Selection (DPS) feature, such as the 3380 Direct Access
Storage and 3480 Magnetic Tape Subsystem, DPS validation is called to restore dynamic pathing arrays
for each DPS device attached to that channel path. For each non-dynamic pathing device that does not
support unconditional reserve and that had an outstanding reserve on the failing channel path, a reserve
command is issued to the device. Any previously active I/O requests are restarted.

Channel path alert conditions

The operating system communicates with the operator when two other indicators are set in a CRW:
channel path temporary and configuration alert temporary. In either case, the operating system
performs no recovery processing.
• Channel path temporary: The operating system issues message IOS162A to inform the operator that
the channel subsystem could not identify the device requesting service.
• Configuration alert temporary: The operating system issues message IOS163A to inform the operator
that the channel subsystem could not associate a valid subchannel with the device requesting service.

Subchannel recovery
If the CRW indicates that a subchannel caused the machine check, the operating system examines the
error recovery code in the CRW. If the CRW indicates that the subchannel is available, the channel
subsystem has recovered from a previous malfunction. I/O functions in progress and presentation of
status by the device have not been affected. No program action is required.
If the CRW indicates that the subchannel is installed parameter initialized, the operating system
determines if the device associated with the subchannel is still valid. If it is, the operating system enables
the subchannel again. If, however, the device related to the subchannel is not valid, the operating system
marks the device as unusable and issues message IOS151I.

Monitoring facility recovery

For a channel monitoring error, the operating system schedules a recovery routine.

I/O device errors

An error can occur in an I/O device. The following topics are covered:
• “I/O errors” on page 57
• “Missing interrupts” on page 57
• “Hot I/O” on page 58

56 z/OS: MVS System Commands

• “Recovery for hung devices” on page 59
• “Recovery for failing devices” on page 60
• “Shared device recovery” on page 62
• “DASD maintenance and recovery” on page 64
• “Recovery for a failing alias unit control block (UCB)” on page 29

I/O errors
Errors that are related to an I/O request are usually indicated in the status data provided with the I/O
interrupt. These errors are:
• Device not operational on any path
• Device status errors, such as a unit check
• Subchannel status errors: interface control check, channel control check, and channel data check
The operating system processing of the interrupt may include:
• Invoking a driver exit
• Interfacing with attention routines and volume verification processing
• Invoking a device-dependent ERP for error recovery
• Processing an unconditional reserve
• Redriving the I/O request on a channel path other than the one that generated the interrupt
• Requesting an operator action by message IOS115A or by restartable wait state X'115'
• Issuing message IOS050I to inform the operator that a subchannel status error occurred

Missing interrupts
At predefined intervals, the operating system checks devices of a specific type to determine if expected
I/O interrupts have occurred. If an expected interrupt has not occurred across two of these checks, that
interrupt is considered missing. The operating system then issues message IOS071I or IOS076E, writes a
logrec data set error record, and tries to correct the problem. For recurring missing interrupts, the
operating system issues message IOS075E together with message IOS076E or IOS077E to indicate the
recurring condition on a particular device.
A feature of the IBM 3990-6 and 9340 attached devices allows MVS/ESA to automatically identify a
system in a multisystem environment that is holding a reserve. After every start pending MIH condition,
the system attempts to determine whether the device is not responding because of a reserve to another
system. If the device is reserved to another system, message IOS431I is issued to identify the system by
its central processor serial number. If the system holding the reserve is a member of the same sysplex as
the system detecting the MIH condition, message IOS431I includes the system name and the LPAR ID, if
there is one.
For JES2 systems, when the reserve is held by a system in the same sysplex, the system attempts to
obtain information about the job causing the reserve by routing a D GRS,DEV=devnum command to that
system. JES2 systems which have JES3 installed must have JES2 started with the NOJES3 option
(CON=(xx,NOJES3) in order to identify the job holding the reserve. Message ISG020I identifies the jobs
holding the reserve on the failing system. The installation can use this information to determine what to
do.
Some causes of missing interrupts are:
• An idle unit control block (UCB) with I/O requests queued to it
• An outstanding I/O operation that should have completed
• An outstanding mount for a tape or disk
The intervals used by the operating system to determine whether an expected interrupt is missing varies
from 15 seconds for DASD to 12 minutes for 3330 Disk Storage. An installation can define in the IECIOSxx

System operations 57
 parmlib member the time intervals for all devices in the I/O configuration. These intervals override the
IBM-supplied defaults.
Note:
1. During IOS recovery processing, the system will override your time interval specification and may issue
MIH messages and MIH logrec error records at this IOS determined interval.
2. During IPL (if the device is defined to be ONLINE) or during the VARY ONLINE process, some devices
may present their own MIH timeout values, via the primary/secondary MIH timing enhancement,
contained in the self-describing data for the device. The primary MIH timeout value is used fo rmost
I/O commands; however, the secondary MIH timeout value may be used for special operations such as
long-busy conditions forlong running I/O operations. Any time a user specifically sets a device or
device class to have an MIH timeout value that is different from the IBM-supplied default for the
device class, the value will override the device-established primary MIH time value. This implies that if
an MIH time value that is equal to the MIH default for the defice class is explicitly requested, IOS will
not override the device-established primary MIH time value. To override the device-established
primary MIH time value, you must explicitly set a time value that is not equal to the MIH default for the
device class.
Note that overriding the device-supplied primary MIH timeout value may adversely affect MIH
recovery processing for the device or device class.
Please refer to the specific device's reference documentation to determine if the device supports self-
describing MIH time values.
Note: If there are missing interrupts on the devices that contain the system residence (SYSRES) or the
page volumes, the operator may not receive any message, because the needed operating system routines
are pageable. The operator can learn about the missing interrupts by initiating restart reason 1.
See z/OS MVS Initialization and Tuning Reference for the IECIOSxx member.

Hot I/O
A hot I/O condition occurs when a device, control unit, or channel path causes continuous unsolicited I/O
interrupts. The operating system attempts to recover from a hot I/O condition so that a reIPL is not
required. For diagnostic purposes, the operating system indicates all hot I/O incidents in logrec data set
error records.
The operating system first tries recovery at the device level by issuing the Clear Subchannel (CSCH)
instruction in an attempt to clear the hot I/O condition. If the condition is cleared, processing continues
normally. If the condition persists, the next recovery action is determined by one of the following:
• The parameters the installation defined in the IECIOSxx parmlib member for hot I/O recovery
• Operator response to the appropriate hot I/O message or restartable wait state for the class of device:
– Message IOS117A, (IOS110D, or wait state X'110') for non-DASD, non-dynamic pathing device
– Message IOS118A, (IOS111D, or wait state X'111') for DASD or dynamic pathing device that is not
reserved
– Message IOS119A, (IOS112D, or wait state X'112') for DASD or dynamic pathing device that is
reserved
Because IPLs related to hot I/O are generally caused by incorrect operator actions, an installation should
use the IECIOSxx parmlib member to make hot I/O recovery more automatic and reduce the need for
immediate operator intervention. The following example parameters, when defined in the IECIOSxx
parmlib member, tell the operating system how to handle automatic recovery from hot I/O.
Reference information: See z/OS MVS Initialization and Tuning Reference for the IECIOSxx parmlib
member.

58 z/OS: MVS System Commands

Example IECIOSxx parameters for hot I/O recovery
The following examples show how to specify the hot I/O recovery parameters in the IECIOSxx parmlib
member. The values shown are also the IBM default values.

HOTIO DVTHRSH=100

• Specifies 100 repeated interrupts as the threshold for the operating system recognizing the condition.

HOTIO DFLT110=(BOX,)

• For a non-DASD, non-dynamic pathing device. Box the device on the first occurrence of this condition.
On recursion, prompt the operator.

HOTIO DFLT111=(CHPK,BOX)

• For a DASD or dynamic pathing device that is not reserved. Attempt channel path recovery for the
device on first occurrence of this condition. On recursion, box the device.

HOTIO DFLT112=(CHPK,OPER)

• For a DASD or dynamic pathing device that is reserved. Attempt channel path recovery for the device on
first occurrence of this condition. On recursion, prompt the operator.

Hot I/O recommendations

Although it does require more operator intervention, additional experience has shown that a higher level
of availability can be achieved by specifying hot I/O recovery options (CHPK,OPER) for all three classes of
devices: DFLT110, DFLT111, and DFLT112. These options will allow the possibility of automatic recovery
before the system requests operator involvement.
Operator involvement might require that the message be issued using the Disabled Console
Communication Facility (DCCF). This will occur when a DASD device is attached on the channel path that
is undergoing Hot I/O recovery. Unless the installation is prepared to deal with messages issued in DCCF
mode, IBM recommends that operator involvement not be requested by the Hot I/O actions.
For non-DASD devices (DFLT110), CHPK,OPER would allow one automated recovery attempt and then
request direction from the operator, depending on how critical the device is. If the device is non-critical to
the operation of the system, such as a printer, the operator could then reply BOX. If the device is critical,
such as a 3705 Communication Controller, and is properly equipped with multiple paths, such as through
a type three channel adapter on the 3705, the operator could reply CHPF. Note that the operator should
ensure that all critical devices on the same channel path (CHP) have multiple paths before replying CHPF.
You can choose recovery options other than the defaults or the general recommendations, because of
considerations unique to the installation. For example, if all DASDs are configured with multiple paths,
each through a different CHP, you might consider specifying CHPK,CHPF for both DFLT111 and DFLT112.
This will allow one attempt to recover without loss of resources, then an attempt to recover by removing
the CHP attached to the failing device or control unit, but without losing a critical device. If the installation
contains DASD devices with only one path, the considerations are the same as for non-DASD.
Note: Since CHPK processing may require a certain level of multi-system disruption and coordination (to
stop sharing processors), the CHPK option may not be suitable for all device classes in a particular Hot I/O
device grouping. For instance, CHPK processing may be suitable for reserved DASD devices, but may not
be suitable for assigned single-path tape devices. CHPK can be avoided on a device class basis by using
the HOTIO BOX_LP(device_class1,...device_classN) parameter in the IECIOSxx parmlib member. Using
the BOX_LP parameter forces a device to be BOXED for Hot I/O conditions that cause CHPK processing to
occur.

Recovery for hung devices

When a device appears to be hung, an operator can consider varying the device offline to try releasing the
hang condition at the device. However, the VARY OFFLINE command may obtain resources critical to the

System operations 59
 system and may attempt to issue I/O. Depending on the condition that caused the device to hang in the
first place, this may cause the VARY OFFLINE command to also hang.
To avoid this problem, the operator can choose to use the VARY OFFLINE command with the FORCE
parameter to mark the device offline and boxed. The FORCE parameter will not obtain resources or issue
I/O, so it will complete regardless of any hardware problems with the device. Since the device is boxed, all
I/O will be posted back to the I/O issuer in permanent error, which should cause all system resources
previously held to be released.
See “Boxed device - operator actions” on page 29 for more information on boxing devices. See “VARY
command” on page 751 for more information on the FORCE option.

Recovery for failing devices

When a device fails, operators can enter the SWAP command to perform dynamic device reconfiguration
(DDR). DDR allows the operator to move or swap a demountable volume from a device. When DDR is
active, the system dynamically requests the swapping whenever a device encounters device errors. DDR
tells the operator to mount the volume on another available device.
Operators can invoke DDR by issuing the SWAP command and specifying the from and to device numbers.
See “SWAP command” on page 747 for more details.
When swapping tape devices, the from and to devices should have the same density, whenever possible.
Swapping devices of unlike but compatible densities can fail the jobs in device allocation at the time of
the swap.
On JES3 systems, DDR checks with JES3 to ensure that the to device has not been assigned to another
job or function. When the swap is complete, DDR notifies JES3.
When a data check occurs in an IBM 3495 Tape Library Dataserver, the system cleans the tape device and
retries the failing operation. If the error persists, the system initiates a swap to another eligible system-
managed tape library device without involving the operator. The system will try to swap to up to five other
devices. If these efforts fail, it issues an error message to the operator and fails the job.
The following devices are supported by DDR:
• 3400 series Magnetic Tape Units.
• Unit record devices. These devices are not swapped by system-initiated DDR; the operator must enter
the SWAP command to swap these devices.
– 1403 Printer
– 2501 Card Reader
– 2540
– 3211 Printer
– 3505 Card Reader
– 3525 Card Punch
• Direct access devices. When using a 3348 Model 70F Data Module, operators must ensure that the to
3340 has the fixed-head feature installed. When swapping a 3340/3344 with the fixed-head feature, be
sure that the to device also has the fixed-head feature installed.
– 3330 Disk Storage
– 3333 Disk Storage and Control
– 3340 Direct Access Storage
– 3344 Direct Access Storage
The following devices are not supported by DDR:
• 3344 and 3350 Direct Access Storage with fixed-head are not supported by system-requested DDR.
• 3375 Direct Access Storage.
• 3380 Direct Access Storage.

60 z/OS: MVS System Commands

• Shared DASD devices, unless the device is swapped to itself.
• Any device holding a permanently-resident volume, such as a system residence or page data set
volume.
• Graphic or teleprocessing devices.

Recovery for channel path errors

When you define your I/O configuration, many devices share common hardware components (such as
channels, channel cards, switches, control unit ports, control unit adapter cards, and fiber-optic links). For
example, all devices for a specific control unit definition share the same hardware components since they
share the same channels and control unit ports. Therefore, when a hardware-related error occurs on a
channel path, multiple devices are affected.
When an error occurs on a channel path, the system performs path recovery which consists of issuing one
or more recovery-related I/Os to test the channel path to see if it is still usable. If path recovery
determines that the channel path is no longer usable, the path is removed (varied offline) from the
affected device. Otherwise, the channel path remains online to the device.
Path recovery is typically performed one device at a time. This means that when an error occurs on one
device, only that device is processed. Errors on other devices are processed independently, even if they
share common hardware components. This may affect application performance since the application is
delayed while the system performs path recovery and then retries the original I/O request. If the
application uses multiple devices that share a failing or malfunctioning hardware component, additional
errors are encountered and further delays occur.
Additionally, certain types of path errors can be intermittent. That is, an error occurs, but path recovery is
successful, so the path is not removed from the device. This also affects performance because
applications may encounter errors multiple times. If this occurs, you may need to manually remove the
bad path or paths from the affected devices to stop the errors from occurring.
The PATH_SCOPE option on the RECOVERY statement in the IECIOSxx parmlib member and the SETIOS
RECOVERY command, along with the PATH_THRESHOLD and PATH_INTERVAL options, allows you to
reduce the elapsed time it takes for the system to recover from channel path-related errors, and helps
prevent system performance problems that can occur when a significant amount of time is spent in
repetitive channel path error recovery. For more information on the syntax of the RECOVERY statement in
IECIOSxx, see z/OS MVS Initialization and Tuning Reference. For more information on the syntax of the
SETIOS RECOVERY command, see “SETIOS command” on page 607.
Specify a PATH_SCOPE of either CU or DEVICE to enable path recovery either for all devices attached to
the control unit (CU) or on a device-by-device basis (DEVICE). The default is PATH_SCOPE=DEVICE.
If PATH_SCOPE=DEVICE is specified, then path recovery is on a device-by-device basis and no monitoring
of intermittent errors is performed. The PATH_INTERVAL and PATH_THRESHOLD keywords may not be
specified with PATH_SCOPE=DEVICE.
If PATH_SCOPE=CU is specified and path recovery determines that a channel path needs to be removed
from a device, the path is removed from all devices defined to the control unit. Additionally, for
intermittent channel path errors, the system collects error statistics over a period of time, and if the
number of errors reaches or exceeds a threshold value, the channel path is removed from all devices
defined to the control unit. The time period and threshold are controlled by the PATH_INTERVAL and
PATH_THRESHOLD parameters as follows:
• PATH_INTERVAL specifies the length of time to monitor for errors (for example, 10 minutes).
• PATH_THRESHOLD specifies the minimum number of path-related errors that must occur every minute
for the specified period of time (PATH_INTERVAL) before the path from the failing hardware component
is removed from all the affected devices.
For example, specifying a PATH_INTERVAL of 10 (minutes) and a PATH_THRESHOLD of 20 (errors per
minute) means that at least 20 errors must occur every minute for 10 consecutive minutes before the
path from the failing hardware component is removed from all the affected devices.

System operations 61
 Note: Do not set the PATH_INTERVAL and PATH_THRESHOLD values to a very low value (for example,
setting the PATH_INTERVAL to 1 minute or setting the PATH_THRESHOLD to 1 error) because this may
interfere with normal system recovery and cause the system to remove channel paths unnecessarily.
When a channel path becomes not operational, the system takes the path offline to the affected devices.
Later, when the path becomes operational, the channel subsystem notifies the system so that it can bring
the path back online. If there are I/Os that are active when the channel path becomes not operational,
these I/Os are terminated with an interface control check. If PATH_SCOPE=CU is specified, these
interface control checks are counted towards the PATH_THRESHOLD value and may cause the system to
internally remove the path from all devices on the control unit if the PATH_THRESHOLD and
PATH_INTERVAL values are too small. Later, when the channel subsystem notifies the system that the
channel path is now available, the system does not automatically bring the channel path online; the
channel path must be brought online manually.
When PATH_SCOPE=CU is specified and the system internally varies the path offline to all devices on a
control unit, the system does not remove the last path to a device if the device is online, allocated,
reserved, or in use by a system component. However, if the path becomes not operational because of a
link threshold condition, then the last path is taken offline. A link threshold condition, also known as a
flapping links condition, occurs when a channel path transitions between not operational and operational
multiple times within a short period of time. This is usually a sign of some type of hardware problem.
These transitions cause the system to perform path-related recovery, which delays applications until the
recovery completes. If the channel path transitions too many times within a short period of time, the
channel subsystem keeps the channel path offline to prevent further path recovery.
When PATH_SCOPE=CU is specified, channel paths that are internally varied offline by the system are not
varied back online automatically. You must use one of the following commands to bring the path back
online after ensuring that the problem that caused the path errors has been resolved:
• VARY CU to vary the path online to all devices for a particular control unit.
• VARY PATH to vary the path online to one or more individual or ranges of devices.
• CONFIG CHP to configure the CHPID online (if it is offline) and to vary the path online to all devices
using that CHPID.
Note: You should bring the path online to a single device first and then wait a short period of time
(minutes) to allow I/Os to be issued to the device before bringing the path online to the remaining
devices. This ensures that the problem has been resolved and no further errors will occur.

Shared device recovery

When a system, for example system A, is sharing devices with other systems, events on any one system
can affect the ability of any or all the systems to access the shared devices. For example, if one of the
sharing systems has an allegiance to a shared device, an I/O operation from system A to that device will
receive a device busy condition. In this case, the I/O operation is held in system A's channel subsystem
until the other system ends its allegiance. At that time, system A's I/O to that device can then be
processed normally.
However, a problem either on the system that has the allegiance or in the I/O hardware could result in the
allegiance not being freed. This could prevent the processing of any pending I/O operations from any of
the sharing systems to the device(s) affected by the allegiance. The indication to any sharing systems that
had an I/O operation hung by such a condition would normally be message IOS071I, indicating a start
pending to the device.
There are a number of other conditions that can cause message IOS071I for a shared device:
• Poor performance of programs using the device
• Contention for the device
• Long reserves
• Application errors
• Operator errors

62 z/OS: MVS System Commands

Operator actions
If message IOS071I occurs for a shared device, the operator should check the operating condition of the
sharing systems. If any system is not operational, it could be the cause of the start-pending because the
system could still hold an allegiance that it had when it became non-operational. Operator action depends
on the condition of the non-operational system:
• If the system is in the check-stop state or in a non-restartable wait state, the operator should
immediately initiate an interface reset to that device from the system console of the non-operational
system. If the interface reset fails to release the device, the operator should issue a system reset from
the system console of the non-operational system.
These actions should be taken before trying to recover the non-operational system, to allow the other
operational systems that are sharing I/O with the non-operational system to continue with as little
disruption as possible.
• If the system is in the stopped state, the operator should try to determine why it is stopped and, if
appropriate, start it again.
• If the system issued message IOS431I, take the actions described in the operator response for that
message.

Unconditional reserve/alternate path recovery

Alternate path recovery permits recovery from control unit or channel-path failures that cause a DASD or
string of DASDs to be no longer accessible to the system. Alternate path recovery is performed only after
the operating system guarantees ownership of the device by ensuring that the device is reserved to this
system.
When the operating system can guarantee ownership of the device, alternate path recovery is performed.
This consists of issuing an unconditional reserve (UR) CCW on a non-failing, online path to the device. If
the UR CCW is successful, the operating system issues message IOS428I. If the UR CCW fails or if there
are no alternate paths to the device, the operating system issues message IOS429I and boxes the device.
If ownership of the device cannot be established, the operating system issues message IOS427A to
determine which recovery action is to be performed.
To maintain volume data integrity during a shared DASD recovery process, the operator must stop I/O
from the sharing systems until the recovery process is complete.
The operator should use the IOACTION STOP command to stop I/O to the device with less disruption to
system processing than cancelling jobs or stopping processors.
See Figure 7 on page 64 for an illustration of three systems sharing a device. Use the following recovery
scenario when system 1 issues message IOS427A, indicating a device failure.
1. Determine the device number on each sharing system.
2. To stop I/O requests for the device, enter IOACTION STOP,DEV=devnum on system 2 and system 3.
If the IOACTION STOP command fails because the device is reserved or reserve pending, and
repeated attempts to stop the I/O using the command continue to fail, then end the reserving task or
stop the system.
3. Reply UR to message IOS427A and wait for recovery completion messages on system 1.
4. After the recovery completion messages, enter IOACTION RESUME,DEV=devnum or IOACTION
RESUME,ALL on system 2 and system 3 to return I/O processing to normal.
Note:
1. Do not leave devices in the stopped state any longer than necessary to perform recovery. A shortage of
SQA storage can result from stopping I/O for extended periods.
2. Before stopping a device, enter the D U,DASD,ALLOC,devnum command to determine which system
resource's I/O will be affected. If any system oriented I/O will be stopped, the system could appear
frozen. This situation will last until I/O resumes to the device.

System operations 63
 Figure 7. DASD device shared by three systems

DASD maintenance and recovery

DASD can experience failures such as defective disk surfaces, drives, and actuators. When these failures
occur, data becomes inaccessible to the operating system and could be lost. To prevent the loss of the
data, an installation should consider using the following to monitor possible error conditions and correct
any before they cause outages.
• The Environmental Record Editing and Printing (EREP) System Exception Report
• Device Support Facilities (ICKDSF)
When a DASD error does occur, such as a defective track, an installation can use z/OS DFSMSdss to
retrieve the data from the defective areas and copy it to a backup DASD.
See the following:
• IBM Disk Storage Management Guide: Error Handling
• Device Support Facilities (ICKDSF) User's Guide and Reference
• EREP User's Guide
• z/OS DFSMSdss Storage Administration

Diagnosing problems in a switched fabric

Devices can be connected to processors via a switched fabric, which consists of one or more FICON
directors in the path from the processor (channels) to the device (control unit). The directors may be a
long distance from each other and connected via one or more inter-switch links (ISLs). Switch vendors
support a number of different fabric topologies and routing algorithms. The path an I/O request takes
through the fabric will vary depending upon the fabric topology and routing algorithm. Therefore, when a
problem occurs it can be difficult to determine the cause.

Switched fabric topology terminology

Fibre channel is a networking technology primarily used for storage area networking. FICON itself is a
protocol layer created by IBM which builds upon the fibre channel transport protocol. A switched fabric is
a fibre channel topology in which individual node ports are interconnected and managed by switches.
The following terms can be used to describe IBM Z® hardware and z/OS I/O configuration, along with the
equivalent terminology used in a switched fabric:
Director
An I/O router that can connect any input port to any output port, which may be referred to as a switch.

64 z/OS: MVS System Commands

 Central processor complex (CPC)
A collection of IBM Z® hardware which is contained in a mainframe (main storage, one or more central
processors, and channels), and which may be referred to as a host system, or simply a host.
Channel (CHPID or PCHID)
A FICON port on a CPC, which may be referred to as a host port.
Control unit (CU)
A storage unit, which may be referred to as a storage system, or simply storage.
Channel path (path)
A series of point-to-point connections that form a route through the network between two
communicating nodes, which may be referred to as a data link, or simply a link.
Exchange
An I/O operation routed through the fabric over a data link.
Figure 8 on page 65 shows an example of a switched fabric.

Figure 8. Example of a switched fabric

In Figure 8 on page 65, fibre channel connection types are labeled using the convention _Port, prefixed
by one or more letters to signify the type of connectivity they provide in the fabric infrastructure. The
hardware components have one or more of the following ports:
N_Ports
Node ports, which are on a host or storage system.
F_Ports
Fabric ports, which are on a switch and provide connections between a node and the network.
E_Ports
Expansion ports, which are on a switch and connect to other switches, sometimes by means of inter-
switch links (ISLs).

System operations 65
 Fabric login is the process by which an N_Port (control unit or channel) registers its presence and
establishes the route through the fabric. This occurs during initialization of the channel and the control
unit.
An entry port is the F_Port or E_Port where the I/O enters the switch, and an exit port is the F_Port or
E_Port where the I/O leaves the switch. Entry and exit ports are relative to the direction of the route
(channel to control unit, or control unit to channel) and location within the route. The switch type is also
determined by the route through the fabric. If there is only one switch, then the switch type is the only
director. If more than one switch, the first entry port is attached to the source director and the last exit
port is attached to the destination director. The switches between the source director and the destination
director are known as intermediate directors.
Figure 9 on page 66 shows two switches, each acting as a source director and destination director
depending on the direction of the I/O flow.

Figure 9. Example of source and destination directors

If the direction of the I/O is from the processor (source) to the CU (destination), port 00 is the entry port
to Director A (Source Director), port 01 is the exit port. Port 20 is the entry port to Director B (destination
Director) and port 23 is the exit port.
If the direction of the I/O is from the CU (source) to the processor (destination), port 23 is the entry port
to Director B and port 20 is the exit port. Port 01 is the entry port to Director A and port 00 is the exit port.

Routing and grouping methods

Fibre channel infrastructure can further be described by the methods used to route I/O requests through
the fabric, as well as how multiple links are grouped to form a logical link. The names of the routing and
grouping methods described here are vendor-neutral. Different switch vendors have different names for
their routing methods (for example, OXID and exchanged based routing) and grouping methods (for
example, trunking).

Static routing
When static routing is in effect, a route through the fabric is assigned at fabric login time. If there is a link
failure on the assigned route, one of the alternate routes is used. Figure 10 on page 67 shows an
example of static routing.

66 z/OS: MVS System Commands

Figure 10. Example of static routing in a switched fabric

Figure 10 on page 67 shows a static path from port 00 to port 02 with three alternate paths. If the link
between port 02 and port 11 fails, one of the alternate ports (01, 03, or 04) will be used.

Dynamic routing
When dynamic routing is in effect, each I/O request (exchange) can take a different path through the
fabric. If a link failure occurs, any eligible path will be used. The algorithm used to determine how I/O
requests are routed through the fabric, as well as how eligible paths are determined, is specific to each
implementation and vendor. For example, I/O requests may be distributed across the different paths
according to the available bandwidth. Additionally, the set of eligible paths may be determined at fabric
build or fabric login time.
Figure 11 on page 67 shows an example of dynamic routing.

Figure 11. Example of dynamic routing in a switched fabric

I/O requests, or exchanges, from port 00 can use either port 01, 02, 03, or 04. Exchange 1 (XID 1) uses
port 02; exchange 2 (XID 2) uses port 04.

Link aggregation
Aggregation means that multiple ISLs are logically grouped to act as a single, higher bandwidth ISL. If
there is a link failure, the affected link is removed. The path is intact as long as one link in the aggregation
is active. Aggregation can be used with either static or dynamic routing. The formation of aggregate links
and how traffic is distributed between the eligible links is vendor-specific.
Figure 12 on page 68 shows an example of link aggregation.

System operations 67
 Figure 12. Example of link aggregation

In Figure 12 on page 68, I/O requests are routed to the aggregate consisting of ports 01 and 02 (agg-1).
This aggregate acts as a single logical link and frames can be routed through either ISL. If one link in
agg-1 fails, agg-1 will still be used since there is a second functioning link. If both links through agg-1 fail,
then the second aggregate consisting of ports 03 and 04 (agg-2) may be used. This example shows an
aggregate link used with static routing. However, this is applicable to dynamic routing as well.

Control unit port function

The control unit port (CUP) function allows a z/OS system to communicate with the FICON Director
through channel programs. This includes control functions like blocking and unblocking ports,
performance monitoring, and error reporting functions.
The CUP device is simulated as a special firmware load on the switch that allows a z/OS system to issue
channel programs to it. The CUP device is defined in the I/O configuration as a switch device and is
brought online to z/OS. The control unit definition for the CUP device consists of one or more channel
paths attached to the switch with the reserved port address destination of 0xFE, which is defined by the
FICON architecture as the address of the control unit port (CUP). Therefore, I/O requests routed to this
destination port are directed to the CUP.

Symptoms and causes of fabric problems

Problems within a switched fabric may be surfaced in different ways. This topic describes some common
issues within a fabric and their possible causes.

Symptoms of problems within the fabric

Symptoms of a fabric problem can be externalized through console messages or information within
displays or reports. Some common symptoms that may develop and examples of message IDs that may
be displayed as a result of a problem within the fabric are:
• Path is not available (IOS001E, IOS002A)
• Errors on channel (IOS050I)
• Missing interrupts (IOS071I)
• Time out errors (IOS051I)
• Long command response time one or more channel paths (for example, RMF I/O Queuing report)
• Alert messages from the switch indicating problems within the fabric
• Fenced port
• High port error counts
• High port utilization

68 z/OS: MVS System Commands

Causes of fabric problems
Errors within the fabric can be caused by either software or hardware problems. Some of the potential
issues that can cause problems in the fabric are:
• Defective cables or optics
• Congestion within the fabric
• I/O or switch configuration problems, such as incorrect cabling or routing
• Channel or control unit hardware or firmware issues
• I/O configuration definition errors

Detection and reporting of fabric problems

There are several tools that can be used to assist in the detection and analysis of fabric problems. This
topic briefly describes some of these tools.

RMF reports
RMF provides online, interactive performance monitoring and long-term overview reporting with post-
processor reports. Some RMF reports that can assist in analysis of fabric problems are:
• Channel path activity report
• Device activity report
• I/O queueing activity report
• FICON Director activity report
• Enterprise Disk Systems (ESS) report
See z/OS RMF Report Analysis for more information about these reports.

DISPLAY M=DEV command

The DISPLAY M=DEV command allows you to display the route through the storage area network (SAN)
fabric for a specific device and channel path by specifying the ROUTE keyword. The routing information
includes all of the switches and ports that are in the path from the channel to the device. If the HEALTH
keyword is specified, health information such as the utilization, optical signal strength, and the state of
each port ID is also displayed. Reporting of routing and health information will only be performed when
the channel is connected to a switch and the control unit definition for the channel path is defined in the
I/O configuration with a two-byte link address. See the description of the D M=DEV command in
“Displaying system configuration information” on page 338 for more information about the syntax for this
command.
In the routing portion of the display output, information for each switch in the path is displayed, which
includes its domain and switch type. The definition of the switch type depends upon the number of
switches in the path between the channel and device, and the position of the switch within the path. If
there is only one switch, the switch type is shown as Only Director. If there is more than one switch,
the first switch is known as the Source Director and the last switch is known as the Destination
Director. If there are any switches between the source director and the destination director, each of
those switches is known as an Intermediate Director.
For each entry and exit port, information about what is physically and logically connected to that port is
displayed under the From and To columns. A physical connection means that the port is connected via a
fibre optic link to a channel, control unit, or another switch. That is, there is a physical link between the
port and the other end of the link. A logical connection means that frames from this port are routed to one
or more ports on the same switch. However, there is no physical link between these ports.
• For entry ports, the physical connection appears under the From column and represents either a
channel, control unit, or a single port on another switch. The logical connection appears under the To
column and represents a single port or a group of ports on the same switch, depending on the routing
and grouping methods.

System operations 69
 • For exit ports, the logical connection appears under the From column and always represents a single
entry port on the same switch. The physical connection appears under the To column and represents
either a channel, control unit, or a single port on another switch.
For example, the entry port on the first switch (source director) is physically connected to a channel but
logically connected to one or more exit ports on the same switch. The exit ports on the first switch are
logically connected to the entry port on that switch, but are physically connected via ISLs to entry ports
on the next switch.
Note that the definition of what is considered an entry port or exit port depends on the direction of the
display request: channel to device (TODEV) or device to channel (FROMDEV). For example, when TODEV
is specified, the port that is connected to the channel is considered an entry port and the port connected
to the control unit is considered an exit port. However, if FROMDEV is specified, the roles are reversed.
When a port is connected to a channel, Chan appears under the From or To columns of the display,
depending on which direction was specified. Likewise, when a port is connected to a control unit, CU
appears in the display.
When an entry or exit port is connected to a single switch port, the domain and port number are displayed
as a four-digit number under the From or To columns.
When an entry port is connected to multiple ports on the current switch, a dynamic or aggregate group
number is displayed under the To column, depending on the routing and grouping methods used. This is
described in more detail later.
When an entry port uses static routing, the exit port or aggregate group number assigned to the port and
the number of alternate paths are displayed. Detailed information about the alternate paths is not
displayed.
When an entry port uses dynamic routing, the set of eligible exit ports is assigned a dynamic group
number. This group number appears in two places. First, it appears under the Dyn column for the exit port
to show which ports make up the dynamic group. Second, it appears under the To column for the entry
port to show that it is associated with this dynamic group of ports. The value that is assigned for the
dynamic group number is switch vendor-specific.
When a set of entry or exit ports are part of an aggregate group of ports, those ports are assigned an
aggregate group number. This group number appears in two places. First, it appears under the Agg
column to show which ports make up the aggregate group. Second, if I/O requests are being statically
routed from an entry port to this aggregate set of ports, then the aggregate group number appears under
the To column of the entry port. The value that is assigned for the aggregate group number is switch
vendor-specific.
For the health portion of the display, a description of the health of the fabric, each switch, and each port is
displayed, as well as the following information for each port:
• The % transmit/receive utilization indicates the percent utilization of the total transmit or receive
bandwidth available at the port.
• The % transmit delay is the percent of time that the frame transmission was delayed because no buffer
credits were available on the port. The % receive delay is the percent of time that the port was unable to
receive frames because all receive frames were utilized.
• The error count is the number of errors detected on the port affecting the transmission or receipt of
frames on the port. This is a sum of the errors counted over the fabric diagnostic interval, which is set to
30 seconds by z/OS.
• The optical signal column indicates the signal strength of the fibre optic signal being transmitted/
received by this port, in units of dBm.

Example 1: Static routing with aggregate links

Figure 13 on page 71 shows an example of static routing, where frames for the I/O exchange go to one
assigned port.

70 z/OS: MVS System Commands

Figure 13. Example of static routing with aggregate links

D M=DEV command output for Example 1

The DISPLAY command in this example is requesting the routing and fabric health information for a
specific path, from the channel port 70 to the port for device 2000 (TODEV). The output shown here
includes only the routing and health portions of the message. Other information from the D M=DEV
command that precedes this information is not shown.

D M=DEV(2000,(70)),ROUTE=TODEV,HEALTH

IEE583I hh.mm.ss DISPLAY M 058

DEVICE sdddd STATUS=ONLINE

Source to destination routing information follows:

Switch Domain=20, Type=Source Director
Group
Port Type From To Agg Dyn Speed Misc
00 Entry Chan Agg-01 .. .. 8G Static Alt=1
01 Exit 2000 3010 01 .. 8G
02 Exit 2000 3011 01 .. 8G
03 Exit 2000 3012 01 .. 8G
04 Exit 2000 3013 01 .. 8G

Switch Domain=30, Type=Destination Director

Group
Port Type From To Agg Dyn Speed Misc
10 Entry 2001 3018 01 .. 8G Static Alt=1
11 Entry 2002 3018 01 .. 8G Static Alt=1
12 Entry 2003 3018 01 .. 8G Static Alt=1
13 Entry 2004 3018 01 .. 8G Static Alt=1
18 Exit Mult CU .. .. 8G ......

From the example output, you can see that the route from the channel to the device travels through two
switches, domains 20 and 30, with domain 20 being the source director and domain 30 being the
destination director. The channel is connected to entry port 00 on switch domain 20, as indicated by the
From column for that port. The To column for the same port indicates that I/O requests originating from
this port are routed to aggregate 01. From the Group Agg column, you can also determine that aggregate
01 consists of exit ports 01, 02, 03, and 04 on the switch. Each of these exit ports is connected to a
different port on switch domain 30, as shown in the To column for the ports. For example, port 03 routes
I/O to port 12 on domain 30. The speed listed is the negotiated speed, in gigabits per second.
The information for the destination director 30 can be interpreted in a similar manner. Entry ports
10,11,12, and 13 are all within aggregate group 01 and route the I/O requests to port 18 on the same
switch. Notice that port 18 will have data routed to it from multiple entry ports on the switch. Since there

System operations 71
 is not a single originating port to identify, the From column contains Mult. Port 18 is not part of an
aggregate group and therefore contains .. in that column. The control unit is connected to port 18.
Note that, in this static routing example, the data for aggregate 05 is not displayed; however, the
information in the Misc column indicates that I/Os are statically routed and there is one alternate route
defined.

Health display for Example 1

The following output shows the health display for Example 1:

Health information follows:

Fabric Health=Port Error

Switch Domain=20, Health=No health issues

%Util %Delay Error Count Opt Signal
Port Health Trn/Rcv Trn/Rcv Trn/Recv Trn/Recv
00 Port Normal 0/0 0/0 0/0 -4.8/-6.6
01 Port Normal 0/0 0/0 0/0 -2.4/-2.0
02 Port Normal 0/0 0/0 0/0 -2.4/-2.1
03 Port Normal 0/0 0/0 0/0 -4.9/-6.6
04 Port Normal 0/0 0/0 0/0 -2.1/-2.3

Switch Domain=30, Health=Port Error

%Util %Delay Error Count Opt Signal
Port Health Trn/Rcv Trn/Rcv Trn/Recv Trn/Recv
10 Port Fenced 0/0 0/0 0/0 ../-6.7
11 Port Normal 0/0 0/0 0/0 -2.4/-2.7
12 Port Normal 0/0 0/0 0/0 -2.1/-2.4
13 Port Normal 0/0 0/0 0/0 -2.4/-2.1
18 Port Normal 0/0 0/0 0/0 -2.4/-2.1

This example of the health data shows that there is a health problem within the fabric, on switch domain
30, as shown by the fabric and switch text Port Error. Switch domain 20 shows no health problems,
but port 10 on switch domain 30 shows that the port has been fenced. The text provided in the fabric
health, switch health, and port health is switch vendor-specific. If any data is not valid, .. is displayed in
the appropriate column.

Example 2: Dynamic routing

Figure 14 on page 72 shows an example of dynamic routing, where frames for the I/O exchange may be
routed to any of the eligible ports. Each of the dynamic paths consists of two aggregate groups. Aggregate
group 01 (Agg-01) consists of ports 01 and 02 and aggregate group 03 (Agg-03) consists of ports 03 and
04.

Figure 14. Example of dynamic routing

72 z/OS: MVS System Commands

D M=DEV command output for Example 2
The DISPLAY command in this example is requesting the routing information for a specific path from the
channel port 70 to the port for device 2000 (TODEV):

D M=DEV(2000,(70)),ROUTE=TODEV
IEE583I hh.mm.ss DISPLAY M 058
DEVICE sdddd STATUS=ONLINE

Source to destination routing information follows:

Switch Domain=70, Type=Source Director
Group
Port Type From To Agg Dyn Speed Misc
00 Entry Chan Dyn-01 .. .. 8G Dynamic
01 Exit 2000 3010 01 01 8G
02 Exit 2000 3011 01 01 8G
03 Exit 2000 3012 03 01 8G
04 Exit 2000 3013 03 01 8G

Switch Domain=30, Type=Destination Director

Group
Port Type From To Agg Dyn Speed Misc
10 Entry 2001 3018 01 .. 8G
11 Entry 2002 3018 01 .. 8G
12 Entry 2003 3018 03 .. 8G
13 Entry 2004 3018 03 .. 8G
18 Exit Mult CU .. .. 8G

You can interpret the output in this example in a similar manner as in “D M=DEV command output for
Example 1” on page 71. It shows that the route direction is from the channel to the device and travels
through two switches. The entry and exit ports for each switch in this route are identified, along with the
entity to which the port is connected on both ends. Notice that dynamic routing is being used, as noted by
the Misc column. I/O requests for device 2000 originating from CHPID 70 are dynamically routed to
dynamic group 01. The Group Dyn column shows that exit ports 01, 02, 03, and 04 are all in dynamic
group 01, and the Group Agg column shows that these exit ports are in two distinct aggregate groups, 01
and 03. Dynamic routing does not apply to the ports on switch domain 30 for I/O requests in this
direction; therefore, those ports contain .. in the Group Dyn column. In the dynamic routing scenario, all
ports are displayed.

Health checks
This topic describes some of the health checks that can help detect and analyze fabric problems.

Command response time monitoring and reporting

The command response (CMR) time monitor detects any abnormally high command response time that
could indicate a SAN problem. CMR time is a component of response time and measures the round trip
delay of the fabric, along with minimal channel and control unit involvement. By monitoring this
measurement and comparing it among the paths to a control unit, fabric problems, such as hardware
errors, misconfiguration, and congestion, can be more easily detected. In addition, inconsistent command
response times will trigger fabric monitoring which is described in “Fabric monitoring and reporting” on
page 75.
The CMR health check (IOS_CMRTIME_MONITOR) reports on any exceptions detected by the monitor.
The check issues an exception if at least one control unit in the system has a path with an average CMR
time that is significantly higher than the other paths to the control unit. See IBM Health Checker for z/OS
User's Guide for more information about this health check.
The following example shows the command response time health check report output. In this example,
the threshold value is 3, and the ratio value is 5. This means that, for an exception to be reported, the
average command response time must be greater than three milliseconds, and the CHPID with the
highest average CMR time must be at least five times greater than the CMR time for the CHPID with the
lowest average response time.

CHECK(IBMIOS,IOS_CMRTIME_MONITOR)
SYSPLEX: LOCAL SYSTEM: SY1
START TIME: 04/23/2013 15:29:05.310858
CHECK DATE: 20100501 CHECK SEVERITY: MEDIUM

System operations 73
 CHECK PARM: THRESHOLD(3),RATIO(5),XTYPE(),XCU()

IOSHC113I Command Response Time Report

The following control units show inconsistent average command response

(CMR) time based on these parameters:
THRESHOLD = 3
RATIO = 5

CMR TIME EXCEPTION DETECTED AT: 04/23/2013 15:25:08.971846

CONTROL UNIT = 0500
ND = 002107.000.IBM.PK.000000000002

ENTRY EXIT CU I/O AVG

CHPID LINK LINK INTF RATE CMR
14 B153 B177 0001 16.486 2.560
44 B353 B375 0012 13.245 5.592
16 B055 B277 0013 13.245 25.60
46 B154 B376 0104 13.112 4.941
47 B155 B377 0105 0 ***

* Medium Severity Exception *

IOSHC112E Analysis of command response (CMR) time detected one or

more control units with an exception.

In the example output, you can see that the CMR time for CHPID 16 is the highest, and is greater than five
times that of CHPID 14, which reports the lowest average response time. Also, note that CHPID 47 does
not indicate an average response time, which means it is offline or has no significant data to report.

I/O rate monitoring and reporting

The I/O rate monitor detects any control units in the system that are reporting inconsistent I/O rates for
their attached channel paths. I/O rate is the number of I/O requests started down the channel path, per
second. The system typically distributes I/O requests equally across all paths for a control unit. When the
system determines that there is a performance problem with a path, it will direct I/O requests away from
that path, resulting in inconsistent I/O rates across the paths. Therefore, a lower than average I/O rate can
be a symptom of potential problems in the fabric. By monitoring this measurement and comparing it
among the paths to a control unit, fabric problems similar to those detected by the CMR monitor can be
surfaced. In addition, an inconsistent I/O rate will trigger fabric monitoring, which is described in “Fabric
monitoring and reporting” on page 75.
The I/O rate health check (IOS_IORATE_MONITOR) reports exceptions detected by the I/O rate monitor.
The check issues an exception if at least one control unit in the system has a total I/O rate across all of its
channel paths that exceeds a user-specified threshold value, and at least one path with an I/O rate
significantly lower than that of the channel path with the highest I/O rate for the control unit. The I/O rate
health check runs on a zEnterprise® EC12 (zEC12) or later processor. See IBM Health Checker for z/OS
User's Guide for more information about this health check.
The following example shows the I/O rate health check report. In this example, the threshold value of 100
indicates that the total I/O rate across all of the CHPIDs must exceed 100 I/Os per second, which it does.
The ratio value of 2 means that any CHPID that has an I/O rate of less than a factor of 2 (that is, one-half)
of the CHPID with the highest I/O rate would be flagged.

CHECK(IBMIOS,IOS_IORATE_MONITOR)
SYSPLEX: LOCAL SYSTEM: SY1
START TIME: 04/22/2013 08:44:14.271360
CHECK DATE: 20120430 CHECK SEVERITY: MEDIUM
CHECK PARM: THRESHOLD(100),RATIO(2),XTYPE(),XCU()

IOSHC133I I/O Rate Report

The following control units show inconsistent I/O rates based on these
parameters:
THRESHOLD = 100
RATIO = 2

I/O RATE EXCEPTION DETECTED AT: 04/22/2013 08:44:14.254730

CONTROL UNIT = 0500
ND = 002107.000.IBM.PK.000000000002

ENTRY EXIT CU I/O AVG IOR

74 z/OS: MVS System Commands

 CHPID LINK LINK INTF RATE CMR EXC
14 B153 B177 0001 39.603 2.560 *
44 B353 B375 0012 101.38 2.112
16 B055 B277 0013 98.019 2.134
46 B154 B376 0104 50.693 2.048
47 B155 B377 0105 *** ***

* Medium Severity Exception *

IOSHC132E Analysis of I/O rates detected one or

more control units with an exception.

Notice that the I/O rate for CHPID 14 is less than half that of CHPID 44 and, therefore, is marked with an
asterisk in the IOR EXC column. If there are multiple paths that were significantly below the threshold, all
such CHPIDs would be marked as having an exception. Also note that CHPID 47 is likely offline, as
indicated by the *** for the I/O rate.

Fabric monitoring and reporting

The fabric monitor begins collecting routing and health information from the switch periodically after it is
triggered by one of the following unusual conditions:
• Command response time monitoring or I/O rate time monitoring detected a discrepancy.
• The switch presents an alert message indicating a problem within the fabric.
• An IFCC or interface time out occurs due to errors that occurred between the channel and source port or
the CU and the destination port.
Fabric monitoring and reporting can only occur when the channel is connected to a switch device and the
control unit definition for the path is defined in the IODF with a two-byte link address.
Until the route is healthy (no unusual conditions are detected for an extended period of time), diagnostic
information about the affected source or destination route will be obtained from the switch by the monitor
at an internally defined interval. Many routes can be monitored simultaneously.
The fabric monitor health check (IOS_FABRIC_MONITOR) exposes possible issues by generating
exceptions and reports for the routes being monitored. The routing and health data obtained by the
monitor is reproduced in the report for analysis. The content and format of this data is similar to the
output of the D M=DEV command (described in “DISPLAY M=DEV command” on page 69) with the
ROUTE=BOTH, HEALTH options. See IBM Health Checker for z/OS User's Guide for more information about
this health check.
The following example shows the output for the fabric monitor health check report. In this example, an
exception is being reported because port 81 on switch C3 is fenced. The complete routing and health
information for the path is provided for diagnostic purposes.

CHECK(IBMIOS,IOS_FABRIC_MONITOR)
START TIME: 04/29/2013 17:34:09.652404
CHECK DATE: 20130329 CHECK SEVERITY: MEDIUM
CHECK PARM: LOG(YES),SHOW(LATEST)

IOSHC120I Fabric Health Report

The following channel paths show fabric health issues:

FABRIC HEALTH EXCEPTION DETECTED AT: 04/29/2013 17:31:18.301627

CHPID=00, Entry link=C181, Exit link=C310, Suspect port=**

Source to destination routing information follows:

Switch Domain=C1, Type=Source Director
Group
Port Type From To Agg Dyn Speed Misc
00 Entry Chan Dyn-01 .. .. 8G Dynamic
81 Exit C100 C381 .. 01 8G
82 Exit C100 C382 .. 01 8G

Switch Domain=C3, Type=Destination Director

Group
Port Type From To Agg Dyn Speed Misc
81 Entry C181 C310 .. .. 8G
82 Entry C182 C310 .. .. 8G
10 Exit Mult CU .. .. 8G

System operations 75
 Health information follows:

Fabric Health=Port Error

Switch Domain=C1, Health=No health issues

%Util %Delay Error Count Opt Signal
Port Health Trn/Rcv Trn/Rcv Trn/Recv Trn/Recv
00 Port Normal 0/0 0/0 0/0 -4.5/-7.4
81 Port Normal 0/0 0/0 0/0 -2.4/-2.9
82 Port Normal 0/0 0/0 0/0 -4.5/-7.4

Switch Domain=C3, Health=Port error

%Util %Delay Error Count Opt Signal
Port Health Trn/Rcv Trn/Rcv Trn/Recv Trn/Recv
81 Port Fenced 0/0 0/0 0/0 ../-6.7
82 Port Normal 0/0 0/0 0/0 -2.4/-2.1
10 Port Normal 0/0 0/0 0/0 -4.5/-7.4

Destination to source routing information follows:

Switch Domain=C3, Type=Source Director

Group
Port Type From To Agg Dyn Speed Misc
10 Entry CU Dyn-02 .. .. 8G Dynamic
81 Exit C310 C181 .. 02 8G
82 Exit C310 C182 .. 02 8G

Switch Domain=C1, Type=Destination Director

Group
Port Type From To Agg Dyn Speed Misc
81 Entry C381 C100 .. .. 8G
82 Entry C382 C100 .. .. 8G
00 Exit Mult Chan .. .. 8G

Health information follows:

Fabric Health=Port Error

Switch Domain=C3, Health=Port Error

%Util %Delay Error Count Opt Signal
Port Health Trn/Rcv Trn/Rcv Trn/Recv Trn/Recv
10 Port Normal 0/0 0/0 0/0 -2.4/-7.4
81 Port Fenced 0/0 0/0 0/0 ../-7.4
82 Port Normal 0/0 0/0 0/0 -2.4/-7.4

Switch Domain=C1, Health=No health issues

%Util %Delay Error Count Opt Signal
Port Health Trn/Rcv Trn/Rcv Trn/Recv Trn/Recv
81 Port Normal 0/0 0/0 0/0 -2.4/-7.4
82 Port Normal 0/0 0/0 0/0 -2.4/-7.4
00 Port Normal 0/0 0/0 0/0 -2.4/-7.4

* Medium Severity Exception *

IOSHC119E Fabric health issues have been detected

Dynamic routing consistency reporting

The dynamic routing health check (IOS_DYNAMIC_ROUTING) identifies any inconsistencies in the
dynamic routing support within the SAN. In order for dynamic routing to function properly, dynamic
routing must be supported at all endpoints, the channel and connected devices, communicating through
the switches. When dynamic routing is enabled in the SAN, the health check will verify that the processor
and attached DASD, tape, and non-IBM devices defined as type CTC support dynamic routing and will
identify those endpoints that do not. See IBM Health Checker for z/OS User's Guide for more information
about this health check.
The following example shows the output for the dynamic routing health check report. In this example,
dynamic routing is enabled in the SAN; however, there are two storage controllers that do not support
dynamic routing.

CHECK(IBMIOS,IOS_DYNAMIC_ROUTING)
SYSPLEX: LOCAL SYSTEM: SY1
START TIME: 06/26/2013 12:31:18.246880
CHECK DATE: 20130601 CHECK SEVERITY: MEDIUM

76 z/OS: MVS System Commands

 IOSHC144I Dynamic routing is enabled in the SAN but not supported
by the following controllers:

NODE DESCRIPTOR
002107.932.IBM.75.000000000002
002107.951.IBM.75.000000004F01

* Medium Severity Exception *

IOSHC142E Dynamic routing inconsistencies were detected

…

Additional recovery actions

This section includes these topics:
• Recovery by CPU restart

Recovery by CPU restart

The operator can initiate recovery from some system incidents, such as loops and uncoded wait states, by
issuing a restart to the processor that has the problem. The restart reason that is entered as part of the
restart process directs the system to perform one of two recovery actions:
Restart reason 0
The system tries to display message IEA500A on the first two consoles defined as master or alternate
and locally attached to the system issuing the message. The message identifies the current unit of
work on the target processor. The operator can reply either:
• RESUME to allow the current unit of work to continue
• ABEND to end that unit of work with an abend X'071'
If the operating system cannot communicate with the either console to issue message IEA500A, it
ends the current unit of work with an abend X'071'.
Restart reason 1
The operating system:
• Interrupts the current unit of work on the target processor
• Detects and attempts to repair errors in critical system areas
• Writes a logrec data set error record for completion code X'071' with reason code 4 when repair
actions were taken
• Reports the results of some of the actions taken in message IEA501I
• Returns control to the interrupted unit of work
Note: Restart of the CPU in a restartable wait state ignores the restart reason.
See Chapter 4, “MVS system commands reference,” on page 137 for information about restart.

System operations 77
78 z/OS: MVS System Commands
Chapter 2. System Reconfiguration

Reconfiguration is the process of adding hardware units to, or removing hardware units from, a
configuration. Units can be either:
• Online: Units in use by a system are called online. When both physically and logically online, a unit is
available to be used by the system.
• Offline: Units not in use by a system are called offline. When either physically or logically offline, a unit
is not available to be used by the system.
An installation can use reconfiguration to:
• Adapt a system to changing work loads by configuring units online or offline as required.
• Perform maintenance on a part of a complex while the other part continues normal operation.
• Possibly recover system operation by configuring failing units offline.
Hardware unit or units may be put offline before initialization of the system or systems. To do this, an
operator can deselect through the system console such units as central processors (CPU), storage
elements, or channel paths. Note that an operator should never deselect a unit during system operation,
because the operating system is not notified of the removal.
During system operation, the operating system configures failing units offline with or without any
intervention. When intervention is needed, the operator:
• Can enter a CONFIG command that identifies the CONFIGxx member of Parmlib that specifies the
reconfiguration. (See z/OS MVS Initialization and Tuning Reference.)
• Can enter a CONFIG or VARY command that directly configures units online or offline. (See Chapter 4,
“MVS system commands reference,” on page 137.)
For maintenance of hardware, prepare reconfiguration actions to configure hardware units offline for
repair and back online so the system can use them. Also, hardware units and channel paths are
reconfigured offline then online during reconfiguration of partitionable systems.

Dynamic I/O configuration

Dynamic I/O configuration lets you change your I/O configuration without causing a system outage. In
other words, you can select a new I/O configuration definition without performing a power-on-reset (POR)
of the hardware or an initial program load (IPL) of the z/OS system. Using I/O definition files (IODFs)
created through hardware configuration definition (HCD), dynamic I/O configuration allows you to add,
delete, or modify the definitions of channel paths, control units, and I/O devices to the software and
hardware I/O configurations. You can change the I/O configuration definitions to both software and
hardware or software only. (See z/OS HCD Planning.)
Dynamic I/O configuration has the following benefits:
• Increases system availability by allowing you to change the I/O configuration while z/OS is running, thus
eliminating the POR and IPL for selecting a new or changed I/O configuration definition.
• Allows you to make I/O configuration changes when your installation needs them rather than wait for a
scheduled outage to make the changes.
• Minimizes the need to over-define an I/O configuration by logically defining hardware devices that do
not physically exist.

© Copyright IBM Corp. 1988, 2018 79

Logical and physical reconfiguration
Logical reconfiguration allows or prevents use of a resource by the operating system. Physical
reconfiguration allows or prevents use of a resource by the hardware. An operator can enter a CONFIG
command on the console with master authority to logically and physically reconfigure the following
hardware units, if applicable for the particular processor complex:
• CPUs
• Central storage elements
• Central storage increments
• Channel paths
• I/O devices
Also, when an operator issues a CONFIG CPU command to reconfigure a processor, the system logically
reconfigures any Integrated Cryptographic Feature (ICRF) attached to the processor.
Note: Physical reconfiguration may not be supported for all hardware units by all processor models. (See
Functional Characteristics).

Reconfiguration support according to processor types

The reconfiguration functions supported by z/OS depend on the configuration of the processor complex,
as follows.

Uniprocessor (UP)
Depending on the processor type, an installation can configure offline some or all of the following:
• Central storage elements
• Central storage increments
• Channel paths
• I/O devices
In a UP system, the purpose of reconfiguration is to configure offline failing units to allow the system to
continue operation.

Multiprocessor (MP)
Depending on the processor type, an installation can configure offline some or all of the following:
• Central processors, including any associated ICRFs
• Central storage elements
• Central storage increments
• Channel paths
• I/O devices

Reconfiguring a central processor

When configuring a central processor offline, the operating system stops dispatching work to the
processor and takes it logically offline. Then the system stops the processor removes it physically from
the configuration, if physical central processor reconfiguration is supported by the machine.

Actions to reconfigure a central processor offline

80 z/OS: MVS System Commands

 1. Enter a CONFIG CPU(x),OFFLINE command on a console with master authority. The system responds
on the console on which the command was entered.
The operating system rejects a CONFIG CPU(x),OFFLINE command when:
• The target processor is the only online processor.
• The target processor is the only processor with an operative timer.
• Alternate CPU recovery (ACR) occurs during OFFLINE processing.
• Any active jobs have processor (CPU) affinity with the target processor.
2. If you enter a CONFIG command for a central processor and currently scheduled jobs have CPU
affinity for that processor, the system issues message IEE718I to list the jobs. Do the following:
a. Prevent the operating system from scheduling any additional jobs, by replying YES to message
IEE718D.
b. Either wait for the active jobs to complete or cancel them.
Note that replying YES to message IEE718D leaves the target central processor unavailable for
affinity job scheduling. If you want to restore the central processor to its original state, enter
CONFIG CPU(x),ONLINE to restore the original central processor status and make the target
central processor available for affinity job scheduling.
c. Reenter the CONFIG CPU(x),OFFLINE command.

Reconfiguring a central processor with an ICRF

The operator cannot directly reconfigure an ICRF. When the operator uses the CONFIG command to
reconfigure a central processor with an associated ICRF, the system changes the online/offline status of
both the central processor and the associated ICRF as follows:
• When the operator enters a CONFIG CPU(x), ONLINE and Integrated Cryptographic Service Facility/MVS
(ICSF/MVS) is active in the processor complex, the system brings the ICRF online.
• When the operator enters a CONFIG CPU(x), OFFLINE command the system takes the ICRF offline.
• When the operator enters a CONFIG CPU(x), ONLINE and ICSF/MVS is not active, the ICRF is not
brought online until ICSF/MVS is started.

Actions to bring online a central processor and its ICRF

Central processor x (CPU x) is to be brought online. The processor has an associated ICRF and ICSF/MVS
is installed and active in the processor complex.
Enter one of the following commands on a console with master authority; the system responds on the
console on which the command was entered:

CONFIG CPU(x)

CONFIG CPU(x), ONLINE

When the command completes, the system issues the following messages:

IEE504I CPU(x), ONLINE

IEE504I CRYPTO(x), ONLINE

System Reconfiguration 81
Removing the last ICRF
When a CONFIG command is entered to remove a central processor associated with the last online ICRF,
the system issues the following messages:

IEE109I CONFIG CPU(x), OFFLINE COMMAND WOULD REMOVE LAST CRYPTO

IEE325D REPLY U TO CONTINUE CONFIG COMMAND. REPLY C TO CANCEL

After U is replied to message IEE325D, the system takes the central processor and the ICRF offline.
From that point on, the system abnormally ends any jobs that request cryptographic services using ICSF/
MVS. This applies to new jobs and to jobs running in the processor complex at the time the system took
the ICRF offline.

Actions to take offline a central processor and its ICRF

Central processor x is to be taken offline. The processor has an associated ICRF.
Enter the following command on a console with master authority; the system responds on the console
on which the command was entered:

CONFIG CPU(x), OFFLINE

When the command completes, the system issues the following messages:

IEE505I CPU(x), OFFLINE

IEE505I CRYPTO(x), OFFLINE

Reconfiguring central storage

To place storage offline and then bring it online to be used again, commands can reconfigure central
storage increments and central storage elements.
Under PR/SM, storage may be reconfigured between logical partitions. See PR/SM Planning Guide for a
description of storage reconfiguration between logical partitions.

Physical view of central storage

Central storage is physically divided into storage elements (SE). The central storage elements are
composed of storage increments. Each storage increment may be composed of two sub-increments:
• One sub-increments contains the even-numbered frames of the increment, such as, 0-kilobyte, 8-
kilobyte, 16-kilobyte, and so on.
• The other contains the odd-numbered frames, such as, 4-kilobyte, 12-kilobyte, 20-kilobyte and so on.
The sub-increments of an increment may reside in different storage elements, as follows:

82 z/OS: MVS System Commands

Specifying the RSU parameter
To prepare for reconfiguration of central storage, specify an RSU parameter in the IEASYSxx parmlib
member or as a parameter during system initialization. The RSU parameter specifies the number of
storage units in central storage that the operating system should keep available for reconfiguration.
The RSU storage increments are reconfigurable or non-preferred. The remaining central storage
increments are non-reconfigurable or preferred.
The default RSU value is 0. If the installation does not specify an RSU value, the default means that the
operating system designates ALL installed central storage as preferred. With RSU=0, the system cannot
be reconfigured.
However, if you specify an RSU value that is greater than the total amount of real storage available on the
system, message IAR026I will be issued by the system during IPL indicating an RSU over-specification
condition, and showing the amount of real storage available on the system. This message will be followed
by an IAR006A message prompting for a valid RSU value. You must select the right RSU value for the
system, otherwise; a large RSU value can ultimately cause system performance problems and
degradation. For information about how to choose the correct RSU value, see z/OS MVS Initialization and
Tuning Reference.

System Reconfiguration 83
 Reference information: See z/OS MVS Initialization and Tuning Reference for more information about the
RSU parameter.

Reconfigurable storage increments

The central storage that is shared by all processors in a configuration is logically divided into storage
increments. For the following example, the installation specified RSU=8 to make half of the storage
increments reconfigurable.

Increment Type
60M Hardware storage area (HSA) and preferred
56M Reconfigurable
52M Reconfigurable
48M Reconfigurable
44M Reconfigurable
40M Reconfigurable
36M Reconfigurable
32M Reconfigurable
28M Reconfigurable
24M Preferred
20M Preferred
16M Preferred
12M System queue area (SQA) and Preferred
8M Preferred
4M Preferred
0M V=R and Preferred

The HSA cannot be in a storage increment that will be reconfigured. The HSA resides in the five highest
megabytes of central storage.

RSU example
Assume that a processor complex has 128 megabytes of central storage and that the storage increment
size is 4 megabytes. Such a system has 32 storage increments.
If the system initializes one side with RSU=16, the operating system allocates as reconfigurable the 16
storage increments (64 megabytes) of the offline side.

RSU parameter specification

The RSU values recommended for the least system overhead and maximum capability for reconfiguration
are as follows:

Processor Recommended RSU Value

Uniprocessor RSU=0
Non-partitionable RSU=0
multiprocessor

84 z/OS: MVS System Commands

Processor Recommended RSU Value
Partitionable processor in
single-image mode Total megabytes of installed central storage
RSU= -----------------------------------------------
2 * Central storage increment size in megabytes

Partitionable processor in
physically partitioned mode Total megabytes of installed central storage
RSU= -----------------------------------------------
2 * Central storage increment size in megabytes

Assignment of storage frames

Storage containing fixed pages cannot be reconfigured. The operating system assigns storage frames as
follows:

Storage Assignment
Non-preferred and preferred Normal page allocation requests
Non-preferred and preferred Short-term page fixes
Preferred Long-term page fixes for non-swappable jobs

However, if a long-term page fix for a non-swappable job requires storage but the preferred storage units
are full, the operating system may convert some non-preferred storage to preferred storage. If so, the
amount of storage available for reconfiguration will be less than that specified in the RSU parameter. The
operating system issues message IAR005I to notify the operator.
If the operator then tries to configure storage offline in preparation for partitioning, the system tries to
free enough central storage to support the request. Central storage and the address ranges assigned to
that storage cannot be configured offline either logically or physically until the required amount of storage
is available.
The operating system normally tries to assign requests for long-term fixed pages to preferred storage
frames when the requesting job was initiated as non-swappable. However, an authorized job can be
initiated as swappable and, while running, issue a SYSEVENT macro to make itself non-swappable for a
short period of time. The job may request long-term fixed pages that are assigned to non-preferred
storage. Usually this request is not a problem because the job shortly makes itself swappable again. The
system can free the storage that backs the long-term fixed pages when the job is swapped out when the
storage is required for storage reconfiguration.
However, a long-running job may make itself non-swappable for long times and also request short-term
fixed pages that cannot be freed until the job ends normally. Some of these requests may be satisfied
from non-preferred storage. Because the frames cannot be freed by paging them out or by swapping out
the job, storage reconfiguration may not be possible.
To resolve this problem, specify such jobs in the program properties table (PPT) in the SCHEDxx parmlib
member.
Reference information: See z/OS MVS Initialization and Tuning Reference for the SCHEDxx member.

System Reconfiguration 85
 Actions to reconfigure central storage

Enter at the console with master authority or in a CONFIGxx parmlib member:

1. CONFIG STOR(E=id),OFFLINE command to configure a central storage element offline
2. CONFIG STOR(E=id),ONLINE command to configure a central storage element online
The system responds on the console on which the command was entered or on the master console for
the system processing the CONFIGxx member.
When configuring a central storage element offline, the system may issue message IEE575A to indicate
that central storage configuration is waiting to complete. The system may cancel the message in less
than a minute. The system may issue and cancel the message several times.
If the message remains on the display for a long time, it indicates that the operating system cannot find
sufficient reconfigurable central storage to satisfy the configuration request.
If the system displays message IEE575A for a long time:
1. Enter a DISPLAY M=STOR command to identify the job using the central storage that cannot be freed.
2. Do one of the following:
a. Cancel any jobs that are using the storage to allow the storage configuration to complete.
b. Reply C to end the storage configuration process.
Any central storage already configured offline remains offline. If desired, bring this central storage
element back online by entering a CONFIG STOR(E=x),ONLINE command.

Reconfiguring channel paths

Channel paths may be reconfigured for partitioning and merging. Under PR/SM, channel paths may be
reconfigured to move a channel path from one logical partition to another.
Reconfigure channel paths carefully. Reconfiguration can remove connections to DASDs or MCS consoles
that are critical to the operation of z/OS. If this occurs, system operation will fail.

Actions to reconfigure channel paths

86 z/OS: MVS System Commands

 To configure channel paths, enter the following:
• To configure channel paths individually offline or online:

CONFIG CHP(x),OFFLINE
CONFIG CHP(x),ONLINE

• To configure all channel paths owned by a side of a partitionable processor complex:

CONFIG CHP(ALL,x),OFFLINE
CONFIG CHP(ALL,x),ONLINE

These commands are particularly useful when partitioning or merging the complex.
• To configure a range of channel paths:

CONFIG CHP(x-y),OFFLINE
CONFIG CHP(x-y),ONLINE

The system determines which devices are connected to a channel path and if that path is the last path to
a device. To configure offline the last path to a device, enter a CONFIG command with one of the
following operands:
• UNCOND operand: To configure offline the last path to an unallocated, online device
• FORCE operand: To configure offline the last path to a device regardless of the state of the device.
To make sure that FORCE is intended, the operating system issues message IEE800D to ask whether
to continue or stop the CONFIG command processing.
Enter all the CONFIG commands at a console with master authority. The system responds on the
console on which the command was entered.

Reconfiguring I/O devices

To reconfigure I/O devices, enter a VARY ONLINE/OFFLINE command at the console with master
authority. For a VARY OFFLINE command for a device that is currently in use, the operating system marks
the device ‘pending offline’. The operating system makes no further allocations to the device unless the
volume mounted on the device is specifically requested.
Because vary offline processing cannot complete until a device is unallocated, either wait until the jobs
using the device complete or cancel them.
Before reconfiguring a complex from single-image mode to physically-partitioned mode, complete or
cancel any tape volume mounts for devices to be reconfigured. Then enter a CONFIG
CHP(ALL,n),OFFLINE,UNCOND command.
If a tape mount is pending when the CONFIG command is entered, the tape drive(s) might not start after
they are mounted and the system has been partitioned. Another way to avoid this problem is to enter a
VARY device online command for the tape drive(s).

Reconfiguring a coupling facility

A coupling facility can be reconfigured to perform maintenance or to upgrade its level of control code.
Before reconfiguring a coupling facility, you should have a plan in place for its orderly shutdown, during
which time structures that are in the coupling facility can be either relocated to another coupling facility or
deallocated (with a possible data loss). Applications using the coupling facility for its structure(s) should
have documented procedures for how to relocate or deallocate them.

System Reconfiguration 87
 Refer to Parallel Sysplex (www.ibm.com/systems/z/advantages/pso) for help with the configuration of a
coupling facility.

88 z/OS: MVS System Commands

Chapter 3. z/OS operator console operations

The tasks of starting, running, and stopping an MVS system involve:

1. Operating the system itself—that is, controlling the system software and most installation hardware
(including processors, channel paths, and I/O devices)
2. Operating the MCS (multiple-console support), HMCS and SMCS (SNA multiple-console support)
consoles.
“Console characteristics and operations” on page 89 describes the physical characteristics and
techniques for operating the various consoles that MVS supports as operators' consoles. It describes the
characteristics and operations that you cannot control, including those operations that are common to all
operator's consoles.
“Defining and changing console characteristics” on page 105 continues the console descriptions of
“Console characteristics and operations” on page 89 by describing the console characteristics that you
can control. It describes the commands that operators and system programmers can use to tailor the
consoles and console operations to the installation's requirements.

Console characteristics and operations

Before choosing consoles for your system environment, review the information on the supported consoles
types.

General characteristics of display consoles

Many different input and output (I/O) devices can function as consoles in an MVS system. Logical
conditions determine how or if the devices function:
1. Online: If allocated, the system assigns functions with these two limitations:
• The device must be capable of performing the function.
• The device cannot be assigned as a console because it is allocated to some other function.
If unallocated, the device can be assigned as a console.
2. Offline: The device is generally unavailable for the system to use.
3. Console: The system can use the device to send messages to you, and you can use the device to issue
system commands (if the device has input capability), but you cannot use the device for other input/
output purposes.
4. Standby:
• Supported on the HMCS and MCS consoles only.
• I/O to the HMCS console is disabled.
• The VARY CN(name),ONLINE command is supported on the MCS, but not on the HMCS.
• To enter Standby mode, deactivate the HMCS session or issue the VARY CN(name),STANDBY
command.
You can use a device for multiple console support (MCS) if the device number for the console on a
CONSOLE statement, in the CONSOLxx parmlib member, is the same as the device number specified in
the IODF. SMCS consoles are also defined in CONSOLxx, but are not specified in HCD.

Subsystem use of consoles

Many different devices can function as consoles in an MVS system if they are specified as consoles in a
CONSOLxx parmlib member. If the console is allocated to a subsystem — CONSOLE
DEVNUM(SUBSYSTEM) — there is no corresponding device definition in the IODF. You should familiarize

© Copyright IBM Corp. 1988, 2018 89

 yourself with subsystem consoles if your configuration includes them; some of them can affect MVS
operations in important ways. It is called a subsystem-allocatable console and is defined to the
subsystem.
For a subsystem-allocatable console, the definition

CONSOLE DEVNUM(SUBSYSTEM)

must appear in the CONSOLxx parmlib member.

Multiple-console configuration
You can divide the functions and message traffic of the system among a number of consoles. These
consoles make up a multiple-console configuration controlled and serviced by MCS.
A multiple-console configuration for a system or sysplex consists of up to 99 active consoles per system.
These consoles can have different levels of authority. For more information, see z/OS MVS Planning:
Operations.
Any console with master console authority allows you to:
• Enter all operator commands
• Change the definition of the hardcopy message set or assign the hardcopy medium
Other MCS and SMCS consoles are used for specific types of operator-system communication when it is
more convenient to have a console located away from the processor. An MCS or SMCS console might, for
example, be located close to tape or remote teleprocessing devices to make it easier for the operator in
that area to see the magnetic tapes. An MCS or SMCS console without master authority cannot enter all
commands (see “System commands grouped according to system command authority” on page 110), and
can receive only those messages that are specifically routed to that console.
Your installation might further limit how you can use a console by assigning an operating use that
prevents the console from accepting commands.
A console you use both to issue commands and receive messages is in full-capability operating mode. A
console that only receives status displays is in status display mode. A console that only monitors system
activities and assists in system security is in message stream mode. Both message stream and status
display consoles do not accept commands.
The different console modes help limit the number of consoles that operators can use to issue
commands, and yet provide operators the information that they need to do their work.
At IPL, the system looks to the CONSOLxx member of parmlib to determine the operating modes of the
consoles. It also looks for the following attributes:
• System command groups — the categories of commands that the system accepts from that console
• Message routing codes — the messages the console receives, determined by routing code
• Message levels — the messages the console receives, determined by message level
• Hardcopy medium — the system log (SYSLOG) or operations log (OPERLOG) that receives the hardcopy
message set
• PFK definitions — the commands that console's PFKs issue

Features on display consoles

MCS display consoles can operate in full-capability, status display, or message stream mode. HMCS and
SMCS consoles only operate in full-capability mode. Each one has a keyboard to enter commands and
responses to messages and to signal the system that you are entering information. Each one also has a
cursor, which appears on the screen as a movable point of light (either an underscore, a horizontal bar, or
a vertical bar). The cursor points out the position on the screen that the system will examine for your next
action. This action might be positioning a typed character, entering a command, requesting message
deletion, or requesting a display. Special keys located on the console keyboard control cursor movement.
A display console can also have some or all of the following features:

90 z/OS: MVS System Commands

Selector pen
The selector pen is a light-sensitive device that is available on some display consoles. When you put
the pen over specific areas of the display console screen, it senses the light from the screen and
signals the system. The system then determines the screen location over which you have put the pen
and takes appropriate action. The action the system takes might involve entering operator commands,
deleting messages from the screen, cancelling processes, or presenting displays.
Audible alarm
An audible alarm is available on display consoles. The system sounds this alarm when certain changes
in conditions occur, such as when you enter an invalid CONTROL command. WTO macros with
descriptor codes of 1, 2, or 11, and all WTOR macros will cause the audible alarm to sound on
operator consoles so-equipped.
Program function keyboard
The program function keyboard is an input device that is available on some display consoles. You can
define each key on the program function keyboard to enter one or more operator commands; you can
enter a command or a group of commands by pressing one key.
Extended highlighting
Extended highlighting refers to blinking, reverse video, and underscored presentation of messages
that require operator action.
Color
Four or more colors are available on some devices, with certain colors identifying certain kinds of
messages that require action.
Intensity
Some messages that require operator action appear brighter.

Display screen areas

The operating mode of the console controls the appearance of a display screen. Figure 15 on page 92
illustrates the differences among the different kinds of consoles. The display screens can have these
functional areas:
Message area
This area contains system and problem program messages and copies of certain operator commands.
The size of the message area depends on the console.
Display areas
These areas contain formatted, multiple-line displays of information about some part of the system.
The displays are written to the console in response to certain commands, such as the DISPLAY
command. The default on consoles in full-capability mode is one display area, the default on consoles
in status display mode is two display areas. For consoles operating in full-capability mode, unless a
status display is requested, the display area is used for general messages.
PFK display line
This line contains a display of program function key (PFK) numbers that you use when entering
commands with the selector pen. This line is available on a 3277 model 2.
Instruction line
This line contains console control messages. For example, if you make an error entering a CONTROL
command, an error message appears in the instruction line.
Entry area
This area contains one or two lines that you use to enter commands and reply to messages.
Warning line
This line warns you of conditions that could require action. For example, a warning message appears
in this line when the message area is full and one or more messages are waiting to appear. The
warning line is not available on output-only consoles in status display operating mode.
Operator information area
This line, the bottom-most line on the screen, is separated from the rest of the screen by a horizontal
line. The operator information area, which is not controlled by z/OS, contains messages and symbols
that keep you informed of the operational status of the terminal. It is not available on some terminals.

z/OS operator console operations 91

 Figure 15 on page 92 shows the screens on consoles in the three different operating modes. You can
change the display areas on the consoles in full-capability mode and status display mode. The screen on
the console in message stream mode always appears as in the figure.

Figure 15. Comparison of the display screens of full-capability and output-only display consoles

L= Operand
Commands that manage consoles and console traffic use the L= operand to modify the screen area. For
example, use the L= operand to delete messages or to delete lines from the screen area.
Commands that direct output use the L= operand to direct the output to an out-of-line area that is defined
to the console. If there is no out-of-line area defined to the console, or if the area ID specified is z, the
message is displayed inline.
For more information on the syntax and use of the L= operand for specific commands, see the description
of the specific command in this book.
For a discussion of the L= operand in a sysplex, see z/OS MVS Planning: Operations.

Special screen characters

The system uses five special screen characters to indicate the status of certain screen messages. These
special characters appear in position three, four, or five of the lines in the message area:
• A vertical line (|) in position three indicates that required action has been taken for the message and the
system has deleted the message.

92 z/OS: MVS System Commands

 • A horizontal bar (-) in position three indicates that the message is for information only and requires no
action from you.
• An asterisk (*) in position four indicates that the message is a system message that requires action from
you.
• An at sign (@) in position four indicates that the message is a problem program message that requires
action from you.
• A plus sign (+) in position five indicates that the message is a problem program message that requires
no action from you.

Messages sent to display consoles

The MVS system and any program running under the MVS system can issue messages. A displayed
message can appear by itself or with information about the message. Each message consists of:
• An identifier, which is a three-letter prefix to identify the system component that produced the message
and a message serial number to identify the individual message. The identifier may contain other
information.
• A message text to provide information, describe an error, or request an operator action.
Messages sent to your consoles can appear in one of the following formats:

f message

or

hh.mm.ss sysname jobident f message

Fields that are always present in a message are:

f
A blank, which means that no action is required, or a special screen character. See “Special screen
characters” on page 92.
message
Message identifier and text
Fields that you might chose to add to a message are:
jobident
Job name or job id for the task that issued the message.
sysname
Name of the system that issued the message
hh.mm.ss
Time stamp, given as the hour (00-23), minute (00-59), second (00-59)
To add any combination of job identification, system name, and time stamp to all console messages, see
“Controlling the format of messages” on page 128. For more information about console messages, see
MVS System Messages.

Operations on display consoles in full-capability mode

Although some of the procedures for operating and controlling display consoles involve special functions
and conditions, most console procedures are quite general. These general procedures are described in
this topic and include:
• How to perform basic keyboard actions
• How to enter commands with the keyboard
• How to enter commands with program function keyboard

z/OS operator console operations 93

 • How to enter commands with the selector pen
• How to change information in the entry area

Performing basic keyboard actions

While the basic operating procedures are similar for all types of display consoles, the physical
characteristics of each console require you to perform certain actions (such as, the ENTER, CANCEL,
cursor detect, and selector pen detect actions) in different ways. The descriptions of operating
procedures later in this section refer to these actions.
To perform the ENTER action, press the ENTER key.
To perform the CANCEL action, on a 3278 or 3279 display console, hold down the ALT key and press the
PA2 key. On all other display consoles, press the CANCEL (PA2) key.
The cancel action:
• Erases the entry area
• Moves the cursor to the first position in the entry area
• Rewrites the message area and the instruction line
• Removes deletable-message indicators (if any are displayed)
• Removes message line numbers (if line numbers are displayed)
To perform a CURSOR DETECT action, position the cursor under the desired character and press the
ENTER key.
To perform a SELECTOR PEN DETECT action, on 3277, 3278, or 3279 display consoles, any of which has
a selector pen, place the selector pen over the desired indicator. Then, press the pen against the screen.
To retrieve the previous command, press the PA1 key.

How to enter commands

You can enter commands with the keyboard, the program function keys, or the selector pen (together with
the PFK display line).

Entering commands with the keyboard

To enter commands with the keyboard through display consoles, use the following procedures. Use the
same procedures to reply to WTOR messages:
1. Move the cursor to the first position in the entry area.
2. Type in the command.
3. Enter the command by performing the ENTER action.

Moving the cursor

Move the cursor to the first position in the entry area by one of the following methods:
• Press the cursor control keys.
• Press the tab key, the back-tab key, or the new line key.
• Press the ENTER key when the cursor is in the entry area or under the ENTER indicator in the instruction
line. Pressing the ENTER key passes any data in the entry area to the system.
• Perform a cancel action. This action might also change the display.

Typing the command

Type in the command. As you type each character, the corresponding character appears in the entry area,
and the cursor advances to the next character position. When you reach the end of the first line of a two-
line entry area, the cursor advances automatically to the first character position of the next line, so that
you can continue the command. The maximum number of characters that you can enter is 126.

94 z/OS: MVS System Commands

You have the option of entering one command or several commands. To enter more than one command,
use the MVS command delimiter. The MVS command delimiter is defined during system initialization in
the CONSOLxx parmlib member. To set the command delimiter after system initialization, use the SET
CON=xx command.
Most commands can be entered in either lowercase or uppercase. The system converts the commands to
uppercase, if required. However, information within a command that is contained within single quotation
marks (for example, a reply to a WTOR message) is not converted to uppercase by the system. If the
system requires the information within the single quotation marks in uppercase, be sure to type it in
uppercase when you enter the command. When an MVS command delimiter has been defined during
system initialization, you cannot use the defined delimiter within single quotation marks.

Entering the command

When you enter the command, the cursor must be in the entry area or under the ENTER indicator in the
instruction line, but it need not be at the end of the command. Pressing the ENTER key or selecting the
ENTER indicator causes the command to be read and processed by the system. Commands other than the
CONTROL command disappear from the entry area and reappear in the message area. If the message
area is full, the command may not appear immediately; to have it displayed, you may have to delete some
messages.
The PA1 Key: Each time you press the PA1 key, you see a command that you entered previously. The
maximum number of times you can press the PA1 key to see previous commands is specified by your
installation with the RBUF option on the CONSOLxx parmlib member. If you exceed this maximum, you
see the same commands again.

Correcting command entry errors

If you make errors entering a CONTROL command, the audible alarm sounds, and the command appears
in the entry area. The location of the cursor indicates the error:
• If the error is an invalid operand, the cursor appears under the invalid operand:

CONTROL X,N

• If the error is an invalid erase request, the cursor appears under the first invalid request.

CONTROL E,31,19

• If the CONTROL command exceeds 126 characters, the cursor appears at location 127 in the entry area.
To correct any of these errors, use the procedures described under “Changing information in the entry
area” on page 99.
If the system detects an error in a command other than a CONTROL command, it writes the command in
the message area with an error message. Follow the procedures indicated for the error message in the
MVS System Messages books.

Entering commands with program function keys

The program function keyboard is a group of keys called PFKs. They are located on or near the operator
console keyboard. PFKs are used as a shortcut for entering commands. Some PFKs have commands
defined for them at IPL. The definitions might be those in a PFK table that your system programmer
assigned to the console, or the PFKs might have the defaults assigned by IBM. You can redefine the PFK
commands; see “Defining PFKs using PFK Tables” and “Defining PFKs using the CONTROL command” on
page 132 in “Defining and changing console characteristics” on page 105.
Each PFK can be either conversational or nonconversational. The commands associated with a
conversational PFK appear in the entry area one at a time when you press the key. You can change them
before entering them. Commands associated with a nonconversational PFK are entered immediately
when you press the key.
If your system programmer does not define and activate a PFK table for your PFKs, IBM supplies the
following definitions (in nonconversational mode):

z/OS operator console operations 95

 Table 5. IBM Defaults for PFKs
PFK Command Comment Definition
1 CONTROL E,1 Erase one line from screen
2 CONTROL E Erase one segment from screen
3 CONTROL E,D Erase status display from screen
4 CONTROL D,F Frame display forward in area
5 CONTROL S,DEL=N Hold in-line output
6 CONTROL S,DEL=RD Resume in-line output
7 DISPLAY A,L List active jobs and TSO users
8 DISPLAY R,L List all outstanding operator action requests
9 and up No definition provided

Note: The IBM-supplied sample IEESPFK illustrates the sequence and syntax of the statements that can
be specified in a PFKTABxx member of SYS1.PARMLIB.

Identifying PFK definition errors

When the system tries to execute an invalid CONTROL N,PFK command, the audible alarm sounds, and
the command appears in the entry area. The location of the cursor indicates the error:
• If the cursor is positioned under the first letter of a keyword (CMD, KEY, PFK, or CON), that keyword or
its trailing equal sign is incorrect.
• If the cursor is positioned under the number of the PFK being defined, that number is either not a
numeric character or not the number of a PFK that was designated for command entry in the PFK table,
or it is the number of a PFK you are trying to associate with a list of key numbers when it is already part
of a list of key numbers.
• If the cursor is positioned under a number following the KEY operand, the key number indicated is
either a non-numeric character, the number of the PFK that is being defined, the number of a PFK that
has already been defined as a list of key numbers, or the number of a PFK that has no command
associated with it in a PFK table.
To correct these errors, follow the procedures described under “Changing information in the entry area”
on page 99.

Checking the commands defined for each PFK

Use the DISPLAY PFK command to determine the commands defined for a console's PFKs, the PFK
definitions in a specific PFK table, or the PFKs in effect for a specific console. The display can appear in
the message area or can be routed to a display area or to another console. Unless you specify another
console, the definitions always refer to the console on which you issue the command.

Table 6. Checking the Commands Defined for Each PFK

If you want to know Use this command
The names of all available PFK tables DISPLAY PFK,TABLE
The PFKs in effect at your console DISPLAY PFK
The definitions in a specific PFK table DISPLAY PFK,TABLE=nnnnnnnn, where nnnnnnnn
is the name of the table
The PFK definitions in effect for a specific console DISPLAY PFK,CN=name, where name is the
console name

96 z/OS: MVS System Commands

“Summary of the PFK Definitions for the Cluster” later in this chapter shows the complete output of the
DISPLAY PFK,TABLE=nnnnnnnn command.
Example 1:
To display the commands associated with the PFKs on the console on which you issue the command,
enter:

DISPLAY PFK

In response to this command, the following message usually appears in the message area:

IEE235I hh.mm.ss PFK DISPLAY

PFK DEFINITIONS FOR CONSOLE nnnnnnnn TABLE - MASTCMDS IN PFKTAB02
KEY# CON ------------DEFINITION-----------------------

The definitions for each key appear under the headings; nnnnnnnn identifies the console on which the
command is issued.
If no PFKs are defined for the console named CON04, the following message appears in the message area
instead:

IEE235I hh:mm:ss PFK DISPLAY

NO PFK DEFINITIONS FOR CON04

Example 2:
To determine the definitions in effect for the PFKs on CON04, enter:

DISPLAY PFK,CN=CON04

In response to this command, a message such as the following might appear in the message area:

IEE235I hh:mm:ss PFK DISPLAY

PFK DEFINITIONS FOR CON04 TABLE - MASTCMDS IN PFKTABJC

where the PFK table in effect for console CON04 is MASTCMDS in the PFKTABJC parmlib member.
The definition for each key appears under the headings. If, however, no PFKs are defined for the console,
the following message appears:

IEE235I hh:mm:ss PFK DISPLAY

NO PFK DEFINITIONS FOR CONSOLE CON04

Entering commands assigned to PFKs in conversational mode

In conversational mode, the system causes commands assigned to PFKs to appear in the entry area. You
can change and then enter them, enter them unchanged, or cancel them. The cursor appears under the
third character of the command or where designated with an underscore when the PFK was assigned a
command. You can change or complete the command by positioning the cursor under the first character
you want to change, typing in the change, and performing an ENTER action.
To enter commands in conversational mode,
1. Press the PFK associated with the command that you want to enter, causing the first command
associated with the key to appear in the entry area.
2. According to your requirements:
• Enter the command by performing an ENTER action. The next command associated with the PFK (if
any) then appears in the entry area.
• Change the command from the keyboard, then enter the command. (See “Changing information in
the entry area” on page 99.)
• Cancel the command that appears in the entry area by performing a CANCEL action. The next
command associated with the PFK (if any) then appears in the entry area.

z/OS operator console operations 97

 • Cancel the request initiated by the first press of the PFK by pressing any PFK while the command is
still in the entry area.
The result of cancelling a request in this way is shown in the following example. In the example, PFK
1 is assigned the commands START PGM1 and START PGM2.

PFK pressed Result

PFK 1 START PGM1 command is displayed
Any PFK START PGM1 command is canceled, and a blank line is displayed
PFK1 START PGM2 command is displayed

Altering a command in the entry area works only for the command entry in progress; the system retains
the original definition for future use of the PFK. To redefine a PFK, use the procedures described in
“Defining and changing console characteristics” on page 105 under “Defining Commands Using the
CONTROL Command.”

Entering commands assigned to PFKs in nonconversational mode

Press the PFK associated with the commands that you want to enter. All of the commands are entered in
the order in which they were associated with the key, just as if you had typed each command and
performed the ENTER action.
Note:
1. PFKs that are defined as conversational function in the conversational mode even though the console
is in nonconversational mode. Use these keys as if you were in conversational mode, as described
earlier under “Entering commands assigned to PFKs in conversational mode” on page 97.
2. Although the commands are entered in order, their execution may overlap. Therefore, assign
commands requiring sequential execution in conversational mode.

Responses to PFK errors

If you press a PFK that is not designated for command entry, the following message appears in the
instruction line:

IEE721I PFK nn NOT SUPPORTED

If you press a PFK that has been designated for command entry but for which no command has been
defined, the following message appears in the instruction line:

IEE722I PFK nn NOT DEFINED

Displaying the PFK numbers on 3277 model 2 consoles

You can display the PFK numbers on 3277-2 consoles and then point to them with the selector pen.
Pointing to a number has the same effect as pressing that key. To display the PFK numbers, use the
CONTROL D,PFK command. To erase the numbers in the PFK line, use the CONTROL E,PFK command.
Example:
To request a display in the PFK display line (this line is located immediately above the instruction line),
enter:

CONTROL D,PFK

In response to this command, a display similar to the following appears in the PFK display line:

1 2 3 4 5 6 7 8 9 10 11 12

98 z/OS: MVS System Commands

Only those numbers that have been designated for PFK command entry appear in the display. Once you
have requested this display, you can leave it on the screen; the PFK display line is not used for any other
purpose, even when the key numbers are not displayed. To erase the display, enter:

CONTROL E,PFK

Entering commands with the selector pen

Use the selector pen to enter commands that appear in the entry area. The commands can be in the entry
area either because you typed them there or because you pressed a PFK that is in conversational mode.
The PFK numbers available for selector pen command entry are defined in the active PFK table or are IBM
defaults.
On a 3277 model 2, the selector pen can be used with the PFK display line to enter commands. The
numbers appearing in the display line represent PFK numbers, and selecting a number with the selector
pen has the same effect as pressing a PFK.
In nonconversational mode, all of the commands associated with a PFK are entered in the order in which
they were associated with the key number. All commands (except CONTROL commands) appear in the
message area when screen space is available. No commands appear in the entry area.
To enter commands on the 3277 model 2 in nonconversational mode:
1. Display the PFK numbers in the PFK display line by entering the CONTROL D,PFK command.
2. Select the PFK number associated with the command(s) you want to enter.
3. Press the selector pen against the screen over the selected number. The command is automatically
entered.
To select commands on the 3277 model 2 in conversational mode, follow the same three steps. The
system does not automatically enter the command; rather, the first command associated with the PFK
number appears in the entry area. To enter the command, follow the steps described in the next section
"Entering Commands with the selector Pen in Conversational mode".

Entering commands with the selector pen in conversational mode

In conversational mode, each command associated with a PFK number is presented in the entry area, one
command at a time, where you can enter it as is, change it and enter it, or cancel it. Changing a command
in the entry area works only for the command entry in progress; the system retains the original definition
for that PFK.
To enter commands with the selector pen in conversational mode:
1. Enter the command by performing the ENTER action or by selecting ENTER. The next command
associated with the PFK (if any) then appears in the entry area.
2. Change the command from the keyboard before entering it as described later in this chapter under
“Changing information in the entry area” on page 99.
3. Cancel the command in the entry area by performing a CANCEL action. The next command (if any) then
appears in the entry area.
4. Cancel the request initiated by the first selection of the PFK number by pressing the selector pen
against the screen over any other PFK number while a command associated with the first key number
is still in the entry area.

Changing information in the entry area

You can change information in the entry area to correct a typing error or to change a command during
conversational command entry or message deletion. You might not need to completely retype a command
to correct or change it. (Both conversational command entry and message deletion are described in this
section.) You can blank out the entry area without entering a command to the system.
Pressing the PA1 key displays a command that you entered previously. When you see that command, you
can make corrections or changes (as described in this section) and press the Enter key to issue the
command.

z/OS operator console operations 99

 Substituting characters
If you make a mistake when typing in the entry area move the cursor to the first character you want to
change and type the correct characters.
Example:
If you type in the following reply to a WTOR message:

R 22,'DISLAY REQUESTED'_

and then note (before performing the enter action) that you have typed the word DISPLAY incorrectly, you
can move the cursor under the L, and type PL. The reply then reads:

R 22,'DISPLAY REQUESTED'

In the same example, if you decide that the correct response is NO, moving the cursor under the D in
DISPLAY and typing NO leaves the following in the entry area:

R 22,'NO'PLAY REQUESTED'

To correct this situation, move the cursor under the P and press the ERASE EOF key. This key erases the
remainder of the entry area (from the cursor to the last character position), leaving the following in the
entry area:

R 22,'NO'_

Inserting characters
To insert one or more characters within data in the entry area:
1. Position the cursor at the character position following the point where the missing data should appear.
2. Press the INS MODE key (the insert mode marker appears on the console).
3. Type in the missing data.
4. On some consoles, you must press the RESET key to return the keyboard to its normal input mode.
Example:
To insert the console identifier 10 in the following command:

DISPLAY JOBS,L=CONSC

Move the cursor back to the C, press the INS MODE key, type in 10, and press the RESET key. The
command then reads:

DISPLAY JOBS,L=CONS10C

Note that the characters to the right of the inserted characters shift to make room for the inserted
characters. If required, characters shift to the second line of the entry area.

Deleting characters
To delete a character, position the cursor at the character to be deleted and press the DEL key.
All characters that follow the deleted one shift to the left to fill the space formerly occupied by the deleted
character. Delete one character at a time.
Example:
To delete the extra S from the following command:

DISPLAY JOBS,L=CONSSOLEC

100 z/OS: MVS System Commands

 Position the cursor at either S and press the DEL key. The command then reads:

DISPLAY JOBS,L=CONSOLEC

Blanking the entry area

The ERASE INPUT key:
To remove all of the data that you have typed in the entry area without causing it to be passed to the
system, press the ERASE INPUT key. This key erases the entry area and moves the cursor to the first
position in the entry area.
Note: Do not use the ERASE INPUT key on the 3279 models 2A, 2C, and 3A. On these devices, the ERASE
INPUT key blanks out the entry areas and all fields with data displayed in red.
The PA2(CANCEL) key:
To clear the entry area and restore the screen, press the PA2 key.

Handling consoles in error conditions

Several types of errors can occur that directly affect the operation of display consoles. In some cases, the
error becomes apparent by a sudden screen failure, the appearance of error messages, or the locking of
the keyboard. In other cases, the error might not be immediately apparent. Errors can be caused by a
programming problem (system error), a console malfunction (hardware error), or a hardware error not
related to the console.

System errors
When a system error occurs, one or more of the following can happen:
• The screen is blanked out, and then an error message appears in the message area
• An error message appears in the WARNING line.
• There is an abnormal lack of console activity.

Responding to an error message in the message area

An error message at the bottom of the message area indicates that a recoverable system error has
occurred. Perform the action specified by the error message, and then perform a CANCEL action. This
should restore the screen. It is good practice to review the messages at this time to make sure that no
messages were lost during error recovery.

Responding to an error message in the WARNING line

An error message in the WARNING line might indicate that an unrecoverable system error has occurred
and that the system needs to be loaded again. If so, follow normal procedures for IPL, and notify your
system programmer.

Responding to an inactive console

An inactive console condition is characterized by a lack of message traffic or a lack of system response to
commands. The inactivity could be caused simply by a low level of system activity, or it could be the result
of a problem in the message handling portion of the control program.
If an MCS, HMCS or SMCS console appears inactive, check the system response by requesting a display of
the time:

DISPLAY T

The system should respond within a few seconds with the time and date. If it does not, perform one of the
following actions:

z/OS operator console operations 101

 • Issue the CONTROL C,D command to cancel any status displays being presented on the inactive
console.
If neither of these procedures returns the console to normal activity, assume that there is some other
problem related to the console. Check for a console hardware error. If the system must be loaded again,
follow normal procedures for IPL. Report the occurrence of this problem to your system programmer.

Console hardware errors

When a console hardware error occurs, one or more of the following can happen:
• Error messages are centered on the screen (the remainder of the screen is blank).
• The screen is blank (and no error message appears).
• The screen appears normal, but the keyboard is locked and you cannot enter commands.

Responding to error messages centered on the screen

If a console hardware error occurs, one of the following sets of messages can appear centered on the
screen:

IEE170E RETRYABLE ERROR. RECENT ACTION MAY NEED TO BE REPEATED

IEE170E PRESS THE CANCEL KEY TO RESTORE THE SCREEN
-- or --
IEE171E CONDITIONAL ERROR. RECENT ACTION MAY NEED TO BE REPEATED
IEE171E PRESS CANCEL TO CONTINUE

Perform a CANCEL action. The CANCEL action should restore most of the screen, including messages
displayed inline in the message area, the instruction line, and the warning line. The entry area and the PFK
line, however, are blanked out, any out-of-line displays are erased, and the cursor is positioned to the first
data entry position. Also, message numbering (if active) is terminated.
Note: If you do not perform a CANCEL action, the system rewrites the screen (same effect as CANCEL)
after about 30 seconds. If a console hardware error results from keyboard input when you perform the
CANCEL action, the system sees the error as a permanent I/O error.

Responding to a blank screen

If the console screen goes blank, the console has failed.
Note: It is normal for the screen of a 3277 to go blank for a few seconds if the back-tab key is pressed
when the cursor is not in the entry area.

Responding to a locked keyboard

Sometimes the system is unable to blank out the screen. If you find that you cannot enter commands
through a console that otherwise appears normal, try to restore the screen by performing a CANCEL
action.
Note: Inhibited input, with or without keyboard locking, can also occur when the system abends or goes
into a wait state, or when a problem occurs in the message handling portion of the control program. See
the procedures described for an inactive console under “System errors” on page 101.

Responding to Console Message Backups

The MVS system keeps some WTO and WTOR messages in buffers in virtual storage. The WTO buffers
hold the messages that the system has not yet displayed at the eligible consoles; the WTOR buffers each
hold one WTOR message that the system has already displayed but that an operator has not responded
to. The maximum number of WTO and WTOR buffers are determined by the MLIM and RLIM parameters
on the INIT statement in the CONSOLxx parmlib member. If these parameters are not coded, the system
defaults (as described in z/OS MVS Initialization and Tuning Reference) are in effect.
To avoid WTO message buffer shortages, you can raise your WTO buffer limit (MLIM) and adjust message
deletion specifications on your consoles. To avoid WTOR message buffer shortage, raise your WTOR buffer
limit (RLIM) and reply to WTORs more frequently. Procedures for responding to WTO and WTOR buffers
shortages follow in this section.

102 z/OS: MVS System Commands

Responding to WTO buffer shortages
When WTO message buffer use reaches 80 percent of the limit specified at IPL, the system issues the
following message:

IEA405E WTO BUFFER SHORTAGE - 80% FULL

The system also issues a DISPLAY CONSOLES,BACKLOG (D C,B) command to provide information helpful
in determining the cause of the buffer shortage.
If the problem continues and WTO buffer use reaches its limit, the system issues the following action
message:

IEA404A SEVERE WTO BUFFER SHORTAGE - 100% FULL

When storage for the WTO buffers is exhausted, the system issues the following message:

IEA652A WTO STORAGE EXHAUSTED - WTOS WILL BE DISCARDED

At this point, any new WTOs will be thrown away.

When the system notifies you that the WTO buffers are 80% full, determine the reason for the buffer
shortage and correct the problem. Possible reasons are:
• A console is not ready and WTO messages are filling the console message buffers because:
– An intervention required condition exists.
– The console has been powered off.
– Some part of the path to the device is not working; for example, an I/O interface is disabled.
– One or more consoles may have their displays held.
• A console is not in roll mode, and messages are filling the console message buffers.
• A console is in roll or wrap mode but the update time is too long, and messages are filling the console
message buffers.
• A buffer limit specified at IPL is too low to handle the message traffic in the system. (Either the value on
the MLIM parameter in the CONSOLxx member is too low, or the system default for RLIM is too low.)
• A program is issuing messages at too rapid a rate and might be in a loop. When a job uses a high
percentage of the WTO buffers, the system issues message CNZ3011I which identifies the jobname and
the address space.
To determine the extent of the problem and the responsible console or consoles, examine the output from
the DISPLAY CONSOLES,BACKLOG (D C,B) command. When messages are backed up for a console, it
might be necessary to delete the queue of messages for the console using a CONTROL Q command. You
might need to issue CONTROL Q several times to clear the console completely.
When there are too many messages from one job/address space, consider cancelling the job or jobs
specified in message CNZ3011I. If cancelling a job would cause a serious impact, look at the messages
the job is issuing. If the job seems to be in a loop, then activate an MPF member to suppress or delete the
repeating message. Another option is to temporarily remove the message's routing code from all the
consoles.
When a high number of buffers is in use for messages from another system in the sysplex, you can route a
D C,B command to the other system to determine if a job on the other system is generating too many
messages. You can protect your system from a runaway job on another system in the sysplex by using the
V CN,DMSCOPE= command.
Figure 16 on page 104 shows an example of the DISPLAY CONSOLES,BACKLOG output. The system
displays information about all consoles, on this system only, that have any outstanding WTO messages.
The output in the figure includes the following line:

MSG: CURR=1356 LIM=1500 RPLY:CURR=1 LIM=10 SYS=1 PFK=NONE

z/OS operator console operations 103

 In this line, MSG: CURR=1356 LIM=1500 tells you the current use of WTO buffers and the specified
limit. RPLY: CURR=1 LIM=1500 tells you the number of WTOR messages that have been displayed and
are awaiting operator reply, and the specified limit. The line confirms that more than 80% of the specified
WTO buffer limit is reached; 1356 WTO buffers are full and the specified limit is 1500. The display in
Figure 16 on page 104 indicates, through NBUF, the number of buffers queued to each console. In this
example, DAVE, with 1217 message buffers filled, is the source of the problem. The buffer limit of 1500
seems adequate, so DAVE is probably failing and causing undisplayed messages to fill the message
buffers.

CNZ4100I 17.08.05 CONSOLE DISPLAY FRAME 1 F E SYS=SY1

CONSOLES MATCHING COMMAND: D C,BACKLOG
MSG:CURR=1356 LIM=1500 RPLY:CURR=1 LIM=10 SYS=SY1 PFK=NONE
DAVE TYPE=MCS STATUS=ACT-SY1
DEFINED=(SY1)
MATCHED=(N/A)
ATTRIBUTES ON SY1
AUTH=(MASTER) CMDSYS=* NBUF=1217 SUPSBY=Y
DEV=03E0 LOGON=OPTIONAL USERID=N/A TIMEOUT=10
MFORM=(S) AREA=(Z,A) PFKTAB=01
USE=FC DEL=RD RTME=1/4 RNUM=25 SEG=19 CON=N
LEVEL=(ALL)
MONITOR=(NONE) INTIDS=N UNKNIDS=N
ROUT=(ALL)
MSCOPE=(*ALL)
ADDRESS SPACE WTO BUFFER USAGE
ASID - 0019 JOBNAME = FLOODNUM NBUF = 520
MESSAGES COMING FROM OTHER SYSTEMS - WTO BUFFER USAGE
SYSTEM = 2 NBUF= 4

Figure 16. DISPLAY CONSOLES,BACKLOG command output

If the buffer limit is not adequate, issue the CONTROL M,MLIM= command to increase the WTO buffer
limit for the duration of the IPL. Your system programmer might code the MLIM parameter on the INIT
statement in the CONSOLxx member to raise the WTO buffer limit for the next IPL.
When the number of buffers in use drops below 60% of the limit specified at IPL time, the system issues
the following message:

IEA406I WTO BUFFER SHORTAGE RELIEVED

Note:
1. All lines of an out-of-line multi-line status display that have not been presented occupy message
buffers. Therefore, you should erase these displays when they are no longer needed.
2. The current buffer count can be larger than the specified limit. Even though the buffer count is greater
than or equal to the limit, the system always gives a privileged task a buffer unless the storage
available for buffers is exhausted.
3. The system does not use the MLIM and RLIM parameter values specified in the CONSOLxx parmlib
member until either the hardcopy medium (SYSLOG or OPERLOG) becomes active or NIP processing is
complete. After NIP processing, multiple consoles become active and buffer space becomes
important.

Responding to WTOR buffer shortages

When WTOR message buffer use reaches 80 percent of the limit specified at IPL, the system issues the
following message:

IEA230E WTOR BUFFER SHORTAGE - 80% FULL

If the problem continues and WTO buffer use reaches its limit, the system issues the following action
message:

IEA231A WTOR BUFFER SHORTAGE CRITICAL - 100% FULL

104 z/OS: MVS System Commands

 When the system notifies you that the WTOR buffers are 80% full, you should reply to the WTOR
messages that are outstanding. If any of the WTORs have rolled off the screen (console roll mode is
DEL=R), use the DISPLAY R,R command to retrieve the text of the outstanding requests.
To raise the limit of WTOR buffers for the duration of the IPL, issue the CONTROL M,RLIM command. If
WTOR buffer use often reaches 80 percent of the limit, the limit for WTOR messages specified at IPL
might be too low to handle the WTOR message traffic in the system. Your system programmer should
code the RLIM parameter on the INIT statement in the CONSOLxx member to raise the WTOR buffer limit
for the next IPL.

Processing MVS messages at the system console during system recovery

During system recovery, MVS might try to communicate with you. Your installation might have defined the
system console, or any other MCS or HMCS console as members of a console group in CNGRPxx to receive
synchronous messages. Synchronous messages are WTO or WTOR messages that can be issued during
initialization or recovery situations. The operator must respond to the WTOR messages before the system
will continue. In a sysplex, a console can display synchronous messages only if it is attached to the
system that issues the message. If your installation has not specified a console group or a console is not
active, the system issues the message to the system console.
The MVS message on the system console does not time out; the message remains on the screen until you
enter a reply. See z/OS MVS Planning: Operations for more information about consoles and console
recovery.

Placing a console in offline status

When an MCS, HMCS or SMCS console or the system log must be bypassed for any reason, you must enter
a VARY command to place the console offline. Command activity from the console is immediately
suspended. If the console is a printer, messages continue to be displayed until all waiting messages have
been issued.
The VARY command does not cause the functions of the bypassed console to be assigned to another
console.

Interchanging your consoles on a control unit

If a device has been specified as a 3270 model X to hardware configuration definition (HCD), you can
replace it with another device and redefine it through the HCD panels. For information about using HCD,
see z/OS HCD User's Guide.

Defining and changing console characteristics

When your system comes up, the definitions in certain members of SYS1.PARMLIB are in effect. After IPL,
you can use CONTROL, MONITOR, SET, and VARY commands to change the definitions; however, the
effect of the command lasts only for the duration of the IPL. To have an effect during the next IPL, the
appropriate Parmlib member used for initialization has to be updated.
This topic describes:
• “Using operator commands to change CONSOLxx statements” on page 105
• “Changing console characteristics” on page 110
• “Controlling system messages and commands” on page 125
• “Defining program function keys (PFKs)” on page 131
• “Processing hardcopy” on page 134

Using operator commands to change CONSOLxx statements

Several operator commands are available to modify the statements in the CONSOLxx parmlib member.

z/OS operator console operations 105

 The CONSOLE statement of CONSOLxx
A CONSOLE statement in the CONSOLxx parmlib member establishes the device as an MCS, HMCS or
SMCS console and defines certain console values or attributes. These values are specified by system
programmers or are IBM defaults. After IPL, operators can use certain commands to change these
attributes. z/OS MVS Planning: Operations lists the values that can be changed by operator command, the
sysplex or system scope of the values, and if these values will or will not be restored to CONSOLxx
parmlib member settings or IBM defaults, by a single system IPL or by a sysplex reinitialization.
CONSOLxx contains console definitions for the system or sysplex.

Table 7. Comparison of system commands and CONSOLE parameters in CONSOLxx

System commands CONSOLE parameters Characteristic that the parameter affects
with default value
CONTROL A AREA Size of the out-of-line display areas
CONTROL N,PFK PFKTAB PFK table
CONTROL S,CON CON(N) Conversational or nonconversational mode
CONTROL S,DEL DEL(RD) Message deletion mode
CONTROL S,MFORM MFORM(M) Format in which the messages appear
CONTROL S,RNUM RNUM(5) Number of message lines included in one
message roll
CONTROL S,RTME RTME(2) Number of seconds between message roll/
wrap
CONTROL S,SEG SEG Number of lines in the message area that can
be deleted by a CONTROL E,SEG command
CONTROL V,CMDSYS CMDSYS Systems where commands on a console can be
directed for processing
CONTROL V,LEVEL LEVEL Message levels for the console
CONTROL V,USE USE(FC) Console operating mode
MONITOR MONITOR Monitoring of certain events
MSCOPE Systems that direct messages to a console
VARY CN,AMSCOPE
VARY CN,DMSCOPE
VARY CN,MSCOPE

VARY CN,AUTOACT AUTOACT Automatic Activate group for the system

console
VARY CN,AUTH AUTH(INFO) Command groups
VARY CN,LOGON LOGON Defines the LOGON attribute
VARY CN,LU LU Defines the predefined LU for an SMCS console
only
ROUTCODE Routing codes for the console
VARY CN,ROUT
VARY CN,AROUT
VARY CN,DROUT

VARY CN,INTIDS INTIDS Whether to receive messages directed to

console ID zero

106 z/OS: MVS System Commands

Table 7. Comparison of system commands and CONSOLE parameters in CONSOLxx (continued)
System commands CONSOLE parameters Characteristic that the parameter affects
with default value
VARY CN,SUPSBY SUPSBY Supports standby mode
VARY CN,TIMEOUT TIMEOUT The system will automatically issue a LOGOFF
command for this console after the number of
minutes specified by TIMEOUT has elapsed
without any console input activity (pressing an
attention-generating key, such as Enter, PA1,
PA2, or a PFK).
VARY CN,UNKNIDS UNKNIDS Whether to receive messages directed to
unknown console IDs (such as 1-byte console
IDs)

The INIT statement in the CONSOLxx member

The INIT statement contains initialization values for the system. You code only one INIT statement in the
CONSOLxx member.
Table 8 on page 107 describes each MVS command that has a corresponding parameter on the INIT
statement in CONSOLxx, the parameter, and the characteristic that the command and parameter affect.
The value in parentheses indicates the default. All values can be changed using the SET CON= command.

Table 8. Comparison of system commands and INIT statements in CONSOLxx

System command Parameter on INIT Characteristic that the parameter
statement with default affects
value
CONTROL M,AMRF AMRF(Y) Establishes whether the action message
retention facility is to be active
CONTROL M,APPLID APPLID Sets the APPLID used by SMCS on this
system
CONTROL M,GENERIC GENERIC Sets the GENERIC used by SMCS for the
entire sysplex
CONTROL M,MLIM MLIM(1500) Limits the number of buffers for WTO
messages that the system has not yet
displayed
CONTROL M,LOGLIM LOGLIM(1000) Limits the number of buffers for
messages that the system sends to the
system log
CONTROL M,RLIM RLIM(10) Limits the number of WTOR messages
that the system has displayed but that
the operator has not replied to
CONTROL M,UEXIT UEXIT(Y) Establishes whether the installation exit
IEAVMXIT is to be active
K M,ROUTTIME ROUTTIME(30) Specifies the maximum number of
seconds that a multisystem ROUTE
command waits for a response

z/OS operator console operations 107

 Table 8. Comparison of system commands and INIT statements in CONSOLxx (continued)
System command Parameter on INIT Characteristic that the parameter
statement with default affects
value
MONITOR MONITOR Establishes how the system displays
mount and demount messages in
response to the MONITOR command
SET CNGRP CNGRP(NO) Specifies the CNGRPxx parmlib
members that the system is to use
SET MMS MMS(NO) Specifies the MMSLSTxx parmlib
member that holds the translation
tables that are available for your system
SET MPF MPF(NO) Specifies the MPFLSTxx parmlib
members that the system is to use
SET MSGFLD=xx MSGFLD Specifies the MSGFLDxx parmlib
member that the system is to use
SET PFK PFK(NONE) Specifies the PFKTABxx parmlib
member that holds the PFK tables that
are available for your consoles
TRACE CT,PARM= CTRACE(CTIOPS00) Specifies the CTnOPSxx parmlib
member that contains tracing options
for the operations services (OPS)
component

The HARDCOPY statement in the CONSOLxx member

Table 9 on page 108 describes each VARY HARDCPY command operand, the corresponding parameter in
CONSOLxx parmlib member, and the task the command and parameter performs. The value in
parentheses indicates the default. All HARDCOPY parameters can be changed using the SET CON=
command.

Table 9. Comparison of VARY HARDCPY commands and HARDCOPY statements in CONSOLxx

VARY HARDCPY command Parameters on HARDCOPY Description
parameters statement
SYSLOG or OPERLOG DEVNUM Establishes whether the hardcopy
medium is SYSLOG or OPERLOG
ROUT ROUTCODE Establishes the routing codes for
messages included in the hardcopy
message set
NOCMDS, INCMDS, STCMDS, CMDLEVEL Establishes whether the hardcopy
or CMDS message set includes operator
commands, responses, or status
displays

The HARDCOPY statement is optional; CONSOLxx contains only one statement for each system. If the
HARDCOPY default is used, the system uses the following defaults:
• The hardcopy medium is SYSLOG.

108 z/OS: MVS System Commands

• The system uses a minimum set of routing codes (1, 2, 3, 4, 7, 8, 10, and 42) to select messages for the
hardcopy message set.
• CMDLEVEL(CMDS) is used to select the level of commands included in the hardcopy message set.

The DEFAULT statement in CONSOLxx

The system programmer uses the DEFAULT statement to control certain default values for MCS, HMCS
and SMCS consoles in the configuration. DEFAULT lets the system programmer specify console attributes
that control the following for console configuration:
• Console security by specifying operator logon options
• Certain console screen functions for all consoles (ability for operators to hold moving or wrapping
messages on the screen)
• Routing for messages without routing codes or other message queuing information, and routing for
synchronous messages that bypass normal message queuing
• Determining the maximum value for operator REPLY IDs.
• Specify a group of consoles that are eligible to receive synchronous messages.
Parameters can be changed using the SET CON= command.

Displaying information about console characteristics

To learn the current characteristics of the console, use the DISPLAY CONSOLES command. The output is
message CNZ4100I, which contains information about the system’s use of consoles as well as
information about each console’s characteristics. Figure 17 on page 109 shows the output of the
command.

CNZ4100I 15.03.36 CONSOLE DISPLAY FRAME 1 F E SYS=SY1

CONSOLES MATCHING COMMAND: D C,ROUT=5
MSG:CURR=1356 LIM=1500 RPLY:CURR=1 LIM=10 SYS=1 PFK=NONE
FRED TYPE=MCS STATUS=ACT-SY2
DEFINED=(*ALL)
MATCHED=(*ALL)
ATTRIBUTES ON SY2
AUTH=(MASTER) CMDSYS=* NBUF=0 SUPSBY=N
DEV=03E0 LOGON=OPTIONAL USERID=N/A TIMEOUT=N/A
MFORM=(S) AREA=(Z,A) PFKTAB=*DEFAULT
USE=FC DEL=RD RTME=2 RNUM=05 SEG=10 CON=N
LEVEL=(ALL)
MONITOR=(JOBNAMES) INTIDS=Y UNKNIDS=Y
ROUT=(ALL)
MSCOPE=(*ALL)
WILMA TYPE=MCS STATUS=ACT-SY2
DEFINED=(*ALL)
MATCHED=(*ALL)
ATTRIBUTES ON SY2
AUTH=(MASTER) CMDSYS=* NBUF=0 SUPSBY=Y
DEV=03E1 LOGON=OPTIONAL USERID=N/A TIMEOUT=30
MFORM=(S) AREA=(Z,A) PFKTAB=*DEFAULT
USE=FC DEL=RD RTME=2 RNUM=05 SEG=10 CON=N
LEVEL=(ALL)
MONITOR=(JOBNAMES) INTIDS=Y UNKNIDS=Y
ROUT=(ALL)
MSCOPE=(*ALL)
NAME TYPE STATUS DEFINED MATCHED
BARNEY MCS INACT *ALL *ALL
BETTY MCS ACT-SY1 *ALL SY2,SY3

Figure 17. DISPLAY CONSOLES,ROUT=5 command output

In the example, the command is to display all consoles that accept messages with a routing code of 5.
FRED and WILMA are active consoles on SY2 that match the specified criteria. Their console information
is displayed in the command output. BARNEY is a console that is not active, but it does accept messages
with a routing code of 5 on all systems. Therefore, the command output only displays BARNEY’s type,
status, all systems on which it is defined, and all systems where it matched the specified criteria. BETTY is
active on SY1 and does not accept messages with a routing code of 5 on SY1, but it does accept them on

z/OS operator console operations 109

 other systems where it is not active. Therefore, the command output only displays the same summarized
information as BARNEY.
Note: To display the console information associated with BARNEY for each system where he accepts
messages with a routing code of 5, include the FULL keyword.

Changing console characteristics

You can change the characteristics of MCS, HMCS and SMCS consoles dynamically through MVS
commands.
Note that using VARY command can only change the console characteristics when the console is active.
The exceptions to this are LU and LOGON characteristics, which can be changed for inactive SMCS
consoles. See “VARY command” on page 751 for more information.

System commands grouped according to system command authority

If an MVS operator command is not RACF-protected (for example, if the RACF OPERCMDS class is not
active, or if no OPERCMDS profile covers the command), the authority to issue the MVS command is
granted based on the command group. There are five command groups:
• Informational commands (INFO)
• System control commands (SYS)
• I/O control commands (IO)
• Console control commands (CONS)
• Master level authority commands (MASTER)
If RACF is used to control who can issue commands, the RACF OPERCMDS settings override the command
group (AUTH) settings. For example, if the user has access to the correct OPERCMDS profile, a job
submitted in a class with AUTH(INFO) will issue a MODIFY command. Similarly, if the user does not have
access to the proper OPERCMDS profile, a job submitted in an AUTH(ALL) jobclass will be unable to issue
a MODIFY command.
The commands in each group are shown in Table 10 on page 111. The command groups are ordered from
the lowest to the highest JES authority level, as described in z/OS JES2 Commands or z/OS JES3
Commands.
You can enter informational commands from any full-capability console. However, to enter system
control, I/O control, or console control commands from a secondary console, that particular command
group must be assigned to that console. If you enter a command at a console where it is not authorized,
MVS rejects the command and sends an error message to the issuing console.
At a master authority console, you can enter all operator commands. Any console with AUTH(MASTER) in
the CONSOLxx parmlib member has master authority.
Using RACF, the installation can allow the operators to log on to any MCS, HMCS or SMCS console. IBM
recommends logon for SMCS. The operator’s RACF profile and group authority determines what
commands can be issued from the console. For a list of MVS commands and their profile names, see “MVS
commands, RACF access authorities, and resource names” on page 112.

110 z/OS: MVS System Commands

Table 10. Command groups used to determine command authority
Command group Command Command
INFO
CMDS DISPLAY REPLY (See Notes)
CMDS SHOW ROUTE
CONTROL (See Notes) SEND
DEVSERV STOPMN
DISPLAY (See Notes)
LOG
LOGOFF
LOGON
MONITOR

SYS (system
ACTIVATE SETAPPC
control) CANCEL SETAUTOR
CHNGDUMP SETCEE
DUMPDS SETETR
HALT (See Note “2” on page 112) SETGTZ
HOLD SETIOS
LIBRARY SETLOAD
MODE SETMF
MODIFY SETOMVS
PAGEADD SETPROG
PAGEDEL SETRRS ARCHIVELOGGING
RELEASE SETRRS CANCEL
RESET SETRRS SHUTDOWN
SET SETSMF
SETSMS
SETUNI
SLIP
START
STOP
SWITCH SMF
TRACE (with CT, ST, or STATUS)
WRITELOG

IO (I/O control)
ASSIGN VARY {NET } (See Note “2” on page
MOUNT 112)
SETHS {OFFLINE} (See Note “5” on page
SWAP 112)
UNLOAD {ONLINE } (See Note “5” on page
112)
{PATH }
{SMS }
{name or [/]devnum}

CONS (console
CONTROL (See Note “3” on page 112) VARY CN(...)[OFFLINE|ONLINE]
control) (See Note “5” on page 112)
VARY {TCPIP}
VARY {WLM}
VARY CN(...),STANDBY

MASTER (master
CMDS ABEND TRACE (with MT)
control) CMDS DUMP VARY {CN(...)[,AUTH=...]}
CMDS FORCE {CN(...)[,LOGON=...]}
CMDS REMOVE {CN(...)[,LU=...]}
CONFIG {CONSOLE[,AUTH=...]}
CONTROL (See Note “3” on page 112) {CU }
DUMP {GRS }
FORCE {HARDCPY }
IOACTION {OFFLINE,FORCE }
QUIESCE {XCF }
RESET CN
SETCON
SETGRS
SETLOGR
SETLOGRC
SETSSI
SETXCF

z/OS operator console operations 111

Table 10. Command groups used to determine command authority (continued)
Command group Command Command

Note:
1. CONS command group when message routing is specified.
2. HALT NET and VARY NET are related to the Virtual Telecommunications Access Method (VTAM®)
3. CONTROL is in the INFO command group except when
• Purging the message queues of any other full-capability MCS, HMCS or SMCS console — MASTER.
• Message routing is specified — CONS.
• Changing or displaying the status of the action message retention facility — MASTER.
• Changing or displaying the number of allowed message buffers — MASTER.
• Changing or displaying the status of WTO user exit IEAVMXIT — MASTER.
• In a sysplex, changing the maximum time to wait for aggregated command responses — MASTER.
• Increasing the number of reply IDs — MASTER.
4. An operator can reply to any message that the console is eligible to receive. Any console with master
authority can reply to any message.
5. VARY CN,OFFLINE and VARY CN,ONLINE require CONS. Without the CN keyword, VARY OFFLINE and VARY
ONLINE require IO authority.

MVS commands, RACF access authorities, and resource names

This section lists all MVS commands, the RACF access authority associated with them, the RACF resource
name for the profile and any explanatory notes:

Table 11. MVS Commands, RACF Access Authorities, and Resource Names
Command/Keyword Authority Resource-Name
ACTIVATE UPDATE MVS.ACTIVATE
CANCEL device UPDATE MVS.CANCEL.DEV.device
CANCEL jobname UPDATE MVS.CANCEL.JOB.jobname
The previous command is for a job that is not a started task.
UPDATE MVS.CANCEL.STC.mbrname.id
CANCEL jobname.id
CANCEL id

The previous command is for a started task for which an identifier is provided.
CANCEL jobname UPDATE MVS.CANCEL.STC.mbrname.jobname
The previous command is for a started task for which an identifier was not provided. mbrname is the name of
the member containing the JCL source.
CANCEL jobname UPDATE MVS.CANCEL.ATX.jobname
The previous command is for APPC transaction programs.
CANCEL U=userid UPDATE MVS.CANCEL.TSU.userid
CHNGDUMP UPDATE MVS.CHNGDUMP
CMDS DISPLAY READ MVS.CMDS.DISPLAY
CMDS DUMP CONTROL MVS.CMDS.DUMP

112 z/OS: MVS System Commands

Table 11. MVS Commands, RACF Access Authorities, and Resource Names (continued)
Command/Keyword Authority Resource-Name
CMDS FORCE CONTROL MVS.CMDS.FORCE
CMDS SHOW READ MVS.CMDS.SHOW
CMDS REMOVE CONTROL MVS.CMDS.REMOVE
CMDS ABEND CONTROL MVS.CMDS.ABEND
CONFIG CONTROL MVS.CONFIG
CONTROL A READ MVS.CONTROL.A

Note: The access authority for all CONTROL commands except CONTROL M is normally READ, but the L=name
(console name) operand can change the access level. When L=name specifies a console that is not full-
capability and is not the issuing console, the access authority is UPDATE. When L=name specifies a console
that is full-capability and is not the issuing console, the access authority is CONTROL.

CONTROL C READ MVS.CONTROL.C

Note: See the note for the CONTROL A
command for exceptions.

CONTROL D READ MVS.CONTROL.D

Note: See the note for the CONTROL A
command for exceptions.

CONTROL E READ MVS.CONTROL.E

Note: See the note for the CONTROL A
command for exceptions.

CONTROL M CONTROL MVS.CONTROL.M

CONTROL N READ MVS.CONTROL.N
Note: See the note for the CONTROL A
command for exceptions.

CONTROL Q READ MVS.CONTROL.Q

Note: See the note for the CONTROL A
command for exceptions.

CONTROL S READ MVS.CONTROL.S

Note: See the note for the CONTROL A
command for exceptions.

CONTROL V READ MVS.CONTROL.V

Note: See the note for the CONTROL A
command for exceptions.

DEVSERV READ MVS.DEVSERV

DISPLAY A READ MVS.DISPLAY.JOB
DISPLAY ALLOC,GRPLOCKS READ MVS.DISPLAY.ALLOC
DISPLAY ALLOC,OPTIONS READ MVS.DISPLAY.ALLOC
DISPLAY APPC READ MVS.DISPLAY.APPC

z/OS operator console operations 113

Table 11. MVS Commands, RACF Access Authorities, and Resource Names (continued)
Command/Keyword Authority Resource-Name
DISPLAY ASCH READ MVS.DISPLAY.ASCH
DISPLAY ASM READ MVS.DISPLAY.ASM
DISPLAY AUTOR READ MVS.DISPLAY.AUTOR
DISPLAY CEE READ MVS.DISPLAY.CEE
DISPLAY CF READ MVS.DISPLAY.CF
DISPLAY CNGRP READ MVS.DISPLAY.CNGRP
DISPLAY CONSOLES READ MVS.DISPLAY.CONSOLES
DISPLAY DIAG READ MVS.DISPLAY.DIAG
DISPLAY DLF READ MVS.DISPLAY.DLF
DISPLAY DUMP READ MVS.DISPLAY.DUMP
DISPLAY EMCS READ MVS.DISPLAY.EMCS
DISPLAY ETR READ MVS.DISPLAY.ETR
DISPLAY FXE READ MVS.DISPLAY.FXE
DISPLAY GRS READ MVS.DISPLAY.GRS
DISPLAY GTZ READ MVS.DISPLAY.GTZ
DISPLAY HIS READ MVS.DISPLAY.HIS
DISPLAY HS READ MVS.DISPLAY.HS
DISPLAY IEFOPZ READ MVS.DISPLAY.IEFOPZ
DISPLAY IOS READ MVS.DISPLAY.IOS
DISPLAY IPLINFO READ MVS.DISPLAY.IPLINFO
DISPLAY IQP READ MVS.DISPLAY.IQP
DISPLAY JOBS READ MVS.DISPLAY.JOB
DISPLAY LOGGER READ MVS.DISPLAY.LOGGER
DISPLAY LOGREC READ MVS.DISPLAY.LOGREC
DISPLAY M READ MVS.DISPLAY.M
DISPLAY MMS READ MVS.DISPLAY.MMS
DISPLAY MPF READ MVS.DISPLAY.MPF
DISPLAY MSGFLD READ MVS.DISPLAY.MSGFLD
DISPLAY NET READ MVS.DISPLAY.NET
DISPLAY OAM READ MVS.DISPLAY.OAM
DISPLAY OMVS READ MVS.DISPLAY.OMVS
DISPLAY OPDATA READ MVS.DISPLAY.OPDATA
DISPLAY PARMLIB READ MVS.DISPLAY.PARMLIB
DISPLAY PCIE READ MVS.DISPLAY.PCIE

114 z/OS: MVS System Commands

Table 11. MVS Commands, RACF Access Authorities, and Resource Names (continued)
Command/Keyword Authority Resource-Name
DISPLAY PFK READ MVS.DISPLAY.PFK
DISPLAY PPT READ MVS.DISPLAY.PPT
DISPLAY PROD READ MVS.DISPLAY.PROD
DISPLAY PROG READ MVS.DISPLAY.PROG
For DISPLAY PROG,EXIT, if resource CSVDYNEX.LIST exists in the FACILITY class, READ authorization to
CSVDYNEX.LIST is required.
DISPLAY R READ MVS.DISPLAY.R
DISPLAY RRS READ MVS.DISPLAY.RRS
DISPLAY SLIP READ MVS.DISPLAY.SLIP
DISPLAY SMF READ MVS.DISPLAY.SMF
DISPLAY SMFLIM READ MVS.DISPLAY.SMFLIM
DISPLAY SMS READ MVS.DISPLAY.SMS
DISPLAY SSI READ MVS.DISPLAY.SSI
DISPLAY SYMBOLS READ MVS.DISPLAY.SYMBOLS
DISPLAY T READ MVS.DISPLAY.TIMEDATE
DISPLAY TCPIP READ MVS.DISPLAY.TCPIP

Note: See z/OS Communications Server: IP System Administrator's Commands for more information about
DISPLAY TCPIP.

DISPLAY TRACE READ MVS.DISPLAY.TRACE

DISPLAY TS READ MVS.DISPLAY.JOB
DISPLAY U READ MVS.DISPLAY.U
DISPLAY WLM READ MVS.DISPLAY.WLM
DISPLAY XCF READ MVS.DISPLAY.XCF
DUMP CONTROL MVS.DUMP
DUMPDS UPDATE MVS.DUMPDS
FORCE device CONTROL MVS.FORCE.DEV.device
FORCE jobname CONTROL MVS.FORCE.JOB.jobname
The previous command is for a job that is not a started task.
CONTROL MVS.FORCE.STC.mbrname.id
FORCE jobname.id
FORCE id

The previous command is for a started task for which an identifier was provided.
FORCE jobname CONTROL MVS.FORCE.STC.mbrname.jobname
The previous command is for a started task for which an identifier was not provided. mbrname is the name of
the member containing the JCL source.
FORCE U=userid CONTROL MVS.FORCE.TSU.userid

z/OS operator console operations 115

Table 11. MVS Commands, RACF Access Authorities, and Resource Names (continued)
Command/Keyword Authority Resource-Name
FORCE device,ARM CONTROL MVS.FORCEARM.DEV.device
FORCE jobname,ARM CONTROL MVS.FORCEARM.JOB.jobname
The previous command is for a job that is not a started task.
FORCE [jobname.]identifier,ARM CONTROL MVS.FORCEARM.STC.mbrname.id
The previous command is for a started task for which an identifier was provided.
FORCE jobname,ARM CONTROL MVS.FORCEARM.STC.mbrname.jobname
The previous command is for a started task for which an identifier was not provided. mbrname is the name of
the member containing the JCL source.
FORCE U=userid,ARM CONTROL MVS.FORCEARM.TSU.userid
FORCE device,TCB=tcbaddr CONTROL MVS.FORCETCB.DEV.device
FORCE jobname,TCB=tcbaddr CONTROL MVS.FORCETCB.JOB.jobname
The previous command is for a job that is not a started task.
FORCE [jobname.]identifier.TCB=tcbaddr CONTROL MVS.FORCETCB.STC.mbrname.id
The previous command is for a started task for which an identifier was provided.
FORCE jobname,TCB=tcbaddr CONTROL MVS.FORCETCB.STC.mbrname.jobname
The previous command is for a started task for which an identifier was not provided. mbrname is the name of
the member containing the JCL source.
FORCE U=userid.TCB=tcbaddr CONTROL MVS.FORCETCB.TSU.userid
HALT EOD UPDATE MVS.HALT.EOD
HALT NET UPDATE MVS.HALT.NET
IOACTION CONTROL MVS.IOACTION
LIBRARY UPDATE MVS.LIBRARY
LOG READ MVS.LOG
MODE UPDATE MVS.MODE
MODIFY jobname UPDATE MVS.MODIFY.JOB.jobname
The previous command is for a job that is not a started task.
MODIFY userid UPDATE MVS.MODIFY.JOB.userid
UPDATE MVS.MODIFY.STC.mbrname.id
MODIFY jobname
MODIFY jobname.id
MODIFY id

The previous command is for a started task for which an identifier was provided.
MODIFY jobname UPDATE MVS.MODIFY.STC.mbrname.jobname

116 z/OS: MVS System Commands

Table 11. MVS Commands, RACF Access Authorities, and Resource Names (continued)
Command/Keyword Authority Resource-Name
The previous command is for a started task for which an identifier was not provided. mbrname is the name of
the member containing the JCL source.
Note: MODIFY might actually affect more than one job. For example:
• If START ABC.DEF and START ABC.GHI are issued, MODIFY ABC.* affects both jobs, and one authorization
request is issued for each.
• If the START ABC command is issued twice, two started tasks named ABC start running on the system.
MODIFY ABC affects both jobs, and one authorization request is issued for each.
Note: The target of the MODIFY command may allow or require additional authorizations. Please be sure to
examine all documentation regarding the target of the command to insure that the proper security is in place.

MONITOR READ MVS.MONITOR

MOUNT UPDATE MVS.MOUNT
PAGEADD UPDATE MVS.PAGEADD
PAGEDEL UPDATE MVS.PAGEDEL
QUIESCE CONTROL MVS.QUIESCE
REPLY READ MVS.REPLY
RESET UPDATE MVS.RESET
RESET CN CONTROL MVS.RESET.CN
ROUTE system READ MVS.ROUTE.CMD.system

Note:
1. When a system name is specified on the ROUTE command, system is the name of the system that is the
target of the command.
2. When the security profile MVS.CPF.ROUTE.CHECK is defined in the OPERCMDS class, the resource-name
MVS.ROUTE.CMD.system is used to validate access authority to using the command prefix facility (CPF) to
transport a command to a different system in the sysplex.

ROUTE *ALL READ MVS.ROUTE.CMD.ALLSYSTEMS

ROUTE *OTHER READ MVS.ROUTE.CMD.OTHERSYSTEMS
ROUTE sysgrpname READ MVS.ROUTE.CMD.sysgrpname
ROUTE (sys1,...,sysN) READ MVS.ROUTE.CMD.sys1

.
.

MVS.ROUTE.CMD.sysN
ROUTE (group1,...,groupN) READ MVS.ROUTE.CMD.group1

.
.

MVS.ROUTE.CMD.groupN
SEND READ MVS.SEND
SET APPC UPDATE MVS.SET.APPC

z/OS operator console operations 117

Table 11. MVS Commands, RACF Access Authorities, and Resource Names (continued)
Command/Keyword Authority Resource-Name
SET ASCH UPDATE MVS.SET.ASCH
SET AUTOR UPDATE MVS.SET.AUTOR
SET CEE UPDATE MVS.SET.CEE
SET CLOCK UPDATE MVS.SET.TIMEDATE
SET CNGRP UPDATE MVS.SET.CNGRP
SET CON UPDATE MVS.SET.CON
SET DAE UPDATE MVS.SET.DAE
SET DATE UPDATE MVS.SET.TIMEDATE
SET DEVSUP UPDATE MVS.SET.DEVSUP
SET FXE UPDATE MVS.SETFXE.FXE
SET GRSRNL UPDATE MVS.SET.GRSRNL
SET GTZ UPDATE MVS.SET.GTZ
SET IEFOPZ UPDATE MVS.SET.IEFOPZ
SET IOS UPDATE MVS.SET.IOS
SET IQP UPDATE MVS.SET.IQP
SET IXGCNF UPDATE MVS.SET.IXGCNF
As part of the SET command, system logger may issue a TRACE CT or a DISPLAY LOGGER command. See
Define authorization for the system logger address space in z/OS MVS Setting Up a Sysplex for additional
required SAF authority.
SET MMS UPDATE MVS.SET.MMS
SET MPF UPDATE MVS.SET.MPF
SET MSGFLD UPDATE MVS.SET.MSGFLD
SET OPT UPDATE MVS.SET.OPT
SET PFK UPDATE MVS.SET.PFK
SET PROG UPDATE MVS.SET.PROG

Note: For examples of how to define RACF profiles for SET PROG, SETPROG APF, SETPROG EXIT, SETPROG
LNKLST and SETPROG LPA, see Examples and MVS Planning Aids for Operations in z/OS MVS Planning:
Operations.

SET RESET UPDATE MVS.SET.TIMEDATE

SET SCH UPDATE MVS.SET.SCH
SET SLIP UPDATE MVS.SET.SLIP
SET SMF UPDATE MVS.SET.SMF
SET SMFLIM UPDATE MVS.SET.SMFLIM
SET SMS UPDATE MVS.SET.SMS
SETALLOC UPDATE MVS.SETALLOC.ALLOC

118 z/OS: MVS System Commands

Table 11. MVS Commands, RACF Access Authorities, and Resource Names (continued)
Command/Keyword Authority Resource-Name
SETAPPC UPDATE MVS.SETAPPC.APPC
SETAUTOR UPDATE MVS.SETAUTOR.AUTOR
SETCEE UPDATE MVS.SETCEE.CEE
SETCON DELETE UPDATE MVS.SETCON.DELETE
SETCON MONITOR (MN) CONTROL MVS.SETCON.MONITOR
SETETR UPDATE MVS.SETETR.ETR
SETFXE UPDATE MVS.SETFXE.FXE
SETGRS UPDATE MVS.SETGRS.AUTHQLVL
SETGRS CNS CONTROL MVS.SETGRS.GRS
UPDATE
SETGRS MODE=STAR MVS.SETGRS.TOLINT
ENQMAXA MVS.SETGRS.RESMIL
ENQMAXU MVS.SETGRS.MODE.STAR
CNS MVS.SETGRS.SYNCHRES
MONITOR MVS.SETGRS.GRSQ
MVS.SETGRS.ENQMAXA
MVS.SETGRS.ENQMAXU
MVS.SETGRS.CNS
MVS.SETGRS.MONITOR

SETGTZ UPDATE MVS.SETGTZ.GTZ

SETIOS UPDATE MVS.SETIOS.IOS
SETHS UPDATE MVS.SETHS
SETLOAD xx,IEASYM UPDATE MVS.SETLOAD.IEASYM
SETLOAD xx,PARMLIB UPDATE MVS.SETLOAD.LOAD
SETLOGR UPDATE MVS.SETLOGR.LOGR
As part of the SETLOGR command, system logger may issue a TRACE CT or a DISPLAY LOGGER command. See
Define authorization for the system logger address space in z/OS MVS Setting Up a Sysplex for additional
required SAF authority.
SETLOGRC CONTROL MVS.SETLOGRC.LOGRC
SETMF UPDATE MVS.SETMF.MF
SETOMVS UPDATE MVS.SETOMVS.OMVS
SETPROG UPDATE MVS.SETPROG

Note: For examples of how to define RACF profiles for SETPROG, SETPROG APF, SETPROG EXIT, SETPROG
LNKLST and SETPROG LPA, see Examples and MVS Planning Aids for Operations in z/OS MVS Planning:
Operations.

SETRRS ARCHIVELOGGING UPDATE MVS.SETRRS.ARCHIVELOGGING

SETRRS CANCEL UPDATE MVS.SETRRS.CANCEL
SETRRS SHUTDOWN UPDATE MVS.SETRRS.SHUTDOWN
SETSMF UPDATE MVS.SETSMF.SMF

z/OS operator console operations 119

Table 11. MVS Commands, RACF Access Authorities, and Resource Names (continued)
Command/Keyword Authority Resource-Name
SETSMS UPDATE MVS.SETSMS.SMS
SETSSI ACTIVATE CONTROL MVS.SETSSI.ACTIVATE.subname
SETSSI ADD CONTROL MVS.SETSSI.ADD.subname
SETSSI DEACTIVATE CONTROL MVS.SETSSI.DEACTIVATE.subname
SETSSI DELETE CONTROL MVS.SETSSI.DELETE.subname

Note: The following rules apply to the subsystem name (subname) value in the SETSSI commands:
• Lower case characters in the subsystem name will be translated to upper case in the resource-name.
• The characters *, &, or % in the subsystem name will be translated to the _ character in the resource-name.
• Embedded blanks in the subsystem name will be translated to the _ character in the resource-name.
• Trailing blanks will not be translated.
• No other characters are translated. IBM recommends defining generic profiles to match subsystem names
with characters that cannot be specified using the RACF command interface.

SETUNI UPDATE MVS.SETUNI.UNI

SETXCF UPDATE MVS.SETXCF.XCF
SLIP UPDATE MVS.SLIP

Note: When the IEASLIP.REFRESH FACILITY class profile is defined, the SLIP command issuer must have
UPDATE access to that profile to use the REFAFTER and REFBEFOR keywords.

START mbrname[.identifier] UPDATE MVS.START.STC.mbrname[.id]

The previous command is for a started task for which an identifier was provided. mbrname is the name of the
member containing the JCL source.
START mbrname,JOBNAME=jobname UPDATE MVS.START.STC.mbrname.jobname
The previous command is for a started task for which an identifier was not provided. mbrname is the name of
the member containing the JCL source.
START commands that use one or more UPDATE The resource name substitutes DDALERT for
of the following keywords: one or more of the keywords.
• DSN or DSNAME MVS.START.jobname.qualifier.DDALERT
• DISP
• PROTECT

An example of the previous MVS START command is as follows:

START jobname.qualifier,DSN=dsname.qualifier,DISP=SHR

STOP jobname UPDATE MVS.STOP.JOB.jobname

The previous command is for a job that is not a started task.
STOP userid UPDATE MVS.STOP.JOB.userid
UPDATE MVS.STOP.STC.mbrname.id
STOP jobname
STOP jobname.id
STOP id

120 z/OS: MVS System Commands

Table 11. MVS Commands, RACF Access Authorities, and Resource Names (continued)
Command/Keyword Authority Resource-Name
The previous command is for a started task for which an identifier was provided. mbrname is the name of the
member containing the JCL source.
STOP jobname UPDATE MVS.STOP.STC.mbrname.jobname
The previous command is for a started task for which an identifier was not provided. mbrname is the name of
the member containing the JCL source.
Note: STOP might actually affect more than one started task if more than one unit of work with the same name
is active at the same time. If so, there is one call to RACF for command authorization for each unit of work.

STOPMN READ MVS.STOPMN

SWAP UPDATE MVS.SWAP
SWITCH SMF UPDATE MVS.SWITCH.SMF
TRACE CT UPDATE MVS.TRACE.CT
TRACE MT CONTROL MVS.TRACE.MT
TRACE ST UPDATE MVS.TRACE.ST
TRACE STATUS UPDATE MVS.TRACE.STATUS
UNLOAD UPDATE MVS.UNLOAD
VARY CN UPDATE MVS.VARY.CN
VARY CN,ACTIVATE READ MVS.VARY.CN

Note: Issue VARY CN,ACTIVATE only from the system console.

VARY CN,AUTH UPDATE MVS.VARY.CN

CONTROL MVS.VARYAUTH.CN

Note: VARY CN,AUTH requires both profiles.

VARY CN,DEACTIVATE MVS.VARY.CN

READ
UPDATE

Note: For the VARY CN,DEACTIVATE command, READ applies only when that command is issued from the
system console; otherwise, UPDATE applies.

VARY CN,LOGON UPDATE MVS.VARY.CN

CONTROL MVS.VARYLOGON.CN

Note: VARY CN,LOGON requires both profiles.

VARY CN,LU UPDATE MVS.VARY.CN

CONTROL MVS.VARYLU.CN

Note: VARY CN,LU requires both profiles.

VARY CN,OFFLINE,FORCE CONTROL MVS.VARYFORCE.CN

VARY CN(...),STANDBY CONTROL MVS.VARYSTANDBY.CN

z/OS operator console operations 121

Table 11. MVS Commands, RACF Access Authorities, and Resource Names (continued)
Command/Keyword Authority Resource-Name
VARY CONSOLE UPDATE MVS.VARY.CONSOLE
VARY CONSOLE,AUTH UPDATE MVS.VARY.CONSOLE
CONTROL MVS.VARYAUTH.CONSOLE

Note: VARY CONSOLE,AUTH requires both profiles.

VARY CU CONTROL MVS.VARY.CU

VARY CU,FORCE CONTROL MVS.VARYFORCE.CU
VARY GRS CONTROL MVS.VARY.GRS
VARY HARDCPY CONTROL MVS.VARY.HARDCPY
VARY NET UPDATE MVS.VARY.NET
VARY OFFLINE UPDATE MVS.VARY.DEV

Note: If VARY CN,OFFLINE is specified, the rules for VARY CN apply (the system checks for UPDATE access to
MVS.VARY.CN, not MVS.VARY.DEV).

VARY OFFLINE,FORCE CONTROL MVS.VARYFORCE.DEV

VARY ONLINE UPDATE MVS.VARY.DEV

Note: If VARY CN,ONLINE is specified, the rules for VARY CN apply (the system checks for UPDATE access to
MVS.VARY.CN, not MVS.VARY.DEV).

VARY PATH UPDATE MVS.VARY.PATH

VARY SMS UPDATE MVS.VARY.SMS
VARY TCPIP UPDATE MVS.VARY.TCPIP

Note: See z/OS Communications Server: IP System Administrator's Commands for more details and information
on necessary profiles for MVS.VARY.TCPIP command.

VARY WLM CONTROL MVS.VARY.WLM

VARY XCF CONTROL MVS.VARY.XCF
WRITELOG READ MVS.WRITELOG

Changing the authorization of a console

You can change the system command groups that a console is authorized to enter.
You change the authorization of consoles by:
• Using the VARY Command:
The VARY CN,AUTH= command defines which system command groups may be entered through the
consoles specified on the AUTH= keyword.
Example:
To assign master level authority to a console named REMOTE, enter:

VARY CN(REMOTE),AUTH=MASTER

122 z/OS: MVS System Commands

 Enter this command through any console that has master authority. If you try to enter this command
from a console without master authority, the command is rejected and a message appears to indicate
that the switch did not take place.
The effect of this command lasts only for the duration of the console being active.

Defining console use

MCS consoles can operate in one of the following ways:
• Status Display Console
• Message Stream Console
• Full-capability Console
Note: In this book, the term output-only mode refers to status display mode and message stream mode.
Note: HMCS and SMCS consoles are not permitted to be status display or message stream consoles.
HMCS and SMCS consoles can only be full-capability consoles.

Using a status display console

A status display console has output capability only; it cannot be used to enter commands. The system
uses the screen to receive status displays.
A console in status display mode provides a convenient area for displaying system status information and
frees a full capacity console for use by other system messages.
You can divide the screen of the status display console into display areas, according to your needs.

Controlling displays on status display consoles

Because a status display console has no input capability, you must enter each request concerning the
console on a separate full-capability console. Use the routing location operand with each command to
designate the console and display area at which an action is to take place.
The routing location operand can be entered only from a console with CONS (console control) command
group authority. Command group authority is described under “System commands grouped according to
system command authority” on page 110.

Using a message stream console

A message stream console has output capability only; it cannot be used to enter commands. The system
uses the screen to present general messages.
A console in message stream mode provides an area for presentation of messages. The messages sent to
a message stream console depend on the routing codes or message levels assigned to that console.
Message stream consoles can provide system monitoring capabilities in tape or disk libraries, or can
assist in system security.
Deleting messages from message stream consoles: When a console enters message stream mode, roll-
deletable message deletion goes into effect automatically. (See “Defining Automatic Message Deletion”
later in this section.) All messages except action messages are automatically removed from the screen.

Using a full-capability console

A full-capability console has both input and output capability; the console can be used both to enter
commands and to receive status displays and messages. There can be many full-capability consoles in
the system or sysplex.
You can divide the screen on a full-capability console so that part of the screen receives general
messages and the other part receives status displays. When a status display is not on the screen, MCS
uses the status display area for general messages.
Changing full-capability to message stream or status display mode: The screens of the message
stream console and the status display console appear identical; they do not have any entry area. However,

z/OS operator console operations 123

 the screens of the consoles in message stream mode receive general messages and the screens of the
status display consoles receive formatted status displays.
When you change a full-capability console to message stream or status display mode, the PFK display
line, the instruction line, and the entry area are incorporated into the message area or the display area.
Figure 18 on page 124 shows the 3277 model 2, in message stream mode. Once a display console enters
message stream or status display mode, it can accept no more input; you must use another console to
enter commands. Examples at the end of this topic illustrate how the display on a full-capability console
changes to the display on a status display or message stream console.

Figure 18. Format of a console screen in message stream mode

The system gives you the following choices for operating mode for MCS consoles:
FC
Full-capability
MS
Message stream
SD
Status display
HMCS and SMCS consoles can only be FC (full-capability) mode consoles. The operating mode of an
HMCS or SMCS console cannot be changed.
If a console is an input/output device, the default operating mode is full-capability mode.
You can check the console operating mode by entering the CONTROL V,REF command. In response to this
command, the specifications appear in the entry area. You can change the specifications using the
procedures described under “Changing information in the entry area” on page 99.
You define the operating mode of a console by:
• Using the CONTROL Command:
Use the USE operand on the CONTROL V command to change the operating mode of a console.
Example 1:
To specify the console, with a console name of CON8, as a full-capability console, enter:

CONTROL V,USE=FC,L=CON8

The effect of this command lasts only for the duration of the console being active.

124 z/OS: MVS System Commands

 Note: When you use the CONTROL command to change the console operating mode, you might also have
to change other console characteristics. If the new definition for the console operating mode is
incompatible with other characteristics, the system rejects the CONTROL command.
Example 2:
To change the console in Example 1 from full-capability mode to status display mode, enter:

CONTROL V,USE=SD,L=CON8

In response to this command, any information on the screen disappears, and the system reestablishes
the display area specifications that were defined in the CONSOLxx parmlib member. If you were changing
the console from full-capability mode to message stream mode, information on the screen would
disappear and the message area would expand, as in Figure 18 on page 124.
Example 3:
To return CON8 to full-capability mode, enter the following command from a full-capability console:

CONTROL V,USE=FC,L=CON8

In response to this command, the message area of the console with a console name of CON8 returns to
its full-capability size, and the console specifications return to those established the last time the console
was in full-capability mode for this IPL or those established in the CONSOLxx member.
The display area specifications also return to the specifications established the last time the console was
in full-capability mode.

Controlling system messages and commands

Messages are the system’s chief means of communication with you. Messages range from informational,
which are important but do not require a response, to immediate action, which are not only important but
require that you perform the requested action at once. The action might be required because the message
issuer waits until the action is performed, or because taking the action as soon as possible can improve
system performance. Less urgent, but still important, are the eventual action and critical eventual
action messages. The message issuer is not waiting for you to perform the action, but a number of
unanswered requests might degrade system performance.
The size of the screen’s message area varies, depending on the type of display console. When the
message area becomes full, you need to delete messages to make room for new ones. You can delete
messages, or have the system do it for you automatically. (See “Deleting Messages from the Console
Screen” later in this chapter.) Once an action message is deleted from the screen, you cannot see the
entire message again unless the action message retention facility is active and you have issued a DISPLAY
R command.
So that you do not have to delete messages too often, make sure that you manage message traffic
carefully on all consoles. For example, if you find that a console screen often fills with action messages,
think about:
• Adjusting routing codes and assigning message levels. Any console should receive only messages for
which the operator of that console is directly responsible.
• Activating the action message retention facility so you can put the console in roll mode without losing
action messages.

Defining routing codes for a console

Most messages have one or more routing codes. The system uses these codes, decimal numbers from 1
to 128, to determine which console or consoles should receive a message. The system programmer
assigns routing codes to the consoles attached to your system so that a specific message type is routed to
the proper console. Table 12 on page 126 lists the routing codes.
Routing codes do not appear with a message at a console; routing codes 1 through 28 do, however,
appear on the system log. To determine the routing codes each console receives, use the DISPLAY

z/OS operator console operations 125

 CONSOLES,A command. Figure 17 on page 109 shows the display that appears in response to this
command.

Table 12. Message Routing Codes

Code Definition
1 Primary operator action
2 Primary operator information
3 Tape pool
4 Direct access pool
5 Tape library
6 Disk library
7 Unit record pool
8 Teleprocessing control
9 System security
10 System error/maintenance/system programmer information
11 Programmer information
12 Emulators
13-20 Reserved for customer use
21-28 Reserved for subsystem use
29 Disaster Recovery
30-40 Reserved for IBM
41 Information about JES3 job status
42 General information about JES2 or JES3
43-64 Reserved for JES2 or JES3
65-96 Messages associated with particular processors
97-128 Messages associated with particular devices

One way to limit the messages that arrive at a console is to assign a routing code or codes to a console.
The console then receives only the messages that are appropriate.
To learn what the routing codes for a console are, enter the DISPLAY CONSOLES command. Figure 17 on
page 109 shows the display that appears in response to this command.
You define routing codes for a console by:
• Using the VARY command:
Use operands on the VARY command to add to the existing set (AROUT operand), subtract from the
existing set (DROUT), or redefine the set (ROUT).
Example:
To assign the routing codes 1, 2, 9, and 10 for a console named CON81D, enter:

VARY CN(CON81D),ROUT=(1,2,9,10)

The effect of this command lasts only for the duration of the console being active.

126 z/OS: MVS System Commands

Defining message levels for a console
Assigning routing codes is one way to limit message traffic to a console. You can further reduce the
number of messages that appear on a console by directing certain messages to consoles by message
levels. The system differentiates among these kinds of message levels:
• Write-to-operator with reply (WTOR) messages, which demand an immediate reply.
• System failure and immediate action messages (descriptor codes 1 and 2), which indicate that a task is
awaiting your action.
• Critical eventual action messages (descriptor code 11), which indicate a potential system problem.
• Eventual action messages (descriptor code 3), which do not require immediate attention.
• Broadcast messages, which are normally sent to every active console regardless of the routing code you
assigned to the console.
• Informational messages, which generally indicate system status. (Most messages are informational.)
Assignment by message level means that a console can accept combinations of action, broadcast, and
informational messages that the system sends to a console. You can choose among the following
message level options:
R
Write to operator (WTOR) messages are to appear
I
Immediate action messages (descriptor codes 1 and 2) are to appear
CE
Critical eventual action messages (descriptor code 11) are to appear
E
Eventual action messages (descriptor code 3) are to appear
IN
Informational messages are to appear
NB
Broadcast messages are not to appear
ALL
All messages, including broadcast messages, are to appear.
If the LEVEL parameter in the CONSOLxx member is not coded, the system sends all messages, including
broadcast messages, to the console.
To display the routing codes and message levels for a console, issue the DISPLAY CONSOLES command.
Figure 17 on page 109 shows the display that appears in response to this command.
To display the routing codes and message levels that appear only on the system log and not on any
console, issue the DISPLAY CONSOLES,HC command.
You define the level of messages for a console by:
• Using the CONTROL Command:
Use the LEVEL operand on the CONTROL V command to assign message levels to a console.
Example 1:
To direct only WTOR messages and immediate action messages to the console with console name
CON06, enter:

CONTROL V,LEVEL=(R,I),L=CON06

Example 2:

z/OS operator console operations 127

 To assign to the console with console name CON12 (and device number 81D) the informational
messages directed to the tape libraries (routing code 5) and disk libraries (routing code 6), enter:

VARY 81D,CONSOLE,ROUT=(5,6)
CONTROL V,LEVEL=IN,L=CON12

Controlling the format of messages

On a display console, a message can appear by itself or with information about the message, such as job
and system identification and the time the message was issued. “Messages sent to display consoles” on
page 93 describes the format of messages and describes the optional information that the system can
include with each message:
J
The jobname/job id of its issuer
S
The name of the system that issued the message
T
A time stamp
M
Only the message text displays
X
Suppress system and job name of its issuer when S and/or J are specified
You request that additional information precede each message the system sends a console by:
• Using the CONTROL command:
Use the MFORM operand on the CONTROL S command to change the format of messages.
Example:
To request that the system add to all messages that appear at console CON2 a time stamp, the name of
the system that issued the message, and the jobname or ID of its issuer, enter:

CONTROL S,MFORM=(J,T,S),L=CON2

The effect of this command lasts only for the duration of the console being active.

Controlling the message processing facility (MPF)

The message processing facility (MPF) controls message processing. It controls the suppression and
retention of messages, the installation exits that gain control when certain messages and commands are
issued, and message presentation (that is, the color, intensity and highlighting of messages) at certain
consoles. It also controls the foreign messages and DOMs that are seen by subsystems and whether
verbose messages are to be produced.
The operator can:
• See what MPF member or members are active with the DISPLAY command
• Change the active MPF member or members with the SET command.
For MPF to suppress messages, hardcopy processing must be active. The suppressed messages do not
appear on any console; they do appear on the hardcopy log, and any extended MCS consoles that are
receiving the hardcopy message set.
Message presentation:
Message presentation refers to the way the system uses color, intensity, and highlighting (including
blinking, reverse-video, and underscoring) to identify messages that require action. The presentation
depends on the type of device you are using.

128 z/OS: MVS System Commands

Using the SET command:
Enter the SET MPF command to change the MPFLSTxx member or members that the system is to use.
Example:
To specify MPFLST03 and MPFLST06 as the MPF members for the system to use, enter:

SET MPF=(03,06)

The effect of this command lasts only for the duration of the IPL.

Displaying information about messages awaiting action

Many systems now handle so much work so quickly that you cannot always keep up with the messages
that demand operator response. These messages roll off the screen before you can respond. The action
message retention facility keeps these messages, including the WTORs and JES3 messages, so that you
can see them at a later time. (While you are examining the messages that you missed, you might, of
course, miss more messages. Experience with your system will help you determine how frequently you
need to check for retained action messages.)
The DISPLAY R command allows you to display all outstanding action messages or a subset of these
messages. For example, to display all outstanding action messages at your console, enter DISPLAY R,M.
To display all the outstanding critical eventual-action messages (descriptor code 11), enter DISPLAY R,CE.
See z/OS MVS Planning: Operations for use of the DISPLAY R command.

Controlling the action message retention facility

During its initialization, the system can start the action message retention facility (AMRF). When active,
the facility retains in a buffer area all action messages (those messages with descriptor codes 1, 2, 3, and
11) except those specified by the installation in the active MPFLSTxx member.
If the first system IPLs and AMRF is active, then AMRF is active on every system that you subsequently
IPL into the sysplex.
When you have performed the action required by a message displayed on the screen, the system deletes
the message; or you can use the CONTROL C command to delete the message. You can remove action
messages from the screen that require later action, then retrieve them in their entirety later by using the
DISPLAY R command. Periodically, you should display the retained messages and delete the ones for
which action has been taken so that the action message retention buffer does not fill up.
To change the messages that the action message retention facility is to retain, activate an MPFLSTxx
member that contains the message retention options you want. The system default is to have the action
message retention facility on.
To learn the status of the action message retention facility, issue the CONTROL M,REF command.
You change the status of the action message retention facility by:
• Using the CONTROL command
Use the CONTROL M,AMRF command to turn the action message retention facility on or off.
Example:
To deactivate the action message retention facility, enter:

CONTROL M,AMRF=N

Controlling message flood automation

Message flood automation detects and handles message floods caused by device or software failures. It
uses policy created by the installation to decide when a message flooding situation is happening and what
actions to take.
The operator can:

z/OS operator console operations 129

 • Change the active MSGFLDxx parmlib member with the SET command
• See the status of Message Flood Automation and the MSGFLDxx member that is active with the
DISPLAY command
• Turn Message Flood Automation on and off and alter the active Message Flood Automation policy with
the SETMF command
Using the SET command: Enter the SET MSGFLD command to change the MSGFLDxx member that the
system is to use.
Example:
To specify MSGFLD03 as the Message Flood Automation member for the system to use, enter:

SET MSGFLD=03

The effect of this command lasts only for the duration of the IPL.
Using the DISPLAY command: Enter the DISPLAY MSGFLD command to obtain information about
Message Flood Automation.
Example:
To determine the status of Message Flood Automation, enter:

DISPLAY MSGFLD,STATUS

Using the SETMF command: Enter the SETMF command to alter the state or policy of Message Flood
Automation.
Example:
To enable Message Flood Automation processing, enter:

SETMF ON

Activating WTO and WTOR installation exit routines

The system programmer at your installation codes installation exit routines that gain control when the
system issues certain messages. A WTO installation exit can change routing codes, descriptor codes, and
message texts, as well as perform other message processing; it can override MPF processing. Information
about coding these installation exits appears in z/OS MVS Installation Exits.
The most effective message control involves coding and installing the installation exit IEAVMXIT, which
can gain control when any WTO or WTOR message is issued.
To learn whether IEAVMXIT is active or not, issue the CONTROL M,REF command. The system displays (in
the entry area) the status of the action message retention facility, the status of installation exit IEAVMXIT,
and the limit of the number of WTO and WTOR buffers.
Your installation might have other exit routines to process messages. MPFLSTxx parmlib members contain
the IDs of messages and the installation exits that process these messages. To activate processing by
these installation exits, see “Controlling the message processing facility (MPF)” on page 128.
You can activate the installation exit IEAVMXIT, if it is installed, by:
• Using the CONTROL command:
Use the UEXIT operand on the CONTROL command to control whether the installation exit IEAVMXIT is
active.
Example:
To deactivate IEAVMXIT, enter:

CONTROL M,UEXIT=N

The effect of the command lasts only for the duration of the IPL.

130 z/OS: MVS System Commands

 Checking message processing, retention, and presentation options
Issue the DISPLAY MPF,MSG command to view the following information:
• Which messages are being suppressed by MPF
• Which action messages are not being retained by the action message retention facility
• Which installation exits receive control for selected messages
• The status of the general WTO installation exit IEAVMXIT
• Whether this message is automated by MPF
• The MPFLSTxx member that identifies the message ID, color attribute, or command installation exit
definition
• A list of the subsystems receiving foreign messages and DOMs
• Whether verbose messages are to be produced or not.
Issue the DISPLAY MPF,COLOR command to view the following information:
• What color, intensity, and highlighting capabilities are in effect.
Issue the DISPLAY MPF command to see all of this information for the messages that are defined in the
MPFLSTxx parmlib member.

Defining program function keys (PFKs)

You can define program function keys for a console by activating a PFK table or by using the CONTROL
N,PFK= command.

Defining PFKs using PFK tables

You define a console’s PFKs by activating a PFK table — a table that your installation has defined. The PFK
table resides, optionally with other PFK tables, in a PFKTABxx parmlib member. The entries in this table:
• Assign one or more commands to a PFK
The text of one or more commands are to be associated with a PFK. Later, when you press this PFK, the
commands are entered into the system.
• Assign one or more other PFKs to a PFK
The commands associated with other PFKs are to be associated with one PFK.
Entries in the PFK table also determine whether conversational or nonconversational mode is to be in
effect for a command defined to a PFK. In nonconversational mode, the commands associated with a key
are entered immediately when you press the key. In conversational mode, pressing a PFK causes the
command to appear in the entry area, but no enter action takes place. You can change, enter, or cancel
the command according to your requirements.
In conversational mode, the cursor normally appears under the third non-blank character when the
command is in the entry area. If you want the cursor to appear in a different location, when you define the
command, type an underscore before the character under which the cursor is to appear. The system
deletes the space occupied by the underscore in the actual command. For example, if you add the
following entry to a PFK table:

PFK(5) CMD('D U,L=_XXX') CON(Y)

pressing PFK 5 causes the following to appear in the entry area:

D U,L=XXX

If you want an underscore to appear in the command, code two consecutive underscores. The system will
treat them as a single underscore, and will not use them for cursor placement. Example:

z/OS operator console operations 131

 If the PRKTAB table contains:

PFK(17) CMD('E _XXXXXXXX,SRVCLASS=BAT__HI'),CON(Y)

when you press PFK17, the entry area will contain:

E XXXXXXXX,SRVCLASS=BAT_HI

with the cursor under the first X.

Selector pens also use the definitions in PFK tables.
You can use some MVS commands to display information about the PFKs at your console, or to change the
PFKs that are available for your consoles. The following commands relate to the previous example:
• Display the PFK definitions in the PFK table named MVSCMDS.
DISPLAY PFK,TABLE=MVSCMDS
• List the names of all PFK tables in the active PFKTABxx member.
DISPLAY PFK,TABLE
• Assign the commands in the PFK table named JES2CMDS to the PFKs on your console.
CONTROL N,PFK=JES2CMDS
• Activate another PFKTABxx member, in this case PFKTAB02.
SET PFK=02
This command assumes that you have a PFK table in PFKTAB02 and that you want to replace MVSCMDS
with another PFK table. (Other consoles might be using tables in the former PFKTABxx member. PFK
definitions for these consoles are not affected by the action of this SET command.)

Defining PFKs using the CONTROL command

Use the CONTROL N,PFK= command to change the definition for PFKs. This command performs three
tasks:
• Assigns one or more commands to a PFK
• Assigns one or more other PFKs to a PFK
• Assigns a PFK table to your console.
With the CONTROL N,PFK= command you can also determine whether conversational or
nonconversational mode is to be in effect for the commands defined to the PFK. Nonconversational mode
is the default. For example, if you define PFK 5 as follows:

CONTROL N,PFK=(5,CMD='D U,L=CON9A'),CON=N

pressing PFK 5 has the same effect as typing DISPLAY U,L=CON9A and pressing the ENTER key.
On the other hand, if you specify conversational mode by entering:

CONTROL N,PFK=(5,CMD='D U,L=CON9A'),CON=Y

pressing PFK 5 causes the command D U,L=CON9A to appear in the entry area but no enter action takes
place. You can change, enter, or cancel the command according to your requirements.
The system does not accept PFK assignments that may result in an endless loop. Examples of commands
that the system will not accept are:
• You cannot assign a PFK to itself. For example, the system does not accept CONTROL N,PFK=(9,KEY=9).
• If a PFK is being assigned a list of PFKs (that is, a key list), that PFK cannot appear in the key list for
another PFK. For example, if PFK 5 is already associated with keys 3 and 4, the system does not accept
CONTROL N,PFK=(6,KEY=5,8).

132 z/OS: MVS System Commands

• If a PFK is already in a key list, you cannot assign a key list to that PFK. For example, if key 4 is
associated with keys 5 and 6, the system does not accept CONTROL N,PFK=(5,KEY=7,8).
Remember that the assignment of the command to the PFK through the CONTROL command lasts only for
the duration of the IPL.
Example 1:
If PFK 3 is associated with commands SET OPT=PM and SEND 14,BRDCST, and PFK 4 is associated with
the command START GTF,MODE=INT,BUF=387,TIME=YES,DEBUG=YES, you can associate all three of
these commands with PFK 5 by entering:

CONTROL N,PFK=(5,KEY=3,4),CON=Y

The commands associated with PFK 5 are now:

SET OPT=PM
SEND 14,BRDCST
START GTF,MODE=INT,BUF=387,TIME=YES,DEBUG=YES

The system schedules the commands in that order, but might not execute them in that order.
Example 2:
To remove a definition previously set for PFK 5, leaving PFK 5 undefined, enter:

CONTROL N,PFK=(5,CMD='')

The PFKTABxx and PFKs

The PFKTABxx parmlib members contain the PFK tables that have the definitions your installation has
assigned to PFKs. To associate your console’s PFKs with the definitions in a particular PFK table:
• The PFK parameter on the INIT statement in the active CONSOLxx member must identify the PFKTABxx
member that contains the table.
• The PFKTAB parameter on the CONSOLE statement in CONSOLxx must identify the name of the PFK
table.
• The particular table must contain entries; each entry supplies a command or commands associated
with a PFK.

You use CONSOLxx and PFKTABxx members to set the PFK definitions at IPL. You can also change the
PFK definitions for the duration of the IPL:
To change a PFK table:
1. Enter SET PFK=xx, if necessary, to change the PFKTABxx member in effect for the console. Other
consoles using the former PFKTABxx member are not affected by the SET command you issue for your
console.
2. Enter CONTROL N,PFK=nnnnnnnn to assign the PFK table that contains the PFK definitions you want to
use for the console.
To change a PFK key:
• Enter CONTROL N,PFK=(nn1,CMD=‘...’) to change a specific PFK key definition for the console where the
command is entered.
During IPL, the system looks for the PFK parameter in CONSOLxx member. If the system does not find the
PFK parameter, it issues the message:

IEA180I USING IBM DEFAULT DEFINITIONS. NO PFK TABLES REQUESTED

In this case, PFKs 1 through 8 have the defaults that IBM supplies. These defaults are shipped in sample
IEESPFK.

z/OS operator console operations 133

 To define PFKs for your consoles, see “Defining PFKs using PFK tables” on page 131.

Processing hardcopy
Logging provides a permanent record of system activity. Your installation can record system messages
and, optionally, commands and command responses, by using the system log (SYSLOG), the operations
log (OPERLOG), or both. Your installation can also allow an extended MCS console to receive the same set
of messages as SYSLOG and OPERLOG. The log that receives messages is called the hardcopy medium.
The group of messages that is recorded is called the hardcopy message set.
The hardcopy message set is defined at system initialization and persists for the life of the system. See
z/OS MVS Planning: Operations for the characteristics of the hardcopy message set.

The hardcopy message set

Unless you specify otherwise, the hardcopy message set includes all messages, except those that are
explicitly omitted through the WTO macro or installation exits. You can request that the hardcopy
message set not include messages with certain routing codes. The minimum set of routing codes is 1, 2,
3, 4, 7, 8, 10, and 42. If you attempt to eliminate any of these, the system includes messages with these
routing codes in the hardcopy message set anyway.
To see information about the kinds of messages that the system includes in the hardcopy message set,
but does not send to any console, issue the DISPLAY CONSOLES,HC command.

Selecting messages for the hardcopy message set

You control which messages are included in the hardcopy message set by:
• Using the VARY command:
Use the VARY ,HARDCPY command to specify the routing codes of messages that are included in the
hardcopy message set. You can add to the existing set (AROUT operand), subtract from the existing set
(DROUT), or redefine the set (ROUT).
Example:
To stop including all routing codes except the minimum set, enter:

VARY ,HARDCPY,DROUT=(5,6,9,11-41,43-128)

The system would give the same response if you entered the VARY ,HARDCPY,ROUT=NONE command.
The effect of this command lasts only for the duration of the IPL.

Selecting commands and command responses for the hardcopy message set
Unless you specify otherwise, the system includes all operator and system commands, responses, and
status displays in the hardcopy message set. To request that some commands and command responses
not be included in the hardcopy message set, the system gives you the following choices on the
VARY ,HARDCPY command:
NOCMDS
The system does not include operator commands or their responses in the hardcopy message set.
INCMDS
The system includes all operator commands and their responses, excluding any status displays, in the
hardcopy message set.
STCMDS or CMDS
The system includes all operator and system commands, their responses, and status displays in the
hardcopy message set. As of z/OS V1R8, STCMDS and CMDS are equivalent.
To see which commands and command responses the system includes in the hardcopy message set,
issue the DISPLAY CONSOLES command. Figure 17 on page 109 shows the display that appears in
response to this command.
Note:

134 z/OS: MVS System Commands

You control which commands and command responses are included in the hardcopy message set by:
• Using the VARY command:
Use the VARY ,HARDCPY command to change the commands or the command responses that are
included in the hardcopy message set.
Example:
To request that the hardcopy message set include all operator commands and responses except status
displays, enter:

VARY ,HARDCPY,INCMDS

The effect of this command lasts only for the duration of the IPL.

The hardcopy medium

You can specify whether the hardcopy medium is the system log (SYSLOG) or the operations log
(OPERLOG). If you use SYSLOG as the hardcopy medium, start a writer that includes the system log
message class (A for MVS, unless otherwise specified in your installation). The SYSLOG spool file is
managed by JES and can be viewed using the spool display and search facility (SDSF). The external writer
will write it to an SMF-managed file.

The system log

The system log (SYSLOG) is a direct access data set that stores messages and commands. It resides in the
primary job entry subsystem’s spool space. It can be used by application and system programmers
(through the WTL macro) to record communications about programs and system functions. You can use
the LOG command to add an entry to the system log.
Several kinds of information can appear in the system log:
• Job time, step time, and data from the JOB and EXEC statements of completed jobs entered by user-
written routines
• Operating data entered by programs using a write to log (WTL) macro instruction
• Descriptions of unusual events that you enter using the LOG command
• The hardcopy message set
When MVS has JES3 as its job entry subsystem, the system log can record console activity. If used to
record console activity, the system log is referred to in JES3 messages as DLOG.
In CONSOLxx, you can use the HCFORMAT keyword on the HARDCOPY statement to specify whether
hardcopy records should have a 2-digit or 4-digit year.
The system log is queued for printing when the number of messages recorded reaches a threshold
specified at system initialization. You can force the system log data set to be queued for printing before
the threshold is reached by issuing the WRITELOG command.
If the system log is defined as the only hardcopy medium and SYSLOG fails, hardcopy is suspended and
the system issues message CNZ4201E. To avoid the loss of hardcopy, IBM recommends both SYSLOG and
OPERLOG be defined as hardcopy.

The operations log

The operations log (OPERLOG) is an MVS system logger application that records and merges the hardcopy
message set from each system in a sysplex that activates OPERLOG. Use OPERLOG as your hardcopy
medium when you need a permanent log about operating conditions and maintenance for all systems in a
sysplex.
For more information on OPERLOG, see z/OS MVS Setting Up a Sysplex.

Assigning the hardcopy medium

Assign the hardcopy medium by using the VARY command.

z/OS operator console operations 135

 Use the HARDCPY operand on the VARY command to assign SYSLOG or OPERLOG as the hardcopy
medium. You can assign both SYSLOG and OPERLOG as the hardcopy medium by issuing the command
separately.
Example:
To specify the hardcopy medium as SYSLOG, issue:

VARY SYSLOG,HARDCPY

The effect of this command lasts only for the duration of the IPL.
To display information about the hardcopy medium, enter:

DISPLAY CONSOLES,HARDCOPY

The resulting display tells you the following information:

• Whether the hardcopy medium is SYSLOG, OPERLOG, or both
• The criteria that have been defined by the installation for selecting messages for the hardcopy message
set
• The number of messages waiting to be placed on the hardcopy medium

136 z/OS: MVS System Commands

Chapter 4. MVS system commands reference

This topic describes the functions, syntax, and parameters of all the MVS base control program (BCP)
system commands. You can use these commands to control both the system itself and multiple console
support (MCS), HMC multiple console support (HMCS) or SNA multiple console support (SMCS) consoles.
Table 13 on page 138 summarizes the MVS BCP system commands and their functions. The table shows
the operator command groups for each command and tells whether you can enter the command from the
job stream, an MCS, HMCS or SMCS console, or an extended MCS console session. An extended MCS
console session is established either by the TSO/E CONSOLE command as an interactive TSO/E session or
by a program issuing the MCSOPER macro so the program can receive messages and issue commands.
See z/OS TSO/E System Programming Command Reference for information about the TSO/E CONSOLE
command. See z/OS MVS Programming: Authorized Assembler Services Reference LLA-SDU for information
about the MCSOPER macro.
An installation can use RACF to control which consoles and commands operators can use. For more
information, see z/OS MVS Planning: Operations.
Operator commands may contain the following characters:
• A to Z
• 0 to 9
• '#$&()*+,-./¢<|!;¬%_>?:@"=
The system translates characters that are not valid into null characters (X'00').
You can enter operator commands in uppercase or lowercase. Unless enclosed in apostrophes, lowercase
letters are converted to uppercase. Therefore, when a lowercase response is required, you must enclose
the text in apostrophes. Also, when an apostrophe appears in the text of a command and the text is
enclosed in apostrophes, you must enter two apostrophes in the text. For example, you would enter:

SEND 'Your job''s done'

You can enter system commands through a multiple console support (MCS) console, HMC multiple
console support (HMCS) console, SNA multiple console support (SMCS) console, extended MCS (EMCS)
console or through the input stream (submitted JCL). Table 13 on page 138 indicates from which types of
consoles a command is accepted. Superscripts denote footnotes that can be found at the end of the table.
All examples show the format for MCS, HMCS and SMCS console entry.
Note:
1. If you enter a system command through a submitted JCL in a JES2 system, enter $VS,‘system
command’ when you enter the command between jobs, and enter //b system command when you
enter the command within a job.
2. Do not use the JES backspace character within a system command.
Following Table 13 on page 138 is a topic on command syntax and format. The syntax rules are shown in
“How to read syntax conventions” on page 151.
The rest of this topic consists of a description of each command in more detail. The descriptions are in
alphabetical order by command name. Each description lists the functions that the command performs
followed by the command’s syntax and parameters. The syntax and parameters of complex commands
follow subsets of the listed functions. Descriptions of the parameters and keywords appear in the order in
which they appear in the syntax.

© Copyright IBM Corp. 1988, 2018 137

Table 13. System command summary
Command Function Acceptable Command
(abbreviation) from group
ACTIVATE Build the interface to and invoke the hardware configuration MCS, HMCS, SYS
definition (HCD) application program interface. SMCS or
extended MCS
console 2
CANCEL (C) Cancel a MOUNT command MCS, HMCS, SYS
SMCS or
Cancel a time-sharing user
extended MCS
Cancel a cataloged procedure consoles or job
stream 2
Cancel a job in execution
Cancel a started catalog procedure
Cancel an external writer allocation
Cancel the writing of a SYSOUT data set by an external
writer session
Cancel a running APPC/MVS transaction program
Cancel a z/OS UNIX System Services process

CHNGDUMP Override dump options specified in parmlib, on the ABEND, MCS, HMCS, SYS
(CD) CALLRTM, and SETRP macros, and in the SDUMP parameter SMCS or
list extended MCS
consoles or job
stream 2
CMDS DISPLAY or SHOW information about commands that are MCS, HMCS, INFO
executing or waiting for execution SMCS or
extended MCS
ABEND, FORCE or REMOVE executing commands or
consoles or job MASTER
commands waiting for execution
stream 2
DUMP the address space where commands typically run
(Master and Console)

CONFIG (CF) Place processors online or offline MCS, HMCS, MASTER

SMCS or
Place central storage elements online or offline
extended MCS
Place amounts of central storage online or offline consoles2
Place ranges of central storage online or offline
Place channel paths online or offline
Place Vector Facilities online or offline

138 z/OS: MVS System Commands

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
CONTROL (K) MCS, HMCS
Change display area specifications INFO
and SMCS
consoles
Delete certain messages INFO

Halt printing of a status display INFO

Control area displays INFO

Remove information from the screens INFO

Activate, deactivate, or display the status MASTER

of the action message retention facility

Change or display the number of allowed MASTER

message and reply buffers

Change or display message deletion or format INFO

specifications

Change or display the status of WTO user MASTER

exit IEAVMXIT

Define commands for PFKs INFO

or MASTER

Purge message queue of a console. INFO

or MASTER

Change operating mode of console INFO

Select the message levels for a console INFO

Increase the RMAX value INFO

In a sysplex, change the maximum time MASTER

MVS waits before aggregating messages
from routed commands

DEVSERV (DS) Display current status of devices and corresponding channel MCS, HMCS, INFO
paths SMCS or
extended MCS
consoles or job
stream 2

MVS system commands reference 139

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
DISPLAY (D) Display information about MVS device allocation group locks MCS, HMCS, INFO
SMCS or
Display information about MVS device allocation settings extended MCS
Display IDGE device allocation information consoles or job
stream 2
Display APPC/MVS configuration information
Display ASCH configuration information
Display auxiliary storage information
Display information about the current auto-reply policy and
the WTORs being monitored by auto-reply processing
Display the current system level Language Environment®
run-time options
Display CONTROL command functions
Display storage and attachment information about coupling
facilities
Display console configuration information
Display system information requests
Display the current options that have been set with DIAGxx
Displaying data lookaside facility (DLF) information
Display the status or contents of SYS1.DUMP data sets,
captured data sets, and dump options in effect
Display extended MCS information
Display status of external time reference (ETR) ports
Display information about Global resource serialization.
Including configuration and usage information, as well as
ENQ and Latch contention and dependency analysis
Display Generic Tracker information
Display status of hardware instrumentation services (HIS)
Display status of HyperSwap® function and device pairs in
the PPRC configuration
Display ICSF information
Display the data set optimization configuration
Display TSO/E parmlib information
Display IOS configuration
Display captured UCB information
Display encryption key manager (EKM) status

140 z/OS: MVS System Commands

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
DISPLAY (D) Display zHPF facility status MCS, HMCS, INFO
(continued) SMCS or
Display FICON switch data information extended MCS
Display the IBM zHyperWrite data replication status consoles or job
stream 2
Display MIDAW facility status
Display current MIH time intervals for individual devices, or
for device classes
Display current system status
Display information about started tasks
Display information about LLA
Display information about system logger and log stream
resources
Display the current logrec error recording medium
Display configuration information
Display information about message flood automation
Display MVS message service and current available
languages
Display the messages MPF is processing and color, intensity,
and highlighting display options in effect
Display z/OS UNIX System Services information
Display information about operation information (OPDATA)
in a sysplex, or display the settings made by the SETCON
MONITOR command
Display PCIE information
Display parmlib information
Display commands defined for PFKs
Displays the contents of the Program Properties Table (PPT)
Display information about registered products and the
product enablement policy
Display entries in the list of APF-authorized program
libraries
Display PROG defaults
Display dynamic exits
Display information about the LNKLST set
Display information about modules dynamically added to
the LPA

MVS system commands reference 141

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
DISPLAY (D) Display the status of the REFRPROT option MCS, HMCS, INFO
(continued) SMCS or
Display the status of the TRACKDIRLOAD option extended MCS
Display system requests and status of the AMRF consoles or job
stream 2
Display status information about RRS coordinated
transactions
Display SLIP trap information
Display SMF options in effect or SMF data sets
Display the in-storage copy of the SMF limits
Display information about the SMS configuration or the
status of SMS volumes or storage groups or SMS trace
options
Display information about all subsystems defined to MVS
Display the current static system symbols
Display local and Greenwich mean time and date
Display information about component or transaction trace
status
Display device status and allocation
Display Unicode services
Display virtual storage information
Display the status of the active workload management
service policy for systems or application environments
Display information about the cross system coupling facility
(XCF)

DUMP Request a dump of virtual storage to be stored in a MCS, HMCS, MASTER

SYS1.DUMP data set SMCS or
extended MCS
console 2
DUMPDS (DD) Change the system’s list of SYS1.DUMP data sets MCS, HMCS, SYS
SMCS or
Clear full SYS1.DUMP data sets and make them available for
extended MCS
dumps
console 2
FORCE Force termination of: MCS, HMCS, MASTER
SMCS or
• A MOUNT command
extended MCS
• A job in execution console 2
• An external writer allocation
• The writing of a SYSOUT data set by an external writer
• A non-cancellable job, time-sharing user, or started task
• A running APPC/MVS transaction program
• Or a task within one of the above

142 z/OS: MVS System Commands

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
HALT (Z) Record statistics before stopping the system (Must first stop MCS, HMCS, SYS
subsystem processing with a subsystem command) SMCS or
extended MCS
console 2
IOACTION (IO) Stop or resume I/O activity to DASD MCS, HMCS, MASTER
SMCS or
extended MCS
console 2
LIBRARY (LI) Eject a volume from a library of removable storage media. MCS, HMCS SYS
and SMCS
Reactivate processing for certain installation exits without
consoles
stopping or restarting the object access method (OAM).
Set or display the media type of scratch volumes that the
system places into the cartridge loader of a device within a
tape library.
Display tape drive status.

LOG (L) Enter comments in the system log MCS, HMCS, INFO
SMCS or
extended MCS
consoles or job
stream 2
LOGOFF To log off MCS, HMCS and SMCS consoles MCS, HMCS INFO
and SMCS
consoles
LOGON To access the MCS, HMCS and SMCS consoles MCS, HMCS INFO
and SMCS
console
MODE Control recording of or suppress system recovery and MCS, HMCS, SYS
degradation machine check interruptions on the logrec data SMCS or
set extended MCS
console 2
Control the monitoring of hard machine check interruptions

MVS system commands reference 143

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
MODIFY (F) Change characteristics of a job by modifying the job MCS, HMCS, SYS
parameters SMCS or
extended MCS
Specify criteria an external writer uses to select data sets
consoles or job
for processing
stream 2
Cause an external writer to pause for operator intervention
Manage the data collection in hardware instrumentation
services (HIS)
Build a new LLA directory
Display information about the catalog address space or
request the catalog address space to perform a specified
service.
Modify TSO/VTAM time-sharing Rebuild a new LNKLST
directory
Display the status of the DLF, or change DLF parameters or
processing mode

MONITOR Continuously display data set status MCS, HMCS, INFO

(MN) SMCS or
Continuously display job status
extended MCS
Monitor time-sharing users logging on and off the system consoles or job
stream 2
MOUNT (M) Mount volumes MCS, HMCS, I/O
SMCS or
extended MCS
consoles or job
stream 2
PAGEADD (PA) Add local page data sets MCS, HMCS, SYS
SMCS or
Specify data sets as non-VIO page data sets
extended MCS
console 2
PAGEDEL (PD) Delete, replace, or drain a local page data set MCS, HMCS, SYS
SMCS or
(PLPA, common page data sets, and the last local page data
extended MCS
set cannot be deleted, replaced or drained)
console 2
QUIESCE Put system in MANUAL state without affecting step timing. MCS, HMCS, MASTER
SMCS or
extended MCS
console 2

144 z/OS: MVS System Commands

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
REPLY (R) Reply to system information requests. MCS, HMCS, INFO
SMCS or
Reply to system requests during recovery processing.
extended MCS
Specify component trace options after issuing TRACE CT. consoles or job
stream 2
Specify system parameters.
Set the time-of-day clock.
Specify SMF options.
Specify DUMP options.

RESET (E) Assign work to a new workload management service class. MCS, HMCS, SYS
Also, quiesce and resume executing work. SMCS or
MASTER
extended MCS
Force a hung console device offline. consoles or job
stream 2
ROUTE (RO) Direct a command to another system, to all systems, or to a MCS, HMCS, INFO
subset of systems in the sysplex. SMCS or
extended MCS
consoles or job
stream 2
SEND (SE) Communicate with other operators. MCS, HMCS, INFO
SMCS or
Communicate with specific time-sharing users.
extended MCS
Communicate with all time-sharing users. consoles or job
stream 2
Save messages in the broadcast data set for issuance at TSO
LOGON time or when requested.
List messages accumulated in the notices section of the
broadcast data set.
Delete a message from the notices section of the broadcast
data set.

MVS system commands reference 145

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
SET (T) Add modules to, or delete modules from, the LPA MCS, HMCS, SYS
dynamically. SMCS or
extended MCS
Change:
consoles or job
• the local time and date stream 2
• the system resources manager (SRM) parameters
• the MPF parameters
• the dump analysis and elimination (DAE) parameters
• SLIP processing by changing the active IEASLPxx parmlib
member
• SMS parameters by selecting member IGDSMSxx in , start
SMS if not started at IPL, or restart SMS if it cannot be
restarted automatically
• available PFK tables
• MIH time intervals by changing the active IECSIOSxx
parmlib member
• excessive spin-loop timeout interval recovery actions
• RNLs by selecting new GRSRNLxx parmlib members
• the APPC/MVS address space information
• the APPC/MVS transaction scheduler information
• the PPT information
• the active console group definitions in the sysplex
• the MMS parameters
• the command installation exits the system is to use
• the product enablement policy the system is to use
• the Generic Tracker parameters (GTZ).
Restart SMF or change SMF parameters by changing the
active SMFPRMxx parmlib member.
Start or stop the common storage and tracking functions.
Start, refresh, or stop MMS.
Update:
• the APF list and dynamic exits
• the format or contents of the APF list
• the LNKLKST set for LNKLST concatenation
• the system logger (IXGLOGR) address space information
by changing the active IXGCNFxx parmlib member.
Specify the MSGFLDxx parmlib member for the system to
use.

Activate auto-reply processing on a system by specifying the

AUTORxx parmlib member that the system is to use.
Add additional MCS console definitions without an IPL.

146 z/OS: MVS System Commands

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
SETALLOC Modify a Device Allocation parameter that was set at IPL by MCS, HMCS, SYS
an ALLOCxx parmlib member or after IPL by a previous SMCS or
SETALLOC command. extended MCS
console 2
SETAPPC Dynamically define or modify the APPC/MVS configuration. MCS, HMCS, SYS
SMCS or
extended MCS
console 2
SETAUTOR Deactivate auto-reply processing on a system or have auto- MCS, HMCS, SYS
reply stop monitoring an outstanding WTOR. SMCS or
extended MCS
console 2
SETCEE Override system-level Language Environment options. MCS, HMCS, SYS
SMCS or
extended MCS
console 2
SETCON Set console services mode of operations, control MCS, HMCS, MASTER
enablement of monitor messages and delete extraneous SMCS or
consoles. extended MCS
console 2
SETETR Enable external time reference (ETR) ports that have been MCS, HMCS, SYS
disabled SMCS or
extended MCS
console 2
SETFXE Set the enablement state of individual functions in the IBM MCS, HMCS, SYS
Function Registry for z/OS. SMCS or
extended MCS
console 2
SETGRS • Migrate a currently active global resource serialization ring MCS, HMCS, MASTER
complex to a global resource serialization star complex SMCS or
extended MCS
• Modify the current RESMIL or TOLINT values console 2
• Set the system values for
– GRSQ
– SYNCHRES
– ENQMAXA
– ENQMAXU
• Change the contention notifying system (CNS) in a global
resource serialization complex

SETGTZ Control the Generic Tracker MCS, HMCS, SYS

SMCS or
extended MCS
console 2

MVS system commands reference 147

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
SETHS Manage HyperSwap. MCS, HMCS, I/O
SMCS or
extended MCS
console 2
SETIOS Respecify, add, or delete MIH time intervals, update DCM, MCS, HMCS, SYS
enable/disable FICON statistics, and enable/disable the SMCS or
MIDAW facility, all without changing the active IECIOSxx extended MCS
parmlib member console 2
SETLOAD Switch dynamically from one parmlib concatenation to MCS, HMCS, SYS
another without having to initiate an IPL, or dynamically SMCS or
update the system symbols on your local system without an extended MCS
IPL. console 2
SETLOGR Take action on system logger log stream resources. MCS, HMCS, MASTER
SMCS or
extended MVS
console 2
SETLOGRC Change the logrec recording medium. MCS, HMCS, MASTER
SMCS or
extended MCS
console 2
SETMF Change the message flood automation state or parameters. MCS, HMCS, SYS
SMCS or
extended MCS
console 2
SETOMVS Change the options that z/OS UNIX System Services uses. MCS, HMCS, SYS
SMCS or
extended MCS
console 2
SETPROG Update APF list MCS, HMCS, SYS
SMCS or
Update dynamic exits
extended MCS
Update the LNKLST set console 2
Dynamically add modules to, or delete modules from, the
LPA.

SETRRS Control RRS processing: MCS, HMCS, SYS

SMCS or
• SETRRS ARCHIVELOGGING will disable or enable archive extended MCS
logging on a given system console 2
• SETRRS CANCEL will end RRS processing
• SETRRS SHUTDOWN will end RRS without resulting in a
X'058' abend

SETSMF (SS) Change SMF parameters without changing the active MCS, HMCS, SYS
SMFPRMxx parmlib member SMCS or
extended MCS
consoles or job
stream 2

148 z/OS: MVS System Commands

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
SETSMS Change SMS parameters without changing the active MCS, HMCS, SYS
IGDSMSxx parmlib member SMCS or
extended MCS
console 2
SETSSI Dynamically add, activate or deactivate a subsystem. MCS, HMCS, MASTER
SMCS or
extended MCS
console 2
SETUNI Control the Unicode environment. MCS, HMCS, SYS
SMCS or
extended MCS
console.2
SETXCF Control the cross-system coupling facility (XCF) MCS, HMCS, MASTER
SMCS or
extended MCS
console 2
SLIP (SL) Set SLIP traps MCS, HMCS, SYS
SMCS or
Modify SLIP traps
extended MCS
Delete SLIP traps consoles or job
stream 2
START (S) Start a job from a console MCS, HMCS, SYS
SMCS or
Start the advanced program-to-program communication
extended MCS
(APPC/MVS) address space
consoles or job
Start the APPC/MVS scheduler (ASCH) address space stream 2
Start the data facility storage management subsystem
(DFSMS/MVS) license compliance facility
Start the generalized trace facility (GTF)
Start hardware instrumentation services (HIS)
Start the library lookaside (LLA) address space
Start the object access method (OAM)
Start resource recovery services (RRS)
Start the system object model (SOM)
Start TSO/VTAM time-sharing
Start the virtual lookaside facility (VLF) or the data lookaside
facility (DLF)
Start an external writer

MVS system commands reference 149

Table 13. System command summary (continued)
Command Function Acceptable Command
(abbreviation) from group
STOP (P) Stop a job in execution MCS, HMCS, SYS
SMCS or
Stop an address space
extended MCS
Stop an ASCH initiator consoles or job
stream 2
Stop an initiator
Stop the data lookaside facility (DLF)
Stop the generalized trace facility (GTF)
Stop hardware instrumentation services (HIS)
Stop the library lookaside (LLA) address space
Stop the object access method (OAM)
Stop the system object model (SOM)
Stop TSO/VTAM time-sharing
Stop the virtual lookaside facility (VLF)
Stop an external writer

STOPMN (PM) Stop continual display of data set status MCS, HMCS, INFO
SMCS or
Stop continual display of job status
extended MCS
Stop monitoring the activity of time-sharing users. consoles or job
stream 2
SWAP (G) Move a volume from one device to another MCS, HMCS, I/O
SMCS or
extended MCS
consoles 2
SWITCH (I) Manually switch recording of SMF data from one data set to MCS, HMCS, SYS
another SMCS or
extended MCS
console 2
TRACE Start, stop, or modify system trace MCS, HMCS, SYS
SMCS or
Start, stop, or modify master trace MASTER
extended MCS
Start, stop, or modify component trace console 2 MASTER
Display the status of system trace, master trace, or SYS
component trace

UNLOAD (U) Remove a volume from system use MCS, HMCS, I/O
SMCS or
extended MCS
consoles or job
stream 2

150 z/OS: MVS System Commands

 Command syntax notation

Table 13. System command summary (continued)

Command Function Acceptable Command
(abbreviation) from group
VARY (V) Control the hardcopy message set and the hardcopy MCS, HMCS, MASTER, I/O,
medium. SMCS or or CONS1
extended MCS
Change the status of a console consoles or job
Change the SMS status of a storage group or volume for one stream
or more MVS systems in the SMS complex
Place I/O devices online or offline
Assign and control consoles
Place I/O paths online or offline
Remove a system from a sysplex
Place I/O paths online after C.U.I.R service
Change a system’s participation in a global resource
serialization complex
Change routing codes for a console
Activate a workload management service policy for a
sysplex
Control an application environment
Process devices or a path to devices attached to a control
unit

WRITELOG (W) Schedule printing of system log MCS, HMCS, SYS

SMCS or
Change system log output class
extended MCS
Close the system log and discontinue the log function consoles or job
stream 2
Restart system log after closing

Note:
1. This command is in a different command authority group depending on the parameters specified on the
command. See Table 10 on page 111 for more information.
2. An extended MCS console can be either an interactive TSO/E session or a program that issues the MCSOPER
macro.

Command syntax notation

You must follow certain syntactical rules when you code the MVS commands described in this chapter.
Use “How to read syntax conventions” on page 151 to help you with the syntax.

How to read syntax conventions

This topic describes how to read syntax conventions. It defines syntax notations and provides syntax
examples that contain these items.
Note: When running a command, specify command parameters in the order in which they are shown in
the command syntax diagram.

MVS system commands reference 151

Command syntax notation

Table 14. Syntax conventions

Notation Meaning Syntax example Sample entry
Apostrophes Apostrophes indicate a
SEND 'message',NOW SEND 'listings
parameter string and ready',NOW
must be entered as
shown.
Comma Commas must be
DISPLAY C,K DISPLAY C,K
entered as shown.
Ellipsis ... Ellipsis indicates that
VARY (devspec[,devspec]...),ONLINE VARY
the preceding item or (282,283,287),ONLINE
group of items can be
repeated one or more
times. Do not enter the
ellipsis.
Parentheses Parentheses and special
DUMP COMM=(text) DUMP COMM=(PAYROLL)
and special characters must be
characters entered as shown.
Underline Underline indicates a K M
K M[,AMRF={Y | N}] |,REF
default option. If you
select an underlined
alternative, you do not
have to specify it when
you enter the command.
Lowercase Lowercase indicates a
MOUNT devnum MOUNT A30
parameter variable term.
Substitute your own or
value for the item.
mount a30

Uppercase Uppercase indicates the

DISPLAY SMF DISPLAY SMF
parameter item must be entered
using the characters or
shown. Enter the item in
either upper or display smf
lowercase.
Single Single brackets
DISPLAY SLIP[=xxxx] DISPLAY SLIP=W292
brackets represent single or
group-related items that
are optional. Enter one
or none of these items.
Stacked Stacked brackets
[TERMINAL] NOTERMINAL
brackets represent group-related [NOTERMINAL]
items that are optional.
Enter one or none of
these items.
Single braces Single braces represent
{COMCHECK | COMK} COMK
group-related items that
are alternatives. You
must enter one of the
items. You cannot enter
more than one.

152 z/OS: MVS System Commands

 System command formats

Table 14. Syntax conventions (continued)

Notation Meaning Syntax example Sample entry
Stacked Stacked braces
MN {DSNAME} MN SPACE
braces represent group related {SPACE }
items that are {STATUS}
alternatives. You must
enter one of the items.
You cannot enter more
than one.
Or-bar (|) An or-bar indicates a
ACTIVATE RECOVER=SOURCE | TARGET ACTIVATE RECOVER=SOURCE
mutually exclusive
choice. When used with
brackets, enter one or
none of the items. When
used with braces, you
must enter one of the
items.
Stacked Stacked items with or-
CD RESET [ ,SDUMP ] CD RESET,SYSUDUMP
items with bars indicates a |,SYSABEND
or-bars (|) mutually-exclusive |,SYSUDUMP
|,SYSMDUMP
and brackets choice. Enter one or |,ALL
none of these items.

System command formats

Two system command formats are defined.

Typical format
Most system commands can use the format shown in Figure 19 on page 153.

Figure 19. Typical system command format

The following command format is depicted in Figure 19 on page 153:

1. Optional command prefixes or blanks
2. Command
3. One or more blanks
4. Optional operands with no embedded blanks: [operand[,operand]...]
5. One or more blanks
6. Optional comments with optional embedded blanks: [comments]
The following restrictions apply to commands using this format:
1. Enter only one command per line. Use a maximum of 126 characters from a console, or 80 characters
through a submitted JCL.

MVS system commands reference 153

ACTIVATE command

2. To include a comment on a command when you have specified no operands, insert the following after
the command: a blank, then a comma, then another blank, and then the comment. The comment may
contain embedded blanks.

A second format
Figure 20 on page 154 shows a format required by some system commands including DISPLAY PROD,
DISPLAY PROG, and SETPROG.

Figure 20. System command format required for some commands

The following command format is depicted in Figure 20 on page 154:

1. Optional command prefixes or blanks
2. Command
3. One or more blanks
4. Optional comments, and optional commas between operands: [operand[comments]...]
5. One optional blank
6. Optional comments with optional embedded blanks: [comments]
This second format provides the opportunity to include a comment after the command and each operand
within the command. These restrictions apply:
1. You may, but do not have to use a comma between operands. Examples:

D PROG APF
D PROG,APF

2. This format requires that each comment be contained between a slash-asterisk and asterisk-slash
pair. Comments may contain embedded blanks. Examples:

D PROG APF /* comments */

D PROG /*comment */ APF /* comment */

ACTIVATE command
Use the ACTIVATE command to activate or test a new I/O configuration definition dynamically.

Restrictions
For a list of restrictions on the ACTIVATE command, see z/OS HCD Planning.
Attention: An ACTIVATE command may still be active as a task in IOSAS after the command task
has been abended with a CMDS ABEND.

Syntax
The complete syntax for the ACTIVATE command is:

154 z/OS: MVS System Commands

 ACTIVATE command

ACTIVATE {[,IODF=xx][,EDT=xx][,PROC=procname][,CFID=id][,ACTIOCDS=xx]}
|,RECOVER={SOURCE|TARGET}

{[ ,SOFT[=VALIDATE|=NOVALIDATE] ] }
|,TEST
|,FORCE
|,FORCE={DEVICE }
{CANDIDATE }
{(DEVICE,CANDIDATE)}
{(CANDIDATE,DEVICE)}

Note: Do not specify a comma before the first parameter following ACTIVATE.

Parameters
IODF=xx
Specifies the two-character suffix of the target IODF data set name (IODFxx) that contains the
configuration definition the system is to activate. When this keyword is omitted, the system defaults to
the active IODF data set name.
EDT=xx
Specifies the eligible devices table (EDT) that the system is to construct from the target IODF. If you
omit this keyword, the system uses the active EDT identifier.
PROC=procname
Indicates the eight-byte name of the processor definition in the target IODF. If you omit this keyword,
the system will use the active processor name.
CFID=id
Specifies the eight-byte configuration identifier that indicates the operating system definition in the
target IODF. If you omit this keyword, the system defaults the configuration identifier as follows:
• When the target IODF has only one configuration identifier, it becomes the default, otherwise, the
current configuration identifier is the default.
RECOVER=
Allows the installation to continue a dynamic change that did not complete due to a hardware,
software, or PR/SM failure. RECOVER cannot be specified with any other parameters. You can specify:
• SOURCE to retry the original I/O configuration
• TARGET to retry the new I/O configuration
• default:
– Retry TARGET IODF if ACTIVATE failed during advance
– Retry SOURCE IODF if ACTIVATE failed while backing out.
ACTIOCDS=xx
Specifies the two-character IOCDS name that the system is to activate. Upon successful completion of
the ACTIVATE command, the default IOCDS for the next power-on-reset will be xx. It does not make
the I/O configuration definition stored in the IOCDS the active one.
For the IOCDS activate process to be successful, the processor token in the target IOCDS must match
the current processor token in the Hardware System Area (HSA). This means that the IOCDS that is
being activated has an I/O configuration definition that matches the I/O configuration currently active
in the channel subsystem.
When you specify ACTIOCDS, you cannot specify TEST.
SOFT
Specifies a dynamic change to the software I/O configuration, which updates the I/O configuration
only to the operating system. To change a software and hardware I/O configuration dynamically, omit
the SOFT keyword.
When you specify SOFT, you cannot specify FORCE.

MVS system commands reference 155

ACTIVATE command

When you specify SOFT without any parameters, it is the same as specifying SOFT=VALIDATE.
=VALIDATE or =NOVALIDATE
Allows you to specify whether or not the system is to validate that any specified hardware elements to
be deleted are offline and available, and that there is sufficient HSA space available to accommodate
the hardware changes.
When a dynamic change is made to the I/O configuration for a processor complex running in LPAR
mode, a change to the software I/O configuration is performed for the first N-1 logical partitions,
followed by a hardware and software change for the Nth logical partition. By specifying the SOFT
keyword (or SOFT=VALIDATE) when changing the I/O configuration on the N-1 logical partitions, you
can determine early on whether there will be sufficient HSA space available for the subsequent
software and hardware I/O configuration changes on the Nth logical partition.
Specifying SOFT=VALIDATE also ensures that the required processing for changes to coupling facility
elements (CF control units or CF channel paths) will be executed. SOFT=VALIDATE is a requirement in
all N-1 partitions when you make changes to coupling facility elements.
TEST
Specifies test mode to check, but not to change, the configuration. The system checks include
whether:
• The dynamic change will fit into the current HSA
• The target IODF exists
• The target IODF contains the target EDT
• The target IOCDS is a valid data set
• The device support code supports devices being dynamically added or deleted
• The devices to be deleted are offline
• The paths to be deleted are offline
• The devices and paths to be deleted are pinned
If you are performing a full dynamic activate, the system provides a list showing which channels and
devices will be added, deleted, or changed during activation.
Warning
If you run the ACTIVATE command with the TEST option and the system detects no errors, there is
still no guarantee that ACTIVATE will work without TEST.
Although pinned devices/paths are detected during ACTIVATE with the TEST option, some
products and functions such as Geographically Dispersed Parallel Sysplex (GDPS) and z/OS Basic
Hyperswap rely on signals done during real (non-TEST) activates in order to prevent deletion of
those devices/paths. Therefore, activates with the TEST option may not alert you to the potential
of a real activate failure that may occur due to pinned devices/paths as the messages indicating
this condition will not be issued.
Devices/paths may become pinned or unpinned if a real activate request is performed at a
separate time from the test activate.
When you specify TEST, you cannot specify ACTIOCDS or FORCE.
FORCE
Specify that the system makes it possible to delete hardware resources that might offset other
partitions.
You must specify FORCE if your processor complex is running in LPAR mode, and you want to activate
a target IODF to delete one or more I/O components. You can also specify FORCE to activate a target
IODF to delete a logical partition from a device candidate list. These deletions may be explicit or
implicit due to changes in the definitions for some I/O components. When you specify FORCE, you
cannot specify SOFT or TEST.
If your processor complex has Enterprise Systems Connection (ESCON) Multiple Image Facility (EMIF)
capability, you can specify FORCE to get the results described in Table 15 on page 157.

156 z/OS: MVS System Commands

 ACTIVATE command

For information about ESCON Multiple Image Facility (EMIF), see z/OS HCD Planning. For information
about access lists and candidate lists, see z/OS HCD User's Guide.

Table 15. Specifying FORCE with EMIF

To do the following: Specify FORCE as follows:
Delete no I/O components, and do either of the Do not specify FORCE.
following:
• Delete no logical partitions from the access or
candidate list of a channel path or PCIe function.
• Delete one or more logical partitions from the access
or candidate list of a channel path or PCIe function
offline to all of those logical partitions. IBM
recommends that you take the channel path or PCIe
function offline before issuing the command.

Delete no I/O components, and delete one or more FORCE=CANDIDATE

logical partitions from the access or candidate list of a
channel path or PCIe function online to any of those
logical partitions. IBM does not recommend this action.
Delete one or more I/O components, and do either of FORCE or FORCE=DEVICE
the following:
• Delete no logical partitions from the access or
candidate list of a channel path or PCIe function.
• Delete one or more logical partitions from the access
or candidate list of a channel path or PCIe function
offline to all of those logical partitions. IBM
recommends that you take the channel path or PCIe
function offline before issuing the command.

Delete one or more I/O components, and delete one or FORCE=(DEVICE,CANDIDATE) or

more logical partitions from the access or candidate list FORCE=(CANDIDATE,DEVICE)
of a channel path or PCIe function online to any of those
logical partitions. IBM does not recommend this action.
Delete one or more logical partitions from the device FORCE or FORCE=DEVICE
candidate list and delete no other I/O components.

Note: Before activating the new configuration, you may have to configure offline affected channel paths or
vary offline affected devices. See z/OS HCD Planning for details about avoiding disruptions to I/O
operations during dynamic changes.
Example 1:
To ACTIVATE the A0 IOCDS, enter:

ACTIVATE ACTIOCDS=A0

Example 2:
To ACTIVATE the configuration definition COMPUT22, contained in the IODF with suffix 03, enter:

ACTIVATE IODF=03,CFID=COMPUT22

Example 3:

MVS system commands reference 157

CANCEL command

To perform a test ACTIVATE to processor definition PROC1001 contained in the currently active IODF,
enter:

ACTIVATE PROC=PROC1001,TEST

Example 4:
To ACTIVATE an IODF with suffix 04, which deletes one or more I/O components from the I/O
configuration, enter:

ACTIVATE IODF=04,FORCE
or
ACTIVATE IODF=04,FORCE=DEVICE

CANCEL command
Use the CANCEL command to end an active job, started task, or time-sharing user immediately. The table
that follows summarizes the tasks that the CANCEL command can perform. Following the table are usage
notes, the complete command syntax, definition of parameters, and examples of use.
If the program that supports the job or started task was designed to recognize the STOP command, use
the STOP command before using the CANCEL command. If the CANCEL command fails several times,
consider using the FORCE command.

Table 16. CANCEL Command Tasks

Task - Immediately Terminate: Syntax

• A job in execution CANCEL jobname

• A running Advanced Program-to-Program Communication/MVS (APPC/
MVS) transaction program
• A started task

• A address space identifier of the work unit you want to cancel CANCEL ASID=asid

• A time-sharing user CANCEL U=userid

• A started task CANCEL identifier

• A MOUNT command
• An external writer allocation
• The output processing for a job
• A z/OS UNIX process

Note:
1. If your system was part of a global resource serialization ring (GRS=START, GRS=JOIN or
GRS=TRYJOIN was specified at IPL) and the system is either inactive or quiesced (by entering the
VARY GRS(system name),QUIESCE command), the CANCEL command might not work for jobs that
own any global resources. Use DISPLAY GRS to determine GRS status.
2. If a job is running, you can end it using either the CANCEL system command or the appropriate
subsystem command. However, if the job is not running, you must CANCEL the job using the
subsystem command.
3. The CANCEL command issues an ABEND with either code 122 or 222 to abnormally end a job step or
time-sharing user. The ABEND is asynchronous and might result in additional errors, depending on

158 z/OS: MVS System Commands

 CANCEL command

which programs were active at the time of the request. You might need to issue additional CANCEL
commands to completely end the job.
4. Entering the CANCEL command during device allocation terminates the external writer as well as the
unit of work. Entering this command when the external writer is processing output for a job terminates
the output processing but leaves the external writer to process other data sets.
5. When you cancel a MOUNT command for a tape unit, the MOUNT command can end before the volume
has been mounted. If the MOUNT command has ended and the mount request is not satisfied, issue
the UNLOAD command to free the tape unit.

Syntax
The complete syntax for the CANCEL command is:

C {jobname }[,DUMP][,A=asid][,ARMRESTART]
{U=userid }
{[jobname.]identifier}

Parameters
jobname
The name of the batch job, started task, or APPC/MVS transaction program to be canceled.
The job name for a given started task can be assigned based on a variety of inputs. These inputs are
examined in the following order, so that if item #1 is not specified, item #2 is used. If neither #1 nor
#2 is specified, then #3 is used, and so on.
1. The jobname specified in the JOBNAME= parameter of the START command
or
The identifier specified on the START command.
2. The jobname specified on the JOB JCL statement within the member.
3. The device number specified on the START command, or the device number associated with the
device type specified on the START command
or
The device number associated with the device type specified on the START command.
4. The device number associated with the IEFRDER DD statement within the member.
5. The member name.
U=userid
The user ID of the time-sharing user you want to cancel.
If the user is just logging on and does not yet have a unique name, you must find out the address
space identifier for the user (see the explanation under A=asid) and use the following version of the
command:
• CANCEL U=*LOGON*,A=asid
[jobname.]identifier
The identifier for the unit of work that you want to cancel, optionally preceded by the job name.
The following types of identifiers can be used:
• The identifier that was specified on the START command.
• [/]devnum, the device number specified when the START or MOUNT command was entered. The
device number is 3 or 4 hexadecimal digits, optionally preceded by a slash (/). You can precede the
device number with a slash to prevent ambiguity between the device number and a device type or
identifier.

MVS system commands reference 159

CANCEL command

• devicetype, the type of device specified when the START or MOUNT command was issued.
If no identifier was specified on the START command, the system assigns temporary identifier
“STARTING” to the unit of work, until the system can assign an identifier according to the following
order of precedence:
1. If an identifier was not specified on the START command, the identifier is the device type (for
example, 3410) or device number (for example, X‘0000’) specified on the START or MOUNT
command.
2. If an identifier, a device type, or a device number was not specified on the START or MOUNT
command, the identifier is the device type specified on an IEFRDER DD statement (invoking a
cataloged procedure) in the JCL.
3. If none of the these was specified, the identifier defaults to the job name.
When you specify jobname.identifier, then identifier can be represented by any of the following:
• An asterisk
• One or more characters from the beginning of the identifier, followed by an asterisk
• The entire identifier
When you specify an asterisk, the system responds with message IEE422I.
Attention: When you use the asterisk format, the command affects all started tasks that begin with
the specified characters. Device numbers are assumed to be four-digit numbers; for example, /13*
would match on 1301, 1302, and so on, but would not match on 13C, because 13C is interpreted as
013C.
Specifying both the job name and the entire identifier causes the command to take effect if one and
only one work unit with that combination of job name and identifier is running. For the case where
more than one work units with the same combination of job name and identifier are running, see the
description of the A=asid parameter.
DUMP
A dump is to be taken. The type of dump (SYSABEND, SYSUDUMP, or SYSMDUMP) depends on the JCL
for the job. A dump request is only valid when made while the job is running. Dumps are not taken
during job allocation or deallocation.
Note: You can use DUMP with any of the other CANCEL parameters.
A=asid
The hexadecimal address space identifier of the work unit you want to cancel.
If more than one work unit is running with the same job name, identifier, combination of job name and
identifier, or user ID that you specified on the CANCEL command, the system rejects the command
because it does not know which work unit to cancel. To avoid this, you must add the parameter A=asid
to your original CANCEL command in order to specify the address space identifier of the work unit.
Note: If the asterisk format is used, you will not be prompted for A=asid. Rather, all work units
meeting the specified criteria will be canceled.
You can use the CANCEL operator command to cancel z/OS UNIX address spaces. Each address space
is equivalent to a z/OS UNIX process.
To find out the address space identifier for a unit of work, you can use the DISPLAY command as
follows:
DISPLAY JOBS,ALL
Lists the address space identifiers for all batch jobs and started tasks.
DISPLAY ASCH,ALL
Lists the address space identifiers for all APPC/MVS transaction programs.
DISPLAY TS,ALL
Lists the address space identifiers for all logged-on time-sharing users.

160 z/OS: MVS System Commands

 CANCEL command

DISPLAY OMVS,ASID=ALL or DISPLAY OMVS,A=ALL

Lists the address space identifiers for all z/OS UNIX processes.
Note: A=asid can be used with any of the other CANCEL parameters except if you specify
jobname.identifier with an asterisk (for example, CANCEL aor2.tl*).
ARMRESTART
Indicates that the batch job or started task should be automatically restarted after the cancel
completes, if it is registered as an element of the automatic restart manager. If the job or task is not
registered or if you do not specify this parameter, MVS will not automatically restart the job or task.
Example 1:
Cancel the job named EXAMPLE and take a dump.

c example,dump

Example 2:
Cancel the job named EXAMPLE. Whether you get a dump or not depends on the system routine in control
when you enter the command.

c example

Example 3:
Of all jobs named EXAMPLE in the system, cancel only the one whose address space identifier is 7F.

c example,a=7F

Example 4:
Log off the system the user just logging on who has an address space identifier of 3D but does not yet
have a unique user identifier.

c u=*logon*,a=3d

Example 5:
Log user A237 off the system.

c u=a237

Example 6:
Log user A237 off the system and take a dump.

c u=a237,dump

Example 7:
Cancel the MOUNT command that requests a volume to be mounted on device number 232, enter:

c 232

Example 8:
Cancel the MOUNT command that requests a volume to be mounted on a 3330 device type.

c 3330

Example 9:
End the device allocation for a writer with device number 00E.

c 00e

MVS system commands reference 161

CANCEL command

Example 10:
End the output processing being done for device number 00E and cause another output data set to be
processed.

c 00e

Example 11:
End the output processing being done for device number 3480 and cause another output data set to be
processed.

c /3480

Example 12:
Of all the transaction programs running with the job name MAIL, end only the one whose address space
identifier is 2C, which is the APPC/MVS scheduler (ASCH) initiator ASID.

C mail,a=2c

Example 13:
End the device allocation for a writer on device number F00E.

c /f00e

Example 14:
There are several tasks running with jobname AOR2. End all of those tasks.

c aor2.*

Example 15:
There are several tasks running with jobname AOR2. Some of those tasks have identifiers beginning T1.
End only those specific tasks.

c aor2.t1*

Example 16:
The following example shows an operator session that cancels a process that is running the shell
command sleep 6000 for the TSO/E user CHAD.

DISPLAY OMVS,U=CHAD

BPXO001I 17.12.23 DISPLAY OMVS 700 C

OMVS ACTIVE BPXPRMHF
USER JOBNAME ASID PID PPID STATE START CT_SECS
CHAD CHAD 001D 262147 1 RI 17.00.10 1.203
CHAD CHAD 001B 131076 5 SI 17.00.10 .111
LATCHWAITPID= 0 CMD=sleep 6000
CHAD CHAD 0041 5 262147 IW 17.00.10 .596
LATCHWAITPID= 0 CMD=-sh
CHAD CHAD3 001B 131076 5 SI 17.00.10 .111
LATCHWAITPID= 0 CMD=sleep 6000

If you want to cancel only the process that is running the shell command sleep 6000, enter:

CANCEL CHAD3

If you want to cancel the TSO/E user CHAD altogether, enter:

CANCEL U=CHAD

162 z/OS: MVS System Commands

 CHNGDUMP command

CHNGDUMP command
Use the CHNGDUMP command to change the mode and system dump options list for any dump type, or to
request structures to be dumped when one or more systems connected to a coupling facility fail. The
dump types are SDUMP, SYSABEND, SYSUDUMP, and SYSMDUMP. If you issue multiple CHNGDUMP
commands, the changes to the system dump options are cumulative.
Table 17 on page 163 summarizes the common tasks that are available for the CHNGDUMP command.

Table 17. Summary of common CHNGDUMP tasks

Command Topic
CHNGDUMP DEL “Removing options from or resetting the system dump options lists” on
page 164
CHNGDUMP RESET “Resetting dump mode to add and the dump options to initial values” on
page 172
CHNGDUMP SET “Setting the dump modes and options” on page 174

Dump options and modes

The system checks the dump mode and dump options each time the system or a user requests a dump.
The dump mode determines whether the system accepts either a dump request or the options a dump
request specifies. The starting dump mode for all four dump types is ADD.
The dump options, whether taken from a s