<<responding both to assembler-list and ibm-main>>
>BSG - Branch in Subspace Group
>EREG - Extract stacked REGisters (32 bits)
>EREGG - Extract stacked REGisters Grande (64-bits)
>ESTA - Extract stacked STAte
>LPTEA - Load Page Table Entry Address
>MSTA - Modify stacked STAte
>SSAR - Set Secondary ASN
>SSAIR - Set Secondary ASN with Instance
>STRAG - Store Real Address p
>TAR - Test Access p
>TPROT - Test PROTection p
> ('interesting' in the sense they are not
> semiprivileged and the first eight are
> not privileged either, but they are
> described in the chapter on Control
> Instructions: so are they 'general'
> instructions? I think not, but it's hard
> to say.)
>My focus: are these first eight instructions useful
>for applications programmers?
BAKR, PR, EREG, EREGG are all part of the original linkage standard for
AR-mode routines, providing a way to preserve the ARs (and GR high halves)
without having to change the caller to provide a large enough save area to
hold everything. AR mode is fully available to applications programmers.
ESTA and MSTA are of primary use to PC target routines so would not be
used by writers of *unauthorized* applications.
The statement that "the first eight are not privileged" seems incorrect.
LPTEA is a privileged operation.
SSAR and SSAIR will not be used by an unauthorized application (they may
be issued but would only be in the "current primary" state rather than
"space switch"). SSAR/SSAIR for space switch are semiprivileged. You would
see these in macro expansions of services entered by non-stacking PC's.
Most applications would not care much about using BSG (this was created to
help cases such as CICS to isolate its transactions from each other).
If you think it important to document which semi-privileged instructions
are available to problem state applications, please submit a readers
comment form asking that this be done. It seems reasonable. It appears at
a glance that all of the semiprivileged instructions in table 5-6 on page
5-28 of PoOp are available, subject to such things as "need a suitable PSW
key mask" and "not requesting space switch". z/OS does set, for example,
CR0 bit 36 which authorizes various instructions.
z/OS itself does not provide support for TRAP2/TRAP4. But some
(authorized) program products do this on their own (a bad decision not to
have this provided by the operating system). They got burned when the
architecture changed incompatibly (incompatible changes in the
architecture are almost never done to problem state programs, but such
changes are something that "we" in the base control program expect to take
care of when they occur). The long and short of it is that you can't use
TRAP2/TRAP4 "on your own" if you are not privileged.
Peter Relson
z/OS Core Technology Design
