Re: COBOL compiler option to list libraries from which COPY members were loaded?
Thanks Sri. As a prior poster pointed out, it is already there. I just missed finding it in the listings that I browsed. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Sunday, September 5, 2021 8:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL compiler option to list libraries from which COPY members were loaded? > I was looking around at listings from multiple incarnations of COBOL > compilers and did not find any which listed the libraries from which > copy members were loaded, as HLASM does for macros and copy members. > > Has there ever been such a compiler option? Peter, You can use XREF(FULL) compiler option https://urldefense.com/v3/__https://www.ibm.com/docs/en/cobol-zos/6.3?topic=options-xref__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Ym5rdXc2PlrfKhGjo5-AqV6Mny2uMooqRDoj1KZ0R8xkErmaW8TLfVL3TsGCX2_mnxilKg$ and here is an example of the output https://urldefense.com/v3/__https://www.ibm.com/docs/en/cobol-zos/6.3?topic=references-example-xref-output-copybasis-cross__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Ym5rdXc2PlrfKhGjo5-AqV6Mny2uMooqRDoj1KZ0R8xkErmaW8TLfVL3TsGCX29p8X7-Xg$ Thanks, Kolusu -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL compiler option to list libraries from which COPY members were loaded?
<*Doh!*> I missed seeing that part of the listings entirely. And it has the same page title back at least as far back as ECOBOL V4.1.0. Many thanks for enlightening me. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Vels Sent: Sunday, September 5, 2021 7:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL compiler option to list libraries from which COPY members were loaded? I use "IBM Enterprise COBOL for z/OS 6.3.0 P210301" and there is a "COPY/BASIS cross-reference of text-names, library names and dataset information" section near the bottom of the compiler listing. I also use "HLASM R6.0" and it has a "Macro and Copy Code Source Summary" near the bottom of the listing. > On Sun, Sep 5, 2021 at 13:57 Farley, Peter x23353 < > 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > > > I was looking around at listings from multiple incarnations of COBOL > > compilers and did not find any which listed the libraries from which > > copy members were loaded, as HLASM does for macros and copy members. > > > > Has there ever been such a compiler option? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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
Hi R'Shmuel AMV"SH, You said: "... That's why you have to rebuild from the object modules if a reentrant module was incorrectly linked as REUS. ...". If you have the PDS Command Processor (CBT File 182) or Startool, you can "edit" the directory entry to add/remove these and other attributes (e.g. AC(0)/AC(1)). Shana Tovah Regards, David On 2021-09-05 17:44, Seymour J Metz wrote: There used to be a children's game called telegram, where a group of children sat in a circle, one got a text and quietly read a short text to an adjacent chile, who quietly repeated it to the next child, etc., until it came back to the first child, who compared it to the original text. Those who know wrote what they aactually wrote, not what was attributed to them. BTW, the text that you cited is incorrect;it's not whether the icluded module actually is refreshable or reentrant that affects the linkage editor, it's whether it is flagged with the attribute. That's why you have to rebuild from the object modules if a reentrant module was incorrectly linked as REUS. -- Shmuel (Seymour J.) Metz https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7C%7C843fac68f3a241365cd808d970b6669c%7C84df9e7fe9f640afb435%7C1%7C0%7C637664751026547371%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=OKM89FQ1NHIocWcpseIqFif00l3K4gvK1QpKtrha4AQ%3Dreserved=0 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponce...@bcs.org.uk] Sent: Saturday, September 4, 2021 8:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RENT binder option Sure. Thank you for confirming that those who know agree with what I have said - for the benefit of those who do not know and who might otherwise be misled into thinking that REFR and RENT LMODs need to be 'protected' from modifying themselves and/or can modify themselves or whatever nonsense else. BTW Off-topic, my hard-copy "MVS/Extended Architecture Linkage Editor and Loader Users's Guide" version 2 release 2.0 (order number GC26-4143-1) second edition (June 1986) agrees with your MVS/370 linkage editor user's guide from 1985, as quoted. And I would most respectfully point out that e.g. "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" does indeed apply if any module's OBJ code has not been link-edited with the REFR attribute but is then included in the LMOD's link-edit SYSLIN cards, *then* the resulting LMOD is marked not REFR regardless of all other link-edited modules included in the said SYSLIN cards having been marked REFR. Thanks again for 'absolving' me from having to defend and protect systems programming from being reduced to mere systems administration, then to level-2 and then level-1 tech support, then to help-desk support - as per Micro$oft Windoze. I thoroughly appreciate your supporting mainframe systems programming. I can now gladly drop out of this thread. Cheers, Chris Poncelet (retired etc.) On 04/09/2021 11:31, Joe Monk wrote: "A module is REFR or RENT - not if it is link-edited as REFR or RENT, but if it never modifies its own storage." Why do you keep lecturing us on things we already know? Jim Mulder knows it best as he is the frickin author of z/OS (well he and Peter Relson). Please stop. "But it is the programmer/developer who is responsible for ensuring that the module's code is indeed REFR or RENT - and it is not the linkage-editor or binder's responsibility." To quote the MVS/370 linkage editor user's guide from 1985: "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." "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." So, it has been the case since 1985 that the linkage editor does check the input load modules, and will not mark a non-RENT/REFR load module as having those attributes. Jim Mulder has been at IBM for 42 years, so 1985 ... yeah he would've been working on MVS then. Thanks. Joe On Fri, Sep 3, 2021 at 9:05 PM CM Poncelet wrote: At the risk of inviting 'flak', I suspect that there is a misconception of what RENT and REFR modules actually are. By definition, RENT and REFR modules should never modify themselves (excluding the peculiar case of a RENT module that ENQ's on part of its code, modifies it, restores it to what it was, then DEQ's it - as this would not violate the definition of RENT modules being concurrently executable by multiple tasks.) A module is REFR or RENT - not if it is link-edited as REFR or RENT, but if it never modifies its own storage. In other words, all modifiable storage must first be
Re: COBOL compiler option to list libraries from which COPY members were loaded?
> I was looking around at listings from multiple incarnations of COBOL > compilers and did not find any which listed the libraries from which > copy members were loaded, as HLASM does for macros and copy members. > > Has there ever been such a compiler option? Peter, You can use XREF(FULL) compiler option https://www.ibm.com/docs/en/cobol-zos/6.3?topic=options-xref and here is an example of the output https://www.ibm.com/docs/en/cobol-zos/6.3?topic=references-example-xref-output-copybasis-cross Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL compiler option to list libraries from which COPY members were loaded?
On Sun, 5 Sep 2021 21:33:49 +, Farley, Peter x23353 wrote: >... >I know you have pointed out several flaws in that support already like needing >at least one (possibly empty) PDS/E in the concatenation ahead of the Unix >directories. > I encountered that problem/circumvention with Rexx SYSEXEC. Support says DSORG=PO is required. Alas, JCL makes DSORG mutex with PATH. HLASM SYSLIB works well after IBM fixed a couple APARS for nested COPYs in a mixed PDS/UNIX SYSLIB concatenation, And similar problem/circumvention with AMATERSE UNPACK SYSUT1. When I report such problems, Support tends to say, "That needs to be a data set." They are unmoved when I read them the definition from "Using Data Sets". >I think I will write my own test of that DESERV functionality just to see >where the bumps in the road are. > Good luck, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL compiler option to list libraries from which COPY members were loaded?
On Mon, 6 Sep 2021 09:15:05 +1000, Peter Vels wrote: >I use "IBM Enterprise COBOL for z/OS 6.3.0 P210301" and there is a >"COPY/BASIS cross-reference of text-names, library names and dataset >information" section near the bottom of the compiler listing. > How are UNIX members reported? >I also use "HLASM R6.0" and it has a "Macro and Copy Code Source Summary" >near the bottom of the listing. > And HLASM re;ports UNIX members nicely. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL compiler option to list libraries from which COPY members were loaded?
I use "IBM Enterprise COBOL for z/OS 6.3.0 P210301" and there is a "COPY/BASIS cross-reference of text-names, library names and dataset information" section near the bottom of the compiler listing. I also use "HLASM R6.0" and it has a "Macro and Copy Code Source Summary" near the bottom of the listing. > On Sun, Sep 5, 2021 at 13:57 Farley, Peter x23353 < > 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > > > I was looking around at listings from multiple incarnations of COBOL > > compilers and did not find any which listed the libraries from which copy > > members were loaded, as HLASM does for macros and copy members. > > > > Has there ever been such a compiler option? > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL compiler option to list libraries from which COPY members were loaded?
My shop uses Enterprise COBOL 6.2 and that information appears in the compile listing. I am not sure which compiler option influences that behavior but it works by default. I rely on it often. On Sun, Sep 5, 2021 at 13:57 Farley, Peter x23353 < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > I was looking around at listings from multiple incarnations of COBOL > compilers and did not find any which listed the libraries from which copy > members were loaded, as HLASM does for macros and copy members. > > Has there ever been such a compiler option? > > If not I suspect an RFE is in order. Business justification: Needed as an > aid to verification that the most recent COPY members were used during > compilation as part of SDLC promotion process to QA/UAT/production status. > Bonus points for listing the date/time of the member in each library (if > available) as part of the compile listing. > > Peter > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- 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
There is no requirement that a self modifying reentrant module ever restore its original contents. The sole requirement is that concurrent invocations yield the correct result. it doesn't matter whether serialization is CS, ENQ, latch, lock, TS or "E. None of the above." Likewise for RENT: the sole requirement is that it produce the correct result even if refreshed in meias res. Now, for both REFR and REFR there are contexts where IBM imposses additional constraints, e.g., authorized concatenations, PLPA, REFRPROT. And just because it is permissible for REFR and RENT code to modify itself doesn't mean that yoush should write self modifying code for production. IMHO such could should only be written as classroom exercises. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponce...@bcs.org.uk] Sent: Friday, September 3, 2021 10:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RENT binder option At the risk of inviting 'flak', I suspect that there is a misconception of what RENT and REFR modules actually are. By definition, RENT and REFR modules should never modify themselves (excluding the peculiar case of a RENT module that ENQ's on part of its code, modifies it, restores it to what it was, then DEQ's it - as this would not violate the definition of RENT modules being concurrently executable by multiple tasks.) A module is REFR or RENT - not if it is link-edited as REFR or RENT, but if it never modifies its own storage. In other words, all modifiable storage must first be GETMAINed (including the module's savearea storage) and any WTO(R)s and DYNALLOC/SVC-99s, DCBs, ACBs and/or RPLs etc. must then use the 'list' and 'executable' forms of these macros/DSECTs to avoid modifying the module's own storage.) As a 'first line of defence', such modules should be coded as RSECTs and not as CSECTs - and the assembler will then trap (with a CC=08, IIRC) any direct attempt to modify the module's own storage. But it is the programmer/developer who is responsible for ensuring that the module's code is indeed REFR or RENT - and it is not the linkage-editor or binder's responsibility. Arguing that REFR or RENT modules need to be 'protected' from modifying themselves, or by others, is methinks beside the point - because such modules should have been coded in such way that they *never* modify themselves to begin with. If others can modify them, then it is these other modules that should be investigated, not the REFR or RENT ones. On 03/09/2021 13:34, Paul Gilmartin wrote: > On Thu, 2 Sep 2021 16:02:07 -0400, Jim Mulder wrote: > >> I found IBM RENT modules that modified themselves >> 15 years ago when I was experimenting to see what would >> happen if we tried to page-protect RENT modules. I have a list: >> > Have you a similar list of IBM REFR modules that modify themselfes? > > Does the setting of REFRPROT affect processing of modules > marked RENT but not REFR? > > What were the reusability attributes of the module in OA25089? > >> ANTMAIN >> ANTSDMLK >> IEAVNIPX >> EZATNF >> IOEFSKN >> FNMVZJV >> FNMVZCVA >> EZAXVMCF >> DSNHDECP >> DSN9PARM >> DSN3INI >> CNMINIT >> CNMCSSIM >> CNMCSSIC >> >> We subsequently removed the unintended RENT from IEAVNIPX. >> So we don't page-protect RENT modules (except for experimental >> purposes under control of another undocumented DIAGxx TRAP name), >> and we implemented REFRPROT instead. I haven't heard about >> any IBM modules that get broken by REFRPROT. > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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
It is certainly true that there are cases where a self modifying REFR and RENT module is more efficient, but IMHO that is asking for trouble. It's the sort of think that I would ask a student to do while learning the concepts, but warn against doing in production. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Andrew Rowley [and...@blackhillsoftware.com] Sent: Saturday, September 4, 2021 4:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RENT binder option On 4/09/2021 12:05 pm, CM Poncelet wrote: > By definition, RENT and REFR modules should never modify themselves > (excluding the peculiar case of a RENT module that ENQ's on part of its > code, modifies it, restores it to what it was, then DEQ's it - as this > would not violate the definition of RENT modules being concurrently > executable by multiple tasks.) > > A module is REFR or RENT - not if it is link-edited as REFR or RENT, but > if it never modifies its own storage. If a RENT module is not allowed to modify it's own storage, what is the difference between RENT and REFR? A RENT module can modify its own storage, it just needs to be done in a way that is synchronized correctly between multiple tasks. As a contrived example, imagine you had a module that counted how many times it was invoked. You could keep that counter in program storage, as long as the updates were appropriately synchronized. It doesn't actually matter whether the counter is in GETMAINed storage or in the module itself - either way updates need to be synchronized. I wouldn't be surprised if a modifiable field in a RENT module is one of the best performing ways to keep a reference to shared state information. Conceptually it is the same as static fields in e.g. a C++ or Java class - the value is shared by every running instance, while information that is specific to an instance is kept in GETMAINed storage. I ran into this many years ago when I "cleaned up" and removed an empty library from the STEPLIB of one of our subsystems. That suddenly meant that the STEPLIB was considered APF authorized, which resulted in S0C4 abends when the subsystem was started and it tried to store information in its RENT load module. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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
1. Neither of those gentlemen is the author of z/OS, nor has either ever claimed to be. They have both written code for z/OS, but so have many others. 2. The quoted text is incorrect; the linkage editor tests how included load modules are flagged, not how they should have been flagged. 3. The testing of the attributes of included modules is much older than 1985. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe Monk [joemon...@gmail.com] Sent: Saturday, September 4, 2021 6:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RENT binder option "A module is REFR or RENT - not if it is link-edited as REFR or RENT, but if it never modifies its own storage." Why do you keep lecturing us on things we already know? Jim Mulder knows it best as he is the frickin author of z/OS (well he and Peter Relson). Please stop. "But it is the programmer/developer who is responsible for ensuring that the module's code is indeed REFR or RENT - and it is not the linkage-editor or binder's responsibility." To quote the MVS/370 linkage editor user's guide from 1985: "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." "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." So, it has been the case since 1985 that the linkage editor does check the input load modules, and will not mark a non-RENT/REFR load module as having those attributes. Jim Mulder has been at IBM for 42 years, so 1985 ... yeah he would've been working on MVS then. Thanks. Joe On Fri, Sep 3, 2021 at 9:05 PM CM Poncelet wrote: > At the risk of inviting 'flak', I suspect that there is a misconception > of what RENT and REFR modules actually are. > > By definition, RENT and REFR modules should never modify themselves > (excluding the peculiar case of a RENT module that ENQ's on part of its > code, modifies it, restores it to what it was, then DEQ's it - as this > would not violate the definition of RENT modules being concurrently > executable by multiple tasks.) > > A module is REFR or RENT - not if it is link-edited as REFR or RENT, but > if it never modifies its own storage. In other words, all modifiable > storage must first be GETMAINed (including the module's savearea > storage) and any WTO(R)s and DYNALLOC/SVC-99s, DCBs, ACBs and/or RPLs > etc. must then use the 'list' and 'executable' forms of these > macros/DSECTs to avoid modifying the module's own storage.) > > As a 'first line of defence', such modules should be coded as RSECTs and > not as CSECTs - and the assembler will then trap (with a CC=08, IIRC) > any direct attempt to modify the module's own storage. But it is the > programmer/developer who is responsible for ensuring that the module's > code is indeed REFR or RENT - and it is not the linkage-editor or > binder's responsibility. > > Arguing that REFR or RENT modules need to be 'protected' from modifying > themselves, or by others, is methinks beside the point - because such > modules should have been coded in such way that they *never* modify > themselves to begin with. If others can modify them, then it is these > other modules that should be investigated, not the REFR or RENT ones. > > > On 03/09/2021 13:34, Paul Gilmartin wrote: > > On Thu, 2 Sep 2021 16:02:07 -0400, Jim Mulder wrote: > > > >> I found IBM RENT modules that modified themselves > >> 15 years ago when I was experimenting to see what would > >> happen if we tried to page-protect RENT modules. I have a list: > >> > > Have you a similar list of IBM REFR modules that modify themselfes? > > > > Does the setting of REFRPROT affect processing of modules > > marked RENT but not REFR? > > > > What were the reusability attributes of the module in OA25089? > > > >> ANTMAIN > >> ANTSDMLK > >> IEAVNIPX > >> EZATNF > >> IOEFSKN > >> FNMVZJV > >> FNMVZCVA > >> EZAXVMCF > >> DSNHDECP > >> DSN9PARM > >> DSN3INI > >> CNMINIT > >> CNMCSSIM > >> CNMCSSIC > >> > >> We subsequently removed the unintended RENT from IEAVNIPX. > >> So we don't page-protect RENT modules (except for experimental > >> purposes under control of another undocumented DIAGxx TRAP name), > >> and we implemented REFRPROT instead. I haven't heard about > >> any IBM modules that get broken by REFRPROT. > > -- gil > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > . > > > > -- > 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
REFR pre-MVS was used by the Machine Check Handler (MCH) to determine whether it was allowed to refresh code after an uncorrectable memory failure. That recovery code does not exist in z/OS. RFER and RENT were independt options; a module could be both, one or neither. RENT controlled serialization. Loading into SP252 key 0 was an RAS issue rather than required behavior. There is and never has been frefreshing of main memory from cache, only from DASD. I know of no IBM operating systems that test REFR in order to deternine whether to back up a page. Page-steal from PLPA discards modified pages whether the contains a flagged REFR or not. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponce...@bcs.org.uk] Sent: Saturday, September 4, 2021 5:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RENT binder option AFAIK The difference between RENT and REFR is that REFR pages (or frames) can be stolen without their having first to backed up - because they can be REFReshed from cache or DASD without this affecting the code's execution - whereas RENT code pages do need to be backed up before they can be stolen. On 04/09/2021 09:34, Andrew Rowley wrote: > On 4/09/2021 12:05 pm, CM Poncelet wrote: >> By definition, RENT and REFR modules should never modify themselves >> (excluding the peculiar case of a RENT module that ENQ's on part of its >> code, modifies it, restores it to what it was, then DEQ's it - as this >> would not violate the definition of RENT modules being concurrently >> executable by multiple tasks.) >> A module is REFR or RENT - not if it is link-edited as REFR or >> RENT, but >> if it never modifies its own storage. > If a RENT module is not allowed to modify it's own storage, what is > the difference between RENT and REFR? > > A RENT module can modify its own storage, it just needs to be done in > a way that is synchronized correctly between multiple tasks. As a > contrived example, imagine you had a module that counted how many > times it was invoked. You could keep that counter in program storage, > as long as the updates were appropriately synchronized. It doesn't > actually matter whether the counter is in GETMAINed storage or in the > module itself - either way updates need to be synchronized. > > I wouldn't be surprised if a modifiable field in a RENT module is one > of the best performing ways to keep a reference to shared state > information. Conceptually it is the same as static fields in e.g. a > C++ or Java class - the value is shared by every running instance, > while information that is specific to an instance is kept in GETMAINed > storage. > > I ran into this many years ago when I "cleaned up" and removed an > empty library from the STEPLIB of one of our subsystems. That suddenly > meant that the STEPLIB was considered APF authorized, which resulted > in S0C4 abends when the subsystem was started and it tried to store > information in its RENT load module. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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
There used to be a children's game called telegram, where a group of children sat in a circle, one got a text and quietly read a short text to an adjacent chile, who quietly repeated it to the next child, etc., until it came back to the first child, who compared it to the original text. Those who know wrote what they aactually wrote, not what was attributed to them. BTW, the text that you cited is incorrect;it's not whether the icluded module actually is refreshable or reentrant that affects the linkage editor, it's whether it is flagged with the attribute. That's why you have to rebuild from the object modules if a reentrant module was incorrectly linked as REUS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM Poncelet [ponce...@bcs.org.uk] Sent: Saturday, September 4, 2021 8:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RENT binder option Sure. Thank you for confirming that those who know agree with what I have said - for the benefit of those who do not know and who might otherwise be misled into thinking that REFR and RENT LMODs need to be 'protected' from modifying themselves and/or can modify themselves or whatever nonsense else. BTW Off-topic, my hard-copy "MVS/Extended Architecture Linkage Editor and Loader Users's Guide" version 2 release 2.0 (order number GC26-4143-1) second edition (June 1986) agrees with your MVS/370 linkage editor user's guide from 1985, as quoted. And I would most respectfully point out that e.g. "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" does indeed apply if any module's OBJ code has not been link-edited with the REFR attribute but is then included in the LMOD's link-edit SYSLIN cards, *then* the resulting LMOD is marked not REFR regardless of all other link-edited modules included in the said SYSLIN cards having been marked REFR. Thanks again for 'absolving' me from having to defend and protect systems programming from being reduced to mere systems administration, then to level-2 and then level-1 tech support, then to help-desk support - as per Micro$oft Windoze. I thoroughly appreciate your supporting mainframe systems programming. I can now gladly drop out of this thread. Cheers, Chris Poncelet (retired etc.) On 04/09/2021 11:31, Joe Monk wrote: > "A module is REFR or RENT - not if it is link-edited as REFR or RENT, but > if it never modifies its own storage." > > Why do you keep lecturing us on things we already know? > > Jim Mulder knows it best as he is the frickin author of z/OS (well he and > Peter Relson). > > Please stop. > > "But it is the > programmer/developer who is responsible for ensuring that the module's > code is indeed REFR or RENT - and it is not the linkage-editor or > binder's responsibility." > > To quote the MVS/370 linkage editor user's guide from 1985: > > "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." > > "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." > > So, it has been the case since 1985 that the linkage editor does check the > input load modules, and will not mark a non-RENT/REFR load module as having > those attributes. Jim Mulder has been at IBM for 42 years, so 1985 ... yeah > he would've been working on MVS then. > > Thanks. > > Joe > > > > On Fri, Sep 3, 2021 at 9:05 PM CM Poncelet wrote: > >> At the risk of inviting 'flak', I suspect that there is a misconception >> of what RENT and REFR modules actually are. >> >> By definition, RENT and REFR modules should never modify themselves >> (excluding the peculiar case of a RENT module that ENQ's on part of its >> code, modifies it, restores it to what it was, then DEQ's it - as this >> would not violate the definition of RENT modules being concurrently >> executable by multiple tasks.) >> >> A module is REFR or RENT - not if it is link-edited as REFR or RENT, but >> if it never modifies its own storage. In other words, all modifiable >> storage must first be GETMAINed (including the module's savearea >> storage) and any WTO(R)s and DYNALLOC/SVC-99s, DCBs, ACBs and/or RPLs >> etc. must then use the 'list' and 'executable' forms of these >> macros/DSECTs to avoid modifying the module's own storage.) >> >> As a 'first line of defence', such modules should be coded as RSECTs and >> not as CSECTs - and the assembler will then trap (with a CC=08, IIRC) >> any direct attempt to modify the module's own storage. But it is the >> programmer/developer who is responsible for ensuring that the module's >> code is indeed REFR or RENT - and it is not the linkage-editor or >> binder's
Re: COBOL compiler option to list libraries from which COPY members were loaded?
"If the member is any PDSE member, the information should be available from FAMS." Or from DESERV for programmers whose company has not signed the NDA and paid the license fee to get FAMS documentation. And since DESERV FUNC=GET requires only an open BPAM DCB which can be for a DD concatenation which may include Unix directories, I would hope that at least some of the same information would also be available (at least modify time, though probably not many of the other ISPF statistics) for Unix files used as copy members. I know you have pointed out several flaws in that support already like needing at least one (possibly empty) PDS/E in the concatenation ahead of the Unix directories. I think I will write my own test of that DESERV functionality just to see where the bumps in the road are. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Sunday, September 5, 2021 3:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL compiler option to list libraries from which COPY members were loaded? On Sun, 5 Sep 2021 17:57:12 +, Farley, Peter x23353 wrote: >I was looking around at listings from multiple incarnations of COBOL compilers >and did not find any which listed the libraries from which copy members were >loaded, as HLASM does for macros and copy members. >... >... Bonus points for listing the date/time of the member in each library > (if available) as part of the compile listing. > I don't believe HLASM shows that information either. It would be useful. If the PDS/PDSE member was edited with ISPF, the information should be available from ISPF stats. If the member is a UNIX file, the informattion should be available from tne file timestamp. If the member is any PDSE member, the information should be available from FAMS. Perhaps an RFE should request an API to extract such information independent of ISPF for each of those cases. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Shopz order eliminate superseded service
It's a tradeoff; some superceding PTFs might have PEs. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Saturday, September 4, 2021 9:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Shopz order eliminate superseded service When I order maintenance from Shopz there is the option to eliminate superseded service. should this be normally selected? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL compiler option to list libraries from which COPY members were loaded?
The “Macro and Copy Code Cross Reference “ output of HLASM the concatenation number from which it is fetched is displayed. The MXREF(XREF) or MXREF(FULL) generates this section. Sent from my iPhone > On Sep 5, 2021, at 3:24 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Sun, 5 Sep 2021 17:57:12 +, Farley, Peter x23353 wrote: >> >> I was looking around at listings from multiple incarnations of COBOL >> compilers and did not find any which listed the libraries from which copy >> members were loaded, as HLASM does for macros and copy members. >> ... >> ... Bonus points for listing the date/time of the member in each library >> (if available) as part of the compile listing. >> > I don't believe HLASM shows that information either. It would be useful. > > If the PDS/PDSE member was edited with ISPF, the information should be > available from ISPF stats. > > If the member is a UNIX file, the informattion should be available from tne > file timestamp. > > If the member is any PDSE member, the information should be available > from FAMS. > > Perhaps an RFE should request an API to extract such information independent > of ISPF for each of those cases. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL compiler option to list libraries from which COPY members were loaded?
I think it does unless that info was dropped since I wrote ASYSLIB and pointed out the data display was wrong, as in wrong PDS. ASYSLIB changed the concatenation via changing the DDNAME being used. That was back about 1996 or so. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Sep 5, 2021, at 3:25 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > On Sun, 5 Sep 2021 17:57:12 +, Farley, Peter x23353 wrote: > >> I was looking around at listings from multiple incarnations of COBOL >> compilers and did not find any which listed the libraries from which copy >> members were loaded, as HLASM does for macros and copy members. >> ... >> ... Bonus points for listing the date/time of the member in each library >> (if available) as part of the compile listing. >> > I don't believe HLASM shows that information either. It would be useful. > > If the PDS/PDSE member was edited with ISPF, the information should be > available from ISPF stats. > > If the member is a UNIX file, the informattion should be available from tne > file timestamp. > > If the member is any PDSE member, the information should be available > from FAMS. > > Perhaps an RFE should request an API to extract such information independent > of ISPF for each of those cases. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL compiler option to list libraries from which COPY members were loaded?
On Sun, 5 Sep 2021 17:57:12 +, Farley, Peter x23353 wrote: >I was looking around at listings from multiple incarnations of COBOL compilers >and did not find any which listed the libraries from which copy members were >loaded, as HLASM does for macros and copy members. >... >... Bonus points for listing the date/time of the member in each library > (if available) as part of the compile listing. > I don't believe HLASM shows that information either. It would be useful. If the PDS/PDSE member was edited with ISPF, the information should be available from ISPF stats. If the member is a UNIX file, the informattion should be available from tne file timestamp. If the member is any PDSE member, the information should be available from FAMS. Perhaps an RFE should request an API to extract such information independent of ISPF for each of those cases. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF field data
finally found out that I had a zparm accumuid set to 1 once I changed it to 0 the data started showing up. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL compiler option to list libraries from which COPY members were loaded?
I was looking around at listings from multiple incarnations of COBOL compilers and did not find any which listed the libraries from which copy members were loaded, as HLASM does for macros and copy members. Has there ever been such a compiler option? If not I suspect an RFE is in order. Business justification: Needed as an aid to verification that the most recent COPY members were used during compilation as part of SDLC promotion process to QA/UAT/production status. Bonus points for listing the date/time of the member in each library (if available) as part of the compile listing. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF field data
Open a ticket with IBM. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Giannelli Sent: Saturday, September 4, 2021 6:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF field data It appears that these 2 fields, ENDUSERWN and ENDUSERWN_L in BMC (QWHCEUWN and QWHCEUWN_Var in SMF) are blank for all records from 2 of our LPARS for all DB2 members on those LPARS. The fields are populated from a third LPAR for all DB2 members on that LPAR. I have not found any differences in the DB2 traces. Is there something LPAR specific that would restrict this data? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF field data
Can you identify what the names may map back to? Are they IP host names, NetBIOS computer names? I know DB2 tries to do a reverse look-up when a remote I IP host when they connect to it. If so, could 2 of your LPAR's be using different DNS servers than the 3rd? Or maybe the hosts connecting to the one LPAR have PTR records while the hosts connecting to the other 2 LPAR's don't have PTR records. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF field data
I'm not aware of anything., I'd talk to BMC about this but I suspect it's how the clients are set up. You also didn't say what client connection types. Also it could be a Db2 bug. Again, not being a Db2 specialist, I wouldn't know about a Db2 bug. Cheers, Martin Martin Packer WW z/OS Performance, Capacity and Architecture, IBM Technology Sales +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://mainframeperformancetopics.com Mainframe, Performance, Topics Podcast Series (With Marna Walle): https://anchor.fm/marna-walle Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: "Bill Giannelli" To: IBM-MAIN@LISTSERV.UA.EDU Date: 04/09/2021 14:15 Subject:[EXTERNAL] Re: SMF field data Sent by:"IBM Mainframe Discussion List" It appears that these 2 fields, ENDUSERWN and ENDUSERWN_L in BMC (QWHCEUWN and QWHCEUWN_Var in SMF) are blank for all records from 2 of our LPARS for all DB2 members on those LPARS. The fields are populated from a third LPAR for all DB2 members on that LPAR. I have not found any differences in the DB2 traces. Is there something LPAR specific that would restrict this data? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ispf edit macro "HX" line command
>I do not understand your response, you asked; I asked about line commnad >ISREDIT HX .ZCSR There was a suggestion and my response was that is a line command And it does not work. Sorry for the misunderstanding I did not know the option "quote original message" and It's tapping me to comment On Thu, 2 Sep 2021 10:55:00 -0500, Carmen Vitullo wrote: >I do not understand your response, you asked; > >there is a way to execute "HX" line command >from edit macro ? >ISREDIT HX .ZCSR > >- is a line command > >now you are asking command line ? >so >ISREDIT (CMD) - 'HEX' > >Carmen > >On 9/2/2021 10:14 AM, Weizman arbel wrote: >> ISREDIT HX .ZCSR should work >> >> this is command line >> and there is Does not exist HX in command line (the command is hex on / hex >> off) >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >-- >/I am not bound to win, but I am bound to be true. I am not bound to >succeed, but I am bound to live by the light that I have. I must stand >with anybody that stands right, and stand with him while he is right, >and part with him when he goes wrong. *Abraham Lincoln*/ > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
