Re: SMP/E and Isolating a CSECT within a load module
You do so at the risk of breaking things if someone fails to put an entry point on the END statement of the main module. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jesse 1 Robinson [jesse1.robin...@sce.com] Sent: Monday, January 25, 2021 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E and Isolating a CSECT within a load module The point of my post was that *not* specifying entry point on the END statement may limit your ability relink the composite module if full source is not available. An unusual (and maybe archaic) case no doubt, but why limit your options? Maybe in the days of card source, it was an extra change to make in the case of module rename. In our case we were SOL to provide DR for an associated shop. It was not our fault, but it was at best disappointing. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Saturday, January 23, 2021 8:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: SMP/E and Isolating a CSECT within a load module *** EXTERNAL EMAIL - Use caution when opening links or attachments *** What is the point of specifying an entry point on the END statement of, e.g., a Bessel function subroutine? -- 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, January 22, 2021 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E and Isolating a CSECT within a load module The SYSLIN "ENTRY whatever" is valid if the "whatever" external symbol is in the ESD. (A LISTIDR should display the contents of the MOD's ESD.) So yes, coding "ENTRY whatever" is safer in making sure that an (L)MOD always has a same entry point. It is also the entry point selected by the linkage editor if there is an "ENTRY" statement in SYSLIN: otherwise it's the assembler's "END " that is selected by the LKED. If the assembler source END statement does not specify a label, the default EP is the first byte of the first CSECT in the link-edited (L)MOD. In modular program design, every assembler source MOD should terminate with an "END whatever" statement to specify the assembler's EP for that MOD - where the "whatever" EP is usually the CSECT name, but not necessarily so. Cf. also "Jackson structured programming (JSP)" as in "Principles of Program Design" by Michael A. Jackson. An (L)MOD can have multiple entry points by specifying "ALIAS mod1,mod2" in SYSLIN. In such case "mod1" and "mod2" would be external names in the (L)MOD and would also be in the ESD. They would then be the alternate entry points for when the (L)MOD is LINK'd or XCTL'd to as "mod1" or "mod2" instead of as "whatever". "ALIAS" can also be coded to specify alternate names of the LMOD that is link-edited as "NAME ". As regards "ORDER", I used it to group together and page-align MODs that most frequently 'interacted' with each other within an LMOD - to avoid page faults and swap-outs if the page containing an associated MOD was 'stolen', i.e. I used "ORDER" for performance reasons. But yes "ORDER" can be used to make sure that all the MODs in an LMOD are kept in sequence. BTW SMP/E does allow including members with SYSLIN "ORDER " and any other control statements during its LKED. Cheers, Chris Poncelet (retired sysprog) On 22/01/2021 03:03, Paul Gilmartin wrote: > On Fri, 22 Jan 2021 01:06:10 +, CM Poncelet wrote: > >> The "END " should always be coded to ensure that the >> beginning of "" is also the entry point. >> > How does this play with SMP/E service which regularly scrambles CSECTs > and doesn't AFAIK generate INCLUDE -ATTR? > Would the programmer more safely code in //SYSLIN either: > ENTRY whatever > or > ORDER whatever > ??? > I had a co-worker who supplied an exhaustive ORDER mentioning every > CSECT, knowing that his code would not be tested in-house with every > permutation (N!) that SMP/E might create. > >> On 21/01/2021 20:54, Jesse 1 Robinson wrote: >>> Without some kind of explicit ENTRY indicator within the source--like END >>> BAMKAPP--there was no ENTRY point generated in the app module. Hence >>> specifying ENTRY BANKAPP to the linker got 'not found'. Maybe
Re: SMP/E and Isolating a CSECT within a load module
The point of my post was that *not* specifying entry point on the END statement may limit your ability relink the composite module if full source is not available. An unusual (and maybe archaic) case no doubt, but why limit your options? Maybe in the days of card source, it was an extra change to make in the case of module rename. In our case we were SOL to provide DR for an associated shop. It was not our fault, but it was at best disappointing. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Saturday, January 23, 2021 8:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: SMP/E and Isolating a CSECT within a load module *** EXTERNAL EMAIL - Use caution when opening links or attachments *** What is the point of specifying an entry point on the END statement of, e.g., a Bessel function subroutine? -- 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, January 22, 2021 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E and Isolating a CSECT within a load module The SYSLIN "ENTRY whatever" is valid if the "whatever" external symbol is in the ESD. (A LISTIDR should display the contents of the MOD's ESD.) So yes, coding "ENTRY whatever" is safer in making sure that an (L)MOD always has a same entry point. It is also the entry point selected by the linkage editor if there is an "ENTRY" statement in SYSLIN: otherwise it's the assembler's "END " that is selected by the LKED. If the assembler source END statement does not specify a label, the default EP is the first byte of the first CSECT in the link-edited (L)MOD. In modular program design, every assembler source MOD should terminate with an "END whatever" statement to specify the assembler's EP for that MOD - where the "whatever" EP is usually the CSECT name, but not necessarily so. Cf. also "Jackson structured programming (JSP)" as in "Principles of Program Design" by Michael A. Jackson. An (L)MOD can have multiple entry points by specifying "ALIAS mod1,mod2" in SYSLIN. In such case "mod1" and "mod2" would be external names in the (L)MOD and would also be in the ESD. They would then be the alternate entry points for when the (L)MOD is LINK'd or XCTL'd to as "mod1" or "mod2" instead of as "whatever". "ALIAS" can also be coded to specify alternate names of the LMOD that is link-edited as "NAME ". As regards "ORDER", I used it to group together and page-align MODs that most frequently 'interacted' with each other within an LMOD - to avoid page faults and swap-outs if the page containing an associated MOD was 'stolen', i.e. I used "ORDER" for performance reasons. But yes "ORDER" can be used to make sure that all the MODs in an LMOD are kept in sequence. BTW SMP/E does allow including members with SYSLIN "ORDER " and any other control statements during its LKED. Cheers, Chris Poncelet (retired sysprog) On 22/01/2021 03:03, Paul Gilmartin wrote: > On Fri, 22 Jan 2021 01:06:10 +, CM Poncelet wrote: > >> The "END " should always be coded to ensure that the >> beginning of "" is also the entry point. >> > How does this play with SMP/E service which regularly scrambles CSECTs > and doesn't AFAIK generate INCLUDE -ATTR? > Would the programmer more safely code in //SYSLIN either: > ENTRY whatever > or > ORDER whatever > ??? > I had a co-worker who supplied an exhaustive ORDER mentioning every > CSECT, knowing that his code would not be tested in-house with every > permutation (N!) that SMP/E might create. > >> On 21/01/2021 20:54, Jesse 1 Robinson wrote: >>> Without some kind of explicit ENTRY indicator within the source--like END >>> BAMKAPP--there was no ENTRY point generated in the app module. Hence >>> specifying ENTRY BANKAPP to the linker got 'not found'. Maybe today's >>> binder takes care of this, but in the 80s we could not find an obvious way >>> to solve it. >>> >>> Given more time we might have come to a resolution, but at the time we were >>> stumped. >>> >>> >>> -Original Message- >>> From: Steve Smith >>> Sent: Thursday, January 21, 2021 12:44 PM >>> >>> *** EXTERNAL EMAIL - Use caution when op
Re: SMP/E and Isolating a CSECT within a load module
On Sun, 24 Jan 2021 04:15:28 +, Seymour J Metz wrote: >What is the point of specifying an entry point on the END statement of, e.g., >a Bessel function subroutine? > Imagine an implementation where that Bessel function might be invoked by LINK. > >From: CM Poncelet >Sent: Friday, January 22, 2021 7:11 PM > >...: otherwise >it's the assembler's "END " that is selected by the LKED. If the >assembler source END statement does not specify a label, ... > It need not be a label. Some forms of expression suffice: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.asma400/end.htm -- gil -- 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 Isolating a CSECT within a load module
What is the point of specifying an entry point on the END statement of, e.g., a Bessel function subroutine? -- 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, January 22, 2021 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E and Isolating a CSECT within a load module The SYSLIN "ENTRY whatever" is valid if the "whatever" external symbol is in the ESD. (A LISTIDR should display the contents of the MOD's ESD.) So yes, coding "ENTRY whatever" is safer in making sure that an (L)MOD always has a same entry point. It is also the entry point selected by the linkage editor if there is an "ENTRY" statement in SYSLIN: otherwise it's the assembler's "END " that is selected by the LKED. If the assembler source END statement does not specify a label, the default EP is the first byte of the first CSECT in the link-edited (L)MOD. In modular program design, every assembler source MOD should terminate with an "END whatever" statement to specify the assembler's EP for that MOD - where the "whatever" EP is usually the CSECT name, but not necessarily so. Cf. also "Jackson structured programming (JSP)" as in "Principles of Program Design" by Michael A. Jackson. An (L)MOD can have multiple entry points by specifying "ALIAS mod1,mod2" in SYSLIN. In such case "mod1" and "mod2" would be external names in the (L)MOD and would also be in the ESD. They would then be the alternate entry points for when the (L)MOD is LINK'd or XCTL'd to as "mod1" or "mod2" instead of as "whatever". "ALIAS" can also be coded to specify alternate names of the LMOD that is link-edited as "NAME ". As regards "ORDER", I used it to group together and page-align MODs that most frequently 'interacted' with each other within an LMOD - to avoid page faults and swap-outs if the page containing an associated MOD was 'stolen', i.e. I used "ORDER" for performance reasons. But yes "ORDER" can be used to make sure that all the MODs in an LMOD are kept in sequence. BTW SMP/E does allow including members with SYSLIN "ORDER " and any other control statements during its LKED. Cheers, Chris Poncelet (retired sysprog) On 22/01/2021 03:03, Paul Gilmartin wrote: > On Fri, 22 Jan 2021 01:06:10 +, CM Poncelet wrote: > >> The "END " should always be coded to ensure that the >> beginning of "" is also the entry point. >> > How does this play with SMP/E service which regularly scrambles CSECTs > and doesn't AFAIK generate INCLUDE -ATTR? > Would the programmer more safely code in //SYSLIN either: > ENTRY whatever > or > ORDER whatever > ??? > I had a co-worker who supplied an exhaustive ORDER mentioning > every CSECT, knowing that his code would not be tested in-house > with every permutation (N!) that SMP/E might create. > >> On 21/01/2021 20:54, Jesse 1 Robinson wrote: >>> Without some kind of explicit ENTRY indicator within the source--like END >>> BAMKAPP--there was no ENTRY point generated in the app module. Hence >>> specifying ENTRY BANKAPP to the linker got 'not found'. Maybe today's >>> binder takes care of this, but in the 80s we could not find an obvious way >>> to solve it. >>> >>> Given more time we might have come to a resolution, but at the time we were >>> stumped. >>> >>> >>> -Original Message- >>> From: Steve Smith >>> Sent: Thursday, January 21, 2021 12:44 PM >>> >>> *** EXTERNAL EMAIL - Use caution when opening links or attachments *** >>> >>> No one knew how to code an ENTRY statement? >>> >>> Personally, I'd make that message the Binder emits about defaulting the >>> entry point to be an RC=8 level error. I usually discover this oversight >>> when something crashes after an APPLY, and by then, it's not so simple to >>> add the ENTRY. > Can you name the vendor? > > -- 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: SMP/E and Isolating a CSECT within a load module
The SYSLIN "ENTRY whatever" is valid if the "whatever" external symbol is in the ESD. (A LISTIDR should display the contents of the MOD's ESD.) So yes, coding "ENTRY whatever" is safer in making sure that an (L)MOD always has a same entry point. It is also the entry point selected by the linkage editor if there is an "ENTRY" statement in SYSLIN: otherwise it's the assembler's "END " that is selected by the LKED. If the assembler source END statement does not specify a label, the default EP is the first byte of the first CSECT in the link-edited (L)MOD. In modular program design, every assembler source MOD should terminate with an "END whatever" statement to specify the assembler's EP for that MOD - where the "whatever" EP is usually the CSECT name, but not necessarily so. Cf. also "Jackson structured programming (JSP)" as in "Principles of Program Design" by Michael A. Jackson. An (L)MOD can have multiple entry points by specifying "ALIAS mod1,mod2" in SYSLIN. In such case "mod1" and "mod2" would be external names in the (L)MOD and would also be in the ESD. They would then be the alternate entry points for when the (L)MOD is LINK'd or XCTL'd to as "mod1" or "mod2" instead of as "whatever". "ALIAS" can also be coded to specify alternate names of the LMOD that is link-edited as "NAME ". As regards "ORDER", I used it to group together and page-align MODs that most frequently 'interacted' with each other within an LMOD - to avoid page faults and swap-outs if the page containing an associated MOD was 'stolen', i.e. I used "ORDER" for performance reasons. But yes "ORDER" can be used to make sure that all the MODs in an LMOD are kept in sequence. BTW SMP/E does allow including members with SYSLIN "ORDER " and any other control statements during its LKED. Cheers, Chris Poncelet (retired sysprog) On 22/01/2021 03:03, Paul Gilmartin wrote: > On Fri, 22 Jan 2021 01:06:10 +, CM Poncelet wrote: > >> The "END " should always be coded to ensure that the >> beginning of "" is also the entry point. >> > How does this play with SMP/E service which regularly scrambles CSECTs > and doesn't AFAIK generate INCLUDE -ATTR? > Would the programmer more safely code in //SYSLIN either: > ENTRY whatever > or > ORDER whatever > ??? > I had a co-worker who supplied an exhaustive ORDER mentioning > every CSECT, knowing that his code would not be tested in-house > with every permutation (N!) that SMP/E might create. > >> On 21/01/2021 20:54, Jesse 1 Robinson wrote: >>> Without some kind of explicit ENTRY indicator within the source--like END >>> BAMKAPP--there was no ENTRY point generated in the app module. Hence >>> specifying ENTRY BANKAPP to the linker got 'not found'. Maybe today's >>> binder takes care of this, but in the 80s we could not find an obvious way >>> to solve it. >>> >>> Given more time we might have come to a resolution, but at the time we were >>> stumped. >>> >>> >>> -Original Message- >>> From: Steve Smith >>> Sent: Thursday, January 21, 2021 12:44 PM >>> >>> *** EXTERNAL EMAIL - Use caution when opening links or attachments *** >>> >>> No one knew how to code an ENTRY statement? >>> >>> Personally, I'd make that message the Binder emits about defaulting the >>> entry point to be an RC=8 level error. I usually discover this oversight >>> when something crashes after an APPLY, and by then, it's not so simple to >>> add the ENTRY. > Can you name the vendor? > > -- 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: SMP/E and Isolating a CSECT within a load module
IBM/SMPE is quite meticulous about supplying all necessary binder control statements via JCLIN. Any omission leads to a PE and concomitant HOLD data. I don't think there's an inherent problem with multiple entry points as long as a binder control statement specifies the one to use. The ancient problem I recited occurred because no usable entry point was specified in the absence of concurrent compile. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Friday, January 22, 2021 5:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: SMP/E and Isolating a CSECT within a load module *** EXTERNAL EMAIL - Use caution when opening links or attachments *** How does this play with SMP/E service which regularly scrambles CSECTs and doesn't AFAIK generate INCLUDE -ATTR? Would the programmer more safely code in //SYSLIN either: ENTRY whatever or ORDER whatever ??? I'd like to think we provide ENTRY statements and/or ORDER statements in all cases where it is important to do so (which tends to be any multi-CSECT load module / program object). 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: Isolating a CSECT within a load module
I was responding to 'The "END " should always be coded to ensure that the beginning of "" is also the entry point.' That relates to the HLASM source, not to SYSLIN. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Friday, January 22, 2021 12:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Isolating a CSECT within a load module On Fri, 22 Jan 2021 11:24:40 -0600, Joe Monk wrote: >There are many SVCs and service routines that have multiple ENTRY >statements > z/OS Version 2 Release 4 MVS Program Management: User's Guide and Reference IBM SA23-1393-40 ... ENTRY statement ... An ENTRY statement should be used whenever a module is *reprocessed* by the binder... [emphasis added] Note: 1. If you provide more than one ENTRY statement, the main entry point specified on the last statement is used. [That ought to generate a warning. How does ENTRY interact with INCLUDE -ATTR?] Perhaps you were thinking of Assembler See also ALIAS. >On Fri, Jan 22, 2021 at 9:37 AM Seymour J Metz wrote: > >> No, the ENTRY statement and the entry parameter on the END statement >> should only be coded in the source for a main program or main CSECT of a >> secondary load module or program object. -- 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: Isolating a CSECT within a load module
On Fri, 22 Jan 2021 11:24:40 -0600, Joe Monk wrote: >There are many SVCs and service routines that have multiple ENTRY >statements > z/OS Version 2 Release 4 MVS Program Management: User's Guide and Reference IBM SA23-1393-40 ... ENTRY statement ... An ENTRY statement should be used whenever a module is *reprocessed* by the binder... [emphasis added] Note: 1. If you provide more than one ENTRY statement, the main entry point specified on the last statement is used. [That ought to generate a warning. How does ENTRY interact with INCLUDE -ATTR?] Perhaps you were thinking of Assembler See also ALIAS. >On Fri, Jan 22, 2021 at 9:37 AM Seymour J Metz wrote: > >> No, the ENTRY statement and the entry parameter on the END statement >> should only be coded in the source for a main program or main CSECT of a >> secondary load module or program object. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Isolating a CSECT within a load module
That doesn't conflict with what I wrote. There should be none that are not intended to be the target of an ATTACH, LOAD, LINK, XCTL or the extended version of same. -- 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: Friday, January 22, 2021 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Isolating a CSECT within a load module There are many SVCs and service routines that have multiple ENTRY statements Joe On Fri, Jan 22, 2021 at 9:37 AM Seymour J Metz wrote: > No, the ENTRY statement and the entry parameter on the END statement > should only be coded in the source for a main program or main CSECT of a > secondary load module or program object. > > > -- > 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: Thursday, January 21, 2021 8:06 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Isolating a CSECT within a load module > > The "END " should always be coded to ensure that the > beginning of "" is also the entry point. > > On 21/01/2021 20:54, Jesse 1 Robinson wrote: > > Without some kind of explicit ENTRY indicator within the source--like > END BAMKAPP--there was no ENTRY point generated in the app module. Hence > specifying ENTRY BANKAPP to the linker got 'not found'. Maybe today's > binder takes care of this, but in the 80s we could not find an obvious way > to solve it. > > > > Given more time we might have come to a resolution, but at the time we > were stumped. > > > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office ⇐=== NEW > > robin...@sce.com > > > > -Original Message----- > > From: IBM Mainframe Discussion List On > Behalf Of Steve Smith > > Sent: Thursday, January 21, 2021 12:44 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: Isolating a CSECT within a load module > > > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > > > No one knew how to code an ENTRY statement? > > > > Personally, I'd make that message the Binder emits about defaulting the > entry point to be an RC=8 level error. I usually discover this oversight > when something crashes after an APPLY, and by then, it's not so simple to > add the ENTRY. > > > > sas > > > > > > On Thu, Jan 21, 2021 at 3:22 PM Jesse 1 Robinson < > jesse1.robin...@sce.com> > > wrote: > > > >> ... > >> As long as the program was compiled and linked in the same run, the > >> END statement picked up BANKAPP as entry point and everything was > >> cool. But when run separately, the entry point was indeterminate, so > link failed. > >> Source of course was not available so we could not add > >> > >> END BANKAPP > >> ... > >> > > -- > > 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 > -- 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: Isolating a CSECT within a load module
There are many SVCs and service routines that have multiple ENTRY statements Joe On Fri, Jan 22, 2021 at 9:37 AM Seymour J Metz wrote: > No, the ENTRY statement and the entry parameter on the END statement > should only be coded in the source for a main program or main CSECT of a > secondary load module or program object. > > > -- > 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: Thursday, January 21, 2021 8:06 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Isolating a CSECT within a load module > > The "END " should always be coded to ensure that the > beginning of "" is also the entry point. > > On 21/01/2021 20:54, Jesse 1 Robinson wrote: > > Without some kind of explicit ENTRY indicator within the source--like > END BAMKAPP--there was no ENTRY point generated in the app module. Hence > specifying ENTRY BANKAPP to the linker got 'not found'. Maybe today's > binder takes care of this, but in the 80s we could not find an obvious way > to solve it. > > > > Given more time we might have come to a resolution, but at the time we > were stumped. > > > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office ⇐=== NEW > > robin...@sce.com > > > > -----Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of Steve Smith > > Sent: Thursday, January 21, 2021 12:44 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: Isolating a CSECT within a load module > > > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > > > No one knew how to code an ENTRY statement? > > > > Personally, I'd make that message the Binder emits about defaulting the > entry point to be an RC=8 level error. I usually discover this oversight > when something crashes after an APPLY, and by then, it's not so simple to > add the ENTRY. > > > > sas > > > > > > On Thu, Jan 21, 2021 at 3:22 PM Jesse 1 Robinson < > jesse1.robin...@sce.com> > > wrote: > > > >> ... > >> As long as the program was compiled and linked in the same run, the > >> END statement picked up BANKAPP as entry point and everything was > >> cool. But when run separately, the entry point was indeterminate, so > link failed. > >> Source of course was not available so we could not add > >> > >> END BANKAPP > >> ... > >> > > -- > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Isolating a CSECT within a load module
No, the ENTRY statement and the entry parameter on the END statement should only be coded in the source for a main program or main CSECT of a secondary load module or program object. -- 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: Thursday, January 21, 2021 8:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Isolating a CSECT within a load module The "END " should always be coded to ensure that the beginning of "" is also the entry point. On 21/01/2021 20:54, Jesse 1 Robinson wrote: > Without some kind of explicit ENTRY indicator within the source--like END > BAMKAPP--there was no ENTRY point generated in the app module. Hence > specifying ENTRY BANKAPP to the linker got 'not found'. Maybe today's binder > takes care of this, but in the 80s we could not find an obvious way to solve > it. > > Given more time we might have come to a resolution, but at the time we were > stumped. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Steve Smith > Sent: Thursday, January 21, 2021 12:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Isolating a CSECT within a load module > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > No one knew how to code an ENTRY statement? > > Personally, I'd make that message the Binder emits about defaulting the entry > point to be an RC=8 level error. I usually discover this oversight when > something crashes after an APPLY, and by then, it's not so simple to add the > ENTRY. > > sas > > > On Thu, Jan 21, 2021 at 3:22 PM Jesse 1 Robinson > wrote: > >> ... >> As long as the program was compiled and linked in the same run, the >> END statement picked up BANKAPP as entry point and everything was >> cool. But when run separately, the entry point was indeterminate, so link >> failed. >> Source of course was not available so we could not add >> >> END BANKAPP >> ... >> > -- > 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: Isolating a CSECT within a load module
On Thu, Jan 21, 2021 at 8:06 PM CM Poncelet wrote: > The "END " should always be coded to ensure that the > beginning of "" is also the entry point. > That's a pretty broad statement. I'd say the entry point should always be specified for main programs, but it's irrelevant for linked-in subroutines. btw, it's not required to be the name of a CSECT. > > On 21/01/2021 20:54, Jesse 1 Robinson wrote: > > Without some kind of explicit ENTRY indicator within the source--like > END BAMKAPP--there was no ENTRY point generated in the app module. Hence > specifying ENTRY BANKAPP to the linker got 'not found'. Maybe today's > binder takes care of this, but in the 80s we could not find an obvious way > to solve it. > > > > Given more time we might have come to a resolution, but at the time we > were stumped. > > > > . > Well, I can't make sense of that, but it's hard to debug an ancient issue based entirely on someone's recollection. Not that you asked anyone to, so I'm not :-) sas -- 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 Isolating a CSECT within a load module
How does this play with SMP/E service which regularly scrambles CSECTs and doesn't AFAIK generate INCLUDE -ATTR? Would the programmer more safely code in //SYSLIN either: ENTRY whatever or ORDER whatever ??? I'd like to think we provide ENTRY statements and/or ORDER statements in all cases where it is important to do so (which tends to be any multi-CSECT load module / program object). 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
SMP/E and Isolating a CSECT within a load module
On Fri, 22 Jan 2021 01:06:10 +, CM Poncelet wrote: >The "END " should always be coded to ensure that the >beginning of "" is also the entry point. > How does this play with SMP/E service which regularly scrambles CSECTs and doesn't AFAIK generate INCLUDE -ATTR? Would the programmer more safely code in //SYSLIN either: ENTRY whatever or ORDER whatever ??? I had a co-worker who supplied an exhaustive ORDER mentioning every CSECT, knowing that his code would not be tested in-house with every permutation (N!) that SMP/E might create. >On 21/01/2021 20:54, Jesse 1 Robinson wrote: >> Without some kind of explicit ENTRY indicator within the source--like END >> BAMKAPP--there was no ENTRY point generated in the app module. Hence >> specifying ENTRY BANKAPP to the linker got 'not found'. Maybe today's binder >> takes care of this, but in the 80s we could not find an obvious way to solve >> it. >> >> Given more time we might have come to a resolution, but at the time we were >> stumped. >> >> >> -Original Message- >> From: Steve Smith >> Sent: Thursday, January 21, 2021 12:44 PM >> >> *** EXTERNAL EMAIL - Use caution when opening links or attachments *** >> >> No one knew how to code an ENTRY statement? >> >> Personally, I'd make that message the Binder emits about defaulting the >> entry point to be an RC=8 level error. I usually discover this oversight >> when something crashes after an APPLY, and by then, it's not so simple to >> add the ENTRY. > Can you name the vendor? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Isolating a CSECT within a load module
The "END " should always be coded to ensure that the beginning of "" is also the entry point. On 21/01/2021 20:54, Jesse 1 Robinson wrote: > Without some kind of explicit ENTRY indicator within the source--like END > BAMKAPP--there was no ENTRY point generated in the app module. Hence > specifying ENTRY BANKAPP to the linker got 'not found'. Maybe today's binder > takes care of this, but in the 80s we could not find an obvious way to solve > it. > > Given more time we might have come to a resolution, but at the time we were > stumped. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Steve Smith > Sent: Thursday, January 21, 2021 12:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Isolating a CSECT within a load module > > *** EXTERNAL EMAIL - Use caution when opening links or attachments *** > > No one knew how to code an ENTRY statement? > > Personally, I'd make that message the Binder emits about defaulting the entry > point to be an RC=8 level error. I usually discover this oversight when > something crashes after an APPLY, and by then, it's not so simple to add the > ENTRY. > > sas > > > On Thu, Jan 21, 2021 at 3:22 PM Jesse 1 Robinson > wrote: > >> ... >> As long as the program was compiled and linked in the same run, the >> END statement picked up BANKAPP as entry point and everything was >> cool. But when run separately, the entry point was indeterminate, so link >> failed. >> Source of course was not available so we could not add >> >> END BANKAPP >> ... >> > -- > 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: Isolating a CSECT within a load module
On Thu, 21 Jan 2021 20:22:22 +, Jesse 1 Robinson wrote: > >Not so fast. We discovered from their install jobs that they had coded >something like this: > > BANKAPP > Lots of code and calls including the IBM module > END > >As long as the program was compiled and linked in the same run, the END >statement picked up BANKAPP as entry point and everything was cool. But when >run separately, the entry point was indeterminate, so link failed. Source of >course was not available so we could not add > > END BANKAPP > I perpetrated one of those once. I was maintaining/upgrading a FOSS Pascal compiler. Direct to SYSLIN; no Assembler. I added the effect of "END APP"; no ESD; nary a label. Obsessive; saving 4 bytes of branch around eyecatcher. But worked fine until a co-worker relinked -- he didn't like my BLKSIZE. I got better; added the branch. Nowadays, INCLUDE -ATTR should handle that -- probably what it was invented for. Same co-worker once bypassed some test code with EXEC COND=ONLY. He was considerably upset when my program ABENDed in an earlier job step. I always use COND=(0,LE) for that purpose. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Isolating a CSECT within a load module
Without some kind of explicit ENTRY indicator within the source--like END BAMKAPP--there was no ENTRY point generated in the app module. Hence specifying ENTRY BANKAPP to the linker got 'not found'. Maybe today's binder takes care of this, but in the 80s we could not find an obvious way to solve it. Given more time we might have come to a resolution, but at the time we were stumped. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Smith Sent: Thursday, January 21, 2021 12:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Isolating a CSECT within a load module *** EXTERNAL EMAIL - Use caution when opening links or attachments *** No one knew how to code an ENTRY statement? Personally, I'd make that message the Binder emits about defaulting the entry point to be an RC=8 level error. I usually discover this oversight when something crashes after an APPLY, and by then, it's not so simple to add the ENTRY. sas On Thu, Jan 21, 2021 at 3:22 PM Jesse 1 Robinson wrote: > ... > As long as the program was compiled and linked in the same run, the > END statement picked up BANKAPP as entry point and everything was > cool. But when run separately, the entry point was indeterminate, so link > failed. > Source of course was not available so we could not add > > END BANKAPP > ... > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Isolating a CSECT within a load module
No one knew how to code an ENTRY statement? Personally, I'd make that message the Binder emits about defaulting the entry point to be an RC=8 level error. I usually discover this oversight when something crashes after an APPLY, and by then, it's not so simple to add the ENTRY. sas On Thu, Jan 21, 2021 at 3:22 PM Jesse 1 Robinson wrote: > ... > As long as the program was compiled and linked in the same run, the END > statement picked up BANKAPP as entry point and everything was cool. But > when run separately, the entry point was indeterminate, so link failed. > Source of course was not available so we could not add > > END BANKAPP > ... > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Isolating a CSECT within a load module
(I know it's not Friday, but time these days is twisted beyond recognition) I
used to work for a bank. One Monday morning, we were told that we needed to
provide a disaster recovery platform for another bank with whom we had a mutual
support agreement. ASAP. Which was totally news to us. Obviously never tested.
They had hit a snag with some kind of upgrade and were completely down.
We were pretty smart, so we carved out some space for them to run their apps
in. We got their system restored from tape. It IPLed. They fired up their app,
which crashed. We found that the failing program had been linked together with
some IBM module that did not match our level of MVS. The problem seemed simple
enough. Relink their program with our version of the IBM module.
Not so fast. We discovered from their install jobs that they had coded
something like this:
BANKAPP
Lots of code and calls including the IBM module
END
As long as the program was compiled and linked in the same run, the END
statement picked up BANKAPP as entry point and everything was cool. But when
run separately, the entry point was indeterminate, so link failed. Source of
course was not available so we could not add
END BANKAPP
Not sure how long we slogged away at this, but before we could bedazzle our way
out of the predicament, guest bank got their upgrade completed and no longer
needed our feeble assistance. We slunk back to our desks.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steff Gladstone
Sent: Thursday, January 21, 2021 6:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Isolating a CSECT within a load module
*** EXTERNAL EMAIL - Use caution when opening links or attachments ***
Thank you Greg, Paul and Max for your informative replies!
On Tue, 5 Jan 2021 at 15:12, Massimo Biancucci wrote:
> I tried to develop you hints:
>
> // EXPORT SYMLIST=*
> // SET INPMOD=oldmd
> // SET OUTMOD=newmod
> // SET INPLIB=myold.lib
> // SET OUTLIB=mynew.lib
> // SET AMBDSN=AMBLIST3
> // SET DSP='MOD,PASS' DSP='MOD,CATLG'
> //*---*
> //* *
> //*---
> *
> //ST010 EXEC PGM=AMBLIST
> //SYSPRINT DD DSN=&SYSUID..&AMBDSN,DISP=(&DSP), //
> SPACE=(TRK,(5,5),RLSE) //LOADLIB DD DISP=SHR,DSN=&INPLIB
> //SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> LISTIDR DDN=LOADLIB,MEMBER=&INPMOD
> /*
> //*---*
> //* *
> //*---
> *
> //ST020 EXEC PGM=SORT
> //SYSOUT DD SYSOUT=*
> //SORTIN DD DSN=&SYSUID..&AMBDSN,DISP=SHR //SORTOUT DD
> DSN=&SYSUID..&AMBDSN..CMD,DISP=(&DSP),
> // SPACE=(TRK,(5,5),RLSE),DCB=(LRECL=80,RECFM=FB,DSORG=PS)
> //SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> SORT FIELDS=COPY
> OUTFIL FNAMES=SORTOUT,REMOVECC,
> INCLUDE=(2,10,CH,EQ,C'CSECT:',AND,
>12,8,CH,NE,C'&OUTMOD'),
> OUTREC=(C' REPLACE ',12,8,80:X),
> TRAILER1=(' INCLUDE SYSLIB(&INPMOD)',/,
>' NAME &OUTMOD(R)')
> /*
> //*---*
> //* *
> //*---*
> //ST030EXEC PGM=HEWL,
> // PARM='LET,XREF,MAP,LIST,NCAL'
> //SYSPRINT DD SYSOUT=*
> //SYSUT1 DD DSN=&&SYSUT1,SPACE=(1024,(120,120),,,ROUND),
> // DCB=BUFNO=1
> //*YSLIN DD DISP=SHR,DSN=J48017.OSET.LOAD(IRXINIT)
> //SYSLIB DD DISP=SHR,DSN=&INPLIB
> //SYSLMOD DD DISP=SHR,DSN=&OUTLIB(&OUTMOD)
> //SYSLIN DD DISP=SHR,DSN=&SYSUID..&AMBDSN..CMD
> //*---*
> //* *
> //*---
> *
> //ST040 EXEC PGM=AMBLIST
> //SYSPRINT DD SYSOUT=*
> //LOADLIB DD DISP=SHR,DSN=&OUTLIB
> //SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> LISTIDR DDN=LOADLIB,MEMBER=&OUTMOD
> LISTLOAD DDN=LOADLIB,MEMBER=&OUTMOD
> /*
>
> and it seems it's still working.
> I'm sure it's possible to further optimize, anyway I think it's a kind
> of tool you u
Re: Isolating a CSECT within a load module
Thank you Greg, Paul and Max for your informative replies!
On Tue, 5 Jan 2021 at 15:12, Massimo Biancucci wrote:
> I tried to develop you hints:
>
> // EXPORT SYMLIST=*
> // SET INPMOD=oldmd
> // SET OUTMOD=newmod
> // SET INPLIB=myold.lib
> // SET OUTLIB=mynew.lib
> // SET AMBDSN=AMBLIST3
> // SET DSP='MOD,PASS' DSP='MOD,CATLG'
> //*---*
> //* *
> //*---*
> //ST010 EXEC PGM=AMBLIST
> //SYSPRINT DD DSN=&SYSUID..&AMBDSN,DISP=(&DSP),
> // SPACE=(TRK,(5,5),RLSE)
> //LOADLIB DD DISP=SHR,DSN=&INPLIB
> //SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> LISTIDR DDN=LOADLIB,MEMBER=&INPMOD
> /*
> //*---*
> //* *
> //*---*
> //ST020 EXEC PGM=SORT
> //SYSOUT DD SYSOUT=*
> //SORTIN DD DSN=&SYSUID..&AMBDSN,DISP=SHR
> //SORTOUT DD DSN=&SYSUID..&AMBDSN..CMD,DISP=(&DSP),
> // SPACE=(TRK,(5,5),RLSE),DCB=(LRECL=80,RECFM=FB,DSORG=PS)
> //SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> SORT FIELDS=COPY
> OUTFIL FNAMES=SORTOUT,REMOVECC,
> INCLUDE=(2,10,CH,EQ,C'CSECT:',AND,
>12,8,CH,NE,C'&OUTMOD'),
> OUTREC=(C' REPLACE ',12,8,80:X),
> TRAILER1=(' INCLUDE SYSLIB(&INPMOD)',/,
>' NAME &OUTMOD(R)')
> /*
> //*---*
> //* *
> //*---*
> //ST030EXEC PGM=HEWL,
> // PARM='LET,XREF,MAP,LIST,NCAL'
> //SYSPRINT DD SYSOUT=*
> //SYSUT1 DD DSN=&&SYSUT1,SPACE=(1024,(120,120),,,ROUND),
> // DCB=BUFNO=1
> //*YSLIN DD DISP=SHR,DSN=J48017.OSET.LOAD(IRXINIT)
> //SYSLIB DD DISP=SHR,DSN=&INPLIB
> //SYSLMOD DD DISP=SHR,DSN=&OUTLIB(&OUTMOD)
> //SYSLIN DD DISP=SHR,DSN=&SYSUID..&AMBDSN..CMD
> //*---*
> //* *
> //*---*
> //ST040 EXEC PGM=AMBLIST
> //SYSPRINT DD SYSOUT=*
> //LOADLIB DD DISP=SHR,DSN=&OUTLIB
> //SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> LISTIDR DDN=LOADLIB,MEMBER=&OUTMOD
> LISTLOAD DDN=LOADLIB,MEMBER=&OUTMOD
> /*
>
> and it seems it's still working.
> I'm sure it's possible to further optimize, anyway I think it's a kind of
> tool you use not so often.
> Anyway take the two of them as POC.
>
> Best regards.
> Max
>
> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> Mail
> priva di virus. www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Il giorno lun 4 gen 2021 alle ore 18:44 Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> ha scritto:
>
> > On Mon, 4 Jan 2021 16:32:47 +0100, Massimo Biancucci wrote:
> > >
> > >I've tried to use sort to help.
> > >
> > >// EXPORT SYMLIST=*
> > >// SET INPMOD=oldmd
> > >// SET OUTMOD=newmod
> > >// SET INPLIB=myold.lib
> > >// SET OUTLIB=mynew.lib
> > >
> > I like that sort of parameterizing. It puts the variables up front,
> > viewable at a glance. I'd add the AMBLIST2 DSNs to the SET list.
> >
> > Can something such as "SET DISP={PASS|CATLG} be used to control
> > temp vs. permanent workfiles?
> >
> > >//* *
> > >//*---*
> > >//ST010 EXEC PGM=IDCAMS
> > >//SYSPRINT DD SYSOUT=*
> > >//SYSIN DD *,SYMBOLS=(JCLONLY,SYMBLOG)
> > > DELETE &SYSUID..AMBLIST2
> > > IF MAXCC=8 THEN SET MAXCC=0
> > >/*
> > >//*---*
> > >//* *
> > >//*---*
> > >//ST020 EXEC PGM=AMBLIST
> > >//SYSPRINT DD DSN=&SYSUID..AMBLIST2,DISP=(,CATLG),
> > >// SPACE=(TRK,(5,5),RLSE)
> > >//LOADLIB DD DISP=SHR,DSN=&INPLIB
> > >//SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> > > LISTIDR DDN=LOADLIB,MEMBER=&INPMOD
> > >/*...
> > My very peculiar preference is to omit the IDCAMS steps and code either:
> > //HANDLE DD DSN=&SYSUID..AMBLIST2,DISP=(MOD,CATLG),
> > // SPACE=(TRK,(5,5),RLSE)
> > //SYSPRINT DD DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE
> >
> > Or:
> > //HANDLE DD DSN=&SYSUID..AMBLIST2,DISP=(MOD,DELETE),
> > // SPACE=(TRK,(5,5),RLSE)
> > //SYSPRINT DD DSN=&SYSUID..AMBLIST2,DISP=(MOD,CATLG),
> > // SPACE=(TRK,(5,5),RLSE)
> >
> > But, performance? Is a failing IDCAMS st
Re: Isolating a CSECT within a load module
I tried to develop you hints:
// EXPORT SYMLIST=*
// SET INPMOD=oldmd
// SET OUTMOD=newmod
// SET INPLIB=myold.lib
// SET OUTLIB=mynew.lib
// SET AMBDSN=AMBLIST3
// SET DSP='MOD,PASS' DSP='MOD,CATLG'
//*---*
//* *
//*---*
//ST010 EXEC PGM=AMBLIST
//SYSPRINT DD DSN=&SYSUID..&AMBDSN,DISP=(&DSP),
// SPACE=(TRK,(5,5),RLSE)
//LOADLIB DD DISP=SHR,DSN=&INPLIB
//SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
LISTIDR DDN=LOADLIB,MEMBER=&INPMOD
/*
//*---*
//* *
//*---*
//ST020 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=&SYSUID..&AMBDSN,DISP=SHR
//SORTOUT DD DSN=&SYSUID..&AMBDSN..CMD,DISP=(&DSP),
// SPACE=(TRK,(5,5),RLSE),DCB=(LRECL=80,RECFM=FB,DSORG=PS)
//SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
SORT FIELDS=COPY
OUTFIL FNAMES=SORTOUT,REMOVECC,
INCLUDE=(2,10,CH,EQ,C'CSECT:',AND,
12,8,CH,NE,C'&OUTMOD'),
OUTREC=(C' REPLACE ',12,8,80:X),
TRAILER1=(' INCLUDE SYSLIB(&INPMOD)',/,
' NAME &OUTMOD(R)')
/*
//*---*
//* *
//*---*
//ST030EXEC PGM=HEWL,
// PARM='LET,XREF,MAP,LIST,NCAL'
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=&&SYSUT1,SPACE=(1024,(120,120),,,ROUND),
// DCB=BUFNO=1
//*YSLIN DD DISP=SHR,DSN=J48017.OSET.LOAD(IRXINIT)
//SYSLIB DD DISP=SHR,DSN=&INPLIB
//SYSLMOD DD DISP=SHR,DSN=&OUTLIB(&OUTMOD)
//SYSLIN DD DISP=SHR,DSN=&SYSUID..&AMBDSN..CMD
//*---*
//* *
//*---*
//ST040 EXEC PGM=AMBLIST
//SYSPRINT DD SYSOUT=*
//LOADLIB DD DISP=SHR,DSN=&OUTLIB
//SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
LISTIDR DDN=LOADLIB,MEMBER=&OUTMOD
LISTLOAD DDN=LOADLIB,MEMBER=&OUTMOD
/*
and it seems it's still working.
I'm sure it's possible to further optimize, anyway I think it's a kind of
tool you use not so often.
Anyway take the two of them as POC.
Best regards.
Max
Mail
priva di virus. www.avast.com
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Il giorno lun 4 gen 2021 alle ore 18:44 Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> ha scritto:
> On Mon, 4 Jan 2021 16:32:47 +0100, Massimo Biancucci wrote:
> >
> >I've tried to use sort to help.
> >
> >// EXPORT SYMLIST=*
> >// SET INPMOD=oldmd
> >// SET OUTMOD=newmod
> >// SET INPLIB=myold.lib
> >// SET OUTLIB=mynew.lib
> >
> I like that sort of parameterizing. It puts the variables up front,
> viewable at a glance. I'd add the AMBLIST2 DSNs to the SET list.
>
> Can something such as "SET DISP={PASS|CATLG} be used to control
> temp vs. permanent workfiles?
>
> >//* *
> >//*---*
> >//ST010 EXEC PGM=IDCAMS
> >//SYSPRINT DD SYSOUT=*
> >//SYSIN DD *,SYMBOLS=(JCLONLY,SYMBLOG)
> > DELETE &SYSUID..AMBLIST2
> > IF MAXCC=8 THEN SET MAXCC=0
> >/*
> >//*---*
> >//* *
> >//*---*
> >//ST020 EXEC PGM=AMBLIST
> >//SYSPRINT DD DSN=&SYSUID..AMBLIST2,DISP=(,CATLG),
> >// SPACE=(TRK,(5,5),RLSE)
> >//LOADLIB DD DISP=SHR,DSN=&INPLIB
> >//SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> > LISTIDR DDN=LOADLIB,MEMBER=&INPMOD
> >/*...
> My very peculiar preference is to omit the IDCAMS steps and code either:
> //HANDLE DD DSN=&SYSUID..AMBLIST2,DISP=(MOD,CATLG),
> // SPACE=(TRK,(5,5),RLSE)
> //SYSPRINT DD DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE
>
> Or:
> //HANDLE DD DSN=&SYSUID..AMBLIST2,DISP=(MOD,DELETE),
> // SPACE=(TRK,(5,5),RLSE)
> //SYSPRINT DD DSN=&SYSUID..AMBLIST2,DISP=(MOD,CATLG),
> // SPACE=(TRK,(5,5),RLSE)
>
> But, performance? Is a failing IDCAMS step less overhead than
> an otiose DISP=(MOD,DELETE) etc.?
>
> >I used "no-temp" dataset to better help in understanding the process.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-
Re: Isolating a CSECT within a load module
On Mon, 4 Jan 2021 16:32:47 +0100, Massimo Biancucci wrote:
>
>I've tried to use sort to help.
>
>// EXPORT SYMLIST=*
>// SET INPMOD=oldmd
>// SET OUTMOD=newmod
>// SET INPLIB=myold.lib
>// SET OUTLIB=mynew.lib
>
I like that sort of parameterizing. It puts the variables up front,
viewable at a glance. I'd add the AMBLIST2 DSNs to the SET list.
Can something such as "SET DISP={PASS|CATLG} be used to control
temp vs. permanent workfiles?
>//* *
>//*---*
>//ST010 EXEC PGM=IDCAMS
>//SYSPRINT DD SYSOUT=*
>//SYSIN DD *,SYMBOLS=(JCLONLY,SYMBLOG)
> DELETE &SYSUID..AMBLIST2
> IF MAXCC=8 THEN SET MAXCC=0
>/*
>//*---*
>//* *
>//*---*
>//ST020 EXEC PGM=AMBLIST
>//SYSPRINT DD DSN=&SYSUID..AMBLIST2,DISP=(,CATLG),
>// SPACE=(TRK,(5,5),RLSE)
>//LOADLIB DD DISP=SHR,DSN=&INPLIB
>//SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
> LISTIDR DDN=LOADLIB,MEMBER=&INPMOD
>/*...
My very peculiar preference is to omit the IDCAMS steps and code either:
//HANDLE DD DSN=&SYSUID..AMBLIST2,DISP=(MOD,CATLG),
// SPACE=(TRK,(5,5),RLSE)
//SYSPRINT DD DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE
Or:
//HANDLE DD DSN=&SYSUID..AMBLIST2,DISP=(MOD,DELETE),
// SPACE=(TRK,(5,5),RLSE)
//SYSPRINT DD DSN=&SYSUID..AMBLIST2,DISP=(MOD,CATLG),
// SPACE=(TRK,(5,5),RLSE)
But, performance? Is a failing IDCAMS step less overhead than
an otiose DISP=(MOD,DELETE) etc.?
>I used "no-temp" dataset to better help in understanding the process.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Isolating a CSECT within a load module
To list all CSECTS (MODs) in an LMOD:
(Note the 'X' continuation char in col 72)
//AMBLIST EXEC PGM=AMBLIST
//SYSPRINT DD DISP=SHR,DSN=
//ANYDD1 DD DISP=SHR,DSN=
//SYSIN DD *
LISTLOAD TITLE=('DUMP CSECTS '), X
DDN=ANYDD1, X
MEMBER=, X
OUTPUT=XREF, X
RELOC=
//*
//
To dump the contents of a CSECT (MOD) in an LMOD:
//SPZAP EXEC PGM=AMASPZAP,COND=(4,LT)
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DISP=SHR,DSN=
//SYSIN DD *
DUMP
//*
//
Cheers, Chris Poncelet (retired sysprog)
On 04/01/2021 13:24, Greg Price wrote:
> On 2021-01-04 9:46 PM, Steff Gladstone wrote:
>> an anyone suggest a method of isolating or extracting a CSECT
>> (statically-linked called program) from a load module?
>
> Well, if it really is a load module, I'd suggest delinking it into an
> object deck. Potentially suitable delinkers are available at cbttape.org.
>
> The one I'm most familiar with is David Noon's delinker which ended up
> being called DELINKI (to distinguish it from the the OS/360 era
> DELINK0, which I believe was enhanced in due course to cater for
> 31-bit modes).
>
> The reason I am more familiar with it is because REVIEW can invoke it
> dynamically. In this usage scenario, you would display the member list
> with a REVIEW program.library command, tag the relevant member(s) with
> the necessary T selection code(s) (or else have every member
> delinked), and then issue the DELINK primary command.
>
> Program DELINKI would be dynamically invoked to delink the selected
> program(s) into the nominated output data set (a detail which I did
> not mention before).
>
> For your situation, I'd expect that you would be better off just
> downloading and "installing" CBT file 90 and figuring out how to run
> it as a stand-alone utility to delink the CSECT of interest. If I can
> figure out how to call it dynamically, it can't be that hard to run it
> in its own job step.
>
> Cheers,
> Greg
>
> --
> 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: Isolating a CSECT within a load module
Steff,
I've tried to use sort to help.
// EXPORT SYMLIST=*
// SET INPMOD=oldmd
// SET OUTMOD=newmod
// SET INPLIB=myold.lib
// SET OUTLIB=mynew.lib
//*---*
//* *
//*---*
//ST010 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *,SYMBOLS=(JCLONLY,SYMBLOG)
DELETE &SYSUID..AMBLIST2
IF MAXCC=8 THEN SET MAXCC=0
/*
//*---*
//* *
//*---*
//ST020 EXEC PGM=AMBLIST
//SYSPRINT DD DSN=&SYSUID..AMBLIST2,DISP=(,CATLG),
// SPACE=(TRK,(5,5),RLSE)
//LOADLIB DD DISP=SHR,DSN=&INPLIB
//SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
LISTIDR DDN=LOADLIB,MEMBER=&INPMOD
/*
//*---*
//* *
//*---*
//ST030 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *,SYMBOLS=(JCLONLY,SYMBLOG)
DELETE &SYSUID..AMBLIST2.CMD
IF MAXCC=8 THEN SET MAXCC=0
/*
//*---*
//* *
//*---*
//ST040 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=&SYSUID..AMBLIST2,DISP=SHR
//SORTOUT DD DSN=&SYSUID..AMBLIST2.CMD,DISP=(,CATLG),
// SPACE=(TRK,(5,5),RLSE),DCB=(LRECL=80,RECFM=FB,DSORG=PS)
//SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
SORT FIELDS=COPY
OUTFIL FNAMES=SORTOUT,REMOVECC,
INCLUDE=(2,10,CH,EQ,C'CSECT:',AND,
12,8,CH,NE,C'&OUTMOD'),
OUTREC=(C' REPLACE ',12,8,80:X),
TRAILER1=(' INCLUDE SYSLIB(&INPMOD)',/,
' NAME &OUTMOD(R)')
/*
//*---*
//* *
//*---*
//ST050EXEC PGM=HEWL,
// PARM='LET,XREF,MAP,LIST,NCAL'
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=&&SYSUT1,SPACE=(1024,(120,120),,,ROUND),
// DCB=BUFNO=1
//*YSLIN DD DISP=SHR,DSN=J48017.OSET.LOAD(IRXINIT)
//SYSLIB DD DISP=SHR,DSN=&INPLIB
//SYSLMOD DD DISP=SHR,DSN=&OUTLIB(&OUTMOD)
//SYSLIN DD DISP=SHR,DSN=&SYSUID..AMBLIST2.CMD
//*---*
//* *
//*---*
//ST060 EXEC PGM=AMBLIST
//SYSPRINT DD SYSOUT=*
//LOADLIB DD DISP=SHR,DSN=&OUTLIB
//SYSINDD *,SYMBOLS=(JCLONLY,SYMBLOG)
LISTIDR DDN=LOADLIB,MEMBER=&OUTMOD
LISTLOAD DDN=LOADLIB,MEMBER=&OUTMOD
/*
It seems working (double check please).
I used "no-temp" dataset to better help in understanding the process.
It would be not so hard the case you need to isolate multiple modules into
one single output module.
Best regards.
Max
Mail
priva di virus. www.avast.com
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Il giorno lun 4 gen 2021 alle ore 11:46 Steff Gladstone <
steff.gladst...@gmail.com> ha scritto:
> Greetings,
>
> Can anyone suggest a method of isolating or extracting a CSECT
> (statically-linked called program) from a load module? The only (clumsy)
> method I can think of is using (within the linkage editor or binder) a
> REPLACE statement ahead of an INCLUDE statement and specifying in the
> REPLACE all of the other CSECTS in the load module. For example, if the
> load module is called LOADMOD1 and contains CSECTS A,B,C,D,E,F,G,H and I
> want to isolate CSECT F, I would code:
>
> REPLACE A,B,C,D,E,G,H
> INCLUDE SYSLIB(LOADMOD1)
> NAME F(R)
>
> Obviously this is unwieldy for a load module with lots of CSECTs.
>
> Does anyone have a more elegant way of doing this?
>
> Thanks,
> Steff
>
> --
> 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: Isolating a CSECT within a load module
On Mon, 4 Jan 2021 12:45:37 +0200, Steff Gladstone wrote: > >... using (within the linkage editor or binder) a >REPLACE statement ahead of an INCLUDE statement and specifying in the >REPLACE all of the other CSECTS in the load module. ... > >Obviously this is unwieldy for a load module with lots of CSECTs. > Might that be scripted, filtering the output of AMBLIST to generate SYSLIN commands? Computers are good at doing unwieldy stuff. Does Binder impose a limit on number of REPLACE statements? Even if so, use multiple passes. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Isolating a CSECT within a load module
On 2021-01-04 9:46 PM, Steff Gladstone wrote: an anyone suggest a method of isolating or extracting a CSECT (statically-linked called program) from a load module? Well, if it really is a load module, I'd suggest delinking it into an object deck. Potentially suitable delinkers are available at cbttape.org. The one I'm most familiar with is David Noon's delinker which ended up being called DELINKI (to distinguish it from the the OS/360 era DELINK0, which I believe was enhanced in due course to cater for 31-bit modes). The reason I am more familiar with it is because REVIEW can invoke it dynamically. In this usage scenario, you would display the member list with a REVIEW program.library command, tag the relevant member(s) with the necessary T selection code(s) (or else have every member delinked), and then issue the DELINK primary command. Program DELINKI would be dynamically invoked to delink the selected program(s) into the nominated output data set (a detail which I did not mention before). For your situation, I'd expect that you would be better off just downloading and "installing" CBT file 90 and figuring out how to run it as a stand-alone utility to delink the CSECT of interest. If I can figure out how to call it dynamically, it can't be that hard to run it in its own job step. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Isolating a CSECT within a load module
Greetings, Can anyone suggest a method of isolating or extracting a CSECT (statically-linked called program) from a load module? The only (clumsy) method I can think of is using (within the linkage editor or binder) a REPLACE statement ahead of an INCLUDE statement and specifying in the REPLACE all of the other CSECTS in the load module. For example, if the load module is called LOADMOD1 and contains CSECTS A,B,C,D,E,F,G,H and I want to isolate CSECT F, I would code: REPLACE A,B,C,D,E,G,H INCLUDE SYSLIB(LOADMOD1) NAME F(R) Obviously this is unwieldy for a load module with lots of CSECTs. Does anyone have a more elegant way of doing this? Thanks, Steff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
