Zos1.13 migration

z/OS

Migration
Version 1 Release 13

“When behaviors aren't the same anymore,
Migration actions are called for.”

GA22-7499-19

z/OS

Migration
Version 1 Release 13

GA22-7499-19

Note:
Before using this information and the product it supports, be sure to read the general information under “Notices” on page
307.

This edition applies to version 1 release 13 modification 0 of IBM z/OS (product number 5694-A01) and to all
subsequent releases and modifications until otherwise indicated in new editions.
This edition replaces GA22-7499-18.
When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
© Copyright IBM Corporation 2002, 2011.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.

Contents
Tables . . . . . . . . . . . . . . . ix Verify that virtual storage limits are set properly 26
Back virtual storage with sufficient real and
About this document . . . . . . . . . xi auxiliary storage. . . . . . . . . . . . 28
Update your check customization for modified
Who should read this document . . . . . . . xi
IBM Health Checker for z/OS checks. . . . . 28
How this document is organized . . . . . . . xi
Remove deleted data sets, paths, and references 29
How to use this document . . . . . . . . . xi
Add references to new data sets and paths . . . 35
Conventions and terminology used in this
Accommodate new address spaces . . . . . 36
document . . . . . . . . . . . . . . . xii
Migration actions for everyone after the first IPL of
Related information . . . . . . . . . . . xiv
z/OS V1R13 . . . . . . . . . . . . . . 38

How to send your comments to IBM . . xv
Chapter 3. Hardware migration actions 39
If you have a technical problem . . . . . . . xv
Replace unsupported devices . . . . . . . . 39
Provide for new device installations . . . . . . 40
Summary of changes . . . . . . . . xvii Update your CFRM policy with coupling facility
structure size changes . . . . . . . . . . . 41
Chapter 1. Introduction . . . . . . . . 1 Accommodate ISC-3, PSC, ESCON, FICON,
Typical migration steps . . . . . . . . . . . 1 OSA-Express2, and dial-up modem changes
Using IBM Health Checker for z/OS for migration introduced with the IBM zEnterprise 196 (z196)
checking . . . . . . . . . . . . . . . . 2 server and the IBM zEnterprise 114 (z114) server . . 42
EPSPT replaced by FIXCAT and REPORT Accommodate token ring, HMC, and ISC-3 changes
MISSINGFIX . . . . . . . . . . . . . . 5 introduced with the System z9 platform . . . . . 44
| z/OS Management Facility . . . . . . . . . 5 Migrate from a Sysplex Timer to STP . . . . . . 45
Elements and features that do not have migration Migrate from ICB-4 to Infiniband coupling links . . 46
actions . . . . . . . . . . . . . . . . 5 | Migrate to an IBM zEnterprise server. . . . . . 47
General recommendations and considerations . . 51
Chapter 2. Migration actions for Restrictions . . . . . . . . . . . . . 52
everyone . . . . . . . . . . . . . . 7 Actions you can take before you order a
zEnterprise server . . . . . . . . . . . 53
Migration actions for everyone before installing z/OS
Actions you can take after you order a
V1R13 . . . . . . . . . . . . . . . . 7
zEnterprise server . . . . . . . . . . . 57
Review PSP buckets . . . . . . . . . . . 7
Recommended migration steps . . . . . . . 57
Install coexistence and fallback PTFs . . . . . 8
Migration and exploitation considerations for
Use zSoftCap to identify the effect of capacity
zEnterprise functions . . . . . . . . . . 57
changes . . . . . . . . . . . . . . . 9
Migrate to a System z10 server . . . . . . . . 62
| Stop using Computing Environment (DCE) and
| DCE Security Server . . . . . . . . . . 10
Restrictions . . . . . . . . . . . . . 65
Add or change volumes to keep your z/OS root
Actions you can take before you order a System
file system in a single data set . . . . . . . 11
z10 server . . . . . . . . . . . . . . 66
Verify that you have enough XCF groups in your
Actions you can take after you order a System
CDS and enough XCF members in your XCF
z10 server . . . . . . . . . . . . . . 69
groups . . . . . . . . . . . . . . . 13
Stop using Managed System Infrastructure for
Migration and exploitation considerations for
Setup (msys for Setup) element . . . . . . . 14
System z10 functions . . . . . . . . . . 70
Upgrade Windows 2000, 98, 95, and NT clients 14
Migrate to a System z9 server . . . . . . . . 73
Migration actions for everyone before the first IPL
of z/OS V1R13 . . . . . . . . . . . . . 15
Restrictions . . . . . . . . . . . . . 75
Set up an IPCS environment . . . . . . . . 15
Actions you can take before you order a System
Use IBM-supplied parmlib and proclib members 18
z9 server . . . . . . . . . . . . . . 76
Migrate /etc and /var system control files . . . 19
Actions you can take after you order a System z9
Update automation and procedures for changed
server . . . . . . . . . . . . . . . 78
and deleted messages . . . . . . . . . . 22
Rework and install user modifications . . . . 22
Migrate to a z990 or z890 server . . . . . . . 79
Reconnect non-IBM products . . . . . . . 24
Actions you can take before you install a z990 or
Reconnect subsystems . . . . . . . . . . 25
z890 server . . . . . . . . . . . . . 80
Update operational and other procedures . . . 25

© Copyright IBM Corp. 2002, 2011 iii

Actions you can take when you order a z990 or Specify valid user exits for the IFASMFDL and
z890 server . . . . . . . . . . . . . 85 IFASMFDP programs . . . . . . . . . . 113
Actions you can take after you install z/OS . . 85 Make IFASMFDL and IFASMFDP run in an
Actions you might need to take once you are authorized environment . . . . . . . . . 115
using a z990 or z890 server . . . . . . . . 87 Provide the migrate or new parameter when
running the PFA install script . . . . . . . 116
Chapter 4. Sysplex migration actions 89 Change default locations for LCCA or PCCA
Sysplex actions related to hardware upgrades . . . 89 control blocks to retain 24-bit virtual storage
Sysplex actions to perform before installing z/OS location . . . . . . . . . . . . . . 117
V1R13 . . . . . . . . . . . . . . . . 89 Remove reference to Unicode Services pre-built
Sysplex actions to perform before the first IPL of image CUNIDHC2 . . . . . . . . . . 118
z/OS V1R13 . . . . . . . . . . . . . . 89 Remove classification rules with the ETC work
Sysplex actions to perform after the first IPL of qualifier . . . . . . . . . . . . . . 119
z/OS V1R13 . . . . . . . . . . . . . . 90 Update the SFM policy to control automatic
termination of impaired critical members . . . 120
Accommodate new REUSASID default . . . . 122
Chapter 5. BCP migration actions . . . 91
Review the list of WTORs in parmlib member
BCP actions to perform before installing z/OS
AUTOR00 . . . . . . . . . . . . . 123
V1R13 . . . . . . . . . . . . . . . . 91
BCP actions to perform after the first IPL of z/OS
Evaluate your stand-alone dump data set
V1R13 . . . . . . . . . . . . . . . . 124
allocations and your IPCS processing of them . . 92
| Update Capacity Provisioning Manager
| Consider exploiting WARNUND for new
| parameters to use CIM Client for Java Version 2. 124
| IEASYSxx statements . . . . . . . . . . 93
| Set AUTHQLVL parameter in GRSCNFxx
| Define DASD storage for Predictive Failure
| parmlib member to recognize new GRS qnames . 125
| Analysis . . . . . . . . . . . . . . 94
| Examine use of the CMDS ABEND command 126
| Migrate from SNMP to z/OS BCPii for
| Ensure Runtime Diagnostics is installed before
| communication to the HMC or SE . . . . . . 95
| invoking Predictive Failure Analysis. . . . . 127
| Verify that at least one blank follows all major
| Carry over your existing CPCC policy . . . . 128
| keyword statements . . . . . . . . . . 96
Evaluate applications that parse AMBLIST
| Examine source for dynamic allocation callers
command LISTLOAD or LISTIDR output . . . 129
| that set the S99DSABA and S99ACUCB flags . . 97
Ensure analysis tools interacting with HIS
| Upgrade Java support for Capacity Provisioning 98
output accommodate HIS state change events . 131
| Discontinue use of PGSER to protect and
Detect program objects that have multiple
| unprotect the READONLY nucleus . . . . . 98
INITIAL LOAD segments . . . . . . . . 132
Track CSVRTLS services . . . . . . . . . 99
BCP actions to perform before the first IPL of z/OS
V1R13 . . . . . . . . . . . . . . . . 100 Chapter 6. Communications Server
Create IPL text . . . . . . . . . . . . 100 migration actions. . . . . . . . . . 135
Reassemble the stand-alone dump program . . 101 Communications Server actions to perform before
| Remove references to the MTFTPS utility . . . 102 installing z/OS V1R13 . . . . . . . . . . 135
| Change value for ARM restart processing . . . 103 | IP Services: Define a user ID for the system
| Modify automation that references output from | resolver with an associated OMVS segment . . 135
| D XCF,SYSPLEX console commands . . . . . 104 | IP Services: Ensure storage availability for
| Update LLA for automation . . . . . . . 105 | ancillary input queue for Enterprise Extender
| Accommodate OPERLOG EMCS console name | traffic . . . . . . . . . . . . . . . 137
| change . . . . . . . . . . . . . . 106 | IP Services: Permit IKE daemon running in FIPS
| Adjust CON= system parameter to | mode to use additional ICSF services . . . . 138
| accommodate default change . . . . . . . 107 | IP Services: Migrate from BIND 9.2.0 . . . . 139
| Accommodate HiperDispatch default of YES on | IP Services: Understand and prepare for
| IBM zEnterprise (z196 and z114) . . . . . . 108 | expanded Intrusion Detection Services . . . . 140
| Start Runtime Diagnostics at system | IP Services: Ensure that the FTP user exit
| initialization . . . . . . . . . . . . . 109 | routine FTCHKPWD tolerates an additional
Ensure all modules of an application are | parameter . . . . . . . . . . . . . 141
compiled with the same version of the | IP Services: Understand change in VIPARANGE
IRARASD macro . . . . . . . . . . . 110 | security verification processing . . . . . . 142
| Issue commands from the system console IP Services: Update IP filter policy to filter IP
| regardless of problem determination mode . . 111 fragments correctly for RFC 4301 compliance . . 143
Update automation that handles messages IP Services: Remove customization of SNMP
IEF374I and IEF376I . . . . . . . . . . 112 sysObjectID MIB object in OSNMPD.DATA file . 145
Use the new 16M default buffer size for trace IP Services: Restore resolver UDP request
options with the CTIGRSxx member. . . . . 113 timeout interval duration . . . . . . . . 146

iv z/OS V1R13.0 Migration

IP Services: Ensure applications tolerate a larger PKI Services: Change the time at which the daily
addrinfo structure . . . . . . . . . . . 147 maintenance task runs . . . . . . . . . . 175
IP Services: Release addrinfo storage after
resolver thread task terminates . . . . . . 148 Chapter 8. DFSMS migration actions 177
IP Services: Update syslogd configuration for DFSMS actions to perform before installing z/OS
archiving rules with shared z/OS UNIX file V1R13 . . . . . . . . . . . . . . . . 177
destinations . . . . . . . . . . . . . 149 DFSMSdfp: Back up SMS control data sets . . 177
| SNA Services: Ensure IVTCSM | DFSMSdfp: Accommodate deletion of
| ASSIGN_BUFFER requests do not exceed 500 | NOIMBED and NOREPLICAT LISTCAT
| images for a single CSM buffer . . . . . . 150 | command attributes . . . . . . . . . . 179
SNA Services: Ensure VTAMSG2 in not used in DFSMSdfp: Modify exit routines to support
your VTAMLST definitions . . . . . . . . 150 31-bit UCB addresses . . . . . . . . . . 180
Communications Server actions to perform before DFSMSdfp and DFSMSdss: Redefine existing
the first IPL of z/OS V1R13 . . . . . . . . 151 VSAM data sets that contain the IMBED,
| IP Services: Review VIPARANGE definitions 151 REPLICATE, and KEYRANGE attributes . . . 180
IP Services: Update automation that keys on DFSMSrmm: Replace CIM providers and CIM
TN3270E Telnet server messages . . . . . . 152 classes. . . . . . . . . . . . . . . 183
IP Services: Ensure the TN3270E Telnet server DFSMS actions to perform before the first IPL of
can end automatically when an OMVS z/OS V1R13 . . . . . . . . . . . . . . 184
shutdown command is issued . . . . . . . 152 DFSMSdfp: Ensure that the Language
IP Services: Disable resolver monitoring of name Environment runtime library is available for
server responsiveness. . . . . . . . . . 153 DLLs . . . . . . . . . . . . . . . 184
IP Services: Disable IP validation checks when DFSMSdfp: Update SYS1.IMAGELIB . . . . 185
defining key exchange policy rules for a | DFSMSdfp: Update operator procedures and
dynamic VPN . . . . . . . . . . . . 154 | system automation for new DADSM pre- and
IP Services: Update modified Netstat message | post-processing dynamic exits . . . . . . . 186
catalogs to include timestamp . . . . . . . 155 | DFSMSdfp: Update procedures that use
IP Services: Update /etc configuration files . . 156 | IEBDSCPY alias name to access IEBCOPY . . . 187
| SNA Services: Adjust to the relocation of the DFSMSdfp: Evaluate applications and modify
| VTAM internal trace table . . . . . . . . 157 for EAV enhancements . . . . . . . . . 188
SNA Services: Disable Enterprise Extender DFSMSdfp: Accommodate new DCBE macro
connection health verification . . . . . . . 161 option . . . . . . . . . . . . . . . 189
SNA Services: Code MULTPATH start option DFSMSdss: Build the IPLable stand-alone
when using multipath . . . . . . . . . 161 DFSMSdss image . . . . . . . . . . . 191
Communications Server actions to perform after DFSMSdss: Recompile and link-edit exit
the first IPL of z/OS V1R13 . . . . . . . . 162 routines or applications that change options in
IP Services: Ensure that preference values the ADRUFO block . . . . . . . . . . 192
associated with IPv6 router advertisement DFSMSdss: Modify applications to handle larger
routes are as expected . . . . . . . . . 162 I/O buffers . . . . . . . . . . . . . 193
| DFSMShsm: Accommodate the changed default
Chapter 7. Cryptographic Services | of PDA trace during DFSMShsm startup . . . 194
migration actions. . . . . . . . . . 165 | DFSMShsm: Accommodate the changed SETSYS
Cryptographic Services actions to perform before | FASTREPLICATION command
installing z/OS V1R13 . . . . . . . . . . 165 | DATASETRECOVERY parameter default . . . 195
ICSF: Ensure PKCS #11 applications call | DFSMShsm: Replace user-defined patch with
C_Finalize() prior to calling dlclose() . . . . . 165 | new SETSYS FASTREPLICATION command to
Cryptographic Services actions to perform before | enable ARC1809I messages . . . . . . . . 196
the first IPL of z/OS V1R13 . . . . . . . . 166 | DFSMShsm: Review messages changed from I
| ICSF: Ensure the CSFPUTIL utility is not used | (informational) to E (eventual action) type. . . 197
| to initialize a PKDS . . . . . . . . . . 166 | DFSMShsm: Remove patch that prevents SMS
ICSF: Modify ICSF startup procedure . . . . 167 | MVT chain rebuild . . . . . . . . . . 198
OCSF: Migrate the directory structure . . . . 168 | DFSMShsm: Update operator procedure in the
| System SSL: Ensure PKCS #11 tokens contain | Multicluster CDS environment . . . . . . 199
| complete certificate chains . . . . . . . . 170 DFSMShsm: Remove user-defined patch that
System SSL: Modify applications to address disables or enables use of the DFSMSdss cross
disablement of SSL V3 and TLS session memory API . . . . . . . . . . . . 200
renegotiation . . . . . . . . . . . . 171 DFSMShsm: Configure your security system to
Cryptographic Services actions to perform after the permit started procedures using new address
first IPL of z/OS V1R13 . . . . . . . . . . 172 space identifier . . . . . . . . . . . . 200
| ICSF: Ensure the expected master key support is DFSMShsm: Update applications that depend
| available . . . . . . . . . . . . . . . 173 on QUERY COPYPOOL output . . . . . . 201

Contents v

DFSMShsm: Update applications that depend Remove Version 2 Printer Inventory files at
on LIST command output . . . . . . . . 202 fallback to z/OS V1R11 . . . . . . . . . 228
DFSMShsm: Accommodate the change of Upgrade Java support for IPP Server . . . . 230
ARCBDEXT exit . . . . . . . . . . . 203 Infoprint Server actions to perform before the first
DFSMS actions to perform after the first IPL of IPL of z/OS V1R13 . . . . . . . . . . . 231
z/OS V1R13 . . . . . . . . . . . . . . 204 Remount the Printer Inventory and copy files
| DFSMSdfp: Accommodate 64-bit and AR mode that were customized. . . . . . . . . . 231
| rules enforcement in DFSMS macros. . . . . 204 | Update or remove the region size in the
| DFSMSdfp: Run OAM configuration database | AOPSTART startup procedure . . . . . . . 232
| migration job . . . . . . . . . . . . 205 Upgrade XML for Infoprint Central . . . . . 233
DFSMSdfp: Run OAM DB2 BIND jobs . . . . 205 Migrate from IP PrintWay basic mode to
DFSMSdfp: Use indirect zFS file system data set extended mode . . . . . . . . . . . . 234
catalog support. . . . . . . . . . . . 206 Infoprint Server actions to perform after the first
| DFSMSdss: Accommodate Catalog Search IPL of z/OS V1R13 . . . . . . . . . . . 236
| Interface default change . . . . . . . . . 207 Run aopsetup . . . . . . . . . . . . 236
| DFSMShsm: Stop using the HOLD command to Remove Version 1 Printer Inventory files after
| quiesce activity prior to control data set backup . 208 deploying z/OS V1R13 . . . . . . . . . 237

Chapter 9. DFSORT migration actions 211 Chapter 12. JES2 migration actions 239
DFSORT actions to perform before installing z/OS JES2 actions to perform before installing z/OS
V1R13 . . . . . . . . . . . . . . . . 211 V1R13 . . . . . . . . . . . . . . . . 239
DFSORT actions to perform before the first IPL of Update code to remove references to PDBLENG 239
z/OS V1R13 . . . . . . . . . . . . . . 211 Ensure calls to JES Property Information
Update automation for changed DFSORT Services SSI can handle multiple members. . . 240
messages . . . . . . . . . . . . . . 211 JES2 actions to perform before the first IPL of z/OS
DFSORT actions to perform after the first IPL of V1R13 . . . . . . . . . . . . . . . . 240
z/OS V1R13 . . . . . . . . . . . . . . 212 JES2 actions to perform after the first IPL of z/OS
Use new MOWRK option to prevent the use of V1R13 . . . . . . . . . . . . . . . . 240
memory object storage for work space sort Activate z11 mode. . . . . . . . . . . 240
applications . . . . . . . . . . . . . 212
Change the number of dynamically allocated Chapter 13. JES3 migration actions 245
work data sets using new DYNAPCT option . . 213 JES3 actions to perform before installing z/OS
V1R13 . . . . . . . . . . . . . . . . 245
Chapter 10. Distributed File Service | Modify code that depends on the format of
migration actions. . . . . . . . . . 215 | suppressed split messages in the DLOG . . . 245
Distributed File Service actions to perform before JES3 actions to perform before the first IPL of z/OS
installing z/OS V1R13 . . . . . . . . . . 215 V1R13 . . . . . . . . . . . . . . . . 246
| zFS: Accommodate new DASD space | Avoid redundant *S main,FLUSH command in
| requirements . . . . . . . . . . . . 215 | response to XCF messages . . . . . . . . 246
| zFS: Copy cloned file systems to a compatibility Modify code that uses DATLOREC and
| mode aggregate . . . . . . . . . . . 217 DATINPTR (IATYDAT) as a programming
| zFS: Copy data from zFS multi-file system interface . . . . . . . . . . . . . . 247
| aggregates to zFS compatibility mode JES3 actions to perform after the first IPL of z/OS
| aggregates . . . . . . . . . . . . . 218 V1R13 . . . . . . . . . . . . . . . . 248
| zFS: Ensure sysplex=filesys is available on all
| zFS R11 and R12 systems in a shared file system Chapter 14. Language Environment
| environment. . . . . . . . . . . . . 219 migration actions. . . . . . . . . . 249
| zFS: Verify virtual storage usage . . . . . . 222 Language Environment actions to perform before
Distributed File Service actions to perform before installing z/OS V1R13 . . . . . . . . . . 249
the first IPL of z/OS V1R13 . . . . . . . . 224 Language Environment actions to perform before
| DCE/DFS: Disable DFS Client initialization . . 224 the first IPL of z/OS V1R13 . . . . . . . . 249
Distributed File Service actions to perform after the Determine the impact of added and changed
first IPL of z/OS V1R13 . . . . . . . . . . 225 runtime options . . . . . . . . . . . 249
Update the CSD based on the newest CEECCSD 249
Chapter 11. Infoprint Server migration Update Language Environment load modules in
actions . . . . . . . . . . . . . . 227 the LPA . . . . . . . . . . . . . . 250
Infoprint Server actions to perform before | Convert to CEEPRMxx to set system-level
installing z/OS V1R13 . . . . . . . . . . 227 | default runtime options . . . . . . . . . 251
Increase space in the Printer Inventory file Examine programs that read output when a D
system . . . . . . . . . . . . . . 227 CEE command is issued . . . . . . . . . 252

vi z/OS V1R13.0 Migration

Set runtime options as overrideable or Security Server actions to perform before installing
nonoverrideable in CEEPRMxx parmlib member 253 z/OS V1R13 . . . . . . . . . . . . . . 273
Language Environment actions to perform after the | Normalize user names specified as X.500
first IPL of z/OS V1R13 . . . . . . . . . . 254 | distinguished names in distributed identity
Examine programs that read output from a | filters . . . . . . . . . . . . . . . 273
CICS CLER transaction . . . . . . . . . 254 Security Server actions to perform before the first
Use Unicode Services to create conversion tables 255 IPL of z/OS V1R13 . . . . . . . . . . . 276
Check for duplicate class names . . . . . . 276
Chapter 15. Library Server migration | Normalize user names specified as X.500
actions . . . . . . . . . . . . . . 257 | distinguished names in distributed identity
Library Server actions to perform before installing
| filters . . . . . . . . . . . . . . . 277
Security Server actions to perform after the first
z/OS V1R13 . . . . . . . . . . . . . . 257
IPL of z/OS V1R13 . . . . . . . . . . . 277
Library Server actions to perform before the first
Update database templates . . . . . . . . 277
IPL of z/OS V1R13 . . . . . . . . . . . 257
Copy Library Server configuration files. . . . 257
| Normalize user names specified as X.500
Copy Library Server notes files . . . . . . 258
| distinguished names in distributed identity
| filters . . . . . . . . . . . . . . . 278
Library Server actions to perform after the first IPL
Use new RACDCERT GENCERT and REKEY
of z/OS V1R13 . . . . . . . . . . . . . 258
defaults for digital certificates . . . . . . . 278

Chapter 16. RMF migration actions 259
Chapter 19. SMP/E migration actions 281
RMF actions to perform before installing z/OS
SMP/E actions to perform after installing SMP/E
V1R13 . . . . . . . . . . . . . . . . 259
V3R6 (z/OS V1R13 SMP/E) but before starting to
RMF actions to perform before the first IPL of
use it . . . . . . . . . . . . . . . . 281
z/OS V1R13 . . . . . . . . . . . . . . 259
Authorize use of SMP/E commands and
| Check your automation for Monitor III
services . . . . . . . . . . . . . . 281
| messages ERB812I and ERB813I . . . . . . 259
SMP/E actions to perform after starting to use
RMF actions to perform after the first IPL of z/OS
SMP/E V3R6 (z/OS V1R13 SMP/E) . . . . . . 282
V1R13 . . . . . . . . . . . . . . . . 260
Use an RMF Monitor III reporter version equal
to or later than your RMF Monitor III gatherer Chapter 20. TSO/E migration actions 283
version . . . . . . . . . . . . . . 260 TSO/E actions to perform before installing z/OS
| Determine need of SMF data collection for V1R13 . . . . . . . . . . . . . . . . 283
| Postprocessor Serialization Delay report . . . 261 Do not rely on TSO/E to check the syntax of
Retrieve the distribution of the IN-READY passwords . . . . . . . . . . . . . 283
QUEUE . . . . . . . . . . . . . . 262 TSO/E actions to perform before the first IPL of
z/OS V1R13 . . . . . . . . . . . . . . 284
Chapter 17. SDSF migration actions 263 TSO/E actions to perform after the first IPL of
z/OS V1R13 . . . . . . . . . . . . . . 284
SDSF actions to perform before installing z/OS
Accommodate changes for data sets allocated by
V1R13 . . . . . . . . . . . . . . . . 263
the RECEIVE command . . . . . . . . . 284
SDSF actions to perform before the first IPL of
z/OS V1R13 . . . . . . . . . . . . . . 263
Review and reassemble user exit routines . . . 263 Chapter 21. XL C/C++ migration
Use dynamic statements for ISFPARMS to avoid actions . . . . . . . . . . . . . . 287
reassembly . . . . . . . . . . . . . 264 XL C/C++ actions to perform before installing
SDSF actions to perform after the first IPL of z/OS z/OS V1R13 . . . . . . . . . . . . . . 287
V1R13 . . . . . . . . . . . . . . . . 266 Review the XL C/C++ Migration Guide for the
| Update configuration for sysplex support . . . 266 Application Programmer . . . . . . . . 287
| Review colors on the OPERLOG panel . . . . 267 XL C/C++ actions to perform before the first IPL
| Set the format of device names on the Punch of z/OS V1R13 . . . . . . . . . . . . . 288
| and Reader panels. . . . . . . . . . . 268 XL C/C++ actions to perform after the first IPL of
Set a default for the Initiators panel . . . . . 269 z/OS V1R13 . . . . . . . . . . . . . . 288
Set the format of device names on the Printers Update IPA compiler option IPA(OBJECT) . . . 288
panel . . . . . . . . . . . . . . . 269
Update batch programs or REXX execs for Chapter 22. z/OS UNIX migration
changes to message ISF770W . . . . . . . 270 actions . . . . . . . . . . . . . . 289
Set the view of the OPERLOG . . . . . . . 271
z/OS UNIX actions to perform before installing
z/OS V1R13 . . . . . . . . . . . . . . 289
Chapter 18. Security Server migration | Update invocations of /usr/sbin/mount
actions . . . . . . . . . . . . . . 273 | commands . . . . . . . . . . . . . 289

Contents vii

| Update invocations of /usr/sbin/unmount | Discontinue use of invalid REXX variables in
| commands . . . . . . . . . . . . . 290 | z/OS UNIX syscalls . . . . . . . . . . 302
| Review programs that invoke the Consider skulker invocations due to updated
| BPX1EXM/BPX4EXM callable service . . . . 291 restriction . . . . . . . . . . . . . 302
Accommodate the new Shell and Utilities Use the BPX.UNIQUE.USER profile instead of
version of the tsocmd command . . . . . . 292 BPX.DEFAULT.USER . . . . . . . . . . 303
Remove MAXSOCKETS values from AF_UNIX
in the BPXPRMxx parmlib member . . . . . 293 Appendix. Accessibility . . . . . . . 305
Discontinue use of z/OS UNIX System Services Using assistive technologies . . . . . . . . 305
Connection Scaling . . . . . . . . . . 294 Keyboard navigation of the user interface . . . . 305
Migrate from HFS file systems to zFS file z/OS information . . . . . . . . . . . . 305
systems . . . . . . . . . . . . . . 294
z/OS UNIX actions to perform before the first IPL
Notices . . . . . . . . . . . . . . 307
of z/OS V1R13 . . . . . . . . . . . . . 298
Trademarks . . . . . . . . . . . . . . 308
| Update invocations of MOUNT statements in
Policy for unsupported hardware. . . . . . . 309
| the BPXPRMxx parmlib member . . . . . . 298
| Accommodate changes to support read-only
| z/OS root for the cron, mail, and uucp utilities . 299 Index . . . . . . . . . . . . . . . 311
z/OS UNIX actions to perform after the first IPL of
z/OS V1R13 . . . . . . . . . . . . . . 301

viii z/OS V1R13.0 Migration

Tables
1. PSP bucket upgrades and FIXCAT values for 6. System z10 functions supported by z/OS
z/OS servers . . . . . . . . . . . . 8 V1R11 and z/OS V1R12 and z/OS V1R13 . . 62
2. IPCS data set requirements for a logon 7. Summary of z990 CFCC coexistence support 84
procedure or DD name allocation . . . . . 16 8. Changed Communications Server
3. Data sets and paths deleted from z/OS V1R13 configuration files . . . . . . . . . . 157
and z/OS V1R12 (in alphabetic order by | 9. Coprocessor activation example . . . . . 173
DDDEF name) . . . . . . . . . . . 30 | 10. Coprocessor activation example (ECC support
4. Data sets added to z/OS V1R13 and z/OS | based only on CEX3C coprocessors) . . . . 174
V1R12 (in alphabetic order by DDDEF name) . 36 11. DFSMSrmm CIM classes and compound keys 183
5. zEnterprise functions supported by z/OS | 12. Examples of zFS error messages . . . . . 221
V1R11 and z/OS V1R12 and z/OS V1R13 . . 47

© Copyright IBM Corp. 2002, 2011 ix

About this document
This document describes how to migrate to z/OS® Version 1 Release 13 (V1R13)
from the following releases:
v z/OS V1R12
v z/OS V1R11

This document does not explain how to exploit new functions in z/OS. For that
information, see the many publications that pertain to the z/OS base elements and
optional features.

Who should read this document
This document is intended for system analysts, system programmers, system
administrators, security administrators, network administrators, database
administrators, and other members of an information technology team who have
experience installing and managing z/OS, and want to plan for and implement the
installation of z/OS V1R13.

How this document is organized
The first four chapters of this document are general in scope, that is, not devoted
to a specific z/OS base element or optional feature. Chapter 1 is an introduction,
Chapter 2 describes migration actions for everyone (that is, system-level actions),
Chapter 3 describes hardware migration actions, and Chapter 4 summarizes
sysplex migration actions.

The remaining chapters are devoted to the specific elements and features that have
migration actions, with one element or feature per chapter. These chapters are in
alphabetic order — from BCP (Chapter 5) to z/OS UNIX (Chapter 22). Within each
chapter, the following standard organization is used:
Migration actions to perform before installing z/OS V1R13
Migration actions to perform before the first IPL of z/OS V1R13
Migration actions to perform after the first IPL of z/OS V1R13

How to use this document
Use this document as your initial source for z/OS migration information. Where
appropriate, this document refers you to other documents for additional
information.

Within this document, read Chapter 1, “Introduction,” on page 1. You can then
proceed sequentially through the subsequent chapters or in whatever order you
prefer based on element or feature interest. The chapters are in alphabetic order by
name of element or feature, once you pass the chapter on migration actions for
everyone, the chapter on hardware migration actions, and the chapter on sysplex
migration actions. Another way to proceed is to concentrate first on preinstall
migration actions within each chapter, then pre-IPL migration actions, and then
post-IPL migration actions. These actions are clearly identified by major headings
within each chapter.

© Copyright IBM Corp. 2002, 2011 xi

Conventions and terminology used in this document
When this document refers to IBM® System z® servers without stating a specific
server, it refers to all of the following servers:
| v IBM zEnterpriseTM 114 (z114)
v IBM zEnterpriseTM 196 (z196)
v IBM System z10™ Enterprise Class (z10 EC)
v IBM System z10 Business Class (z10 BC)
v IBM System z9® Enterprise Class (z9 EC), formerly the IBM System z9 109
(z9-109)
v IBM System z9 Business Class (z9 BC)
v IBM eServer™ zSeries® 990 (z990)
v IBM eServer zSeries 890 (z890)

Important terms you should understand are:
v Migration. Migration is the first of two stages in an upgrade to a new release of
z/OS. (The second stage is exploitation.) During this stage you install your new
system with the objective of making it functionally compatible with the previous
system. After a successful migration, the applications and resources on the new
system function the same way (or similar to the way) they did on the old system
or, if that is not possible, in a way that accommodates the new system
differences so that existing workloads can continue to run. Migration does not
include exploitation of new functions except for new functions that are now
required.
v Exploitation. Exploitation is the second of two stages in an upgrade to a new
release of z/OS. (The first stage is migration.) During this stage you do
whatever customizing and programming are necessary to take advantage of
(exploit) the enhancements available in the new release.
v Coexistence. Coexistence is the situation in which two or more systems at
different software levels share resources. The resources could be shared at the
same time by different systems in a multisystem configuration, or they could be
shared over a period of time by the same system in a single-system
configuration.
Examples of coexistence are two different JES releases sharing a spool, two
different service levels of DFSMSdfp sharing catalogs, multiple levels of SMP/E
processing SYSMODS packaged to exploit the latest enhancements, or an older
level of the system using the updated system control files of a newer level (even
if new function has been exploited in the newer level).
The sharing of resources is inherent in multisystem configurations that involve
Parallel Sysplex® implementations. But other types of configurations can have
resource sharing too. Examples of configurations where resource sharing can
occur are:
– A single processor that is time-sliced to run different levels of the system,
such as during different times of the day
– A single processor running multiple images by means of logical partitions
(LPARs)
– Multiple images running on several different processors in either Parallel
Sysplex or non-Parallel Sysplex configurations
The way in which you make it possible for earlier-level systems to coexist with
the most current level is to install coexistence and fallback PTFs on the
earlier-level systems.

xii z/OS V1R13.0 Migration

v Fallback. Fallback is a return to the prior level of a system. Fallback can be
appropriate if you migrate to a new release and, during testing, encounter severe
problems that can be resolved by backing out the new release. By installing
coexistence and fallback PTFs on the “old” system before you migrate, the old
system can tolerate changes that were made by the new system during testing.

To identify the timing of migration actions, this document uses three types of
headings:
v Actions to perform Before installing z/OS V1R13. These are migration actions
that you perform on your current system, either because they require the current
system or because they are possible on the current system. You do not need the
z/OS V1R13 level of code to make these changes, and the changes do not
require the z/OS V1R13 level of code to run once they are made. Examples are
installing coexistence and fallback PTFs on your current system, discontinuing
use of hardware or software that will no longer be supported, and starting to
use existing functions that were optional on prior releases but required in z/OS
V1R13.
v Actions to perform before the first IPL of z/OS V1R13. These are migration
actions that you perform after you have installed z/OS V1R13 but before the
first time you IPL. These actions require the z/OS V1R13 level of code to be
installed but do not require it to be active. That is, you need the z/OS V1R13
programs, utilities, and samples in order to perform the migration actions, but
the z/OS V1R13 system does not have to be IPLed in order for the programs to
run. Examples are running sysplex utilities and updating the RACF® database
template.
It is possible to perform some of the migration actions in this category even
earlier. If you prepare a system on which you will install z/OS V1R13 by
making a clone of your old system, you can perform migration actions that
involve customization data on this newly prepared system before installing
z/OS V1R13 on it. Examples of such migration actions are updating
configuration files and updating automation scripts.
v Actions to perform after the first IPL of z/OS V1R13. These are migration
actions that you can perform only after you have IPLed z/OS V1R13. You need
a running z/OS V1R13 system to perform these actions. An example is issuing
RACF commands related to new functions. Note that the term “first IPL” does
not mean that you have to perform these actions after the very first IPL, but
rather that you need z/OS V1R13 to be active to perform the task. You might
perform the task quite a while after the first IPL.

Each migration action within the headings above is presented using the following
standard format:
v A title that identifies the migration action.
v Description. This is a brief description of the functional change that caused the
migration action.
v Element or feature. This is the name of the base element or optional feature that
changed.
v When change was introduced. This is the z/OS release in which the change was
introduced.
v Applies to migration from. The migration action is relevant if you are migrating
from this release.

About this document xiii

v Timing. This is when you should perform the migration action. There are three
categories: before installing z/OS, before first IPL, or after first IPL. (For SMP/E
there are two categories: after installing SMP/E but before starting to use it, and
after starting to use SMP/E.)
v Is the migration action required? This question refers to the migration action
identified by the title. The answer can be one of the following:
– Yes. The migration action is required in all cases.
– Yes, if... The migration action is required only in a certain case. Most of the
migration actions in this document are in this category.
– No, but recommended... The migration action is not required but is
recommended because it is a good programming practice, because it will be
required in the future, or because it resolves unacceptable system behavior
(such as poor usability or poor performance) even though resolution might
require a change in behavior.
v Target system hardware requirements. This is hardware required by the
functional change. It could be processor and peripheral devices; drivers,
engineering changes, or patches needed; or specific hardware functions that
must be active.
v Target system software requirements. This is software required by the functional
change. It could be z/OS optional features, software products, and PTFs that are
needed on the target system, as well as specific software functions that must be
active.
v Other system (coexistence or fallback) requirements. These are requirements
placed on an earlier release by the functional change in the new release. The
earlier release could be running on a system that shares resources (coexists) with
the new system or it could be the release from which you are migrating (and to
which you might want to fall back).
v Restrictions. These are any known limits on how the function can be used.
v System impacts. These are any known impacts of using the function, such as
increased storage or more time required to run.
v Related IBM Health Checker for z/OS check. These are IBM Health Checker for
z/OS checks available for the migration action.
v Steps to take. This is what you have to do to perform the migration action.
v Reference information. This is a pointer to additional information that helps you
perform the migration action.

The order in which the migration actions are presented does not imply importance
or chronology.

Related information
See z/OS Introduction and Release Guide for an introduction to z/OS and an
overview of the new functions in each release of z/OS.

See z/OS Planning for Installation for a summary of installation changes in each
release of z/OS, driving system hardware and software requirements, target
system hardware and software requirements, the coexistence-migration-fallback
policy, required releases of IBM middleware products, and considerations for
planning future installations.

To view, search, and print z/OS publications, go to the z/OS Internet Library at
http://www.ibm.com/eserver/zseries/zos/bkserv/.

xiv z/OS V1R13.0 Migration

How to send your comments to IBM
We appreciate your input on this publication. Feel free to comment on the clarity,
accuracy, and completeness of the information or give us any other feedback that
you might have.

Use one of the following methods to send us your comments:
1. Send an email to mhvrcfs@us.ibm.com
2. Visit the Contact z/OS web page at http://www.ibm.com/systems/z/os/zos/
webqs.html
3. Mail the comments to the following address:
IBM Corporation
Attention: MHVRCFS Reader Comments
Department H6MA, Building 707
2455 South Road
Poughkeepsie, NY 12601-5400
U.S.A.
4. Fax the comments to us as follows:
From the United States and Canada: 1+845+432-9405
From all other countries: Your international access code +1+845+432-9405

Include the following information:
v Your name and address
v Your email address
v Your telephone or fax number
v The publication title and order number:
z/OS V1R13.0 Migration
GA22-7499-19
v The topic and page number related to your comment
v The text of your comment.
When you send comments to IBM, you grant IBM a nonexclusive right to use or
distribute your comments in any way it believes appropriate without incurring any
obligation to you.

IBM or any other organizations will only use the personal information that you
supply to contact you about the issues that you submit.

If you have a technical problem
Do not use the feedback methods listed above. Instead, do one of the following:
v Contact your IBM service representative
v Call IBM technical support
v Visit the IBM support portal at http://www.ibm.com/systems/z/support/

© Copyright IBM Corp. 2002, 2011 xv

Summary of changes
This topic summarizes the changes made to this document.

Summary of Changes
for GA22-7499-19
September 2011
z/OS Version 1 Release 13

This document contains information previously presented in GA22-7499-18, which
supports z/OS V1R12.

New information:
v The following migration actions are new:
– Migration actions for everyone
- “Stop using Computing Environment (DCE) and DCE Security Server” on
page 10.
– BCP
- “Consider exploiting WARNUND for new IEASYSxx statements” on page
93.
- “Define DASD storage for Predictive Failure Analysis” on page 94.
- “Migrate from SNMP to z/OS BCPii for communication to the HMC or SE”
on page 95.
- “Verify that at least one blank follows all major keyword statements” on
page 96.
- “Examine source for dynamic allocation callers that set the S99DSABA and
S99ACUCB flags” on page 97.
- “Upgrade Java support for Capacity Provisioning” on page 98.
- “Discontinue use of PGSER to protect and unprotect the READONLY
nucleus” on page 98.
- “Remove references to the MTFTPS utility” on page 102.
- “Change value for ARM restart processing” on page 103.
- “Modify automation that references output from D XCF,SYSPLEX console
commands” on page 104.
- “Update LLA for automation” on page 105.
- “Accommodate OPERLOG EMCS console name change” on page 106.
- “Adjust CON= system parameter to accommodate default change” on page
107.
- “Accommodate HiperDispatch default of YES on IBM zEnterprise (z196
and z114)” on page 108.
- “Start Runtime Diagnostics at system initialization” on page 109.
- “Issue commands from the system console regardless of problem
determination mode” on page 111.
- “Update Capacity Provisioning Manager parameters to use CIM Client for
Java Version 2” on page 124.
- “Set AUTHQLVL parameter in GRSCNFxx parmlib member to recognize
new GRS qnames” on page 125.

© Copyright IBM Corp. 2002, 2011 xvii

- “Examine use of the CMDS ABEND command” on page 126.
- “Ensure Runtime Diagnostics is installed before invoking Predictive Failure
Analysis” on page 127.
– Communications Server
- “IP Services: Define a user ID for the system resolver with an associated
OMVS segment” on page 135.
- “IP Services: Ensure storage availability for ancillary input queue for
Enterprise Extender traffic” on page 137.
- “IP Services: Permit IKE daemon running in FIPS mode to use additional
ICSF services” on page 138.
- “IP Services: Understand and prepare for expanded Intrusion Detection
Services” on page 140.
- “IP Services: Ensure that the FTP user exit routine FTCHKPWD tolerates an
additional parameter” on page 141.
- “IP Services: Understand change in VIPARANGE security verification
processing” on page 142.
- “SNA Services: Ensure IVTCSM ASSIGN_BUFFER requests do not exceed
500 images for a single CSM buffer” on page 150.
- “IP Services: Review VIPARANGE definitions” on page 151.
- “SNA Services: Adjust to the relocation of the VTAM internal trace table”
on page 157.
– Cryptographic Services
- “ICSF: Ensure the CSFPUTIL utility is not used to initialize a PKDS” on
page 166.
- “System SSL: Ensure PKCS #11 tokens contain complete certificate chains”
on page 170.
- “ICSF: Ensure the expected master key support is available” on page 173.
– DFSMS
- “DFSMSdfp: Accommodate deletion of NOIMBED and NOREPLICAT
LISTCAT command attributes” on page 179.
- “DFSMSdfp: Update operator procedures and system automation for new
DADSM pre- and post-processing dynamic exits” on page 186.
- “DFSMSdfp: Update procedures that use IEBDSCPY alias name to access
IEBCOPY” on page 187.
- “DFSMShsm: Accommodate the changed default of PDA trace during
DFSMShsm startup” on page 194.
- “DFSMShsm: Accommodate the changed SETSYS FASTREPLICATION
command DATASETRECOVERY parameter default” on page 195.
- “DFSMShsm: Replace user-defined patch with new SETSYS
FASTREPLICATION command to enable ARC1809I messages” on page 196.
- “DFSMShsm: Review messages changed from I (informational) to E
(eventual action) type” on page 197.
- “DFSMShsm: Remove patch that prevents SMS MVT chain rebuild” on
page 198.
- “DFSMShsm: Update operator procedure in the Multicluster CDS
environment” on page 199.
- “DFSMSdfp: Accommodate 64-bit and AR mode rules enforcement in
DFSMS macros” on page 204.
- “DFSMSdfp: Run OAM configuration database migration job” on page 205.

xviii z/OS V1R13.0 Migration

- “DFSMSdss: Accommodate Catalog Search Interface default change” on
page 207.
- “DFSMShsm: Stop using the HOLD command to quiesce activity prior to
control data set backup” on page 208.
– Distributed File Service
- “zFS: Accommodate new DASD space requirements” on page 215.
- “zFS: Copy cloned file systems to a compatibility mode aggregate” on page
217.
- “zFS: Copy data from zFS multi-file system aggregates to zFS compatibility
mode aggregates” on page 218.
- “zFS: Ensure sysplex=filesys is available on all zFS R11 and R12 systems in
a shared file system environment” on page 219.
- “zFS: Verify virtual storage usage” on page 222.
- “DCE/DFS: Disable DFS Client initialization” on page 224.
– Infoprint Server
- “Update or remove the region size in the AOPSTART startup procedure”
on page 232.
– JES3
- “Modify code that depends on the format of suppressed split messages in
the DLOG” on page 245.
- “Avoid redundant *S main,FLUSH command in response to XCF messages”
on page 246.
– Language Environment
- “Convert to CEEPRMxx to set system-level default runtime options” on
page 251.
– RMF
- “Check your automation for Monitor III messages ERB812I and ERB813I”
on page 259.
- “Determine need of SMF data collection for Postprocessor Serialization
Delay report” on page 261.
– SDSF
- “Update configuration for sysplex support” on page 266.
- “Review colors on the OPERLOG panel” on page 267.
- “Set the format of device names on the Punch and Reader panels” on page
268.
– Security Server
- “Normalize user names specified as X.500 distinguished names in
distributed identity filters” on page 273.
– z/OS UNIX
- “Update invocations of /usr/sbin/mount commands” on page 289.
- “Update invocations of /usr/sbin/unmount commands” on page 290.
- “Review programs that invoke the BPX1EXM/BPX4EXM callable service”
on page 291.
- “Update invocations of MOUNT statements in the BPXPRMxx parmlib
member” on page 298.
- “Accommodate changes to support read-only z/OS root for the cron, mail,
and uucp utilities” on page 299.

Summary of changes xix

- “Discontinue use of invalid REXX variables in z/OS UNIX syscalls” on
page 302.

Changed information:
v z/OS Management Facility (z/OSMF) migration actions are located in
"Migrating from an earlier release of z/OSMF" in IBM z/OS Management Facility
Configuration Guide.
v “Elements and features that do not have migration actions” on page 5 has been
updated.
v “Update your check customization for modified IBM Health Checker for z/OS
checks” on page 28 has been updated to reflect new, changed, and deleted IBM
for Health Checker for z/OS checks.
v Table 3 on page 30 has been updated.
v Table 4 on page 36 has been updated.
v “Accommodate ISC-3, PSC, ESCON, FICON, OSA-Express2, and dial-up modem
changes introduced with the IBM zEnterprise 196 (z196) server and the IBM
zEnterprise 114 (z114) server” on page 42 has been updated to include
information about the new IBM zEnterprise 114 (z114) server.
v The z/OS V1R12 migration action, "Migrate to an IBM zEnterprise 196 (z196)
server," has been undated to include information about the new IBM zEnterprise
114 (z114 server) and is now titled, “Migrate to an IBM zEnterprise server” on
page 47.
v "IP Services: Migrate from DNS BIND 9.2.0" and replaced with “IP Services:
Migrate from BIND 9.2.0” on page 139.
v “Determine the impact of added and changed runtime options” on page 249 has
been updated.
v Also, see additional changes indicated by the change bar | in the margin.

Deleted information:
v Approximately 80 migration actions have been deleted because they applied to
migrations from z/OS V1R10, and that release is not supported for migration to
z/OS V1R13.
v z/OS Management Facility (z/OSMF) migration actions can be found in
"Migrating from an earlier release of z/OSMF" in IBM z/OS Management Facility

This document contains terminology, maintenance, and editorial changes. Technical
changes or additions to the text and illustrations are indicated by a vertical line to
the left of the change.

xx z/OS V1R13.0 Migration

Chapter 1. Introduction
Upgrading to a new release of z/OS is usually a two-stage process:
v Stage 1: Migration. During this stage you install your new system with the
objective of making it functionally compatible with the previous system. After a
successful migration, the applications and resources on the new system function
the same way (or similar to the way) they did on the old system or, if that is not
possible, in a way that accommodates the new system differences so that
existing workloads can continue to run. Migration does not include exploitation
of new functions except for new functions that are now required.
v Stage 2: Exploitation. During this stage you do whatever customizing and
programming are necessary to take advantage of (exploit) the enhancements
available in the new release.

This document describes what you must do to migrate from either of the two
releases that are supported for direct migration to z/OS V1R13:
v z/OS V1R12
v z/OS V1R11
If you want to migrate to z/OS V1R13 from any other release, contact your IBM
representative to find out if there are alternatives available.

Typical migration steps
It is possible to make migration changes at the same time you make the changes
necessary to exploit new functions in the new release. However, the more prudent
approach is to do your migration first and then exploit new functions. The typical
steps to accomplish this are:
1. Learn about z/OS V1R13. Good sources of information are z/OS Introduction
and Release Guide, z/OS Planning for Installation, and http://www.ibm.com/
eserver/zseries/zos/.
2. Perform as many of the migration actions as you can on your existing (“old”)
system so that you have fewer actions to perform after you install z/OS
V1R13. In this information, the actions you can perform on your existing
system are identified by headings that say actions to perform before
installing z/OS V1R13. (Note that not all of the actions are required. Some
depend on your environment, configuration, and workload, and are identified
accordingly.) These actions should be made to, or copied (cloned) to, all
existing systems that will be migrated to z/OS V1R13.
Use IBM Health Checker for z/OS to assist with some migration actions. See
“Using IBM Health Checker for z/OS for migration checking” on page 2.
3. Order and install coexistence and fallback service for any system that will
share resources with a z/OS V1R13 system. (See “Install coexistence and
fallback PTFs” on page 8.) This service needs to be installed on all systems
that will coexist with z/OS V1R13 and all systems that will be migrated to
z/OS V1R13 (and which you might fall back to).
4. Prepare the driving system. For driving system requirements, see the topic
about preparing the driving system in z/OS Planning for Installation.
5. Order and install z/OS V1R13. If you use a ServerPac, refer to ServerPac:
Installing Your Order. If you use a CBPDO, refer to z/OS Program Directory.

© Copyright IBM Corp. 2002, 2011 1

6. Prepare target system hardware and software. During this step, perform the
migration actions identified by headings that say actions to perform before
the first IPL of z/OS V1R13. (Again, not all of the actions are required. Some
depend on your environment, configuration, and workload, and are identified
accordingly.)
7. IPL the new z/OS V1R13 system with your updated customization and
configuration files.
8. Perform any migration actions identified by headings that say actions to
perform after the first IPL of z/OS V1R13. (Again, not all of the actions are
required. Some depend on your environment, configuration, and workload,
and are identified accordingly.)
Use IBM Health Checker for z/OS to assist with some migration actions. See
“Using IBM Health Checker for z/OS for migration checking.”
9. Deploy z/OS V1R13 to other systems within a sysplex, data center, and
enterprise.
The migration is now complete.
10. When you are confident that a system, or in some cases all systems in a
sysplex, are not going to fall back to z/OS V1R12 or z/OS V1R11 exploit the
functions introduced in z/OS V1R13.
11. Deploy this exploitation on other systems (again within a sysplex, data center,
and eventually enterprise).

Using IBM Health Checker for z/OS for migration checking
Beginning with z/OS V1R10, the IBM Health Checker for z/OS infrastructure is
being exploited for migration purposes. Checks are being added to help you
determine the applicability of various migration actions. Before you migrate to
your new z/OS release, you should use these new checks to assist with migration
planning. After you migrate, you should rerun them to verify that the migration
actions were successfully performed. As with any IBM Health Checker for z/OS
check, no updates are made to the system. These new migration checks only report
on the applicability of specific migration actions on a system, and only on the
currently active system.

The migration checks are very similar to the other checks provided by IBM Health
Checker for z/OS. The only differences are:
v The names of migration checks follow the convention
ZOSMIGVvvRrr_component_program_name (or, for ICSF,
ICSFMIGnnnn_component_program_name). Notice the “MIG” characters followed
immediately by the release identifier. This convention tells you that the check
helps with migration and it tells you the release in which the migration action
was introduced. If the release in which the migration action was introduced is
not known, the name will be ZOSMIGREC.
v By default, migration checks are inactive. This is because you might not want to
know about migration actions during nonmigration periods.

System REXX health check considerations

All exploiters of the System REXX support in z/OS require that the System REXX
customization be performed. Using the IBM Health Checker for z/OS health
checks is one example of possible System REXX exploitation. In particular, any
compiled REXX execs must have the proper runtime support available from the
Alternate Library for REXX (available in z/OS since V1R9) or from the IBM
Library for REXX on zSeries (5695-014). Several IBM Health Checker for z/OS

2 z/OS V1R13.0 Migration

migration health checks have been written in compiled System REXX. These health
checks rely upon the System REXX customization and runtime activities being
completed. If System REXX (and the security environment that System REXX
requires) have not been properly customized, then System REXX health checks will
not execute successfully.
v For System REXX customization activities, refer to "System REXX" in z/OS MVS
Programming: Authorized Assembler Services Guide.
v For compiled REXX exec runtime availability, see "Alternate Library for REXX
Customization Considerations" in z/OS Program Directory, or refer to product
documentation accompanying IBM Library for REXX on zSeries.

As stated previously, migration checks are intended to be used on your current
z/OS release and then again after you have migrated to your new z/OS release.
The steps you might follow in each of these two scenarios are shown below.

On your current z/OS release:
1. Install the latest migration checks. Review all the latest health checks (for both
best practices and migration) by using the functional PSP bucket HCHECKER
(which is SMP/E FIXCAT IBM.Function.HealthChecker). If you want to see all
IBM Health Checker for z/OS checks see http://www.ibm.com/systems/z/os/
zos/hchecker/check_table.html.
You might want to install the PTFs during a regular service window so that an
IPL is scheduled afterwards. Checks are often added by a function when it is
started or restarted, so you might find that installing the PTFs before a
scheduled IPL works best for you. Additional migration checks can be added at
different times, so having all the latest ones installed prior to making your
migration plans is recommended.
2. Activate the migration checks appropriate to your migration path. Because the
naming convention for migration checks indicates which release introduced the
corresponding migration actions, you can activate just the checks appropriate
for your migration path. Using SDSF (or another method for viewing checks,
such as filters), you can view ahead of time which migration checks you have
available on your system. For example, if you are migrating from z/OS V1R11
to z/OS V1R13 you need to activate the migration checks for changes that
occurred in both z/OS V1R12 and z/OS V1R13. If you are migrating from
z/OS V1R12 to z/OS V1R13, you only need to activate the migration checks for
changes that occurred in z/OS V1R13. There are many ways to make a check
active, as well as many ways of using wildcards to include specific checks.
Here are some examples of using the MODIFY command to make checks
active:
v F HZSPROC,ACTIVATE,CHECK=(IBM*,*MIG*)
v F HZSPROC,ACTIVATE,CHECK=(IBM*,ICSFMIG*)
v F HZSPROC,ACTIVATE,CHECK=(IBM*,ZOSMIGV1R12)
Remember that for z/OS, two naming conventions are used: one for ICSF (that
starts with ICSFMIGnnnn) and one for the rest of z/OS (that starts with
ZOSMIGVvvRrr). Use a wildcard filter that includes the intended migration
checks.
3. Review the migration check output and rerun checks as appropriate. Any exceptions
should be addressed in your migration plan. If you can complete the migration
action prior to moving to the new z/OS release, you can rerun the check to
verify that it was completed correctly on your current system.

Chapter 1. Introduction 3

4. Deactivate the migration checks if you desire. If you no longer desire to have the
migration checks active, you can deactivate them similar to the way you
activated them. For example:
v F HZSPROC,DEACTIVATE,CHECK=(IBM*,*MIG*)
v F HZSPROC,DEACTIVATE,CHECK=(IBM*,ICSFMIG*)
v F HZSPROC,DEACTIVATE,CHECK=(IBM*,ZOSMIGV1R12)

After you have migrated to the new z/OS release, the steps are similar:
1. Install the latest migration checks. New migration checks might be available for
your new z/OS system since you installed it. Therefore, review all the latest
health checks (for both best practices and migration) by using the functional
PSP bucket HCHECKER (which is SMP/E FIXCAT
IBM.Function.HealthChecker). If you want to see all IBM Health Checker for
z/OS checks that are available, see http://www.ibm.com/systems/z/os/zos/
hchecker/check_table.html.
2. Activate the migration checks appropriate to your migration path. For migration
verification, activate the checks appropriate on the release you are migrating
from, migrating through, and migrating to. For example, if you are migrating
from z/OS V1R11 to z/OS V1R13, you need to activate the migration checks
for changes that occurred in both z/OS V1R12 and z/OS V1R13. If you are
migrating from z/OS V1R12 to z/OS V1R13, you only need to activate the
migration checks for changes that occurred in z/OS V1R13. Here are some
examples of using the MODIFY command to make checks active. (These are the
same activation commands shown previously.)
v F HZSPROC,ACTIVATE,CHECK=(IBM*,*MIG*)
v F HZSPROC,ACTIVATE,CHECK=(IBM*,ICSFMIG*)
v F HZSPROC,ACTIVATE,CHECK=(IBM*,ZOSMIGV1R12)
3. Review the migration check output and rerun checks as appropriate. Any exceptions,
which could indicate that a migration action was not performed correctly,
should be addressed. Rerun the check after the corrections have been made.
4. Deactivate the migration checks. Once your migration verification is complete,
deactivate the migration checks similar to the way you activated them. For
example (using the same deactivation commands shown previously):
v F HZSPROC,DEACTIVATE,CHECK=(IBM*,*MIG*)
v F HZSPROC,DEACTIVATE,CHECK=(IBM*,ICSFMIG*)
v F HZSPROC,DEACTIVATE,CHECK=(IBM*,ZOSMIGV1R12)

Within this document, the migration actions that have checks are clearly identified
within the migration actions. All of the checks are made by IBM Health Checker
for z/OS but, as stated earlier, some of the checks are the new migration checks
(identified by names that start with ZOSMIGVvvRrr or ICSFMIGnnnn) and others
are regular health checks.

Note that not all migration actions in this document are addressed by checks;
many migration actions do not lend themselves to programmatic checking.
Therefore, use this document to prepare your migration plan and do not rely solely
on checks.


EPSPT replaced by FIXCAT and REPORT MISSINGFIX
IBM removed the Enhanced PSP Tool (EPSPT), host compare program, and the
associated extract files from the IBM Technical Support web site
(http://www14.software.ibm.com/webapp/set2/psp/srchBroker), effective 31
December 2010. The Enhanced PSP Tool's function has been replaced by the
addition of FIXCAT (fix category) information to Enhanced HOLDDATA and the
REPORT MISSINGFIX function introduced in z/OS V1R10 SMP/E, which offers
distinct advantages over the Enhanced PSP Tool. This SMP/E function is also
available for all supported releases of z/OS in SMP/E for z/OS V3R6 (5655-G44),
which you can order separately.

| z/OS Management Facility
| IBM z/OS Management Facility (z/OSMF) provides system programmers with a
| framework for managing various aspects of a z/OS system through a web browser
| interface. By streamlining some traditional tasks and automating others, z/OSMF
| can help to simplify the day-to-day operations and administration of a z/OS
| system. For more information about z/OSMF, see www.ibm.com/systems/z/os/
| zos/zosmf/.

| For information about z/OSMF migration steps, see "Migrating from an earlier
| release of z/OSMF" in IBM z/OS Management Facility Configuration Guide.

Elements and features that do not have migration actions
The following z/OS V1R13 elements and features do not have migration actions
and thus are not discussed:
v Alternate Library for REXX
v BDT
v BDT File-to-File
v BDT SNA NJE
v BookManager® BUILD
v BookManager READ
| v CIM
v Communications Server Security Level 3
v EREP
v ESCON® Director Support
v FFST
v GDDM
v GDDM-PGF
v GDDM-REXX
v HCD
| v HCM
v HLASM
v HLASM Toolkit
v IBM HTTP Server
v ICKDSF
| v Integrated Security Services
v ISPF
v Metal C Runtime Library
v MICR/OCR
v NFS
v Run-Time Library Extensions
v TIOC
| v z/OS IBM TDS

Chapter 1. Introduction 5

v z/OS Security Level 3
v 3270 PC File Transfer Program


Chapter 2. Migration actions for everyone
Migration actions for everyone before installing z/OS Use IBM-supplied parmlib and proclib members 18
V1R13 . . . . . . . . . . . . . . . . 7 Migrate /etc and /var system control files . . . 19
Review PSP buckets . . . . . . . . . . . 7 Update automation and procedures for changed
Install coexistence and fallback PTFs . . . . . 8 and deleted messages . . . . . . . . . . 22
Use zSoftCap to identify the effect of capacity Rework and install user modifications . . . . 22
changes . . . . . . . . . . . . . . . 9 Reconnect non-IBM products . . . . . . . 24
| Stop using Computing Environment (DCE) and Reconnect subsystems . . . . . . . . . . 25
| DCE Security Server . . . . . . . . . . 10 Update operational and other procedures . . . 25
Add or change volumes to keep your z/OS root Verify that virtual storage limits are set properly 26
file system in a single data set . . . . . . . 11 Back virtual storage with sufficient real and
Verify that you have enough XCF groups in your auxiliary storage. . . . . . . . . . . . 28
CDS and enough XCF members in your XCF Update your check customization for modified
groups . . . . . . . . . . . . . . . 13 IBM Health Checker for z/OS checks. . . . . 28
Stop using Managed System Infrastructure for Remove deleted data sets, paths, and references 29
Setup (msys for Setup) element . . . . . . . 14 Add references to new data sets and paths . . . 35
Upgrade Windows 2000, 98, 95, and NT clients 14 Accommodate new address spaces . . . . . 36
Migration actions for everyone before the first IPL Migration actions for everyone after the first IPL of
of z/OS V1R13 . . . . . . . . . . . . . 15 z/OS V1R13 . . . . . . . . . . . . . . 38
Set up an IPCS environment . . . . . . . . 15

This topic describes general migration actions that apply to everyone, regardless of
which elements and features you use.

Migration actions for everyone before installing z/OS V1R13
This topic describes general migration actions that you can perform on your
current (old) system. You do not need the z/OS V1R13 level of code to make these
changes, and the changes do not require the z/OS V1R13 level of code to run once
they are made.

Review PSP buckets
Description: You should check the preventive service planning (PSP) “buckets” for
important software and hardware installation and maintenance information that
occurs too late in the development cycle to be included in the product publications.
Included are PTFs for both service and small programming enhancements (SPEs).

Element or feature: Multiple.
When change was introduced: General migration action not tied to a
specific release.
Applies to migration from: z/OS V1R12 and z/OS V1R11.
Timing: Before installing z/OS V1R13.
Is the migration action required? Yes.
Target system hardware requirements: None.
Target system software requirements: None.
Other system (coexistence or fallback) None.
requirements:
Restrictions: None.
System impacts: None.


Related IBM Health Checker for z/OS None.
check:

Steps to take:
1. Identify which PSP buckets to review. For this task you will need to know:
v PSP bucket upgrade IDs (or “upgrades”). The most relevant upgrades are
those related to z/OS V1R13 and its servers. The z/OS V1R13 upgrade is
ZOSV1R13; the server upgrades are shown in Table 1.
v FIXCAT values if you use the SMP/E REPORT MISSINGFIX command in
conjunction with the FIXCAT type of HOLDDATA (as mentioned in the tip
below). The FIXCAT values are shown in Table 1. Note that the values shown
are for the minimum support necessary for the servers. If you exploit
additional functions on a server, the FIXCAT value will have additional
qualifiers.
Table 1. PSP bucket upgrades and FIXCAT values for z/OS servers
Server Upgrade FIXCAT value
| z114 2818DEVICE IBM.Device.Server.z114-2818
z196 2817DEVICE IBM.Device.Server.z196-2817
z10 EC 2097DEVICE IBM.Device.Server.z10-EC-2097
z10 BC 2098DEVICE IBM.Device.Server.z10-BC-2098
z9 EC 2094DEVICE IBM.Device.Server.z9-EC-2094
z9 BC 2096DEVICE IBM.Device.Server.z9-BC-2096

2. Obtain the PSP buckets from http://www14.software.ibm.com/webapp/set2/
psp/srchBroker or from IBMLink.
3. Review the PSP buckets and take whatever actions are prescribed.

Tip: To simplify finding the appropriate PSP bucket and identifying which PTFs
listed in the PSP bucket need to be installed on your system, you can use SMP/E
FIXCATs and the REPORT MISSINGFIX command. (The FIXCAT values are shown
in Table 1.)

Reference information:
v For z/OS subsets, see z/OS Program Directory.
v For details about the SMP/E REPORT MISSINGFIX command, see SMP/E
Commands.

Install coexistence and fallback PTFs
Description: Coexistence and fallback PTFs installed on pre-z/OS V1R13 systems
allow those systems to coexist with z/OS V1R13 systems during your migration,
and allow backout from z/OS V1R13 to the previous systems if necessary.
Coexistence and fallback are important because they allow you to migrate systems
in a multisystem configuration to z/OS V1R13 using rolling IPLs (one system at a
time), allowing for continuous application availability.


specific release.
Other system (coexistence or fallback) Install the appropriate PTFs.
requirements:
Restrictions: None.
check:

Steps to take: Before introducing z/OS V1R13 into your environment, install
coexistence and fallback PTFs on all pre-z/OS V1R13 systems with which your
z/OS V1R13 system will coexist.

Use the SMP/E REPORT MISSINGFIX command in conjunction with the FIXCAT
type of HOLDDATA as follows:
1. Acquire and RECEIVE the latest HOLDDATA onto your pre-z/OS V1R13
systems. Use your normal service acquisition portals or download the
HOLDDATA directly from http://service.software.ibm.com/holdata/
390holddata.html. Ensure that you select Full from the Download NOW
column to receive the FIXCAT HOLDDATA, as the other files do not contain
FIXCATs.
2. Run the SMP/E REPORT MISSINGFIX command on your pre-z/OS V1R13
systems and specify a Fix Category (FIXCAT) value of “IBM.Coexistence.z/
OS.V1R13”. The report will identify any missing coexistence and fallback PTFs
for that system. For complete information about the REPORT MISSINGFIX
command, see SMP/E Commands.
3. Periodically, you might want to acquire the latest HOLDDATA and rerun the
REPORT MISSINGFIX command to find out if there are any new coexistence
and fallback PTFs.

Reference information: For an explanation of the z/OS coexistence-migration-
fallback policy, see the coexistence and fallback topic in z/OS Planning for
Installation.

Use zSoftCap to identify the effect of capacity changes
Description: The zSoftware Migration Capacity Planning Aid (zSoftCap) is a
PC-based tool that evaluates the effects of software release migrations.

specific release.

Chapter 2. Migration actions for everyone 9

Is the migration action required? No, but recommended to help in assessing
processor capacity and available resources
when migrating to new software levels.
Target system hardware requirements: This tool runs on your workstation.
Requirements are:
| v A dual-core technology, or faster,
| processor.
v An SVGA display 1024 x 768 or better.
| v Approximately 5 MB of hard disk space
| for the zSoftCap application and user's
| guide, plus 80 MB for the IBM Java 1.6
| runtime environment.

Target system software requirements: This tool runs on your workstation.
Requirements are:
| v Windows 7 or Windows XP.
| v IBM Java 1.6, or later, runtime
environment. This environment is available
with the tool.
requirements:
Restrictions: None.
check:

Steps to take:
| v Download zSoftCap from one of the following web sites:
| – Customers: http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/
| PRS268.
| – Business partners: http://partners.boulder.ibm.com/src/atsmastr.nsf/Web/
| Techdocs. Note that this requires an ID on PartnerWorld®.
v Run zSoftCap to determine your expected increase in CPU utilization (if any)
and to identify your storage requirements, such as how much storage is needed
to IPL.

Reference information: zSoftCap User's Guide, which is provided with the tool.

| Stop using Computing Environment (DCE) and DCE Security
| Server
| Description: Starting with z/OS V1R13, the Distributed Computing Environment
| (DCE) and DCE Security Server elements of z/OS will no longer be shipped. Any
| product or application with direct or indirect dependency on either of these DCE
| elements of z/OS needs to be migrated to another solution.
| v DCE includes the following interfaces that other products or applications
| depend on:
| – DCE RPC (DCE Remote Procedure Call)
| – CDS (DCE Cell Directory Service)
| – DTS (DCE Distributed Time Service)


| – DCE Threads Service
| – IDL (Interface Definition Language – part of RPC, but widely used)
| v Other products known to depend on DCE interfaces include the following:
| – The DCE Security Server
| – DFS (Distributed File Service)
| – DCE Application Support Server (no longer supported; used IDL and RPC
| Runtime to interface with back ends like CICS, IMS, OTMA, etc.)
|
| Element or feature: Multiple.
| When change was introduced: z/OS V1R13 (previewed in z/OS V1R12
| Software Announcement 210-235, dated July
| 22, 2010).
| Applies to migration from: z/OS V1R12 and z/OS V1R11.
| Timing: Before installing z/OS V1R13.
| Is the migration action required? Yes.
| Target system hardware requirements: None.
| Target system software requirements: None.
| Other system (coexistence or fallback) None.
| requirements:
| Restrictions: None.
| System impacts: None.
| Related IBM Health Checker for z/OS ZOSMIGREC_SMB_RPC available in APAR
| check: OA30117.
|

| Steps to take:
| v Look for:
| – DCEKERN started task is necessary for your product or application to work,
| or
| – DCE API function calls are made by your product or application, including
| calls to the RPC Runtime.
| v Then migrate:
| – All dependencies on any DCE technology to an equivalent offering from
| another product (IBM WebSphere Application Server, the IBM Network
| Authentication Service, or the IBM Directory Server). For more information,
| see the DCE Replacement Strategies Redbook at http://
| www.redbooks.ibm.com/redbooks/pdfs/sg246935.pdf..

| Reference information: DCE Replacement Strategies Redbook at
| http://www.redbooks.ibm.com/redbooks/pdfs/sg246935.pdf..

Add or change volumes to keep your z/OS root file system in
a single data set
Description: Because of release enhancements and service, the size of the z/OS
root file system (or “version root file system”) continues to grow from release to
release. As of z/OS V1R10, the size of the z/OS root file system, whether HFS or
zFS, was approximately 3100 cylinders on a 3390 Direct Access Storage Device.
This is close to the limit of 3339 cylinders on a 3390-3 device.


It is advisable to have the z/OS root file system within a single data set for ease of
management.

specific release.
Is the migration action required? No, but recommended for ease of
management if your z/OS root file system
resides on a 3390-3 volume (or another
DASD volume that is close to the 3390-3
limit of 3339 cylinders).
requirements:
Restrictions: None.
Related IBM Health Checker for z/OS Use IBM Health Checker for z/OS check
check: CHECK(IBMUSS,
ZOSMIGREC_ROOT_FS_SIZE) to determine
if a volume has enough space for the z/OS
root file system. This capability is available
in z/OS V1R11 with PTF UA49363 (APAR
OA28684) installed.

Steps to take: To keep the z/OS root file system in a single data set, do one of the
following:
v Move your z/OS root file system to a larger DASD volume geometry.
v Use multiple volumes for the z/OS root file system data set.

If your z/OS root data set cannot fit on the volume or volumes you have defined
for it, divide the z/OS root, with the smaller file systems being managed together.

Remember that all systems to which you deploy the z/OS root file system need
sufficient DASD space to hold the z/OS root.

Beginning with z/OS V1R11 ServerPac, the default device type is changed to
3390-9 instead of 3390-3 in the Modify System Layout panels.

Tip:
v File systems for subsystems and products other than the z/OS product itself
might also increase in size. When examining the volume for how much space
your z/OS file system is using, check other product file system sizes too.

Reference information: For more information about multivolume data sets, see
z/OS DFSMS Implementing System-Managed Storage.


Verify that you have enough XCF groups in your CDS and
enough XCF members in your XCF groups
Description: Over time, as various z/OS functions and applications exploit XCF
services, you must ensure that there is enough space in the sysplex couple data set
for all the XCF groups and members that are to be defined by the exploiters. It is
possible that your sysplex couple data set could contain an inadequate number of
XCF groups or members.

| Note: Starting with z/OS V1R13, JES2 is using new XCF groups for its spool
| migration enhancement. JES spool migration utilizes tasks on all members of
| a MAS to manage the migration of a spool volume's data and the access to
| that migrating or migrated data. These various tasks communicate using
| messages sent through JESXCF services. The JESXCF services utilize one
| XCF group for each active migration to identify what messages are for
| which active migration. XCF groups are a limited system resource, so JES2
| limits the number of concurrent active migrations to five. If you plan to
| perform spool migrations, verify that you have up to five XCF groups
| available if you intend to have up to five spool migrations active at any
| given time. JES2 will only utilize the number of XCF groups available, up to
| five, for spool migrations.

specific release.
Is the migration action required? No, but recommended to ensure that you
have an adequate number of XCF groups
and members formatted in your sysplex
couple data sets.
requirements:
Restrictions: None.
check: XCF_SYSPLEX_CDS_CAPACITY, which
checks the adequacy of the number of
groups, members, and systems for which a
sysplex CDS is formatted.

Steps to take:
1. Issue the DISPLAY XCF,COUPLE command on your current system. Notice the
values of MAXGROUP and PEAK for your sysplex couple data sets. These
values show you the maximum number of XCF groups that the couple data
sets can support, and the peak number of XCF groups ever in use in the
sysplex. Also notice the values of MAXMEMBER and PEAK for your sysplex
couple data sets. These values show you the maximum number of members
that the couple data set can support in one group, and the greatest number of
members ever in use in the largest group in the sysplex.


2. If your peak member value is close to the maximum member value, you might
want to reformat your sysplex couple data sets to support a larger maximum
number of members to be used by any one group.

v For information about formatting sysplex couple data sets with the MAXGROUP
and MAXMEMBER parameters, see z/OS MVS Setting Up a Sysplex.
v For information about the DISPLAY XCF command, see z/OS MVS System
Commands.

Stop using Managed System Infrastructure for Setup (msys
for Setup) element
Description: Starting in z/OS V1R12, support is withdrawn for Managed System
Infrastructure for Setup (msys for Setup). In the future, IBM intends to continue to
deliver improvements to help with z/OS setup and configuration.

When change was introduced: zOS V1R12 (previewed in Announcement
Letter Number AP05-1215 dated July 27,
2005).
Applies to migration from: z/OS V1R11.
Is the migration action required? Yes, if you use msys for Setup.
requirements:
Restrictions: None.
check:

Steps to take: Discontinue using msys for Setup for function enablement, setup, or
configuration of z/OS.

Reference information: For software supported with z/OS, see the software
requirements topic in z/OS Planning for Installation.

Upgrade Windows 2000, 98, 95, and NT clients
Description: z/OS does not support service for client operating systems whose
service is withdrawn by the operating system manufacturer. As a result, IBM no
longer supports service for clients running Windows 2000, Windows 98, Windows
95, or Windows NT Workstation 4.xx.

When change was introduced: 13 August 2002 in the z/OS V1R4 availability
announcement.


Is the migration action required? No, but recommended because z/OS does
not support service for client operating
systems whose service is withdrawn by the
operating system manufacturer.
requirements:
Restrictions: None.
check:

Steps to take: Use a supported follow-on to Windows 2000, Windows 98, Windows
95, or Windows NT Workstation 4.xx.

Reference information: For client software supported with z/OS, see the software
requirements topic in z/OS Planning for Installation.

Migration actions for everyone before the first IPL of z/OS V1R13
This topic describes general migration actions that you can perform after you have
installed z/OS V1R13 but before the first time you IPL. These actions might
require the z/OS V1R13 level of code to be installed but do not require it to be
active.

Set up an IPCS environment
Description: The interactive problem control system (IPCS) is a tool in the BCP
that provides formatting and analysis support for dumps and traces. You must set
up an IPCS environment so that you can process any dumps taken on the
newly-built z/OS system.

specific release.
Timing: Before the first IPL of z/OS V1R13.
Is the migration action required? Yes, if the target system cannot be used for
native IPCS and usage of IPCS for
information produced by the target system is
necessary.


Other system (coexistence or fallback) Ensure that the current IPCS data sets are
requirements: accessible from an earlier system for
debugging a dump. You can ensure this by
putting the IPCS data sets on a volume that
is shared between your current system and
your earlier system.

Tip: If it is necessary to have unique IPCS
data set names for your current system
(because you already have the IPCS data sets
with similar names on your earlier system),
you can create a unique alias in your catalog
that resolves to the current IPCS data sets.
This will allow you to have
“duplicately”-named IPCS data sets, which
are uniquely referenced.

When using unique aliases, remember that
you may have to update the security
definition for the unique high-level qualifier
used in the catalog.
Restrictions: None.
check:

Steps to take: Set up an IPCS environment. For guidance, use the information
listed in “Reference information” below. During setup, ensure that your logon
procedure points to the target system's level of IPCS data sets, which are shown in
Table 2.
Table 2. IPCS data set requirements for a logon procedure or DD name allocation
DD name Data set name Notes®
IATTABL SYS1.SIATTBL0, if applicable This is a JES3 data set. If you
use JES3, ensure that this
data set corresponds to the
level of JES3 that you are
running with z/OS V1R13.


Table 2. IPCS data set requirements for a logon procedure or DD name
allocation (continued)
IPCSPARM SYS1.PARMLIB This is the data set that
contains all the shipped
Note: This DD name is z/OS V1R13 parmlib IPCS
needed if one of the members. If the copies of
following is true: BLSCECT and all the other
v The system on which the IPCS members are not at
dump was taken has z/OS V1R13 level, then IPCS
different BCP and JES might fail when you attempt
levels than the system on to use it.
which the dump will be SYS1.SHASPARM, if This is a JES2 data set. If you
examined using IPCS. applicable use JES2, ensure that this
v You have not specified data set corresponds to the
these data sets in your level of JES2 that you are
system's parmlib running with z/OS V1R13.
concatenation.
SYS1.SIATPARM, if This is a JES3 data set. If you
applicable use JES3, ensure that this
ISPMLIB SYS1.SBLSMSG0
SYS1.SIATMSG0, if This is a JES3 data set. If you
ISPPLIB SYS1.SBLSPNL0
SYS1.SHASPNL0, if This is a JES2 data set. If you
SYS1.SIATPNL0, if applicable This is a JES3 data set. If you
ISPSLIB SYS1.SBLSKEL0
ISPTLIB SYS1.SBLSTBL0


Table 2. IPCS data set requirements for a logon procedure or DD name
allocation (continued)
STEPLIB SYS1.MIGLIB

Note: This DD name is SYS1.SIEAMIGE This data set was added in
needed if the system on z/OS V1R7. It is a PDSE
which the dump was taken data set that complements
has different BCP and JES SYS1.MIGLIB. This data set
levels than the system on is used along with
which the dump will be SYS1.MIGLIB for IPCS.
examined using IPCS. SYS1.SHASMIG, if applicable This is a JES2 data set. If you
running with z/OS V1R13
SYS1.SIATMIG, if applicable This is a JES3 data set. If you
SYSEXEC SYS1.SIATCLI0, if applicable This is a JES3 data set. If you
SYSPROC SYS1.SBLSCLI0

v For more information about IPCS, see z/OS MVS IPCS Customization.
v For more information about the correct logon procedure updates, see the z/OS
Program Directory.
v For information about setting up the JES2 IPCS environment, see z/OS JES2
Diagnosis.
v For information about setting up the JES3 IPCS environment, see z/OS JES3
Diagnosis.
v For additional information, see z/OS Communications Server: IP Diagnosis Guide.

Use IBM-supplied parmlib and proclib members
Description: Ensure that all new and changed parmlib and proclib members that
are shipped in z/OS V1R13 are updated in your parmlib and proclib
concatenations.

specific release.


requirements:
Restrictions: None.
check:

Steps to take:
v For parmlib, add the data set pointed to by the z/OS V1R13 PARMLIB DDDEF
to your parmlib concatenation. The data set should generally be added last in
the concatenation, and you should make sure that the other data sets in the
concatenation do not have members with the same names as IBM-supplied
members. If you place the data set on the system residence volume and use an
indirect catalog entry, future migrations will not require this particular migration
step.
v For proclib:
1. Ensure that the default proclib members have been copied to your default
proclib to pick up the new and changed members.
2. Update individual sample members provided and ensure they are accessible
to the system, as shown in the table of proclib member updates in z/OS
Program Directory.
3. Ensure that the procedure libraries listed in the table of libraries to be added
to the proclib concatenation in z/OS Program Directory have been placed in
the necessary procedure library concatenations and are available to the
system.

Reference information: For lists of parmlib and proclib members that are shipped,
see z/OS Program Directory.

Migrate /etc and /var system control files
Description: The /etc and /var directories contain system control files. The /etc
directory contains customization data that you maintain and the /var directory
contains customization data that IBM maintains.

The following elements and features use /etc:
v BCP (Predictive Failure Analysis). See “Provide the migrate or new parameter
when running the PFA install script” on page 116.
v CIM.
v Communications Server (IP Services component). See “IP Services: Update /etc
configuration files” on page 156.
v Cryptographic Services (PKI Services and System SSL components).
v DFSMSrmm.
v Distributed File Service. The SMB server uses /etc/dfs.
v IBM HTTP Server.
| v z/OS IBM TDS (LDAP server component) uses /etc/ldap.
v Infoprint Server. See “Remount the Printer Inventory and copy files that were
customized” on page 231.
v Library Server. See “Library Server actions to perform before the first IPL of
z/OS V1R13” on page 257.


v z/OS UNIX.

The following elements and features use /var:
v Cryptographic Services (OCSF component). See “OCSF: Migrate the directory
structure” on page 168.
v DFSMSrmm.
v z/OS IBM TDS (LDAP server component) uses /var/ldap.
v Infoprint Server. See “Remount the Printer Inventory and copy files that were
customized” on page 231.
v Integrated Security Services. The Network Authentication Service component
uses /var/skrb.

During installation, subdirectories of /etc and /var are created. If you install z/OS
using ServerPac or SystemPac®, some files are loaded into /etc and /var because
of the customization performed in ServerPac and SystemPac. You have to merge
the files in /etc and /var with those on your previous system. If you install z/OS
using CBPDO, you should copy the files from your old system to the z/OS V1R13
/etc and /var subdirectories.

After merging or copying the contents of /etc and /var, you have to inspect and
modify the files as necessary to reflect z/OS V1R13 requirements.

specific release.
requirements:
Restrictions: None.
check:

Steps to take: Copy files from your old system to the z/OS V1R13 /etc and /var
subdirectories, and then modify the files as necessary to reflect z/OS V1R13
requirements. If you have other files under your existing /var directory, then you
will have to merge the old and new files under /var. The easiest way to do this is
to create a clone of your current /var file system and then copy the new /var files
into the clone.

Many z/OS UNIX utilities are available for comparing and copying directory
structures and files. Two that are especially helpful for /etc and /var migration
work are:
v diff (with the -r option, for recursion): This utility is very useful for comparing
the path structures and file contents, and has many options available. The


dircmp utility has fewer options for directory comparisons, and the cmp utility
stops after the first difference in a file comparison and has output that is more
cumbersome.
v pax: The -rw option works like a copy (instead of making or extracting from a
single file archive) for directories, symbolic links, and files. Consider the -pe
option for saving the attributes when doing the copy. The -k option prevents
overwriting of existing files.

To determine what you need to migrate, first compare the ServerPac's /etc and
/var file systems with your existing /etc and /var file systems. Mount a copy of
your existing /etc and /var file systems to a location outside the ServerPac file
system. For instance, you might have your ServerPac file systems at
/ServerPac/zOS_Rx/etc and /ServerPac/zOS_Rx/var, and your existing file systems
at /Service/ImageX/etc and /Service/ImageX/var. You might have several file
systems to mount that are copies of each of your image's /etc and /var file
systems (ImageX, ImageY, and ImageZ, for instance). To compare the ServerPac
and existing system's /etc and /var, you can run two z/OS UNIX commands,
such as:
diff -r /ServerPac/zOS_Rx/etc /Service/ImageX/etc
diff -r /ServerPac/zOS_Rx/var /Service/ImageX/var

These command results will give you a list of the changes that your existing
system's /etc and /var file systems are missing—both the structure differences and
the file content differences.

Once you know the directories, symbolic links, and files you are missing from your
existing system, there are several ways to propagate the ServerPac information
forward:
v You could use the pax command (with the -k option) to copy from the ServerPac
/etc and /var file systems to each of your existing system's /etc and /var file
systems. For example:
cd /ServerPac/zOS_Rx/etc
pax -rvwk -pe * /Service/ImageX/etc

Another example:
cd /ServerPac/zOS_Rx/var
pax -rvwk -pe * /Service/ImageX/var

The pax command is a good choice because it copies all files, directories, and
symbolic links for each file system from the ServerPac system using a single
command without overlaying any existing files.
v You could rerun the product-supplied MKDIR jobs to recreate the directories and
symbolic links on each of your existing system's /etc and /var file systems. (A
list of the MKDIR jobs is found in z/OS Program Directory and the other program
directories for the products that were in your ServerPac order.) MKDIR jobs are
designed to be run multiple times without damaging your existing file system.
For the files under /var/ocsf, rerun the OCSF-supplied ocsf_install_crypto
installation script. Or, you can combine these jobs and script them into a single
batch job to make the execution more consolidated and repeatable.

After you have made the changes to a copy of your existing image's /etc and /var
file systems, you can unmount them and use them for your deployment of the
ServerPac system, as your schedule indicates. Remember, you are using copies of


your existing /etc and /var file systems, and you are preserving what you had
previously by modifying copies, so your customization for those specific existing
images is not lost.

Reference information: None.

Update automation and procedures for changed and deleted
messages
Description: Every release, many messages change and some are deleted. If you
use automation programs to handle messages, or you have operator or other
procedures that deal with messages, you should update the programs or
procedures appropriately.

specific release.
Is the migration action required? Yes, if you use automation programs or other
procedures to handle messages.
requirements:
Restrictions: None.
check:

Steps to take: Review the lists of changed and deleted messages at Summary of
message changes in z/OS Summary of Message and Interface Changes. Update
programs that automate on these messages and make other necessary
accommodations.

Also, see the following migration actions, which have greater detail about some of
the message changes:
| v “Update automation that handles messages IEF374I and IEF376I” on page 112
| v “Update automation for changed DFSORT messages” on page 211
v “Migrate from IP PrintWay basic mode to extended mode” on page 234
| v “Modify code that depends on the format of suppressed split messages in the
| DLOG” on page 245

Reference information: For a list of changed and deleted messages, see z/OS
Summary of Message and Interface Changes.

Rework and install user modifications
Description: A user modification is a change constructed by a user to modify an
existing function, add to an existing function, or add a user-defined function.
Common types of user modifications are:
v User-written and vendor-written exit routines.


v User-written and vendor-written SVCs.
v User-written and vendor-written termination routines.
v Modifications of IBM source code.
v Unit information modules (UIMs) for non-IBM hardware.
v User-written and vendor-written modules that are listed in a NUCLSTxx parmlib
member.
v Updates to default modules to set site defaults differently than the IBM-supplied
defaults, such as for the following element and features:
– C/C++ without Debug Tool.
– DFSORT. Consider using ICEPRMxx parmlib members, introduced in z/OS
V1R10, to eliminate the assembler language installation option modules.
– HLASM.
– ISPF (specifically, the ISPF configuration table).
– Language Environment®. Consider using the CEEROPT module, which can be
used to specify runtime options for CICS®, IMS™ LRR, and other LRR users.
Also consider using the CEEPRMxx parmlib member, introduced in z/OS
V1R7, to eliminate the assembler language runtime option modules. See
“Determine the impact of added and changed runtime options” on page 249
for more information about CEEPRMxx.
– SDSF (ISFPARMS customization). See “Use dynamic statements for ISFPARMS
to avoid reassembly” on page 264 for further information.

If you made any user modifications, you have to determine which ones need to be
reworked and which ones just need to be reinstalled.

specific release.
Is the migration action required? Yes, if you made any user modifications.
requirements:
Restrictions: None.
check:

Steps to take: Use the z/OS SMP/E Planning and Migration Assistant to help
determine which user modifications need to be reworked and which just have to
be reinstalled. The Top or New Intermediate Product Migration Changes Report
uses data found on your system, combined with IBM-supplied information from
the Software Information Base, to show you the current levels of products available
as well as product migration and functional changes using a comparison of FMIDs.
You can use this report to determine the product migration impacts by reviewing
the “changed” FMIDs. This can help you assess how many user modifications have


to be reworked if you issued the LIST SYSMOD USERMOD FORFMID (listing the
“changed” FMIDs) command. All other user modifications can be reinstalled
without having to be reworked.

Note: IBM recommends using exit routines for any user modifications where
possible, and installing the exit routines with SMP/E. By using SMP/E, it is
easier to bring forward modifications to the z/OS release you are installing.

v For information about SDSF customization, see z/OS SDSF Operation and
Customization.
v For information about XL C/C++ customization, see z/OS XL C/C++ User's
Guide.
v For information about DFSORT customization, see z/OS DFSORT Installation and
Customization.
v For information about HLASM customization, see HLASM Installation and
Customization Guide.
v For information about ISPF customization, see z/OS ISPF Planning and
Customizing.
v For information about Language Environment customization, see z/OS Language
Environment Customization.

Reconnect non-IBM products
Description: If you use any independent software vendor (ISV) products, you need
to make them usable with the new system.

specific release.
Is the migration action required? Yes, if you use any ISV products and need to
reconnect them after performing a ServerPac
or SystemPac installation.
requirements:
Restrictions: None.
check:

Steps to take: Check with your ISVs to make sure the product levels you are using
support the new z/OS release, and then reconnect your ISV products to the new
release of z/OS following the instructions provided by the ISVs. If any ISV
products do not need to be installed in the same libraries and zones as z/OS, place
them in their own sets of libraries and SMP/E zones. This means that, unless you


have to change ISV product code, such as installing PTFs, or obtain a new level of
the product, you will not need to reinstall it after you install a new ServerPac or
SystemPac.

v For a list of independent software vendors (ISVs) that support z/OS, as well as
announcements, testimonials, and other information, see http://www.ibm.com/
systems/z/solutions/isv/.
v For a directory of ISV products that support z/OS, see the Global Solutions
Directory at http://www.ibm.com/software/solutions/isv.

Reconnect subsystems
Description: If you use subsystems, you need to make them usable with the new
system.

specific release.
Is the migration action required? Yes, if you will use CICS, DB2®, IMS, or NCP
on your new system.
requirements:
Restrictions: None.
check:

Steps to take: Ensure that any required coexistence PTFs are installed before using
the subsystem with the new z/OS system, as well as any required SVCs, system
modifications, parmlib setup, and proclib setup. Follow the instructions for the
subsystem that you need to reconnect.

Reference information: Subsystem program directories.

Update operational and other procedures
Description: Depending on which method you used to install (ServerPac, CBPDO,
or other deliverable), and which functions you plan to exploit, you might need to
update the operation, automation, administration, security, backup, and recovery
procedures for your site.

specific release.


requirements:
Restrictions: None.
check:

Steps to take: Review your operation, automation, administration, security,
backup, and recovery procedures, and make any necessary changes depending on
how you installed and which functions you plan to exploit. Some possible changes
are:
v Allowing applicable users access to new high-level qualifiers. The default new
high-level qualifiers are shown in “Add references to new data sets and paths”
on page 35.
v Updating and testing your backup and recovery procedures to accommodate the
new target system.
v Updating and testing any disaster recovery procedures.
v Updating and testing any automation procedures to take advantage of new
functions.
v Updating security system definitions, such as defining new users and resources,
permitting users to use new resources, and defining new profiles in the RACF
FACILITY class.

Reference information: For the RACF FACILITY class profiles that were added for
z/OS UNIX, see z/OS UNIX System Services Planning.

Verify that virtual storage limits are set properly
Description: Virtual storage requirements usually grow from release to release. You
should review the virtual storage limits you want to set. Generally, there are two
areas of concern: common areas (above and below the 16 MB line) and individual
address spaces. An increase in virtual storage for common areas reduces the virtual
storage size of all address spaces. An increase in virtual storage for individual
address spaces impacts only the individual address spaces.

specific release.
requirements:
Restrictions: None.


Related IBM Health Checker for z/OS Use IBM Health Checker for z/OS to help
check: determine whether your virtual storage limits
are set properly. The check RSM_MEMLIMIT
checks the current setting for the MEMLIMIT
parameter in SMFPRMxx, which affects the
amount of virtual storage above the 2 GB bar
that is available to jobs. This check verifies
that a nonzero MEMLIMIT value is in use.

Steps to take: Determine how much virtual storage use to allow above the 2 GB
bar. While there is no practical limit to the number of virtual addresses an address
space can request above the bar, the system can limit the amount of virtual storage
above the bar that an address space is allowed to use. The amount of virtual
storage above the bar is determined as follows. The MEMLIMIT parameter in
parmlib member SMFPRMxx sets the default system-wide limit, which defaults to
2 GB as of z/OS V1R10 (and zero prior to z/OS V1R10). However, the
system-wide default MEMLIMIT can be overridden by specifying REGION=0M or
MEMLIMIT on JOB or EXEC statements in JCL. To set a limit on the use of virtual
storage above the bar, use the SMF exit IEFUSI. For more information, see Limiting
the use of memory objects in z/OS MVS Programming: Extended Addressability Guide.

If you want to control the use of virtual storage above the 2 GB bar, do one or
more of the following:
v The MEMLIMIT default is 2 GB. If this 2 GB default value is acceptable to you,
no change to SMFPRMxx is necessary. (Prior to z/OS V1R10, the default
MEMLIMIT was zero, and you had to specify a nonzero MEMLIMIT in an active
SMFPRMxx member of parmlib to establish a system default other than zero for
available virtual storage above 2 GB.)
v You can specify MEMLIMIT explicitly in JCL to override the system default that
was set (or allowed to default) in SMFPRMxx.
v You can specify REGION=0M on the job statement in JCL to implicitly set
MEMLIMIT to NOLIMIT, which also overrides the system default (from
SMFPRMxx).
v You can use IEFUSI both to establish a system default MEMLIMIT for different
classes of work (for example, job, TSO, STC) and limit the amount of virtual
storage that can be used above the bar, provided that an explicit or implicit
nonzero MEMLIMIT is in effect from JCL or SMFPRMxx. As of z/OS V1R10,
keyword HONORIEFUSIREGION | NOHONORIEFUSIREGION is available in
SCHEDxx to identify if the region and MEMLIMIT settings specified through or
otherwise affected by the IEFUSI exit are to take effect for a program.

v Information about how to evaluate the real storage configuration can be found
in the Washington Systems Center white paper z/OS Performance: Managing
Processor Storage in a 64-bit Environment - V1 at http://www.ibm.com/support/
techdocs. (Search for “WP100269”.)
v For more information about controlling region size and region limits using the
IEFUSI exit, see z/OS MVS Initialization and Tuning Guide.
v For more information about the HONORIEFUSIREGION keyword, see z/OS
MVS Initialization and Tuning Reference.


Back virtual storage with sufficient real and auxiliary storage
Description: As you exploit additional virtual storage by defining additional
address spaces or by exploiting memory objects, ensure that you have defined
sufficient real and auxiliary storage.

specific release.
requirements:
Restrictions: None.
check:

Steps to take: Using an RMF™ report, determine whether additional real or
auxiliary storage is needed by checking the following real storage concentration
indicators:
v UIC and average available frames
v Demand page rates
v Percentage of auxiliary slots in use

Reference information: For more information about memory objects, see z/OS
MVS Programming: Extended Addressability Guide and Washington Systems Center
flash 10165 at http://www.ibm.com/support/techdocs. (Search for “flash10165”.)

Update your check customization for modified IBM Health
Checker for z/OS checks
Description: Changes that IBM makes to the checks provided by IBM Health
Checker for z/OS can affect any updates you might have made.

The checks that were changed by IBM in z/OS V1R13 are:
| v SUP_HiperDispatch
| v USS_PARMLIB
| v XCF_SFM_CFSTRHANGTIME

| The checks that were deleted by IBM in z/OS V1R13 are:
| v CSVTAM_VIT_DSPSIZE
| v CSVTAM_VIT_SIZE

The checks that were changed by IBM in z/OS V1R12 are:
v USS_PARMLIB


| v ZOSMIGREC_ROOT_FS_SIZE (introduced by APAR OA28684 for z/OS V1R9,
| V1R10 and V1R11)

specific release.
Is the migration action required? No, but recommended to ensure that your
checks continue to work as you intend them
to work.
requirements:
Restrictions: None.
Related IBM Health Checker for z/OS See Steps to take: below.
check:

Steps to take:
1. Look at the updated checks in IBM Health Checker for z/OS: User's Guide.
2. Review changes you made for those checks, in HZSPRMxx parmlib members,
for example.
3. Make any further updates for the checks to ensure that they continue to work
as intended.

Reference information: For complete information about updating checks, see
“Customizing and managing checks” in IBM Health Checker for z/OS: User's Guide.

Remove deleted data sets, paths, and references
Description: Data sets and paths are routinely removed from z/OS for reasons
such as consolidation of data sets and removal of elements and features. You must
determine whether these changes affect your environment.

specific release.
requirements:
Restrictions: None.


check:

Steps to take: Using Table 3 as a guide, remove data sets and paths that do not
exist in the current release. Also, remove references to them. You might find
references in the following places:
v Parmlib
v Proclib
v Logon procedures
v Catalogs
v Security definitions, including program control definitions
v DFSMS ACS routines
v /etc/profile
v SMP/E DDDEF entry
v Backup and recovery procedures, as well as any references to them

In the table, the data sets are identified as distribution library (DLIB) data sets or
target library data sets.
Notes:
1. Ensure that references to the DCE target library EUV.SEUVLINK and DFS
target library IOE.SIOELMOD have been removed from your LNKLST
concatenation. Ensure that any reference to DCE target library EUV.SEUVLPA
has been removed from the LPALST concatenation.
2. Do not remove any data sets, paths, or references that are needed by
earlier-level systems until those systems no longer need them.
Table 3. Data sets and paths deleted from z/OS V1R13 and z/OS V1R12 (in alphabetic order by DDDEF name)
Data set name or path
(high-level qualifiers DLIB or From element or When
DDDEF are defaults) target feature deleted Why deleted
ACIMHFS CIM.ACIMHFS DLIB msys for Setup z/OS V1R12 msys for Setup
removed from z/OS
ACIMMOD1 CIM.ACIMMOD1 DLIB msys for Setup z/OS V1R12 msys for Setup
removed from z/OS
ACIMPLUG CIM.ACIMPLUG DLIB msys for Setup z/OS V1R12 msys for Setup
removed from z/OS
| ABPAHFS BPA.ABPAHFS DLIB z/OS UNIX System z/OS V1R13 z/OS UNIX System
| Services Services Connection
| Manager removed
| from z/OS
| ACMXDBRM CMX.ACMXDBRM DLIB z/OS UNIX System z/OS V1R13 z/OS UNIX System
| Manager removed
| from z/OS
| ACMXHFS CMX.ACMXHFS DLIB z/OS UNIX System z/OS V1R13 z/OS UNIX System
| Manager removed
| from z/OS
ACUNIMG SYS1.ACUNIMG DLIB BCP z/OS V1R12 Unicode Services will
no longer ship the
pre-built image
SYS1.ACUNIMG


Table 3. Data sets and paths deleted from z/OS V1R13 and z/OS V1R12 (in alphabetic order by DDDEF
name) (continued)
| AEUVACF EUV.AEUVACF DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVDBRM EUV.AEUVDBRM DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVEXEC EUV.AEUVEXEC DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVEXP EUV.AEUVEXP DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVHDR EUV.AEUVHDR DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVHDRK EUV.AEUVHDRK DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVHDCP EUV.AEUVHDCP DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVHETC EUV.AEUVHETC DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVHINC EUV.AEUVHINC DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVHJPN EUV.AEUVHJPN DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVHLBR EUV.AEUVHLBR DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVHTCL EUV.AEUVHTCL DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVHXMP EUV.AEUVHXMP DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVIDL EUV.AEUVIDL DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVLIB EUV.AEUVLIB DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVLIBK EUV.AEUVLIBK DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVLIBS EUV.AEUVLIBS DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVLINK EUV.AEUVLINK DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVMSG EUV.AEUVMSG DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVMSGJ EUV.AEUVMSGJ DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVPNL EUV.AEUVPNL DLIB DCE z/OS V1R13 DCE removed from
| z/OS.
| AEUVPNLJ EUV.AEUVPNLJ DLIB DCE z/OS V1R13 DCE removed from
| z/OS.


name) (continued)
SCIMBIN /usr/lpp/cim/bin/ Target msys for Setup z/OS V1R12 msys for Setup
IBM removed from z/OS
SCIMPWS /usr/lpp/cim/IBM Target msys for Setup z/OS V1R12 msys for Setup
removed from z/OS
SCIMPLUG /usr/lpp/cim/plugin/ Target msys for Setup z/OS V1R12 msys for Setup
IBM/ removed from z/OS
SCIMXML CIM.SCIMXML Target msys for Setup z/OS V1R12 msys for Setup
removed from z/OS
| SCMXBIN /usr/lpp/cmx/bin/ Target z/OS UNIX System z/OS V1R13 z/OS UNIX System
| Manager removed
| from z/OS.
| SCMXDBRM CMX.SCMXDBRM Target z/OS UNIX System z/OS V1R13 z/OS UNIX System
| Manager removed
| from z/OS.
| SCMXINC /usr/lpp/cmx/ Target z/OS UNIX System z/OS V1R13 z/OS UNIX System
| include/IBM/ Services Services Connection
| Manager removed
| from z/OS.
| SCMXLIB /usr/lpp/cmx/lib/ Target z/OS UNIX System z/OS V1R13 z/OS UNIX System
| Manager removed
| from z/OS.
| SCMXMJPN /usr/lpp/cmx/nls/ Target z/OS UNIX System z/OS V1R13 z/OS UNIX System
| msg/Ja_JP/IBM/ Services Services Connection
| Manager removed
| from z/OS.
| SCMXMSC /usr/lpp/cmx/nls/ Target z/OS UNIX System z/OS V1R13 z/OS UNIX System
| msg/C/IBM/ Services Services Connection
| Manager removed
| from z/OS.
| SCMXSAMP /usr/lpp/cmx/ Target z/OS UNIX System z/OS V1R13 z/OS UNIX System
| samples/IBM/ Services Services Connection
| Manager removed
| from z/OS.
SCUNIMG SYS1.SCUNIMG Target BCP z/OS V1R12 Unicode Services will
no longer ship the
pre-built image
SYS1.SCUNIMG. See
“Remove reference to
Unicode Services
pre-built image
CUNIDHC2” on page
118 for more
information.
| SEUVACF EUV.SEUVACF Target DCE z/OS V1R13 DCE removed from
| z/OS.


name) (continued)
| SEUVPNLJ EUV.SEUVPNLJ Target DCE z/OS V1R13 DCE removed from
| z/OS.
| SEUVPRC EUV.SEUVPRC Target DCE z/OS V1R13 DCE removed from
| z/OS.
SFOMUCMP /usr/lib/nls/locale/ Target Language Environment z/OS V1R12 HFS directory will no
ucmap/IBM/ longer be shipped.
SFOMUCNV /usr/lib/nls/locale/ Target Language Environment z/OS V1R12 HFS directory will no
uconvtable/IBM/ longer be shipped.
| SIOELMOD IOE.SIOELMOD Target DFS z/OS V1R13 No load modules are
| installed in these
| libraries as of z/OS
| V1R13.
| SIOEMSGE IOE.SIOEMSGE Target DFS z/OS V1R13 English message
| provided as of z/OS
| V1R13.
| SIOEMSGJ IOE.SIOEMSGJ Target DFS z/OS V1R13 Japanese message
| provided in z/OS
| V1R13.
| SIOEPNLE IOE.SIOEPNLE Target DFS z/OS V1R13 English panel library is
| no longer provided in
| z/OS V1R13.
| SIOEPNLJ IOE.SIOEPNLJ Target DFS z/OS V1R13 Japanese panel library
| is not provided in
| z/OS V1R13.


Add references to new data sets and paths
Description: New data sets and paths are routinely added to z/OS for reasons
such as consolidation of data sets and addition of new elements and features. You
must determine whether these additions affect your environment.

specific release.
requirements:
Restrictions: None.


check:

Steps to take: Using Table 4 as a guide, add references in the following places for
data sets and paths that have been added to z/OS:
v Parmlib
v Proclib
v Logon procedures
v Catalogs
v Security definitions, including program control definitions
v DFSMS ACS routines
v Any backup and recovery procedures.

Rules: Some of the data sets shipped with z/OS are PDSEs and are most likely in
your link list. If one or more are in your link list and on your system residence
volume, adhere to the following PDSE sharing rules to avoid data set corruption:
v If you specified PDSESHARING(NORMAL), do not share PDSE data sets
beyond the scope of the global resource serialization complex.
v If you specified PDSESHARING(EXTENDED), do not share PDSE data sets
beyond the scope of the sysplex.
Table 4. Data sets added to z/OS V1R13 and z/OS V1R12 (in alphabetic order by DDDEF name)
Data set name
(high-level qualifiers DLIB or
DDDEF are defaults) or path target To element or feature When added Why added
| SERBHFS /usr/lpp/gpm/IBM Target RMF z/OS V1R13. New RMF file system
| path for RMF XP.


Accommodate new address spaces
Description: The MAXUSER value in parmlib member IEASYSxx specifies a value
that the system uses to limit the number of jobs and started tasks that can run
concurrently during a given IPL. You might want to increase your MAXUSER
value to take new address spaces into account.

There are two new address spaces in z/OS V1R13.
| v GPM4CIM is an address space to be used for cross-platform performance
| management with RMF XP. You can start it by using procedure
| SYS1.PROCLIB(GPM4CIM) from the console, as started task, with the following
| command:
| s gpm4cim[.identifier],os=A|X|Z

| Since you can run multiple GPM4CIM instances simultaneously, it is
| recommended to assign an identifier that you can use for subsequent STOP or
| MODIFY commands. You may already have created the userID GPMSERVE as
| owner of the GPMSERVE procedure. The GPM4CIM started task can be assigned
| to the same userID with the following command:
| RDEFINE STARTED GPM4CIM.* STDATA(USER(GPMSERVE) TRUSTED(YES))

| For more information, refer to z/OS RMF User's Guide.


v The Runtime Diagnostics address space HZR will be a persistent address space.
When the HZR address space is started with the START command S
HZR,SUB=MSTR, it will remain active until stopped with the STOP command
P HZR. To analyze a system, enter the MODIFY HZR,ANALYZE command. See
“Start Runtime Diagnostics at system initialization” on page 109 for more
information.

There was one new address space in z/OS V1R12. ARCnRSTy is the address space
identifier for full-volume recovery from dump, where n is the DFSMShsm host ID
and y is the instance of the DFSMSdss started task (a number from 1 to 4). Data set
recovery from dump will still use ARCnREST. See “DFSMShsm: Configure your
security system to permit started procedures using new address space identifier”
on page 200 for more information.

| Element or feature: v BCP for HZR.
v DFSMShsm for ARCnRSTy.
| v RMF for GPM4CIM.

| When change was introduced: v z/OS V1R13 for GPM4CIM and HZR.
v z/OS V1R12 for ARCnRSTy.

| Applies to migration from: v z/OS V1R12 and z/OS V1R11 for
| GPM4CIM and HZR.
v z/OS V1R12 for ARCnRSTy.
Is the migration action required? No, but recommended to ensure that your
MAXUSER value in parmlib member
IEASYSxx is adequate.
requirements:
Restrictions: None.
check:

Steps to take: If necessary, increase your MAXUSER value in parmlib member
IEASYSxx to take the new address spaces into account. One way to find out how
many address spaces you use is to issue the DISPLAY A,L command and total the
address spaces in the IEE114I and IEE115I messages on the old and new systems.
Notes:
1. A modest overspecification of MAXUSER should not hurt system performance.
2. The number of total address spaces is the sum of M/S, TS USERS, SYSAS, and
INITS.
3. If you change your MAXUSER value, you must re-IPL to make the change
effective.

Reference information: For more information about the MAXUSER parameter,
including its interaction with the RSVSTRT and RSVNONR parameters and factors
that contribute to the number of active address spaces, see “statements and
parameters for IEASYSxx” in z/OS MVS Initialization and Tuning Reference.


Migration actions for everyone after the first IPL of z/OS V1R13
None.


Chapter 3. Hardware migration actions
Replace unsupported devices . . . . . . . . 39 Restrictions . . . . . . . . . . . . . 65
Provide for new device installations . . . . . . 40 Actions you can take before you order a System
Update your CFRM policy with coupling facility z10 server . . . . . . . . . . . . . . 66
structure size changes . . . . . . . . . . . 41 Actions you can take after you order a System
Accommodate ISC-3, PSC, ESCON, FICON, z10 server . . . . . . . . . . . . . . 69
OSA-Express2, and dial-up modem changes Recommended migration steps . . . . . . . 69
introduced with the IBM zEnterprise 196 (z196) Migration and exploitation considerations for
server and the IBM zEnterprise 114 (z114) server . . 42 System z10 functions . . . . . . . . . . 70
Accommodate token ring, HMC, and ISC-3 changes Migrate to a System z9 server . . . . . . . . 73
introduced with the System z9 platform . . . . . 44 General recommendations and considerations . . 75
Migrate from a Sysplex Timer to STP . . . . . . 45 Restrictions . . . . . . . . . . . . . 75
Migrate from ICB-4 to Infiniband coupling links . . 46 Actions you can take before you order a System
| Migrate to an IBM zEnterprise server. . . . . . 47 z9 server . . . . . . . . . . . . . . 76
General recommendations and considerations . . 51 Actions you can take after you order a System z9
Restrictions . . . . . . . . . . . . . 52 server . . . . . . . . . . . . . . . 78
Actions you can take before you order a Recommended migration steps . . . . . . . 78
zEnterprise server . . . . . . . . . . . 53 Migrate to a z990 or z890 server . . . . . . . 79
Actions you can take after you order a Actions you can take before you install a z990 or
zEnterprise server . . . . . . . . . . . 57 z890 server . . . . . . . . . . . . . 80
Recommended migration steps . . . . . . . 57 Actions you can take when you order a z990 or
Migration and exploitation considerations for z890 server . . . . . . . . . . . . . 85
zEnterprise functions . . . . . . . . . . 57 Actions you can take after you install z/OS . . 85
Migrate to a System z10 server . . . . . . . . 62 Actions you might need to take once you are
General recommendations and considerations . . 64 using a z990 or z890 server . . . . . . . . 87

This topic describes hardware migration actions. The information in this topic is
not specifically related to migrating to z/OS V1R13; it only applies if you are
changing hardware. Therefore, this topic does not categorize the actions in terms of
when they should be performed (before installing, before the first IPL, or after the
first IPL).

Replace unsupported devices
Description: You should remove and replace devices that were supported by
earlier releases but cannot be used with the current release of z/OS because they
are no longer supported.

specific release.
Timing: Anytime.
Is the migration action required? Yes, if you use any of the devices that are no
longer supported.
Target system hardware requirements: Replacement devices as necessary.
requirements:
Restrictions: None.


check:

Steps to take:
1. Determine whether the devices you use are supported. A list of supported I/O
devices is in the topic about identifying I/O device requirements in z/OS
Planning for Installation. If you have a question about support for any devices
not listed, contact your IBM representative.
2. Install replacement devices. Move data that is stored on unsupported devices to
the supported devices. Detach unsupported devices from the system and delete
their corresponding device definitions from the input/output definition file
(IODF).

v For a list of I/O devices that are supported, see the topic about identifying I/O
device requirements in z/OS Planning for Installation.
| v For information about deleting device definitions from the IODF, see z/OS HCD
| User's Guide.

Provide for new device installations
Description: The hardware configuration of your processors and I/O devices
determines how many devices you can attach to your system. z/OS supports
attachment of up to 65,280 devices, each with up to eight access paths.

specific release.
Timing: Anytime.
Is the migration action required? Yes, if you are going to use new devices with
z/OS V1R11 and later.
Target system hardware requirements: Dependent upon the new devices used.
requirements:
Restrictions: None.
check:

Steps to take: The following are general considerations related to I/O device
support.
v Attaching devices through HCD. You can define, or attach, new devices to your
system through the interactive panels of the Hardware Configuration Definition
(HCD) base element. HCD has dynamic I/O capabilities, changing hardware
definitions without the need for an IPL or hard power-on reset.
Any time you make changes to your I/O configuration, you need to use HCD to
modify your system's I/O definition file (IODF). You should also update the


input/output configuration data set (IOCDS) when you run HCD to ensure that
the configuration information is consistent across the software and microcode.
v Operating modes. Most devices attached to z/OS operate in full function mode,
that is, all features on the device are compatible with, and usable on, the
operating system. Some of these features include:
– For DASD devices: dynamic path reconnection, extended count-key-data
operation, and caching and cache-related facilities
– For tape devices: cartridge stack loading and data compaction
Some devices also operate in compatibility mode, which allows you to simulate
the function of another device or model. Compatibility mode causes the device
to function like a different device of the same type, ignoring some or all of the
additional features the device might have. This allows you to migrate between
devices with minimal impact on programs that have device dependencies.
v UCB virtual storage constraint relief. Each device attached to the system has one or
more UCBs associated with it. You have the option to define UCBs either above
or below the 16 MB line by specifying the LOCANY parameter on the Hardware
Configuration Definition (HCD) panel. The system programmer should review
the contents of the link pack area (LPA) list to determine whether to remove or
move libraries to gain virtual storage constraint relief.
v Hardware maintenance. Some devices require a specific level of hardware
maintenance to operate properly on a z/OS system. DFSMS software support for
new hardware devices might also require the installation of PTFs.

v For a summary of the most commonly-used I/O devices supported by z/OS
that are also directly supported by DFSMS functions, see the topic about
identifying I/O device requirements in z/OS Planning for Installation. If you have
a question about support for a device that is not listed, contact your IBM
representative.
v For more information about HCD, see z/OS HCD Planning.
v For information about working with IODFs, see z/OS HCD User's Guide.

Update your CFRM policy with coupling facility structure size changes
Description: If you are migrating to a new level of coupling facility control code
(CFCC), you have to make appropriate coupling facility structure size updates in
the z/OS coupling facility resource management (CFRM) policy.

specific release.
Timing: Anytime.
Is the migration action required? Yes, if you are migrating to a new CFCC
level.
Target system hardware requirements: See http://www.ibm.com/systems/z/
advantages/pso/cftable.html .
requirements:
Restrictions: None.


check:

Steps to take: If you are migrating to a new CFCC level, do the following:
1. Run the Coupling Facility Structure Sizer (CFSizer) tool. This tool sizes
structures, taking into account the amount of space needed for the current
CFCC levels. The tool sizes for the most currently available level; you might
find that the results are oversized if you use an earlier CFCC level. You can
find the tool at http://www.ibm.com/systems/support/z/cfsizer/.
Alternatively, you can run an as-is batch utility program called SIZER after you
have brought a new CFLEVEL coupling facility into use in your configuration.
SIZER examines your currently allocated coupling facility structures and
recalculates the size that should be used for them with the new later-CFLEVEL
coupling facility. The as-is SIZER utility is available as a zipped package that
you can download from http://www.ibm.com/systems/support/z/cfsizer/
altsize.html .
2. Update the CFRM policy with the size modifications that are needed.
3. Activate the updated CFRM policy so that it becomes the active policy
governing structure allocation in the sysplex.

Reference information: For a detailed description of coupling facility code levels
and the processors that support those levels, see http://www.ibm.com/systems/z/
advantages/pso/cftable.html .

Accommodate ISC-3, PSC, ESCON, FICON, OSA-Express2, and dial-up
modem changes introduced with the IBM zEnterprise 196 (z196) server
and the IBM zEnterprise 114 (z114) server
Description: The following changes in hardware support could affect your
environment. Make appropriate changes as needed.
| v ISC-3 features (#0217, #0218, #0219). The z196 is the last high-end server, and
| the z114 is the last mid-range server, to offer ordering of ISC-3. You should begin
| migrating from ISC-3 features (#0217, #0218, #0219) to 12x InfiniBand (#0163 -
| HCA2-O or #0171 - HCA3-O fanout) or 1x InfiniBand (#0168 - HCA2-O LR or
| #0170 - HCA3-O LR fanout) coupling links.
| v Power Sequence Controller (PSC feature #6501). IBM intends not to offer
| support for the PSC (feature #6501) on future System z servers after the z196
| (machine type 2817) and z114 (machine type 2818). PSC features cannot be
| ordered and cannot be carried forward on an upgrade to such a follow-on
| server. The optional PSC feature is used to turn on or off specific control units
from the central processor complex (CPC).
| v ESCON channels. IBM plans not to offer ESCON channels as an orderable
| feature on System z servers that follow the z196 (machine type 2817) and z114
| (machine type 2818). In addition, ESCON channels cannot be carried forward on
| an upgrade to such follow-on servers. This plan applies to channel path
| identifier (CHPID) types CNC, CTC, CVC, and CBY and to feature numbers
| 2323 and 2324. You should be migrating from ESCON to FICON and eliminating
| ESCON channels from the mainframe wherever possible. Alternate solutions are
| available for connectivity to ESCON devices. IBM Global Technology Services
| offers an ESCON to FICON migration solution, Offering ID #6948-97D, to help


| facilitate migration from ESCON to FICON. This offering can help you to
| simplify and manage a single physical and operational environment.
| v FICON® Express4 channels. The z196 is the last high-end server, and the z114 is
| the last mid-range server, to support FICON Express4 channels. You should
| begin migrating from FICON Express4 channel features (#3321, #3322, #3324) to
| FICON Express8S channels.
| v OSA-Express2 features. The z196 is the last high-end server, and the z114 is the
| last mid-range server, to support OSA-Express2 features. You should begin
| migrating from OSA-Express2 features (#3364, #3365, #3366) to OSA-Express3
| 1000BaseT and OSA-Express4S features.
| v Dial-up modems. The z196 is planned to be the last high-end server, and the
| z114 is planned to be the last mid-range server, to support dial-up modems for
| use with the Remote Support Facility (RSF), and the External Time Source (ETS)
| option of Server Time Protocol (STP). The currently available Network Time
| Protocol (NTP) server option for ETS, as well as Internet time services available
| using broadband connections, can be used to provide the same degree of
| accuracy as dial-up time services. You should begin migrating from dial-up
| modems to broadband for RSF connections.


| When change was introduced: v 12 July 2011 in U.S. Announcement Letter
| 211-252.
v 15 February 2011 in U.S. Announcement
Letter 111-012.
v 22 July 2010 in U.S. Announcement letter
110-170.
| Timing: Before migrating to a zEnterprise server.
| Is the migration action required? No, but recommended if you are using a
| z196 (or earlier) server or a z114 server
| because these are the last servers that will
| support the changes mentioned in
| "Description" above.
Target system hardware requirements: See "Description" above.
requirements:
Restrictions: None.
check:

Steps to take: Take into account the statements in “Description” above as you
make your plans for the future.



Accommodate token ring, HMC, and ISC-3 changes introduced with
the System z9 platform
Description: The following changes in hardware support could affect your
environment:
v Token ring: The z990 and z890 are the last servers to offer token ring adapter
features on the hardware management consoles (HMCs), Support Elements
(SEs), and Trusted Key Entry (TKE) workstations. Thus:
– Token ring is not available as a feature on the System z10 or System z9 HMC.
Current® HMCs with token ring may be carried forward to a System z10 or
System z9 server during an upgrade from a z990 or z900.
– Token ring is not available as a feature on the System z10 or System z9 SE or
TKE workstation. Token ring is not offered as a feature on System z10 and
System z9 servers and cannot be carried forward to a System z10 or System
z9 server during an upgrade from a z990 or z900.
– The OSA-Express Token Ring feature is not supported on System z10 and
System z9 servers. Token ring is not offered as a feature on System z10 and
System z9 servers and cannot be carried forward to a System z10 or System
z9 server during an upgrade from a z990 or z900.
v HMC: The z990 and z890 are the last servers on which the HMC is open.
Starting with System z9 servers, the HMC is for the exclusive use of the HMC
application. Customer applications cannot reside on the HMC. The ESCON
Directory and Sysplex Timer® applications cannot reside on the HMC. TCP/IP is
the only supported communication protocol. The HMC supports System z10 and
System z9 servers. It can also be used to support z990, z890, z900, z800, G5, G6,
and Multiprise 3000 servers. They must be upgraded to a new AROM level.
v ICB-2s and ISC-3s in compatibility mode: The z990 and z890 are the last
servers to support Integrated Cluster Bus-2 (ICB-2) and InterSystem Channel-3
(ISC-3) compatibility mode links. System z10 and System z9 servers do not
support them. If you have ICB-2 or ISC-3 compatibility mode links defined,
convert them to a supported link technology.

When change was introduced: 27 July 2005 in the z9 EC (formerly z9-109)
announcement.
Applies to migration from: z/OS V1R12 and z/OS V1R11
Timing: Before migrating to a System z10 or System
z9 server.
Is the migration action required? Yes, if you plan to install a System z10 or
System z9 server and are affected by any
support changes mentioned in “Description”
above.
Target system hardware requirements: See “Description” above.
requirements:
Restrictions: None.
check:


Steps to take: Take into account the statements in “Description” above as you
make your plans for the future.


Migrate from a Sysplex Timer to STP
Description: The Server Time Protocol (STP) feature is the follow-on to the Sysplex
Timer (9037-002). STP is designed to allow multiple servers and coupling facilities
to maintain time synchronization with each other, without requiring a Sysplex
| Timer. STP is a hardware feature of the z196, z114, z10 EC, z10 BC, z9 EC, z9 BC,
z990, and z890.

When change was introduced: STP was announced on 27 July 2005 in the z9
EC announcement (US letter 105-241) and on
10 October 2006 in the STP announcement
(US letter 106-715). STP became generally
available in January 2007.
Timing: Anytime.

| Is the migration action required? v Yes, if you are planning to use a z196 or
| z114 server because the Sysplex Timer
| (9037-002) is not supported with these
| servers.
| Note: You do not need an STP-only
| configuration with a z196 or z114 server.
| The z196 and z114 servers can participate
| in a Mixed-CTN configuration if the other
| servers connect to an ETR and are STP
| enabled. The other server becomes the
| stratum 1 server for the Mixed-CTN and
| the z196 and z114 servers connect to the
| stratum 1 server using coupling link
| technology.
v No, but recommended if you are using a
System z10 or earlier server because these
are the last servers that will support the
Sysplex Timer (9037-002).


Target system hardware requirements: The servers and coupling facilities that are
| capable of supporting STP are the z196, z114,
Systems z10 EC, z10 BC, z9 EC, z9 BC, z990,
and z890. The STP feature number is 1021.

STP is a server-wide facility that is
implemented in the Licensed Internal Code
| (LIC) of the z196, z114, Systems z10 ECs, z10
BCs, z9 ECs, z9 BCs, z990s, z890s, and
coupling facilities, and presents a single view
of time to PR/SM™.

The Sysplex Timer's LIC has been upgraded
to support using STP in a Mixed Coordinated
Timing Network (CTN). The required
Sysplex Timer LIC is shipped along with the
STP feature and must be installed by the IBM
Service Support Representative prior to
migrating from a Sysplex Timer based
External Time Reference (ETR) network to
any STP Coordinated Timing Network
(CTN).
Target system software requirements: Even though z/OS has function to support
STP, additional PTFs are required. Consult
the PSP buckets for STP-related maintenance.
Use FIXCAT IBM.Device.Server.device-
type.ServerTimeProtocol to get this
information.
requirements:
Restrictions: None.
Related IBM Health Checker for z/OS Use ZOSMIGREC_SUP_TIMER_INUSE on
check: z/OS V1R11 or later to determine whether
the timing mode on the current system is
ETR.

Steps to take: To implement STP, see the STP web site and the publications and
other resources that are listed there. The STP web site is at http://www.ibm.com/
systems/z/advantages/pso/stp.html .

Reference information: See “Steps to take” above.

Migrate from ICB-4 to Infiniband coupling links
Description: System z10 is the last server to support Integrated Cluster Bus-4
(ICB-4) links. IBM does not intend to offer ICB-4 links on future servers.

When change was introduced: The intention to not offer ICB-4 links on
future servers was originally stated in the
IBM System z10 EC announcement on 26
February 2008.
Timing: Anytime.


| Is the migration action required? v Yes, if you are planning to use a z196 or
| z114 server because ICB-4 links are not
| offered with these servers.
v No, but recommended if you are using a
System z10 or earlier server because these
are the last servers to offer ICB-4 links.
requirements:
Restrictions: None.
check:

Steps to take: Use InfiniBand coupling links instead of ICB-4 links. Updates to
zEnterprise Parallel Sysplex coupling connectivity allow attachment between
zEnterprise and System z10 and System z9 general purpose servers (no longer just
standalone coupling facilities) using 12X InfiniBand attachment at 6 gigabytes per
| second (Gbps). If a z196, z114, z10 EC, or z10 BC server is attached to a z9 EC or
| z9 BC server, they operate at 3 gigabytes per second (Gbps) using 12X IFB.
InfiniBand coupling can provide significantly improved service times compared to
ISC-3s for distances up to 150 meters.

Reference information: You can read about InfiniBand coupling links in IBM
System z Connectivity Handbook, SG24-5444.

| Migrate to an IBM zEnterprise server
| Description: An IBM zEnterprise System includes a Central Processing Complex
| (CPC), either the IBM zEnterprise 196 (z196) server or the IBM zEnterprise 114
| (z114) server, or both, the zEnterprise BladeCenter Extension (zBX) with its
| integrated optimizers or select IBM blades, and the zEnterprise Unified Resource
| Manager (Unified Resource Manager).

The IBM zEnterprise 114 (z114) is the newest member of the zEnterprise family.
The z114 is an entry-level enterprise server with a smaller mainframe footprint
than the IBM zEnterprise 196 (z196).

The specific zEnterprise functions exploited by z/OS depend on the z/OS release.
See Table 5.
Table 5. zEnterprise functions supported by z/OS V1R11 and z/OS V1R12 and z/OS V1R13
zEnterprise function R11 R12 R13
Included in base z/OS support
| Base support Y Y Y
OSA-Express3 (GbE LX and SX, Y Y Y
1000BASE-T, 10 GbE LR and SR)
InfiniBand Coupling Links Y Y Y


Table 5. zEnterprise functions supported by z/OS V1R11 and z/OS V1R12 and z/OS V1R13 (continued)
®
New z/Architecture instructions Y Y Y

(Support differs by release. z/OS V1R12,
z/OS V1R13, and higher, include XL
C/C++ support for ARCH(9) and
TUNE(9) options.)
Up to 128 Coupling Links CHPIDs Y Y Y
FICON Express8 (CHPID FC) Y Y Y
IFAURP reporting Y Y Y
Greater than 64 CPs per server Y (z196 only) Y (z196 only) Y (z196 only)
Crypto toleration Y Y Y

(Support differs depending on level of
ICSF installed. PTF required.)
| OSA-Express3 (CHPID type OSD) with or Y Y Y
| without exploitation of two ports per
| CHPID
Up to 32 HiperSockets™ Y Y Y
RMF postprocessor crypto activity report - Y Y Y
4096 bit
CPU measurement facility (HIS) Y Y Y
Greater than 64 CPs per LPAR Y (z196 only) Y (z196 only) Y (z196 only)
HiperDispatch cache and affinity node Y Y Y
changes
HiperDispatch serviceability Y Y Y

(Support differs by release.)
LE high register resolution Y Y Y
Exploitation of z/OS support
| Power save mode Y (z196 only) Y (z196 only) Y (z196 only)
OSA-Express4S (GbE LX and SX, and 10 Y Y Y
GbE LR and SR)
OSA-Express4S improved port granularity Y Y Y
FICON Express8S support of zHPF single Y Y Y
track operations
FICON Express8S support of zHPF Y Y Y
multi-track operations
Coupling Facility Control Code (CFCC) Y Y Y
Level 17
Three subchannel sets Y Y Y
| IPL from alternate subchannel set Y Y Y
IBM zEnterprise Unified Resource Y Y Y
Manager


Legend:
Y = supported.
N = not supported
| Note: PTFs may be required. Refer to “Actions you can take before you order a zEnterprise
| server” on page 53 for information about finding the appropriate PTFs.

When change was v The IBM zEnterprise 114 (z114), which shipped in September
introduced: 2011.
v The IBM zEnterprise 196 (z196), which first shipped in September
2010.
v The IBM zEnterprise BladeCenter Extension (zBX), which shipped
November 2010.
Applies to migration z/OS V1R12 and z/OS V1R11.
from:
Timing: Anytime before you introduce a zEnterprise server into your
environment.
Is the migration Yes, if you want to run z/OS V1R13, V1R12 or V1R11 on a
action required? zEnterprise server, or if you want to run a Coupling Facility on a
zEnterprise server. If you will run only a Coupling Facility on a
zEnterprise system, then only the sysplex-related actions below are
relevant.
Target system v A z196 or a z114 server.
hardware
v Additional hardware required for specific functions.
requirements:
– zDAC requires:
- FICON channels attached to switches (either FICON
Express8 or FICON Express4 - [CHPID type: FC])
- Up-to-date controller microcode
- Up-to-date switch microcode
| – IBM zEnterprise Blade Center Extension (zBX) is required for
| the IBM Smart Analytics Optimizer for DB2 for z/OS V1.1, the
| IBM WebSphere DataPower Integration Appliance XI50 for
| zEnterprise (DataPower XI50z), and select POWER7 and IBM
| System x blades.
| – An IBM System Storage® DS5020 is required for IBM Smart
| Analytics Optimizer.
Target system 1. See the list of PTFs in the Software Service Level section of the
software PSP buckets.
requirements:
2. See Install the necessary z/OS service, as indicated in PSP
buckets described in “General recommendations and
considerations” on page 51.
Other system v It is recommended that you install and run the zEnterprise
(coexistence or required service on your existing server. This will enable you to
fallback) fall back from a hardware perspective, yet maintain your
requirements: software level.
v The PTFs to support CFCC Level 17 have coexistence (or sysplex
preconditioning) PTFs that are required to be installed throughout
your sysplex prior to implementing CFCC Level 17.


Restrictions: See “Restrictions” on page 52.
Related IBM Health IBM Health Checker for z/OS check,
Checker for z/OS SUP_HiperDispatchCPUConfig, is added to z/OS V1R12 and
check: available on z/OS V1R11 with APAR OA30476. This check will
verify that HiperDispatch is enabled on a zEnterprise system. (For
more information, see "HiperDispatch cache and affinity node
changes" in “Migration and exploitation considerations for
zEnterprise functions” on page 57).

Steps to take: Follow the “General recommendations and considerations,” adhere
to the “Restrictions” on page 52, and perform the tasks described in the various
topics below.

General recommendations and considerations
As you plan your migration to a zEnterprise server, consider the following:
1. Relatively few migration actions are new when coming from a z10 EC or a
z10 BC server. Migration to a zEnterprise server has, as its base, a migration to
the z10 EC or z10 BC servers. This means that if you are migrating to a
zEnterprise server from a z10 EC or z10 BC server, and have performed the
migration actions associated with the z10 EC or z10 BC, you have fewer
migration actions than if you were migrating from a server prior to the z10 EC
or z10 BC and have not yet performed the migration actions associated with
these servers. There are, in fact, very few new migration actions to perform on
z/OS for a zEnterprise server if you have already migrated to a z10 EC or z10
BC server. It is important to note that you can migrate directly to a zEnterprise
server without installing the intermediate (prior to z10 EC and z10 BC) servers,
but you still need to ensure that any migration considerations are satisfied for
the servers that you “skipped.” To read about z10 EC and z10 BC server
migration actions, see “Migrate to a System z10 server” on page 62.
2. Support is delivered by service (and FMID web deliverables for ICSF). The
delta (from a z10 EC or z10 BC) support for a zEnterprise server, excluding
cryptographic support, is delivered by service (PTFs). The cryptographic
support for the zEnterprise server continues to be FMIDs, many of which are
still available in web deliverables. Different ICSF web deliverables, providing
different levels of support, are available for different releases of z/OS. (See
“Decide on the steps you will take for your migration to a zEnterprise server”
in “Actions you can take before you order a zEnterprise server” on page 53 for
further information.)
3. Larger coupling facility structure sizes might be necessary. When you change
coupling facility control code (CFCC) levels, your coupling facility structure
sizes might change. zEnterprise servers initially ship with CFCC level 17. If, as
part of your migration to a zEnterprise server, you change CFCC levels (either
by placing a coupling facility on the zEnterprise server or by moving the
coupling facility to a z10 EC or z10 BC at a later CFCC level), you might have
larger structure sizes than you did previously. If your CFCC levels are identical,
structure sizes are not expected to change when you migrate from a previous
server to a newer generation server.
4. Use the same software level throughout a sysplex. Having members of a
sysplex at the same software level (other than during brief migration periods) is
good software management policy.


5. Migrate hardware and software at different times. To minimize the amount of
change (and therefore risk) that you experience at one time, do not migrate
your software release level at the same time that you migrate your hardware.
6. Update SCRT to latest version. If you use SCRT, make sure it is at the latest
level. This is a requirement for vWLC, as well as when you upgrade servers.
The latest level of SCRT can be downloaded from the SCRT web site at
http://www.ibm.com/eserver/zseries/swprice/scrt/.

Restrictions
Restrictions associated with zEnterprise servers are:
1. Functional limitations: Not all zEnterprise functions are available in every
z/OS release. See Table 5 on page 47 for a list of the zEnterprise functions
available in each z/OS release. Some functions have migration or exploitation
considerations (see “Migration and exploitation considerations for zEnterprise
functions” on page 57). Many functions are enabled or disabled, based on the
presence or absence of the required hardware and software. If you wish to
position yourself to exploit any new zEnterprise functions, the software and
hardware may be installed in either order. That is, there is no requirement to
install either software or hardware first to exploit a specific function. However,
due to outage windows and testing considerations, you might want to consider
installing all the required software first, then upgrading the hardware and,
finally, updating your customization to exploit the new functions.
2. zEnterprise servers in a sysplex:
v zEnterprise servers are only supported in a parallel sysplex with other
zEnterprise servers, z10 EC and z10 BC servers, and z9 EC and z9 BC
servers. If you are running z/OS on zSeries z900, z800, z990, or z890 servers,
then you cannot add a zEnterprise server to that sysplex. That is, you will
not be able to perform rolling IPLs to introduce a zEnterprise server if you
have any of the earlier (pre-System z) servers either as z/OS images or
coupling facility images in the sysplex. The earlier servers in the sysplex
must be upgraded to System z9 or later to have zEnterprise servers
supported in the sysplex. If you have any z/OS images or coupling facility
images on an earlier server, and you intend to introduce a zEnterprise server
into that sysplex, you must migrate those images to a System z9 (or later)
server prior to introducing the zEnterprise server.
v The Integrated Cluster Bus 4 (ICB-4) Coupling Links are not supported on a
zEnterprise CPC. Use 12x InfiniBand coupling links, which are designed to
replace Integrated Cluster Bus 4 (ICB-4), and to complement 1x InfiniBand
and ISC-3 on a zEnterprise server. InfiniBand coupling can provide
significantly improved service times compared to ISC-3s for distances up to
150 meters. You can read about InfiniBand coupling links in IBM System z
Connectivity Handbook (SG24-5444).
v The zEnterprise servers cannot be connected to a Sysplex Timer (9037-002).
The Server Time Protocol (STP) feature is the follow-on to the Sysplex Timer.
STP is designed to allow multiple servers and coupling facilities to maintain
time synchronization with each other without requiring a Sysplex Timer. STP
is a hardware feature of the zEnterprise, z10 EC, z10 BC, z9 EC, z9 BC, z990,
and z890 servers. To implement STP, see the STP web site and the
publications and other resources listed there. The STP web site is at
http://www.ibm.com/systems/z/advantages/pso/stp.html .
The STP design introduced a concept called Coordinated Timing Network
(CTN). A CTN is a collection of servers and coupling facilities that are
time-synchronized to a time value called Coordinated Server Time. A CTN
can be configured in two ways:


– STP-only CTN, which does not require a Sysplex Timer.
– Mixed-CTN (External Time Reference and STP), which does require a
Sysplex Timer.
The Sysplex Timer provides the timekeeping information in a Mixed-CTN.
Even though the zEnterprise servers do not support attachment to a
Sysplex Timer, they can participate in a Mixed-CTN that has either a z10
or z9 server synchronized to the Sysplex Timer. This maintains the
capability for enterprises to concurrently migrate from an existing External
Time Reference (ETR) to a Mixed-CTN and from a Mixed-CTN to an
STP-only CTN.
3. Unsupported hardware features: The following hardware features that were
| available on System z10 (and some earlier) servers cannot be ordered (and
| cannot be carried forward on an upgrade to a z114) server with zEnterprise
servers. You must migrate to the newer technology available on zEnterprise
servers.
v FICON Express®
v FICON Express2
v Crypto Express2
v OSA-Express2 10 GbE LR
The following hardware features are not orderable on z196 servers. If they are
installed on your existing server at the time of an upgrade to a z196 server,
they may be retained.
v FICON Express4 10KM LX
v FICON Express4 SX
v FICON Express4 4KM LX
v OSA-Express2 GbE LX
v OSA-Express2 GbE SX
v OSA-Express2 1000BASE-T
| The following hardware features are not orderable on z114 servers. If they are
| installed on your existing server at the time of an upgrade to a z114 server,
| they may be retained.
| v FICON Express4 10KM LX
| v FICON Express4 SX
| v FICON Express4 4KM LX
| v FICON Express4-2C 4KM LX
| v FICON Express4-2C SX
| v OSA-Express2 GbE LX
| v OSA-Express2 GbE SX
| v OSA-Express2 1000BASE-T

Actions you can take before you order a zEnterprise server
You can perform the following migration actions before you order or install a
zEnterprise server:
1. Review the sysplex configuration in which the zEnterprise server will
participate. In particular, if you have any existing z900, z800, z990, or z890
z/OS images or coupling facility images in the sysplex, move those z/OS
images or coupling facilities to later servers, such as a System z10 (z10 EC or


z10 BC), System z9 (z9 EC or z9 BC), or later. This action is necessitated by the
restriction that a zEnterprise server cannot participate with prior-level servers
in a sysplex.
2. Implement STP (or a Mixed-CTN) timing network. This action is necessitated
because Sysplex Timers (9037-002) are not supported on zEnterprise servers.
See “Migrate from a Sysplex Timer to STP” on page 45.
3. Migrate from ICB-4 to InfiniBand coupling links. This action is necessitated
because ICB-4 links are not supported on zEnterprise servers. If desired, you
can take this action after you order a zEnterprise server, as you upgrade to the
new server. See “Migrate from ICB-4 to Infiniband coupling links” on page 46.
4. Migrate from unsupported hardware features to newer technology. This
action is necessitated because FICON Express, FICON Express2, Crypto
Express2, and OSA-Express2 10 GbE LR are not supported on zEnterprise
servers.
5. Install the necessary z/OS service, as indicated in PSP buckets. For a
zEnterprise 196 CPC, PTFs are identified in the 2817DEVICE PSP bucket
| (Subset 2817/ZOS). For a zEnterprise 114 CPC, PTFs are identified in the
| 2818DEVICE PSP bucket (Subset 2818/ZOS). For an IBM zEnterprise
BladeCenter Extension (zBX) attached to your z196 CPC or to your z114 CPC,
the PTFs are identified in the 2458DEVICE PSP bucket (Subset 2458/ZOS). In
each PSP bucket, the content is dependent on the z/OS release you will run on
the zEnterprise server. If you reviewed the PSP buckets some time ago, review
them again to ensure that any newly identified z/OS service has been installed.
To assist you in determining if you have the recommended service (identified
in these PSP buckets) installed on your system, you can use the SMP/E
REPORT MISSINGFIX command in conjunction with the FIXCAT type of
HOLDDATA, as follows:
a. Acquire and RECEIVE the latest HOLDDATA onto your z/OS system(s).
Use your normal service acquisition portals or download the two (2) year
390holddata.html. Ensure you select Full from the Download NOW column
(last 730 days) to receive the FIXCAT HOLDDATA, as the other files do not
contain FIXCAT HOLDDATA.
b. Run the SMP/E REPORT MISSINGFIX command on your z/OS systems
and specify one or more of the following Fix Categories (FIXCAT):
v IBM.Device.Server.z196-2817
v IBM.Device.Server.z196-2817.ParallelSysplexInfiniBandCoupling
v IBM.Device.Server.z196-2817.ServerTimeProtocol
v IBM.Device.Server.z196-2817.zHighPerformanceFICON
| v IBM.Device.Server.z114-2818
| v IBM.Device.Server.z114-2818.ParallelSysplexInfiniBandCoupling
| v IBM.Device.Server.z114-2818.ServerTimeProtocol
| v IBM.Device.Server.z114-2818.zHighPerformanceFICON
| v IBM.Device.Server.z114-2818.UnifiedResourceManager
v IBM.Device.Server.zBX-2458
v IBM.Device.Server.zBX-2458.ISAOPT
The report will identify any missing coexistence and fallback PTFs for that
system. For complete information about the REPORT MISSINGFIX
command, see SMP/E Commands.


c. Periodically, you might want to acquire the latest HOLDDATA and rerun
the REPORT MISSINGFIX command to find out if there are any new PTFs
recommended for the zEnterprise servers.
Notes:
a. You can also use Service Link's PSP Service Extraction tool.
b. Because the Enhanced PSP Tool (EPSPT) was removed the end of 2010, you
can no longer use that tool to identify missing PSP bucket service. You
should use SMP/E’s Fix Category support, which is fully integrated into
SMP/E procedures and IBM product and service deliverables.
6. Run CFSIZER. If you are moving your coupling facilities and the coupling
facility structures will be on higher CFCC levels than they were previously, run
the Coupling Facility Structure Sizer (CFSIZER) tool to find out if you have to
increase coupling facility structure sizes. zEnterprise servers are initially
shipped with CFCC Level 17; prepare to make the necessary changes as
indicated by the tool. You can find the CFSIZER tool at http://www.ibm.com/
systems/support/z/cfsizer/.
7. Plan for the fixed HSA enhancement on a zEnterprise server. On zEnterprise
(and z10) servers, preplanning requirements are minimized by offering a fixed
HSA and introduction of the ability to seamlessly include such events as
creation of LPARs, inclusion of logical subsystems, changing logical processor
definitions in an LPAR, and introduction of cryptography into an LPAR.
8. Decide on the steps you will take for your migration to a zEnterprise server.
As a guide, see “Recommended migration steps” on page 57. Also, note the
following:
v You should compare the cryptographic support you currently have installed
with the support required for the functions you plan to use on the
zEnterprise server. Several cryptographic support web deliverables have been
made available for various z/OS releases. When a subsequent cryptographic
web deliverable is available for a particular z/OS level, the previous one is
withdrawn. The newer cryptographic web deliverable, however, includes the
previous function (when applicable) for that particular z/OS level. Note that
you can use the newer cryptographic web deliverables on servers before the
zEnterprise servers, that is, on z10 and z9 (or earlier) servers.
v The level of function provided for cryptographic support differs by z/OS
release and the ICSF web deliverable that is installed. For z/OS V1R11 and
later, exploitation of zEnterprise cryptographic support is provided by
| Cryptographic Support for z/OS V1R11-V1R13 (FMID HCR7790), available
| September 2011. Note that this level of ICSF is not integrated in z/OS V1R13
and will need to be downloaded and installed even after ordering a z/OS
| V1R13 ServerPac. For z/OS V1R11 and z/OS V1R12, exploitation of the
| original zEnterprise cryptographic enhancements was provided by the
| Cryptographic Support for z/OS V1R10-V1R12 web deliverable (FMID
| HCR7780), which is integrated into z/OS V1R13 orders. The Cryptographic
| web deliverables are available at http://www-03.ibm.com/systems/z/os/
| zos/downloads/
– Coexistence PTFs are available for all supported z/OS releases and all
existing supported ICSF web deliverables.
– For z/OS V1R11: If you require protected key CP Assist for Cryptographic
Function, new Crypto Express3 or Crypto Express3 -1P, then minimally
you must install the Cryptographic Support for z/OS V1R9-V1R11 web
deliverable (FMID HCR7770).
– For z/OS V1R11 and z/OS V1R12: If you require ANSI X9.8 Pin security,
enhanced Common Cryptographic Architecture (CCA), 64 Bit, CP Assist


for Cryptographic Function (CPACF) enhancements, Secure Keyed-Hash
Message Authentication Code (HMAC), CKDS Constraint Relief, PCI
Audit, Elliptical Curve Cryptography (ECC) Digital Signature Algorithm,
and CBC Key Wrap, PKA RSA OEAP with SHA-256, then minimally you
must install the Cryptographic Support for z/OS V1R10-V1R12 web
deliverable (FMID HCR7780), which is integrated into z/OS V1R13 orders.
| – For z/OS V1R11 and later releases: For Crypto Express3 feature when
| defined as a coprocessor: expanded support for AES algorithm, enhanced
| ANSI TR-31 Secure Key Exchange, PIN block decimalization table
| protection, and PKA RSA OAEP with SHA-256 algorithm, additional
| Elliptic Curve Cryptography (ECC) functions. You must install the
| Cryptographic Support for z/OS V1R11-V1R13 web deliverable (FMID
| HCR7790), available September 2011.

| Note: ICSF, specifically HCR7770, HCR7780, and HCR7790, require
coexistence PTFs to be installed on earlier levels of ICSF if they share
keys in their sysplex. To assist in identifying the coexistence service,
the following Fix Categories can be used:
– IBM.Coexistence.ICSF.z/OS_V1R9-V1R11-HCR7770
– IBM.Coexistence.ICSF.z/OS_V1R10-V1R12-HCR7780
| – IBM.Coexistence.ICSF.z/OS_V1R11-V1R13-HCR7790
9. Review the new mnemonics introduced for the zEnterprise server. The new
mnemonics might collide with (be identical to) the names of assembler macro
instructions you use or provide. In the event of such collisions, the HLASM’s
default opcode table (UNI) will treat specification of these names as
instructions when APAR PK97799 is installed. This will probably cause
assembler error messages and possibly cause generation of incorrect object
code.
If you write programs in Assembler Language, you should compare the list
provided in z/Architecture Principles of Operation to the names of assembler
macro instructions you use or provide, to identify any such conflicts or
collisions that would occur following installation of HLASM APAR PK97799. If
a conflict is identified, take one of the following actions:
v Change the name of your macro instruction.
v Specify PARM=’...OPTABLE(YOP)...’ (or some other earlier opcode table).
v Specify a separate ASMAOPT file containing assembler options, such as in
the previous method (this method requires no changes to source code or
JCL).
v Add, as the first statement of your source program, *PROCESS
OPTABLE(YOP).
v Specify the PROFILE option either in JCL or the ASMAOPT file, and the
specified or default member of the SYSLIB data set is copied into the front of
the source program.
v If you must use both a new instruction and a macro with the same name in
an assembly, you can use the following technique (where XXX is a sample
mnemonic):
Assume the default OPTABLE(UNI) is in effect
XXX a,b new instruction
PUSH ACONTROL save current optable definition
ACONTROL OPTABLE(YOP) switch optable dynamically
XXX r,s,t macro invocation
POP ACONTROL restore previous definition
XXX c,d new instruction


For more information about HLASM’s opcode table, see HLASM Programmer's
Guide.

Actions you can take after you order a zEnterprise server
After you order but before you install your zEnterprise server, do the following:
1. Use the CHPID Mapping Tool. As you might have done with your z10 EC,
z10 BC, z9 EC or z9 BC servers, use the CHPID Mapping Tool to map logical
CHPIDs to physical channels (PCHIDs) and create input to HCD/IOCP for
your zEnterprise server. The tool is a workstation-based Java application
available from the Resource Link® web site (http://www.ibm.com/servers/
resourcelink). For more information about this tool, refer to the web site.
2. Define an Ensemble. If you are running z/OS V1R10 or later, you can define
an Ensemble and exploit the IBM zEnterprise Unified Resource Manager. See
System z Ensemble Planning and Configuration Guide (GC27-2608) for a detailed
description of the steps required to define an Ensemble.

Recommended migration steps
This topic suggests the steps for migrating your same z/OS release level from your
current server to a zEnterprise server. The steps are based on the assumption that
you want to minimize the amount of change (and therefore risk) and the amount
of work required to perform the migration.

Your migration steps follow:
1. If necessary, migrate to an STP-only or Mixed-CTN timing network.
2. Ensure that you have installed the z196, z114, z10 EC (or z10 BC), and z9 EC
(or z9 BC) required service, as indicated in the respective PSP buckets. Refer to
Install the necessary z/OS service, as indicated in PSP buckets in “Actions
you can take before you order a zEnterprise server” on page 53 for information
about how SMP/E V3R5 and SMP/E V3R6 can help you identify, acquire, and
install any missing required service.
3. Ensure you have the required service, and any required ICSF web deliverable
installed for the cryptographic functions that you have decided to use.
4. Upgrade your hardware to zEnterprise system. If necessary convert to
InfiniBand Coupling Links from ICB-4 links.
5. Update configuration setting to exploit zEnterprise functions.

Migration and exploitation considerations for zEnterprise
functions
This topic provides migration and exploitation considerations for zEnterprise
server functions.

The following zEnterprise functions are available on z/OS V1R11 and later
releases:
v InfiniBand Coupling. Each system can use, or not use, InfiniBand coupling
links independently of what other systems are doing, and do so in conjunction
with other link types. InfiniBand Coupling connectivity can only be performed
with other systems that also support InfiniBand Coupling.
v HiperDispatch. The existing HIPERDISPATCH=YES|NO parameter in
IEAOPTxx member of parmlib, and on the SET OPT=xx command to control
whether HiperDispatch is enabled or disabled for the system, can be changed
dynamically. The default is that HiperDispatch is disabled on z/OS V1R7
| through z/OS V1R12.


| Beginning with z/OS V1R13 when running on a zEnterprise server, the
| IEAOPTxx keyword HIPERDISPATCH will default to YES. If
| HIPERDISPATCH=NO is specified, the specification will be honored as it was on
| previous z/OS releases. The IBM z/OS Health Checker check
| SUP_HiperDispatch checks whether the expected HiperDispatch check
| parameter state (HIPERDISPATCH(YES) or HIPERDISPATCH(NO), where YES is
| the default for the check, matches the actual HiperDispatch state of the system.
| For more information, see “Accommodate HiperDispatch default of YES on IBM
| zEnterprise (z196 and z114)” on page 108.
| A WLM goal adjustment might be required when using HiperDispatch. Review
| and update your WLM policies as necessary.
v HiperDispatch cache and affinity node changes. This function is enhanced to
exploit zEnterprise architecture and now allows three physical CPs from same
chip to form affinity node. A z10 uses HiperDispatch book cache support and
four physical CPs from same book.
To realize the benefits of HiperDispatch, z/OS has been changed to force
HiperDispatch=YES for LPARs with greater than 64 CPUs. On LPARs with
greater than 64 CPUs defined on a zEnterprise server with IEAOPTxx specifying
HIPERDISPATCH=NO during IPL (or SET OPT=xx after IPL), the system
generates a message but continues to run with HIPERDISPATCH=YES. The new
message is IRA865I HIPERDISPATCH=YES FORCED DUE TO GREATER THAN
64 LPS DEFINED.
On LPARs in which HIPERDISPATCH=NO is specified with less than 64 CPUs,
you can dynamically add more CPUs and continue to run in
HIPERDISPATCH=NO. However, you may see the new message ISN012E
HIPERDISPATCH MUST BE ENABLED TO CONFIGURE CPU IDS GREATER
THAN 3F ONLINE.
Any attempt to configure CPUs greater than 64 CPUs online in
HIPERDISPATCH=NO will be rejected with message IEE241I CPU(x) NOT
RECONFIGURED ONLINE - REQUIRES HIPERDISPATCH ENABLED.
An LPAR with greater than 64 CPUs that dynamically changed to
HIPERDISPATCH=YES cannot go back to HIPERDISPATCH=NO. It will be
treated as if it was IPLed with HIPERDISPATCH=YES after
HIPERDISPATCH=YES is activated.
To assist with warning when you are getting close to 64 CPUs and running with
HIPERDISPATCH=NO, the IBM Health Checker for z/OS check,
SUP_HiperDispatchCPUConfig, was added in z/OS V1R12 and available on
z/OS V1R11 with APAR OA30476. The check always succeeds for LPAR in
HIPERDISPATCH=YES (all CPU configurations supported). When an LPAR is
running with HIPERDISPATCH=NO, the check raises an exception when the
number of CPUs is close to forcing the LPAR to IPL with
HIPERDISPATCH=YES. The CPUSLEFTB4NEEDHD parameter indicates the
minimum number of CPUs that can be installed and activated on an LPAR
running in HIPERDISPATCH=NO. When CPUSLEFTB4NEEDHD=0, the check
always succeeds. The default is 8, with values 0-63 accepted. The system
redrives the check when the HIPERDISPATCH state changes or CPUs are
dynamically added. Possible IBM Health Checker for z/OS messages:
– IEAVEH080I CPU configuration supported with HiperDispatch curstate
– IEAVEH081E CPU configuration supported with HiperDispatch disabled.
numcpus more CPU(s) can be added with HiperDispatch disabled.
v CFCC Level 17. If you are moving your coupling facilities and the coupling
facility structures will be on higher CFCC levels than they were previously, run
the Coupling Facility Structure Sizer (CFSIZER) tool to find out if you have to


increase coupling facility structure sizes. zEnterprise servers initially shipped
with CFCC Level 17. Prepare to make the necessary changes as indicated by the
tool. You can find the CFSIZER tool at http://www.ibm.com/systems/support/
z/cfsizer/.

Note: The PTFs to support CFCC Level 17 have coexistence (or sysplex
preconditioning) PTFs that require installation throughout your sysplex
prior to implementing CFCC Level 17.
v Third Subchannel Set. You now have the ability to extend the amount of
addressable storage capacity to help facilitate storage growth with the
introduction of a third subchannel set, an additional 64K devices, to help
complement other functions such as "large" or extended addressing volumes and
HyperPAV. This may also help to facilitate consistent device address definitions,
simplifying addressing schemes for congruous devices.
The first subchannel set (SS 0) allows definitions of any type of device, such as
bases, aliases, secondaries, and those other than disk that do not implement the
concept of associated aliases or secondaries. The second and third subchannel
sets (SS1 and SS2) can now both be designated for use for disk alias devices (of
both primary and secondary devices), or Metro Mirror secondary devices only.
The third subchannel set applies ESCON, FICON and zHPF protocols.
Definitions for the third subchannel set are similar to those for the second
subchannel set and can be made with HCD.
| The IODF statement of LOADxx allows users to indicate which devices to use
| during IPL (that is, devices that are connected to subchannel set 0, 1 or 2). This
| specification is done on the IODF statement (column 36). For more information,
| see z/OS MVS Initialization and Tuning Reference.
v IPL from alternate subchannel set. This function allows you to IPL from
subchannel set 1 (SS1) or subchannel set 2 (SS2), in addition to subchannel set 0.
Devices used early during IPL processing can now be accessed using subchannel
set 1 or subchannel set 2. This is intended to allow users of Metro Mirror (PPRC)
secondary devices defined using the same device number and a new device type
in an alternate subchannel set to be used for IPL, IODF, and standalone dump
| volumes when needed. IPL from an alternate subchannel set is supported by
| z/OS V1R13, as well as z/OS V1R12 and z/OS V1R11 with PTFs, and applies to
| the FICON and zHPF protocols (CHPID type FC).
| To IPL from an alternate subchannel set, you need to specify a 5 digit load
| address on the LPAR image profile on the HMC, and have the appropriate
| specification on the IODF statement in LOADxx.
v IBM zEnterprise Unified Resource Manager for enabling management and
virtualization of heterogeneous workloads. The Unified Resource Manager
manages the deployment of heterogeneous hardware resources based on
individual workload requirements:
– Performance management
– Integrated private data network
See System z Ensemble Planning and Configuration Guide (GC27-2608) for a detailed
description on the steps required.
| v Power save mode. This function is available only on z196 servers. There is a
| new SMFPRMxx parmlib option, MAXEVENTINTRECS, that allows governing
| the number of event interval records to be collected when the processor capacity
| changes. The default is zero. To collect extra records between regular intervals
| when the processor capacity changes, the default must be adjusted.
| If you are using the CPU Measurement Facility (Hardware Instrumentation
| Services), there is a new parameter on the MODIFY hisproc command. You can


| use this parameter, STATECHANGE, to override the default action to take when
| a CPU speed change is detected within the HIS component.
| v zHPF performance improvements for FICON Express8S. FICON Express8S
| contains a new IBM ASIC which is designed to support the 8 Gbps (gigabytes
| per second) PCIe interface to the PCIe I/O drawer and increased start I/Os. In
| addition, a hardware data router has been added in support of the zHPF and
| FCP protocols for path length reduction and increased throughput. FICON
| Express8S supports a link data rate of 2, 4, or 8 Gbps autonegotiated. With these
| changes FICON Express8S, when supporting the zHPF or FCP protocols, has
| been designed to achieve full duplex line speed (8 Gbps) in each direction. The
| performance of the FICON protocol remains unchanged from FICON Express8.
| To use zHPF performance improvements for FICON Express8S, you need to
| specify the ZHPF=YES | NO parameter in the IECIOSxx of PARMLIB and use
| FICON Express8S
| v Additional Crypto exploitation. The following enhancements have been added
| to the Common Cryptographic Architecture support, which is used in the
| Crypto Express3 feature when it is configured as a coprocessor:
| – ANSI X9.8 Pin security
| – Enhanced Common Cryptographic Architecture (CCA), 64bit, CP Assist for
| Cryptographic Function (CPACF) enhancements
| – Secure Keyed-Hash Message Authentication Code (HMAC)
| – CKDS Constraint Relief
| – PCI Audit, Elliptical Curve Cryptography (ECC) Digital Signature Algorithm
| – CBC Key Wrap
| – PKA RSA OEAP with SHA-256
| – Expanded support for AES algorithm
| – Enhanced ANSI TR-31 Secure Key Exchange
| – PIN block decimalization table protection
| – PKA RSA OAEP with SHA-256 algorithm, additional Elliptic Curve
| Cryptography (ECC) functions.

The following zEnterprise functions are only available on z/OS V1R12 and later
releases:
v z/OS Discovery and AutoConfiguration (zDAC) for FICON channels. With a
zEnterprise CPC and z/OS, a new function, z/OS Discovery and
AutoConfiguration (zDAC), is designed to automatically perform a number of
I/O configuration definition tasks for new and changed disk and tape
controllers connected to a switch or director when attached to a FICON channel.
When new controllers are added to an I/O configuration, or changes are made
to existing controllers, the system is designed to discover them and propose
configuration changes based on a policy you define in the hardware
configuration dialog (HCD). Your policy can include preferences for availability
and bandwidth including parallel access volume (PAV) definitions, control unit
numbers, and device number ranges.
zDAC is designed to perform discovery for all systems in a sysplex that support
the function. The proposed configuration will incorporate the current contents of
the I/O definition file (IODF) with additions for newly installed and changed
control units and devices. zDAC is designed to help simplify I/O configuration
on CPC running z/OS and reduce complexity and setup time. zDAC applies to
all FICON features supported on zEnterprise servers when configured as CHPID
type FC, and is supported by z/OS V1R12 and later.


To use zDAC, you must first establish a policy for the discovery operation. This
is done through HCD or HCM. You can limit the scope of the discovery, limit
the proposal information, indicate the desired number of paths to discovered
logical control units, and indicate the method used for device and control unit
numbering. After controllers and devices are discovered, you can select which
controllers to be defined and accept or override the proposed values for control
units and devices.
v OSA-Express3 and OSA-Express4S Inbound Workload Queuing (IWQ).
Inbound workload queuing for Enterprise Extender is supported by the
OSA-Express4S and OSA-Express3 features when defined as CHPID types OSD
or OSX. It is exclusive to the z196 and z114 servers, and is supported by z/OS
and by z/VM for guest exploitation. OSA-Express3 introduces inbound
workload queuing (IWQ), which creates multiple input queues and allows OSA
to differentiate workloads "off the wire" and then assign work to a specific input
queue (per device) to z/OS. With each input queue representing a unique type
of workload, each having unique service and processing requirements, the IWQ
function allows z/OS to preassign the appropriate processing resources for each
input queue. This approach allows multiple concurrent z/OS processing threads
to then process each unique input queue (workload), avoiding traditional
resource contention. In a heavily mixed workload environment, this "off the
wire" network traffic separation provided by OSA-Express3 IWQ reduces the
conventional z/OS processing required to identify and separate unique
workloads, which results in improved overall system performance and
scalability. The types of z/OS workloads that are identified and assigned to
unique input queues are:
– z/OS Sysplex Distributor traffic: Network traffic that is associated with a
distributed Virtual Internet Protocol Address (VIPA) is assigned a unique
input queue allowing the Sysplex Distributor traffic to be immediately
distributed to the target host.
– z/OS bulk data traffic: Network traffic that is dynamically associated with a
streaming (bulk data) TCP connection is assigned to a unique input queue
allowing the bulk data processing to be assigned the appropriate resources
and isolated from critical interactive workloads.
IWQ is supported on zEnterprise CPC and System z10, and is exclusive to
OSA-Express3 CHPID types OSD and OSX (exclusive to zEnterprise CPC). There
are some Communications Server configuration settings required to enable
multiple inbound data queues.
v Display OSAINFO. OSA-Express3 introduces the capability for the operating
system to directly query and display the current OSA configuration information
(similar to OSA/SF). z/OS exploits this new OSA capability by introducing a
new TCP/IP operator command, Display OSAINFO. Display OSAINFO allows
the operator to monitor and verify the current OSA configuration, which helps
to improve the overall management, serviceability, and usability of
OSA-Express3. The Display OSAINFO command is exclusive to OSA-Express3
CHPID types OSD, OSM, and OSX (on z196, z114, and z10 servers).
v C/C++ ARCH(9) and TUNE(9) options. The ARCHITECTURE C/C++ compiler
option selects the minimum level of machine architecture on which your
program can run. Certain features provided by the compiler require a minimum
architecture level. ARCH(9) exploits instructions available on zEnterprise servers.
For more information, refer to the ARCHITECTURE compiler option in z/OS XL
C/C++ User's Guide. The TUNE compiler option allows you to optimize your
application for specific machine architecture. The TUNE level has to be at the
ARCH level, at a minimum. If the TUNE level is lower than the specified ARCH
level, the compiler forces TUNE to match the ARCH level, or uses the default


TUNE level, whichever is greater. For more information about the
ARCHITECTURE and TUNE compiler options refer to z/OS XL C/C++ User's
Guide.
Exploitation restriction. When programs exploit the ARCH(9) or TUNE(9)
option, those programs can only run on zEnterprise servers, or an operation
exception will occur. This is a consideration for programs that will run on
different server levels (z10 and z9 servers) during development, test, and
production, as well as during fallback or disaster recovery.

| The following zEnterprise functions are only available on z/OS V1R13 and later
| releases. See z/OS Introduction and Release Guide for restrictions, dependencies, and
| steps to take to use these new hardware functions):
| v OSA-Express4S checksum offload for LPAR-to-LPAR traffic for IPv4 and IPv6
| packets (CHPID type OSD). Checksum offload for LPAR-to-LPAR traffic is
| included in the OSA-Express4S design. The checksum function has been moved
| from the PCIe adapter to the OSA-Express4S hardware to help reduce CPU
| utilization.
| v OSA-Express4S large send for IPv6 packets (CHPID types OSD and OSX).
| Large send (also referred to as TCP segmentation offload) is designed to
| improve performance by offloading outbound TCP segmentation processing
| from the host to an OSA-Express4S feature by employing a more efficient
| memory transfer into OSA-Express4. Large send support for IPv6 packets
| applies to the OSA-Express4S features (CHPID type OSD and OSX), and is
| exclusive to z196 and z114.
| v Inbound workload queuing for Enterprise Extender. Inbound workload
| queuing (IWQ) for the OSA-Express4S features has been enhanced to
| differentiate and separate inbound Enterprise Extender traffic to a new input
| queue. The Enterprise Extender separation and processing associated with the
| Enterprise Extender input queue provides improved scalability and performance
| for Enterprise Extender.

| Note: See z/OS Communications Server: IP Configuration Guide for additional
| information about OSA-Express4S checksum offload for LPAR-to-LPAR
| traffic for IPv4 and IPv6 packets (CHPID type OSD), OSA-Express4S large
| send for IPv6 packets (CHPID types OSD and OSX), and Inbound workload
| queuing for Enterprise Extender.

Migrate to a System z10 server
Description: The IBM System z10 servers (z10 EC and z10 BC) are follow ons to
the IBM System z9 servers (z9 EC [formerly z9-109] and z9 BC) and IBM eServer
zSeries servers (z990, z890, z900, and z800). The System z10 servers build on the
inherent strengths of the System z platform, deliver new technologies that offer
dramatic improvements in price and performance for key new workloads, and
enable a new range of hybrid solutions.

The specific System z10 functions exploited by z/OS depend on the z/OS release.
See Table 6.
Table 6. System z10 functions supported by z/OS V1R11 and z/OS V1R12 and z/OS V1R13
System z10 function R11 R12 R13
Included in base z/OS support
Dynamic addition of logical CPs without B B B
preplanning


Table 6. System z10 functions supported by z/OS V1R11 and z/OS V1R12 and z/OS V1R13 (continued)
RMF FICON enhancement B B B
Greater than 54 CPs (64) for a single B (z10 EC only) B (z10 EC only) B (z10 EC only)
LPAR
XL C/C++ ARCH(8) and TUNE(8) B B B
Large memory (up to 1 TB on z10 EC B B B
now, up to 248 GB on z10 BC planned for
30Jun2009)
HiperDispatch B B B
CPACF and Configurable Crypto Express2 B B B
Key management for remote loading of B B B
ATM and point-of-sale (POS) keys and
support for ISO 16609 CBC Mode T-DES
MAC requirements
New z/Architecture instructions B B B
65535 MP factors B B B
OSA-Express3 10 Gigabit Ethernet B B B
FICON8 enhancement B B B
OSA-Express3 Gigabit Ethernet B B B
1000BASE-T Ethernet B B B
Protected Key CP Assist for B B B
Cryptographic Function
New Crypto Express3 and Crypto B B B
Express3 -1P
Explicit z/OS support
HiperSockets Multiple Write Facility B B B
Capacity Provisioning B B B
Large page support B B B
OSA-Express3 double port density B B B
CPU Measurement Facility architecture B B B
Service aids support for large dumps B B B
Layer 3 VMAC support (VMAC Support B B B
for OSA-Express2 and OSA-Express3
when configured as CHPID type OSD
[QDIO])
CPACF enhanced to support SHA-384 and B B B
SHA-512 bit for message digest, ISO
Format 3 PIN blocks, secure key AES,
support for RSA keys up to 4096 bits in
length, dynamically add crypto to a
logical partition, Random Number
Generator Long, and enhanced TKE
auditing
Support for 13-digit through 19-digit PAN B B B
data, ICSF Query service, and enhanced
SAF checking
Coupling facility level 16 B B B


Table 6. System z10 functions supported by z/OS V1R11 and z/OS V1R12 and z/OS V1R13 (continued)
High Performance FICON for System z B B B
(zHPF)
Decimal floating point B B B
Usage Report Program (IFAURP) support B B B
Parallel Sysplex InfiniBand (PSIFB) B B B
coupling links
Legend:
Blank – not supported
B – FMID in base product (assumes service identified in the hardware PSP bucket is
installed)
P – PTFs listed in the System z10 PSP bucket are required

When change was introduced: The System z10 EC server, which first
shipped in February 2008.
Timing: Anytime.
Is the migration action required? Yes, if you want to run z/OS on a System
z10 server.
Target system hardware requirements: A System z10 server.
Target system software requirements: See the appropriate PSP buckets for required
web deliverables and PTFs for specific
functions, as described in “Recommended
migration steps” on page 69.
Other system (coexistence or fallback) See the appropriate PSP buckets for required
requirements: PTFs for specific functions, as described in
“Recommended migration steps” on page 69.
Restrictions: None.
check:

Steps to take: Follow the recommendations and considerations, adhere to the
restrictions, and perform the tasks described in the topics below.

As you plan your migration to a System z10 server, consider the following:
1. Relatively few migration actions are new when coming from a System z9
server. Migration to a System z10 server has, as its basis, a migration to a z9
EC or z9 BC. This means that if you are migrating to a System z10 server from
a z9 EC or z9 BC (and have performed the migration actions associated with
the z9 EC or z9 BC), you have fewer migration actions than if you were
migrating from a server prior to the z9 EC or z9 BC and have not yet
performed the migration actions associated with the z9 EC or z9 BC. There are,
in fact, very few new migration actions to perform on z/OS for a System z10
server if you have already migrated to a z9 EC or z9 BC. It is important to note
that you can migrate directly to a System z10 server without installing the


intermediate (prior to z9 EC and z9 BC) servers, but you still need to ensure
that any migration considerations are satisfied for the servers that you
“skipped”. To read about z9 EC and z9 BC migration actions, see “Migrate to a
System z9 server” on page 73.
2. Support is delivered by service (and FMID web deliverables for ICSF). The
delta (from a z9 EC or z9 BC) support for a System z10 server, excluding
cryptographic support, is delivered by service (PTFs). Some cryptographic
support for the System z10 (and earlier) servers is provided by a web
deliverable (FMID). Depending on the cryptographic support provided and the
z/OS release that you are running, you might need to download and install a
different ICSF web deliverable.
sizes might change. System z10 servers now ship with CFCC level 16. If, as
part of your migration to a System z10 server, you change CFCC levels (either
by placing a coupling facility on the System z10 server or by moving the
coupling facility to a z9 EC or z9 BC at a later CFCC level), you might have
larger structure sizes than you did previously. If your CFCC levels are identical,
server to a System z10 server.
4. Update CFRM policies. Coupling facilities are identified in the CFRM policy
by their physical node descriptor information (for example, machine type,
model, serial number, LPAR number). When a coupling facility undergoes a
hardware upgrade, one or more of these pieces of information is likely to
change, therefore, the definition of the coupling facility in the CFRM policy
must change accordingly.

Restrictions
Restrictions associated with the System z10 server are:
1. Functional limitations: Not all System z10 functions are available in every
z/OS release. See Table 6 on page 62 for a list of the System z10 functions
available in each z/OS release. Some functions have exploitation or migration
considerations (see below). Many functions are enabled or disabled, based on
the presence or absence of the required hardware and software. If you wish to
position to exploit any new System z10 functions, the software and hardware
may be installed in either order. That is, there is no requirement to install either
software or hardware first to exploit a specific function.
2. System z10 in a sysplex:
v The z9 EC and z9 BC are the last servers to support active participation in
the same Parallel Sysplex with z900, z800, and earlier servers. If you are
running z/OS on a z900 or z800, you cannot add a System z10 server to that
sysplex. That is, you will not be able to perform rolling IPLs to introduce a
System z10 server if you have any z900 or z800 images (either as z/OS
images or coupling facilities) in the sysplex. Any z900 or z800 servers in the
sysplex have to be upgraded to a z990, z890, or later server to have a System
z10 server supported in the sysplex. If you have any z/OS images or
coupling facilities on a z900 or z800, and you intend to introduce a System


z10 server into that sysplex, you must migrate those images to z990 or z890
(or later) prior to introducing the System z10 server.
v The Integrated Cluster Bus (ICB) connector on the System z10 server is
different than on previous servers, requiring new links and connectors to be
installed on previous servers in order to connect them to a System z10 server
by ICB. This is a hardware-only migration action.
v The z10 EC model E64 servers cannot use ICB-4 coupling links. On this
model, all required coupling link connectivity must be provided using PSIFB
and/or ISC-3 coupling links.

Actions you can take before you order a System z10 server
You can perform the following migration actions before you order or install your
System z10 server:
1. Review the sysplex configuration in which the System z10 server will
participate. In particular, if you have any existing z900 or z800 z/OS images or
coupling facilities in the sysplex, move these z/OS images or coupling facilities
to later servers (such as z990 or z890 or later). This action is necessitated by the
restriction that a System z10 server cannot participate with a z900 or z800 in a
sysplex.
2. Install new links and connectors on earlier servers. This action is necessitated
because the ICB connector on the System z10 server is different than on
previous servers.
3. Review restrictions and coexistence requirements for earlier servers. Because
the z9 EC and z9 BC support is the basis for the System z10 server support, the
restrictions and coexistence requirements for the z9 EC and z9 BC also apply to
the System z10 server. For instance, large page support is not supported by
z/OS when z/OS runs as a guest under z/VM® on a System z10 server.
Review the restrictions and coexistence requirements that were introduced for
the z9 EC, if you have not already done so, and take any necessary actions. You
can find the z9 EC restrictions and coexistence requirements in “Migrate to a
System z9 server” on page 73.
4. Install the necessary z/OS service, as indicated in PSP buckets. The
appropriate PSP buckets are listed in “Recommended migration steps” on page
69 and are dependent on the z/OS release you will run on the System z10
server and on the hardware support you already have installed. If you
reviewed the PSP buckets a long time ago, there might have been additions
since then, so ensure that any newly identified z/OS service has been installed.
To assist you in determining whether you have the recommended service
installed on your system, which is identified in these PSP buckets, you can use
the SMP/E REPORT MISSINGFIX command with a FIXCAT value of
“IBM.Device.Server.z10-EC-2097” or “IBM.Device.Server.z10-BC-2098”, the
Enhanced PSP Tool (http://www14.software.ibm.com/webapp/set2/psp/
srchBroker), or ServiceLink’s PSP Service Extraction tool.
If you use REPORT MISSINGFIX, some FIXCAT values you can use for specific
System z10 functions are:
v IBM.Device.Server.z10-BC-2098.CapacityProvisioning
v IBM.Device.Server.z10-BC-2098.DecimalFloatingPoint
v IBM.Device.Server.z10-BC-2098.MIDAW
v IBM.Device.Server.z10-BC-2098.ParallelSysplexInfiniBandCoupling
v IBM.Device.Server.z10-BC-2098.ServerTimeProtocol
v IBM.Device.Server.z10-BC-2098.zAAP
v IBM.Device.Server.z10-BC-2098.zHighPerformanceFICON


v IBM.Device.Server.z10-BC-2098.zIIP
v IBM.Device.Server.z10-EC-2097.CapacityProvisioning
v IBM.Device.Server.z10-EC-2097.DecimalFloatingPoint
v IBM.Device.Server.z10-EC-2097.MIDAW
v IBM.Device.Server.z10-EC-2097.ParallelSysplexInfiniBandCoupling
v IBM.Device.Server.z10-EC-2097.ServerTimeProtocol
v IBM.Device.Server.z10-EC-2097.zAAP
v IBM.Device.Server.z10-EC-2097.zHighPerformanceFICON
v IBM.Device.Server.z10-EC-2097.zIIP
5. Run CFSizer. If you are moving your coupling facilities and the coupling
facility structures will be on later CFCC levels than they were previously, run
the Coupling Facility Structure Sizer (CFSizer) tool to find out if you have to
increase coupling facility structure sizes. Prepare to make the necessary changes
as indicated by the tool. You can find the CFSizer tool at http://
www.ibm.com/systems/support/z/cfsizer/.
6. Plan for the System z10 fixed HSA enhancement. With System z10 servers,
planning requirements are minimized by the availability of a fixed HSA and
introduction of the ability to seamlessly include events such as creation of
LPARs, inclusion of logical subsystems, changing logical processor definitions
in an LPAR, and introduction of cryptography into an LPAR. For more
information about this enhancement, see the System z10 Redbooks®.
7. Decide on the steps you will take for your migration to a System z10 server.
As a guide, see “Recommended migration steps” on page 69. Be aware of the
following:
v You should review the cryptographic support you currently have installed
versus the support required for the functions you plan to use on the System
z10 server. Several cryptographic support web deliverables have been made
available for various z/OS releases. The web deliverables listed in
“Recommended migration steps” on page 69 are the minimum web
deliverable level for the function specified. When a subsequent cryptographic
web deliverable is available for a particular z/OS level, the previous one is
withdrawn. The newer cryptographic web deliverable, however, includes the
previous function (when applicable) for that particular z/OS level. Note that
you can use the newer cryptographic web deliverables on servers prior to the
System z10 server (that is, on System z9 and zSeries servers).
The level of cryptographic support integrated in z/OS is ICSF FMID
HCR7751 in z/OS V1R11, ICSF FMID HCR7770 in z/OS V1R12. and ICSF
FMID HCR7780 in z/OS V1R13.
Where ICSF FMID HCR7751 is installed, the following coexistence support is
needed on other systems:
– PTF UA51214 (APAR OA29839) and PTF UA44731 (APAR OA26579) for
FMID HCR7750
– PTF UA51212 (APAR OA29839), PTF UA37971 (APAR OA21807), and PTF
UA44730 (APAR OA26579) for FMID HCR7740
Where ICSF FMID HCR7770 is installed, the following coexistence support is
needed on other systems:
– PTF UA51255 (APAR OA29997) and PTF UA51213 (APAR OA29839) for
FMID HCR7751
– PTF UA51254 (APAR OA29997), PTF UA51214 (APAR OA29839), and PTF
UA44731 (APAR OA26579) for FMID HCR7750


– PTF UA51253 (APAR OA29997), PTF UA51212 (APAR OA29839), PTF
UA37971 (APAR OA21807), and PTF UA44730 (APAR OA26579) for FMID
HCR7740
v You can migrate to z/OS V1R13 before or after you migrate to a System z10
server.
8. Upgrade your SCRT level if you want to process System z10 SMF data. SCRT
V14.2.9 (Version 14 Release 2 Modification Level 9) provides support for the
System z10 server. If you collect SMF data on a System z10 server and the data
will be processed by the SCRT, you must minimally use SCRT V14.2.9 to
generate your SCRT reports. If you do not need to process SMF data from a
System z10 server, you are not required to download or use SCRT V14.2.9; you
may continue to use SCRT V14.1.0 or V14.2.0 until the next version upgrade of
the SCRT. SCRT V14.2.9 (or later) is available from the SCRT web site at
http://www.ibm.com/eserver/zseries/swprice/scrt/.
9. Review the new mnemonics introduced for the System z10. In support of the
System z10 server, HLASM introduced new mnemonics for the new machine
instructions. The new mnemonics might collide with (be identical to) the names
of assembler macro instructions you use or provide. In the event of such
collisions, the HLASM default opcode table (UNI) will treat specification of
these names as instructions when the PTF for APAR PK58463 is installed. This
will probably cause assembler error messages and possibly cause generation of
incorrect object code.
If you write programs in assembler language, you should compare the list
provided in z/Architecture Principles of Operation to the names of assembler
macro instructions you use or provide, to identify any such conflicts or
collisions that would occur following installation of the PTF for HLASM APAR
PK58463.
To see the differences of supported mnemonics before and after applying the
PTF for APAR PK58463, assemble an END statement with the
PARM='OPTABLE(UNI,LIST)' option, and compare the SYSPRINT files for the
two assemblies.
If a conflict is identified, take one of the following actions:
v Change the name of your macro instruction.
v Specify PARM=’...OPTABLE(YOP)...’ or some other, earlier opcode table.
v Specify a separate ASMAOPT file containing assembler options as in the
previous method. This method requires no changes to source code or JCL.
v Add *PROCESS OPTABLE(YOP) as the first statement of your source program.
v Specify the PROFILE option in either JCL or the ASMAOPT file, and the
specified or default member of the SYSLIB data set is copied into the
beginning of the source program.
v If you must use both a new instruction and a macro with the same name in
an assembly, you can use the following technique, where XXX is a sample
mnemonic. (Assume that the default OPTABLE(UNI) is in effect.)
XXX a,b new instruction
PUSH ACONTROL save current optable definition
ACONTROL OPTABLE(YOP) switch optable dynamically
XXX r,s,t macro invocation
POP ACONTROL restore previous definition
XXX c,d new instruction
For more information about the HLASM opcode table, see HLASM
Programmer's Guide.


Actions you can take after you order a System z10 server
After you order but before you install your System z10 server, do the following:
1. Use the CHPID Mapping Tool. As you might have done with your z9 EC or
z9 BC, use the CHPID Mapping Tool to map logical CHPIDs to physical
channels (PCHIDs) and create input to HCD/IOCP for your System z10 server.
The tool is a workstation-based Java application available from the Resource
Link web site (http://www.ibm.com/servers/resourcelink). For more
information about this tool, refer to the web site.
2. Plan for the changes in hardware memory granularity on a System z10 server.
The minimum hardware memory granularity for LPAR assignment to central
storage elements (initial and reserved) and for z/OS memory reconfiguration is
changed on System z10 servers. On a z9 EC, z9 BC, z990, and z890 it is 64 MB,
on a z10 EC it is 256 MB, and on a z10 BC it is 128 MB. Addressability is also
increased to 8 TB on a z10 EC. For more information, see PR/SM Planning
Guide.
If your installation is set up to do central memory reconfiguration with z/OS,
you might have to change your RSU setting in parmlib member IEASYSxx. You
can specify RSU as a number, a percentage of all storage, or in MB (or GB or
TB). z/OS MVS Initialization and Tuning Reference states that while number
values from 1-9999 are supported, it is recommended that you use the
megabyte, gigabyte, or terabyte format. If you currently specify RSU as a
number, such as RSU=10 on a System z9 server, this would result in 640 MB
assuming a partition with the largest element of 32 GB or less of central
storage. However, on a z10 EC with the same amount of central storage, the
result would be 2560 MB. If you specify an RSU in MB or GB, there will
probably be less of an impact but you need to understand that the values are
rounded to a multiple of 256 MB instead of 64 MB or 128 MB.
Note that specifying an RSU value greater than the total amount of real storage
available on the system will cause message IAR026I THE RSU VALUE
SPECIFIED EXCEEDS THE TOTAL AMOUNT OF REAL STORAGE
AVAILABLE ON THIS SYSTEM: yyyyyyyyM to be issued by the system during
IPL indicating an RSU overspecification condition, and showing the amount of
real storage available on the system. This message will be followed by IAR006A
INVALID {VRREGN|REAL|RSU} PARM - RESPECIFY OR PRESS ENTER FOR
THE DEFAULT prompting for a valid RSU value. Special care should be given
to select the right RSU value for the system. A large RSU value can ultimately
cause system performance problems.

Note: Message IAR026I was introduced in z/OS V1R11, and rolled back to
prior releases, by RSM APAR OA27801. It is now integrated into the base
of z/OS V1R12.

current server to a System z10 server. The steps are based on the assumption that

If your current z/OS release is V1R11, follow these steps:
1. Install the service in the following PSP buckets:
v The z10 PSP bucket:
– For the z10 EC: upgrade 2097DEVICE, subset 2097/ZOS
– For the z10 BC: upgrade 2098DEVICE, subset 2098/ZOS


v The z9 EC PSP bucket: upgrade 2094DEVICE, subset 2094/ZOS (if not
already on a z9 EC or z9 BC)
v The z990 PSP bucket: upgrade 2084DEVICE, subset 2084/ZOS (if not already
on a z990 or z890)
2. Upgrade your hardware to a System z10 server. If you are migrating from a
z990 or z890 server, see “Migrate to a System z9 server” on page 73 for z9 EC
and z9 BC migration considerations that you must also satisfy.

If your current z/OS release is V1R12, follow these steps:
v The z10 PSP bucket:
– For the z10 EC: upgrade 2097DEVICE, subset 2097/ZOS
– For the z10 BC: upgrade 2098DEVICE, subset 2098/ZOS
v The z9 EC PSP bucket: upgrade 2094DEVICE, subset 2094/ZOS (if not
already on a z9 EC or z9 BC)
v The z990 PSP bucket: upgrade 2084DEVICE, subset 2084/ZOS (if not already
on a z990 or z890)

| If your current z/OS release is V1R13, follow these steps:
| 1. Install the service in the following PSP buckets:
| v The z10 PSP bucket:
| – For the z10 EC: upgrade 2097DEVICE, subset 2097/ZOS
| – For the z10 BC: upgrade 2098DEVICE, subset 2098/ZOS
| v The z9 EC PSP bucket: upgrade 2094DEVICE, subset 2094/ZOS (if not
| already on a z9 EC or z9 BC)
| v The z990 PSP bucket: upgrade 2084DEVICE, subset 2084/ZOS (if not already
| on a z990 or z890)

| Tip for locating the correct service: To simplify finding the appropriate PSP bucket
| and identifying which PTFs listed in the PSP bucket need to be installed on your
| system, use the SMP/E REPORT MISSINGFIX command in conjunction with the
| FIXCAT type of HOLDDATA, as follows:
| 1. Acquire and RECEIVE the latest HOLDDATA onto your pre-z/OS V1R13
| systems. Use your normal service acquisition portals or download the
| HOLDDATA directly from http://service.software.ibm.com/holdata/
| 390holddata.html. Ensure you use the FULL file (last 730 days) to receive the
| FIXCAT HOLDDATA, as the other files do not contain FIXCAT HOLDDATA.
| 2. Run the SMP/E REPORT MISSINGFIX command on your pre-z/OS V1R13
| systems and specify a Fix Category (FIXCAT) value of “IBM.Device.Server.z10-
| BC-2098” or “IBM.Device.Server.z10-EC-2097”. The report will identify any
| missing coexistence and fallback PTFs for that system. For complete
| information about the REPORT MISSINGFIX command, see SMP/E Commands.
| 3. Periodically, you might want to acquire the latest HOLDDATA and rerun the
| REPORT MISSINGFIX command to find out if there are any new coexistence
| and fallback PTFs.

Migration and exploitation considerations for System z10
functions
1. C/C++ ARCH(8) and TUNE(8) options: The ARCHITECTURE option of the XL
C/C++ compiler selects the minimum level of machine architecture on which
your programs will run. Certain features provided by the compiler require a


minimum architecture level. ARCH(8) exploits instructions available on System
z10 servers. For more information, refer to the ARCHITECTURE compiler
option in z/OS XL C/C++ User's Guide. The TUNE compiler option allows you
to optimize your application for a specific machine architecture within the
constraints imposed by the ARCHITECTURE option. The TUNE level must not
be lower than the setting in the ARCHITECTURE option. For more information,
refer to the TUNE compiler option in z/OS XL C/C++ User's Guide. You must
have at least the z/OS V1R9 XL C/C++ compiler to use this function.
Exploitation restriction: Once programs exploit the ARCH(8) or TUNE(8)
option, the programs can only run on System z10 servers; otherwise, an
operation exception will occur. This is a consideration for programs that will
run on different server levels (System z9 and zSeries) during development, test,
and production, as well as during fallback or disaster recovery.

Note: ARCH(7) is the minimum level required to exploit decimal floating point
support. The resulting program objects can run on System z9 servers
(depending on the MLC installed) as well as on System z10 servers.
2. HiperDispatch: A new HIPERDISPATCH=YES|NO parameter in parmlib
member IEAOPTxx, and on the SET OPT=xx command, controls whether
HiperDispatch is enabled or disabled for the system. The value can be changed
dynamically. HiperDispatch defaults to disabled. Thus, by default, your
environment is not changed from a HiperDispatch perspective when migrating
from a pre-System z10 server to a System z10 server. Once migration has
completed, you can exploit the HiperDispatch function of the System z10
server.
Because HiperDispatch improves the performance of a System z10 system, a
new health check (SUP_HIPERDISPATCH) was added to verify that
HiperDispatch is enabled. The new health check is only added on System z10
systems. WLM goal adjustment might be required when using this function.
Review and update your WLM policies as necessary. You might need to turn
off and on HiperDispatch while adjusting your WLM goals.
3. Capacity Provisioning: An installed On/Off CoD record is a necessary
prerequisite for automated control of temporary capacity through z/OS
Capacity Provisioning. Capacity Provisioning allows you to set up rules
defining the circumstances under which additional capacity should be
provisioned in order to fulfill a specific business need. The rules are based on
criteria, such as the maximum additional capacity that may be activated for one
or more workloads, and time and workload conditions. The workload condition
can identify a specific application by use of WLM service classes. Capacity
changes can be suggested or implemented automatically, when authorized by
policy. This support provides a fast response to capacity changes and ensures
sufficient processing power will be available with the least possible delay even
if workloads fluctuate. For more information, see z/OS MVS Capacity
Provisioning User's Guide.
4. Large page support: A change to the z/Architecture on System z10 servers is
designed to allow memory to be extended to support large (1 MB) pages. Large
pages are used in addition to the existing 4 KB pages. The use of large pages is
expected to reduce memory management overhead for exploiting applications.
Large page support is primarily of benefit for long-running applications that
are memory-access intensive. Large page support is not recommended for
general use. Short-lived processes with small working sets are normally not
good candidates for large pages.
To use large pages, you need to run z/OS V1R11 (or later) with the appropriate
PTFs in a native System z10 LPAR. The support is not enabled if you are


running without the software support, are running on a prior generation of
server, or are running as a z/OS guest under z/VM. Without the large page
support, page frames are allocated at the (current) 4 KB size.
Furthermore, to exploit large page frames, a new LFAREA=xx
%|xxxxxxM|xxxxxxG parameter in parmlib member IEASYSxx must be
specified. This parameter cannot be changed dynamically.
With the installation of APAR OA32001, the calculation of the max value of the
LFAREA is changed. The LFAREA max value is now less than the old max
LFAREA value. The maximum amount of real storage that can be used to back
large pages is now (80% of the online storage available at IPL) minus 2 GB.
Make sure the LFAREA value you specify in the IEASYSxx member is less than
the new max value available in the system. You can specify LFAREA as a
percentage of all storage, or in MB or GB. Specifying a percentage for the
LFAREA parameter is now also calculated as (the percent of the online storage
available at IPL) minus 2 GB. Special care should be given to select the right
LFAREA value for the system. See z/OS MVS Initialization and Tuning Reference
and DOC APAR OA34024 for information about valid specification of the
LFAREA parameter.
Notes:
| a. You must apply the PTF for APAR OA31116 to z/OS V1R11 and z/OS
| V1R12 to use the command DISPLAY VIRTSTOR,LFAREA to find the
| allocation status of LFAREA.
b. If you do not want large frame support, do not use LFAREA= to exploit
large page frames. If LFAREA=0M is explicitly specified on a system where
large page support is not desired, message IAR021I THE LFAREA WAS
SPECIFIED BUT SUFFICIENT STORAGE IS NOT AVAILABLE is issued.
The system correctly does not provide any large frames in this case.
5. Coupling facility level 16: Service time for CF duplexing is improved, shared
IMS and MQ list notification is improved, and the structure increment size is
increased from 512 KB to 1 MB.
6. Parallel Sysplex InfiniBand (PSIFB) coupling links: InfiniBand coupling links
provide an additional option for your Parallel Sysplex cluster on System z10
and System z9. When used in the data center, InfiniBand coupling links can
replace Integrated Cluster Bus-4 (ICB-4) and InterSystem Channel-3 (ISC-3)
links.

Note: Be sure to conduct performance analyses when replacing one type of
coupling link with another.
Coupling facilities can now be separated by up to 150 meters (492 feet).
InfiniBand coupling links use fiber optic cabling containing 12 pairs (12x) of
fiber compared to one pair (1x) of fiber used with ISC-3 fiber optic cabling.
InfiniBand coupling links support double data rate (DDR) when a z10 EC is
communicating with another z10 EC. InfiniBand coupling links support single
data rate (SDR) when a z10 EC is communicating with a z9 EC dedicated CF or
z9 BC Model S07 dedicated CF. When the InfiniBand coupling link is z10
EC-to-z10 EC, the link auto-negotiates to 6 GBps. A z10 EC system
auto-negotiates to 3 Gbps when connected to a z9 EC or z9 BC dedicated
coupling facility.

Note: The InfiniBand link data rate of 6 Gbps or 3 Gbps does not represent the
performance of the link. The actual performance is dependent upon
many factors including latency through the adapters, cable lengths, and
the type of workload. With InfiniBand coupling links, while the link data


rate may be higher than that of ICB, the service times of coupling
operations are greater, and the actual throughput may be less than with
ICB links.
Refer to the Coupling Facility Configuration Options white paper for a more
specific explanation of when to continue using the current ICB technology
versus migrating to InfiniBand coupling links. The white paper is available at
http://www.ibm.com/systems/z/advantages/pso/whitepaper.html.
A new infrastructure was created to support an InfiniBand coupling link
environment. Host channel adapter optical (HCA-O) fanouts have been
introduced for System z10 and System z9 dedicated coupling facilities. The
HCA-O fanouts, with two ports per fanout, reside on the front of each
processor book. The fiber optic cables are plugged directly into the front of the
HCA-O fanouts:
v HCA2-O fanout for System z10 servers
v HCA1-O fanout for z9 EC and z9 BC Model S07 dedicated coupling facilities
There is a new physical definition to associate with a channel path identifier
with an adapter identification. Unlike channels installed in an I/O cage, which
are identified by a physical channel path identifier (PCHID) number related to
their physical location, HCA-O fanouts and ports are identified by an adapter
identification (AID) value that is determined by its physical location. The AID
must be used to assign a CHPID to the fanout in the hardware configuration
definition. The CHPID assignment is done by associating the CHPID to an AID
and port. The AID assigned to a fanout can be found in the PCHID report
provided for each new server or for upgrades on System z10 and System z9
servers.
There is also a new CHPID type CIB (coupling using InfiniBand). CHPID type
CIB is common for System z10 and System z9 servers.
On System z10 and System z9 servers, the design allows up to 16 CHPIDs to
be defined across the two ports on each HCA-O fanout. This can reduce the
number of coupling links; physical coupling links can be shared by multiple
sysplexes. For example, this capability allows for one CHPID to be directed to
one coupling facility and a second CHPID to be directed to a separate coupling
facility on the same target server, using the same port. An increased number of
CHPIDs per physical link can help to facilitate consolidation of ISC-3 links onto
InfiniBand coupling links.
InfiniBand coupling links can also be used to exchange timekeeping messages
for Server Time Protocol (STP).
You can choose the coupling links that best suit your business needs: IC, ICB,
IFB, or ISC-3.

Migrate to a System z9 server
Description: The IBM System z9 servers (z9 EC [formerly z9-109] and z9 BC) are
follow-ons to the IBM eServer zSeries servers (z990, z890, z900, and z800). They
continue the evolution of the mainframe, building on the structure introduced with
the z990 in support of z/Architecture, reliability, availability, scalability, and
clustering. System z9 servers expand upon a key attribute of the platform,
availability, to help ensure that you have a resilient infrastructure designed to
satisfy the requirements of on demand business. With the increased performance
and total system capacity possible for System z9 servers, you have an opportunity
to continue to consolidate diverse applications on a single platform.

The specific System z9 functions exploited by z/OS V1R13, V1R12, and V1R11 are:


1. Separate LPAR management of processor units (PUs)
2. 63.75K subchannel support
3. OSA-Express2 Gigabit Ethernet (LX and SX)
4. OSA-Express2 1000BASE-T Ethernet
5. OSA-Express2 10 Gigabit Ethernet (LR)
6. OSA/SF IP and MAC addressing
7. FICON Express4 (4KM LX, 10KM LX, and SX)
8. CP Assist for Cryptographic Functions (CPACF) clear key
9. Crypto Express2 as a coprocessor (secure key)
10. Request node identification data (RNID) for native FICON
11. Channel Data Link Control (CDLC) support
12. Up to 60 LPARs on z9 EC and 30 LPARs on z9 BC
13. Crypto Express2 as an accelerator
14. CPACF enhancements (AES, SHA-256, and PRNG)
15. Remote Keyload for ATMs and POSs, and ISO 16609 CBC Mode TDES for
MAC
16. Modified Indirect Data Address Word (MIDAW) support
17. zIIP support
18. Multiple subchannel sets
19. HiperSockets support of IPv6
20. Virtual local area network (VLAN) management enhancements
21. FICON link incident reporting
22. XLC C/C++ (enable ARCH(7) and TUNE(7) compiler options)
23. Up to 512 GB real storage on z9 EC (GB equals 1 073 741 824 bytes)

When change was introduced: The first System z9 server, the z9 EC,
shipped in September 2005.
Timing: Anytime.
Is the migration action required? Yes, if you want to run z/OS on a System z9
server.
Target system hardware requirements: A System z9 server.
Other system (coexistence or fallback) See the appropriate PSP buckets for required
requirements: PTFs for specific functions, as described in
“Steps to take”.
Restrictions: None.
check:

Steps to take: Follow the recommendations and considerations, adhere to the
restrictions, and perform the tasks described in the topics below.


As you plan your migration to a System z9 server, consider the following:
1. Relatively few migration actions are new when coming from a z990 or z890.
Migration to a System z9 server has, as its basis, a migration to a z990 or z890.
This means that if you are migrating to a System z9 server from a z990 or z890
(and have performed the migration actions associated with the z990 or z890),
you have fewer migration actions than if you were migrating from a server
prior to the z990 or z890 and have not yet performed the migration actions
associated with the z990 and z890. There are, in fact, very few new migration
actions to perform on z/OS for a System z9 server if you have already
migrated to a z990 or z890. It is important to note that you can migrate directly
to a System z9 server without installing the intermediate (prior to z990 and
z890) servers, but you still need to ensure that any migration considerations are
satisfied for the servers that you “skipped”. To read about z990 and z890
migration actions, see “Migrate to a z990 or z890 server” on page 79.
2. Support is delivered by service and FMIDs. The delta (from a z990 or z890)
support for a System z9 server, excluding cryptographic support, is delivered
by service (PTFs), unlike the support that was required for the z990 and z890.
The z990 and z890 support was delivered with service and FMIDs (web
deliverables and features). The cryptographic support for the System z9 servers
continues to be FMIDs, many of which are still available in web deliverables.
Different web deliverables, providing different levels of support, are available
for different releases of z/OS.
sizes might change. System z9 servers initially ship with CFCC Level 14. If, as
part of your migration to a System z9 server, you change CFCC levels (either
by placing a coupling facility on the System z9 server or by moving the
coupling facility to a z990 or z890 at a later CFCC level), you might have larger
structure sizes than you did previously. If your CFCC levels are identical,
server to a System z9 server.
4. Update CFRM policies. Coupling facilities are identified in the CFRM policy

Restrictions
Restrictions associated with the System z9 server are:
1. z/OS as a guest of z/VM: Modified indirect data address words (MIDAWs) and
subchannel sets are not supported by z/OS when z/OS runs as a guest under
z/VM on a System z9 server.
2. System z9 server in a sysplex:


v Integrated Cluster Bus-2 (ICB-2) and InterSystem Channel-3 (ISC-3)
compatibility mode links are not supported on System z9 servers. If you
have ICB-2 or ISC-3 compatibility mode links defined, convert them to a
supported link technology.
v If you have a G5 or G6 coupling facility image, you cannot connect that
coupling facility to any System z9 z/OS senders (or, for duplexing, to a
System z9 coupling facility). Having a G5 or G6 coupling facility, therefore,
introduces coexistence issues if any System z9 z/OS images, or System z9
coupling facilities, participating in that sysplex.
3. HMC: The hardware management console (HMC) is for the exclusive use of the
HMC application. Customer applications cannot reside on the HMC. The
ESCON Directory and Sysplex Timer applications cannot reside on the HMC.
TCP/IP is the only supported communication protocol. The HMC supports
System z9 servers. It can also be used to support z990, z890, z900, z800, G5, G6,
and Multiprise 3000 servers. They must be upgraded to a new AROM level.
4. Token Ring:
v Token Ring is not available as a feature on the System z9 HMC. Current
HMCs with Token Ring may be carried forward to a System z9 server during
an upgrade from a z990 or z900.
v Token Ring is not available as a feature on the System z9 Support Element
(SE) or Trusted Key Entry (TKE) workstation. Token Ring is not offered as a
feature on System z9 servers and cannot be carried forward to a System z9
server during an upgrade from a z990 or z900.
v The OSA-Express Token Ring feature is not supported on System z9 servers.
Token Ring is not offered as a feature on System z9 servers and cannot be
carried forward to a System z9 server during an upgrade from a z990 or
z900.
5. C/C++ ARCH(7) and TUNE(7) options: The ARCHITECTURE C/C++ compiler
option selects the minimum level of machine architecture on which your
program will run. Certain features provided by the compiler require a
minimum architecture level. ARCH(7) exploits instructions available on System
z9 servers. For more information, refer to the ARCHITECTURE compiler option
in z/OS XL C/C++ User's Guide.
The TUNE compiler option allows you to optimize your application for a
specific machine architecture within the constraints imposed by the
ARCHITECTURE option. The TUNE level must not be lower than the setting in
the ARCHITECTURE option. For more information, refer to the TUNE compiler
option in z/OS XL C/C++ User's Guide.
Exploitation restriction: Once programs exploit the ARCH(7) or TUNE(7)
option, those programs can only run on System z9 servers, or an operation
exception will occur. This is a consideration for programs that will run on
different server levels (System z9 and zSeries) during development, test, and
production, as well as during fallback or disaster recovery.

Actions you can take before you order a System z9 server
You can perform the following migration actions before you order or install your
System z9 server:
1. Review the sysplex configuration in which the System z9 server will
participate. In particular, if you have any existing G5 or G6 coupling facilities
in the sysplex, move those coupling facilities to later servers (such as z990 or
z890). This action is necessitated by the restriction that System z9 z/OS images
in a sysplex cannot use G5 or G6 coupling facilities, nor can G5 or G6 coupling
facilities duplex with a System z9 coupling facility.


2. Review your current link technology. If you have any ICB-2 or ISC-3
compatibility mode links, convert them to a supported link technology.
3. Review coexistence requirements. Because the z990 and z890 support is the
basis for the System z9 server support, the coexistence requirements for the
z990 and z890 also apply to the System z9 server. For instance, ICKDSF R17
must be installed on all z/OS and z/VM images that will share DASD with the
z990 or z890 (and therefore, with System z9 servers). Review the coexistence
requirements that were introduced for the z990, if you have not already done
so, and take any necessary actions. You can find the z990 coexistence
requirements in “Migrate to a z990 or z890 server” on page 79.
4. Install the necessary z/OS service, as indicated in PSP buckets. The
appropriate PSP buckets are listed in “Recommended migration steps” on page
78 and are dependent on the z/OS release you will run on the System z9 server
and on the hardware support you already have installed. If you reviewed the
PSP buckets a long time ago, there might have been additions since then, so
ensure that any newly identified z/OS service has been installed. To assist you
in determining whether you have the recommended service installed on your
system, which is identified in these PSP buckets, you can use the SMP/E
REPORT MISSINGFIX command with a FIXCAT value of
“IBM.Device.Server.z9-EC-2094” or “IBM.Device.Server.z9-BC-2096”, the
Enhanced PSP Tool (http://www14.software.ibm.com/webapp/set2/psp/
srchBroker), or ServiceLink's PSP Service Extraction tool.
System z9 functions are:
v IBM.Device.Server.z9-BC-2096.DecimalFloatingPoint
v IBM.Device.Server.z9-BC-2096.MIDAW
v IBM.Device.Server.z9-BC-2096.ParallelSysplexInfiniBandCoupling
v IBM.Device.Server.z9-BC-2096.ServerTimeProtocol
v IBM.Device.Server.z9-BC-2096.zAAP
v IBM.Device.Server.z9-BC-2096.zIIP
v IBM.Device.Server.z9-EC-2094.DecimalFloatingPoint
v IBM.Device.Server.z9-EC-2094.MIDAW
v IBM.Device.Server.z9-EC-2094.ParallelSysplexInfiniBandCoupling
v IBM.Device.Server.z9-EC-2094.ServerTimeProtocol
v IBM.Device.Server.z9-EC-2094.zAAP
v IBM.Device.Server.z9-EC-2094.zIIP
5. Run CFSizer. If you are moving your coupling facilities and the coupling
facility structures will be on later CFCC levels than they were previously, run
the Coupling Facility Structure Sizer (CFSizer) tool to find out if you have to
increase coupling facility structure sizes. System z9 servers initially ship with
CFCC Level 14. Prepare to make the necessary changes as indicated by the tool.
You can find the CFSizer tool at http://www.ibm.com/systems/support/z/
cfsizer/.
6. Estimate the amount of HSA needed. If you intend to add more devices,
exploit subchannels, or use more LPARs on the System z9 server than you did
on your previous server, you should estimate the amount of hardware system
area (HSA) that will be necessary on the System z9 server. Use the HSA
Estimator tool, which is available on Resource Link (http://www.ibm.com/
servers/resourcelink).


7. Decide on the steps you will take for your migration to a System z9 server.
As a guide, see “Recommended migration steps.” Be aware of the following:
v You should review the cryptographic support you currently have installed
versus the support required on the System z9 server. Several cryptographic
support web deliverables have been made available for various z/OS
releases. The web deliverables listed in “Recommended migration steps” are
the minimum web deliverable level for the function specified. When a
subsequent cryptographic web deliverable is available for a particular z/OS
level, the previous one is withdrawn. The newer cryptographic web
deliverable, however, includes the previous function (when applicable) for
that particular z/OS level. Note that you can use the newer cryptographic
web deliverables on servers prior to the System z9 server (that is, on zSeries
servers).
The level of cryptographic support integrated in z/OS V1R11 is ICSF FMID
HCR7751. ICSF FMID HCR7770 (integrated in z/OS V1R10) available as a
web deliverable for cryptographic support for z/OS V1R9, z/OS V1R10, and
z/OS V1R11.
v You can migrate to z/OS V1R13 before or after you migrate to a System z9
server.

Actions you can take after you order a System z9 server
After you order but before you install your System z9 server, do the following:
1. Use the CHPID Mapping Tool. As you might have done with your z990 or
z890, use the CHPID Mapping Tool to map logical CHPIDs to physical
channels (PCHIDs) and create input to HCD/IOCP for your System z9 server.
The tool is a workstation-based Java application available from the Resource
Link web site (http://www.ibm.com/servers/resourcelink). For more
information about this tool, refer to the web site.

current server to a System z9 server. The steps are based on the assumption that

Your migration steps are:
v The z9 EC PSP bucket: upgrade 2094DEVICE, subset 2094/ZOS
v The z9 BC PSP bucket: upgrade 2096DEVICE, subset 2096/ZOS
v The z990 PSP bucket: upgrade 2084DEVICE, subset 2084/ZOS
2. Upgrade your hardware to a System z9 server. If you are migrating from a z900
or z800 server, see “Migrate to a z990 or z890 server” on page 79 for z990 and
z890 migration considerations that you must also satisfy.

Tip for locating the correct service: To simplify finding the appropriate PSP bucket
and identifying which PTFs listed in the PSP bucket need to be installed on your
system, use the SMP/E REPORT MISSINGFIX command in conjunction with the
FIXCAT type of HOLDDATA as follows:
1. Acquire and RECEIVE the latest HOLDDATA onto your pre-z/OS V1R13
systems. Use your normal service acquisition portals or download the


390holddata.html. Ensure you use the FULL file (last 730 days) to receive the
FIXCAT HOLDDATA, as the other files do not contain FIXCAT HOLDDATA.
2. Run the SMP/E REPORT MISSINGFIX command on your pre-z/OS V1R13
systems and specify a Fix Category (FIXCAT) value of “IBM.Device.Server.z9-
BC-2096 ” or “IBM.Device.Server.z9-EC-2094 ”. The report will identify any
missing coexistence and fallback PTFs for that system. For complete
information about the REPORT MISSINGFIX command, see SMP/E Commands.
3. Periodically, you might want to acquire the latest HOLDDATA and rerun the
REPORT MISSINGFIX command to find out if there are any new coexistence
and fallback PTFs.

Migrate to a z990 or z890 server
Description: The IBM eServer zSeries 990 (z990) and zSeries 890 (z890) represent
the second generation of zSeries servers. The z990 and z890 servers provide more
processing power, memory, and I/O capacity than the first generation of zSeries
servers (z900 and z800). By migrating to z/OS V1R13 on a z990 or z890 server, you
can take advantage of these improvements.

When change was The first z990 server shipped in June 2003. The first z890 server
introduced: shipped in May 2004.
Applies to migration z/OS V1R12 and z/OS V1R11.
from:
Timing: Anytime.
Is the migration Yes, if you want to run z/OS on a z990 or z890 server. Also, be
action required? aware that if any non-z990, non-z890 systems coexist with z990 or
z890 systems, coexistence requirements affect the non-z990,
non-z890 systems.
Target system A z990 or z890 server and, for cryptography, the following
hardware hardware features: PCI X Cryptographic Coprocessor (PCIXCC), CP
requirements: Assist for Cryptographic Functions (CPACF) DES/TDES, and PCI
Cryptographic Accelerator (PCICA).
Target system None.
software
requirements:
Other system For shared DASD requirements, see item 4 on page 83. For CFCC
(coexistence or coexistence requirements, see item 6 on page 83.
fallback)
requirements:
Restrictions: v Only LPAR mode (not basic mode) is supported on a z990 or
z890 server.
v Also, see the note on page 82.
System impacts: A power-on reset is required when adding or removing a Logical
Channel Subsystem (LCSS), changing the maximum number of
devices for an LCSS, adding or deleting LPARs, and adding or
changing a resource in an LCSS other than LCSS 0.
Related IBM Health None.
Checker for z/OS
check:

Steps to take: Follow the requirements and recommendations below. Included is
information about required HMC levels, configuring a z990 or z890 server,

installing software and microcode for coexistence with a z990 or z890 server,
cryptographic considerations, and operational considerations.

First, some general considerations and reminders:
v z/OS V1R5 and later contains z990 exploitation support.
v Minimizing the number of changes you make concurrently makes it easier to
pinpoint problems. Therefore, avoid upgrading your software release level at the
same time that you upgrade your hardware.
v Having members of the sysplex at the same software level, except for brief
migration periods, is good software management policy.

Actions you can take before you install a z990 or z890 server
1. Upgrade HMC microcode. Upgrade the hardware management console (HMC)
driver level to 1.8.0 or later. IBM recommends migrating z900 and z800 HMCs
to HMC driver level 1.8.0 or later before z990 or z890 installation.
2. Review PSP buckets. You should review and install all the applicable service
in the 2084DEVICE (for z990) or 2086DEVICE (for z890) PSP bucket. To assist
you in determining whether you have the recommended service installed on
your system, which is identified in these PSP buckets, you can use the SMP/E
REPORT MISSINGFIX command with a FIXCAT value of
“IBM.Device.Server.z990-2084 ” or “IBM.Device.Server.z890-2086”, the Enhanced
PSP Tool (http://www14.software.ibm.com/webapp/set2/psp/srchBroker), or
ServiceLink's PSP Service Extraction tool.
server functions are:
v IBM.Device.Server.z990-2084.zAAP
v IBM.Device.Server.z890-2086.zAAP
3. Define the z990 or z890 server. Use HCD to define the z990 or z890 server.
When installing a new (“net add”) z990 or z890 server, you must define the
operating system and processor. You can use the copy or migrate functions of
HCD to model these definitions after an existing processor.
When using a miscellaneous equipment specification (MES) package to upgrade
a z900 server to a z990 server, or to upgrade a z800 server to a z890 server, or
when replacing one or more z900 servers (or z800 servers) with a z990 or z890
server (a “box swap” or “push/pull”), you must copy or migrate the existing
definitions to a z990 or z890 Logical Channel Subsystem (LCSS). IBM
recommends the following:
v Ensure that the production input/output definition file (IODF) that will be
used to migrate existing definitions contains all the definitions for all the
items to be migrated (operating system configurations, ESCON and FICON
switches, logical partitions, channels, control units, devices, and coupling
facility processors). Using one source IODF means that there will be no
conflict to be resolved during the migration process with any control unit or
device for address or number definition conflict, address or number range
conflict, or type definition conflict.
v If you are consolidating two processors into a z990 or z890 server, copy or
migrate one processor into LCSS 0 and the other into LCSS 1.
When making the z990 or z890 hardware definitions, you must:


v Define the z990 or z890 processor. Only LPAR mode is allowed. You also need
to define the number of LCSSs that you intend to use. Note that increasing
or decreasing the number of LCSSs will require a power-on reset of a new
input/output configuration data set (IOCDS). IBM recommends that when
you define a z990 or z890 server, you should initially define the number of
LCSSs you expect to use — up to two LCSSs on a z890 or up to four LCSSs
on a z990.
v Define the channel subsystems. For each channel subsystem, specify an LCSS
ID, a description, and the maximum number of devices:
Notes:
a. There is no hardware system area (HSA) expansion support on the z990
or z890 support element (SE). The maximum number of devices, defined
for each LCSS, replaces the HSA expansion percentages in the central
processor complex (CPC) activation profile on the support element.
b. If you change the maximum number of devices in an LCSS, you cannot
do an ACTIVATE; you must do a power-on reset. IBM recommends that
when you define a z990 or z890 server, you initially define the maximum
number of devices that you expect to use in the future.
c. Because of the increase in the number of LPARs and LCSSs, be sure that
the value specified on the MAXDEV keyword is large enough. (Increasing
MAXDEV requires a power-on reset). The HCD default for maximum
number of devices is 63K. This could result in a large amount of HSA
storage being wasted.
v Define logical partitions. The partition names may not be duplicated across
LCSSs. On servers other than z990 and z890 servers, partition numbers are
the same as Multiple Image Facility (MIF) IDs. On z990 and z890 servers,
partition numbers are assigned at power-on reset based on the IOCDS. MIF
IDs are still specified using HCD/IOCP. On z990 and z890 servers, the
partition number can be in the range 1–30 (X'1–1E') and the MIF ID must be
in the range 1–15 (X'1–F'). The partition number will be unique across all
LCSSs. The MIF ID must be unique within each LCSS, but can be duplicated
across LCSSs. Note that partition numbers are not related to LPAR IDs,
which are specified in the HMC image profile.
Notes:
a. IBM recommends when you define a z990 or z890 server, you should
initially define the number of logical partitions that you expect to use.
If you plan to exploit more than 15 LPARs, then define the number of
LCSSs (two or more) that you expect to use. For exploiting more than 15
LPARs and more than one LCSS, ensure that you have the correct
hardware driver level. You only need to define the LCSS and LPARs (and
specify the maximum devices for the LCSS). The LPAR can be defined
with no I/O resources. I/O configuration definitions can be dynamically
added later to a logical partition (nondisruptively). The newly defined
I/O configuration definition change can be dynamically activated. Note
that any z800 or z900 server used as a coupling facility image in this
environment needs to have the CFCC z990 Compatibility MCL installed
(see item 6 on page 83 for details).
b. There is no correlation between LPAR ID and the LCSS under which an
LPAR runs. There can be LPARs in LCSS 0 with LPAR IDs greater than
15, and there can be LPARs in LCSS 1 (and LCSS 2 and LCSS 3) with
LPAR IDs less than or equal to 15.
v Define channel paths. The processor name is qualified by the LCSS ID.
Channel path IDs (CHPIDs) only need to be unique within an LCSS.


Notes:
a. There are no default CHPIDs on the machine when configured or
shipped. Physical channel IDs (PCHIDs) must be defined.
b. Cryptography functions do not require CHPIDs.
c. Spanned channels access and candidate lists are by LCSS and partition.
d. The internal queued direct (IQD) CHPID on the VTAM® start option
IQDCHPID=xx must be defined as a spanned CHPID if communication
with systems in other LCSSs is desired.
v Recommended: Use the CHPID Mapping Tool to map logical CHPIDs to
physical channels (PCHIDs) and create input to HCD/IOCP. The tool is a
workstation-based Java application available from the IBM Resource Link
web site: http://www.ibm.com/servers/resourcelink. It updates the z990 or
z890 IOCP input file with the “PCHID” keyword and can generate reports to
help with cabling. To obtain and use the tool, do the following:
– If this is an initial z990 or z890 order, download a machine order file
(CFReport or manufacturing order file) from Resource Link to a
workstation.
– Create a validated work IODF (an IODF that is valid except that it is
missing PCHIDs) using HCD option 2.12 (Build Validated Work I/O
Definition File).
– Create an IOCP deck without PCHIDs or with some PCHIDs missing
using HCD option 2.3 (Build IOCP Input Deck).
– Download the IOCP file (which can include PCHID keywords) to the
workstation.
– Download the tool.
– Run the tool selecting the 2084 hardware configuration file (.hwc or .cfr)
and import the IOCP statements.
– Upload the updated IOCP deck with the PCHIDs assigned using HCD
option 5.1 (Migrate IOCP/OS Data). Choose migrate option 3 (PCHIDS).
– Build a production IODF.
– Write the IOCDS to the z990 or z890 support element using HCD or
stand-alone IOCP.
v Define control units. A control unit is defined once in the IODF but the
CHPID.link combinations for a z990 or z890 processor are defined for each
LCSS because each LCSS has its own set of CHPIDs.
v Define devices. The channel subsystem data (for example, the preferred path
and candidate lists) must be specified for each LCSS (and may be different
for each LCSS).

Note: The following features and functions are not supported by the z990 and
z890 servers:
v Parallel channels. Use the IBM ESCON Converter or the Optica
Technologies 34600.
v OSA-2 adapters. Use the equivalent OSA-Express adapter. (For FDDI,
use a multiprotocol switch or router with the appropriate network
interface.)
v OSA-Express ATM adapters. Use a multiprotocol switch or router with
the appropriate network interface, for example, 1000BASE-T or Gigabit
Ethernet.
v 4-Port ESCON cards. Replace these with new 16-Port ESCON cards
during upgrade. The 16-Port ESCON card has a MTRJ-45 connector.


v FICON cards (pre-FICON Express). Replace these with FICON Express
during upgrade. FICON Express has a different connector.
v PCICC. This feature is replaced with PCIXCC for most of the
commonly used cryptography functions.
v Activation of an over-defined channel configuration.
v Systems Network Architecture (SNA) Operations Management
commands and SNA based APIs are not supported on z990 and z890
servers. These commands were previously used by the System
Automation for OS/390® product as well as NetView®. It is
recommend that you now use the Simple Network Management
Protocol (SNMP) application programming interfaces (APIs) for your
automation needs.
4. Install coexistence software. All images that share DASD with any z/OS,
z/VM, or z/VSE® operating system images running on a z990 or z890 server
need to have ICKDSF R17 installed. IBM recommends that ICKDSF R17 be
deployed to all other systems that share DASD, before any z990 or z890 server
is brought into use in the sysplex.
5. Plan for coupling facility images. Coupling facility images on G2, G3, G4, or
equivalent processors cannot be connected to operating system images on a
z990 or z890 server and therefore any structures in these coupling facility
images also need to be moved to a coupling facility that can connect to this
environment (G5, G6, z800, z900, z990, or z890 server).
Only coupling facility images on G5, G6, z800, and z900 servers are supported.
While z990 and z890 servers do not offer a stand-alone coupling facility option,
you could have a coupling facility image as the only image in the z990 or z890
server, making it look effectively like a stand-alone coupling facility, or you
could have an ICF image along with other partitions running z/OS, or other
workloads, on your z990 or z890 server (possibly using coupling facility
duplexing). Alternatively, you can continue to use your existing z900 or z800
coupling facilities (2064-100) and G5/G6 coupling facilities. However,
workloads such as data sharing, global resource serialization, and DB2 (users of
locking structures) are likely to require newer technology for performance
reasons. If you have such workloads, you should plan to upgrade G5 coupling
facilities (9672-R06) to z900 coupling facilities, or move your coupling facilities
to z990s or z890s. IBM does not recommend using G5 coupling facilities in a
Parallel Sysplex cluster with z990 or z890 servers for these workloads. You
should only use them as a temporary migration step.
6. Install z990 CFCC coexistence microcode. If you intend to have an operating
system image or a coupling facility image on a z990 or z890 server and have
more than 15 LPARs defined (even if 15 or fewer are activated), you need to
have CFCC compatibility code installed on:
v Any coupling facility image (stand-alone or ICF) on a G5, G6, z800, or z900
server that will connect to an operating system image on the z990 or z890
server.
v Any coupling facility image (stand-alone or ICF) that will be duplexed with
a z990 or z890 coupling facility image.
IBM recommends that the CFCC z990 compatibility MCL be rolled out on all
coupling facility images that will reside on a G5, G6, z800, or z900 server that
will connect to an operating system image on a z990 or z890 server or be
duplexed with a coupling facility image on a z990 or z890 server, before any
z990 or z890 server is brought into use in the sysplex.


Notes:
a. The CFCC z990 compatibility code is provided with the GA level of CFCC
Level 11 (for G5 and G6 servers) and as an MCL on CFCC Level 12 (for
z900 and z800 servers). The CFLEVEL 12 MCL is disruptive, so IBM
recommends that you coordinate the installation of this MCL with other
disruptive MCLs, if possible.
b. If you are MES-upgrading to a z990 or z890 server, or replacing (“box
swap”) an existing server, then the “old” server does not require the CFCC
compatibility MCL. However, any remaining G5, G6, z800, or z900 servers
that will be connecting to the z990 or z890 server will require the MCL
upgrade (if more than 15 LPARs will be defined).
c. If 15 or fewer LPARs will be defined on the z990 or z890 server, then the
CFCC compatibility code is not required on z900 and z800 servers. If at any
time in the future you define more than 15 LPARs, then the CFCC
compatibility code will be required at that time.
d. If you have a coupling facility image (stand-alone or ICF) on a G5 or G6
server that will either connect to an operating system image on a z990 or
z890 server or be duplexed with a z990 or z890 coupling facility image, then
the CFCC level of the G5 or G6 coupling facility image must be CFCC Level
11 (or later).
e. If you have a coupling facility image (stand-alone or ICF) on a z900 or z800
server that will either connect to an operating system image on a z990 or
z890 server or be duplexed with a z990 or z890 coupling facility image, then
the CFCC level of the z900 or z800 coupling facility image must be CFCC
Level 12.
Table 7. Summary of z990 CFCC coexistence support
15 or fewer LPARs More than 15 LPARs
defined on a z990 or defined on a z990 or
Server CFCC level z890 server z890 server
Pre-G5, G5, or G6 CFCC Level 9 (or Not supported Not supported
below)
G5 or G6 CFCC Level 11 Supported Supported
z800 or z900 CFCC Level 9 or 10 Not supported Not supported
z800 or z900 CFCC Level 12 Supported Not supported
z800 or z900 CFCC Level 12 with Supported Supported
CFCC compatibility
code, or CFCC Level
13

7. Install cryptographic software, if necessary. If you use cryptographic services,
ensure that you have the level of cryptographic support that you require on
your z/OS system. For a cross reference of ICSF FMIDs, web deliverables, and
z/OS releases, see http://www.ibm.com/support/techdocs/atsmastr.nsf/
WebIndex/TD103782.

Note: The following infrequently used cryptographic functions that are in z900
and z800 servers are not in z990 and z890 servers:
v Digital Signature Algorithm support
v ANSI x9.17 services and key types
v Cipher_Text Translate (CSNBCTT)
v German Bank Pool - Pin Offset
v CSFUDK (replaced with CSNBDKG)


v Commercial Data Masking Facility (CDMF) – 40-bit Encryption

Actions you can take when you order a z990 or z890 server
Determine future target I/O requirements before placing your order.

If required, use “Plan Ahead” for I/O cages and associated base infrastructure
(adding I/O cages later is disruptive).

PCIXCC installation will be nondisruptive. Use “Plan Ahead” for the PCIXCC to
ensure that slots are reserved in advance. This also balances the configuration
when PCIXCC is available and installed.

Once I/O infrastructure is planned ahead, model upgrades or adding I/O cards
can be nondisruptive, and Self-Timed Interconnect buses (STIs) are hot-pluggable.

Ensure that proper hardware features are ordered. For example, hardware features
for cryptography are:
v PCIXCC (feature code 0868), if required
v CP Assist for Cryptographic Functions (CPACF) DES/TDES (feature code 3863)
v PCICA (feature code 0862), if required

Ensure that Driver 55 or later is ordered if you want support for the following
features and functions on the z990 server:
v Four Logical Channel Subsystems
v Spanned external channels
v PCIX Crypto Adapter Integrated Console Controller
v OSA Integrated Console Control (OSA-ICC)
v Extended Translation Facility
v System z Application Assist Processor (zAAP) (requires Driver 55K or later)

Actions you can take after you install z/OS
1. Update CFRM policies.
If a coupling facility image resides on a G5, G6, z800, or z900 server, then the
partition number currently specified in the CFRM policy is the same as the
partition number defined in HCD. No change is required for the partition
number.
If a coupling facility image resides on a z990 or z890 server, then the partition
number specified in the CFRM policy is the logical partition identifier specified
in the HMC Image Profile (Partition ID). The CFRM policy utility was changed
to accept a two-digit hexadecimal PARTITION value for an LPAR ID greater
than 15.
Update CFRM policies. Coupling facilities are identified in the CFRM policy
2. Update automation for new and changed messages.
The following messages are changed to display two-digit LPAR IDs: IOS431I,
IXC101I, IXC105I, IXC357I, IXC360I, IXC361I, IXC362I, IXC500I, IXC505I,
IXC506I, IXC507I, IXC515I, IXC517I, IXC518I, IXC519E, IXC551I, IXC579I,
IXL008I, IXL010E, IXL141I, IXL150I, IXL157I, IXL158I, IXL160E, and IOX50xI.
PCHID information is now displayed, when appropriate.


The following messages are associated with changed command output:
v IEE174I – display output for D M=CPU command
v IOS506I display output for D IOS,CONFIG(HSA) and D IOS,CONFIG(ALL)
command output
3. Notify those affected by changed command output. Command syntax is not
changed for z990 and z890 support but rather the display output for the
following commands is changed:
v The D M=CPU command can now display a two-hexadecimal-digit LPAR ID
from partitions running on a z990 or z890 server, which supports two-digit
LPAR IDs. (The message number is IEE174I.) The logical CPU address no
longer appears in the CPU ID. CSS ID, MIF ID, and the like are now
formatted.
v The D IOS,CONFIG(HSA) command will display zeros for the unshared
subchannel and logical CUs lines in the message. (The message number is
IOS506I.) On z/OS V1R5 and later, subchannel and logical CUs will be
displayed by LCSS.
v The D M=CHP command is changed to add PCHID to the display.
v The D CF command is changed to support two-hexadecimal-digit LPAR IDs
and PCHIDs.
v The D XCF command is changed to support two-hexadecimal-digit LPAR
IDs.
4. Modify programs affected by changed SMF records. If you currently process
SMF records 70, 74, 79, and 89, you will need to review changes and modify
any user-written programs if they are affected. The changes are:
v SMF Record 70 Subtype 1 (CPU and PR/SM Activity) is now split into
multiple records if the number of LPARs and CPs requires more than 32K.
Each piece is self-containing, that is, records can be processed without
reassembling the broken pieces.
v SMF Record 74 Subtype 1 (Device Activity) is changed because of I/O
architecture.
v SMF Record 79 Subtype 9 (Device Activity) is changed because of I/O
architecture.
v SMF Record 89 (product usage data) is changed to support 4-bit and 8-bit
LPAR identifiers and more than 15 LPARs.
v SMF Record 99 Subtype 8 (WLM LPAR Management – CPU Period Table
Entry) is changed to add the CSS ID.
v SMF Record 99 Subtype 9 (I/O Subsystem Info – Channel Path Data Entry) is
changed to add the CSS ID.
5. Update parmlib members. Review parmlib changes and update members as
appropriate:
v If you use cryptography, then you should be aware that ICSF provides IPCS
support. A parmlib member, CSFIPCSP, will be installed into the library
specified on the SMP/E PARMLIB DDDEF statement (and delivered in
SYS1.IBM.PARMLIB in ServerPac). Ensure that this library is included in
your IPCS concatenation. If you copy members from that library to another
library, you have to copy CSFIPCSP.
v There is no change to member SMFPRMxx. However, there is a change in the
description of the serial number in the SID parameter when a z990 or z890 is
involved; the first two digits are the LPAR ID instead of the logical CPU
address and LPAR ID.


6. Modify programs affected by macro changes. As with any software upgrade,
you need to review any macro changes and update any user programs if they
are affected.

Actions you might need to take once you are using a z990 or
z890 server
ACTIVATE actions:
v You can perform a software ACTIVATE (the number of defined LCSSs is
irrelevant).
v You can only perform a hardware ACTIVATE if the changed or new resources
are restricted to LCSS 0.
v A power-on reset is required when adding or removing an LCSS, changing the
maximum number of devices for an LCSS, adding or deleting LPARs, and
adding or changing a resource in an LCSS other than LCSS 0.
v You can perform full hardware or software ACTIVATE (regardless of the LCSS
where the new or changed resources are defined).

Be aware that removing (restoring) the CFCC compatibility code from a G5, G6,
z800, or z900 server will reintroduce sysplex coexistence considerations. That is,
removing the CFCC compatibility support from a coupling facility image elsewhere
in the sysplex will prohibit that coupling facility from participating in a sysplex
with operating system or coupling facility images on a z990 or z890 with more
than 15 LPARs defined on it (regardless of the number of LPARs that are
activated).


Chapter 4. Sysplex migration actions
Sysplex actions related to hardware upgrades . . . 89 Sysplex actions to perform after the first IPL of
Sysplex actions to perform before installing z/OS z/OS V1R13 . . . . . . . . . . . . . . 90
V1R13 . . . . . . . . . . . . . . . . 89
Sysplex actions to perform before the first IPL of
z/OS V1R13 . . . . . . . . . . . . . . 89

This topic summarizes actions for you to take if you are migrating systems that are
members of a base sysplex or Parallel Sysplex configuration.

Sysplex actions related to hardware upgrades
Title of migration action Page or topic
Update your CFRM policy with coupling facility structure size 41
changes
Migrate from a Sysplex Timer to STP 45
Migrate from ICB-4 to Infiniband coupling links 46
Migrate to an IBM zEnterprise server 47
Migrate to a System z10 server 62
Migrate to a System z9 server 73
Migrate to a z990 or z890 server 79

Sysplex actions to perform before installing z/OS V1R13
Page or
Element or feature Title of migration action topic
Multiple Install coexistence and fallback PTFs 8
DFSMSdfp DFSMSdfp: Back up SMS control data sets 177
| Distributed File zFS: Ensure sysplex=filesys is available on all zFS 219
| Service R11 and R12 systems in a shared file system
| environment

Sysplex actions to perform before the first IPL of z/OS V1R13
None.

Page or
| BCP Change value for ARM restart processing 103
| BCP Modify automation that references output from D 104
| XCF,SYSPLEX console commands
| BCP Accommodate OPERLOG EMCS console name 106
| change
| BCP Update the SFM policy to control automatic 120
| termination of impaired critical members


Page or
| JES3 Avoid redundant *S main,FLUSH command in 246
| response to XCF messages

Sysplex actions to perform after the first IPL of z/OS V1R13
None.

Page or
SDSF Update configuration for sysplex support 266


Chapter 5. BCP migration actions
BCP actions to perform before installing z/OS Update automation that handles messages
V1R13 . . . . . . . . . . . . . . . . 91 IEF374I and IEF376I . . . . . . . . . . 112
Evaluate your stand-alone dump data set Use the new 16M default buffer size for trace
allocations and your IPCS processing of them . . 92 options with the CTIGRSxx member. . . . . 113
| Consider exploiting WARNUND for new Specify valid user exits for the IFASMFDL and
| IEASYSxx statements . . . . . . . . . . 93 IFASMFDP programs . . . . . . . . . . 113
| Define DASD storage for Predictive Failure Make IFASMFDL and IFASMFDP run in an
| Analysis . . . . . . . . . . . . . . 94 authorized environment . . . . . . . . . 115
| Migrate from SNMP to z/OS BCPii for Provide the migrate or new parameter when
| communication to the HMC or SE . . . . . . 95 running the PFA install script . . . . . . . 116
| Verify that at least one blank follows all major Change default locations for LCCA or PCCA
| keyword statements . . . . . . . . . . 96 control blocks to retain 24-bit virtual storage
| Examine source for dynamic allocation callers location . . . . . . . . . . . . . . 117
| that set the S99DSABA and S99ACUCB flags . . 97 Remove reference to Unicode Services pre-built
| Upgrade Java support for Capacity Provisioning 98 image CUNIDHC2 . . . . . . . . . . 118
| Discontinue use of PGSER to protect and Remove classification rules with the ETC work
| unprotect the READONLY nucleus . . . . . 98 qualifier . . . . . . . . . . . . . . 119
Track CSVRTLS services . . . . . . . . . 99 Update the SFM policy to control automatic
BCP actions to perform before the first IPL of z/OS termination of impaired critical members . . . 120
V1R13 . . . . . . . . . . . . . . . . 100 Accommodate new REUSASID default . . . . 122
Create IPL text . . . . . . . . . . . . 100 Review the list of WTORs in parmlib member
Reassemble the stand-alone dump program . . 101 AUTOR00 . . . . . . . . . . . . . 123
| Remove references to the MTFTPS utility . . . 102 BCP actions to perform after the first IPL of z/OS
| Change value for ARM restart processing . . . 103 V1R13 . . . . . . . . . . . . . . . . 124
| Modify automation that references output from | Update Capacity Provisioning Manager
| D XCF,SYSPLEX console commands . . . . . 104 | parameters to use CIM Client for Java Version 2. 124
| Update LLA for automation . . . . . . . 105 | Set AUTHQLVL parameter in GRSCNFxx
| Accommodate OPERLOG EMCS console name | parmlib member to recognize new GRS qnames . 125
| change . . . . . . . . . . . . . . 106 | Examine use of the CMDS ABEND command 126
| Adjust CON= system parameter to | Ensure Runtime Diagnostics is installed before
| accommodate default change . . . . . . . 107 | invoking Predictive Failure Analysis. . . . . 127
| Accommodate HiperDispatch default of YES on | Carry over your existing CPCC policy . . . . 128
| IBM zEnterprise (z196 and z114) . . . . . . 108 Evaluate applications that parse AMBLIST
| Start Runtime Diagnostics at system command LISTLOAD or LISTIDR output . . . 129
| initialization . . . . . . . . . . . . . 109 Ensure analysis tools interacting with HIS
Ensure all modules of an application are output accommodate HIS state change events . 131
compiled with the same version of the Detect program objects that have multiple
IRARASD macro . . . . . . . . . . . 110 INITIAL LOAD segments . . . . . . . . 132
| Issue commands from the system console
| regardless of problem determination mode . . 111

This topic describes migration actions for the base element BCP (Base Control
Program).

BCP actions to perform before installing z/OS V1R13
This topic describes BCP migration actions that you can perform on your current
(old) system. You do not need the z/OS V1R13 level of code to make these
they are made.


Evaluate your stand-alone dump data set allocations and your
IPCS processing of them
Description: As your applications grow in size and use ever greater amounts of
storage, you should evaluate whether the DASD allocated for your stand-alone
dump data continues to be adequate.

In z/OS V1R6, support was introduced for extended-format sequential data sets, a
form of data set that is SMS-managed and can occupy more than 64 K tracks per
volume. In z/OS V1R7, this support was supplemented with support for large
format sequential data sets (DSNTYPE=LARGE), a form of data set that is
essentially the same as conventional sequential data sets except that more than 64
K tracks may be spanned per volume. If your stand-alone dump data sets are
spread over more volumes than you want, both types of support can help you gain
better control over the number of volumes used for each stand-alone dump data
set.

Element or feature: BCP.
specific release.
Is the migration action required? No, but recommended because of changes
that have been made to stand-alone dump
processing (that reorder dump records with
the intent of recording more important data
early), and especially recommended if you
deploy any LPARs with significantly more
main storage than previously used.
requirements:
Restrictions: None.
check:

Steps to take:
v Use multivolume stand-alone dump data sets. Adjust the number of volumes
and their separation to achieve tolerable stand-alone dump capture times.
v Use extended-format sequential data sets or large format sequential data sets.
Copy their contents to an extended-format, compressed, striped data set using
the IPCS COPYDUMP subcommand prior to analysis. Use the same or a larger
striping factor than you used for your stand-alone dump data sets. Dump data
sets to which stand-alone dump can write may be neither compressed nor
striped, but both attributes are advantageous for the target of the copy
operation. Starting with z/OS V1R12, stand-alone dump data sets can be placed
in track-managed space as well as cylinder-managed space on Extended Address
Volumes (EAV).
v Use a large CISIZE and striping for IPCS dump directories, and use blocking,
striping, and compression for the stand-alone dump data set. Very large


stand-alone dumps might require that you define your directory with the
extended addressing attribute, allowing it to hold more than 4 GB.
Tips: Control interval sizes less than 24K have been shown to be more
vulnerable to fragmentation when used as IPCS dump directories, and IPCS
performance can be degraded when such fragmentation occurs. In this
background, warning message BLS21110I will be issued and you might recreate
the DDIR by using the CLIST BLSCDDIR.
BLS21110I CISIZE(cisize) is less than 24K. It may degrade IPCS performance

v For information about dump data set allocation, extended-format sequential data
sets, large format sequential data sets, and multivolume dump data sets, see
z/OS MVS Diagnosis: Tools and Service Aids.
v For stand-alone dump best practices, see z/OS Problem Management.

| Consider exploiting WARNUND for new IEASYSxx statements
| Description: Starting in z/OS V1R13 (and rolled back to z/OS V1R12 and z/OS
| V1R11 in OA35929), you can specify the WARNUND statement in IEASYSxx.
| When used, this statement indicates that warning message IEA660I be issued when
| undefined statements are encountered, rather than prompting for a correct
| statement. Usage of WARNUND can be particularly useful when specifying new
| parmlib options in IEASYSxx (such as the new IXGCNF and IGGCAT system
| parameters which are introduced in z/OS V1R13), and allowing these new
| IEASYSxx specifications to be shared with pre-z/OS V1R13 systems.
|
| Element or feature: BCP.
| When change was introduced: z/OS V1R13, and rolled back to z/OS V1R12
| and z/OS V1R11 with APAR OA35929.
| Is the migration action required? No, but recommended to assist in sharing
| IEASYSxx members between z/OS V1R13,
| and pre-z/OS V1R13 systems, when new
| enhancements in z/OS V1R13 are to be
| exploited.
| Other system (coexistence or fallback) Ensure the PTF for APAR OA35929 is
| requirements: installed on all pre-z/OS V1R13 systems so
| that the WARNUND statement can be
| identified and processed correctly.
| Restrictions: Certain restrictions are identified when using
| WARNUND in IEASYSxx. See reference
| information below.
| Related IBM Health Checker for z/OS None.
| check:
|

| Steps to take:
| 1. Install the PTF for APAR OA35929 on all pre-z/OS V1R13 systems.

Chapter 5. BCP migration actions 93

| 2. As you add new statements in IEASYSxx for functional exploitation and you
| wish to share those modified IEASYSxx members with pre-z/OS V1R13
| systems, add WARNUND to the beginning of IEASYS00 as that will cover
| updates in all IEASYSxx members.

| Reference information:
| v z/OS MVS System Messages, Vol 6 (GOS-IEA).
| v z/OS MVS Initialization and Tuning Guide.
| v Documentation in the PTFs for APAR OA35929.

| Define DASD storage for Predictive Failure Analysis
| Description: Before z/OS V1R13, Predictive Failure Analysis (PFA) did not
| document the requirement for additional DASD storage to accommodate check
| output. Starting with z/OS V1R13, z/OS Problem Management contains DASD
| requirements to ensure PFA has enough space to update and create files in the
| z/OS UNIX file system to store check output. In addition, because zFS no longer
| stores data in 1K fragments, zFS for z/OS V1R13 might need more DASD storage
| to store the same amount of data than was required in previous releases. For
| additional information about zFS requirements, see “zFS: Accommodate new
| DASD space requirements” on page 215.
|
| When change was introduced: z/OS V1R13.
| Is the migration action required? Yes, if you use PFA.
| requirements:
| check:
|

| Steps to take: Define additional DASD storage for PFA. The total space for the
| PFA file system for each LPAR depends on the release of z/OS you are running.
| z/OS V1R11 (HBB7760)
| 200 cylinders primary; 50 cylinders secondary on a 3390 device.
| z/OS V1R12 (HBB7770)
| z/OS V1R13 (HBB7780)

| Reference information: For additional information and storage requirements for
| earlier z/OS releases, see Steps for installing PFA in z/OS Problem Management.


| Migrate from SNMP to z/OS BCPii for communication to the
| HMC or SE
| Description: IBM intends for z/OS V1R13 to be the final release in which SNMP as
| supported protocol for the communication to the Hardware Management Console
| (HMC) or Support Element (SE) is available. If you are currently using SNMP for
| the communication, it is recommended that you now migrate to BCPii. The
| migration includes enabling the communication through BCPii for the provisioning
| manager user and adding a new key to the Capacity Provisioning Manager
| parameter file.
|
| Is the migration action required? No, but recommended because the migration
| to BCPii will be required in a future release.
| requirements:
| check:
|

| Steps to take:
| v You can use the tracking facility to help with this migration action. In tracking
| facility output, look for violations that start with CPO-W:SNMP usage domain
| name, where domain name is replaced with the actual name of the affected
| domain. Exploit the z/OS tracking facility on z/OS V1R12 or z/OS V1R11 by
| installing the PTF for APAR OA35284. If you are using the tracking facility and
| have no instances of affected domains after starting Capacity Provisioning
| Manager, then this migration action is not applicable to you.
| v Set up BCPii as described in z/OS MVS Programming: Callable Services for
| High-Level Languages.
| v Define the required security profiles to allow the Capacity Provisioning Manager
| user to access the hardware information.
| v Add the Topology.Protocol=INTERNAL key to the Capacity Provisioning
| Manager parameter file. Using the default values, the file is the member
| CPO.DOMAIN1.PARM(PARM).

| v For information about BCPii setup, see z/OS MVS Programming: Callable Services
| for High-Level Languages.
| v For information about required security profile and how to define the new key
| to the Capacity Provisioning Manager parameters, see z/OS MVS Capacity
| Provisioning User's Guide.
| v For information about using the tracking facility, see "Appendix A. Tracking
| facility" in z/OS MVS Planning: Operations.


| Verify that at least one blank follows all major keyword
| statements
| Description: Before z/OS V1R13, you could specify INIT, DEFAULT, HARDCOPY
| and CONSOLE keyword statements without using a blank delimiter. This can
| cause a problem if other keywords are misplaced or misspelled. For example, if
| INTIDS(Y) is misspelled as INITIDS(Y), the parser considers this an INIT
| statement. This could result in a console not being defined correctly, or even
| having a system with no consoles after initialization except the system console.

| Starting with z/OS V1R13, if you do not have a blank character after the four
| major keywords (INIT, DEFAULT, HARDCOPY, and CONSOLE), you will receive a
| syntax error during CONSOLxx parmlib processing indicated by message IEA195I
| or message IEA196I as shown in the example below:
| - IEA196I CONSOLM1 03E0: NAME REQUIRED FOR CONSOLE.
| - IEA196I CONSOLM1 INIT: DUPLICATE SPECIFICATION IGNORED.
| - IEA196I CONSOLM1 03E0: UNRECOGNIZED KEYWORD INITDS(Y) IGNORED.
| - IEA196I CONSOLM1 03E0: UNRECOGNIZED KEYWORD INITDS(Y) IGNORED.
| - IEA195I CONSOLM1 LINE1: UNRECOGNIZED STATEMENT TYPE IGNORED.
| - IEA195I CONSOLM1 LINE1: UNRECOGNIZED STATEMENT TYPE IGNORED.

| Also, if you do not have a blank after the major keywords INIT, DEFAULT, and
| HARDCOPY, the default values will be used. In the case of the major keyword,
| CONSOLE, you will be left with only the system console if all of your CONSOLE
| statements do not end with a blank characters.
|
| Is the migration action required? Yes, if you do not have at least one blank
| after any of the four major keywords INIT,
| DEFAULT, HARDCOPY, and CONSOLE.
| requirements:
| check:
|

| Steps to take:
| 1. Examine your CONSOLxx parmlib member to verify that you have at least one
| blank after all of your major keyword statements.
| 2. If, you do not have a blank, update your CONSOLxx parmlib member by
| entering one or more blanks between the major keyword statements and their
| associated keywords.

| Reference information: For more information about the CONSOLxx parmlib
| member, see z/OS MVS Initialization and Tuning Reference.


| Examine source for dynamic allocation callers that set the
| S99DSABA and S99ACUCB flags
| Description: TIOTs and XTIOTs contain entries for each DD statement allocated by
| either batch (JCL) or dynamic allocation. The TIOT is a below-the-line control block
| that contains contiguous DD entries, which allows for a sequential search. Because
| of limits on its size and structure, a TIOT can only accommodate a specific number
| of DD statements (for example, 3273 single unit DD statements for a TIOT size of
| 32k.)

| To overcome this restriction, device allocation introduced XTIOTS or extended
| TIOTs above the 16M line, but the support was limited to authorized dynamic
| allocation callers only because the authorized flag S99TIOEX had to be set in order
| to build XTIOTs. Later, this restriction was relaxed when unauthorized dynamic
| allocation callers could request XTIOTs by setting S99ACUCB; however, the ability
| to get an above-the-line data set association block (DSAB) that contains a pointer to
| the TIOTs/ XTIOTs was limited to requests by authorized callers only, because the
| S99DSABA flag (which can be set by authorized or unauthorized callers) is
| honored only if the authorized S99TIOEX flag also has been set.

| In z/OS V1R12, the Basic Access Method (BAM) added support for XTIOTs.
| Because it makes sense to allow unauthorized callers to get DSABs above the line,
| in z/OS V1R13, device allocation added support to build DSABs above the line
| when the S99DSABA bit flag is set and either S99ACUCB or S99TIOEX is also set.
| Thus, unauthorized users can fully utilize the virtual storage constraint relief
| (VSCR) capabilities provided by allocation and get the benefits of both the
| above-the-line DSABs and XTIOTs.

| If any unauthorized dynamic allocation caller indicates through S99DSABA that
| above-the- line DSABs are supported but encounters a programming error in the
| user code when referencing above-the-line DSABs, action is required. Before z/OS
| V1R13, if the dynamic allocation callers set the S99DSABA and S99ACUCB flags,
| allocation built below-the-line DSABs, scanned the below-the-line DSAB queue,
| and found them below the line. For z/OS V1R13, if dynamic allocation callers
| request above-the-line DSABs through S99DSABA and S99ACUCB, allocation
| builds above-the-line DSABs, scans the above-the-line DSAB queue, and finds them
| above the line. If the dynamic allocation callers have an existing programming
| error when they attempt to reference above-the-line DSABs , they will continue to
| encounter errors. If these dynamic allocation callers need to use below-the-line
| DSABS , they should not set the S99DSABA.
|
| Is the migration action required? Yes, if you have unauthorized dynamic
| allocation callers that set the S99DSABA and
| S99ACUCB flags.
| requirements:


| check:
|

| Steps to take: For mission critical code, examine source for use of S99DSABA. If
| found, verify that field DSQDSABA is not used and that 4 byte (31 bit) pointers are
| used if the DSAB is accessed by the program itself.

| Reference information: For details about S99DSABA and S99ACUCB, see z/OS
| MVS Programming: Authorized Assembler Services Guide.

| Upgrade Java support for Capacity Provisioning
| Description: Starting with z/OS V1R13, the Provisioning Manager component of
| Capacity Provisioning requires Java V6.0. If the references in the ENV member of
| the Provisioning Manager parameters dataset specify the location of an earlier
| version of Java, you must update the LIBPATH environment variable.
|
| Is the migration action required? Yes, if you use Capacity Provisioning.
| Target system software requirements: IBM 31-bit SDK for z/OS, Java Technology
| Edition, V6 (5655-R31).
| Other system (coexistence or fallback) None
| requirements:
| check:
|

| Steps to take:
| v Install IBM 31-bit SDK for z/OS, Java 2 Technology Edition, V6 (5655-R31).
| v Change the LIBPATH variable in the ENV member of your Provisioning
| Manager PARM data set to point to the installation directories of your Java V6
| installation. LIBPATH statement may look like:
| LIBPATH=/usr/lib:/usr/lpp/java/J6.0/bin:usr/lpp/java/J6.0/bin/classic:
| /usr/lpp/cpo/lib

| Reference information: For information about how to adapt the Provisioning
| Manager parameters, see z/OS MVS Capacity Provisioning User's Guide

| Discontinue use of PGSER to protect and unprotect the
| READONLY nucleus
| Description: Starting in z/OS V1R12, most of the READONLY nucleus is backed
| by 1 MB pages. This makes protecting or unprotecting the READONLY nucleus
| with the PGSER macro difficult because the macro can only handle virtual storage


| pages backed by 4 KB pages. Therefore, the PGSER macro is changed, with APAR
| OA33782, to no longer support requests to protect and unprotect the READONLY
| nucleus if it is backed by 1 MB pages.
|
| When change was introduced: z/OS V1R13. z/OS V1R12 by APAR
| OA33782.
| Applies to migration from: z/OS V1R12 without APAR OA33782, and
| z/OS V1R11.
| Is the migration action required? Yes, if you use the PGSER macro to protect
| or unprotect the READONLY nucleus.
| requirements:
| System impacts: Failure to discontinue use of PGSER to
| protect and unprotect READONLY nucleus
| that is backed by 1 MB pages will result in
| the ABEND18A reason codes indicated in
| "Steps to take," below.
| check:
|

| Steps to take: Do not use PGSER to protect or unprotect the READONLY nucleus
| when it is backed by 1 MB pages. Users requiring the modification of READONLY
| nucleus should use the DATOFF macro.

| Failure to discontinue use of PGSER to protect and unprotect READONLY nucleus
| that is backed 1 MB pages will result in the following ABEND18A reason codes:
| v FF070411– The caller issued a PGSER macro with the PROTECT parameter for
| virtual storage in the READONLY nucleus that is backed by 1 MB pages. This
| storage area cannot be specified with the PROTECT keyword.
| v FF080411 – The caller issued a PGSER macro with the UNPROTECT parameter
| for virtual storage in the READONLY nucleus that is backed by 1 MB pages.
| This storage area cannot be specified with the UNPROTECT keyword.

| Reference information: For detailed information about PGSER, see z/OS MVS
| Programming: Authorized Assembler Services Reference LLA-SDU.

Track CSVRTLS services
Description: z/OS V1R5 was the last release of z/OS to support Run-Time Library
Services (RTLS) for Language Environment. In z/OS V1R12, the underlying
CSVRTLS services were removed from z/OS. A way to track CSVRTLS usage, and
to let you find any programs that might be using these services, is available in
z/OS V1R11, and rolled back to z/OS V1R10 with APAR OA29019.

When change was introduced: z/OS V1R12.


Is the migration action required? Yes, if you are using CSVRTLS services.
requirements:
Restrictions: None.
System impacts: As of z/OS V1R12, failure to remove
references to the SET RTLS or DISPLAY RTLS
command will result in error messages
indicating the entry is unknown or not
supported, as shown below:
IEE309I SET UNIDENTIFIABLE KEYWORD
IEE305I DISPLAY COMMAND INVALID
check:

Steps to take:
v Exploit the z/OS tracking facility to help determine if you are using any of the
CSVRTLS services (SET RTLS command, DISPLAY RTLS command, CSVRTLS
macro, and RTLS system parameter in IEASYSxx parmlib member) removed
from z/OS V1R12:
– For z/OS V1R11, install PTF UA49184 for APAR OA29995.

v See APAR OA29995.
v To learn more about the tracking facility, see Appendix A in z/OS MVS Planning:
Operations.
v To activate or deactivate the tracking facility, use the SETCON TRACKING
command. For information about this command, see z/OS MVS System
Commands.
v To display the recorded events, use the DISPLAY OPDATA,TRACKING
command. For information about this command, see z/OS MVS System
Commands. This command displays message CNZ1001I. For information about
this message, see z/OS MVS System Messages, Vol 4 (CBD-DMO).

BCP actions to perform before the first IPL of z/OS V1R13
This topic describes BCP migration actions that you can perform after you have
active.

Create IPL text
Description: IPL text is bootstrap information required for IPL (such as the location
of the nucleus library). You must create IPL text by running ICKDSF against the
system residence volume.



specific release.
requirements:
Restrictions: None.
check:

Steps to take: Update and run the IPLTEXT job to write a new copy of the IPL
text. If you install z/OS with a ServerPac, an installation dialog job is provided to
perform this action. If you install z/OS with a CBPDO, instructions to perform this
action are provided in z/OS Program Directory.

Note: When the IPLTXTEXIST parameter (which was introduced by ICKDSF R17
APAR PK16403) is specified with the REFORMAT command using the
IPLDD parameter, WTOR message ICK21836D is suppressed if IPL text
already exists.

Reference information: For a sample IPLTEXT job, see z/OS Program Directory.
ServerPac provides a similar job for accomplishing this task; see ServerPac:
Installing Your Order.

Reassemble the stand-alone dump program
Description: The stand-alone dump program produces a dump of storage that is
occupied by a system that failed or a stand-alone dump program that failed. You
must reassemble the stand-alone dump program each release. Once the stand-alone
dump program is properly created on a DASD residence volume, it resides in the
SYS1.PAGEDUMP.Vvolser data set.

specific release. See "Steps to take" for
required changes to generate a stand-alone
dump program using one-step JCL.
requirements:
Restrictions: None.


check:

Steps to take: Reassemble the stand-alone dump program. If you install z/OS with
a ServerPac, an installation dialog job is provided to perform this action. If you
install z/OS with a CBPDO, instructions to perform this action are provided in
z/OS MVS Diagnosis: Tools and Service Aids.

| If you are migrating from a pre-z/OS V1R12 system where the PTF for OA31077 is
| not applied, stand alone dump one-step (now called one-stage) JCL needs to be
| updated to specify DDNAME of TRK0TEXT and DSFSYSIN. Also, another job step
| (for DASD) to invoke ICKDSF must be added. Sample JCL can be found in z/OS
| MVS Diagnosis: Tools and Service Aids and DOC APAR OA34383.

Note: Starting with z/OS V1R12, NUCLIB=(volser,unit) parameter can be specified
with the AMDSADMP macro in one-stage generation JCL. Prior to z/OS
V1R12, this parameter was allowed only when using the two-stage
generation JCL.

v ServerPac: Installing Your Order
v z/OS MVS Diagnosis: Tools and Service Aids

| Remove references to the MTFTPS utility
| Description: Before z/OS V1R13, you might have used the problem documentation
| upload utility (PDUU), packaged as MTFTPS, to send large volumes of problem
| documentation, such as stand-alone dumps, to IBM support. Beginning with z/OS
| V1R13, the z/OS problem documentation upload utility (PDUU) is a standard part
| of the base operating system with entry point name AMAPDUPL.
|
| Timing: Before the first IPL of z/OS V1R13.
| Is the migration action required? No, but recommended if you previously used
| the stand-alone version of PDUU (MTFTPS).
| requirements:
| check:
|

| Steps to take: To avoid possible conflicts, remove the stand-alone version of the
| PDUU utility and begin using the supported version:
| 1. Remove any prior version of MTFTPS from your system. The PDUU utility
| name is AMAPDUPL (in SYS1.MIGLIB), although MTFTPS is shipped as an
| alias entry point to AMAPDUPL


| 2. Begin using the PDUU as the primary utility for sending large volumes of
| product documentation to IBM Support.

| Reference information: For complete details, including JCL statements and
| examples, see the topic on The z/OS Problem Documentation Upload Utility in
| z/OS MVS Diagnosis: Tools and Service Aids.

| Change value for ARM restart processing
| Description: Before performing cross-system restart, automatic restart management
| (ARM) waits for member cleanup for the terminated system to complete. ARM
| proceeds with cross-system restart if cleanup takes longer than a certain amount of
| time. Before z/OS V1R13, this time was two minutes. Support for a new
| parameter, CLEANUP_TIMEOUT, is available with the PTFs for APAR OA35357
| applied to z/OS V1R13, z/OS V1R12, z/OS V1R11, and z/OS V1R10. The default
| for this new parameter is five minutes. That is, ARM will wait five minutes for
| member cleanup for a terminated system to complete before performing
| cross-system restart for an element.

| Starting with z/OS V1R13, the CLEANUP_TIMEOUT parameter can be used to
| indicate that ARM is to wait additional time for member cleanup for a terminated
| system to complete. To get the two minute timeout behavior that existed before the
| default change, CLEANUP_TIMEOUT(120) must be added to the ARM policy. If
| you do not specify CLEANUP_TIMEOUT(120), the system issues the following
| message to the system log to record when CLEANUP_TIMEOUT has an effect on
| cross-system restart processing:
| IXC815I MEMBER CLEANUP FOR SYSTEM sysname1 NUMBER sysnum1 INCOMPLETE
|
| When change was introduced: z/OS V1R13, and rolled back to z/OS V1R12,
| z/OS V1R11, and z/OS V1R10 by APAR
| OA35357.
| Applies to migration from: z/OS V1R12 and z/OS V1R11 without the
| PTFs for OA35357 applied.
| Is the migration action required? Yes, if you have the PTF for APAR OA35357
| applied and a five-minute timeout for
| member cleanup is not acceptable.
| Other system (coexistence or fallback) The new five minute default, or any use of
| requirements: the CLEANUP_TIMEOUT parameter other
| than CLEANUP_TIMEOUT(120), is not fully
| effective until all systems in the sysplex have
| support for the CLEANUP_TIMEOUT
| parameter. APAR OA35357 provides support
| for the CLEANUP_TIMEOUT parameter.
| Restrictions: None
| check:
|


| Steps to take: If you prefer to use the two minute value for ARM restart
| processing, do the following:
| 1. Use the z/OS V1R13 version of IXCMIAPU to define an ARM policy with
| CLEANUP_TIMEOUT(120).
| 2. Use the SETXCF START command to start the new or updated policy.

| Reference information: For details, see the topic "Automatic restart management
| parameters for administrative data utility" in the chapter "Administrative data
| utility" in z/OS MVS Setting Up a Sysplex.

| Modify automation that references output from D
| XCF,SYSPLEX console commands
| Description: Before z/OS V1R13, when the following D XCF console commands
| were issued, the resulting messages contained output information from the
| command depending on the options specified:
| v D XCF
| IXC334I hh.mm.ss DISPLAY XCF SYSPLEX sysplex-name: sysname sysname
| sysname sysname
| v D XCF,SYSPLEX
| sysname sysname
| v D XCF SYSPLEX,ALL
| IXC335I hh.mm.ss DISPLAY XCF text

| Starting with z/OS V1R13, the output message for a D XCF,SYSPLEX command is
| changed to IXC336I, which provides more basic information about a system. In
| addition, a new output message, IXC337I, is issued for a D XCF,SYSPLEX
| command when a system name or ALL is specified. Detailed sysplex and system
| information was added and reformatted in the new message. These changes can
| affect your message automation programs.
| v D XCF
| sysname sysname
| v D XCF,SYSPLEX
| IXC336I hh.mm.ss DISPLAY XCF text
| SYSTEM TYPE SERIAL LPAR STATUS TIME SYSTEM STATUS
| sysname type serial lpar m/dd/yyyy status
|
| SYSTEM STATUS DETECTION PARTITIONING PROTOCOL CONNECTION EXCEPTIONS: local_limit
| SYSTEM DIAG INFO: cpiiservice faileddatetime retcode
| SYSTEM ABEND CODE: abendcode ABEND REASON CODE: abendrsncode
| TIME OF FAILURE: abenddatetime
| v D XCF,SYSPLEX,ALL | system name
| IXC337I hh.mm.ss DISPLAY XCF
| SYSPLEX sysplex-name MODE: plex_mode
| SYSTEM system-name STATUS: system-status
| system-status
| TIMING: system-timing
| STATUS TIME: activetime
| JOIN TIME: activetime
| SYSTEM NUMBER: system-number
|


| Is the migration action required? Yes, if you use automation programs or other
| procedures to handle message IXC335I.
| requirements:
| check:
|

| Steps to take: Modify automation that references output from D XCF,SYSPLEX, D
| XCF,SYSPLEX,ALL, and D XCF,SYSPLEX,systemname commands. Message IXC337I
| replaces IXC335I. IXC335I is no longer issued.

| Reference information: For details about the message output for IXC334I, IXC336I,
| and IXC337I, see z/OS MVS System Messages, Vol 10 (IXC-IZP).

| Update LLA for automation
| Description: Before z/OS V1R13, if you started library lookaside (LLA) using a
| CSVLLAxx parmlib member, and then stopped and restarted LLA without using a
| parmlib member, LLA honored the "no parmlib member" state and managed only
| the data sets in the LNKLST concatenation. Beginning with z/OS V1R13, the same
| scenario results in using the CSVLLAxx parmlib member with which LLA
| previously started. To get back to the "no parmlib member" state, you must specify
| LLA=NONE when starting LLA.
|
| Is the migration action required? Yes, if you have automation or operator
| procedures that restart LLA and you want
| LLA to restart with no parmlib member even
| when you previously started LLA with a
| parmlib member.
| requirements:
| check:
|


| Steps to take: If you have automation in place to restart LLA and you want
| automation to restart without a parmlib member even when you had started LLA
| with a parmlib member, you must change it to use the LLA=NONE parameter.

| Reference information: See the topic on CSVLLAxx (library lookaside (LLA) list)
| in z/OS MVS Initialization and Tuning Reference

| Accommodate OPERLOG EMCS console name change
| Description: Starting with z/OS V1R13 (and z/OS V1R12, z/OS V1R11, and z/OS
| V1R10 with the PTF for APAR OA31913 applied), the OPERLOG EMCS console
| name *OPLOGyy is generated using the two character System Clone value
| (&SYSCLONE). The default &SYSCLONE value is obtained from the System Name
| (&SYSNAME) (for example, System Name = SYSTEM1 / System Clone = M1 ).
| This naming convention is similar to the SYSLOG EMCS console (*SYSLGyy).
|
| When change was introduced: z/OS V1R13 (z/OS V1R12, z/OS V1R11,
| z/OS V1R10, and z/OS V1R9 by APAR
| OA31913).
| Applies to migration from: z/OS V1R12 and z/OS V1R11, both without
| the PTF for APAR OA31913 installed.
| Is the migration action required? Yes, if you depend on the OPERLOG EMCS
| console name.
| requirements:
| check:
|

| Steps to take: The change of OPERLOG EMCS console name spans all
| configurations (MULTISYSTEM, XCFLOCAL, MONOPLEX, in GRS RING or STAR
| mode). If you depend on the name of OPERLOG EMCS console in your own
| procedure, it must be adjusted to reflect this change. For example, the following
| will display the OPERLOG EMCS console name:
| D C,KEY=OPERLOG (message IEE892I)
| D EMCS (message IEE129I)
| D EMCS,CN=*OPLOG* (message IEE129I)

| Note: With the PTF for APAR OA30757 applied to z/OS V1R11 or z/OS V1R10,
| and in z/OS V1R12, this change was already in effect.

| Reference information: For more information about the OPERLOG EMCS console,
| see z/OS MVS Planning: Operations.


| Adjust CON= system parameter to accommodate default
| change
| Description: Before z/OS V1R13, the default console operating mode was
| SHARED. Beginning with z/OS V1R13, the default console operating mode is
| changing from SHARED mode to DISTRIBUTED mode. SHARED mode will be
| removed in a future release. DISTRIBUTED mode is now the preferred mode of
| operations.
|
| Is the migration action required? Yes, if there is no specification on the CON=
| system parameter and SHARED mode is
| required.
| requirements:
| System impacts: Impacts could be experienced falling back to
| shared, but only after taking advantage of
| some of the functionality offered in
| distributed. For more information, see
| "Operation modes of console support" in
| z/OS MVS Planning: Operations.
| Related IBM Health Checker for z/OS Use check
| check: ZOSMIGV1R13_CNZ_CONS_OPER_MODE,
| available with APAR OA32930, to determine
| if your installation has explicitly identified
| your console service operating mode.
|

| Steps to take: Examine the system parameters used to IPL the system or sysplex.
| The initial mode is specified on the CON= system parameter. Use the D
| OPDATA,MODE to find the current mode, which is displayed in message
| CNZ9006I.
| v If DISTRIBUTED is specified, no action is required.
| v If SHARED is specified, an action is not currently required, but DISTRIBUTED
| mode will become a required action in the future.
| v If there is no specification on the CON= system parameter, DISTRIBUTED mode
| is now the default.
| v If there is no specification on the CON= system parameter and SHARED mode
| is required, you have to explicitly request the SHARED mode on the CON=
| system parameter. This allows the system or systems to continue functioning in
| the same manner as they do today. Use the SETCON MODE=SHARED
| command to request SHARED mode.
| Tip: When you activate the OPERCMDS FACILITY class, you must have the
| CONTROL access authority to the profile when issuing the SETCON MODE
| command.

| Reference information: For more information, see:


| Examine the IEAOPTxx member(s) used for each z/OS V1R13 image that will be
| IPLed on a z196 or a z114. Then find the HIPERDISPATCH keyword and take one
| of the following actions:
| v For HiperDispatch=YES, no action is required.
| v When the HiperDispatch keyword is omitted, note that the image will take the
| default of HiperDispatch=YES and IPL with HiperDispatch enabled. Decide if
| you wish to accept that HiperDispatch will be enabled by default by reviewing
| the subsequent steps, and the "HiperDispatch=YES considerations" section.
| v For HiperDispatch=NO, investigate why that image was running in
| HiperDispatch=NO and choose one of the following:
| – Define a plan to migrate that image to HiperDispatch=YES. See the
| "HiperDispatch=YES considerations" section for further information.
| – Continue to run the image with HiperDispatch=NO (IBM does not
| recommend this option for LPARs where the LPAR weight guarantees a share
| of two or more physical processors without a compelling reason for running
| HiperDispatch=NO).
| To get the SUP_HiperDispatch health check to succeed, add the machine type
| to the MachTypes parameter and verify that the HIPERDISPATCH parameter
| is NO.

| HiperDispatch=YES considerations:
| v Before enabling HiperDispatch review the WLM policy and make appropriate
| changes as needed that are described in the “WLM Policy Considerations” in the
| “Planning Considerations For HiperDispatch Mode” white paper at
| http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101229.
| v Verify that the LPAR profiles of the partitions in which the system may be IPLed
| allow for "Global Performance Data Control". See the Processor Resource/Systems
| Manager Planning Guide for a description of this capability. If this capability is
| not allowed, WLM will be unable to understand capacity that is used by other
| LPARs and will use all logical processors. Using all logical processors will result
| in suboptimal use of cache, reducing the capacity of the partition when more
| logical processors are defined compared to the share of the partition. This can
| also result in the "short CP" effect where a logical processor may have a unit of
| work dispatched while removed from a physical processor for significant
| intervals. This can lead to response time problems.

| v "Planning Considerations for HiperDispatch Mode" white paper at IBM Techdocs
| http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101229.
| v Processor Resource/Systems Manager Planning Guide
| v z/OS MVS Initialization and Tuning Reference
| v z/OS MVS Planning: Workload Management
| v IBM Health Checker for z/OS: User's Guide

| Start Runtime Diagnostics at system initialization
| Description: Before z/OS V1R13, Runtime Diagnostics ran as a as a started task
| under the master subsystem and had to be started each time you wanted an
| analysis. It was started, did its analysis, then ended. Beginning with z/OS V1R13,
| you can start Runtime Diagnostics to run as an address space under the master
| subsystem. After you start the Runtime Diagnostics address space (HZR), it
| remains running until stopped using the STOP command. Use the MODIFY
| HZR,ANALYZE command to generate a Runtime Diagnostics analysis and report.


|
| Is the migration action required? No, but recommended to use Runtime
| Diagnostics.
| requirements:
| check:
|

| Steps to take: To start the Runtime Diagnostics address space (HZR) on z/OS
| V1R13:
| 1. Ensure the hzrproc (HZR) points to PGM=HZRINIT, not PGM=HZRIMAIN as
| in z/OS V1R12. The hzrproc (HZR) ships in the SYS1.PROCLIB data set.
| 2. If you want to start Runtime Diagnostics address space (HZR) during system
| initialization, specify COM=’S HZR,SUB=MSTR’ in the COMMNDxx parmlib
| member. Otherwise, the HZR address space must be started manually: S
| HZR,SUB=MSTR
| 3. After the Runtime Diagnostics address space (HZR) is started, use the MODIFY
| HZR,ANALYZE command to generate Runtime Diagnostics' reports.

| Reference information: For complete details about using Runtime Diagnostics, see
| the topic on Runtime Diagnostics overview in z/OS Problem Management.

Ensure all modules of an application are compiled with the
same version of the IRARASD macro
Description: Starting with z/OS V1R12, the IRARASD macro (field RQFASDWA)
defines a 512-byte (changed from 338-byte) work area for SYSEVENT REQFASD.
When you recompile a module that includes the IRARASD macro, you must also
recompile all other modules that include the IRARASD macro and belong to the
same application.

It is only necessary to ensure that all modules of an application use the same
version of the IRARASD macro; it is not necessary to recompile all modules with
the z/OS V1R12 version of the IRARASD macro.

Is the migration action required? No, but recommended to avoid incompatible
work area sizes between program and
declaration when declaration of the work
area is done outside the program (DSECT).


requirements:
Restrictions: None.
check:

Steps to take: Ensure all modules of an application are compiled with the same
version of the IRARASD macro.

v See APAR OA33666.
v See macro IRARASD in SYS1.MACLIB

| Issue commands from the system console regardless of
| problem determination mode
| Description: Before z/OS V1R12, the system console could not issue any
| commands (except REPLY and VARY CN(*),ACTIVATE) unless it was placed in
| problem determination (PD) mode through the VARY CN(*),ACTIVATE command.
| Starting with z/OS V1R12, processing changed so that commands could always be
| entered at the system console regardless of problem determination mode. With
| APAR OA34731, commands can only be entered at the system console if the
| CONSOLxx keyword ALLOWCMD(Y) is specified on the system console
| definition.
|
| When change was introduced: z/OS V1R12 and z/OS V1R11 by APAR
| OA34731.
| PTF for OA34731 installed.
| Is the migration action required? No, but recommended to immediately enter
| commands from the system console during
| critical situations.
| Other system (coexistence or fallback) The parmlib statement ALLOWCMD in
| requirements: CONSOLxx is not tolerated on systems that
| do not have the PTF for APAR OA34731
| installed.
| Related IBM Health Checker for z/OS Use CHECK(CNZ_SYSCONS_ALLOWCMD)
| check: to compare the ALLOWCMD setting for the
| system console with the setting specified on
| the check.
|


| Steps to take: Add ALLOWCMD(Y) to the system console definition in the
| CONSOLxx member of PARMLIB if you wish to allow commands to be issued
| from the system console regardless of problem determination mode.

| v PTF HOLD information for APAR OA34731.

Update automation that handles messages IEF374I and
IEF376I
Description: Starting in z/OS V1R12, message IEF374I is replaced by message
IEF032I, and message IEF376I is replaced by message IEF033I. If you use
automation programs to handle messages, or you have operator or other
procedures that deal with messages, you should update the programs or
procedures appropriately.

Sample output of new messages for z/OS V1R12:
| IEF142I BEANSZZ STEP1 - STEP WAS EXECUTED - COND CODE 0000
| IEF373I STEP/STEP1 /START 2010272.2014
| IEF032I STEP/STEP1 /STOP 2010272.2014
| CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC
| VIRT: 4K SYS: 232K EXT: 0K SYS: 11936K
| IEF375I JOB/BEANSZZ /START 2010272.2014
| IEF033I JOB/BEANSZZ /STOP 2010272.2014
| CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC

Is the migration action required? Yes, if you use automation programs or other
procedures to handle messages IEF374I and
IEF376I.
| Target system software requirements: APAR PM23467 is needed for the Tivoli
| Workload Scheduler (TWS) product.
requirements:
Restrictions: None.
check:

Steps to take:
v Modify automated actions for IEF374I so they now work with message IEF032I.
v Modify automated actions for IEF376I so they now work with message IEF033I.

Reference information: For details about messages IEF032I and IEF033I, see z/OS
MVS System Messages, Vol 8 (IEF-IGD).


Use the new 16M default buffer size for trace options with the
CTIGRSxx member
Description: Before z/OS V1R12, the default buffer value (BUFSIZE) for the trace
option with the GRS component in the IBM-supplied CTIGRS00 parmlib member
was 128K, the maximum value was 16MB, and the buffer was in GRS below the
bar private storage. Starting with z/OS V1R12, the default size in CTIGRS00 is
increased to 16MB, the maximum is 2047MB, and the buffer is in GRS above the
bar private storage in its own memory object. If you specify your own CTIGRSxx
member on the CTRACE option in GRSCNFxx parmlib member, change the
BUFSIZE in CTIGRSxx to 16MB.

Is the migration action required? Yes, if you modified any IBM-supplied
procedures.
requirements:
Restrictions: None.
check:

Steps to take: Change the trace option BUFSIZE in CTIGRSxx parmlib member to
16M or make the new default value (16M) active.

Reference information: For more information, see "Trace buffer values" z/OS MVS
Diagnosis: Tools and Service Aids and z/OS MVS JCL Reference.

Specify valid user exits for the IFASMFDL and IFASMFDP
programs
Description: When you run the SMF log stream dump program (IFASMFDL) or
the SMF data set dump program (IFASMFDP), the name of an installation-written
exit routine that is given control at the indicated times can be specified by the
USERx (x=1, 2, or 3) parameter.

Beginning with z/OS V1R12 (and z/OS V1R11 with the PTFs for APAR OA29894
applied), to allow user exits to be called by the SMF dump programs, the exits
must now be pre-defined to the system using the new keywords shipped in the
SMFPRMxx parmlib member. The SMFDLEXIT keyword allows exits to be
specified for the IFASMFDL program, and the SMFDPEXIT keyword allows exits
to be specified for the IFASMFDP program.

Both keywords have the same suboptions, USER1, USER2 and USER3. The
suboptions allow multiple exits to be specified for each user exit point in the
respective dump program. The syntax follows.


SMFDLEXIT( USER1( exit1, exit2, ... ) | NOUSER1 ,
USER2( exit1, exit2, ... ) | NOUSER2 ,
USER3( exit1, exit2, ... ) | NOUSER3 )
SMFDPEXIT( USER1( exit1, exit2, ... ) | NOUSER1 ,
USER2( exit1, exit2, ... ) | NOUSER2 ,
USER3( exit1, exit2, ... ) | NOUSER3 )

| Note: In z/OS V1R13, or with the PTF for SMF APAR OA33696 applied to z/OS
| V1R12 or z/OS V1R11, IFASMFDP can once again run in a non-APF
| authorized environment when using the DUMP option. Also, when
| IFASMFDP is executed in an unauthorized environment, the exits specified
| with USER1, USER2 and USER3 will not be verified against what is in the
| SMFPRMxx parmlib member.

When change was introduced: z/OS V1R12. z/OS V1R11, z/OS V1R10, and
z/OS V1R9 with APAR OA29894.
Applies to migration from: z/OS V1R11 without the PTF for APAR
OA29894 applied.
Is the migration action required? Yes, if you use the user exit routines.
Other system (coexistence or fallback) You must apply the PTF for APAR OA29894
requirements: if you share the SMFPRMxx parmlib
member, with the keyword SMFDLEXIT or
SMFDPEXIT specified, on multiple systems.
Restrictions: None.
check:

Steps to take:
v Register an exit specified for IFASMFDL or IFASMFDP using the USER1, USER2
or USER3 parameters through the SMFPRMxx parmlib member. If you fail to do
this, you will receive the following error message, and IFASMFDL or IFASMFDP
will stop the processing:
IFA840I USER EXIT xxxxxxxx NOT REGISTERED WITH SYSTEM
v View the D SMF,O command output to determine if the exits are successfully
registered.

Note: You do not need to explicitly define the exits used by the operation of RACF
SMF unload utility; they are registered by default.
Default: SMFDLEXIT(USER2(IRRADU00),USER3(IRRADU86))
SMFDPEXIT(USER2(IRRADU00),USER3(IRRADU86))

v For details about the SMFPRMxx parmlib member, see z/OS MVS Initialization
and Tuning Reference.
v For details about SMF dump programs, see z/OS MVS System Management
Facilities (SMF).


Make IFASMFDL and IFASMFDP run in an authorized
environment
Description: When you run the SMF log stream dump program (IFASMFDL) or
SMF data set dump program (IFASMFDP), the DUMP function is permitted even
in an unauthorized environment. (Note: The CLEAR function of the SMF data set
dump program requires APF authorization. No such function exists for the SMF
log stream dump program.

Beginning with z/OS V1R12 (and z/OS V1R11 with the PTFs for APAR OA29894
applied), the IFASMFDL and IFASMFDP programs are required to run in an
authorized environment. Otherwise, the programs will lose authorization and you
will get an S338 followed by a S330 abend, especially if the programs are being
executed under TSO/E.

| Note: In z/OS V1R13, or with the PTF for SMF APAR OA33696 applied to z/OS
| V1R12 or z/OS V1R11, IFASMFDP can once again run in a non-APF
| authorized environment when using the DUMP option.

When change was introduced: z/OS V1R12. z/OS V1R11, z/OS V1R10, and
z/OS V1R9 with APAR OA29894.
Applies to migration from: z/OS V1R11 without the PTF for APAR
OA29894 applied.
Is the migration action required? Yes, if you do not invoke the SMF dump
program as a jobstep task.
requirements:
Restrictions: None.
check:

Steps to take:
v If you run the SMF dump program using JCL, the APF-authorization assigned to
it is preserved, and no action is required.
v For the TSO/E environment, you need to add IFASMFDL and IFASMFDP to the
AUTHPGM section of the IKJTSOxx parmlib member when the programs are
being invoked using a TSO/E CALL command.
v If LINKMVS or ATTCHMVS is used in a REXX program to invoke IFASMFDL
or IFASMFDP, change the invocations of IFASMFDL and IFASMFDP using
LINKMVS or ATTCHMVS to use the TSO/E CALL command. In addition, add
the IFASMFDL and IFASMFDP program to the AUTHPGM section of the
IKJTSOxx parmlib member.
v If calling IFASMFDL or IFASMFDP from another program, that program must be
authorized.


Note: A ++HOLD(ACT) is being shipped with the PTFs for APAR OA32258 to
notify that IFASMFDL and IFASMFDP need to be executed in an authorized
environment.

v For details about IKJTSOxx parmlib member, see z/OS MVS Initialization and
Tuning Reference.
v For details about SMF dump programs, see z/OS MVS System Management
Facilities (SMF).

Provide the migrate or new parameter when running the PFA
install script
Description: Before z/OS V1R12, when installing Predictive Failure Analysis (PFA)
it was not necessary for you to specify how to handle the existing data in the
check directories. Beginning with z/OS V1R12, you must append a parameter,
migrate or new, on the installation script to specify if the PFA check directories
retain data from the prior release. If you do not append the migrate or new
parameter, the AIRSHREP.sh script fails.

Is the migration action required? Yes, if you are using PFA.
Other system (coexistence or fallback) Refer to z/OS Problem Management for
requirements: considerations and actions required for
Predictive Failure Analysis (PFA) when
falling back to z/OS V1R12 or z/OS V1R11
from z/OS V1R13.
Restrictions: None.
check:

Steps to take: Provide the migrate or new parameter when running the PFA install
script, AIRSHREP.sh, or when using the sample JCL for batch provided in
SYS1.SAMPLIB.
v migrate: Use the migrate parameter to preserve PFA history data from the prior
release. The migrate option is recommended for all installations that previously
used PFA. When you specify the migrate parameter, the install script preserves
data from the prior release and creates new directory structures for checks not
previously installed on your system.
v new: Use the new parameter if you are installing PFA for the first time or if you
want to delete everything from prior releases and start PFA with new directories.
When you specify the new parameter, the install script deletes the existing check
directories and creates a new directory structure for all the checks.

For example, to run the install script from your home directory:


1. On the OMVS command line, go to the home directory for the PFA user: cd
/pfa
2. Run the install script appending the migrate parameter: /usr/lpp/bcp/
AIRSHREP.sh migrate

Reference information: For complete details, see the topic on Steps for installing
PFA in z/OS Problem Management.

Change default locations for LCCA or PCCA control blocks to
retain 24-bit virtual storage location
Description: In parmlib member DIAGxx, you can specify the virtual location of
the LCCA control block (mapped by the IHALCCA macro) or the location of the
PCCA control block (mapped by the IHAPCCA macro) to be used when a CPU is
brought online. Before z/OS V1R12, if the IHALCCA or IHAPCCA structures
specified on the CBLOC VIRTUAL24 or VIRTUAL31 keyword of DIAGxx did not
specify either the 24-bit (VIRTUAL24) or 31-bit (VIRTUAL31) location, the default
location for the LCCA or PCCA was in 24-bit virtual storage.

Beginning with z/OS V1R12, the default location for the LCCA and PCCA is now
in 31-bit virtual storage if you do not specify VIRTUAL24 or VIRTUAL31 for the
structures IHALCCA and IHAPCCA. If only one standard processor is online
during the IPL, the LCCA and PCCA of the IPL CPU will be in 24-bit storage
regardless of the specification.

Is the migration action required? Yes, if you want to keep the 24-bit virtual
storage location for IHALCCA or IHAPCCA.
requirements:
Restrictions: None.
Related IBM Health Checker for z/OS The following z/OS V1R12 migration checks,
check: (available with APAR OA32015 on z/OS
V1R11), determine if your current settings
match RMODE 31 for the LCCA or PCCA
control blocks:

CHECK(IBMSUP,ZOSMIGV1R12_SUP
_LCCA_ABOVE_16M)
CHECK(IBMRCF,ZOSMIGV1R12_RCF
_PCCA_ABOVE_16M)

As is the convention, these checks are
shipped inactive and are to be activated
when exploring migration actions.


Steps to take: If you want to retain the 24-bit virtual storage location for
IHALCCA or IHAPCCA, specify VIRTUAL24 on the CBLOC keyword in DIAGxx
parmlib member:
VIRTUAL24(IHALCCA)
VIRTUAL24(IHAPCCA)

Reference information: For information, see z/OS MVS Initialization and Tuning
Reference.

Remove reference to Unicode Services pre-built image
CUNIDHC2
Description: Starting in z/OS V1R7, Unicode Services provided support to
dynamically load tables into storage when a Unicode service request is made and
the table is not already in storage. This enhancement is colloquially known as
“Unicode On Demand.” If the appropriate table needed to satisfy the service
request is not in storage, Unicode Services will load the table dynamically without
disrupting the caller’s request. All tables needed for character conversion, case
conversion, normalization, and collation services are now loaded automatically into
storage when they are required and not already present. These tables are added to
other tables already in storage.

Starting in z/OS V1R12, the pre-built image CUNIDHC2 has been eliminated. This
pre-built image contained all the conversion tables supported by DB2 and would
be loaded into storage when you had an empty Unicode environment (no UNI=xx
in the IEASYSxx member) and the first requestor of a Unicode conversion service
would be DB2. Given that most customers would use only a handful of these
tables and given that Unicode Service has the capability to dynamically load tables
into storage, the need for pre-built image has become obsolete. Unicode Services
will no longer ship the pre-built image SYS1.SCUNIMG(CUNIDHC2) and will no
longer automatically load the pre-built image. We recommend that you use the
Unicode On Demand capability to load all tables.

Is the migration action required? Yes, if the SYS1.SCUNIMG is in the LNKLST
specification.
requirements:
Restrictions: None.

Steps to take:
v Remove SYS1.SCUNIMG from the LNKLST specification.
v Remove SYS1.SCUNIMG from the APF authorization list. Note that if your
installation is running with the entire LNKLST as APF authorized
(LNKAUTH=LNKLST), you do not need to take any additional action. If your


installation is not running with the LNKLST as APF authorized
(LNKAUTH=APFTAB), you need to explicitly remove the APF authorization for
this data set.
v Remove the catalog entry for SYS1.SCUNIMG.
v Remove the following DDDEF entries:

Name Data Set Name
ACUNIMG SYS1.ACUNIMG
SCUNIMG SYS1.SCUNIMG

Note: If you want to create and load an image with the same conversion tables as
the eliminated pre-built image, do the following:
1. Invoke the image generator program using the JCL provided in
SYS1.SCUNJCL(CUNJIUTL). Use the conversion statements specified in
SYS1.SAMPLIB(CUNSISM6). CUNSISM6 contains all the conversion
statements needed to build the pre-built image.
2. After building the image, specify the image name in the CUNUNIxx
parmlib member.
3. Specify the corresponding UNI=xx parameter in your IEASYSxx parmlib
member and re-IPL.

Reference information: For more information about how to create an image, see
the section on Creating a Unicode Services Environment in z/OS Unicode Services
User's Guide and Reference.

Remove classification rules with the ETC work qualifier
Description: Beginning with z/OS V1R12, the workload management (WLM)
service definition no longer supports the work qualifier EWLM transaction class
name (ETC) for classification rules of the subsystem type EWLM.

If the activated service definition contains classification rules with qualifier type
ETC, they are simply ignored by WLM. However, the next time you modify the
classification rules for subsystem EWLM with the WLM ISPF Application, you
have to delete the ETC rules before you save your modifications. Although z/OS
V1R12 disregards classification rules with the ETC work qualifier, we recommend
that you remove them. If you do not remove the rules, you will have to delete
them the next time you use the WLM ISPF application to modify the EWLM
subsystem type.

Is the migration action required? No, but recommended, otherwise you will
have to delete the classification rules the next
time you use the WLM ISPF application to
modify the EWLM subsystem type.
requirements:
Restrictions: None.


check:

Steps to take: If your WLM service definitions contain classification rules for
subsystem type EWLM with the ETC work qualifier, start the WLM ISPF
application and choose the Classification Rules option from the Definition Menu.
Use the Modifiy option (3) for the IBM-supplied subsystem type EWLM. Delete all
rows with the ETC qualifier type by using the Delete row Option (D).

Reference information: For a description of how to modify a WLM service
definition, see z/OS MVS Planning: Workload Management.

Update the SFM policy to control automatic termination of
impaired critical members
Description: Starting with z/OS V1R12, a member of an XCF group can identify
itself as being critical to the operation of the group or the system. If a critical
member appears to be inoperative (impaired) and the condition persists long
enough, XCF automatically terminates the member in an attempt to resolve the
problem. For a member that is critical to the operation of the system, this
termination causes the system to be removed from the sysplex. For more
information about XCF groups, see z/OS MVS Setting Up a Sysplex.

Members of the SYSGRS group, for instance, are critical to the operation of the
system. If any GRS member is impaired, ENQ processing is likely impacted
throughout the sysplex. Failure to perform ENQ processing in a timely fashion has
significant negative impact. Thus if a GRS member appears to be impaired, XCF
will automatically remove from the sysplex, the system on which that member
resides.

You can set the MEMSTALLTIME parameter in your sysplex failure management
(SFM) policy to control how long XCF allows a critical member to persist in an
impaired state before it initiates termination of the member (or the member's
system). If the MEMSTALLTIME specification resolves to NO (either implicitly or
explicitly), XCF will terminate an impaired critical member if the condition persists
as long as the failure detection interval (INTERVAL) of the system on which the
member resides, or if the condition persists as long as two minutes, whichever is
greater. To determine which groups are using the critical support, issue the
appropriate XCF display command.

The MEMSTALLTIME parameter also determines how long XCF allows a
signalling sympathy sickness condition to persist before terminating a stalled
group member that is contributing to the problem.

The MEMSTALLTIME parameter indicates the number of seconds that XCF should
wait before it terminates a member that is impacting the sysplex. A
MEMSTALLTIME value of 120 (two minutes) seems to suit many installations as it
provides some additional time for the system to resume normal operation, yet
allows automatic action to resolve the problem before the sympathy sickness
condition critically impacts the sysplex. Installations that resolve such conditions
through manual intervention sometimes use a higher value to allow time for such
intervention to be accomplished. Installations that are less able to tolerate
sympathy sickness conditions sometimes set lower values.


Is the migration action required? No, but recommended when you want to
designate how long XCF will wait before
initiating termination of the impaired critical
members.
requirements:
Restrictions: None.
check:

Steps to take: If you do not have an SFM policy, or if the SFM policy specifies
(either implicitly or explicitly) MEMSTALLTIME(NO), determine if the default time
that XCF will wait before terminating an impaired critical member is acceptable.
The default time is the maximum of the effective failure detection interval, or two
minutes, whichever is greater.

If you have an SFM policy that specifies MEMSTALLTIME other than NO, confirm
that the current specification is also acceptable for the termination of critical
members.

If changes are necessary, take the following steps:
1. As needed, use the IXCMIAPU utility to create a function couple data set for
SFM policies.
2. Use the IXCMIAPU utility to create or modify an SFM policy with an
acceptable MEMSTALLTIME specification.
3. Issue the SETXCF command to activate the desired SFM policy.
Notes:
1. On a sysplex-wide reIPL, the policy cannot be activated until some system is
up far enough to process the SETXCF command.
2. For an existing sysplex, the appropriate SFM policy must be activated before
the z/OS V1R12 system is IPLed to ensure that the z/OS V1R12 system will
use the desired MEMSTALLTIME specification.
3. If you currently specify or default to an effective action of
MEMSTALLTIME(NO), activating a policy with MEMSTALLTIME(n) might
change the behavior of the existing sysplex (since XCF is then permitted to
terminate stalled XCF members that are causing signaling sympathy sickness).
Enhance operational and automation procedures to deal with stalled or
impaired members. Relevant messages to consider for dealing with stalled
members in general, and signaling sympathy sickness specifically, are IXC431I,
IXC432I, IXC430E, IXC640E, IXC660E, IXC631I, and IXC632I. Additional
messages to consider for impaired members are IXC633I, IXC634I, IXC635E,
IXC636I. For more information about XCF messages, see Handling Signaling
Sympathy Sickness in z/OS MVS Setting Up a Sysplex.


Reference information: For details about using SFM policy see z/OS MVS Setting
Up a Sysplex.

Accommodate new REUSASID default
Description: In z/OS V1R9, the REUSASID(YES|NO) parameter in parmlib
member DIAGxx was introduced with a default of NO. Starting with z/OS V1R12,
the default is changed to YES.

When a reusable ASID is requested by the START command or the ASCRE macro,
this reusable ASID is assigned if REUSASID(YES) is specified in DIAGxx. If
REUSASID(NO) is specified in DIAGxx, an ordinary ASID is assigned. The default
is REUSASID(YES). The use of reusable ASIDs might result in system 0D3 abends,
if products or programs have not been upgraded to tolerate reusable ASIDs.

Is the migration action required? Yes. If this migration action is not taken, the
0D3 abends might occur with downlevel
products that provide no toleration support
for reusable ASIDs. Because reusable ASIDs
have been available since z/OS V1R9, it is
reasonable to expect that the current levels of
products are tolerant of reusable ASIDs.
requirements:
Restrictions: None.
System impacts:
check:

Steps to take:
1. On z/OS V1R11 systems, specify REUSASID(YES) in the parmlib member
DIAGxx. On z/OS V1R12 and z/OS V1R13 systems, keep REUSASID(YES), or
allow it to default to YES. You can use the SET DIAG=xx command to change
the REUSASID (YES|NO) option.
2. Verify that no 0D3 abends occur as a result.
3. If 0D3 abends do occur, apply appropriate maintenance to the affected code.
4. If this is not possible, specify REUSASID(NO) in DIAGxx on z/OS V1R13 to
override the new default of REUSASID(YES).

v For more information about reusable ASIDs, see z/OS MVS Programming:
Extended Addressability Guide.
v For more information about the REUSASID parameter in the parmlib member
DIAGxx, see z/OS MVS Initialization and Tuning Reference.


Review the list of WTORs in parmlib member AUTOR00
Description: In z/OS V1R12, the DDDEF"d PARMLIB provides an AUTOR00
member. This member should be found in your parmlib concatenation during IPL
and will result in auto-reply processing being activated. If the WTORs listed in
AUTOR00 are automated by your existing automation product, ensure that the
replies in AUTOR00 are appropriate.

requirements:
Restrictions: None.
check:

Steps to take: Examine the WTOR replies in the AUTOR00 parmlib member. If the
replies or delay duration are not desirable, you can create a new AUTORxx
parmlib member and make corresponding changes. Also compare the replies to
what your automation product would reply to these WTORs. Make sure that the
AUTOR00 replies are in accordance with the replies from your automation
product. IBM does not recommend making updates to AUTOR00, because updates
to AUTOR00 might be made by the service stream or in new z/OS releases.
Notes:
1. If you have created an AUTORxx parmlib member, update the IEASYSyy
parmlib member that you use for IPL. Add the following statement to the
IEASYSyy member:
AUTOR=(xx,00)

Here xx corresponds to the AUTORxx parmlib member that you created. The
IEASYSyy members specifying AUTOR cannot be shared with prior z/OS
releases. If you only need the default AUTOR00 settings, you can omit
specifying AUTOR= in IEASYSyy, and other z/OS levels can continue to use
IEASYSyy. Even if AUTOR= is not specified in IEASYSyy, AUTOR00 is used if
it exists.

Note: If you have automation already in place for a WTOR and that WTOR
now appears in AUTOR, the AUTOR version still can be used. Review
the WTORs in AUTOR and your automation; either remove the WTOR
from AUTOR or from your automation.
2. If you don't want to activate auto-reply processing, specify AUTOR=OFF in the
parmlib member IEASYSxx or in response to message IEA101A SPECIFY
SYSTEM PARAMETERS. It is not recommended that you remove AUTOR00


from parmlib, because service or new releases might reinstall AUTOR00. If
there is no AUTOR00 member in parmlib, auto-reply is not activated and the
following messages are produced:
CNZ2600I AUTO-REPLY POLICY ATTEMPTING TO USE AUTOR=00.
IEA301I AUTOR00 NOT FOUND IN PARMLIB
CNZ2601I AUTO-REPLY POLICY NOT ACTIVATED.
NO ENTRIES SPECIFIED
3. The IEASYSyy members specifying AUTOR=OFF cannot be shared with prior
z/OS releases.

Reference information: For more information about the AUTORxx and IEASYSyy
parmlib members, see z/OS MVS Initialization and Tuning Reference.

BCP actions to perform after the first IPL of z/OS V1R13
This topic describes BCP migration actions that you can perform only after you
have IPLed z/OS V1R13. You need a running z/OS V1R13 system to perform these
actions.

| Update Capacity Provisioning Manager parameters to use CIM
| Client for Java Version 2
| Description: If you set up your Provisioning Manager in z/OS V1R11 or earlier,
| and you are not using the default installation path /usr/lpp/wbem/jclient for
| your CIM component, you need to set up the Capacity Provisioning Manager for
| the use of CIM Client for Java Version 2.
|
| When change was introduced: General migration action not tied to a
| specific release.
| Timing: After the first IPL of z/OS V1R13.
| Is the migration action required? Yes, if you use Capacity Provisioning
| Manager and are not using the default
| installation path for your CIM component.
| requirements:
| check:
|

| Steps to take:
| v The Provisioning Manager user CPOSRV needs read access to CIM Client for
| Java Version 2 sblim-cim-client2.jar. These access rights are usually sufficient by
| default. If the current access rights are insufficient, you must set the "other" read
| access permissions of the file accordingly, using the UNIX command chmod, for
| example, chmod o+r /usr/lpp/wbem/jclient/sblim-cim-client2.jar. Note that this
| command must be issued by a user with appropriate authorization.


| v If your CIM installation directory is not at the default location, you need to add
| the location of the CIM Client for Java Version 2 sblim-cim-client2.jar to the
| CLASSPATH entry. If you have already specified the location of a previous
| version of the CIM Client for Java, you need to add the location of CIM Client
| for Java Version 2 before the location of the previous version of CIM Client for
| Java. The CLASSPATH is specified in the ENV member of the Provisioning
| Manager runtime environment data set, prefix.PARM. The prefix for the data set
| name is the high-level qualifier of the Capacity Provisioning Manager
| parameters data set and the name of the domain managed by the Capacity
| Provisioning Manager. For example, with the default values, the data set name
| would be CPO.DOMAIN1.PARM.

| Reference information: For additional information about Setting up a Capacity
| Provisioning domain, see z/OS MVS Capacity Provisioning User's Guide

| Set AUTHQLVL parameter in GRSCNFxx parmlib member to
| recognize new GRS qnames
| Description: Beginning with z/OS V1R13, global resource serialization (GRS)
| provides an additional list of qnames that are conditionally authorized: ARCDSN,
| ARCBTAPE, ARCGPA, ARCBACV, and ARCMIGV. You can set the new
| AUTHQLVL parameter in the GRSCNFxx parmlib member to indicate whether the
| system is to recognize the second list of authorized qnames in addition to the
| original list. The value is either 1 (default) or 2.

| The AUTHQLVL setting of 1 (default) denotes that the existing IBM default list for
| authorized qnames (that is, the list in effect for systems at z/OS V1R12 and earlier)
| is in effect for the system in the global resource serialization (GRS) complex. The
| AUTHQLVL setting of 2 denotes the addition of the five new qnames (ARCDSN,
| ARCBTAPE, ARCGPA, ARCBACV, ARCMIGV) to the authorized qname list and
| provides a higher level of protection; however, it can cause some products to fail.
| An unauthorized program issuing ENQ or DEQ requests for any of these qnames
| when AUTHQLVL of 2 is in effect will get ABEND338 or ABEND330, respectively.
| ISGENQ requests with COND=NO will get similar ABENDs and ISGENQ requests
| with COND=YES will get return code 8, reason code xxxx081E,
| ISGENQRsn_NotAuthorizedForQName.
|
| Element or feature: BCP
| Is the migration action required? Yes, to protect authorized programs utilizing
| these qnames from denial-of-service attacks.
| requirements:
| Related IBM Health Checker for z/OS Use check GRS_AUTHQLVL_SETTING to
| check: help determine your installation's need for
| authorized qname protection.
|


| Steps to take:
| 1. Products that are designed to interact with resources that have these qnames
| need to run authorized. In order to help determine if your installation has any
| of these products running on your system, there is a new AUTHQ2 filter on the
| EQDQ Monitor. Before the new AUTHQLVL is increased to 2, this filter shows
| ENQ requests that are made with any of these new qnames from an
| unauthorized program.
| 2. The AUTHQLVL setting in GRSCNFxx refers to a specific system. A rolling IPL
| is required to ensure consistency across the GRS complex. The increased
| AUTHQLVL value can be tested on one system but only for ENQ requests
| initiated on that system. The AUTHQLVL=2 migration process is not complete
| until all systems across the GRS complex are at 2.
| 3. If ABEND338 or ABEND330 occurs from the change because one of the
| required products is missed, the SETGRS command supports a fallback to 1 on
| any given system by issuing SETGRS AUTHQLVL=1; however, you cannot
| dynamically increase the AUTHQLVL. Another IPL is required. Use the
| SETGRS AUTHQLVL command to dynamically change the value of the level
| to 2 for the addition of the 5 new qnames.

| Reference information: For details about authorized qnames, see z/OS MVS
| Planning: Global Resource Serialization.

| Examine use of the CMDS ABEND command
| Description: Before z/OS V1R13, the CMDS ABEND command ended an
| executing command if the command was hung. In z/OS V1R12, or with the PTFs
| for APAR OA30527 installed on z/OS V1R11 and z/OS V1R10, the command
| processors were allowed to specify the new non-abendable attribute to set
| themselves non-abendable. When the new attribute was specified for a target
| command, the CMDS ABEND command rejected with message CNZ6002I. The
| CMDS ABEND attempted to terminate the hung command.. Starting in z/OS
| V1R13, the new parameter FORCE is added to the CMDS command so that a
| CMDS FORCE specification overrides the non-abendable attribute and the
| command will be terminated as it is today. Separating the ABEND and FORCE
| requests allow different RACF profiles to be defined so that installations can allow
| CMDS ABEND, but not CMDS FORCE. FORCE is intended to be used where the
| only alternative is to re-IPL the system.
|
| Is the migration action required? No, but recommended if you use the CMDS
| ABEND command or have automation that
| does.
| requirements:
| check:


|

| Steps to take: Automation that uses the CMDS ABEND command is affected
| because the termination of a running command can be rejected. For some
| commands, this rejection is important because it can prevent a system or sysplex
| outage. If you use the CMDS ABEND command or have automation that does,
| certain commands will no longer be terminated by the CMDS ABEND command.
| v If you must terminate a command, continue to use the CMDS ABEND
| command. If the command is in a state making it non-abendable, use the CMDS
| FORCE command after understanding the following recommendations
| associated with the FORCE parameter:
| – After issuing CMDS FORCE, you might have to re-IPL the system or,
| depending on the command being terminated, a sysplex-wide IPL may be
| required.
| – You should ensure that the target command is hung and not just requiring
| additional time to complete.

| v For details about the CMDS command, see z/OS MVS System Commands.
| v See message CNZ6002I COMMAND command WITH ID id NOT ABENDABLE
| in z/OS MVS System Messages, Vol 4 (CBD-DMO).

| Ensure Runtime Diagnostics is installed before invoking
| Predictive Failure Analysis
| Description: Beginning with z/OS V1R13, Predictive Failure Analysis (PFA) calls
| Runtime Diagnostics to analyze and report insufficient metric activity from the
| following checks:
| v PFA_ENQUEUE_REQUEST_RATE
| v PFA_MESSAGE_ARRIVAL_RATE
| v PFA_SMF_ARRIVAL_RATE

| Therefore, PFA requires the Runtime Diagnostics address space (HZR) to be active
| on any system it analyzes.
|
| Is the migration action required? Yes, if you plan on using the following
| checks:
| v PFA_ENQUEUE_REQUEST_RATE
| v PFA_MESSAGE_ARRIVAL_RATE
| v PFA_SMF_ARRIVAL_RATE
| requirements:


| System impacts: If RTD isn't running and PFA calls it, the call
| to RTD returns with a return code of 12 and
| a reason code of 3074 (C02), and PFA
| processing skips the potential exception
| because it could not be confirmed through
| RTD (as in previous releases without this
| z/OS V1R13 enhancement). If or when RTD
| ever becomes active, the calls will become
| successful. The return code and reason code
| are logged in the systemnameRUN.LOG for
| the check, as follows:
| Calling to determine too low
| Return code = 0000000C
| Reason code = 00000C02
| check:
|

| Steps to take: Ensure the HZR is defined as a system address space. See “Start
| Runtime Diagnostics at system initialization” on page 109.

| Reference information: For complete details about using Runtime Diagnostics, see
| the topics Runtime Diagnostics overview and Predictive Failure Analysis overview
| and installation in z/OS Problem Management.

| Carry over your existing CPCC policy
| Description: The Capacity Provisioning Control Center (CPCC) can coexist with
| older versions of the CPCC on a workstation. However, z/OS V1R13 CPCC uses a
| different default workspace. If you want to continue using your existing CPCC
| workspace, point to the respective directory during the installation of z/OS V1R13
| CPCC. It is also possible to change the workspace when the CPCC starts.
|
| Is the migration action required? Yes, if you want to continue using your
| existing CPCC workspace.
| Other system (coexistence or fallback) You must run a level of the CPCC client that
| requirements: corresponds to the z/OS system that you
| target. For example, run the z/OS V1R13
| CPCC client on the workstation when
| interacting with the z/OS V1R13 Capacity
| Provisioning Manager, and run the z/OS
| V1R12 CPCC client on the workstation when
| interacting with the z/OS V1R12 Capacity
| Provisioning Manager.
| check:
|


| Steps to take:
| v Install z/OS V1R13 CPCC using information in documentation referenced below.

| Note: With z/OS V1R13, the location of the default workspace changes from, for
| example,
| C:Documents and SettingsuserApplication DataIBMIBM Capacity
| Provisioning Control Center

| to
| C:Documents and SettingsuserApplication DataIBMIBM Capacity
| Provisioning Control Center V1R13

| The actual directories depend on the Windows version that you are using.
| v If you want to continue using your existing (pre-z/OS V1R13) CPCC workspace,
| point to the desired workspace during the installation process. You can also
| switch the workspace at a later time by navigating to the desired workspace
| when the CPCC starts.

| Reference information: For more information about installing and uninstalling
| CPCC, see z/OS MVS Capacity Provisioning User's Guide.

Evaluate applications that parse AMBLIST command
LISTLOAD or LISTIDR output
Description:
1. Prior to z/OS V1R12, the AMBLIST command LISTLOAD output for load
modules, in the MODLIST area of the output, AMBLIST printed only the
hexadecimal representation of TEXT records.
Beginning with z/OS V1R12, AMBLIST command LISTLOAD output for load
modules is made to work similarly to the same output for program objects. In
particular, the output now includes the TEXT records output in EBCDIC format
to the right of the hexadecimal representation. This also means that some of the
columns for the hexadecimal output have been shifted.
2. Prior to z/OS V1R12, the AMBLIST commands LISTLOAD and LISTIDR
output header for UNIX program objects printed the constant **UNIX** for
both MEMBER NAME and LIBRARY, in the output header for each processed
UNIX program object.
Beginning in z/OS V1R12, AMBLIST commands LISTLOAD and LISTIDR
output header for UNIX program objects display the actual directory path
name and file name of the UNIX file. It is represented this way regardless of
whether or not the MEMBER is specified as a relative path name. Note that
MEMBER NAME and LIBRARY still only utilize a single output line each,
therefore, if either exceeds the number of allotted characters they will be
truncated on the left and preceded by two periods and a space (.. ).

Timing: After the first IPL of z/OS V1R13.
Is the migration action required? Yes, if your application depends on the
output generated by the AMBLIST command
LISTLOAD or LISTIDR control statement
processing.


requirements:
Restrictions: None.
check:

Steps to take: Output from the AMBLIST command is not an intended
programming interface.
1. Evaluate applications that parse AMBLIST command LISTLOAD output to
ensure that either there is no dependency on the TEXT output alignment or the
additional data to the right of the hexadecimal output.
2. Evaluate applications that parse AMBLIST command LISTLOAD or LISTIDR
output to ensure that there is no dependency on either the MEMBER NAME or
LIBRARY in the output header being the constant **UNIX** or any other
particular format.
To reduce future impact and maintenance, IBM suggests migrating the parsing
routines or applications to use an IBM provided programming interface such as the
Program Management APIs. See Using the binder application programming
interfaces (APIs) inz/OS MVS Program Management: Advanced Facilities.

The following example shows the TEXT output from LISTLOAD
OUTPUT=MODLIST of a load module (note that the MODLIST output is included
with other output specifications, including when the OUTPUT option is not
specified). The output for load modules now has the same alignment as for
program objects, except that the offset field for load modules continues to 6
characters wide whereas it is 8 characters wide for program objects:
v Before z/OS V1R12:
RECORD# 6 T E X T
000000 E3C1E2E3 C5E240C1 D9C540C4 C9C6C6C5 D9C5D5E3 F0F1F2F3 F4F5F6F7 F8F9F0F1
000020 F2F3F4F5 F6F7F8F9
******END OF LOAD MODULE LISTING
v With z/OS V1R12:
RECORD# 6 T E X T
000000 E3C1E2E3 C5E240C1 D9C540C4 C9C6C6C5 D9C5D5E3 F0F1F2F3 F4F5F6F7 F8F9F0F1
*TASTES ARE DIFFERENT012345678901*
000020 F2F3F4F5 F6F7F8F9
*23456789 *
******END OF LOAD MODULE LISTING

The following example shows the output header from LISTLOAD of a UNIX
program object.
v Before z/OS V1R12:
LISTLOAD MEMBER=llllllll/a.out
***** M O D U L E S U M M A R Y *****
MEMBER NAME: **UNIX**
LIBRARY: **UNIX**
v With z/OS V1R12:


LISTLOAD MEMBER=llllllll/a.out
***** M O D U L E S U M M A R Y *****
MEMBER NAME: a.out
LIBRARY: .. eeeeee/ffffffff/gggggggg/hhhhhhhh/iiiiiiii/jjjjjjjj/llllllll

Reference information: For details about the AMBLIST command, see z/OS MVS
Diagnosis: Tools and Service Aids.

Ensure analysis tools interacting with HIS output
accommodate HIS state change events
Description: Hardware instrumentation services (HIS) is a function that collects
hardware event data for processors in SMF records type 113, subtype 2, as well as
UNIX System Services output files. You can only use HIS for IBM System z10 or
later machines. In z/OS V1R12 (and in z/OS V1R11with the PTF for APAR
OA30486 installed), functionality is added to the HIS component which causes
changes in the output filename formats produced by HIS (.CNT, .SMP, .MAP), as
well as introducing additional lines to the .CNT file possibly causing
incompatibilities. In addition, an increase in SMF Type 113 records might be
noticed.

Any tools that programmatically open the HIS output files (.CNT, .MAP, or .SMP),
and any tools that programmatically analyze the HIS output .CNT file, should be
analyzed and updated to accommodate the new formats.

Is the migration action required? Yes, if you start HIS and have programs that
analyze the HIS output.
requirements:
Restrictions: None.
check:

Steps to take:
v What to look for:
– The new filename output format is an indication that the support is installed.
– The first line of the .CNT file indicates output version 2.
– New output message HIS032I “STATE CHANGE DETECTED
ACTION=action.”
– An additional line in the output of DISPLAY HIS command, which describes
the action that should be taken should a state change event occur (specified
by the operator at the start of a collection run).
v What to do:


– If programmatically opening files, ensure the new output file format is
handled.
– If programmatically parsing the .CNT file, ensure to check the VERSION
identifier in the header. If the identifier is VERSION 2, be prepared for the
new STATECHANGE line.

Reference information: For additional information about HIS state change events,
see z/OS MVS System Commands.

Detect program objects that have multiple INITIAL LOAD
segments
Description: Prior to z/OS V1R12, the binder RMODE option only applied to the
first module segment, which contains some but possibly not all the initial load
classes, though always the class wherein lies the entry point. Subsequent segments
containing other initial load classes were not affected by the RMODE option, and
thus the binder determined the RMODE based on the attributes of the classes
contained therein.

Beginning with z/OS V1R12, the binder RMODE option applies to all initial load
classes by default. Thus all segments containing initial load classes are affected.
This new behavior takes affect only when the RMODE binder option is specified.
Also the RMODE option has been expanded so that either the new or previous
behavior can be explicitly requested.

Is the migration action required? Yes, with the following conditions.

Only users or ISVs that produce program
object programs, which might have multiple
INITIAL LOAD segments, need to take
action if all of the items listed below are true:
v Program is required to reside in a program
object.
v Program has multiple segments.
v Program has multiple initial load classes.
v Program has mixed RMODEs.
v Program is link-edited with the RMODE
option to override the binder default.

Note: In most cases, even if a program has
multiple segments containing INITIAL
LOAD classes, no action is required.
Other system (coexistence or fallback) Install compatibility PTFs for APAR OA30988
requirements: on z/OS V1R11 systems.
Restrictions: None.
System impacts: Above-the-line and below-the-line storage
usage might change.


check:

Steps to take: To determine whether you might be affected by this change, you can
run the AMBLIST service aid against your program objects and examine the
output. However, if you do not explicitly specify the RMODE option when you
bind the program, it is not affected even if the following two conditions are true.

Run AMBLIST using the LISTLOAD control statement. Using the OUTPUT=MAP
option results in a smaller amount of output that still contains the pertinent
information.

The following two conditions must both be true for the program to be affected by
the new RMODE option behavior:
1. In the Module Summary, only programs that are program objects and are
PO FORMAT: 3

or higher are affected.
2. In the SEGMENT MAP, only programs for which there is class entry SEGMENT
2, and TYPE INITIAL, are affected.

Note: The RMODE differs for the SEGMENT 1, INITIAL load classes, and the
SEGMENT 2, INITIAL load classes.

Given that these two conditions are true, there are then generally three possible
situations:
1. If the RMODE option is not being specified, there is no need to do anything, as
| the behavior is identical to z/OS V1R11.
2. If you specified RMODE=ANY, expected all segments to be RMODE=31, but
find that one segment is RMODE=24, part of the program is using
below-the-line storage. In most cases, this is not desirable and the new binder
behavior will remedy the situation.
It is possible that you rely on having part of the program use below-the-line
storage. You can use RMODE(ANY,COMPAT) to revert to the pre-z/OS V1R12
behavior.
3. If you specified RMODE=24, expected all segments to be RMODE=24, but find
that one segment is RMODE=31, part of the program is using above-the-line
storage. In most cases, this is desirable and the new binder behavior could
cause a problem by causing the program to use more below-the-line storage.
It is also possible that you rely on having part of the program use
above-the-line storage. You can use RMODE(24,COMPAT) to revert to the
pre-z/OS V1R12 behavior.

Reference information: For more information about using the RMODE option, see
z/OS MVS Program Management: User's Guide and Reference.


Chapter 6. Communications Server migration actions
Communications Server actions to perform before SNA Services: Ensure VTAMSG2 in not used in
installing z/OS V1R13 . . . . . . . . . . 135 your VTAMLST definitions . . . . . . . . 150
| IP Services: Define a user ID for the system Communications Server actions to perform before
| resolver with an associated OMVS segment . . 135 the first IPL of z/OS V1R13 . . . . . . . . 151
| IP Services: Ensure storage availability for | IP Services: Review VIPARANGE definitions 151
| ancillary input queue for Enterprise Extender IP Services: Update automation that keys on
| traffic . . . . . . . . . . . . . . . 137 TN3270E Telnet server messages . . . . . . 152
| IP Services: Permit IKE daemon running in FIPS IP Services: Ensure the TN3270E Telnet server
| mode to use additional ICSF services . . . . 138 can end automatically when an OMVS
| IP Services: Migrate from BIND 9.2.0 . . . . 139 shutdown command is issued . . . . . . . 152
| IP Services: Understand and prepare for IP Services: Disable resolver monitoring of name
| expanded Intrusion Detection Services . . . . 140 server responsiveness. . . . . . . . . . 153
| IP Services: Ensure that the FTP user exit IP Services: Disable IP validation checks when
| routine FTCHKPWD tolerates an additional defining key exchange policy rules for a
| parameter . . . . . . . . . . . . . 141 dynamic VPN . . . . . . . . . . . . 154
| IP Services: Understand change in VIPARANGE IP Services: Update modified Netstat message
| security verification processing . . . . . . 142 catalogs to include timestamp . . . . . . . 155
IP Services: Update IP filter policy to filter IP IP Services: Update /etc configuration files . . 156
fragments correctly for RFC 4301 compliance . . 143 | SNA Services: Adjust to the relocation of the
IP Services: Remove customization of SNMP | VTAM internal trace table . . . . . . . . 157
sysObjectID MIB object in OSNMPD.DATA file . 145 SNA Services: Disable Enterprise Extender
IP Services: Restore resolver UDP request connection health verification . . . . . . . 161
timeout interval duration . . . . . . . . 146 SNA Services: Code MULTPATH start option
IP Services: Ensure applications tolerate a larger when using multipath . . . . . . . . . 161
addrinfo structure . . . . . . . . . . . 147 Communications Server actions to perform after
IP Services: Release addrinfo storage after the first IPL of z/OS V1R13 . . . . . . . . 162
resolver thread task terminates . . . . . . 148 IP Services: Ensure that preference values
IP Services: Update syslogd configuration for associated with IPv6 router advertisement
archiving rules with shared z/OS UNIX file routes are as expected . . . . . . . . . 162
destinations . . . . . . . . . . . . . 149
| SNA Services: Ensure IVTCSM
| ASSIGN_BUFFER requests do not exceed 500
| images for a single CSM buffer . . . . . . 150

This topic describes migration actions for base element Communications Server.

Communications Server actions to perform before installing z/OS
V1R13
This topic describes Communications Server migration actions that you can
perform on your current (old) system. You do not need the z/OS V1R13 level of
code to make these changes, and the changes do not require the z/OS V1R13 level
of code to run once they are made.

| IP Services: Define a user ID for the system resolver with an
| associated OMVS segment
| Description: Starting with z/OS V1R13, the system resolver uses z/OS UNIX
| services in the resolver address space. Use of z/OS UNIX services requires the
| resolver to have an OMVS segment associated with its user ID. If you do not
| define a user ID for the resolver with an associated OMVS segment, the resolver
| initialization will fail and the TCP/IP stack initialization will not be able to
| complete.


|
| Element or feature: Communications Server.
| Is the migration action required? Yes, if you do not have a user ID defined for
| the system resolver that has an associated
| OMVS segment, which provides access to
| z/OS UNIX services.
| requirements:
| System impacts: If you do not define a user ID for the system
| resolver that includes an OMVS segment, the
| resolver initialization will fail and the
| initialization of all TCP/IP stacks will be
| delayed.
| check:
|

| Steps to take:
| 1. If you already have a user ID for the system resolver started procedure, and
| you explicitly defined an OMVS segment for the ID, or an OMVS segment was
| created automatically through the RACF automated assignment of unique
| UNIX identities support or through default OMVS segment support, no action
| is required.
| 2. If you already have a resolver user ID but it does not have an OMVS segment,
| you must define an OMVS segment for the resolver user ID.
| 3. If you do not have a resolver user ID, you must create one that includes an
| OMVS segment.
| The following information is an excerpt of the SEZAINST(EZARACF) sample job
| that you can use to define a user ID with an OMVS segment and assign it to the
| system resolver started procedure. You might need to modify the sample values
| that are specified in the commands for your environment. For example, the UID,
| Default Group, and Resolver user ID values are sample values.
| //*=========================== RESOLVER ===============================
| //*====================================================================
| //*====================================================================
| //*
| //* Create the userid and its OMVS Segment for the daemon and
| //* add it to the STARTED Class which is activated in this job.
| //*
| //* If you chose not to use the RACF STARTED Class,
| //* the entry should be placed in the started procedures table ICHRIN03.
| //*
| //RESOLVER EXEC PGM=IKJEFT01
| //SYSTSPRT DD SYSOUT=*
| //SYSTSIN DD *
| SETROPTS CLASSACT(STARTED)
| SETROPTS RACLIST(STARTED)
| SETROPTS GENERIC(STARTED)
| ADDUSER RESOLVER DFLTGRP(OMVSGRP) OMVS(UID(42) HOME(’/’)) -
| NOPASSWORD


| RDEFINE STARTED RESOLVER.* STDATA(USER(RESOLVER))
| SETROPTS RACLIST(STARTED) REFRESH
| SETROPTS GENERIC(STARTED) REFRESH
| //*

| Reference information: For information about defining and assigning a user ID for
| started procedures, see Using Started Procedures in z/OS Security Server RACF
| Security Administrator's Guide.

| For information about defining an OMVS segment, see RACF and z/OS Unix in
| z/OS Security Server RACF Security Administrator's Guide.

| For general information about the system resolver, see Steps for defining the
| resolver address space in z/OS Communications Server: IP Configuration Guide.

| IP Services: Ensure storage availability for ancillary input
| queue for Enterprise Extender traffic
| Description: In z/OS V1R13, the processing of IPAQENET and IPAQENET6
| INTERFACE statements is enhanced. Coding the WORKLOADQ parameter on
| these INTERFACE statements now enables the QDIO inbound workload queueing
| function for Enterprise Extender (EE) traffic. An additional ancillary input queue
| (AIQ) is established for inbound traffic for EE if HPR=RTP is specified as a VTAM
| start option. Each AIQ increases storage utilization by an amount equal to 36K of
| fixed ECSA, plus potentially the READSTORAGE value (64K multiplied by the
| number of SBALs) of fixed CSM 4K data space storage. If you have configured
| QDIO inbound workload queuing, you must ensure that there is sufficient fixed
| ECSA and 4K CSM dataspace storage for the AIQ for EE traffic.
|
| Applies to migration from: z/OS V1R12.
| Is the migration action required? No, but recommended if you have the
| WORKLOADQ parameter specified on the
| INTERFACE statement and you have
| concerns about using additional storage.
| Target system hardware requirements: This migration action is required only if you
| are using OSA-Express3, or later, features on
| an IBM zEnterpsie z196.
| requirements:
| System impacts: Each AIQ increases storage utilization by an
| amount equal to 36K of fixed ECSA plus
| potentially the READSTORAGE value (64K
| multiplied by the number of SBALs) of fixed
| CSM 4K data space storage.
| check:
|

| Steps to take:

Chapter 6. Communications Server migration actions 137

| 1. Verify if you are using EE; you are using EE if HPR=RTP is defined as a VTAM
| start option and if an EE XCA Major Node is defined and active. If you are
| using EE, continue with steps 2-5. If you have HPR=RTP defined as a VTAM
| start option but do not have an EE XCA Major Node defined and active,
| continue with steps 2, 3 and 5. Otherwise there is no increase in storage usage
| and no further action is required.
| 2. Count the total number of OSA-Express3, and later, interfaces that are coded
| with the WORKLOADQ parameter on the IPAQENET and IPAQENET6
| INTERFACE statements. Make a note of the number.
| 3. Verify that sufficient ECSA is available. To do this, multiply the total number of
| OSA-Express3, and later, interfaces that have inbound workload queueing
| enabled (you determined this number in step 2) by 36K. The resulting number
| indicates how much new ECSA is required. Use the DISPLAY CSM command
| to verify that sufficient ECSA is available to enable this function.
| 4. Verify that sufficient real storage is available. 64-bit real storage is used for the
| dataspace read buffers. Multiply the total number of OSA-Express3, and later,
| interfaces that have inbound workload queueing enabled (determined in step 2)
| by 64K and by 126 (8064K). The maximum number of read buffers per queue is
| 126. The resulting number is approximately the amount of additional 64-bit real
| storage that is required for the data space read buffers for all the new EE input
| queues.
| 5. If sufficient storage is not available, either increase the available storage or
| consider defining some of the OSA-Express3, and later, INTERFACE statements
| with the NOWORKLOADQ parameter.

| Reference information: Performance improvements for Enterprise Extender traffic
| in z/OS Communications Server: New Function Summary

| IP Services: Permit IKE daemon running in FIPS mode to use
| additional ICSF services
| Description: In z/OS V1R13, the Internet Key Exchange (IKE) daemon is enhanced
| to take advantage of new services that are provided by Integrated Cryptographic
| Service Facility (ICSF) when the IKE daemon is running in Federal Information
| Processing Standards (FIPS) mode. The new ICSF services are provided in updates
| to ICSF PKCS number 11 functions CSFPDVK and CSFPDMK. ICSF now provides
| the following information to the IKE daemon, each with a single call to ICSF:
| v The derivation of the original seed key.
| v The phase 1 key set.
| v The phase 2 key set.
|
| Is the migration action required? Yes, if you currently run the IKE daemon in
| FIPS mode and if you control the access to
| ICSF resources in the CSFSERV class.
| requirements:


| check:
|

| Steps to take:
| v The IKE daemon now requires READ access to the CSF1DVK and CSF1DMK
| resources in CSFSERV when the IKE daemon is configured to run in FIPS mode.
| v If your security server is RACF, issue the following commands in the order
| shown. If you use a different security server, determine and perform the
| equivalent steps.
| 1. PERMIT CSF1DVK CLASS(CSFSERV) ID(IKED) ACCESS(READ)
| 2. PERMIT CSF1DMK CLASS(CSFSERV) ID(IKED) ACCESS(READ)
| 3. SETROPTS RACLIST(CSFSERV) REFRESH

| Reference information: For details, see the steps for setting up profiles in the
| CSFSERV resource class in z/OS Communications Server: IP Configuration Guide.

| IP Services: Migrate from BIND 9.2.0
| Description: IBM intends for z/OS V1R13 to be the final release in which the z/OS
| BIND 9.2.0 function is available. If you are using this function as a server, you
| must find a replacement as soon as you can.
|
| When change was introduced: The removal of the BIND 9.2.0 function was
| first announced in February 2009. z/OS
| V1R13 is the final release in which the BIND
| 9.2.0 function is available.
| Is the migration action required? Yes, if are using the BIND 9.2.0 function as a
| server.
| requirements:
| Related IBM Health Checker for z/OS Use ZOSMIGV1R11_CS_BIND9 for BIND
| check: 9.2.0 to determine if a z/OS BIND 9.2.0 name
| server is in use.
|

| Steps to take:
| v If you have been using z/OS BIND 9.2.0 as a caching-only name server, use the
| z/OS resolver DNS caching function to cache DNS responses.
| v If you have been using z/OS BIND 9.2.0 as a primary or secondary authoritative
| name server, investigate using BIND on Linux for System z or BIND on an IBM
| blade in a zBX.


| Reference information: For details about the resolver, see z/OS Communications
| Server: IP Configuration Guide and z/OS Communications Server: IP Configuration
| Reference.

| IP Services: Understand and prepare for expanded Intrusion
| Detection Services
| Description: Beginning in z/OS V1R13, Intrusion Detection Services (IDS) is
| enhanced to monitor IPv6 traffic. This includes scan detection and reporting, attack
| detection, attack reporting, attack prevention, and traffic regulation. Additional
| attack detection, reporting, and prevention are also provided for IPv4 traffic.
|
| Timing: Before installating z/OS V1R13.
| Is the migration action required? Yes, if you are using IDS on a stack that is
| being run as a dual-mode stack (IPv4 and
| IPv6).
| requirements:
| check:
|

| Steps to take:
| 1. If any of the following IDS attack types are enabled, be aware that both IPv4
| and IPv6 traffic will be monitored for attacks of these types:
| v Malformed attack type
| v UDP perpetual echo attack type
| v Flood attack type
| v ICMP redirect attack type
| 2. If you use the trmdstat command to get a consolidated view of IDS log records,
| be aware that the default report, provided when the trmdstat command is
| issued with no report option, will be the IDS Summary report. The IDS
| Summary report provides a summary of all IDS information.
| 3. If you have a TCP scan rule that applies to all local IP addresses (such as when
| the LocalHostAddr All is specified explicitly or by default in the policy), then
| TCP scan events will be detected for both IPv4 and IPv6 packets. If you want
| the TCP scan rule to continue to only detect scan events for IPv4 packets,
| modify the rule to specify a local IP address of 0.0.0.0/0.
| 4. If you have a UDP scan rule that applies to all local IP addresses (such as when
| UDP scan events will be detected for both IPv4 and IPv6 packets. If you want
| the UDP scan rule to continue to only detect scan events for IPv4 packets,
| modify the rule to specify a local IP address of 0.0.0.0/0.


| 5. If you have a TCP traffic regulation (TR) rule that applies to all local IP
| addresses (such as when the LocalHostAddr All is specified explicitly or by
| default in the policy), then limits will be enforced for both IPv4 and IPv6
| connection requests. If you want the TCP TR rule to continue to only enforce
| limits for IPv4 connection requests, modify the rule to specify a local IP address
| of 0.0.0.0/0.
| 6. If you have a UDP TR rule that applies to all local IP addresses (such as when
| limits will be enforced for both IPv4 and IPv6 packets. If you want the UDP TR
| rule to continue to only enforce limits for IPv4 packets, modify the rule to
| specify a local IP address of 0.0.0.0/0.
| 7. If you use LDAP to configure IDS policy and you are using the default value
| for attribute ibm-idsLocalHostIPAddress with a TCP scan, UDP scan, TCP TR,
| or UDP TR rule, events will be detected and limits will be enforced for both
| IPv4 and IPv6 traffic. If you want these rules to continue to apply to only IPv4
| traffic, modify the attribute to specify ibm-idsLocalHostIPAddress:3-0.0.0.0-0.

| Reference information: For details, see the following:
| v Intrusion Detection Services in z/OS Communications Server: IP Configuration
| Guide
| v IBM Configuration Assistant for z/OS Communications Server online help; see
| the What's New in V1R13 help information for IDS configuration
| v IDS policies defined in IDS configuration files in z/OS Communications Server: IP
| Configuration Reference

| IP Services: Ensure that the FTP user exit routine FTCHKPWD
| tolerates an additional parameter
| Description: Starting in z/OS V1R13, the z/OS FTP server is enhanced to allow
| logging into FTP with a password phrase. An additional parameter describing the
| password or password phrase that is used to log into the z/OS FTP server is now
| passed to the FTCHKPWD user exit. If you have installed an FTCHKPWD exit
| routine, and your exit routine meets one or both criteria listed in Is the migration
| action required? below, then you must take action.
|
| Is the migration action required? Yes, if your installation uses the FTCHKPWD
| user exit routine, and if one of the following
| conditions is true:
| v Your exit routine cannot tolerate an
| additional parameter passed to the exit
| routine.
| v Your exit routine inspects or processes the
| password parameter in any way.
| requirements:


| check:
|

| Steps to take:
| v Inspect your FTCHKPWD user exit routine. Modify as needed to support the
| additional parameter.

| v The FTCHKPWD user exit in z/OS Communications Server: IP Configuration Guide.
| v The FTCHKPWD user exit in z/OS Communications Server: IP Configuration
| Reference.

| IP Services: Understand change in VIPARANGE security
| verification processing
| Description: Prior to z/OS V1R13, the System Authorization Facility (SAF)
| resource profile associated with the VIPARANGE statement
| (EZB.BINDDVIPARANGE.sysname.tcpname) was ignored in the following scenario
| when an application issues a bind:
| v The port specified on the bind matches a PORT statement, and
| v the IP address of the application's bind is within a VIPARANGE subnet, or the
| application's bind is an unspecified address and the IP address on the BIND
| parameter of the PORT statement is within a VIPARANGE subnet.

| In this scenario, the PORT statement (including its optional SAF parameter) was
| used to control access to both the port and to creating the dynamic VIPA (DVIPA).

| Beginning in V1R13, the VIPARANGE resource profile is not ignored in this
| scenario; creation of the IP address is controlled by both the SAF resource profile
| associated with the VIPARANGE statement and by the PORT statement:
| v For a VIPARANGE statement, you can control the creation of the IP address by
| defining the following SAF resource profiles in the SERVAUTH class:
| – EZB.BINDDVIPARANGE.sysname.tcpname
| – EZB.BINDDVIPARANGE.sysname.tcpname.resname, if the new SAF parameter
| is included on the VIPARANGE statement
| v The PORT statement controls whether an application can bind to a given port.
|
| Is the migration action required? Yes, if you have defined the
| EZB.BINDDVIPARANGE.sysname.tcpname
| resource profile, but you have not given
| READ access to this resource to all
| applications that create DVIPAs by binding
| to addresses that are within a VIPARANGE
| subnet.


| requirements:
| check:
|

| Steps to take: Be aware that the EZB.BINDDVIPARANGE.sysname.tcpname resource
| profile is always checked if defined; ensure all applications that create DVIPAs by
| binding to addresses within a VIPARANGE subnet have READ access to this
| resource.

| v Enhanced security for binding to DVIPAs in z/OS Communications Server: New
| Function Summary
| v Defining a security profile for SIOCSVIPA, SIOCSVIPA6, and MODDVIPA in
| z/OS Communications Server: IP Configuration Guide
| v Defining a security profile for binding to DVIPAs in the VIPARANGE statement
| in z/OS Communications Server: IP Configuration Guide
| v VIPARANGE statement in z/OS Communications Server: IP Configuration Reference

IP Services: Update IP filter policy to filter IP fragments
correctly for RFC 4301 compliance
Description: Beginning with z/OS V1R12, all IP security filters must be compliant
with RFC 4301. You can no longer use the RFC4301Compliance parameter on the
IpFilterPolicy statement to specify whether Policy Agent enforces compliance. The
RFC4301Compliance parameter is ignored and Policy Agent enforces the rule that
ensures all IP filters are compliant.

IP filter policy support for filtering fragments was improved in z/OS V1R10.
Before z/OS V1R10, Communications Server filtered all IP fragments using a
policy of first possible filter match and filtered IPv6 fragments as protocol
IPv6Frag. Beginning with z/OS V1R10, Communications Server follows rules and
restrictions established by RFC 4301 (http://www.ietf.org/rfc/rfc4301.txt) to
ensure proper classification of fragments. RFC 4301, “Security Architecture for the
Internet Protocol”, specifies the base architecture for IPSec-compliant systems,
including restrictions on the routing of fragmented packets.

Communications Server does not implement stateful fragment checking, therefore,
restrictions were added as required by RFC 4301 to require that IP filter rules for
routed traffic do not allow specific ports, types, or codes. The configuration
parameter RFC4301Compliance could be used in z/OS V1R10 and z/OS V1R11 to
optionally configure whether the RFC 4301 rules should be applied. Beginning
with z/OS V1R12, this parameter (RFC4301Compliance on the IpFilterPolicy
statement) is deprecated. All IP filter rules must support the RFC 4301 rules and
restrictions.

Element or feature: Communications Server.


Is the migration action required? Yes, if your IP filter policy selectively
matches routed traffic based on TCP port,
UDP port, ICMP type and code, ICMPv6
type and code, OSPF type, or MIPv6 type. If
you configured the RFC4301Compliance
parameter on the IpFilterPolicy statement, it
is recommended that you remove the
parameter because it is deprecated beginning
with z/OS V1R12.
requirements:
Restrictions: None.
check: ZOSMIGV1R11_CS_RFC4301 to determine if
IPSec filter rules are compliant with
RFC4301.

Steps to take: If you currently use the IBM Configuration Assistant for z/OS
Communications Server to configure your IP security policy, perform the following
steps:
v If each configured TCP/IP stack has the RFC 4301 setting marked compliant, no
migration action is required. By default, the RFC 4301 setting is marked
compliant.
v Otherwise, for each stack with the RFC 4301 setting marked not compliant:
1. Change the setting to compliant. Click Apply Changes and a report will be
displayed.
2. Study the report. The report indicates if any rules were detected that are not
RFC 4301 compliant, and it explains the reasons why.
3. If the report indicates a user action is required, go to each rule marked as
incomplete, select the rule, and click the View Details button to determine
the user action required. Edit each rule to make the correction.

If you manually configure your IP security policy, use Policy Agent to identify any
IP security filter rules that are not compliant with RFC 4301.
v If you have implemented the RFC4301Compliance parameter on the
IpFilterPolicy statement with a setting of Yes in your current release, no
migration action is required. You may optionally remove the parameter because
it is deprecated in V1R12. Beginning with V1R12, Policy Agent will log a
warning message if the RFC4301Compliance parameter is configured. Policy
Agent will enforce that all IP security rules are compliant with RFC 4301.
v Otherwise (you have not implemented the RFC4301Compliance parameter with
a setting of Yes in your current release), review your Policy Agent log file to
determine if there are any configured rules that are not compliant with RFC
4301. Policy Agent will identify any filter rules that are not compliant with RFC
4301 as warnings in release V1R11.
1. If Policy Agent does not identify any filter rules that are not compliant with
RFC 4301, no migration action is required.
2. If Policy Agent identifies filter rules that are not compliant with RFC 4301,
perform the following steps to ensure that all IpFilterRule objects pertaining

to routed traffic do not distinguish between port, type, or code values. For
this process, identify all IpFilterRule objects that pertain to routed traffic (for
example, objects that have an IpService Routing specification of Routed or
Either). For each of these IpFilterRule objects, perform the following steps:
a. If the IpService Routing specification is Either but the filter rule applies
only to local traffic, correct the Routing specification to read Local.
b. If the IpService Routing specification is Routed and the filter rule applies
to certain specific ports, types, or codes, perform the following steps:
1) Identify all IpFilterRule objects that apply to routed traffic between
the same or overlapping endpoints as the IpFilterRule under
consideration.
2) z/OS V1R12 Communications Server requires that the same filter
policy action be applied to all ports, types, or codes between the same
routed endpoints. This is necessary because of the inherent ambiguity
in determining the correct policy action to take for fragments in which
these values are unknown. At your choice, you may apply the same
policy action to a single IP protocol or to all IP protocols between the
same routed endpoints. Consult the filter rules identified in the
previous step and choose an appropriate filter action of deny, permit,
or ipsec to be applied to all of this traffic. If you choose an action of
ipsec, choose an appropriate level of IPSec protection for all of this
traffic.
3) Create a single IpFilterRule for the traffic identified in the previous
step pertaining to all port, type, or code values or to all protocols, at
your choice and with the filter action of your choice.
4) Remove all port-, type-, and code-specific IpFilterRule objects that
were previously identified as pertaining to routed traffic between the
same pair of endpoints as the IpFilterRule under consideration.
5) Change the policy at the corresponding security endpoint to match
the changes made to local policy.
6) For this routed traffic, enforce sufficient IP filter policy at the final IP
traffic destination node to ensure that unwanted traffic is denied
based on the port-, type-, or code-specific IpFilterRule objects that
were previously removed from the local policy.
c. If the IpService Routing specification is Either and the filter rule applies
to certain specific ports, types, or codes, perform the following steps:
1) Create two copies of this filter rule, one of which has a Routing
specification of Local and one of which has a Routing specification of
Routed.
2) Leave the Local filter rule unchanged; for the Routed filter rule,
perform the steps listed in 2b to apply new routed traffic restrictions.
d. Otherwise, no change is necessary for this IpFilterRule.

v “IpService statement” in z/OS Communications Server: IP Configuration Reference

IP Services: Remove customization of SNMP sysObjectID MIB
object in OSNMPD.DATA file
Description: The SNMP agent allows you to provide some initial settings for a
small set of MIB objects by using the OSNMPD.DATA file. One of the objects for
which an initial value can be provided is sysObjectID.0. The sysObjectID.0 object is
the vendor's authoritative identification of the network management subsystem


contained in the entity. That is, it is intended to uniquely identify the SNMP agent.
Changing this value is not recommended and the ability to change it will be
disabled in a future release. As of z/OS V1R4, warning message EZZ6317I is
written to the syslog daemon if the object is set by using the OSNMPD.DATA file.
As of z/OS V1R8, message EZZ6317I is also written to the console.

When change was introduced: Future removal of the ability to customize
the sysObjectID value was announced in the
z/OS V1R4 time frame. Message EZZ6317I is
written to the syslog daemon as of z/OS
V1R4, and to both the syslog daemon and
console as of z/OS V1R8.
Is the migration action required? No, but recommended because the ability to
customize the sysObjectID value is planned
to be removed in a future release.
requirements:
Restrictions: None.
Related IBM Health Checker for z/OS
check:

Steps to take: Review the statements in your OSNMPD.DATA configuration file. If
this file contains a statement for the sysObjectID object, remove the statement from
the file.

Reference information: For details about statements in the OSNMPD.DATA
configuration file, see the network management topic of z/OS Communications
Server: IP Configuration Guide.

IP Services: Restore resolver UDP request timeout interval
duration
Description: Prior to z/OS V1R12, the default setting for considering UDP requests
to a name server to have timed out (as specified by the TCPIP.DATA
RESOLVERTIMEOUT statement) was 30 seconds. Starting with z/OS V1R12, the
default is 5 seconds. If you want the resolver to continue to use the old value, you
must take action.

Is the migration action required? Yes, if your network requires longer than 5
seconds for resolver queries to be processed
by a name server under normal network
conditions.


requirements:
Restrictions: None.
check:

Steps to take:
v Code the RESOLVERTIMEOUT 30 statement in each TCPIP.DATA dataset where
the previous UDP timeout duration interval is needed.
v If the resolver is active when all the TCPIP.DATA datasets are updated, issue the
MODIFY resolver,REFRESH command to cause the resolver to refresh the
TCPIP.DATA settings.
v If the resolver is not active, start the resolver.

v RESOLVERTIMEOUT statement in z/OS Communications Server: IP Configuration
Reference
v MODIFY command: Resolver address space in z/OS Communications Server: IP
System Administrator's Commands

IP Services: Ensure applications tolerate a larger addrinfo
structure
Description: The addrinfo structure is used by the getaddrinfo() function to hold
host address information. In z/OS V1R12, the addrinfo structure (struct addrinfo)
is enhanced to comply with RFC 5014. As a result, the struct addrinfo is larger
than it was prior to z/OS V1R12. When the res parameter returned by
getaddrinfo() is a chain of pointers to struct addrinfo structures, the pointers point
to the larger struct addrinfo.

Is the migration action required? Yes, because your application might have a
dependency on the size of the struct addrinfo
structures returned by the getaddrinfo()
subroutine points.
requirements:
Restrictions: None.
check:


Steps to take:
v Be aware that the res parameter returned by the getaddrinfo() subroutine will
point to larger struct addrinfo structures.
v Change your application as necessary to accommodate larger struct addrinfo
structures.

v z/OS XL C/C++ Run-Time Library Reference
v z/OS UNIX System Services Programming: Assembler Callable Services Reference

IP Services: Release addrinfo storage after resolver thread
task terminates
Description: The resolver allocates storage in the application address space to
contain the addrinfo data returned by the getaddrinfo() function. Prior to z/OS
V1R12, the resolver released this storage when the task that issued the
getaddrinfo() function terminated. With z/OS V1R12, the resolver releases the
addrinfo storage when the process task that owns the task that issued the
getaddrinfo() function terminates. Applications with long-running tasks that do not
explicitly release addrinfo storage using the freeaddrinfo() function might
experience an increase in storage usage.

Is the migration action required? No, but recommended to prevent excessive
consumption of application virtual storage by
resolver functions.
requirements:
Restrictions: None.
check:

Steps to take: Update application source code to ensure that the freeaddrinfo()
function is issued to release all addrinfo storage obtained using the getaddrinfo()
function.

v Protocol-independent nodename and service name translation in z/OS
Communications Server: IPv6 Network and Application Design Guide.
v FREEADDRINFO for the macro API in z/OS Communications Server: IP Sockets
Application Programming Interface Guide and Reference.
v GETADDRINFO for the macro API in z/OS Communications Server: IP Sockets
Application Programming Interface Guide and Reference.


v FREEADDRINFO for the CALL instruction API in z/OS Communications Server:
IP Sockets Application Programming Interface Guide and Reference.
v GETADDRINFO for the CALL instruction API in z/OS Communications Server: IP
Sockets Application Programming Interface Guide and Reference.
v z/OS Communications Server: IP IMS Sockets Guide.

IP Services: Update syslogd configuration for archiving rules
with shared z/OS UNIX file destinations
Description: Starting with z/OS V1R11, you can configure the syslogd daemon
(syslogd) to perform automatic archiving for z/OS UNIX files. You do this by
specifying the -N parameter on the appropriate syslogd rules in the configuration
file, along with specific configuration statements for the archive function.
Beginning with z/OS V1R12, if you use the same z/OS UNIX file destination on
multiple syslogd rules, the automatic archiving function is not supported on any of
these rules.

Is the migration action required? Yes, if you configure multiple syslogd rules
that use the same z/OS UNIX file
destination, and if you configure automatic
archiving for that destination file.
requirements:
Restrictions: None.
check:

Steps to take: If you configure multiple syslogd rules that use the same z/OS
UNIX file destination, and configure automatic archiving for that destination file,
perform the following steps:
v If you do not require automatic archiving, remove the -N parameter from all
rules that share the same z/OS UNIX file destination.
v If you do require automatic archiving, change the destination to a unique z/OS
UNIX file for each rule that shares the same z/OS UNIX file destination.

Note: If you do not perform either of these steps, message FSUM1273 jobname
AUTOMATIC ARCHIVE NOT USED FOR RULES WITH SHARED
DESTINATION is issued to the operator console, and one or more instances
of message FSUM1272 WARNING: ARCHIVE FUNCTION DISABLED FOR
RULES WITH SHARED DESTINATION filename is written to the syslogd
error destination. The automatic archiving function is turned off for all
syslogd rules that share z/OS UNIX file destinations. Although automatic
archiving is turned off, syslogd continues to log messages to the destination
file.


Reference information: For more information, see syslog daemon in z/OS
Communications Server: IP Configuration Reference.

| SNA Services: Ensure IVTCSM ASSIGN_BUFFER requests do
| not exceed 500 images for a single CSM buffer
| Description: Beginning with z/OS V1R13, Communications Storage Manager
| (CSM) will reject the ASSIGN_BUFFER request after 500 image buffers of a single
| CSM buffer are requested, and CSM will return a new reason code of 26. The new
| reason code 26 states: "Assign buffer request failed because CSM reached the limit
| of the maximum number of image buffers of the single CSM buffer."
|
| Is the migration action required? No, but recommended. Your application
| probably does not request more than 500
| images of a CSM buffer; however, you
| should examine IVTCSM ASSIGN_BUFFER
| calls to ensure that this is the case.
| requirements:
| check:
|

| Steps to take: To prevent application failures due to excessive ASSIGN_BUFFER
| requests:
| v Identify any authorized applications that use CSM services and verify that the
| number of image buffers requested by IVTCSM ASSIGN_BUFFER for a single
| CSM buffer can never be more than 500.
| v If necessary, change the application so the total number of IVTCSM
| ASSIGN_BUFFER image buffer requests is 500 or less.

| Reference information: None.

SNA Services: Ensure VTAMSG2 in not used in your VTAMLST
definitions
Description: Starting in z/OS V1R12, VTAMSG2 is a new reserved name of an
internal major node built by VTAM. As such, there should be no other use of the
name VTAMSG2 in the VTAM definitions that are used by your system.



Is the migration action required? Yes, if you have used the name VTAMSG2 in
any of your VTAM definition statements.
requirements:
Restrictions: None.
check:

Steps to take:
1. Investigate all your VTAM definitions.
2. If you find the name VTAMSG2 in any of them, change the name to a
non-reserved name. Note that if you continue to configure and try to activate
VTAMSG2, message IST607I VARY ACT FOR VTAMSG2 FAILED - INVALID
NODE TYPE OR STATE will be issued.

Reference information: For details about your VTAM definitions, see Resources
automatically activated by VTAM in z/OS Communications Server: SNA Network
Implementation Guide.

Communications Server actions to perform before the first IPL of z/OS
V1R13
perform after you have installed z/OS V1R13 but before the first time you IPL.
These actions might require the z/OS V1R13 level of code to be installed but do
not require it to be active.

| IP Services: Review VIPARANGE definitions
| Description: Prior to z/OS V1R13, for any dynamic VIPA (DVIPA) creation
| request, the first matching VIPARANGE statement is used when creating a DVIPA.
| Beginning in z/OS V1R13, the most specific VIPARANGE statement match is used
| when creating a DVIPA.
|
| Is the migration action required? No, but recommended to ensure DVIPAs are
| created as intended.
| requirements:


| check:
|

| Steps to take:
| 1. Be aware of the change in VIPARANGE processing.
| 2. Update VIPARANGE definitions as needed.

| v VIPARANGE statement in z/OS Communications Server: IP Configuration Reference

IP Services: Update automation that keys on TN3270E Telnet
server messages
Description: Prior to z/OS V1R12, all Telnet messages began with the word
"TELNET" after the message identifier. The DEBUG, LUNS, and LUNR messages
began with "TELNET jobname" after the message identifier. Starting with z/OS
V1R12, the first word "TELNET" is replaced with the jobname. For the DEBUG,
LUNS, and LUNR messages, all other words in the message are shifted to the left.
If you have automation which assumes certain positions for these messages, you
must make accommodations to accept the new format of these messages.

Is the migration action required? Yes, if you have automation checking Telnet
server messages.
requirements:
Restrictions: None.
check:

Steps to take: Ensure that no automation expects the first word of a Telnet
message to be "TELNET" and ensure that any automation that keys on the DEBUG
message EZZ6035I, or the LUNS and LUNR messages EZZ6091I - EZZ6099I, is
updated to handle the word shift to the left.

Reference information: For details about the TN3270E Telnet messages and
jobnames, see EZZ6xxxx messages in z/OS Communications Server: IP Messages
Volume 4 (EZZ, SNM).

IP Services: Ensure the TN3270E Telnet server can end
automatically when an OMVS shutdown command is issued
Description: Prior to z/OS V1R12, if the Telnet application was active when you
issued the F OMVS,SHUTDOWN command, Telnet continued to be active but in


an unusable state. Starting with z/OS V1R12, Telnet stops automatically when you
issue the F OMVS,SHUTDOWN command. Messages are issued in the order they
appear below:
BPXI055I OMVS SHUTDOWN REQUEST ACCEPTED
EZZ6008I tnproc STOPPING
EZZ6010I tnproc SERVER ENDED FOR PORT 23
EZZ6009I tnproc SERVER STOPPED

Is the migration action required? Yes, if you issue an F OMVS,SHUTDOWN
command when the Telnet application is
active.
requirements:
Restrictions: None.
check:

Steps to take: Review your procedures for issuing the F OMVS,SHUTDOWN
command and be aware the Telnet server will stop when the command is issued.

Reference information: See Managing Telnet in z/OS Communications Server: IP

IP Services: Disable resolver monitoring of name server
responsiveness
Description: Prior to z/OS V1R12, the z/OS Communications Server system
resolver did not provide notification of situations where a Domain Name System
(DNS) name server was not responding to resolver queries sent to the name server.
Starting with z/OS V1R12, the resolver will notify the operator when an
unresponsive name server is detected. This function provides critical diagnostic
information to the network operator and allows the operator to take steps to avoid
performance and availability problems. If you do not want the resolver to provide
these notifications, you must take action.

Timing: Before first IPL of z/OS V1R13.
Is the migration action required? Yes, if you do not want notification of
potential problems with name servers in
your network.


requirements:
Restrictions: None.
check:

Steps to take:
v If you do not already have a resolver setup file, create one.
v Code the UNRESPONSIVETHRESHOLD(0) statement in a resolver setup file. A
percentage_of_queries value of 0 indicates that resolver should not monitor name
server responsiveness. The default percentage is 25% of resolver queries.
v If resolver is active, issue the MODIFY
resolver,REFRESH,SETUP=resolver_setup_file command to cause the resolver to
stop monitoring name server responsiveness.
v If the resolver is not active, start the resolver.

v Steps for creating a resolver setup file in z/OS Communications Server: IP
Configuration Guide
v Monitoring the responsiveness of Domain Name System name servers in z/OS
Communications Server: IP Configuration Guide
v UNRESPONSIVETHRESHOLD statement in z/OS Communications Server: IP
Configuration Reference
v MODIFY command: Resolver address space in z/OS Communications Server: IP
System Administrator's Commands

IP Services: Disable IP validation checks when defining key
exchange policy rules for a dynamic VPN
Description: You can configure policy rules for IP security when defining key
exchange policy for dynamic virtual private networks (DVPNs). Prior to z/OS
V1R12, there was no automatic way to verify that the identity of the remote peer
matched the IP address of the remote peer. Beginning with z/OS V1R12, such IP
validation checks are enforced by default. If you do not want the IP validation
checking enabled on your policy rules for security key exchanges, you must
disable it.
Notes:
1. The new default to enable IP validation checking is a benefit; however, one
example of why you might want to disable the checking is if your remote
security endpoint is expected to be behind a network address translation (NAT)
device.
2. A value coded on the parameter to disable the automatic IP validation checking
is ignored if the identity of the peer is not an IPv4 or IPv6 address.



Is the migration action required? Yes, if you want bypass the IP security key
exchange validation check that verifies that
the identity of the remote peer matches the
IP address of the remote peer.
requirements:
Restrictions: None.
check:

Steps to take: Specify the value YES on the BypassIpValidation parameter of the
KeyExchangePolicy or KeyExchangeAction statements. (The value of NO is the
default).

Reference information: For details, see the KeyExchangeAction and
KeyExchangePolicy statements in z/OS Communications Server: IP Configuration
Reference.

IP Services: Update modified Netstat message catalogs to
include timestamp
Description: z/OS V1R12 enhances Netstat to verify that its message catalogs are
at the same maintenance level as the Netstat program. If the message catalog time
stamp does not match the Netstat program time stamp, Netstat uses the default
messages. If you are customizing the netmsg.cat or netmsg6.cat message catalogs,
you must take action to preserve the time stamp.

Element or feature: Communications Server
Is the migration action required? Yes, if you are customizing either the
netmsg.cat or netmsg6.cat message catalog.
requirements:
Restrictions: None.
check:

Steps to take:
1. Issue the dspcat command with the -t -g options against the netmsg.cat (for
example, issue dspcat netmsg.cat -g -t) to retrieve the necessary output to
supply to the gencat command to generate your translated message catalog.


The z/OS Communications Server netmsg.cat is installed in the z/OS UNIX file
system directory /usr/lpp/tcpip/lib/nls/msg/C.
The output file displays as follows:
The time stamp of catalog netmsg.cat is: 2009 112 00:11 UTC
$delset 1
$set 1
$quote "
2. Remove the first line of the output file generated by the dspcat command and
replace it with a $timestamp directive and the time stamp value from the same
output file.
The new output file displays as follows:
$timestamp 2009 112 00:11 UTC
$delset 1
$set 1
$quote "
3. Make any other appropriate changes to customize your message catalog and
issue the gencat command to generate the new message catalog.
4. Repeat steps 1-3 for the netmsg6.cat message catalog.

Reference information: For additional information on customizing message
catalogs, see Customize TCP/IP messages in z/OS Communications Server: IP

IP Services: Update /etc configuration files
Description: Some utilities provided by Communications Server require the use of
certain configuration files. You are responsible for providing these files if you
expect to use the utilities. IBM provides default configuration files as samples in
the /usr/lpp/tcpip/samples directory. Before the first use of any of these utilities,
you should copy these IBM-provided samples to the /etc directory (in most cases).
You can further customize these files to include installation-dependent information.
An example is setting up the /etc/osnmpd.data file by copying the sample file
from /usr/lpp/tcpip/samples/osnmpd.data to /etc/osnmpd.data and then
customizing it for the installation.

If you customized any of the configuration files that have changed, then you must
incorporate the customization into the new versions of the configuration files.

When change was introduced: Various releases. See Table 8 on page 157.
Is the migration action required? Yes, if you have customized a configuration
file (listed in Table 8 on page 157) that IBM
has changed.
requirements:
Restrictions: None.
check:


Steps to take: If you added installation-dependent customization to any of the
IBM-provided configuration files listed in Table 8, make the same changes in the
new versions of the files by copying the IBM-provided samples to the files shown
in the table and then customizing the files.
Table 8. Changed Communications Server configuration files
Utility IBM-provided sample file Target location What changed and when
Internet Key /usr/lpp/tcpip/samples/iked.conf /etc/security/ In z/OS V1R12, a new
Exchange Daemon iked.conf configuration statement is
(IKED) provided to enable FIPS 140
mode for the IKE daemon.
Network Security /usr/lpp/tcpip/samples/nssd.conf /etc/security/ In z/OS V1R12, new
Services Server nssd.conf configuration statements are
Daemon (NSSD) provided to configure new
functions of the IPSec
discipline, including FIPS 140
mode and HTTP retrieval and
caching of certificates,
certificate bundles, and
certificate revocation lists.
Policy Agent /usr/lpp/tcpip/samples/ N/A In z/OS V1R12, new IPSec
pagent_CommonIPSec.conf configuration options enable
the use of IKEv2, and of new
cryptographic algorithms for
IPSec traffic.
Policy Agent /usr/lpp/tcpip/samples/pagent.conf /etc/pagent.conf In z/OS V1R12, the
RFC4301Compliance
parameter is deprecated on
the IpFilterPolicy statement.
SNMP agent /usr/lpp/tcpip/samples/ /etc/osnmpd.data Every release, the value of the
osnmpd.data sysName MIB object is
updated to the current
release.

v For more details about configuration files, see z/OS Communications Server: IP
v For information about modifying the NFS samples, see Chapter 10 in z/OS
Network File System Guide and Reference.

| SNA Services: Adjust to the relocation of the VTAM internal
| trace table
| Description: Starting with z/OS V1R13, the VTAM internal trace (VIT) table is
| relocated from ECSA to HVCOMMON and the VIT data space is eliminated. As a
| result, be aware of the following changes starting in z/OS V1R13:
| v The SIZE parameter of the TRACE start option and the MODIFY TRACE
| command is used to set the size of the VTAM Internal Trace (VIT) table. Prior to
| z/OS V1R13, the value of the SIZE parameter specified the number of pages of
| ECSA (for example, SIZE=999). Starting with z/OS V1R13, the value of the SIZE
| parameter of the TRACE start option and the MODIFY TRACE command
| specifies the number of megabytes of HVCOMMON (for example, SIZE=4M).


| v Starting with z/OS V1R13, the DSPSIZE parameter is not valid.
| – The DSPSIZE parameter was used to set the size of the VIT data space. Prior
| to z/OS V1R13, the value of the DSPSIZE parameter specified the number of
| megabytes of data space in 10 megabytes increments (for example,
| DSPSIZE=5 for 50 megabytes).
| – If DSPSIZE is coded in the VTAM start list, the following informational
| message is displayed: IST448I DSPSIZE OPTION IGNORED - NO LONGER
| SUPPORTED. Processing then continues disregarding the specification.
| – If DSPSIZE is specified on a MODIFY TRACE command, the following
| informational message is displayed: IST448I DSPSIZE OPTION IGNORED -
| NO LONGER SUPPORTED. The entire MODIFY TRACE command is
| ignored.
| v Numerous messages are no longer issued and are retired.
|
| Is the migration action required? Yes, if one or more of the following
| conditions are true:
| v If automation of the MODIFY TRACE
| command exists and the command
| specifies SIZE in pages or DSPSIZE, and
| the failure of that command is
| unacceptable.
| v If automated applications that parse retired
| messages not finding any of the newly
| retired messages is unacceptable.
| requirements:
|
| Restrictions: v Valid SIZE values are 4M-2048M inclusive.
| v If you specify a SIZE value that is larger
| than the default value, z/OS will perform
| paging on portions of the VIT table. Before
| you specify a large SIZE value, ensure that
| you have sufficient real or auxiliary
| storage to contain the entire VIT. Failure to
| ensure sufficient storage might result in an
| auxiliary storage shortage. If an SVC
| dump is taken that includes common
| storage, the size of the dump data set also
| increases. You must also take the increase
| in the size of the dump data set into
| consideration.
| System impacts: Moving the VIT to HVCOMMON can make
| up to 999 pages of ECSA available to other
| applications or subsystems.


| Related IBM Health Checker for z/OS None. The VIT associated health checks have
| check: been removed. See “Update your check
| customization for modified IBM Health
| Checker for z/OS checks” on page 28 for
| more information.
|

| Steps to take:
| v Migrate your VTAM start lists:
| Although the VTAM internal trace (VIT) table size is now specified in megabytes
| and the DSPSIZE parameter is no longer valid, you are not forced to update
| your VTAM start lists before using z/OS V1R13. If you use a nonzero DSPSIZE
| value in your start list, your tracing capacity will be diminished unless you
| perform these migration tasks. You should convert your SIZE value to
| megabytes and delete your DSPSIZE specification.
| v Migrate your automated MODIFY TRACE commands:
| Unlike the VTAM start lists, the migration of any automation of the MODIFY
| TRACE command that specifies the value of the SIZE parameter in pages or the
| DSPSIZE parameter is required before using z/OS V1R13 if the failure of that
| command is unacceptable. If you fail to perform this migration effort, the
| automated command will be rejected, the size of the table will remain
| unchanged, and any other modifications specified on the command (for
| example, opt=all) will be ignored.
| v Migrate your TRACE option or MODIFY TRACE command when they specify
| the SIZE parameter, the DSPSIZE parameter, or both parameters:
| 1. If DSPSIZE=0 is specified, delete the specification. If the SIZE parameter is
| also specified or you want a table size larger than 4 megabytes, proceed to
| steps 2, 3, and 4.
| 2. If DSPSIZE is not specified, specify the SIZE value as the number of
| megabytes you want in your trace table (4 megabytes minimum, for
| example, SIZE=4M). Regardless of the size of the VIT, only a few megabytes
| are backed by 64-bit real storage. This range of fixed pages is dynamically
| shifted as VIT records are written. The migration task is complete for this
| start list or automated command.
| 3. If the DSPSIZE parameter is specified and the SIZE parameter is not, change
| DSPSIZE to SIZE and change the value to the number of megabytes you
| want in your trace table (4 megabytes minimum). If you want to retain the
| equivalent of what was specified for DSPSIZE, specify the SIZE value as the
| DSPSIZE value and append '0M'. For example, DSPSIZE=1 is equivalent to
| SIZE=10M. The migration task is complete for this start list or automated
| command.
| 4. If the DSPSIZE and SIZE parameters are both specified, delete the DSPSIZE
| specification and change the value of the SIZE parameter to the number of
| megabytes you want in your trace table (4 megabytes minimum). If you
| want to retain the equivalent of what was specified for the DSPSIZE
| parameter, change the value of the SIZE parameter to the DSPSIZE value and
| append '0M'. For example, DSPSIZE=3 is equivalent to SIZE=30M.
| v Migrate applications that parse retired messages:
| If you have automation that parses the output from the MODIFY TRACE,
| DISPLAY TRACE, or DISPLAY STATS command, you might need to update
| them because the VIT size is now reported in megabytes. Also, you will no
| longer see DSPSIZE reported as the VIT data space has been removed.


| In addition, numerous messages are retired because they no longer apply. As a
| result, perform the following steps:
| – If you run automation that parses the output of the MODIFY or DISPLAY
| TRACE command, change the automation to process megabytes instead of
| pages.
| Previous message: IST315I VTAM INTERNAL TRACE ACTIVE - MODE = INT,
| SIZE = size PAGES
| Updated message: IST315I VTAM INTERNAL TRACE ACTIVE - MODE = INT,
| SIZE = size MB
| – If you run automation that parses the output of the DISPLAY STATS
| command, change the automation to process megabytes instead of pages.
| Previous message: IST1227I 2 999 = VIT TABLE SIZE
| Updated message: IST1227I 2 4 = VIT TABLE SIZE
| Also, you will no longer see the following message because the VIT data
| space has been removed:
| IST1227I 163 0 = VIT DATA SPACE TABLE SIZE
| – If you run automation that parses any of the following messages, delete the
| automation because the messages are either retired or no longer used for the
| VIT.
| IST318I VTAM INTERNAL TRACE ACTIVATION FAILED -- UNABLE TO FIX STORAGE
| IST495I type HAS BEEN SET TO value
| IST1659I DATA SPACE dspname DSPSIZE = dspsize actsize
| IST1741I DATA SPACE SDUMPX FAILED WITH RETURN CODE code REASON reason
| ISTH003I The VTAM Internal Trace (VIT) table size is at the maximum
| value, which provides optimal trace information for problem
| determination
| ISTH004E VTAM Internal Trace (VIT) table size of vit_size is too small
| ISTH007I VTAM Internal Trace (VIT) dataspace size is at the maximum
| value, which provides optimal trace information for problem
| determination
| ISTH008E VTAM Internal Trace (VIT) dataspace size of dspsize is too
| small
| IVT5602I DATA SPACE SDUMPX FAILED WITH RETURN CODE code REASON reason
| v Other automation:
| If you have automation that parses for or specifies the character string ISTITDS1,
| which prior to z/OS V1R13 was the name of the data space containing the VIT
| data space, you might want to modify that automation because the data space
| will no longer be created. This is highly recommended if you have SLIP traps
| that dump the VIT data space.

| v See TRACE for MODULE, STATE (with OPTION), or VTAM internal trace in
| z/OS Communications Server: SNA Resource Definition Reference for additional
| information about specifying the size of the VTAM internal trace (VIT) table
| using the VTAM TRACE start option.
| v See MODIFY TRACE command in z/OS Communications Server: SNA Operation
| for additional information about specifying the size of the VTAM internal trace
| (VIT) table using the MODIFY TRACE command.


SNA Services: Disable Enterprise Extender connection health
verification
Description: Starting in z/OS V1R12, VTAM verifies the health of the Enterprise
Extender (EE) connection while the connection is being activated. VTAM sends a
Logical Data Link Control (LDLC) probe to the remote partner using all five ports
during the activation. If the partner is not reachable by any port for any reason,
| VTAM does not start the EE connection. VTAM issues the following health
| verification failure message group if the attempt to connect failed during the
| activation of the EE connection when VTAM sent the LDLC probe to the remote
| partner:
| IST2330I EE HEALTH VERIFICATION FAILED FOR puname AT time
| IST1680I type IP ADDRESS ip_address
| IST1680I type IP ADDRESS ip_address
| IST314I END

If you do not want VTAM to verify the health of the EE connection, code the start
option EEVERIFY=NEVER before starting VTAM.

Is the migration action required? Yes, if you used fewer than five ports to start
an EE connection in a previous release, you
must code the start option
EEVERIFY=NEVER before you start VTAM.
requirements:
Restrictions: None.
check:

Steps to take:
v If you are using less than five ports for all of your EE connections, then you
need to specify the EEVERIFY=NEVER start option.
v If you have specific EE connections, you need to specify EEVERIFY=NEVER on
the PU or GROUP statement for that EE connection.

Reference information: Refer to start option EEVERIFY in z/OS Communications
Server: SNA Resource Definition Reference.

SNA Services: Code MULTPATH start option when using
multipath
Description: Prior to z/OS V1R12, multipath support was enabled by a single
switch in the TCP/IP profile for both Enterprise Extender (EE) and TCP/IP traffic.
Beginning with z/OS V1R12, multipath support is disabled (by default) for EE
connections. If you want to continue to use multipath for your EE connections, you
must code the start option MULTPATH=TCPVALUE before starting VTAM.

Timing: Before the first IPL of z/OS V1R13
Is the migration action required? Yes, if you want to continue using multipath
for EE connections.
requirements:
Restrictions: None.
check:

Steps to take: Add MULTPATH=TCPVALUE to the VTAM start option file
ATCSTRxx.

Reference information: For details about RTP performance problems over EE with
multipath routing enabled, see z/OS Communications Server: SNA Diagnosis Vol 1,
Techniques and Procedures.

Communications Server actions to perform after the first IPL of z/OS
V1R13
perform only after you have IPLed z/OS V1R13. You need a running z/OS V1R13
system to perform these actions.

IP Services: Ensure that preference values associated with
IPv6 router advertisement routes are as expected
Starting in z/OS V1R12, TCP/IP processes preference values that are provided in
IPv6 router advertisement messages. Prior to z/OS V1R12, all router advertisement
routes were generated with a medium preference value.

Element or feature: Communications Server
Is the migration action required? Yes, if your stack is IPv6 enabled and your
adjacent routers are originating IPv6 router
advertisement messages that contain
preference values other than the default
value (medium) for either the default route
or an indirect prefix route.


requirements:
Restrictions: None.
check:

Steps to take:
1. Review the reference information for a description of how z/OS
Communications Server uses the preference values that are received in IPv6
router advertisement messages.
2. Ensure that the preference values associated with the router advertisement
routes generated from information received in router advertisement messages
are as expected.
3. If any preference values differ from what you expected, make the necessary
configuration changes on the advertising routers.

Reference information: For details, see the IPv6 routing topic in z/OS
Communications Server: IPv6 Network and Application Design Guide.


Chapter 7. Cryptographic Services migration actions
Cryptographic Services actions to perform before System SSL: Modify applications to address
installing z/OS V1R13 . . . . . . . . . . 165 disablement of SSL V3 and TLS session
ICSF: Ensure PKCS #11 applications call renegotiation . . . . . . . . . . . . 171
C_Finalize() prior to calling dlclose() . . . . . 165 Cryptographic Services actions to perform after the
Cryptographic Services actions to perform before first IPL of z/OS V1R13 . . . . . . . . . . 172
the first IPL of z/OS V1R13 . . . . . . . . 166 | ICSF: Ensure the expected master key support is
| ICSF: Ensure the CSFPUTIL utility is not used | available . . . . . . . . . . . . . . . 173
| to initialize a PKDS . . . . . . . . . . 166 PKI Services: Change the time at which the daily
ICSF: Modify ICSF startup procedure . . . . 167 maintenance task runs . . . . . . . . . . 175
OCSF: Migrate the directory structure . . . . 168
| System SSL: Ensure PKCS #11 tokens contain
| complete certificate chains . . . . . . . . 170

This topic describes migration actions for base element Cryptographic Services.
Included are the components Integrated Cryptographic Service Facility (ICSF),
Open Cryptographic Services Facility (OCSF), PKI Services, and System Secure
Sockets Layer (SSL).

Cryptographic Services actions to perform before installing z/OS
V1R13
This topic describes Cryptographic Services migration actions that you can perform
on your current (old) system. You do not need the z/OS V1R13 level of code to
make these changes, and the changes do not require the z/OS V1R13 level of code
to run once they are made.

ICSF: Ensure PKCS #11 applications call C_Finalize() prior to calling
dlclose()
Description: A PKCS #11 application initializes the environment by calling
dlopen() to load the PKCS #11 DLL into storage, and then calling C_Initialize().
Later, when processing is complete, the application terminates processing by
calling C_Finalize(), and then calling dlclose(). Reinitialization, if desired, can be
achieved by calling dlopen() and C_Initialize() a second time.

In prior releases, z/OS PKCS #11 allowed an application to implicitly finalize the
environment by calling dlclose() without first calling C_Finalize(). Starting with
ICSF FMID HCR7770, this is no longer be supported. If an application does not call
C_Finalize() prior to calling dlclose(), a subsequent attempt to re-initialize PKCS
#11 by calling C_Initialize() will result in error CKR_FUNCTION_FAILED being
returned.

Element or feature: Cryptographic Services.
When change was introduced: ICSF FMID HCR7770, which was initially
made available in web deliverable
Cryptographic Support for z/OS V1R9-R11 and
is now integrated into z/OS V1R12.
Applies to migration from: z/OS V1R11 without ICSF FMID HCR7770
installed.


Is the migration action required? Yes, if you use the following sequence of
calls: dlopen(), C_Initialize(), processing
functions, dlclose(), dlopen(), C_Initialize().
requirements:
Restrictions: None.
check:

Steps to take: PKCS #11 application developers must:
1. Scan their source code for the following sequence of calls: dlopen(),
C_Initialize(), processing functions, dlclose(), dlopen(), C_Initialize().
2. Change all such sequences to insert a call to C_Finalize() before the call to
dlclose().

Reference information: For more information on writing PKCS #11 applications,
refer to z/OS Cryptographic Services ICSF Writing PKCS #11 Applications.

Cryptographic Services actions to perform before the first IPL of z/OS
V1R13
after you have installed z/OS V1R13 but before the first time you IPL. These
actions might require the z/OS V1R13 level of code to be installed but do not
require it to be active.

| ICSF: Ensure the CSFPUTIL utility is not used to initialize a
| PKDS
| Description: ICSF provides a utility program, CSFPUTIL, that performs certain
| functions that can also be performed using the administrator’s panels. In releases
| of ICSF prior to FMID HCR7780 (available as web deliverable Cryptographic Support
| for z/OS V1R10-V1R12), you could use the CSFPUTIL utility program to initialize a
| PKDS, reencipher a PKDS, and refresh the in-storage copy of the PKDS. You can
| still use the CSFPUTIL utility to reencipher or refresh a PKDS. However, starting
| with FMID HCR7780 (Cryptographic Support for z/OS V1R10-V1R12, now integrated
| into z/OS V1R13), the CSFPUTIL utility program no longer supports the function
| to initialize a PKDS. Instead, the ICSF panels must be used to initialize a PKDS.
|
| Element or feature: Cryptographic Services.
| When change was introduced: ICSF FMID HCR7780, which was initially
| made available in web deliverable
| Cryptographic Support for z/OS V1R10-R12 and
| is now integrated into z/OS V1R13.
| Applies to migration from: z/OS V1R12 or z/OS V1R11 without ICSF
| FMID HCR7780 installed.


| Is the migration action required? Yes, if you have jobs that use the the
| CSFPUTIL utility program to initialize a
| PKDS.
| requirements:
| System impacts: Because of this change, jobs that call the
| CSFPUTIL utility with the INITPKDS option
| will no longer initialize a PKDS, and return
| code 4 (which indicates that supplied
| parameters are incorrect) will be returned.
| check:
|

| Steps to take: Make sure no jobs call CSFPUTIL with the INITPKDS option. Use
| the administrator panels to initialize the PKDS instead.

| Reference information: For more information in initializing the PKDS and on the
| CSFPUTIL utility, refer to z/OS Cryptographic Services ICSF Administrator's Guide.

ICSF: Modify ICSF startup procedure
Description: The program that started ICSF in earlier releases was named
CSFMMAIN. In ICSF FMID HCR7770 (initially made available in the web
deliverable Cryptographic Support for z/OS V1R9-R11 and now integrated into z/OS
V1R12), the CSFMMAIN program is replaced by the CSFINIT program. If your
ICSF startup procedure is not modified to run this new program, the procedure
will not start the HCR7770 level of ICSF.

When change was introduced: ICSF FMID HCR7770, which was initially
made available in web deliverable
Cryptographic Support for z/OS V1R9-R11 and
now integrated into z/OS V1R12.
Applies to migration from: z/OS V1R11 without ICSF FMID HCR7770
installed.
Is the migration action required? Yes, if you use CSFMMAIN as the ICSF
startup program.
requirements:
Restrictions: None.

Steps to take:
v In your startup procedure for ICSF:

Chapter 7. Cryptographic Services migration actions 167

1. Find the job step that identifies the ICSF startup program (CSFMMAIN) that
was used in earlier releases. For example:
CSFSTART EXEC PGM=CSFMMAIN,REGION=0M,TIME=1440
2. Modify the PGM parameter on this EXEC statement to identify the new
startup program (CSFINIT):
CSFSTART EXEC PGM=CSFINIT,REGION=0M,TIME=1440
3. Save your changes to the startup procedure.
Tips:
v Member CSF in SYS1.SAMPLIB contains a sample JCL code for an ICSF startup
procedure.
v The new PPT entry for CSFINIT is shipped in the IBM default PPT table by
APAR OA26245 for z/OS V1R9 and z/OS V1R10.
v Refer to Washington Systems Center (WSC) Flash FLASH10620 for tips about
sharing the ICSF startup procedure between ICSF release levels.
| v In HCR7770 and later, ICSF PKCS11 requests above the bar memory.
| ABENDDC2-16 in CSFKSTDC can be encountered due to a large number of
| TKDS requests. System programmers can code MEMLIMIT=NOLIMIT in the
| new ICSF startup procedures to prevent an ABENDDC2 when system limits for
| above the bar memory are set too low. For more information, see
| http://www-01.ibm.com/support/docview.wss?uid=isg1OA34077 .

Reference information: For more information on ICSF startup procedures, refer to
z/OS Cryptographic Services ICSF System Programmer's Guide.

OCSF: Migrate the directory structure
Description: If you previously configured Open Cryptographic Services Facility
(OCSF), you need to verify that the OCSF directories have been migrated to the
target system.

Note: If you want to take advantage of the new Software Cryptographic Service
Provider 2 (SWCSP2), you should bypass this migration action. When your
z/OS V1R11 system is up and running, install OCSF by running the install
script and then the IVP.

specific release.
Is the migration action required? Yes, if you currently use OCSF or if new
products or functions on your new z/OS
system require OCSF to be active. However,
if you installed your new z/OS system with
ServerPac or SystemPac, the OCSF
installation script has been run and you do
not have to perform this migration action for
that system.
requirements:


Restrictions: None.
check:

Steps to take: Migrate the OCSF /var directory structure to the target system. If
you installed z/OS V1R11 with CBPDO or by cloning an already-installed V1R11
system, you can either copy the /var/ocsf directory from your old system or rerun
the installation script. If you installed z/OS V1R11 with ServerPac or SystemPac,
the OCSF installation script has been run and you have no migration actions for
that target system (although you still have to migrate the directory structure to any
cloned systems, as stated above).

If you copy /var/ocsf, verify that the OCSF /var directory structure has been
migrated to the target system as described in “Migrate /etc and /var system
control files” on page 19. The OCSF registry (the /var/ocsf files) contains the
directory path names to the code libraries. If the registry files are copied, the CSSM
DLL and the add-ins must be in the same location on the target system as on the
prior release. The normal locations are /usr/lpp/ocsf/lib for the CSSM and
supporting DLLs and /usr/lpp/ocsf/addins for the add-in libraries.

If you copied /var/ocsf, do the following:
1. Verify that the following four files exist in that directory:
v CDSA_Registry.dir with permissions (-rw-r--r--)
v CDSA_Registry.pag with permissions ( -rw-r--r--)
v CDSA_Sections.dir with permissions (-rw-r--r-- )
v CDSA_Sections.pag with permissions (-rw-r--r--)
2. Verify that the required RACF FACILITY class profiles are defined and set up:
v CDS.CSSM — authorizes the daemon to call OCSF services
v CDS.CSSM.CRYPTO — authorizes the daemon to call a cryptographic service
provider (CSP)
v CDS.CSSM.DATALIB — authorizes the daemon to call a data storage library
(DL) service provider
3. Ensure that the necessary libraries are program controlled:
v XL C/C++ runtime libraries
v Language Environment libraries
v SYS1.LINKLIB
v SYS1.SIEALNKE

If you did not copy /var/ocsf, rerun the installation script:
1. Set up the RACF FACILITY class profiles required by OCSF and authorize the
appropriate user IDs to those profiles:
v CDS.CSSM — authorizes the daemon to call OCSF services
v CDS.CSSM.CRYPTO — authorizes the daemon to call a cryptographic service
provider (CSP)
v CDS.CSSM.DATALIB — authorizes the daemon to call a data storage library
(DL) service provider
2. Ensure that the following libraries are defined as program controlled:
v XL C/C++ runtime libraries


v Language Environment libraries
v SYS1.LINKLIB
v SYS1.SIEALNKE
3. Run the ocsf_install_crypto script from the OMVS shell. This must be run from
the target system.
a. Verify and update $LIBPATH.
b. Change directory to the location of the script (/usr/lpp/ocsf/bin).
c. Run the script.

Whether you reinstalled or migrated, it is strongly recommended that you rerun
IVP ocsf_baseivp from the OMVS shell. This IVP verifies that OCSF is installed
and configured correctly. To run the IVP:
1. Mount /usr/lpp/ocsf/ivp.
2. Read the README file and follow the instructions.
3. Run the IVP.

If you were using other IBM or non-IBM services to supplement the functions in
OCSF, such as the Open Cryptographic Enhanced Plug-ins (OCEP) component of
base element Integrated Security Services, or the PKI Services component of base
element Cryptographic Services, you must ensure that these are migrated or
reinstalled.

Reference information: z/OS Open Cryptographic Services Facility Application
Programming.

| System SSL: Ensure PKCS #11 tokens contain complete
| certificate chains
| Description: The PKCS #11 token certificate validation process should retrieve and
| validate the complete chain of certificates up to a root (self-signed) certificate. Prior
| to V1R12, however, System SSL may have successfully validated an incomplete
| certificate chain when retrieving a certificate from a PKCS #11 token. In System
| SSL V1R12, the certificate validation process has been improved, and access to the
| complete certificate chain is required for successful certificate validation.
| Implementations using PKCS #11 tokens containing incomplete certificate chains
| may find that certificates that passed validation in releases prior to z/OS V1R12
| now fail validation in z/OS V1R12.
|
| Is the migration action required? Yes, if PKCS #11 tokens are being used by a
| System SSL application.
| requirements:


| Related IBM Health Checker for z/OS None
| check:
|

| Steps to take: Ensure that PKCS #11 tokens being used by System SSL applications
| contain the complete certificate issuer chain up to a root (self-signed) certificate.
| You can use the z/OS shell-based program gskkyman or the z/OS Security Server
| (RACF) RACDCERT command to display supported tokens and their certificates.

| v For additional information about certificate validation and the gskkyman
| command, refer to z/OS Cryptographic Services System SSL Programming.
| v For additional information about the RACDCERT command, refer to z/OS
| Security Server RACF Command Language Reference.

| System SSL: Modify applications to address disablement of
SSL V3 and TLS session renegotiation
Description: Session renegotiation allows an existing SSL V3 or TLS session to
perform a re-handshake. A common reason for this is to refresh the session keys
used to encrypt data transmitted across the secure connection. In z/OS V1R11,
z/OS V1R10, and z/OS V1R9 without the PTFs for APAR OA31172 installed, the
default behavior of System SSL was to permit applications to perform SSL V3 and
TLS server session renegotiations according to the SSL V3 Protocol Specification
and RFC2246. The new default behavior for z/OSV1R11, with the PTFs for APAR
OA31172 installed, is to disable session renegotiation.

If you run System SSL applications that handle session renegotiation, server
renegotiation will fail unless renegotiation is explicitly enabled. The
gsk_secure_socket_read API will return with error code 432. The
gsk_secure_soc_read API will return with error code -7.

When change was introduced: z/OS V1R11, z/OS V1R10, and z/OS V1R9
by APAR OA31172.
Applies to migration from: z/OS V1R11 without the PTFs for APAR
OA31172 installed.
Timing: Before first IPL of z/OS V1R13.
Is the migration action required? Yes, if you run any System SSL applications
that request or receive requests for session
renegotiation.
requirements:
Restrictions: None.

Steps to take:
1. Identify the System SSL applications your installation runs, and determine
whether any of those applications require session renegotiation. If no
applications require session renegotiation, no further action is needed.


2. If any System SSL applications your installation runs attempts session
renegotiation, determine whether this renegotiation is required.
v If the renegotiation is not required, modify the application so that it does not
attempt session renegotiation.
v If server session renegotiation is necessary, and you are willing to accept
potential risks, server session renegotiation can be explicitly enabled.
– For applications that accept the specification of environment variables, the
GSK_RENEGOTIATION environment variable should be used.
- Specify GSK_RENEGOTIATION=NONE to disable SSL V3 and TLS
handshake renegotiation as a server. This is the default.
- Specify GSK_RENEGOTIATION=ALL to allow SSL V3 and TLS
handshake renegotiation as a server. This is equivalent to the System
SSL behavior for session renegotiation.
- Specify GSK_RENEGOTIATION=ABBREVIATED to allow SSL V3 and
TLS abbreviated handshake renegotiation as a server for resuming the
current session only, while disabling SSL V3 and TLS full handshake
renegotiation as a server. The System SSL session ID cache is not
checked when resuming the current session with this value set.
– For applications that don't allow the specification of environment variables
or want to tailor individual SSL environments within an application, use
the enumeration identifier GSK_RENEGOTIATION on
thegsk_attribute_set_enum API. For the GSK_RENEGOTIATION
enumeration identifier:
- Specify GSK_RENEGOTIATION_NONE to disable SSL V3 and TLS
handshake renegotiation as a server. This is the default.
- Specify GSK_RENEGOTIATION_ALL to allow SSL V3 and TLS
handshake renegotiation as a server.
- Specify GSK_RENEGOTIATION_ABBREVIATED to allow SSL V3 and
TLS abbreviated handshake renegotiation as a server for resuming the
current session only, while disabling SSL V3 and TLS full handshake
renegotiation as a server. With this enumeration value set, the System
SSL session ID cache is not checked when resuming the current session.
The gsk_attribute_get_enum API also accepts the enumeration identifier
GSK_RENEGOTIATION, and will return one of the preceding
enumeration values indicating the current renegotiation setting for the
specified SSL environment.

Reference information: For information about System SSL programming, refer to
z/OS Cryptographic Services System SSL Programming.

Cryptographic Services actions to perform after the first IPL of z/OS
V1R13
only after you have IPLed z/OS V1R13. You need a running z/OS V1R13 system
to perform these actions.


| ICSF: Ensure the expected master key support is available
| Description: In versions of ICSF prior to FMID HCR7780, in order for a
| coprocessor to become active, a DES master key needed to be set on the
| coprocessor. Once the coprocessor was active, DES master key support, and the
| support of any other master key (an AES master key or an asymmetric master key)
| set on the coprocessor, would then be available.

| Starting with ICSF FMID HCR7780, the activation procedure for non-CCF systems
| is designed to maximize the number of active coprocessors by selecting the set of
| master keys that are available on the majority of coprocessors. A DES master key is
| no longer required in order for a coprocessor to become active. Instead, any one of
| four master keys – the DES master key, the AES master key, the RSA master key
| (which in earlier releases was called the asymmetric master key), or the ECC
| master key – is enough for a coprocessor to become active. However, because the
| goal is to select the combination of master keys that will maximize the number of
| active coprocessors, if a certain master key is not set on all the same coprocessors,
| that master key support will not be available. Before you use ICSF FMID HCR7780,
| you must understand the new method of coprocessor activation in order to ensure
| that the expected master keys will be available. You may need to set master keys
| on additional coprocessors to ensure the same master key support you had in
| earlier versions of ICSF is available in ICSF FMID HCR7780.
|
| When change was introduced: ICSF FMID HCR7780, which was initially
| made available in web deliverable
| Cryptographic Support for z/OS V1R10-R12
| and is now integrated into z/OS V1R13.
| Applies to migration from: z/OS V1R12 or z/OS V1R11 without ICSF
| FMID HCR7780 installed.
| requirements:
| check:
|

| Steps to take: Make sure you understand the new method of coprocessor
| activation described in this migration action to ensure the expected master key
| support is available.

| To further illustrate the change in coprocessor activation introduced in ICSF FMID
| HCR7780, let's say you have the following four coprocessors with these master
| keys set (as indicated by the letter “Y”).
| Table 9. Coprocessor activation example
| E00 E01 E02 E03
| DES Y Y


| Table 9. Coprocessor activation example (continued)
| E00 E01 E02 E03
| AES Y Y Y Y
| RSA (ASYM) Y Y
|

| In releases prior to ICSF FMID HCR7780, a DES master key was required in order
| for a coprocessor to become active. In our example, coprocessors E00 and E02 have
| the DES master key set, so they become active. The DES master key is available as
| well as the AES and RSA (ASYM) master keys which are set on the E00 and E02
| coprocessors. Coprocessors E01 and E03 do not have a DES master key set, and so
| are not active.

| Starting with ICSF FMID HCR7780, any master key is enough for a coprocessor to
| become active and the activation procedure tries to maximize the number of active
| coprocessors. The AES master key is set on all four of these coprocessors, so all
| four of the coprocessors become active. However, since the DES and RSA master
| keys are not set on all four of the coprocessors, DES and RSA support is not
| available. As coprocessor master keys are set or changed, however, additional
| function may become available. In this case, setting the DES and RSA master keys
| on coprocessors E01 and E03 would make the DES and RSA support available.

| ECC master key support is based on the existence of CEX3C coprocessors. If a
| mixture of CEX3C coprocessors and older coprocessors exist on a system, then
| ECC support will be based solely on the state of the CEX3C coprocessors. For
| example, let's change our example so that two of the coprocessors are CEX3C
| coprocessors (as identified by the G prefix in the name) with the ECC master key
| set.
| Table 10. Coprocessor activation example (ECC support based only on CEX3C
| coprocessors)
| G00 E01 G02 E03
| DES Y Y
| AES Y Y Y Y
| RSA (ASYM) Y Y
| ECC Y Y
|

| In this example, the AES master key is still the one set on the majority of
| coprocessors and makes the coprocessors active. The DES and RSA master keys are
| not set on all the coprocessors, and so DES and RSA support is not available. The
| ECC master key cannot be set on all coprocessors (because it is not available on
| the CEX2C). However, unlike the DES and RSA support, ECC support is still
| available. This is because the ECC master key is set on all CEX3C coprocessors.

| To ensure the master key support that you expect is available, follow these steps:
| 1. To ensure AES support, set the AES master key on each CEX2C and CEX3C.
| 2. To ensure DES support, set the DES master key on each CEX2C, CEX3C, and
| (as long as AES support is not also needed) PCIXCC.
| 3. To ensure RSA support, set the RSA master key on each CEX2C, CEX3C, and
| (as long as AES support is not also needed) PCIXCC.
| 4. To ensure ECC support, set the ECC master key on each CEX3C.


| To verify the master key support is available, select option 1, COPROCESSOR
| MGMT, from the ICSF Primary menu. This will display the coprocessor
| management panel, which shows which coprocessors are active, and the state of
| the master keys for coprocessors.

| v For information about entering master key parts, refer to z/OS Cryptographic
| Services ICSF Administrator's Guide.
| v Search for TechDoc "Activation of Cryptographic Coprocessors and
| Cryptographic Algorithms with ICSF, HCR7780", at http://www.ibm.com/
| support/techdocs/atsmastr.nsf/Web/TechDocs.

PKI Services: Change the time at which the daily maintenance task
runs
Description: Before z/OS V1R12, PKI Services ran a daily maintenance task when
you started the PKI Services daemon, and every twenty-four hours after that.
Starting with z/OS V1R12, by default the task runs when you start the PKI
Services daemon, and daily at midnight local time. If running this task at midnight
causes problems, for example performance problems because you have other tasks
scheduled to run at midnight, you can change the time at which the PKI Services
daily maintenance task runs.

Is the migration action required? Yes, if you do not want the PKI Services
daily maintenance task to run at midnight.
requirements:
Restrictions: None.
check:

Steps to take: Change the value of the MaintRunTime variable in the PKI Services
configuration file to specify the time at which you want the daily maintenance task
to run.

Reference information: For details about updating the MaintRunTime variable, see
z/OS Cryptographic Services PKI Services Guide and Reference.


Chapter 8. DFSMS migration actions
DFSMS actions to perform before installing z/OS | DFSMShsm: Accommodate the changed SETSYS
V1R13 . . . . . . . . . . . . . . . . 177 | FASTREPLICATION command
DFSMSdfp: Back up SMS control data sets . . 177 | DATASETRECOVERY parameter default . . . 195
| DFSMSdfp: Accommodate deletion of | DFSMShsm: Replace user-defined patch with
| NOIMBED and NOREPLICAT LISTCAT | new SETSYS FASTREPLICATION command to
| command attributes . . . . . . . . . . 179 | enable ARC1809I messages . . . . . . . . 196
DFSMSdfp: Modify exit routines to support | DFSMShsm: Review messages changed from I
31-bit UCB addresses . . . . . . . . . . 180 | (informational) to E (eventual action) type. . . 197
DFSMSdfp and DFSMSdss: Redefine existing | DFSMShsm: Remove patch that prevents SMS
VSAM data sets that contain the IMBED, | MVT chain rebuild . . . . . . . . . . 198
REPLICATE, and KEYRANGE attributes . . . 180 | DFSMShsm: Update operator procedure in the
DFSMSrmm: Replace CIM providers and CIM | Multicluster CDS environment . . . . . . 199
classes. . . . . . . . . . . . . . . 183 DFSMShsm: Remove user-defined patch that
DFSMS actions to perform before the first IPL of disables or enables use of the DFSMSdss cross
z/OS V1R13 . . . . . . . . . . . . . . 184 memory API . . . . . . . . . . . . 200
DFSMSdfp: Ensure that the Language DFSMShsm: Configure your security system to
Environment runtime library is available for permit started procedures using new address
DLLs . . . . . . . . . . . . . . . 184 space identifier . . . . . . . . . . . . 200
DFSMSdfp: Update SYS1.IMAGELIB . . . . 185 DFSMShsm: Update applications that depend
| DFSMSdfp: Update operator procedures and on QUERY COPYPOOL output . . . . . . 201
| system automation for new DADSM pre- and DFSMShsm: Update applications that depend
| post-processing dynamic exits . . . . . . . 186 on LIST command output . . . . . . . . 202
| DFSMSdfp: Update procedures that use DFSMShsm: Accommodate the change of
| IEBDSCPY alias name to access IEBCOPY . . . 187 ARCBDEXT exit . . . . . . . . . . . 203
DFSMSdfp: Evaluate applications and modify DFSMS actions to perform after the first IPL of
for EAV enhancements . . . . . . . . . 188 z/OS V1R13 . . . . . . . . . . . . . . 204
DFSMSdfp: Accommodate new DCBE macro | DFSMSdfp: Accommodate 64-bit and AR mode
option . . . . . . . . . . . . . . . 189 | rules enforcement in DFSMS macros. . . . . 204
DFSMSdss: Build the IPLable stand-alone | DFSMSdfp: Run OAM configuration database
DFSMSdss image . . . . . . . . . . . 191 | migration job . . . . . . . . . . . . 205
DFSMSdss: Recompile and link-edit exit DFSMSdfp: Run OAM DB2 BIND jobs . . . . 205
routines or applications that change options in DFSMSdfp: Use indirect zFS file system data set
the ADRUFO block . . . . . . . . . . 192 catalog support. . . . . . . . . . . . 206
DFSMSdss: Modify applications to handle larger | DFSMSdss: Accommodate Catalog Search
I/O buffers . . . . . . . . . . . . . 193 | Interface default change . . . . . . . . . 207
| DFSMShsm: Accommodate the changed default | DFSMShsm: Stop using the HOLD command to
| of PDA trace during DFSMShsm startup . . . 194 | quiesce activity prior to control data set backup . 208

This topic describes migration actions for base element DFSMSdfp and optional
features DFSMSdss, DFSMShsm, DFSMSrmm, and DFSMStvs.

DFSMS actions to perform before installing z/OS V1R13
This topic describes DFSMS migration actions that you can perform on your
current (old) system. You do not need the z/OS V1R13 level of code to make these
they are made.

DFSMSdfp: Back up SMS control data sets
Description: In a multisystem Storage Management Subsystem (SMS) complex,
operating systems share a common set of SMS classes, groups, ACS routines, and a
configuration base, which make up the storage management policy for the
complex. This storage management policy is maintained in a source control data
set (SCDS). When this policy is activated for SMS, the bound policy is maintained


in processor storage and on DASD in an active control data set (ACDS). Systems in
the complex communicate SMS information through a common communications
data set (COMMDS).

It is recommended that to successfully share SMS control data sets in a
multisystem environment where there are mixed levels of DFSMS, you update,
translate, validate, and activate SMS policies on the system with the latest level of
DFSMS. When an earlier control data set is to be updated or activated, the control
data set is formatted by the later-level system. The shared SMS control blocks
reflect the new, rather than the previous, lengths and control information.

For fallback, IBM recommends restoring SMS control data sets from backups taken
on the fallback release.

Editing a policy on an earlier system could invalidate unused control information
and prevent the control data set from being accessed by a later system. A warning
message is provided before a policy can be changed on an earlier system. ACS
routines may need to be updated and translated so to not reference policy items
not known to the earlier system.

Remember, you risk policy activation failures if SCDS changes are not validated
using the latest-level system in a sysplex.

Element or feature: DFSMSdfp.
specific release.
Is the migration action required? No, but recommended to ensure data
integrity.
Other system (coexistence or fallback) Install the PTFs in “Install coexistence and
requirements: fallback PTFs” on page 8 if they are not
already installed.
Restrictions: None.
check:

| Steps to take: Do the following on your pre-z/OS V1R13 systems:
| 1. Back up SMS control data sets according to established procedures in the event
| that fallback is required. The control data set format is VSAM linear.
| 2. Install all coexistence PTFs in “Install coexistence and fallback PTFs” on page 8.

In addition, if you modified and activated a higher-level policy on a pre-z/OS
V1R13 system, do the following to ensure that the ACDS can be accessed on z/OS
V1R13:
1. On the pre-z/OS V1R13 system, save the active ACDS as an SCDS with the
SETSMS SAVESCDS command.
2. On z/OS V1R13, update, translate, validate, and activate the saved SMS policy.


v z/OS DFSMS Implementing System-Managed Storage
v z/OS DFSMSdfp Storage Administration

| DFSMSdfp: Accommodate deletion of NOIMBED and
| NOREPLICAT LISTCAT command attributes
| Description: Before z/OS V1R13, output from the IDCAMS LISTCAT command
| displayed the NOIMBED and NOREPLICAT attributes. Starting with z/OS V1R13,
| these attributes are no longer included in the LISTCAT command output. This
| might affect programs that parse LISTCAT results.

| In 2001, support for creating data sets with IMBED or REPLICATE attributes on
| the AMS DEFINE command was removed. Starting with z/OS V1R13, the
| LISTCAT output no longer displays the default NOIMBED and NOREPLICAT
| attributes. This information is no longer needed. This might affect programs that
| parse LISTCAT results.

| Note that for any cluster defined prior to 2001 with IMBED or REPLICATE
| attributes, those attributes are displayed in IDCAMS LISTCAT command output.

| Before this z/OS V1R13 change, when you issued a LISTCAT for a data set, at the
| end, you would see attribute characteristics. They would look something like this
| example:
| ATTRIBUTES
| KEYLEN----------------15 AVGLRECL--------------80
| RKP--------------------0 MAXLRECL--------------80
| STRIPE-COUNT-----------1
|
| SHROPTNS(4,3) RECOVERY UNIQUE NOERASE INDEXED NOWRITECHK NOIMBED NOREPLICAT
| UNORDERED NOREUSE NONSPANNED EXTENDED EXT-ADDR

| Starting with z/OS VR13, when you issue a LISTCAT for a data set, the result will
| look something like this example:
| ATTRIBUTES
| KEYLEN----------------15 AVGLRECL--------------80
| RKP--------------------0 MAXLRECL--------------80
| STRIPE-COUNT-----------1
|
| SHROPTNS(4,3) RECOVERY UNIQUE NOERASE INDEXED NOWRITECHK UNORDERED NOREUSE
| NONSPANNED EXTENDED EXT-ADDR

|
| Element or feature: DFSMSdfp.
| Is the migration action required? No, but recommended if you use programs
| that parse LISTCAT results.
| requirements:
| check:
|

Chapter 8. DFSMS migration actions 179

| Steps to take: It is recommended that you convert the programs that parse
| LISTCAT results to use Catalog Search Interface (CSI).

| Reference information: See information about CSI in z/OS DFSMS Managing
| Catalogs.

DFSMSdfp: Modify exit routines to support 31-bit UCB
addresses
Description: Before z/OS V1R12, DADSM captured the unit control block (UCB)
address passed to it in its interfaces. Starting in z/OS V1R12, DADSM will no
longer capture the UCB address passed to it and will use the actual 31-bit UCB
address. The UCB address will either be above or below the 16 MB line. This
address in turn will be passed into the DADSM pre- and post- installation exit
routines (IGGPRE00, IGGPOST0) in the current 4-byte IEXUCB field. Therefore, the
address in IEXUCB may now contain a 31-bit UCB address. Exit routines that do
not support 31-bit UCB addresses will need to be upgraded to support a 31-bit
UCB address.

Is the migration action required? Yes. If an exit routine does not support 31-bit
UCB, it will need to be upgraded to support
31-bit UCB addresses.
requirements:
Restrictions: None.
check:

Steps to take: Update the exit to support a 31-bit UCB address.

Reference information: For details about DADSM pre- and post-installation exit
routines, see z/OS DFSMS Installation Exits.

DFSMSdfp and DFSMSdss: Redefine existing VSAM data sets
that contain the IMBED, REPLICATE, and KEYRANGE
attributes
Description: No supported release of z/OS honors the IMBED, REPLICATE, and
KEYRANGE attributes for new VSAM data sets. In fact, using these attributes can
waste DASD space and often degrades performance. Servicing these VSAM data
sets has become increasingly difficult. In some cases, unplanned outages have
occurred. For these reasons, IBM recommends that you stop using IMBED and
REPLICATE, and that you minimize or eliminate your use of KEYRANGE.


IMBED and REPLICATE were intended as performance improvements and have
been rendered obsolete by newer, cached DASD devices. Striped data sets provide
much better performance than KEYRANGE and should be viewed as a candidate
for any existing KEYRANGE data sets.

Starting in z/OS V1R12, DFSMSdss provides some assistance in identifying and
converting data sets with KEYRANGES, IMBED or REPLICATE attributes:
v Data set dump processing and restore processing issue a message ADR508I
(ttt)-mmmmm(yy), THE FOLLOWING DATA SETS REQUIRE SOME ACTION TO
BE TAKEN when data sets with those attributes are encountered.
v Logical restore processing automatically converts indexed VSAM data sets with
the IMBED or REPLICATE attributes, but not the KEYRANGES attribute, to
key-sequenced data sets (KSDS) that do not have those attributes. It also issues
message ADR507I (ttt)-mmmmm(yy), DATA SET dsn WAS RESTORED WITHOUT
THE IMBED OR REPLICATE ATTRIBUTES indicating that the data set has been
converted.

Element or feature: DFSMSdfp and DFSMSdss.
When change was introduced: The recommendation to migrate from
IMBED, REPLICATE, and KEYRANGE was
originally made in the z/OS V1R6 timeframe.
In Software Announcement 204-180
(RFA39951), dated August 10, 2004, IBM
announced its intent to withdraw support for
VSAM IMBED, REPLICATE, and
KEYRANGE attributes in a future release.
Based on customer feedback, IBM no longer
plans to remove this support from z/OS in
the foreseeable future. IBM still recommends
that you stop using these attributes and
plans to remove IMBED and REPLICATE
attributes during logical DFSMSdss restore
operations and DFSMShsm recall operations
as announced in Software Announcement
207-175 4 (RFA45594), dated August 7, 2007.
The DFSMSdss function to aid in conversion
was added in z/OS V1R12.
Is the migration action required? No, but recommended to avoid degraded
performance and wasted DASD space.
requirements:
Restrictions: HSM only logs messages for non-zero return
codes (non I-type), so the messages for this
line item won't be logged by HSM for any
function.
Related IBM Health Checker for z/OS Use check CATALOG_IMBED_REPLICATE
check: on z/OS V1R11 to detect IMBED and
REPLICATE attributes in your master catalog
and any connected user catalogs.


Steps to take:
1. Determine which VSAM data sets and ICF catalogs were defined with the
IMBED, REPLICATE, or KEYRANGE attribute. Data set dump processing and
restore processing issue message ADR508I (ttt)-mmmmm(yy), THE FOLLOWING
DATA SETS REQUIRE SOME ACTION TO BE TAKEN to indicate data sets
with the attributes.
To further help you identify the data sets, you can get a tool that reads existing
VSAM data sets and ICF catalogs, and reports which ones have these attributes.
The tool is available from the software server (ftp.software.ibm.com) in the
s390/mvs/tools directory as IMBDSHIP.JCL.TRSD. Download the file in binary
format and unterse it on your z/OS system using AMATERSE or TRSMAIN.
Instructions for using the tool are included in the downloaded JCL.
Notes:
a. The tool only checks data sets that are on DASD.
b. “AMATERSE” and “TRSMAIN” are names for a service aid that compresses
and decompresses data exchanged with IBM. “AMATERSE” is the preferred
program name since its integration into z/OS V1R9. “TRSMAIN” is the
original program name and is now shipped as an alias entry point to
AMATERSE. For more information about AMATERSE, including several
differences with TRSMAIN, see z/OS MVS Diagnosis: Tools and Service Aids.
2. Schedule a time for the affected VSAM data sets and ICF catalogs to be
unavailable, and redefine them.
For VSAM data sets you can use JCL similar to the following:
//* EXPORT A KSDS
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INDD DD DSN=EXAMPLE.KSDS,DISP=OLD
//OUTDD DD DSN=EXAMPLE.KSDS.EXPORTED,DISP=(NEW,CATLG),
// SPACE=(CYL,(1,1)),UNIT=SYSDA
//SYSIN DD *
EXPORT EXAMPLE.KSDS -
INFILE(INDD) -
OUTFILE(OUTDD) -
TEMPORARY

//* NOW IMPORT THE EXPORTED COPY
//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//INDD DD DSN=EXAMPLE.KSDS.EXPORTED,DISP=SHR
//SYSIN DD *
IMPORT -
INFILE(INDD) -
OUTDATASET(EXAMPLE.KSDS)
For ICF catalogs, see informational APAR II13354 for step-by-step instructions
on using IDCAMS EXPORT/IMPORT with ICF catalogs.

v For more information about IDCAMS EXPORT and IMPORT, see z/OS DFSMS
Access Method Services for Catalogs.
v For more information about the AMATERSE service aid, see z/OS MVS
Diagnosis: Tools and Service Aids.
v For more information about data set dump and restore processing, see z/OS
DFSMSdss Storage Administration.
v For more information about messages ADR507I and ADR508I, see z/OS MVS
System Messages, Vol 1 (ABA-AOM).


DFSMSrmm: Replace CIM providers and CIM classes
Description: In z/OS V1R10, the keys used for the DFSMSrmm CIM classes were
changed. Prior to z/OS V1R12, you had the option of using a backward-compatible
CIM provider, rather than updating your code to handle the new key formats.
Beginning with z/OS V1R12, the backward-compatible CIM provider is no longer
supported. If you have not done so already, you must unregister the previous CIM
providers and CIM classes, and register the currently supported CIM providers
and CIM classes.

Element or feature: DFSMSrmm.
Is the migration action required? Yes, if you have not yet updated your code
to handle the current key formats and are
still using the backward-compatible CIM
provider (provided as rmmcim19.tar.Z
compressed tar archive).
requirements:
Restrictions: None.
check:

Steps to take:
1. Update your code to handle the key formats used in z/OS V1R11 and later. For
the current formats, see Table 11.
2. Using the rmmutil.sh tool, unregister all the z/OS V1R9 CIM providers and
unload all the z/OS V1R9 CIM classes.
3. Using the same rmmutil.sh tool, register the complete set of z/OS V1R12 CIM
providers and load the z/OS V1R12 CIM classes.

Table 11 shows the old (V1R9) keys of DFSMSrmm CIM classes and the current
(V1R11 and later) compound keys, which have formats of concatenated strings
containing the values of the old keys delimited with "+" and appended with spaces
by the fix length, if needed.
Table 11. DFSMSrmm CIM classes and compound keys
Class Name Key Transformation
IBMRMM_Dataset DataSetName,PhysicalFileSequenceNumber,
VolumeSerialNumber, and CdsID keys have been replaced
with Name key of format
DatasetName+FileSeq+Volser+CdsID.
IBMRMM_Location LocationName, LocationType, and CdsID keys have been
replaced with Tag key of format
LocationName+LocationType+CdsID.


Table 11. DFSMSrmm CIM classes and compound keys (continued)
Class Name Key Transformation
IBMRMM_LogicalVolume VolumeSerialNumber and CdsID keys have been replaced
with DeviceID key of format Volser+CdsID.
IBMRMM_Owner OwnerId and CdsID keys have been replaced with
InstanceID key of format OrgID:OwnerID+CdsID.
IBMRMM_PhysicalVolume VolumeSerialNumber and CdsID keys have been replaced
with Tag key of format Volser+CdsID.
IBMRMM_PolicyRule PolicyRuleType, PolicyRuleName, JobNameMask, and CdsID
keys have been replaced with PolicyRuleName key of format
RuleType+RuleName+JobNameMask+CdsID.
IBMRMM_Product ProductNumber and CdsID keys have been replaced with
IdentifyingNumber key of format ProductNumber+CdsID.
IBMRMM_ShelfLocation LocationName, MediaName, ShelfLocationNumber, and
CdsID keys have been replaced with Tag key of format
LocationName+MediaName+Number+CdsID.

Starting with z/OS V1R10, in order to simplify processing of the compound keys,
every changed class has the KeyWithCdsIdName attribute containing the name of
its compound key. Additionally, xxxFormat and xxxMask attributes are provided,
where xxx is the name of the compound key. For example, TagFormat property of
IBMRMM_PhysicalVolume is set to "Volser+CdsID" and TagMask string contains
the consecutive concatenation of six blanks, symbol "+", and eight blanks.

Reference information: For additional details, see the topic “Setting up
DFSMSrmm CIM provider” in z/OS DFSMSrmm Implementation and Customization
Guide.

DFSMS actions to perform before the first IPL of z/OS V1R13
This topic describes DFSMS migration actions that you can perform after you have
active.

DFSMSdfp: Ensure that the Language Environment runtime
library is available for DLLs
Description: Language Environment provides common services and
language-specific routines in a single runtime environment. You can use Language
Environment to build and use dynamic link libraries (DLLs) for applications.

specific release.
Is the migration action required? Yes, if your installation builds or references
DLLs.


requirements:
Restrictions: None.
check:

Steps to take: If your installation builds or references DLLs, either you must set up
the system link list to refer to the Language Environment runtime libraries
(SCEERUN and SCEERUN2), or each job that creates or uses a DLL must include a
STEPLIB DD statement referencing these libraries.

v z/OS Language Environment Run-Time Application Migration Guide
v z/OS Language Environment Customization
v z/OS Language Environment Programming Guide

DFSMSdfp: Update SYS1.IMAGELIB
Description: If you use page mode printers such as the IBM 3800 or the IBM 3900
running in line mode (not page mode), you must install library character sets,
graphic character modification modules, and character arrangement tables in
SYS1.IMAGELIB. This migration action does not apply if you are using IBM 3900
printers that are driven by PSF.

specific release.
Is the migration action required? Yes, if you are not using your old
SYS1.IMAGELIB, you are installing with
ServerPac or SystemPac, and you are using
line mode printers such as the 3800 or 3900.
Target system hardware requirements: IBM 3800 or 3900 printers.
requirements:
Restrictions: None.
check:

Steps to take:
1. Run the LCSBLD1 job from the samplib data set to create character sets,
graphic character modification modules, and character arrangement tables in
SYS1.IMAGELIB.
2. Copy customized or locally-written FCBs and UCS images from your old
system's SYS1.IMAGELIB data set to the new system's SYS1.IMAGELIB data
set.


Reference information: For information about maintaining SYS1.IMAGELIB, see
z/OS DFSMSdfp Advanced Services.

| DFSMSdfp: Update operator procedures and system
| automation for new DADSM pre- and post-processing dynamic
| exits
| Description: Before z/OS V1R13, exits for the DADSM pre- and post-processing
| functions were loaded by DFSMSdfp, as installation exits during initialization, as
| modules IGGPRE00 and IGGPOST0. Starting with z/OS V1R13, z/OS dynamic
| exits services is used to define a pre-processing dynamic exit, IGGPRE00_EXIT, and
| a post-processing dynamic exit, IGGPOST0_EXIT, and associate IGGPRE00 and
| IGGPOST0 modules as exit routines to these respective dynamic exits. All DADSM
| functions (create, extend, scratch, partial release, and rename) share these common
| dynamic exits and will be called where the previous installation exits of IGGPRE00
| and IGGPOST0 were called using the same existing interfaces. This change requires
| changes to DFSMSdfp operating procedures and system automation (if any).
|
| Is the migration action required? Yes, if DADSM installation exits IGGPRE00
| or IGGPOST0 are in use.
| requirements:
| check:
|

| Steps to take:
| v If you use the IGGPRE00 or the IGGPOST0 installation exits, you do not need to
| change them in any way; just install them as you always have. DFSMSdfp will
| automatically exploit the dynamic exit services and use your IGGPRE00 or
| IGGPOST0 installation exit as exit routines to the new IGGPRE00_EXIT and
| IGGPOST0_EXIT dynamic exits. You do not need to change the load module
| names for IGGPRE00 or IGGPOST0, however, you may change the names if
| desired. If you do change the names, update the PROGxx parmlib member or
| issue the SETPROG command to get the modules loaded because DFSMSdfp
| will not load them as exit routines to the dynamic exits.
| v You can now have multiple exit routines associated with each of the
| IGGPRE00_EXIT and IGGPOST0_EXIT dynamic exits for the DADSM pre- and
| post-processing exits. Other programs can use the CSVDYNEX macro to
| associate their exit routines to these dynamic exits and can add and delete exit
| routines from any dynamic exit routine as required. They also can be added and
| deleted with the PROGxx member of parmlib and with the SETPROG ADD
| operator command. All exit routines will be called when the DADSM pre- and
| post-dynamic exits are called from each DADSM function. The execution of one


| exit routine may then change the behavior of a subsequent one. The order in
| which the exit routines are called by the system could be in any order.
| v The IGGPRE00 and IGGPOST0 module addresses in the CVAF table
| (CVFDPR31, CVFDPOR31) will continue to be set. Therefore, other programs
| that continue to use this interface will be unaffected. Since dynamic exit services
| would not be used in this case, no other exit routine associated with the
| dynamic exits will be called. These programs should be changed to use dynamic
| exit services, CSVDYNEX.

| Reference information: To read more about the use of dynamic exit services and
| these new dynamic exits, see:
| v z/OS MVS Programming: Authorized Assembler Services Guide for information
| about the CSVDYNEX macro.
| v z/OS MVS Initialization and Tuning Reference for information about the PROGxx
| parmlib member.
| v z/OS MVS System Commands for information about the D PROG, SETPROG
| EXIT, and SET PROG=xx commands.
| v z/OS DFSMS Installation Exits, "DFSMS Data Management Installation/Dynamic
| Exits" chapter.

| DFSMSdfp: Update procedures that use IEBDSCPY alias name
| to access IEBCOPY
| Description: Before z/OS V1R13, the IEBCOPY utility was an APF-authorized
| program that had to run from an APF-authorized library. If another program called
| IEBCOPY, that program also had to be APF-authorized. Starting in z/OS V1R13,
| the IEBCOPY utility is no longer APF-authorized and can be run from
| non-authorized libraries; callers of IEBCOPY no longer need to be APF-authorized.
| In addition to this authorization change, other performance improvements have
| been made to IEBCOPY as well.

| IEBCOPY is a data set library management utility that is used to perform many
| critical system build and maintenance activities. If this utility does not work
| correctly, then key library data sets could be rendered as unusable and the z/OS
| user would be left without a fallback method. A fallback copy of the z/OS V1R12
| level of IEBCOPY is provided, named IEBCOPYO, for use if you experience
| problems with the updated version of IEBCOPY in z/OS V1R13. The old
| IEBCOPYO utility with its alias of IEBDSCPY is installed into SYS1.LINKLIB with
| authorization code one, AC(1).

| Since the code in IEBCOPY is now different from the code in IEBCOPYO, IBM
| recommends that you do not copy and replace IEBCOPY with IEBCOPYO because
| of maintenance issues. PTFs will update IEBCOPY and IEBCOPYO load modules
| appropriately as each load module requires service.

| The IEBDSCPY alias name of IEBCOPY that exists in earlier versions of DFSMS is
| no longer an alias name in the z/OS DFSMS V1R13 IEBCOPY load module. The
| IEBDSCPY alias name continues to exist as the alias to the IEBCOPYO load
| module in z/OS V1R13, but will be eliminated as an alias of the IEBCOPYO load
| module in future releases of DFSMS. If you currently access the IEBCOPY utility
| by using the IEBDSCPY alias name, you need to make the necessary change to use
| the IEBCOPY primary name.
|


| Is the migration action required? No, but reommended if you don't want to be
| connected to the pre-z/OS V1R13 version of
| IEBCOPY.
| requirements:
| System impacts: It is important to note with the changes
| introduced in z/OS V1R13 IEBCOPY, the
| requirement for SMP/E to be APF-authorized
| remains. That is, these IEBCOPY changes
| have no effect on the requirement that
| SMP/E is APF-authorized.
| check:
|

| Steps to take:
| v Programs or procedures that use the IEBDSCPY alias name to access IEBCOPY
| should be changed to use the IEBCOPY primary name. Programs that continue
| to use the alias name will connect to the old, pre-z/OS V1R13 version, currently
| called IEBCOPYO.
| v IEBCOPY can now be called by programs that are not APF-authorized.

| Reference information: For more information about the IEBCOPY utility, see z/OS
| DFSMSdfp Utilities.

DFSMSdfp: Evaluate applications and modify for EAV
enhancements
Description: Starting with z/OS V1R12, additional non-VSAM data set types in the
extended addressing space (EAS) are supported. This includes support for
sequential (BASIC or LARGE), partitioned (PDS or PDSE), Catalogs, and BDAM
data sets in EAS. Before z/OS V1R12, any program trying to open one of these
types of non-VSAM data sets that have been allocated with extended attribute
DSCBs (format 8 DSCB from a z/OS V1R12 system) failed with abend IEC144I
313-0C. Now on a z/OS V1R12 system, applications can open these non-VSAM
data sets allocated with extended attribute DSCBs with standard BSAM, BPAM
and QSAM access.

In many cases, application programs will function as usual. However, application
programs that reference the data set extents found in the DEB or access the DSCB
or its extents must change to either support format 8 DSCBs and 28-bit cylinder
addressing or to abend when they encounter such data sets.



Is the migration action required? Yes, for application programs that allocated
the non-VSAM data sets listed above with
the extended attributes option from z/OS
V1R11.
requirements:
Restrictions: None.
Related IBM Health Checker for z/OS None
check:

Steps to take:
v Look for applications that allocated the following types of non-VSAM data sets
in EAS with the extended attributes option from z/OS V1R11:
– Sequential (BASIC or LARGE)
– Partitioned (PDS or PDSE)
– Catalogs
– BDAM
Look for applications that allocate these non-VSAM data sets in EAS with the
EATTR=OPT data set keyword on JCL or in SMS data class to specify that the
data set can have extended attribute DSCBs (format 8/9 DSCBs) and can
optionally have extents in the EAS. In z/OS V1R11, the EATTR keyword would
have no affect for these non-VSAM data sets until the data set type is enabled in
the system for EAS. However, in z/OS V1R12 these data set types are enabled
for EAS.
v Affected applications must either support format 8 DSCBs and 28–bit addressing
or to issue an abend code to fail processing when they encounter such data sets,
because the system will no longer automatically abend with IEC144I 313-0C.

Reference information: See also Using extended address volumes enhancements in
z/OS DFSMS Using the New Functions and information about the EAV migration
assistance tracker in Using the extended address volume (EAV) migration
assistance tracker in z/OS DFSMSdfp Advanced Services.

DFSMSdfp: Accommodate new DCBE macro option
Description: Before z/OS V1R12, the DCB access methods did not support the
nocapture UCB option of a dynamic allocation. Starting in z/OS V1R12, the DCB
access methods will support a new DCBE option, LOC=ANY, to signify that the
application program supports the XTIOT, UCB nocapture and DSAB-above-the-line
options of dynamic allocation. The new DCBE option also signifies that the
application program has no dependancy on any of XTIOT, UCB address or
DSAB-above-the-line options of dynamic allocation.



Is the migration action required? Yes, if you use the XTIOT, UCB nocapture
and DSAB-above-the-line options of dynamic
allocation, or if any of the callers of your
program might have used those options to
allocate files which your program will open .
requirements:
Restrictions: None.
check:

Steps to take:
1. Review, and modify if needed, the installation exit routines that receive a TIOT
entry or UCB address directly or indirectly. These include:
v DADSM pre- and post-processing exits (IGGPRE00 and IGGPOST0).
v Tape management exits (IFG019LA (label anomaly), IFG019VM (volume
mount), IFG019FV (file validation), IFG019FS (file start on volume) and
IFG055FE (file end on volume)). They receive UCB addresses from
TEPMUCB in IFGTEP, from DEBUCBA and from TIOEFSRT. All three
sources will allow a 31-bit UCB address. TEPMUCB sometimes will be an
uncaptured 31-bit address. If the new DEB31UCB bit is on, the UCB address
and modeset byte will be different as described in IEZDEB.
v NSL tape exits (NSLOHDRI, NSLEHDRI, NSLOHDRO, NSLEHDRO,
NSLETRLI, NSLETRLO, NSLCTRLO, IEFXVNSL and NSLREPOS). OPEN,
EOV and CLOSE will always turn DEB31UCB on in the work area to signify
that DXDEBUCB is a 31-bit UCB address and the modeset byte is moved as
described above. Even though the UCB address field will be four bytes, it
typically will still contain a three-byte address.
v Volume label editor routines (IFG0193C and IFG0553C). Same work area
changes as described for the NSL routines.
v DCB OPEN installation exit (IFG0EX0B).
v The IGXMSGEX installation exit for the MSGDISP macro already supports its
caller passing a 31-bit UCB address but there might be more cases in which
this occurs.
v The data management ABEND installation exit (IFG0199I) passes a UCB
address in field OAIXUCBA. It might now be 31-bit.
v IECIEUCB as mapped by the IECIEPRM macro for the ISO/ANSI Version 3
and Version 4 installation exits (IFG0193G) contains the tape UCB address. In
the past this has always been a 24-bit address. Now it might be a 31-bit
address.
The above exits are documented in z/OS DFSMS Installation Exits. IEFDB401, a
dynamic allocation input validation exit, is documented in z/OS MVS
Installation Exits.
2. Verify that the installation exit routines will not be affected adversely.
| 3. Set the NON_VSAM_XTIOT option to YES or NO in the DEVSUPxx parmlib
| member. (The default is NON_VSAM_XTIOT=NO.)


4. Change the program to set LOC=ANY in the DCBE macro. The default is
LOC=BELOW.

| Note: The new DCBELOCANY flag can only be used in z/OS V1R12 or later.
| If a program has the DCBELOCANY flag defined, and is compiled or
| assembled using a z/OS V1R11 level of the DFSMS macros, then a
| compile or assemble error will occur. See APAR OA33409 for more
| information.

Reference information: For details about the new DCBE option, see z/OS DFSMS
Macro Instructions for Data Sets and z/OS DFSMS Using the New Functions.

DFSMSdss: Build the IPLable stand-alone DFSMSdss image
Description: If you intend to use the Stand-Alone Services provided by DFSMSdss,
you must use the DFSMSdss BUILDSA function to create the Stand-Alone Services
IPL-capable core image. Starting with z/OS V1R12, DFSMSdss now uses BSAM
instead of EXCP to read from and write to DFSMSdss dump data sets during
DUMP, COPYDUMP, and RESTORE operations. To migrate to this support, you
must rebuild the IPL-able core image for the Stand-Alone Services program.

If this migration action is not performed, users of the DSS standalone restore will
not be able to restore backups on tape created with greater than 65520 byte blocks.
Message ADRY3530I SEQUENCE ERROR ON RESTORE TAPE is issued and the
operation is terminated. Backups created with 65520 byte blocks will restore as
they did in z/OS V1R11.

Element or feature: DFSMSdss.
specific release.
Is the migration action required? Yes, if you intend to use the Stand-Alone
Services provided by DFSMSdss.
Target system hardware requirements: Stand-Alone Services supports the IBM 3494
TotalStorage Enterprise Automated Tape
Library, the IBM 3495 TotalStorage Enterprise
Automated Tape Library, and the IBM 3590
TotalStorage Enterprise Tape Subsystem.
requirements:
Restrictions: Stand-Alone Services does not support the
creation of the core image on an
SMS-managed volume.
System impacts: v To ensure that Stand-Alone Services is
available when you run from DASD, do
not delete the SYS1.ADR.SAIPLD.Vvolser
data set or move it to another volume.
v If you IPL from DASD and later change
the volume serial number, you must rerun
the BUILDSA function to create a new core
image data set with the new volume serial
number in the name.


check:

Steps to take:
1. Prepare for Stand-Alone Services by creating a Stand-Alone Services IPLable
core image with the BUILDSA command. With the BUILDSA command you
can specify the device (card reader, tape drive, or DASD volume) from which
Stand-Alone Services will be IPLed. You can also specify the operator console
to be used for Stand-Alone Services.
The BUILDSA function builds the IPLable core image under the current
operating system and determines a record size based on whether the IPL is
from card, tape, or DASD.
2. Use RACF or another external security system to protect the
SYS1.ADR.SAIPLD.Vvolser data set and the Stand-Alone Services modules.
3. If you have not done so already, make a backup copy of your system that can
be restored by this function. For information about backing up volumes, see
z/OS DFSMSdss Storage Administration.

Note: Message ADRY3530I SEQUENCE ERROR ON RESTORE TAPE might be
issued with operation terminated if a user tries to restore a back up that
was created with a block size greater than 65520 bytes, using the DSS
stand-alone restore program from z/OS V1R11.

Reference information: For more information, see z/OS DFSMSdfp Storage
Administration.

DFSMSdss: Recompile and link-edit exit routines or
applications that change options in the ADRUFO block
Description: Starting with z/OS V1R12, if you change options in the ADRUFO
block with either:
v the options installation exit routine, ADRUIXIT, or
v an application that invokes DFSMSdss with the API or XMAPI and then uses the
Presenting ADRUFO Record exit (Eioption exit 13),
you must recompile and link-edit the exit routine or application using macro
libraries provided with z/OS V1R12.

Is the migration action required? Yes, if you change options in the ADRUFO
block with either the exit routine or
application.
requirements:
Restrictions: None.


check:

Steps to take: Recompile and link-edit the exit routine or application using macro
libraries provided with release z/OS V1R12.

Reference information: For details, see z/OS DFSMS Installation Exits.

DFSMSdss: Modify applications to handle larger I/O buffers
Description: Starting with z/OS V1R12, DFSMSdss uses BSAM instead of EXCP to
read from and write to DFSMSdss dump data sets during DUMP, COPYDUMP,
and RESTORE operations. This allows DFSMSdss to support 256K blocksize when
writing to and reading from a tape. Before z/OS V1R12, the maximum was 65,520
bytes. If you have an application that invokes DFSMSdss with the API or XMAPI,
you should ensure that the application handles I/O buffers up to the new
maximum of 262,144 bytes. The affected exit options are EIOP03 and EIOP06. For
these exits, the storage (buffer) pointed to by EIRECPTR may now be greater than
65,520 bytes, up to a maximum of 262,144 bytes.

Is the migration action required? Yes, if the application invokes DFSMSdss
with the API or XMAPI.
Other system (coexistence or fallback) Note: Tapes with greater than 65,520 bytes
requirements: BLKSIZE can be read by z/OS V1R11
systems with the PTFs for APAR OA30822
| installed. If you try to restore from a tape
| that has greater than 64K blocksize, but do
| not have the PTFs for OA30822 installed on
| your system, the restore will fail. Most likely,
| it will fail with an ADR370E INVALID
| SEQUENCE NUMBER error message.
Restrictions: None.
check:

Steps to take:
v Ensure that the application can handle I/O buffers that are up to 262,144 bytes.
If the application cannot handle I/O buffers that are up to 262,144 bytes, you
can:
– Specify PARM='USEEXCP=YES' in OPTPTR of the API or the EXEC PARM
with PGM=ADRDSSU (for example, EXEC
PGM=ADRDSSU,PARM='USEEXCP=YES'). You can also specify
PARM='USEEXCP=YES' in OPTPTR of the API that invokes ADRXMAIA, or
specify it on the EXEC PARM with PGM=ADRXMAIA (for example, EXEC
PGM=ADRXMAIA,PARM='USEEXCP=YES').


– Set a block size to an acceptable value either with the JCL DD statement or
when dynamically allocating the DD for your application during processing
of the Presenting ADRUFO Record exit (Eioption exit 13).
– Code BLKSZLIM and set the BLKSZLIM value to 65,520. Note that DSS only
supports BLKSZLIM of 65,520 and above; for a backup to be compatible with
releases earlier than z/OS V1R10, the backup must have no larger than 65,520
byte blocks. BLKSZLIM can be set in the following places:
1. BLKSZLIM keyword on the DD statement or dynamic allocation. The
BLKSZLIM keyword on a DD statement keyword is described in z/OS
MVS JCL Reference.
2. Block size limit in data class. Set by storage administrator. Available even
if the data set is not SMS-managed. The block size in the data class is
described in z/OS DFSMS Implementing System-Managed Storage.
3. System default set in TAPEBLKSZLIM keyword in DEVSUPxx parmlib
member in SYS1.PARMLIB. Also available in DFA. The TAPEBLKSZLIM
parameter is described in z/OS MVS Initialization and Tuning Reference.
v If the application inspects the DTVBLKSZ field in the volume record of physical
dumps or the DTHBLKSZ field in the data set header of logical dumps, you
may need to make further changes. When a physical backup is created on tape
with a block size that is greater than 65,520 bytes, the DTVBLKSZ field is
X'FFFE'. The block size is stored in an extended volume record following the
volume record, DTSDEVOL. When a logical backup is created on tape with a
block size greater than 65,520 bytes, the DTHBLKSZ field is X'FFFE'. The block
size is stored in a new extended tape header record, S, following the data set
header record.

Reference information: For information about the API, see z/OS DFSMSdss Storage
Administration. For information about the Presenting ADRUFO Record exit
(Eioption exit 13) , see z/OS DFSMS Installation Exits.

| DFSMShsm: Accommodate the changed default of PDA trace
| during DFSMShsm startup
| Description: Before z/OS V1R13, PDA trace was disabled (PDA=NO) during
| DFSMShsm startup unless PDA=YES was manually added to the DFSMShsm
| startup procedure. Starting with z/OS V1R13, PDA trace is enabled (PDA=YES) by
| default during DFSMShsm startup. After DFSMShsm is started, the SETSYS PDA
| setting controls PDA tracing.
|
| Element or feature: DFSMShsm.
| Is the migration action required? Yes, if you do not want the new default.
| requirements:
| check:


|

| Steps to take: To enable PDA trace during DFSMShsm startup, no action is
| required. To disable PDA trace during DFSMShsm startup, specify PDA=NO in the
| DFSMShsm startup procedure before starting DFSMShsm.

| Reference information: For more information about enabling or disabling PDA
| trace during DFSMShsm startup, see z/OS DFSMShsm Implementation and
| Customization Guide.

| DFSMShsm: Accommodate the changed SETSYS
| FASTREPLICATION command DATASETRECOVERY parameter
| default
| Description: Before z/OS V1R13, the SETSYS FASTREPLICATION command
| DATASETRECOVERY parameter default was PREFERRED and fast replication data
| set recovery was performed whenever possible. The standard copy method was
| used when fast replication could not be. Starting with z/OS V1R13, the SETSYS
| FASTREPLICATION command DATASETRECOVERY parameter default is
| changed to NONE and the standard copy method is used to perform data set
| recovery. Fast replication is not used by default.
|
| Is the migration action required? Yes, if you want to use fast replication for
| data set recovery and you do not currently
| specify a fast replication data set recovery
| preference in the ARCCMDxx parmlib
| member of SYS1.PARMLIB.
| requirements:
| check:
|

| Steps to take:
| 1. Determine which fast replication data set recovery preference you want to use.
| 2. Add a fast replication data set recovery preference to the ARCCMDxx parmlib
| v If a fast replication data set recovery preference is specified and matches the
| preference you want to use, no action is required.
| v If no fast replication data set recovery preference is specified, add SETSYS
| FASTREPLICATION (DATASETRECOVERY (PREFERRED)) to continue
| using the same preference as before z/OS V1R13.


| Alternatively, if your preference is to require fast replication data set recovery,
| you can specify SETSYS FASTREPLICATION (DATASETRECOVERY
| (REQUIRED)).
| Notes:
| 1. If you previously specified SETSYS FASTREPLICATION
| (DATASETRECOVERY (NONE)) in the ARCCMDxx parmlib member of
| SYS1.PARMLIB, you can optionally remove it and use the default.
| 2. The FRRECOV command ALLOWPPRCP options
| PRESERVEMIRRORREQUIRED, PRESERVEMIRRORPREFERRED,
| PRESERVEMIRRORNO, and YES cannot be used if fast replication data set
| recovery is not allowed. That is, if the z/OS V1R13 SETSYS
| FASTREPLICATION command DATASETRECOVERY parameter default is
| used or if SETSYS FASTREPLICATION (DATASETRECOVERY (NONE))
| setting is in effect.

| Reference information: For more information about fast replication, the FRRECOV
| command, and the SETSYS command, see z/OS DFSMShsm Storage Administration.

| DFSMShsm: Replace user-defined patch with new SETSYS
| FASTREPLICATION command to enable ARC1809I messages
| Description: Before z/OS V1R13, a patch was required to enable (and
| subsequently disable) ARC1809I messages during fast replication volume pairing.
| Starting with z/OS V1R13, the VOLUMEPAIRMESSAGES parameter is added to
| the existing SETSYS FASTREPLICATION command to control the issuance of the
| ARC1809I messages. Remove the patch and replace it with the new parameter.
|
| Is the migration action required? Yes, if the ARCCMDxx parmlib member of
| SYS1.PARMLIB contains: PATCH .FRGCB.+9
| BITS(.1......)
| requirements:
| Restrictions: The SETSYS FASTREPLICATION
| (VOLUMEPAIRMESSAGES(YES))
| statement in ARCCMCxx is not supported
| on pre-z/OS V1R13 systems.
| check:
|

| Steps to take:
| 1. Remove PATCH .FRGCB.+9 BITS(.1......) from the ARCCMDxx parmlib
| 2. Add SETSYS FASTREPLICATION(VOLUMEPAIRMESSAGES(YES)) to the
| ARCCMDxx parmlib member of SYS1.PARMLIB.


| Reference information: For more information about using the SETSYS
| FASTREPLICATION command and VOLUMEPAIRMESSAGES parameter to
| disable unwanted ARC1809I messages, see z/OS DFSMShsm Storage Administration.

| DFSMShsm: Review messages changed from I (informational)
| to E (eventual action) type
| Description: Before z/OS V1R13, messages ARC0036, ARC0503, and ARC0704
| were informational messages (ending in the letter “I”). Starting with z/OS V1R13,
| messages ARC0036, ARC0503, and ARC0704 are reclassified as eventual action
| messages (ending in the letter “E”). The meaning of the messages is unchanged.
| The type is changed only.

| Each of these messages indicate a significant error has occurred and are more
| easily identifiable as eventual action messages.
| v Message ARC0036E indicates that an I/O error occurred when writing to the
| PDA output data set.
| v Message ARC0503E indicates a dynamic allocation error.
| v Message ARC0704E indicates a VTOC copy data set processing error during
| volume backup, dump, or recovery.
| These changes can affect applications that depend on message ARC0036I,
| ARC0503I, or ARC0704I and applications triggered by message type.
|
| Is the migration action required? Yes, if your applications depend on message
| ARC0036I, ARC0503I, or ARC0704I or if your
| applications are triggered by message type.
| requirements:
| check:
|

| Steps to take: Update applications that:
| v depend on ARC0036I to work with ARC0036E.
| v are triggered by message type.

| Reference information: For more information about DFSMShsm messages, see
| z/OS MVS System Messages, Vol 2 (ARC-ASA).


| DFSMShsm: Remove patch that prevents SMS MVT chain
| rebuild
| Description: Before z/OS V1R13, the flag at MCVT+C8 X'80' was used to prevent
| the SMS MVT chain rebuild at the beginning of primary space management and at
| the beginning of interval migration, based on the current SMS storage group
| definitions. If the SMS storage groups had not been changed and no new SMS
| volumes had been added since the last time primary space management or interval
| migration was run, you could prevent the SMS MVT chain from being needlessly
| rebuilt or refreshed by entering the following PATCH command:

| PATCH .MCVT.+C8 BITS(1.......)

| Starting with z/OS V1R13, this flag is maintained automatically by DFSMShsm.
| DFSMShsm checks for the occurrence of an ENF 15 event at the beginning of
| primary space management, at the beginning of interval migration, and at the
| beginning of on-demand migration. When an ENF 15 event is reported,
| DFSMShsm performs an SMS MVT chain rebuild or refresh. After a successful SMS
| MVT chain rebuild, DFSMShsm does not rebuild or refresh the MVT chain until
| the next SMS configuration change (that is, the next ENF 15 event).

| Starting with z/OS V1R13, DFSMShsm does not take into account the PATCH
| .MCVT.+C8 BITS(1.......) command. Nevertheless, it is recommended to remove
| this patch command from the ARCCMDxx parmlib member of SYS1.PARMLIB to
| avoid any misunderstanding.
|
| Element or feature: DFSMS.
| Is the migration action required? No, but recommended because starting from
| z/OS V1R13, the patch command no longer
| performs a useful function other than what is
| already handled automatically by
| DFSMShsm. Additionally, it been discovered
| in the past that leaving unnecessary useless
| patches in DFSMShsm's startup procedures
| can cause confusion and potential problems.
| Other system (coexistence or fallback) Remove this patch when all systems are at
| requirements: z/OS V1R13 if a common DFSMShsm's
| startup procedure is shared with downlevel
| systems.
| check:
|

| Steps to take: Remove PATCH .MCVT.+C8 BITS(1.......) from the ARCCMDxx
| parmlib member of SYS1.PARMLIB.

| Reference information: None.


| DFSMShsm: Update operator procedure in the Multicluster
| CDS environment
| Description: In the DFSMShsm Multicluster control data sets environment, the
| same number of clusters must be specified to all DFSMShsm hosts that are sharing
| a multicluster MCDS or BCDS, or both. If a DFSMShsm host is started with a
| different number of clusters than the other currently active hosts, the CDS will be
| logically corrupted and may require extensive recovery actions.

| In z/OS V1R12 (and in z/OS V1R11, z/OS V1R10, and z/OS V1R9 when the PTF
| for OA29346 is installed), DFSMShsm is modified to detect a conflict between the
| number of CDS clusters specified to a host in the startup proclib JCL and the
| number recorded in the MHCR record.
|
| When change was introduced: z/OS V1R12 (z/OS V1R11, z/OS V1R10, and
| z/OS V1R9 by APAR OA29346).
| Applies to migration from: z/OS V1R11 without the PTF for APAR
| OA29346 applied.
| Is the migration action required? Yes, if you use the DFSMShsm Multicluster
| CDS environment.
| requirements:
| check:
|

| Steps to take: A new WTOR message, ARC0264A, is issued asking if the change to
| the cluster number is intended. If the reply is Y, the DFSMShsm host is allowed to
| start with the new cluster count. If the reply is N, the DFSMShsm host is not
| allowed to start, which results in error message ARC0130I RC20.
| ARC0264A {MCDS|BCDS} CLUSTERS CHANGED FROM m TO d. IF NOT INTENDED,
| STARTUP WILL RESULT IN CDS CORRUPTION. INTENDED? (Y OR N)
| ARC0130I CONTROL DATA SET DEFINITION RULES FOR THE {MCDS|BCDS} WERE NOT FOLLOWED,
| RETURN CODE=20

| The WTOR message is issued at the first DFSMShsm host initialization right after
| switching into the multicluster CDS environment.

| Note: Regardless of the single or multiple DFSMShsm host environment, the
| initialization of the first host after the number of CDS clusters has been
| updated by the reorganization will result in an ARC0264A WTOR message
| asking the operator to confirm the new cluster count.

| Reference information: For more information about the Multicluster Control Data
| Sets, see z/OS DFSMShsm Implementation and Customization Guide.


DFSMShsm: Remove user-defined patch that disables or
enables use of the DFSMSdss cross memory API
| Description: In z/OS V1R10 and later, DFSMShsm's use of the DFSMSdss cross
| memory API can be disabled or enabled by including a patch or the SETSYS
| DSSXMMODE (Y | N) command in the ARCCMDxx parmlib member of
| SYS1.PARMLIB. Starting with z/OS V1R12 , support is added to the existing
| SETSYS DSSXMMODE command to permit the Y and N setting to individually
| control backup, CDS backup, dump, migration, full-volume recovery, and data set
| recovery. Because of this, disabling or enabling DFSMSdss cross memory mode
| should be done exclusively with the SETSYS DSSXMMODE command. Instances
| of patching the MCVT at offset +433 should be removed from ARCCMDxx.

Element or feature: DFSMShsm.
Is the migration action required? Yes, if the ARCCMDxx parmlib member of
SYS1.PARMLIB contains: PATCH .MCVT.+433
requirements:
Restrictions: None.
check:

Steps to take:
1. Remove PATCH .MCVT.+433 from the ARCCMDxx parmlib member of
SYS1.PARMLIB.
2. Add the corresponding SETSYS DSSXMMODE command in the ARCCMDxx
parmlib member of SYS1.PARMLIB.

Reference information: For more information about using the SETSYS
DSSXMMODE command, see z/OS DFSMShsm Storage Administration.

DFSMShsm: Configure your security system to permit started
procedures using new address space identifier
Description: Before z/OS V1R12, when using the DFSMSdss cross memory API,
the address space identifier for full-volume and data set recovery from dump was
| ARCnREST. Starting in z/OS V1R12, when using the DFSMSdss cross memory
| API, the address space identifier for full-volume recovery from dump is changed
| to ARCnRSTy where n is the DFSMShsm host ID and y is the instance of the
| DFSMSdss started task (a number 1 - 4). Data set recovery from dump will still use
ARCnREST.

With the addition of multitasking volume recovery from DUMP in z/OS V1R12,
the address space names for the DSS cross memory address spaces are separated
so that four DSS volume recovery address spaces and only one DSS data set


recovery address space can be created. ARCnREST is used for data set recovery
from dump; ARCnRSTy is used for volume recovery from dump

Is the migration action required? Yes, if DFSMSdss cross memory support is
used for full-volume recovery from dump.
requirements:
Restrictions: None.
check:

Steps to take: Before attempting full-volume recovery from dump, configure your
security system to permit started procedures using the new address space
identifier for DFSMSdss cross memory support for full-volume recovery from
dump.

Reference information: For more information about controlling use of DFSMSdss
cross memory support using the SETSYS DSSXMMODE command, see z/OS
DFSMShsm Storage Administration. For more information about DFSMSdss address
spaces started by DFSMShsm and configuring your security system, see z/OS
DFSMShsm Implementation and Customization Guide.

DFSMShsm: Update applications that depend on QUERY
COPYPOOL output
Description: Before z/OS V1R12, the DFSMShsm QUERY COPYPOOL command
output did not display FlashCopy® “background copy percent-complete”
information. Starting in z/OS V1R12, the QUERY COPYPOOL command output in
message ARC1820I will display applicable “background copy percent-complete”
(PCT-COMP) information for full-volume FlashCopy pairs with an incomplete
background copy. Percent-complete information (a percentage) is available for
full-volume FlashCopy pairs with an incomplete background copy only. A
full-volume FlashCopy relationship is established when the FlashCopy technique
(such as fast reverse restore or incremental) designates it, or when SETSYS
FASTREPLICATION(FCRELATION(FULL)) has been specified.

This change can affect applications that depend on QUERY COPYPOOL output.



Is the migration action required? Yes, if you will be using any FlashCopy
technique that creates a full-volume
FlashCopy relationship or if you will be
specifying SETSYS
FASTREPLICATION(FCRELATION(FULL))
and your applications depend on QUERY
COPYPOOL output or message ARC1820I.
requirements:
Restrictions: None.
check:

Steps to take: Update applications that depend on QUERY COPYPOOL output.

Reference information: For more information about using the QUERY command,
see z/OS DFSMShsm Storage Administration.

DFSMShsm: Update applications that depend on LIST
command output
Description: The DFSMShsm LIST command output changed in z/OS V1R11 and
in z/OS V1R12.
v Starting in z/OS V1R11, the LIST DSNAME(dsname) BCDS and LIST LEVEL(hlq)
BCDS output no longer display the RACF IND field when OUTDATASET or
SYSOUT (default) is specified as the destination for the output. The RACF IND
field is displayed when TERMINAL is specified as the destination for the
output.
v Starting in z/OS V1R12, the LIST COPYPOOL(cpname) output includes: a new
FASTREPLICATION state (FCFRRINCOMPLETE), fast reverse restore status field
(FCFRR=), and recovery complete status field (RECOVERYINCOMPLETE=). This
new output is displayed when OUTDATASET, SYSOUT (default), or TERMINAL
is specified as the destination for the output.

These changes can affect applications that depend on LIST output.

When change was introduced: z/OS V1R12 and z/OS V1R11 (as explained
in the description).
Is the migration action required? Yes, if your applications depend on the
RACF IND field value in the output with the
OUTDATASET or SYSOUT destination, or if
your applications depend on LIST
COPYPOOL(cpname) output.


requirements:
Restrictions: None.
check:

Steps to take:
1. Remove any dependency on the RACF IND field on the LIST
DSNAME(dsname) BCDS or LIST LEVEL(hlq) BCDS output when using
OUTDATASET or SYSOUT.
2. Update applications that depend on LIST COPYPOOL(cpname) output to handle
the new FASTREPLICATION state and new fields.

Reference information: See Using the LIST Command in z/OS DFSMShsm Storage
Administration.

DFSMShsm: Accommodate the change of ARCBDEXT exit
Description: Prior to DFSMShsm z/OS V1R10, ARCBDEXT was called during
volume-level backup operations (AUTOBACKUP for automatic and BACKVOL for
command-based operations). Users examined information in the exit's input data
structure to determine whether to allow or disallow backup of a data set. Starting
with DFSMShsm z/OS V1R10, ARCBDEXT is called during individual data set
backup operations, as well as volume-level backup operations. When called for
individual data set backup, the exit's input data structure differs, but the return
code values and meanings remain the same as for volume-level backups. Users
must examine the level information in the input data structure, at offset x'04' , to
determine whether ARCBDEXT is being invoked for volume-level or for individual
data set backup.

When change was introduced: z/OS V1R11 by APAR OA28948 and z/OS
V1R10 by APAR OA28136.
Applies to migration from: z/OS V1R11 without APAR OA28948.
Is the migration action required? Yes, if you want to allow command backup
but disallow autobackup for some data sets.
requirements:
Restrictions: None.

Steps to take: Examine the level information in the input data structure at offset
x'04' to determine whether ARCBDEXT is being invoked for volume-level or for
individual data set backup. The level field will contain '*EXPAND1' for
volume-level requests and '*EXPAND2' for individual data set backup requests. For
individual data set backup requests, the field at offset x'0C' contains additional


status information about whether the backup request is the result of a backup data
set command or the result of retry from a volume command.

Reference information: For more information, see z/OS DFSMS Installation Exits.

DFSMS actions to perform after the first IPL of z/OS V1R13
This topic describes DFSMS migration actions that you can perform only after you
actions.

| DFSMSdfp: Accommodate 64-bit and AR mode rules
| enforcement in DFSMS macros
| Description: Before z/OS V1R13, many DFSMS macros that did not support 64-bit
| or AR mode did not react to being invoked in 64-bit or AR mode, and generated
| code that might have been invalid in 64-bit or AR mode. Starting with z/OS
| V1R13, these macros are changed to issue an assembly-time message and suppress
| expansion if they are invoked in 64-bit or AR mode. If you have code, including
| exits, that invokes DFSMS macros, you should review your code and modify it as
| appropriate to accommodate the new enforcement of 64-bit and AR mode rules.
|
| Is the migration action required? Yes, if you have code, including exits, that
| invokes DFSMS macros.
| requirements:
| check:
|

| Steps to take: Modify your source code so that no DFSMS macros are invoked
| after the SYSSTATE macro specifies 64-bit or AR mode. (The one exception is the
| TRKADDR macro, which supports 64-bit mode.) When you assemble your code, if
| a return code of 8 or greater is returned by the High Level Assembler, check for
| assembler messages that indicate that a macro has been invoked after AMODE 64
| or AR mode was specified on the SYSSTATE macro.

| Change the source code as appropriate:
| v If the macro invocation will be executing in a supported environment (31-bit or
| 24-bit and not AR mode), then precede that invocation with SYSSTATE
| AMODE64=NO,ASCENV=P.
| v If your tests show that the macro expansion does work when invoked in 64-bit
| or AR mode, then you can consider coding SYSSTATE with AMODE64=NO and


| ASCENV=P even though it does not match the execution environment. This type
| of macro invocation is not supported by IBM unless the documentation for that
| macro says otherwise.

| Reference information: For details about DFSMS macros, refer to z/OS DFSMS
| Macro Instructions for Data Sets and z/OS DFSMSdfp Advanced Services.

| DFSMSdfp: Run OAM configuration database migration job
| Description: When migrating to z/OS V1R13, you must run the OAM
| configuration database migration job (CBRSMR1D). CBRSMR1D creates the File
| System Delete Table in the OAM Configuration Database. You must run
| CBRSMR1D even if you do not plan to use OAM file system support.
|
| Is the migration action required? Yes, if you use OAM.
| requirements:
| check:
|

| Steps to take:
| 1. Update and run the OAM configuration database migration job (CBRSMR1D)
| provided in SAMPLIB.
| 2. Run OAM DB2 BIND and GRANT jobs. To determine which BIND and
| GRANT jobs you need to run, see z/OS DFSMS OAM Planning, Installation, and
| Storage Administration Guide for Object Support.

| Reference information: For more information, see the topic “Migrating, Installing,
| and Customizing OAM” in z/OS DFSMS OAM Planning, Installation, and Storage
| Administration Guide for Object Support.

DFSMSdfp: Run OAM DB2 BIND jobs
Description: When migrating to any new release of z/OS, you must run OAM
DB2 BIND jobs if you are using OAM for object support. The BIND jobs update
DB2 with new OAM DB2 code.

specific release.
Is the migration action required? Yes, if you use OAM object support.


requirements:
Restrictions: None.
check:

Steps to take: Run the BIND jobs appropriate to your installation:
1. Update and execute the samplib job CBRPBIND (OAM DB2 Bind Package Job).
2. Do one of the following:
| v If your installation starts OAM, uses the file system sublevel or optical or
| tape devices, or uses the OAM storage management component (OSMC), do
| the following:
| – Update and execute samplib job CBRABIND (OAM DB2 Application Plan
| Bind for LCS and OSR).
| – Update and execute samplib job CBRHBIND (OAM DB2 Application Plan
| Bind for OSMC).
| v If your installation does not start OAM, use the file system sublevel or
| optical or tape devices, or use OSMC, update and execute samplib job
| CBRIBIND (OAM DB2 Application Plan Bind for OSR only).
3. For more information, see the topic “Migrating, Installing, and Customizing
OAM” in z/OS DFSMS OAM Planning, Installation, and Storage Administration
Guide for Object Support.

| Note: If you choose to edit a previous version of an OAM BIND job, you must
| incorporate any new changes as described in the header of each samplib
| OAM BIND job.

Reference information: For more information about OAM, see z/OS DFSMS OAM
Planning, Installation, and Storage Administration Guide for Object Support.

DFSMSdfp: Use indirect zFS file system data set catalog
support
Description: Starting in z/OS V1R12, zFS file systems may be cataloged using a
system symbol. This allows zFS file system data sets to be indirectly cataloged the
same way as non-VSAM data sets.

Is the migration action required? No, but recommended to make deployment
easier for zFS file system data sets.


Other system (coexistence or fallback) Systems prior to z/OS V1R12 cannot process
requirements: the indirectly-cataloged zFS file system data
sets and will fail with volume not found
errors.
| Restrictions: This support is limited to zFS file system
| data sets only. That is, all VSAM linear data
| sets are not included in this support; only
| data sets formatted as zFS file systems are
| included in this support. Also, this support is
| limited to single-volume zFS file system data
| sets.
check:

Steps to take: Use the reference information below to use this new support.

| v For setting up the indirect catalog entry, see "Define Cluster" in z/OS DFSMS
| Access Method Services for Catalogs and DOC APAR OA34695.
v For information about the steps required to establish an indirect catalog entry for
zFS file system data sets and what the IDCAMS LISTCAT output will produce,
see z/OS DFSMS Access Method Services for Catalogs.
v For cloning processes to use this support, see z/OS Planning for Installation.

| DFSMSdss: Accommodate Catalog Search Interface default
| change
| Description: In z/OS V1R11, DFSMSdss logical data set COPY, DUMP, and
| RELEASE operation used the Catalog Search Interface (CSI) by default to find
| cataloged data sets based on the generic filter criteria on the INCLUDE keyword
| when no input volumes are specified. Prior to z/OS V1R11, you could make use of
| CSI functionality on z/OS V1R10, z/OS V1R9, and z/OS V1R8 systems by
| installing the PTF for APAR OA25644 and patching the offset X'54' into the
| ADRPATCH module to X'11'.

| In z/OS V1R13 (and with the PTF for APAR OA32120 installed on z/OS V1R12
| and z/OS V1R11), DFSMSdss no longer uses the CSI for Catalog filtering during
| logical data set processing as the default; DFSMSdss uses generic catalog locates in
| this scenario.
|
| Element or feature: DFSMSdss.
| When change was introduced: z/OS V1R13 (z/OS V1R12 and z/OS V1R11
| by APAR OA32120).
| Applies to migration from: z/OS V1R12 and z/OS V1R11, both without
| the PTF for APAR OA32120 installed.
| Is the migration action required? Yes, if you want to use CSI during Catalog
| filtering for logical data set processing.


| requirements:
| check:
|

| Steps to take:
| v To use the CSI during Catalog filtering for the DFSMSdss logical data set COPY,
| DUMP, and RELEASE operation, the DFSMSdss patch byte at offset X'54' must
| be set to X'11' to enable the functionality.
| v If the DFSMSdss patch byte at offset X'54' is set to any value other than X'00'
| and X'11' to use generic catalog locates instead of CSI (as done in earlier
| releases), you do not need to set it because this previous method of finding
| cataloged data sets is now in effect by default.

| Note: If you are intentionally using the CSI default by setting the DFSMSdss
| PATCH byte at offset X'54' to X'11', then you don't need to take any action to
| expect the functionality be effective. However, if you left the DFSMSdss
| PATCH byte at offset X'54' as X'00' and want to continue using the CSI
| during Logical Data Set processing, you need to set that Patch byte to X'11'.

| Reference information: For more information about the DFSMSdss patch byte, see
| v INFO APAR II14616.
| v z/OS DFSMSdss Storage Administration.

| DFSMShsm: Stop using the HOLD command to quiesce
| activity prior to control data set backup
| Description: Before z/OS V1R13, you might have manually or programmatically
| held DFSMShsm activity using the HOLD command prior to starting a control
| data set (CDS) backup. Starting with z/OS V1R13, the ARCCAT resource is
| released by all functions running on z/OS V1R13 DFSMShsm hosts, and the
| functions are quiesced when CDS backup starts. Manually or programmatically
| holding DFSMShsm activity is no longer necessary.
|
| Is the migration action required? No, but recommended because DFSMShsm
| will automatically release the ARCCAT
| resource when a CDS backup is starts.
| Target system hardware requirements: Cross coupling facility (XCF) services are
| required to communicate the start of a CDS
| backup to all DFSMShsm hosts. XCF services
| must be available and configured properly.
| requirements:


Chapter 9. DFSORT migration actions
DFSORT actions to perform before installing z/OS Use new MOWRK option to prevent the use of
V1R13 . . . . . . . . . . . . . . . . 211 memory object storage for work space sort
DFSORT actions to perform before the first IPL of applications . . . . . . . . . . . . . 212
z/OS V1R13 . . . . . . . . . . . . . . 211 Change the number of dynamically allocated
Update automation for changed DFSORT work data sets using new DYNAPCT option . . 213
messages . . . . . . . . . . . . . . 211
DFSORT actions to perform after the first IPL of
z/OS V1R13 . . . . . . . . . . . . . . 212

This topic describes migration actions for optional feature DFSORT.

DFSORT actions to perform before installing z/OS V1R13
None.

DFSORT actions to perform before the first IPL of z/OS V1R13
This topic describes DFSORT migration actions that you can perform after you
have installed z/OS V1R13 but before the first time you IPL. These actions might
active.

Update automation for changed DFSORT messages
Description: In z/OS V1R12, the text for some DFSORT messages (ICExxxx) is
changed. Text and insert fields have been added, changed, or removed in the
messages listed below in “Steps to take”. These changes can affect automation
programs that examine the text of the messages.

Element or feature: DFSORT.
Is the migration action required? Yes, if you have automation routines that
examine the message text of the messages
listed below in “Steps to take”.
requirements:
Restrictions: None.
check:

Steps to take: Update your automation to handle the following DFSORT message
changes:
v The release level has changed from "V1R10" to "V1R12" in message ICE000I.


v The following new messages have been added:
– ICE236I
– ICE248I
– ICE249I
– ICE264I
– ICE278I
– ICE299I
– ICE801I
v Text and insert fields have been changed in the following messages to provide
new information:
– ICE199I
– ICE255I
– ICE289A
– ICE897I
– ICE898I

Reference information: For details about the ICE messages, see z/OS DFSORT
Messages, Codes and Diagnosis Guide.

DFSORT actions to perform after the first IPL of z/OS V1R13
This topic describes DFSORT migration actions that you can perform only after
you have IPLed z/OS V1R13. You need a running z/OS V1R13 system to perform
these actions.

Use new MOWRK option to prevent the use of memory object
storage for work space sort applications
Description: Beginning with z/OS V1R12, DFSORT uses memory object storage as
intermediate work space. A new installation option, MOWRK, specifies whether
memory object storage can be used for intermediate work space or as an extension
of main storage, as appropriate, or only as an extension of main storage. Using
memory object storage as intermediate work space is the preferred choice.
DFSORT's shipped installation default for MOWRK is YES (use memory object
storage as work space or as an extension of main storage). If appropriate, you can
change MOWRK for all DFSORT sort applications to only use memory objects as
an extension of main storage by specifying NO.

| The MOSIZE installation default will still limit the total amount of memory object
| storage that can be used by a sort application.

Is the migration action required? Yes, if the default value YES is not
acceptable.


requirements:
Restrictions: None.
check:

Steps to take:
v To prevent the use of memory object storage for work space for all DFSORT sort
applications, use ICEPRMxx members activated by a START ICEOPT started task
command to set the MOWRK=NO option, as appropriate.
| v Alternatively, you can set MOWRK=NO with the previous (less preferred)
| method of using the ICEMAC macro and usermods.
v To prevent the use of memory object storage for work space for individual
DFSORT sort applications, use the NOMOWRK run time option as described in
the referenced documentation below.

v For details about the MOWRK installation option, see z/OS DFSORT Installation
and Customization.
v For details about the MOWRK and NOMOWRK run time options, see z/OS
DFSORT Application Programming Guide.

Change the number of dynamically allocated work data sets
using new DYNAPCT option
Description: Beginning with z/OS V1R12, you will see an increase in the number
of dynamically allocated work data sets for sort applications. A new installation
option, DYNAPCT, specifies a percentage that is applied to the
DYNALOC/DYNALLOC value in effect to determine the number of additional
work data sets to be dynamically allocated. These additional work data sets will be
allocated with 0 space and only used if needed to complete a sort when the disk
work space requirement is unexpectedly larger than anticipated. The total disk
work space initially allocated by DFSORT will not increase.

DFSORT's shipped installation default for DYNAPCT is 10 (percent). If
appropriate, you can adjust DYNAPCT for all DFSORT sort applications or for
individual DFSORT sort applications by specifying 0 to 254 (percent) or OLD (no
change from previous releases). DYNAPCT=0 indicates a 0 percentage, so no
additional work data sets will be added.

Note: DYNAPCT=OLD tells DFSORT to operate the way it did previously:
v OLD specifies that additional work data sets should only be allocated
when DFSORT cannot determine the file size. When DFSORT is able to
determine the file size, additional work data sets will not be allocated
(y=0), and the total number of work data sets will be n.

DYNAPCT=0 tells DFSORT to use 0%, which means no additional work
data sets will be allocated.


Chapter 9. DFSORT migration actions 213

Is the migration action required? Yes, if the default of 10 (percent) is not
acceptable.
Note: If DYNAPCT=10 is not sufficient to
avoid out of space ABENDs, then you might
want to raise the value of n.
requirements:
Restrictions: None.
check:

Steps to take:
v To change the number of dynamically allocated work data sets for all DFSORT
sort applications, use ICEPRMxx members activated by a START ICEOPT started
task command to set the DYNAPCT=x or DYNAPCT=OLD option, as
appropriate.
| v Alternatively, you can set DYNAPCT=x or DYNAPCT=OLD with the previous
| (less preferred) method of using the ICEMAC macro and usermods.
v To change the number of dynamically allocated work data sets for individual
DFSORT applications, use the DYNAPCT=x or DYNAPCT=OLD run time option
as described in the referenced documentation below.

v For details about the DYNAPCT installation option, see z/OS DFSORT
Installation and Customization.
v For details about the DYNAPCT run time option, see z/OS DFSORT Application
Programming Guide.


Chapter 10. Distributed File Service migration actions
Distributed File Service actions to perform before | zFS: Ensure sysplex=filesys is available on all
installing z/OS V1R13 . . . . . . . . . . 215 | zFS R11 and R12 systems in a shared file system
| zFS: Accommodate new DASD space | environment. . . . . . . . . . . . . 219
| requirements . . . . . . . . . . . . 215 | zFS: Verify virtual storage usage . . . . . . 222
| zFS: Copy cloned file systems to a compatibility Distributed File Service actions to perform before
| mode aggregate . . . . . . . . . . . 217 the first IPL of z/OS V1R13 . . . . . . . . 224
| zFS: Copy data from zFS multi-file system | DCE/DFS: Disable DFS Client initialization . . 224
| aggregates to zFS compatibility mode Distributed File Service actions to perform after the
| aggregates . . . . . . . . . . . . . 218 first IPL of z/OS V1R13 . . . . . . . . . . 225

This topic describes migration actions for base element Distributed File Service.

Distributed File Service actions to perform before installing z/OS
V1R13
This topic describes Distributed File Service migration actions that you can
perform on your current (old) system. You do not need the z/OS V1R13 level of
code to make these changes, and the changes do not require the z/OS V1R13 level
of code to run once they are made.

| zFS: Accommodate new DASD space requirements
| Description: zFS always reads and writes data in 8K blocks. However, in z/OS
| V1R13, zFS stores data either inline or in 8K blocks. (Inline data is a file that is
| smaller than 53 bytes and is stored in the file's metadata.) Unlike in previous
| releases, zFS R13 no longer stores data in 1K fragments. zFS R13 can read data
| stored in fragments; however, when the data is updated, it is moved into 8K
| blocks. Previously, zFS could store data in 1K fragments (contained in an 8K
| block). This meant that multiple small files could be stored in a single 8K block.

| Because data is no longer stored in fragments, zFS R13 might need more DASD
| storage than was required in previous releases to store the same amount of data.
| More storage may also be needed if zFS R13 is in a mixed-release sysplex and
| becomes the zFS owning system of a file system.
| v Scenario 1: If every file in the file system is 1K or less, zFS R13 could require up
| to four times the DASD storage as was needed in previous releases.
| v Scenario 2: Because HFS uses 4K blocks to store data and zFS uses 8K blocks, if
| every file in the file system were 4K or less, zFS R13 could require up to twice
| as much DASD space to store these files.
| v Scenario 3: If the file system contains 1000 files that are 1K in size, zFS in R13
| could take a maximum of 10 cylinders more than zFS in previous releases.

| Typically, however, any increase in the DASD storage used by zFS R13 will be
| negligible. For example, the z/OS V1R13 version root file system copied using zFS
| R13 takes approximately 2% more space than the same file system copied using
| zFS R11. Note that zFS R13 packs multiple ACLs and symbolic links into an 8K
| block which previous releases did not do. To minimize the chance of application
| failure due to running out of DASD storage in newly mounted file systems, the
| default value for the IOEFSPRM option aggrgrow is changed from Off to On.
|
| Element or feature: Distributed File Service.


| Is the migration action required? Yes, if you will be using zFS V1R13 to create
| new zFS file systems or update data in
| existing file systems, where the file system
| contains many small files.

| This action is also required if you have not
| specified the zFS aggrgrow option in your
| IOEFSPRM configuration options file.
| requirements:
| System impacts: zFS R13 may use more DASD storage for
| data than previous releases required. The
| amount of DASD storage depends on file
| sizes and on ACL and symbolic link usage.
| In general, the more small files in the file
| system, the more likely it is that a file system
| created or updated with zFS R13 will require
| more DASD storage than previous releases.
| check:
|

| Steps to take: Perform the following steps, as appropriate for your installation.

| For all zFS file systems:
| 1. If you have not specified the zFS aggrgrow option in your IOEFSPRM
| configuration options file, recognize that the default is changing in z/OS V1R13
| from aggrgrow=off to aggrgrow=on. This means that by default, a zFS
| read-write mounted file system that is mounted on z/OS V1R13 will attempt to
| dynamically extend when it runs out of space if a secondary allocation size is
| specified and there is space on the volume(s).
| 2. If you do not want that default change and you want it to act as in prior
| releases, specify aggrgrow=off in your IOEFSPRM configuration options file so
| that it takes effect on the next IPL. You can dynamically change the aggrgrow
| option to off with the zfsadm config -aggrgrow off command. You can see
| your current value for aggrgow with the zfsadm configquery -aggrgrow
| command.

| For new zFS file systems:
| 1. Increase the estimated size of a new zFS file system, if you know that many
| files in the file system will be small.
| 2. Mount zFS read-write file systems and allow them to dynamically extend; if
| more DASD space is needed, applications will not fail because the file systems
| are out of storage.


| To do so, mount the file systems with the AGGRGROW mount option or use
| the default aggrgrow=on IOEFSPRM configuration option. The data set must
| have a non-zero secondary allocation size and there must be space on the
| volume to allow dynamic extension.

| For existing zFS file systems:
| 1. Use the scan for small files utility (zfsspace) to determine if an existing file
| system needs more DASD storage. For a mounted zFS file system, the utility
| shows the number of small files (1K or less), if a secondary allocation is
| specified, and if aggrgrow=on is specified.You can determine how many files
| you have in a file system that are less than or equal to 1K in size by using the
| following shell command:
| find <mountpoint> -size -3 -type f -xdev | wc -l
| The zfsspace utility can be downloaded from ftp://public.dhe.ibm.com/s390/
| zos/tools/zfsspace/zfsspace.txt.
| 2. If a file system has a secondary allocation size and is mounted with the
| AGGRGROW mount option, allow it to dynamically extend to minimize the
| potential failure due to lack of storage. If there are insufficient candidate
| volumes, also consider adding volumes by using the IDCAMS ALTER
| command with the ADDVOLUMES option. Generally, after adding volumes, a
| remount samemode is required to have them take effect.
| 3. If a file system is not enabled to dynamically extend, consider explicitly
| growing the file system using the z/OS UNIX zfsadm grow command. This is
| especially important if the file system contains many small files that will be
| updated.
| 4. If you expect a file system to grow larger than 4GB (about 5825 3390 cylinders)
| and it is not SMS-managed with extended addressability, you will need to copy
| it to an SMS-managed zFS data set with a data class that includes extended
| addressability. To do so, use the pax command. If a zFS aggregate is to be
| larger than 4GB, it must be SMS-managed with a data class that includes
| extended addressability.

| Reference information: Refer to the following documentation for more information
| about the migration steps.
| v For information about zFS administration tasks and how zFS stores files, see
| z/OS Distributed File Service zSeries File System Administration, SC24-5989.
| v For information about VSAM extended addressability and SMS-managed data
| sets, see z/OS DFSMS Implementing System-Managed Storage, SC26-7407.
| v For information about the pax command, see z/OS UNIX System Services
| Command Reference, SA22-7802.

| zFS: Copy cloned file systems to a compatibility mode
| aggregate
| Description: z/OS V1R13 is planned to be the last release that zFS will support
| cloning file systems. In anticipation of this removal of support, you should
| discontinue using zFS clone functions, such as the zfsadm clone and zfsadm
| clonesys commands. You should also discontinue mounting any zFS file system
| aggregates that contain a cloned (.bak) file system.

| When support for cloning file systems is withdrawn, only zFS compatibility mode
| aggregates will be supported.
|

Chapter 10. Distributed File Service migration actions 217

| Software Announcement 211-007, dated 15
| February 2011).
| Is the migration action required? Yes, if your installation uses cloned file
| systems.
| requirements:
| check:
|

| Steps to take:
| 1. Determine if cloned file systems (.bak) have been created or are in the process
| of being created on your system.
| v Issue the modify zfs,query command and review the contents of the FILE
| report. The Flg field in the report will indicate the status of the file system
| aggregate.
| 2. If your system contains cloned file systems, copy that data to a compatibility
| mode aggregate.

| Reference information: For more information about zFS commands and
| performing administration tasks, see z/OS Distributed File Service zSeries File System
| Administration, SC24-5989.

| zFS: Copy data from zFS multi-file system aggregates to zFS
| compatibility mode aggregates
| Description: z/OS V1R13 is planned to be the last release of zFS support for
| multi-file system aggregates. If you have data stored in zFS multi-file system
| aggregates, you should copy the data from the zFS multi-file system aggregates
| into zFS compatibility mode aggregates.

| When this support is withdrawn, only zFS compatibility mode aggregates will be
| supported.
|
| Software Announcement 211-007, dated
| February 15, 2011).
| Is the migration action required? Yes, if your installation uses multi-file system
| aggregates.


| requirements:
| check: ZOSMIGV1R11_ZFS_RM_MULTIFS or check
| ZOSMIGREC_ZFS_RM_MULTIFS to help
| determine if any multi-file system aggregates
| are attached on your system.
|

| Steps to take: Use one of the following methods to determine if you are using zFS
| multi-file system aggregates:
| v Use the IBM Health Checker for z/OS check referenced above.
| v Scan your zFS IOEFSPRM configuration options file for define_aggr statements.
| v Scan your /etc/rc file for any zfsadm attach commands.
| v Issue the zfsadm aggrinfo command to determine if an aggregate is a multi-file
| system aggregate; in the command response, COMP indicates compatibility
| mode and MULT indicates multi-file system.

| If you are using zFS multi-file system aggregates, copy the data from each of those
| file systems into its own zFS compatibility mode aggregate.

| v For more information about zFS commands and administration tasks, see z/OS
| Distributed File Service zSeries File System Administration, SC24-5989.
| v For more information about IBM health checks, refer to IBM Health Checker for
| z/OS: User's Guide .

| zFS: Ensure sysplex=filesys is available on all zFS R11 and
| R12 systems in a shared file system environment
| Description: In z/OS V1R13, zFS only runs in sysplex=filesys mode. This requires
| that all sysplex members in the shared file system environment must run
| sysplex=filesys, including any z/OS V1R11 and z/OS V1R12 systems.
|
| Is the migration action required? Yes, if you have a shared file system
| environment with more than one system in
| that environment.


| Other system (coexistence or fallback) Install the PTF for APAR OA32925 on z/OS
| requirements: V1R11.

| If a problem occurs when zFS is running
| sysplex=filesys on a z/OS V1R11 or z/OS
| V1R12 system, you can perform the
| following steps:
| v Remove the sysplex specification from
| each system or specify sysplex=off on each
| system (this is equivalent to the default).
| v Perform a rolling IPL or restart zFS on
| each system.

| This procedure cannot be done after zFS on
| the z/OS V1R13 system has joined the
| sysplex. If you try to start zFS on another
| z/OS V1R13 system after you have changed
| zFS to sysplex=off on the z/OS V1R11 or
| z/OS V1R12 system, zFS on z/OS V1R13
| will not start. This happens because zFS on
| z/OS V1R13 requires all other systems be
| zFS sysplex=filesys.

| Also, if you try to bring in zFS z/OS V1R13
| when sysplex=filesys is not active on all
| systems, you will receive message
| IOEZ00721I Sysplex member sysname is not
| running sysplex=filesys. zFS on this
| initializing member will terminate.,
| where sysname is the sysplex member that is
| not running sysplex=filesys.
| System impacts: Specifying zFS sysplex=filesys in a shared file
| system environment causes zFS to run
| sysplex-aware on a file system basis. This is
| the preferred mode for zFS in a shared file
| system environment.
| check: ZOSMIGV1R13_ZFS_FILESYS(available with
| APAR OA35465 on z/OS V1R12 and z/OS
| V1R11).
|

| Steps to take: Perform the following steps to ensure that sysplex=filesys is
| available on all zFS z/OS V1R11 and z/OS V1R12 systems in a shared file system
| environment.
| 1. Install the PTF for APAR OA32925 (UA55765) on all z/OS V1R11 systems, and
| make it active on all systems through a rolling IPL. This provides the enhanced
| connect function required by zFS V1R13.
| 2. If you are currently running zFS sysplex=off, specify sysplex=filesys and make
| it active on all systems through a rolling IPL.
| If you are running sysplex=on, specify sysplex=filesys and
| sysplex_filesys_sharemode=rwshare and make it active on all systems through
| a rolling IPL. The health check ZOSMIGV1R13_ZFS_FILESYS verifies that all
| z/OS V1R11 and z/OS V1R12 systems in the shared file system environment
| have specified sysplex=filesys before z/OS V1R13 is introduced.


| To determine if you are running zFS sysplex=filesys, issue the MODIFY
| ZFS,QUERY,LEVEL operator command. In a shared file system environment, the
| last line of the response indicates if zFS is running sysplex=filesys. In the following
| example, zFS is running sysplex=filesys.
| f zfs,query,level
| IOEZ00639I zFS kernel: z/OS zSeries File System
| Version 01.11.00 Service Level OA33895 - HZFS3B0.
| Created on Mon Aug 23 14:02:18 EDT 2010.
| sysplex(filesys,norwshare) interface(3)
| IOEZ00025I zFS kernel: MODIFY command - QUERY,LEVEL completed successfully

| If you do not perform these steps on z/OS V1R11 or z/OS V1R2 systems, you will
| receive error messages when you try to bring up zFS on a z/OS V1R13 system. In
| the examples shown in Table 12, DCEIMGVM, DCEIMGVN and DCEIMGVQ are
| three sysplex members in a shared file system environment.
| Table 12. Examples of zFS error messages
| Example 1 DCEIMGVM (running z/OS V1R13) tries to enter the sysplex environment.

| DCEIMGVN and DCEIMGVQ are running z/OS V1R11 but the coexistance APAR has not
| been installed on either system.
| Results DCEIMGVM (z/OS V1R13) issues:
| IOEZ00675E zFS will terminate... system DCEIMGVN does not support the following
| feature(s) used by this system (DCEIMGVM):
| enhanced connect
| IOEZ00675E zFS will terminate... system DCEIMGVQ does not support the following
| feature(s) used by this system (DCEIMGVM):
| enhanced connect
| IOEZ00057I zFS kernel program IOEFSKN is ending
| Example 2 DCEIMGVN (running z/OS V1R11 without coexistence APAR) tries to enter the sysplex
| environment.

| DCEIMGVM and DCEIMGVQ are running z/OS V1R13.
| Results DCEIMGVN (z/OS V1R11) issues the following messages:
| IOEZ00677E zFS will terminate... system DCEIMGVM uses feature(s) not supported
| by the initializing system (DCEIMGVN).
| IOEZ00677E zFS will terminate... system DCEIMGVQ uses feature(s) not supported
| by the initializing system (DCEIMGVN).
| IOEZ00057I zFS kernel program IOEFSCM is ending

| DCEIMGVM (z/OS V1R13) issues:
| IOEZ00676E DCEIMGVN will terminate... it does not support the following
| feature(s) used by this system(DCEIMGVM):
| enhanced connect

| DCEIMGVQ (z/OS V1R13) issues:
| IOEZ00676E DCEIMGVN will terminate... it does not support the following
| feature(s) used by this system(DCEIMGVQ):
| enhanced connect
| Example 3 DCEIMGVM (running z/OS V1R13) tries to enter the sysplex environment.

| DCEIMGVN and DCEIMGVQ (running z/OS V1R11 with the coexistance APAR installed)
| are not running sysplex=filesys.
| Results DCEIMGVM (z/OS V1R13) issues:
| IOEZ00721I Sysplex member DCEIMGVN is not running sysplex=filesys.
| zFS on this initializing member will terminate.
| IOEZ00721I Sysplex member DCEIMGVQ is not running sysplex=filesys.
| zFS on this initializing member will terminate.
| IOEZ00057I zFS kernel program IOEFSKN is ending.
| Example 4 DCEIMGVN (running z/OS V1R11 without sysplex=filesys and with the coexistence APAR
| installed) tries to enter the sysplex environment.

| DCEIMGVM and DCEIMGVQ are running z/OS V1R13.


| Table 12. Examples of zFS error messages (continued)
| Results DCEIMGVN (z/OS V1R11 without sysplex=filesys) issues:
| IOEZ00677E zFS will terminate... system DCEIMGVM uses feature(s)
| not supported by the initializing system (DCEIMGVN).
| IOEZ00677E zFS will terminate... system DCEIMGVQ uses feature(s)
| not supported by the initializing system (DCEIMGVN).
| IOEZ00057I zFS kernel program IOEFSCM is ending

| DCEIMGVM (z/OS V1R13) issues:
| IOEZ00720I Initializing system DCEIMGVN will not be allowed
| to join the sysplex.
| It is not running sysplex=filesys.

| DCEIMGVQ (z/OS V1R13) issues:
| IOEZ00720I Initializing system DCEIMGVN will not be allowed
| to join the sysplex.
| It is not running sysplex=filesys.
|

| about these migration steps.
| v For details about messages, see z/OS Distributed File Service Messages and Codes,
| SC24-5917.
| v For more information about running zFS in a shared file system environment,
| see z/OS Distributed File Service zSeries File System Administration, SC24-5989.
| v For more information about IBM health checks, refer to IBM Health Checker for
| z/OS: User's Guide .

| zFS: Verify virtual storage usage
| Description: Applying PTF UA55765 (zFS APAR OA33451) to z/OS V1R11 fixes a
| performance problem that occurs because of too many storage obtains and releases
| in zFS. The resolution of the problem involves obtaining a new block of storage at
| zFS initialization. This storage obtain is for approximately 60 MB.
|
| When change was introduced: z/OS V1R11 by APAR OA33451.
| Applies to migration from: z/OS V1R11 without APAR OA33451.
| requirements:
| System impacts: If your zFS virtual storage usage is close to
| the limit of the zFS address space, this
| additional virtual storage request at zFS
| initialization could cause zFS to fail to
| initialize and not come up, or zFS may come
| up but with insufficient remaining storage to
| handle zFS requests such as mount. In these
| cases, you would likely see zFS the warning
| message IOEZ00662I: ZFS is low on storage.


| check:
|

| Steps to take:
| 1. Verify that PTF UA55765 (zFS APAR OA33451) is installed.
| 2. Check zFS storage usage by using the operator command MODIFY
| ZFS,QUERY,STORAGE. If you compare the third line of data (USS/External
| Storage Access Limit) to the fourth line (Total Bytes Allocated
| (Stack+Heap+OS)), you will be able to see how close zFS is to using its
| maximum storage. The Total Bytes Allocated should be less than the
| USS/External Storage Access Limit. For example:
| MODIFY ZFS,QUERY,STORAGE
| IOEZ00438I Starting Query Command STORAGE.
| zFS Primary Address Space Storage Usage
| ---------------------------------------
|
| Total Storage Available to zFS: 1938817024 (1893376K) (1849M)
| Non-critical Storage Limit: 1917845504 (1872896K) (1829M)
| USS/External Storage Access Limit: 1875902464 (1831936K) (1789M)
| Total Bytes Allocated (Stack+Heap+OS): 245559296 (239804K) (234M)
| Heap Bytes Allocated: 213411011 (208409K) (203M)
| Heap Pieces Allocated: 295003
| Heap Allocation Requests: 295610
| Heap Free Requests: 607
|
| Heap Usage By Component
| --------------------------
| Bytes No. of No. of
| Allocated Pieces Allocs Frees Component
| ---------- ------ ------ ------ ---------
| 66836 10 10 0 Interface
| 5112 8 12 4 Media Manager I/O driver
| 1828 5 5 0 Trace Facility
| 431452 7 7 0 Message Service
| 282789 1701 2216 515 Miscellaneous
| 34632 41 43 2 Aggregate Management
| 106220 31 31 0 Filesystem Management
| 33128 23 29 6 Administration Command Handling
| 35115496 100692 100692 0 Vnode Management
| 17030164 36313 36315 2 Anode Management
| 34838428 7140 7146 6 Directory Management
| 475992 6170 6172 2 Log File Management
| 34459280 12299 12300 1 Metadata Cache
| 420312 4014 4014 0 Transaction Management
| 9740 24 24 0 Asynchronous I/O Component
| 58288 156 156 0 Lock Facility
| 169224 443 443 0 Threading Services
| 249200 5968 5972 4 Cache Services
| 46058 6 8 2 Configuration parameters processing
| 11842136 98386 98386 0 User File Cache
| 56100 99 118 19 Storage Management
| 63318828 942 950 8 XCF Services
| 11640 8 10 2 Cross system attach validation
| 2338560 20489 20489 0 Server Token Manager (STKM)
| 12048 16 16 0 Server Token Cache (STKC)
| 11996704 8 8 0 Client Token Cache (CTKC)
| 0 0 0 0 Server Vnode Interface (SVI)
| 816 4 38 34 Name Space (NS)

| You can see that, in this case, the Total Bytes Allocated (234M) is much less
| than the USS/External Storage Access Limit (1789M). If the Total Bytes


| Allocated becomes greater than or equal to the USS/External Storage Access
| Limit, zFS will issue an IOEZ00662I message.
| If you see that the Total Bytes Allocated approaches the value of the
| USS/External Storage Access Limit, you should take steps to decrease your
| cache sizes using the z/OS UNIX zfsadm config command. See the z/OS
| Distributed File Service zSeries File System Administration (SC24-5989) for
| more information on the zfsadm command.
| 3. If zFS has failed to initialize and is not active, you should decrease some of
| your zFS IOEFSPRM settings, such as dir_cache_size, meta_cache_size,
| recovery_max_storage, token_cache_size, tran_cache_size, vnode_cache_size
| (especially if they are significantly larger than the default for these values) and
| restart zFS. If zFS is active but warning message IOEZ00662I has been issued,
| you can attempt to decrease the caches dynamically using the zfsadm config
| command. (You should also make the corresponding changes in your
| IOEFSPRM file for the next zFS restart.) Alternatively, you can stop and restart
| zFS after making cache size changes to your IOEFSPRM file.
| As a general practice, it is a good idea to periodically check zFS storage usage by
| using the operator command MODIFY ZFS,QUERY,STORAGE.

| v For more information about the zfsadm command, see z/OS Distributed File
| Service zSeries File System Administration.
| v For more information about zFS administration, see z/OS Distributed File Service
| zSeries File System Administration.

Distributed File Service actions to perform before the first IPL of z/OS
V1R13

| DCE/DFS: Disable DFS Client initialization
| Description: The DFS client (DFSCM) is a physical file system that is started
| during z/OS UNIX initialization based on a FILESYSTYPE statement in the
| BPXPRMxx parmlib member. Starting with z/OS V1R13, the DFS client function is
| removed.
|
| Software Announcement 210-235, dated July
| 22, 2010).
| requirements:


| Related IBM Health Checker for z/OS Use ZOSMIGREC_SMB_RPC available by
| check: APAR OA30117.
|

| Steps to take: If your installation uses the DFS client, you must remove the
| following statement from the BPXPRMxx parmlib member to prevent the client
| from initializing:
| FILESYSTYPE TYPE(DFSC)
| ENTRYPOINT(IOECMINI)
| PARM(’ENVAR("_EUV_HOME=/opt/dfslocal/home/dfscm") /
| >DD:IOEDFSD 2>&1’)
| ASNAME(DFSCM)

| If this migration action is not performed before the first IPL of z/OS V1R13, you
| will receive the following error message:
| IOEP12402E:
| As of z/OS Version 1 Release 13, the DFS client function has been removed.

| z/OS UNIX will successfully initialize, but you will need to follow the guidance in
| the message to remove the entry and restart z/OS UNIX.

| If you have not already done so, you should use the z/OS UNIX pax command to
| migrate any data in DCE DFS or Episode file systems to other file systems. The
| recommended general procedure is as follows:
| 1. Set up a zFS file system to receive the data.
| 2. Copy your DCE DFS or Episode file system data to the zFS file system, using
| the z/OS UNIX pax command.
| 3. Set up a z/OS NFS server to allow data access from a remote z/OS UNIX
| system.

| about these migration steps.
| v For details about message IOEP12402E, see z/OS Distributed File Service Messages
| and Codes, SC24-5917.
| v For information about setting up a zFS file system, see z/OS Distributed File
| Service zSeries File System Administration, SC24-5989.
| v For information about the pax command, see z/OS UNIX System Services
| Command Reference, SA22-7802.
| v For information about NFS, see z/OS Network File System Guide and Reference .
| v For information about SMB, see z/OS Distributed File Service SMB Administration,
| SC24-5918 .

Distributed File Service actions to perform after the first IPL of z/OS
V1R13

None


Chapter 11. Infoprint Server migration actions
Infoprint Server actions to perform before | Update or remove the region size in the
installing z/OS V1R13 . . . . . . . . . . 227 | AOPSTART startup procedure . . . . . . . 232
Increase space in the Printer Inventory file Upgrade XML for Infoprint Central . . . . . 233
system . . . . . . . . . . . . . . 227 Migrate from IP PrintWay basic mode to
Remove Version 2 Printer Inventory files at extended mode . . . . . . . . . . . . 234
fallback to z/OS V1R11 . . . . . . . . . 228 Infoprint Server actions to perform after the first
Upgrade Java support for IPP Server . . . . 230 IPL of z/OS V1R13 . . . . . . . . . . . 236
Infoprint Server actions to perform before the first Run aopsetup . . . . . . . . . . . . 236
IPL of z/OS V1R13 . . . . . . . . . . . 231 Remove Version 1 Printer Inventory files after
Remount the Printer Inventory and copy files deploying z/OS V1R13 . . . . . . . . . 237
that were customized. . . . . . . . . . 231

This topic describes migration actions for optional feature Infoprint Server.

Infoprint Server actions to perform before installing z/OS V1R13
This topic describes Infoprint Server migration actions that you can perform on
your current (old) system. You do not need the z/OS V1R13 level of code to make
these changes, and the changes do not require the z/OS V1R13 level of code to run
once they are made.

Increase space in the Printer Inventory file system
Description: In z/OS V1R12, the format of the Infoprint Server Printer Inventory
| files has changed from Version 1 to Version 2 format. When you migrate from
| z/OS V1R11 and start Infoprint Server on z/OS V1R13 for the first time, Infoprint
Server reformats the Version 1 Printer Inventory files and creates Version 2 Printer
Inventory files. The Version 1 Printer Inventory files are not removed so that if you
need to fall back to z/OS V1R11, Infoprint Server can use the Version 1 Printer
Inventory files. Therefore, the Printer Inventory file system requires more space in
| z/OS V1R13 than in z/OS V1R11. You might need to increase space in the
Infoprint Server Printer Inventory file system.

Element or feature: Infoprint Server.
requirements:
Restrictions: On z/OS V1R11 systems, Infoprint Server
cannot read or export the Version 2 Printer
Inventory. If you want to use the Version 2
Printer Inventory on z/OS V1R11, use the
pidu command to export the Version 2
Printer Inventory while running on z/OS
V1R13 and then use the pidu command to
import the exported copy to z/OS V1R11.


IBM Health Checker for z/OS check: ZOSMIGV1R12_INFOPRINT_INVSIZE
available with APAR OA32093.

Steps to take:
1. Do one of these:
v Run the IBM Health Checker for z/OS check
ZOSMIGV1R12_INFOPRINT_INVSIZE.
v Run the df command to display the current utilization of the Printer
Inventory file system. Printer Inventory files are located in the Infoprint
Server base directory. The default base directory name is /var/Printsrv.
You might have changed the base directory name in the base-directory
attribute in the aopd.conf configuration file. The aopd.conf default location is
/etc/Printsrv/aopd.conf. However, you might have specified a different
location in environment variable AOPCONF.
The free space required is 200% of the sum of the Version 1 Printer Inventory
and historical Printer Inventory files (master.db, jestoken.db, pwjestoken.db,
hinv/hinv.db, and logdb/log.db).
If the “Capacity” is greater than 33%, increase the size of the file system.
Example:
df -P /var/Printsrv
Filesystem 512-blocks Used Available Capacity Mounted on
OE17A.S1.VAR 64800 54184 10616 84% /DEVE/var
2. To increase the size of the file system, you can use the z/OS UNIX zfsadm
grow (zFS) or confighfs (HFS) command.

Tip: Set the aggrfull (zFS) or FSFULL (HFS) file system option so that warning
messages are issued if the Infoprint Server base directory (/var/Printsrv) is getting
full.

v For information about the /var/Printsrv directory and how to use the pidu
command to export and import the Printer Inventory, see z/OS Infoprint Server
Customization.
v For information about how to start and stop Infoprint Server, see z/OS Infoprint
Server Operation and Administration.
v For information about managing file systems, see z/OS UNIX System Services
Planning.
v For information about the zfsadm grow command and the aggrfull option, see
z/OS Distributed File Service zSeries File System Administration
v For information about the confighfs command, see z/OS UNIX System Services
Command Reference.

Remove Version 2 Printer Inventory files at fallback to z/OS
V1R11
Description: In z/OS V1R12, the format of the Infoprint Server Printer Inventory
| files has changed from Version 1 to Version 2 format. When you migrate from
| z/OS V1R11 and start Infoprint Server on z/OS V1R13 for the first time, Infoprint
Server reformats the Version 1 Printer Inventory files and creates Version 2 Printer
Inventory files. Both Version 1 and Version 2 Printer Inventory files exist in the


Infoprint Server base directory. Infoprint Server on z/OS V1R13 uses the Version 2
Printer Inventory files. If you fall back to z/OS V1R11, Infoprint Server uses the
Version 1 Printer Inventory files.

| If you start Infoprint Server on z/OS V1R13 a second time after falling back to
| z/OS V1R11, Infoprint Server uses the existing Version 2 Printer Inventory files
that it created the first time you started Infoprint Server on z/OS V1R13. It does
not reformat the Version 1 Printer Inventory files again.

If you want Infoprint Server to reformat the Version 1 Printer Inventory files again,
remove the Version 2 Printer Inventory files before you start Infoprint Server on
z/OS V1R13. Because the Version 2 Printer Inventory files no longer exist,
Infoprint Server reformats the Version 1 Printer Inventory files and creates a new
set of Version 2 Printer Inventory files.

In most cases, you should remove the Version 2 Printer Inventory files if they exist.
If you do not remove the Version 2 Printer Inventory files, any changes that the
administrator made to the Version 1 Printer Inventory on z/OS V1R11 are not in
the Version 2 Printer Inventory.

Is the migration action required? No, but recommended if you want Infoprint
Server to reformat the Version 1 Printer
Inventory files after a fallback.
requirements:
Restrictions: None.
IBM Health Checker for z/OS check: INFOPRINT_V2DB_CHECK available with
APAR OA32093.

Steps to take:
1. Run the IBM Health Checker for z/OS check INFOPRINT_V2DB_CHECK.
2. If Version 2 Printer Inventory files exist after falling back to z/OS V1R11,
remove them from the Infoprint Server base directory. Be careful not to remove
any Version 2 files while running z/OS V1R13 because Infoprint Server on
z/OS V1R13 requires Version 2 Printer Inventory files.
Version 2 files have the extension “v2db”. The default base directory is
/var/Printsrv.
Example: These z/OS UNIX commands switch to an effective UID of 0, remove
all files with the “v2db” extension from directory /var/Printsrv, and switch
back to the original UID:

Chapter 11. Infoprint Server migration actions 229

su
rm -f $(find /var/Printsrv/ -name "*.v2db")
exit

Note: To remove Printer Inventory files, you must have an effective UID of 0
or be a member of the RACF AOPADMIN group.

Reference information: For information about the /var/Printsrv directory, see
z/OS Infoprint Server Customization.

Upgrade Java support for IPP Server
Description: In z/OS V1R12, the Internet Printing Protocol (IPP) Server component
of Infoprint Server requires Java V6.0. If the JAVA_HOME environment variable
specifies the location of an earlier version of Java, you must update the
JAVA_HOME environment variable.

Timing: Before installing z/OS V1R13, if APAR
OA28720 is applied. Otherwise, after
installing z/OS V1R13.
Is the migration action required? Yes, if you use IPP Server and specify the
JAVA_HOME environment variable. You are
using IPP Server if the start-daemons={ippd}
attribute is specified in the Infoprint Server
configuration file. The configuration file's
default location is /etc/Printsrv/aopd.conf.
However, you might have specified a
different location in environment variable
AOPCONF.
| Target system software requirements: IBM 31-bit SDK for z/OS, Java Technology
| Edition, V6 (5655-R31)
requirements:
Restrictions: None.
IBM Health Checker for z/OS check: None.

Steps to take:
1. Install IBM 31-bit SDK for z/OS, Java 2 Technology Edition, V6 (5655-R31).
2. If you use the IPP Server, edit the aopstart EXEC to update the directory path
specified in the JAVA_HOME environment variable. IPP Server requires the
31-bit version of Java V6.0.
3. If you use the z/OS HTTP Server, update the setting of JAVA_HOME in the
z/OS HTTP Server environment variables file httpd.envvars.

Note: If you installed Java V6.0 in the default Java directories, you do not need to
specify the JAVA_HOME environment variable. If JAVA_HOME is not
specified, IPP Server looks for Java files in the /usr/lpp/java/J6.0 directory.


Reference information: For information about how to edit the aopstart EXEC and
the z/OS HTTP Server environment variables file, see z/OS Infoprint Server
Customization.

Infoprint Server actions to perform before the first IPL of z/OS V1R13
This topic describes Infoprint Server migration actions that you can perform after
you have installed z/OS V1R13 but before the first time you IPL. These actions
might require the z/OS V1R13 level of code to be installed but do not require it to
be active.

Remount the Printer Inventory and copy files that were
customized
Description: When migrating to z/OS V1R13 Infoprint Server, you must bring
forward the customized data from your previous system.

specific release.
requirements:
Restrictions: None.
check:

Steps to take:
v Printer Inventory:
– Remount the /var/Printsrv directory from the z/OS V1R11 or V1R12 system
on the z/OS V1R13 system. The /var/Printsrv directory contains the Printer
Inventory as well as other Infoprint Server files. The default directory is
/var/Printsrv. However, you might have changed the directory name in the
base-directory attribute in the aopd.conf configuration file.
Notes:
1. After you start Infoprint Server on the z/OS system, you should use the
Infoprint Server pidu command to export the Printer Inventory on the
z/OS V1R13 system so that you have a backup of the Printer Inventory.
2. If /var/Printsrv is not mounted at a separate mount point, use the
Infoprint Server pidu command to export the Printer Inventory on the
original system and restore it on the z/OS V1R13 system. Do not use
other copy commands to copy the Printer Inventory. (Mounting
/var/Printsrv at a separate mount point can result in better management
of disk space and easier migration.)
– Configure the Infoprint Server environment variables (for example,
AOPCONF, PATH, LIBPATH, NLSPATH, MANPATH) in /etc/profile.

v Configuration file: If you modified the Infoprint Server configuration file, copy the
file to the z/OS V1R13 system. Its default location is /etc/Printsrv/aopd.conf.
However, you might have specified a different location in environment variable
AOPCONF.
v aopstart EXEC: If you modified the aopstart EXEC, copy it to the z/OS V1R13
system.
v IP PrintWay™: If you currently use the IP PrintWay component of Infoprint
Server, copy to the z/OS V1R13 system any IP PrintWay exit routines and data
| stream filters you have written. It is a good practice to recompile the exits and
| filters on z/OS V1R13.
v NetSpool: If you currently use the NetSpool component of Infoprint Server, copy
| to the z/OS V1R13 system any NetSpool exit routines you have written. It is a
| good practice to recompile the exits and filters on z/OS V1R13.
v Print Interface: If you currently use the Print Interface component of Infoprint
Server, take these actions:
– If you have written any data stream filters, copy them to the z/OS V1R13
system. You do not need to recompile them.
– If you run the SAP R/3 application server on the z/OS system, copy the SAP
callback daemon configuration file to the z/OS V1R13 system. Its default
location is /etc/Printsrv/aopsapd.conf. However, you might have specified a
different location in environment variable AOPSAPD_CONF.
v Infoprint Central: If you currently use Infoprint Central, copy the z/OS HTTP
Server configuration and environment variables files to the z/OS V1R13 system.
The default locations of these files are /etc/httpd.conf and /etc/httpd.envvars.

Reference information: z/OS Infoprint Server Customization.

| Update or remove the region size in the AOPSTART startup
| procedure
| Description: Starting with z/OS V1R13, the Infoprint Server startup procedure
| AOPSTART specifies a region size of 512 megabytes. Before z/OS V1R13,
| AOPSTART did not specify a region size, so the default region size defined for
| your installation was used.

| Because the default region size might not be sufficient to use all the functions that
| Infoprint Server provides, it is a good practice to specify a region size on the
| startup procedure. However, if you want to continue to use the default region size
| or a region size other than 512 megabytes, edit the AOPSTART procedure to
| remove the region specification. If you have customized the AOPSTART procedure,
| you can continue to use the customized version.
|
| Element or feature: Infoprint Server.
| Is the migration action required? Yes, if you use the AOPSTART procedure
| that IBM provides and want to continue to
| use the default region size used in releases
| prior to z/OS V1R13.


| requirements:
| IBM Health Checker for z/OS check: None.
|

| Steps to take:
| 1. Modify the EXEC statement in the AOPSTART procedure to remove or alter the
| REGION parameter:
| //AOPSTART EXEC PGM=AOPBATCH,PARM=’//usr/lpp/Printsrv/bin/aopstart’,
| // REGION=512M,
| // TIME=NOLIMIT
| 2. Save the AOPSTART procedure.

| Tips:
| v The AOPSTART procedure is distributed in SYS1.IBM.PROCLIB. However,
| during installation it might have been copied to another data set in the started
| task PROCLIB concatenation.
| v Specify a region size of at least 256 MB if you start the Infoprint Server
| Transform Manager to run data stream transforms. (This tip also applies to
| releases before z/OS V1R13.)
| v Specify a region size of at least 200 MB if you start the Infoprint Server IPP
| Server to receive print requests from IPP-enabled clients. (This tip also applies to
| releases before z/OS V1R13.)
| v User exits, such as IEFUSI, can modify the region size of an address space. Do
| not alter the region size of address spaces in the OMVS subsystem category.

| v For information about the AOPSTART procedure, see z/OS Infoprint Server
| Customization.
| v For more information about the IEFUSI exit, see z/OS MVS Installation Exits.

Upgrade XML for Infoprint Central
Description: In z/OS V1R12, the Infoprint Central component of Infoprint Server,
which you can use to work with IP PrintWay extended mode print jobs and
printers, requires the IBM XML Toolkit for z/OS V1.10 (5655-J51) product.

Is the migration action required? Yes, if you use Infoprint Central. You are
using Infoprint Central if the
start-daemons={ssid} attribute is specified in
the Infoprint Server configuration file. The
file's default location is /etc/Printsrv/
aopd.conf. However, you might have
specified a different location in environment
variable AOPCONF.


| Target system software requirements: IBM XML Toolkit for z/OS V1.10 (5655-J51).
requirements:
Restrictions: None.
check:

Steps to take:
1. Install IBM XML Toolkit for z/OS V1.10 (5655-J51).
2. Specify the XML Toolkit for z/OS V1.10 libraries in the LIBPATH environment
variable in your z/OS IBM HTTP Server environment variables file (default
location is /etc/httpd.envvars). After z/OS V1R13 is installed, Infoprint
Central requires the XML Toolkit for z/OS V1.10 libraries:
v LIBPATH: change /usr/lpp/ixm/IBM/xml4c-5_6/lib to /usr/lpp/ixm/IBM/
xml4c-5_7/lib
v LIBPATH: change /usr/lpp/ixm/IBM/xslt4c-1_10/lib to
/usr/lpp/ixm/IBM/xslt4c-1_11/lib
v ICU_DATA: You can remove this variable because XML no longer uses this
variable.
3. Restart the z/OS IBM HTTP Server to pick up the changes to the environment
variables file.

Reference information: For information about how to customize Infoprint Central,
see z/OS Infoprint Server Customization.

Migrate from IP PrintWay basic mode to extended mode
Description: Since z/OS V1R5, the IP PrintWay component of Infoprint Server can
operate in a mode called IP PrintWay extended mode. IP PrintWay extended mode
uses the SYSOUT Application Programming Interface (SAPI) to obtain output data
sets from the JES spool. IP PrintWay extended mode provides better performance,
improved usability, and additional functions. For information about the
enhancements and limitations in extended mode, see z/OS Infoprint Server
Customization.

IP PrintWay basic mode is the name used for the original IP PrintWay mode of
operation. You can continue to run IP PrintWay basic mode in z/OS V1R13. In
future releases, IBM will make enhancements only to IP PrintWay extended mode.

You can run IP PrintWay basic mode and IP PrintWay extended mode at the same
time only if you make sure that IP PrintWay basic mode and IP PrintWay extended
mode select different print jobs from the JES spool to print. Otherwise,
unpredictable results can occur.

When change was introduced: Basic mode was stabilized in z/OS V1R5.
Extended mode was introduced in z/OS
V1R5.


Is the migration action required? No, but recommended because it will become
a requirement in a future release.
Target system software requirements: v If you use Infoprint Central to work with
IP PrintWay extended mode print jobs and
printers, you need:
– An operating IBM HTTP Server base
element of z/OS
– The XML Toolkit for z/OS V1.10
(5655-J51)
– IBM 31-bit SDK for z/OS, Java
Technology Edition, V6 (5655-R31).
– Microsoft Internet Explorer 5.5,
Netscape Navigator 7.0, or IBM Home
Page Reader 4.0
v In addition to IBM 31-bit SDK for z/OS,
Java Technology Edition, V6 (5655-R31),
one of the following will also work:
– IBM 64-bit SDK for z/OS, Java
Technology Edition, V6 (5655-R32)
– IBM 31-bit SDK for z/OS, Java 2
Technology Edition, V5 (5655-N98)
– IBM 64-bit SDK for z/OS, Java 2
Technology Edition, V5 (5655-N99)
v To use IP PrintWay extended mode to
print to VTAM-controlled printers,
Infoprint Coaxial Printer Support for z/OS
(5655-N62) is required.
requirements:
Restrictions: None.
Related IBM Health Checker for z/OS Use check INFOPRINT_PRINTWAY_MODE,
check: available with APAR OA26583, to determine
if you are currently using IP PrintWay basic
mode.

Steps to take: See Migrating from IP PrintWay basic mode to extended mode in

v z/OS Infoprint Server Customization describes the features and limitations of IP
PrintWay extended mode and how to customize IP PrintWay extended mode. It
also describes how to customize the common message log and Infoprint Central.
v z/OS Infoprint Server Operation and Administration describes how to log in to
Infoprint Central and how to view messages in the common message log. It also
describes how to modify printer definitions for IP PrintWay extended mode.
v z/OS Infoprint Server User's Guide describes considerations for submitting print
jobs when you use IP PrintWay extended mode.
v z/OS Infoprint Server Messages and Diagnosis describes how to trace IP PrintWay
extended mode.


v The Infoprint Central online help system describes how to use Infoprint Central.

Infoprint Server actions to perform after the first IPL of z/OS V1R13
This topic describes Infoprint Server migration actions that you can perform only
after you have IPLed z/OS V1R13. You need a running z/OS V1R13 system to
perform these actions.

Run aopsetup
Description: When migrating to z/OS V1R13 Infoprint Server, you must run the
aopsetup shell script to establish the correct file permissions for Infoprint Server
directories and files.

specific release.
requirements:
Restrictions: None.
check:

Steps to take: Run the aopsetup shell script from an rlogin shell, from an OMVS
session, or with the BPXBATCH command. Specify the names of the RACF groups
that you defined for Infoprint Server operators and administrators as arguments to
aopsetup. For example, if you defined group AOPOPER for operators and group
AOPADMIN for administrators, enter:
/usr/lpp/Printsrv/bin/aopsetup AOPOPER AOPADMIN

Rule: You must run aopsetup from a user ID with a UID of 0. You can use the su
command to switch to an effective UID of 0 if you have READ access to the
BPX.SUPERUSER profile in the RACF FACILITY class.

Tip: You can run aopsetup from the driving system (instead of the target system) if
all of these are true:
v You have the target system's /var/Printsrv directory accessible.
v You reference the target system's /usr/lpp/Printsrv directory mounted under a
/service directory as described in the comments at the beginning of the
aopsetup shell script.
v The RACF database groups for operators and administrators are the same on the
driving and target system.

Reference information: For details about running aopsetup, see z/OS Infoprint
Server Customization.


Remove Version 1 Printer Inventory files after deploying z/OS
V1R13
| Description: When you migrate from z/OS V1R11 and start Infoprint Server in
| z/OS V1R13 for the first time, Infoprint Server reformats the Version 1 Printer
| Inventory files and creates Version 2 Printer Inventory files. The Version 1 Printer
| Inventory files are not removed so that if you need to fall back to z/OS V1R11,
| Infoprint Server can use the Version 1 Printer Inventory files.

After you have fully deployed z/OS V1R13 and are sure that you will not need to
fall back to z/OS V1R11, you can remove the Version 1 Printer Inventory files to
free up space in the Infoprint Server base directory.

Is the migration action required? No, but recommended to free up space in the
Infoprint Server base directory.
| Other system (coexistence or fallback) If you need to fall back to z/OS V1R11 after
| requirements: removing the Version 1 Printer Inventory
| files, use the pidu command to export the
| Version 2 Printer Inventory on the z/OS
| V1R13 system and import the exported copy
| to the z/OS V1R11 system.
Restrictions: None.
IBM Health Checker for z/OS check: None.

Steps to take:
1. Remove the Printer Inventory Version 1 database files in the Infoprint Server
base directory. Version 1 files have a “db” extension. The default base directory
is /var/Printsrv.
Example: These z/OS UNIX commands switch to an effective UID of 0, remove
all files with the “db” extension from directory /var/Printsrv, and switch back
to the original UID:
su
rm -f $(find /var/Printsrv/ -name "*.db")
exit

Note: To remove Printer Inventory files, you must have an effective UID of 0
or be a member of the RACF AOPADMIN group.

Reference information: For information about the /var/Printsrv directory and
how to use the pidu command to export and import the Printer Inventory, see


Chapter 12. JES2 migration actions
JES2 actions to perform before installing z/OS JES2 actions to perform after the first IPL of z/OS
V1R13 . . . . . . . . . . . . . . . . 239 V1R13 . . . . . . . . . . . . . . . . 240
Update code to remove references to PDBLENG 239 Activate z11 mode. . . . . . . . . . . 240
Ensure calls to JES Property Information Check BERT utilization . . . . . . . . 242
Services SSI can handle multiple members. . . 240
JES2 actions to perform before the first IPL of z/OS
V1R13 . . . . . . . . . . . . . . . . 240

This topic describes migration actions for base element JES2.

JES2 actions to perform before installing z/OS V1R13
This topic describes JES2 migration actions that you can perform on your current
they are made.

Update code to remove references to PDBLENG
Description: Starting with z/OS V1R12, JES2 supports variable size PDDBs,
though the PDDBs generated in this release remain a fixed size. Installation exits
that examine PDDBs or step through PDDBs using the compile time length of the
PDDB need to be updated to use a run time length field. To facilitate locating an
exit code that is assuming a fixed PDDB size, the compile time length equate
PDBLENG has been deleted. Code that used this compile time length should be
updated to use the run time field PDBSIZE to determine the size of the PDDB. The
field PDBSIZE has correctly contained the length of the PDDB since z/OS V1R7
(the field existed in earlier releases but was not consistently set).

Element or feature: JES2.
When change was introduced: z/OS V1R12 JES2.
Applies to migration from: z/OS V1R11 JES2.
Is the migration action required? Yes, if installation exits use PDBLENG
equate.
requirements:
Restrictions: None.
check:

Steps to take: Before installing z/OS V1R13 JES2, review installation exits for
references to the field PDBLENG. If any references are found, the code needs to be
updated to use the run time PDDB length field PDBSIZE.


Reference information: For a description of how to write installation exits, see
z/OS JES2 Installation Exits.

Ensure calls to JES Property Information Services SSI can
handle multiple members
Description: In z/OS V1R11 JES2, the Initiator information function of the JES
Property Information Services SSI (SSI 82) returned information for the local
member only, even if multiple members matched the value that was specified on
the member filter. In z/OS V1R12 JES2, if information for multiple members is
requested by specifying wildcards on the member filter, the Initiator information
function will return information for all members that match the filter request.

Is the migration action required? Yes, if you are using the Initiator information
function of the JES Property Information
Services SSI.
requirements:
Restrictions: None.
Related IBM Health Checker for z/OS None
check:

Steps to take: Before installing z/OS V1R13 JES2, ensure that all calls to the
Initiator information function of the JES Property Information Services SSI (SSI 82)
that request information for multiple members can correctly handle information
being returned for multiple members.

Reference information: See z/OS MVS Using the Subsystem Interface for more
information.

JES2 actions to perform before the first IPL of z/OS V1R13
None.

JES2 actions to perform after the first IPL of z/OS V1R13
This topic describes JES2 migration actions that you can perform only after you
actions.

Activate z11 mode
Description: If you wish to take advantage of the full-function level of z/OS
V1R11 JES2, you must be in z11 mode. Activating z11 mode upgrades the JES2
checkpoint and enables JES2 functionality that is introduced in z/OS V1R11,


including JOE data area extensions supported by BERTs. For more information on
the JES2 functionality introduced in z/OS V1R11, see the reference links below.

Is the migration action required? No, but recommended to activate the
full-function level of z/OS V1R13 JES2
processing.
requirements:
Restrictions: In order to activate z11 mode, all systems in
the JES2 MAS must be at z/OS V1R11 or
later. You may fall back to z2 mode, if
necessary.
Related IBM Health Checker for z/OS Use check JES2_Z11_Upgrade_CK_JES2 to
check: determine if your system is ready to upgrade
the JES2 checkpoint to z11 mode. For more
information, see IBM Health Checker for z/OS:
User's Guide.

Steps to take:
v After migrating to z/OS V1R11 JES2, or later, on all systems in your MAS,
determine your z11 checkpoint activation readiness:
1. Use the $D ACTIVATE command. This command indicates if activation to
z11 mode will succeed.
2. Review your current utilization of BERT data to determine if there are
sufficient BERTS, as detailed in “Check BERT utilization” on page 242.
| 3. If you issue the $ACTIVATE,LEVEL=z11 command, activation of LARGEDS
| support is required.
| 4. An additional nnn 4K records for CKPT1 is required for z11 mode.
| v Run the JES2 $ACTIVATE command to verify non-configuration changes that
| must be accommodated before going to z11, and to activate z11 mode following
the considerations for this command found in z/OS JES2 Commands.

Note: The SPOOLDEF LARGEDS=FAIL (default value) in JES2PARM parmlib
member is not supported in z11 mode. In z11 mode, on a COLD start,
JES2 defaults to LARGEDS=ALLOWED. However, you cannot issue the
$ACTIVATE,LEVEL=z11 command in the environment of SPOOLDEF
LARGEDS=FAIL.

By default, JES2 restarts in the same mode (z2 or z11) as other members of the
MAS (if any are active) or the mode the last active JES2 member was in when it
came down. To restart JES2 in z2 mode, specify UNACT on PARM=. On a cold
start JES2 starts in z11 mode unless overridden by OPTSDEF
COLD_START_MODE or UNACT parameter.

Chapter 12. JES2 migration actions 241

Check BERT utilization
Before issuing the $ACTIVATE,LEVEL=z11 command, review the current
utilization of BERT data to determine whether there are sufficient BERTs.
Additional BERTs are needed for each SYSOUT data set that has transaction data
associated with it. These SYSOUT data sets can be seen using SDSF by setting
APPC ON and examining SYSOUT data sets on the H and O panels; SYSOUT data
sets with transaction data have nontraditional JES2 job IDs. Consider increasing the
number of BERTs to correspond to two times the maximum number of transaction
SYSOUT data sets on the system. BERT utilization should be monitored after the
$ACTIVATE to z11 mode to ensure there are sufficient BERTs for the jobs and
SYSOUT in the MAS. There are several ways to determine your current BERT
usage.
v The $D CKPTSPACE,BERTUSE command displays a table of the types of control
blocks in BERTs and how many BERTs are used by each control block type. The
example below shows the output of the command:
$HASP852 CKPTSPACE CURRENT BERT UTILIZATION
$HASP852 TYPE COUNT CB COUNT
$HASP852 -------- --------- ---------
$HASP852 INTERNAL 11 1,
$HASP852 JQE 211 108,
$HASP852 CAT 114 38,
$HASP852 WSCQ 1 1,
$HASP852 DJBQ 0 0,
$HASP852 JOE 0 0,
$HASP852 FREE 763 0

In the example, there are 108 JQEs that have a total of 211 BERTs associated with
them. This example is for a system in z2 mode and does not have any BERTs
associated with JOEs.
v The $D ACTIVATE command displays the number of BERTs that are needed for
activation to z11 mode. This is the number of BERTs that will be associated with
JOEs after the $ACTIVATE. The example below shows the output of the $D
ACTIVATE command:
$HASP895 $DACTIVATE
$HASP895 JES2 CHECKPOINT MODE IS CURRENTLY Z2
$HASP895 THE CURRENT CHECKPOINT:
$HASP895 -- CONTAINS 1100 BERTS AND BERT UTILIZATION IS 30
$HASP895 PERCENT.
$HASP895 -- CONTAINS 158 4K RECORDS.
$HASP895 z11 CHECKPOINT MODE ACTIVATION WILL:
$HASP895 -- EXPAND CHECKPOINT SIZE TO 165 4K RECORDS.
$HASP895 -- REQUIRE 22 ADDITIONAL BERTS AND UTILIZATION
$HASP895 WOULD REACH 32 PERCENT.
$HASP895 z11 ACTIVATION WILL SUCCEED IF ISSUED FROM THIS MEMBER.

In the example, there are 22 additional BERTs that will be used after the
$ACTIVATE to z11 mode, for transaction data associated with JOEs.

Note: When the SPOOLDEF LARGEDS=FAIL (default value) is in effect in your
JES2PARM parmlib member, the following message will be issued by the
$ACTIVATE command:
$HASP895 z11 ACTIVATION WILL FAIL IF ISSUED FROM THIS MEMBER.
$HASP895 THE FOLLOWING ISSUES PREVENT ACTIVATION:
$HASP895 -- LARGEDS SUPPORT MUST BE ACTIVATED.
v A general history of BERT usage can be obtained by using the $JD
HISTORY(BERT) command or by using the SDSF RM panel. This displays the
usage of BERTs after the system was IPLed. The example below shows the
output of the $JD HISTORY(BERT) command:


$HASP9130 D HISTORY
$HASP9131 JES2 BERT USAGE HISTORY
DATE TIME LIMIT USAGE LOW HIGH AVERAGE
-------- -------- -------- -------- -------- -------- --------
2009.086 16:00:00 1100 337 337 337 337
2009.086 15:50:09 1100 337 125 337 192

v For a list of the enhancements introduced in z/OS V1R11 for z11 mode, see z/OS
Introduction and Release Guide.
v For $ACTIVATE, $D ACTIVATE, $D CKPTSPACE and $JD HISTORY command
details, see z/OS JES2 Commands.


Chapter 13. JES3 migration actions
JES3 actions to perform before installing z/OS Modify code that uses DATLOREC and
V1R13 . . . . . . . . . . . . . . . . 245 DATINPTR (IATYDAT) as a programming
| Modify code that depends on the format of interface . . . . . . . . . . . . . . 247
| suppressed split messages in the DLOG . . . 245 JES3 actions to perform after the first IPL of z/OS
JES3 actions to perform before the first IPL of z/OS V1R13 . . . . . . . . . . . . . . . . 248
V1R13 . . . . . . . . . . . . . . . . 246
| Avoid redundant *S main,FLUSH command in
| response to XCF messages . . . . . . . . 246

This topic describes migration actions for optional feature JES3.

JES3 actions to perform before installing z/OS V1R13
This topic describes JES3 migration actions that you can perform on your current
they are made.

| Modify code that depends on the format of suppressed split
| messages in the DLOG
| Description: The JES3 DLOG facility was introduced for tracking all message
| activity in a sysplex. It uses an MCS extended console to receive the messages and
| reformats them in the JES3 format. When these messages are longer than can be
| formatted into a single line, they are split into two lines. Prior to z/OS V1R13 JES3,
| longer messages having a receive ID were formatted differently if they were
| suppressed by the message processing facility (MPF). Beginning with z/OS V1R13
| JES3, all suppressed messages with a receive ID are split in the same manner.

| The following DLOG excerpt shows how a suppressed message (XXX100I) was
| split prior to z/OS V1R13 JES3:
| 10250 1143599 SY1 R= XXX33913 ICH70001I IBMUSER LAST ACCESS AT 11:39:46 ON MONDAY, NOVEMBER 1, 2010
| 10250 1144001 SY1 R= XXX33913 IEF403I XXX33913 - STARTED - TIME=11.44.00
| MLG 10250 1144004 &SY1 R= XXX33913 +XXX100I 9012345678901234567890123456
| MLG 10250 1144004 &SY1 R= XXX3391378901234567890123456789012345678901234567890123456789012345
| 10250 1144004 SY1 R= XXX33913 IEF404I XXX33913 - ENDED - TIME=11.44.00

| The following DLOG excerpt shows how a suppressed message (XXX100I) is split
| prior beginning with z/OS V1R13 JES3:
| 10305 1000486 SY1 R= XXX33913 ICH70001I IBMUSER LAST ACCESS AT 09:57:46 ON MONDAY, NOVEMBER 1, 2010
| 10305 1000488 SY1 R= XXX33913 IEF403I XXX33913 - STARTED - TIME=10.00.48
| MLG 10305 1000494 &SY1 R= XXX33913 +XXX100I 9012345678901234567890123456
| MLG 10305 1000494 &SY1 R= XXX33913 78901234567890123456789012345678901234567890123456789012345
| 10305 1000494 SY1 R= XXX33913 IEF404I XXX33913 - ENDED - TIME=10.00.49

|
| Element or feature: JES3.
| When change was introduced: z/OS V1R13 JES3.
| Applies to migration from: z/OS V1R12 JES3.
| Is the migration action required? Yes, if your installation has a code
| dependency on the format of messages in the
| JES3 DLOG.


| requirements:
| check:
|

| Steps to take: Ensure that any dependency on DLOG message formats are
| examined and corrected.

| Reference information: For more information, see the "Message Format" chapter in
| z/OS JES3 Messages.

JES3 actions to perform before the first IPL of z/OS V1R13
This topic describes JES3 migration actions that you can perform after you have
active.

| Avoid redundant *S main,FLUSH command in response to
| XCF messages
| Description: Prior to z/OS V1R13, a DOWN response to message IXC102A issued
| for a JES3 local processor required operations to enter the *S main,FLUSH
| command. Without the *S main,FLUSH command, jobs on the local were held up
| until the local processor was reconnected.

| Starting in z/OS V1R13, JES3 flushes the active jobs on the local processor
| automatically as soon as the operator responds to message IXC102A. This
| automatic flush eliminates the step of issuing the command and reduces the time
| gap between the local processor being removed from the sysplex and job recovery
| actions.

| In z/OS V1R13 and later releases, if you run the *S main,FLUSH command in
| response to the XCF messages, the command will have no effect because the
| affected jobs will have already been flushed by the new automatic processing.
|
| Element or feature: JES3.
| Is the migration action required? No, but recommended to avoid redundant *S
| main,FLUSH commands.
| requirements:


| check:
|

| Steps to take: If you want to avoid redundant *S main,FLUSH commands, remove
| the *S main,FLUSH command from all automated procedures or operating
| procedures.

| Reference information: z/OS JES3 Messages.

Modify code that uses DATLOREC and DATINPTR (IATYDAT)
as a programming interface
Description: When a job's JCL contains in-stream data sets, the in-stream data is
stored in multi-record files apart from the JESJCLIN file. These files are located by
SYSIN pointer records that are written into a job's JESJCLIN file by input service.
Prior to z/OS V1R12 (without APAR OA34642), SYSIN pointer records were
included in the JESJCLIN file's record count which is saved in DATLOREC
| (IATYDAT). In z/OS V1R12, z/OS V1R11, and z/OS V1R10 (with APAR OA33040),
the SYSIN pointer records were not included in the record count for JESJCLIN
| files. With APAR OA34642 applied, a new flag, DATCTLRD (IATYDAT), will be on
for any record, including SYSIN pointer records, that are not included in a file's
record count.

| When change was introduced: z/OS V1R12 JES3, z/OS V1R11 JES3, and
| z/OS V1R10 JES3 with the PTF for APAR
| OA34642 applied.
| Applies to migration from: z/OS V1R12 JES3 or z/OS V1R11 JES3
| without the PTF for APAR OA34642 applied.
Is the migration action required? Yes, if you use DATLOREC and DATINPTR
(IATYDAT) as a programming interface.
requirements:
Restrictions: None.
check:

Steps to take: Before applying the PTF for APAR OA34642, examine and modify
any code that uses DATLOREC and DATINPTR (IATYDAT) as a programming
interface. Note that IATYDAT is an internal JES3 control block that resides on spool
and that this change affects only JESJCLIN data sets.

Reference information: For more information, see z/OS JES3 Initialization and
Tuning Guide.


JES3 actions to perform after the first IPL of z/OS V1R13
None.


Chapter 14. Language Environment migration actions
Language Environment actions to perform before Examine programs that read output when a D
installing z/OS V1R13 . . . . . . . . . . 249 CEE command is issued . . . . . . . . . 252
Language Environment actions to perform before Set runtime options as overrideable or
the first IPL of z/OS V1R13 . . . . . . . . 249 nonoverrideable in CEEPRMxx parmlib member 253
Determine the impact of added and changed Language Environment actions to perform after the
runtime options . . . . . . . . . . . 249 first IPL of z/OS V1R13 . . . . . . . . . . 254
Update the CSD based on the newest CEECCSD 249 Examine programs that read output from a
Update Language Environment load modules in CICS CLER transaction . . . . . . . . . 254
the LPA . . . . . . . . . . . . . . 250 Use Unicode Services to create conversion tables 255
| Convert to CEEPRMxx to set system-level
| default runtime options . . . . . . . . . 251

This topic describes migration actions for base element Language Environment.

Language Environment actions to perform before installing z/OS
V1R13
None.

Language Environment actions to perform before the first IPL of z/OS
V1R13
This topic describes Language Environment migration actions that you can

Determine the impact of added and changed runtime options
| Description: Periodically, Language Environment introduces new runtime options,
| adds new suboptions to existing runtime options, and changes the defaults of
| runtime options. For z/OS V1R12 and z/OS V1R13, no runtime options were
| changed or new suboptions added. Therefore, no migration action is required for
| your migration to z/OS V1R13.

Update the CSD based on the newest CEECCSD
Description: Each release, Language Environment adds or deletes load modules in
the CICS system definition (CSD) file. Thus, you should update the file each
release using the program definitions found in member CEECCSD and, if using
| CICS Transaction Server (TS) for z/OS V3 (5655-M15), in member CEECCSDX. The
| CSD samples provided by Language Environment (CEECCSD and CEECCSDX) at
| the latest release may be used for systems at lower releases that can co-exist with
| this level of z/OS.

Element or feature: Language Environment.
specific release.


Target system software requirements: CICS.
requirements:
Restrictions: None.
check:

| Steps to take: Update the CSD file using the program definitions in member
| CEECCSD (and member CEECCSDX if using CICS TS V3) found in the
| hlq.SCEESAMP data set.

| Note: The group containing the Language Environment runtime routines must be
| in the group list used during CICS startup.

Reference information: See z/OS Language Environment Run-Time Application
Migration Guide

Update Language Environment load modules in the LPA
Description: Each release you must update the Language Environment load
modules that you make accessible through the link pack area (LPA). In addition,
each release you should review your list of Language Environment load modules
in the LPA to determine if it's still suitable.

specific release.
Is the migration action required? Yes, if you need to make modules accessible
through the link pack area (LPA).
requirements:
Restrictions: None.
check:

Steps to take: Review Language Environment load modules in the LPA.

To move load modules into the LPA, use the following sample members in the
CEE.SCEESAMP data set:
v AFHWMLP2: This is a sample of all Language Environment Fortran component
modules eligible for the LPA.


v CEEWLPA: This is a sample of a PROGxx member of SYS1.PARMLIB that
includes all Language Environment CEE-prefixed runtime modules eligible for
the LPA (that is, all Language Environment base modules) except the callable
services stubs.
v CELQWLPA: This is a sample for AMODE 64 runtime support.
v EDCWLPA: This is a sample of a PROGxx member of SYS1.PARMLIB that
includes all Language Environment EDC-prefixed and CEH-prefixed runtime
modules eligible for the LPA (that is, all XL C/C++ component modules) except
locales and code page converters.
v IBMALLP2 (or IBMPLPA1 for Enterprise PL/I for z/OS): This is a sample of all
Language Environment PL/I component modules eligible for the LPA.
v IGZWMLP4: This is a sample of all Language Environment COBOL component
modules eligible for the LPA.

To see which modules are eligible for the LPA, refer to z/OS Language Environment
Customization. The modules listed there can be put in the LPA or extended LPA
(ELPA) depending on their RMODE value:
v If the RMODE is ANY, the module can reside in the LPA or in the ELPA (above
or below the 16 MB line).
v If the RMODE is 24, the module can reside only in the LPA (below the 16 MB
line).

If you are considering placing the modules listed in z/OS Language Environment
Customization in the LPA or the ELPA, then IBM recommends that you place the
SCEELPA data set in the LPA list (LPALSTxx). SCEELPA contains Language
Environment load modules that are reentrant, that reside above the 16 MB line,
and that are heavily used by z/OS.

In z/OS Language Environment Customization you will also see tables of modules
eligible for the LPA and the ELPA above and beyond what is found in the
SCEELPA data set. You will need to use the dynamic LPA or MLPA approach to
move these modules into the LPA or ELPA. You do not need to include
recommended modules if they contain functions your installation does not use.
Language Environment modules not listed in these tables can be moved into the
LPA or ELPA at your discretion.

Reference information: See the table “Language Environment sample IEALPAnn
or PROGxx members in hlq.SCEESAMP” for the list of sample members and their
changed content in z/OS Language Environment Customization. The table contains a
list of eligible load modules for:
v Language Environment base modules
v Language Environment XL C/C++ component modules
v Language Environment COBOL component modules
v Language Environment Fortran component modules
v Language Environment PL/1 component modules

| Convert to CEEPRMxx to set system-level default runtime
| options
| Description: In the IBM z/OS V1.12 Software Announcement 210-235 dated 22 July
| 2010, IBM announced plans to remove, in a future release, the capability to change
| the default Language Environment runtime options settings using SMP/E
| installable USERMODs. If you are still using assembler modules to specify your

Chapter 14. Language Environment migration actions 251

| installation-wide default runtime options (CEEDOPT, CEECOPT, or CELQDOPT),
| IBM recommends you now convert to using the CEEPRMxx parmlib member to set
| your system-level default Language Environment runtime options.
|
| Element or feature: Language Environment.
| When change was introduced: z/OS V1R13. (Previewed in IBM z/OS V1.12
| Software Announcement 210-235, 22 July
| 2010.)
| Is the migration action required? No, but recommended because even though
| the runtime option usermods continue to be
| supported in this release, IBM plans to
| remove this functionality in a future release
| of z/OS.
| requirements:
| Related IBM Health Checker for z/OS Use CEE_USING_LE_PARMLIB to check that
| check: default Language Environment runtime
| options are set within a CEEPRMxx parmlib
| member.
|

| Steps to take:
| v If you are no longer using the Language Environment runtime option assembler
| usermods, you have no further action.
| v If you are using the Language Environment runtime option assembler usermods,
| you should now convert to CEEPRMxx. Taking this step now will eliminate a
| migration action in a future release.

| Reference information: For details about specifying CEEPRMxx, see z/OS Language
| Environment Customization.

Examine programs that read output when a D CEE command
is issued
Description: Starting in z/OS V1R12, changes are made to the Language
Environment runtime options report when a D CEE command is issued. Before
z/OS V1R12, the Language Environment runtime options report displayed all
suboptions, even if they were not explicitly set for any runtime option that was
specified. Starting in z/OS V1R12, when a valid option is specified with a parmlib
member or a SETCEE command, only the suboptions specified are displayed when
a D CEE command is issued. A comma is displayed as a place holder for those
suboptions not specified.



Is the migration action required? Yes, if you have an application that reads the
output of a D CEE command.
requirements:
Restrictions: None.
check:

Steps to take:

Examine any programs that read the output of a D CEE command to ensure
compatibility with the updated runtime options report. Commas are now
displayed for any suboptions that are not explicitly specified in a parmlib member
or with a SETCEE command.

For example, if the following SETCEE command is issued:
SETCEE CEEDOPT,ALL31,ANYHEAP(4K),FILETAG(,AUTOTAG)

a subsequent D CEE,CEEDOPT command displays the following:
CEE3745I 09.32.13 DISPLAY CEEDOPT
NO MEMBERS SPECIFIED
LAST WHERE SET OPTION
-----------------------------------------------------------------------
SETCEE command ALL31()
SETCEE command ANYHEAP(4096,,,)
SETCEE command FILETAG(,AUTOTAG)

Reference information: For more information, see z/OS Language Environment
Customization and z/OS MVS System Commands.

Set runtime options as overrideable or nonoverrideable in
CEEPRMxx parmlib member
Description: Before z/OS V1R12, all runtime options specified in a CEEPRMxx
parmlib member were overrideable by default. Beginning with z/OS V1R12, you
can set runtime options as overrideable or nonoverrideable in the CEEPRMxx
parmlib member or with a SETCEE command using the OVR or NONOVR
attribute. The ability to specify an option as overrideable or nonoverrideable
removes a barrier to using CEEPRMxx.

Is the migration action required? No, but recommended so you can eliminate
use of the assembler language usermods to
specify installation-wide runtime options,
and use parmlib member CEEPRMxx instead.


requirements:
Restrictions: None.
Related IBM Health Checker for z/OS Use CEE_USING_LE_PARMLIB to verify use
check: of the CEEPRMxx parmlib member.

Steps to take: Set runtime options as overrideable or nonoverrideable in the
CEEPRMxx parmlib member or by issuing the SETCEE command using the OVR
or NONOVR attribute.

Now that runtime options can be specified as overrideable or nonoverrideable in a
CEEPRMxx parmlib member, and with a SETCEE command, you can eliminate the
use of assembler language usermods to specify installation-wide runtime options.

v For details about specifying a CEEPRMxx parmlib member, see z/OS Language
Environment Customization.
v For the updated CEEPRM00 sample parmlib member, which includes every
option specified as overrideable, see the CEE.SCEESAMP data set.

Language Environment actions to perform after the first IPL of z/OS
V1R13
This topic describes Language Environment migration actions that you can

Examine programs that read output from a CICS CLER
transaction
Description: Starting with z/OS V1R12, the Language Environment runtime
options report displayed from the CICS CLER transaction is changed. The report is
modified to have a wider LAST WHERE SET column to accommodate longer
values, such as "Installation Non-overrideable." In addition, the report heading
OPTIONS is changed to OPTION to match the other runtime options reports.

Is the migration action required? Yes, if you have an application that reads the
output of a CICS CLER transaction.
requirements:
Restrictions: None.


check:

Steps to take: Examine programs that read the output of a CICS CLER transaction
to ensure compatibility with the updated CLER runtime options report. The LAST
WHERE SET column is now wider and the OPTIONS heading is changed to
OPTION. The following is a subset of the new report to show the formatting
changes:
LAST WHERE SET OPTION
----------------------------- -----------------------------------------------
Installation default ABPERC(NONE)
Installation default ABTERMENC(ABEND)
Installation default NOAIXBLD

Reference information: For more information, see z/OS Language Environment
Programming Guide and z/OS Language Environment Debugging Guide.

Use Unicode Services to create conversion tables
Description: Beginning with z/OS V1R12, the C/C++ runtime library will no
longer include any ucmap source code or genxlt source code for character
conversions now being performed by Unicode Services.

Is the migration action required? Yes, if you use the iconv() family of functions
to test to a "known conversion result"and
experience testcase failures. Also, if you use
custom conversion tables replacing those
listed in either ucmapt.lst or genxlt.lst.
requirements:
Restrictions: None.
check:

Steps to take:
v If you use customized conversion tables, you should now generate custom
Unicode Services conversion tables.
v If you use the iconv() family of functions testing to a “known conversion result”
and experience test case failures, you need to update your expected results to
the new conversion results.


v If you want to create custom conversion tables involving any of the CCSIDs
related to the conversion table source no longer being shipped, you should now
generate custom Unicode Services conversion tables instead of custom Language
Environment conversion tables.

The installation prefix.SCEEUMAP data set will no longer be shipped.

The /usr/lib/nls/locale/ucmap HFS directory will no longer be shipped.

Note: The _ICONV_TECHNIQUE environment variable must be set to the same
technique search order value used for the customized Unicode Services table
in order for the iconv() family of functions to use the customized Unicode
Services table. For example, if you want the iconv() family of functions to
use a user-defined Unicode Services table with a technique search order of 2,
the _ICONV_TECHNIQUE environment variable should be set to 2LMREC.

Reference information: For information about how to generate and use custom
Unicode Services conversion tables, see z/OS Unicode Services User's Guide and
Reference.


Chapter 15. Library Server migration actions
Library Server actions to perform before installing Copy Library Server configuration files. . . . 257
z/OS V1R13 . . . . . . . . . . . . . . 257 Copy Library Server notes files . . . . . . 258
Library Server actions to perform before the first Library Server actions to perform after the first IPL
IPL of z/OS V1R13 . . . . . . . . . . . 257 of z/OS V1R13 . . . . . . . . . . . . . 258

This topic describes migration actions for base element Library Server.

Library Server actions to perform before installing z/OS V1R13
None.

Library Server actions to perform before the first IPL of z/OS V1R13
This topic describes Library Server migration actions that you can perform after
you have installed z/OS V1R13 but before the first time you IPL. These actions
might require the z/OS V1R13 level of code to be installed but do not require it to
be active.

Copy Library Server configuration files
Description: The Library Server configuration files (bookmgr.80, booksrv.80)
contain information about your environment and preferences. The information in
bookmgr.80 includes the names of bookshelf lists for bookshelves in MVS™ data
sets and the names of the HFS directories that Library Server reads and writes
during execution. The information in booksrv.80 includes the HFS directory names
of book collections, shelves, and bookcases. There are default values but normally
you would customize them. In order to bring the customized values over to your
new system, you have to copy them. (Note that port number suffix .80, used in
bookmgr.80 and booksrv.80, is an example. Your port number suffix might be
different.)

Element or feature: Library Server.
specific release.
Is the migration action required? Yes, if you intend to preserve your Library
Server configuration.
requirements:
Restrictions: None.
check:


Steps to take: Copy your current (customized) configuration files, usually
bookmgr.80 and booksrv.80, to your new system and add any configuration
parameters that are new since the z/OS release from which you are migrating.
Otherwise Library Server will run with default values, not the values you're used
to. A suggested (but not required) place for these configuration files is
/etc/booksrv. Library Server will also search /etc and the original cgi-bin for
them. If you place the files in any other directory, use the EPHConfigPath
environment variable to tell Library Server where to find them.

Reference information: For a complete description of each parameter of the
Library Server configuration files, see z/OS Program Directory.

Copy Library Server notes files
Description: Users can make comments in book topics by creating notes that are
appended to the end of each topic. If you do not copy these notes to the new
system, they will be lost.

Element or feature: Library Server.
specific release.
Is the migration action required? Yes, if you intend to preserve notes from
release to release.
requirements:
Restrictions: None.
check:

Steps to take: Copy all the files from your existing notes directory to the new one.
The default directory for saving book notes is /usr/lpp/booksrv/public/bookmgr/
notes. You can override this default by specifying a directory on the NOTEDIR
parameter of the bookmgr.80 configuration file.

Reference information: For a complete description of each parameter of the
Library Server configuration files, see z/OS Program Directory.

Library Server actions to perform after the first IPL of z/OS V1R13
None.


Chapter 16. RMF migration actions
RMF actions to perform before installing z/OS Use an RMF Monitor III reporter version equal
V1R13 . . . . . . . . . . . . . . . . 259 to or later than your RMF Monitor III gatherer
RMF actions to perform before the first IPL of version . . . . . . . . . . . . . . 260
z/OS V1R13 . . . . . . . . . . . . . . 259 | Determine need of SMF data collection for
| Check your automation for Monitor III | Postprocessor Serialization Delay report . . . 261
| messages ERB812I and ERB813I . . . . . . 259 Retrieve the distribution of the IN-READY
RMF actions to perform after the first IPL of z/OS QUEUE . . . . . . . . . . . . . . 262
V1R13 . . . . . . . . . . . . . . . . 260

This topic describes migration actions for optional feature Resource Measurement
Facility™ (RMF).

RMF actions to perform before installing z/OS V1R13
None.

RMF actions to perform before the first IPL of z/OS V1R13
This topic describes RMF migration actions that you can perform after you have
active.

| Check your automation for Monitor III messages ERB812I and
| ERB813I
| Description: Starting with z/OS V1R13, RMF Monitor III messages ERB812I
| (introduced in z/OS V1R11) and ERB813I are issued as single line WTO messages.
| Before z/OS V1R13, for those messages, there could have been multiple WTOs if
| the message length was longer than 69 characters. If you use an automation
| product that processes these messages, check the algorithm, and, if required, adapt
| it to the new message output.
|
| Element or feature: RMF.
| Is the migration action required? Yes, if you use automation products for RMF
| messages ERB812I and ERB813I.
| requirements:
| check:
|


| Steps to take: If you use an automation product that processes RMF Monitor III
| messages ERB812I and ERB813I, check the algorithm because the output format of
| these messages changes in z/OS V1R13 RMF.

| Below are examples of the old output format and the new output format for these
| messages. Check the code of your automation product to determine if you need to
| adapt it to the new message output format.

| Old output format:
| ERB812I III: MONITOR III DATA RECORDING INTO DATA SET ’RMF.MONITOR3.D
| ERB812I III: ATASET3.SYSE’ STOPPED
| ERB813I III: ACTIVE MONITOR III DATA SET IS NOW ’RMF.MONITOR3.DATASET
| ERB813I III: 4.SYSE’

| New output format:
| ERB812I III: MONITOR III DATA RECORDING INTO DATA SET ’RMF.MONITOR3.DATASET3.SYSE’ STOPPED
| ERB813I III: ACTIVE MONITOR III DATA SET IS NOW ’RMF.MONITOR3.DATASET4.SYSE’

| Reference information: For further information see z/OS RMF Messages and Codes.

RMF actions to perform after the first IPL of z/OS V1R13
This topic describes RMF migration actions that you can perform only after you
actions.

Use an RMF Monitor III reporter version equal to or later than
your RMF Monitor III gatherer version
Description: To avoid problems when reporting Monitor III data, use an RMF
reporter version that is equal to or later than the latest RMF gatherer version used
to collect the data to be reported. For example, it is safe to use an RMF reporter
version from z/OS V1R13 for data collected with an RMF gatherer from z/OS
V1R11, but not vice versa.

Mixed (and therefore problematic) levels of collected data can occur in the
following scenarios:
v Single system: You install and test a new release, then fall back to an earlier one;
your data sets might contain data collected with different versions of the RMF
gatherer.
v Sysplex: You migrate to a new release on one system in a sysplex but try to use
an earlier reporter version from another system to report on the migrated
system's data.

Element or feature: RMF.
specific release.
Is the migration action required? Yes, if you had planned to use an
earlier-level RMF reporter on data that was
collected with a later-level RMF gatherer.


Other system (coexistence or fallback) See “Steps to take” below.
requirements:
Restrictions: None.
check:

Steps to take: Always use an RMF Monitor III reporter version that is equal to or
later than the gatherer version used to collect the data from which you want to
produce a report.

Note: Monitor III notifies users by issuing information message ERB948I when a
reporter session is started on a system in a sysplex that is not running with
the highest RMF level available in the sysplex. The message helps users to
avoid reporting problems.

Reference information: For more information about Monitor III commands, see
z/OS RMF User's Guide.

| Determine need of SMF data collection for Postprocessor
| Serialization Delay report
| Description: Starting with z/OS V1R13, RMF provides a new Postprocessor
| Serialization Delay report. If you do not need this report, you should turn off data
| collection for SMF record 72 subtype 5.
|
| Element or feature: RMF.
| Is the migration action required? No, but recommended if you do not want to
| collect SMF data for the Postprocessor
| Serialization Delay report.
| requirements:
| check:
|

| Steps to take: Determine if you want to use the new Postprocessor Serialization
| Delay report. SMF data required for this report is gathered by default. If you do
| not want to use this report, you should suppress the SMF data collection for the
| new record type 72 subtype 5. You achieve this by specifying NOTYPE for this
| SMF record type in the SMF parmlib member SMFPRMxx.

| Another method to suppress the data gathering of record 72.5 for the Serialization
| Delay report is to use the SUBSYS parameter in the SMFPRMxx parmlib member

Chapter 16. RMF migration actions 261

| for the STC subsystem (started tasks, where RMF is one of them). To exclude data
| gathering for SMF record 72.5, specify SUBSYS(STC,NOTYPE(72(5)), ... ).

| The SUBSYS specification overrides the SYS specification. So for example, if you
| have defined SYS(TYPE(...,72,...)) in your SMFPRMxx parmlib member, you can
| use SUBSYS(STC, NOTYPE(72(5))) to make exceptions to your SYS specification
| and just exclude gathering of SMF record 72.5 for started tasks like RMF.

| Reference information: For details about specifying SMF data collection, see z/OS
| MVS Initialization and Tuning Reference.

Retrieve the distribution of the IN-READY QUEUE
Description: Before z/OS V1R12, the Postprocessor CPU Activity report provided
a graphical representation of how many address spaces have been waiting in the
IN-READY QUEUE. Starting with z/OS V1R12, the DISTRIBUTION OF
IN-READY QUEUE is replaced by a more precise DISTRIBUTION OF WORK
UNIT QUEUE representation.

You can retrieve the old IN-READY QUEUE distribution values using the
corresponding Overview control statements and display a numerical representation
in the Postprocessor Overview report or a graphical representation in the
Spreadsheet Reporter.

Element or feature: RMF.
Is the migration action required? Yes, if you want to retrieve the old
IN-READY QUEUE information as presented
in the CPU Activity reports earlier than z/OS
V1R12.
requirements:
Restrictions: None.

Steps to take: Use the available OCPU1, OCPU2, ... OCPU80 Overview control
statements to retrieve the information presented in the DISTRIBUTION OF
IN-READY QUEUE of the CPU Activity reports earlier than z/OS V1R12. With
these statements, you can produce either a numerical representation in the
Postprocessor Overview report or you can use the RMF Spreadsheet Reporter to
see a graphical representation: Select the System Overview Report spreadsheet
macro and click on the OneCpuCont sheet to see the graphical output.

Reference information: For details about using Overview conditions for the
Overview Report and the Spreadsheet Reporter, see z/OS RMF User's Guide.


Chapter 17. SDSF migration actions
SDSF actions to perform before installing z/OS | Review colors on the OPERLOG panel . . . . 267
V1R13 . . . . . . . . . . . . . . . . 263 | Set the format of device names on the Punch
SDSF actions to perform before the first IPL of | and Reader panels. . . . . . . . . . . 268
z/OS V1R13 . . . . . . . . . . . . . . 263 Set a default for the Initiators panel . . . . . 269
Review and reassemble user exit routines . . . 263 Set the format of device names on the Printers
Use dynamic statements for ISFPARMS to avoid panel . . . . . . . . . . . . . . . 269
reassembly . . . . . . . . . . . . . 264 Update batch programs or REXX execs for
SDSF actions to perform after the first IPL of z/OS changes to message ISF770W . . . . . . . 270
V1R13 . . . . . . . . . . . . . . . . 266 Set the view of the OPERLOG . . . . . . . 271
| Update configuration for sysplex support . . . 266

This topic describes migration actions for optional feature SDSF.

SDSF actions to perform before installing z/OS V1R13
None.

SDSF actions to perform before the first IPL of z/OS V1R13
This topic describes SDSF migration actions that you can perform after you have
active.

Review and reassemble user exit routines
Description: If you have written user exit routines, review them to ensure they are
still appropriate for the current environment, and make changes as necessary. All
user exit routines must be reassembled with the z/OS V1R13 level of the SDSF
macro library.

Element or feature: SDSF.
specific release.
Is the migration action required? Yes, if user exit routines are in use.
requirements:
Restrictions: None.
check:


Steps to take: Review user exit routines to ensure they are appropriate for z/OS
V1R13. Make changes as necessary. Regardless of whether you have made changes,
reassemble the user exit routines with the z/OS V1R13 level of the SDSF macro
library.

| Tip: A PROPLIST statement, along with PROPERTY statements, both in the
| ISFPRMxx parmlib member, defines customized values for certain SDSF properties.
| It provides an alternative to writing user exit routines to customize those
| properties. A user exit routine that customizes the same property as a PROPERTY
| statement overrides the value on the PROPERTY statement.

Reference information: See z/OS SDSF Operation and Customization.

Use dynamic statements for ISFPARMS to avoid reassembly
Description: ISFPARMS in SDSF is used for specifying global options, the format
of panels, and security for SDSF functions. SDSF provides two alternatives for
ISFPARMS:
v Assembler macros that you define, assemble, and then link into the SDSF load
library. This is the original format for defining ISFPARMS and it continues to be
supported for compatibility.
v Dynamic statements, which are in parmlib member ISFPRMxx. Dynamic
statements are the recommended format. They are easier to code and are more
dynamic than the assembler macros; they can be updated without reassembling
or link-editing. The statements are processed by an SDSF server, which is
controlled by MVS operator commands.

specific release.
Is the migration action required? No, but recommended to avoid the migration
action of reassembling your customized
ISFPARMS for each z/OS release. (If you do
not use dynamic statements for ISFPARMS,
reassembly of your customized ISFPARMS is
required on each release.)
requirements:
Restrictions: None.


Related IBM Health Checker for z/OS Use check SDSF_ISFPARMS_IN_USE to
check: verify that SDSF dynamic statements in
ISFPRMxx are being used rather than the
assembler macros. If the check determines
that the assembler macro ISFPARMS is in use
instead, and that it has been modified, the
check generates an exception. If the
assembler macro ISFPARMS is in use but it
has not been modified, so that all defaults
are in effect, the check does not generate an
exception.

SDSF registers this check with the IBM
Health Checker for z/OS infrastructure when
the SDSF server address space is initialized.
However, one of the items this check verifies
is that the SDSF server itself is in use, so you
have to manually add this check (particularly
if you do not use the SDSF server) so that
the IBM Health Checker for z/OS
infrastructure will invoke the check. To add
the check, put the following statement in
your PROGxx parmlib member: EXIT ADD
EXITNAME(HZSADDCHECK) MODNAME(ISFHCADC).

| SDSF health checks are distributed in
| ISF.SISFLOAD for installations running SDSF
| in the LNKLST. The checks are also
| distributed in ISF.SISFLINK for installations
| that do not run SDSF in the LNKLST. For
| those installations, ISF.SISFLINK must be
| added to the LNKLST.

| Note: To avoid a possible ABEND 290 with
| reason code 02014007 issued by HZSADDCK:
| v Make sure that you specify the proper
| check routine name. The check routine
| module must be in an APF-authorized
| library. The system must be able to locate
| the check routine within the joblib, the
| steplib of the IBM Health Checker for
| z/OS address space, the LPA, or the
| LNKLST.
| v Make sure that you specify the proper
| message table name. The message table
| module must be in an APF-authorized
| library. The system must be able to locate
| the message table within the joblib, the
| steplib of the IBM Health Checker for
| z/OS address space, the LPA, or the
| LNKLST.

Steps to take: If you are already using dynamic statements for ISFPARMSxx, there
is no migration action to perform.

If you are using assembler macros for ISFPARMS, do one of the following:
v Convert your existing ISFPARMS to dynamic statements by using a conversion
utility that you invoke with the ISFACP command.

Chapter 17. SDSF migration actions 265

v Reassemble your customized ISFPARMS for use with z/OS V1R13. Reassembly
must be done whenever you change your z/OS release. Before reassembling
ISFPARMS, you might want to update it for new function. The assembler
ISFPARMS cannot be shared with any other release of SDSF. Only use
ISFPARMS for the release on which it is assembled.

| Note: Sample job ISFPARME has been removed from the samples supplied with
| SDSF. This job contained SMP/E control statements to receive the sample
| assembler macro ISFPARMS as a user modification (usermod). If you have
| an SMP/E usermod that specifies modifications to assembler macro
| ISFPARMS, change the usermod to indicate that module ISFPARMS is
| now owned by the SDSF JES2 feature FMID (JJE778S) and not the base
| SDSF FMID (HQX7780). The correct SMP/E syntax is ++VER(Z038)
| FMID(JJE778S), not ++VER(Z038) FMID(HQX7780).

v For details about invoking the conversion utility with the ISFACP command, see
z/OS SDSF Operation and Customization.
v For information about ISFPARMS and the ISFPRMxx parmlib member, see
"ISFPARMS format alternatives" in z/OS SDSF Operation and Customization.

SDSF actions to perform after the first IPL of z/OS V1R13
This topic describes SDSF migration actions that you can perform only after you
actions.

| Update configuration for sysplex support
| Description: When SDSF originally introduced support for sysplex-wide device
| and resource panels in a JES2 environment, that support required WebSphere® MQ,
| SDSF servers and a server group defined in ISFPARMS. In recent releases, SDSF
| enhancements have reduced the requirement for WebSphere MQ and the server
| group. Beginning with z/OS V1R13, SDSF completely eliminates the need for
| WebSphere MQ and the server group when all systems are at the z/OS V1R13
| level.

| The following panels are made sysplex-wide by default: LI (lines), NO (nodes),
| PUN (punches), RDR (readers) and SO (spool offloaders).

| The following panels now use cross system coupling facility (XCF) support to
| provide sysplex-wide data: CK (checks), ENC (enclaves), PS (processes) and RM
| (JES2 resources). Using XCF for the sysplex-wide data is preferable because XCF is
| always present and no configuration is required.

| If you have configured SDSF's sysplex support in previous releases, you may now
| have obsolete WebSphere MQ configuration and server group definitions in
| ISFPARMS.

| For the CK, ENC, PS and RM panels, you may need to perform some
| configuration to ensure that all of the systems are included in sysplex-wide panels.
|
| Element or feature: SDSF.


| requirements:
| check:
|

| Steps to take: If all of the systems in the sysplex are at the z/OS V1R13 level:
| v Consider removing obsolete definitions:
| – Server group statements (SERVERGROUP, SERVER and COMM) in
| ISFPARMS.
| – WebSphere MQ configuration and related SAF profiles, including queues that
| you defined for SDSF and SAF profiles that protect the queues used by SDSF.
| v Ensure that the names of the SDSF servers are the same on all systems. By
| default, SDSF uses the SDSF server name for the XCF application server name to
| obtain sysplex-wide data for the CK, ENC, PS and RM panels. If the names of
| the servers are not the same on all systems, you must specify the suffix of an
| XCF server name with the CONNECT statement in ISFPARMS.

| If the sysplex includes systems at the z/OS V1R13 level, and others at a lower
| level, and you want to include the lower level systems on the CK, ENC, PS or RM
| panels, you must set the communications mode to Z12. This causes SDSF to obtain
| sysplex-wide data as in previous releases, using WebSphere MQ and the server
| group. To set the communications mode:
| v Users can issue this command: SET CMODE Z12.
| v System programmers can use this custom property in ISFPARMS:
| Comm.Release.Mode. You set a custom property with the PROPLIST and
| PROPERTY statements in ISFPRMxx parmlib member.

| v For more information about the SET CMODE command, refer to the online
| help. For more information about ISFPRMxx, WebSphere MQ configuration and
| security and the requirements for sysplex-wide panels when the sysplex has
| mixed levels of z/OS and JES2, refer to z/OS SDSF Operation and Customization,
| SA22-7670.
| v For information about ISFPARMS and the ISFPRMxx parmlib member, see
| "ISFPARMS format alternatives" in z/OS SDSF Operation and Customization.

| Review colors on the OPERLOG panel
| Description: Starting with z/OS V1R13, messages are displayed on the OPERLOG
| panel with the color that was assigned to them when they were issued. Users can
| customize colors or disable the use of color with the SET SCREEN command.
|


| Is the migration action required? Yes, if you want to disable color on the
| OPERLOG panel.
| requirements:
| check:
|

| Steps to take: To disable color on the OPERLOG panel, use the SET SCREEN
| command.

| Reference information: For more information on the SET SCREEN command,
| refer to the online help.

| Set the format of device names on the Punch and Reader
| panels
| Description: Starting with z/OS V1R13, SDSF shows device names on the Punch
| (PUN) and Reader (RDR) panels in a longer format, with dots between subtypes.
| This could affect batch programs or REXX execs that process the device names. The
| system programmer can use a custom property to retain the shorter format that
| was used in previous releases.
|
| Is the migration action required? Yes, if you want device names on the PUN
| and RDR panels to be displayed in the
| shorter format, as in previous releases.
| requirements:
| check:
|

| Steps to take: In ISFPRMxx, set custom property
| Panel.PUN.DevNameAlwaysShort and Panel.RDR.DevNameAlwaysShort to TRUE,
| to use the short form of devices names on the PUN and RDR panels.


| Reference information: For details about setting the custom property in
| ISFPRMxx, see the discussion of the PROPLIST nad PROPERTY statements, in z/OS
| SDSF Operation and Customization, SA22-7670.

Set a default for the Initiators panel
Description: Starting with z/OS V1R12, SDSF shows WLM-managed initiators as
well as JES-managed initiators on the Initiators (INIT) panel. This may result in a
significantly greater number of rows than were previously shown. New
parameters, JES | WLM | ALL (ALL is the default), on the INIT command allow
users to specify which initiators should be displayed. However, system
programmers might want to set a custom property so that only JES-managed
initiators are shown by default.

Is the migration action required? Yes, if you have WLM-managed initiators but
want only JES-managed initiators to be
displayed on the INIT panel, by default, as in
previous releases.
requirements:
Restrictions: None.
check:

Steps to take: To set JES-managed initiators as the default for the INIT panel, set
| custom property Command.INIT.DefaultJESManage to TRUE in ISFPRMxx.

Reference information: For details about setting the custom property in
ISFPRMxx, see the discussion of the PROPLIST and PROPERTY statements in z/OS
SDSF Operation and Customization.

Set the format of device names on the Printers panel
Description: Starting with z/OS V1R12, SDSF shows device names on the Printers
(PR) panel in a longer format, with dots between subtypes. This could affect batch
programs or REXX execs that process the device names. The system programmer
can use a custom property to retain the shorter format that was used in previous
releases.



Is the migration action required? Yes, if you want device names on the PR
panel to be displayed in the shorter format,
as in previous releases.
requirements:
Restrictions: None.
check:

Steps to take: To use the short form of device names on the PR panel, set custom
property Panel.PR.DevNameAlwaysShort to TRUE in ISFPRMxx.

Reference information: For details about setting the custom property in
ISFPRMxx, see the discussion of the PROPLIST and PROPERTY statements in z/OS
SDSF Operation and Customization.

Update batch programs or REXX execs for changes to
message ISF770W
Description: Starting with z/OS V1R12, the text of message ISF770W has changed.
This might affect batch programs or REXX execs that depend on the message text.
The message is issued when the number of requests (system commands) exceeds a
limit set by a REXX special variable.

The text of the message changed from:

SYSTEM COMMAND LIMIT limit FROM VARIABLE name REACHED.
to
REQUEST LIMIT limit FROM VARIABLE name REACHED.

Is the migration action required? Yes, if you have batch programs or REXX
execs that depend on the text of message
ISF770W.
requirements:
Restrictions: None.
check:


Steps to take: Review batch programs or REXX execs for dependence on the text of
| message ISF770W, and make changes as necessary.

Reference information: For details about SDSF's batch and REXX support, see
z/OS SDSF Operation and Customization.

Set the view of the OPERLOG
Description: Starting with z/OS V1R12, SDSF sets the view to include only active
log data when displaying the OPERLOG. Before z/OS V1R12, SDSF included both
active and inactive log data. Inactive log data is data for which there has been a
delete request but which is still in the log stream. If you have SDSF batch
programs or local procedures that depend on the presence of inactive log data on
SDSF's OPERLOG panel, you might need to update them.

Is the migration action required? Yes, if you have batch programs or local
procedures that depend on the presence of
inactive log data on SDSF's OPERLOG panel.
requirements:
Restrictions: None.
check:

Steps to take: Review batch programs or local procedures for a dependence on the
presence of inactive log data on the OPERLOG panel, and make changes as
necessary. Alternatively, you can use the PROPLIST and PROPERTY statements in
ISFPRMxx to set custom property Log.Operlog.ViewAll to TRUE, to cause the
OPERLOG panel to continue to include inactive log data.

Reference information: For information about the OPERLOG panel, see SDSF's
online help. For details about SDSF's batch support and custom properties in
ISFPRMxx, see z/OS SDSF Operation and Customization. For details about active and
inactive log data, see z/OS MVS Programming: Assembler Services Guide.


Chapter 18. Security Server migration actions
Security Server actions to perform before installing Security Server actions to perform after the first
z/OS V1R13 . . . . . . . . . . . . . . 273 IPL of z/OS V1R13 . . . . . . . . . . . 277
| Normalize user names specified as X.500 Update database templates . . . . . . . . 277
| distinguished names in distributed identity | Normalize user names specified as X.500
| filters . . . . . . . . . . . . . . . 273 | distinguished names in distributed identity
| Steps to take: . . . . . . . . . . . 274 | filters . . . . . . . . . . . . . . . 278
Security Server actions to perform before the first Use new RACDCERT GENCERT and REKEY
IPL of z/OS V1R13 . . . . . . . . . . . 276 defaults for digital certificates . . . . . . . 278
Check for duplicate class names . . . . . . 276
| Normalize user names specified as X.500
| distinguished names in distributed identity
| filters . . . . . . . . . . . . . . . 277

This topic describes migration actions for optional feature Security Server.

Security Server actions to perform before installing z/OS V1R13
This topic describes Security Server migration actions that you can perform on
your current (old) system. You do not need the z/OS V1R13 level of code to make
these changes, and the changes do not require the z/OS V1R13 level of code to run
once they are made.

| Normalize user names specified as X.500 distinguished names
| in distributed identity filters
| Description: RACF provides distributed identity filters in support of z/OS identity
| propagation. Before z/OS V1R13, RACF removed leading and trailing blank
| characters before storing the user name value of a distributed identity filter when
| you specified the user name as an X.500 distinguished name (DN). Starting in
| z/OS V1R13, RACF normalizes the user name before storing it in the RACF
| database. The normalization process includes removing leading and trailing blank
| and null characters from each relative distinguished name (RDN) of the DN.
|
| Element or feature: Security Server.
| When change was introduced: z/OS V1R13, and rolled back to z/OS V1R12
| and z/OS V1R11 by APARs OA34259 and
| OA34258.
| PTFs for APARs OA34259 and OA34258
| applied.


|
| Timing: v Before installing z/OS V1R13 for
| determining if your installation has
| already defined any distributed identity
| filters. Go to “Before installing z/OS
| V1R13” in this migration action.
| v Before the first IPL of z/OS V1R13 for
| customizing and executing the sample
| REXX exec IRR34258. Go to “Before the
| first IPL of z/OS V1R13” on page 275 in
| this migration action.
| v After the first IPL of z/OS V1R13 for
| redefining a filter for an X.500 user
| identity. Go to “After the first IPL of z/OS
| V1R13” on page 275 in this migration
| action.
| Is the migration action required? Yes, if your installation specified an X.500
| DN as the user name of a distributed
| identity filter on a z/OS V1R12 or z/OS
| V1R11 system without the normalization
| function provided with APARs OA34259 and
| OA34258.
| Other system (coexistence or fallback) If your installation specified an X.500 DN as
| requirements: the user name of a distributed identity filter
| on a z/OS V1R12 or z/OS V1R11 system
| without the normalization function provided
| with APARs OA34259 and OA34258, the
| filter might not function properly in z/OS
| V1R13.
| check:
|

| Steps to take:
| Before installing z/OS V1R13: The following steps can be performed by the
| RACF security administrator or a RACF user with the SPECIAL attribute.
| 1. Determine whether your installation has already defined any distributed
| identity filters. To do this, issue the following RACF command to search for
| profiles in the IDIDMAP class. For details about the SEARCH command, see
| z/OS Security Server RACF Command Language Reference.
| SEARCH CLASS(IDIDMAP)
| If there are no profiles in the IDIDMAP class, your installation is unaffected by
| this change. Skip to step 7. No further migration actions for this change are
| required.
| 2. If you find profiles in the IDIDMAP class, discontinue defining distributed
| identity filters until after the first IPL of z/OS V1R13.
| 3. Execute the RACF database unload utility (IRRDBU00) to create a sequential
| file from a RACF database. For details about running IRRDBU00, see z/OS
| Security Server RACF Security Administrator's Guide.


Zos1.13 migration

More Related Content

What's hot (19)

Viewers also liked (10)

Similar to Zos1.13 migration (20)

More from satish090909 (8)

Recently uploaded (20)

Zos1.13 migration