FDRMOVE special considerations

Security

By default, every data set moved by FDRMOVE invokes security checks from the z/OS system allocation and catalog functions. The user ID under which FDRMOVE is running must be authorized to create and update all selected data sets. The security system overhead may be significant if many data sets are involved. For this reason, the default security is not recommended.

To reduce this overhead and better control security, FDRMOVE supports a security STGADMIN profile that allows FDRMOVE to bypass security while moving data sets. To invoke this support:

• Specify the STGADMIN operand on the MOVE or FASTMOVE statement, for example,

FASTMOVE TYPE=DSF,STGADMIN, other operands

• Authorize the user ID under which FDRMOVE runs to profile STGADMIN.ADR.STGADMIN.MOVE in class FACILITY (any authority, including READ, is adequate). All known security systems support such profiles
• If the user ID is authorized to that profile, all security checks from all system components invoked by the FDRMOVE job is bypassed. It does not affect any other jobs

The advantages of STGADMIN are:

• Security overhead is reduced
• The user ID under which FDRMOVE runs is authorized to move any data set, but has no authority to those data sets outside of FDRMOVE. This may be a significant advantage if a third party contractor is running FDRMOVE at your installation.

We strongly recommend specifying the STGADMIN operand in FDRMOVE jobs to use the STGADMIN.ADR.STGADMIN.MOVE profile for all FDRMOVE operations.

Security systems

It is possible that different security rules exist on various LPARs and that the security profiles for all the data sets that FDRMOVE selects do not exist on the LPAR where it is running. This causes security error messages unless STGADMIN is specified.

We recommend implementing STGADMIN in order to bypass this issue.

Allocation Control Packages

Your installation may have a software package that controls or influences the volumes on which new DASD data sets get allocated. Such packages include:

• Allocation Control Center (ACC) from DTS Software
• BMCMainView SRM from BMC Software
• CAAllocate DASD Space and Placement from Broadcom

There may be others.

If your installation's rules allow them to, these packages may override the selection of output volumes specified by the NVOL=, NEWSTORGRP=, and ENEWSTORGRP= operands of FDRMOVE. To allow the FDRMOVE control cards to be honored, you can either change the rules for the allocation control package, or add a special DD statement to the FDRMOVE JCL. The DD statement may be one of the following (or your installation may have specified a different DDNAME):

For ACC:

For MainView SRM (successor of POOL-DASD and ProSMS):

//PLDIGN DD DUMMY//PROIGN DD DUMMY//PROIGNOR DD DUMMY//BYPASPRO DD DUMMY

For CAAllocate (successor of VAM and VDS):

//VAMBYPAS DD DUMMY//VDSBYPAS DD DUMMY

Unmovable Table

Certain data sets in your system may be active without a SYSDSN enqueue, so FDRMOVE cannot tell that they are active. Such data sets should not be moved. There may be other data sets that have DASD-location dependencies; they should also not be moved.

To make it easier to avoid moving such data sets, FDRMOVE supports an “unmovable table”, a list of data sets that should not be moved. This unmovable table resides in the FDRMOVE program library. Actually, it is the same table that is used by COMPAKTOR (PGM=FDRCPK).

The unmovable table is converted into internally generated EXCLUDE statements for every FDRMOVE job and is shown in the control statement display.

The unmovable table distributed with FDRMOVE contains entries for:

• SYS1.VVDS.*
• SYS1.VTOCIX.*
• SYS1.LOGREC

You should identify additional data sets that are active without a SYSDSN enqueue, or that should not be moved for other reasons, such as:

• JES Procedure Libraries (PROCLIBs)
• JES SPOOL and Checkpoint data sets
• PAGE data sets (including PLPA and COMMON)
• Coupling data sets
• Tape Management System data sets
• LINKLIST Program Libraries
• CICS Journals
• SYS1.BRODCAST
• SYS1.MANx (SMF) data sets
• Security System data sets
• FDRMOVE Program Library
• Non SMS-managed APF-Authorized Program Libraries
• Data sets used by programs specified with the NODSI option in the Program Properties Table (PPT) (PARMLIB member SCHEDxx)

