security with storage allocation under z.OS

[Ze'ev Atlas]

Hi allIn the 1970's I probably could have done some getmain, write some code into that obtained memory and jump to that code.  I assume that nowadays, this would be impossible and there is some security model to prevent such a security breach.Do you know where can I find information on the mainframe security model under z/OS.
Ze'ev Atlas

[Tom Harper]

That is not impossible and used in many products for performance reasons, such as sorting.

Sent from my iPhone

> On Nov 16, 2020, at 12:24 PM, Ze'ev Atlas <000001774d97d10...@LISTSERV.UGA.EDU> wrote:
>
> Hi allIn the 1970's I probably could have done some getmain, write some code into that obtained memory and jump to that code. I assume that nowadays, this would be impossible and there is some security model to prevent such a security breach.Do you know where can I find information on the mainframe security model under z/OS.
> Ze'ev Atlas

--------------------------------------------------------------------------------
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.

[Steve Smith]

There is a new operand on STORAGE, EXECUTABLE=YES|NO. The default is YES,
and for earlier releases there was no execute-prevention capability afaik.

I don't know what to tell you about the "security model". It's a big
subject.

sas

[Tom Harper]

And curiously the facility is present for STORAGE OBTAIN and ISRV64 but not for IARCP64.

Sent from my iPhone

[Seymour J Metz]

An across the board restriction would brek, e.g., LOADER.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Ze'ev Atlas <000001774d97d10...@LISTSERV.UGA.EDU>
Sent: Monday, November 16, 2020 12:24 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: security with storage allocation under z.OS

[Ze'ev Atlas]

I am pretty certain that something would break.  My question was to guide me to where the security model is discussed, so I could code a valid and safe application that actually does what I've described in a safe and compliant way.
ZA

Sent from Yahoo Mail on Android

On Mon, Nov 16, 2020 at 2:24 PM, Seymour J Metz<sme...@GMU.EDU> wrote: An across the board restriction would brek, e.g., LOADER.

[Tony Harminc]

On Mon, 16 Nov 2020 at 12:24, Ze'ev Atlas
<000001774d97d10...@listserv.uga.edu> wrote:
>
> Hi allIn the 1970's I probably could have done some getmain, write some code into that obtained memory and jump to that code. I assume that nowadays, this
> would be impossible and there is some security model to prevent such a security breach.

Why do you call this a security breach? What is wrong with being able
to write and execute your own code? If you can't do that, you don't
have a computer, you have an appliance. Sort of like an iPhone...

Yes, there have been architectures over the years that regard the
ability to execute code as a privilege. But zArch (and predecessors)
has never worked that way.
What is the difference between executing that code you propose that
does the GETMAIN and so on, and executing the code that you wrote into
the area you obtained? What matters is what code can do with and to
data, and that is controlled by mechanisms that don't depend on who
wrote the code into storage.

For that matter, what is the difference between building a sequence of
zArch instructions and then executing them, and building a sequence of
Java bytecodes or REXX instructions and executing *them*?

So why is IBM adding the notion of no-execute storage to the
architecture? Same reason as Intel and everyone else: to help prevent
bugs in *privileged* code from being exploited by crafted data. If a
program has a bug such that it treats part of its input data as a
branch offset without validating it, then it is useful to have the
normal kind of storage not allow execution. It just reduces the attack
surface.

> Do you know where can I find information on the mainframe security model under z/OS.

There is a fair bit of information on what not to do when writing
privileged programs. IBM has given sessions on this topic at SHARE and
such. These are all how to write code according to rules identified in
the very first statement of MVS System Integrity published around
1972.

Tony H.

[Farley, Peter x23353]

It is not necessary to getmain storage in which to run a dynamically created program. I wrote a simple subroutine to retrieve the LE CAA address from R12 that can be stored in a COBOL WORKING-STORAGE area and executed very easily. Sample code below.

You could copy this simple subroutine into any dynamically acquired storage you wish and execute it from there as well.

There are times I wish that Ent. COBOL had an inline assembler option like the MetalC compiler does, not that I ever expect it to happen. Too small a business case for an RFE.

I’ll bet someone could cobble something like a workable “inline ASM” using a COBOL-oriented macro processor like MetaCOBOL (does anyone still have that around?), or you could brute-force it with an awk or gawk script or even a rexx/perl/lua script. Trickier and more error prone, but possible.

Peter


GETCAA code in WORKING-STORAGE, pointers to use it, and sample PROCEDURE division code to invoke it:

. . . . .
01 WS-GETCAA-PROGRAM.
* GET ARGUMENT ADDRESS L 15,0(,1)
05 FILLER PIC X(04) VALUE X'58F01000'.
* STORE A(CAA) INTO ARGUMENT ST 12,0(,15)
05 FILLER PIC X(04) VALUE X'50C0F000'.
* SET RETURN-CODE = 0 XR 15,15
05 FILLER PIC X(02) VALUE X'17FF'.
* RETURN TO CALLER BR 14
05 FILLER PIC X(02) VALUE X'07FE'.

01 WS-CAA-PTR.
05 COBCAA-ADDR PROCEDURE-POINTER.
05 FILLER REDEFINES COBCAA-ADDR.
10 COBCAA-ADDR1 POINTER.
10 COBCAA-ADDR2 POINTER.

01 GETCAA-ADDR1 POINTER.

. . . . .
PROCEDURE DIVISION.
. . . . .
* GET CAA ADDRESS VIA EMBEDDED ASSEMBLER CODE
SET GETCAA-ADDR1 TO ADDRESS OF WS-GETCAA-PROGRAM
SET COBCAA-ADDR TO GETCAA-ADDR1
CALL COBCAA-ADDR USING GETCAA-ADDR1

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Ze'ev Atlas
Sent: Monday, November 16, 2020 12:25 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: security with storage allocation under z.OS

--

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.

[Binyamin Dissen]

Why would anything break? How would that be any different from the same code
being in your module?

On Mon, 16 Nov 2020 20:32:24 +0000 Ze'ev Atlas
<000001774d97d10...@LISTSERV.UGA.EDU> wrote:

:>I am pretty certain that something would break.  My question was to guide me to where the security model is discussed, so I could code a valid and safe application that actually does what I've described in a safe and compliant way.

:>ZA

:>Sent from Yahoo Mail on Android
:>
:> On Mon, Nov 16, 2020 at 2:24 PM, Seymour J Metz<sme...@GMU.EDU> wrote: An across the board restriction would brek, e.g., LOADER.

--

Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[Charles Mills]

> If a program has a bug such that it treats part of its input data as a branch offset without validating it,
> then it is useful to have the normal kind of storage not allow execution.

Yes, and to help prevent a bad guy from sending a z/OS program some sort of "message" -- perhaps a URL or SQL -- that is actually crafted as a series of malicious executable instructions, and then somehow inducing the program to branch to it.

The program in question would not have to be privileged. The program might have permitted access to certain datasets or tables that it could be induced to modify maliciously.

Charles

[Charles Mills]

All programs except the IPL text, the nucleus and a few things like that are
of course loaded into "GETMAIN" storage. An across the board restriction on
executing in GETMAIN storage would not just break things, it would break
every thing. It would totally brick the box.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Binyamin Dissen
Sent: Monday, November 16, 2020 1:58 PM
To: ASSEMBL...@LISTSERV.UGA.EDU

[Ngan, Robert]

I found out the hard way that, if you code EXECUTABLE=YES of the STORAGE OBTAIN, you must also code it on the associated STORAGE RELEASE.
Evidently, it's implemented as a subpool under the covers, so like subpool getmains, you must have matching values on OBTAIN and RELEASE.

Robert Ngan
HCL Technologies

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Steve Smith
Sent: Monday, November 16, 2020 11:39
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS

[Ze'ev Atlas]

Ok, this is a piece of information in line of what i was looking for.  Could you please refer me to documentation about storage obtain and storage releaseThank youZA

Sent from Yahoo Mail on Android

On Mon, Nov 16, 2020 at 5:29 PM, Ngan, Robert<rn...@DXC.COM> wrote: I found out the hard way that, if you code EXECUTABLE=YES of the STORAGE OBTAIN, you must also code it on the associated STORAGE RELEASE.

[Dan Greiner]

The ability to prevent instruction execution was introduced by the instruction-execution-protection (IEP) facility on the z14 (September 2017). Per the facility blurb in Chapter 1 of the PoO:

"The instruction-execution-protection facility may be available on a model implementing z/Architecture. When the facility is installed and enabled, and an instruction is fetched from the primary or home address space, an instruction-execution-protection control in the leaf DAT-table entry used in the translation determines whether instructions may or may not be executed from the frame mapped by the entry.

The facility may be used by a control program to better segregate instructions from data. Improved system reliability and integrity may be realized by preventing the execution of instructions from storage locations intended to contain only data. For example, erroneously or maliciously modified data in a program stack can be prevented from being executed. (September, 2017)"

So, the facility only applies to virtual addresses on newer models. As I recall, the development of this facility was requested by z/Linux in order to help avoid classic stack-overflow exposures; but, it obviously has applicability to other environments. (It was also introduced in order to "keep up with the Joneses — er ... I mean the Intels.)

[Paul Gilmartin]

On 2020-11-16, at 17:47:10, Dan Greiner wrote:
> ...

> So, the facility only applies to virtual addresses on newer models. As I recall, the development of this facility was requested by z/Linux in order to help avoid classic stack-overflow exposures; but, it obviously has applicability to other environments. (It was also introduced in order to "keep up with the Joneses — er ... I mean the Intels.)
>

Conversely, there's REFRPROT to prevent storing into programs
marked REFR. Dismayingly, I believe REFRPROT is global and
intrduces incompatibility with "dusty deck" programs erroneously
marked REFR.

-- gil

[Ze'ev Atlas]

That make sense, as I am competing with the Linux develipers.  I consider implementing a simple model, befiting native z/OS, with option to implement the security model when it becomes ubiquitous.  I really thank you for the information, as it gives me the basic answer to my question and quest.ZA

Sent from Yahoo Mail on Android

[Jim Mulder]

That is correct, a subpool has 2 SPQEs - one for EXECUTABLE=YES,
and one for EXECUTEABLE=NO. In z/OS 2.3 and 2.4, we search
only the SPQE for the EXECUTABLE attribute that you specify
when releasing storage, In future release which follows
z/OS 2.4, release processing has been enhanced to treat
what you specify as a performance hint, and search that
SPQE first, and then search the other one if necessary. So
you will no longer need to specify EXECUTABLE correctly
on the release, but you will get better performance if you do.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
11/16/2020 05:29:02 PM:

> From: "Ngan, Robert" <rn...@DXC.COM>
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Date: 11/17/2020 02:03 AM
> Subject: Re: security with storage allocation under z.OS
> Sent by: "IBM Mainframe Assembler List"
<ASSEMBL...@LISTSERV.UGA.EDU>
>

[Jim Mulder]

I am not dismayed. REFRPROT works exactly the way I intended it to
work.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY


"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

11/16/2020 08:35:29 PM:

> From: "Paul Gilmartin" <00000014e0e4a59...@LISTSERV.UGA.EDU>
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Date: 11/17/2020 02:16 AM
> Subject: Re: security with storage allocation under z.OS
> Sent by: "IBM Mainframe Assembler List"
<ASSEMBL...@LISTSERV.UGA.EDU>

[Binyamin Dissen]

On Mon, 16 Nov 2020 18:35:29 -0700 Paul Gilmartin
<00000014e0e4a59...@LISTSERV.UGA.EDU> wrote:

That is a good thing. However, RENT alone does not (conceptually) require a
module to be refreshable.

[Ze'ev Atlas]

Good morning JimI am sending this email off list and I hope that you would help me.I am working to adapt the S390X SLJIT engine to native z/OS.  The current development direction is bound toLinux, as the initiative came from the IBM Linux team.  Therefore, the code is peppered with Linux mambo jumbo and is using C headers not available in the normal IBM C that I am using (to create LE comptible code, not Linux).  Basically they use gcc and make their effort incompatible.Yet, I want the result code of my effort to be as compatible as possible.  If I want to allocate storage for executale purpose in normal IBM C, protecting it the z/OS way, what should I do?
Thank youZe'ev Atlas

Sent from Yahoo Mail on Android

On Tue, Nov 17, 2020 at 2:11 AM, Jim Mulder<d10...@US.IBM.COM> wrote:   That is correct, a subpool has 2 SPQEs - one for EXECUTABLE=YES,

[Seymour J Metz]

Indeed, OS/360 had some code that was reentrant but not refreshable; AFAIK IBM has cleaned up all such abominations, and the binder does not allow you to create a load module or program object marked as reentrant but not refreshaable.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Binyamin Dissen <bdi...@DISSENSOFTWARE.COM>
Sent: Tuesday, November 17, 2020 2:35 AM
To: ASSEMBL...@LISTSERV.UGA.EDU

Subject: Re: security with storage allocation under z.OS

On Mon, 16 Nov 2020 18:35:29 -0700 Paul Gilmartin
<00000014e0e4a59...@LISTSERV.UGA.EDU> wrote:

:>On 2020-11-16, at 17:47:10, Dan Greiner wrote:
:>> ...
:>> So, the facility only applies to virtual addresses on newer models. As I recall, the development of this facility was requested by z/Linux in order to help avoid classic stack-overflow exposures; but, it obviously has applicability to other environments. (It was also introduced in order to "keep up with the Joneses — er ... I mean the Intels.)
:>>
:>Conversely, there's REFRPROT to prevent storing into programs
:>marked REFR. Dismayingly, I believe REFRPROT is global and
:>intrduces incompatibility with "dusty deck" programs erroneously
:>marked REFR.

That is a good thing. However, RENT alone does not (conceptually) require a
module to be refreshable.

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://secure-web.cisco.com/19AoSGhGCR9I2eaAlvNQjDjrGeYVI8ZnwKDIRJFUw1x7i6ftx0Yb12NJmP5eT2Te_OX9fUfESQIxioFXHlvBsg8Owy9vbkR7RMoW26HYBeIGic1jYsKU8DRLF1OFfdQp_zEwAACiSd1uyXFy2uOG9rHoc243dXs2vrw5CdrmeBK5ulvS-2te48-y_edoYLr3akyrUOeZfuRgv8iccGgnCCD68J9NzHpL9coOltM4z494TX4ENW-p0LE2xuah-y6czQqH9_IksxhmxpkRUHcvsmdYXixdWX3emhB_En5iHoPNdxlmOUzkooWN42sNutD_hXn6w30x70WPkGYBbSPqXh2vyR0aLfO5pyVR2erbVJ0Os_MZNbfGaapiimpq_js5F_Pb2xpAAYm86DXgBjXlX3CyoM5UEyGVEVWmZbTtIxsftsvuESs_jUryrMu8P_RH5/http%3A%2F%2Fwww.dissensoftware.com

[Seymour J Metz]

Both the LE CAA and the COBOL working storage reside in dynamically acquired storage; it doesn't matter whether that's GETMAIN or STORAGE OBTAIN.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Farley, Peter x23353 <00000dc9d8785c2...@LISTSERV.UGA.EDU>
Sent: Monday, November 16, 2020 4:45 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS

[Seymour J Metz]

It's a security exposure in C that is alleviated by putting the stack and heap in nonexecutable storage.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Tony Harminc <to...@HARMINC.COM>
Sent: Monday, November 16, 2020 4:37 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS

On Mon, 16 Nov 2020 at 12:24, Ze'ev Atlas

[ste...@copper.net]

How is this a security exposure for c but not ALC?

I’m not a c programmer. Nor do I program with Java.

I would like to understand this.

Regards,
Steve Thompson

--- sme...@GMU.EDU wrote:

[Farley, Peter x23353]

Because most hackers who want to insert malicious code into a web page don’t know mainframe object code but do know how to insert arbitrary Intel object code and java byte code and SQL to achieve their ends.

Maybe also because there are probably very few mainframe ALC programs that are directly interfacing with web pages or the internet in general.

State-sponsored bad actors are a different animal, they very well may know mainframe object code (after all, US "intelligence" organizations certainly do), but again how many ALC programs are directly connected to the net? Probably much more COBOL these days, and even then through middleware like CICS.

One can, of course, write insecure network code in ALC as in any other language, but the preponderance of network-connected code isn't written in ALC, and the IBM mainframe object code architecture isn’t very widely known in the hacker community compared to the Intel or ARM architectures.

Peter

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of ste...@copper.net
Sent: Tuesday, November 17, 2020 10:40 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS

How is this a security exposure for c but not ALC?

I’m not a c programmer. Nor do I program with Java.

I would like to understand this.

Regards,
Steve Thompson

--- sme...@GMU.EDU wrote:

From: Seymour J Metz <sme...@GMU.EDU>
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS
Date: Tue, 17 Nov 2020 14:28:31 +0000

It's a security exposure in C that is alleviated by putting the stack and heap in nonexecutable storage.


--

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.

[Binyamin Dissen]

On Tue, 17 Nov 2020 13:58:23 +0000 Seymour J Metz <sme...@GMU.EDU> wrote:

:>Indeed, OS/360 had some code that was reentrant but not refreshable; AFAIK IBM has cleaned up all such abominations, and the binder does not allow you to create a load module or program object marked as reentrant but not refreshaable.

You are asserting that RENT now forces REFR?

:>________________________________________

:>From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Binyamin Dissen <bdi...@DISSENSOFTWARE.COM>
:>Sent: Tuesday, November 17, 2020 2:35 AM
:>To: ASSEMBL...@LISTSERV.UGA.EDU
:>Subject: Re: security with storage allocation under z.OS
:>
:>On Mon, 16 Nov 2020 18:35:29 -0700 Paul Gilmartin
:><00000014e0e4a59...@LISTSERV.UGA.EDU> wrote:
:>
:>:>On 2020-11-16, at 17:47:10, Dan Greiner wrote:
:>:>> ...
:>:>> So, the facility only applies to virtual addresses on newer models. As I recall, the development of this facility was requested by z/Linux in order to help avoid classic stack-overflow exposures; but, it obviously has applicability to other environments. (It was also introduced in order to "keep up with the Joneses — er ... I mean the Intels.)
:>:>>
:>:>Conversely, there's REFRPROT to prevent storing into programs
:>:>marked REFR. Dismayingly, I believe REFRPROT is global and
:>:>intrduces incompatibility with "dusty deck" programs erroneously
:>:>marked REFR.
:>
:>That is a good thing. However, RENT alone does not (conceptually) require a
:>module to be refreshable.

--
Binyamin Dissen <bdi...@dissensoftware.com>

http://www.dissensoftware.com

[Seymour J Metz]

Sorry, it's the other way around: 'The linkage editor processed the serially reusable (REUS), reenterable (RENT) and refreshable (REFR)attributes as separate and independent options. The binder, however, treats them as a single, multivaluedattribute with an implied hierarchical relationship: “refreshable” implies “reenterable” and “reenterable”implies “serially reusable”. '

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Binyamin Dissen <bdi...@DISSENSOFTWARE.COM>

Sent: Tuesday, November 17, 2020 12:21 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: security with storage allocation under z.OS

On Tue, 17 Nov 2020 13:58:23 +0000 Seymour J Metz <sme...@GMU.EDU> wrote:

:>Indeed, OS/360 had some code that was reentrant but not refreshable; AFAIK IBM has cleaned up all such abominations, and the binder does not allow you to create a load module or program object marked as reentrant but not refreshaable.

You are asserting that RENT now forces REFR?

:>________________________________________
:>From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Binyamin Dissen <bdi...@DISSENSOFTWARE.COM>
:>Sent: Tuesday, November 17, 2020 2:35 AM
:>To: ASSEMBL...@LISTSERV.UGA.EDU
:>Subject: Re: security with storage allocation under z.OS
:>
:>On Mon, 16 Nov 2020 18:35:29 -0700 Paul Gilmartin
:><00000014e0e4a59...@LISTSERV.UGA.EDU> wrote:
:>
:>:>On 2020-11-16, at 17:47:10, Dan Greiner wrote:
:>:>> ...
:>:>> So, the facility only applies to virtual addresses on newer models. As I recall, the development of this facility was requested by z/Linux in order to help avoid classic stack-overflow exposures; but, it obviously has applicability to other environments. (It was also introduced in order to "keep up with the Joneses — er ... I mean the Intels.)
:>:>>
:>:>Conversely, there's REFRPROT to prevent storing into programs
:>:>marked REFR. Dismayingly, I believe REFRPROT is global and
:>:>intrduces incompatibility with "dusty deck" programs erroneously
:>:>marked REFR.
:>
:>That is a good thing. However, RENT alone does not (conceptually) require a
:>module to be refreshable.

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://secure-web.cisco.com/1ccD7tACnViQKA_YiWQTyoTavbBUcZIKMXyJQ8coFcHPQjZWuV7kPYC8eivosXPHEcYj6g2qxcV8y77C3Buo6t5ADfmXm1mD5lqMnb9Y_g0ij2Kefdeocg6hggmGongeFe0q9IOn8NwwjXRmw9x9KLOPJU8KA0l2mx-e0BoQq-EnUZ5Drd3mJ51WEyIiNEg7XfNRybWNA3YdD4qNAJRV-9ke5FXmSgIhVwmWs4MHHrPJXCYBBK2ppfULJiIbb4D0eEVYq7yE5rCPrkrtqG4B36_fgm__NvG71s7p4yR6NSPVo8MpMHoxySZW7ZpLRhK_WxcKSJ49kXyJmRmjO0bIw0y_OIKSFrDfOjecgi4cvckxun40aOH8PI6cjzSYb_cqiHdENouygBgJrgdn1GYY77pF6EH2rL63tToFvtnS06Co2Ts_1VsgiZS9PhiJRa8uU/http%3A%2F%2Fwww.dissensoftware.com

[Paul Gilmartin]

> On 2020-11-17, at 10:21:10, Binyamin Dissen wrote:

>
> On Tue, 17 Nov 2020 13:58:23 +0000 Seymour J Metz wrote:
>
> :>Indeed, OS/360 had some code that was reentrant but not refreshable; AFAIK IBM has cleaned up all such abominations, and the binder does not allow you to create a load module or program object marked as reentrant but not refreshaable.
>
> You are asserting that RENT now forces REFR?
>

I read the converse. in:
MVS Program Management: User's Guide and Reference
• The linkage editor processed the serially reusable (REUS),
reenterable (RENT) and refreshable (REFR) attributes as

separate and independent options. The binder, however,

treats them as a single, multivalued attribute with an

implied hierarchical relationship: “refreshable” implies
“reenterable” and “reenterable” implies “serially reusable”.

-- gil