Updated and improved ECPS:VM support

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Updated and improved ECPS:VM support

Hercules390 - Vm mailing list

 
 Hey VMers.....
 
 
 
 ECPS:VM is back!
 
 
 
 Extended Control Program Support is a suite of assists that help VM perform better.  ECPS:VM has long been a part of the Hercules emulator.  Over the past few months I have fixed a number of bugs which greatly improve its reliability and added a number of new assists that had not been previously implemented in the original version.
 
 
 
 Many of you may have tried using the existing ECPS:VM support within the Hercules emulator at one time or another, and probably ended up turning it off if it seemed like things might not be working properly.  For too many years the recommendation was to turn it off if you experienced quirky behavior.  No more.
 
 
 
 The updated ECPS:VM support is reliable and makes a remarkable improvement in performance.  It is particularly beneficial if you are running a guest operating system under VM.  New assists were added to help CP with shadow table maintenance and channel program translation, as well as new instruction assists to speed up the simulation of certain privileged instructions.  At least a dozen bugs have been identified and fixed in the original support and many of those bugs were impacting guests.  In total, 4 new instruction assists and 9 new CP assists were added.
 
 
 
 More information about the new ECPS:VM support is available in the README.ECPSVM file, here:
 
 
 
 https://github.com/hercules-390/hyperion/blob/master/README.ECPSVM
 
 
 
 The new ECPS:VM support is part of the Hyperion master.  For those that are adept at compiling and building their own copy of the emulator, you need only rebuild to obtain the support.  Windows users can also choose to download the pre-built binaries from Fish's website:
 
 
 
 http://www.softdevlabs.com/hyperion.html
 
 
 
 When the next update of TK4- is released, it will ship with prebuilt binaries for several different platforms that will include the new ECPS:VM support.  For those using the Hercules 3.xx versions, those versions are stabilized and it is unlikely that the ECPS updates will make it into version 3.
 
 
 
 ECPS:VM is for those running VM/370 or VM/SP.  No changes to CP are required in order to use ECPS:VM.  Once you have updated emulator binaries, you only need place a "ECPSVM  YES" statement in the Hercules configuration file that you use to start VM.  
 
 
 
 Regards,
 
 Bob
 

 
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
On 12 June 2017 at 11:42, [hidden email] wrote:

> ECPS:VM is back!
>
Great news!

> next update of TK4- is released, it will ship with prebuilt binaries for
> several different platforms that will include the new ECPS:VM support.  For
> those using the Hercules 3.xx versions, those versions are stabilized and
> it is unlikely that the ECPS updates will make it into version 3.
>

It strikes me that this is also the place to deal with the (minor but
philosophically annoying) presence and incorrect behaviour of the EPSW
instruction that has been back-ported into S/370 on TK4-. Given that EPSW
is not present in any real S/370 instruction set, and gives wrong answers
only when running under a non-SIE type VM, it would seem reasonable to me
to provide the following behaviour:

If the CP (and VM) assists are not in use (determined by the settings of
CR6, I imagine), then treat EPSW as the unprivileged instruction it is on
S/390, i.e. it returns the real PSW from any state. If the assists are in
use, and EPSW is issued in real problem state, then send it off to ECPS for
handling. This would of course require that ECPS:VM be able to find and
return/calculate the virtual PSW, but this is surely trivial given what
else the assists know about the VMBLOK etc.

This suggestion may seem architecturally dodgy, but given that these
assists are not merely a handful of additional instructions, but rather
change the behaviour of a number of things, I don't think it's unreasonable.