And add them to the table.

To update the table, go to the FDR ISPF main menu (see Unmovable Table) and then:

1. Enter “I” (for Install)
2. Enter “5” to update the COMPAKTOR Unmovable Table (also used for FDRMOVE)
3.  Make sure that the program library points to the FDRMOVE library and press Enter
4. Now you can add or edit entries

You must have UPDATE authority to the FDRMOVE program library since the table must be stored in that library.

System Volumes

Volumes in use by the operating system may have data sets that may not be enqueued and are continuously in use, such as:

• JES spool and checkpoint
• Page including PLPA and COMMON
• Coupling data sets
• LINKLIST data sets (If LINKLIST data sets are enqueued by LLA on your system, they do not need to be in the unmovable table)

You must either avoid moving the volumes containing these data sets, or add them to the unmovable table. Failure to do so may result in FDRMOVE moving the data sets, with possible system failure as the result.

Data sets that are indirectly cataloged (to a volume serial number of ****** for the IPL volume, or &SYSRx for an extended SYSRES volume) cannot be properly recataloged by FDRMOVE and should not be moved.

You must avoid moving these data sets and add them to the unmovable table or exclude these volumes from participating. However, you CAN move volumes containing these data sets non-disruptively with FDRPAS.

IBM RACF Data Sets

FDRMOVE identifies one active RACF data set for the current system and automatically excludes it. However, if you have more than one data set in the active primary RACF data base, or you have an active backup RACF data base, or you have separate RACF data bases for different systems, you should add all of the active RACF data sets to the Unmovable Table, since RACF does not enqueue its data sets. You CAN move volumes containing active RACF data sets non-disruptively with FDRPAS.

Temporary Data Sets

FDRMOVE automatically excludes temporary data sets by generating this EXCLUDE statement.

APF-Authorized Libraries

APF-authorized program libraries are specified in the PROGxx member of PARMLIB. Non SMS-managed APF-authorized libraries must specify the volume on which they reside, so if such a library is moved by FDRMOVE, it is no longer APF-authorized and may cause program failures. You can move the volume containing a non SMS-managed APF-authorized library data set non-disruptively with FDRPAS, or you can update and activate a new PROGxx member after moving the library.

SMS-managed APF-authorized are not a problem; they are authorized on any volume.

Catalogs

FDRMOVE cannot move ICF catalogs. Catalogs are automatically detected and excluded. A SIMMOVE warns you about all catalogs that cannot be moved.

To move a catalog, consult the IBM z/OS DFSMS Managing Catalogs (SC26-7409) manual. You may also want to read IBM informational APAR II13354 that has step-by-step instructions.

You can move a volume containing catalogs non-disruptively using FDRPAS.

Special Data Sets

Special data sets on each volume, such as the VTOC, VTOCIX, VVDS, and ABR Model DSCB are automatically excluded by FDRMOVE. They are specific to the volume they reside on and never need to be moved.

If you have changed the ABRINDEX value from the default of “FDRABR” in the FDR Global Options Table, ensure that you also change the ABRINDEX value to the same value in the FDRMOVE Options. Otherwise, ABR Model DSCBs are not determined as such and the entries are moved.

Generation Data Groups (GDGs)

Generation Data Groups (GDGs) are automatically handled. There are no special considerations for GDGs.

Connected Catalogs (Aliased Catalogs)

Installation running with multiple LPARs. We have found that many installations have catalogs that are not connected (aliased) on every LPAR. This is usually an oversight but it may be done on purpose.

If FDRMOVE moves data sets on an LPAR where its catalog is not connected, FDRMOVE treats them as uncataloged data sets. VSAM data sets in these catalogs give an error message, while non-VSAM data sets are moved without updating any catalogs. Non-VSAM data sets allocated and moved to non SMS-managed volumes do not update the catalog. Non-VSAM data sets allocated and moved to SMS-managed volumes are cataloged using the catalog structure of the system where FDRMOVE is run.

Therefore, you must check all LPARs for this condition before running FDRMOVE.

