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 <edja...@phoenixsoftware.com> 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
