Name conflicts can arise when symbols with identical names occur in the external symbol dictionary of a load unit. Symbols are CSECTs, ENTRYs, COMMONs and XDSEC-Ds. Note that identical names are not necessarily always conflicting names.
DBL handles name conflicts differently, depending on whether the operating mode is RUN-MODE=*STD or RUN-MODE=*ADVANCED (see "Operating modes RUN-MODE=*STD and RUN-MODE=*ADVANCED").
Handling name conflicts in RUN-MODE=*STD
In the case of RUN-MODE=*STD, name conflicts are detected regardless of whether or not the symbols in a module are masked. The user has no means of controlling how name conflicts are handled.
The following table shows how name conflicts are handled by DBL. “Entry 1” stands for a symbol in a loaded module or for a COMMON that is already known in the current load unit. Any uninitialized COMMON at the end of the load unit is flagged in the symbol table and treated as a CSECT in subsequent load calls. A name conflict occurs if an “Entry 2” symbol of the same name is found in the module to be loaded.
Entry 1 | ||||
Entry 2 | CSECT | ENTRY | COMMON | XDSEC-D |
CSECT | (1) | --- | (2) | -- |
ENTRY | --- | (3) | -- | |
COMMON | (3) | (4) | (5) | -- |
XDSEC-D | -- | -- | -- | (6) |
Explanation
(1) | A name conflict has been detected.Loading of the module containing the CSECT with the same name is aborted.The autolink function is terminated. If loading of the module was initiated by an INCLUDE statement in an object module (see appendix), the module is ignored and processing continues. |
(2) | The COMMON section is initialized with the CSECT. |
(3) | A name conflict has been detected.Loading is aborted. |
(4) | The name conflict is not detected. |
(5) | The second COMMON section is ignored. |
(6) | Recoverable error.The second XDSEC-D is skipped. |
(-) | Not a name conflict (only an identical name). |
Handling name conflicts in RUN-MODE=*ADVANCED
In RUN-MODE=*ADVANCED, name conflicts are detected only if the symbols in a module are not masked. The user is notified with a message of any name conflict which could lead to errors. By including the NAME-COLLISION operand in the load call, the user can control how name conflicts are handled. The following options are available:
operand NAME-COLLISION=*STD
Name conflicts between nonmasked symbols are indicated by warning messages. The module containing the symbol with the same name is loaded. The new occurrence of the symbol is masked, i.e. it is not used to resolve external references.
operand NAME-COLLISION=*ABORT
Loading of the current load unit is aborted as soon as a name conflict between nonmasked symbols is detected.
The following table shows how DBL handles name conflicts when the user has specified NAME-COLLISION=*STD. “Entry 1” stands for a nonmasked symbol in a loaded module or for a COMMON that is already known in the current load unit. Any uninitialized COMMON at the end of the load unit is flagged in the symbol table and treated as a CSECT insubsequent load calls. A name conflict occurs if a nonmasked “Entry 2” symbol of the same name is found in the module to be loaded.
Entry 2 | ||||
Entry 1 | CSECT | ENTRY | COMMON | XDSEC-D |
CSECT | (1) | (1) | (2) | -- |
ENTRY | (1) | (1) | (2) | -- |
COMMON | (1) | (1) | (3) | -- |
XDSEC-D | -- | -- | -- | (4) |
Explanation
(1) | A name conflict has been detected.The symbol “Entry 1” is not masked and can be used to resolve external references. The symbol “Entry 2” is masked and cannot be used for resolving external references. A warning is issued. |
(2) | The COMMON section is initialized with the CSECT (as for RUN-MODE=*STD). |
(3) | The second COMMON section is ignored (as for RUN-MODE=*STD). |
(4) | Recoverable error.The second XDSEC-D is skipped. The name conflict is handled in the same way as for RUN-MODE=*STD. |
(-) | Not a name conflict (only an identical name). |