Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!newstop!sun!quintus!jbeard
From: jbeard@quintus.UUCP (Jeff Beard)
Newsgroups: comp.lang.asm370
Subject: Re: SVC 202 under CMS
Message-ID: <1222@quintus.UUCP>
Date: 26 Jul 89 22:30:36 GMT
References: <6214@rpi.edu>
Reply-To: jbeard@quintus.UUCP (Jeff Beard)
Distribution: usa
Organization: Quintus Computer Systems, Inc: Mountain View, Ca
Lines: 39

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.