Tony H.
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
Hi Tony,
 
 This is an interesting idea and being very familiar now with the ECPS code in Hercules it would be almost trivial to implement.  The ECPS code has access to the virtual PSW and it would be simple to return that value when ECPS is active and the real machine is in problem state and when CR6 allows it.
 
 But up to this point, all of the supported functions in ECPS:VM as implemented in Hercules are per the IBM specification to the best of my knowledge and given the limited documentation still available.  Altering the behavior of EPSW would be non-standard behavior and something ECPS never did.  There are strong opinions in the Hercules user community regarding non-standard behavior.  As you may recall, within the last year in the main Hercules group there was a lengthy thread of well over 100 posts on both sides of the argument of whether to allow S/390 and Z instructions to execute in S/370 mode.
 
 The behavior of EPSW in a VM/370 virtual machine can be viewed much the same way as the execution of the STCK instruction, where VM/370 documentation states that STCK cannot be virtualized because it is a non-privileged instruction (or words to that effect).  You could argue that EPSW should not now be virtualized for the same reason.
 
 For myself, I tend to be someone who would rather have access to all of the instructions that are available in the emulator, where appropriate, even if they did not exist on real S/370 hardware at the time.  If it makes a programming task easier, I want to be able to use it and I am fully aware of the risks and limitations of using a S/390 instruction in S/370 mode, for example.  And I generally do not want someone else to tell me that I can't, that is, to decide for me because it is not pure.
 
 To accommodate both sides, if the EPSW assist function were to be implemented there may need to be a configuration option to allow for those who want it virtualized and those who do not.
 
 On the other hand, I doubt that many are issuing EPSW instructions in a S/370 mode virtual machine.  I'd like to hear from the users if they would like to see EPSW virtualized or not.
 
 Regards,
 Bob
 
---In [hidden email], <tharminc@...> wrote :


 On 12 June 2017 at 11:42, wably@... mailto:wably@... wrote:
 ECPS:VM is back!
 Great news!  

 next update of TK4- is released, it will ship with prebuilt binaries for several different platforms that will include the new ECPS:VM support.  For those using the Hercules 3.xx versions, those versions are stabilized and it is unlikely that the ECPS updates will make it into version 3.



 It strikes me that this is also the place to deal with the (minor but philosophically annoying) presence and incorrect behaviour of the EPSW instruction that has been back-ported into S/370 on TK4-. Given that EPSW is not present in any real S/370 instruction set, and gives wrong answers only when running under a non-SIE type VM, it would seem reasonable to me to provide the following behaviour:


 If the CP (and VM) assists are not in use (determined by the settings of CR6, I imagine), then treat EPSW as the unprivileged instruction it is on S/390, i.e. it returns the real PSW from any state. If the assists are in use, and EPSW is issued in real problem state, then send it off to ECPS for handling. This would of course require that ECPS:VM be able to find and return/calculate the virtual PSW, but this is surely trivial given what else the assists know about the VMBLOK etc.


 This suggestion may seem architecturally dodgy, but given that these assists are not merely a handful of additional instructions, but rather change the behaviour of a number of things, I don't think it's unreasonable.

 
Tony H.


 

Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
On 12 June 2017 at 18:25, [hidden email] wrote:

> But up to this point, all of the supported functions in ECPS:VM as
> implemented in Hercules are per the IBM specification to the best of my
> knowledge and given the limited documentation still available.  Altering
> the behavior of EPSW would be non-standard behavior and something ECPS
> never did.  There are strong opinions in the Hercules user community
> regarding non-standard behavior.  As you may recall, within the last year
> in the main Hercules group there was a lengthy thread of well over 100
> posts on both sides of the argument of whether to allow S/390 and Z
> instructions to execute in S/370 mode.
>

I think the discussion was more about what should in a given "base"
architecture than whether additions done in a modular fashion like s370x
should be allowed at all. It also veered unfortunately into issues of
"Who's in charge here anyway".


> The behavior of EPSW in a VM/370 virtual machine can be viewed much the
> same way as the execution of the STCK instruction, where VM/370
> documentation states that STCK cannot be virtualized because it is a
> non-privileged instruction (or words to that effect).  You could argue
> that EPSW should not now be virtualized for the same reason.
>

I would argue it this way:

If you are a purist/historian, then you won't install the s370x module, and
you won't have any instructions that don't match the architecture you've
chosen. Easy.

If you are an experimentalist, and go with s370x, then EPSW will give
results consistent with those on ESA/3x0 under all circumstances except
when you are running in a VM/370-style virtual machine. In that case it is
guaranteed to always give an incorrect result.

If you configure ECPS then, by definition you are running VM/370, *and* are
willing to have some facilities on your machine that are not described in
any Principles of Operation.

I think the analogy to STCK in a virtual machine is weak, mostly because
while STCK existed ab initio on S/370 (and therefore VM/370), EPSW did not
exist in S/370 for the exact reason that it or any similar instruction
would give incorrect results; indeed I remember this being discussed at
SHARE. Back-porting it in s370x is not like other modern innocuous features
such as the relative branch or long displacement instructions. EPSW could
have been added to ECPS way back when, but as Lynne Wheeler has oft pointed
out, the microcode space was very limited, and every byte had to provide
performance improvement rather than nifty "would be nice" features.

While I agree that probably no one much is using it, I suggest that it
would be architecturally and practically reasonable to include the
virtualized behaviour if EPSW is present (which requires explicit use of
s370x), and if ECPS is active (which requires configuring both Hercules and
VM/370).

[In passing, does ECPS provide for virtualization of STCK in a virtual
machine? I think not, but maybe that slipped by me at some point.]

Tony H.
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
Tony,
 
 As usual you make an excellent argument.  I have no problem adding this in a future update.
 
 [In passing, does ECPS provide for virtualization of STCK in a virtual machine? I think not, but maybe that slipped by me at some point.]
 
 ECPS does not provide for virtualization of STCK although it does attempt to virtualize the interval timer.  This is the same as the IBM specification.  Hercules ECPS could most certainly be modified to virtualize STCK but this change would not be a trivial effort.  Further, it probably would  require a CP modification in order to provide storage in the VMBLOK or MICBLOK in which to store the value of the virtual user's TOD clock.  There may be other modifications required  as well (the dispatcher seems likely).  At present none of the ECPS supported features require a CP modification beyond those already provided by IBM in VM/370 Release 6 plus PTFs.
 
 Regards,
 Bob
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list


On 6/12/2017 10:30 PM, Tony Harminc [hidden email] [H390-VM] wrote:
> It strikes me that this is also the place to deal with the (minor but
> philosophically annoying) presence and incorrect behaviour of the EPSW
> instruction that has been back-ported into S/370 on TK4-. Given that
> EPSW is not present in any real S/370 instruction set, and gives wrong
> answers only when running under a non-SIE type VM, it would seem
> reasonable to me to provide the following behaviour:

Tony,

That's purely and simply a bug. EPSW should never have made it into the
s370x module.

EPSW is a virtualization breaker in S/370 mode - that is - it is
revealing real state machine information while being unprivileged.

My bad...

--Ivan

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
Hi Ivan
It's not your bad... it's mine, because I did it a year ago, and only in the TK4- variety of Hercules. I didn't commit any of the s37x changes I made for TK4- to Hyperion, so, at least in that respect, Hyperion should still be clean...
Cheers
J├╝rgen
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
On Mon, 2017-06-12 at 22:25 +0000, [hidden email] [H390-VM] wrote:

>
>
> Hi Tony,
>
>  
>
> For myself, I tend to be someone who would rather have access to all
> of the instructions that are available in the emulator, where
> appropriate, even if they did not exist on real S/370 hardware at the
> time. If it makes a programming task easier, I want to be able to use
> it and I am fully aware of the risks and limitations of using a S/390
> instruction in S/370 mode, for example.  And I generally do not want
> someone else to tell me that I can't, that is, to decide for me
> because it is not pure.
>
>  
>
> To accommodate both sides, if the EPSW assist function were to be
> implemented there may need to be a configuration option to allow for
> those who want it virtualized and those who do not.
>
I would suggest the configuration option, perhaps related to ECPS, that
would enable this behavior.

