II07297: BINDER:WHAT YOU NEED TO KNOW AND DO WHEN USING?

APAR status

• INTRAN

Error description

• This APAR is to document some of the major differences using
  the BINDER. What's different; what you need to know and do.
  **********************************************************
  * BINDER: WHAT'S DIFFERENT, WHAT YOU NEED TO KNOW AND DO!*
  **********************************************************
  THE BINDER IS THE DEFAULT LKED/LOADER NAME AS OF DFSMS 1.1.
  In DFSMS/MVS 1.1 the Program management binder assumes all
  of the functions of the DFP Linkage Editor and batch Loader.
  
  Invoking the linkedit functions via the primary names, that is,
  IEWL, HEWL, LINK, etc., 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 may 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 pre-DFSMS 1.1 releases.
  It is the practice in many installations to copy the
  Linkage Editor from the new release over 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 will be copied instead of the Linkage Editor.
  The Binder will not run in pre-DFSMS 1.1 releases.
  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 function,
  it has new data structures and opened-ended queues and lists
  that require more virtual storage.  (In so doing, the
  "table overflow" conditions have been eliminated as well
  as the SYSLIN blocksize limit of 3200 bytes.)
  In addition, whereas the Linkage Editor used its SYSUT1
  data set as a workfile, "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 via data spaces and in the user's address space.
  NOTE:  The SYSUT1 data set is no longer required and
  will be ignored by the Binder.
  *
  It is recommended that the MINIMUM REGION SIZE be 2 MEG.
  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
  of CSECTS, load modules, RLDs, etc. being combined),
  in most installations and jobs 2 MEG 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.
  HOWEVER, because there are some instances when it is
  necessary to limit the storage available to the Binder,
  (e.g. other programs are sharing the address space,
  like SMP/E), the Binder will honor the SIZE parameter if
  it is specified.  We recommend that for batch LINKEDIT
  jobs that the SIZE parameter be removed. However, if SIZE
  is specified, ensure that sufficient region is available
  in extended private for Binder working storage.
  Atleast 2Mb is recommended.
  *
  Your system may 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 MAY be necessary to increase the space
  allocated to the system's paging data sets.
  ************************************************************
  *DIFFERENCES IN PROCESSING BETWEEN BINDER & LINKAGE EDITOR *
  ************************************************************
  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 over 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 it determines to be non-executable over an
  executable module unless explicitly told to do so.  To
  protect the user and also 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.  Users running with earlier releases
  of SMP/E must create or modify the 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, etc.
  If it didn't recognize the input, it ignored it and took the
  default - without informing the user that an error was
  detected.  The user may or may not have been getting what he
  thought he 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.
  :NOTE: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 program
  management publication, SC26-4916.
  * Uninitialized Storage - Specifying uninitialized space or
  variables in your program may result in unpredictable results
  during execution. Part of this uninitialized space may be
  represented by binary zeros in the load module and part by gaps
  in the module text. The algorithym for terminating a load
  module text record depends on a number of factors, such as
  blocksize, and number of bytes left on the track differs
  between the Linkage Editor and 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 GETMAINed for the first time in
  the job step, then the storage will contain zeros. Otherwise,
  there may be more information left over from a prior useage
  in the same job step. The risk is increased with very large
  uninitialized areas or when loading the program in an inter-
  active environment.
  It is documented in the Assembler H V2 Reference manual 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".
  Manuals referenced:
  Assembler H V2 Language Reference manual
  IBM COBOL II Application Programming Guide for MVS
       section - Working Storage
  IBM VS COBOL for OS/VS
       section - Working Storage and Communications
  ******************************************
  *Binder processing of control statements *
  ******************************************
  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,
  the Linkage Editor the first.  This could result in
  execution errors if conflicting ENTRY statements are present.
  ******************************************
  *Binder processing of module attributes  *
  ******************************************
  The Binder always accepts an explicit override of a module
  attribute, whereas the Linkage Editor sometimes does not.
  For example, although the JCL may 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 reentrancy if the
  override had not been present.
  The Binder treats REFR, RENT and REUS as values to its
  reusability attribute. COMPAT parm was introduced by OW05347
  to make the Binder to behave like the Linkage Editor. Please
  read OW03535 and OW05347 for more details.
  ************************************************************
  * AMODE/RMODE defaults usually consistent w/ Linkage Editor*
  ************************************************************
  If the user overrides both or neither AMODE and/nor RMODE
  via either execution parameter or Binder control statement,
  the resultant 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 program management
  guide, SC26-4916, for additional information of option
  defaults.
  ***************************************************************
  
  
  
  LLA PROCESSING
  The Binder will always bypass LLA when accessing a program
  library, i.e. 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 reworded all others
  for clarity, accuracy, and improved diagnostics.  All the
  messages numbers numbers have been changed.  If the customer
  has 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 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
  Binder.  While the Binder is stricter about consistency in
  both its input and output, it has compromised in many cases
  to match the Linkage Editor behavior (and minimize customer
  disruption).  In these cases, however, the Binder will print
  out a warning message identifying the inconsistency.  The user
  may see more RC 4's than usual. (One example of this is when
  AMODE/RMODEare not consistent with the ESD information.  The
  explicit external specification will be honored, if possible,
  but warning message will identify this inconsistency.)
  *     ***  NOTE TO SYSTEMS PROGRAMMER   ***
  When installing the BINDER the following should be kept in mind.
  The minimum data space size for BINDER is 16M. C/C++ users
  should request a minimum of 1 gig of data space. Data space will
  not be utilized by BINDER if the data space size is set less
  than 16M. If data space is not used, such as data space size is
  less than 16M, or IEFUSI exit is removed, it may cause
  degradation to the Binder. MSGIEW2971T can be issued for a very
  large module. To set the data space size, set option in IEFUSI.
  *
  ADDITIONAL INFORMATION on using the Binder can be found in
  DFSMS/MVS 1.1 Program Management - SC26-4916 PMUSER -
  Program Management User Considerations, which is available
  on MKTTOOLS.
  LOCAL FIX:
  *********************************************************
  ADDITIONAL MESSAGES ADDED
  *********************************************************
  IEW2541E (MSGIEW2541E introduced by OY67352)
  MEMBER member WITHIN DDNAME ddname WITH CONCATENATION NUMBER
  number CONTAINS A BLOCK OF SIZE size WHICH IS LONGER THAN THE
  DATA SET BLKSIZE
  .
  Explanation: A load module being included contains a block which
  is longer than the data set blksize.
  .
  Source: Binder
  .
  Detecting Module    IEWBXCRW
  .
  System action: Module is not included.
  User response: An override BLKSIZE may be coded on the DD card.
  To permanently increase the BLKSIZE of the data set, the
  override must be used when writing to the data set.
  --------------------------------------------------------
  AUTOCALL
  The order in which modules are included during autocall
  processing is not specifiable by the user and should
  therefore be considered unpredictable.  Due to different
  autocall algorithms in the two programs, the sequence of
  includes will be different in the binder than it was in
  the linkage editor.  If this sequence is important, then
  you should provide INCLUDE control statements in the
  input stream.
  ----------------------------------------------------------
  SMP/E CONSIDERATIONS
  SMP/E is often used by system programmers for software
  installation.  SMP/E now invokes the binder, and the
  following operation differences must be considered.  In
  each case, the recommended action is to modify the LKED
  UTILITY entry in the global
  1. The binder must be invoked with the STORENX option,
     to allow saving not-executable modules.  If you are
     using a version of SMP/E prior to Release 7, you must
     add the STORENX option to the PARM field of the
  2. For certain classes of errors the binder sets a return
     code of 8, whereas the linkage editor returned 12 or
     16. The highest acceptable link edit return  code, as
     distributed by SMP/E, is 8, which means that some errors
     may go unnoticed.  To ensure that SMP/E intercepts
     severity 8 errors, you should change the RC value in
     the UTILITY entry to 4.  This may cause problems,
     however,  if you install software where level 8
     errors from the binder are expected or considered
     acceptable.
  3. If you cannot lower the maximum return code to 4 then
     you must check all level 8 error messages issued by
     the binder.  If message volume is a problem,
     informational  and warning messages can be suppressed
     by adding MSGLEVEL(8) to the PARM field in the LKED
     UTILITY entry.
  ------------------------------------------------------------
  LET Parameter on the PARM statement
  PARM=LET by itself will result in LET=8 - IT DOES NOT
  DEFAULT TO 4.  IF the PARM statement is coded without
  LET then the default is 4. This is coded to conform with
  SMPE    5695DF108
  ------------------------------------------------------------
  INFORMATION CONTINUED IN APAR II07696
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels