Re: RENT binder option
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, the behaviors are
going to depend on the system on which the module is being executed. The
binder really is just merely setting the bits in the directory.
That said the REUS options, along with AMODE and RMODE, are surprisingly
confusing, especially with their linkage editor history. The section of the
binder (Program Management: User's Guide and Reference), Appendix B ->
Migrating from the linkage editor to the binder -> Binder processing
differences from the linkage editor, does a pretty good job of explaining all
this:
https://www.ibm.com/docs/en/zos/2.4.0?topic=binder-processing-differences-from-linkage-editor
Lastly that's certainly a long-standing error in the publication! "The
refreshable attribute is negated if any input modules are not refreshable."
That's linkage editor behavior, and it is only true with the binder if
COMPAT(LKED) is specified.
In fact in the linkage editor that is the behavior of all the reusability
options (I'm looking at the MVS/ESA Linkage Editor and Loader's Guide Version 3
Release 1, SC26-4510-1, Second Edition June 1989): (** highlighting ** is mine)
In reference to the OP statement ("Someone else stated that by compiling with
the RENT compiler option, it will implicitly bind as RENT as well. My
observations tell me that this is not the case."), note that none of the
INCLUDEd modules attributes _set_ the reusability on, they only may turn it off.
Reusability Attributes
Either one of two attributes may be specified to denote the reusability of a
module. (Reusability means that the same copy of a load module can be used by
more than one task either concurrently or one at a time.) The reusability
attributes are reenterable and serially reusable; if neither is specified, the
module is not reusable and a fresh copy must be brought into virtual storage
before another task can use the module.
** The linkage editor only stores the attribute in the directory entry; it does
not check whether the module is really reenterable or serially reusable. **
A reenterable module is automatically assigned the reusable attribute. However,
a reusable module is not also defined as reenterable; it is reusable only.
Reenterable: A module with the reenterable attribute can be executed by more
than one task at a time; that is, a task may begin executing a reenterable
module before a previous task has finished executing it. This type of module
cannot be modified by itself or by any other module during execution. If a
module is to be reenterable, all the control sections within the module must be
reenterable.
**If the reenterable attribute is specified, and any load modules that are not
reenterable become a part of the input to the linkage editor, the attribute is
negated.**
Serially Reusable: A module with the serially reusable attribute can be
executed by only one task at a time; that is, a task may not begin executing a
serially reusable module before a previous task has finished executing it. This
type of module must initialize itself and/or restore any instructions or data
in the module altered during execution. If a module is to be serially reusable,
all its control sections must be either serially reusable or reenterable.
** If the serially reusable attribute is specified, and any load modules that
are neither serially reusable nor reenterable become a part of the input to the
linkage editor, the serially reusable attribute is negated. **
Refreshable Attribute:
A module with the refreshable attribute can be replaced by a new copy during
execution by a recovery management routine without changing either the sequence
or results of processing. This type of module cannot be modified by
itself or by any other module during execution. The linkage editor only stores
the attribute in the directory entry; it does not check whether the module is
refreshable. If a module is to be refreshable, all the control sections within
it must be refreshable.
** If the refreshable attribute is specified, and any load modules that are not
refreshable become a part of the input to the linkage editor, the attribute is
negated. **
Barry L
On Fri, 27 Aug 2021 11:38:05 + Seymour J Metz wrote:
> No, it is a text file containing one of IBM's old descriptions of the
> reusability option in *the binder* and in now way makes any claim about the
> linkage editor. Further, it is
incorrect: RENT by itself is not enough to protect a module from modification.
Contrast wit Module reusability at
and REUS: Reusability options at
Re: RENT binder option
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 editor table of incompatible options has always shown REUS and RENT as incompatible.) On Thu, 26 Aug 2021 12:37:17 + Seymour J Metz wrote: > Even the linkage editor had a hierarchy: nonreusable, serially reusable and > reentrant. The difference is that in the binder REFR is part of the > hierarchy, while in the linkage edi tor it is independent. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
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 program objects reusability is treated as a single-value field, not individual bits. The binder simply sets the attributes, there's no attempt by the binder to do anything but complain if the sections (CSECTs) are not consistent with the REUSability option set by the user. If the option specified is more restrictive the binder will give a warning message (IEW2609W) , but still set the module reusability according to the option specified. The default is always REUS=NONE. Unlike the binder, the linkage editor may honor the module reusability over the option set by the user. Note that while it is only in the PDSDE directory entry of load modules (not in the ESD information of load modules or OBJ object modules), it is available to the binder in the ESD information in program objects and GOFF object modules, as well as in the PDS and PDSE (PMAR) directory entries. And actually the binder can be told to honor the reusability within the module as well, by using the option COMPAT(LKED). Then the binder will issue an informational message (IEW2664I) instead of a warning message, and honor the "downgraded" reusability. Also the binder will take the most restrictive reusability specified as a simple option name, regardless of order (I know of no other binder options that work this way). So PARM='REFR,NORENT' gets you REFR. To "reset" to non-reentrant you'd have to use the binder syntax REUS(NONE) (or equally REUS=NONE). To the original DLL question: Languages like C may have data/variables which are writable (residing in the writable-static area, WSA). There was a time and I think in some cases it is still true, where the load point of the module is used by LE to determine that the module was already loaded for a given enclave. LE may use that information to decide whether it should create a new WSA instance associated with that DLL (module), which is shared for the entire LE enclave. Thus not having the module marked as RENT could cause problems, with multiple instances of data/variables are seen in different modules/procedures/functions of the entire DLL application. On Sun, 15 Aug 2021 18:47:26 -0400 Steve Smith wrote: > > Seems like deja vu. For all practical purposes, RENT and REFR (which > implies RENT) have the same effect (that may be a tautology). > > For whatever reasons, RENT & REFR were defined such that they didn't > accurately describe how they were implemented. What the OS wanted was > protected memory for programs (and good programmers want that too). In > effect, both mean that program storage cannot be modified during > execution. But the module attribute definitions go on about the ability > for multiple tasks to simultaneously use the module, or for the ability to > tolerate a refresh. Neither of those things absolutely requires > non-modification, so one wonders why IBM wandered off into those tangents. > > On the converse, it's not that hard to write read-only code that is not > reentrant (thread-safe in newspeak). And nothing in z/OS cares a bit... > you just get unpredictable results. Actual reentrancy requires interlocked > access to any shared memory; avoiding variables embedded within the program > module is just the beginning. > > The bottom line is that Program Fetch allows RENT modules to be shared, > REUS is just a weird ENQ trick, and otherwise you get multiple copies. I > really don't know if REFR has any effect over RENT. Perhaps it's required > for PLPA modules. > > sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLL linkage vs static linkage
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 the NOXPLINK import/export mechanism is significantly different than XPLINK, to start with it uses the original (Prelinker style) Q-con PR (offset) rather than the R-con/V-con representing the descriptor.) I think it's a reportable problem if you wish to pursue with binder, but an RFE might be a better thing to spend energy on. You do need to compile the COBOL modules differently in order for them to be DLL-enabled (C++ and XPLINK C are always DLL-enabled, but not COBOL). Though you could always compile them DLL-enabled and still link everything statically, you probably wouldn't want that overhead so you'd want a different proc or proc invocation. Thus whatever that switch was could also choose to include or exclude all the no-call LIBRARY statements. As for the IEW2638S message and the binder not saving the module, that's because you've got the binder parm LET=0 coded. The default is LET=4 (it's LET=8 if you code LET with no value). LET=0 tells the binder to mark it Not Executable (NX directory attribute) if the return code is higher than 0, and binder will not (by default) Replace an existing module that is marked Executable with one that is not. Barry On Wed, 11 Aug 2021 12:42:29 -0500 Frank Swarbrick wrote: > > I've now been successful in implementing your suggestion. Some comments > follow. > > The following is successful for a static link. Cobol compiler options > "NODYNAM NODLL" and the inclusion of SYS1.SCSFSTUB in the binder SYSLIB. > . . . > > Next is a successful "DLL link". Cobol compiler options "NODYNAM DLL". > Added "DYNAM=DLL CASE=MIXED" to the binder parameters. The CSFDLL31 side > file is included "in place" of SCSFSTUB. > . . . > > Now, if we take the previous example (DLL resolution) and add back SYSLIB > with SYS1.SCSFSTUB, the static resolution takes precedence over DLL > resolution, which is what I don't want. > . . . > > Next let's try Barry's suggestion: > . . . > > Unlike my attempt to do this with our standard compile proc, this does seem > to work as designed. > It does put out the following warning, which causes an RC of 4 instead of 0, > which is annoying. > > IEW2455W 9205 SYMBOL CSNBRNGL UNRESOLVED. NOCALL OR NEVERCALL SPECIFIED. > > But in the end it succeeds with the DLL import to resolve it. > > *** I M P O R T E D A N D E X P O R T E D S > Y M B O L S *** > --- > SOURCE > IMPORT/EXPORT TYPESYMBOL DLL DDNAME > SEQ MEMBER > - -- > --- - >IMPORT CODECSNBRNGLCSFDLL31SIEASID > 01 CSFDLL31 > > When I modify our standard compile proc in a similar (!!) manner I still get > an error: > > IEW2638S 5384 AN EXECUTABLE VERSION OF MODULE *NULL* EXISTS AND CANNOT BE > REPLACED BY THE NON-EXECUTABLE MODULE JUST > CREATED. > > I'm unclear as to what I am doing differently here. Not sure if I'll > research it any further, however, as I don't think this is really the > solution I'm looking for. Two reasons: > 1) I can't use it for non-DLL applications, and thus it defeats my desire to > have a single proc that works for both DLL and non-DLL applications (without > overrides). > 2) That warning message just bugs me! > > I am still thinking about making an RFE to give DLL linkage priority. Is > this a lost cause, or should I do it? > > Thanks! > Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLL linkage vs static linkage
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 the LNKLST concatenation, specifically: SYS1.LINKLIB, SYS1.MIGLIB, SYS1.CSSLIB, SYS1.SIEALNKE, and SYS1.SIEAMIGE Barry On Wed, 11 Aug 2021 15:37:42 -0400 Eric D Rossman wrote: > Reply > > I would like to point out that the stubs in SCSFSTUB use OS linkage and > the entry points in CSFDLL31 use LE linkage. You should use whichever > matches the linkage declared (or defaulted) for the ICSF callable > services. > > It is never correct to specify both SCSFSTUB and an ICSF side-deck in the > same link operation. It might work but it might not. > > As to what I meant by static, I suspect that I might be using the wrong > terminology for this and perhaps I am misremembering how it works. I > thought you could directly linkedit a shared object [like > SIEALNKE(CSFDLL31)] into a load module and it would be treated as if it > were an archive (.a) instead of shared object/DLL (.so). > > Eric Rossman, CISSP^62^AF > ICSF Cryptographic Security Development > z/OS Enabling Technologies > edros...@us.ibm.com > Tieline: 295-6882 or (845) 435-6882 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLL linkage vs static linkage
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 2021 16:41:46 -0500 Frank Swarbrick wrote: > > Hi Barry, > > Interesting. But I can't quite get it to work. What's bizarre is that the > DLL linkage seems to get resolved: > > IMPORT/EXPORT TYPESYMBOL DLL DDNAME > SEQ MEMBER > - -- > --- - >IMPORT CODECSNBRNGLCSFDLL31SIEASID > 01 CSFDLL31 > > But the binder is still giving me an error: > > IEW2455W 9205 SYMBOL CSNBRNGL UNRESOLVED. NOCALL OR NEVERCALL SPECIFIED. > IEW2638S 5384 AN EXECUTABLE VERSION OF MODULE *NULL* EXISTS AND CANNOT BE > REPLACED BY THE NON-EXECUTABLE MODULE JUST > CREATED. > > Very odd! > > Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLL linkage vs static linkage
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): LIBRARY (symname) That tells the binder to not resolve symbol 'symname' from an autocall library. You can still explicitly include it, or the symbol could come in statically due to being part of another module. The binder will still always resolve statically first -- or more accurately it will only attempt to "resolve dynamically" symbols that are unresolved after final autocall. (It's a bit of a misnomer, the binder is only promised that the symbol will be there when LE tries to find it, so the binder dutifully builds the construct for LE to do so.) I'd suggest having this statement at the top of a file of control statements, to avoid having to quote all the symbol names: SETOPT PARM(CASE=MIXED) * Avoid quoting symbol names on LIBRARY Barry On Mon, 9 Aug 2021 23:36:37 + Frank Swarbrick wrote: > Reply > > In the LE Programming Guide, section "Building a simple DLL application" > (https://www.ibm.com/docs/en/zos/2.4.0?topic=dlls-building-simple-dll-application), > the following statement is made: > > "After final autocall processing of DD SYSLIB is complete, all DLL-type > references that are not statically resolved are compared to IMPORT control > statements. Sy mbols on IMPORT control statements are treated as definitions, and cause a matching unresolved symbol to be considered dynamically rather than statically resolved. A dynamically resolved symbol causes an entry in the binder B_IMPEXP to be created. If the symbol is unresolved at the end of DLL processing, it is not accessible at run time." > > This means (and I have tested this), if the called routine can be resolved > both statically and via DLL, it will always choose to bind statically. > > For example, ICSF provides both individual program modules for each callable > service, and also DLLs that provide entry points for each callable service. > DLL lin kage for these routines requires including the appropriate DLL side deck (CSFDLL31). But you also cannot include in your "autocall concatenation" the library that contains the individual called routines (in this case CSF.SCSFMOD0), otherwise those modules are statically linked, and the DLL imports are ignored. For example, here's an excerpt from the program binder step: > > //SYSLIN DD * > INCLUDE SIEASID(CSFDLL31) > /* > // DD DSN=&OBJMOD,DISP=(OLD,DELETE) > // DD DDNAME=USERLIN > //SYSLIB DD DSN=CEE.SCEELKED,DISP=SHR > // DD DSN=CEE.SCEELKEX,DISP=SHR > // DD DSN=CSF.SCSFMOD0,DISP=SHR > //SIEASID DD DSN=SYS1.SIEASID,DISP=SHR > > You must not include the CSF.SCSFMOD0 library if you want to use DLL linkage > for those modules. > > In my shop we have all libraries that have modules that any of our programs > might want to use (rather than having processes to allow for explicitly > including tho se libraries only when used). But if we were to migrate to using DLLs (we are a COBOL shop, btw) we'd have to do something so that "DLL applications" don't have t he "static libraries" in the binder SYSLIB. This is "annoying". Would I get any support from the community if I were to open an RFE and request a binder option t o prioritize DLL linkage over static linkage? Or better yet, is there already a way to accomplish this? > > Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
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 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). On Peter Relson wrote: > Reply > > >The binder will simply discard the "private code" (unnamed) CSECT > (section), if it has text. > I suspect that Barry inadvertently omitted the word "no" before "text". > > Peter Relson > z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
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 difference between the AMODEs is described in 'SYS1.MACLIB(IEWBCES)', which shows that X'00' is Unspecified while X'01' is explicitly AMODE=24. I believe this is from the days before there were AMODEs and RMODEs, perhaps some concern that Unspecified would have to be treated specially, though I'm not aware that it ever is. The treatment of AMODE & RMODE by the binder is described in the Program Management User's Guide and Reference in the Chapter "Creating programs from source modules", section "Addressing and Residence modes". As well of course under their respective options. Careful looking at the description of "Linkage Editor" processing, which is specifically talking about the very old linkage editor, which you'd only get with a few names such as HEWLKED. That's not the binder, it's talking about some of the usually not problematic differences. (Most everything uses the binder. SMP/E always uses the binder, never the linkage editor.) On Wed, 3 Feb 2021 11:57:07 -0500 Thomas David Rivers wrote: > > > > > I could find nothing in the "Program Management: Advanced Facilities" > > doc that indicated an AMODE flag value of B'00' is any different/special > > verses B'01' (it is surprising that there are 2 AMODE 24 options there.) > > I _did_ find a parenthentical comment in the book "z/OS MVS Programming: > Assembler Services Guide", in the section titled "Linkage editor > and binder support of AMODE and RMODE", in the sub-section of > "Linkage editor RMODE processing". It says: > >The linkage editor determines the RMODE of each CSECT. If the RMODEs >are all the same, the linkage editor assigns that RMODE to the load > module. >If the RMODEs are not the same (ignoring the RMODE specification on > common >sections), the more restrictive value, RMODE 24, is chosen as the > load module's RMODE. > > > So - it seems any RMODE specification on a common section (empty or not, > I suppose) > is ignored. > > I didn't (yet) find a similar statement about AMODE... > > Just wanted to leave this here for the future. > >- Dave R. - > > -- > riv...@dignus.comWork: (919) 676-0847 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64 bit Assembler DLL app PSECT parm
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=MIXED parm, or (preferable so it works regardless), put quotes around the symbol names on the control statements. If you look at the SYSDEFSD produced by the binder, it quotes these: IMPORT CODE64,'SYSADATA','opendata' On 22 Aug 2019 18:55:24 -0400 Joseph Reichman wrote: > Did that my problem now Is that I am getting unresolved in the Assembler > program which is calling my DLL, > the DLL exported function which is a C program -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64 bit Assembler DLL app PSECT parm
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 believe it's the same for the entire compilation unit, but the specification is that it corresponds to the function.) The environment address comes from the caller loading the function descriptor -- the R-con/V-con pair for that function. Where V(function) gives the address of the code, R(function) gives the address of the "environment". That then gives the function the base location for its "writable-static area" on entry -- the non-reentrant area containing writable data items and static data items. Thus when an XPLINK function is to call another function (exception OS linkage), it needs a descriptor to do so. As the address of the environment is unique to each instance of the program (LE enclave), the descriptor of a RENT-compiled program has to live in the WSA so that it can be updated with the environment address of the target program, unlike a V-con which can be relocated during load time. (The V-con in the descriptor also needs to be updated in support of DLLs, i.e. if the function being called is not within the calling module). The net of this is that in XPLINK you need the PSECT in concert with the call macro (CELQCALL), and that call macro automatically takes care of allocating the descriptor. The manual says only under the CELQCALL usage notes: 2. This macro requires that a PSECT was defined by the CELQPRLG prolog macro Though I don't see where there is a similar note, CEEPDDA and CEEPLDA also both require a PSECT for XPLINK (perhaps because these macros also work for non-XPLINK DLLs). These allow you to define and reference data items your environment (WSA) which are exportable/importable respectively. On 21 Aug 2019 11:17:24 AM Joseph Reichman wrote: > Just looked thru LE book shelf would be nice > If they had programming examples > Or at the very least documentation on the parameters used for the EDC macros -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about a Program Object's MIGRATABLE attribute
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 object in a PDSE or UNIX. All such operations always requires the binder. * Though there is a bit in the PDS Directory Entry (IHAPDS PDSNMIG), a load module cannot have this attribute. That bit is remapped for a program object, in a load module it is part of PDS2RLDS. Thus you can (for instance) read the directory of a PDSE and still determine if the member is "migratable". A bit is also defined in the PMAR (IEWPMARL PMARL_NMIG). * There is a relationship with the binder COMPAT option, to the extent that the binder has automatically determined the COMPAT level. If the user decides to set COMPAT to some not-required higher level (perhaps to exploit some non-executable feature like binder COMPRESSion), the MIGRATABLE option can still be on. * Besides the two macros, AMBLIST also reports on the MIGRATABLE bit. This is documented in Diagnosis: Tools and Service Aids, that it will print either NON-MIGR or MIGRATE (the explanation of those is no more detailed than the macros). * One of the reasons for setting non-migratable is that the module "text" exceeds 16MB. Binder has elected to not enumerate all the possible reasons. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using the Binder API and MetalC
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 when included in a MetalC > program. > Below is the result of including the binder API header as provided by IBM: > > ERROR CCN3244 /usr/include/__iew_api.h:659 External variable __IEW_GE > cannot be redefined. > . . . > ERROR CCN3244 /usr/include/__iew_api.h:530 External variable __IEW_AD > cannot be redefined. > CCN0793(I) Compilation failed for file //'TSOUSER.TEST.CSRC(TESTBIND)'. > Object file not created. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about the z/OS Binder API
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 it sounds like you've done) would be acceptable. Yeah that's been the problem with MODMAP. In general for this sort of thing you should be creating the workmod (CREATEW) with INTENT=ACCESS and doing the INCLUDE with ATTRIB=Y to preserve things. That is what is done for both IEBCOPY (between PDS & PDSE) and UNIX cp/mv (from UNIX filesystem to dataset). I presume you are doing that, otherwise you would need to rebind (BINDW) prior to using GETE. Unfortunately that's the problem, the use of MODMAP changes the module structure, and using INTENT=BIND, thus requiring a BINDW call before doing GETE, can potentially change the module organization (i.e. change locations of items). Barry On 3 Jul 2018 20:25:25 + Farley, Peter x23353 wrote: > Hi Barry, > > Thanks for the detailed reply. I understand a bit more about the structure > now. I may be able to examine the ER data to get the information instead of > scanning the class table, > but if the ED table entry physically precedes the ER entry it may be tricky > to coordinate within the current code structure. Scanning the class entries > is already coded, and at least that works for now. > > Unfortunately the application is scanning existing executables, none of which > was bound (or is ever likely to be bound) using the MODMAP option. > Re-binding is not an available option -- unless it could be created > on-the-fly in the created in-memory workspace? > Is that possible without actually rewriting the executable to the input > library? How much external knowledge of the original binding parameters > (entry points, AMODE/RMODE, RENT options, etc.) > is necessary but not available in an INCLUDE'd existing executable program? > And what may be needed if it is a really OLD executable program from > decades-ago linkage? > > I will consider entering an RFE, thanks for the suggestion. In the meantime, > I do have at least one working alternative to collect the needed data. > > Again my sincere thanks for your help, it is much appreciated. > > Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about the z/OS Binder API
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 those ESD types. The Class offset is the offset of that item within the class, as you say. The Element offset is the offset of that item within the element. That footnote may have been meant to say that with respect to inputs (PUTD), for an ED or ER type the binder will provide the value regardless of what you specify, but for LD you must provide one (probably it just shouldn't say ED). In the binder MODULE MAP output the corresponding heading on this column is "SECTION OFFSET" as the section name is really describing the element contributions within the defined class(es). In "Using the binder application programming interfaces (APIs) -> Understanding binder programming concepts -> Organization of data in the program module -> Multiple-text class modules, load segments and ESD offsets", there is a description of finding the SEGMENT offset, the offset of the class within the segment (for a single segment module, the offset within the module), which is just as you described it. It seems like a useful RFE to submit to ask for a new ESD_SEGM_OFFSET. The binder would have to go back through all the ESD records and update the ED, LD, PR, and ER records with the calculated value after it determined how it was segmented and bound. There is one other way which is to build the module with the MODMAP option. Then the MODMAP can be read from the module and it contains a mapping of the ESDs relative to their owning segments. See the description of the MODMAP option in the Program Management: User's Guide & Reference and the description of the MODMAP structure and how to read it in the Program Management: Advanced Facilities manual in "Data areas -> Module Map". Barry On 2 Jul 2018 20:49:27 + Farley, Peter x23353 wrote: > The documentation for the z/OS V2.2 Binder API in the manual "z/OS MVS > Program Management: Advanced Facilities" in "Appendix D. Binder API buffer > formats", page 279 (PDF page count 297) has a footnote #3 for field > ESD_ELEM_OFFSET which says: > > 3. Calculated on the ED and ER records, required input to LD. > > That note says to me that if I INCLUDE an existing program (object or load > module) into a Binder work space using the Binder API's, then for ED entries > in the ESD obtained for that program using FUNC=GETD for TYPE=ESD I should > see the element offset for the class of that section. > > As it turns out, the Binder API FUNC=GETD for TYPE=ESD always returns a > binary zero in that field. No matter what VERSION level of the API macros is > used (I have tried all version numbers from 4 up to 7) the field > ESD_ELEM_OFFSET is always a zero. This holds true for both program objects > loaded form a PDSE and load modules loaded from a PDS. > > For load modules loaded from a PDS, the "class" offset is actually zero > (B_TEXT is the only class of a load module) so the zero value for a load > module loaded form a PDS is actually accurate. However, for a complex > program object (COBOL V5+ or C/C++, etc.) it is not accurate. > > The other offset field in the ED entry (field ESD_CLASS_OFFSET) accurately > contains the offset from the start of the containing Binder class section, > but nowhere does the ED entry contain the offset of the CLASS from the start > of the loaded program. It was my impression (perhaps wrongly) that the > Binder API should tell me that offset in each ED entry for an ESD section. > > To get to the actual start of a particular section of code in a loaded > program it seems that you also have to use FUNC=GETN for NTYPE=CLASS to get > all of the CLASS names and their respective offsets (field name BNL_SEGM_OFF) > and add that value to the ESD_CLASS_OFFSET to find the code in storage. > Which means you have to search the CLASS names table for each ED > section > name using the name at ESD_RES_CLASS_PTR to find the containing class name > and then extract the offset from that CLASS entry. > > Is this expected behavior of the Binder API, or is this a possible > error/failure in the API? Should that class offset value from BNL_SEGM_OFF > in the CLASS entry also be stored into the ESD_ELEM_OFFSET field > automatically by the Binder API when a module is INCLUDEd into a workspace, > or not? > > If I am just misreading the API documentation, I would appreciate any > enlightenment you can provide. > > Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and STRIPSECT? (was: ... INCLUDE only when necessary)
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 addresses a misbehavior of SMP/E which secularly piles up private
> sections (Which I think are something programmers should avoid anyway.
> But Pascal reportedly dotes on them.)
>
> Note: For a section to be considered unreferenced, it must:
> ...
> Not be the target of a control statement
> (Such as ORDER?)
>
> Does SMP/E respect STRIPSEC? Does it cause no problems, e.g. with
> RESTORE? How might it interact with the "++MOD(...) CSECT(...)"
> argument?
>
> Thanks again,
> gil
Can't really blame SMP/E for accumulating them, that's the binders fault. For
a given section name, it quietly deletes same-named duplicates it finds (if
any), so for an unnamed section it has no handle.
Since SMP/E does not document recognizing STRIPSEC on the JCLIN PARM, I expect
it would be ignored (you might get away with using SETOPT if you really had
some need for this).
I would hope however that modules are not shipped which contain unnecessary
unnamed sections! Though sometimes unreferenced sections, named or not, are
there for a reason and should not be removed.
That said I don't think SMP/E could care about unnamed sections, only ones that
it can have been told the names of.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: program mgmt binder include only when necessary
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 18:27:32 -0700 Frank Swarbrick wrote: > > Is there an option that tells the binder to INCLUDE a module only if it > resolves at least one unresolved symbol? > > My specific case is the CICS/MQ stub library. 99% of our CICS programs do > not use MQ, yet currently I have our CICS compile proc do an INCLUDE of this > module in order to satisfy the one case where it is needed. Since CICS and > MQ do not provide aliases of the actually entry points, AUTOCALL does not > find the module (CSQCSTUB). So it seems to me that something that would be > useful would be a happy middle between "always include this member" and what > AUTOCALL does. > > The "obvious" other option is to do the INCLUDE of this module only for this > program. This may seem strange, but our inhouse written change control > process does not currently allow for this. Because almost every other symbol > is resolved simply by AUTOCALL; and for the one that doesn't (the DFHELII > stub) we simply always do an INCLUDE for that if the compile is for a CICS > program. Obviously we can enhance our system to allow us to specify for each > program any additional modules it requires. But this seems such an "obvious" > feature to me that I wonder why its not supplied (if that is the case). > > Am I just missing what I am looking for? > > If I'm not missing it, would you vote for an RFE for such a feature? > > Frank > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
Sorry if I've confused the matter. What I meant was that only a very few important and relatively simple changes to the definition of OBJ objects and load module programs are made (nothing that would require new constructs). AMODE 64 is an example of one of those. Other than those, 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 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 external symbol names. > > > > While it does the intended job, the Prelinker has several > > drawbacks, such as the inability to incrementally rebind a module > > so created (read "csect replacement"). The prelinker does not > > handle GOFF object modules such as produced by C/C++ with XPLINK > > and COBOL V5. GOFF object modules can define characteristics of a > > program which cannot be represented in a load module. > > > > Note that the binder has been producing program objects for over 25 > > years. It is difficult to make significant enhancements to OBJ > > object module and load module formats. Some important things have > > been added such as AMODE 64 and quad-word alignment. > > > > barry_lichtenst...@us.ibm.com > > Since COBOL does not and will not in the foreseeable future need > amode 64 I find the argument un helpful. > > Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
Hi Bill, Point taken. But my point was that if your JCL uses a PDS rather than a PDSE, in some cases you'll get the binder error "IEW2606S 4B39 MODULE INCORPORATES VERSION 3 PROGRAM OBJECT FEATURES AND CANNOT BE SAVED IN LOAD MODULE FORMAT." As the PL/I procs do (the ones with "P" in their names), invoking the Prelinker can allow a subset of programs to be transformed into a linkage-editor compatible format. It only works when the compiler produces XOBJ object modules, not with GOFF. Simply, you can always make SYSLMOD be a PDSE, but you cannot always 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 > > 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 > > external symbol names. > > > > While it does the intended job, the Prelinker has several drawbacks, such > > as the inability to incrementally rebind a module so created (read "csect > > replacement"). The prelinker does not handle GOFF object modules such as > > produced by C/C++ with XPLINK and COBOL V5. GOFF object modules can define > > characteristics of a program which cannot be represented in a load module. > > > > Note that the binder has been producing program objects for over 25 years. > > It is difficult to make significant enhancements to OBJ object module and > > load module formats. Some important things have been added such as AMODE > > 64 and quad-word alignment. > > > > barry_lichtenst...@us.ibm.com > > > > Sorry, I was still being unclear. What I meant is that if you run JCL which > uses a PDSE as output for executable programs, then you are using a PDSE. If > you run JCL that uses a PDS, then you are using a PDS. Using a PDSE in the > JCL to compile a PL/I program does not mean that PL/I can only produce code > requiring Program Objects, which was that little side-track in the discussion. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
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 external symbol names. While it does the intended job, the Prelinker has several drawbacks, such as the inability to incrementally rebind a module so created (read "csect replacement"). The prelinker does not handle GOFF object modules such as produced by C/C++ with XPLINK and COBOL V5. GOFF object modules can define characteristics of a program which cannot be represented in a load module. Note that the binder has been producing program objects for over 25 years. It is difficult to make significant enhancements to OBJ object module and load module formats. Some important things have been added such as AMODE 64 and quad-word alignment. barry_lichtenst...@us.ibm.com On Tue, 26 Jan 2016 13:52:28 -0600, Bill Woodger wrote: > Sorry not to be clear that I was paraphrasing the PL/I Programming Guide: > > > "Cataloged procedures IBMZCB and IBMZCBG use features of the program > management binder introduced in DFSMS/MVS ® 1.4 in place of the prelinker > supplied with Language Environment. These procedures produce a program object > in a PDSE. > > Cataloged procedures IBMZCPL, IBMZCPLG and IBMZCPG use the prelinker > supplied with Language Environment and produce a load module in PDS. Use > these procedures if you do not want to use a PDSE. > > ... > > The IBMZCB cataloged procedure, shown in Figure 11 on page 142, includes two > procedure steps: PLI, which is identical to cataloged procedure IBMZC, and > BIND, > which invokes the Program Management binder (symbolic name IEWBLINK) to > bind the object module produced in the first procedure step. > ... > > The IBMZCPL cataloged procedure, shown in Figure 13, includes three procedure > steps: PLI, which is identical to cataloged procedure IBMZC; PLKED, which > invokes the Language Environment prelinker; and LKED, which invokes the > linkage editor (symbolic name IEWL) to link-edit the object module produced in > the first procedure step." > > At the end of the day, it is the JCL which determines where the executable > program resides. > > PL/I can create programs which do not require to be a Program Object. COBOL > V5 cannot. > > Aside 1: Without an "unless we feel like it" clause, I'm not buying a "we > won't do that" unless the Board are behind it. > > Aside 2: Who thought it was a good idea to name a place where one or more > Object Programs can turn up a Program Object. That's clear, right? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Critique my Binder RCF?
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 sequence they are specified on the ORDER statement. The syntax of the ORDER statement is:" It looks as though an attempt was made to document how ORDER affects sections which contribute to more than one binder class. Thanks for catching this! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AMASPZAP to C main marked as $private
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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Binder attributes
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 you have an existing program module in a library then you can use INCLUDE -ATTR to have the binder set the reusability to that of the included module. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
