a brief look at - · pdf filez/os mvs system commands - v2r3 - sa38-0666-30 z/os jes2...

A Brief Look at

Our members are leading the Mainframe Revolution

Is Researched and Compiled by:

Richard K. Faulhaber – Andrew Hoyt Robichaux [email protected] [email protected]

Technical Support Analysts

NewEra Software, Inc.

Last Updated: September 12, 2017

Based on generally Available Public Documentation and Presentations iii

A Brief Look at What’s New in V2R3

1 FOREWORDRichard K. Faulhaber, the leader of this project, provides technical support services to all NewEra Software product customers and prospects worldwide. With his diverse background in various IT capacities, boundless creativity, and overwhelming enthusiasm for technology, he brings a fresh eye to z System computing.

In compiling this document and its future updates for you, Richard and his associate Andrew Hoyt Robichaux have and will use their best professional efforts to sort out changes and new things coming to you in V2R3 and beyond. Their work is based on findings from generally available public documentation and presentations. Though their research is extensive, it is ongoing. As they learn more, expect updates.

I suggest you stay tuned!

Paul R. Robichaux, Co-Founder

Source Documentation

The source documents used in creating this V2R3 Summary, z/OS V2R3 Elements and Features, can be found at the following web address:

https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3Library?OpenDocument

Specific documents cited are as follows:

z/OS MVS System Commands - V2R3 - SA38-0666-30 z/OS JES2 Initialization and Tuning Reference - V2R3 - SA32-0992-30z/OS JES3 Initialization and Tuning Reference - V2R3 - SA32-1005-30z/OS Communications Server - SNA Resource Definition Reference - V2R3 - SC27-3675-30z/OS Communications Server - IP Configuration Reference - V2R3 - SC27-3651-30 z/OS MVS Initialization and Tuning Reference - V2R3 - SA23-1380-30 z/OS Security Server RACF - Command Language Reference - V2R3 - SA23-2292-30

https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3Library?OpenDocument

iv Based on generally Available Public Documentation and Presentations


Based on generally Available Public Documentation and Presentations v


2 TABLE OF CONTENTS1 Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

2 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

3 MVS SYSTEM COMMANDS: /* V2R3 ADD & CHANGE */ . . . . . . . . . . . . . . . . . . . . . . . .1

3.1 MVS System Commands New to V2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13.1.1 SETOMVS command - /* New keyword / attribute in V2R3 */ . . . . . . . . . . . . . . . . . . . . .13.1.2 SETIOS command - /* New keyword in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . .23.1.3 DISPLAY FXE command - /* New in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33.1.4 DISPLAY OAM,CONFIG command - /* New in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . .53.1.5 DISPLAY XCF command - /* New parameters in V2R3 */ . . . . . . . . . . . . . . . . . . . . .53.1.6 CHNGDUMP command - /* New options in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . .63.1.7 DUMP command - /* New keyword in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83.1.8 SETFXE command - /* New in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93.1.9 SET command - /* New parameter in V2R3 */. . . . . . . . . . . . . . . . . . . . . . . . . . . . .113.1.10 SETLOGR MANAGE command - /* New parameters in V2R3 */ . . . . . . . . . . . . . . .113.1.11 SETXCF MODIFY command - /* New parameter in V2R3 */ . . . . . . . . . . . . . . . . . .123.2 MVS System Commands Changed in V2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143.2.1 DEVSERV command - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143.2.2 DISPLAY SMS command - /* Changed in V2R3 */. . . . . . . . . . . . . . . . . . . . . . . . . .153.2.3 DISPLAY OAM command - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . .153.2.4 MODIFY command - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163.2.5 DISPLAY VIRTSTOR,HVSHARE command - /* Changed in V2R3 */ . . . . . . . . . . . .163.2.6 SETUNI command - /* Parameters changed in V2R3 */. . . . . . . . . . . . . . . . . . . . . .173.3 MVS System Commands removed from V2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193.3.1 DISPLAY CONSOLES command - /* Parameter removed from V2R3 */ . . . . . . . . .193.3.2 DISPLAY OPDATA command - /* Parameter removed from V2R3 */ . . . . . . . . . . . .193.3.3 VARY command - /* Information removed from V2R3 */ . . . . . . . . . . . . . . . . . . . . .203.4 Complete List of MVS System Commands with changes noted . . . . . . . . . . . . . . . . . .20

4 JES2: /* V2R3 ADD & CHANGE */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224.1 JES2 statements Changed in V2R3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224.1.1 DEBUG - /* V2R3 Keyword Added */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224.1.2 JOBDEF - /* V2R3 Keyword Added */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224.1.3 MASDEF - /* V2R3 Keyword Added */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234.1.4 NETSERV - /* V2R3 Keywords Added */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244.1.5 NJEDEF - /* V2R3 Keywords Added */. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254.1.6 NODE(xxxxxxxx) - /* V2R3 Keyword Added */ . . . . . . . . . . . . . . . . . . . . . . . . . . . .264.1.7 OUTDEF - /* V2R3 Keyword Removed */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274.1.8 RDR(nn) - /* V2R3 Keyword Removed */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274.2 Complete list of JES2 statements with changes noted . . . . . . . . . . . . . . . . . . . . . . . . .28

5 JES3: /* V2R3 ADD & CHANGE */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305.1 JES3 statement with keywords or parameters New to V2R3. . . . . . . . . . . . . . . . . . . . .305.1.1 CLASS - /* V2R3 Keyword Added */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305.1.2 NETSERV - /* V2R3 Keyword Added */. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

vi Based on generally Available Public Documentation and Presentations


5.1.3 NJERMT - /* V2R3 Keyword Added */. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315.2 Complete list of JES3 statements with changes noted . . . . . . . . . . . . . . . . . . . . . . . . .33

6 VTAM: /* NO CHANGES */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

7 TCPIP PROFILE: /* V2R3 CHANGES */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347.1 TCP/IP Statements for which support was removed from V2R3 . . . . . . . . . . . . . . . . . .347.1.1 DEVICE and LINK statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347.2 TCP/IP Statements which were changed in V2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367.2.1 GLOBALCONFIG statement - /* V2R3 CHANGED */ . . . . . . . . . . . . . . . . . . . . . . . .367.2.2 IPCONFIG statement - /* V2R3 CHANGED */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .377.2.3 IPCONFIG6 statement – /* V2R3 CHANGED */ . . . . . . . . . . . . . . . . . . . . . . . . . . . .387.2.4 NETMONITOR statement – /* V2R3 CHANGED */. . . . . . . . . . . . . . . . . . . . . . . . . .397.2.5 SMFCONFIG statement – /* V2R3 CHANGED */ . . . . . . . . . . . . . . . . . . . . . . . . . . .407.2.6 TRANSLATE statement – /* V2R3 CHANGED */ . . . . . . . . . . . . . . . . . . . . . . . . . . .417.3 Complete List of TCP/IP Statements with changes noted . . . . . . . . . . . . . . . . . . . . . . .41

8 TN3270E Telnet Statements: /* NO CHANGES */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .438.1 Telnet profile statements: NO CHANGES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .438.2 Telnet parameter statements in the Telnet profile – NO CHANGES . . . . . . . . . . . . . . . .438.3 Telnet Mapping Statements in the Telnet Profile (VTAM Statements) – NO CHANGES . .44

9 TCPIP DATA and Resolver: /* NO CHANGES */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .459.1 All Configuration Statements in TCPIP.DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

10 OMPROUTE: /* NO CHANGES */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

11 SMTP: /* NO CHANGES */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

12 FTP: /* NO CHANGES */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4612.1 All FTP.DATA Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

13 IBM Health Checker for z/OS: /* V2R3 ADD & CHANGES */ . . . . . . . . . . . . . . . . . . . . .5013.1 IBM Health Checks new to V2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5013.1.1 ICSF_OPTIONS_CHECKS - /* V2R3 ADD */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5013.1.2 ICSF_UNSUPPORTED_CCA_KEYS - /* V2R3 ADD */ . . . . . . . . . . . . . . . . . . . . . . .5113.1.3 JES_NJE_SECURITY and JES_NJE_SECURITY_ssname - /* V2R3 ADD */ . . . . . .5213.1.4 RACF_ENCRYPTION_ALGORITHM - /* V2R3 ADD */ . . . . . . . . . . . . . . . . . . . . . . .5413.1.5 RACF_PASSWORD_CONTROLS - /* V2R3 ADD */ . . . . . . . . . . . . . . . . . . . . . . . . .5413.1.6 RACF_RRSF_RESOURCES - /* V2R3 ADD */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5413.1.7 RSM_HVCOMMON - /* V2R3 ADD */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5513.1.8 RSM_INCLUDE1MAFC - /* V2R3 ADD */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5513.1.9 RSM_MINIMUM_REAL - /* V2R3 ADD */. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5513.1.10 USS_INETD_UNSECURE_SERVICES - /* V2R3 ADD */ . . . . . . . . . . . . . . . . . . . . .5613.1.11 USS_SUPERUSER - /* V2R3 ADD */. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5613.1.12 XCF_CF_STR_ENCRYPT - /* V2R3 ADD */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5613.1.13 ZFS_VERIFY_COMPRESSION_HEALTH - /* V2R3 ADD */ . . . . . . . . . . . . . . . . . . .5613.2 IBM Health Checks with changes in V2R3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5713.2.1 ASM_PLPA_COMMON_USAGE - /* V2R3 CHANGE */ . . . . . . . . . . . . . . . . . . . . . .5713.2.2 CSVTAM_VIT_OPT_STDOPTS - /* V2R3 CHANGE */ . . . . . . . . . . . . . . . . . . . . . . .5713.2.3 CNZ_Task_Table - /* V2R3 CHANGE */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5813.2.4 RACF_classname_ACTIVE - /* V2R3 CHANGE */ . . . . . . . . . . . . . . . . . . . . . . . . . .5913.2.5 RACF_SENSITIVE_RESOURCES - /* V2R3 CHANGE */ . . . . . . . . . . . . . . . . . . . . .5913.2.6 USS_KERNEL_PVTSTG_THRESHOLD - /* V2R3 CHANGE */. . . . . . . . . . . . . . . . .61

Based on generally Available Public Documentation and Presentations vii


13.2.7 USS_PARMLIB - /* V2R3 CHANGE */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6313.3 IBM Health Checks removed from V2R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6513.3.1 CSAPP_SMTPD_MAIL_RELAY - /* V2R3 REMOVED */ . . . . . . . . . . . . . . . . . . . . . .6513.3.2 ZOSMIGV2R2_NEXT_CS_LEGACYDEVICE - /* V2R3 REMOVED */ . . . . . . . . . . . .6513.3.3 ZOSMIGV2R2_NEXT_CS_SENDMAILCLIEN - /* V2R3 REMOVED */ . . . . . . . . . . .6513.3.4 ZOSMIGV2R2_NEXT_CS_SENDMAILDAEMN - /* V2R3 REMOVED */ . . . . . . . . . .6513.3.5 ZOSMIGV2R2_NEXT_CS_SENDMAILMSA - /* V2R3 REMOVED */. . . . . . . . . . . . .6513.3.6 ZOSMIGV2R2_NEXT_CS_SENDMAILMTA - /* V2R3 REMOVED */ . . . . . . . . . . . . .6513.3.7 ZOSMIGV2R2_NEXT_CS_SMTPDDAEMON - /* V2R3 REMOVED */. . . . . . . . . . . .6513.3.8 ZOSMIGV2R2_NEXT_CS_SMTPDMTA - /* V2R3 REMOVED */. . . . . . . . . . . . . . . .6513.3.9 ZOSMIGV2R2_Next_CS_TFTP - /* V2R3 REMOVED */ . . . . . . . . . . . . . . . . . . . . . .65

14 Parmilb Members: /* V2R3 ADD */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6614.1 FXEPRMxx (IBM Function Registry for z/OS) - /* NEW in V2R3 */ . . . . . . . . . . . . . . . . .66

15 Parmlib Keywords: /* V2R3 CHANGES */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6815.1 BPXPRMxx - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6815.2 CEEPRMxx - /* Clarification added to V2R3 */. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6915.3 CLOCKxx - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6915.4 DEVSUPxx - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7115.5 DIAGxx - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7215.6 GRSCNFxx (global resource serialization config) - /* New usage note in V2R3 */ . . . . . .7415.7 IEADMCxx (DUMP command parmlib) - /*New use example in V2R3 */ . . . . . . . . . . . .7515.8 IEAOPTxx (OPT parameters) - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . .7515.9 IEASYSxx (symbol definitions and IEASYSxx members) - /* Changed in V2R3 */. . . . . .7515.9.1 CON - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7615.9.2 DRMODE - /* Removed from V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7715.9.3 FXE - /* New in V2R3 */. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7715.9.4 HZSPROC - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7715.9.5 IZU - /* New in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7815.9.6 LFAREA - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7815.9.7 REAL - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8315.9.8 VRREGN - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8315.10 IEFOPZxx (data set optimization configuration) - /* Changed in V2R3 */ . . . . . . . . . . . .8315.11 IGDSMSxx (storage mgmt subsys def) - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . .8415.12 IGGCATxx (DFSMS catalog configuration) - /* Changed in V2R3 */ . . . . . . . . . . . . . . . .8715.13 IKJTSOxx (TSO/E commands & programs) - /* New parameter in V2R3 */ . . . . . . . . . .8815.14 IXGCNFxx (system logger initialization parameters) - /* New parameters in V2R3 */. . . .8815.15 IZUPRMxx (configure IBM z/OS Mgmt Facility) - /* Changed in V2R3 */. . . . . . . . . . . . .8915.16 PROGxx (authorized program list, exits, LNKLST sets and LPA) - /* Changed in V2R3 */. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9015.17 SMFLIMxx (specifying region and memlimit values) - /* Changed in V2R3 */ . . . . . . . . .9015.18 SMFPRMxx (system mgmnt facilities (SMF) parameters) - /* Changed in V2R3 */ . . . . .9115.19 VATLSTxx (volume attribute list) - /* Changed in V2R3 */ . . . . . . . . . . . . . . . . . . . . . . . .9215.20 Complete list of Parmlib Members with changes noted: . . . . . . . . . . . . . . . . . . . . . . . .93

16 Static System Symbols – /* NO CHANGES */ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

viii Based on generally Available Public Documentation and Presentations


Based on generally Available Public Documentation and Presentations 1


3 MVS SYSTEM COMMANDS: /* V2R3 ADD & CHANGE */

3.1 MVS System Commands New to V2R3

3.1.1 SETOMVS command - /* New keyword / attribute in V2R3 */

The SC_EXITTABLE 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.

The optional UNMOUNT|NOUNMOUNT attribute was added to the VERSION statement.

SETOMVS command syntax (excerpt)

SC_EXITTABLE='sc_exittable' **Added to V2R3 **

Enables installations to attach exit routines to z/OS UNIX System Services syscalls. Exit routines that are associated with the exit points BPX_PRE_SYSCALL and BPX_POST_SYSCALL will run when the syscalls defined in SC_EXITTABLE is run. BPX_PRE_SYSCALL exit routines will run before the defined syscall and BPX_POST_SYSCALL exit routines will run after the defined syscall.

Specifying SC_EXITTABLE causes performance degradation. The more syscall exits that you define, the greater the performance degradation. Syscall stubs must be in uppercase.

The SC_EXITTABLE statement specifies the path name of a z/OS UNIX file. This file is intended to contain a list of z/OS UNIX System Services syscall stubs that the user wants to attach exit routines to.

By specifying a null sc_exittable, the SC_EXITTABLE value is reset to null. An example is shown as follows:SC_EXITTABLE = ''

SERV_LPALIB=('dsname ','volser ')

Specifies the target service library where the z/OS UNIX System Services modules that are to be built into LPA are located. dsname is a 1-to-44 character value that represents a valid load library data set name. The alphabetic characters in the load library name must be uppercase. volser is a 1-to-6 character value representing a valid volume serial number for the volume that contains the specified load library. The alphabetic characters in the volume serial number must be uppercase. The library data set must be on the specified volume or the specification will not be accepted and an error will occur during the parsing of the statements.

If a null dsname is specified, SERV_LPALIB is reset to null. It does not matter what is specified for volser if dsname is null.

SERV_LINKLIB=('dsname ','volser ')

Specifies the target service library where the z/OS UNIX System Services modules that are to be loaded into the private area of the OMVS address space are located. dsname is a 1-to-44 character value that represents a valid load library data set name. The alphabetic characters in the load library name must be uppercase. volser is a 1-to-6 character value that represents a valid volume serial number for the volume that contains the specified load library. The alphabetic characters in the volume serial number must be uppercase. The SETOMVS command library data set must reside

2 Based on generally Available Public Documentation and Presentations


on the volume specified or the specification will not be accepted and an error will occur during the parsing of the statements.

If a null dsname is specified, SERV_LNKLIB is reset to null. It does not matter what is specified for volser if dsname is null.

VERSION='nnnn '

VERSION('nnnn '|*[,UNMOUNT|NOUNMOUNT])

The VERSION statement applies only to systems that are exploiting shared file systems. VERSION allows multiple releases and service levels of the binaries to coexist and participate in shared file systems. A directory with the value nnnn specified on VERSION is dynamically created at system initialization under the sysplex root that is used as a mount point for the version file system. This directory, however, is only dynamically created if the root file system for the sysplex is mounted read/write. When SYSPLEX(YES) is specified, you must also specify the VERSION parameter.

Specify UNMOUNT to turn on the version auto-unmount option, which will cause the VERSION_AUTO_UNMOUNT attribute to be set for the version file system. If unspecified, NOUNMOUNT is the default at system initialization. If the version string ’nnnn’ is ’/’ (slash), the version auto-unmount option will be set to NOUNMOUNT regardless of what is specified.

Note: nnnn is a case-sensitive character string no greater than 8 characters in length. It indicates a specific instance of the version file system. The most appropriate values for nnnn are the name of the target zone, SYSR1, or another qualifier meaningful to the system programmer. For example, if the system is at V2R9, you can specify REL9 for VERSION.

The VERSION value is substituted in the content of symbolic links that contain $VERSION. For scenarios that describe the use of the version file system, see the section on shared file systems in a sysplex in z/OS UNIX System Services Planning.

You can also dynamically turn on or off the VERSION_AUTO_UNMOUNT attribute using the SETOMVS command.

SETOMVS VERSION=(’string’,UNMOUNT|NOUNMOUNT)

Using the SETOMVS command:

• If 'string' is specified but not UNMOUNT or NOUNMOUNT, then the current version auto-unmount option is used.

• You can specify * instead of ’string’ in order to change only the version auto-unmount option.

3.1.2 SETIOS command - /* New keyword in V2R3 */

SETIOS command syntax (excerpt)



HYPERPAV={NO or BASEONLY or YES or XPAV} ** Added to V2R3 **Specifies the use of HyperPAV mode. Use of this keyword changes the mode of operation of HyperPAV-capable DASD control units to the requested mode.

HYPERPAV=NOSpecifies that HyperPAV mode is not to be used.

HYPERPAV=BASEONLYSpecifies that I/O is to be run only on non-PAV-alias devices in HyperPAV mode.

HYPERPAV=YESSpecifies that HyperPAV mode is to be used.

HYPERPAV=XPAVSpecifies that HyperPAV mode is to be used, and wherever possible, allow aliases to be used for peer control units in the defining alias management group (AMG). This HyperPAV mode is also known as SuperPAV mode. Control units on a storage controller with the exact same paths, in order, and those that share the alias management group number, as defined by the storage controller, are eligible to share alias devices when the system is operating in SuperPAV mode.

3.1.3 DISPLAY FXE command - /* New in V2R3 */

New DISPLAY FXE command, “Displaying function enablement state information”

Displaying function enablement state information

Use the DISPLAY FXE command to display the current enablement state of individual functions in the IBM Function Registry for z/OS.

Parameters

{VENDOR|VN}=vendorname

A string identifying the owning vendor area by name, with optional wildcard use:

• You can use an asterisk (‘*’) to match a sequence of zero, one, or more characters.

• You can use a question mark (‘?’) to match a single arbitrary character.

• Any comparisons to actual registry values for matching purposes will be case-insensitive.

{VENDORSLOT|VS}=vendorslot

A number identifying the owning vendor area by the vendor area slot number in the anchor table. Slot numbers start at 1.

{PRODUCT|PN}=productname

A string identifying the owning product area by name, with optional wildcard use:






[PRODUCTSLOT|PS}=productslot

A number identifying the owning product area by the product area slot number in the owning vendor area table. Slot numbers start at 1.

{PRODUCTID|PID}=productID

A string qualifying the owning product area further using a product ID. Note that although this is shown as optional in the command syntax, this parameter is required to successfully match those products in the registry which are set up with a product ID, for example to distinguish different instances or versions of the same product.

You can use wildcards, as follows:



Any comparisons to actual registry values for matching purposes will be case-insensitive.

{INSTANCEID|IID}=instanceID

A string qualifying the owning product area further, using an instance ID. Note that although this is shown as optional in the command syntax, this parameter is required to successfully match those products in the registry that are set up with an instance ID, for example to distinguish different instances or versions of the same product.





{FUNCTION|FN}=functionname

A string identifying the function entry by name, with optional wildcard use:




{FUNCTIONSLOT|FS}=functionslot

A number identifying the owning function entry by the function entry slot number in the owning product area. Slot numbers start at 1.

{FUNCTIONUPDTYPE|FUNCUPDTYPE|FUT}={AUTHONLY|ANYAUTH}

Selects the list of function entries in the owning product area, based on authorization:

AUTHONLY

Selects the list of function entries, in the owning product area, which can only be updated by authorized code and the SETFXE command. This is the default value.

ANYAUTH

Selects the list of function entries, in the owning product area, which can be updated by code of any authorization level (unauthorized code is required to use the FXECNTRL service), or the SETFXE command.

STATE

Displays the enablement state (enabled or disabled) of the selected functions.



3.1.4 DISPLAY OAM,CONFIG command - /* New in V2R3 */

Created new DISPLAY OAM,CONFIG command.

Added new DISPLAY OAM,CONFIG command to table.

Displaying OAM component information

Use the DISPLAY OAM,CONFIG command to display the configuration for the OAM component of DFSMS. Current OAM subsystem and address space configuration will be displayed as well as OAMplex membership.

