DFSMDA macro

Use the Dynamic Allocation macro (DFSMDA) to build a member (that is, one or more parameter lists) for naming data sets that can participate in dynamic allocation and deallocation. Members include databases, DEDBs, and data sets.

To use DFSMDA you must catalog all specified database data sets. However, you do not need to initially allocate them through control region JCL.

IMS users and IBM® CICS® Transaction Server for z/OS® users can dynamically allocate IMS databases. For Fast Path databases, if the database data sets to be allocated are registered in DBRC, the information required to dynamically allocate the data sets is obtained from DBRC. You do not need to supply DFSMDA members for them. When the dynamic allocation information is obtained from DBRC, the DISP= used to allocate the data sets is either DISP=OLD or DISP=SHARE depending on the following:

If SHARELVL=0, DISP=OLD is used.
If SHARELVL=1, 2, or 3, DISP=SHARE is used.

DFSMDA is not a system definition macro.

The priority of allocation information is shown in the following table.

Table 1. Allocation information priorities
	DBRC	DD statement	DFSMDA member
DEDBs and MSDBs	1	2	3
All others	N/A	1	2

Database data sets specified in DFSMDA are allocated at different times depending on whether you are running in an IMS DB/DC, IMS batch, or CICS environment. The environment requirements are:

IMS DB/DC database data sets are allocated either when a /START command is issued for the database or when an IMS application program is scheduled. You deallocate the data set by the /DBR command. If a database data set is specified in the JCL, it is allocated by z/OS during control region startup. You can deallocate it with the /DBR command and reallocate it with the /START command.
IMS batch database data sets are allocated near the beginning of the job step, before the batch application starts execution.
Dynamic allocation is always attempted for all non-JCL allocated databases defined in the PSB being executed. This is performed by searching the JOBLIB/STEPLIB concatenation for DFSMDA members, unless dynamic allocation is disabled (for batch only) by the presence of the NODYNALLOC statement in your DFSVSMxx member.
If a batch job uses a PSB with more database PCBs than are necessary for a particular job, you can avoid dynamic allocation of the unnecessary databases while still maintaining a library of DFSMDA members for all databases belonging to the PSB. You have two methods of doing this:
- You can include the NODYNALLOC statement in your DFSVSMxx member and include DD statements for only the necessary databases in your job JCL. The library of DFSMDA members does not need to be removed from the JOBLIB/STEPLIB concatenation because the NODYNALLOC statement disables batch dynamic allocation.
- You can maintain separate libraries of DFSMDA members, which can be included or excluded from the JOBLIB/STEPLIB concatenation as needed. DFSMDA members need not be kept in your IMSVS.SDFSRESL.
  For example, you can maintain one main library of DFSMDA members for all the databases for a PSB and maintain several subset libraries. You concatenate only the library that is appropriate for the job being run. Dynamic allocation searches the entire JOBLIB/STEPLIB concatenation for DFSMDA members, so you must remove or alter all libraries that contain undesired members.
If the databases for which your program has update intent have logical relationships or secondary indexes, those additional databases containing the logical relationships or secondary indexes can also be allocated, whether by JCL or DFSMDA members. To cause dynamic allocation of a logically related database, change the PROCOPT to indicate update intent. To dynamically allocate a secondary index, change the PROCOPT to indicate update intent or include a PCB with PROCSEQ= for the secondary index.

If the PCB specifies a PROCOPT that does not indicate update intent, no intent is propagated to a logically related database or to a secondary index, and dynamic allocation is not attempted for either of these related databases.
CICS database data sets are allocated when an application program issues a schedule call for the PSB. Deallocation occurs, for example, during the processing of STOP and RECOVERDB commands issued against the database.

You can dynamically allocate online log data sets (OLDS), write ahead data sets (WADS), and system log data sets (SLDS) if they are named in the DFSMDA macro. The DFSMDA macro must be defined to permit SLDS input to IMS to restart in z/OS.

When you start an OLDS using the /START command, the OLDS must be defined in the DFSMDA macro, even if it is allocated in JCL.

The IMS Monitor data set can also participate in dynamic allocation and deallocation. The IMS Monitor data set is allocated when it is started with the /TRACE ON command and deallocated when it is stopped with the /TRACE OFF command. It need not be initially allocated through JCL. It must not be cataloged if residing on tape; it must be cataloged if on DASD.

