I received the following information about your questions from the
Binder architect, Leona Baumgart.
John Ehrman
A couple of related issues are touched on in this series of notes.
1. The default action of the binder is that a non-executable module
will NOT replace an executable one. The default value for LET
(LET=4, which is the same as NOLET) means that a level 8 error will
cause a module to be marked not-executable and it will NOT replace
an executable module of the same name (whether or not (R) is
specified on the NAME statement).
2. As of z/OS 1.6, XREF and MAP will be produced even if the module
is not saved (assuming things were not so bad that we couldn't
produce a coherent bound module).
(------------------ Referenced Note Follows --------------------)
> Date: Wed, 31 Aug 2005 08:36:38 -0500
> From: "McKown, John" <[EMAIL PROTECTED]>
>
> I had this asked of me recently and I cannot think of a simple way
> to do it. Is there some way to stop the binder from adding/replacing
> a program object in a library if the binder detects any kind of an
> error which would result in a return code > 4?
>
> I know of the STORENX=NO, but that does not do what I want. The
> closest that I have been able to think of is to have the binder put
> the program object(s) into a temporary library, then have a subsequent
> IEBCOPY step copy the members from the temporary library into the
> permanent library.
>
> What happened is that a "bad" module (binder rc>4) replaced a "good"
> module. The programmer is asking why would the binder do this? I don't
> really have a good answer other than "that is the way it works", which
> is not really very comforting.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
