Discussion:
CP vs IFL
(too old to reply)
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-11 20:11:37 UTC
Permalink
Hello,
Does anyone on this list knows how to tell if the underlying processor is
an IFL ? The "Logical_CPU Characteristics" of an STSI instruction does not
seem to yield any useful information.
Thank youl
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-11 20:34:55 UTC
Permalink
On 8/11/2016 10:11 PM, Aaron Finerman ***@gmail.com
[hercules-390] wrote:
>
>
> Hello,
> Does anyone on this list knows how to tell if the underlying processor
> is an IFL ? The "Logical_CPU Characteristics" of an STSI instruction
> does not seem to yield any useful information.
> Thank youl
>
Aaron,

It's a bit tricky. You have to issue a SERVC call to do that. If you
issue SERVC command 0x00120001 in the SCCB and it succeeds, it's an IFL.
If it fails, then it's a CP and you can retrieve the information using
command code 0x00020001. Do not issue the latter on an IFL or the system
will go into a check stopped state (that's how z/OS is prevented from
being IPLed on an IFL).

Besides that, a CP and an IFL are exactly the same (at least as far as
hercules is concerned).

--Ivan


[Non-text portions of this message have been removed]
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-11 20:48:14 UTC
Permalink
Thank you, Ivan!
It appears that IBM wanted to make sure x'00020001' Check-Stops on an IFL.
Because even with CPs, if the virtual configuration is Linux, it will
Check-Stop. Do you know how far back x'00120001' goes and is there a
possibility to Check-Stop on a processor that is not supported ?
Best regards..

On Thu, Aug 11, 2016 at 4:34 PM, Ivan Warren ***@vmfacility.fr
[hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
>
>
> On 8/11/2016 10:11 PM, Aaron Finerman ***@gmail.com
> [hercules-390] wrote:
> >
> >
> > Hello,
> > Does anyone on this list knows how to tell if the underlying processor
> > is an IFL ? The "Logical_CPU Characteristics" of an STSI instruction
> > does not seem to yield any useful information.
> > Thank youl
> >
> Aaron,
>
> It's a bit tricky. You have to issue a SERVC call to do that. If you
> issue SERVC command 0x00120001 in the SCCB and it succeeds, it's an IFL.
> If it fails, then it's a CP and you can retrieve the information using
> command code 0x00020001. Do not issue the latter on an IFL or the system
> will go into a check stopped state (that's how z/OS is prevented from
> being IPLed on an IFL).
>
> Besides that, a CP and an IFL are exactly the same (at least as far as
> hercules is concerned).
>
> --Ivan
>
> [Non-text portions of this message have been removed]
>
>
>
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-12 00:24:34 UTC
Permalink
On 8/11/2016 10:48 PM, Aaron Finerman ***@gmail.com
[hercules-390] wrote:
>
>
> Thank you, Ivan!
> It appears that IBM wanted to make sure x'00020001' Check-Stops on an
> IFL. Because even with CPs, if the virtual configuration is Linux, it
> will Check-Stop. Do you know how far back x'00120001' goes and is
> there a possibility to Check-Stop on a processor that is not supported ?
> Best regards..
>
I am not sure I understand the question.

By Virtual configuration, do you mean running under z/VM ? If this is
the case - and if there is a way to define virtual processors in a
virtual machine to be IFLs (even if the real processors are CPs) - then
since SERVC induces a mandatory SIE intercept, then z/VM CP may decide
to put the virtual machine in check stop state.

--Ivan


[Non-text portions of this message have been removed]
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-12 00:58:48 UTC
Permalink
Sorry for not being clear on that. Yes, I did mean the virtual
configuration under z/VM. If the real LPAR has one or more CPs, the default
configuration of any virtual machine that logs on is ESA390. But can be
changed to LINUX using the SET VCONFIG command. However, if there are no
CPs, the virtual configuration can not be set to ESA390. So, there has be a
way for zVM to know it is running on an IFL. Since order x'00120001' works
both on IFLs and CPs, Is there a field in Read Configuration that specifies
the processor type ? Best regards.

On Thu, Aug 11, 2016 at 8:24 PM, Ivan Warren ***@vmfacility.fr
[hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
>
>
> On 8/11/2016 10:48 PM, Aaron Finerman ***@gmail.com
> [hercules-390] wrote:
> >
> >
> > Thank you, Ivan!
> > It appears that IBM wanted to make sure x'00020001' Check-Stops on an
> > IFL. Because even with CPs, if the virtual configuration is Linux, it
> > will Check-Stop. Do you know how far back x'00120001' goes and is
> > there a possibility to Check-Stop on a processor that is not supported ?
> > Best regards..
> >
> I am not sure I understand the question.
>
> By Virtual configuration, do you mean running under z/VM ? If this is
> the case - and if there is a way to define virtual processors in a
> virtual machine to be IFLs (even if the real processors are CPs) - then
> since SERVC induces a mandatory SIE intercept, then z/VM CP may decide
> to put the virtual machine in check stop state.
>
> --Ivan
>
> [Non-text portions of this message have been removed]
>
>
>
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-12 01:17:07 UTC
Permalink
On 8/12/2016 2:58 AM, Aaron Finerman ***@gmail.com [hercules-390]
wrote:
>
>
> Sorry for not being clear on that. Yes, I did mean the virtual
> configuration under z/VM. If the real LPAR has one or more CPs, the
> default configuration of any virtual machine that logs on is ESA390.
> But can be changed to LINUX using the SET VCONFIG command. However, if
> there are no CPs, the virtual configuration can not be set to ESA390.
> So, there has be a way for zVM to know it is running on an IFL. Since
> order x'00120001' works both on IFLs and CPs, Is there a field in Read
> Configuration that specifies the processor type ? Best regards.
>
Aaron,

The configuration is ALWAYS going to be ESA architectured upon login
(Switching to z/Arch is only via SIGP) - regardless of IFLs and CPs.

Order 00120001 only works on IFLs
Order 00020001 only works on CPs.

The only difference is that issuing 00020001 on an IFL will end in a
check stop.

--Ivan


[Non-text portions of this message have been removed]
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-12 01:48:53 UTC
Permalink
Ivan, Thank you so much for your help and guidance.
Best regards,

On Thu, Aug 11, 2016 at 9:17 PM, Ivan Warren ***@vmfacility.fr
[hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
>
>
> On 8/12/2016 2:58 AM, Aaron Finerman ***@gmail.com [hercules-390]
> wrote:
> >
> >
> > Sorry for not being clear on that. Yes, I did mean the virtual
> > configuration under z/VM. If the real LPAR has one or more CPs, the
> > default configuration of any virtual machine that logs on is ESA390.
> > But can be changed to LINUX using the SET VCONFIG command. However, if
> > there are no CPs, the virtual configuration can not be set to ESA390.
> > So, there has be a way for zVM to know it is running on an IFL. Since
> > order x'00120001' works both on IFLs and CPs, Is there a field in Read
> > Configuration that specifies the processor type ? Best regards.
> >
> Aaron,
>
> The configuration is ALWAYS going to be ESA architectured upon login
> (Switching to z/Arch is only via SIGP) - regardless of IFLs and CPs.
>
> Order 00120001 only works on IFLs
> Order 00020001 only works on CPs.
>
> The only difference is that issuing 00020001 on an IFL will end in a
> check stop.
>
> --Ivan
>
> [Non-text portions of this message have been removed]
>
>
>
Mike Schwab Mike.A.Schwab@gmail.com [hercules-390]
2016-08-12 14:14:46 UTC
Permalink
On Thu, Aug 11, 2016 at 8:17 PM, Ivan Warren ***@vmfacility.fr
[hercules-390] <hercules-***@yahoogroups.com> wrote:
>
> Aaron,
>
> The configuration is ALWAYS going to be ESA architectured upon login
> (Switching to z/Arch is only via SIGP) - regardless of IFLs and CPs.
>
<deleted>
> --Ivan

When z14 ships, it will start in z/Arch and won't perform the switch to ESA.

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-12 14:47:18 UTC
Permalink
When z14 ships, it will start in z/Arch and won't perform the switch to
ESA.


This we will see when it ships ! Furthermore, in terms of hercules, it
won't be much of a concern (we'll just need to have an option for it to
behave in that way).

--Ivan



[Non-text portions of this message have been removed]
Tony Harminc tharminc@gmail.com [hercules-390]
2016-08-12 17:36:10 UTC
Permalink
On 12 August 2016 at 10:47, Ivan Warren ***@vmfacility.fr wrote:

> When z14 ships, it will start in z/Arch and won't perform the switch to
> ESA.
>
>
> This we will see when it ships ! Furthermore, in terms of hercules, it
> won't be much of a concern (we'll just need to have an option for it to
> behave in that way).


z/VM 6.4 has a similar feature:

"In addition, support will be added to simulate a z/Architecture-only
environment, by providing a virtual machine environment that is always
in the z/Architecture architectural mode and **cannot switch** to the
ESA/390 architectural mode. This can be useful for testing software in a
**z/Architecture-only environment**, in advance of deploying software on
a future z/Architecture-only machine."

But I'm curious: are the details of a zArch mode IPL well defined? The -10
version of the POO says clearly that:

"Activating the load-clear key or the load-normal key sets the
architectural mode to the ESA/390 mode."

And then:

"When the IPL I/O operation is completed successfully, the
subsystem-identification word for the IPL device is stored in absolute
storage locations 184-187, zeros are stored in absolute storage locations
188-191, and a new PSW is loaded from absolute storage locations 0-7."

Clearly this can only be describing an ESA/390 mode IPL. It wouldn't be
difficult to modify the description to allow for the post-IPL new PSW to be
loaded from locations 0-15 (or maybe from 416-431?), but where is the
correct behaviour documented?

Tony H.
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-12 17:54:53 UTC
Permalink
I would think an eight byte PSW would still be loaded from location 0. In
z/Architecture mode, LPSW is still valid and the PSW is converted to 16
bytes.
Best regards,

On Fri, Aug 12, 2016 at 1:36 PM, Tony Harminc ***@gmail.com
[hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
> On 12 August 2016 at 10:47, Ivan Warren ***@vmfacility.fr wrote:
>
>> When z14 ships, it will start in z/Arch and won't perform the switch to
>> ESA.
>>
>>
>> This we will see when it ships ! Furthermore, in terms of hercules, it
>> won't be much of a concern (we'll just need to have an option for it to
>> behave in that way).
>
>
> z/VM 6.4 has a similar feature:
>
> "In addition, support will be added to simulate a z/Architecture-only
> environment, by providing a virtual machine environment that is always
> in the z/Architecture architectural mode and **cannot switch** to the
> ESA/390 architectural mode. This can be useful for testing software in a
> **z/Architecture-only environment**, in advance of deploying software on
> a future z/Architecture-only machine."
>
> But I'm curious: are the details of a zArch mode IPL well defined? The -10
> version of the POO says clearly that:
>
> "Activating the load-clear key or the load-normal key sets the
> architectural mode to the ESA/390 mode."
>
> And then:
>
> "When the IPL I/O operation is completed successfully, the
> subsystem-identification word for the IPL device is stored in absolute
> storage locations 184-187, zeros are stored in absolute storage locations
> 188-191, and a new PSW is loaded from absolute storage locations 0-7."
>
> Clearly this can only be describing an ESA/390 mode IPL. It wouldn't be
> difficult to modify the description to allow for the post-IPL new PSW to be
> loaded from locations 0-15 (or maybe from 416-431?), but where is the
> correct behaviour documented?
>
> Tony H.
>
>
>
Tony Harminc tharminc@gmail.com [hercules-390]
2016-08-12 19:00:34 UTC
Permalink
On 12 August 2016 at 13:54, Aaron Finerman ***@gmail.com wrote:

> I would think an eight byte PSW would still be loaded from location 0. In
> z/Architecture mode, LPSW is still valid and the PSW is converted to 16
> bytes.


Ah - good point! I hadn't thought that the loading of that first PSW could
be considered to be done by (old-style) LPSW. That makes complete sense,
since IPLable programs would need far fewer changes than otherwise.

Tony H.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-12 19:45:45 UTC
Permalink
On 8/12/2016 9:00 PM, Tony Harminc ***@gmail.com [hercules-390] wrote:
>
>
> On 12 August 2016 at 13:54, Aaron Finerman ***@gmail.com
> <mailto:***@gmail.com> wrote:
>
> I would think an eight byte PSW would still be loaded from
> location 0. In z/Architecture mode, LPSW is still valid and the
> PSW is converted to 16 bytes.
>
>
> Ah - good point! I hadn't thought that the loading of that first PSW
> could be considered to be done by (old-style) LPSW. That makes
> complete sense, since IPLable programs would need far fewer changes
> than otherwise.
>
> Tony H.
>
If it is confirmed that new systems will start in z/Arch mode I guess...
We'll just have to wait on the next Poo - and not speculate

--Ivan


[Non-text portions of this message have been removed]
Tony Harminc tharminc@gmail.com [hercules-390]
2016-08-12 20:42:49 UTC
Permalink
On 12 August 2016 at 15:45, Ivan Warren ***@vmfacility.fr wrote:

> If it is confirmed that new systems will start in z/Arch mode I guess...
> We'll just have to wait on the next Poo - and not speculate


An interesting comment in IBM-MAIN from IBM's Jim Mulder in Feb 2016:

> z/OS and z/OS Stand-alone Dump have been prepared for a
> z/Architecture-only machine since z/OS 1.12. z/OS used to run in
> ESA/390 mode up until the point in IPL where LOADxx was processed,
> so that a LOADxx parm could be used to determine whether ESA/390
> or z/Architecture should be the final mode. And stand-alone dump
> needed to run in the mode of the system it was dumping. Removing the
> ESA/390 support was a fair amount of work, especially in stand-alone
> dump, and I did not want us to have to do that in multiple releases
> via PTFs, so I did in in z/OS 1.12, long before there was a plan as
> to when a z/Architecture-only machine would be built.

I don't remember if any of stand-alone dump is still shipped in source (it
used to be generated from macros), but it would be an interesting place to
look. And of course z/Linux is the usual place to find out about new zArch
features. But all this is meaningless in the absense of a current machine
that can IPL in zArch mode. Jim's comment suggests that some already can;
maybe there's a hidden config option somewhere. Or maybe he tests only
under a z/VM that can enforce this.