Historically, it has been the objective of preserving "pure"
capabilities while enabling additional ones for those who desire them.

The inclusion of many z instructions in ESA/390 mode was the first, to
my knowledge, times this separation was not preserved.
>  
>
> Regards,
>
> Bob


Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list


On 6/13/2017 4:14 PM, Harold Grovesteen [hidden email] [H390-VM]
wrote:
> I would suggest the configuration option, perhaps related to ECPS, that
> would enable this behavior.
>
> Historically, it has been the objective of preserving "pure"
> capabilities while enabling additional ones for those who desire them.
>
> The inclusion of many z instructions in ESA/390 mode was the first, to
> my knowledge, times this separation was not preserved.
>
Harold,

I am not sure what you mean by "historically" and "pure".

Hercules has, from its early stages, included facilities that are not
described in the Principle of Operations and even facilities that have
never been implemented on an IBM implementation.

The only red line was always : Any implemented feature (even if it's a
hercules only feature) should NOT break the "principle of operations".

Note that on some IBM implementations, a LOT of z only instructions are
implemented in ESA/390 mode (even some that are not marked N3).

--Ivan


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
On 13 June 2017 at 11:34, Ivan Warren [hidden email] wrote:
> Hercules has, from its early stages, included facilities that are not
> described in the Principle of Operations and even facilities that have never
> been implemented on an IBM implementation.

Can you give an example or two?

> The only red line was always : Any implemented feature (even if it's a
> hercules only feature) should NOT break the "principle of operations".

Such a "harmless" back-porting as that of the Relative and Immediate
instructions to S/370 categorically breaks the S/370 Principles of
Operation. On an S/370 machine, opcodes 84 (WRD) and 85 (RDD) must
either work or produce an Operation or Privop exception. Executing
instead BRXH and BRXLE is a violation. It is certainly open to the
Hercules "model" of S/370 to not implement the Direct Control feature,
but it is not an S/370 if it implements instructions from some other
architecture for those opcodes instead.

But no one is complaining about this. Why? Because no one really ever
used WRD/RDD to speak of (well, I actually executed them and verified
with a scope that they worked as documented on the /165, and they were
used on the 65MP, but realistically...) and the Relative and Immediate
instructions are just so innocuous and useful that, well who can
complain.

But the red line has been crossed.

> Note that on some IBM implementations, a LOT of z only instructions are
> implemented in ESA/390 mode (even some that are not marked N3).

I don't know what N3 is. But yes, many zArch instructions were back
ported to the last few ESA/390 machines.

So to the notion of the s370x feature. I see nothing at all wrong with
allowing all kinds of stuff to be implemented this way. Surely this is
exactly the way to keep the purists and the experimentalists both
happy. No purist has to configure s370x, and as long as they don't,
they should get a S/370 PofO compliant machine. Those who want more
can use s370x, or of course write and install their own additions.
Whether ECPS and such go into s370x or into some separate module, well
I don't have a strong opinion. But an exhanced EPSW seems to me like a
perfect addition to ECPS.

Tony H.

Tony H.
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list


On 06/13/2017 07:10 PM, Tony Harminc [hidden email] [H390-VM] wrote:

> I don't know what N3 is. But yes, many zArch instructions were back
> ported to the last few ESA/390 machines.

And they are documented in the last edition of the ESA PoO.  And also
marked as the N3 facility in appendix B of that manual.

That manual also defines what is available in SIE for an ESA virtual
machine on z hardware, even z13.

Ivan is hinting that there are more instructions available in SIE ESA
than the N3 instructions.

Please, Ivan, which instructions on what hardware?  Chapter and verse,
as you demand of the rest of us.

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list


