Re: Re: GCIC Fullscreen applications - Update

Ivan Warren <[email protected]>
Newsgroups gmane.comp.emulators.hercules390.vm
Message-ID <[email protected]>
On 9/3/2010 3:02 PM, Rocky wrote:
>
>
> The only user in my system that is defined to come up EC mode is MAINT.
>

Something must have been lost in the translation..

A machine which has "SET ECMODE ON" can and will perfectly operate with 
a BC MODE PSW. All the Old PSWs will be presented *exactly* at the same 
position *regardless* of whether 'SET ECMODE' is ON or OFF. Everything 
you'd expect from a system operating with a BC mode PSW will behave 
EXACTLY the same - regardless of "CP SET ECMODE ON" or "CP SET ECMODE 
OFF" (notable exception below).

The location of interrupt codes is ONLY controlled by the PSW EC mode 
bit (bit 8 in the PSW) at the time the interruption occurred and NOT 
whether a virtual machine has CP SET ECMODE ON or OFF.

'CP SET ECMODE ON' (or the ECMODE Directory option) only *enables* you 
to use an EC mode PSW - but in no way does it FORCE you to do so.

CMS on MAINT only operates with a BC mode PSW and doesn't have any 
issues with the virtual machine definition being "ECMODE ON". I/O 
interrupt codes, external interrupt codes, Program and SVC interrupt 
codes are presented as usual as part of the OLD PSWs in PSA.

Now the "exception"

If your program doesn't operate correctly when "SET ECMODE ON" is in 
effect (again, I am *NOT* talking about the EC mode bit in the PSW) then 
something else is happening. I haven't checked, but most likely, your 
program is entering a CPU Timer or Clock Comparator interrupt loop. This 
would happen if your CR0 has CPU Timer and/or Clock Comparator subclass 
masks bits turned on (Bits 20 & 21) AND your External Interrupt handler 
doesn't set the CPU Timer to a positive value and/or doesn't set the 
Clock Comparator to a time in the future or doesn't clear bits 20 & 21 
in CR0. Since Clock Comparator and CPU Timer interrupts are not cleared 
by the interrupt being taken (contrary to the Interval Timer) this means 
the interrupt remains pending until the CPU Timer or Clock Comparator 
are set to values that precludes generating the relevant interrupt 
directly after issuing a LPSW instruction or SSM instruction that sets 
the external interrupt mask in the PSW to 1. This is the most common 
cause of

The Clock Comparator and CPU Timer facilities *ARE* available with a BC 
mode PSW, but require the virtual machine to have "CP SET ECMODE ON. So 
if your CR0 has subclass mask bits for Clock Comparator & Cpu Timer but 
your virtual machine doesn't have 'CP SET ECMODE ON', then no interrupt 
will ever occur because CP doesn't maintain the CPU Timer and/or Clock 
comparator registers for a virtual machine that has "CP SET ECMODE OFF" 
in effect.

Again :
- EC Mode bit in PSW set (EC MODE PSW) *requires* CP SET ECMODE ON
- Using the Clock Comparator, CPU Timer and certain instructions (such 
as STNSM or STOSM) *require* CP SET ECMODE ON
- EC Mode bit in PSW clear (BC mode PSW) will operate with either "CP 
SET ECMODE" : ON or OFF.... CP SET ECMODE OFF is *NOT* required.

Side note : This changed with S/370 XA : BC mode PSWs are no longer 
allowed at this point and bit 8 in PSW *MUST* be 1. z/Arch has a very 
different PSW format and bit 8 *MUST* be 0.
.. By *MUST* I mean that if you do try otherwise, you'll get an early 
specification exception program interrupt.

--Ivan
smime.p7s (application/pkcs7-signature, 4 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.