On Thu, Jun 6, 2019 at 2:58 PM Ed Jaffe <[email protected]> wrote:

> On 6/5/2019 9:27 AM, John McKown wrote:
> >
> > ...I am now looking at the EXECUTABLE=NO
> > operand of the STORAGE OBTAIN. I already check the z/OS level "02.02.00"
> or
> > greater to dual path my assembly code. But I have also read that although
> > z/OS 2.3 will accept this operand, on anything less than a z14, it is
> > ignored. So I am trying to make sure that the person assembling the code
> is
> > targeting a z14 or above.
>
> Why? Who cares what kind of machine you're running on? If it's an older
> machine, you just get the old behavior because the new behavior doesn't
> exist. On a new machine, you get the new behavior (non-executable
> storage). Either way, it's all good...
>

Just me, just learning new stuff. This is not for some product or anything
else. Just stretching the wings. And I've now come to some conclusions
about this sort of things.



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


-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


Maranatha! <><
John McKown

Reply via email to