On 6/13/2017 7:10 PM, Tony Harminc [hidden email] [H390-VM] wrote:
> On 13 June 2017 at 11:34, Ivan Warren [hidden email] wrote:
>> Hercules has, from its early stages, included facilities that are not
>> described in the Principle of Operations and even facilities that have never
>> been implemented on an IBM implementation.
> Can you give an example or two?
Fancy VM diag emulation... (for S/370), SIE (not described in PoP)...

>
>> The only red line was always : Any implemented feature (even if it's a
>> hercules only feature) should NOT break the "principle of operations".
> Such a "harmless" back-porting as that of the Relative and Immediate
> instructions to S/370 categorically breaks the S/370 Principles of
> Operation. On an S/370 machine, opcodes 84 (WRD) and 85 (RDD) must
> either work or produce an Operation or Privop exception. Executing
> instead BRXH and BRXLE is a violation. It is certainly open to the
> Hercules "model" of S/370 to not implement the Direct Control feature,
> but it is not an S/370 if it implements instructions from some other
> architecture for those opcodes instead.
>
> But no one is complaining about this. Why? Because no one really ever
> used WRD/RDD to speak of (well, I actually executed them and verified
> with a scope that they worked as documented on the /165, and they were
> used on the 65MP, but realistically...) and the Relative and Immediate
> instructions are just so innocuous and useful that, well who can
> complain.
>
> But the red line has been crossed.

You are correct... I never noticed the overlap of opcodes there. But yes
- the line is crossed there (maybe a footnote somewhere should be put
forth).

>
>> Note that on some IBM implementations, a LOT of z only instructions are
>> implemented in ESA/390 mode (even some that are not marked N3).
> I don't know what N3 is. But yes, many zArch instructions were back
> ported to the last few ESA/390 machines.

The "N3" instructions are those instructions marked with note "N3" in
the z/Arch list of instruction which *MUST* be implemented when the
machine is running in ESA/390 mode.
See Appendix B in SA22-7832 :

N3 : Instruction is new in z/Architecture and has been added to ESA/390.

>
> So to the notion of the s370x feature. I see nothing at all wrong with
> allowing all kinds of stuff to be implemented this way. Surely this is
> exactly the way to keep the purists and the experimentalists both
> happy. No purist has to configure s370x, and as long as they don't,
> they should get a S/370 PofO compliant machine.
The only thing I see which is *NOT* S/370 compliant, is the RDD/WRD
overlap... otherwise, it's still a PoP compliant implementation.
>   Those who want more
> can use s370x, or of course write and install their own additions.
> Whether ECPS and such go into s370x or into some separate module, well
> I don't have a strong opinion. But an exhanced EPSW seems to me like a
> perfect addition to ECPS.
The issue I see here is that, if that route is taken, then EPSW would
act differently whether ECPS is enabled or not - either by manual
control or via CR6. In essence, whether ECPS VM Assists is enabled or
not should have no operational impact on the virtual machine behavior
(besides performance). I don't think any OS running inside a virtual
machine would be interested with the *actual* PSW (as seen by CP).
> Tony H.
>
>



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list


On 6/13/2017 7:31 PM, 'John P. Hartmann' [hidden email] [H390-VM]
wrote:
> Please, Ivan, which instructions on what hardware? Chapter and verse,
> as you demand of the rest of us.
>
>
John,

By 2nd hand experience (old messages on the old dev mailing list), some
have reported that on some IBM hardware, some instructions not marked as
N3 are available on z machines when they are running in ESA/390 mode.

Again, implementing some z instruction not marked as N3 in ESA/390 mode
does NOT break any PoP rule.

It only breaks the rule if the instruction specifies the machine MUST be
in z/Arch mode for the instruction to work.

--Ivan




smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
If the instruction is marked with a different feature code than N3 (and
*all* z instructions are) *and* that feature is listed as available in z
architecture mode for the equivalent facility bit, then the instruction
must 0c1 under ESA.  I expect your correspondents were speaking through
their hats.