IBM DFSMShsm Migration Volumes

DFSMShsm Migration volumes on DASD must be excluded from FDRMOVE since the DASD volume that the migrated data set resides on is required for DFSMShsm to properly locate the migrated image so the data set can be restored. However, FDRPAS can move the entire migration volume since the DASD volume serial number would remain the same.

Uncataloged Data Sets

If some data sets are cataloged in a catalog that is not active on all systems, be sure to run FDRMOVE for those data sets on a system where they are cataloged. Otherwise, FDRMOVE treats them as uncataloged data sets. Non-VSAM data sets allocated to non SMS-managed volumes are moved without updating any catalogs, which may cause failures on systems where they are cataloged. Non-VSAM data sets allocated to SMS-managed volumes are moved and cataloged using the catalog structure of the system where FDRMOVE is run. Uncataloged VSAM clusters are not moved.

Data sets may erroneously appear to be uncataloged if their alias is not connected to the proper user catalog on one or more systems.

Volumes that are copies of online volumes may appear to contain data sets that are not cataloged. These volumes should not be moved with FDRMOVE. They include:

• Volumes created by DFSMSdss full-volume COPY without the COPYVOLID option
• Volumes created by IBMTDMF for backup purposes
• The original source volume of a IBMTDMF migration
• Volumes created by TSO FlashCopy commands (for example, FCESTABL)
• Volumes created by EMC SPLIT of a BCV, or EMCSNAP, if the target is online after the operation
• There may be other volumes of this type

FDREPORT can be used to identify uncataloged data sets. Member MOVREP04 in the JCL library is an example of an FDREPORT job that identifies data sets that are not cataloged or cataloged to nonstandard catalog structures.

Unmovable Data Sets

PS, PO, and DA data sets on non SMS-managed volumes can be marked as unmovable in the Format 1 DSCB (via DSORG=PSU, POU, or DAU). An unmovable data set can ONLY be moved to the same track addresses on the output volume as it occupied on the input volume. An unmovable data set with more than three extents cannot be moved by FDRMOVE.

Archived Data Sets

Data sets that are archived only have catalog entries that indicate their archive status. Since these data sets are not physically on DASD, FDRMOVE does not change the catalog entries for these data sets.

Data Sets Cataloged in Multiple Catalogs

If you have separate master catalogs for your various systems, certain system data sets may be cataloged in each catalog. FDRMOVE can only update the catalog for the system it is running on, so it is the user's responsibility to update the other catalogs.

SMS Class Consideration

When an SMS-managed data set is moved, the SMS class names (data class, management class, and storage class) are retained, unless the user changes them with the MGMTCLAS= or STORCLAS= operands. The data class cannot be changed. The Automatic Class Selection (ACS) routines are not called, and the class names are not checked for validity.

FlashCopy and EMCSNAP

FlashCopy and EMCSNAP do not support cascading relationships. In other words, if a data set on the source volume is currently the target of a Flash or Snap that has not completed, then Flash or Snap cannot be used to copy the data set to the FDRMOVE target volume. In this case, normal read/write I/O is used to copy the data sets.

If FASTMOVE used FDRPAS to move a volume to a transit station, this is not an issue unless new Flash or Snap has been issued since that move.

EMCSNAP is not used on data sets less than 15 tracks.

DSCB Fields

After a data set is moved with FDRMOVE, the Update Flag (DS1IND02) is turned “ON” and the Last Referenced Date is unchanged.

FlashCopy on HDS DASD

FlashCopy is used to process data sets to a PPRC/Truecopy/HUR Primary volume by default. In some configurations, it is advisable to disable this feature, since the remote mirror is considered inconsistent during the “pending duplex state” created by use of FlashCopy replication.

There are 2 options available:

• Specify “INSTANT=NO” on the MOVE command statement to prevent the use of FlashCopy.
• Use TGTPPDEF=NO. (Default: YES)
  • This option (A.I.4.19) disables the ability to Flash to PPRC primary volumes. A FlashCopy will be attempted and return with SENSE x‘0F x ‘85’, but will revert to Normal I/O.
  • This allows FlashCopy use on other data sets being processed by the jobstream.

