MigratingTo_zOSR7_Part3

Abstract: Migrating to z/OS 1.7 Part 3 of 3 - GO!Want to know about the migration tasks for the latest and greatest z/OS release? This presentation discusses where themigration actions new for z/OS R7 will be covered with a focus on migrating from z/OS R4. Included will be requiredmigration tasks for z/OS R7 from selected elements - DFSMS, Language Environment, JES2, JES3, SMP/E, and z/OSUNIX. Also included are highlights of some enhancements you'll see in z/OS R7 for system programmers.

This presentationwill be of interest to systems programmers and their managers who are migrating to z/OS R7. It isstrongly recommended that you review 'Migrating to z/OS R7 Part 1 - Get Ready!' and ‘Migrating to z/OS R7 Part 2 - GetSet!” before reviewing this presentation.

The general availability date for z/OS Version 1 Release 7 was September 30, 2005.

Migrating to z/OS 1.7 Part 3 of 3 - GO!

(c) Copyright IBM Corporation, 2006 March 7, 2006Page 1 of 46

Migrating to z/OS 1.7:Migrating to z/OS 1.7:Part 3 of 3 - GO!Part 3 of 3 - GO!

Marna WALLEz/OS Build and Install

IBM Systems and Technology Group Poughkeepsie, New York

[email protected]

March 7, 2006 | Seattle, WA



3© 2006 IBM Corporation

Structure of Migrating to z/OS 1.7 PresentationsPart 1 of 3: Get Ready!

Hopefully, you reviewed this presentation. .

Part 2 of 3: Get Set!Hopefully, you reviewed this presentation. Especially understand the HCD IODF V5 migration action!

Part 3 of 3: GO!Migrations actions for z/OS R7 (with a focus on migrating from R4) from selected elements:

DFSMSJES2 and JES3Language EnvironmentSMP/E

z/OS UNIX

Also included are highlights of some enhancements you'll see in z/OS R7 for system programmers.

Migrating to z/OS 1.7: Part 3 of 3 - GO!

You

need

to re

view

all

3 pr

esen

tatio

ns to

get

a

com

plet

e m

igra

tion

pict

ure!



© 2006 IBM Corporation

4Migrating to z/OS 1.7 Part 3 of 3 - GO!

Migration ActionsElement Specific Migration Actions for z/OS R7 (from z/OS R4):

DFSMSJES2JES3Language EnvironmentSMP/EUNIX System Services

Installation Enhancements in z/OS R7Som z/OS R7 Enhancments for System Programmers

Summary

Migrating to z/OS 1.7 Part 3 of 3 - GO! Agenda


5© 2006 IBM CorporationMigrating to z/OS 1.7 Part 3 of 3 - GO!

Elements with Migration Actions from z/OS R4 to z/OS R7Documented in z/OS Migration

For complete migration tasks for z/OS R7, see this book!from R4 to R7, and R5 to R7, and R6 to R7"When behaviors aren't the same anymore, migration actions are called for."

From z/OS R4 to z/OS R7:BCP Communications Server Cryptographic ServicesDFSMSDFSORTHCDHLASMICKDSFInfoprint Server Integrated Security Services ISPF

means the migration actions were in the previous presentation and this one

Migration Actions that follow are divided by :ELEMENT, and then

WHEN you can do the action: Now, Pre-First IPL, or Post-First IPL

JES2JES3Language Environment Library ServerNFS (new!)OSA/SFRMFSDSF Security Server (RACF)SMP/E TSO/EXL C/C++z/OS UNIX System Services

Migration Actions for Elements Between z/OS V1 R4 and z/OS V1 R7When migrating from z/OS V1 R4 to z/OS V1 R7, the specified elements have required migration actions. Refer to z/OSMigration for complete information on the required migration actions for all elements. Selected element migration actionsfollow in this presentation, and the subsequent presentation.

Migration Actions for z9-109, z990, and z890 ServersFor details on the migration actions required when running on, or in a sysplex with a system or CF image on a z9-109,z990 or z890 server, refer to the z/OS Migration book.

MigrationDefinitions and ClassificationsImportant terms you should understand are:

Migration. Migration is the installation of a new version or release of a program to replace an earlier version orrelease. After a successful migration, the applications and resources on the new system function the same way (orsimilar to the way) they did on the old system. Migration does not include exploitation of new functions except for newfunctions that are now required, such as workload manager (WLM) goal mode, which became a requirement in z/OSV1R3 when compatibility mode was no longer supported. Coexistence. Coexistence is the situation in which two or more systems at different software levels resources. Theresources could be d at the same time by different systems in a multisystem configuration, or they could be d over aperiod of time by the same system in a single-system configuration. Examples of coexistence are two different JESreleases sharing a spool, two different service levels of DFSMSdfp™ sharing catalogs, multiple levels of SMP/Eprocessing SYSMODs packaged to exploit the latest enhancements, or an older level of the system using theupdated 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. Butother types of configurations can have resource sharing too. Examples of configurations where resource sharing canoccur are:– A single processor that is time-sliced to run different levels of the system, such as during different times of the day





What exactly is a z/OS "Migration Action"?

Migration is the installation of a new version or release of a program to replace an earlier version or release.

After a successful migration, the applications and resources on the new system function the same way they did on the old system, if possible. "System Equivalence"Migration does not include exploitation of new functions except for new functions that are now required to use.Migration actions are classified as:

Required: required for all usersRequired-IF: only required in certain casesRecommended: good to do because it 1) is good practice, 2) may be required in the future, 3) resolves performance or usability problem

Migration actions are also classified as when they may be performed:NOW, Pre-First IPL, or Post-First IPL

– 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 Sysplexconfigurations

The way in which you make it possible for earlier-level systems to coexist with the most current level is to installcoexistence and fallback PTFs on the earlier-level systems. Fallback. Fallback is a return to the prior level of a system. Fallback can be appropriate if you migrate to a newrelease and, during testing, encounter severe problems that can be resolved by backing out the new release. Byinstalling coexistence and fallback PTFs on the “old” system before you migrate, the old system can tolerate changesthat were made by the new system during testing. Exploitation. Exploitation is making productive use of new functions. Exploitation follows migration.

Migration Requirement Classification and TimingThe migration actions are classified as to their requirement status:

Required. The migration action is required in all cases. Required-IF. The migration action is required only in a certain case. Most of the migration actions in this presentationare in this category.Recommended. The migration action is not required but is recommended because it is a good programmingpractice, because it will be required in the future, or because it resolves unacceptable system behavior (such as poorusability or poor performance) even though resolution might require a change in behavior.

To identify the timing of migration actions, this presentation uses three types of headings: Now. These are migration actions that you perform on your current system, either because they require the currentsystem or because they are possible on the current system. You don’t need the z/OS V1R7 level of code to makethese changes, and the changes don’t require the z/OS V1R7 level of code to run once they are made. Examples areinstalling coexistence and fallback PTFs on your current system, discontinuing use of hardware or software that willno longer be supported, and starting to use existing functions that were optional on prior releases but required in z/OSV1R7. Pre-First IPL. These are migration actions that you perform after you’ve installed z/OS V1R7 but before the first timeyou IPL. These actions require the z/OS V1R7 level of code to be installed but don’t require it to be active. That is,you need the z/OS V1R7 programs, utilities, and samples in order to perform the migration actions, but the z/OSV1R7 system does not have to be IPLed in order for the programs to run. Examples are running sysplex utilities andupdating 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 whichyou will install z/OS V1R7 by making a clone of your old system, you can perform migration actions that involvecustomization data on this newly prepared system before installing z/OS V1R7 on it. Examples of such migrationactions are updating configuration files and updating automation scripts. Post-First IPL. These are migration actions that you can perform only after you’ve IPLed z/OS V1R7. You need arunning z/OS V1R7 system to perform these actions. An example is issuing RACF commands related to newfunctions. 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 V1R7 to be active to perform the task. You might perform the task quite a while afterthe first IPL.







DFSMS Migration Actions from z/OS R4 to z/OS R7

Migration Actions You Can Do NOW:Redefine existing VSAM data sets that contain the IMBED, REPLICATE, and KEYRANGE attributes (Recommended)Determine which VSAM data sets were allocated with IMBED, REPLICATE, or KEYRANGE by using tool IMBDSHIP.JCL.TRSD. Install the PTF for APAR OA10952. The PTF fixes the problem in which an exported copy of a VSAM data set that has the IMBED or REPLICATE attribute (or both) does not remove the attribute when the IMPORT is done

Schedule a time for the VSAM data sets to be unavailable, and redefine them.

Convert ISAM data sets and programs to VSAM (Required-IF, as of R7)R7 removes support for ISAM. Convert to VSAM data sets. ISAM programs can still use ISAM interface to VSAM.

Remove CATALOG parm from DEFINE PAGESPACE unless RECATALOG is specified (Required-IF, as of R7)

Ensure that the DFSMShsm journal is allocated correctly (Required, as of R7)Evaluate the need to increase DFSMSrmm control data set size (Required, as of R5 APAR)

Continued on next foil...



DFSMS Migration Actions from z/OS R4 to z/OS R7Migration Actions Pre-First IPL:

Ensure that the Language Environment run-time is available for DLLs (Required-IF)

SCEERUN and SCEERUN2 must be available to create or use DLLsBuild the IPLable stand-alone DFSMSdss image (Required-IF)

Use the BUILDSA command to create the Stand-Alone Services IPL-capable core image

Ensure SYS1.IMAGELIB is customized for your printing environment (Required-IF)

ServerPac delivers a new SYS1.IMAGELIB, and you may have had line mode printer information in your previous SYS1.IMAGELIB

Tune DFSMShsm for the secondary space management multiple tasks enhancement (Recommended, as of R6)

Among other things, determine the max number of SSM tasks that should be processed concurrently. Prior to z/OS V1R6, the default was 1. Now the default is 3.

Continued on next foil...

DFSMS Migration Actions Between z/OS R4 and z/OS R7These migration actions were taken from z/OS Migration. Some descriptions and actions have been shortened forinclusion in this presentation. For the complete descriptions and actions, refer to z/OS Migration.

DFSMS Migration Actions You Can Do Now

Redefine existing VSAM data sets that contain the IMBED, REPLICATE, and KEYRANGE attributes(Recommended)Recommended because it will become a requirement in a future release.No supported release of z/OS allows you to use the IMBED, REPLICATE, and KEYRANGE attributes for new VSAM datasets. In fact, using these attributes can waste DASD space and often degrades performance. Servicing these VSAM datasets has become increasingly difficult. In some cases, unplanned outages have occurred. To provide an environment inwhich outages are less likely, IBM has announced the removal of the support in existing VSAM data sets for the IMBED,REPLICATE, and KEYRANGE attributes. IMBED and REPLICATE were intended as performance improvements andhave been obsoleted by newer, cached DASD devices. Striped data sets should provide much better performance thanKEYRANGE and should be viewed as a candidate for any existing KEYRANGE data sets.Migration action: 1. Determine which VSAM data sets were defined with the IMBED, REPLICATE, or KEYRANGE attribute. To help you

perform this task, you can get a tool that reads existing VSAM data sets and reports which ones have theseattributes. The tool is available from the software server (ftp.software.ibm.com) in the s390/mvs/tools directory asIMBDSHIP.JCL.TRSD. Download the file in binary format and unterse it on your z/OS system using TRSMAIN.Instructions for using the tool are included in the downloaded JCL. See APAR II13894 for additional information.