On 06/13/2017 08:10 PM, Ivan Warren [hidden email] [H390-VM] wrote:
> It only breaks the rule if the instruction specifies the machine MUST be
> in z/Arch mode for the instruction to work.
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
Tony,
 
 I'm having second thoughts about using ECPS code to alter the behavior of EPSW in a VM/370 virtual machine.  The reason is that the EPSW would return different results depending on whether ECPS is enabled or not.
 
 One thing ECPS does not do is change the behavior of any instruction it assists vs. the CP simulation of that same instruction.  It's only purpose is to try to do it faster and take some of the burden off of CP.  If anyone finds an assisted instruction that yields a different result then that is a bug in the ECPS code.
 
 At first glance, altering the behavior of EPSW seems fine for a given user since that user chose to load s370x and issue that instruction in any programming he might do.  But what if that user creates an application or tool and then posts it to the H390-VM forum for all to use?  It will give different results or might even fail depending on whether the other recipients are using ECPS:VM or not.   The author of the application should not have to document that everyone must use ECPS:VM (or, must NOT use ECPS:VM) in order to use his program.
 
 (As I am writing this I see that Ivan beat me to it and also pointed out that EPSW would yield differing results with ECPS and without).
 
 Unfortunately, the ECPS code remains the best place to perform this kind of function as I see it.  Other ways that I could think about that might get the job done have other problems, such as altering the behavior for any MVS 3.8J user running native that issues EPSW.   ECPS:VM has the good effect of isolating any behavior modification only to VM.
 
 Regards,
 Bob
 

 

Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list


On 6/13/2017 8:36 PM, 'John P. Hartmann' [hidden email] [H390-VM]
wrote:
> If the instruction is marked with a different feature code than N3 (and
> *all* z instructions are) *and* that feature is listed as available in z
> architecture mode for the equivalent facility bit, then the instruction
> must 0c1 under ESA.  I expect your correspondents were speaking through
> their hats.
>
Where do YOU read this in the z/Arch or ESA/390 Pop ?????

N3 is not a "feature" per se, it is a list of instructions that are new
to z, but that *must* also be implemented in ESA/390.

Nowhere in the PoP does it say that some instructions NOT marked as N3
*cannot* be implemented in ESA/390.

In the latest z/Architecture PoP the *ONLY* instruction that is
guaranteed to throw a PIC 1 is opcode 0x00.

--Ivan


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
On 13 June 2017 at 14:54, [hidden email] wrote:

> I'm having second thoughts about using ECPS code to alter the behavior of
> EPSW in a VM/370 virtual machine.  The reason is that the EPSW would
> return different results depending on whether ECPS is enabled or not.
>

Yup.


> One thing ECPS does not do is change the behavior of any instruction it
> assists vs. the CP simulation of that same instruction.  It's only
> purpose is to try to do it faster and take some of the burden off of CP.  If
> anyone finds an assisted instruction that yields a different result then
> that is a bug in the ECPS code.
>

Fair enough.


> At first glance, altering the behavior of EPSW seems fine for a given user
> since that user chose to load s370x and issue that instruction in any
> programming he might do.  But what if that user creates an application or
> tool and then posts it to the H390-VM forum for all to use?  It will give
> different results or might even fail depending on whether the other
> recipients are using ECPS:VM or not.   The author of the application
> should not have to document that everyone must use ECPS:VM (or, must NOT
> use ECPS:VM) in order to use his program.
>

I see your point, certainly. I suppose the issue is what is the
alternative? And the only realistic one I can think of, given that the
result is always wrong in a virtual machine, is not to implement it at all.
Which is too bad for e.g. MVS 3.8 users who might find it quite handy, but
what can you do...