L=a, name, or name-a

Specifies the display area (a), console name (name), or both (name-a) where the display is to appear.

If you omit this operand, the display is presented in the first available display area or the message area of the console through which you enter the command.

Note: For a detailed description of the output of the DISPLAY OAM,CONFIG command, see the description of message CBR1960I in z/OS MVS System Messages, Vol 4 (CBD-DMO).

3.1.5 DISPLAY XCF command - /* New parameters in V2R3 */

New parameters added to DISPLAY XCF for display of the encryption state of coupling facility structures.

Displaying cross system coupling facility (XCF) information

Use the DISPLAY XCF command to display cross system coupling information in the sysplex.



Syntax

The syntax of the DISPLAY XCF command (excerpt):

ENCRYPTED ** Added to V2R3 **

User structure data written to the coupling facility structure and residing in the coupling facility structure is encrypted.

NOTENCRYPTED

User structure data written to the coupling facility structure and residing in the coupling facility structure is not encrypted.

ENCMISMATCH

A coupling facility structure with an encryption state (encrypted or not encrypted) that does not match the CFRM policy specification.

• This can identify the following:

• Invalid CFRM policy specification of ENCRYPT(YES) for lock structures that do not support encryption.

• Coupling facility structures with a CFRM pending policy change for the ENCRYPT attribute. The pending policy change can be resolved through deallocation of structure in the coupling facility, structure rebuild processing or the REALLOCATE process.

If pending policy changes exist for a coupling facility structure, this pending policy information will be used to determine if an encryption state mismatch exists.

3.1.6 CHNGDUMP command - /* New options in V2R3 */

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.

New SDUMP,TYPE=XMEMT support for adding cross-memory ASIDs of the originally requested, non-exempt target ASIDs to console initiated dumps.



Setting the dump modes and options

Use the following form of the CHNGDUMP command to set the dump modes and put specified options in the dump options lists.

Syntax (excerpt):

SDUMP,TYPE=XMEMT

Set the SDUMP system dump options list to “cross memory of target ASIDs”. Specifying TYPE=XMEMT causes the SVC dump to dump private storage (depending on the SDATA options that are in effect) from the active cross memory address spaces of the originally requested, non-exempt target address spaces specified on the ASID/JOBNAME and TSONAME parameters on the DUMP command. The added XMEMT ASIDs are listed in message IEA047I.

The installation can use the CHNGDUMP command to set XMEMT to Yes or No. This setting can be overridden by the XMEMT= setting, the DUMP command REPLY, or the IEADMCxx parmlib member. The following table shows the XMEMT settings and results for each scenario.

SDUMP,MAXTNDSP=(time1,time2,time3)

Specifies the maximum time, in seconds, that an SVC dump keeps tasks non-dispatchable for different categories of address spaces.



time1

Defines the maximum time that one or more tasks in system resources manager (SRM) critical address spaces are kept non-dispatchable.

time2

Defines the maximum time that one or more tasks in SRM important address spaces are kept non-dispatchable.

time3

Defines the maximum time that one or more tasks in SRM normal address spaces are kept non-dispatchable.

Usage notes:

• By default, SDUMP processing does not reset task non-dispatchability when data capture is proceeding.

• The time intervals are positional. Omitted values result in the default behavior for MAXTNDSP.

• If more than one time value is updated, the values must be enclosed in parentheses.

• The time values can be altered or disabled by using the SET option.

• A blank after MAXTNDSP= triggers an end-of-command and enables the default behavior for MAXTNDSP.

• When MAXTNDSP=(3,,) is specified, it indicates that only the tasks in critical address spaces get reset to dispatchable after 3 seconds. This result can also be achieved by specifying MAXTNDSP=3 or MAXTNDSP=(3).

• When using a value such as MAXTNDSP=(0,0,7), it indicates that tasks in critical and important address spaces are never set as non-dispatchable, and normal address spaces are reset dispatchable after 7 seconds.

• The address space category is determined by the system resources manager (SRM) by using the Workload Manager (WLM) service class. For more information, see System-provided service classes in z/OS MVS Planning: Workload Management.

3.1.7 DUMP command - /* New keyword in V2R3 */

New keyword, XMEMT = YES or NO, is supported on the reply to the DUMP command.

Specifying dump options

You must use the REPLY command to respond to message IEE094D.

The REPLY command syntax for specifying dump options is:

R id,U

or

R id[,ASID=(n[,n]...)][,JOBNAME=(name[,name]...)][,TSONAME=(name[,name]...)][,DSPNAME=(dspname-entry[,dspname-entry]...)]

[,{PROBDESC|PROB|PD}=key-spec][,REMOTE=(request[,request]...)][,SDATA[=(option[,option]...)][,STOR=(beg,end[,beg,end]...)]

[,STRLIST=(s-option[,s-option]...)][,DEFERTND=Yes|No][,XMEMT=Yes|No][,CONT|,END]

XMEMT=YES or NO

Specifies whether SDUMP processing includes private storage from active cross-memory environment of the non-exempt target ASIDs originally requested on ASID/JOBNAME/TSONAME parameters on the DUMP command. The behavior depends on the SDATA options that are in effect.



This behavior can also be controlled by the TYPE=XMEMT setting on the CHNGDUMP command. See “Example: How CHNGDUMP commands affect dump modes and options” on page 187 for a summary of how CHNGDUMP and DUMP options affect the overall result of XMEMT.

When XMEMT is in effect, processing for the DUMP command attempts to dump local storage from other ASIDs that are in a cross-memory relation with the eligible target ASIDs. The added XMEMT ASIDs are listed in message IEA047I in z/OS MVS System Messages, Vol 6 (GOS-IEA)).

3.1.8 SETFXE command - /* New in V2R3 */

New “SETFXE command”.

Use the SETFXE command to set the enablement state of individual functions in the IBM Function Registry for z/OS.

Syntax

The complete syntax for the SETFXE command is:

Parameters

{VENDOR|VN}=vendorname





{VENDORSLOT|VS}=vendorslot


{PRODUCT|PN}=productname





[PRODUCTSLOT|PS}=productslot


{PRODUCTID|PID}=productID

A string qualifying the owning product area further using a product ID. Note that although this is shown as optional in the command syntax, this parameter is requir ed to successfully match those products in the registry which are set up with a product ID, for example to distinguish different instances or versions of the same product.







{INSTANCEID|IID}=instanceID

A string qualifying the owning product area further, using an instance ID. Note that although this is shown as optional in the command syntax, this parameter is required to successfully match those products in the registry that are set up with an instance ID, for example to distinguish different instances or versions of the same product.





{FUNCTION|FN}=functionname





{FUNCTIONSLOT|FS}=functionslot


{FUNCTIONUPDTYPE|FUNCUPDTYPE|FUT}={AUTHONLY|ANYAUTH}


AUTHONLY

Selects the list of function entries, in the owning product area, which can only be updated by authorized code and the SETFXE command. This is the default value.

ANYAUTH

Selects the list of function entries, in the owning product area, which can be updated by code of any authorization level (unauthorized code is required to use the FXECNTRL service), or the SETFXE command.

STATE

Displays the enablement state (enabled or disabled) of the selected functions.

ENABLED={YES|NO}

The desired enablement state to be set in the selected function entry.



3.1.9 SET command - /* New parameter in V2R3 */

New FXE parameter on the “SET command”.

FXEPRMxx: Control the IBM Function Registry for z/OS.

Syntax (excerpt)

FXE={x1|(x1, . . .,xn)}