HDS FlashCopy is not used on data sets less than 15 tracks.

Hitachi has a limitation on the number of active FlashCopy extents per volume, so if many data sets or extents must be copied, this limit may be exceeded. If the limit is exceeded it uses normal I/O to complete the move. To find out what your limit is, issue the TSO command TSO FCQUERY DEV(uuuu); specify a device in the source control unit and also in the target control unit, whichever ones are HDS DASD. The output looks like this.

Display Max Active FlashCopy Extents – TSO FCQUERY DEV(17FC)

MAX is the maximum number of FlashCopy extents supported per volume, and ACT is the number currently active.

Hitachi has a limitation of on the total active FlashCopy extents per control unit, which is set by the HDS CE.

FDRINSTANT

If you are using FDRINSTANT to do full-volume backups of the FASTMOVE source volumes, you should be aware that FDRINSTANT might not work while a volume is in a transit station. This is because the volume will no longer be in the same DASD subsystem as your FDRINSTANT target devices. This also applies to other software that depends on fast replication facilities.

Obviously, if you intend to backup the new FDRMOVE target volumes, you need to setup new FDRINSTANT jobs for those volumes.

FASTMOVE Performance

The data rate depends on the configuration, the number of FASTMOVE subtasks, the number of data sets to be moved, and other factors. FASTMOVE can typically move up to 1TB of data per minute, residing within no more than 250 data sets moving 16 volumes concurrently. FASTMOVE can typically allocate, catalog and move over 1000 small data sets per minute with 16 concurrent volumes. Moving 16 concurrent volumes requires 2 FDRMOVE jobs running concurrently.

Although FASTMOVE uses FlashCopy, EMCSNAP, or Snap to quickly move data sets from the transit stations to the target volumes, performance can be affected by a number of factors. FASTMOVE does not use a large amount of CPU time, but if sufficient resources are not available to the FASTMOVE task, it impacts performance.

It is highly recommended that the Indexed VTOC (VTOCIX) be active on all source and target volumes, in order to improve performance.

Since FDRMOVE must update the catalog for every data set or component moved, catalogs should be tuned for performance. See the IBM z/OS DFSMS Managing Catalogs (SC26-7409) manual for guidance.

Transit Stations

FASTMOVE works best when the number of offline transit station devices equals or exceeds the number of input volumes. FASTMOVE is able to move all the input volumes to a transit station. Then, when you “bounce” the application that is using the data sets, all of them can be moved at once.

However, it may not be possible to provide a sufficient number of transit stations. FASTMOVE still works, but in stages. It moves input volumes to the transit stations until it runs out of stations. The FDRMOVE ISPF panel or the console STATUS command shows you what volumes are in transit stations and what data sets FASTMOVE is waiting for. Now when you bounce the application FASTMOVE moves the selected data sets from the transit stations.

Assuming that all selected data sets on that set of input volumes have been moved, they are swapped back to their original devices, and other volumes move to the transit stations. Now, you can bounce the application again to move the data sets from those volumes. This is repeated until all selected data sets have been moved.

IBM HyperSwap and EMC AutoSWAP

You cannot use FDRMOVE with FASTMOVE TYPE=DSF if IBM GDPS HyperSwap, IBM Basic HyperSwap, or EMC AutoSWAP is active on the source DASD; HyperSwap and AutoSWAP volumes fail in the FDRPAS TRANSIT step. However, FDRMOVE supports HyperSwap and AutoSWAP volumes with MOVE TYPE=DSF.

CSA and ECSA Usage

FDRMOVE has no special CSA or ECSA usage, the same as any batch job.

The FDRPAS TYPE=TRANSIT job uses a small amount of CSA/ECSA while a volume is actively being moved to or from a transit station.

Enqueues and Reserves

FDRMOVE requires that SYSDSN enqueues (data set name enqueues) be propagated as global enqueues to all systems, so that it can determine what data sets are active. This is a standard procedure for all sites with shared DASD.

However, with multiple sysplexes or monoplexes, the SYSDSN enqueue must be propagated to all plexes where the data set may be in use.