I suppose it could be a standalone feature independent of ECPS, but
dependant on heuristically determining that VM/370 is in control (vs e.g.
someone playing with an S/370 version of Linux or KVM or something...). How
to do that (in the absense of trusting CR6), I'm not sure. Probably there
are sufficient clues in low storage, but ugliness is on the horizon. :-(

VM/370 would surely not be offended if EPSW worked by examining the
(architected because of ECPS) virtual PSW.


> (As I am writing this I see that Ivan beat me to it and also pointed out
> that EPSW would yield differing results with ECPS and without).
>
>
>
> Unfortunately, the ECPS code remains the best place to perform this kind
> of function as I see it.  Other ways that I could think about that might
> get the job done have other problems, such as altering the behavior for any
> MVS 3.8J user running native that issues EPSW.   ECPS:VM has the good
> effect of isolating any behavior modification only to VM.
>

Yup - that's why I proposed it when you mentioned your new work on ECPS.
Well, I don't have a super strong opinion on it. I've found it a
surprisingly useful instruction on my day job on z/OS. This is mostly for
legacy code that can't keep reliable track of what state it's in, but it
also applies to good code that wants to be able to be called in problem or
supervisor state and/or any key (and I mean called directly rather than as
an SVC routine where there is an RB or old PSW to look back at).

Tony H.
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
Ivan,

I did work for the manufacturer of those machines at one point, don't
forget.

Take this example from chapter 4:

21
The extended-immediate facility is installed in the
z/Architecture architectural mode.

This is to be read that the instructions are available only in z
architecture mode and only when bit 21 of the facility list is one.  By
inference, they will 0c1 in ESA mode, since they did so on a a G5.

Who says so?  The chap who writes the manual.  How do I know?  I asked
him.  Could he be wrong/misled?  In your mind, obviously.  The company
in question does not work that way.

This eternal go round is becoming tedious, Ivan.  Very tedious.  Put it
on hold.

On 06/13/2017 09:35 PM, Ivan Warren [hidden email] [H390-VM] wrote:
> Where do YOU read this in the z/Arch or ESA/390 Pop ?????
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
In reply to this post by Hercules390 - Vm mailing list
Hello!
And this is only available on Hyperion? Correct?
-----
Gregg C Levine [hidden email]
"This signature fought the Time Wars, time and again."


On Tue, Jun 13, 2017 at 3:35 PM, Ivan Warren [hidden email]
[H390-VM] <[hidden email]> wrote:

>
>
> On 6/13/2017 8:36 PM, 'John P. Hartmann' [hidden email] [H390-VM]
> wrote:
>>
>> If the instruction is marked with a different feature code than N3 (and
>> *all* z instructions are) *and* that feature is listed as available in z
>> architecture mode for the equivalent facility bit, then the instruction
>> must 0c1 under ESA.  I expect your correspondents were speaking through
>> their hats.
>>
> Where do YOU read this in the z/Arch or ESA/390 Pop ?????
>
> N3 is not a "feature" per se, it is a list of instructions that are new to
> z, but that *must* also be implemented in ESA/390.
>
> Nowhere in the PoP does it say that some instructions NOT marked as N3
> *cannot* be implemented in ESA/390.
>
> In the latest z/Architecture PoP the *ONLY* instruction that is guaranteed
> to throw a PIC 1 is opcode 0x00.
>
> --Ivan
>
Reply | Threaded
Open this post in threaded view
|

Re: Updated and improved ECPS:VM support

Hercules390 - Vm mailing list
Gregg,
 

 Correct.  It is available on Hyperion if you obtain the latest sources and build your own binaries.  If you run Windows, you can choose to use Fish's prebuilt Windows binaries which also have the updated ECPS support.
 

 As I mentioned in the initial post, it will also be available with TK4- update 09 whenever that is ready.  TK4- is MVS 3.8J of course but the TK4- package ships with prebuilt Hyperion binaries for several different platforms.  You can use those binaries to run VM just as easily as MVS.
 

 Regards,
 Bob
 

---In [hidden email], <gregg.drwho8@...> wrote :


 Hello!
 And this is only available on Hyperion? Correct?
 -----
 Gregg C Levine gregg.drwho8@... mailto:gregg.drwho8@...
 "This signature fought the Time Wars, time and again."
 


1234