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
Lpar deletion from IODF
Dear, Using HCD, there is a need to remove a Lpar(Partition) definition from a CEC. As we know much on it, I removed a lpar from the Processor definition which is followed into Processor ID>CSS ID>6. Work with partition. Selected the Lpar and deleted with a Work IODF, and ready to build a Production IODF. With this process, it is pretty quite simple and straight forward removing the lpar. I however, make sure of a few others that I am a bit concerned below: 1. may lose any of connection from other existing lpars 2. may have any messages from consoles on other existing lpars 3. may have some stuff to do with Sysplex coupled with two CECs, and CF01, 02 in each CEC 4. may have an issue when dynamic refresh with this Lpar removal IODF over all lpars in the CEC in implementing "Activate S/W, and H/W configuration 5. anything that I am not aware of Any input from youall will greatly be appreciated, let me know if any further information needed. Thanks huge in advance!! Steve -- 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
VS COBOL II 1.3 differed from 1.4 was Re: Looking for an old OSVS Cobol II v1.3
[Default] On 19 Jan 2021 05:56:15 -0800, in bit.listserv.ibm-main 01304632a58d-dmarc-requ...@listserv.ua.edu (W Mainframe) wrote: >Guys, >I am planning to revival an old application written in OSVS Cobol II v1.3 >(it's important the correct release) for VMSP rel5 in my P370... Unfortunately >my cobol mdisk has some crc errors, I can't read it and there is no backup... >:(Anyone has this compiler available? There is no comercial focus... Are you looking for 1.3 which I think was still COBOL 74 standard as opposed to 1.4 which I think was the first to be the COBOL 85 standard? There were some noticeable changes in syntax and interpretation between the two standards. Clark Morris >ThanksDan > >Sent from Yahoo Mail for iPhone > >-- >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
Another Old Timer lost
All: Anyone who knew Bob Levy I wish to inform you of his death. Bob was a big-time GUIDE person. He was a prominent person in the Storage Group in GUIDE. Bob passed away in December. I just found out about it a week ago. Bob died of Cancer. All that knew Bob was better off because of what Bob did for Storage Management. He provided excellent user input into IBM for immediate and long term storage futures. After Bob retired, he was still active in Storage Management. Some of the code from 40 years ago still runs today on Z architecture with little or no change. Bob was drafted, and he went into the Navy. After he got out, he was an operator and then Programmer for the 7090 and then the 360, 370, and upwards. He was a significant person in the user community in the MSS from IBM. If you know of any old-timers active in Guide, please let them know of Bob’s passing. Sorry for the interruption. Back to the discussion. Ed -- 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
IBM Open Enterprise SDK for Python 3.9 is now available!
IBM Open Enterprise SDK for Python 3.9 was generally available on Jan 15th, 2020. This release is based on the Python 3.9 community release at https://docs.python.org/3.9/whatsnew/3.9.html. With this release, IBM Z clients gain access to the latest and greatest Python community release. Not only can you keep pace with development across all of your platforms, but you can also leverage your IBM Z assets like DB2 databases and datasets, as well as using the vast Python package ecosystem. Visit the Python Community page for more how-to information at https://community.ibm.com/community/user/ibmz-and-linuxone/groups/topic-home?CommunityKey=d867d066-1659-4aad-ab24-d14d92093531. IBM Open Enterprise SDK for Python is a strategic programming language and IBM intends to maintain currency with the Python Software Foundation. This release includes: - New dictionary merge & update operators for more succinct code - New removeprefix() and removesuffix() string methods - Type annotations in the source that now supports built-in collection types like list and dict - A new more performant parser makes it easier to add new functionality to the Python language - A new graphlib package in the standard library which supports producing a Topological ordering Looking to get a jump start using Python on IBM Z? Check out our video demos! - Learn how to set up your virtual environment at https://mediacenter.ibm.com/media/1_tpjlr333. - Learn how to build a native package at https://mediacenter.ibm.com/media/1_b6mjzc4v. To obtain the latest version of IBM Open Enterprise SDK for Python, please visit the Product Page at https://www.ibm.com/products/open-enterprise-python-zos. For more information about IBM Open Enterprise SDK for Python documentation, please visit BIM Knowledge Center at https://www.ibm.com/support/knowledgecenter/SSCH7P_3.9.0. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