FDRMOVE has no special consideration for hardware reserves. There is no requirement that all reserves be converted to global enqueues.

CA MII (CAMIM)

FDRMOVE does a conditional enqueue on SYSDSN for each data set to be moved. Since it does this as it is reading the VTOC of a source volume, it might enqueue many data sets in a very short period.

• If you are using CA MII (Multi-Image Integrity component of CAMIM), prior to release 11.6, this may result in a large number of contention messages from MII, which may flood and backup your console.
• To suppress these messages, see member FDRCONXT in the Installation Control Library (ICL) installed with FDRMOVE. This describes a CA MII exit that can be activated by a MIM console command to suppress those messages for FDR programs and it does not affect any other MIM operations.

CA MII does not support GQSCAN (except for the LPAR that FDRMOVE is executing on) so that FDRMOVE cannot determine the job names if it is owned on other system. If the data set is enqueued on this LPAR and also on other LPARs, FDRMOVE may display the local job names plus the MII address space name.

The following message is displayed by a SIMMOVE or a STATUS or ISPF monitor if the data set is not enqueued on this LPAR; it may or may not be enqueued on another system but FDRMOVE cannot determine its enqueue status.

If you run a SIMMOVE on each LPAR, then you can determine which jobs are holding the enqueues.

Multi-Volume Data Sets

FDRMOVE must always move multi-volume data sets to the same number of volumes they currently occupy. When moving multi-volumes, the NVOL= list must always contain sufficient volumes to contain the data set. However, it is possible to move one or more pieces of a multi-volume data set without moving the rest.