The two alphanumeric (A-Z,0-9) or national (@,#,$) characters that identify the one or more FXEPRMxx parmlib members to be processed by the SET command. FXEPRMxx members contain statements that control the IBM Function Registry for z/OS, for example statements that affect the enablement state of individual function entries.

3.1.10 SETLOGR MANAGE command - /* New parameters in V2R3 */

New parameters USEOFFLOADMIN and USESTAGINGMIN are added to “SETLOGR MANAGE command”

Syntax

.

USEOFFLOADMIN(YES|NO)

Specifies whether the system ensures that log stream offload data sets are allocated on the system with a size of at least 1MB, when the LS_SIZE attribute is not specified for the log stream. For more information about planning for log stream offload data sets, see Plan DASD space for system logger in z/OS MVS Setting Up a Sysplex.

The following options are possible:

YES Indicates that the system ensures that log stream offload data sets are allocated on the system with a base minimum size of at least 1MB. If a log stream offload data set is newly allocated with a size smaller than 1MB, logger deletes the data set and allocates a new one with a size of at least 1MB.

The message IXG256I is issued if this occurs. For more information, see z/OS MVS System Messages, Vol 10 (IXC-IZP).



NO Indicates that the system does not ensure the use of the 1MB offload data set size as a base minimum. It is recommended that offload data sets be sized no smaller than 1MB, unless the log stream exploiter specifically recommends a size below 1MB.

You can use the DISPLAY LOGGER,IXGCNF[,MANAGE] command to view the parameter settings for configuring the system logger.

STAGING

Specifies the system logger policy on the system for managing log stream staging data sets.

USESTAGINGMIN(YES|NO)

Specifies whether the system ensures that log stream staging data sets are allocated on the system with a size of at least 10MB, when the STG_SIZE attribute is not specified for the log stream. For more information about planning for staging data set use, see Plan space for staging data sets in z/OS MVS Setting Up a Sysplex.

The following options are possible:

YES Indicates that the system ensures that log stream staging data sets are allocated on the system with a base minimum size of at least 10MB. If a log stream staging data set is allocated with a size smaller than 10MB, logger deletes the data set and allocates a new one with a size of at least 10MB.


NO Indicates that the system does not ensure the use of the 10MB staging data set size as a base minimum.

It is recommended that staging data sets be sized no smaller than 10MB, unless the log stream exploiter specifically recommends a size below 10MB.

You can use the DISPLAY LOGGER,IXGCNF[,MANAGE] command to view the parameter settings for configuring the system logger.

3.1.11 SETXCF MODIFY command - /* New parameter in V2R3 */

New parameter ENCRYPTKEY to generate encryption keys for coupling facility structures, see “SETXCF MODIFY command”.

Syntax (excerpt):

STRNAME or STRNM={strname |ALL}

Specifies a structure name pattern identifying the name of one or more coupling facility structures that are to be modified. The structure name pattern can be up to 16 characters long. ALL or * can be specified to modify all structures, or a valid structure name followed by an optional wildcard (*) suffix can be specified. A valid structure name begins with an uppercase



alphabetic character (A – Z) and can also contain numeric characters and the four special characters: $, @, #, _.

ALTER=DISABLED

CF structure alter processing is to be disabled for matching structures. Starting CF structure alter processing for such structures are not permitted.

ALTER=ENABLED

CF structure alter processing is to be enabled for matching structures.

ENCRYPTKEY ** Added to V2R3 **

All structures in the active CFRM policy with names matching the structure name pattern specified and defined with ENCRYPT(YES) in the active CFRM policy are assigned a new encryption key generated using ICSF services. Any structures defined in the administrative policies in the active CFRM couple data set that match the names of the affected structures in the active CFRM policy are also updated. The change takes affect immediately for the relevant unallocated structures. The change will become a pending CFRM policy change for the relevant allocated structures. For more information on encryption key management for coupling facility structures, see the information on encrypting structure data in z/OS MVS Setting Up a Sysplex.

Example: To generate a new encryption key that is applied to all structures matching BIG*, enter:

SETXCF MODIFY,STRNAME=BIG*,ENCRYPTKEY

The following shows examples of messages the system issues showing the results of the message:

IXC562I SETXCF COMMAND TO MODIFY THE ENCRYPTION KEYFOR STRUCTURE(S) IN CFRM POLICY CFCRYPT ACCEPTEDIXC512I POLICY CHANGE IN PROGRESS FOR CFRM 149

TO MAKE CFCRYPT POLICY ACTIVE.1 POLICY CHANGE(S) PENDING.

IXC121I CFRM ENCRYPT STATUS CHANGE: ADMINISTRATIVE DATA KEYS HAVE BEEN UPDATED.IXC563I SETXCF COMMAND COMPLETED: ENCRYPTION KEYCHANGED IMMEDIATELY FOR 1 STRUCTURE(S),ENCRYPTION KEY CHANGE PENDING FOR 1 STRUCTURE(S)

IXC513I COMPLETED POLICY CHANGE FOR CFRM.CFCRYPT POLICY IS ACTIVE.



3.2 MVS System Commands Changed in V2R3Added information about read-only devices in “Device assignment” and “Responding to failing devices”.

Device assignment

Operationally, the assignment of devices is influenced by:

• 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.

Responding to failing 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.

3.2.1 DEVSERV command - /* Changed in V2R3 */

Use the DEVSERV command to request a display of the status of DASD and tape devices. The response is a display of basic status information about a device, a group of devices, or storage control units, and optionally can include a broad range of additional information.

You can display: ** Changed in V2R3 **

• Logical mode and read-only access of the device

Examples

Example 4: ** Changed in V2R3 **

To display the status of SMS-controlled device 430 and the seven devices whose addresses follow it, enter:

ds s,430,8

This command would produce the following display:

IGD001I 11:49:20 DEVSERV SMS 455UNIT,TYPE ,MD,VOLUME,VOLSTAT STORGRP, SGSTAT

430 ,3380 ,OR,XP0101,ENABLED SXP01 ,ENABLED

431 ,3380 ,AR,XP0201,ENABLED SXP02 ,ENABLED

432 ,3380 ,AR,XP0202,ENABLED SXP02 ,ENABLED




436 ,3380 ,OR,338001,STRG/RSDNT, VOLUME NOT MANAGED BY SMS

437 ,3380 ,AR,SMSPCK,STRG/RSDNT, VOLUME NOT MANAGED BY SMS

Note: Indications in the MD column are: O=online, A=allocated, F=offline, R=read-only.

Example 6: ** Changed in V2R3 **

This example shows devices configured with read-only access. If record caching has not been installed, the RC column in the third header line is left blank.

Issuing DEVSERV P,430,2 produces this display:



devserv p,430,2IEE459I 16.24.41 DEVSERV PATHS 572

UNIT DTYPE MD CNT VOLSER CHPID=PATH STATUSRTYPE SSID CFW TC DFW PIN DC-STATE CCA DDC CYL CU-TYPE

00430,3380D ,AR,000,XP0101,25=+ 2E=+IE YY NN N SIMPLEX C0 01 885 3990-3

00431,3380E ,OR,000,XP0101,25=+ 2E=+IE YY NN N SIMPLEX C1 01 1770 3990-3

************************ SYMBOL DEFINITIONS ************************** A = ALLOCATED O = ONLINE R = READ-ONLY + = PATH AVAILABLE

3.2.2 DISPLAY SMS command - /* Changed in V2R3 */

Updated “Displaying storage management subsystem information” with information regarding OAM in both classic and multiple OAM configurations.

Syntax (excerpt):

OAM

If both optical libraries and tape libraries are defined in the SMS configuration, the system displays the optical library information followed by the tape library information in a classic OAM configuration. In a multiple OAM configuration, only the tape library information is displayed.

Note: This operand is not valid when issued from a TSO/E terminal in OPERATOR mode.

OAMXCF

Displays OAM XCF status if OAM is a member of an OAMplex. This command is only valid in a classic OAM configuration. In a multiple OAM configuration, the ODIFY,oam,DISPLAY,OAMXCF command must be used to display OAM XCF status.

3.2.3 DISPLAY OAM command - /* Changed in V2R3 */

Changed to add entry to DISPLAY OAM command.

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:

Command/Keyword Authority Resource-Name

DISPLAY OAM READ MVS.DISPLAY.OAM



Syntax (excerpt):

3.2.4 MODIFY command - /* Changed in V2R3 */

Changed to include support for modifying an OAM configuration using the F OTIS command.

Managing the object access method (OAM)

Use the MODIFY OAM command to display information about the object access method (OAM) or to request that OAM perform a specified service: object management, space management, or recovery functions.

F OAM,parameters

** Changed in V2R3 **Use the MODIFY OTIS command to modify an OAM configuration.

F OTIS,parameters

For a detailed discussion of the MODIFY OAM and MODIFY OTIS command parameters, see the z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support, and the z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Tape Libraries.

3.2.5 DISPLAY VIRTSTOR,HVSHARE command - /* Changed in V2R3 */

Updated the LFAREA section for “Displaying virtual storage information”.

Displaying virtual storage information

Use the DISPLAY VIRTSTOR command to identify the virtual storage configuration.

Note: The values for DISPLAY VIRSTOR are in decimal.

The following information is displayed in message IAR019I:

If DISPLAY VIRTSTOR,HVSHARE is specified:

• Source of HVSHARE parameter can be a parmlib member, operator supplied, or the default.

• The size of the high virtual shared area in gigabytes.

• The range of the high virtual shared area in gigabytes.

• The amount of shared storage allocated into memory objects in megabytes.

If DISPLAY VIRTSTOR,HVCOMMON is specified:

• Source of HVCOMMON parameter can be a parmlib member, operator supplied, or the default.

• The size of the 64-bit common area in gigabytes.

• The range of the 64-bit common area in gigabytes.

• The amount of 64-bit common area that is allocated in megabytes.

IF DISPLAY VIRTSTOR,LFAREA is specified: ** Changed in V2R3 **

• Source of LFAREA parameter and LFAREA 1 MB and 2 GB utilization statistics are displayed.

Additional real storage utilization statistics can be found via the MODIFY AXR,IAXDMEM command.



L=a, name, or name-a

Specifies the display area (a), console name (name), or both (name-a) where the display is to appear.

If you omit this operand, the display is presented in the first available display area or the message area of the console through which you enter the command.

Note: For the output of the DISPLAY VIRTSTOR command, see the description of message IAR019I in z/OS MVS System Messages, Vol 6 (GOS-IEA).

3.2.6 SETUNI command - /* Parameters changed in V2R3 */

Changed to add Unicode 9.0 support to the SETUNI command.

Parameters changed as follows (see highlights):

ADD,CASE([LOCAL | SPECIAL |NORMAL])[,UNIVER(univer )][,PAGEFIX(YES|NO)][,DSNAME | DSN(dsname )][,VOLSER| VOL(volser )]

Adds the character case conversion tables to the Unicode environment. Local, Special, and Normal are optional and can be defined in the same statement only once.

univer

Specifies the Unicode standard version to be loaded. Valid values are:

UNI300UNI301UNI320UNI401UNI410UNI500UNI600UNI900

dsname

Specifies the name of the data set that contains the specific tables.

The specified dsname must have similar characteristics as the SYS1.SCUNTBL data set provided. The size of the data set can be unequal.

If no dsname is specified, SYS1.SCUNTBL is used as the default.

volser

Specifies the volume serial number of the device on which the tables are to be loaded. volser can be from one- to six-characters.

Example:

SETUNI ADD,CASE,DSN=SYS1.SCUNTBL,VOL=XLAD01

ADD,NORMALIZE | NORM ([normver ])[,PAGEFIX(YES|NO)][,DSNAME |DSN(dsname )][,VOLSER | VOL(volser )]



Adds the normalization tables to the Unicode environment.

normver

Specifies the Unicode standard table version to be loaded. Possible values are one of the following:

UNI301UNI320UNI401UNI410UNI600UNI900

dsname

Specifies the name of the data set that contains the specific tables.

The specified dsname must have similar characteristics as the SYS1.SCUNTBL data set provided. The size of the data set can be unequal.

If no dsname is specified, SYS1.SCUNTBL is used as the default.

volser

Specifies the volume serial number of the device on which the tables are to be loaded. volser can be from one- to six-characters.

ADD,COLLATE | COLL([UCAver ])[,PAGEFIX(YES|NO)][,DSNAME | DSN(dsname )][,VOLSER | VOL(volser )] [[,LOCALE(locale )[,DSNAME(dsname )][,VOLUME|VOL(volser )]] | [,COLRULES(colrules ) [,DSNAME(dsname )][,VOLUME|VOL(volser )]]]

Adds the collation tables to the Unicode environment.

UCAver

Specifies the Unicode Collation Algorithm (UCA) versions . Possible values are one or more of the following:

UCA301UCA400R1UCA410UCA600UNI900



3.3 MVS System Commands removed from V2R3Information relating to shared mode for consoles was removed from “Displaying console status information” on page 282, “Displaying operator information (OPDATA)” on page 404, “SETCON command” on page 657, and “VARY command” on page 926.

3.3.1 DISPLAY CONSOLES command - /* Parameter removed from V2R3 */

Information relating to shared mode for consoles was removed.

Syntax (excerpt):

SHAREDMODE ** Removed from V2R3 **

Displays the status of all MCS, HMCS, SMCS and subsystem consoles that are available in console services shared mode. Use SHAREDMODE to display which consoles will continue to exist in console services shared mode.

Note: EMCS consoles are unaffected by a fallback from console services distributed mode to shared mode.

3.3.2 DISPLAY OPDATA command - /* Parameter removed from V2R3 */


Displaying operator information (OPDATA)

Use the DISPLAY OPDATA command to display operator information (OPDATA). Depending on the operands specified, the display may represent either sysplex-wide data or system-unique data.

The syntax of the DISPLAY OPDATA command is:

MODE ** Removed from V2R3 **

The system issues message CNZ9006I that displays the current Console Services mode and migration status of all systems in the sysplex.



3.3.3 VARY command - /* Information removed from V2R3 */


VARY CN command

Note as it appears in V2R2:

** Removed from V2R3 **6. In console services shared mode, the effect of the VARY attribute command lasts for the

duration of the IPL. In distributed mode, the effect of the command lasts only for the duration of the console being active.

Note as it appears in V2R3:

6. The effect of the VARY attribute command lasts only for the duration of the console being active.

3.4 Complete List of MVS System Commands with changes notedThis is a complete list of MVS System Commands. Details of the noted changes are found in the previous sections.

ACTIVATE command – NO CHANGESCANCEL command – NO CHANGESCHNGDUMP command – /* New options in V2R3 */CMDS command – NO CHANGESCONFIG command – NO CHANGESCONTROL command – NO CHANGESDEVSERV command – /* Changed in V2R3 */DISPLAY command –

DISPLAY CONSOLES command - /* Parameters removed from V2R3 */ DISPLAY FXE command - /* New in V2R3 */ DISPLAY OAM command - /* Changed in V2R3 */

DISPLAY OAM,CONFIG command - /* New in V2R3 */DISPLAY OPDATA command - /* Parameters removed from V2R3 */DISPLAY SMS command - /* Changed in V2R3 */DISPLAY VIRTSTOR,HVSHARE command - /* Changed in V2R3 */DISPLAY XCF command - /* New parameters in V2R3 */

DUMP command – /* New keyword in V2R3 */DUMPDS command – NO CHANGESFORCE command – NO CHANGESHALT command – NO CHANGESIOACTION command – NO CHANGESLIBRARY command – NO CHANGESLOG command – NO CHANGESLOGOFF command – NO CHANGESLOGON command – NO CHANGESMODE command – NO CHANGESMODIFY command – /* Changed in V2R3 */MONITOR command – NO CHANGESMOUNT command – NO CHANGESPAGEADD command – NO CHANGESPAGEDEL command – NO CHANGESQUIESCE command – NO CHANGESREPLY command – NO CHANGESRESET command – NO CHANGESROUTE command – NO CHANGES



SEND command – NO CHANGESSET command – /* New parameter in V2R3 */SETALLOC command – NO CHANGESSETAPPC command – NO CHANGESSETAUTOR command – NO CHANGESSETCEE command – NO CHANGESSETCON command – NO CHANGESSETETR command – NO CHANGESSETFXE command – /* New in V2R3 */SETGRS command – NO CHANGESSETGTZ command – NO CHANGESSETHS command – NO CHANGESSETICSF command – NO CHANGESSETIOS command – /* New keyword in V2R3 */SETLOAD command – NO CHANGESSETLOGR command –

SETLOGR MANAGE command - /* New parameter in V2R3 */SETLOGRC command – NO CHANGESSETMF command – NO CHANGESSETOMVS command – /* New keyword / attribute in V2R3 */SETPROG command – NO CHANGESSETRRS command – NO CHANGESSETSMF command – NO CHANGESSETSMS command – NO CHANGESSETSSI command – NO CHANGESSETUNI command – /* Parameters changed in V2R3 */SETXCF command –

SETXCF MODIFY command - /* New parameter in V2R3 */SLIP command – NO CHANGESSTART command – NO CHANGESSTOP command – NO CHANGESSTOPMN command – NO CHANGESSWAP command – NO CHANGESSWITCH command – NO CHANGESTRACE command – NO CHANGESUNLOAD command – NO CHANGESVARY command – /* Information removed from V2R3 */WRITELOG command – NO CHANGES



4 JES2: /* V2R3 ADD & CHANGE */

4.1 JES2 statements Changed in V2R3.

4.1.1 DEBUG - /* V2R3 Keyword Added */

Modified DEBUG to add EDS=Yes|No.

EDS=Yes|No ** Added to V2R3 **

Specifies whether (YES) or not (NO) JES2 email sender task in JES2 EDS address space should provide additional diagnostic information during communication with the z/OSMF server.

4.1.2 JOBDEF - /* V2R3 Keyword Added */

Modified JOBDEF to add NFY_SUBJECT=string.

Syntax (excerpt):



NFY_SUBJECT=string ** Added to V2R3 **

Specifies the optional character string that is used by JES2 as a subject line in email messages that are sent as a result of processing the NOTIFY JCL statement. Subject line can be up to 128 characters. Enclose string in single quotation marks if text includes blanks or special characters. Adding quotation marks also prevents capitalization of alphabetic characters.

Default: If this parameter is not specified, JES2 provides the default subject line of: z/OS job event notification.

Scope: Single Member.

4.1.3 MASDEF - /* V2R3 Keyword Added */

Modified MASDEF to add ESUBSYS=emergency_subsystem_name=.

Syntax (excerpt):

ESUBSYS=emergency_subsystem_name ** Added to V2R3 **

Specify the 1 to 4 character subsystem name to be used for the emergency subsystem. If the name is not defined, its definition is added at JES2 initialization. If it is a defined name and it is in active use, message HASP430 is issued and JES2 fails to initialize.

If an emergency subsystem name is not provided, a default of HASP is used. If HASP is not defined, its definition is added at JES2 initialization. If the name is in active use, a new default of HASA is used. If HASA is in use, a new default of HASB is used. If HASB is in use, a new default of HASC is used, and so on.



4.1.4 NETSERV - /* V2R3 Keywords Added */

Modified NETSERV to add SECURE keywords.

Syntax (excerpt):

SECURE=OPTIONAL|REQUIRED|USE_SOCKET ** Added to V2R3 **

Indicates whether the NETSERV should accept only connection requests with a secure protocol in use such as TLS/SSL. When SECURE=REQUIRED is specified, the NETSERV rejects all connection requests that do not specify a secure protocol is to be used for the connection. When SECURE=OPTIONAL is specified, the NETSERV allows connections with or without a secure protocol in use.

The default, USE_SOCKET, inherits the SECURE setting from the SOCKET statement associated with the NETSERV. If the SOCKET says SECURE=YES, then processing is the same as specifying ECURE=REQUIRED on the NETSERV.

To specify that the NETSERV should use NJENET-SSL (2252) as the PORT it is listening on and the default port for outgoing connections, but not require all connections to use TLS/SSL, you must specify SOCKET SECURE=YES on the socket that is associated with the NETSERV and set the NETSERV to SECURE=OPTIONAL.



4.1.5 NJEDEF - /* V2R3 Keywords Added */

Modified NJEDEF to add PRECHECK=YES|NO and VERIFY_SUBNET=YES|NO

Syntax (excerpt):

PRECHECK=YES|NO ** Added to V2R3 **

Indicates whether NJE jobs that are marked dubious (due to the VFYPATH or VERIFY_SUBNET specification) must pass additional verification processing before being allowed to run on the local node. The pre-check ensures that the job can pass verification without any submitter information being passed to the security product. Specifying PRECHECK=YES can result in security failures for jobs from nodes indicated as trusted in RACF (if the job is marked as dubious). These same jobs may pass verification when PRECHECK=NO is specified. This setting has no effect on jobs that are not marked dubious.

VERIFY_SUBNET=YES|NO ** Added to V2R3 **

Specifies whether subnet path verification is done for jobs arriving by way of NJE. Verification ensures that jobs that claim to originate from a node within the local subnet (subnet that the local node is in) and indicate to run on a node in the local subnet arrive from an adjacent node that is also within the local subnet. Jobs that do not match this criteria are marked dubious and are subject to a validation precheck (based on the NJEDEF PRECHECK setting). This setting has no effect if the local node is not within a subnet (NODE(xx) SUBNET= is blank for the local node) and for jobs that indicate they are from a node that is not in the local subnet.



4.1.6 NODE(xxxxxxxx) - /* V2R3 Keyword Added */

Modified NODE(xxxxxxxx) to add VFYPATH=YES|NO to Modification keywords and Selection limiting keywords.

Syntax (excerpt):

. . . .

. . . .

. . . .

VFYPATH=YES|NO ** Added to V2R3 **

Specifies whether path verification processing is done for jobs that indicate they originated at this node. This keyword only applies if the node is the local node (specified as OWNNODE on NJEDEF) or a node that is defined as DIRECT=YES. Jobs that do not pass path verification are marked dubious and are subject to a validation precheck (based on the NJEDEF PRECHECK setting). Validation is based on the adjacent node from which the job arrived, the node the job claims to originate from, the intended execution node, and the VFYPATH setting of NODE statement defining the job's originating node.



4.1.7 OUTDEF - /* V2R3 Keyword Removed */

Modified to remove WS_OPT=YES|NO keyword.

Syntax (excerpt):

. . . .

WS_OPT=No|Yes ** Removed from V2R3 **

Enables (Yes) or disables (No) JOE index based SYSOUT work selection optimization. For details see z/OS JES2 Initialization and Tuning Guide.

No Disables JOE index based SYSOUT selection optimization. SYSOUT work selection reverts to the z/OS Version 1.13 level of JES2 work selection processing.

Yes Enables JOE index based SYSOUT selection optimization.

Modification: $T OUTDEF operator command.

Scope: MAS

4.1.8 RDR(nn) - /* V2R3 Keyword Removed */

Modified RDR(nn) to remove AUTO keyword.

Syntax (excerpt):

. . . .



4.2 Complete list of JES2 statements with changes notedThis is a complete list of JES2 statements. Details of the noted changes are found in the previous two sections.

APPL(jxxxxxxx) - No ChangesBADTRACK - No ChangesBUFDEF - No ChangesCKPTDEF - No ChangesCKPTSPACE - No ChangesCOMPACT - No ChangesCONDEF - No ChangesCONNect - No ChangesD INITINFO - No ChangesD LOADMOD(jxxxxxxx) - No ChangesD MODule(jxxxxxxx) - No ChangesD OPTsdef - No ChangesD SUBNET(jxxxxxxx) - No ChangesDEBUG - /* V2R3 Keyword Added */DESTDEF - No ChangesDEStid(xxxxxxxx) - No ChangesESTBYTE - No ChangesESTIME - No ChangesESTLNCT - No ChangesESTPAGE - No ChangesESTPUN - No ChangesEXIT(nnn) - No ChangesFSS(accccccc) - No ChangesGRPDEF - No ChangesINCLUDE - No ChangesInit(nnnn) - No ChangesINITDEF - No ChangesINPUTDEF - No ChangesINTRDR - No ChangesJECLDEF,JES2= - No ChangesJECLDEF,JES3= - No ChangesJOBCLASS - No ChangesJOBDEF - /* V2R3 Keyword Added */JOBPRTY(n) - No ChangesL(nnnnn).JT(n) - No ChangesL(nnnnn).ST(n) - No ChangesLINE(nnnnn) - NJE/RJE BSC Lines - No ChangesLINE(nnnnn) -NJE/RJE SNA Lines - No ChangesLINE(nnnnn) – NJE TCP/IP Lines - No ChangesLOADmod(jxxxxxxx) - No ChangesLOGON(nnn) - No ChangesMASDEF - /* V2R3 Keyword Added */MEMBer(nn) - No ChangesNAME - No ChangesNETACCT - No ChangesNETSERV(nnn) - /* V2R3 Keywords Added */NJEDEF - /* V2R3 Keywords Added */NODE(xxxxxxxx) - /* V2R3 Keyword Added */OFF(n).JR - No ChangesOFF(n).JT - No Changes



OFF(n).SR - No ChangesOFF(n).ST - No ChangesOFFLOAD(n) - No ChangesOPTsdef - No ChangesOUTCLASS(v) - No ChangesOUTDEF - /* V2R3 Keyword Removed */OUTPRTY(n) - No ChangesPCEDEF - No ChangesPRINTDEF - No ChangesPROCLIB(xxxxxxxx) - No ChangesPRT(nnnnn) - No ChangesPUN(nn) - No ChangesPUNCHDEF - No ChangesR(nnnn).PR(m) - No ChangesR(nnnnn).PU(m) - No ChangesR(nnnnnn).RD(m) - No ChangesRDR(nn) - /* V2R3 Keyword Removed */RECVOPTS - No ChangesREDIRect(vvvvvvvv) - No ChangesREP - No ChangesREQJOBID - No ChangesRMT(nnnnn) - BSC RJE Workstation - No ChangesRMT(nnnnn) - SNA RJE Workstation - No ChangesSMFDEF - No ChangesSOCKET(xxxxxxxx) - No ChangesSPOOL - No ChangesSPOOLDEF - No ChangesSSI(nnn) - No ChangesSUBTDEF - No ChangesTPDEF - No ChangesTRACE(n) - No ChangesTRACEDEF - No ChangesVERify - No ChangesZAPJOB - No Changes



5 JES3: /* V2R3 ADD & CHANGE */

5.1 JES3 statement with keywords or parameters New to V2R3.

5.1.1 CLASS - /* V2R3 Keyword Added */

Modified to add GDGBIAS=JOB|STEP keyword.

Syntax (excerpt):

GDGBIAS= ** Added to V2R3 **

Specifies how relative references to a generation data set in a DD JCL statement are resolved. If the job's JOB JCL statement includes the GDGBIAS= keyword, the job CLASS specification for GDGBIAS is ignored.

JOB

Relative references to a generation data set are resolved on a job basis. The system establishes the relationship between the relative generation number and the absolute generation number when the generation data set is first referenced in the job. This relationship is consistent throughout the job.

STEP

Relative references to a generation data set are resolved on a job step basis. The system establishes the relationship between the relative generation number and the absolute generation number when the generation data set is first referenced in each job step. Each job step that references the generation data set establishes a new relationship.

If GDGBIAS is not specified or an invalid value is used, JES3 uses the default value JOB.



5.1.2 NETSERV - /* V2R3 Keyword Added */

Modified to add SECURE=OPTIONAL|REQUIRED keyword.

SECURE= ** Added to V2R3 **

Indicates whether the Netserv address space should accept only connection requests with a secure protocol in use such as TLS/SSL. When SECURE=REQUIRED is specified, the Netserv addressSpace rejects all connection requests that do not specify a secure protocol is to be used for the connection. When SECURE=OPTIONAL is specified, the default, the Netserv address space allows connections with or without a secure protocol in use.

5.1.3 NJERMT - /* V2R3 Keyword Added */

Modified to add PRECHECK=YES|NO keyword.

Syntax (excerpt):

. . . .

PRECHECK= ** Added to V2R3 **

Indicates whether NJE jobs that are marked dubious (because of the VFYPATH specification) must pass more validation processing before being allowed to run on the home node. The pre-check validation ensures that the job can pass validation without any submitter information being passed to the security product. This could result in jobs from nodes indicated as trusted in RACF that worked with PRECHECK=NO to fail when PRECHECK=YES is specified (because they are marked as dubious). This setting has no effect if the job is not marked dubious. The default is YES.

PRECHECK=YES

Indicates that NJE jobs marked dubious undergoes the additional validation on the home node.

PRECHECK=NO

Indicates that NJE jobs do not undergo more verification on the home node, regardless of being marked dubious.



Security Usage:

1. Use the expected password (EXPWD) parameter to specify a password that the home node expects to receive from a directly connected BSC or TCP/IP node. The password allows a remote node to start a communication line to the home node. You can define the password (PWD) parameter that the home node must send to a directly connected BSC or TCP/IP node This password allows the home node to start a communication line to the remote node. In addition, the NJERMT statement contains the EXSIG and SIG passwords for dial-up lines and BSC connections.

2. Use the PWCNTL parameter to specify whether job passwords should be sent encrypted, sent without encryption, or checked only at the local node.

3. Use the SECSIGNON parameter (valid for TYPE=TCPIP only) to indicate that the signon procedure includes additional checking using the encryption of a random string to confirm the identity of the node. When SECSIGNON is specified, PWD and EXPWD password values are not used.

4. Use the TLS parameter (valid for TYPE=TCPIP only) to indicate that the TCP/IP transmission uses the Transport Layer Secure facility.

5. Use the VFYPATH and PRECHECK parameters to control whether inbound NJE jobs should be marked dubious, and whether such NJE jobs marked dubious should be revalidated.



5.2 Complete list of JES3 statements with changes notedThis is a complete list of JES3 statements. Details of the noted changes are found in the previous section.

ACCOUNT - No ChangesBADTRACK - No ChangesBUFFER - No ChangesCIPARM - No ChangesCLASS - /* V2R3 Keyword Added */COMMDEFN - No ChangesCOMMENT - No ChangesCOMPACT - No ChangesCONSOLE - No ChangesCONSTD - No ChangesDEADLINE - No ChangesDESTDEF - No ChangesDEVICE - No ChangesDEVICE - No ChangesDEVICE - No ChangesDYNALDSN - No ChangesDYNALLOC - No ChangesENDINISH - No ChangesENDJSAM - No ChangesFORMAT - No ChangesFSSDEF - No ChangesGROUP - No ChangesHWSNAME - No ChangesINCLUDE - No ChangesINTDEBUG - No ChangesMAINPROC - No ChangesMSGROUTE - No ChangesNETSERV - /* V2R3 Keyword Added */NJECONS - No ChangesNJERMT - /* V2R3 Keyword Added */OPTIONS - No ChangesOUTSERV - No ChangesRESCTLBK - No ChangesRESDSN - No ChangesRJPLINE - No ChangesRJPTERM - No ChangesRJPWS - No ChangesSELECT - No ChangesSETACC - No ChangesSETNAME - No ChangesSETPARAM - No ChangesSETRES - No ChangesSOCKET - No ChangesSPART - No ChangesSTANDARDS - No ChangesSYSID - No ChangesSYSOUT - No ChangesTRACK - No Changes



6 VTAM: /* NO CHANGES */

7 TCPIP PROFILE: /* V2R3 CHANGES */

7.1 TCP/IP Statements for which support was removed from V2R3

7.1.1 DEVICE and LINK statements

7.1.1.1 LAN Channel Station and OSA devices statement – LINK statement for token-ring network or PC network LCS - /* V2R3 REMOVED */

7.1.1.2 LAN Channel Station and OSA devices statement – LINK statement for FDDI LCS - /* V2R3 REMOVED */

This part of the Syntax removed in V2R3:



7.1.1.3 MPCOSA devices statement - /* V2R3 REMOVED */

This part of the Syntax removed in V2R3:



7.2 TCP/IP Statements which were changed in V2R3

7.2.1 GLOBALCONFIG statement - /* V2R3 CHANGED */



7.2.2 IPCONFIG statement - /* V2R3 CHANGED */

OLD (V2R2):

NEW (V2R3):



7.2.3 IPCONFIG6 statement – /* V2R3 CHANGED */

OLD (V2R2):

Syntax (excerpt):

NEW (V2R3):

Syntax (excerpt):



7.2.4 NETMONITOR statement – /* V2R3 CHANGED */



7.2.5 SMFCONFIG statement – /* V2R3 CHANGED */

Changes to Type 119 Options in V2R3:



7.2.6 TRANSLATE statement – /* V2R3 CHANGED */

OLD (V2R2):

NEW (V2R3):

7.3 Complete List of TCP/IP Statements with changes notedARPAGE statement - No ChangesAUTOLOG statement – No ChangesBEGINROUTES statement – No ChangesBSDROUTINGPARMS statement – No ChangesDEFADDRTABLE statement – No ChangesDELETE statement – No ChangesDEVICE and LINK statements - /* V2R3 CHANGED */

CTC devices statement – No ChangesLAN Channel Station and OSA devices statement -

LINK statement for token-ring network or PC network LCS - /* V2R3 REMOVED */LINK statement for FDDI LCS - /* V2R3 REMOVED */

MPCIPA OSA-Express QDIO devices statement - /* V2R3 CHANGED */MPCIPA HiperSockets devices statement – No ChangesMPCOSA devices statement - /* V2R3 REMOVED */MPCPTP devices statement – No ChangesVIRTUAL devices statement – No ChangesGLOBALCONFIG statement - /* V2R3 CHANGED */HOME statement – No ChangesINCLUDE statement – No ChangesINTERFACE statements – No Changes

IPAQENET OSA-Express QDIO interfaces statement – No ChangesIPAQIDIO HiperSockets interfaces statement – No ChangesVIRTUAL interfaces statement – No ChangesIPAQENET6 OSA-Express QDIO interfaces statement – No ChangesIPAQIDIO6 HiperSockets interfaces statement – No ChangesLOOPBACK6 interface statement - No Changes MPCPTP6 interfaces statement - No Changes VIRTUAL6 interfaces statement – No Changes

IPCONFIG statement - /* V2R3 CHANGED */IPCONFIG6 statement - /* V2R3 CHANGED */



IPSEC statement – No ChangesITRACE statement – No ChangesLINK statements – See DEVICE and LINK statements above.NETACCESS statement – No ChangeNETMONITOR statement - /* V2R3 CHANGED */OSAENTA statement - No Changes PKTTRACE statement – No ChangesPORT statement – No ChangesPORTRANGE statement – No ChangesPRIMARYINTERFACE statement – No ChangesSACONFIG statement – No ChangesSMFCONFIG statement - /* V2R3 CHANGED */SMFPARMS statement – No ChangesSOMAXCONN statement – No ChangesSRCIP statement – No ChangesSTART statement – No ChangesSTOP statement – No ChangesTCPCONFIG statement – No ChangesTELNETPARMS statement – No Changes Note: This is found in “TN3270 Telnet server” config statements.TRANSLATE statement - /* V2R3 CHANGED */UDPCONFIG statement – No ChangesVIPADYNAMIC statements – No Changes

VIPADEFINE statement – No ChangesVIPABACKUP statement – No ChangesVIPADELETE statement – No ChangesVIPADISTRIBUTE statement – No ChangesVIPARANGE statement – No ChangesVIPAROUTE statement – No ChangesVIPASMPARMS statement – No Changes



8 TN3270E TELNET STATEMENTS: /* NO CHANGES */

Statements are noted as grouped if they appear together within the same Syntax Statement.

8.1 Telnet profile statements: NO CHANGESTELNETGLOBALS statements - No Changes

Group: TELNETGLOBALS, ENDTELNETGLOBALS

TELNETPARMS statements - No Changes

Group: TELNETPARMS, ENDTELNETPARMS

PARMSGROUP statement - No Changes

Group: PARMSGROUP, ENDPARMSGROUP

BEGINVTAM block – No Changes

INCLUDE statement – No Changes

8.2 Telnet parameter statements in the Telnet profile – NO CHANGES BINARYLINEMODE statement – No ChangesCHECKCLIENTCONN statement - No ChangesCLIENTAUTH statement - No ChangesCODEPAGE statement - No ChangesCONNTYPE statement - No ChangesCRLLDAPSERVER statement - No ChangesDBCSTRACE statement - No ChangesDBCSTRANSFORM statement - No ChangesDEBUG statement - No ChangesDISABLESGA statement - No ChangesDROPASSOCPRINTER statement - No ChangesENCRYPTION statement - No ChangesEXPRESSLOGON statement - No ChangesFORMAT statement - No ChangesFULLDATATRACE statement - No ChangesINACTIVE statement - No ChangesINCLUDE statement – No ChangesKEEPINACTIVE statement - No ChangesKEEPLU statement - No ChangesKEYRING statement - No ChangesLUSESSIONPEND statement - No ChangesMAXRECEIVE statement - No ChangesMAXREQSESS statement - No ChangesMAXRUCHAIN statement - No ChangesMAXTCPSENDQ statement - No ChangesMAXVTAMSENDQ statement - No ChangesMSG07 statement - No ChangesNACUSERID statement - No ChangesOLDSOLICITOR statement - No ChangesPASSWORDPHRASE statement - No ChangesPORT, SECUREPORT and TTLSPORT statements - No ChangesPROFILEINACTIVE statement - No ChangesPRTINACTIVE statement - No ChangesREFRESHMSG10 statement - No Changes



SCANINTERVAL and TIMEMARK statements - No ChangesSEQUENTIALLU statement - No ChangesSGA statement - No ChangesSHAREACB statement - No ChangesSIMCLIENTLU statement - No ChangesSINGLEATTN statement - No ChangesSMFINIT and SMFTERM statements - No ChangesSMFPROFILE statement – No ChangesSNAEXT statement - No ChangesSSLTIMEOUT statement - No ChangesSSLV2 and NOSSLV2 statements - No ChangesSSLV3 and NOSSLV3 statements – No ChangesTCPIPJOBNAME statement - No ChangesTELNETDEVICE statement - No ChangesTESTMODE statement - No ChangesTIMEMARK statement – No ChangesTKOGENLU, TKOGENLURECON and NOTKO statements - No ChangesTKOSPECLU, TKOSPECLURECON, and NOTKO statements - No ChangesTN3270E statement - No ChangesTNSACONFIG statement - No ChangesUNLOCKKEYBOARD statement - No ChangesXCFGROUP statement - No Changes

8.3 Telnet Mapping Statements in the Telnet Profile (VTAM Statements) – NO CHANGESALLOWAPPL statement - No ChangesDEFAULTAPPL statement - No ChangesDEFAULTLUS or SDEFAULTLUS statement - No ChangesDEFAULTLUSSPEC or SDEFAULTLUSSPEC statement - No ChangesDEFAULTPRT or SDEFAULTPRT statement - No ChangesDEFAULTPRTSPEC or SDEFAULTPRTSPEC statement - No ChangesDESTIPGROUP statement - No ChangesHNGROUP statement - No ChangesINTERPTCP statement - No ChangesIPGROUP statement - No ChangesLINEMODEAPPL statement - No ChangesLINKGROUP statement - No ChangesLUGROUP or SLUGROUP statements - No ChangesLUMAP statement - No ChangesMONITORGROUP statement - No ChangesMONITORMAP statement - No ChangesPARMSGROUP statement - No ChangesPARMSMAP statement - No ChangesPORT statement - No ChangesPRTDEFAULTAPPL statement - No ChangesPRTGROUP or SPRTGROUP statement - No ChangesPRTMAP statement - No ChangesRESTRICTAPPL statement - No ChangesUSERGROUP statement - No ChangesUSSTCP statement - No Changes



9 TCPIP DATA AND RESOLVER: /* NO CHANGES */

9.1 All Configuration Statements in TCPIP.DATA ALWAYSWTO statement - No ChangesDATASETPREFIX statement - No ChangesDOMAIN statement - No ChangesDOMAINORIGIN statement - No ChangesHOSTNAME statement - No ChangesLOADDBCSTABLES statement - No ChangesLOOKUP statement - No ChangesMESSAGECASE statement - No ChangesNAMESERVER statement - No ChangesNOCACHE statement - No ChangesNOCACHEREORDER statement – No ChangesNSINTERADDR statement - No ChangesNSPORTADDR statement - No ChangesOPTIONS statement - No ChangesRESOLVERTIMEOUT statement - No ChangesRESOLVERUDPRETRIES statement - No ChangesRESOLVEVIA statement - No ChangesSEARCH statement - No ChangesSOCKDEBUG statement - No ChangesSOCKNOTESTSTOR statement - No ChangesSOCKTESTSTOR statement - No ChangesSORTLIST statement - No ChangesTCPIPJOBNAME statement - No ChangesTCPIPUSERID statement - No ChangesTRACE RESOLVER statement - No ChangesTRACE SOCKET statement - No Changes; and # statements - No Changes



10 OMPROUTE: /* NO CHANGES */

11 SMTP: /* NO CHANGES */

12 FTP: /* NO CHANGES */

12.1 All FTP.DATA StatementsACCESSERRORMSGS (FTP server) statement - No ChangesADMINEMAILADDRESS (FTP server) statement - No ChangesANONYMOUS (FTP server) statement - No ChangesANONYMOUSFILEACCESS (FTP server) statement - No ChangesANONYMOUSFILETYPEJES (FTP server) statement - No ChangesANONYMOUSFILETYPESEQ (FTP server) statement - No ChangesANONYMOUSFILETYPESQL (FTP server) statement - No ChangesANONYMOUSFTPLOGGING (FTP server) statement - No ChangesANONYMOUSHFSDIRMODE (FTP server) statement - No ChangesANONYMOUSHFSFILEMODE (FTP server) statement - No ChangesANONYMOUSHFSINFO (FTP server) statement - No ChangesANONYMOUSLEVEL (FTP server) statement - No ChangesANONYMOUSLOGINMSG (FTP server) statement - No ChangesANONYMOUSMVSINFO (FTP server) statement - No ChangesAPPLNAME (FTP server) statement - No ChangesASATRANS (FTP client & server) statement - No ChangesAUTOMOUNT (FTP client & server) statement - No ChangesAUTORECALL (FTP client & server) statement - No ChangesAUTOTAPEMOUNT (FTP client & server) statement - No ChangesBANNER (FTP server) statement - No ChangesBLKSIZE (FTP client & server) statement - No ChangesBUFNO (FTP client & server) statement - No ChangesCCONNTIME (FTP client) statement - No ChangesCCTRANS (FTP client) statement - No ChangesCCXLATE (FTP server) statement - No ChangesCHKCONFIDENCE statement (FTP client & server) statement - No ChangesCHKPTFLUSH (FTP client) statement - No ChangesCHKPTINT (FTP client & server) statement - No ChangesCHKPTPREFIX (FTP client) statement - No ChangesCIPHERSUITE (FTP client & server) statement - No ChangesCLIENTERRCODES (FTP client) statement - No ChangesCLIENTEXIT (FTP client) statement - No ChangesCONDDISP (FTP client & server) statement - No ChangesCTRLCONN (FTP client & server) statement - No ChangesDATACLASS (FTP client & server) statement - No ChangesDATACTTIME (FTP client) statement - No ChangesDATAKEEPALIVE (FTP client & server) statement - No ChangesDATATIMEOUT (FTP server) statement - No ChangesDB2 (FTP client & server) statement - No Changes



DB2PLAN (FTP client and server) statement - No ChangesDBSUB (FTP client & server) statement - No ChangesDCBDSN (FTP client & server) statement - No ChangesDCONNTIME (FTP client & server) statement - No ChangesDEBUG (FTP client & server) statement - No ChangesDEBUGONSITE (FTP server) statement - No ChangesDEST (FTP server) statement - No ChangesDIRECTORY (FTP client & server) statement - No ChangesDIRECTORYMODE (FTP client & server) statement - No ChangesDSNTYPE (FTP client & server) statement - No ChangesDSWAITTIME (FTP client & server) statement - No ChangesDSWAITTIMEREPLY (FTP server) statement - No ChangesDUMP (FTP client & server) statement - No ChangesDUMPONSITE (FTP server) statement - No ChangesEATTR (FTP client & server) statement - No ChangesEMAILADDRCHECK (FTP server) statement - No ChangesENCODING (FTP client & server) statement - No ChangesEPSV4 (FTP client) statement - No ChangesEXTENSIONS (FTP client & server) statement - No ChangesFIFOIOTIME (FTP client & server) statement - No ChangesFIFOOPENTIME (FTP client & server) statement - No ChangesFILETYPE (FTP client & server) statement - No ChangesFTPKEEPALIVE (FTP client & server) statement - No ChangesFTPLOGGING (FTP server) statement - No ChangesFWFRIENDLY (FTP client) statement - No ChangesHFSINFO (FTP server) statement - No ChangesINACTIVE (FTP Server) statement - No ChangesINACTTIME (FTP client) statement - No ChangesISPFSTATS (FTP client & server) statement - No ChangesJESENTRYLIMIT (FTP server) statement - No ChangesJESGETBYDSN (FTP server) statement - No ChangesJESINTERFACELEVEL (FTP server) statement - No ChangesJESLRECL (FTP server) statement - No ChangesJESPUTGETTO (FTP server) statement - No ChangesJESRECFM (FTP server) statement - No ChangesKEYRING (FTP client & server) statement - No ChangesLISTLEVEL (FTP server) statement - No ChangesLISTSUBDIR (FTP client & server) statement - No ChangesLOGCLIENTERR (FTP client) statement - No ChangesLOGINMSG (FTP server) statement - No ChangesLRECL (FTP client & server) statement - No ChangesMBDATACONN (FTP client & server) statement - No ChangesMBREQUIRELASTEOL (FTP client & server) statement - No ChangesMBSENDEOL statement (FTP client & server) statement - No ChangesMGMTCLASS (FTP client & server) statement - No ChangesMIGRATEVOL (FTP client & server) statement - No ChangesMVSINFO (FTP server) statement - No ChangesMVSURLKEY (FTP server) statement - No ChangesMYOPENTIME (FTP client) statement - No ChangesNETRCLEVEL (FTP client) statement - No ChangesNONSWAPD (FTP server) statement - No ChangesPASSIVEDATACONN (FTP server) statement - No ChangesPASSIVEDATAPORTS (FTP server) statement - No ChangesPASSIVEIGNOREADDR (FTP client) statement - No Changes



PASSIVEONLY (FTP client) statement - No Changes PASSPHRASE (FTP server) statement - No ChangesPDSTYPE (FTP client & server) statement - No ChangesPORTCOMMAND (FTP server) statement - No ChangesPORTCOMMANDIPADDR (FTP server) statement - No ChangesPORTCOMMANDPORT (FTP server) statement - No ChangesPORTOFENTRY4 (FTP server) statement - No ChangesPRIMARY (FTP client & server) statement - No ChangesPROGRESS (FTP client) statement - No ChangesQUOTESOVERRIDE (FTP client & server) statement - No ChangesRDW (FTP client & server) statement - No ChangesRECFM (FTP client & server) statement - No ChangesREMOVEINBEOF (FTP client & server) statement - No ChangesREPLY226 (FTP server) statement - No ChangesREPLYSECURITYLEVEL (FTP server) statement - No ChangesRESTGET (FTP client) statement - No ChangesRESTPUT (FTP server) statement - No ChangesRETPD (FTP client & server) statement - No ChangesSBDATACONN (FTP client & server) statement - No ChangesSBSENDEOL statement (FTP client & server) statement - No ChangesSBSUB (FTP client & server) statement - No ChangesSBSUBCHAR (FTP client & server) statement - No ChangesSBTRANS (FTP client) statement - No ChangesSECONDARY (FTP client & server) statement - No ChangesSECURE_CTRLCONN (FTP client & server) statement - No ChangesSECURE_DATACONN (FTP client & server) statement - No ChangesSECURE_FTP (FTP client & server) statement - No ChangesSECURE_HOSTNAME (FTP client) statement - No ChangesSECUREIMPLICITZOS (FTP client & server) statement - No ChangesSECURE_LOGIN (FTP server) statement - No ChangesSECURE_MECHANISM (FTP client) statement - No ChangesSECURE_PASSWORD (FTP server) statement - No ChangesSECURE_PASSWORD_KERBEROS (FTP server) statement - No ChangesSECURE_PBSZ (FTP client & server) statement - No ChangesSECURE_SESSION_REUSE (FTP client & srvr) - No ChangesSEQNUMSUPPORT (FTP client) statement - No ChangesSMF (FTP server) statement - No ChangesSMFAPPE (FTP server) statement - No ChangesSMFDCFG (FTP server) statement - No ChangesSMFDEL (FTP server) statement - No ChangesSMFEXIT (FTP server) statement - No ChangesSMFJES (FTP server) statement - No ChangesSMFLOGN (FTP server) statement - No ChangesSMFREN (FTP server) statement - No ChangesSMFRETR (FTP server) statement - No ChangesSMFSQL (FTP server) statement - No ChangesSMFSTOR (FTP server) statement - No ChangesSOCKSCONFIGFILE (FTP client) statement - No ChangesSPACETYPE (FTP client & server) statement - No ChangesSPREAD (FTP client & server) statement - No ChangesSQLCOL (FTP client & server) statement - No ChangesSSLV3 (FTP client & server connection) statement - No ChangesSTARTDIRECTORY (FTP server) statement - No ChangesSTORCLASS (FTP client & server) statement - No Changes



SUPPRESSIGNOREWARNINGS (FTP client & server) statement - No ChangesTAPEREADSTREAM (FTP server) statement - No ChangesTLSCERTCROSSCHECK (FTP client & server) - No ChangesTLSMECHANISM (FTP client & server) statement - No ChangesTLSPORT (FTP client & server) statement - No ChangesTLSRFCLEVEL (FTP client & server) statement - No ChangesTLSTIMEOUT (FTP client & server) statement - No ChangesTRACE (FTP client & server) statement - No ChangesTRACECAPI (FTP client) statement - No ChangesTRAILINGBLANKS (FTP client & server) statement - No ChangesTRUNCATE (FTP client & server) statement - No ChangesUCOUNT (FTP client & server) statement - No ChangesUCSHOSTCS (FTP client & server) statement - No ChangesUCSSUB (FTP client & server) statement - No ChangesUCSTRUNC (FTP client & server) statement - No ChangesUMASK (FTP client & server) statement - No ChangesUNICODEFILESYSTEMBOM (FTP client & server) statement - No ChangesUNITNAME (FTP client & server) statement - No ChangesUNIXFILETYPE (FTP client & server) statement - No ChangesVCOUNT (FTP client & server) statement - No ChangesVERIFYUSER (FTP server) statement - No ChangesVOLUME (FTP client & server) statement - No ChangesWRAPRECORD (FTP client & server) statement - No ChangesWRTAPEFASTIO (FTP client & server) statement - No ChangesXLATE (FTP server) statement - No ChangesFTP server environment variables - No ChangesSOCKS configuration statements in SOCKSCONFIGFILE - No Changes

DIRECT statement - No ChangesSOCKD statement - No Changes



13 IBM HEALTH CHECKER FOR Z/OS: /* V2R3 ADD & CHANGES */

13.1 IBM Health Checks new to V2R3

13.1.1 ICSF_OPTIONS_CHECKS - /* V2R3 ADD */

Description:

The ICSF_OPTIONS_CHECKS examines the value of some of the ICSF installation options that can affect performance.

Reason for check:

The check reports whether the current setting matches the option setting supplied in the parameter or the default setting.

z/OS releases the check applies to:

ICSF FMID HCR7780, HCR7790, HCR77A0, HCR77A1, HCR77B0, and HCR77B1 running on z/OS V1R9, z/OS V1R10, z/OS V1R11, z/OS V1R12, z/OS V1R13, z/OS V2R1, or z/OS V2R2 with PTFs for APAR OA48452 applied. ICSF FMID HCR77C0 and later running on z/OS V2R1 and later.

Type of check (local or remote):

Local

User override of IBM values:

The following sample shows the defaults for customizable values for this check. Use this sample to make permanent check customizations in an HZSPRMxx parmlib member used at IBM Health Checker for z/OS startup. If you just want a one-time only update to the check defaults, omit the first line (ADDREPLACE POLICY) and use the UPDATE statement on a MODIFY hzsproc command. Note that using non-POLICY UPDATEs in HZSPRMxx can lead to unexpected results and is therefore not recommended.

ADDREPLACE POLICY[(policyname)] [STATEMENT(name)]UPDATECHECK(IBMICSF,ICSF_OPTIONS_CHECKS)ACTIVESEVERITY(MEDIUM) INTERVAL(ONETIME) DATE(’date_of_the_change’)PARM('CHECKAUTH(NO),CKTAUTH(NO),KEYAUTH(NO)')REASON(’Your reason for making the update.’))