Tony H.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-12 21:07:08 UTC
Permalink
On 8/12/2016 10:42 PM, Tony Harminc ***@gmail.com [hercules-390] wrote:
>
>
> On 12 August 2016 at 15:45, Ivan Warren ***@vmfacility.fr
> <mailto:***@vmfacility.fr> wrote:
>
> If it is confirmed that new systems will start in z/Arch mode I
> guess...
> We'll just have to wait on the next Poo - and not speculate
>
>
> An interesting comment in IBM-MAIN from IBM's Jim Mulder in Feb 2016:
>
> > z/OS and z/OS Stand-alone Dump have been prepared for a
> > z/Architecture-only machine since z/OS 1.12. z/OS used to run in
> > ESA/390 mode up until the point in IPL where LOADxx was processed,
> > so that a LOADxx parm could be used to determine whether ESA/390
> > or z/Architecture should be the final mode. And stand-alone dump
> > needed to run in the mode of the system it was dumping. Removing the
> > ESA/390 support was a fair amount of work, especially in stand-alone
> > dump, and I did not want us to have to do that in multiple releases
> > via PTFs, so I did in in z/OS 1.12, long before there was a plan as
> > to when a z/Architecture-only machine would be built.
>
> I don't remember if any of stand-alone dump is still shipped in source
> (it used to be generated from macros), but it would be an interesting
> place to look. And of course z/Linux is the usual place to find out
> about new zArch features. But all this is meaningless in the absense
> of a current machine that can IPL in zArch mode. Jim's comment
> suggests that some already can; maybe there's a hidden config option
> somewhere. Or maybe he tests only under a z/VM that can enforce this.
>
> Tony H.
>
Again,

I don't think there will be any issue with adapting hercules to
implement a z/Arch only machine, once we know of the specifics. I
foresee it will just be a configuration statement/command to turn this
on, and then behave as the next Poo dictates.

--Ivan


