Re: LOC=64 executable code?

I suspect the target of an execute is treated like a branch, but the Redbook seems to be silent on the subject. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ngan, Robert Sent: Friday, July 28, 2017 2:29 PM To:

Re: LOC=64 executable code?

On 7/28/2017 2:29 PM, Ngan, Robert wrote: There were severe restrictions on LOC=64 code before (mainly, must be non-interruptible) Those restrictions were lifted six years ago beginning with z/OS 1.13. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo,

Re: LOC=64 executable code?

Yes, I saw the IEP feature on the z14 announcement. There were severe restrictions on LOC=64 code before (mainly, must be non-interruptible) so since they added EXECUTABLE= to the LOC=64 allocation logic, I figured they might have eased up on what kind of code was allowed above the bar. So...

Re: LOC=64 executable code?

In other words, EXECUTABLE=YES is not some new RMODE=64 feature. EXECUTABLE=NO is a new security feature. It is a guard against buffer overflow type vulnerabilities in which a bad guy sends you some message (like a Web URL) that is actually machine instructions and also manages to overlay code

Re: LOC=64 executable code?

>Date:Fri, 28 Jul 2017 00:14:46 + >From:"Ngan, Robert" >Subject: LOC=64 executable code? >Just noticed that the z/OS 2.3 manuals mention EXECUTABLE=YES|NO parameter for >IARV64 GETSTOR requests. >Anyone have a summary of what kinds of code we can move above the bar in

LOC=64 executable code?

>>Anyone have a summary of what kinds of code we can move above the bar in z/OS 2.3? and >You can move code that invokes no services or invokes only services that >support RMODE(64) execution. And that has basically been true since z/OS 1.13 via LOAD with ADDR64 What is available in z/OS 2.3