Recommendation: If you use the multiple DEDB area data set facility, register all data sets belonging to that area in either DBRC or DFSMDA.

The specified areas are allocated either when a /START command is issued for the area or when an application program attempts to use the area. The area is deallocated by /STOP AREA. Multiple areas can be deallocated by /STOP ADS.

In an XRF environment, all database and area data sets must be dynamically allocated.

Supported environments

The IMSDALOC macro can be used in the IMS DB/DC, BATCH, and DBCTL environments.

Syntax

The DFSMDA macro is coded as a z/OS macro. The statement label is optional, the macro DFSMDA is coded after one or more blanks, and additional parameters are separated by blanks. z/OS continuation rules apply.

The DFSMDA macro has several statement types (as indicated by the TYPE= parameter), each of which uses different additional parameters. Code the statements types as follows:

One TYPE=INITIAL statement to start the parameter list build.
As many of the other TYPE= statements as necessary. The maximum number of TYPE=DATABASE statements allowed is 250.
One TYPE=FINAL to end the list.

TYPE=INITIAL statement

This statement indicates the start of a parameter list build and is required. No other parameters are valid on a TYPE=INITIAL statement. The format of this statement is:

TYPE=CATDBDEF statement

This statement defines the dynamic allocation parameter list for the IMS catalog partition definition data set. This data set contains the definitions for the catalog HALDBs that are not defined in the DBRC RECON data set. The DD name of the catalog partition definition data set is DFSHDBSC.

DBNAME=: Specifies the DBD name of a Catalog database whose data sets are to be dynamically allocated. This name is used as a member name in IMS.SDFSRESL to identify this database parameter list.

DSNAME=: The name of the IMS catalog partition definition data set. The name can be any combination of simple and compound names that are valid in JCL, but cannot contain any special characters.

TYPE=CATDSHLQ statement

This statement defines the high level qualifier name to use when creating or allocating the system data sets of the IMS catalog. The system data sets of the IMS catalog include the IMS directory data sets, the bootstrap data set, and the staging data set.

DDNAME=: The alias name of the IMS catalog database to which the system data sets belong followed by the characters HLQ. For example, DDNAME=CAT1HLQ.
The xxxx value that you specify on DDNAME must match the alias name for the IMS catalog that is defined on the ALIAS= parameter in the CATALOG section of the DFSDFxxx PROCLIB member.

SYSDSHLQ=: The high level qualifier name to use when creating or allocating the IMS catalog system data sets. The name can be any combination of simple and compound names that are valid in JCL, but cannot contain any special characters.

TYPE=DATABASE statement

This statement specifies the start of the definition for a database to participate in dynamic allocation and deallocation: one or more TYPE=DATASET statements should follow. (Do not use this statement for a DEDB area.) The format of the statement is:

DBNAME=: Specifies the DBD name of a database whose data sets are to be dynamically allocated. This name is used as a member name in IMS.SDFSRESL to identify this database parameter list. Care should be taken to ensure that this name does not conflict with existing members in IMS.SDFSRESL. This includes, but is not limited to, IMS modules and user-supplied exit routines.

TYPE=DATASET statement

This statement defines either a data set within the database specified in the previous TYPE=DATABASE statement or a DEDB area. One complete TYPE=DATASET is used for each data set or area data set defined. Every data set within a database to be dynamically allocated and deallocated must be named in a TYPE=DATASET statement. When defining dynamic allocation of IMSACBA or IMSACBB, the TYPE=IMSACBA or TYPE=IMSACBB statement is followed by one or more TYPE=DATASET statements. When defining DEDB areas, a TYPE=FPDEDB statement must precede each TYPE=DATASET statement. If the data set within a database identifies a secondary index data set shared with another database, the DFSMDA members for the two databases must be generated in separate assemblies. The format of this statement is:

DSNAME=: Specifies the name of the data set. The name can be any combination of simple and compound names valid in JCL, except the name cannot contain special characters.
DDNAME=: Specifies the name of the DD statement defining this data set. This name is the same as that used in the DATASET or AREA statement of the DBDGEN.
For multiple ADSs, this name is the same as the ADDN name registered in the ADS RECON data set.
DISP=: Specifies the disposition of this data set when allocated. The default is OLD.

TYPE=DFSDCMON statement

Include one TYPE=DFSDCMON statement to define the dynamic allocation parameter list for the IMS Monitor data set. The format of this statement is:

DSNAME=