[Non-text portions of this message have been removed]
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-18 00:08:57 UTC
Permalink
While I was trying every instruction I could think of, trying to figure out
if I'm running on an IFL or CP, I did run into a few interesting Diagnose
instructions. However, I noticed Hercules does not return correct data on
Diagnose 224. Hercules returns code 2 for ICF, where in real life it is
code 4.
Best regards,

On Fri, Aug 12, 2016 at 5:07 PM, Ivan Warren ***@vmfacility.fr
[hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
>
>
> On 8/12/2016 10:42 PM, Tony Harminc ***@gmail.com [hercules-390]
> wrote:
> >
> >
> > On 12 August 2016 at 15:45, Ivan Warren ***@vmfacility.fr
> > <mailto:***@vmfacility.fr> wrote:
> >
> > If it is confirmed that new systems will start in z/Arch mode I
> > guess...
> > We'll just have to wait on the next Poo - and not speculate
> >
> >
> > An interesting comment in IBM-MAIN from IBM's Jim Mulder in Feb 2016:
> >
> > > z/OS and z/OS Stand-alone Dump have been prepared for a
> > > z/Architecture-only machine since z/OS 1.12. z/OS used to run in
> > > ESA/390 mode up until the point in IPL where LOADxx was processed,
> > > so that a LOADxx parm could be used to determine whether ESA/390
> > > or z/Architecture should be the final mode. And stand-alone dump
> > > needed to run in the mode of the system it was dumping. Removing the
> > > ESA/390 support was a fair amount of work, especially in stand-alone
> > > dump, and I did not want us to have to do that in multiple releases
> > > via PTFs, so I did in in z/OS 1.12, long before there was a plan as
> > > to when a z/Architecture-only machine would be built.
> >
> > I don't remember if any of stand-alone dump is still shipped in source
> > (it used to be generated from macros), but it would be an interesting
> > place to look. And of course z/Linux is the usual place to find out
> > about new zArch features. But all this is meaningless in the absense
> > of a current machine that can IPL in zArch mode. Jim's comment
> > suggests that some already can; maybe there's a hidden config option
> > somewhere. Or maybe he tests only under a z/VM that can enforce this.
> >
> > Tony H.
> >
> Again,
>
> I don't think there will be any issue with adapting hercules to
> implement a z/Arch only machine, once we know of the specifics. I
> foresee it will just be a configuration statement/command to turn this
> on, and then behave as the next Poo dictates.
>
> --Ivan
>
> [Non-text portions of this message have been removed]
>
>
>
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-18 21:06:21 UTC
Permalink
Aaron Finerman wrote:

[...]
> I noticed Hercules does not return correct data on
> Diagnose 224. Hercules returns code 2 for ICF, where
> in real life it is code 4.

Here's how they're currently defined in Hercules:

#define SCCB_PTYP_CP 0 /* CPU */
#define SCCB_PTYP_ICF 1 /* Crypto */
#define SCCB_PTYP_IFA 2 /* zAAP */
#define SCCB_PTYP_IFL 3 /* Linux */
//efine SCCB_PTYP_XXX 4 /* ??? */
#define SCCB_PTYP_SUP 5 /* zIIP */

I'd like to just switch around codes 1 and 3 (ICF = Crypto and IFL = Linux) since that's what I believe you're saying, but I want to be sure.

Can you do me a favor Aaron, and list for us ALL of the actual engine type codes that are returned by a real machine?

Thanks!

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-18 21:14:43 UTC
Permalink
On 8/18/2016 11:06 PM, ''Fish' (David B. Trout)' ***@gmail.com
[hercules-390] wrote:
> Aaron Finerman wrote:
>
> [...]
>> I noticed Hercules does not return correct data on
>> Diagnose 224. Hercules returns code 2 for ICF, where
>> in real life it is code 4.
> Here's how they're currently defined in Hercules:
>
> #define SCCB_PTYP_CP 0 /* CPU */
> #define SCCB_PTYP_ICF 1 /* Crypto */
> #define SCCB_PTYP_IFA 2 /* zAAP */
> #define SCCB_PTYP_IFL 3 /* Linux */
> //efine SCCB_PTYP_XXX 4 /* ??? */
> #define SCCB_PTYP_SUP 5 /* zIIP */
>
> I'd like to just switch around codes 1 and 3 (ICF = Crypto and IFL = Linux) since that's what I believe you're saying, but I want to be sure.
>
> Can you do me a favor Aaron, and list for us ALL of the actual engine type codes that are returned by a real machine?
>
> Thanks!
>
Fish

I don't think ICF is a crypto facility. I think it's a Coupling Facility.

--Ivan





[Non-text portions of this message have been removed]
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-18 22:04:31 UTC
Permalink
Hi Fish, Code 3 should definitely stay as 'IFL'. It is code 1 and 4 that
should be swapped. I also think ICF is 'Integrated Coupling Facility' and
not 'Crypto'.
Here is the list:
0 C3D74040 CP
1 40404040
2 E9C1C1D7 ZAAP
3 C9C6D340 IFL
4 C9C3C640 ICF
5 E9C9C9D7 ZIIP
Best regards,

On Thu, Aug 18, 2016 at 5:06 PM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
> Aaron Finerman wrote:
>
> [...]
> > I noticed Hercules does not return correct data on
> > Diagnose 224. Hercules returns code 2 for ICF, where
> > in real life it is code 4.
>
> Here's how they're currently defined in Hercules:
>
> #define SCCB_PTYP_CP 0 /* CPU */
> #define SCCB_PTYP_ICF 1 /* Crypto */
> #define SCCB_PTYP_IFA 2 /* zAAP */
> #define SCCB_PTYP_IFL 3 /* Linux */
> //efine SCCB_PTYP_XXX 4 /* ??? */
> #define SCCB_PTYP_SUP 5 /* zIIP */
>
> I'd like to just switch around codes 1 and 3 (ICF = Crypto and IFL =
> Linux) since that's what I believe you're saying, but I want to be sure.
>
> Can you do me a favor Aaron, and list for us ALL of the actual engine type
> codes that are returned by a real machine?
>
> Thanks!
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: ***@softdevlabs.com
>
>
>
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-18 22:36:55 UTC
Permalink
Ivan wrote:

> I don't think ICF is a crypto facility.
> I think it's a Coupling Facility.

Really? A Coupling Facility is a type of PROCESSOR (engine)? I thought it was a type of CHANNEL. Isn't there some type of crypto engine/processor on modern z's?

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Gregg Levine gregg.drwho8@gmail.com [hercules-390]
2016-08-18 22:45:08 UTC
Permalink
Hello!
Yes there is. But I'm not sure what it is.

This of course does not explain why there is an angry big foot in your
parking lot, Fish, next to an big strange looking object.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."


On Thu, Aug 18, 2016 at 6:36 PM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] <hercules-***@yahoogroups.com>
wrote:
> Ivan wrote:
>
>> I don't think ICF is a crypto facility.
>> I think it's a Coupling Facility.
>
> Really? A Coupling Facility is a type of PROCESSOR (engine)? I thought it was a type of CHANNEL. Isn't there some type of crypto engine/processor on modern z's?
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: ***@softdevlabs.com
>
>
>
>
>
>
> ------------------------------------
> Posted by: "\"Fish\" \(David B. Trout\)" <***@softdevlabs.com>
> ------------------------------------
>
> Community email addresses:
> Post message: hercules-***@yahoogroups.com
> Subscribe: hercules-390-***@yahoogroups.com
> Unsubscribe: hercules-390-***@yahoogroups.com
> List owner: hercules-390-***@yahoogroups.com
>
> Files and archives at:
> http://groups.yahoo.com/group/hercules-390
>
> Get the latest version of Hercules from:
> http://www.hercules-390.org
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-18 22:51:54 UTC
Permalink
On 8/19/2016 12:36 AM, ''Fish' (David B. Trout)' ***@gmail.com
[hercules-390] wrote:
> Ivan wrote:
>
>> I don't think ICF is a crypto facility.
>> I think it's a Coupling Facility.
> Really? A Coupling Facility is a type of PROCESSOR (engine)? I thought it was a type of CHANNEL. Isn't there some type of crypto engine/processor on modern z's?
>
Fish,