Parameters accepted:

Yes. The following parameters are supported to identify installation options to be checked:

CHECKAUTH(YES | NO)

Specifies that the check compare the current value of the CHECKAUTH option specified in the ICSF installations options data set. The CHECKAUTH option controls the SAF checking of authorized callers.

Default: NO

CKTAUTH(YES | NO)

Specifies that the check compare the current value of the CKTAUTH option specified in the ICSF installations options data set. The CKTAUTH option controls when CKDS record authentication codes are checked when a CKDS is loaded into the in-storage copy.



Note: The CKTAUTH option was deprecated in FMID HCR77A1. Systems at release HCR77A1 or newer will ignore this option.

Default: NO

KEYAUTH(YES | NO)

Specifies that the check compare the current value of the KEYAUTH option specified in the ICSF installations options data set. The KEYAUTH option controls whether in-storage CKDS records have their record authentication code checked when the record is read by an application.

Note: The KEYAUTH option was deprecated in FMID HCR77A1. Systems at release HCR77A1 or newer will ignore this option.

Default: NO

Verbose support:

No

Debug support:

No

Reference:

For more information on the ICSF installation options, see z/OS Cryptographic Services ICSF System Programmer's Guide.

Messages:

This check issues the following messages:• CSFH0037E

This check also issues the following information message:• CSFH0036I

See in z/OS Cryptographic Services ICSF Messages.

SECLABEL recommended for multilevel security users:

SYSLOW - see z/OS Planning for Multilevel Security and the Common Criteria for information on using SECLABELs.

13.1.2 ICSF_UNSUPPORTED_CCA_KEYS - /* V2R3 ADD */

Description:

The Cryptographic Coprocessor Feature (CCF) supported cryptographic algorithms that are not supported on newer Crypto Express features. Keys for these unsupported algorithms and services may have been stored in the CKDS and PKDS. The ICSF_UNSUPPORTED_CCA_KEYS health check will list the label of records in the active CKDS and PKDS with keys that are not support by the current cryptographic features. The ICSF administrator can use the list to determine if the records can be deleted. The administrator can archive the records if the format of the CKDS and PKDS is the common record format (KDSR).

For the PKDS, all records with DSS public or private key tokens will be listed.

For the CKDS, all records with DES ANSI X9.17 keys and DES data-translation keys (key type DATAXLAT) will be listed.

The ICSF_UNSUPPORTED_CCA_KEYS check will list the labels of all records regardless of the state of the record. This means that records that are archived or inactive will appear in the list.



Reason for check:

The ICSF_UNSUPPORTED_CCA_KEYS check allows the ICSF administrator to identify all records in the cryptographic key data sets which are unsupported by the cryptographic features.

13.1.3 JES_NJE_SECURITY and JES_NJE_SECURITY_ssname - /* V2R3 ADD */

Description:

This check examines the various network job entry (NJE) parameters associated with the listed subsystem to verify that they are configured using the best practices. In particular, it ensures that any node that is considered trusted by the installation security product (allowed to submit jobs without additional authentication) has been configured with appropriate parameters.

• Use check JES_NJE_SECURITY for the primary subsystem (JES2 or JES3).

• Use check JES_NJE_SECURITY_ssname to check the security setup of secondary JES2 subsystems that you may be running. ssname is the subsystem name associated with a secondary subsystem.

For this check to work properly, it has to determine from the security product the NJE nodes that are considered trusted. By default, this check is set up for installations that use RACF as their security product. If you are not using RACF, you need to alter the parameter NJEEXEC for this EXEC. This should be set to either the name of the exec specified by your security product for this check, or the string NONE if your security product does not have the concept of trusted nodes.

RACF considers a node to be trusted if one of the following is true:

• The node is a local node. A local node is indicated by its inclusion in the member list of the &RACLNDE profile in the RACFVARS class.

• The node name is covered by a profile in the NODES class with a universal access (UACC) value greater than READ. A profile is considered to cover the node name if the first qualifier matches the node name (generic characters may be used) and the 2nd qualifier matches the string "USERJ" (to indicate that the profile pertains to incoming jobs). The third qualifier (user ID) is not considered when determining if there is a match.

See Providing security for JES in the z/OS Security Server RACF Security Administrator's Guide for more information.

If a node is a local node, the NODES class is not inspected for matches on that node name.

Authorization Required when using RACF as the security product: For installations using RACF as their security product, the APIs used by this check require that the user ID assigned to the IBM Health Checker for z/OS started task have the following authority:

• READ access to the IRR.RADMIN.RLIST resource in the FACILITY class. This allows the check to use the R_admin callable service (IRRSEQ00) to extract general resource profiles.

• RACF command authority to list profiles in the RACFVARS and NODES classes. On a z/OS V2R1 system, IBM recommends assigning the user ID the AUDITOR attribute. On a z/OS V2R2 system, IBM recommends assigning the user ID the ROAUDIT attribute, unless it is sharing the RACF database with a z/OS V2R1 system on which the check will run.

Note: This check may take longer to run than most checks. The time required is a function of the number of NJE nodes defined, the number of NODES class profiles defined, the number of NODES profiles that include a RACF variable in the profile name, and the number of members in the RACFVARS profile for each variable.

Reason for check:

NJE security is based on the integrity of the data in the headers associated with jobs sent over NJE. This integrity is ensured by carefully securing each node and connection in a network. In many cases, it is not possible for an installation to secure all the NJE nodes in a network. Generally, this is



not a problem because jobs entering a system must pass authentication checks before they can run. However, if trusted nodes exist in the network, then the normal authentication checks are bypassed. If there are trusted nodes in your network, you need to take addition precautions to ensure the integrity of the jobs being received.

This check is intended to report on settings that could cause an exposure on your node or on other nodes in your network, on a node by node basis. If you use trusted nodes, you need to take steps to ensure that jobs from dubious sources are not allowed to run without requiring authentication to your security product. Checks for trusted nodes (if any exist on your system) are more stringent than non-trusted nodes. But all node definitions are verified to ensure your system is securing the network properly. As with all security, it is only as good as the weakest link. Your entire network is only as secure as the weakest node that is allowed to join it.

Authentication of nodes connecting to your network is the first line of defense. This can take the form of simple passwords coded in the JES initialization decks, profiles in the APPCLU class that define keys used during signon, or Transport Layer Security (TLS) based authentication and certificate processing. Some form of password authentication should be used for all nodes that connect to your network. For nodes that are considered trusted, TCP/IP connections with AT/TLS active is considered best practice. In general, AT/TLS should be combined with node passwords to ensure complete authentication during NJE signon. However, NJE networks often include nodes that are not under the control of one data center or set of programmers. Even if you secure all the NJE signons over which you have control, there could be other parts of your network that are not as secure or have no security (such as a test system, for example). If you have trusted nodes, this can provide an attacker a way to send jobs into the network you secured. To prevent any exposures, you need to ensure that data that claims to come from a trusted node actually arrived via a known and secure path.