Specifies the name of the data set, which must not be cataloged if the unit defines a TAPE device. However, if UNIT=DASD is specified, then the data set must be cataloged and available. The name can be any combination of simple and compound names valid in JCL, but must not contain special characters.

DDNAME=IMSMON

Is the required value for DDNAME.

UNIT=

Specifies the unit for the DC Monitor data set. If the data set resides on a direct access device, UNIT=DASD must be specified and the data set must be cataloged. Otherwise, the value of UNIT= can be the name of any tape device valid to the installation. The default is UNIT=TAPE.

BUFNO=

Specifies the number of buffers for the IMS Monitor data set. Valid numbers range from 2 to:

a maximum of 99 for DFP
255 for DFSMS

The default is 5.

Changes to BUFNO will not take effect until the next start of IMS. The initialization of these values is done only once after an IMS start.

BLKSIZE=

Specifies the block size for the IMS Monitor data set. For a tape device (UNIT≠DASD), the default is 32 KB. If UNIT=DASD, the default is 27 992.

Changes to BLKSIZE will not take effect until the next start of IMS. The initialization of these values is done only once after an IMS start.

DISP=

Specifies the disposition for the IMS Monitor data set for a UNIT=DASD data set definition. Valid values are OLD and SHR. OLD is the default if this parameter is not supplied. A warning message is issued if any other value is supplied, and a DISP=OLD value overrides the value specified.

TYPE=FPDEDB statement

This statement defines an area within a data entry database (DEDB). One TYPE=FPDEDB statement is required for each area to be specified. The format of this statement is:

DBNAME=: Specifies the DBD name of the DEDB in which the specified area resides. This parameter is optional, and is used for documentation purposes only. For DEDB areas, the IMS.SDFSRESL parameter list is not named with the database name, but rather with the area's ddname.

TYPE=IMSACB statement

IMS uses the TYPE=IMSACB statement to dynamically create the staging library during the ACB library member online change process.

The HALDB alter function also uses dynamic allocation of the staging ACBLIB and requires that the staging ACBLIB be available throughout alter processing until the online change function completes the alter process.

The ACB library member online change function works only in an IMSplex environment, where the global online change process is supported. You can optionally include the IMSACB DD statement in the IMS procedure rather than the DFSMDA macro to dynamically allocate the staging ACBLIB. See this topic for an overview of dynamically allocating the staging ACBLIB: Dynamically allocating the ACB staging library for ACBLIB member online change.

The format of this statement is:

DSNAME=: Specifies the name of the data set. The name can be any combination of simple and compound names valid in JCL, except that it cannot contain special characters.

TYPE=IMSACBA statement

IMS uses the TYPE=IMSACBA statement to create the dynamic allocation member to allocate the IMS IMSACBA library data sets. Using DFSMDA to dynamically allocate IMSACBA allows you to resize the inactive ACBLIB data sets, add data sets to the concatenation, or change data sets in the concatenation without bringing IMS down. See the following topic for an overview of dynamically allocating the IMSACBA data set: Dynamically allocating the IMSACBA and IMSACBB library data sets.

The format of this statement is:

The TYPE=IMSACBA statement is followed by one or more TYPE=DATASET statements.

Dynamic allocation statements for the IMSACBA and IMSACBB data sets can be combined in the same job. They cannot be combined with other statements to dynamically allocate any other IMS data set.

TYPE=IMSACBB statement

IMS uses the TYPE=IMSACB statement to create the dynamic allocation member to allocate the IMS IMSACBB library data sets. Using DFSMDA to dynamically allocate IMSACBB allows you to resize the inactive ACBLIB data sets, add data sets to the concatenation, or change data sets in the concatenation without bringing IMS down. See the following topic for an overview of dynamically allocating the IMSACBB data set: Dynamically allocating the IMSACBA and IMSACBB library data sets.

The format of this statement is:

The TYPE=IMSACBB statement is followed by one or more TYPE=DATASET statements.

Dynamic allocation statements for the IMSACBA and IMSACBB data sets can be combined in the same job. They cannot be combined with other statements to dynamically allocate any other IMS data set.

TYPE=OLCSTAT statement

This statement defines the dynamic allocation parameter list for the global online change OLCSTAT data set. The format of this statement is:

DSNAME: Specifies the name of the OLCSTAT data set. The name can be any combination of simple and compound names valid in JCL, except that it cannot contain special characters.

TYPE=OLDS statement

This statement defines the dynamic allocation parameter list for the online log data set (OLDS). There must be as many DFSMDA macros as there are OLDS.

Requirement: If you use dual logging, DFSMDA member names are required for both the primary and secondary OLDS.

The format of this statement is:

DSNAME=: Specifies the name of the data set. The name can be any combination of simple and compound names valid in JCL, except that it cannot contain special characters.
DDNAME=: Specifies the OLDSs to be allocated. If the OLDSs are dual, there must be a pair of macros, one with the ddname of the primary OLDS and the other with the ddname of the secondary OLDS (for example, DFSOLP01 and DFSOLS01). The data set must be cataloged. Substitute P for x when declaring a primary data set. Substitute S for x when declaring a secondary data set. Values from 00 through 99 can be specified for nn.

TYPE=RECON statement

This statement defines the dynamic allocation parameter list for database recovery control (DBRC). The format of this statement is:

DSNAME=: Specifies the name of the data set. The name can be any combination of simple and compound names valid in JCL, except that it cannot contain special characters.
DDNAME=: Specifies the name of the DD statement defining this data set. If an application uses alternate DD names for the RECON data sets, the dynamic allocation members must be created for the alternate DD names before the application can use these DD names.
WAIT=: If YES is specified on any of the TYPE=RECON statements, a wait is issued for any of the RECONs found to be offline during DBRC initialization. WAIT=NO is the default. Omitting the WAIT= parameter or specifying WAIT=NO causes dynamic allocation to fail if a RECON data set is offline during DBRC initialization.

TYPE=SLDS statement

This statement defines the dynamic allocation parameter list for the SLDS. SLDSs are dynamically allocated when required as input for restart. A single DFSMDA member with name IMSLOGR must be created to specify the UNIT information required for allocation. All SLDSs to be used as input to restart must reside on the same device type. The format of this statement is:

UNIT=: Specifies the device required for allocation. All SLDSs used as input for restart must reside on the same device type. This applies to both the primary and secondary data sets when dual logging is used. The device type can be tape or DASD.
DDNAME=IMSLOGR: Is the required value for DDNAME.

TYPE=TRACE statement

This statement defines the dynamic allocation parameter for external trace data sets. External trace data can be written to disk storage or to a tape unit. The statement differs with the type of storage chosen. The format of the statement for disk allocation is:

DDNAME: Specifies the ddname of the data set located on the disk. n specifies the number of the data set, and must be either 1 or 2. Each data set must be cataloged. Use two data sets to ensure that trace data is available at EOV.
DSNAME: Specifies the data set name. The name can be any combination of alphanumeric characters that is valid for IMS, except for special characters such as @, $, or #. DSNAME can be up to 44 bytes long.

The format for data set allocation to tape is:

DDNAME

Specifies the ddname of the data set located on the tape. DFSTRA0T is the required ddname if you allocate the external trace data set to a tape.

DSNAME

Specifies the data set name. DSNAME must not be cataloged. The name and can be any combination of alphanumeric characters that is valid for IMS, except for special characters such as @, $, or #. The name you specify can be up to 44 bytes long.

UNIT

Specifies the unit for the external trace data set. The unit must be a tape device, but can be any name valid to the installation. The default value is TAPE.

BLKSIZE

Is the block size of the external trace data set. The minimum value is 4008. Any other value chosen must be a multiple of 4004 (the LRECL) plus 4. The default is 16384.

Recommendation: Use a block size of 20 024 because it is 1/2 track.

Future DASD might change the track size, and older DASD might have different track sizes.

TYPE=WADS statement

This statement defines the dynamic allocation parameter list for the write ahead data set (WADS). There must be as many DFSMDA macros as there are WADS data sets. The DFSMDA member name must be the same as the ddname of the WADS that it defines.

Requirement: If dual logging is used, DFSMDA member names are required for both the primary and secondary WADS.

The format of this statement is:

DSNAME=: Specifies the name of the data set. The name can be any combination of simple and compound names valid in JCL, except that it cannot contain special characters. The data set must be cataloged.
DDNAME=: Specifies the WADS to be allocated. Values 0 through 9 can be specified for n. When dual logging for the WADS is requested using the WADS=D execution time parameter, there must be at least two WADS provided.

TYPE=FINAL statement

This statement indicates the end of a parameter list build and is required. No other parameters are valid on a TYPE=FINAL statement. The format of this statement is:

JCL examples

The examples in this topic contain the following comment line above the SYSIN statement, for reference only, to aid in column alignment.

//* +----1----+----2----+----3----+----4----+----5----+----6----+----7---

Example 1: Specify three databases and the IMS Monitor data set to participate in dynamic allocation and deallocation.

//DALOC    JOB
//*
//STEP    EXEC IMSDALOC
//* +----1----+----2----+----3----+----4----+----5----+----6----+----7---
//SYSIN     DD  *
   DFSMDA TYPE=INITIAL
   DFSMDA TYPE=DATABASE,DBNAME=DI41M101
   DFSMDA TYPE=DATASET,DSNAME=IMSQA.M1I3I1,DDNAME=M1I3I1
   DFSMDA TYPE=DATASET,DSNAME=IMSQA.M1I3O1,DDNAME=M1I3O1
   DFSMDA TYPE=DATABASE,DBNAME=DX41SK03
   DFSMDA TYPE=DATASET,DSNAME=IMSQA.DB5H111,DDNAME=DXSK0301,           X
               DISP=SHR
   DFSMDA TYPE=DATASET,DSNAME=IMSQA.DB5H222,DDNAME=DXSK0302,           X
               DISP=SHR
   DFSMDA TYPE=DATASET,DSNAME=IMSQA.DB5H333,DDNAME=DHSK0301,           X
               DISP=SHR
   DFSMDA TYPE=DATABASE,DBNAME=DH41SK03
   DFSMDA TYPE=DATASET,DSNAME=IMSQA.DB4D111,DDNAME=DDSK0101,           X
               DISP=SHR
   DFSMDA TYPE=DATASET,DSNAME=IMSQA.DB4D222,DDNAME=DDSK0102,           X
               DISP=SHR
   DFSMDA TYPE=DFSDCMON,DDNAME=IMSMON,DSNAME=I115T237.IMSMON
   DFSMDA TYPE=FINAL
   END
