If a field in a control block is marked as being a programming interface, it does not matter what language is used to reference it and REXX "STORAGE" is just as valid as assembler "MVC" .
What is being pointed out is that a REXX exec that uses "STORAGE" to access reverse-engineered or non-programming interface fields of control blocks is liable to break in some fashion in future releases or maintenance levels. IPLINFO is just a REXX exec and it executes in problem state. CSVAPF is the interface to retrieve the APF list in the same way that UCBSCAN is the interface to retrieve UCB info. Are there OCO control blocks that you can access in memory to "bypass" the supported interface? Yes. Is this a good idea - I would suggest not. As stated before, my advice would be to convert the REXX usage of such non-GUPI fields to use some sort of external function that uses supported interfaces and returns the information using IRXEXCOM. Rob -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Wednesday, May 9, 2018 3:58 PM To: [email protected] Subject: Re: AC(1) On Wed, 9 May 2018 06:23:42 -0500, Steve Horein wrote: >On Fri, May 4, 2018 at 6:33 AM, Peter Relson wrote: >> <snip> >> I believe you. The code that was shown was assembler. Regardless, >> being an exec still means that the choice was made not to use an >> intended programming interface. >> </snip> > >If a data area is described with "Programming Interface Information" >and then referenced via Rexx STORAGE calls, is that considered a choice >to not use an intended programming interface? > ... MVC is "an intended programming interface". A carelessly authorized program can do a lot of damage with MVC. >I am an automation administrator with regrettably zero assembler >programming skills, and tend to use such Rexx calls to alleviate the >painful process of MVS command output parsing to get information, if >available, when I can. > Might one use fork() (BPX1FRK, SYSCALL fork, ...) to run unvetted Rexx code such as IPLINFO safely unauthorized in a separate address space, returning results via a pipe or socket to an authorized caller? (Is IPLINFO free of the constraints of TSO?) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