The most obvious way to do this is to make a direct connection to the node:

• In JES3, this implies defining the trusted node with TYPE= on the NJERMT statement (required in JES3 to connect to a node). So, the idea of adjacent and directly connected node is essentially the same thing in JES3.

• In JES2, just connecting to an adjacent node is not enough. You must take the additional step of defining the node as DIRECT=YES on the JES2 NODE statement. This is because JES2 supports dynamic routing of work in the network. If a connection goes down, JES2 will normally search its routing tables for an alternate path to the destination node. If one exists JES2 will send the work down the alternate path. This is great for getting things to their intended destination, but this will introduce “store and forward” processing to a job destined to a trusted node. Store and forward can be a problem because it introduces uncertainty about the source of data. The DIRECT=YES parameter on the NODE statement in JES2 forces jobs to only be sent directly to that node. If there is no adjacent connection to the node, no attempt to find an alternate path will be made. Coding DIRECT=YES (or the equivalent with other networking products) on both ends of a connection to a trusted node ensures jobs will only be directly sent between the nodes. Routing based security then ensures anything that arrives on another path is marked as dubious and jobs will be fully validated before being allowed to execute.

JES2 has an alternative to specifying DIRECT=YES for nodes located within a small, controlled environment called a SUBNET. SUBNETs were created to simplify network routing. Each node in JES2 can optionally be defined as being in a SUBNET. Conceptually, if you are outside a subnet and want to send something to a node within a subnet, then all you need to do is get the data to any node in the same subnet as the destination and it will ensure the data gets to where it needs to go.

Subnets can be used to represent nodes in a company (all nodes in company Z are defined in company X’s JES2 as being in the same subnet) or just a location or district. What makes subnets interesting from a security standpoint is a fallout of the basic design that requires that a job on a node inside a subnet that has a destination that is also inside the subnet, cannot be sent out of the subnet to get there. Put more simply, if nodes A and B are in the same subnet and A sends



something to node B, the subnet definition ensures that the data being sent to B will never be sent out of the subnet. So if something is claiming to come from node A and is destined to node B arrives from outside the subnet A and B are in, then routing based security will mark the job as dubious (and require it to authenticate at the destination node).

If you define the nodes in your data center (or the location that you control) as being in a subnet (on all the nodes in the data center or location) and you secure the NJE signons within the nodes in the subnet, you can ensure that the origin information associated with the job claiming to be from within the subnet is correct. However, you should ensure that you have strict control over all nodes in the subnet. As subnets get larger, strong control over signon procedures gets harder and exceptions can creep in (“it’s only a test node”). If a node does not have strict signon security, keep that node out of the subnet. You can trust the node, but use a direct connection to establish the trust, not a subnet. Remember it only takes one weak signon to create a possible exposure.

13.1.4 RACF_ENCRYPTION_ALGORITHM - /* V2R3 ADD */

Description:

The RACF_ENCRYPTION_ALGORITHM check verifies that the KDFAES algorithm is used for password protection.

Reason for check:

RACF_ENCRYPTION_ALGORITHM allows RACF to verify that the KDFAES algorithm is used for password protection.

13.1.5 RACF_PASSWORD_CONTROLS - /* V2R3 ADD */

Description:

The RACF_PASSWORD_CONTROLS health check examines the client's RACF password control settings and raises an exception when recommended settings are not being used.

Using the IBM supplied default Health Check parameter values, an exception would be raised if either:

• RACF is not enabled for mixed-case passwords.

• The invalid password revocation count is greater than three (3).

• The maximum days a password/passphrase is valid is greater than 90.

• The INITSTATS function is not in effect.

Reason for check:

RACF_PASSWORD_CONTROLS allows RACF to examine the client's RACF password control settings and raises an exception when recommended settings are not being used.

13.1.6 RACF_RRSF_RESOURCES - /* V2R3 ADD */

Description:

The RACF_RRSF_RESOURCES check examines the security characteristics of the RRSF INMSG/OUTMSG workspace data sets. This check is functionally the same as the RACF_SENSITIVE_RESOURCES check. As its own check, it can be disabled when the Health Checker address space is not authorized to use R_admin to retrieve RRSF INMSG/OUTMSG data set names.

For each of these, the check examines:

• That the data set exists on the expected volume. If the data set does not exist on the volume, a V (volume exception) is placed in the Status (S) column.

• That the resource has baseline protection. The RRSF INMSG/OUTMSG data sets can have a general access as high as NONE.



The check verifies the protection of each data set by extracting its profile and examining the UACC, WARNING status, and the ID(*) entry in the access list if one exists. In addition, if there is no profile protecting a data set, then if NOPROTECTALL or PROTECTALL(WARN) is in effect, the check flags the data set as an exception. The customer can optionally specify a user ID to the check which, if specified, is used to perform a RACF authorization check for the next higher access authority after the highest expected general access authority.

The APIs used by this Health Check require that the user ID assigned to the Health Checker for z/OS address space has the following access:

• IRR.RADMIN.EXTRACT.RRSF in the FACILITY class. READ authority is required to use R_admin to extract RRSF information.

• <subsystem>.TARGET.LIST in the OPERCMDS class. If this resource is protected, READ authority is required.

Reason for check:

RACF_RRSF_RESOURCES allows RACF to examine the security characteristics of the RRSF INMSG/OUTMSG workspace data sets.

13.1.7 RSM_HVCOMMON - /* V2R3 ADD */

Description:

Checks the configured size and current allocation of the high virtual common area (HVCOMMON in parmlib member IEASYSxx). This check issues a warning when the allocation of high virtual storage exceeds a predetermined threshold, and/or when the size of the high virtual common area is less than the default minimum.

Reason for check:

The HVCOMMON setting controls the size of the common area above 2GB, directly affecting how much virtual storage may be common to all jobs on the system. Setting this value too low may cause jobs relying on common high virtual storage to fail. The default suggested value for this area is 64G.

13.1.8 RSM_INCLUDE1MAFC - /* V2R3 ADD */

Description:

Checks to see whether INCLUDE1MAFC(NO) was specified on the IEAYSxx parmlib member LFAREA parameter.

Reason for check:

With z/OS V2R3, the INCLUDE1MAFC(NO) is ignored by the system. INCLUDE1MAFC(YES) is the only accepted specification, which results in the 1M frames associated with the IEASYSxx parmlib member LFAREA parameter to be included in the RCEAFC count. INCLUDE1MAFC(YES) reduces the likelihood of paging in the system.

13.1.9 RSM_MINIMUM_REAL - /* V2R3 ADD */

Description:

Compares the amount of central storage against a minimum suggested value.

Reason for check:

For optimal results, ensure that the amount of central storage is adequate to meet the needs of the applications that run on your system. System with small amounts of central storage are susceptible to memory pressure which leads to significant delays or outages. Starting with z/OS V2R3, IBM recommends a minimum of 8G of central storage to help improve system availability.



13.1.10 USS_INETD_UNSECURE_SERVICES - /* V2R3 ADD */

Description:

This check reports unsecure services that are configured for the inetd daemon.

Reason for check:

The inetd daemon can be configured to accept connections for services that are considered unsecure. These services are by nature unsecure because they require user authentication that uses cleartext (unencrypted) sockets. A remote attacker can exploit this vulnerability to sniff logins and passwords.

13.1.11 USS_SUPERUSER - /* V2R3 ADD */

Description:

The check verifies that the SUPERUSER option in BPXPRMxx contains a userID that is defined to the security product and has an OMVS segment with a UID of 0.

The check will run once per IPL unless an error is found. It will also run any time SUPERUSER is changed via a SETOMVS or SET OMVS system command.

Reason for check:

The userID value for SUPERUSER must be defined to the security product and have an OMVS segment with a UID of 0.

13.1.12 XCF_CF_STR_ENCRYPT - /* V2R3 ADD */

Description:

This check raises an exception when the current resident data format of structure data (encrypted or non-encrypted) in allocated structures is not consistent with the effective ENCRYPT parameter for the structure in the CFRM policy. Additionally, the check will report an exception when a change to the cryptographic encryption key used for structure data encryption is pending for any allocated encrypted structure. Cryptographic encryption key changes can be requested via the SETXCF MODIFY command for structures allocated with encrypted resident data.

Reason for check:

This check verifies that structure data in an allocated structure is consistent with the effective ENCRYPT parameter and cryptographic encryption key for the structure (when the structure data is encrypted) in the CFRM policy.

13.1.13 ZFS_VERIFY_COMPRESSION_HEALTH - /* V2R3 ADD */

Description:

Checks whether all user cache pages are registered with the zEDC Express service when there are compressed file systems.

Reason for check:

zFS performance might be affected when there are compressed file systems and there are cache pages that are not registered with the zEDC Express service.



13.2 IBM Health Checks with changes in V2R3

13.2.1 ASM_PLPA_COMMON_USAGE - /* V2R3 CHANGE */

This Health Check has been updated in z/OS V2R3.

Description:

Looks at the slot usage of the PLPA and Common page data sets. The check generates an exception if the combined usage of both data sets meets or exceeds the warning threshold.

Note: If the PLPA and Common page data sets are not defined in the system, informational message ILRH0112I is issued to indicate this condition and the check is stopped from running.

Reason for check:

You should prevent full conditions on the PLPA and Common page data sets.

User override of IBM values: ** Updated in V2R3 **


ADDREPLACE POLICY[(policyname)] [STATEMENT(name)]UPDATECHECK(IBMASM,ASM_PLPA_COMMON_USAGE)INTERVAL(00:30)PARM(’THRESHOLD(80%)’)DATE(’date_of_the_change’)REASON('The reason for the change.')

13.2.2 CSVTAM_VIT_OPT_STDOPTS - /* V2R3 CHANGE */


Description:

Checks to see whether the VTAM Internal Trace (VIT) group option STDOPTS is active.

Reason for check:

IBM suggests that the VIT STDOPTS group option always be activated, since it is almost always required when servicing a VTAM problem.


z/OS V2R1 and later.



ADDREPLACE POLICY[(policyname)] [STATEMENT(name)]UPDATECHECK(IBMCS,CSVTAM_VIT_OPT_STDOPTS)



DATE(’date_of_the_change’)REASON(’Your reason for making the update.’)ACTIVESEVERITY(LOW)INTERVAL(ONETIME)

Debug support:

No

Verbose support:

No


No

Reference:

For more information on defining VTAM Internal Trace parameters, see TRACE for MODULE, STATE (with OPTION) or VTAM internal trace in z/OS Communications Server: SNA Resource Definition Reference.

Messages:

This check issues the following exception messages:

• ISTH006E

See z/OS Communications Server: SNA Messages.


SYSLOW - see z/OS Planning for Multilevel Security and the Common Criteria for information on using SECLABELs.

13.2.3 CNZ_Task_Table - /* V2R3 CHANGE */


Description:

Reports the status of important tasks that run in the CONSOLE address space.

Reason for check:

Using the report generated from this check, installations can determine if there are (real or potential) problems with specific functions of the Consoles component.



ADDREPLACE POLICY[(policyname)] [STATEMENT(name)]UPDATEDATE(’date_of_the_change’)REASON(’Your reason for making the update.’)ACTIVESEVERITY(LOW)INTERVAL(00:15)



13.2.4 RACF_classname_ACTIVE - /* V2R3 CHANGE */


Description:

Each of the RACF_classname_ACTIVE checks examine the status of a single RACF general resource class:

• RACF_UNIXPRIV_ACTIVE

• RACF_FACILITY_ACTIVE

• RACF_TAPEVOL_ACTIVE

• RACF_TEMPDSN_ACTIVE

• RACF_TSOAUTH_ACTIVE

• RACF_OPERCMDS_ACTIVE

• RACF_CSFKEYS_ACTIVE

• RACF_CSFSERV_ACTIVE

• RACF_JESJOBS_ACTIVE

• RACF_JESSPOOL_ACTIVE

Reason for check:

An effective RACF implementation requires that the baseline group of RACF general resource classes listed above be active.




No.



ADDREPLACE POLICY[(policyname)] [STATEMENT(name)]UPDATECHECK(IBMRACF,RACF_classname_ACTIVE),SEVERITY(MED),INTERVAL(24:00),DATE(’date_of_the_change’)REASON(’Your reason for making the update.’)

13.2.5 RACF_SENSITIVE_RESOURCES - /* V2R3 CHANGE */

Description:

The RACF_SENSITIVE_RESOURCES check examines the security characteristics of several system-critical data sets and general resources other than data sets. The output of this check is a list of exceptions flagged.

For each of these, the check examines:

• For system-critical data sets, that the data set exists on the expected volume. If the data set does not exist on the volume, a V (volume exception) is placed in the Status (S) column.



• That the resource has baseline protection. For example, APF data sets can have a general access as high as READ, while the data sets which comprise the RACF data base must have a general access of NONE.

The check verifies the protection of each resource by extracting its profile and examining the UACC, WARNING status, and the ID(*) entry in the access list if one exists. In addition, if there is no profile protecting a data set, then if NOPROTECTALL or PROTECTALL(WARN) is in effect, the check flags the data set as an exception. The customer can optionally specify a user ID to the check which, if specified, is used to perform a RACF authorization check for the next higher access authority after the highest expected general access authority.

The resources above are all “discrete resources”, that is, the resource name is a predictable value. There are other “sensitive” resource names which contain a variable value, often in the form of a data set name or module name. This support enhances the RACF_SENSITIVE_RESOURCES check to examine these resources for a proper baseline protection. These are shown in “Additional “Generic” General Resources for RACF_SENSITIVE_RESOURCES.”

The RACF_SENSITIVE_RESOURCE health check will report on each resource name that it finds, flagging exceptions in a manner consistent with the existing exception flagging. No new messages are planned.

The RACF_SENSITIVE_RESOURCE check will not validate any portion of the “variable” portion of the resource name.

The RACF_SENSITIVE_RESOURCE check will evaluate only the names which begin with the specific high level qualifier. Profiles which contain generic qualifiers or RACF variables in the high level qualifier will not be flagged.

Because of the change in the resources that are checked in the RACF_SENSITIVE_RESOURCES check, the date associated with the check is changed to '20120106' (6 January 2012).

Reason for check:

The system is critically exposed if these resources are not properly protected.






Yes, you can specify a user ID as a parameter. The following example shows keywords you can use to specify an user ID (GENUSER) in the PARM field for RACF_SENSITIVE_RESOURCES. You can specify the following keywords on either HZSPRMxx or on a MODIFY command:

CHECK(RACF_SENSITIVE_RESOURCES)OWNER(IBMRACF)DATE(’date_of_the_change’)PARM(GENUSER)REASON(’Your reason for making the update.’)

The check verifies that the specified user ID is a syntactically valid user ID, that the user ID exists, and that the user ID is active and has not been revoked. If any of these conditions is not true, an error message is written to the IBM Health Checker for z/OS log and the check continues processing as if no parameter had been specified to the check.


The following sample shows the defaults for customizable values for this check. Use this sample to make permanent check customizations in an HZSPRMxx parmlib member used at IBM Health Checker for z/OS startup. If you just want a one-time only update to the check defaults, omit the first line (ADDREPLACE POLICY) and use the UPDATE statement on a MODIFYhzsproc command. Note that using non-POLICY UPDATEs in HZSPRMxx can lead to unexpected results and is therefore not recommended.

ADDREPLACE POLICY[(policyname)] [STATEMENT(name)]UPDATECHECK(IBMRACF,RACF_SENSITIVE_RESOURCES),SEVERITY(HI),INTERVAL(08:00),DATE(’date_of_the_change’)REASON(’Your reason for making the update.’)

13.2.6 USS_KERNEL_PVTSTG_THRESHOLD - /* V2R3 CHANGE */

Description:

This check monitors the current usage of private below-the-bar storage of the UNIX System Services kernel against a suggested threshold.

Reason for check:

Exhausting the kernel private below-the-bar storage will cause unpredictable errors because resources can no longer be obtained, which could potentially bring down z/OS UNIX.





ADDREPLACE POLICY[(policyname)] [STATEMENT(name)]



