The binder behavior might be different from the linkage editor
in some significant ways:
- The linkage editor ignored data it didn't recognize or couldn't
process. The binder also discards nonprocessable input, but diagnoses
the error with a message and nonzero return code.
- The linkage editor accepted the first ENTRY control statement encountered,
whereas the binder accepts the last. This could result in execution
errors if the multiple statements specify conflicting entry points.
- Unlike the linkage editor, explicit AMODE and RMODE specifications during
binder processing always override the corresponding attributes in
the ESD of included modules. A new MIN value has been provided for
AMODE to allow ESD influence over the results. RMODE(MIN) is the default
and can not be specified.
- AMODE and RMODE are treated as independent options until they
are needed during binder processing. The linkage editor processes
them as a pair. If only one of the pair is specified on either the
parm string or a control statement, the other will be set depending
on the one specified. If neither option is specified or both are specified,
the binder will behave like the linkage editor. If only one is specified,
the results might be different.
- Many object modules, especially assembler programs and programs
written for older compilers, indicate AMODE(24) or RMODE(24) in their
ESD records. Overriding these values at bind time will produce warning
messages IEW2646I and IEW2651I, one per section in error. The linkage
editor ignored the condition but the binder assumes that a valid error
condition might exist. By specifying the binder option COMPAT=LKED
(see below), you can force the binder to suppress these messages and
leave the return code unchanged.
- Reusability (REUS, RENT and REFR) is handled differently
by the binder. While the linkage editor processes the attributes independently,
the binder stores them as a single value. The binder assumes that
reenterable programs are also serially reusable, and the refreshable
programs are also reenterable. This should not cause any processing
difficulties.
- The binder was designed to always accept an explicit override
of a module attribute, whereas the linkage editor sometimes does not.
For example, although the JCL can specify RENT in the parm list, when
one CSECT being bound into a load module is reusable and the rest
are reentrant, the linkage editor ignores the external parameter and
assigns the module as reusable. The binder will allow the explicit
override of RENT on the JCL to take priority.
- Since the release of the binder, customer feedback indicated there
has been some dependence on the internals of the linkage editor processing
in two areas: module attribute defaulting and AMODE/RMODE consistency.
- Many job streams specify RENT with the expectation that the linkage
editor would look at all the pieces and assign the highest level reusability
it could, for example, the customer expected the linkage editor to
override any external parameters.
- Many programs in the field continue to be bound with inconsistent
AMODE/RMODE specifications that are known and ignored by the linkage
editor.
As a result, an
option (COMPAT=LKED) was added
to the binder. When this is specified in the JCL the binder will behave
like the linkage editor in the following ways:
- The binder will ignore externally specified module reusability
attributes if any of the included load modules or program objects
are of lesser reusability. A summary message is produced to show that
the overall reusability of the module was downgraded.
- AMODE/RMODE conflict messages (IEW2646I, IEW2651I) will not be
issued by the binder when conditions such as AMODE ANY modules are
combined with AMODE 24 modules.
Note: It is essential that binder messages regarding reusability,
AMODE and RMODE be analyzed. The appropriate action in all such cases
is to correct the input, and perhaps to rebind the program if the
attributes displayed in the binder Processing Summary are incorrect.
- The batch loader (HEWLDIA) can be used to load an in-storage object
module. While this function is not supported by the binder, the binder
will invoke the batch loader transparently when this interface is
invoked. Applications that continue to use this interface cannot use
any new functions provided by the binder. This support is limited
and provided for compatibility only.