The binder and linkage editor manuals have attempted to describe the load-time
behaviors of modules according to the link-time parameters. (Similarly for the
binder FETCHOPT). This is somewhat unfortunate, as while it is reasonable to
expect some description of the options in those manuals, th
Shmuel you are correct. If you code RENT the linkage editor also sets REUS, and
if you set REFR it does not set the others. However you can also independently
turn on or off REUS in the linkage editor. The binder enforces that only one
reusability attribute is set. (Interestingly the linkage ed
The linkage editor treated the reusability attributes individually and they
could potentially be set independently (NORENT and REFR). The binder treats
reusability as a hierarchy, REFR implies RENT, RENT implies SERIALLY REUSABLE,
so it will never set them that way. In GOFF object modules and
Frank,
I suspect that I tried out the restricted no-call LIBRARY statements with
XPLINK C programs, because there I do not get the IEW2455W message. I'm pretty
sure you should not get that message for NOXPLINK either, whether it be C or
COBOL. (It's not obvious to me why it's happening, but t
Eric,
To the best of my knowledge SYS1.SIEALNKE members are not intended to be linked
directly into programs.
SYS1.CSSLIB (or other component-specific libraries like LE's CEE.SCEELKED)
should have the stubs for their functions. SYS1.SIEALNKE is one of the
datasets which are by default part of
Hi Frank,
Two things I'd check:
* You've invoked the binder with the DYNAM=DLL parm
* The reference(s) are dynamic (descriptors) so that they can be satisfied by
the IMPORT
Otherwise the binder cannot resolve them dynamically and since you now told it
to not autocall...
Barry
On Tue, 10 Aug
This complaint has come up every so often. There is something already in the
binder that works. However it requires a control statements one-for-one with
each IMPORT statement. The control statement is a restricted no-call LIBRARY
statement, it looks simply like this (with the parentheses):
Thanks for catching that omission Peter. I wish I could edit my post... instead
I'll just reposting that paragraph in hopes it's less confusing for anyone
looking at the archives:
The binder will simply discard the "private code" (unnamed) CSECT (section), if
it has no text.
It never gets incor
The binder will simply discard the "private code" (unnamed) CSECT (section), if
it has text.
It never gets incorporated into the module being bound, so it should have no
effect on it.
Binder has behaved like this since near the beginning (early 90's, around when
PM3 format was introduced).
The
I think that's normal for the binder to not show the module information for
your exported functions & variables, because they are being exported by the
module currently being bound, so it's sort of superfluous.
For historical reasons the binder uppercases things. You can either use the
CASE=MI
The value of R5 on entry to an XPLINK (which include AMODE 64) function is not
the address of the WSA in its entirety (as R0 was in non-XPLINK), but rather
the value of the "environment" of that function, which is somewhere within the
WSA of that module (executable file). (As implemented I beli
In reply to David and others, a couple of points that might be of interest:
* I confirm that the MIGRATABLE attribute is just as people have suggested, to
indicate whether a program can be copied between PDS and PDSE, or saved as a
load module in a PDS when it was able to be saved as a program o
Strictly as a circumvention, knowing that you are not actually going to call
these functions, I want to make sure you know you could use the XL C/C++
SUPPRESS option: SUPPRESS(CCN3244)
On 16 Aug 2018 16:24:56 + Farley, Peter x23353 wrote:
> Yes the binder API header as coded does cause harm
Hi Peter,
The documentation for GETE warns: "Note: Processing of the ESD records returned
by a GETE call should not make assumptions about the order of the returned ESD
records..." The expectation was that there would never be a very large number
of classes, so that a simple class lookup (as i
Hi Peter,
In the description of the fields of the ESD entry buffer format it shows:
3 ESD_ELEM_OFFSET Binary 72 4 Offset within class element (LD, ER)
2 ESD_CLASS_OFFSET Binary 76 4 Offset within class segment (ED, LD, PD, ER)
The parenthetical information means these fields apply to only t
On Tue, 23 Feb 2016 10:36:16 -0600 Paul Gilmartin wrote:
> Oooh! Neat! Thanks. And I see:
>
> z/OS MVS Program Management: User's Guide and Reference
> SA23-1393-00
>
> STRIPSEC={PRIV|YES | NO}
> STRIPSEC=PRIV
> Specifies that unreferenced unnamed sections are to be removed.
>
> This a
You might try the STRIPSEC option. It does not work on a specific INCLUDE,
rather the binder will remove any sections which are not used at the end of
input. There will be a section in the MAP output showing which ones (if any)
were removed.
barry.lichtenst...@us.ibm.com
On Mon, 22 Feb 2016
make it be
a PDS -- even with the Prelinker.
barry_lichtenst...@us.ibm.com
On Wed, 27 Jan 2016 18:08:11 -0600, Bill Woodger wrote:
> On Wednesday, 27 January 2016 17:26:04 UTC, Barry Lichtenstein wrote:
> > It's not the JCL per-se. The combination of XOBJ object modules and the
&
, new capabilities are
implemented only in GOFF and Program Objects.
On Wed, 27 Jan 2016 13:40:38 -0600, Ed Gould wrote:
> On Jan 27, 2016, at 11:25 AM, Barry Lichtenstein wrote:
>
> > It's not the JCL per-se. The combination of XOBJ object modules
> > and the Prelinke
It's not the JCL per-se. The combination of XOBJ object modules and the
Prelinker was a tactical solution to advancements in programs, originally
created for C programs. XOBJ object modules addressed several deficiencies in
OBJ object modules, such the ability to have long case-sensitive exter
It appears that the manual got mangled in z/OS R12. In z/OS R11 it starts out
simply saying:
"The ORDER statement indicates the sequence in which control sections or named
common areas appear in the output program object or load module. The control
sections or named common areas appear in the
If you are in this situation, and you do not have the source to recompile, but
you are able to rebind the module, you can use the binder control statement
CHANGE (or REPLACE) to turn the private section name into an actual name. This
capability was introduced in z/OS V1R13.
---
The binder default is REUS=NONE. There's no option to tell the binder to set
it based on the inputs (like might be called "REUS=MIN").
The existing attributes, to the extent they are available to the binder, are
only used to determine if there is a conflict with a specified reusability.
If
23 matches
Mail list logo