UPDATE,CHECK(IBMUSS,USS_KERNEL_PVTSTG_THRESHOLD),INTERVAL(00:02),SEVERITY(HIGH),PARM('PVTSTG_HIGH(90%),PVTSTG_MED(85%),PVTSTG_LOW(80%)’),DATE(’date_of_the_change’)REASON(’Your reason for making the update.’)

Debug support:No

Verbose support:No

Parameters accepted:Yes, as follows:

• When not using dynamic severity:

• PVTSTG(pvtstg%) where an integer, 0-100, followed by a %, indicating the threshold percent for usage of kernel private storage below the bar that was available after kernel initialization. An exception message is displayed when system values are equal to or greater than pvtstg%. The severity of the exception message depends on the system's % usage of kernel private storage that is below the bar.

• A percentage of 80-84 is low severity.

• A percentage of 85-89 is medium severity.

• A percentage above 89 is high severity.

• When using user-specified dynamic severity, which is only valid with KERNELSTACKS(ABOVE):

• PVTSTG_HIGH(pvtstg%)

• PVTSTG_MED(pvtstg%)

• PVTSTG_LOW(pvtstg%)

• PVTSTG_NONE(pvtstg%)

pvtsg%

An integer, 0-100 followed by a %, indicating the threshold percent for usage of kernel private storage below the bar that was available after kernel initialization.

When using dynamic severity, you can specify one or more thresholds. If a threshold value for a given severity is not specified, no exception message is issued for that level. If PVTSTG is specified along with any PVTSTG_xxx values, the PVTSTG value is ignored and the exception severity coincides with the specified parameters.



Default: PVTSTG(85%)

You can use synonyms for these parameters as follows:

Reference:None.

Messages:This check issues the following messages:

• BPXH072E

See the BPXH messages in z/OS MVS System Messages, Vol 3 (ASB-BPX).


SYSLOW - see z/OS Planning for Multilevel Security and the Common Criteria for information about using security labels.

13.2.7 USS_PARMLIB - /* V2R3 CHANGE */

Description:

This check compares z/OS UNIX System Services current system settings with \those specified in the BPXPRMxx parmlib members that are used during initialization. If a difference is found, an exception message is issued. For PARM values on the MOUNT statement, the check is case-sensitive; exceptions are raised for otherwise identical values that are expressed in different cases.

If a dynamic symbolic is contained in the value specification for any BPXPRMxx statement, that statement might be flagged as changed because the current dynamic value is different from the value that was used when the BPXPRMXX statement was originally processed.

If the system finds syntax errors in one or more of the BPXPRMxx parmlib members the check issues message BPXH046E. If syntax errors are found, the check does not make a comparison between the system and the parmlib settings. You must correct all syntax errors before the check will compare the system and the parmlib settings. See the explanation for message BPXH046E in z/OS MVS System Messages, Vol 3 (ASB-BPX) for more information.

The z/OS UNIX dynamic settings that are checked are listed in the following table.



• For the FILESYSTYPE statement, the types that are specified in the BPXPRMxx parmlib members are compared to what Physical File Systems are currently running.

• For the ROOT and MOUNT FILESYSTEM statements, these are checked:

• Mount point

• Mode, RDWR for example.

• Automove setting. AUTOMOVE and system list are both treated as AUTOMOVE.

• PARM subparameter

• For the NETWORK statement, only the MAXSOCKETS value is checked for AF_INET and AF_INET6. ** Updated in V2R3 **

• For the VERSION statement, the version auto-unmount attribute keyword that is specified or defaulted in the BPXPRMxx parmlib members is compared against the current auto-unmount attribute, as displayed by D OMVS,O.

For example, if the version file system owning system has statement VERSION('V2R3',UNMOUNT), and non-owning system has statement VERSION('V2R3'), and after IPLing the non-owning system, the operator issues SETOMVS VERSION=('V2R3',UNMOUNT), then the USS_PARMLIB Health Check on the non-owning system will report the difference found as follows:

Reason for check:

When dynamic changes are made to z/OS UNIX, the BPXPRMxx parmlib members should be updated with the changes so that they will be available the next time z/OS UNIX is unitialized.



13.3 IBM Health Checks removed from V2R3The following Health Checks were deleted in z/OS V2R3:

13.3.1 CSAPP_SMTPD_MAIL_RELAY - /* V2R3 REMOVED */

13.3.2 ZOSMIGV2R2_NEXT_CS_LEGACYDEVICE - /* V2R3 REMOVED */

13.3.3 ZOSMIGV2R2_NEXT_CS_SENDMAILCLIEN - /* V2R3 REMOVED */

13.3.4 ZOSMIGV2R2_NEXT_CS_SENDMAILDAEMN - /* V2R3 REMOVED */

13.3.5 ZOSMIGV2R2_NEXT_CS_SENDMAILMSA - /* V2R3 REMOVED */

13.3.6 ZOSMIGV2R2_NEXT_CS_SENDMAILMTA - /* V2R3 REMOVED */

13.3.7 ZOSMIGV2R2_NEXT_CS_SMTPDDAEMON - /* V2R3 REMOVED */

13.3.8 ZOSMIGV2R2_NEXT_CS_SMTPDMTA - /* V2R3 REMOVED */

13.3.9 ZOSMIGV2R2_Next_CS_TFTP - /* V2R3 REMOVED */



14 PARMILB MEMBERS: /* V2R3 ADD */

14.1 FXEPRMxx (IBM Function Registry for z/OS) - /* NEW in V2R3 */

FXEPRMxx contains statements that let you control the IBM Function Registry for z/OS, for example statements that affect the enablement state of individual function entries.

Parameter in IEASYSxx (or issued by the operator)

FXE = {x1|(x1,...,xn)}

The two alphanumeric or national characters, represented by x1 and xn, are appended to FXEPRMxx to identify the FXEPRMxx member or members of parmlib for the IBM Function Registry for z/OS.

Syntax rules for FXEPRMxx

The following syntax rules apply to FXEPRMxx:

• Use columns 1 through 71. Do not use columns 72 through 80 for data; these columns are ignored.

• At least one delimiter (space or comma) is required between a statement and keyword. Delimiters are not required between keywords.

• Comments may appear in columns 1-71 and must begin with "/*' and end with "*/".

Syntax format of FXEPRMxx

IBM-supplied default for FXEPRMxx

There is no default FXEPRMxx parmlib member assumed if you do not specify FXE= in IEASYSxx.

Statements and parameters for FXEPRMxx

{VENDOR|VN}(vendorname)




• Any comparisons to actual registry values for matching purposes will be

• case-insensitive.

{VENDORSLOT|VS}(vendorslot )


{PRODUCT|PN}(productname )







{PRODUCTSLOT|PS}(productslot )


{PRODUCTID|PID}(productID )

A string qualifying the owning product area further using a product ID. Note that although this is shown as optional in the command syntax, this parameter is required to successfully match those products in the registry which are set up with a product ID, for example to distinguish different instances or versions of the same product.





{INSTANCEID|IID}(instanceID )

A string qualifying the owning product area further, using an instance ID.

Note that although this is shown as optional in the command syntax, this parameter is required to successfully match those products in the registry that are set up with an instance ID, for example to distinguish different instances or versions of the same product.





{FUNCTION|FN}(functionname )





{FUNCTIONSLOT|FS}(functionslot )


{FUNCTIONUPDTYPE|FUNCUPDTYPE|FUT}({AUTHONLY|ANYAUTH})


AUTHONLYSelects the list of function entries, in the owning product area, which can only be updated by authorized code and the SETFXE command. This is the default value.

ANYAUTHSelects the list of function entries, in the owning product area, which can be updated by code of any authorization level (unauthorized code is required to use the FXECNTRL service), or the SETFXE command.

ENABLED({YES|NO})

The desired enablement state to be set in the selected function entry.



15 PARMLIB KEYWORDS: /* V2R3 CHANGES */

15.1 BPXPRMxx - /* Changed in V2R3 */

“BPXPRMxx (z/OS UNIX System Services parameters),” was updated:

• To support the ability to unmount the version file system if it is no longer being used in the sysplex, the VERSION statement was updated. It has an optional version auto-unmount attribute keyword that can be set to UNMOUNT or NOUNMOUNT.

• The SC_EXITTABLE statement was added. It enables pre-system call and post-system call exit routines for select z/OS UNIX callable services.

• The USS_SUPERUSER health check can be used to verify that the SUPERUSER parameter contains a user ID that is defined to the security product and has an OMVS segment with a UID of 0.

Syntax (excerpts):

. . . .

. . . .

SCEXITTABLE('sc_exittable') ** Added to V2R3 **

Specifies the path name of a z/OS UNIX file. This file is intended to contain a list of z/OS UNIX syscall stubs that a user wants to enable syscall exits for. The stub names must be in all caps. If a null path name is specified, SC_EXITTABLE is reset to null.

You can change the SC_EXITTABLE path name dynamically by using the SETOMVS or SET OMVS command. To make a permanent change, edit the BPXPRMxx member that will be used for IPLs.

Changes to the SC_EXITTABLE file are not applied immediately. If a change needs to be activated sooner, use the SETOMVS or SET OMVS command to apply the change immediately.

VERSION('nnnn '[,UNMOUNT|NOUNMOUNT]) ** Changed in V2R3 **

The VERSION statement applies only to systems that are exploiting shared file systems. VERSION allows multiple releases and service levels of the binaries to coexist and participate in shared file system. A directory with the value nnnn specified on VERSION is dynamically created at system initialization under the sysplex root that is used as a mount point for the version file system. However,



this directory is only dynamically created if the sysplex root file system is mounted read/write.

Specify UNMOUNT to turn on the version auto-unmount option, which will cause the VERSION_AUTO_UNMOUNT attribute to be set for the version file system if it is mounted on this system. If unspecified, NOUNMOUNT is the default at system initialization. If the version string ’nnnn’ is ’/’ (slash), the version auto-unmount option will be set to NOUNMOUNT regardless of what is specified.

Note: nnnn is a case-sensitive character string no greater than 8 characters in length. It indicates a specific instance of the version file system. The most appropriate values for nnnn are the name of the target zone, &SYSR1, or another qualifier meaningful to the system programmer. For example, if the system is at V2R9, you can specify REL9 for VERSION. When SYSPLEX(YES) is specified, you must also specify the VERSION parameter.

The VERSION value is substituted in the content of symbolic links that contain $VERSION. For scenarios that describe the use of the version file system, see Sharing file systems in a sysplex in z/OS UNIX System Services Planning.

If you are testing or changing to a new maintenance level, dynamically change the VERSION value by using the SETOMVS command.

SETOMVS VERSION=’string’

You can also dynamically turn on or off the VERSION_AUTO_UNMOUNT attribute using the SETOMVS command.SETOMVS VERSION=(’string’,UNMOUNT|NOUNMOUNT)

Using the SETOMVS command:

• If 'string' is specified but not UNMOUNT or NOUNMOUNT, then the current version auto-unmount option is used.

• You can specify * instead of ’string’ in order to change only the version auto-unmount option.

You can also change the settings of this parameter by using SET OMVS=(xx) and SETOMVS RESET=(xx) parmlib specifications.

Note: Do not change VERSION dynamically if you have any users that are logged on or running applications because replacing the system files for these users might be disruptive.

15.2 CEEPRMxx - /* Clarification added to V2R3 */

Guidance regarding the use of the NONOVR option was added to the CEEPRMxx parmlib member

CAUTION:

Runtime options are intended to allow programs, both yours and programs that are supplied by software vendors, to configure how they want to run with Language Environment. Marking runtime options as NONOVR might cripple the capabilities of these programs, prevent them from being tuned properly, inhibit their ability to perform First Failure Data Capture, and prevent them from running. With very few exceptions, IBM strongly discourages customers from marking any runtime option as NONOVR.

15.3 CLOCKxx - /* Changed in V2R3 */

Clarification was added to the TIMEZONE parameter of the CLOCK parmlib member about applications that are required to run with local time equal to UTC.

Along with the ACCURACY keyword, specify the ACCMONINTV keyword to set a user-defined timing interval when the TOD clock accuracy monitor service is to be processed.



Syntax format of CLOCKxx

ACCURACY mmmmm ** Changed in V2R3 **

Specifies an acceptable time deviation for the TOD clock from an external time source in milliseconds, with valid values between 0 and 60000 milliseconds (60 seconds).

When the ACCURACY keyword is specified, the system will also monitor the TOD clock accuracy by issuing message IEA049I to the hardcopy log. Message IEA049I will display the time discrepancy for the TOD clock from an external time source (ETS).

The ACCURACY function will be processed every 60 minutes unless the ACCMONINTV keyword is specified with a user-defined timing interval. Please refer to message IEA049I for additional details on setting the user-defined time interval.

Default: 0, which indicates that the time accuracy check function is not enabled. If the difference between the TOD clock and the external time source time exceeds the ACCURACY value, message IEA032E is issued.

ACCMONINTV mmss | mss ** Added to V2R3 **

Sets a timing interval when the ACCURACY function is to be processed. The ACCMONINTV keyword requires the ACCURACY keyword to be specified and have a nonzero value.

mmss Minutes (mm) and Seconds (ss) in decimal format. Minutes must be between 00 and 60. Seconds must be between 00 and 59.

mss Minutes (m) and Seconds (ss) in decimal format. Minutes must be between 0 and 9. Seconds must be between 00 and 59.

Notes:

• The Seconds (ss) value must always be 2 digits. The Minutes (m or mm) value can be either 1 or 2 digits.

• Specifying ACCMONINTV 000 or 0000 is not valid.

Default: 6000 (60 minutes)



15.4 DEVSUPxx - /* Changed in V2R3 */

Syntax format of DEVSUPxx

“Statements and parameters for DEVSUPxx” are updated with information on enabling or disabling the AOM496I status message for transparent cloud tiering operations.

{ENABLE | DISABLE}( feature )

Enables or disables a particular feature, where feature can be any one of the following choices:

AOM496I ** Added to V2R3 **

Enables or disables the issuing of the AOM496I status message on the console for transparent cloud tiering operations.

ENABLE(AOM496I)

Enables the issuing of the AOM496I status message on the console for transparent cloud tiering operations. The following message is issued when ENABLE(AOM496I) is present in a DEVSUPxx member:

’IEA253I DEVSUP AOM496I IS ENABLED’

DISABLE(PPRCMT)

Disables the issuing of the AOM496I status message on the console for transparent cloud tiering operations. This is the default. The following message is issued when DISABLE(AOM496I) is present in a DEVSUPxx member:

’IEA253I DEVSUP AOM496I IS DISABLED’

Default: DISABLE(AOM496I)

REFVTOC

Enables or disables the automatic REFVTOC function of the Device Manager:

DISABLE(REFVTOC)

When the REFVTOC feature is disabled and the system detects a volume expansion, the system issues message IEA019I, but the VTOC is not rebuilt. An ICKDSF Batch job must be submitted to rebuild the VTOC before the newly added space on the volume can be used.



ENABLE(REFVTOC) ** Changed in V2R3 **

When the REFVTOC feature is enabled and the system detects a volume expansion, the system issues message IEA019I. If the volume is online, the Device Manager causes the volume VTOC to be rebuilt. This allows the newly added space on the volume to be used by the system.

Default: ENABLE(REFVTOC)

PPRCSYMCONFG= ** New in V2R3 **

NO Specifies that the PPRC/Metro Mirror HyperSwap configuration is not symmetrical. This indicates the same volume address is not used to identify primary and secondary volumes in a pair relationship.

YES Specifies that the PPRC/Metro Mirror HyperSwap configuration is symmetrical. This indicates the same volume address is used to identify both primary and secondary volumes in a pair relationship.

Default: NO

A symmetrical logical configuration is a duplicate configuration where the Metro Mirror primary and secondary disk subsystems are configured with the same Logical Subsystem number (LSS) and Channel Connection Address (CCA) pairs. That is the PPRC primary and secondary devices have the same LSS and CCA in the local and remote storage controllers. These configurations are believed to be common as most clients configure Metro Mirror primary and secondary disk subsystems identically. An asymmetrical configuration has logical LSS and CCA numbers different between the local and remote sites.

15.5 DIAGxx - /* Changed in V2R3 */

DIAGxx contains statements that control the following functions: ** New in V2R3 **

Controlling AutoIPL, which can re-IPL z/OS, take a stand alone dump (SADMP), or take a SADMP and have SADMP re-IPL z/OS when it has finished.

Syntax (excerpt):

. . . .

FREEMAINEDFRAMES(NO) ** Changed in V2R3 **

FREEMAINEDFRAMES(YES) [EXCLUDEJOBLIST([job1[,job2 . . .]])]

To enhance performance on IBM z13™ and later hardware, the system cannot free the real frame that is backing a low private virtual page following a FREEMAIN (that is, when the page no longer contains any GETMAIN-assigned storage ranges); however, the system will overwrite the contents of the frame to ensure that sensitive information is removed. Such a frame is referred to as a freemained frame. Freemained frames do not cause the count of frames owned by the address space to be decremented, nor do they cause the count of available frames within the system to be incremented.



FREEMAINEDFRAMES(NO)

Disables the freemained frames feature on a system-wide basis. The high freemained frames feature is also disabled when this option is specified.

FREEMAINEDFRAMES(YES) [EXCLUDEJOBLIST([job1[,job2 . . .]])]

Enables the freemained frames feature, except for the specified jobs. If the job name of either a START, MOUNT, LOGON, or initiated program matches a value specified in the EXCLUDEJOBLIST parameter, that job will be excluded from the freemained frames feature. Up to eight job names may be specified and can include the * and ? wildcard characters, where the * character is allowed in any position.

When you exclude a job, all existing freemained frames, including high freemained frames, are purged from the associated address space.

Reissuing the SET DIAG command with different EXCLUDEJOBLIST values will not increase the total number of excluded jobs; the last EXCLUDEJOBLIST specification overrides any previous specifications.

Disabling this feature for selected jobs will cause performance degradation for the entire system, not just for the specified jobs.

Example: The following statement disables the freemained frames feature for all initiators under JES2:FREEMAINEDFRAMES(YES) EXCLUDEJOBLIST(INIT)

This feature is active by default on z13™ and later hardware and only applies to region private storage below the 2 GB bar, which is defined as subpools 0-127, 129-132, 240, 244, 250-252.

FF31HIGH(NO) ** New in V2R3 **

FF31HIGH(YES) [EXCLUDEJOBLIST([job1[,job2 . . .]])]

To enhance performance on IBM zMidas and later hardware, the system might not free the real frame that is backing a high private or LSQA page following a FREEMAIN (that is, when the page no longer contains any high private GETMAIN-assigned storage ranges); the system will overwrite the contents of the frame to ensure that sensitive information is removed if the frame's key is not 0-7 or not fetch protected. Such a frame is referred to as a high freemained frame. Like Low Private Freemained frames, High Private Freemained Frames do not cause the count of frames owned by the address space to be decremented, nor do they cause the count of available frames within the system to be incremented.

FF31HIGH(NO)

Disables the high freemained frames feature on a system-wide basis.

FF31HIGH(YES) [EXCLUDEJOBLIST([job1[,job2 . . .]])]

Enables the high freemained frames feature, except for the specified jobs. If the job name of either a START, MOUNT, LOGON, or initiated program matches a value specified in the EXCLUDEJOBLIST parameter, that job will be excluded from the freemained frames feature. Up to eight job names may be specified and may include the * and ? wildcard characters, where the * character is allowed in any position. When you exclude a job, all existing high freemained frames are purged from the associated address space. Reissuing the SET DIAG command with different EXCLUDEJOBLIST values will not increase the total number of excluded jobs; the last EXCLUDEJOBLIST specification overrides any previous specifications. Disabling this feature for selected jobs will cause performance degradation for the entire system, not just for the specified jobs.



CBLOC [VIRTUAL24(structure1,structure2, . . .)]

[VIRTUAL31(structure1,structure2, . . .)]

VIRTUAL24

Provides the names of structures to be located in 24-bit virtual storage.

VIRTUAL31

Provides the names of structures to be located in 31-bit virtual storage.

Structure names:

IHALCCA

When a CPU is brought online, the location of its LCCA is determined by which list includes IHALCCA. If neither of the lists include IHALCCA, the LCCA is in 31-bit virtual storage. If both lists include IHALCCA, the resulting location is undocumented. The LCCA of the IPL CPU is built in 24-bit storage before DIAGxx is processed.

If additional standard CPs are brought online later in the IPL process, the IPL CPU is automatically configured offline and back online, with its LCCA located according to the CBLOC specification.

IHAPCCA

When a CPU is brought online, the location of its PCCA is determined by which list includes IHAPCCA. If neither of the lists include IHAPCCA, the PCCA is in 31-bit virtual storage. If both lists include IHAPCCA, the resulting location is undocumented. The PCCA of the IPL CPU is built in 24-bit storage before DIAGxx is processed.

If additional standard CPs are brought online later in the IPL process, the IPL CPU is automatically configured offline and back online, with its PCCA located according to the CBLOC specification.

IHAASVT

When the system is IPLed, the location of its ASVT is determined by which list includes IHAASVT. If neither of the lists include IHAASVT, the ASVT is in 24-bit virtual storage. If both lists include IHAASVT, the resulting location is undocumented.

CNZSSICB ** Added to V2R3 **

When SSI Functions 9, 10, or 14 are called upon, their respective control blocks will be created in 31-bit storage.

15.6 GRSCNFxx (global resource serialization config) - /* New usage note in V2R3 */

The SYNCHRES parameter of “Statements and parameters for GRSCNFxx” has been enhance with additional notes for clarification.

SYNCHRES{(YES)|(NO)}

Indicates whether the system defined in the GRSCNFxx MATCHSYS parameter is to have synchronous reserve processing activated.

Default: YES

Notes:• If SYNCHRES=YES, but GRS cannot complete the I/O to reserve a device, message ISG363I is

issued. The request continues as if SYNCHRES=NO.

• A reserve is done synchronously regardless of any SYNCHRES=NO specification if ZHPF is enabled and the device operates I/O in Transport Mode.



15.7 IEADMCxx (DUMP command parmlib) - /*New use example in V2R3 */

A new example explaining how to include private storage of XMEMT ASIDs that have an active cross-memory relationship with originally requested, non-exempt target ASIDs is added to “Statements and parameters for IEADMCxx”.

Following is a new examples of IEADMCxx usage:

To request that a dump include private storage of XMEMT ASIDs that have an active cross-memory relationship with the originally requested, non-exempt target ASIDs 3B and 41:

a. Create the member and specify the target XMEMT ASIDs. For example, if you created EADMCGV.

SDATA=(CSA,SQA,LSQA,RGN),XMEMT=YES,ASID=(3B,41)

b. Issue the following console command:

DUMP TITLE=(XMEMT dump),PARMLIB=GV

15.8 IEAOPTxx (OPT parameters) - /* Changed in V2R3 */

Routing options: ** New in V2R3 **

[,RTCAPLEADTIME=x ]

RTCAPLEADTIME=x ** New in V2R3 **

Specifies how far in advance an upcoming soft capping should influence WLM's sysplex routing recommendations. When the estimated time to capping is less than x minutes, WLM considers the upcoming soft capping in its routing recommendations. Otherwise, it does not consider the upcoming soft capping in its routing recommendations.

Value range: 0 - 60

Default: 0

15.9 IEASYSxx (symbol definitions and IEASYSxx members) - /* Changed in V2R3 */

IEASYSxx parameters

DeletedDRMODE - This parameter is no longer supported. Any specification of it has no effect on the system.

AddedFXE - Specifies one or more suffixes of the IBM Function Registry for z/OS parmlib member, FXEPRMxx, to be used by the system.

IZU - Completes the names of one or more parmlib members (IZUPRMxx) that specify the settings for IBM z/OS Management Facility (z/OSMF) on the system.

ChangedLFAREA - Specifies the amount of real storage that can be used to satisfy fixed 1 MB and 2 GB page requests.



Syntax rules for IEASYSxx

ChangedThe system considers the first record that does not end in a comma to be the end of the member and ignores subsequent lines. You can use the remainder of the record, which contains the last parameter, for comments, providing there is at least one blank between the last parameter and the comments. You can also use additional lines after the last parameter for comments, as the below shows.

** MY IEASYSxx MEMBER*

CON=01,MLPA=(00,01,02,03,L), USE CONSOL01, IEALPA00-03COUPLE=&SYSCLONE, XCF SERIAL CTCS ARE DEFINEDPLEXCFG=MULTISYSTEM, TURN SYSPLEX ONLICENSE=Z/OS, THE SYSTEM IS RUNNING WITH A Z/OS LICENSEDIAG=01 USE DIAG01. LAST STMT; LIST ENDS HERE

THIS MEMBER CONTAINS SOME TRAILING COMMENTS WITH BLANK LINES AFTER THE LAST RECORD.

Statements and parameters for IEASYSxx

15.9.1 CON - /* Changed in V2R3 */

V2R2 Syntax

CON={aa}{(aa[,L][,NOJES3][,modespec])}{modespec}{NONE}{(NONE[,L][,NOJES3][,modespec])}{NOJES3}{(NOJES3[,modespec])}

V2R3 Syntax

CON={aa}{(aa[,L][,NOJES3])}{NONE}{(NONE[,L][,NOJES3])}{NOJES3}

The two alphanumeric characters (aa) are appended to CONSOL to form the name of the installation-created CONSOLxx member of SYS1.PARMLIB.

If you specify the L option, the system lists all of the statements read from the CONSOLxx member on the operator's console.

If you specify NONE, the system uses all the IBM defaults for the CONSOLxx parmlib member to bring up the system. For information about when you would want to specify CON=NONE, see z/OS MVS Planning: Operations.

When operating JES2 on a system with JES3 installed, IBM suggests the use of the NOJES3 option to allow the comma to be omitted between the REPLY ID and the command text when using short form reply.

The NOJES3 option has no effect when specified on a system that does not have JES3 installed.

The aa or NONE specification, if used, must precede the NOJES3 option. The L option, if used, can



precede or follow the NOJES3 option. If you specify only NOJES3 on CON=, the system assumes you wanted (NONE,NOJES3).

The NOJES3 option, if specified, remains in effect for the duration of the IPL. If you specify NOJES3 with an error, (such as CON=(aa,NOJES3) for a CONSOLxx member that does not exist, or CON=(NONE,NOJES3) when a CONSOLxx member is required), the NOJES3 value remains in effect, regardless of how you respond to the system's prompt for CON=. To remove the NOJES3 specification, you must reload the initial program and omit the NOJES3 option when you respecify the CON= parameter.

Value range: NONE or any two characters (A-Z, 0-9, @, #, or $) and, optionally, NOJES3.

Default: CON=NONE

Associated parmlib member: CONSOLxx

15.9.2 DRMODE - /* Removed from V2R3 */

DRMODE={NO}|{YES}

This parameter is no longer supported. Although the keyword can be specified, any specification of it has no effect on the system.

Value range: Not applicable.

Default: NO

Associated parmlib member: None

15.9.3 FXE - /* New in V2R3 */

FXE={x1|(x1, . . .,xn)}

This optional parameter specifies one or more suffixes of FXEPRMxx parmlib members to be processed when the system starts. FXEPRMxx members contain statements that control the IBM Function Registry for z/OS, for example statements that affect the enablement state of individual function entries in the registry.

Value range: Any two alphanumeric or national ($,#,@) characters.

Default: None

Associated parmlib member: FXEPRMxx

15.9.4 HZSPROC - /* Changed in V2R3 */

HZSPROC=hzsprocname

This parameter specifies the name of the HZSPROC procedure you want the system to use to automatically start IBM Health Checker for z/OS at IPL-time. Specify this parameter if you want to use a name other than the default, HZSPROC. The procedure specified must reside in a SYS1.PROCLIB data set.

You can customize your HZSPROC procedure. For more information, see Steps for optimizing IBM Health Checker for z/OS in IBM Health Checker for z/OS User's Guide.

Value range: A 1-8 character string, where the first character is alphabetic or national ($,#,@) and the other characters, if any, are alphanumeric or national.

A special value of *NONE is accepted to signify that no procedure should be used and that Health Checker should not be started automatically at IPL time.

Default: HZSPROC



15.9.5 IZU - /* New in V2R3 */

IZU={aa }

{(aa,bb . . .)}

This parameter specifies one or more suffixes of the optional z/OS Management Facility (z/OSMF) parmlib member, IZUPRMxx to be used by the system. The two characters, represented by aa (or bb, and so on), are appended to IZUPRM to form the names of the IZUPRMxx members, when IZUPRM=SYSPARM (or IZUPRM=PREV for IPL-time) is specified in the IZUSVR1 startup procedure for z/OSMF.

The IZUPRMxx parmlib member contains parameters for configuring z/OSMF and managing its behavior.

Value range: Any two alphanumeric or national ($,#,@) characters.

Default: None

Associated parmlib member: IZUPRMxx

15.9.6 LFAREA - /* Changed in V2R3 */

LFAREA = {xM | xG | xT | x%}

{(xM | xG | xT | x% [,INCLUDE1MAFC(YES|NO)])}

{( [1M=(a [,b]) | 1M=(a% [,b%])]

[,2G=(a [,b]) | ,2G=(a% [,b%])]

[,PROMPT | ,NOPROMPT]

[,INCLUDE1MAFC(YES|NO)]

)}

** Changed in V2R3 **

The LFAREA parameter specifies the maximum amount of online real storage available at IPL that can be used to satisfy fixed 1 MB and 2 GB page requests. The xM, xG, xT, and x% syntax form specifies the maximum amount of 1 MB pages, and the 1M= and 2G= syntax form specifies the maximum amount of 1 MB and 2 GB pages. The two syntax forms cannot be combined. Each syntax specification uses a different formula for calculating percentage requests and the system limit, as described in “Request handling for the LFAREA system limit” on page 502 and “Request handling for insufficiently contiguous online real storage” on page 503 of the MVS Initialization and Tuning Reference.

Note: Specifying LFAREA for fixed 1 MB pages does not reserve an amount of real storage to be used exclusively for fixed 1 MB page requests. It simply specifies the target cap for the most fixed 1 MB page requests that can be satisfied for this system.

In the following descriptions, 2 GB is equal to a decimal value of 231, or 2147483648, and 4 GB is equal to a decimal value of 232, or 4294967296.

Value range: The following value ranges apply to the value specified on the LFAREA parameter. The maximum values that can be specified for the LFAREA are described in “Request handling for the LFAREA system limit” on page 502 of the MVS Initialization and Tuning Reference.



xM or xG or xT

Specifies the maximum amount of online real storage that can be used to satisfy fixed 1 MB page requests. Up to six decimal digits can be specified for x: xM specifies the amount is in megabytes; xG specifies the amount is in gigabytes; xT specifies the amount in terabytes. A specification of 0M, 0G, or 0T results in the system using no real storage to satisfy fixed 1 MB page requests for the life of the IPL.

x%

Specifies the maximum amount of online real storage that can be used to satisfy fixed 1 MB page requests, as a percentage of the total online real storage at IPL. Up to two digits can be specified. The percentage is calculated as (x% * online real storage at IPL) – 2G. The maximum percentage that can be specified is 80%. A specification of 0% results in no successful fixed 1 MB page requests.

1M=(a)

Specifies the maximum number of 1 MB pages of that can be used to satisfy fixed 1 MB page requests. Up to eight decimal digits can be specified for a. A specification of 1M=(0,0) results in the system using no real storage to satisfy fixed 1 MB page requests for the life of the IPL.

1M=(a,b)

Specifies the maximum number of 1 MB pages that can be used to satisfy fixed 1 MB page requests. Up to eight decimal digits each can be specified for a and b. The value that is specified for a is the target number of pages, and the value that is specified for b is the minimum number. The system attempts to meet the request at or as near as possible up to the target number, but at no less than the minimum number. The value that is specified for b must be less than or equal to the value specified for a, and can be zero. A specification of 1M=(0,0) results in the system using no real storage to satisfy fixed 1 MB page requests for the life of the IPL. When the LFAREA parameter has been processed, no additional amounts of storage are reserved later in an attempt to reach the target. Both a value and a percentage, such as 1M=(a ,b %) or 1M=(a %,b ), cannot be specified.

1M=(a%)

Specifies the maximum amount of online real storage that can be used to satisfy fixed 1 MB page requests, as a percentage. Up to two digits can be specified. The storage amount is calculated as a% * (online real storage at IPL – 4G), rounded down to the nearest 1 MB boundary. The maximum percentage that can be specified is 80%. A specification of 1M=(0%) results in the system using no real storage to satisfy fixed 1 MB page requests for the life of the IPL.

1M=(a%,b%)

Specifies the maximum amount of online real storage that can be used to satisfy fixed 1 MB page requests, as a percentage. Up to two digits each can be specified for a % and b %. The value specified for a % is the target amount, and the value specified for b % is the minimum amount. The system attempts to satisfy the request at or as near as possible up to the target amount, but at no less than the minimum amount. The percentages are calculated as percent * (online real storage at IPL – 4G), rounded down to the nearest 1 MB boundary. The maximum percentage that can be specified for a % is 80%. The value specified for b % must be less than or equal to the value for a %, and can be zero. A specification of 1M=(0%,0%) results in the system using no real storage to satisfy fixed 1 MB page requests for the life of the IPL. When the LFAREA parameter has been processed, no additional amounts of storage are reserved later in an attempt to reach the target. Both a value and a percentage, such as 1M=(a ,b %) or 1M=(a %,b ), cannot be specified.



2G=(a)

Specifies the number of 2 GB pages of online real storage to reserve in the large frame area. Up to eight decimal digits can be specified for a . A specification of 2G=(0) results in zero 2 GB pages being reserved. Each 2 GB page is placed only in a 2 GB area of contiguous real storage on a 2 GB boundary, which means that enough 2 GB areas of contiguous online storage on 2 GB boundaries must be available at IPL for the number of 2 GB pages requested.

2G=(a,b)

Specifies the number of 2 GB pages of online real storage to reserve in the large frame area. Up to eight decimal digits each can be specified for a and b. The value specified for a is the target number of pages, and the value specified for b is the minimum number. The system attempts to satisfy the request at or as near as possible up to the target number, but at no less than the minimum number. The value specified for b must be less than or equal to the value for a, and can be zero. A specification of 2G=(0,0) results in zero 2 GB pages being reserved. When the LFAREA parameter has been processed, no additional amounts of storage are reserved later in an attempt to reach the target. Both a value and a percentage, such as 2G=(a ,a %) or 2G=(a %,a ) cannot be specified. Each 2 GB page is placed only in a 2 GB area of contiguous real storage on a 2 GB boundary, which means that enough 2 GB areas of contiguous online storage on 2 GB boundaries must be available at IPL for at least the minimum number of 2 GB pages requested.

2G=(a%)

Specifies the amount of online real storage to reserve in the large frame area for 2 GB pages, as a percentage. Up to two digits can be specified for a. The storage amount is calculated as a % * (online real storage at IPL – 4G), rounded down to the nearest 2 GB boundary. The maximum percentage that can be specified is 80%. A specification of 2G=(0%) results in zero 2 GB pages being reserved. Each 2 GB page is placed only in a 2 GB area of contiguous real storage on a 2 GB boundary, which means that enough 2 GB areas of contiguous online storage on 2 GB boundaries must be available at IPL for the amount of 2 GB pages requested.

2G=(a%,b%)

Specifies the amount of online real storage to reserve in the large frame area for 2 GB pages as a percentage. Up to two digits each can be specified for a % and b %. The value specified for a % is the target amount, and the value specified for b % is the minimum. The system attempts to satisfy the request at or as near as possible up to the target amount, but at no less than the minimum amount. The percentages are calculated as percent * (online real storage at IPL – 4G), rounded down to the nearest 2 GB boundary. The maximum percentage that can be specified for a % is 80%. The value specified for b % must be less than or equal to the value for a %, and can be zero. A specification of 2G=(0%,0%) results in zero 2 GB pages being reserved. When the LFAREA parameter has been processed, no additional amounts of storage are reserved later in an attempt to reach the target. Both a value and a percentage, such as 2G=(a,b%) or 2G=(a%,b), cannot be specified. Each 2 GB page is placed only in a 2 GB area of contiguous real storage on a 2 GB boundary, which means that enough 2 GB areas of contiguous online storage on 2 GB boundaries must be available at IPL for at least the minimum amount of 2 GB pages requested.

PROMPT | NOPROMPT

Specifies whether the system prompts for respecification of the LFAREA parameter when the request cannot be satisfied. The default is PROMPT, which specifies for the system to prompt when either the 1M= or 2G= request cannot be satisfied. The value NOPROMPT specifies for the system to ignore the LFAREA request when either or both of the 1M= and 2G= requests cannot be satisfied, and to instead have zero 1 MB pages and zero 2 GB pages that can be used to satisfy fixed 1 MB and 2 GB page requests.



INCLUDE1MAFC(YES|NO)

Specifies whether the 1 M LFAREA specification is included in the available frame count (RCEAFC). With z/OS V2R3, the INCLUDE1MAFC specification is ignored. The 1 M LFAREA specification is always included in the available frame count (RCEAFC).

YES Specifies that the 1 M LFAREA specification is included in the available frame count. This is the default and the only accepted value. For compatibility with applicable releases before z/OS V2R2, you can also specify INCLUDE1MAFC(YES) as INCLUDE1MAFC.

NO Specifies that the 1 M LFAREA specification is not included in the available frame count.

This value is always ignored.

Default: INCLUDE1MAFC(YES).

Notes:

1. Application programs can check the RCEINCLUDE1MAFC bit to determine if INCLUDE1MAFC(YES) is in effect, regardless of z/OS release.

2. Application programs that use the STGTEST SYSEVENT must be assessed to determine if any changes need to be made. The STGTEST event returns information about the amount of storage available in the system, which includes the LFAREA.

Displaying LFAREA information

You can use the MODIFY AXR,IAXDMEM command to display memory utilization statistics associated with the LFAREA.

For more information, see Displaying real storage memory statistics in z/OS MVS System Commands.

Request handling for the LFAREA system limit

The system limits the amount of online real storage that can be used to satisfy fixed 1 MB and 2 GB page requests. The system applies this limit differently depending on which of the two syntax forms is used for the LFAREA request. The two syntax forms cannot be combined.

If the LFAREA request is specified using xM, xG, xT, or x% syntax:

• The system limit is calculated as: (80% * online real storage available at IPL) – 2G

• The value specified by xM, xG, xT, or x% is applied toward the limit, with the percentage calculated as (x% * online storage available at IPL) – 2G.

• If the limit is exceeded, the system rejects the request and prompts for respecification of the LFAREA request.

If the LFAREA request is specified using the 1M= or 2G= syntax form:

• The system limit is calculated as: 80% * (online real storage available at IPL – 4G)

• The system limit is imposed on the sum of the 1 MB and 2 GB pages.

• For the form 1M=(a) and 1M=(a%) and 2G=(a) and 2G=(a%), the value specified for a or a% is applied toward the limit, with the percentage value calculated as a% * (online storage available at IPL – 4G).

• For the form 1M=(a,b) and 1M=(a%,b%) and 2G=(a,b) and 2G=(a%,b%), the value specified for b or b% is applied toward the limit, with the percentage value calculated as b% * (online storage available at IPL – 4G).

• For any percentage request that is by definition over 80%, the system rejects the request as a specification error and prompt for respecification of LFAREA, regardless of the PROMPT or NOPROMPT specification. The following examples are specification error cases:

• LFAREA=(1M=81%)

• LFAREA=(1M=(40%,20%),2G=(41%,20%))



• LFAREA=(1M=(1,0),2G=80%))

• If either or both of the 1M= or 2G= requests and PROMPT (either explicitly or by default) are specified, and the applicable value or sum of values exceeds the system limit, the system issues a prompt to respecify LFAREA. Otherwise, when NOPROMPT is specified, the LFAREA parameter is ignored and the system will not use any real storage to satisfy fixed 1 MB and 2 GB page requests for the life of the IPL.

• For any request containing a target and minimum specification where the target or sum of targets is above the system limit, the system attempts to satisfy the request at or less than the system limit, if the request can be satisfied at or above the minimum values specified.

Request handling for insufficiently contiguous online real storage

In some cases, the LFAREA request cannot be satisfied even though it does not exceed the system limit. For example, real storage could be configured in such a way that some offline areas are interspersed among online areas, preventing the system from locating enough contiguous storage areas that start on a 2 GB boundary to use for the set of 2 GB pages.

When the LFAREA request is specified using the xM, xG, xT, or x% syntax form:

• For the syntax form xM, xG, and xT, the value specified for x is the maximum amount of real storage that can be used to satisfy fixed 1 MB page requests.

• For a percentage request, the amount is calculated as: (percent * online real storage at IPL) – 2 GB

• When calculated, the percentage request is rounded down to the nearest 1 MB boundary.

• If rounding down the percentage request results in zero, the system will not use any real storage to satisfy fixed 1 MB page requests for the life of the IPL.

• If the amount of storage required to satisfy the request cannot be located, the request is satisfied at less than the requested amount and the system will then continue with the IPL.

When the LFAREA request is specified using the 1M= or 2 GB= syntax form:

• For the form 1M=(a) and 1M=(a%) and 2G=(a) and 2G=(a%), the value specified for a or a% is both the target and the minimum amount of real storage that the system is used to satisfy fixed 1 MB and 2 GB page requests.

• For the form 1M=(a,b) and 1M=(a%,b%) and 2G=(a,b) and 2G=(a%,b%), the value specified for a or a% is the target amount, and b or b% is the minimum amount of real storage that can be used to satisfy fixed 1 MB and 2 GB page requests.

• For a percentage request, the amount is calculated as: percent * (online real storage at IPL – 4G)

• Once calculated, the 1M= or 2G= percentage request is rounded down to the nearest respective 1 MB or 2 GB boundary.

• If rounding down the percentage request results in zero, and PROMPT is specified (either explicitly or by default), the system issues a prompt to respecify LFAREA. Otherwise, when NOPROMPT is specified, the LFAREA parameter is ignored and the system will not use any real storage to satisfy fixed 1 MB and 2 GB page requests for the life of the IPL.

• If the 1M= or 2G= request cannot be satisfied with at least the minimum amount requested, and PROMPT is specified (either explicitly or by default), the system will issue a prompt to respecify LFAREA. Otherwise, when NOPROMPT is specified, the LFAREA parameter is ignored and the system will not use any real storage to satisfy fixed 1 MB and 2 GB page requests for the life of the IPL.

Default Value: None (No LFAREA is defined)

Associated Parmlib Member: None



15.9.7 REAL - /* Changed in V2R3 */

Default value changed in V2R3.

OLD(V2R2)

Default: 76. (This means a default value of 76K.)

NEW(V2R3)

Default: 0.

15.9.8 VRREGN - /* Changed in V2R3 */

VRREGN=nnnn

This parameter specifies the default real-storage region size for an ADDRSPC=REAL job step that does not have a REGION parameter in its JCL. The numerical value of the operand (nnnn) indicates the real-storage region size in 1 KB blocks. The VRREGN parameter has no meaning if REAL=0 is specified.

15.10 IEFOPZxx (data set optimization configuration) - /* Changed in V2R3 */

The OLD subparameter under the OLDNEW(parameters) definition in “Statements and parameters for IEFOPZxx” of IEFOPZxx (Data Set Optimization Configuration) has been updated for clarity.

OLD(DSNAME(dsname )[,VOLUME(volname )])

Identifies the pre-optimized load library.

DSNAME(dsname)

dsname is a valid 1 to 44 character data set name. The data set specified by dsname is known as an IEFOPZ-Old data set.

Other considerations for specifying an IEFOPZ-Old data set are:

• The system expects, but does not enforce, that the IEFOPZ-Old data set is a load library, that it is not a tape data set, and that it is not a GDG Base.

• An IEFOPZ-Old data set must not match any IEFOPZ-New data set.

• Do not specify an alias of an IEFOPZ-Old data set as an IEFOPZ-New data set, or vice versa. The system might not enforce this.

• An IEFOPZ-Old data set must not have the same name as any of the data sets identified by the PROGxx SYSLIB statement as being automatically part of the LNKLST, or any of the defaults for those data sets (SYS1.LINKLIB, SYS1.CSSLIB, SYS1.MIGLIB, SYS1.SIEALNKE, SYS1.SIEAMIGE). The system will enforce the case of not using the defaults, and after IPL only will enforce the case of using a data set identified by the SYSLIB statement as being automatically part of the LNKLST.

DSNAME can be specified as DSN.

VOLUME(volname )

Optionally specifies a volume to be used. volname must be 1 to 6 characters. It must be a valid volume name once normal symbol substitution has occurred. You can use a value of "*MCAT*" to indicate that the data set is located on the volume containing the master catalog. The system is to use the data set on that volume. Note that, as with normal allocation processing (as described for the VOLUME parameter in the z/OS MVS JCL Reference), if the volume is SMS-managed, then the system will find and allocate the data set to the volume on which it resides, even if that is different from the volume specified.

When no volume is specified, the system uses the catalog to determine the volume to use.



VOLUME can be specified as VOLSER or VOL.

The following rule will be applied for a JCL (or dynamic allocation) case that provides DSN without volume (the system will locate the volume from the catalog as part of its processing and will determine the real data set name if the specification was an alias). In all cases, it is that real data set name that is used for the match.

• If there is an IEFOPZ-Old data set with matching DSN and with a specified volume that matches what the system found, then that IEFOPZ-Old data set is used.

• Else if there is an IEFOPZ-Old data set with no specified volume and with matching DSN (the match uses the IEFOPZ-Old data set's DSN's real DSN if the IEFOPZ-Old data set's DSN was an alias) then this IEFOPZ-Old data set is used (whether or not the earlier system look up of the DSN in the catalog found the same volume that the system located in the catalog this time)

• Else there is no match

• The following rule will be applied for a JCL (or dynamic allocation) case that provides both DSN and volume (for example, DSN=MY.DS,VOL=SER=V):

• If there is an IEFOPZ-Old data set with matching DSN and with a specified volume that matches, then that IEFOPZ-Old data set is used

• Else if there is an IEFOPZ-Old data set with no specified volume and with matching DSN (the match uses the IEFOPZ-Old data set's DSN's real DSN if the IEFOPZ-Old data set's DSN was an alias) but when the system earlier had looked up the DSN in the catalog the volume that was found matches, then this IEFOPZ-Old data set is used

• Else there is no match. This includes the case of an IEFOPZ-Old data set with no specified volume where, for example, when the IEFOPZ-Old data set was created, the catalog entry for MY.DS was for volume V2. In the example, then, the JCL had MY.DS on V, and the IEFOPZ-Old data set has MY.DS for V2. The system does not look up MY.DS in the catalog when processing the JCL in order to avoid undesirable extra overhead, and thus does not know if the current catalog entry is for volume V.

If the IEFOPZ-Old data set is in the IPL-time LNKLST, then the data set must either be cataloged in the master catalog or the volume must be specified. Also, the data set must be cataloged in the post-IPL catalog (just not necessarily in the master catalog).

Note: For an IEFOPZ-Old data set that is provided without volume, the system will recognize that a data set of that name in the LNKLST is the same as the IEFOPZ-Old data set only if the LNKLST data set was provided without volume. Conversely, for an IEFOPZ-Old data set that is provided with volume, the system will recognize that a data set of that name in the LNKLST is the same as the IEFOPZ-Old data set only if the LNKLST data set was provided with that same volume.

15.11 IGDSMSxx (storage mgmt subsys def) - /* Changed in V2R3 */

The unit of measure for total real storage for RLSFIXEDPOOLSIZE({(sysname1,size1[...;sysname32,size32])}) in “Optional keywords for IGDSMSxx” has been added for clarity. DB2SSID and OAMPROC keywords have also been added.

Optional keywords for IGDSMSxx

The following keywords are optional. Defaults, if any, are noted.

ACSDEFAULTS(YES | NO)

Specifies whether SMS initializes the following automatic class selection (ACS) routine variables from an additional call to RACF:

• &APPLIC

• &DEF_DATACLAS

• &DEF_MGMTCLAS



• &DEF_STORCLAS

Specify YES to request that RACF or a functional equivalent gives SMS the values. Because SMS must set these variables every time a data set is created, specifying NO reduces the overhead of using RACF. If you specify NO, these variables have no values that are associated with them.

Specify YES also to request that RACF or a functional equivalent gives SMS the data key value in a RACF DFP DATA SET profile. When you specify NO, SMS does not retrieve the data key value from the RACF DFP DATA SET profile.

The ACSDEFAULTS keyword is not applicable for OAM.

Default: NO

AKP({nnn[,nnn[...,nnn]] |1000})

Specifies the activity keypoint trigger value, which is the number of logging operations between keypoints. Up to 32 activity keypoint values can be specified. AKP values must be specified in the same order as DFSMStvs instance names. Specify a value from 200 to 65535.

You can allow some values to default while specifying others. For example, in AKP(800,,3000), the value for the DFSMStvs instance in the second position defaults to 1000, and sets the values for the first and third DFSMStvs instances to 800 and 3000 respectively.

If AKP is specified with only the TVSNAME parameter without an identifier, AKP applies to the system on which the parmlib member is being read. TVSNAME must be specified with the AKP parameter.

Activity keypointing is the process of accounting for all the log records in the undo and shunt logs that are involved in active units of recovery. Activity keypointing enables DFSMStvs to delete records that are no longer involved in active units of recovery. It also enables DFSMStvs to update the undo log to optimize its restart performance related to reading the log stream.

An ideal AKP value is a balance between processing activity keypoints too frequently and not frequently enough. Specifying an AKP value that is too low might increase CPU usage unnecessarily, while too high an AKP value increases the storage requirements of the logstreams. To calculate an ideal AKP value, consider how many transactions the logs need to hold concurrently, the duration of those transactions, and how many updates each transaction will perform.

To begin calculating your AKP value, start with a value that is greater than the average number of updates that occur during the length of a transaction, and lower than 3 times the maximum of that value. This can be expressed by the following formula:

AKP > Avg(TranTime) x Avg(UpdPerTran) x Avg(TranPerTime)

AKP < 3 x Max(TranTime) x Max(UpdPerTran) x Max(TranPerTime)

Where the average and maximum of each of the following parameters is known:

TranTime = Transaction running time (in a time unit such as seconds)

UpdPerTran = Updates per transaction

TranPerTime = Transactions per time unit (same units as TranTime)

While this calculation provides a starting point for your AKP setting, it is recommended that you then monitor the logstream usage and adjust the AKP value as necessary.

Default: 1000



CA_RECLAIM(NONE|{DATACLAS|DATACLASS})

Specifies whether to use CA reclaim for KSDSs according to the CA Reclaim attribute in their data classes.

DATACLAS|DATACLASS

Indicates that the SMS-managed KSDSs and non-SMS-managed KSDSs will go by the data class specification of CA Reclaim=Y|N at define time or subsequent ALTER setting. Only the resultant catalog setting of CA Reclaim=Y will do CA reclaim; CA Reclaim=N will not do CA reclaim. It is the way to specify some KSDSs not to use CA reclaim. The default is DATACLAS. If CA_RECLAIM is not specified in SYS1.PARMLIB, the CA_RECLAIM(DATACLAS) default is in effect, which means the default is CA reclaim enabled.

NONE

Indicates that none of the KSDSs is using CA reclaim, regardless of the data class specification. To ensure CA reclaim is disabled, specify CA_RECLAIM(NONE).

Default: DATACLAS

DB2SSID(ssid)

For a classic OAM configuration, this keyword specifies the name of the DB2® subsystem which is used by Object Access Method (OAM) for object storage. ssid can be from one to four characters. If your installation does not use OAM for object storage, omit this keyword or specify a value of NONE.

For a multiple OAM configuration, this keyword is ignored and instead each OAM subsystem configured in IEFSSNxx is required to specify the name of the DB2® subsystem with which it is associated.

Default: There is no default.

OAMPROC(procname)

In a classic OAM configuration, this keyword specifies the name of the procedure that is to start an OAM address space when SMS is initialized. You must specify this keyword if you want an OAM address space to be started during IPL. The procedure name can be from one to eight characters.

In a multiple OAM configuration, this keyword can be used to start only one of the OAM address spaces. It is recommended that this procedure name be used for the single OAM address space configured for Tape Library processing (if needed and if the OAM address space can be started before your tape management system).

Regardless of which procedure name is used, an additional OAM configuration must be performed for the associated OAM subsystem definition in IEFSSNxx to identify the appropriate DB2 identifier as well as for the procedure itself to identify the appropriate DB2 identifier. In the case of the specification of the recommended procedure used to start the single OAM address space (configured for Tape Library processing), the OAM configuration for the associated OAM subsystem and procedure must specify 'NONE' for the DB2 identifier.

Default: There is no default.

PS_EXT_VERSION(1|2)

This parameter indicates the format in which the system should create sequential extended format data sets. The default is PS_EXT_VERSION(1) to denote the version 1 format. That means that if the sequential extended format data set is not striped and has multiple volumes, FlashCopy cannot process it.

DFSMSdss must use conventional I/O to copy this type of data set. When the option is PS_



EXT_VERSION(2), any new sequential extended format data sets created is in version 2 format. This allows FlashCopy to copy the data set much more efficiently if it has multiple volumes and is not striped. The system saves this version number in the field DFASEFVR in the DFA, which is mapped by the IHADFA macro as described in z/OS DFSMSdfp Advanced Services.

Each data set's catalog entry will indicate whether the data set is version 1 or version 2. You can display the data set version via IDCAMS LISTCAT and DCOLLECT.

Encrypted data sets will be created in version 2 format for any user specification.

Default: 1

RLSFIXEDPOOLSIZE({(ALL,size)})

RLSFIXEDPOOLSIZE({(sysname1,size1[ . . .;sysname32,size32])})

Specifies the amount of the total real storage in megabytes, both above and below the 2 gigabyte bar, that will be permanently fixed (pinned) on either of the following environments:

• All systems

• Each system referenced in the parameter

Default: 0

15.12 IGGCATxx (DFSMS catalog configuration) - /* Changed in V2R3 */

Statements and parameters for IGGCATxx

CATMAX(nnnn )

Specifies the maximum number of catalogs that can be opened concurrently in CAS. When the limit is exceeded, the least recently accessed catalog is closed, freeing the CAS storage it had occupied. They remain allocated, but in restart status with no CAS storage. If the new limit is less than the previous limit, all currently open catalogs are closed.

The minimum value is 1 and the maximum value is 9999. The number that is specified for nnnn is in decimal.

While the maximum value of 9999 can be specified, it is highly recommended that the value does not exceed the number of open data sets for an address space as determined by the size of the TIOT specified in Chapter 4, “ALLOCxx (allocation system defaults),” on page 71 for a description. For example, if a 32K TIOT is specified, then it is recommended that CATMAX be set to no higher than 1635. Similarly for a 64K TIOT, the recommended maximum would be 3273.

DUMPON(rc ,rsn ,mod [,cnt ])

Specifies the return (rc) and reason codes (rsn) to take a dump on if a match is found in a valid catalog module (mod). The optional cnt value specifies to capture a dump on the nth occurrence of the condition (one to three characters from 1 to 999). The default for cnt is 1.



15.13 IKJTSOxx (TSO/E commands & programs) - /* New parameter in V2R3 */

The IKJTSOxx parmlib member has a new USERIDMAX parameter.

Syntax (excerpt):

USERIDMAX{(7)} | {(8)} ** New in V2R3 **

Allows setting a longer user ID or prefix. When USERIDMAX is set to a value of 8, the following should be kept in mind:

• The SUBMIT command will submit jobs for 8-character user IDs with job names equal to the user ID.

• If messages sent to 8-character user IDs via the SEND command are to be saved, they will only be saved if user logs are enabled. Messages will be delivered to the user if they are to be displayed in the user's session.

• Information Center Facility will only allow users with IDs that are seven characters or less to invoke Information Center Facility function.

• Users who share their IDs with z/OS V2R2 or lower systems and set 8 character prefix values should be made aware that the prefix value will not be usable on those shared systems since the maximum length supported is 7.

Default: 7

15.14 IXGCNFxx (system logger initialization parameters) - /* New parameters in V2R3 */

The IXGCNFxx parmlib member has new parameters, USEOFFLOADMIN and USESTAGINGMIN, in the MANAGE specification.

Syntax (excerpt):

USEOFFLOADMIN(YES | NO) ** New in V2R3 **

Specifies whether the system ensures that log stream offload data sets are newly allocated on the system with a size of at least 1MB when the LS_SIZE attribute is not specified for the log stream. For more information about planning for log stream offload data sets, see Plan DASD space for system logger in z/OS MVS Setting Up a Sysplex.

YES Indicates that the system ensures that log stream offload data sets are allocated on the system with a base minimum size of at least 1MB. If a log stream offload data set is newly allocated with a size smaller than 1MB, the logger deletes the data set and allocates a new one with a size of



at least 1MB.


NO Indicates that the system does not ensure the use of the 1MB offload data set size as a base minimum.

It is recommended that offload data sets are to be sized no smaller than 1MB, unless the log stream exploiter specifically recommends a size below this amount.

To view the parameter settings for configuring the system logger, use the DISPLAY LOGGER,IXGCNF[,MANAGE] command.

Default: YES

STAGING

Specifies the system logger policy on the system for managing log stream staging data sets.

USESTAGINGMIN(YES | NO)

Specifies whether the system ensures that log stream staging data sets are newly allocated on the system with a size of at least 10MB when the STG_SIZE attribute is not specified for the log stream. For more information about planning for staging data set use, see Plan space for staging data sets in z/OS MVS Setting Up a Sysplex.

YES Indicates that the system ensures that log stream staging data sets are allocated on the system with a base minimum size of at least 10MB. If a log stream staging data set is newly allocated with a size smaller than 10MB, the logger deletes the data set and allocates a new one with a size of at least 10MB.


NO Indicates that the system does not ensure the use of the 10MB staging data set size as a base minimum.

It is recommended that staging data sets are to be sized no smaller than 10MB, unless the log stream exploiter specifically recommends a size below this amount.

To view the parameter settings for configuring the system logger, use the DISPLAY LOGGER,IXGCNF[,MANAGE] command.

Default: YES

15.15 IZUPRMxx (configure IBM z/OS Mgmt Facility) - /* Changed in V2R3 */

IEASYSxx has a new system parameter IZU to identify one or more IZUPRMxx parmlib members to be used for your z/OSMF configuration. See IZU in IEASYSxx section above.

You do not have to create an IZUPRMxx parmlib member to get IBM z/OS Management Facility (z/OSMF) up and running. Instead, you might find that the z/OSMF configuration defaults are sufficient for your environment. If so, use the defaults for a quick-start experience with z/OSMF. If your z/OSMF set-up requires customization, you can provide a customized member, IZUPRMxx, with installation-specific values for your configuration.

For more information about the IZUPRMxx parmlib member, including syntax and parameters, see IBM z/OS Management Facility Configuration Guide.



15.16 PROGxx (authorized program list, exits, LNKLST sets and LPA) - /* Changed in V2R3 */

Removing an XCFAS ENQ ** Changed in V2R3 **

The XCFAS address space has an ENQ on each LNKLST data set. These ENQs provide serialization on the LNKLST data sets. An ENQ on a LNKLST data set prevents that data set from being altered as long as it is a member of an active LNKLST. There is no connection between sysplex processing and LNKLST processing.

There are times when you may want to remove the XCFAS ENQ; for example, when you want to update a data set of the same name on a different volume. Use the LNKLST UNALLOCATE statement, described in “Syntax format of the LNKLST statements” on page 784, or the SETPROG LNKLST,UNALLOCATE system command, described in z/OS MVS System Commands, to remove the ENQ.

LLA also holds an ENQ on each LNKLST data set. You can remove this ENQ by using the GET_LIB_ENQ(NO) option of the CSVLLAxx parmlib member, by updating LLA to REMOVE the data set from LLA management, or by stopping LLA. See Chapter 25, “CSVLLAxx (library lookaside (LLA) list),” on page 287. For more information about an LLA-managed data set, see Removing libraries from LLA management in the z/OS MVS Initialization and Tuning Guide.

After it is again OK for the system to have the ENQ, restore the previous system behavior, such as with:

• The LNKLST ALLOCATE statement or the SETPROG LNKLST,ALLOCATE command.

• The GET_LIB_ENQ(YES) option of the CSVLLAxx parmlib member.

15.17 SMFLIMxx (specifying region and memlimit values) - /* Changed in V2R3 */

Use the SMFLIMxx parmlib member to specify values that are similar to several of the output fields in the IEFUSI SMF exit. These values can override the REGION of a job step, set the MEMLIMIT for a job step or cause space to be reserved in high private subpools in the private area.

The SMFLIM specification becomes active when the SMF address space is initialized, regardless of whether SMF records are being collected and recorded.

SMFLIMxx consists of a set of REGION statements. Each REGION statement has one or more filter keywords and corresponding memory attributes to be set.

Note: For more information on region size, see the section Limiting user region size in z/OS MVS Initialization and Tuning Guide.

SYSRESVABOVE(nnnnn K|nnnnn M|nnnnn G)

Specifies the minimum size of storage that is reserved for high private subpools in extended private storage above the 16 MB line. This value can range from 1K to 2047M or 2G. If an IEFUSI exit sets a smaller limit on the job step's storage, the system reserved area will be larger than the minimum that is specified in the rule.

nnnnn G Specifies the value in gigabytes.nnnnn M Specifies the value in megabytes.nnnnn K Specifies the value in kilobytes.

SYSRESVBELOW(nnnnn K|nnnnn M)

Specifies the minimum size of storage that is reserved for high private subpools in nonextended private storage below the 16 MB line. This value can range from 1K to 16384K or 16M. If an IEFUSI exit sets a smaller limit on the job step's storage, the system reserved area will be larger than the minimum that is specified in the rule.

nnnnn M Specifies the value in megabytes.nnnnn K Specifies the value in kilobytes.



REGIONABOVE(NOLIMIT | nnnnn K|nnnnn M|nnnnn G)

Overrides the extended region specification (set with the REGION or REGIONX keywords) that was coded in a job's JCL, or the default that was coded in the job class. This value can range from 1K to 2047M or 2G. The value can also be set to NOLIMIT, which specifies that the region size for this job step is not to be limited. The SYSRESVABOVE value will still ensure that storage is reserved in high private subpools of extended storage for use by authorized programs.

NOLIMIT There is no limit on the use of virtual storage above 16 megabytes.nnnnn G Specifies the value in gigabytes.nnnnn M Specifies the value in megabytes.nnnnnK Specifies the value in kilobytes.

REGIONBELOW(NOLIMIT | nnnnnK| nnnnnM)

Overrides the nonextended region specification (set with the REGION or REGIONX keywords) that was coded in a job's JCL, or the default that was coded in the job class. This value can range from 1K to 16384K or 16M. The value can also be set to NOLIMIT, which specifies that the region size for this job step is not to be limited. The SYSRESVBELOW value will still ensure that storage is reserved in high private subpools of non-extended storage for use by authorized programs.

NOLIMIT There is no limit on the use of virtual storage below 16 megabytes.nnnnnM Specifies the value in megabytes.nnnnnK Specifies the value in kilobytes.

15.18 SMFPRMxx (system mgmnt facilities (SMF) parameters) - /* Changed in V2R3 */

Statements and parameters for SMFPRMxx

BUFUSEWARN(nn ) ** Notes added to V2R3 **

Specifies the overall buffer warning level percentage (nn) when SMF starts to issue a warning message depending on the recording environment. For data set recording environments, the following occurs:

• SMF preallocates and maintains storage in the buffer for initial use and for internal control information. This is included in the in-use accounting of the buffer for BUFUSEWARN processing.

• SMF maintains the current and high water mark values of the percentage of the buffer that is in-use. The values are reported in SMF23LCP and SMF23LHP, respectively.

For the following keywords, the Value Range has changed:

TYPE{(aa,bb)|(aa,bb:zz)|(aa,bb:zz,...)}

TYPE({aa ,bb |aa ,bb :zz |aa ,bb :zz ,...})NOTYPE({aa ,bb |aa ,bb :zz |aa ,bb :zz ,...})

TYPE{(aa ,bb )|(aa ,bb :zz )|(aa ,bb :zz ,...)}

TYPE{aa,bb(cc) } NOTYPE ({aa,bb:zz }) {aa,dd(cc:yy),...}{aa,bb(cc,...)}

Value range: 0-2047 (SMF record types) ** Changed in V2R3 **



15.19 VATLSTxx (volume attribute list) - /* Changed in V2R3 */

Creating a VATLSTxx member

The VATLSTxx member contains an optional VATDEF statement followed by entries that define the mount and use attributes of DASD volumes.

Use the VATDEF statement in VATLSTxx to specify a default use attribute. If you do not specify VATDEF, the system assigns a default of PUBLIC to those volumes that are not specifically assigned a use attribute in the VATLSTxx member or in a MOUNT command.

If specified, the VATDEF statement must be the first non-comment line in VATLSTxx. Any VATDEF statement after the first line is treated as a DASD volume entry.

In the first VATLSTxx member that is specified in the VAL= operand, all of the VATDEF keywords are processed. In subsequent VATLSTxx members, only the STARCOMMENT keyword value is accepted and used. The IPLUSE and SYSUSE keywords are ignored.

The following is the syntax for the VATDEF statement. Unlike DASD volume entries in VATLSTxx members, the VATDEF statement is not column-dependent but it also cannot be continued on another line.

VATDEF ** Changed in V2R3 **

The default for use attributes for DASD volumes and comment processing in VATLSTxx. If you specify VATDEF without any operands, the system uses the operands IPLUSE(PUBLIC), SYSUSE(PUBLIC), and STARCOMMENT(YES).

STARCOMMENT ** New in V2R3 **

Indicates whether an asterisk in column 1 will be processed as a comment for subsequent lines in the current VATLSTxx member. This value only applies to the current VATLSTxx member.

YES A line with an asterisk in column 1 will be treated as a comment. This is the default when the STARCOMMENT keyword is not specified.

NO A line with an asterisk in column 1 will be treated as a DASD volume entry.

Syntax rules for VATLSTxx ** Changed in V2R3 **

• The following rules apply to the entire VATLSTxx member:

• Each record is 80 characters long. The system ignores columns 72 through 80.

• Prior to the VATDEF statement (if provided) or the first DASD volume entry (if no VATDEF statement is provided), lines with an asterisk in column 1 will be treated as comments. This is not affected by the VATDEF STARCOMMENT keyword value.

• If the VATDEF statement was provided with STARCOMMENT(NO), lines after the VATDEF statement that begin with an asterisk in column 1 are treated as DASD volume entries. Otherwise, by default all lines with an asterisk in column 1 are treated as comments.

• The VATDEF STARCOMMENT keyword value applies only to the current VATLSTxx member. Each VATLSTxx member will be processed according to the STARCOMMENT keyword value



specified in that member, or if no STARCOMMENT keyword value is provided, according to the defaults described in this list.

The following rules apply to the creation of a DASD volume entry in the VATLSTxx member:

• Each record consists of 80 columns, although columns 22 through 80 are ignored.

• The fields are column-dependent, as shown in “Statements and parameters for VATLSTxx”.

• There are only two required fields: the volume serial number and the device types. All other fields have defaults.

• Use a comma to separate adjacent fields, except before the optional information field.

• Specify all characters in EBCDIC.

15.20 Complete list of Parmlib Members with changes noted:ADYSETxx (dump suppression)ALLOCxx (allocation system defaults)ANTMIN00 (ANTMAIN control parameters)ANTXIN00 (XRC services)APPCPMxx (define APPC/MVS configuration)ASCHPMxx (APPC/MVS transaction scheduler)AUTORxx (auto-reply policy specifications)AXRxx (system REXX options)BLSCECT (formatting exits for dump and trace analysis)BLSCUSER (installation customization for dump and trace analysis)BPXPRMxx (z/OS UNIX System Services parameters) - /* Changed in V2R3 */CEAPRMxx (common event adapter parameters)CEEPRMxx (runtime option parameters) - /* Clarification added to V2R3 */CLOCKxx (time of day parameters) - /* Changed in V2R3 */CNGRPxx (specify console groups)CNLcccxx (time and date format for translated messages)COFDLFxx (hiperbatch parameters)COFVLFxx (virtual lookaside facility parameters)COMMNDxx (commands automatically issued at initialization)CONFIGxx (standard configuration list)CONSOLxx (consoleconfiguration definition)COUPLExx (cross-system coupling facility (XCF) parameters)CSVLLAxx (library lookaside (LLA) list)CTncccxx (component trace parameters)CUNUNIxx (Unicode Services environment)DEVSUPxx (device support options) - /* Changed in V2R3 */DFHSSIxx (message-formatting initialization member)DIAGxx (control common storage tracking and GFS trace) - /* Changed in V2R3 */EPHWP00 (BookManager topic extraction)EXITxx (allocation installation exit list)EXSPATxx (excessive spin condition actions)FXEPRMxx (IBM Function Registry for z/OS)GRSCNFxx (global resource serialization configuration) - /* New usage noted in V2R3 */GRSMONxx (global resource serialization monitor)GRSRNLxx (global resource serialization resource name lists)GTFPARM (generalized trace facility parameters)GTZPRMxx (Generic Tracker parameters)HZSPRMxx (manage IBM Health Checker for z/OS checks)IDAVDTxx (VSAM dynamic trace parameters)IEAABD00 (ABDUMP written to a SYSABEND data set)IEAAPFxx (authorized program facility list)



IEAAPP00 (authorized I/O appendage routines)IEACMD00 (IBM-supplied commands)IEADMCxx (DUMP command parmlib) - /* New use example in V2R3 */IEADMP00 (ABDUMP written to a SYSUDUMP data set)IEADMR00 (ABDUMP written to a SYSMDUMP data set)IEAFIXxx (fixed LPA list)IEALPAxx (modified LPA list)IEAOPTxx (OPT parameters) - /* Changed in V2R3 */IEAPAKxx (LPA pack list)IEASLPxx (SLIP commands)IEASVCxx (installation-defined SVCs)IEASYMxx (symbol definitions and IEASYSxx members)IEASYSxx (system parameter list) - /* Changed in V2R3 */IECIOSxx (I/O related parameters)IEFOPZxx (data set optimization configuration) - /* Changed in V2R3 */IEFSSNxx (subsystem definitions) - keyword parameter formIFAPRDxx (product enablement policy)IFGPSEDI (enhanced data integrity)IGDSMSxx (storage management subsystem definition) - /* Changed in V2R3 */IGGCATxx (DFSMS catalog configuration) - /* Changed in V2R3 */IKJTSOxx (TSO/E commands and programs) - /* New parameter in V2R3 */IOEPRMxx (z/OS Distributed File Service z/OS File System parameters)IPCSPRnn (Interactive Problem Control System)IQPPRMxx (PCIE related parameters)IVTPRM00 (Communication Storage Manager)IXGCNFxx (system logger initialization parameters) - /* New Parameters in V2R3 */IZUPRMxx (configure IBM z/OS Management Facility) - /* Changed in V2R3 */LNKLSTxx (LNKLST concatenation)LOADxx (system configuration data sets)LPALSTxx (LPA library list)MMSLSTxx (MVS message service list)MPFLSTxx (message processing facility list)MSGFLDxx (message flood automation parameters)MSTJCLxx (master scheduler JCL)NUCLSTxx (customizing the nucleus region)PFKTABxx (program function key table definition)PROGxx (authorized program list, exits, LNKLST sets and LPA) - /* Changed in V2R3 */SCHEDxx (PPT, master trace table, and abend codes for automatic restart)SMFLIMxx (specifying region and memlimit values) - /* Changed in V2R3 */SMFPRMxx (system management facilities (SMF) parameters) - /* Changed in V2R3 */TSOKEY00 (TSO/VTAM time sharing parameters)VATLSTxx (volume attribute list) - /* Changed in V2R3 */XCFPOLxx (XCF PR/SM policy)



16 STATIC SYSTEM SYMBOLS – NO CHANGES

NewEra Software, Inc.

Contact Information

800-421-5035 (Toll-free in North America)

408-520-7100

[email protected]

User Guides and Product Data Sheets:www.newera-info.com/Links.html

a brief look at - · pdf filez/os mvs system commands - v2r3 - sa38-0666-30 z/os jes2...

Documents