/*

Example 2: Specify three DEDB areas to participate in dynamic allocation and deallocation

//DALOC    JOB
//*
//STEP    EXEC IMSDALOC
//* +----1----+----2----+----3----+----4----+----5----+----6----+----7---
//SYSIN     DD  *
   DFSMDA TYPE=INITIAL
   DFSMDA TYPE=FPDEDB,DD41SK02
   DFSMDA TYPE=DATASET,DSNAME=DB9AREA0,DDNAME=DB9AREA0
   DFSMDA TYPE=FPDEDB
   DFSMDA TYPE=DATASET,DSNAME=DB22AR0,DDNAME=DB22AR0,                  X
               DISP=SHR
   DFSMDA TYPE=FPDEDB,DEDBJN22
   DFSMDA TYPE=DATASET,DSNAME=DB22AR1,DDNAME=DB22AR1,                  X
               DISP=OLD
   DFSMDA TYPE=FINAL
   END
/*

Example 3: Specify the JCL and macro statements for SLDS to participate in dynamic allocation and reallocation

//ASSMBLY EXEC IMSDALOC
//*
//SYSLIB    DD  DSN=RNC.SDFSMAC,DISP=SHR
//          DD  DSN=I13OTS13.SDFSMAC,DISP=SHR
//          DD  DSN=IMS.&SYS2.SDFSMAC,DISP=SHR
//* +----1----+----2----+----3----+----4----+----5----+----6----+----7---
//SYSIN     DD  *
   DFSMDA TYPE=INITIAL
   DFSMDA TYPE=SLDS,UNIT=SYSDA,DDNAME=IMSLOGR
   DFSMDA TYPE=FINAL
   END
/*
//LNKEDT.SYSLMOD DD DSNAME=IMSQA.TNUC2,DISP=SHR,
//             UNIT=SYSDA,VOL=SER=USER01

Example 4: Build allocation members for RECON data sets RECON1, RCONSS, and RCONPW, and to trace data sets on DASD

//DYNALL   JOB
//*
//STEP    EXEC IMSDALOC
//SYSIN     DD  *
   DFSMDA TYPE=INITIAL
   DFSMDA TYPE=RECON,DSNAME=IMSV41.RECON01,DDNAME=RECON1,WAIT=YES
   DFSMDA TYPE=RECON,DSNAME=IMSV41.RECON02,DDNAME=RCONSS,WAIT=YES
   DFSMDA TYPE=RECON,DSNAME=IMSV41.RECON03,DDNAME=RCONPW,WAIT=YES
   DFSMDA TYPE=TRACE,DDNAME=DFSTRA01,DSN=IMS41.DFSTRA01
   DFSMDA TYPE=TRACE,DDNAME=DFSTRA02,DSN=IMS41.DFSTRA02
   DFSMDA TYPE=FINAL
   END
/*

Example 5: Build allocation members for RECON data sets and to trace data sets on tape

//DYNALL   JOB
//*
//STEP    EXEC IMSDALOC
//SYSIN     DD  *
   DFSMDA TYPE=INITIAL
   DFSMDA TYPE=RECON,DSNAME=IMSV41.RECON01,DDNAME=RECON1,WAIT=YES
   DFSMDA TYPE=RECON,DSNAME=IMSV41.RECON02,DDNAME=RECON2,WAIT=YES
   DFSMDA TYPE=RECON,DSNAME=IMSV41.RECON03,DDNAME=RECON3,WAIT=YES
   DFSMDA TYPE=TRACE,DDNAME=DFSTRA0T,DSNAME=TAPEDS1,UNIT=TAPE,BLKSIZE=20024
   DFSMDA TYPE=FINAL
   END
/*

Example 6: Define three data sets in the IMSACBA concatenation


//DYNALL   JOB
//*
//STEP    EXEC IMSDALOC
//SYSIN     DD  *
   DFSMDA TYPE=INITIAL
   DFSMDA TYPE=IMSACBA
   DFSMDA TYPE=DATASET,DSNAME=IMS.ACBLIB1
   DFSMDA TYPE=DATASET,DSNAME=IMS.ACBLIB2
   DFSMDA TYPE=DATASET,DSNAME=IMS.ACBLIB3
   DFSMDA TYPE=FINAL
   END
/*

Example 7: Define three data sets in the IMSACBB concatenation

//DYNALL   JOB
//*
//STEP    EXEC IMSDALOC
//SYSIN     DD  *
   DFSMDA TYPE=INITIAL
   DFSMDA TYPE=IMSACBB
   DFSMDA TYPE=DATASET,DSNAME=IMS.ACBLIB4
   DFSMDA TYPE=DATASET,DSNAME=IMS.ACBLIB5
   DFSMDA TYPE=DATASET,DSNAME=IMS.ACBLIB6
   DFSMDA TYPE=FINAL
   END
/*

Example 8: Define a DFSMDA member for the IMS catalog DBD

The following sample JCL defines a DFSMDA member for the catalog DBD. Replace dsn with a name of your choice.

//*
//STEP    EXEC IMSDALOC
//* +----1----+----2----+----3----+----4----+----5----+----6----+----7---
//SYSIN     DD  *
   DFSMDA TYPE=INITIAL
   DFSMDA TYPE=CATDBDEF,DSNAME=dsn
   DFSMDA TYPE=FINAL
   END
/*

Restrictions

The following restrictions apply when using the Dynamic Allocation macro:

HALDBs are dynamically allocated and do not need the Dynamic Allocation macro.
If you are going to dynamically allocate a database, all DD statements referenced in the DMB for the database must be defined in the TYPE=DATASET, DDNAME= parameter. A database cannot be partially allocated by JCL and partially allocated by a dynamic allocate member.
Because dynamic allocation cannot resolve logical relationships between DBDs, you must define a dynamic allocation member for each DBD in a logically related database. For example, a HIDAM database is composed of two logically related DBDs, the index DBD and the data area DBD. Each DBD in this example must have a dynamic allocation member with the same name as the DBD.
The Batch Backout utility (DFSBBO00) is the only IMS utility that is supported for dynamic allocation.
A database that is generated as a DFSMDA member cannot be given a name that is a duplicate of any label name that is generated during the assembly step of the DFSMDA job. IMS generates a label using the database name during this step, and an error occurs if that label name exists in code invoked by DFSMDA. This restriction does not apply to data set names.
A database that is generated as a DFSMDA member cannot be defined with a ddname that is identical to the ddname defined for another database during the same assembly step of the DFSMDA job. If more than one database must be defined with the same ddname (as in the case of secondary indexes), the DFSMDA job must be run separately for each required occurrence of the ddname.
Unless it is a dynamic allocation member, no member that has the same name as a database should be bound into IMS.SDFSRESL.