[Consolidating several responses]
On 12/29/2011 6:57 AM, Peter Relson wrote:
<<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 <== privileged
(thanks to Peter Relson for pointing that out, below)
MSTA - Modify stacked STAte
SSAR - Set Secondary ASN
SSAIR - Set Secondary ASN with Instance
STRAG - Store Real Address p
TAR - Test Access p <== not privileged
(thanks to Allen Gainsford for pointing that out to me)
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.
[I added TRAP2 and TRAP4 after Martin Truebner pointed out the
omission]
I have noted a couple of omissions in the PoPs that I will submit
a Readers Comment for; but there also needs to be a place in each
operating system's pub set where it specifies what semiprivileged
instructions are available under that system. Not sure where that
would be for z/OS, but I'll give it some thought.
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
Thanks for that, Peter.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
