[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
