On 08/07/2018 04:37 PM, Dan Greiner wrote:
Steve Thompson wrote:
BTW, there are a few instructions on IBM systems that are not
documented. One of those is, SIGH (ok, SIE :) ). You can't SIE an
SIE either (this is part of the Interpretive Execution Facility).
Actually, the original SIE was documented in "IBM System/370 Extended Architecture —
Interpretive Execution" (SA22-7095-00). You can find it at
http://bitsavers.org/pdf/ibm/370/princOps/SA22-7095-0_370-XA_Interpretive_Execution_Jan84.pdf.
The storage operand of the SIE instruction is the state-description block (SDB), the
original format of which (described in SA22-7095) is no longer supported. Alas, the
documentation of current versions of the SDB are not publicly available.
However, various customers made use of the original-recipe SIE. As I recall,
Stanford Linear Accelerator Center (SLAC) made use of SIE to dispatch a Wylbur
guest (thus isolating the rest of the OS from Wylbur's proclivity to wildly
branch while in supervisor state).
Since the operand of the SIE instruction is not another instruction, I'm not sure what
you mean by "You can't SIE an SIE either ..." The SIE firmware certainly allows
multiple levels of interpretive execution: PR/SM issues SIE to dispatch a logical
partition (a 1st-level guest), and zVM running in a partition issues SIE to dispatch a
virtual-machine guest (a 2nd-level guest). Conceivably — given a really smart VM guest,
and access to the current SIE doc — you could dispatch additional levels of guest
configurations.
Yeah, I knew most of that at one time. But I also knew that SIE
stopped being documented, I think with XA. I know the version of
it prior to ESA was not documented, because of TIDA at AMDAHL.
The persons that handled SIE for AMDAHL told me that SIE can't be
used to dispatch a second level VM machine.
The "EXCEPTION" to that appeared to be with PR/SM which
originally was VM under the covers -- as it was explained to us
by customers -- OK, we could read the console and we recognized
the message prefixes as well.
So I have understood that SIE can't dispatch SIE. But hey, I
haven't had the opportunity to work at that level since the
AMDAHL bean counter layoff of 1989.
And the wild branch in Wylbur (well some wild branch) I finally
fixed when I took ACS/OBS WYLBUR to source maintenance and SMP/E
install. To get all this to work, I had to overhaul the JES2 SRB
mode code so that the users would assemble a module that WYLBUR
would load and then have all the displacements that matched the
JES2 they were running. So we ran that level of WYLBUR in house
for two years as I hammered out various things in getting the
components correctly defined in SMPE so that, IIRC, you could
chose JES2 SRB, or JES2 SSI or JES3 SSI for spool access -- they
were mutually exclusive. Then ACF2, or RACF, or Top Secret, or
WACF (Wylbur Access Control Feature IIRC that name) were all
mutually exclusive. And there were a few other components but I
can't remember them.
At any rate, George Coldren and I chased that wild branch through
the code and we just couldn't pin it down to *the* cause. Even
with XDC, we couldn't recreate it at will, so we could never find
it.
Once the SMPE version of ACS/WYLBUR shipped (9.5, I've forgotten
the FUNCTION ID), the number of outstanding problems we had
dropped from 400+ to less than 25.
Wish I could find someone with the source for that. I don't think
it would take me much more than a year to have it running in z/OS
-- Assuming I could work on it full time :)
Regards,
Steve Thompson
