This is an older piece of information which might help some users. It should not be used in place of the Program Directory shipped with the Version 3.1 products, nor should it be used in place of the post linkedit jobs we provide. This document addresses the difference between the older linkage editor and the new Binder product. APARs and manuals are more up to date, so be sure to refer to those as well.
Binder is the default LKED/LOADER name, as of the introduction of DFSMS 1.1. In DFSMS/MVS 1.1, the program management binder assumes all the functions of the DFP Linkage Editor and the batch Loader.
Invoking the linkedit functions through the primary names -- IEWL, HEWL, LINK -- will result in execution of the Binder.
Most associated names for both the Linkage Editor and the Batch Loader are now defined to the binder. You can invoke the Linkage Editor, which remains the same as in the previous releases (MVS/DFP), by using either HEWLKED or HEWLF064. You can invoke the MVS/DFP Batch Loader using the name HEWLDIA. Except for a "stub", which is initially loaded and resides in SYS1.LINKLIB, all of the Binder code resides in ELPA.
The Binder will not run on releases prior to DFSMS 1.1.
It is the practice in many installations to copy the Linkage Editor from the new release to the system, which is building this new release, so that the new system can be built with the latest Linkage Editor. (In some earlier releases this was actually a requirement.) Using the same names as in previous system builds, the Binder rather than the Linkage Editor will be copied. The Binder will not run in releases prior to DFSMS 1.1. To avoid this problem, the initial load of the Binder includes a test for the level of the operating system. If it is a pre-DFSMS 1.1 release, the Binder automatically invokes the Linkage Editor.
The Binder requires a larger region than the linkage editor.
Because the Binder has relaxed all the restrictions inherent in the Linkage Editor and has added additional functions, it contains new data structures and opened-ended queues and lists that require more virtual storage. (The "table overflow" conditions have been eliminated, as well as the SYSLIN blocksize limit of 3200 bytes.) Also, while the Linkage Editor used its SYSUT1 data set as a workfile, thus "spilling" data out to DASD when it ran out of space in storage, the Binder saves I/O in favor of using more processor storage, both through data spaces and in your address space. The SYSUT1 data set is no longer required and will be ignored by the Binder.
The MINIMUM REGION SIZE should be 2 MB.
While the amount of storage required by the Binder is directly related to the number of pieces being bound together (not necessarily the text size itself, but the size of CSECTS, load modules, RLDs, and so on being combined), in most installations and jobs 2 MB should be sufficient. The Binder executes in 31-bit addressing mode, so storage can be obtained from above the line if available.
The Binder does not require the "SIZE" PARM.
It is preferable that the SIZE PARM not be specified, since the Binder can do a better job of managing its own space. There are some instances where it is necessary to limit the storage available to the Binder (for example, if other programs are sharing the address space, like SMP/E). As a result, the Binder will honor the SIZE parameter if it is specified. We recommend that for batch LINKEDIT jobs, the SIZE parameter be removed. However, if SIZE is specified, ensure that sufficient region is available in extended private for Binder working storage. At least 2 MB is recommended.
Your system might require increased space for paging data sets.
Because the Binder uses data spaces (which are usually not accounted for in calculation of paging space requirements), and does use more virtual storage than the Linkage Editor, it might be necessary to increase the space allocated to the system's paging data sets.
The Binder won't store a non-executable module automatically.
In the past, it was possible for a user to wipe out a good version of a module inadvertently, when the Linkage Editor stored with it a module that was marked as not-executable by the Linkage Editor. SMP/E, as part of its normal processing, replaces a member with an empty, non-executable version in one step and then replaces it with the new member in the next step. The Binder will not store a module that it determines to be non-executable over an executable module unless explicitly told to do so. To protect the user and also to allow SMP/E to operate, a new option, STORENX, can be specified; PARM=(STORENX,,,,,,,). As of release 1.7, SMP/E will invoke the Binder using the new STORENX option. If you are running an earlier release of SMP/E, you must create or modify the linkedit UTILITY entry in the SMP/E global zone to specify the STORENX option.
The Binder is stricter than the Linkage Editor.
The Linkage Editor was very lenient about accepting invalid control statements, bad syntax, incorrect keywords, and so on. If it didn't recognize the input, it ignored it and took the default - without informing the user that an error was detected. Users might or might not have been getting what they thought they requested. The Binder treats unrecognizable input as a level-8 error condition, causing the module to be marked not-executable (unless the LET option has been specified). The job will have to be modified to provide the correct input to the Binder. This refers to all input that is invalid per the existing Linkage Editor documentation.
The Binder will accept as valid all input that is documented as "valid" for the Linkage Editor, except as noted in the DFSMS/MVS V1R4 Program Management manual (SC26-4916-03).
Specifying uninitialized space or variables in your program might result in unpredictable results during execution. Part of this uninitialized space might be represented by binary zeros in the load module, and part of the space will be represented by gaps in the module text. The algorithm for terminating a load module text record depends on a number of factors, such as blocksize and the number of bytes left on the track (if this number differs between the Linkage Editor and the Binder). During loading, text gaps are not initialized to anything by the loader. The contents of storage will be unchanged from the load. If the storage was affected by a GETMAIN for the first time in the job step, then the storage will contain zeros. Otherwise, there might be more information from a prior usage in the same job step. The risk is increased with very large uninitialized areas or when loading the program in an interactive environment. The Assembler H V2 Reference manual states that all uninitialized DS space storage must be initialized. COBOL states that all working storage must be initialized. "If the initial value is not explicitly specified, it is unpredictable." The manuals that were referenced are the Assembler H V2 Language Reference manual, the IBM COBOL II Application Programming Guide for MVS, the sections entitled "Working Storage IBM VS COBOL for OS/VS," and "Working Storage and Communications."
The Binder processes the last occurrence of a control statement or option.
The Linkage Editor processes the last occurrence for some control statements, the first for others. For example, if there are multiple ENTRY statements, the Binder takes the last ENTRY statement, and it takes the Linkage Editor first. This could result in execution errors if conflicting ENTRY statements are present.
The Binder always accepts an explicit override of a module attribute, whereas the Linkage Editor sometimes does not.
For example, although the JCL might specify RENT in the PARM list, when one CSECT being bound into a load module is reusable and the rest of the CSECTs are reentrant, the Linkage Editor ignores the external parameter and defines the module as reusable. The one CSECT must be located and recompiled to change the load module.
The Binder will allow the user to override the internal attributes explicitly on the JCL.
By specifying RENT on the JCL, the Binder defines the module as reentrant, regardless of the attributes of the internal CSECTs. Warning messages will be produced for each included CSECT, which would have downgraded the module's re-entrance if the override had not been present. The Binder treats REFR, RENT, and REUS as values to its reusability attribute. The COMPAT parameter was introduced by OW05347 to make the Binder behave like the Linkage Editor. OW03535 and OW05347 provide for more details.
If you override both (or neither) AMODE and RMODE through either the execution parameter or through the Binder control statement, the resulting load module or program object will have the same AMODE and RMODE characteristics as that produced by the Linkage Editor. However, if only one of the two modes are overridden, the other will not default to a fixed value as it did in the Linkage Editor. Refer to the discussion on AMODE and RMODE in Chapters 2 and 7 of the DFSMS/MVS V1R3 Program Management guide (SC26-4916) for additional information about option defaults.
The Binder will always bypass LLA when accessing a program library. When including a load module or program object, it will always bring in the copy from DASD, regardless of whether it is cached in LLA or not.
Binder output has changed.
The Binder has added many messages and has reworded others for clarity, accuracy, and improved diagnostics. All the message numbers have been changed. If you have any vendor products, which rely on message numbers, those tables will have to be modified. The volume of messages can be controlled using the new MSGLEVEL option of the Binder PARM field. The default listing (LIST=SUMMARY) includes more information than is printed by the Linkage Editor. It can be modified by specifying other parameters available with the LIST option. More informational and warning messages will result from the Binder. While the Binder is strict about consistency in both its input and output, it is compromised in many cases to match the Linkage Editor behavior (and to minimize disruption to you). In these cases, however, the Binder will print a warning message identifying the inconsistency. As a result, you might see more RC 4's than usual. One example of this is when AMODE and RMODE are not consistent with the ESD information. The explicit external specification will be honored, if possible, but a warning message will identify this inconsistency.
When installing the BINDER, the following should be kept in mind.
The minimum data space size for Binder is 16 MB. Data space will not be utilized by the Binder if the data space size is set to less than 16 MB. If data space is not used, this might cause degradation in the use of the Binder. To set the data space size, set the option in IEFUSI.