You can run a SIMMOVE step that looks for multi-volume data sets. For each input volume, it displays the highest number of volumes (HIGHEST SEQ#). Take the highest number as the minimum number of NVOL= volumes to move these data sets successfully. This does not work for non SMS-managed VSAM clusters.

If you do not provide sufficient NVOL= volumes, then the FDRMOVE step gets an error message similar to this.

FDR156** ALLOCATE FAILED FOR 00001 TRK COMP=X'0004-041C0416' VOL=vol DSN=dsn

VOL= is the first volume that FDRMOVE tried. The message shows COMP=X'0014 if there was insufficient space on the first volume tried, and there was no other place to put the data sets on the NVOL volumes.

Candidate Volumes

SMS-managed VSAM clusters with candidate volumes are handled automatically:

• If the SMS storage class is not guaranteed space, then candidate volumes are simply asterisks (*) in the catalog and do not need to be updated.
• If the SMS storage class is guaranteed space, then a “candidate space” is created on each candidate volume. FDRMOVE will move these candidate spaces if the volume is selected (CATDSN= or ALLDSN).

For SMS-managed non-VSAM data sets with candidate volumes are handled automatically:

• If the SMS storage class is not guaranteed space, then candidate volumes are simply asterisks (*) in the catalog and do not need to be updated.
• If the SMS storage class is guaranteed space, then a “candidate space” is created on each candidate volume. FDRMOVE moves these candidate spaces if the volume is selected (CATDSN= or ALLDSN).

Non SMS-managed VSAM clusters with candidate volumes are handled:

• Candidate volumes are marked as candidates in the catalog. FDRMOVE updates the candidate list if there are sufficient unused volumes in the NVOL= list, after all active pieces of the cluster are moved. If there are not sufficient unused volumes, some candidates are updated and some are not. If a cluster has the IMBED attribute (no longer supported by IBM) then candidates are not updated.

Non SMS-managed non-VSAM data sets:

• Specific candidate volsers (these are very rare) appear in the catalog when you provide extra volsers at allocation time. They are not marked in any special way by IBM and do not appear in the DASD VTOCs so FDRMOVE does not update the volsers.

For non SMS-managed volumes where FDRMOVE was not able update the candidate volsers, you need to locate these data sets and use the IDCAMS ALTER command with REMOVEVOLUMES to delete the candidates and ADDVOLUMES to add new candidates. Note that the number of candidate volumes required may be less on the new DASD volumes than on the old DASD volumes because the new DASD are so much larger; you may not need any candidates.

A SIMMOVE step with VTOCEMPTY=CHECK and SELECT CATDSN= with NVOL= (for all possible new volsers) identifies all pieces of multi-volume data set that have not been moved to those NVOLs, including candidate volsers for VSAM.

Hierarchical File System (HFS) and z/OS File System (zFS) Data Sets

FDRMOVE can move Hierarchical File System (HFS) and z/OS File System (zFS) data sets (used by UNIX System Services (USS)) as long as they are not active. FDRMOVE does not quiesce these data sets, so it is your responsibility to free the data sets if they must be moved. With FDRPAS, the entire volume these Hierarchical File System (HFS) and z/OS File System (zFS) data sets are on can be moved regardless if they are active or not.

DISABLENEW= Option of FDRMOVE

If you specify the FDRMOVE option DISABLENEW=YES, then FDRMOVE sets all input SMS-managed volumes to a status of DISNEW and non SMS-managed volume to a mount status of PRIVATE. The purpose of DISABLENEW= is to prevent new allocations to the input volumes once the move starts, assuming that the user wants to completely empty the input volumes and direct new allocations to the output volumes. For SMS, the input and output volumes would typically be assigned to the same storage group, allowing the new allocations to naturally flow to the new volumes.

The SMS status of DISNEW is very effective for accomplishing this. However, there is a consideration. If a new SMS configuration is activated (the SMS “ACTIVATE” function), then all volumes are set to the SMS status indicated in the SCDS being activated. Since the FDRMOVE input volumes were originally marked as ACTIVE in the configuration, the ACTIVATE will probably return them to ACTIVE, allowing new allocations to go to those volumes.

Before you activate a new SMS configuration, during or after an FDRMOVE operation, you must set those input volumes to DISNEW in that configuration before activation. This is very important. You must communicate this to any group or person who may do an ACTIVATE.

Also, if you have separate SMS configurations for each LPAR, DISABLENEW=YES only disables the volumes on the current LPAR, so you are responsible for manually disabling the volumes on the other LPARs before moving any data sets.

An IPL does not reset the volume status, only an ACTIVATE.

Extended Address Volumes (EAVs)

Before z/OS V1R10, DASD storage was limited to 65,520 cylinders per volume. z/OS V1R10 supports Extended Address Volumes (EAVs), which are by definition 65,521 cylinders or larger. The maximum size of a volume is 262,668 cylinders with z/OS V1R10.

In z/OS 1.13 and higher, an EAV volume can be up to 1 TB in size (1,182,006 cylinders).

The cylinder addresses greater than 65,535 on an Extended Address Volume (EAV) are referred to as the Extended Address Space (EAS). These cylinder addresses are represented by 28-bit cylinder numbers. The cylinder addresses below 65,536 on an Extended Address Volume (EAV) are referred to as the base addressing space. These cylinder addresses are represented by 16-bit cylinder numbers or by 28-bit cylinder numbers whose high order 12 bits are zero.

The track address with 28-bit cylinder numbers has the following format: track address is a 32-bit number that identifies each track within a volume. It is CCCCcccH in the hexadecimal nibbles format where:

• “CCCC” is the low order 16 bits of the cylinder number,
• “ccc” is the high order 12 bits of the cylinder number, and
• “H” is the four-bit track number.

Extended address volumes are divided into track-managed space and cylinder-managed space.

• Track-managed space is the space on the volume that is managed in tracks and cylinders. Track managed space ends at cylinder address 65,519. Each data set occupies an integral multiple of tracks. Track-managed space also exists on all non-Extended Address Volumes (EAVs).
• Cylinder-managed space is the space on the volume that is managed only in Multi-Cylinder Units. A Multi-Cylinder Unit (MCU) is 21 cylinders. Cylinder-managed space begins at cylinder address 65,520. Each data set occupies an integral multiple of Multi-Cylinder Units (MCUs). Space requests targeted for the cylinder-managed space are rounded up to the next Multi-Cylinder Unit. Cylinder-managed space only exists on Extended Address Volumes (EAVs). An EAS-eligible data set is one that can be allocated anywhere on an EAV.

EAS-eligible data sets allocated on an EAV are created with Format 8 and Format 9 DSCBs in the VTOC. A Format 8 DSCB is equivalent to a Format 1 DSCB and the Format 9 DSCB provides additional attribute data and a set of pointers to possible Format 3 DSCBs.

For an Extended Address Volume (EAV), the system and storage group breakpoint value (BPV) helps direct DASD space requests to cylinder or track-managed space. The breakpoint value is expressed in cylinders. When the size of a DASD space request is the breakpoint value or greater, the system prefers to use cylinder-managed space for that extent. This rule applies to each request for primary or secondary space for data sets that are eligible for cylinder-managed space. If cylinder-managed space is insufficient, the system uses the track-managed space or uses both types of spaces. When the size of a DASD space request is less than the breakpoint value, the system prefers to use the track-managed space. If space is insufficient, the system uses the cylinder-managed space or uses both types of spaces. The breakpoint value (BPV) is specified in the IGDSMSxx PARMLIB member. This parameter is optional and if not specified, the default value of 10 cylinders is used. A breakpoint value can also be specified for each storage group and overrides any value in the IGDSMSxx PARMLIB member.

EAS-eligible data sets include the following:

• SMS-managed and non SMS-managed VSAM data sets
• zFS data sets
• Sequential data sets, including extended, basic, and large formats
• PDS and PDSE data sets
• Direct (BDAM) data sets
• Data set allocated with undefined DSORGs

Non-EAS eligible data sets include:

• HFS data sets
• PAGE data sets
• VTOC and VTOC index data sets
• VSAM data sets with IMBED or KEYRANGE attributes

EATTR=OPT Considerations

The FDRMOVE MOVE function supports EATTR=OPT allowing the MOVE process to allocate data sets in the cylinder-managed space of Extended Address Volumes (EAVs). The allocation of data sets in the cylinder-managed space by FDRMOVE follows these rules:

• For a non-VSAM data set, if the file has EATTR=OPT specified in the DSCB, or if the EATTR=OPT keyword is specified on the MOVE command and the file does not have EATTR=NO specified in the DSCB, the FDRMOVE MOVE function allows the allocation to go to cylinder-managed space.

– A single-volume non-VSAM data set is allowed to round up to a multiple of 21 cylinders according to the normal allocation rules. That is, if the size is equal to or larger than the breakpoint value (BPV; default is 10 cylinders), the data set is allowed to be rounded up and allocated in cylinder-managed space.

– A multi-volume non-VSAM data set is not allowed to round up. If the size is not a multiple of 21 cylinders, the allocation is allowed to be split between cylinder-managed space and track-managed space. If the size is less than 21 cylinders, the data set is allocated in track-managed space.

• VSAM clusters are eligible to be allocated in cylinder-managed space by default; EATTR=OPT does not need to be specified.
• If the part of the data component on the current volume is a multiple of 21 cylinders, it is allocated in cylinder-managed space.
• If the part of the data component on the current volume is not a multiple of 21 cylinders, and it is in more than one extent, the allocation is allowed to be split between cylinder-managed space and track-managed space. For example, a component with 22 cylinders may get 21 cylinders in cylinder-managed space and 1 cylinder in track-managed space.
• If the part of the data component on the current volume is not a multiple of 21 cylinders, and it is in one extent:
  • If the cluster is single-volume, and the component is larger than 105 cylinders, then it is rounded up to a multiple of 21 cylinders and allocated in cylinder-managed space. For example, a component with 106 cylinders is rounded up to 126 cylinders.
  • If the cluster is single-volume, and the component is smaller than 105 cylinders, then it is allocated in track-managed space with the same size.
  • If the cluster is multi-volume, then regardless of size, the component is allocated in track-managed space with the same size.
• Index components of VSAM clusters are always allocated in track-managed space with the same size unless the index component is a multiple of 21 cylinders.
• Clusters that have IMBED or KEYRANGE attributes are always allocated in track-managed space with the same size.