2. Install the PTF for APAR OA10952. The PTF fixes the problem in which an exported copy of a VSAM data set thathas the IMBED or REPLICATE attribute (or both) does not remove the attribute when the IMPORT is done. Note thatthis change helps further remove, through normal processing, data sets that have the IMBED or REPLICATEattribute. The PTFs for APAR OA10952 are UA17230 for z/OS V1R6, UA17229 for z/OS V1R5, and UA17237 forz/OS V1R4. (APAR OA





DFSMS Migration Actions from z/OS R4 to z/OS R7

Migration Actions Pre-First IPL:Modify DFSMShsm ARCMDEXT and ARCMMEXT exit routines to handle data set processing (Required-IF, as of R5)Modify HQUERY REQUEST commands that don’t have request numbers (Required-IF, as of R5)

To determine all pending hsm requests for a userid use HQUERY , and not HQUERY REQUEST

Use catalog search order, instead of JOBCAT and STEPCAT (Required-IF, as of R7)In z/OS R7, JOBCAT and STEPCAT support has been removed. You can no longer enable or disable them.

Define RACF FACILITY class profiles for DFSMShsm (Required-IF, as of R5)If you have the RACF FACILITY class active, you must define the new profiles prior to starting DFSMShsm in z/OS R5. If you do not have the new profiles defined, every DFSMShsm command fails.

Make sure your VOLCAT is large enough to support 255 media types (Required-IF, as of R5)LIBRARYENTRY in the volume catalog (VOLCAT) has increased in size to accommodate 255 media types and recording technologies.

Convert the optical configuration database to z/OS R5 format (Required, as of R5)You must run the CBRSMR15 sample job to convert your optical configuration data base to z/OS R5 format. It adds two new columns to the DB2 TAPEVOL table.

Recompile exit ADRUIXIT or your UIM because the ADRUFO parm list increased (Required-IF, as of R5 and APARs)Length of ADRUFO parameter list has increased. Recompile installation exit ADRUIXIT or the UIM with the updated ADRUFO macro.

Migration Actions Post-First IPL:Ensure the integrity of SMS control data sets (Recommended)

Update, translate, validate, and activate SMS policies from a z/OS V1R7 system, when in a mixed-level sysplex

3. Schedule a time for the affected VSAM data sets to be unavailable, and redefine them.

Convert ISAM data sets and programs to VSAM (Required-IF, as of R7)Required if you have any ISAM data sets in use or programs that use ISAM.In z/OS V1R7, IBM removed most support for the indexed sequential access method (ISAM) and indexed sequential datasets. Users are no longer able to process (create, open, copy, or dump) ISAM data sets. Current ISAM data sets can stillexist, and users can display information about them and delete them. Before migrating to z/OS V1R7, any ISAM data setsstill in use should be copied or converted to VSAM data sets. Subject to existing restrictions, programs that use ISAM willcontinue to work using the ISAM interface to VSAM. Migration action: 1. Find out if you have ISAM data sets or programs that use ISAM:

For data sets: If you know your system has no ISAM data sets, you do not have to take migration steps. If you are notsure whether your system has ISAM data sets in use, you can take one of the following actions to find out:

Check for SYS1.ISAMLPA — if SYS1.ISAMLPA is not in your existing LPA concatenation or LINKLSTconcatenation, then programs are not using ISAM to access ISAM data sets (they could still be using the ISAMinterface to VSAM). Note: the system data set SYS1.ISAMLPA and the distribution library SYS1.AOSD8 nolonger exist in z/OS V1R7. If SYS1.ISAMLPA is in your LPA concatenation, you should remove it. This will saveyou about 177,528 bytes below the 16 MB line in LPA. Removing this will not affect programs that use the ISAMinterface to VSAM data sets. Use the DCOLLECT function of IDCAMS to search online volumes for a data set that has IS or ISU indicated forthe DSORG value. Check system logs for message IEC134I – starting in OS/390 V2R10, this message has been issued wheneverISAM data sets are opened, to warn that ISAM support is being discontinued.

For programs: To find programs that use ISAM services, do the following: Search for DSORG=IS in assembler source code and JCL. It appears on the DCB macro for BISAM and QISAMand on the DD statements. Search for equivalent statements in COBOL and PL/I programs. Then find the datasets used by these programs or JCL. It is possible that you have an assembler language program that uses certain internal IBM macros that are nolonger distributed. They were previously shipped in the SYS1.AMODGEN macro library. Their names, and anyalternatives to use, are: IGGDEBD, IGGIOBD, IEZIOB, IGGLDCP, IGGLOAD, IGGSCAN, IGGWKNCP. Look for any invocations of the IEBISAM utility program and remove them or ensure they are not used.

2. For ISAM data sets and the programs that use them, take one of the following actions before migrating to z/OS V1R7:Delete the data sets or programs if no longer needed. Copy the data to VSAM data sets and switch to using the ISAM interface to VSAM. Convert the programs and data sets to VSAM.

Remove the CATALOG parameter from DEFINE PAGESPACE commands unless RECATALOG is specified(Required-IF, as of R7)Required if you specified the CATALOG parameter on a DEFINE PAGESPACE command without the RECATALOG parameter.Before z/OS V1R7, it was possible to specify a catalog on the access method services command to define a new pagespace. However, IBM recommended against the use of this CATALOG parameter, since it could conflict with the allocatespecifications for the main page space data set. As of z/OS V1R7, the CATALOG parameter is no longer supported onthe AMS DEFINE PAGESPACE command, unless it is used together with the RECATALOG parameter. Commandsspecifying the CATALOG parameter without RECATALOG will fail with the message IDC3171I.Migration action: In jobs that issue the access method services DEFINE PAGESPACE command with the CATALOGparameter, delete the CATALOG parameter unless the RECATALOG parameter is also specified.

Ensure that the DFSMShsm journal is allocated correctly (Required, as of R7)The DFSMShsm journal data set must be allocated with the following attributes:

Single volume Single extent Contiguous space No secondary space allocation Non-striped



Before z/OS V1R7, definition of the attributes was not enforced by the DFSMShsm code, even though the attributes weredocumented in z/OS DFSMShsm Implementation and Customization Guide. Starting with z/OS V1R7, their definition isenforced by the code. Therefore, you should make sure that you’ve defined your journal data set correctly. Failure todefine the journal with the attributes above causes DFSMShsm to shut down. These attributes are required even if youuse a large format data set for the journal.

Evaluate the need to increase DFSMSrmm control data set size (Required, as of R5 APAR)As of z/OS V1R5, the required space for your DFSMSrmm control data set increases over time. This requirement foradditional space is caused by an increase in the size of the volume record caused by APAR OW56584 and extended binsupport when it is enabled. For example, each time a volume record is updated (such as during inventory management)or a new data set is written on a volume, the associated control data set volume records migrate to a new leveldynamically. This increases the size of the volume record by 64 bytes. When extended bin support is enabled, the size ofthe bin records also increases by 24 bytes if the move is to or from a bin-managed storage location. In addition, largercontrol data set records for volumes and bins require larger journal records. Migration action: Refer to the detailed steps in z/OS Migration for the migration action to perform.

DFSMS Migration Actions Pre-First IPL

Ensure that the Language Environment run-time library is available for DLLs (Required-IF)Required if your installation builds or references DLLs.Language Environment provides common services and language-specific routines in a single run-time environment. Youcan use Language Environment to build and use dynamic link libraries (DLLs) for applications.Migration action: If your installation builds or references DLLs, either you must set up the system link list to refer to theLanguage Environment run-time libraries (SCEERUN and SCEERUN2), or each job that creates or uses a DLL mustinclude a STEPLIB DD statement referencing these libraries.Reference information: z/OS DFSMS Migration, z/OS Language Environment Run-Time Migration Guide , z/OSLanguage Environment Customization, and z/OS Language Environment Programming Guide Build the IPLable stand-alone DFSMSdss image (Required-IF)Required if you intend to use the Stand-Alone Services provided by DFSMSdss.If you intend to use the Stand-Alone Services provided by DFSMSdss, you must use the DFSMSdss BUILDSA function tocreate the Stand-Alone Services IPL-capable core imageMigration action:1. Prepare for Stand-Alone Services by creating a Stand-Alone Services IPL-able core image with the BUILDSA

command. With the BUILDSA command you can specify the device (card reader, tape drive, or DASD volume) fromwhich Stand-Alone Services will be IPLed. You can also specify the operator console to be used for Stand-AloneServices. The BUILDSA function builds the IPL-able core image under the current operating system and determines arecord 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 theStand-Alone Services modules.

3. If you haven’t done so already, make a backup copy of your system that can be restored by this function. Forinformation about backing up volumes, see z/OS DFSMSdss Storage Administration Guide.

Reference information: z/OS DFSMS Migration and z/OS DFSMSdss Storage Administration Reference.Ensure your SYS1.IMAGELIB is customized for your printing environment (Required-IF)Required if you are not using your old SYS1.IMAGELIB, you are installing with ServerPac or SystemPac, and you areusing line mode printers such as the 3800 or 3900.If you use line mode printers such as the IBM 3800 or the IBM 3900 running in line mode (not page mode), you mustinstall library character sets, graphic character modification modules, and character arrangement tables inSYS1.IMAGELIB. This migration action does not apply if you are using IBM 3900 printers that are driven by PSF.Migration action:

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 thenew system's SYS1.IMAGELIB data set.

Reference information: z/OS DFSMS Migration.

Tune DFSMShsm for the SSM multiple tasks enhancement (Recommended, as of R6)



Recommended if you use secondary space management.The secondary space management (SSM) function is enhanced to run with multiple tasks in a single DFSMShsm host,allowing the function to complete more quickly. As a result of this enhancement, the following changes have been made, designed to improve performance, you might want to retune DFSMShsm because of them:

The default number of tasks for SSM has increased from one to three: two cleanup tasks and one tape movementtask. The default number of recall tasks has increased from 5 to 15 to aid in the processing of deletions that SSM initiates. Small data set packing (SDSP) data sets are no longer allocated for the entire SSM window. Deletion requests for expired migrated data sets are given a low priority so that user recalls and user-initiateddeletions are processed before SSM-generated deletions.

In addition, a new SETSYS parameter, MAXSSMTASKS, allows you to specify the number of SSM tasks that you want torun concurrently. Migration action:

Determine the maximum number of SSM tasks that should be processed concurrently. Prior to z/OS V1R6, thedefault was 1. Now the default is 3: two cleanup tasks and one tape movement task. You can set the maximum byusing the SETSYS MAXSSMTASKS command. Note that each SSM tape movement task requires two tape drives ifyou are using DUPLEXing for migration; this might affect the number of SSM tasks that you want to allow. Determine the maximum number of recall tasks that can be processed concurrently. Prior to z/OS V1R6, the defaultwas 5. Now the default is 15 to accommodate SSM deletion requests. You can set the maximum by using theSETSYS MAXRECALLTASKS command. If a DFSMShsm host will not be performing SSM, you will probably want toreduce the maximum number of recall tasks. Because SDSPs are no longer allocated for the entire SSM window, you might want to reconsider your SDSPreorganization procedures. Reconsider any procedures you have in place to reduce or eliminate user-initiated recalls or deletes during SSMprocessing because SSM-initiated deletes are processed only after all user-initiated recalls and deletes have beenprocessed. Determine the number of SDSP data sets that should be defined to your DFSMShsm system, now that the number ofSSM tasks has increased from one to three (or more). It is important to plan the number of SDSP data sets in relationto the number of concurrent migration tasks and the amount of processing performed by functions with a higherusage priority for the SDSP data sets.

Modify DFSMShsm ARCMDEXT and ARCMMEXT exit routines to handle data set processing(Required-IF, as of R5)Required if you use the ARCMDEXT or ARCMMEXT installation exit.z/OS V1R5, neither the ARCMDEXT nor the ARCMMEXT installation exits were called during command data setmigration. Beginning with z/OS V1R5, both are called for command data set migration, either via the HMIGRATEend-user command or the MIGRATE storage administrator command specified with the DATASETNAME parameter. TheARCMDEXT exit is called when migrating from Level0 DASD to either migration level (ML) 1 disk or ML2 tape or disk. TheARCMMEXT exit is called when migrating an already migrated data set to either ML1 disk, ML2 disk, or ML2 tape. You should modify your ARCMDEXT and ARCMMEXT exit routines to first determine why they are called (volumeprocessing or data set processing) and then perform the volume processing (as before) or data set processing (which isnew).

Modify HQUERY REQUEST commands that don't have request numbers (Required-IF, as of R5)Required if you use the HQUERY REQUEST command with no parameters.Previously, you could list all pending DFSMShsm requests for a particular user ID by specifying an HQUERY commandwith no parameters, or by specifying an HQUERY command with the REQUEST parameter but no request numbers. Forexample, the following command: HQUERY IBMWould yield the same result as this command: HQUERY REQUEST Starting with z/OS V1R5, only the HQUERY command (without parameters) lists all pending requests. The HQUERYREQUEST command fails and message ARC0165I is issued. This change is necessitated by the DFSMShsm RACFFACILITY class enhancement. Migration action: Remove the REQUEST parameter from any HQUERY commands that are used to obtain a list of allpending DFSMShsm requests for a particular user ID.



Use the catalog search order instead of JOBCAT and STEPCAT (Required-IF, as of R7)Required if you use the JOBCAT or STEPCAT facilities.As a first step toward removal of the DFSMSdfp JOBCAT and STEPCAT facilities, in z/OS V1R5 the JOBCAT andSTEPCAT DD statements were disabled by default, but you could still enable or disable them. Now, in z/OS V1R7, theyhave been removed and you can no longer enable or disable them. By way of background, the JOBCAT and STEPCAT facilities have been in existence for many years, predating theintroduction of ICF (integrated catalog facility) catalogs. JOBCAT and STEPCAT were designed to address some of thefunctional shortcomings of VSAM catalogs, such as:

VSAM volume ownership, that is, all data sets on a volume having to be in the same VSAM catalog. Multiple catalogscould not point to data sets on the same volume. Performance problems resulting from no multilevel alias support, as well as lack of ability to subset catalog data forrecovery purposes. Restrictions in the definition of the catalog SVC interface.

The introduction of ICF catalogs in the mid-1980s and other catalog enhancements (such as the multilevel alias support)directly addressed those problems. In addition, processes were developed for system build to use system specific aliasesinstead of JOBCAT or STEPCAT. CBIPO introduced these processes and they are used today by offerings such asServerPac to create data set entries in the new master catalog of the system being built. At the time ICF catalogs were introduced, the JOBCAT and STEPCAT facilities were functionally stabilized. NeitherSMS-managed data sets nor UCBs above the 16 megabyte line may be used with JOBCAT or STEPCAT. ICF catalogscontain sufficient functional capabilities that all functions that previously could only be performed with JOBCAT orSTEPCAT can now be done without them. Furthermore, the use of JOBCAT and STEPCAT can actually cause significant problems. Data sets are generally notcataloged according to the normal predictable search order when JOBCAT or STEPCAT is used. This impacts the abilityto do comprehensive installation storage management and can increase staff requirements. For example, intervalmigration and recall using DFSMShsm is effectively unusable when the data sets cannot be found using the standardcatalog search order. The use of JOBCAT and STEPCAT can also result in noticeable increases in the time required toperform catalog requests.Migration action: Change the jobs that use JOBCAT and STEPCAT to use the normal catalog search order, asdescribed in z/OS DFSMS Access Method Services for Catalogs.

Define RACF FACILITY class profiles for DFSMShsm (Required-IF, as of R5)Required if the RACF FACILITY class is active.z/OS V1R5, the DFSMShsm RACF FACILITY class enhancement provides a way to protect all DFSMShsm commandaccess through the use of RACF FACILITY class profiles. An active RACF FACILITY class establishes the securityenvironment. An active RACF FACILITY class means that DFSMShsm uses RACF protection for all commands instead ofusing only simple AUTH command protection. If the RACF FACILITY class is active, DFSMShsm uses RACF FACILITY class checking. If you have not defined the newprofiles, every DFSMShsm command fails.Migration action: If you have the RACF FACILITY class active, you must define the new profiles prior to startingDFSMShsm V1R5. If the new profiles are not defined, all storage administrator commands and user commands fail.Inform users that they can no longer use the following DFSMShsm commands. They must use the equivalent commandswith the “H” prefix. OLD Command NEW CommandQUERY HQUERYCANCEL HCANCELBDELETE HBDELETEALTERDS HALTERDSPerform the following steps to define new profiles for access to DFSMShsm commands. These profiles provideDFSMShsm users and storage administrators the equivalent access to DFSMShsm commands that they had beforeinstalling z/OS V1R5: 1. To allow all users to access all user commands, define a generic profile of STGADMIN.ARC.ENDUSER.* with a

default access of READ. For example: RDEFINE FACILITY STGADMIN.ARC.ENDUSER.* UACC(READ). 2. To prevent all users from issuing storage administrator commands, define a generic profile of STGADMIN.ARC.* with

a default access of NONE. For example: RDEFINE FACILITY STGADMIN.ARC.* UACC(NONE).



3. To permit storage administrators to issue all DFSMShsm storage administrator commands, use the RACF PERMITcommand. For example: PERMIT STGADMIN.ARC.* CLASS(FACILITY) USER(userid) ACCESS(READ).

Reference information: For an outline of the steps for implementing RACF FACILITY classes for DFSMShsmcommands, see z/OS DFSMS Migration. For greater detail, see z/OS DFSMShsm Implementation and Customization Guide. For a discussion of the changes to the DFSMShsm commands, see z/OS DFSMShsm Managing Your Own Data.

Make sure your VOLCAT is large enough to support 255 media types (Required-IF, as of R5)Required if you use more than four media types or more than five recording technologies.When the system-managed tape library was originally designed, it supported up to eight media types and 15 recordingtechnologies. Four of the eight media types (MEDIA1/CST, MEDIA2/ECCST, MEDIA3/HPCT, and MEDIA4/EHPCT) andfive of the 15 recording technologies (18-TRACK, 36-TRACK, 128-TRACK, 256-TRACK, and 384-TRACK) are usedtoday. As of z/OS V1R5, the tape library supports 255 media types and recording technologies to allow you to easily useadditional media types and recording technologies as they become available. As a result of this change, the LIBRARYENTRY in the volume catalog (VOLCAT) has increased in size. You shouldexamine the size of your volume catalog to ensure that it is large enough to hold your catalog records.Migration action: Determine whether you have free space in the catalog and have secondary allocation defined for thevolume catalog. In most cases, there should be room in your existing volume catalog to accommodate the expandedlibrary record length, which has grown by 1976 bytes.Note: The first time (and first time only) that a specific LIBRARYENTRY is updated (for any reason), the length of therecord is changed to the new length.Review any DFSMShsm PATCH commands that patch the YGCB control block. Two offsets have changed. If you arepatching the following two YGCB areas, you need to update your PATCH commands:

The reuse capacity table for migration tapes has moved from YGCB.+2C to YGCB.+1EC. The reuse capacity for backup tapes has moved from YGCB.+6C to YGCB.+22C.

Convert the optical configuration database to z/OS R5 format (Required, as of R5)In z/OS V1R5, an Object Access Method (OAM) object enhancement allows OAM to expire object tape volumes and toexpire tape and optical volumes that belong to object backup storage groups. This enhancement significantly reduces theamount of private storage that the OAM address space uses at larger installations. Even if you don’t take advantage of this enhancement, you must run the CBRSMR15 samplib job to convert the opticalconfiguration database to z/OS V1R5 format.Migration action: Run the CBRSMR15 job in SYS1.SAMPLIB to add two new columns, OUNITNAM and DATACLAS,to the DB2 TAPEVOL table. If you will retain expired tape volumes in their original storage group, or release expired volumes to MVS scratch, then it isappropriate to leave the OUNITNAM and DATACLAS names blank. However, in order for object tape volumes introducedinto the OAM inventory prior to z/OS V1R5 to be eligible for reuse when they are returned to OAM scratch status, youmust either manually update their OUNITNAM and DATACLAS fields in the TAPEVOL table or, if appropriate, enableSETOAM OAMSCRATCHSYNCH mode in the CBROAMxx PARMLIB member. Reference information: For information about synchronizing OAM scratch tapes, see z/OS DFSMS OAM Planning,Installation, and Storage Administration Guide for Object Support.

Recompile exit ADRUIXIT or your UIM because the ADRUFO parm list increased (Required-IF, as of R6and rolled back in APARs)Required if your user exit ADRUIXIT or UIM is sensitive to ADRUFO length changes.The length of the ADRUFO parameter list has increased to support new functions. You might have to recompileinstallation exit ADRUIXIT or the user interaction module (UIM) with the updated ADRUFO macro. Migration action: If you use installation exit ADRUIXIT or invoke DFSMSdss with an application program, perform thefollowing steps: 1. If you use ADRUIXIT to change installation options with the ADRUFO parameter list, review the updated ADRUFO

macro to determine if you need to recompile and link-edit installation exit ADRUXIT using the z/OS V1R5 macrolibraries. UFOFUNCT and UFOPARM sizes have increased. New keyword indicators are added and the existingUFOT0IND is changed to UFO4FLGS.

2. If you invoke DFSMSdss using the API and change options with the ADRUFO parameter list on EIOPTION 13, reviewthe updated ADRUFO macro to determine if you need to recompile and link-edit your user interaction module (UIM)using the z/OS V1R5 macro libraries. The increased UFOFUNCT and UFOPARM lengths and changes to some fieldsin the ADRUFO parameter list might affect the UIM.



Reference information: For details about DFSMSdss application programming interfaces and EIOPTION 13, see z/OSDFSMSdss Storage Administration Reference. For ADRUFO mapping, see z/OS DFSMS Installation Exits.

DFSMS Migration Actions Post-First IPLEnsure the integrity of SMS control data sets (Recommended)Recommended when using SMS in a mixed-level sysplex.In a multisystem Storage Management Subsystem (SMS) complex, operating systems a common set of SMS classes,groups, ACS routines, and a configuration base, which make up the storage management policy for the complex. Thisstorage management policy is maintained in a source control data set (SCDS). When this policy is activated for SMS, thebound policy is maintained in processor storage and on DASD in an active control data set (ACDS). Systems in thecomplex communicate SMS information through a common communications data set (COMMDS). It is strongly recommended that to successfully SMS control data sets in a multisystem environment where there aremixed levels of DFSMS, you update, translate, validate, and activate SMS policies on the system with the latest level ofDFSMS. If you do not translate your ACS routines and validate your SCDS on the latest level of DFSMS, the translationand validation might fail. This failure occurs because some constructs and definitions are known only to later levels ofDFSMS. It can also occur due to changes in validation rules between releases. Once the control data sets are formattedby the later-level system, the SMS control blocks reflect the new rather than the back-level lengths and controlinformation.Migration action: 1. Install all coexistence PTFs, which you can find in the z/OS Migration book, or in the presentation "Migrating to z/OS

1.7 Part 1 ot 3 - Get Ready" .2. Save the active ACDS as an SCDS with the SETSMS SAVESCDS command. 3. Update, translate, validate, and activate SMS policies using a z/OS V1R7 system. Remember, once you’ve translated

using a z/OS V1R7 system, you risk failure if you update and translate using a back-level system.







JES2 Migration Actions from z/OS R4 to z/OS R7Migration Actions You Can Do NOW:

Update automation that displays certain characteristics of post-execution jobs (Required-IF, as of R5/R6)Previously, you could modify ($TJ) or display ($DJ) characteristics of a post-execution job even though they didn't apply in a post-execution environment. Now, you cannot display SRVCLASS, SCHENV, SCHENV_AFF, and SECLABEL_AFF for jobs that are post-execution. These values are no longer maintained.

Review automation that handles msg $HASP621 for ***** if number of work elements in a class exceeds 99999 (Required-IF, as of R7 and rolled back)

Migrate to z2 mode (Required-IF, as of R7)Compatibility mode (R4) has been removed in z/OS R7.Before $ACTIVATE,LEVEL=z2 is done, analyze exit routines, how your system processess control block changes, job numbers, and macro services.

Migration Actions Pre-First IPL:Modify SAPI applications that set SSS2DUPJ (Required-IF, as of R7 and rolled back)

Remove the RELADDR= parm from SPOOLDEF initialization statements (Required-IF, as of R7)

Update JES2 exit routines due to the z/OS R7 structure changes (Required-IF, as of R7)Update automation and procedures because of changed input processing (Required-IF, as of R7)

Adjust debugging procedures because SVC 111 is no longer used for PUTs to an internal reader (Required-IF, as of R7)Correctly process ENF58 records for SYSOUT checkpoints (Required-IF, as of R5/R6)Update exit 34 to support PSO unallocation flagging (Required-IF, as of R5/R6)

Update exit routnes to recognize null service class for WLM processing (Required-IF, as of R5/R6)

Migration Actions Post-First IPLRemove the RDINUM= parameter from INTRDR iniatization statements (Recommended, as of R7)



JES2 Migration Actions from z/OS R4 to z/OS R7

Update JES2 exit routines due to the z/OS R7 structure changes (Required-IF, as of R7)

Some NJE and input service functions were moved from the JES2 AS to the application AS. Results in improved performance, reliability, failure isolation, and outage avoidance. This can break processing done by the following JES2 exits:

Exits 2, 3, 4, 7, 20, 39, 46, and 47 are not called for INTRDRs and NJE/TCP processing. Exit 8 is now called for INTRDR and NJE/TCP processing. Exits 36 and 37 now get control in a different address space for INTRDR and NJE/TCP processing. These are pre-SAF and post-SAF exits.Exit 13 has been deleted. Exit 49 has new function and is being called for $S J commands. Exit 40 can now be used to control NJE mail notification (function that was in exit 13). The input to exits 2, 3, 4, 20, 46, and 47 has changed significantly.

Read "JES2 z/OS 1.7 Exit Migration Guide" on web for important information!http://www.ibm.com/servers/eserver/zseries/zos/installation/zos17_jes2_migration.html




12© 2006 IBM CorporationMiMigrating to z/OS 1.7 Part 3 of 3 - GO!


Update procedures because of changed input processing (Required-IF, as of R7)Input processing was rewritten, thus this change may affect your applications and procedures.

JCL/JECL processing: more details on errors, parsing of operands conforms to standard JCL rules (some previous errors may now run correctly)SYSIN data processing: SYSIN ds properly handles carriage cntl, var recfm, and SYSIN up to 32KB long. Jobs that work on z/OS R7 may fail in prior releases. Submitted jobs from R7 will exec correctly w/ a mixed-level MAS.Internal reader processing in requestor AS: Moved from JES2 AS to AS that allocated the internal reader. Higher CPU and IO now associated with the owning AS. Processing occurs at dispatching priority of the requestor and not JES2's priority, thus lower priority AS may not submit jobs as fast as higher priority AS.Buffer of data in internal readers: Now, job cards are processed as soon as they are passed to the internal reader. No buffering of data, and the internal reader data space no longer exits.Internal reader messages in JOB log: Input processing msgs are issued in the submitting AS and placed in the JOB log (JESMSGLG) of the submitting AS. Increases size of the JOB log. May want to spin or suppress the JOB log.Internal reader processing when JES2 AS fails: JES2 AS used to discard job on an internal reader when JES2 AS abnormally terminated. Now, JES2 tries to retain jobs that are active on an internal reader when JES2 terminates.


13© 2006 IBM CorporationMiMigrating to z/OS 1.7 Part 3 of 3 - GO!


Some approaches for z/OS R7 JES2 exit changes:"Minimum alteration" - determine what is needed to migrate existing exits to new environment wih minimum changes to the logic and code.

In most cases, this can be done."Equivalent function" - determine what exit logic is doing and evaluate what is needed to accomplish the same function in the new exits.

May result in simplier exit logic that is less error prone.

However, may require a larger up-front design effort.

Some options for the z/OS R7 JES2 migration changes:JES2 exit assessment offering in the U.S. by IBM Global Services

Priced service.Can also help with getting to Z2 mode.

http://www.ibm.com/servers/eserver/zseries/zos/support/jes2_exits_offering.html

"Staging" JES2 on your z/OS R7 system.You can run z/OS R4 JES2 and z/OS R5/R6 JES2 on z/OS R7.

JES2 Migration Actions Between z/OS R4 and z/OS R7These migration actions were taken from z/OS Migration. Some descriptions and actions have been shortened forinclusion in this presentation. For the complete descriptions and actions, refer to z/OS Migration.

JES2 Migration Actions You Can Do Now

Update automation that displays certain characteristics of post-execution jobs (Required-IF, as ofR5/R6)Required if you use automation to modify or display SRVCLASS, SCHENV, SCHENV_AFF, or SECLABEL_AFF for jobsthat are post-execution.Prior to z/OS V1R5, you could modify (using a $TJ command) or display (using a $DJ command) characteristics of apost-execution job even though those characteristics did not apply in a post-execution environment. As of z/OS V1R5,you cannot display SRVCLASS, SCHENV, SCHENV_AFF, and SECLABEL_AFF for jobs that are post-execution,because JES2 does not maintain these values for jobs once they complete execution.Migration action: It is possible that operators or automation scripts might attempt to issue a command to modify a rangeof jobs (or use some filter) that includes jobs that are already in post-execution processing. Educate your operations staffabout this change and review and change automation scripts that issue $Djob and $Tjob commands that attempt to setSRVCLASS= or SCHENV= for post-execution jobs.Reference information: For information about using the $Djob and $Tjob commands used by operators and automationscripts, see z/OS JES2 Commands.

Review automation that handles message $HASP621 (Required-IF, as of R7 and rolled back viaOA08768) Required if you have automation routines that examine message $HASP621.Message $HASP621 displays the number of work elements in a class. Before z/OS V1R7 JES2, if the number exceeded99999, an incorrect value was displayed. As of z/OS V1R7 JES2, if the number exceeds 99999, ***** is displayed. Besure that your automation can handle the new display.In z/OS R7, the format of the command is: OUT R=........... CLASS class= nnnnn,... where class=nnnnn,... are the classes and thenumber of work elements in each class. Note: If the number of work elements exceeds 99999 then ***** will display.Migration action: Review automation routines that handle message $HASP621 to make sure they can handle ***** forthe number of work elements, and update any routines that can’t handle *****.

Migrate to z2 mode (Required-IF, as of R7)Required if you use R4 mode.Before z/OS V1R7, JES2 could operate in either of two modes, as specified on the $ACTIVATE command: compatibility(R4) mode and full function (z2) mode. As of z/OS V1R7, JES2 can operate only in z2 mode; R4 mode is withdrawn. z2mode enables larger limits for jobs, output elements, trackgroup space, and job number range, and intended to improvetrackgroup usage tracking. You must migrate to z2 mode before IPLing z/OS V1R7 JES2. Do not activate z2 mode until allsystems in the MAS are at z/OS V1R2 or later JES2.Migration action: In preparing for your migration to JES2 z2 mode, analyze the following:

Exit routines and unique code that would be affected by activating JES2 in z2 mode. If your exit routines use JQE orJOE chaining fields, or reference job number fields, then z2 mode changes require you to update the exit routines.Field names have been changed to help identify where logic changes are needed. You might want to enable your exit routines to support both R4 and z2 modes to facilitate migration. If your exitroutines must support systems running in both modes, be aware that fields within control blocks such as the JQE aremode sensitive. For example in R4 mode, use JQEJOBNO_R4 for the job number in a real JQE; in z2 mode, useJQEJBNUM for the job number. However if you are referencing the job number in a JQA (artificial JQE), useJQEJBNUM. How your JES2 system processes the JOE, JQE, JQA, and JOT control blocks that are significantly changed in z2mode. Control blocks and fields used to store job numbers (such as the $SJB, $JIB, $FSAXB, and $COMWORK). How you use the following JES2 macro services:

$QJQE and $#JOE: These macros process the JQE and JOE control block chains using proper chaining fieldsbased on the current checkpoint processing mode (either R4 mode or z2 mode). Therefore, users of thesemacros do not have to be sensitive to which JES2 processing mode is currently being used. $#JOE is changed toprocess chains (such as the CHAR JOE chain). Both $QJQE and $#JOE have improved their loop control andhave usability enhancements.



$DOGJQE: The JQA returned by $DOGJQE always reflects the z2 mode processing format. Code that processesan artificial JQE (JQA) need not examine the JES2 processing mode (z2 mode or R4 mode) to examine JQAfields. $JQEJNUM: $JQEJNUM is a new macro used to obtain the binary job number for a particular JQE. This macrooperates in z2 mode and R4 mode and processes the JQA or JQE that is passed. $JBIDBLD: This macro converts a binary job number to a printable job ID. $JBIDBLD is updated to accept a JQE(or JQA) as input and operates in z2 mode or R4 mode. $JBIDBLD formats the job ID, in the correct way, basedon the current job number range.

Your changes made to support JES2 in R4 mode, to ensure that they are compatible with z2 mode.

After your analysis is complete, perform the following tasks as appropriate for your installation: Convert any locally-developed code to use the new fields and field names. Process JOE and job queue element (JQE) control blocks as much as possible with the macros provided ($QJQE,$#JOE, $DOGJQE, $JQEJNUM, $JBIDBLD) instead of writing and using your own code. Ensure that all the field and control block changes identified with z/OS V1R2 JES2 are incorporated, includingupdates to the surrounding logic.

You can use the $ACTIVATE command ($ACTIVATE,LEVEL=R4) to revert to R4 mode from z2 mode. Beforedeactivating z2 mode, z/OS checks that no features exploiting z2 mode are active. If functions are exploiting z2 mode, the$ACTIVATE,LEVEL=R4 command fails with message HASP445. By default, JES2 restarts in the same mode (R4 or z2)as other members of the MAS (if any are active) or the mode the last active JES2 member was in when it came down. Torestart JES2 in R4 mode, specify UNACT on PARM=. Note: As of z/OS V1R7 JES2, the $ACTIVATE command has been deleted.

JES2 Migration Actions Pre-First IPLModify SAPI applications that set SSS2DUPJ (Required-IF, as of R7 and rolled back via OA04745)Required if you have SAPI applications that select sysout data sets by specific job namde and sett SSS2DUPJ.SAPI applications that select sysout data sets by specific job name and set SSS2DUPJ now work differently. Before z/OSV1R7, without the PTF for APAR OA04747 installed, if two jobs in the system matched the name specified in SSS2JOBNand one of them had sysout data sets destined for another node, SSS2DUPJ was not set. As of z/OS V1R7, if two jobs inthe system match the name specified in SSS2JOBN and one of them has sysout data sets destined for another node,SSS2DUPJ is set.Migration action: Modify any applications that are affected by the change in processing.

Remove the RELADDR= parameter from SPOOLDEF initialization statements (Required-IF, as of R7)Required if SPOOLDEF RELADDR= is set to NEVER.z/OS V1R2 (and rolled back to OS/390 V2R10 by an APAR), JES2 added initial support for large SPOOL volumes byallowing you to place a SPOOL data set anywhere on a volume, with the size of the SPOOL data set limited to 64Ktracks. Also in z/OS V1R2, the keyword RELADDR= was added to the SPOOLDEF initialization statement to specifyrelative track addressing. Because older releases did not support relative track addressing, this keyword specified thatrelative addressing was allowed when a new SPOOL volume was started.In z/OS V1R7, JES2 introduces support for SPOOL volumes greater than 64K tracks. Because of this larger SPOOLvolume support and because compatibility with older releases is no longer an issue, the RELADDR= keyword is no longersupported and you should discontinue using it. All new SPOOL volumes started in z/OS V1R7 use relative trackaddressing.Migration action: Remove RELADDR= from the SPOOLDEF initialization statement in your z/OS V1R7 initializationdeck. If you don’t remove it, RELADDR=ALWAYS or RELADDR=ASNEEDED is ignored, but RELADDR=NEVER resultsin an invalid statement error and the entire SPOOLDEF statement is not processed. Specify SPOOLDEF RELADDR=ALWAYS on pre-z/OS V1R7 members that SPOOL with z/OS V1R7 by updating theirinitialization decks and by issuing the command $TSPOOLDEF,RELADDR=ALWAYS on one pre-z/OS V1R7 MASmember. z/OS V1R7 JES2 continues to support existing SPOOL volumes that use absolute track addressing. No changes to yourexisting SPOOL volumes are needed. Only new volumes that are started by a z/OS V1R7 JES2 are affected by removalof support for the RELADDR= keyword.

Update JES2 exit routines because of z/OS V1R7 structure changes (Required-IF, as of R7)



Required if you use any of the affected JES2 exits.In z/OS V1R7 JES2, some NJE and input service functions were moved from the JES2 address space to applicationaddress spaces. This was done to improve performance and reliability as well as reduce system outages. In particular,the new NJE over TCP/IP (NJE/TCP) function and existing internal reader (INTRDR) processing now occur outside theJES2 address space. This can break processing done by the following JES2 exit routines: 2, 3, 4, 7, 8, 13, 20, 36, 37, 39,40, 46, 47, and 49. The specific changes are:

Exits 2, 3, 4, 7, 20, 39, 46, and 47 are not called for INTRDRs and NJE/TCP processing. Exit 8 is now called for INTRDR and NJE/TCP processing. Exits 36 and 37 now get control in a different address space for INTRDR and NJE/TCP processing. Exit 13 has been deleted. Exit 49 has new function and is being called for $S J commands. Exit 40 can now be used to control NJE mail notification (function that was in exit 13). The input to exits 2, 3, 4, 20, 46, and 47 has changed significantly.

If you are using any of these changed exits, examine your routines and modify them if necessary.Migration action: Modify your exit routines to take into account the changes above. See z/OS JES2 Installation Exits fordetails about the functions and interfaces of the changed exits. Some services have been added to z/OS V1R7 JES2 to help you rework your exit routines to support the newenvironment. The services are a new USER,ANY environment, local $JCT extensions, $BLDMSG and $SCAN support,table pair enhancements, and multiple exit 0s. These services are discussed in z/OS JES2 Macros and z/OS JES2Installation Exits.Tip: An excellent reference that contains important information is available from this website: http://www.ibm.com/servers/eserver/zseries/zos/installation/zos17_jes2_migration.html. Read the “JES2 z/OS 1.7 ExitMigration Guide”. This website also contains other helpful information available from the z/OS JES2 development teamto assist you in performing the z/OS R7 JES2 migration actions.

Update automation and procedures because of changed input processing (Required-IF, as of R7)Required if any of the changes impact your local procedures.z/OS V1R7 JES2, input processing was rewritten to support NJE over TCP/IP and internal reader changes. If any of yourapplications are affected by the changed processing, you have to modify them. The changes are:

JCL/JECL processing: In previous releases, error messages for erroneous statements simply stated that thestatement was incorrect (for example, HASP112 jobname -- INVALID /*JOBPARM CARD). In z/OS V1R7 JES2, thesemessages include details about the operand in error (for example, HASP112 jobname -- INVALID /*JOBPARM CARD -VALUE OF CARDS= EXCEEDS 99999999). You might need to update processing that examines error messages. In z/OS V1R7 JES2, the parsing of operands has been modified to conform to standard JCL rules. Some JCL thatwould result in errors in earlier releases now runs correctly. For example, SECLABEL=’SYSHIGH’ is allowed in z/OSV1R7 but is not processed correctly in previous releases. Pre-z/OS V1R7 JES2 code does not support the use ofapostrophes with SECLABEL. Because of this, be careful when developing JCL in z/OS V1R7 JES2 that is to be runon previous releases. Test JCL on the target release to ensure that it is processed correctly. SYSIN data processing: In z/OS V1R7 JES2, the processing of SYSIN data sets has been updated to properly handlecarriage control, variable record formats, and SYSIN records up to 32 KB in length. Because of this, job streams thatwork in z/OS V1R7 might fail in prior releases of JES2. However, jobs submitted on z/OS V1R7 will run correctly onother MAS members, even if the member they run on is pre-z/OS V1R7. Internal reader processing in requestor address space: In z/OS V1R7 JES2, internal reader processing has been movedfrom the JES2 address space to the address space that allocated the internal reader. This was done to allow multiplejob streams to be processed in parallel and to improve error isolation. However, because the processing is now in theowner address space, CPU and I/O activity that was previously associated with the JES2 address space is nowassociated with the owning address space. In addition, because the processing occurs in the address space thatowns the internal reader, the processing occurs at the dispatching priority of the requestor instead of JES2’s priority.Thus, in a busy system, low priority address spaces are not able to submit jobs as fast as higher priority addressspaces. Buffering of data in internal readers: Before z/OS V1R7 JES2, jobs submitted to an internal reader were buffered in 8KB buffers in a data space. The buffers were not processed until the internal reader was closed, an ENDREQ wasissued, or a /*EOF or /*DEL card was processed. In z/OS V1R7 JES2, the cards are processed as soon as they arepassed to the internal reader. There is no buffering of data and the internal reader data space no longer exists.



Internal reader messages in JOB log: In z/OS V1R7 JES2, internal reader processing has been moved to thesubmitting address space. This causes input processing messages (such as $HASP100) to be issued in thesubmitting address space and to be placed in the JOB log (JESMSGLG) of the submitting address space. This isuseful for verifying the status of jobs that are submitted. However, it can increase the size of the JOB log, especiallyfor address spaces that submit a significant number of jobs. If the size of the JOB log becomes a concern, considerusing the JESLOG JOB card parameter to spin or suppress the JOB log data set.Internal reader processing when JES2 address space fails: Before z/OS V1R7 JES2, JES2 discarded any job that wason an internal reader when the JES2 address space abnormally terminated. With z/OS V1R7 JES2, JES2 attempts toretain jobs that are active on an internal reader when JES2 terminates. However, in some cases, JES2 still discards ajob because of lost checkpoint updates.

Migration action: Review your automation and procedures, and update them as needed based on the changesdiscussed above.

Adjust debugging procedures because SVC 111 is no longer used for PUTs to an internal reader(Required-IF, as of R7)Required if you debug problems using system trace.In z/OS V1R7, many uses of SVC 111 were converted to stacking Program Call (PC) instructions. As a result, when youdebug problems related to internal readers, you must look for the JES2 PC trace entries rather than SVC 111 traceentries to understand what JES2 is doing.Migration action: Evaluate your debugging procedures for the system trace impacts.

Correctly process ENF58 records for SYSOUT checkpoints (Required-IF, as of R5/R6)Required if you have applications that process all ENF58 records (with no qualifier).In releases prior to z/OS V1R5, JES2 generates an ENF 58 record as SYSOUT data sets allocated with a client token areprocessed. This allows an application to track the progress of a SYSOUT data set as it is processed. However, once adata set starts printing, there are no status updates until the printing has completed. There is no indication of progress (orlack of progress) while the data set is printing. To address this deficiency in ability to track progress, JES2 is updated to generate an ENF 58 record whenever aSYSOUT data set is checkpointed. A new qualifier is used on this ENF record. The rate at which these ENF records areissued is determined by the checkpoint interval on the printer that is processing the SYSOUT data set.Migration action: 1. Review your frequency of checkpointing based on the addition of ENF58 record generation. You might find that

updates to the PRTnnnn checkpoint parameters are appropriate for better system tuning. Frequent checkpoints canslow down printing and increase system overhead. A balance needs to be achieved between the overhead of printerstaking a checkpoint and the currency of information displayed by applications listening to ENF 58.

2. If you have an application that listens for ENF 58 record generation, review that code and consider updating it to becertain to process this new qualifier correctly. Correctly structured code should not need updating; however, considerthe following code scenario: a. There were 10 possible qualifiers for ENF58 when the exit was written. b. Code that listens to ENF58 tests for the first nine qualifiers explicitly. c. If not one of the first nine, the code assumes that the qualifier is the 10th. d. Now that a new qualifier is added (number 11 for “checkpoint issued”), this same code would mistakenly assume

that qualifier 11 (not one of the nine explicitly tested) is qualifier 10 (the one not explicitly tested but assumedabove).

Your quick review of any ENF58 installation-provided processing code you now have might prove useful.

Update exit 34 to support PSO unallocation flagging (Required-IF, as of R5/R6)Required if you use JES2 exit 34. JES2 exit 34 (subsystem interface data set unallocation), decimal offset 16 of register 1 contains the address of aperipheral data definition block (PDDB). Previously this address could be set to zero only if the data set type is a regularinternal reader or an unknown data set type. It is now also set to zero if a Process SYSOUT Work Area (PSO)unallocation was performed after the job step TCB ended. Migration action: Examine your exit 34 code to ensure that the potential zero address for PSO unallocation can beprocessed correctly.



Reference information: For information about coding an exit 34 routine to affect the subsystem interface data setunallocation, see z/OS JES2 Installation Exits.

Update exit routines to recognize null service class for WLM processing (Required-IF)Required if you are using WLM-managed initiators (that is, if you specify MODE=WLM on any JOBCLASS(x) statements).z/OS uses the default workload manager (WLM) policy when z/OS is started without a WLM couple data set or if there isa problem or error when accessing the current policy in the WLM couple data set. The default WLM policy assigns a nullservice class (SRVCLASS= on a $Djob command) to all jobs. Previously, batch jobs in a WLM-managed job class thatwere assigned a null service class would not be selected for execution. Now these jobs are eligible for execution. Migration action: Update exit routines and automation code to recognize a null service class as valid for jobs awaitingexecution and in execution. This change implies that WLM-managed initiators will now select jobs with a null serviceclass. This could impact data that is presented through SMF and information passed in various data areas. You shouldexamine code that uses service classes to ensure that it properly handles a null or blank value. Reference information: For information about coding exit routines, see z/OS JES2 Installation Exits

JES2 Migration Actions Post-First IPLRemove the RDINUM= parameter from INTRDR initialization statements (Recommended, as of R7)Not required, but recommended to avoid confusion in the future.z/OS V1R7 JES2, internal reader processing was updated to move processing from the JES2 address space to theaddress space that allocates the internal reader. With this change, the table of internal readers that was maintained inECSA is no longer required. The data areas that represent the internal reader are now in the private storage of theallocating address space. Because the table of internal readers no longer exists, you no longer need to specify the size ofthe table. As a result, the RDINUM= parameter, which specified the number of internal readers, has been removed fromthe INTRDR initialization statement. You should remove the obsolete RDINUM= parameter from your INTRDRinitialization statements. Migration action: Delete the RDINUM= parameter from the INTRDR statement in your initialization stream. If you don’tdelete it, it is ignored and no error message is generated. Nevertheless, deleting it can help avoid confusion by anyonewho encounters it in the future and is unaware that it is no longer functional. Moreover, although the parameter is ignorednow, it might not be ignored in a future release.



JES3 Migration Actions Between z/OS R4 and z/OS R7These migration actions were taken from z/OS Migration. Some descriptions and actions have been shortened forinclusion in this presentation. For the complete descriptions and actions, refer to z/OS Migration.

JES3 Migration Actions You Can Do Now

<none>

JES3 Migration Actions Pre-First IPLChange OSEDBYCT to OSEDBYTE (Required-IF, as of R7)Required if you use the IATYOSE macro.The data set byte count in the IATYOSE macro was changed to a 3-byte numeric field and the name of the field waschanged to OSEDBYTE by APAR OA04281. OSEDBYCT, which mapped the low-order two bytes of this field, has beendeleted.Migration action: Change any exit or modification code that refers to the field name OSEDBYCT to refer to OSEDBYTEinstead, and to handle OSEDBYTE as a 3-byte field.

Update programs that obtain JES3 working set histogram data from SMF type 84 records (Required-IF,as of R7)Required if the SMF type 84 working set size data is used for report generation.Users of the JES3 monitoring facility (JMF) can produce a histogram of JES3 working set sizes. If requested, this datacan be recorded in SMF type 84 records. These records contain plot table entries, in 100 KB increments (where KBequals 1024 bytes), starting with the smallest working set value that is found and ending with the largest one found. Eachentry was two words: word 1 contains the working set size in KB and word 2 contains the number of times the working setsize was at this KB value.





JES3 Migration Actions from z/OS R4 to z/OS R7Migration Actions You Can Do NOW:

<none>

Migration Actions Pre-First IPL:Change OSEDBYCT to OSEDBYTE (Required-IF, as of R7)

Data set byte count in IATYOSE macro is now 3-byte numeric field, named OSEDBYTE.

Update programs that obtain JES3 working set histogram data from SMF type 84 records (Required-IF, as of R7)

Working set size entries that occur 0 times are no longer included in SMF data.Change exits and modifications to use IATXDATX (Required-IF, as of R5/R6 and rolled back)

DATCC prefix size in the IATYDAT macro has increased. If you have any exits or modifications that use the DATCC value to advance from the DAT prefix to the data within spooled records, they need to change to use the IATXDATX macro.

Update the BFSIZ parameter on the NJERMT statement (Required-IF, as of R5/R6)JES3 spool records have an additional two bytes in the prefix. Now, the maximum buffer size for an NJERMT statement (BFSIZ parameter) is the maximum buffer size on the BUFFER BUFSIZE parameter minus 46, instead of minus 44.Make the change if you have any directly connected BSC NJE nodes and do not allow the buffer size to take the default.

Migration Actions Post-First IPL:<none>

Before z/OS V1R7 JES3, entries in which word 2 was 0 were included in the SMF data. Starting with z/OS V1R7 JES3,entries in which word 2 is 0 are no longer included. If the histogram data is being used to generate a report and the0-count entries are needed, the program generating the report has to create them.Migration action: Before the first time that SMF data will be used to create a working set size report, update the reportgenerating program to supply 0-count entries. One way to determine the number of 0-count entries to include is toprocess the first entry (call this entry x) and then subtract the size of entry x (in KB) from the size of entry x+1 and dividethe result by 100. The result, minus 1, is the number of 0-count entries that need to be generated before processing entryx+1. Then make entry x+1 the x entry and repeat this process until the high count value is processed. Note that theincremental value can be obtained from field R84WSINC in the SMF type 84 record.

Change exits and modifications to use IATXDATX (Required-IF, as of R5/R6 and rolled back viaOW57535)Required if you have any user exits or modifications that use the DATCC value to advance from the DAT prefix to thedata within spooled records.The DATCC prefix size in the IATYDAT macro has increased in z/OS V1R5. If you have any exits or modifications thatuse the length of DATCC or reference DATXMLEN (which depends on the prefix size), or use the field SVTMUBLN in theIATYSVT macro or the field TVTMUBLN in the IATYTVT macro (both of which depend on the prefix size) to determine theamount of room left in a buffer, you must change this code to use the IATXDATX macro.Migration action: Recode any user exits or modifications that use the DATCC value to advance from the DAT prefix tothe data in spooled records to instead use the IATXDATX macro. Reference information: For details about using the IATXDATX utility, see z/OS JES3 Customization

Update the BFSIZ parameter on the NJERMT statement (Required-IF, as of R5/R6)Required if you have any directly connected BSC NJE nodes and do not allow the buffer size to take the default.Starting in z/OS V1R5, JES3 spool records have an additional two bytes in the prefix. Because of this, the maximumbuffer size for an NJERMT statement (BFSIZ parameter) is now the maximum buffer size on the BUFFER BUFSIZEparameter minus 46, instead of minus 44. Migration action: If you have any NJERMT statements that specify a BFSIZ parameter that is larger thanBUFFER,BUFSIZE minus 45, recode the BFSIZ parameter on the NJERMT statement to be BUFFER,BUFSIZE minus 46instead of BUFFER,BUFSIZE minus 44.Reference information: For details about using the NJERMT statement, see z/OS JES3 Initialization and Tuning Reference.

JES3 Migration Actions Post-First IPL

<none>







Language Environment Migration Actions from z/OS R4 to z/OS R7Migration Actions You Can Do NOW:

Migrate from use of RTLS (Required-IF, as of R6)Function no longer required, due to stability and upward compatibliity of Language Environment run-time libary.Ensure that your customized run-time options do NOT have RTLS, VERSION, or LIBRARY.

Migrate from use of DLL Rename Utility (Required-IF, as of R6)C/C++ DLLs have been licensed with the z/OS base, therefore the DLL Rename Utility is no longer required.

Migration Actions Pre-First IPL:Update the CICS system definition file based on the newest CEECCSD sample (Required)

In each release, load modules are added/deleted to this file. If using CICS TS V3, in member CEECCSDX.

Review Language Environment load modules in LPA (Required-IF)Update applications that do not use standard interfaces to process a utmpx data base (Required-IF, as of R6)

Existing apps that do NOT use the standard interface must be rewritten for use of z/OS R6.Standard interfaces include: setutxent(), getutxent(), getutxid(), putxtline(), and endutxent().



Language Environment Migration Actions from z/OS R4 to z/OS R7Migration Actions Pre-First IPL:

Determine the impact of changes to default run-time options (Required-IF, as of R5)

In R7 new parm member, CEEPRMxx, for specifing LE run-time options for the system!Changes to the run-time options in R5:

HEAPCHK now has a pool depth suboptionHEAPPOOLS has several new suboptions that allow you to define six additional pools.

No changes in R6 or R7.Update your existing CEEDOPT and CEECOPT, noting the changes above.

Migration Actions Post-First IPL:Accept new putenv() default (Recommended, as of R5 and rolled back)

Now, the string passed to putenv() is placed directly into the array of environment variables.Can restore previous behavior of putenv().

Language Environment Migration Actions Between z/OS R4 and z/OS R7These migration actions were taken from z/OS Migration. Some descriptions and actions have been shortened forinclusion in this presentation. For the complete descriptions and actions, refer to z/OS Migration.

Language Environment Migration Actions You Can Do Now

Migrate from use of RTLS (Required-IF, as of R6)Required if you use RTLS or if you have any CEEUOPT or CEEROPT modules that contain RTLS, VERSION, orLIBRARY run-time options.Effective with z/OS V1R6, Language Environment’s use of run-time library services (RTLS) is discontinued. z/OS V1R5 isthe last release that included the support. This function has been used primarily in run-time migration. Given the stabilityand the upward compatibility being provided by the Language Environment run-time library in recent releases of OS/390and z/OS, this functionality is no longer required.Migration action: Remove any references that your applications make to the LIBRARY, RTLS, and VERSION run-timeoptions. All references to these run-time options are removed from the CEEDOPT, CEECOPT, CEEROPT, andCEEUOPT modules, and from all options reports. Note that existing CEEUOPT and CEEROPT modules might containRTLS, VERSION, or LIBRARY options. If so, you can use them unchanged on z/OS V1R6. Informational messageCEE3611I is issued to indicate that the run-time options are ignored. To eliminate the message, modify the CEEUOPT orCEEROPT module.

Migrate from use of DLL Rename Utility (Required-IF, as of R6)Required if you use the DLL Rename Utility.Effective with z/OS V1R6, IBM has removed the Dynamic Link Library (DLL) Rename Utility, which was in LanguageEnvironment. z/OS V1R5 was the last release that included the utility. This utility was used to package and redistributeIBM-supplied DLLs with applications. Since OS/390 V1R3, the C/C++ DLLs have been licensed with the OS/390 andz/OS base operating systems. Therefore, the DLL Rename Utility is no longer required.

Language Environment Migration Actions Pre-First IPL

Update the CICS CSD based on the newest CEECCSD sample (Required)Each release, Language Environment adds or deletes load modules in the CICS system definition (CSD) file. Thus, youshould update the file each release using the program definitions found in member CEECCSD and, if using CICSTransaction Server (TS) for z/OS V3 (5655-M15), in member CEECCSDX.

For example, in z/OS V1R2, the CLER CICS(R) transaction was added to display run-time options under CICS and alter asubset of options. Therefore, you must define the CLER transaction in the CICS CSD. The CEECCSD sample job in thehlq.SCEESAMP data set has been updated to include the CSD entries for the CLER transaction. Migration action: Update the CSD file using the program definitions in member CEECCSD (and member CEECCSDX ifusing CICS TS V3) found in the hlq.SCEESAMP data set. Note: The group containing the LE run time routines must be in the group list used during CICS startup.

Review Language Environment load modules in LPA (Required-IF)Required if you need to make modules accessible through the link pack area (LPA).Each release you must update the Language Environment load modules that you make accessible through the link packarea (LPA). In addition, each release you should review your list of load modules in the LPA to determine if it’s stillsuitable.Migration action: Review Language Environment load modules in the LPA.

To move load modules into the LPA, use sample members are provided in the CEE.SCEESAMP data set.To see which modules are eligible for the LPA, refer to z/OS Language Environment Customization. The moduleslisted there can be put in the LPA or extended LPA (ELPA) depending on their RMODE value:If you are considering placing the modules listed in z/OS Language Environment Customization in the LPA or theELPA, then IBM highly recommends that you place the SCEELPA data set in the LPA list (LPALST xx). SCEELPAcontains Language Environment load modules that are reentrant, that reside above the 16 MB line, and that areheavily used by z/OS.In z/OS Language Environment Customization you will also see tables of modules eligible for the LPA and the ELPAabove and beyond what is found in the SCEELPA data set. You will need to use the dynamic LPA or MLPA approachto 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 intothe LPA or ELPA at your discretion.

Update applications that do not use the standard interfaces to process a utmpx database (Required-IF,as of R6)Required if you have applications that do not use the standard intefaces to process a utmpx database.The /etc/utmpx file contains a user accounting database. In z/OS V1R6, the format of the utmpx records is extended tosupport longer remote host names (ut_host) of up to 1024 bytes. The new format also supports the natural growth of the64-bit timeval structure, providing a separate ut_tv element for applications compiled as 64-bit. Finally, an internal element,ut_version, replaces space formerly taken up for alignment and is used by the library to distinguish the utmpx recordformat. Existing applications (compiled prior to z/OS V1R6) that use the standard interfaces to process a utmpx database willcontinue to run as before, with the same mappings. The offsets of existing elements in the old format have not changed.Applications will simply not “see” beyond the first 32 bytes of ut_host. (Of course, if you want your applications to referenceany of the new elements, you will have to modify and recompile the applications.)

Existing applications that do not use the standard interfaces to process a utmpx database must be rewritten for use on az/OS V1R6 system.Migration action: Rewrite applications that use nonstandard interfaces to process a utmpx database. For details, seethe utmpx.h header shipped with z/OS V1R6. If possible, convert to use of standard interfaces so that future changes do not impact you. The standard interfacesinclude the following C functions: setutxent(), getutxent(), getutxid(), getutxline(), pututxline(), and endutxent().

Determine the impact of changes to default run-time options (Required-IF, as of R5)Required if you updated the installation-wide run-time option CSECT (CEEDOPT or CEECOPT) in a previous release.Periodically, Language Environment introduces new run-time options, adds new suboptions to existing run-time options,and changes the defaults of run-time options. Before migrating to a new release of z/OS, you should review the run-timeoption values for the new release.

In z/OS V1R7, a new parmlib member, CEEPRMxx, was added for Language Environment. You can use it tospecify Language Environment run-time options for the system. Operator commands are also provided to allowyou to query and update the active run-time options for the system. This simplifies the management of LanguageEnvironment options, particularly in multisystem environments, and makes it possible to move LanguageEnvironment customization out of assembler language modules maintained using SMP/E usermods. However,specifying Language Environment options using CEEDOPT, CEECOPT and CELQDOPT modules continues to besupported.

In z/OS V1R6 and z/OS V1R7, there were no changes to Language Environment run-time options. The following changes have been made to Language Environment run-time options in z/OS R5:

HEAPCHK now has a pool depth suboption. HEAPPOOLS has several new suboptions that allow you to define six additional pools.

Migration action: Consider using CEEPRMxx, the new parmlib member added in z/OS V1R7.Compare your existing source for the installation-wide run-time options CSECT, CEEDOPT (non-CICS environment)or CEECOPT (CICS environment), with the new samples in hlq.SCEESAMP to determine whether you need tochange your defaults. If changes are necessary, you must make them and apply the corresponding usermods. If you don’t update your previous CEEDOPT or CEECOPT with the new HEAPCHK and HEAPPOOLS suboptions,the assembly of the previous usermods will fail. If you don’t install any usermods whatsoever, Language Environmentuses the default values.

Language Environment Migration Actions Post-First IPL

Determine the impact of changes to default run-time options (Recommended, as of R5)Recommended in order to be POSIX compliant. This is incorporated into z/OS R5 and rolled back to z/OS V1R4, z/OS V1R3,and z/OS V1R2 by APAR PQ61928.



The C/C++ function putenv() has changed to place the string passed to putenv() directly into the array of environmentvariables. This behavior assures compliance with the POSIX standard. Before the change, the storage used to define theenvironment variable passed into putenv() was not added to the array of environment variables. Instead, the systemcopied the string into system allocated storage. An environment variable, _EDC_PUTENV_COPY, is available to allow youto use the old behavior.Migration action: To allow the new, POSIX-compliant behavior of putenv(), do nothing; it’s now the default condition. To restore the previous behavior of putenv(), following these steps: 1. Be sure the environment variable, _EDC_PUTENV_COPY, is available on your z/OS V1R5 system. 2. Set the environment variable to_EDC_PUTENV_COPY=YES.



SMP/E V3R4 Migration Actions Between z/OS R4 and z/OS R7These migration actions were taken from z/OS Migration. Some descriptions and actions have been shortened forinclusion in this presentation. For the complete descriptions and actions, refer to z/OS Migration.Note: SMP/E is a driving system element and, as such, is fully usable from your driving system by accessing the installedSMP/E target libraries prior to an IPL. Given that, SMP/E migration actions are presented in two categories rather than thethree categories used in the rest of this presentation. The two categories are:

SMP/E actions to perform after installing SMP/E V3R4 (z/OS V1R4 SMP/E) but before starting to use it SMP/E actions to perform after starting to use SMP/E V3R4 (z/OS V1R7 SMP/E)

SMP/E V3R4 Migration Actions Before Installing SMP/E

Modify firewall commands for the FTP client, when using SMP/E electronic capabilities (Required-IF, asof R6)Required if you use SMP/E RECEIVE FROMNETWORK command or SMP/E's Internet Service Retrieval function, andspecify client firewall commandsIn SMP/E V3R3 (which is in z/OS V1R6), the RECEIVE FROMNETWORK command was enhanced to use theCommunications Server FTP client. Because of the way in which the FTP client and local firewalls prompt for a user IDand password, this enhancement requires changes to the <FIRECMD> tags used to navigate through a local firewall. The<FIRECMD> tags are specified in the CLIENT data set for the RECEIVE FROMNETWORK command and the SMPCLNTdata set for the new GIMGTPKG service routine.Prior to SMP/E V3R3, you may have specified the following <FIRECMD>tags: <FIRECMD> USER &USER; </FIRECMD> <FIRECMD> PASS &PW; </FIRECMD> With SMP/E V3R3, if your local firewall or the FTP client prompts for the userid, then do not specify the USERsubcommand on the <FIRECMD> tag. Only specify the userid or the appropriate substitution variable on the <FIRECMD>tag as follows: <FIRECMD> &USER; </FIRECMD>





SMP/E V3R4 Migration Actions from z/OS R4 (V3R1) to z/OS R7 (V3R4)

Migration Actions After Installing SMP/E:Modify firewall commands for FTP client, when using SMP/E electronic retrieval functions (Required-IF, as of R6)

Migrate from CLIENT to FTP.DATA for local site parameters (Required-IF, as of R6)If you specify pasv or keepalive in the CLIENT data set, then specify FWFriendly and FTPKEEPALIVE in the FTP.DATA data set.

Specify which utility programs SMP/E can call (Required-IF, as of R5)If you had used module GIMUTTBL to specify which utility programs SMP/E was allowed to call, use a security program (RACF) instead.

Specify SMP/E dialog customization options (Required-IF, as of R5)Use Option" 0 - Settings" from the SMP/E menu to implement customization options.

Use the LINK LMODS command instead of REPORT CALLLIBS (Required-IF, as of R5)REPORT CALLLIBs has been removed, use LINK LMODS instead.

Migration Actions After Using SMP/E:Upgrade SMP/E zones (Required-IF)

If you want to use new SMP/E V3.2 functions that make incompatible changes to SMP/E zones (like the SMPLTS reduction!).Once you've run the UPGRADE command, you may no longer use prior SMP/E releases for that zone.

If your local firewall or the FTP client prompts for the password, then do not specify the PASS subcommand on the<FIRECMD> tag. Only specify the password or the appropriate substitution variable on the <FIRECMD> tag as follows:<FIRECMD> &PW; </FIRECMD>With SMP/E V3R3, you may need to add two additional <FIRECMD> tags if once connected to your local firewall, you arenot yet connected to the remote server. To connect to the remote server, add the following <FIRECMD> tags:

<FIRECMD> USER &REMOTE_USER; /FIRECMD>

In the end, the commands you specify in the <FIRECMD> tags should be the same as those you use with the z/OSCommunications Server FTP client. Since the behavior of various firewalls differ, the best way to determine the necessary<FIRECMD> tags is to perform an FTP operation using the FTP client in a JCL job and then specify the same commandsthat were needed in that operation in the <FIRECMD> tags in the CLIENT and/or SMPCLNT data set.

Example FTP JCL job://job JOB job parameters... //FTP EXEC PGM=FTP //OUTPUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //INPUT DD * firewall_host firewall_userid SITE remote_host ; USER remote_userid ; remote_password DIR QUIT

Migrate from CLIENT to FTP.DATA for local site parameters (Required-IF, as of R6)Required if you use the pasv and keepalive attributes in the CLIENT data set.SMP/E now uses the FTP.DATA configuration data set to allow the client to specify local site parameters. Two of theparameters specified in the FTP.DATA data set are FWFriendly and FTPKEEPALIVE. These parameters correspond tothe pasv and keepalive attributes in the CLIENT data set. Therefore, no longer specify the pasv and keepalive attributesin the CLIENT data set. Rather, specify the FWFriendly and FTPKEEPALIVE parameters in the FTP.DATA data set.Migration action: Remove any pasv and keepalive attributes from the CLIENT data set. Replace them with FWFriendlyand FTPKEEPALIVE parameters in the FTP.DATA data set. Any pasv and keepalive attributes that remain in the CLIENT data set are ignored. However, removing them now can helpavoid confusion in the future by anyone who encounters them and is unaware that they are no longer functional.

<CLIENTpasv="YES"keepalive="300">

</CLIENT> FWFRIENDLY TRUEFTPKEEPALIVE 300

FTP.DATA<CLIENT

pasv="YES"keepalive="300">

</CLIENT> FWFRIENDLY TRUEFTPKEEPALIVE 300

FTP.DATA

FWFRIENDLY TRUEFTPKEEPALIVE 300

FTP.DATA

Specify which utility programs SMP/E can call (Required-IF, as of R5)Required if you have modified module GIMUTTBL and want to retain the options specified there.In prior SMP/E releases, you had to modify module GIMUTTBL to specify which utility programs SMP/E was allowed tocall. Module GIMUTTBL and load module GIMUTTBL are no longer supplied as part of SMP/E. Macro GIMDFUT, whichwas used to replace the IBM-supplied copy of GIMUTTBL, is also no longer supplied.Migration action: You can specify which utility programs SMP/E can call by using z/OS Security Server (RACF) to createa profile for the utility program in the PROGRAM general resource class.

Specify SMP/E dialog customization options (Required-IF, as of R5)Required if you have modified panel GIM@UPRM and want to keep the options specified there.



A new option, Option 0, has been added to the SMP/E Primary Option Menu GIM@PRIM to implement the current SMP/Ecustomization options. This new option allows you to enter or change the values for the customization options that werepreviously found in panel GIM@UPRM. When you select option 0 from the GIM@PRIM panel, the panel GIM@PARM willappear. The options you then specify are saved permanently in the ISPF profile pool for later use by other SMP/E dialogprocesses.Migration actions: Use the new Option 0 on the SMP/E Primary Option Menu GIM@PRIM to specify the desired SMP/Edialog customization options. The options you specify will be saved.

Use the LINK LMODS command instead of REPORT CALLLIBS (Required-IF, as of R5)Required if you have system programming procedures or jobs that use the REPORT CALLLIBS command.The REPORT CALLLIBS command has been removed from SMP/E V3R2. It has been replaced by the LINK LMODScommand.Migration action: Use the LINK LMODS command instead of REPORT CALLLIBS.

SMP/E V3R4 Migration Actions After Installing SMP/EUpgrade SMP/E zones (Required-IF)Required if you wish to use new SMP/E functions that make incompatible changes to SMP/E zones. New releases of SMP/E must sometimes make changes to SMP/E data sets that cannot be properly processed by priorSMP/E releases. SMP/E usually makes incompatible changes only when necessary to provide new and improvedcapabilities. For example, a new type of element requires a new entry type in SMPCSI data sets and these new entrytypes are typically not understood or processed correctly by SMP/E levels that have not been specifically updated to doso. The UPGRADE command allows you to specify when SMP/E is permitted to make incompatible changes to SMP/E datasets. This, in turn, allows you to make the trade-off between exploiting new SMP/E functions and preserving compatibilitywith prior SMP/E releases. For more information about the UPGRADE command, refer to SMP/E Commands. Migration actions: Once you have decided that you will no longer maintain a particular SMP/E zone with SMP/Ereleases prior to SMP/E V3R4, run the UPGRADE command for that zone. This enables you to exploit all the newfunctions of the latest SMP/E for that zone. But remember, once you run UPGRADE for a zone using a particular releaselevel of SMP/E, you must continue to use that release level to process that zone.







z/OS UNIX System Services Migration Actions from z/OS R4 to z/OS R7Migration Actions You Can Do NOW:

Modify BPXPRMxx because SET OMVS=xx now executes MOUNT, FILESYSTYPE, and NETWORK statements (Required-IF, as of R7)

Before R7 these statements were executed on SET OMVS=xx commands, now they will be.

Remove settings of _MAKE_BI=YES (Recommended, as of R5)

Migration Actions Pre-First IPL:Change NOAUTOMOVE to AUTOMOVE for sysplex-aware file systems (Recommended, as of R6)

Sysplex-aware file systems will be AUTOMOVE'd, even if you have specified NO. Migrate from central byte range lock manager (BRLM) support (Required-IF, as of R6)

When all systems are at R6, distributed BRLM is the only locking method supported.Choose an appropriate GID value for the TFS root directory (Required-IF, as of R5)

GID for a TFS root directory is the value of what you specify when you mount the TFS, default is 0.

Specify enough storage above bar if mounting TFS in a colony address space (Required-IF, as of R5)

By default, when TFS is mounted storage is obtained above bar. May specify that you want storage obtained below bar (PARM('-s 60 -3')

Update USS /etc configuration files (Required-IF, as of R6)



z/OS UNIX System Services Migration Actions from z/OS R4 to z/OS R7Migration Actions Post-First IPL:

Migrate from HFS to zFS (Recommended)zFS is now allowed in all levels of file system hierarchy (including root!). Support for the HFS file system has been stabilized and you are encouraged to migrate to the zFS file system for better performance, but IBM has not announced removal of support for the HFS file system.Use the handy ISPF-based tool, BPXWH2Z, available in z/OS R7. This tool will:

Migrate HFS file systems (both mounted and unmounted) to zFS file systems. If the HFS being migrated is mounted, the tool automatically unmounts it and then mounts the new zFS file system on its current mount point. Define zFS aggregates by default to be approximately the same size as the HFS. The new allocation size can also be increased or decreased.

Have the migration run in TSO foreground or UNIX background.

Evaluate the need for chmod and chtag to follow symbolic links (Required-IF, as of R5)

chmod and chtag commands now follow symlinks. Use -h to specify that symlinks are not followed

Install books and a bookshelf for the OHELP command (Required-IF)

z/OS UNIX System Services Migration Actions Between z/OS R4 and z/OS R7These migration actions were taken from z/OS Migration. Some descriptions and actions have been shortened forinclusion in this presentation. For the complete descriptions and actions, refer to z/OS Migration.

z/OS UNIX System Services Migration Actions You Can Do NowModify BPXPRMxx because SET OMVS=xxx now executes MOUNT, FILESYSTYPE, and NETWORKstatements (Required-IF, as of R7)Required if you have MOUNT, FILESYSTYPE, or NETWORK statements in your BPXPRMxx parmlib member and you do not wantthese statements to be executed when the SET OMVS=xx operator command is issued.Before z/OS V1R7, the SET OMVS=xx operator command did not execute the MOUNT, FILESYSTYPE, and NETWORKstatements from the BPXPRMxx parmlib member. As of z/OS V1R7, SET OMVS=xx executes MOUNT, FILESYSTYPE,and NETWORK statements from BPXPRMxx. (If BPXPRMxx is used in a sysplex, the MOUNT, FILESYSTYPE, and NETWORKstatements are ignored on pre-z/OS V1R7 systems but executed on z/OS V1R7 systems.)Migration action: If you do not want SET OMVS=xx to execute the BPXPRMxx MOUNT, FILESYSTYPE, or NETWORKstatements, then edit your BPXPRMxx parmlib member to remove these statements and copy them into anotherBPXPRMxx parmlib member. If you want to use that new BPXPRMxx parmlib member for your next IPL, add it to yourOMVS= list in IEASYSxx. If you want SET OMVS=xx to execute the BPXPRMxx MOUNT, FILESYSTYPE, or NETWORKstatements, then do nothing.

Remove setting of _MAKE_BI=YES (Recommended, as of R5)Recommended to avoid confusion in the future.Support for the _MAKE_BI shell variable is removed. Prior to z/OS V1R5, when set to YES, the z/OS UNIX shell usedbuilt-in make, c89, cc, and c++ commands, rather than the separate executables. The intended performance benefits forlarge application builds were not realized in most cases. This support is disabled in z/OS V1R5 in favor of internalchanges to the compiler commands. The make, c89, cc, and c++ commands are no longer built into the z/OS UNIX shell.Migration action: Delete any settings of _MAKE_BI=YES. If any remain, they are ignored. Nevertheless, deleting themis recommended to avoid confusion in the future.

z/OS UNIX System Services Migration Actions Pre-First IPL

Change NOAUTOMOVE to AUTOMOVE for sysplex-aware file systems (Recommended, as of R6)Recommended to avoid confusion in the future.Previously, you could set either NOAUTOMOVE or an automove system list (SYSLIST) for both sysplex-aware andsysplex-unaware file systems. However, they would be ignored for sysplex-aware file systems during dead systemrecovery. Now you cannot set NOAUTOMOVE or SYSLIST for sysplex-aware file systems. If you do, AUTOMOVE isused instead and you will get an informational message telling you of the change.

What are sysplex-aware file systems? The owner of a file system is the first system that processes the mount. Thissystem always accesses the file system locally, that is, the system does not access the file system through a remotesystem. Other nonowning systems in the sysplex access the file system either locally or through the remote owningsystem, depending on the physical file system (PFS) and the mount mode. If a PFS allows a file system to be locallyaccessed on all systems in a sysplex for a particular mode, the PFS is sysplex-aware for that mode. If a PFS requires thata file system be accessed through the remote owning system from all other systems in a sysplex for a particular mode,then the PFS is sysplex-unaware for that mode.

To find out if the file system is sysplex-aware, you can use the D OMVS,F command to display each mounted file system.Those file systems for which this system is not the owner, and for which it says Client=N, are sysplex-aware (they are notclients and are locally-mounted to the PFS). Those file systems for which this system is not the owner, and for which itsays Client=Y, are sysplex-unaware.

Migration action: For sysplex-aware file systems, replace NOAUTOMOVE in the BPXPRMxx parmlib member withAUTOMOVE. Also, when mounting file systems, do not use a SYSLIST. On MOUNT statements in BPXPRMxx, werecommend that you use either AUTOMOVE or UNMOUNT for sysplex-aware file systems.

Migrate from central BRLM support (Required-IF, as of R6)Required if you use central BRLM support.



Prior to z/OS V1R6, central byte range lock manager (BRLM) was the default and distributed BRLM was an option. Now,central BRLM is no longer supported once all systems in a sysplex are at the z/OS V1R6 level. Distributed BRLM is theonly supported byte range locking method when all systems in a sysplex are at the z/OS V1R6 level. With distributedBRLM, the lock manager is initialized on every system in the sysplex.Migration action: If you are already running with a z/OS UNIX couple data set that enables distributed BRLM, there isno change required to activate distributed BRLM for z/OS V1R6. Likewise, if your sysplex only has systems at the z/OSV1R6 level, there is no change required because distributed BRLM is the default. z/OS V1R6 systems ignore theDISTBRLM setting in the couple data set.

If you run the IXCL1DSU utility to create a z/OS UNIX couple data set, distributed BRLM is set up as the default.

To enable distributed BRLM if you are running mixed levels in a sysplex, follow these steps before bringing the first z/OSV1R6 system into the sysplex: 1. Use the IXCL1DSU utility to update the BPXCMDS data set.

DISTBRLM NUMBER(0) is no longer supported; NUMBER(1) is the default DISTBRLM NUMBER is ignored in a sysplex that consists of all z/OS V1R6 systems; NUMBER(1) isrecommended if you are running mixed levels in a sysplex. Example: DEFINEDS SYSPLEX(PLEX1) ... DATA TYPE(BPXMCDS) ITEM NAME(DISTBRLM) NUMBER(1) /*default */

2. Activate the BPXCMDS data set.

If you migrate to z/OS V1R6 by running mixed levels in a sysplex, you must enable distributed BRLM before IPLing the z/OS V1R6system because a z/OS V1R6 system may attempt to activate distributed BRLM when the central BRLM server leaves the sysplex,regardless of the setting in the z/OS UNIX couple data set. The inconsistency between distributed BRLM being active and central BRLMbeing defined in the couple data set can cause an EC6-BadOmvsCds abend on downlevel systems. It is a notification-only abendindicating that the CDS should be updated. z/OS UNIX will still operate normally, and distributed BRLM will be active in the sysplex.

Choose an appropriate GID value for the TFS root directory (Required-IF, as of R5)Required if you use TFS but the following are not appropriate for your environment: a GID of 0, permissions of 0777, and a UID of 0.Previously, when a GID for the root of a temporary file system (TFS) was assigned, its value was that of the default groupfor the user ID under which the TFS was running. Now, the GID for a TFS root directory is the value of what you specifywhen you mount the TFS; if you do not specify a value, the default of 0 is used.Migration action: On the mount, set the GID for the TFS root. Mount users must have UID(0) or at least READ accessto the BPX.SUPERUSER FACILITY class. If the only privilege the user needs is the ability to mount, then you shoulddefine the profile SUPERUSER.FILESYS.MOUNT in the UNIXPRIV class and give that user at least READ authority. Example: To set the GID to 1 for the TFS root: MOUNT FILESYSTEM(’/tmp’) /* TFS for /tmp directory */ MOUNTPOINT(’/tmp’) TYPE(TFS) /* Filesystem type TFS */ MODE(RDWR) /* Mounted for read/write */ PARM(’-g 1 -p 1777 -u 999 -s 20’) /* change the GID from 0 (default) to 1 change permissions from 0777 (default) to 1777, which sets the stickybit. Change UID from 0 (default) to 999 set size to 20 MB */ Notes: 1. Global access is allowed by default. 2. If you do not specify a size on a TFS mount, the default of 1 MB is used.Guideline: Set the sticky bit on for /tmp and other public directories. If the sticky bit is on, only the owner of a file (orsuperuser) can remove files in that directory. On a public directory such as /tmp, if the sticky bit is not set, anyone couldremove files.

Specify enough storage above the bar if you are mounting a TFS in a colony address space(Required-IF, as of R5)Required if you use a TFS in a colony address space, and do not have enough storage specified above the 2GB bar.If you plan to mount a temporary file system (TFS) in a colony address space, you need to specify enough storage abovethe 2 GB bar to accommodate the mount request, or choose to have the TFS mounted below the bar.Migration action: When a TFS is mounted in a colony address space, storage for the mount is obtained (by default)above the 2 GB bar. Therefore, make sure that enough storage is available above the bar. The amount of storagerequired



depends on the size of the TFS.If you wish to have the TFS mount obtain storage below the bar, specify PARM(’-s 60 -3’) in the MOUNT statement in theBPXPRMxx parmlib member to force the storage to be obtained below the bar.

Updated UNIX System Services /etc configuration files (Required-IF)Required if you have customized a configuration file that IBM has changed.Some utilities provided by z/OS UNIX require the use of certain configuration files. You are responsible for providingthese files if you expect to use the utilities. IBM provides default configuration files as samples in the /samples directory.Before the first use of any of these utilities, you must copy these IBM-provided samples to the /etc directory (in mostcases). You can further customize these files to include installation-dependent information. An example is setting up the/etc/rc file by copying the sample file from /samples/rc to /etc/rc 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 thenew versions of the configuration files.Migration action: The only file for UNIX System Services that has changed (in each z/OS release) is for the OHELPutility. The IBM-provided sample is in /samples/ohelp.ENU and you have the file copied to /etc/ohelp.ENU. Everyrelease, bookshelf and book data set names are updated. See "Install books and a bookshelf for the OHELP command"below for related information.

z/OS UNIX System Services Migration Actions Post-First IPLMigrate from HFS file systems to zFS file systems (Recommended)Not required, recommended. Support for the HFS file system has been stabilized and you are encouraged to migrate tothe zFS file system for better performance, but IBM has not announced removal of support for the HFS file system.Before z/OS V1R7, the HFS file system was the primary hierarchical file system. As of z/OS V1R7, you can use anycombination of HFS and zFS file systems. Because zFS has higher performance characteristics than HFS and is thestrategic file system, HFS might no longer be supported in future releases and you will have to migrate the remaining HFSfile systems to zFS. The HFS and zFS file system types in mount statements and command operands are now generic file system types thatcan mean either HFS or zFS. Based on the data set type, the system will determine which is appropriate.Migration action: Before beginning the migration, follow these steps: 1. Establish backout procedures. 2. Decide on naming conventions. 3. Decide on unavailability. 4. Perform the conversion from HFS to zFS file system.

Tip: You can use the BPXWH2Z tool to perform the conversion. It is an ISPF-based tool that migrates HFS filesystems to zFS file systems. It has a panel interface that enables you to alter the space allocation, placement, SMSclasses, and data set names. A HELP panel is provided. With this tool, you can:

Migrate HFS file systems (both mounted and unmounted) to zFS file systems. If the HFS being migrated ismounted, the tool automatically unmounts it and then mounts the new zFS file system on its current mount point. Define zFS aggregates by default to be approximately the same size as the HFS. The new allocation size canalso be increased or decreased. Have the migration run in TSO foreground or UNIX background.

BPXWH2Z is located in partitioned data set SBPXEXEC (usually called SYS1.SBPXEXEC). When you run theBPXWH2Z tool on your z/OS V1R7 system, it uses the z/OS V1R7 level of the pax command. This level has beenenhanced for sparse file support and other characteristics that are of concern when migrating from an HFS to zFS filesystem. You can manually migrate from an HFS to zFS file system without using the tool. When doing that, the z/OSV1R7 level of the pax command is recommended. However, you would need to allocate and format the target zFS filesystems.

5. Change policies and scripts, and so forth, to reflect the change from the HFS file system to zFS file system. Tip: Make sure you’re using the RMF Monitor III option to report on zFS activity.

Evaluate the need for chmod and chtag to follow symbolic links (Required-IF, as of R5)Required if chmod and chtag commands are not intended to follow symbolic links.



The chmod and chtag commands are updated to follow symbolic links, for compatibility with non-z/OS UNIX platforms.Shell scripts that depend on the original behavior of the chmod and chtag commands might fail. For example, thecommand: chmod -R 777 dir where the dir tree contains external links, will now generate errors for the external links. You can use the -h option, which is unchanged in z/OS V1R5, to specify that symbolic links are not followed.Migration action: Evaluate any failing shell scripts. Typically, you can fix them by adding the -h option. For example:chmod -hR 777 dir

Install books and a bookshelf for the OHELP command (Required-IF)Required if you use the OHELP command.The TSO/E OHELP command uses the BookManager READ base element to display online reference information aboutshell commands, TSO/E commands, C functions, callable services, and messages issued by the shell and dbx. Beforethis online help facility can be used, you must set it up by installing books and a bookshelf. Migration action: Copy the IBM-supplied sample file /samples/ohelp.ENU to /etc/ohelp.ENU. If you choose not to use theIBM-supplied default file, you can create your own file called /etc/ohelp.language_id, where language_id is the TSO/Euser’s primary language code.



z/OS V1 R7 Install-Related Enhancements

Documentation Enhancements for z/OS R7For z/OS V1.7, the z/OS Migration book (GA22-7499) covers all three supported migration paths. (For z/OS V1.4 itcovered only one migration path.)

The three migration paths are:z/OS Release 1.6 to z/OS Release 1.7z/OS Release 1.5 to z/OS Release 1.7z/OS Release 1.4 to z/OS Release 1.7.

As an added bonus, you are able to download a copy of the z/OS Migration book that is customized to your particularmigration path. For example, if you download the V1.6-to-V1.7 book, you receive a PDF of the book that contains only theV1.6-to-V1.7 migration actions. The V1.4-to-V1.6 migration actions are not included in the customized book. In otherwords, the book won’t contain migration actions that don’t apply to your particular migration path.

The customized Migration books are available with general availability of z/OS V1.7 from the z/OS Migration andInstallation Web page, which is: http://www.ibm.com/eserver/zseries/zos/installation/zos_migration.html

Selected ServerPac Enhancements in z/OS R7No secondary extends in LNKLST data sets: If you would like to have secondary extents (which is the priorbehavior), use the CHANGE SECOND Y command. This command will allocate 10% secondary only for those datasets shipped with no secondary extents. Merging z/OS UNIX file systems: This support can allow you to merge z/OS UNIX file systems in zFS and HFS datasets in a way similar to the support for PDS and PDSE data sets, when the merge would result in a usable mountpoint. This can help you simplify file system configurations and parmlib management for file systems.IBM Health Checker for z/OS: Once the ServerPac installation steps have been completed, IBM Health Checker forz/OS will be enabled, reducing the setup required for use. This can help you use its new functions more quickly toidentify potential problems in your installation.





z/OS V1 R7 Install-Related Enhancements

Documentation:z/OS Migration contains all supported migration paths to z/OS R7!

z/OS R4 to z/OS R7, z/OS R5 to z/OS R7, and z/OS R6 to z/OS R7

No licensed publications anymore, effective with z/OS R7.

DeliverablesServerPac in z/OS R7:

No secondary extents in LNKLST data sets: You can revert back to prior behavior, if you wish

with the CHANGE SECOND Y command (for 10% secondary).

Merging z/OS UNIX file systems: This support can allow you to merge z/OS UNIX file systems in zFS and HFS data sets in a way similar to the support for PDS and PDSE data sets, when the merge would result in a usable mount point. This can help you simplify file system configurations and parmlib management for file systems.

IBM Health Checker for z/OS: Once the ServerPac installation steps have been completed, IBM Health Checker for z/OS will be enabled, reducing the setup required for use. This can help you use its new functions

more quickly to identify potential problems in your installation.PSP bucket removal in ServerPac and CBPDO: Up-to-date PSP buckets are now available

online. This current information is pointed to.

...and lots of other goodies from prior releases you may not have yet seen!

PSP bucket removal: Up-to-date PSP buckets are now available online. ServerPac and CBPDO have been changedto point to this current information.






21© 2006 IBM CorporationMMigrating to z/OS 1.7 Part 3 of 3 - GO!

z/OS R7 Install-Related Enhancements

Summary of Enhancements of System Programmer Interest

UNIX: Dynamic Service ActivationLanguage Environment: Run-Time Options Parmlib Member

BCP: IEARELEC Sample to Remove EMCS ConsolesJES2 and JES3: >64K Tracks for Spool Data Sets

Other R7 goodies I couldn't fit in:Integrated Catalog Forward Recovery Utility incorporated into z/OS R7.USS OEDIT increase maximum width for file edit and give warning if extended attributes are set on a file being edited before oedit causes them to get reset.Tons of USS ISHELL enhancements!.D OMVS,MF for move and mount failure information

z/OS R7 UNIX System Services Dynamic Service ActivationYou can dynamically activate and deactivate service items (PTFs, ++APARS, ++Usermods) that affect the UNIX SystemService component modules without having to re-IPL. This capability is primarily intended to allow an installation toactivate corrective service to avoid unplanned re-IPLs of your systems. Additionally, this capability can be used to activatea temporary patch that can be used in gathering additional documentation for a recurring system problem. Although thiscapability can be used to activate preventive service on an ongoing basis, it is not intended for this purpose as areplacement for the regular application of service that does require a re-IPL.

F OMVS,ACTIVATE=SERVICE activates the service. F OMVS,DEACTIVATE=SERVICE backs off the service. D OMVS,ACTIVATE displays the current set of services that were dynamically activated.

Those PTFs that can be dynamically activated will have ++HOLD information within the PTF indicating whether the PTFcan be activated as such. Additonally, any ++USERMOD or ++APAR provided from IBM will have explicit instructionsprovided by the IBM Service Team indicating whether the ++USERMOD or ++APAR can be dynamically activated, aswell. Although a service item may be identified as being capable of dynamic activation, the level of a given system maynot be current enough to allow the activation of the service item. Guideline: In order to be prepared to exploit dynamic service activation, you must stay current on UNIX System ServicesComponent maintenance. Staying current makes it more likely that any given service item can be activated dynamically,because the running system will be at a high enough level to accept the service item. On a periodic or as-needed basis,you will have to determine the selected PTFs that you would be interested in activating dynamically for correctivepurposes. These would likely be the PTFs that are of highest severity and highest impact related to your workloads.Although the dynamic service activation feature can be used to activate most UNIX System Services component PTFs, itis not intended to be used as a way to activate a large set of maintenance for preventive purposes. Those PTFs that arecapable of being activated dynamically will be identified by ++HOLD REASON(DYNACT) data inside their PTFs. In orderto properly activate the PTF, whatever instructions that are included with this hold data must be followed.

Service items are activated from service activation libraries that have been identified via the SERV_LPALIB andSERV_LINKLIB parameters in the BPXPRMxx parmlib member. The service activation libraries contain the service itemsthat have already been installed and that you want to activate on the next F OMVS,ACTIVATE=SERVICE command. The






UNIX: Dynamic Service Activation

Designed to allow you to install z/OS UNIX service without an IPL in some cases. Previously, an IPL was always required to refresh the kernel after installing maintenance.

You need to stay fairly current on service to best be able to exploit this feature You need to determine the selected PTFs you are interested in activating dynamically for corrective purposesNot intended to be used to as a complete replacement for regular preventative maintenance application

Only those PTFs with ++HOLD REASON(DYNACT) data will be capable of dynamic activation

You must follow whatever explicit instructions are given within the ++HOLD documentation to perform the activation and deactivation.To use: set up SERV_LPALIB and SERV_LINKLIB statements in BPXPRMxx (or with SET OMVS=xx or SETOMVS commands). This will identify the load libraries for z/OS UNIX LPA and LINKLIB resident modules where customers will SMP/E install the maintenance to be activated dynamically. Then issue commands to activate or deactivate. Example:

SERV_LPALIB(‘SYS1.LPALIB’,WRK170) in BPXPRMxxF OMVS,ACTIVATE=SERVICE activates the service. F OMVS,DEACTIVATE=SERVICE backs off the service. D OMVS,ACTIVATE displays the current set of services that were dynamically activated

libraries enable you to identify for a given activation request the normal LPALIB and LINKLIB target libraries where youinstall service via SMP/E for future IPLs or a specific library where you have installed a specific fix.

In BPXPRMxx, details on the statements are:SERV_LPALIB(’dsname’, ’volser’) Specifies the target service library where the UNIX System Services modules thatare normally built into LPA are located. Value Range:dsname is a 1-to-44 character value representing a valid MVS load library data set name. The alphabetic characters in the load library name must be uppercase. volser is a 1-to-6 character value representinga valid volume serial number for the volume that contains the specified MVS load library. The alphabetic characters inthe volume serial number must be uppercase. You can change the value of SERV_LPALIB dynamically using the SETOMVS or SET OMVS command. To make apermanent change, edit the BPXPRMxx member that will be used for future IPLs. SERV_LINKLIB(’dsname’, ’volser’) Specifies the target service library where the UNIX System Services modulesthat are normally loaded from SYS1.LINKLIB into the private area of the OMVS address space are located. Value Range:dsname is a 1-to-44 character value representing a valid MVS load library data set name. The alphabeticcharacters in the load library name must be uppercase. volser is a 1-to-6 character value representing a valid volumeserial number for the volume that contains the specified MVS load library. The alphabetic characters in the volumeserial number must be uppercase. You can change the value of SERV_LINKLIB dynamically using the SETOMVS or SET OMVS command. To make apermanent change, edit the BPXPRMxx member that will be used for future IPLs.

For more information about using this enhancement, see z/OS UNIX System Services: Planning.



z/OS R7 Language Environment: Run-Time Options Parameter MemberA new parmlib member, CEEPRMxx, can be used to specify Language Environment run-time options for the system.Operator commands are also provided that allow you to query and update the active run-time options for the system. Thiscan simplify the management of Language Environment options, particularly in multisystem environments, and makes itpossible to move Language Environment customization out of assembler language modules maintained using SMP/Eusermods. Specifying Language Environment options using CEEDOPT, CEECOPT and CELQDOPT modules willcontinue to be supported.

z/OS R7 Language Environment provides PARMLIB members for specifying defaults for many system options (refer toCEE.SCEESAMP's CEEPRM00). The CEEPRMxx member can be used for specifying default run-time options inLanguage Environment. The member is identified during IPL by a CEE=xx statement, either in the IEASYSyy data set orin the IPL PARMS. You can:

Change the member after IPL with the SET CEE=xx commandChange individual options using the SETCEE commandDisplay current option settings with the D CEE command

Guideline: Using this support is not required, so the default IEASYS00 member does not specify a CEEPRMxx member. Ifyou want to use this support a sample CEEPRM00 member is included in SCEESAMP.

The format of the CEEPRMxx member is:CEECOPT(opt1, opt2, ..., optn)CEEDOPT(opt1, opt2, ..., optn)CELQDOPT(opt1, opt2, ..., optn)

During IPL, you can specify a parmlib member by using one of the methods shown in these examples:On the sysparms entered at system IPL: R 0,sysp=yy,CEE=(xx,yy,L)In the IEASYSyy member: with CEE=(xx,yy,L)






LE: Run-Time Option Parameter MemberBefore, your Language Environment default run-time options were specified in assembler language modules, probably within SMP/E usermods.As of R7, there is Language Environment parmlib support (CEEPRMxx), for specifying your default run-time options. You can gid rid of those pesky assembler language modules and SMP/E usermods with this support!In CEEPRMxx, there are groups of Language Environment run-time options. Options in each group are delimited by open and closing parens “( … )”. Valid options for each group are the same as in the Assembler parts of the same name:

CEEDOPT - non-AMODE 64 environment run-time optionsCEECOPT - CICS environment run-time optionsCELQDOPT - AMODE 64 environments run-time options

To use:Set up CEEPRMxx with your values (don't need to specify ones you want to do default to)IPL with it, by adding CEE=(xx,yy,L) to either the IEASYS member or R0,sysp=aa,CEE=xxOnce the system is running, a different CEEPRM member may be used with the SET CEE=zz command

You can specify a group more than once in a single member. You can specify an option more than once within a group ora member. Options are processed in the order in which they appear. Suboptions that appear later override earlieroccurrences of the same suboptions. When multiple members are specified, they are processed in the order specified.

After IPL, you can change the active PARMLIB member with the SET CEE=xx command. The format of the SET CEEcommand is: SET CEE=(xx,yy,...,nn)Guidelines:1. xx, yy, and nn are two alphanumeric characters that specify one or more CEEPRMxx PARMLIB members.2. If you specify only one member, parentheses are optional.3. If you specify two or more members, parentheses are required.The SET CEE command parses the CEEPRMxx PARMLIB member and replaces the options with the contents of the newmember.

CEEOPTS DD SupportThere’s another enhancement in z/OS R7 Language Environment not mentioned in the foil above. Prior to z/OS R7, youcould override the system-wide run-time options when you invoked a program with the PARM statement on the EXEC inthe JCL. However, this PARM statement had the JCL limit of 100 characters - that's a JCL limit and not specific toLanguage Environment.

Now, in z/OS R7, you don't have to specify run-time options on the PARM statement on the EXEC -- you can use theCEEOPTS DD statement instead - and thus get the 100 character limit removed. Both ways are supported in z/OS R7 -the old way with the 100 character limit on the PARM=, and the new way with the CEEOPTS DD statement.

If you've been running out of characters for run-time specifications on your PARM= in JCL, then this enhancement willhelp you. Note that the CEEOPTS DD is ignored under CICS, LRR, SPC, and for an exec()ed program.

Refer to z/OS Language Environment Customization for more information on z/OS R7 Language Environmentenhancements.



z/OS R7 BCP: IEARELEC Sample for Removing EMCS Consolesz/OS V1.7 delivers the support for deleting unused EMCS consoles. You can delete the definition of any extended MCSconsole, thus freeing the ID that had been assigned to the extended MCS console. The system then can reuse that ID fora newly-defined extended MCS console. To remove a console definition, use the sample JCL for program IEARELEC inSYS1.SAMPLIB. The following restrictions for removing an extended MCS console apply:

The extended MCS console must be inactive. Extended MCS consoles can only be removed on a z/OS V1R7 or higher system. The removal will becommunicated to systems at a lower level. The console ID of a removed extended MCS console can be reused once it has been deactivated and removed. It issafe to use the console ID to process a command response, but you should avoid saving the console ID for laterprocessing. Therefore, you should use the console name to direct messages to specific consoles. If the console ID isused, messages may end up going to unintended consoles. The console ID of a removed extended MCS console can only be reused by activating another extended MCSconsole on a z/OS V1R7 or higher system.

Sample invocations of IEARELEC://JOBA JOB ... //sss EXEC PGM=IEARELEC,PARM='CONSNAME(CONSOL01)' JOBA will attempt to remove the console named ‘CONSOL01’.

//JOBB JOB ... //sss EXEC PGM=IEARELEC,PARM='CONSNAME(CONSOL*)' JOBB will attempt to remove any console with a name that begins with ‘CONSOL’ (for example, CONSOL01,CONSOL02, etc.)

//JOBC JOB ... //sss EXEC PGM=IEARELEC,PARM='CONSNAME(SY?CON*)'




24© 2006 IBM CorporationMMigrating to z/OS 1.7 Part 3 of 3 - GO!


BCP: IEARELEC Sample for Removing EMCS Consoles

Before, there were long IPL and console data refresh times into a sysplex. Information on all EMCS consoles was sent across systems, including inactive EMCS consoles that are no longer needed.As of z/OS R7: you have the ability to remove inactive EMCS consoles that are no longer needed. This will allow reduced system refresh and IPL times into a sysplex.To use: All systems in a sysplex must be either z/OS V1R7 or have APAR OA06857 installed on any level between z/OS R4 and R6.A sample program (IEARELEC) is provided to show customers how to use the service that removes inactive EMCS consoles:

The service supports the wildcarding of console names.Must be APF-authorized.

Example: //MYJOB JOB ... //sss EXEC PGM=IEARELEC,PARM='CONSNAME(CONSOL*)'

JOBC will attempt to remove any console whose name has as its first two characters, ‘SY’, and its fourth thrusixth characters, ‘CON’ (for example, SY1CON1, SY1CON2, SY2CON1, SY2CON2, etc.)

When you specify CONSNAME(*) for IEARELEC, all EMCS consoles that are inactive and are not IBM internal consolesare removed.

Looking at the last example, this is the output you will see:Sample output from invoking IEARELEC:

//JOBC JOB ... //sss EXEC PGM=IEARELEC,PARM='CONSNAME(SY?CON*)'

Service generates the following hardcopy-only message:CNZ4002I EMCS CONSOLE REMOVAL FOR WILDCARD PATTERN SY?CON* FOUND: 4 REMOVED: 4 NOT REMOVED: 0 THE FOLLOWING EMCS CONSOLES WERE REMOVED: SY1CON1 SY1CON2 SY2CON1 SY2CON2

IEARELEC generates the following joblog message:

MRC104I ALL EMCS CONSOLES MATCHING THE WILDCARD PATTERN OF SY?CON* HAVE BEEN REMOVED

For more information on this function, refer to z/OS MVS Planning: Operations.



z/OS R7 JES2 and JES3: >64K Tracks for Spool Dataz/OS V1.7 provides support for large-format sequential data sets. Support is provided for nonextended-format sequentialdata sets larger than 64K tracks. This is in addition to previously provided support for extended-format data sets largerthan 64K tracks. JES2 and JES3 support using these larger data sets for spool data sets. Before using large-formatsequential data sets, refer to WSC Flash 10424 for important information. (Also, refer to informational APARII14094 which contains the same information.)

(In z/OS R7 SDSF, SDSF displays the information about JES2 spool volumes that is returned by the $DSPOOLcommand, including total spool utilization and individual spool volume utilization and status, for all membersof a multi-access spool cluster (MAS) from any member of the MAS.)

Because of the nature of the changes, down level releases cannot support these new larger spool volumes (in partbecause DFSMS on the down level z/OS systems do not support the larger data sets). As a result, a new external wasneeded in JES2 to “activate” the support in the initialization deck. There are no externals in JES3 to support thisenhancement. In JES2, the LARGEDS= parameter was added to SPOOLDEF for this enhancement. LARGEDS has three values,NEVER, ASNEEDED and ALWAYS.

NEVER does not allow any large data set to be used. It also allows down level JES2 member to co-exist with thislevel of JES2. ASNEEDED will activate the LARGEDS support (update checkpoint and change the format for new SPOOL controlblocks) and allow large data set to be started. ALWAYS is similar to ASNEEDED except you do not need a large volume to test the new format for MTTR. As such,ALWAYS is intended as a testing tool.

MTTR is the way the SPOOL is addressed using 4 bytes - M is SPOOL extent number, TT is the track address(up to 64K), and R is the record number.






JES2 and JES3: >64K Tracks for Spool Data Sets

Before, Current SPOOL was limited to 64K tracks. Newer DASD can have many more tracks, and you wanted to dedicate an entire volume to SPOOL. (PAV ensures that large SPOOLs perform well.)As of z/OS R7: Support added to allow SPOOL data sets to be up to 1M tracks. No, you can dedicate large volumes entirely to SPOOL!To use in JES3: No externals to use!To use in JES2: format of MTTR used to address records on SPOOL has changed

Plan for your exploitation. Once LARGEDS=ASNEEDED is set, pre-z/OS R7 JES2s cannot be warm started even if set to LARGEDS=NEVER.In JES2 initialization deck: SPOOLDEF=

NEVER does not allow any large data set to be used. It also allows down level JES2 member to co-exist with this level of JES2. ASNEEDED will activate the LARGEDS support (update checkpoint and change the format for new SPOOL control blocks) and allow large data set to be started. ALWAYS is similar to ASNEEDED except you do not need a large volume to test the new format for MTTR

Note! Downlevel systems cannot support new larger spool vols, as they don't understand nonextended-format sequential ds larger than 64K tracks!

With this support, the new SPOOL addressing method, 5 byte MTTTT, was defined (called MQT for short, Mquad T). In addition, there are places in the code that use a 6 byte MTTTTR (or MQTR for short).

Once LARGEDS is set to ALWAYS or ASNEEDED, down level JES2 members can never again enter the MAS (even ifLARGEDS is set to NEVER). The LARGEDS parameter has MAS scope and is honored in the initialization deck on aCOLD start and can be modified via a $T command. Once LARGEDS is set to ALWAYS or ASNEEDED, JES2 starts creating SPOOL control blocks that down level membersdo not know how to process. Because of this, once LARGEDS is set to ALWAYS or ASNEEDED, down level JES2scannot ever join this MAS (unless a cold start is done).

To start using this support, this is the preferred migration path to large SPOOL data sets for JES2. It minimizes the risk tothe system and provides a reasonable backout plan.1. On a test system, test applications that access SPOOL by setting LARGEDS=ALWAYS and starting a SPOOL

volume.2. Migrate to z/OS 1.7 JES2 on all MAS members3. Wait for z/OS 1.7 JES2 to stabilize (no need to fall back)4. $T SPOOLDEF to LARGEDS=ASNEEDED5. Stabilize with the new format of data areas6. Start a large SPOOL volume

Consider using SPOOL affinity to limit jobs using new SPOOL7. Once stabilized, drain old SPOOL volumes and migrate to new larger SPOOL data sets

Clear SPOOL affinities if used for testing earlier

REMEMBER, once LARGEDS=ASNEEDED is set, pre-z/OS 1.7 JES2s cannot be warm started even if set toLARGEDS=NEVER.

For more information, refer to the JES2 and JES3 publications.







Marna's "Big Migs" from z/OS R4 to z/OS R7

Migration Actions You Should NOT Overlook:z/OS R6 Architecture Level Set - must be z/Architecture mode

Use the z/Architecture checklist provided.z/OS R7 BCP 1-byte Console ID support removal

Use the Console ID Tracking Facility, introduced in z/OS R4 Consoles Enhancement feature with the latest exclusion list now.

z/OS R7 XL C/C++ does not ship the OS/390 R10 CompilersMove to the ISO C/C++ compilers now, may still use OS/390 R10 compilers from prior system.

z/OS R7 HCD IODF V5 Coexistence considerations with lower systemsz/OS R7 DFSMS JOBCAT/STEPCAT support removed.

Use the MODIFY CATALOG,ENABLE(JOBSTEPCAT) on R5 to turn support back on (for now!)

z/OS R7 JES2 Z2 - must be in Z2 mode!

z/OS R7 JES2 Exit and Input Processing changes

Future "Big Migs" You Can Mitigate NOW:Remove your dependency on the C/C++ IBM Open Class (IOC) Dynamic Link Libraries (DLLs)

Use the Standard C++ Library insteadz/OS DFSMS Imbed, Replicate, Keyrange removal in a future release.

Use the IMBDSHIP tool, and install PTF for APAR OA10952 now!Start your conversion from HFS to zFS after you migration to z/OS R7

Use z/OS R7's tool, BPXWH2Z to help.



Migration ActionsElement Specific Migration Actions for z/OS R7 (from z/OS R4):

DFSMS JOBCAT/STEPCAT not support on R7! Redefine IMBED, REPLICATE, and KEYRANGE VSAM ds..

HCD Update IODF to V5 level, remember coexistence considerations

JES2 Migrate to z2 mode!Get your exits prepared for changes. SYS1.HASLNKE.

Language Environment - Consider using new parmlib member CEEPRMxx to eliminate your assembler module run-time default options usermods.SMP/E - Migrate from CLIENT to FTP.DATA, Update firewall commands.z/OS UNIX - Migrate from central to distributed Byte Range Lock Manager. Move to zFS.

Installation Related Enhancements in R7Deliverables Enhancements ServerPac enhancementsFunctional Enhancements - USS Dynamic Service Activation, LE CEEPRMxx, Remove inactive EMCS consoles, JES Spool >64k Tracks

Summary: Migrating to z/OS 1.7 Part 3 of 3 - GO!

Documents

MigratingTo_zOSR7_Part3