No.. Actually a CF is a Coupling Facility (or I think was... I don't
think IBM makes those) which is basically a processor which only has CF
links, and the ICF is the virtualized version of a CF as presented by
PR/SM or z/VM which runs the CF code which allows multiple processors in
a sysplex to maintain and synchronize internal OS structures and
maintain a common time base. The CF code is basically Licensed Internal
Code which is why hercules cannot run as a CF or run ICF virtual
machines or partitions. It is not a technical restriction (some
developer of hercules DID manage to run hercules as a CF at some point
but didn't pursue as the legal implications were too complicated).

https://en.wikipedia.org/wiki/Coupling_Facility

--Ivan



[Non-text portions of this message have been removed]
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-18 23:06:39 UTC
Permalink
On 8/19/2016 12:36 AM, ''Fish' (David B. Trout)' ***@gmail.com
[hercules-390] wrote:
> Ivan wrote:
>
>> I don't think ICF is a crypto facility.
>> I think it's a Coupling Facility.
> Really? A Coupling Facility is a type of PROCESSOR (engine)? I thought it was a type of CHANNEL. Isn't there some type of crypto engine/processor on modern z's?
>
Fish,

And to complete this. The "crypto" processor is I think the CCA
(Cryptographic Coprocessor Adapter ?) which is a PCI adapter which plugs
in to some models. Contrary to all the other crypto facilities we
implement, it also provides asymmetric cryptography by allowing an
application to store (write only) a private RSA/DSA key unto the adapter
(and the adapter guaranteeing that if the adapter is snatched from the
system that the private key will become inaccessible) allowing secure
PKI signing and encryption operations. It is accessible using specific
(undocumented) instructions by IBM products only.

--Ivan



[Non-text portions of this message have been removed]
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2016-08-19 06:22:36 UTC
Permalink
On 08/19/2016 12:36 AM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] wrote:
>
>
> Ivan wrote:
>
>> I don't think ICF is a crypto facility.
>> I think it's a Coupling Facility.
>
> Really? A Coupling Facility is a type of PROCESSOR (engine)? I thought
> it was a type of CHANNEL. Isn't there some type of crypto
> engine/processor on modern z's?

A coupling facility is a plain old CPU that runs a different load of
code than an operating system (code is loaded by the service processor
from an encrypted file). I once managed to get a 16-way system to run
just as a coupling facility. Took me a while to get things back where I
could IML it back into "normal" life.


------------------------------------

------------------------------------

Community email addresses:
Post message: hercules-***@yahoogroups.com
Subscribe: hercules-390-***@yahoogroups.com
Unsubscribe: hercules-390-***@yahoogroups.com
List owner: hercules-390-***@yahoogroups.com

Files and archives at:
http://groups.yahoo.com/group/hercules-390

Get the latest version of Hercules from:
http://www.hercules-390.org


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/hercules-390/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/hercules-390/join
(Yahoo! ID required)

<*> To change settings via email:
hercules-390-***@yahoogroups.com
hercules-390-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
hercules-390-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
'Norman Hollander on Desertwiz' norman.hollander@desertwiz.biz [hercules-390]
2016-08-19 16:25:48 UTC
Permalink
Fish-

All the z engines are exactly the same. They can be characterized as
General Purpose (GP),

zIIP (as of z13 no more zAAPs), ICF (Coupling Facility), or IFL (Linux)
engines. The GP is unique

in that it can be "capped" or "knee capped" to appear to run slower and
consume less MIPS

or MSUs. In reality, the engine still runs the same speed as the given GHz
of the processors,

but it is time-sliced to appear to run at a lower rate. All the specialty
engines run at full speed.

The type of engine is determined by the firmware (specifically assigned by
the Service Element).

The Crypto engines sit adjacent on the Processor Chip and uses a unique set
of hardware instructions.

There are additional Crypto accelerators that live in add-on PCI cards (more
$$$).



zN



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Thursday, August 18, 2016 3:52 PM
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-390] CP vs IFL







On 8/19/2016 12:36 AM, ''Fish' (David B. Trout)' ***@gmail.com
<mailto:***@gmail.com>
[hercules-390] wrote:
> Ivan wrote:
>
>> I don't think ICF is a crypto facility.
>> I think it's a Coupling Facility.
> Really? A Coupling Facility is a type of PROCESSOR (engine)? I thought it
was a type of CHANNEL. Isn't there some type of crypto engine/processor on
modern z's?
>
Fish,

No.. Actually a CF is a Coupling Facility (or I think was... I don't
think IBM makes those) which is basically a processor which only has CF
links, and the ICF is the virtualized version of a CF as presented by
PR/SM or z/VM which runs the CF code which allows multiple processors in
a sysplex to maintain and synchronize internal OS structures and
maintain a common time base. The CF code is basically Licensed Internal
Code which is why hercules cannot run as a CF or run ICF virtual
machines or partitions. It is not a technical restriction (some
developer of hercules DID manage to run hercules as a CF at some point
but didn't pursue as the legal implications were too complicated).

https://en.wikipedia.org/wiki/Coupling_Facility

--Ivan

[Non-text portions of this message have been removed]
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-19 01:58:02 UTC
Permalink
Aaron Finerman wrote:

(sequence adjusted for clarity)

> Hi Fish, Code 3 should definitely stay as 'IFL'.
> It is code 1 and 4 that should be swapped.
>
> Here is the list:
>
> 0 C3D74040 CP
> 1 40404040
> 2 E9C1C1D7 ZAAP
> 3 C9C6D340 IFL
> 4 C9C3C640 ICF
> 5 E9C9C9D7 ZIIP
> Best regards,

Thanks. I'll go ahead and make that change right away.

It's a good thing I asked for clarification. You originally said 2 and 4!


> I also think ICF is 'Integrated Coupling Facility'
> and not 'Crypto'.

Yeah, my bad. I know there are integrated crypto chips/processors in modern mainframes, just like there are in personal computers these days (Intel calls them "TPM"s: "Trusted Platform Modules"; my system has one), and having played around with HCD/IODFs in the past I also know there are Coupling Facility channels too (CHPIDs?), but I wasn't aware that there were CF processor types. That's why I guessed (presumed) ICF was a crypto processor and not a CF processor. (An understandable mistake for someone like me to make, not being that familiar/experienced with such things.)

Anyway, Ivan straightened me out so we're cool I think.

I'll go ahead and make that change right away.

Thanks for your help.

p.s. Has ANYONE figured out the answer to the original question yet? How to tell what type of processor you (i.e. your task) are currently executing on?

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-19 12:10:34 UTC
Permalink
Hi Fish,
Going forward, Its the STHYI xB256' instruction (availability subject to
bit 74 of STFLE, itself subject to bit 7 of STFL). But for now, Ivan's
response helped and put me on the right track. SERVC function code
x'00120001' gives return code x'01F0' on a CP. In addition Diagnose 204
also provides processor types.
Best regards,

On Thu, Aug 18, 2016 at 9:58 PM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
> Aaron Finerman wrote:
>
> (sequence adjusted for clarity)
>
> > Hi Fish, Code 3 should definitely stay as 'IFL'.
> > It is code 1 and 4 that should be swapped.
> >
> > Here is the list:
> >
> > 0 C3D74040 CP
> > 1 40404040
> > 2 E9C1C1D7 ZAAP
> > 3 C9C6D340 IFL
> > 4 C9C3C640 ICF
> > 5 E9C9C9D7 ZIIP
> > Best regards,
>
> Thanks. I'll go ahead and make that change right away.
>
> It's a good thing I asked for clarification. You originally said 2 and 4!
>
> > I also think ICF is 'Integrated Coupling Facility'
> > and not 'Crypto'.
>
> Yeah, my bad. I know there are integrated crypto chips/processors in
> modern mainframes, just like there are in personal computers these days
> (Intel calls them "TPM"s: "Trusted Platform Modules"; my system has one),
> and having played around with HCD/IODFs in the past I also know there are
> Coupling Facility channels too (CHPIDs?), but I wasn't aware that there
> were CF processor types. That's why I guessed (presumed) ICF was a crypto
> processor and not a CF processor. (An understandable mistake for someone
> like me to make, not being that familiar/experienced with such things.)
>
> Anyway, Ivan straightened me out so we're cool I think.
>
> I'll go ahead and make that change right away.
>
> Thanks for your help.
>
> p.s. Has ANYONE figured out the answer to the original question yet? How
> to tell what type of processor you (i.e. your task) are currently executing
> on?
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: ***@softdevlabs.com
>
>
>
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-20 02:06:56 UTC
Permalink
Aaron Finerman wrote:

> Going forward, Its the STHYI x'B256' instruction
> (availability subject to bit 74 of STFLE, itself subject
> to bit 7 of STFL).

Interesting. The STHYI x'B256' instruction doesn't currently exist in Hercules. I wonder what it does? How it works? How difficult it would be to implement?

Jan Jaeger usually does this sort of stuff for us, but he hasn't been around for *years* now. (I wonder why and where he's been / been up to?)


> But for now, Ivan's response helped and put me on the right track.
> SERVC function code x'00120001' gives return code x'01F0' on a CP.

But that just tells you whether your processor is a CP type processor, yes? (I haven't looked at the code) But if you're NOT running on a CP processor type, it doesn't tell you which of the other types you ARE running on, correct? Wasn't that pretty much the original question, or am I reading more into it than is really there?


> In addition Diagnose 204 also provides processor types.

But that just returns, in EBCDIC, a list of processor types in ascending processor type code sequence, correct? So again, it doesn't help much, does it?

Is there some DIAG code or SERVC request that will tell you your processor TYPE code? If you knew that then you could use that to index into the processor types list returned by DIAG 224 et VOILA.

But I'm not seeing how you've managed to figure it.

(unless it has something to do with that magical STHYI x'B256' instruction?)

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Michael Short michael.short.47@gmail.com [hercules-390]
2016-08-20 03:48:20 UTC
Permalink
It is probably enough to know if the processor is a CP (throttled) or a
specialty engine (Non-throttled).
All specialty are the same, only distinguished by the code loaded by the
HMC.

Except for an IFL for Linux, the other non-throttled engines run specialty
code which a Hercules user
normally would not be executing.

So one should probably say that the engine will either be a CP or an IFL,
which you can determine.

On Fri, Aug 19, 2016 at 10:06 PM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
> Aaron Finerman wrote:
>
> > Going forward, Its the STHYI x'B256' instruction
> > (availability subject to bit 74 of STFLE, itself subject
> > to bit 7 of STFL).
>
> Interesting. The STHYI x'B256' instruction doesn't currently exist in
> Hercules. I wonder what it does? How it works? How difficult it would be to
> implement?
>
> Jan Jaeger usually does this sort of stuff for us, but he hasn't been
> around for *years* now. (I wonder why and where he's been / been up to?)
>
> > But for now, Ivan's response helped and put me on the right track.
> > SERVC function code x'00120001' gives return code x'01F0' on a CP.
>
> But that just tells you whether your processor is a CP type processor,
> yes? (I haven't looked at the code) But if you're NOT running on a CP
> processor type, it doesn't tell you which of the other types you ARE
> running on, correct? Wasn't that pretty much the original question, or am I
> reading more into it than is really there?
>
> > In addition Diagnose 204 also provides processor types.
>
> But that just returns, in EBCDIC, a list of processor types in ascending
> processor type code sequence, correct? So again, it doesn't help much, does
> it?
>
> Is there some DIAG code or SERVC request that will tell you your processor
> TYPE code? If you knew that then you could use that to index into the
> processor types list returned by DIAG 224 et VOILA.
>
> But I'm not seeing how you've managed to figure it.
>
> (unless it has something to do with that magical STHYI x'B256'
> instruction?)
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: ***@softdevlabs.com
>
>
>
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2016-08-20 05:55:33 UTC
Permalink
It is implemented by CP. See CP Programming Services chapter 29.

Hercules should not implement it.

On 08/20/2016 04:06 AM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] wrote:
> Interesting. The STHYI x'B256' instruction doesn't currently exist in
> Hercules. I wonder what it does? How it works? How difficult it would be
> to implement?
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-20 16:22:22 UTC
Permalink
John P. Hartmann wrote:

> It is implemented by CP.
> See CP Programming Services chapter 29.

"Chapter 29. Symptom Record Reporting"??

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-20 06:09:59 UTC
Permalink
Hi Fish,
The purpose of my original question was to be able to access the LOADPARM,
without risking a Check-Stop. SERVC function x'00120001' satisfies my
needs. As for Diagnose 204, it has several functions and it returns the
number of structures and a structure of each LPAR and a structure of each
engine allocated to that LPAR. Hercules does support these functions.
However the reported amount of memory of the LPAR is erroneous.
Best regards,

On Fri, Aug 19, 2016 at 10:06 PM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
> Aaron Finerman wrote:
>
> > Going forward, Its the STHYI x'B256' instruction
> > (availability subject to bit 74 of STFLE, itself subject
> > to bit 7 of STFL).
>
> Interesting. The STHYI x'B256' instruction doesn't currently exist in
> Hercules. I wonder what it does? How it works? How difficult it would be to
> implement?
>
> Jan Jaeger usually does this sort of stuff for us, but he hasn't been
> around for *years* now. (I wonder why and where he's been / been up to?)
>
> > But for now, Ivan's response helped and put me on the right track.
> > SERVC function code x'00120001' gives return code x'01F0' on a CP.
>
> But that just tells you whether your processor is a CP type processor,
> yes? (I haven't looked at the code) But if you're NOT running on a CP
> processor type, it doesn't tell you which of the other types you ARE
> running on, correct? Wasn't that pretty much the original question, or am I
> reading more into it than is really there?
>
> > In addition Diagnose 204 also provides processor types.
>
> But that just returns, in EBCDIC, a list of processor types in ascending
> processor type code sequence, correct? So again, it doesn't help much, does
> it?
>
> Is there some DIAG code or SERVC request that will tell you your processor
> TYPE code? If you knew that then you could use that to index into the
> processor types list returned by DIAG 224 et VOILA.
>
> But I'm not seeing how you've managed to figure it.
>
> (unless it has something to do with that magical STHYI x'B256'
> instruction?)
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: ***@softdevlabs.com
>
>
>
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-20 16:43:15 UTC
Permalink
Aaron Finerman wrote:

[...]
> As for Diagnose 204, [...]
> the reported amount of memory
> of the LPAR is erroneous.

Oh?! How so? Tell me more!

I'd like to fix this if possible.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-20 22:39:48 UTC
Permalink
Hi Fish,
Diagnose 204 function x'00010007' in the LPAR structure after the SYSPLEX
name, etc. at offset x'24' should be size of the LPAR (4 bytes) in mega
bytes (Perhaps MAINSIZE). Hercules returns X'40000000'.
Best regards,

On Sat, Aug 20, 2016 at 12:43 PM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
> Aaron Finerman wrote:
>
> [...]
> > As for Diagnose 204, [...]
> > the reported amount of memory
> > of the LPAR is erroneous.
>
> Oh?! How so? Tell me more!
>
> I'd like to fix this if possible.
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: ***@softdevlabs.com
>
>
>
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-21 04:19:08 UTC
Permalink
Aaron Finerman wrote:

> Diagnose 204 function x'00010007' in the LPAR structure
> after the SYSPLEX name, etc. at offset x'24' should be
> size of the LPAR (4 bytes) in mega bytes (Perhaps MAINSIZE).
> Hercules returns X'40000000'.

Hmmm... That doesn't match up with Hercules (but then we already know that).

Hercules is currently returning storage size in bytes, not megabytes. That's an easy fix.

Also, Hercules believes the field to be an 8-byte doubleword field at offset X'20, not a 4-byte fullword field at offset X'24':


typedef struct _DIAG204_X_PART {
/*00*/ BYTE partnum; /* Logical partition number
starts with 1 */
/*01*/ BYTE virtcpu; /* Number of virt CP's */
/*02*/ BYTE realcpu; /* Number of real CP's */
/*03*/ BYTE pflag;
/*04*/ FWORD mlu;
/*08*/ BYTE partname[8]; /* Partition name */
/*10*/ BYTE cpcname[8]; /* CPC name */
/*18*/ BYTE osname[8]; /* Operating system type */
/*20*/ DBLWRD cssize; /* Central storage size */
/*28*/ DBLWRD essize; /* Expanded Storage size */
/*30*/ BYTE upid;
/*31*/ BYTE resv1[3];
/*34*/ FWORD gr_mlu;
/*38*/ BYTE gr_name[8]; /* Sysplex name? */
/*40*/ BYTE resv2[32];
/*60*/} DIAG204_X_PART;


I'm guessing that's no big deal. Whether you access it as a fullword at offset X'24' or as a doubleword at offset X'20', you ultimately end up getting the same thing.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-21 17:10:25 UTC
Permalink
Hi Fish,
I run a 48 LAPR system and I see the correct storage sizes on all LPARs in
Megabytes. I also see a '?' next to Sysplex Name at offset x'38'. I do run
a sysplex and I see the sysplex name at offset X'10'. CPC name is not there.
Best regards,

On Sun, Aug 21, 2016 at 12:19 AM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
> Aaron Finerman wrote:
>
> > Diagnose 204 function x'00010007' in the LPAR structure
> > after the SYSPLEX name, etc. at offset x'24' should be
> > size of the LPAR (4 bytes) in mega bytes (Perhaps MAINSIZE).
> > Hercules returns X'40000000'.
>
> Hmmm... That doesn't match up with Hercules (but then we already know
> that).
>
> Hercules is currently returning storage size in bytes, not megabytes.
> That's an easy fix.
>
> Also, Hercules believes the field to be an 8-byte doubleword field at
> offset X'20, not a 4-byte fullword field at offset X'24':
>
> typedef struct _DIAG204_X_PART {
> /*00*/ BYTE partnum; /* Logical partition number
> starts with 1 */
> /*01*/ BYTE virtcpu; /* Number of virt CP's */
> /*02*/ BYTE realcpu; /* Number of real CP's */
> /*03*/ BYTE pflag;
> /*04*/ FWORD mlu;
> /*08*/ BYTE partname[8]; /* Partition name */
> /*10*/ BYTE cpcname[8]; /* CPC name */
> /*18*/ BYTE osname[8]; /* Operating system type */
> /*20*/ DBLWRD cssize; /* Central storage size */
> /*28*/ DBLWRD essize; /* Expanded Storage size */
> /*30*/ BYTE upid;
> /*31*/ BYTE resv1[3];
> /*34*/ FWORD gr_mlu;
> /*38*/ BYTE gr_name[8]; /* Sysplex name? */
> /*40*/ BYTE resv2[32];
> /*60*/} DIAG204_X_PART;
>
> I'm guessing that's no big deal. Whether you access it as a fullword at
> offset X'24' or as a doubleword at offset X'20', you ultimately end up
> getting the same thing.
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: ***@softdevlabs.com
>
>
>
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-22 20:54:18 UTC
Permalink
Aaron Finerman wrote:

> I run a 48 LPAR system and I see the correct storage sizes
> on all LPARs in Megabytes.

And as of commit af73ce286b0732fc0128a0809b2131abc68a3d10 so does Hyperion now too! :)


> I also see a '?' next to Sysplex Name at offset x'38'. I
> do run a sysplex and I see the sysplex name at offset X'10'.
> CPC name is not there.

Hercules doesn't do sysplexing as far as I know.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
'Peter J. Jansen' peter_j_jansen@yahoo.com [hercules-390]
2016-08-23 14:10:43 UTC
Permalink
If I may 




As of my CTC Enhanced (CTCE) contributions, Hercules does Sysplexing, albeit only in the “Base” variety.



My Hercules setup (working for both Hyperion 4.00 and Spinhawk 3.12) includes a z/OS 1.10 3-member Base Sysplex. Two of these each run on a Windows 10 PC, the 3rd one on a SUSE SLES 12 SP1 PC. Each Hercules is configured with a different LPAR number and name (which z/OS uses for its configuration). The 3 systems all tap into the same NTP, so their time difference is a few ms at most; z/OS is configured using SIMETRID as a time source.



Because also z/VM SSI works fine using the CTCE device, the above 3 systems can also run a z/VM 6.3 SSI cluster, and each of these can actually run the same z/OS Base Sysplex member 2nd level.



This sysplexing is, to the best of my knowledge, only possible on Hercules. I don’t know if zPDT supports CTC’s similar to my CTCE, but I think it lacks the wonderful shared DASD support Hercules has.



In short: Hercules does do sysplexing !



Peter Jansen



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Monday, 22 August, 2016 22:54
To: hercules-***@yahoogroups.com
Subject: RE: [hercules-390] CP vs IFL





Aaron Finerman wrote:

> I run a 48 LPAR system and I see the correct storage sizes
> on all LPARs in Megabytes.

And as of commit af73ce286b0732fc0128a0809b2131abc68a3d10 so does Hyperion now too! :)

> I also see a '?' next to Sysplex Name at offset x'38'. I
> do run a sysplex and I see the sysplex name at offset X'10'.
> CPC name is not there.

Hercules doesn't do sysplexing as far as I know.

--
"Fish" (David B. Trout)
Software Development Laboratories
<http://www.softdevlabs.com> http://www.softdevlabs.com
mail: <mailto:***@softdevlabs.com> ***@softdevlabs.com
hgservers@yahoo.com [hercules-390]
2016-08-23 17:59:53 UTC
Permalink
I thought that Shared DASD was broken in Hyperion?
'Peter J. Jansen' peter_j_jansen@yahoo.com [hercules-390]
2016-08-23 21:10:44 UTC
Permalink
It most definitely is NOT. Hercules shared DASD works as a charm, in both Hyperion and Spinhawk.



Peter J.



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Tuesday, 23 August, 2016 20:00
To: hercules-***@yahoogroups.com
Subject: RE: [hercules-390] CP vs IFL





I thought that Shared DASD was broken in Hyperion?
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-23 21:24:05 UTC
Permalink
On 8/23/2016 11:10 PM, 'Peter J. Jansen' ***@yahoo.com
[hercules-390] wrote:
>
>
> It most definitely is NOT. Hercules shared DASD works as a charm, in
> both Hyperion and Spinhawk.
>
> Peter J.
>
>
I agree it works like a charm, but there was a question that was raised
at one point :

Isn't there a possibility that local DASD caching could lead to
inconsistencies when dealing with shared DASDs ? (Note I've also used
DASD sharing *within* a single hercules instance to emulate a 3880 Dual
Channel Path on a S/370 MP system (by the way we can emulate the S/370
Multiple Channel Sets feature), without any apparent issues)

(There is a very subtle dasd cache issue I am dealing with, but it's not
a show breaker and unrelated with DASD sharing).

--Ivan


[Non-text portions of this message have been removed]
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-24 04:11:01 UTC
Permalink
For those of you who don't know, the Hercules Shared Dasd feature

http://hercules-390.github.io/html/shared.html

allows multiple Hercules instances to access the same set of dasd in a controlled manner. (It's not just for dasd though. Note the above web page is titled "Shared DEVICE Server" (emphasis mine), not DASD.)

My memory regarding its reliability/stability was refreshed off-list by someone who shall remain anonymous but who absolutely positively knows what the frick he's talking about (should be considered an authority on the subject).

The basic poop is as follows:

> > Shared DASD -- as designed -- will normally work in the
> > ***small/casual*** arena, up to a certain point in which
> > load is NOT one of the factors. SYNCIO does not play a
> > known role in shared DASD corruption issues;
>
> So shared dasd under load causes problems and syncio doesn't
> play any role in that. Got it.
>
>
> > there is an architectural issue with shared DASD that causes
> > the corruption.
>
> Yes, that's what I remember you telling me before.
>
>
> > Shared DASD breaks with corruption issues in just a few seconds
> > under diagnostic testing, or certain OS high-performance loads
> > in a variety of subsystems.
>
> Got it. Shared dasd under load == bad.
> Shared dasd casual == probably okay.
>
>
> > SYNCIO still has to be turned off for I/O diagnostic testing
> > to complete properly. The primary reason for the use of SYNCIO
> > is now gone, other than user preference, as the bottlenecks
> > SYNCIO originally addressed have been removed. Under high loads,
> > SYNCIO also becomes a performance detriment.
>
> Got it. SYNCIO == shouldn't break things but isn't useful
> and degrades performance as load increases.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
'Peter J. Jansen' peter_j_jansen@yahoo.com [hercules-390]
2016-08-24 09:12:07 UTC
Permalink
Thanks for making me aware of this problem, but also of the fact that the
device sharing can be used for other devices, e.g. (Hercules emulated) tape
drives.



Would it be possible to obtain a reproducible shared DASD problem scenario
please ? I'd like to investigate and possibly fix the problem if it can be
reproduced.



Peter J.



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Wednesday, 24 August, 2016 06:11
To: hercules-***@yahoogroups.com
Subject: [hercules-390] Reliability of Hercules Shared Dasd Feature





For those of you who don't know, the Hercules Shared Dasd feature

<http://hercules-390.github.io/html/shared.html>
http://hercules-390.github.io/html/shared.html

allows multiple Hercules instances to access the same set of dasd in a
controlled manner. (It's not just for dasd though. Note the above web page
is titled "Shared DEVICE Server" (emphasis mine), not DASD.)

My memory regarding its reliability/stability was refreshed off-list by
someone who shall remain anonymous but who absolutely positively knows what
the frick he's talking about (should be considered an authority on the
subject).

The basic poop is as follows:

> > Shared DASD -- as designed -- will normally work in the
> > ***small/casual*** arena, up to a certain point in which
> > load is NOT one of the factors. SYNCIO does not play a
> > known role in shared DASD corruption issues;
>
> So shared dasd under load causes problems and syncio doesn't
> play any role in that. Got it.
>
>
> > there is an architectural issue with shared DASD that causes
> > the corruption.
>
> Yes, that's what I remember you telling me before.
>
>
> > Shared DASD breaks with corruption issues in just a few seconds
> > under diagnostic testing, or certain OS high-performance loads
> > in a variety of subsystems.
>
> Got it. Shared dasd under load == bad.
> Shared dasd casual == probably okay.
>
>
> > SYNCIO still has to be turned off for I/O diagnostic testing
> > to complete properly. The primary reason for the use of SYNCIO
> > is now gone, other than user preference, as the bottlenecks
> > SYNCIO originally addressed have been removed. Under high loads,
> > SYNCIO also becomes a performance detriment.
>
> Got it. SYNCIO == shouldn't break things but isn't useful
> and degrades performance as load increases.

--
"Fish" (David B. Trout)
Software Development Laboratories
<http://www.softdevlabs.com> http://www.softdevlabs.com
mail: <mailto:***@softdevlabs.com> ***@softdevlabs.com
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-25 13:40:18 UTC
Permalink
Peter J. Jansen wrote:

[...]
> Would it be possible to obtain a reproducible shared DASD
> problem scenario please? I'd like to investigate and possibly
> fix the problem if it can be reproduced.

I don't know, but I'll pass along your request.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-25 13:46:07 UTC
Permalink
On 8/25/2016 3:40 PM, ''Fish' (David B. Trout)' ***@gmail.com
[hercules-390] wrote:
> Peter J. Jansen wrote:
>
> [...]
>> Would it be possible to obtain a reproducible shared DASD
>> problem scenario please? I'd like to investigate and possibly
>> fix the problem if it can be reproduced.
> I don't know, but I'll pass along your request.
>
All,

I think there is no actual issue pertaining to shared DASDs. But it
probably needs to be exercised. Mark Gaubatz did raise the point that
there *MIGHT* be a caching issue when using shared DASD, a conflict
between local cache(s) and shared DASD instance cache, but it might have
been solved in the meantime or might have been a non-issue after all.

I am currently using a Shared DASD architecture with 3 instances... 1 is
an I/O only instance, and 2 hercules instances accessing DASDs on that
I/O only instance (kind of like a SAN infrastructure) and I haven't seen
any issue.. yet...

--Ivan



[Non-text portions of this message have been removed]
'Peter J. Jansen' peter_j_jansen@yahoo.com [hercules-390]
2016-08-24 08:52:50 UTC
Permalink
Thanks for making me aware of this potential DASD sharing problem. I would
have thought that Hercules would do NO local caching at ALL for shared DASD.
Was this assumption wrong ?



If this assumption is wrong, could then the correction not be to ensure that
shared DASD I/O is NOT Hercules cached locally ? To the best of my
knowledge, there is no mechanism for any DASD control unit to signal a 'DASD
cache invalidation' to any connected sharing system, so I think Hercules
local shared DASD caching is just not possible. The only shared DASD caching
possible would be by the OS itself, knowing that certain DASD extents (e.g.
regular datasets) are protected from modification by other systems whilst
ENQ protected. I presume Hercules shared DASD implements RESERVE/RELEASE,
nowadays not used so much anymore because of GRS ( / XCF / XES ).



I have not yet encountered Hercules shared DASD problems, but I have indeed
not exercised heavy OS I/O loads. If I could reproduce known shared DASD
related problems, then I could attempt to find and fix the problems.
Information welcome !



Peter J.



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Tuesday, 23 August, 2016 23:24
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-390] CP vs IFL



