Re: LINK vs LOAD/CALL
No. RENT implies REUS. Meanwhile RENT *may* be modified IFF an ENQ is first issued on the code to be modified, provided that code is then restored to what it was before it was ENQ'd and then DEQ'd. Only REFR prohibits any code modification (because REFR means that an LMOD can be swapped out and refreshed from its original copy on DASD, at any time during execution and without interruption) - and REFR implies RENT implies REUS, but RENT does not imply REFR. On 05/02/2021 20:02, Joseph Reichman wrote: > Sorry to jump in here but can you have rent without reus > > > >> On Feb 5, 2021, at 2:59 PM, Seymour J Metz wrote: >> >> If the module is not REUS then every LOAD will get a different copy. If the >> module is REUS but not RENT then LOAD, ENQ, CALL, DEQ, DELETE is safe. Using >> LOAD, SYNCH, DELETE is left as an excise for the reader. In most cases I >> would use LINK(X). >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >> Bernd Oppolzer [bernd.oppol...@t-online.de] >> Sent: Friday, February 5, 2021 1:41 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: LINK vs LOAD/CALL >> >> I would like to add: >> >> while LINK is functionally the same as LOAD - CALL - DELETE, >> there is an important difference: >> >> the transfer of control with LINK is known to the operating system, >> but with LOAD - CALL - DELETE, it is NOT known. >> In fact, CALL is not a supervisor action, it is simple machine >> instructions (very cheap). >> This means that if a module is not RENT and not REUS (for example), >> a call using LOAD - CALL - DELETE is not safe, because the system does >> not know that >> the module is in use. Another subtask can easily call the same module at >> the same time, >> if it knows the address, and it will never get another copy. You are >> responsible yourself >> for doing things right. >> >> With LINK, on the contrary, if the module is not RENT and not REUS, the >> system >> will ALWAYS fetch a new copy, when you do another LINK. >> >> (There is a "use count" in the control blocks, which is incremented and >> decremented >> during LINK processing, but of course not, when doing a CALL). >> >> Kind regards >> >> Bernd >> >> >>> Am 05.02.2021 um 18:54 schrieb Frank Swarbrick: >>> I am not a systems programmer. I am a COBOL programmer who knows only >>> enough assembler to be dangerous. >>> What is the "difference" between doing a LOAD and a CALL to perform a >>> dynamic call and doing a LINK? >>> >>> -- >>> 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: LINK vs LOAD/CALL
RENT implies REUS; REUS does not imply RENT. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joseph Reichman [reichman...@gmail.com] Sent: Friday, February 5, 2021 3:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL I opened a dcb load library with the same load mod name as the first Did an attach DCB= TASKLIB= Didn’t pick it up from there as the module from the first load lib with same name was linked REUS > On Feb 5, 2021, at 3:48 PM, Seymour J Metz wrote: > > RENT implies REUS.. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Joseph Reichman [reichman...@gmail.com] > Sent: Friday, February 5, 2021 3:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > Sorry to jump in here but can you have rent without reus > > > >> On Feb 5, 2021, at 2:59 PM, Seymour J Metz wrote: >> >> If the module is not REUS then every LOAD will get a different copy. If the >> module is REUS but not RENT then LOAD, ENQ, CALL, DEQ, DELETE is safe. Using >> LOAD, SYNCH, DELETE is left as an excise for the reader. In most cases I >> would use LINK(X). >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >> Bernd Oppolzer [bernd.oppol...@t-online.de] >> Sent: Friday, February 5, 2021 1:41 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: LINK vs LOAD/CALL >> >> I would like to add: >> >> while LINK is functionally the same as LOAD - CALL - DELETE, >> there is an important difference: >> >> the transfer of control with LINK is known to the operating system, >> but with LOAD - CALL - DELETE, it is NOT known. >> In fact, CALL is not a supervisor action, it is simple machine >> instructions (very cheap). >> This means that if a module is not RENT and not REUS (for example), >> a call using LOAD - CALL - DELETE is not safe, because the system does >> not know that >> the module is in use. Another subtask can easily call the same module at >> the same time, >> if it knows the address, and it will never get another copy. You are >> responsible yourself >> for doing things right. >> >> With LINK, on the contrary, if the module is not RENT and not REUS, the >> system >> will ALWAYS fetch a new copy, when you do another LINK. >> >> (There is a "use count" in the control blocks, which is incremented and >> decremented >> during LINK processing, but of course not, when doing a CALL). >> >> Kind regards >> >> Bernd >> >> Am 05.02.2021 um 18:54 schrieb Frank Swarbrick: >>> I am not a systems programmer. I am a COBOL programmer who knows only >>> enough assembler to be dangerous. >>> What is the "difference" between doing a LOAD and a CALL to perform a >>> dynamic call and doing a LINK? >>> >>> -- >>> 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 -- 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: LINK vs LOAD/CALL
I opened a dcb load library with the same load mod name as the first Did an attach DCB= TASKLIB= Didn’t pick it up from there as the module from the first load lib with same name was linked REUS > On Feb 5, 2021, at 3:48 PM, Seymour J Metz wrote: > > RENT implies REUS.. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Joseph Reichman [reichman...@gmail.com] > Sent: Friday, February 5, 2021 3:02 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > Sorry to jump in here but can you have rent without reus > > > >> On Feb 5, 2021, at 2:59 PM, Seymour J Metz wrote: >> >> If the module is not REUS then every LOAD will get a different copy. If the >> module is REUS but not RENT then LOAD, ENQ, CALL, DEQ, DELETE is safe. Using >> LOAD, SYNCH, DELETE is left as an excise for the reader. In most cases I >> would use LINK(X). >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >> Bernd Oppolzer [bernd.oppol...@t-online.de] >> Sent: Friday, February 5, 2021 1:41 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: LINK vs LOAD/CALL >> >> I would like to add: >> >> while LINK is functionally the same as LOAD - CALL - DELETE, >> there is an important difference: >> >> the transfer of control with LINK is known to the operating system, >> but with LOAD - CALL - DELETE, it is NOT known. >> In fact, CALL is not a supervisor action, it is simple machine >> instructions (very cheap). >> This means that if a module is not RENT and not REUS (for example), >> a call using LOAD - CALL - DELETE is not safe, because the system does >> not know that >> the module is in use. Another subtask can easily call the same module at >> the same time, >> if it knows the address, and it will never get another copy. You are >> responsible yourself >> for doing things right. >> >> With LINK, on the contrary, if the module is not RENT and not REUS, the >> system >> will ALWAYS fetch a new copy, when you do another LINK. >> >> (There is a "use count" in the control blocks, which is incremented and >> decremented >> during LINK processing, but of course not, when doing a CALL). >> >> Kind regards >> >> Bernd >> >> Am 05.02.2021 um 18:54 schrieb Frank Swarbrick: >>> I am not a systems programmer. I am a COBOL programmer who knows only >>> enough assembler to be dangerous. >>> What is the "difference" between doing a LOAD and a CALL to perform a >>> dynamic call and doing a LINK? >>> >>> -- >>> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Separating CSECTs from a load module
Dear Folks, We have just made a development to help isolate a csect from a load module. The tool which can help, is the latest version of the PDS 8.6 product from the Updates page of www.cbttape.org. The latest version of the PDS 8.6 program from CBT File 182 (see the Updates page of www.cbttape.org), together with the CSECTS rexx exec on that file (please use only the latest one), now makes isolating an object deck from a load module very simple, provided that the PDS program is set up with its proper bells and whistles, under ISPF. What to do: Bring up a member list for your load library, which includes the load module that you want to look at. (BTW if the load library is a PDSE, use IEBCOPY to copy (at least) that load module to a pds load library. The PDS COPY command with the NEW parameter makes this very easy.) Then bring up PDS against that load library. Make a Member List (ML subcommand) which includes the load module in question. Then use the CS line command against the load module name in the member list. If the proper version of the CSECTS rexx exec is installed (included in CBT File 182), then a new panel will come up which will display all that module's csects. A line command of 'O' which really stands for "Object", will delink the csect (running David Noon's DELINKI program) and present you with its object deck. Just copy off the object deck and use it in a new linkedit stream, or in any way you want. I hope this helps. Please note that (we hope) all auxiliary programs needed or called by the PDS program, are included in File 182 under the member UTILXMIT. All the best of everything to all of you... Sincerely, Sam Golob (on behalf of John Kalinich, who did the work) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
RENT implies REUS.. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joseph Reichman [reichman...@gmail.com] Sent: Friday, February 5, 2021 3:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL Sorry to jump in here but can you have rent without reus > On Feb 5, 2021, at 2:59 PM, Seymour J Metz wrote: > > If the module is not REUS then every LOAD will get a different copy. If the > module is REUS but not RENT then LOAD, ENQ, CALL, DEQ, DELETE is safe. Using > LOAD, SYNCH, DELETE is left as an excise for the reader. In most cases I > would use LINK(X). > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Bernd Oppolzer [bernd.oppol...@t-online.de] > Sent: Friday, February 5, 2021 1:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > I would like to add: > > while LINK is functionally the same as LOAD - CALL - DELETE, > there is an important difference: > > the transfer of control with LINK is known to the operating system, > but with LOAD - CALL - DELETE, it is NOT known. > In fact, CALL is not a supervisor action, it is simple machine > instructions (very cheap). > This means that if a module is not RENT and not REUS (for example), > a call using LOAD - CALL - DELETE is not safe, because the system does > not know that > the module is in use. Another subtask can easily call the same module at > the same time, > if it knows the address, and it will never get another copy. You are > responsible yourself > for doing things right. > > With LINK, on the contrary, if the module is not RENT and not REUS, the > system > will ALWAYS fetch a new copy, when you do another LINK. > > (There is a "use count" in the control blocks, which is incremented and > decremented > during LINK processing, but of course not, when doing a CALL). > > Kind regards > > Bernd > > >> Am 05.02.2021 um 18:54 schrieb Frank Swarbrick: >> I am not a systems programmer. I am a COBOL programmer who knows only >> enough assembler to be dangerous. >> What is the "difference" between doing a LOAD and a CALL to perform a >> dynamic call and doing a LINK? >> >> -- >> 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: LINK vs LOAD/CALL
Sorry to jump in here but can you have rent without reus > On Feb 5, 2021, at 2:59 PM, Seymour J Metz wrote: > > If the module is not REUS then every LOAD will get a different copy. If the > module is REUS but not RENT then LOAD, ENQ, CALL, DEQ, DELETE is safe. Using > LOAD, SYNCH, DELETE is left as an excise for the reader. In most cases I > would use LINK(X). > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Bernd Oppolzer [bernd.oppol...@t-online.de] > Sent: Friday, February 5, 2021 1:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LINK vs LOAD/CALL > > I would like to add: > > while LINK is functionally the same as LOAD - CALL - DELETE, > there is an important difference: > > the transfer of control with LINK is known to the operating system, > but with LOAD - CALL - DELETE, it is NOT known. > In fact, CALL is not a supervisor action, it is simple machine > instructions (very cheap). > This means that if a module is not RENT and not REUS (for example), > a call using LOAD - CALL - DELETE is not safe, because the system does > not know that > the module is in use. Another subtask can easily call the same module at > the same time, > if it knows the address, and it will never get another copy. You are > responsible yourself > for doing things right. > > With LINK, on the contrary, if the module is not RENT and not REUS, the > system > will ALWAYS fetch a new copy, when you do another LINK. > > (There is a "use count" in the control blocks, which is incremented and > decremented > during LINK processing, but of course not, when doing a CALL). > > Kind regards > > Bernd > > >> Am 05.02.2021 um 18:54 schrieb Frank Swarbrick: >> I am not a systems programmer. I am a COBOL programmer who knows only >> enough assembler to be dangerous. >> What is the "difference" between doing a LOAD and a CALL to perform a >> dynamic call and doing a LINK? >> >> -- >> 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: LINK vs LOAD/CALL
OK, now I get it. That sequence would indeed almost exactly emulate LINK. And therefore, there's probably no reason to do it; but who knows. I didn't say that RBs were esoteric, only that the need to create one with SYNCH is. I think the typical case is for some authorized code to run a user exit somewhat safely. sas On Fri, Feb 5, 2021 at 2:39 PM Ed Jaffe wrote: > On 2/5/2021 11:06 AM, Steve Smith wrote: > > > > SYNCH could replace CALL, but the reasons for doing so are pretty > esoteric, > > and 99.99% of application programmers never have, and never need hear > about > > it (I realize the grammar is off, but I liked it this way... sorry). > > > My point is that LINK replaces SYNCH/LOAD/CALL/DELETE, not just > LOAD/CALL/DELETE. > > SYNCH runs a subroutine in a new PRB. In that subroutine you LOAD the > module and pass control to it. When it returns, you issue a DELETE for > the module and then an SVC 3. The new RB is deleted, and control resumes > at the instruction following the SYNCH macro. > > LINK does all of this in one macro. > > Creating a new RB to run some code is not esoteric at all. It's > fundamental to how MVS works. > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > > > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
If the module is not REUS then every LOAD will get a different copy. If the module is REUS but not RENT then LOAD, ENQ, CALL, DEQ, DELETE is safe. Using LOAD, SYNCH, DELETE is left as an excise for the reader. In most cases I would use LINK(X). -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bernd Oppolzer [bernd.oppol...@t-online.de] Sent: Friday, February 5, 2021 1:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL I would like to add: while LINK is functionally the same as LOAD - CALL - DELETE, there is an important difference: the transfer of control with LINK is known to the operating system, but with LOAD - CALL - DELETE, it is NOT known. In fact, CALL is not a supervisor action, it is simple machine instructions (very cheap). This means that if a module is not RENT and not REUS (for example), a call using LOAD - CALL - DELETE is not safe, because the system does not know that the module is in use. Another subtask can easily call the same module at the same time, if it knows the address, and it will never get another copy. You are responsible yourself for doing things right. With LINK, on the contrary, if the module is not RENT and not REUS, the system will ALWAYS fetch a new copy, when you do another LINK. (There is a "use count" in the control blocks, which is incremented and decremented during LINK processing, but of course not, when doing a CALL). Kind regards Bernd Am 05.02.2021 um 18:54 schrieb Frank Swarbrick: > I am not a systems programmer. I am a COBOL programmer who knows only enough > assembler to be dangerous. > What is the "difference" between doing a LOAD and a CALL to perform a dynamic > call and doing a LINK? > > -- > 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: LINK vs LOAD/CALL
On 2/5/2021 11:06 AM, Steve Smith wrote: SYNCH could replace CALL, but the reasons for doing so are pretty esoteric, and 99.99% of application programmers never have, and never need hear about it (I realize the grammar is off, but I liked it this way... sorry). My point is that LINK replaces SYNCH/LOAD/CALL/DELETE, not just LOAD/CALL/DELETE. SYNCH runs a subroutine in a new PRB. In that subroutine you LOAD the module and pass control to it. When it returns, you issue a DELETE for the module and then an SVC 3. The new RB is deleted, and control resumes at the instruction following the SYNCH macro. LINK does all of this in one macro. Creating a new RB to run some code is not esoteric at all. It's fundamental to how MVS works. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ 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: LINK vs LOAD/CALL
On Fri, Feb 5, 2021 at 1:28 PM Ed Jaffe wrote: > On 2/5/2021 10:04 AM, Steve Smith wrote: > > LINK is one step, rather than LOAD/CALL/DELETE. > > > I would say LINK takes the place of SYNCH/LOAD/CALL/DELETE. > > > Why? That sequence that makes no sense. SYNCH could replace CALL, but the reasons for doing so are pretty esoteric, and 99.99% of application programmers never have, and never need hear about it (I realize the grammar is off, but I liked it this way... sorry). sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zero-length PC section, the binder, and resulting AMODE/RMODE
Barry Lichtenstein wrote: The binder will simply discard the "private code" (unnamed) CSECT (section), if it has text. It never gets incorporated into the module being bound, so it should have no effect on it. Binder has behaved like this since near the beginning (early 90's, around when PM3 format was introduced). Thanks Barry! My casual tests did show that the binder does not ignore the AMODE of "private code" sections when they have text: DC 'Some text' AMODE 31 RMODE ANY FOO CSECT FOO AMODE 31 FOO RMODE ANY BR 14 END FOO will generate an AMODE 31/RMODE ANY load module, but DC 'Some text' AMODE 24 FOO CSECT FOO AMODE 31 FOO RMODE ANY BR 14 END FOO seems to an AMODE 24/RMODE 24 load module... but, AMODE 24 FOO CSECT FOO AMODE 31 FOO RMODE ANY BR 14 END FOO seems to generate an AMODE 31/RMODE ANY load module. - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LINK vs LOAD/CALL
I would like to add: while LINK is functionally the same as LOAD - CALL - DELETE, there is an important difference: the transfer of control with LINK is known to the operating system, but with LOAD - CALL - DELETE, it is NOT known. In fact, CALL is not a supervisor action, it is simple machine instructions (very cheap). This means that if a module is not RENT and not REUS (for example), a call using LOAD - CALL - DELETE is not safe, because the system does not know that the module is in use. Another subtask can easily call the same module at the same time, if it knows the address, and it will never get another copy. You are responsible yourself for doing things right. With LINK, on the contrary, if the module is not RENT and not REUS, the system will ALWAYS fetch a new copy, when you do another LINK. (There is a "use count" in the control blocks, which is incremented and decremented during LINK processing, but of course not, when doing a CALL). Kind regards Bernd Am 05.02.2021 um 18:54 schrieb Frank Swarbrick: I am not a systems programmer. I am a COBOL programmer who knows only enough assembler to be dangerous. What is the "difference" between doing a LOAD and a CALL to perform a dynamic call and doing a LINK? -- 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: LINK vs LOAD/CALL
On 2/5/2021 10:04 AM, Steve Smith wrote: LINK is one step, rather than LOAD/CALL/DELETE. I would say LINK takes the place of SYNCH/LOAD/CALL/DELETE. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ 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: LINK vs LOAD/CALL
Thank you! From: IBM Mainframe Discussion List on behalf of Steve Smith Sent: Friday, February 5, 2021 11:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL LINK is one step, rather than LOAD/CALL/DELETE. LINK will honor the target module's reusability attributes. It is more overhead for a frequently invoked program. Technically, LINK creates a new PRB, which is sometimes, if rarely, required. You would probably find out the first time if the called program does an XCTL or an EXIT and you crash. sas On Fri, Feb 5, 2021 at 12:54 PM Frank Swarbrick wrote: > I am not a systems programmer. I am a COBOL programmer who knows only > enough assembler to be dangerous. > What is the "difference" between doing a LOAD and a CALL to perform a > dynamic call and doing a LINK? > > -- > 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: LINK vs LOAD/CALL
LINK is one step, rather than LOAD/CALL/DELETE. LINK will honor the target module's reusability attributes. It is more overhead for a frequently invoked program. Technically, LINK creates a new PRB, which is sometimes, if rarely, required. You would probably find out the first time if the called program does an XCTL or an EXIT and you crash. sas On Fri, Feb 5, 2021 at 12:54 PM Frank Swarbrick wrote: > I am not a systems programmer. I am a COBOL programmer who knows only > enough assembler to be dangerous. > What is the "difference" between doing a LOAD and a CALL to perform a > dynamic call and doing a LINK? > > -- > 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: LINK vs LOAD/CALL
LOAD and CALL keeps the module you loaded resident in memory until and unless you manually delete it. LINK can (not always) load a new copy every time you use the LINK, which can be expensive. In time used. HTH Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Friday, February 5, 2021 12:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: LINK vs LOAD/CALL EXTERNAL EMAIL I am not a systems programmer. I am a COBOL programmer who knows only enough assembler to be dangerous. What is the "difference" between doing a LOAD and a CALL to perform a dynamic call and doing a LINK? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
LINK vs LOAD/CALL
I am not a systems programmer. I am a COBOL programmer who knows only enough assembler to be dangerous. What is the "difference" between doing a LOAD and a CALL to perform a dynamic call and doing a LINK? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCP/IP relationship to OMVS
I've been playing around with COBOL and the Unix callable services. Kinda cool! Glad they are not limited to assembler. From: IBM Mainframe Discussion List on behalf of David Crayford Sent: Friday, February 5, 2021 12:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TCP/IP relationship to OMVS On 5/02/2021 1:32 am, Charles Mills wrote: > TCP/IP certainly makes use of lots of UNIX services. Yes, and it goes both ways. I'm working a project right now with one of the original IBM OMVS developers and he told me that the BPX callable services wrap Comms Server APIs and then the LE C/C++ runtime wrap the BPX services. AF_UNIX sockets are handled in OMVS. It was an inspired decision by IBM to provide callable services for z/OS UNIX and not another macro interface like EZASMI. -- 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: TCP/IP relationship to OMVS
That depends on what you mean by recent. -- 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: Thursday, February 4, 2021 2:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TCP/IP relationship to OMVS On Thu, 4 Feb 2021 09:32:58 -0800, Charles Mills wrote: > >I believe TCP/IP and several of its "children" such as FTP server run as UNIX >daemons. > Some such children are recent adoptees. I believe FTP on MVS far antedates OMVS. (But was that an ISV offering? IIRC an Intel Fastpath(?) that masqueraded as a CTC.) -- 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: Any way to anticipate failure messages
Dave says no; he had to do deconstructive maintenance after failures. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of PINION, RICHARD W. [rpin...@firsthorizon.com] Sent: Thursday, February 4, 2021 3:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to anticipate failure messages Didn't the HAL 9000 have predictive failure analysis? Of course that was in 2001 :) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Thursday, February 4, 2021 3:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Any way to anticipate failure messages [External Email. Exercise caution when clicking links or opening attachments.] List - As always something happens and management reacts We are looking to see if there is any tool that could trap any message or event on Mainframe and generate a daily report for the SYSPROGs to review to ensure zero failures Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- 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: EXTERNAL EMAIL: Re: Any way to anticipate failure messages
Would bitsavers host it if you scanned it? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jerry Whitteridge [jerry.whitteri...@albertsons.com] Sent: Thursday, February 4, 2021 5:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL EMAIL: Re: Any way to anticipate failure messages I have a copy of that on IBM letterhead hidden away somewhere Jerry Whitteridge jerry.whitteri...@albertsons.com Manager Mainframe Systems & HP Non-Stop Albertsons Companies -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Thursday, February 4, 2021 3:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL EMAIL: Re: Any way to anticipate failure messages That made me smile - OS/VU I had forgotten about that one Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Thursday, February 4, 2021 2:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to anticipate failure messages https://clicktime.symantec.com/347j2kHQiRMnxey3444pqMi7Vc?u=http%3A%2F%2Fwww.weathergraphics.com%2Ftim%2Fibm.htm > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Lizette Koehler > Sent: Thursday, February 04, 2021 1:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Any way to anticipate failure messages > > So the problem is to know what events or message will occur and then > prevent them from happening. > > The Omnipresence SysTem > > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Paul Gilmartin > Sent: Thursday, February 4, 2021 2:17 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Any way to anticipate failure messages > > On Thu, 4 Feb 2021 21:59:22 +0100, Radoslaw Skorupka wrote: > > >W dniu 04.02.2021 o 21:40, Lizette Koehler pisze: > >> > >> As always something happens and management reacts > >> > >> We are looking to see if there is any tool that could trap any > >> message or event on Mainframe and generate a daily report for the > >> SYSPROGs to review to ensure zero failures > > > >Real answer: NO. > > > As I read it, the OP recognizes the inevitable "[a]s always" > occurrence of failures and wishes to prevent management's receiving > immediate notification of those failures. > > -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- 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: TCP/IP relationship to OMVS
There was also an ISV TCP/IP implementation from Interlink. I recall at the time modifying Lionel's excellent XMITIP to use Interlink TCP. Dana On Thu, 4 Feb 2021 23:46:40 +, Frank Swarbrick wrote: >Looks like OS/390 V2R4 (Sept 1997?) contained "A new TCP/IP stack, for >applications using OS/390 UNIX System Services (formerly called OpenEdition) >sockets". > >Prior to that was TCP/IP Version 3 Release 2, which I believe was based on a >port of TCP/IP for VM (and written in Pascal!). Or something like that. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More freeform output using SORT
> So I guess I need to use Rexx, or some other language? SORT doesn't > do variable length output fields? Dave, You don't have to use REXX as DFSORT is quite capable of handling variable string. Use the function JFY (justifies string to left/right) or SQZ (removes spaces in between and justifies the string left/right). Both functions allow you to append strings to the beginning of the string or at the end. You can also increase the length of the string. I assumed the input to be dataset names which can have a maximum length of 44 bytes ( exception zfs files). Use the following JCL which would give you the desired results //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD * ZOS21D.ASM.AASMMAC1 ZOS21D.ASM.AASMMAC2 ZOS21D.ASM.AASMMOD1 ZOS21D.ASM.AASMMOD2 ZOS21D.ASM.AASMPUT2 ZOS21D.ASM.AASMSAM1 ZOS21D.ASM.AASMSAM2 ZOS21D.CBC.ACCNCMP ZOS21D.CBC.ACCNSR1 ZOS21D.CBC.ACLBDLL ZOS21D.CBC.ACLBDLL2 //SORTOUT DD SYSOUT=* //SYSINDD * OPTION COPY INREC BUILD=(01,44,JFY=(SHIFT=LEFT, LEAD=C'name="', TRAIL=C'"', LENGTH=80)) /* The output from the above job is 80 bytes records name="ZOS21D.ASM.AASMMAC1" name="ZOS21D.ASM.AASMMAC2" name="ZOS21D.ASM.AASMMOD1" name="ZOS21D.ASM.AASMMOD2" name="ZOS21D.ASM.AASMPUT2" name="ZOS21D.ASM.AASMSAM1" name="ZOS21D.ASM.AASMSAM2" name="ZOS21D.CBC.ACCNCMP" name="ZOS21D.CBC.ACCNSR1" name="ZOS21D.CBC.ACLBDLL" name="ZOS21D.CBC.ACLBDLL2" Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: X3270 or c3270 on mac
Hi Shmuel, I've check it out. Unfortunately, explicit partitions are not supported. If you're interested to give it a try anyway, please let me know and I'll send you a copy. If you'll be the only one using it, you can use it for free. Regards, Michael -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List Im Auftrag von Seymour J Metz Gesendet: Dienstag, 2. Februar 2021 15:22 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: X3270 or c3270 on mac Does it support explicit partitions? How much does it cost? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Immo [i...@mikno.de] Sent: Tuesday, February 2, 2021 7:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: X3270 or c3270 on mac Give JProtector from XPS a try. It's Java. Doesn't matter if you'll run it on Linux, Mac or Windows. Regards, Michael -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List Im Auftrag von Seymour J Metz Gesendet: Dienstag, 2. Februar 2021 10:19 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: X3270 or c3270 on mac If only there were a 3270 simulator for Linux with the functionality of a 3290, or at least enough to support SPLIT and VSPLIT in ISPF. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of René Jansen [rene.vincent.jan...@gmail.com] Sent: Tuesday, February 2, 2021 7:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: X3270 or c3270 on mac ZOC is fine for Mac, as it is for PC. Exists for many years and is Rexx scriptable. Does all I need, like moving the enter key to where it belongs, and cuts and pasts JCL without interrupting your workflow. René Jansen > On 2 Feb 2021, at 11:51, David Crayford wrote: > > One of the reasons I chose a PC instead of a Mac when I had the choice for a > new work machine was the lack of a decent 3270 emulator. By decent I mean > something that supports a custom 160*60 screen size. > > This is not a shameless plug for one of our products but if I were a > Mac user I would checkout Rocket Terminal Emulator (Web Edition) [1]. > It runs in a browser and you can configure the keyboard using the GUI. > The usual > 3270 keys like right-CNTL=enter, destructive backspace work great. It > supports custom screen sizes perfectly. It requires a Node.js web server but > if you're a single user you can run the server on your Mac at a much reduced > price. > For enterprise customers you can run the server on a distributed system or > even z/OS if you so choose. > > [1] > https://www.rocketsoftware.com/products/rocket-bluezonepassport-termin > al-emulator/rocket-bluezone-web > > >> On 1/02/2021 8:12 am, Jousma, David wrote: >> I've seen this mentioned here before. Would anyone who is using mind >> sharing your key map file? I'm playing around with it on my Mac. Looking >> for a headscarf. >> >> Thanks, dave >> This e-mail transmission contains information that is confidential and may >> be privileged. >> It is intended only for the addressee(s) named above. If you receive >> this e-mail in error, please do not read, copy or disseminate it in >> any manner. If you are not the intended recipient, any disclosure, >> copying, distribution or use of the contents of this information is >> prohibited. Please reply to the message immediately by informing the >> sender that the message was misdirected. After replying, please erase it >> from your computer system. Your assistance in correcting this error is >> appreciated. >> >> >> >> >> - >> - 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
