🚀 go-pugleaf

SVC 202 is NOT your only problem!  EVERY SVC is exposed to this issue.
Recall that the 370 memory is monolithic ( ie unclassified as to data vs. code).
While some systems segregate instruction space from data space (typically
stack architecures like Tandem, DecVax...), the 370 does not.
This leads to the necessity of fetching and decoding the op-code at the current
instruction counter(IC) location, and if not sucessfull, program check
interrupt 01 occurs.

This allows such weird sequences as

        op1,br->op2,data1,op2,br->op3,data2,op3,....

which occurs with many assembler macro expansions!  The MF={E,L} ensures
that this does not occure, specifying the data for the code to be
at the MF=L invocation and only code at the MF=E invocation.  BUT THIS IS
NOT THE DEFAULT!  Unless specifically concerned with multi-threading or
reentrantcy, most if not all 370 coders will use the default and allow
macros to expand as in

        open dcb,input
+       la      r1,dcb
+       o       r1,=xl8'80000000'
+       st      r1,&sysindx
+       la      r1,&sysindx
+       svc     13
+       b       &sysindex+4
+&sysindx ds    f
+
(don't flame if the above is not precisely the expansion ... it's been a
long time and  the conecpt is the issue anyway).

The parameter to open is R1, pointing to a data area in the instruction steam
which MUST be bypassed with the Branch.

The case you site (SVC 202, and by the way 203) is unique to VM, in that
the data area follows immediately after the SVC, which requires the functional
code to return R14+6 for the normal case return or indirectly for errors
via `L R14,2(,R14), BR R14'.  SVC 203 uses the following (?? halfword) data
as input to the function.