[.]

Isn't there a possibility that local DASD caching could lead to
inconsistencies when dealing with shared DASDs ? (Note I've also used
DASD sharing *within* a single hercules instance to emulate a 3880 Dual
Channel Path on a S/370 MP system (by the way we can emulate the S/370
Multiple Channel Sets feature), without any apparent issues)

(There is a very subtle dasd cache issue I am dealing with, but it's not
a show breaker and unrelated with DASD sharing).

--Ivan
hgservers@yahoo.com [hercules-390]
2016-08-25 06:27:19 UTC
Permalink
Alright. Good to know. I was thinking of a thread about MAS from back in February that said something about some modification breaking it... didn't know that that had been fixed.

I had it working with MVS 3.8j (TK3 systems) quite well actually in a three system configuration a couple of years ago with 3.08 IIRC... I'll have to try it again with Hyperion.


---In hercules-***@yahoogroups.com, <***@...> wrote :

It most definitely is NOT. Hercules shared DASD works as a charm, in both Hyperion and Spinhawk.

Peter J.

From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Tuesday, 23 August, 2016 20:00
To: hercules-***@yahoogroups.com
Subject: RE: [hercules-390] CP vs IFL




I thought that Shared DASD was broken in Hyperion?
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-25 14:27:32 UTC
Permalink
In addition to the information regarding the Hercules Shared Device feature presented in the "Reliability of Hercules Shared Dasd Feature" thread (https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/79719), the following information is presented in relation to the SYNCIO dasd device option that was mentioned:


> Analysis of SYNCIO and the Hyperion Channel Updates
>
> SYNCIO was originally designed for slower single core
> systems (processors designed before 2004, at the latest).
> On these systems, not having to create a new device thread
> (or take time for task switching) saved a substantial
> amount of time and significantly improved performance.
>
> In multi-core systems, this advantage is lost, as SYNCIO
> now ties up the CPU thread from performing additional work
> while the I/O operation is being processed (which is the
> complete opposite of the way start-i/o and start-subchannel
> work on mainframes).
>
> With the Hyperion channel updates done by Mark Gaubatz,
> the wait time for an available device thread was virtually
> eliminated. Once running, the channel subsystem now
> executes nearly 100% of queued I/O requests without having
> to wait for thread creation. If a device thread is available,
> but waiting, execution will begin within 100ms at the outside,
> should a signal_condition status be cleared before response
> (a hole in the Posix definition/operation of signal_condition).
>
> When thread creation is required, the next entering or exiting
> I/O will cause an additional thread to be created if the queue
> is not empty after dequeuing the next I/O request, as well as
> the queuing mechanism itself creating a new device thread early
> when an out-of-threads condition is detected. This also pre-
> vents a rush of new concurrent thread requests tying up critical
> kernel code paths and effectively stopping all other productive
> use of the machine (observed on both Linux and Windows).
>
> It has been observed that the 100ms limit also keeps the idle
> device tasks active in the various schedulers, without placing
> them on a true idle list, from which it may take significantly
> longer to redispatch under some Windows and Linux setups.
>
> Device threads are not terminated unless they have been idle
> for at least two seconds, are not subject to user's devtmax
> setting (but always subject to devtmax -1, another holdover),
> and there are more than four idle threads. For devtmax > 0,
> devtmax threads are maintained, once created. Changing the
> devtmax value on the fly will permit the creation of additional
> device threads, or trimming of existing threads once their
> respective I/O have completed, or are idle.
>
> This design also keeps the device subsystem from surging,
> ramping up to the demand and then dropping the "excess" threads
> too quickly, only to have another burst of I/O activity create
> another round of device-thread thread creation and immediate
> trimming. It is possible that three additional tuning "knobs"
> could be added: first to define the minimum number of threads
> to maintain for devtmax 0, second, to specify an idle time
> before excess thread trimming is triggered, and finally, what
> value constitutes "excess" (the current default is four).
>
> Operational Notes:
>
> * For Windows, devtmax > 0 should ALWAYS be specified;
> if Hercules is in operation long enough with heavy dynamic
> I/O loads and devtmax -1 and 0, Hercules will crash Windows
> due to the number of threads created and destroyed. This
> condition has been seen on Windows 7, 8, & 8.1, but has
> not yet been verified on Windows 10. On an early Intel
> Core i7 laptop with plenty of resources, the condition
> can be raised in as little as 3.5 days on Windows 7 using
> devtmax 0; this limit was hit using an 8-core Intel Xeon
> system from 2008 in less than 40 hours.
>
> * For performance with heavy I/O loads, don't define more
> than 3/4 of the real cores as a CPU engine type; you may
> still need to further reduce the number of CPU engines
> and/or use devtmax > 0 to maintain enough freedom for
> the host operating system to not panic and thrash under
> the load.
>
> * For planning purposes, a hyperthreaded core is roughly
> equal to 0.20-0.33 real cores. Core i7 laptops should
> not be run at more than roughly 70-75% of total capability
> for long periods of time, depending on the cooling
> capabilities of the laptop (clock frequency adjustments
> takes place to regulate the operational temperature of
> the chip, resulting in unwanted thermal cycling, along
> with irregular response and performance times). Higher
> performance may be achieved WITHOUT hyperthreading, and
> thermal cycling may not occur as frequently, permitting
> operation at a higher percentage of total capability.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-23 19:53:38 UTC
Permalink
***@yahoo.com wrote:

> I thought that Shared DASD was broken in Hyperion?

I can't recall the specifics but I believe the SYNCIO played a role in whether it worked or not or perhaps how well it worked (or something like that).

In any case I do know that our current implementation does not conform to known I/O architecture specifications and caused much trouble during attempts to make Hyperion's I/O subsystem more architecturally compliant, and may have been purposely disabled for a short time.

But it most definitely is enabled by default today (as is SYNCIO too), and, as far as I know, has been for quite some time now.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-23 19:42:41 UTC
Permalink
Peter Jansen wrote:

<chomp!>
> In short: Hercules does do sysplexing !
>
> Peter Jansen

(Ack!) A thousand pardons, Peter! I had forgotten about all your hard work in that area! I am VERY sorry about that! Please accept my most *sincere* apology!

:(

(I feel absolutely *terrible* about this!)

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-22 02:01:43 UTC
Permalink
Hi Fish,
I did a little bit of digging and found out that the storage size can
remain in bytes at double word x'20', but the flag at x'03' has to be set
to x'10'. Considering VM Diag 204 and SERVC Read Configuration return this
data in Megabytes, it would make more sense to provide it in Megs.
Best regards,

On Sun, Aug 21, 2016 at 12:19 AM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
> Aaron Finerman wrote:
>
> > Diagnose 204 function x'00010007' in the LPAR structure
> > after the SYSPLEX name, etc. at offset x'24' should be
> > size of the LPAR (4 bytes) in mega bytes (Perhaps MAINSIZE).
> > Hercules returns X'40000000'.
>
> Hmmm... That doesn't match up with Hercules (but then we already know
> that).
>
> Hercules is currently returning storage size in bytes, not megabytes.
> That's an easy fix.
>
> Also, Hercules believes the field to be an 8-byte doubleword field at
> offset X'20, not a 4-byte fullword field at offset X'24':
>
> typedef struct _DIAG204_X_PART {
> /*00*/ BYTE partnum; /* Logical partition number
> starts with 1 */
> /*01*/ BYTE virtcpu; /* Number of virt CP's */
> /*02*/ BYTE realcpu; /* Number of real CP's */
> /*03*/ BYTE pflag;
> /*04*/ FWORD mlu;
> /*08*/ BYTE partname[8]; /* Partition name */
> /*10*/ BYTE cpcname[8]; /* CPC name */
> /*18*/ BYTE osname[8]; /* Operating system type */
> /*20*/ DBLWRD cssize; /* Central storage size */
> /*28*/ DBLWRD essize; /* Expanded Storage size */
> /*30*/ BYTE upid;
> /*31*/ BYTE resv1[3];
> /*34*/ FWORD gr_mlu;
> /*38*/ BYTE gr_name[8]; /* Sysplex name? */
> /*40*/ BYTE resv2[32];
> /*60*/} DIAG204_X_PART;
>
> I'm guessing that's no big deal. Whether you access it as a fullword at
> offset X'24' or as a doubleword at offset X'20', you ultimately end up
> getting the same thing.
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: ***@softdevlabs.com
>
>
>
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-22 20:58:46 UTC
Permalink
Aaron Finerman wrote:

> I did a little bit of digging and found out that the
> storage size can remain in bytes at double word x'20',
> but the flag at x'03' has to be set to x'10'.

Do you have any information of what the other flag bits are and what they mean?


> Considering VM Diag 204 and SERVC Read Configuration
> return this data in Megabytes, it would make more sense
> to provide it in Megs.

I agree.

And as mentioned in my previous reply Hercules now correctly reports the value in megabytes too (as of commit af73ce286b0732fc0128a0809b2131abc68a3d10).

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
hgservers@yahoo.com [hercules-390]
2016-08-21 00:50:28 UTC
Permalink
http://marc.info/?l=linux-390&m=140511806409406&w=2

Looks like a z/VM exclusive instruction?
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-08-21 01:34:04 UTC
Permalink
On 8/21/2016 2:50 AM, ***@yahoo.com [hercules-390] wrote:
> http://marc.info/?l=linux-390&m=140511806409406&w=2
>
> Looks like a z/VM exclusive instruction?
>
>
hercules is known for implementing a limited set of z/VM CP diagnose
instructions.

One of the objective was to be able to run z/Arch Solaris on hercules
without needing z/VM.

Since the Poo doesn't give any guidelines as to what the DIAG
instruction does (it may even break any guideline given in the rest of
the manual), there is nothing wrong with implementing anything we want.

--Ivan



[Non-text portions of this message have been removed]
Aaron Finerman arfinerman@gmail.com [hercules-390]
2016-08-21 01:07:49 UTC
Permalink
It would be very surprising. Because zVM only instructions (like IUCV B2F0)
don't make it in to the Principles of Operation.
Best regards,

On Sat, Aug 20, 2016 at 8:50 PM, ***@yahoo.com [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> http://marc.info/?l=linux-390&m=140511806409406&w=2
>
> Looks like a z/VM exclusive instruction?
>
>
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2016-08-21 08:20:36 UTC
Permalink
On 08/21/2016 03:07 AM, Aaron Finerman ***@gmail.com
[hercules-390] wrote:
>
>
> It would be very surprising. Because zVM only instructions (like IUCV
> B2F0) don't make it in to the Principles of Operation.

Ah, but they are there. It is just that IBM suppresses them in the
published version of the document. You typically see them in appendix B
for a short while when something went awry with the conditional
processing. I've also seen the IUCV and LDSF external interrupt codes.

For STHYI, See p. xxviii (Bibliography).

10. The store-hypervisor-information facility is
described in the publication z/VM CP Program-
ming Services (SC24-6179).

And p. 4-77 (facility bits).

74
The store-hypervisor-information facility is installed
in the z/Architecture architectural mode (see
Reference [10.] on page xxviii).


> Best regards,
>
> On Sat, Aug 20, 2016 at 8:50 PM, ***@yahoo.com
> <mailto:***@yahoo.com> [hercules-390]
> <hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com>> wrote:
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2016-08-20 01:54:38 UTC
Permalink
Fish wrote:
> Aaron Finerman wrote:

[...]
> > Hi Fish, Code 3 should definitely stay as 'IFL'.
> > It is code 1 and 4 that should be swapped.
[...]
>
> Thanks. I'll go ahead and make that change right away.

Done! Fixed in commit 57a48425d83335ae293e21f5dbb4de95bf340eea.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Loading...