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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Seymour J Metz Sent: Saturday, January 23, 2021 8:15 PM To: [email protected] 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 [[email protected]] on behalf of CM Poncelet [[email protected]] Sent: Friday, January 22, 2021 7:11 PM To: [email protected] 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 <EP>" 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 <member 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 <whatever>" 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 +0000, CM Poncelet wrote: > >> The "END <whatever CSECT>" should always be coded to ensure that the >> beginning of "<whatever CSECT>" 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 [email protected] with the message: INFO IBM-MAIN
