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