No. On Fri, Jun 11, 2021 at 4:36 PM MELVYN MALTZ < [email protected]> wrote:
> 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. >
