Re: LINK vs LOAD/CALL

2021-02-05 Thread CM Poncelet
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

Re: LINK vs LOAD/CALL

2021-02-05 Thread Seymour J Metz
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

Re: LINK vs LOAD/CALL

2021-02-05 Thread Joseph Reichman
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.. > > > -- >

Separating CSECTs from a load module

2021-02-05 Thread Sam Golob
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

Re: LINK vs LOAD/CALL

2021-02-05 Thread Seymour J Metz
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:

Re: LINK vs LOAD/CALL

2021-02-05 Thread Joseph Reichman
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

Re: LINK vs LOAD/CALL

2021-02-05 Thread Steve Smith
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

Re: LINK vs LOAD/CALL

2021-02-05 Thread Seymour J Metz
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

Re: LINK vs LOAD/CALL

2021-02-05 Thread Ed Jaffe
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

Re: LINK vs LOAD/CALL

2021-02-05 Thread Steve Smith
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

Re: zero-length PC section, the binder, and resulting AMODE/RMODE

2021-02-05 Thread Thomas David Rivers
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

Re: LINK vs LOAD/CALL

2021-02-05 Thread Bernd Oppolzer
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

Re: LINK vs LOAD/CALL

2021-02-05 Thread Ed Jaffe
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/

Re: LINK vs LOAD/CALL

2021-02-05 Thread Frank Swarbrick
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

Re: LINK vs LOAD/CALL

2021-02-05 Thread Steve Smith
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

Re: LINK vs LOAD/CALL

2021-02-05 Thread Farley, Peter x23353
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

LINK vs LOAD/CALL

2021-02-05 Thread 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

Re: TCP/IP relationship to OMVS

2021-02-05 Thread Frank Swarbrick
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

Re: TCP/IP relationship to OMVS

2021-02-05 Thread Seymour J Metz
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,

Re: Any way to anticipate failure messages

2021-02-05 Thread Seymour J Metz
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]

Re: EXTERNAL EMAIL: Re: Any way to anticipate failure messages

2021-02-05 Thread Seymour J Metz
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

Re: TCP/IP relationship to OMVS

2021-02-05 Thread Dana Mitchell
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

Re: More freeform output using SORT

2021-02-05 Thread Sri h Kolusu
> 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

AW: X3270 or c3270 on mac

2021-02-05 Thread Immo
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: