Converting REJECT commands to PRTITION and OPENRULE commands

If you use REJECT commands, you have to convert from the use of REJECT commands in order to use the PRTITION and OPENRULE commands. Review your existing REJECT commands across all system images and identify the sets of volumes to be used on each system. Identify the PRTITION and OPENRULE commands required for each system to minimize parmlib maintenance as your storage requirements change. Until you define one or more PRTITION or OPENRULE commands, both partitioning and rejecting of volumes are controlled by REJECT commands. Any REJECT commands that specify ANYUSE are used for partitioning of undefined volumes, but all REJECT commands are used for rejecting volumes at OPEN time.

When you use either PRTITION or OPENRULE commands, the REJECT commands are no longer used so you must start using both PRTITION and OPENRULE at the same time to avoid loss of function. You have to remove the REJECT commands from parmlib, because they will fail when any PRTITION or OPENRULE commands are defined. When parmlib is processed, DFSMSrmm issues message EDG0239E, followed by message EDG0215D to provide an option to ignore the error or fail and then retry with message EDG0107D with another parmlib member. When you have created your new commands, remove the REJECT commands. The PRTITION and OPENRULE commands can only be used on z/OS V1R10 and later releases. Lower level releases continue to use the REJECT commands.

To give you more choice and flexibility, conversion from REJECT commands should not be done one to one and should not be automated. When each REJECT command is converted strictly to an equivalent PRTITION and OPENRULE command, you can end up with too much complexity and duplication. The best approach is to start from scratch and list the basic rules you want to implement. See Identifying basic rules for additional information. In addition to understanding the basic rules, you must also consider the changed function and whether you are affected by it:

For volumes not defined to DFSMSrmm, the REJECT command with ANYUSE causes CUA requests to fail. With the PRTITION command, you can choose between the actions of either ACCEPT or IGNORE. You no longer have the option to fail a CUA request. The ACCEPT action results in the volume being added to DFSMSrmm and the CUA continues. The IGNORE action causes DFSMSrmm to take no action for the CUA request.
For non-system-managed volumes that are not defined to DFSMSrmm, the default processing during OPEN did not add the volume to the CDS. The default processing for the PRTITION command is that non-system-managed volumes are added to the CDS.

Examine any existing EDG_EXIT100, EDG_EXIT200, and CBRUXENT installation exits to determine whether they contain customization that is no longer needed. The PRTITION and OPENRULE functions should allow the removal of almost any customization related to partitioning, rejecting volumes, and ignoring volumes. The existing installation exit customization need not be removed immediately, but can be used alongside the new function, and removed only when it is certain that they are no longer needed. Any existing customization of CBRUXENT and EDG_EXIT200 can very likely be replaced by the use of PRTITION parmlib commands. Any existing EDGUX100 function that controls use of a volume, that might fail the open of a tape data set, or reject a volume, or enable volumes to be ignored without coding EXPDT=98000, can likely be replaced by the use of OPENRULE parmlib commands.

Follow these steps:

Review customization of installation exits and identify the OPENRULE and PRTITION commands that can be used instead
Identify your global PRTITION and OPENRULE commands
Review your requirements across all systems images and identify which sets of volumes should be used on each system. Identify the PRTITION and OPENRULE commands required for each system to minimize parmlib maintenance as your storage requirements change
Code the new parmlib commands.
DFSMSrmm provides an option to have a common parmlib member and then a system-specific parmlib member for each system. The global PRTITION and OPENRULE commands are good candidates for the common parmlib member and the more specific volume sets related commands are best placed in the system specific parmlib member.
Create new parmlib members ready for implementation, leaving the existing parmlib member as a fallback
Refresh DFRMM started procedure to use the new parmlib members (F DFRMM,M=xx)
Plan to remove at a later time exit customization and remove the old parmlib member that is no longer required for fallback.