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.
