Forgive me for belaboring this but you have gotten me thinking. If you can come up with an example of OPEN MF=E/L coding, no matter how contrived and obscure, that will - Let you store data into the MVS supervisor or an MVS control block (despite your being KEY=8) - Let you store data into some other address space to which you do not have permitted access - Let you open a dataset that you do not have permission to open, perhaps no permission to open in the mode you are opening it - Elevate your permissions in some other way
then IBM will and should be very, very interested. That is the point of the Statement of Integrity. Otherwise ... well, I said it twice already: your gun, ... It's pretty trivial to come up with examples of assembler code that blow up. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Charles Mills Sent: Friday, June 11, 2021 4:22 PM To: [email protected] Subject: Re: A problem with OPEN and CLOSE macros OK, I kind of get your point. The OPEN will store the new R5 into the executed MVC, which will cause it to move 256 bytes, regardless of the value in R2. But so what? I can write examples of assembler code all day that will work very, very badly. (Sometimes I even do it unintentionally.) Your gun, your bullet, your foot. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Charles Mills Sent: Friday, June 11, 2021 3:53 PM To: [email protected] Subject: Re: A problem with OPEN and CLOSE macros I think one of the features (ha!) of assembler is your gun, your bullet, your foot. A store instruction (ST) into a halfword will probably cause storage corruption, with probably unhappy results. There might be a halfword of slack after the halfword in some cases, and then some unrelated change might eliminate that slack. Ka-boom! It is just a feature (ha!) of all of the older MF=E/L macros that a mismatch causes the famous unpredictable results. Mark Nelson is not your guy for this, unless you think there is an integrity issue. I don't know who would be your guy. I think IBM's attitude toward enhancements of basic DFSMS is pretty much "if it ain't broke ..." I am trying to make sense out of your example. What is L R5,EXMVC supposed to accomplish? The L/OI is going to put D2FFxyyy into R5, right (where x is your base register and yyy is unpredictable)? The most likely result IMHO is a S0C4 on the OPEN, never mind any other side effects. I don't really "get" your example at all. Where do HERE and THERE come into it? What AMODE is the example supposed to execute in? Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of MELVYN MALTZ Sent: Friday, June 11, 2021 1:36 PM To: [email protected] Subject: A problem with OPEN and CLOSE macros 1) An OPEN/CLOSE with MF=L,MODE=24 can be overlayed with an MF=E,MODE=31 (and vice-versa). This results in destruction of the list, abends would occur 2) An OPEN/CLOSE with MF=L with (say) 2 entries can be overlayed with an MF=E with 3 entries. The end-of-list bit isn't touched, but a storage violation occurs It is true that the "DFSMS Macro Instructions for Data Sets" does warn against mixed mode and MF=L/E length differences with the usual 'unpredictable results may occur' The first problem doesn't worry me, but the second one does, look at this cut-down code...no apologies for it being contrived...if I wanted to hide it, I could do... LA 2,8-1 EX R2,EXMVC L R5,EXMVC OILF R5,X'00FF0000' OPEN (DCB2,OUTPUT,(R5)),MF=(E,HERE24O),MODE=24 EX R2,EXMVC ... HERE DC 8C'A' THERE DC 8C'B' * DCB1 DCB ... DCB2 DCB ... * HERE24O OPEN (DCB1,INPUT),MF=L EXMVC MVC THERE(0),HERE Using OPEN/CLOSE to subvert code sends this into another dimension I've been exchanging Emails with Mark Nelson (RACF Development) about this and have offered a solution, I can quite understand why IBM aren't keen on it 1) The OPEN/CLOSE list structure must change The 'new' structure needs an 8-byte header eg. DC C'OPCL' eyecatcher DC X'mode bit' DC XL3'no. of entries' 2) The OPEN/CLOSE SVC processors must be able to detect the 'old' and 'new' formats in order not to disturb existing code 3) OPEN/CLOSE MF=E will have extra coding for the 'new' format only, to detect both mode and storage violation errors...setting an error code Whether this is worth doing is largely up to the user community, I would be worried if an innocent looking macro could subvert program code Your thoughts ? Melvyn Maltz.
