[hercules-390] Instruction leakage into 370 mode.

['John P. Hartmann' [e-mail] [hercules-390]]

I am validating the crypto instructions against the various PoO manuals
on Hyperion (aka Hercules version 4).

It turns out that a correctly formatted KM in 370 architecture mode
behaves as if the architecture mode is ESA. (And a slew of other
instructions do likewise).

As for 360, the Ex instructions were assigned to emulators. If someone
opens Hyperion out of the box, runs DOS and starts the 1401 emulator,
that person should receive a message about the lack of emulator hardware
support, not some totally random permutation of the contents of storage
and registers. (And I'll not be dragged into a discussion of whether E9
was the 1401 emulator; perhaps it was the 1620 emulator... or some other
one... or the widely implemented SPO--Stop and Punch Operator.)

This will be fixed in the fullness of time as I build test cases that
fail to program check. Unless someone convinces me he will implement an
ARCHLVL for such abominations and thus restore out-of-box behaviour to
the expected state.

If you think the current behaviour of Hyperion is cute, now is the time
to create your own fork of Hyperion (or stick with spinhawk).

[Ivan Warren [e-mail] [hercules-390]]

On 1/6/2017 7:34 PM, 'John P. Hartmann' ***@gmail.com
[hercules-390] wrote:
> I am validating the crypto instructions against the various PoO manuals
> on Hyperion (aka Hercules version 4).
>
> It turns out that a correctly formatted KM in 370 architecture mode
> behaves as if the architecture mode is ESA. (And a slew of other
> instructions do likewise).
>
Why ?

There are NO indication in any of the the various POPs that any
instruction not described in the manual should generate an Operation
Exception ! I think they even include a programming note that DOES
specifically say that no program should rely on a PIC 1 being generated
when an opcode not defined in the manual is executed.

The only exception was introduced in a late z/Arch POP that specifies
that opcode X'00' will generate an operation exception (PIC 1). All the
others specify that there is great chance that no instruction will ever
be assigned to opcode X'00' and that it *MAY* generate a PIC 1....

SA22-7832-10
Page 6-30 on Operation Exception, Programming note : (some equivalent
wording exists in GA22-7000 and the ESA POP)

****
1. Some models may offer instructions not
described in this publication, such as those provided
for assists or as part of special or custom
features. Consequently, operation codes not
described in this publication do not necessarily
cause an operation exception to be recognized.
Furthermore, these instructions may cause
modes of operation to be set up or may otherwise
alter the machine so as to affect the execution
of subsequent instructions. To avoid causing
such an operation, an instruction with an operation
code not described in this publication should
be executed only when the specific function
associated with the operation code is desired.
2. Operation code 00 hex will never be assigned to
an instruction implemented in the CPU.
****

So why cull anything - Implementing an ESA or even z/Arch instructions
in S/370 mode (provided it is compatible) is NOT an issue and does NOT
contradict the manual.

--Ivan



[Non-text portions of this message have been removed]

[Joe Monk [e-mail] [hercules-390]]

Page 78 of A22-6821-0:

"When an operation code is not assigned or the assigned operation is not
available on the particular model, an operation exception is recognized.
The operation is suppressed.

The instruction-length code is 1, 2, or 3."

So an attempt to execute an opcode in an invalid architecture mode should
cause an OPEX in my opinion.

Joe

On Fri, Jan 6, 2017 at 1:16 PM, Ivan Warren ***@vmfacility.fr
[hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
>
>
> On 1/6/2017 7:34 PM, 'John P. Hartmann' ***@gmail.com
> [hercules-390] wrote:
> > I am validating the crypto instructions against the various PoO manuals
> > on Hyperion (aka Hercules version 4).
> >
> > It turns out that a correctly formatted KM in 370 architecture mode
> > behaves as if the architecture mode is ESA. (And a slew of other
> > instructions do likewise).
> >
> Why ?
>
> There are NO indication in any of the the various POPs that any
> instruction not described in the manual should generate an Operation
> Exception ! I think they even include a programming note that DOES
> specifically say that no program should rely on a PIC 1 being generated
> when an opcode not defined in the manual is executed.
>
> The only exception was introduced in a late z/Arch POP that specifies
> that opcode X'00' will generate an operation exception (PIC 1). All the
> others specify that there is great chance that no instruction will ever
> be assigned to opcode X'00' and that it *MAY* generate a PIC 1....
>
> SA22-7832-10
> Page 6-30 on Operation Exception, Programming note : (some equivalent
> wording exists in GA22-7000 and the ESA POP)
>
> ****
> 1. Some models may offer instructions not
> described in this publication, such as those provided
> for assists or as part of special or custom
> features. Consequently, operation codes not
> described in this publication do not necessarily
> cause an operation exception to be recognized.
> Furthermore, these instructions may cause
> modes of operation to be set up or may otherwise
> alter the machine so as to affect the execution
> of subsequent instructions. To avoid causing
> such an operation, an instruction with an operation
> code not described in this publication should
> be executed only when the specific function
> associated with the operation code is desired.
> 2. Operation code 00 hex will never be assigned to
> an instruction implemented in the CPU.
> ****
>
> So why cull anything - Implementing an ESA or even z/Arch instructions
> in S/370 mode (provided it is compatible) is NOT an issue and does NOT
> contradict the manual.
>
> --Ivan
>
> [Non-text portions of this message have been removed]
>
>
>

[Ivan Warren [e-mail] [hercules-390]]

On 1/6/2017 8:58 PM, Joe Monk ***@gmail.com [hercules-390] wrote:
>
>
> Page 78 of A22-6821-0:
>
> "When an operation code is not assigned or the assigned operation is
> not available on the particular model, an operation exception is
> recognized. The operation is suppressed.
>
> The instruction-length code is 1, 2, or 3."
>
> So an attempt to execute an opcode in an invalid architecture mode
> should cause an OPEX in my opinion.
>
> Joe
>
>
Joe,

On a particular "MODEL" (not "architecture") - that's the keyword...
hercules is a specific model on its own - and hence is allowed to have
its own additional facilities and additional instructions in whatever
architecture mode it is running.

Only 1 opcode is pretty much guaranteed to generate a PIC 1 : That's
opcode X'00'.

--Ivan


[Non-text portions of this message have been removed]

[Joe Monk [e-mail] [hercules-390]]

Models belong to architectures. A 360/30 is not the same as a 370/158 which
is not the same as 3090. We dont call them a Model 30 ... we call it a
360/30, which ties it to the 360 architecture.

So if I want to run in 360/30 mode, the instructions from a 3090 should
cause an opex, in my opinion.

Joe

On Fri, Jan 6, 2017 at 2:14 PM, Ivan Warren ***@vmfacility.fr
[hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
>
>
> On 1/6/2017 8:58 PM, Joe Monk ***@gmail.com [hercules-390] wrote:
> >
> >
> > Page 78 of A22-6821-0:
> >
> > "When an operation code is not assigned or the assigned operation is
> > not available on the particular model, an operation exception is
> > recognized. The operation is suppressed.
> >
> > The instruction-length code is 1, 2, or 3."
> >
> > So an attempt to execute an opcode in an invalid architecture mode
> > should cause an OPEX in my opinion.
> >
> > Joe
> >
> >
> Joe,
>
> On a particular "MODEL" (not "architecture") - that's the keyword...
> hercules is a specific model on its own - and hence is allowed to have
> its own additional facilities and additional instructions in whatever
> architecture mode it is running.
>
> Only 1 opcode is pretty much guaranteed to generate a PIC 1 : That's
> opcode X'00'.
>
> --Ivan
>
> [Non-text portions of this message have been removed]
>
>
>

[Ivan Warren [e-mail] [hercules-390]]

On 1/6/2017 9:27 PM, Joe Monk ***@gmail.com [hercules-390] wrote:
>
>
> Models belong to architectures. A 360/30 is not the same as a 370/158
> which is not the same as 3090. We dont call them a Model 30 ... we
> call it a 360/30, which ties it to the 360 architecture.
>
> So if I want to run in 360/30 mode, the instructions from a 3090
> should cause an opex, in my opinion.
>
> Joe
>
Hercules is none of those...

Further more, all IBM manufactured machines implemented instructions and
facilities not described in the respective PoPs...

Having XA, ESA or even z/Arch which are architecturally correct in say
S/370 doesn't break anything. It just falls under the "model dependent"
clause.

--Ivan


[Non-text portions of this message have been removed]

['John P. Hartmann' [e-mail] [hercules-390]]

The rules of engagement here forbids me to say what hercules *is*; some
of us want it to get closer to what one would want it to be. Some
Hyperion users, I am sure, do not wish the embarrassment of their
programs failing for one reason or another when they hit real iron.

For 360, I'd say that unless the machine had emulators and/or RPQs, the
machine repertoire was identical to the PoO.

Various ECPS assist snuck into /370. They were, for VM at least,
documented in the CP source code.

So, Ivan, you're doing ARCHLEVEL S370X?

For you bystanders, this is not as trivial as it sounds.

On 06/01/17 21:28, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
> Hercules is none of those...


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

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

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/

[Ivan Warren [e-mail] [hercules-390]]

On 1/6/2017 10:43 PM, 'John P. Hartmann' ***@gmail.com
[hercules-390] wrote:
> The rules of engagement here forbids me to say what hercules *is*; some
> of us want it to get closer to what one would want it to be. Some
> Hyperion users, I am sure, do not wish the embarrassment of their
> programs failing for one reason or another when they hit real iron.
>
> For 360, I'd say that unless the machine had emulators and/or RPQs, the
> machine repertoire was identical to the PoO.
>
> Various ECPS assist snuck into /370. They were, for VM at least,
> documented in the CP source code.
>
> So, Ivan, you're doing ARCHLEVEL S370X?
>
> For you bystanders, this is not as trivial as it sounds.
>
John,

S370x already exists... You just need to ldmod it in the config file.

--Ivan



[Non-text portions of this message have been removed]

['John P. Hartmann' [e-mail] [hercules-390]]

Pick another name, then. And what do I load to get the unadulterated
370 back?

On 06/01/17 21:47, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
> John,
>
> S370x already exists... You just need to ldmod it in the config file.


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

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

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/

[Ivan Warren [e-mail] [hercules-390]]

On 1/6/2017 10:49 PM, 'John P. Hartmann' ***@gmail.com
[hercules-390] wrote:
> Pick another name, then. And what do I load to get the unadulterated
> 370 back?
Don't load s370x...

--Ivan



[Non-text portions of this message have been removed]

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

> And what do I load to get the unadulterated 370 back?

The opposite of "ldmod s37x": rmmod s37x! Duh!

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

['John P. Hartmann' [e-mail] [hercules-390]]

I did not load any modules. And KM does not program check in 370
architecture mode, as it should..

So what should I have done?

On 06/01/17 22:57, ''Fish' (David B. Trout)' ***@gmail.com
[hercules-390] wrote:
>
>
>> And what do I load to get the unadulterated 370 back?
>
> The opposite of "ldmod s37x": rmmod s37x! Duh!
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: ***@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

<*> 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/

[Ivan Warren [e-mail] [hercules-390]]

On 1/7/2017 12:35 AM, 'John P. Hartmann' ***@gmail.com
[hercules-390] wrote:
> I did not load any modules. And KM does not program check in 370
> architecture mode, as it should..
>
> So what should I have done?
>
>
Tell me .. again.. WHERE does it say in the PoP that KM should program
check ?

--Ivan



[Non-text portions of this message have been removed]

['John P. Hartmann' [e-mail] [hercules-390]]

C'm on Ivan. No 370 had any crypto. In fact, most of the algorithms
were not yet discovered at the time. Though I'll grant you that one
could get a 145/8 with a lucifer chip.

You've even been been voted down as to the usefulness/desirability of
your pet idiosyncrasy.

For the benefit of the bystanders, my original announcement was one of
policy; it was not a request for discussion. That discussion has
already taken place (and Ivan said the same then too).

On 06/01/17 23:42, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
>
>
>
>
> On 1/7/2017 12:35 AM, 'John P. Hartmann' ***@gmail.com
> [hercules-390] wrote:
>> I did not load any modules. And KM does not program check in 370
>> architecture mode, as it should..
>>
>> So what should I have done?
>>
>>
> Tell me .. again.. WHERE does it say in the PoP that KM should program
> check ?
>
> --Ivan
>
> [Non-text portions of this message have been removed]
>
>


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

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

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/

[Tony Harminc [e-mail] [hercules-390]]

On 6 January 2017 at 18:53, 'John P. Hartmann' ***@gmail.com wrote:
> For the benefit of the bystanders, my original announcement was one of
> policy; it was not a request for discussion. That discussion has
> already taken place (and Ivan said the same then too).

Bystanders? So corporate policy is set without regard to those
annoying customers, or end users, or others who have been around for
15 years or so.

I get enough of this kind of attitude at my day job.

Sounds a lot like IBM... :-(

Tony H.

[Ivan Warren [e-mail] [hercules-390]]

On 1/7/2017 12:53 AM, 'John P. Hartmann' ***@gmail.com
[hercules-390] wrote:
> C'm on Ivan. No 370 had any crypto. In fact, most of the algorithms
> were not yet discovered at the time. Though I'll grant you that one
> could get a 145/8 with a lucifer chip.
There sure is : It's called... hercules ! It's a S/370 implementation
which implements GA22-7000 (up to a certain point - some optional
features just cannot be implemented or make no sense) and *ALSO*
implements crypto, and various features while still abiding to GA22-7000
architectural constraints. I'm certain a 4381, 308x or 3090 running in
S/370 mode (or ran a PR/SM LPAR in S/370 mode) implemented a lot of XA
and/or ESA features which weren't described in GA22-7000.... the same
for pre-z virtual machines running on XA/ESA systems in S/370 mode... Or
in XA/ESA/S390 mode on a z Machine (this one already hit us on the head
several times - and it's not only limited to the "N3" instruction set).

So going from a S/370 model 115 and to a G5, a MP3K, a [PR]/390 running
a S/370 virtual machine under VM/ESA you are going to get a whole
different set of results. The only constant is they will ALL obey the
constraints given by the relevant Principle of Operations (and so does
hercules - that is just yet another implementation).

(And we can't even emulate any S/370 1x5 models since it would require
stripping it out of DAT - it might be possible but would require a
special build and probably hasn't been attempted in a while).

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

>> On 06/01/17 22:57, ''Fish' (David B. Trout)' ***@... mailto:***@... [hercules-390] wrote:
>>

>>

>>> And what do I load to get the unadulterated 370 back?

>>

>> The opposite of "ldmod s37x": rmmod s37x! Duh!

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

>

> I did not load any modules. And KM does not program check in 370

> architecture mode, as it should..

>

> So what should I have done?

>
John


If you are inclined to, you normally find out quickly what's wrong. So I'm a bit surprised that this isn't the case here... well, may be you were not exactly inclined to .


Anyway: It's clear that dyncrypt must have been loaded when you didn't receive the expected program check. Perhaps you might want to issue the "lsmod" command at the Hercules console to check? Note, that in Hyperion an "ldmod dyncrypt" command is issued automagically after initialization, which may be the reason why you had it loaded.


To get a clean S/370 system initially one can easily remove this magic from hdl.c or, as I did in TK4- Hercules, introduce a build option (I named it OPTION_PRELOAD_DYNCRYPT) to control this Initial loading.


I just gave your KM fc0 test a quick try on TK4- Hercules (used TK4- Hercules as an example only, any Hyperion incarnation configured the same way will behave the same way; I simply didn't want to build Hyperion for that simple test). The result is as expected: KM program checks out of the box, works fine once dyncrypt is explicitly loaded and program checks again after unloading dyncrypt.


Here an excerpt of the Hercules console log:


11:33:44 HHC01413I Hercules version 4.00

11:33:44 HHC01414I (c) Copyright 1999-2012 by Roger Bowler, Jan Jaeger, and others

11:33:44 HHC01415I Built on Jun 26 2016 at 22:04:26

11:33:44 HHC01416I Build information:

11:33:44 HHC01417I Windows (MSVC) build for AMD64

11:33:44 HHC01417I Hercules for TK4- (64-bit Windows)

\

> most initialization messages skipped

/

11:33:44 HHC01417I Running on HPM9180 Windows-6.1.7601. 7 Enterprise Edition 64-bit, Intel(R) x64 LP=4,
Cores=4, CPUs=1

\

> run s/370 variant of John's KM fc0 test

/

11:34:37 HHC01603I script local_scripts\testkm

11:34:37 HHC02260I Script 3: begin processing file local_scripts/testkm

11:34:37 HHC01603I * KM fc0

11:34:37 HHC01603I stopall

11:34:38 HHC01603I sysclear

11:34:38 HHC02311I sysclear completed

11:34:38 HHC01603I archmode s/370

\

> Program definition skipped

/

11:34:38 HHC01603I ostailor null

11:34:38 HHC01603I restart

11:34:38 HHC02228I Key restart pressed

11:34:38 HHC00801I Processor CP00: Operation exception code 0001 ilc 4

11:34:38 PSW=0008000000000218 INST=B92E0024 KM 2,4 cipher_message

11:34:38 R:00000000:K:06=00080000 00000200 00000000 00000000 ................

11:34:38 R:00000000:K:06=00080000 00000200 00000000 00000000 ................

11:34:38 GR00=00000000 GR01=00000500 GR02=00000000 GR03=00000000

11:34:38 GR04=00000000 GR05=00000000 GR06=00000000 GR07=00000000

11:34:38 GR08=00000000 GR09=00000000 GR10=00000000 GR11=00000000

11:34:38 GR12=00000000 GR13=00000000 GR14=00000000 GR15=00000000

11:34:38 HHC00809I Processor CP00: disabled wait state 000A0000 0000DEAD

11:34:39 HHC01603I * Display parameter block

11:34:39 HHC01603I r 500.f

11:34:39 HHC02290I R:00000500:K:06=00010203 04050607 08090A0B 0C0D0E0F ................

11:34:39 HHC01603I * Expected result


11:34:39 HHC01603I r 580.f

11:34:39 HHC02290I R:00000580:K:06=F0703838 00002828 00000000 00000000 0...............

11:34:39 HHC02264I Script 3: file local_scripts\testkm processing ended

\

> load dyncrypt

/

11:34:52 HHC01603I ldmod dyncrypt

11:34:52 HHC01526I HDL: loading module dyncrypt...

11:34:52 HHC00150I Crypto module loaded (c) Copyright 2003-2015 by Bernard van der Helm

11:34:52 HHC00151I Activated facility: Message Security Assist

11:34:52 HHC00151I Activated facility: Message Security Assist Extension 1, 2, 3 and 4

11:34:52 HHC01527I HDL: module dyncrypt loaded

\

> run s/370 variant of John's KM fc0 test again, dyncrypt is now loaded

/

11:34:56 HHC01603I script local_scripts\testkm

11:34:56 HHC02260I Script 4: begin processing file local_scripts/testkm

11:34:56 HHC01603I * KM fc0

11:34:56 HHC01603I stopall

11:34:58 HHC01603I sysclear

11:34:58 HHC02311I sysclear completed

11:34:58 HHC01603I archmode s/370

\

> Program definition skipped

/

11:34:58 HHC01603I ostailor null

11:34:58 HHC01603I restart

11:34:58 HHC02228I Key restart pressed

11:34:58 HHC00809I Processor CP00: disabled wait state 000A0000 00ABCDEF

11:34:59 HHC01603I * Display parameter block

11:34:59 HHC01603I r 500.f

11:34:59 HHC02290I R:00000500:K:06=F0703838 00002828 00000000 00000000 0...............

11:34:59 HHC01603I * Expected result

11:34:59 HHC01603I r 580.f

11:34:59 HHC02290I R:00000580:K:06=F0703838 00002828 00000000 00000000 0...............

11:34:59 HHC02264I Script 4: file local_scripts\testkm processing ended

\

> unload dyncrypt

/

11:35:16 HHC01603I rmmod dyncrypt

11:35:16 HHC01528I HDL: unloading module dyncrypt...

11:35:16 HHC01529I HDL: module dyncrypt unloaded

\

> run s/370 variant of John's KM fc0 test again, dyncrypt no longer loaded

/

11:35:19 HHC01603I script local_scripts\testkm

11:35:19 HHC02260I Script 5: begin processing file local_scripts/testkm

11:35:19 HHC01603I * KM fc0

11:35:19 HHC01603I stopall

11:35:20 HHC01603I sysclear

11:35:20 HHC02311I sysclear completed

11:35:20 HHC01603I archmode s/370

\

> Program definition skipped

/

11:35:20 HHC01603I ostailor null

11:35:20 HHC01603I restart

11:35:20 HHC02228I Key restart pressed

11:35:20 HHC00801I Processor CP00: Operation exception code 0001 ilc 4

11:35:20 PSW=0008000000000218 INST=B92E0024 KM 2,4 cipher_message

11:35:20 R:00000000:K:06=00080000 00000200 00000000 00000000 ................

11:35:20 R:00000000:K:06=00080000 00000200 00000000 00000000 ................

11:35:20 GR00=00000000 GR01=00000500 GR02=00000000 GR03=00000000

11:35:20 GR04=00000000 GR05=00000000 GR06=00000000 GR07=00000000

11:35:20 GR08=00000000 GR09=00000000 GR10=00000000 GR11=00000000

11:35:20 GR12=00000000 GR13=00000000 GR14=00000000 GR15=00000000

11:35:20 HHC00809I Processor CP00: disabled wait state 000A0000 0000DEAD

11:35:21 HHC01603I * Display parameter block

11:35:21 HHC01603I r 500.f

11:35:21 HHC02290I R:00000500:K:06=00010203 04050607 08090A0B 0C0D0E0F ................

11:35:21 HHC01603I * Expected result

11:35:21 HHC01603I r 580.f

11:35:21 HHC02290I R:00000580:K:06=F0703838 00002828 00000000 00000000 0...............

11:35:21 HHC02264I Script 5: file local_scripts\testkm processing ended



Cheers
JÃŒrgen

['John P. Hartmann' [e-mail] [hercules-390]]

Have a look in opcode.c, JÃŒrgen. That's where the damage is.

dyncrypt has to be loaded to provide the instructions in ESA and Z.

The question was rhetorical. The answer is, Hell no. We the
yammerheads don't want anything near real hardware, so you will have to
suffer--it is our ball.

But do these people contribute to enhancing the quality of Hyperion?
Hell, no!

On 07/01/17 11:19, ***@id.ethz.ch [hercules-390] wrote:
>
>
>>> On 06/01/17 22:57, ''Fish' (David B. Trout)' ***@..._
> <mailto:***@...> [hercules-390] wrote:
>
>>>
>>>
>>>> And what do I load to get the unadulterated 370 back?
>>>
>>> The opposite of "ldmod s37x": rmmod s37x! Duh!
>>>
>>
>
>> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
>>
>
>> I did not load any modules. And KM does not program check in 370
>> architecture mode, as it should..
>>
>> So what should I have done?
>>
> John
>
> If you are inclined to, you normally find out quickly what's wrong. So
> I'm a bit surprised that this isn't the case here... well, may be you
> were not exactly inclined to .
>
> Anyway: It's clear that dyncrypt must have been loaded when you didn't
> receive the expected program check. Perhaps you might want to issue the
> "lsmod" command at the Hercules console to check? Note, that in Hyperion
> an "ldmod dyncrypt" command is issued automagically after
> initialization, which may be the reason why you had it loaded.
>
> To get a clean S/370 system initially one can easily remove this magic
> from hdl.c or, as I did in TK4- Hercules, introduce a build option (I
> named it OPTION_PRELOAD_DYNCRYPT) to control this Initial loading.
>
> I just gave your KM fc0 test a quick try on TK4- Hercules (used TK4-
> Hercules as an example only, any Hyperion incarnation configured the
> same way will behave the same way; I simply didn't want to build
> Hyperion for that simple test). The result is as expected: KM program
> checks out of the box, works fine once dyncrypt is explicitly loaded and
> program checks again after unloading dyncrypt.
>
> Here an excerpt of the Hercules console log:
>
> 11:33:44 HHC01413I Hercules version 4.00
> 11:33:44 HHC01414I (c) Copyright 1999-2012 by Roger Bowler, Jan Jaeger,
> and others
> 11:33:44 HHC01415I Built on Jun 26 2016 at 22:04:26
> 11:33:44 HHC01416I Build information:
> 11:33:44 HHC01417I Windows (MSVC) build for AMD64
> 11:33:44 HHC01417I Hercules for TK4- (64-bit Windows)
> \
> > most initialization messages skipped
> /
> 11:33:44 HHC01417I Running on HPM9180 Windows-6.1.7601. 7 Enterprise
> Edition 64-bit, Intel(R) x64 LP=4,
> Cores=4, CPUs=1
> \
> > run s/370 variant of John's KM fc0 test
> /
> 11:34:37 HHC01603I script local_scripts\testkm
> 11:34:37 HHC02260I Script 3: begin processing file local_scripts/testkm
> 11:34:37 HHC01603I * KM fc0
> 11:34:37 HHC01603I stopall
> 11:34:38 HHC01603I sysclear
> 11:34:38 HHC02311I sysclear completed
> 11:34:38 HHC01603I archmode s/370
> \
> > Program definition skipped
> /
> 11:34:38 HHC01603I ostailor null
> 11:34:38 HHC01603I restart
> 11:34:38 HHC02228I Key restart pressed
> 11:34:38 HHC00801I Processor CP00: Operation exception code 0001 ilc 4
> 11:34:38 PSW=0008000000000218 INST=B92E0024 KM
> 2,4 cipher_message
> 11:34:38 R:00000000:K:06=00080000 00000200 00000000 00000000
> ................
> 11:34:38 R:00000000:K:06=00080000 00000200 00000000 00000000
> ................
> 11:34:38 GR00=00000000 GR01=00000500 GR02=00000000 GR03=00000000
> 11:34:38 GR04=00000000 GR05=00000000 GR06=00000000 GR07=00000000
> 11:34:38 GR08=00000000 GR09=00000000 GR10=00000000 GR11=00000000
> 11:34:38 GR12=00000000 GR13=00000000 GR14=00000000 GR15=00000000
> 11:34:38 HHC00809I Processor CP00: disabled wait state 000A0000 0000DEAD
> 11:34:39 HHC01603I * Display parameter block
> 11:34:39 HHC01603I r 500.f
> 11:34:39 HHC02290I R:00000500:K:06=00010203 04050607 08090A0B 0C0D0E0F
> ................
> 11:34:39 HHC01603I * Expected result
> 11:34:39 HHC01603I r 580.f
> 11:34:39 HHC02290I R:00000580:K:06=F0703838 00002828 00000000 00000000
> 0...............
> 11:34:39 HHC02264I Script 3: file local_scripts\testkm processing ended
> \
> > load dyncrypt
> /
> 11:34:52 HHC01603I ldmod dyncrypt
> 11:34:52 HHC01526I HDL: loading module dyncrypt...
> 11:34:52 HHC00150I Crypto module loaded (c) Copyright 2003-2015 by
> Bernard van der Helm
> 11:34:52 HHC00151I Activated facility: Message Security Assist
> 11:34:52 HHC00151I Activated facility: Message Security Assist Extension
> 1, 2, 3 and 4
> 11:34:52 HHC01527I HDL: module dyncrypt loaded
> \
> > run s/370 variant of John's KM fc0 test again, dyncrypt is now loaded
> /
> 11:34:56 HHC01603I script local_scripts\testkm
> 11:34:56 HHC02260I Script 4: begin processing file local_scripts/testkm
> 11:34:56 HHC01603I * KM fc0
> 11:34:56 HHC01603I stopall
> 11:34:58 HHC01603I sysclear
> 11:34:58 HHC02311I sysclear completed
> 11:34:58 HHC01603I archmode s/370
> \
> > Program definition skipped
> /
> 11:34:58 HHC01603I ostailor null
> 11:34:58 HHC01603I restart
> 11:34:58 HHC02228I Key restart pressed
> 11:34:58 HHC00809I Processor CP00: disabled wait state 000A0000 00ABCDEF
> 11:34:59 HHC01603I * Display parameter block
> 11:34:59 HHC01603I r 500.f
> 11:34:59 HHC02290I R:00000500:K:06=F0703838 00002828 00000000 00000000
> 0...............
> 11:34:59 HHC01603I * Expected result
> 11:34:59 HHC01603I r 580.f
> 11:34:59 HHC02290I R:00000580:K:06=F0703838 00002828 00000000 00000000
> 0...............
> 11:34:59 HHC02264I Script 4: file local_scripts\testkm processing ended
> \
> > unload dyncrypt
> /
> 11:35:16 HHC01603I rmmod dyncrypt
> 11:35:16 HHC01528I HDL: unloading module dyncrypt...
> 11:35:16 HHC01529I HDL: module dyncrypt unloaded
> \
> > run s/370 variant of John's KM fc0 test again, dyncrypt no longer loaded
> /
> 11:35:19 HHC01603I script local_scripts\testkm
> 11:35:19 HHC02260I Script 5: begin processing file local_scripts/testkm
> 11:35:19 HHC01603I * KM fc0
> 11:35:19 HHC01603I stopall
> 11:35:20 HHC01603I sysclear
> 11:35:20 HHC02311I sysclear completed
> 11:35:20 HHC01603I archmode s/370
> \
> > Program definition skipped
> /
> 11:35:20 HHC01603I ostailor null
> 11:35:20 HHC01603I restart
> 11:35:20 HHC02228I Key restart pressed
> 11:35:20 HHC00801I Processor CP00: Operation exception code 0001 ilc 4
> 11:35:20 PSW=0008000000000218 INST=B92E0024 KM
> 2,4 cipher_message
> 11:35:20 R:00000000:K:06=00080000 00000200 00000000 00000000
> ................
> 11:35:20 R:00000000:K:06=00080000 00000200 00000000 00000000
> ................
> 11:35:20 GR00=00000000 GR01=00000500 GR02=00000000 GR03=00000000
> 11:35:20 GR04=00000000 GR05=00000000 GR06=00000000 GR07=00000000
> 11:35:20 GR08=00000000 GR09=00000000 GR10=00000000 GR11=00000000
> 11:35:20 GR12=00000000 GR13=00000000 GR14=00000000 GR15=00000000
> 11:35:20 HHC00809I Processor CP00: disabled wait state 000A0000 0000DEAD
> 11:35:21 HHC01603I * Display parameter block
> 11:35:21 HHC01603I r 500.f
> 11:35:21 HHC02290I R:00000500:K:06=00010203 04050607 08090A0B 0C0D0E0F
> ................
> 11:35:21 HHC01603I * Expected result
> 11:35:21 HHC01603I r 580.f
> 11:35:21 HHC02290I R:00000580:K:06=F0703838 00002828 00000000 00000000
> 0...............
> 11:35:21 HHC02264I Script 5: file local_scripts\testkm processing ended
>
> Cheers
> JÃŒrgen
>
>

[[e-mail] [hercules-390]]

Hi John


Have had a look, but couldn't find any damage... at least not more damage than elsewhere:


grep '\*B9[123][8ABCDEF].*\"[PK]' opcode.c

/*B91E*/ GENx37Xx390x900 (compute_message_authentication_code,RRE,"KMAC"),

/*B928*/ GENx37Xx390x900 (perform_cryptographic_key_management_operation,RRE,"PCKMO"), /*810*/

/*B92A*/ GENx37Xx390x900 (cipher_message_with_cipher_feedback,RRE,"KMF"), /*810*/

/*B92B*/ GENx37Xx390x900 (cipher_message_with_output_feedback,RRE,"KMO"), /*810*/

/*B92C*/ GENx37Xx390x900 (perform_cryptographic_computation,none,"PCC"), /*810*/

/*B92D*/ GENx37Xx390x900 (cipher_message_with_counter,RRF_M,"KMCTR"), /*810*/

/*B92E*/ GENx37Xx390x900 (cipher_message,RRE,"KM"),

/*B92F*/ GENx37Xx390x900 (cipher_message_with_chaining,RRE,"KMC"),

/*B93E*/ GENx37Xx390x900 (compute_intermediate_message_digest,RRE,"KIMD"),

/*B93F*/ GENx37Xx390x900 (compute_last_message_digest,RRE,"KLMD"),



What exact damage do you mean?


Cheers
JÃŒrgen

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


Have a look in opcode.c, JÃŒrgen. That's where the damage is.

dyncrypt has to be loaded to provide the instructions in ESA and Z.

The question was rhetorical. The answer is, Hell no. We the
yammerheads don't want anything near real hardware, so you will have to
suffer--it is our ball.

But do these people contribute to enhancing the quality of Hyperion?
Hell, no!

On 07/01/17 11:19, ***@... mailto:***@... [hercules-390] wrote:
>
>
>>> On 06/01/17 22:57, ''Fish' (David B. Trout)' ***@..._
> <mailto:***@...> [hercules-390] wrote:
>
>>>
>>>
>>>> And what do I load to get the unadulterated 370 back?
>>>
>>> The opposite of "ldmod s37x": rmmod s37x! Duh!
>>>
>>
>
>> ---In hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com, <***@...> wrote :
>
>>
>
>> I did not load any modules. And KM does not program check in 370
>> architecture mode, as it should..
>>
>> So what should I have done?
>>
> John
>
> If you are inclined to, you normally find out quickly what's wrong. So
> I'm a bit surprised that this isn't the case here... well, may be you
> were not exactly inclined to .
>
> Anyway: It's clear that dyncrypt must have been loaded when you didn't
> receive the expected program check. Perhaps you might want to issue the
> "lsmod" command at the Hercules console to check? Note, that in Hyperion
> an "ldmod dyncrypt" command is issued automagically after
> initialization, which may be the reason why you had it loaded.
>
> To get a clean S/370 system initially one can easily remove this magic
> from hdl.c or, as I did in TK4- Hercules, introduce a build option (I
> named it OPTION_PRELOAD_DYNCRYPT) to control this Initial loading.
>
> I just gave your KM fc0 test a quick try on TK4- Hercules (used TK4-
> Hercules as an example only, any Hyperion incarnation configured the
> same way will behave the same way; I simply didn't want to build
> Hyperion for that simple test). The result is as expected: KM program
> checks out of the box, works fine once dyncrypt is explicitly loaded and
> program checks again after unloading dyncrypt.
>
> Here an excerpt of the Hercules console log:

['John P. Hartmann' [e-mail] [hercules-390]]

I would have expected , e.g.,

/*B92E*/ GENx___x390x900 (cipher_message,RRE,"KM"),

And the s370x module to supply activation in the 370 architecture mode.

j.

On 07/01/17 13:18, ***@id.ethz.ch [hercules-390] wrote:
>
>
> Hi John
>
>
> Have had a look, but couldn't find any damage... at least not more
> damage than elsewhere:
>
>
> grep '\*B9[123][8ABCDEF].*\"[PK]' opcode.c
>
> /*B91E*/ GENx37Xx390x900 (compute_message_authentication_code,RRE,"KMAC"),
>
> /*B928*/ GENx37Xx390x900
> (perform_cryptographic_key_management_operation,RRE,"PCKMO"), /*810*/
>
> /*B92A*/ GENx37Xx390x900
> (cipher_message_with_cipher_feedback,RRE,"KMF"), /*810*/
>
> /*B92B*/ GENx37Xx390x900
> (cipher_message_with_output_feedback,RRE,"KMO"), /*810*/
>
> /*B92C*/ GENx37Xx390x900
> (perform_cryptographic_computation,none,"PCC"), /*810*/
>
> /*B92D*/ GENx37Xx390x900
> (cipher_message_with_counter,RRF_M,"KMCTR"), /*810*/
>
> /*B92E*/ GENx37Xx390x900 (cipher_message,RRE,"KM"),
>
> /*B92F*/ GENx37Xx390x900 (cipher_message_with_chaining,RRE,"KMC"),
>
> /*B93E*/ GENx37Xx390x900 (compute_intermediate_message_digest,RRE,"KIMD"),
>
> /*B93F*/ GENx37Xx390x900 (compute_last_message_digest,RRE,"KLMD"),
>
>
> What exact damage do you mean?
>
> Cheers
> JÃŒrgen
>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
> Have a look in opcode.c, JÃŒrgen. That's where the damage is.
>
> dyncrypt has to be loaded to provide the instructions in ESA and Z.
>
> The question was rhetorical. The answer is, Hell no. We the
> yammerheads don't want anything near real hardware, so you will have to
> suffer--it is our ball.
>
> But do these people contribute to enhancing the quality of Hyperion?
> Hell, no!
>
> On 07/01/17 11:19, ***@... <mailto:***@...>
> [hercules-390] wrote:
> >
> >
> >>> On 06/01/17 22:57, ''Fish' (David B. Trout)' ***@..._
> > <mailto:***@...> [hercules-390] wrote:
> >
> >>>
> >>>
> >>>> And what do I load to get the unadulterated 370 back?
> >>>
> >>> The opposite of "ldmod s37x": rmmod s37x! Duh!
> >>>
> >>
> >
> >> ---In hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com>,
> <***@...> wrote :
> >
> >>
> >
> >> I did not load any modules. And KM does not program check in 370
> >> architecture mode, as it should..
> >>
> >> So what should I have done?
> >>
> > John
> >
> > If you are inclined to, you normally find out quickly what's wrong. So
> > I'm a bit surprised that this isn't the case here... well, may be you
> > were not exactly inclined to .
> >
> > Anyway: It's clear that dyncrypt must have been loaded when you didn't
> > receive the expected program check. Perhaps you might want to issue the
> > "lsmod" command at the Hercules console to check? Note, that in Hyperion
> > an "ldmod dyncrypt" command is issued automagically after
> > initialization, which may be the reason why you had it loaded.
> >
> > To get a clean S/370 system initially one can easily remove this magic
> > from hdl.c or, as I did in TK4- Hercules, introduce a build option (I
> > named it OPTION_PRELOAD_DYNCRYPT) to control this Initial loading.
> >
> > I just gave your KM fc0 test a quick try on TK4- Hercules (used TK4-
> > Hercules as an example only, any Hyperion incarnation configured the
> > same way will behave the same way; I simply didn't want to build
> > Hyperion for that simple test). The result is as expected: KM program
> > checks out of the box, works fine once dyncrypt is explicitly loaded and
> > program checks again after unloading dyncrypt.
> >
> > Here an excerpt of the Hercules console log:
>
>

[[e-mail] [hercules-390]]

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

>

> I would have expected , e.g.,

>

> /*B92E*/ GENx___x390x900 (cipher_message,RRE,"KM"),

>
Hi John



/*B92E*/ GENx___x390x900 (cipher_message,RRE,"KM"),
is exactly the same as

/*B92E*/ GENx37Xx390x900 (cipher_message,RRE,"KM"),



The 37X identifier is for documentation purposes only, it has no function:


grep -F '#define GENx37X' opcode.h
#define GENx37Xx390x___ GENx___x390x___
#define GENx37Xx___x900 GENx___x___x900
#define GENx37Xx390x900 GENx___x390x900
>
> And the s370x module to supply activation in the 370 architecture mode.
>
Well, during my s37x refurbishment work on TK4- Hercules in Spring 2016, I in fact had created a version that had the cryptographic instructions built in, i.e. it was not using a dynamic module any more, and that activated the cryptographic instructions for the S/370 architecture using s37x. So, I can definitely confirm that this would work.


After discussions with beta testers I reverted this change, firstly to remain closer to Hyperion mainline, and secondly because the dynamic variant provides more flexibility. I'm convinced that this is the way to go (at least for TK4- Hercules... of course it's your decision where you are going to take Hyperion).


Cheers
JÃŒrgen

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


I would have expected , e.g.,

/*B92E*/ GENx___x390x900 (cipher_message,RRE,"KM"),

And the s370x module to supply activation in the 370 architecture mode.

j.

On 07/01/17 13:18, ***@... mailto:***@... [hercules-390] wrote:
>
>
> Hi John
>
>
> Have had a look, but couldn't find any damage... at least not more
> damage than elsewhere:
>
>
> grep '\*B9[123][8ABCDEF].*\"[PK]' opcode.c
>
> /*B91E*/ GENx37Xx390x900 (compute_message_authentication_code,RRE,"KMAC"),
>
> /*B928*/ GENx37Xx390x900
> (perform_cryptographic_key_management_operation,RRE,"PCKMO"), /*810*/
>
> /*B92A*/ GENx37Xx390x900
> (cipher_message_with_cipher_feedback,RRE,"KMF"), /*810*/
>
> /*B92B*/ GENx37Xx390x900
> (cipher_message_with_output_feedback,RRE,"KMO"), /*810*/
>
> /*B92C*/ GENx37Xx390x900
> (perform_cryptographic_computation,none,"PCC"), /*810*/
>
> /*B92D*/ GENx37Xx390x900
> (cipher_message_with_counter,RRF_M,"KMCTR"), /*810*/
>
> /*B92E*/ GENx37Xx390x900 (cipher_message,RRE,"KM"),
>
> /*B92F*/ GENx37Xx390x900 (cipher_message_with_chaining,RRE,"KMC"),
>
> /*B93E*/ GENx37Xx390x900 (compute_intermediate_message_digest,RRE,"KIMD"),
>
> /*B93F*/ GENx37Xx390x900 (compute_last_message_digest,RRE,"KLMD"),
>
>
> What exact damage do you mean?
>
> Cheers
> JÃŒrgen
>
> ---In hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com, <***@...> wrote :
>
> Have a look in opcode.c, JÃŒrgen. That's where the damage is.
>
> dyncrypt has to be loaded to provide the instructions in ESA and Z.
>
> The question was rhetorical. The answer is, Hell no. We the
> yammerheads don't want anything near real hardware, so you will have to
> suffer--it is our ball.
>
> But do these people contribute to enhancing the quality of Hyperion?
> Hell, no!
>

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

> I would have expected , e.g.,
>
> /*B92E*/ GENx___x390x900 (cipher_message,RRE,"KM"),
>
> And the s370x module to supply activation in the 370 architecture mode.
>
> j.

FYI:

(opcode.h)

#define GENx37Xx390x___ GENx___x390x___
#define GENx37Xx___x900 GENx___x___x900
#define GENx37Xx390x900 GENx___x390x900

I have no idea why loading dyncrypt apparently such instructions to work in 370 mode. Sounds like a bug to me.

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

[[e-mail] [hercules-390]]

Hi Fish


of course I did a few additional changes to get the crypto instructions to working in TK4- Hercules S/370 mode, amongst them this one in dyncrypt.c:


- HDL_DEFINST(HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb93e, compute_intermediate_message_digest);

- HDL_DEFINST(HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb93f, compute_last_message_digest);

- HDL_DEFINST(HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92e, cipher_message);

- HDL_DEFINST(HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb91e, compute_message_authentication_code);

- HDL_DEFINST(HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92f, cipher_message_with_chaining);

- HDL_DEFINST(HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92d, cipher_message_with_counter);

- HDL_DEFINST(HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92a, cipher_message_with_cipher_feedback);

- HDL_DEFINST(HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92b, cipher_message_with_output_feedback);

- HDL_DEFINST(HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92c, perform_cryptographic_computation);

- HDL_DEFINST(HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb928, perform_cryptographic_key_management_operation);

+ HDL_DEFINST(HDL_INSTARCH_370 | HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb93e, compute_intermediate_message_digest);

+ HDL_DEFINST(HDL_INSTARCH_370 | HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb93f, compute_last_message_digest);

+ HDL_DEFINST(HDL_INSTARCH_370 | HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92e, cipher_message);

+ HDL_DEFINST(HDL_INSTARCH_370 | HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb91e, compute_message_authentication_code);

+ HDL_DEFINST(HDL_INSTARCH_370 | HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92f, cipher_message_with_chaining);

+ HDL_DEFINST(HDL_INSTARCH_370 | HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92d, cipher_message_with_counter);

+ HDL_DEFINST(HDL_INSTARCH_370 | HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92a, cipher_message_with_cipher_feedback);

+ HDL_DEFINST(HDL_INSTARCH_370 | HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92b, cipher_message_with_output_feedback);

+ HDL_DEFINST(HDL_INSTARCH_370 | HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb92c, perform_cryptographic_computation);

+ HDL_DEFINST(HDL_INSTARCH_370 | HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb928, perform_cryptographic_key_management_operation)



But this type of changes I consider self understanding and thus not necessarily needing to be mentioned .


Well, I am of course curious how John managed to get into a situation in which those instructions seemed to work out of the box in S/370 mode. I haven't seen that answered up to now though . But you may be right: A bug might have gotten introduced in Hyperion at a later date than when I forked TK4- Hercules...


Cheers
JÃŒrgen





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


> I would have expected , e.g.,
>
> /*B92E*/ GENx___x390x900 (cipher_message,RRE,"KM"),
>
> And the s370x module to supply activation in the 370 architecture mode.
>
> j.

FYI:

(opcode.h)

#define GENx37Xx390x___ GENx___x390x___
#define GENx37Xx___x900 GENx___x___x900
#define GENx37Xx390x900 GENx___x390x900

I have no idea why loading dyncrypt apparently such instructions to work in 370 mode. Sounds like a bug to me.

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

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

JÃŒrgen Winkelmann wrote:

> Hi Fish
>
> of course I did a few additional changes to get the crypto
> instructions to working in TK4- Hercules S/370 mode, amongst
> them this one in dyncrypt.c:
>
> - HDL_DEFINST(HDL_INSTARCH_390 | HDL_INSTARCH_900, 0xb93e,
> compute_intermediate_message_digest);

[...]

> + HDL_DEFINST(HDL_INSTARCH_370 | HDL_INSTARCH_390 | HDL_INSTARCH_900,
> 0xb93e, compute_intermediate_message_digest);
<snip>

Yep. That's definitely one way to do it.

Of course doing so makes the availability of cipher instructions in 370 mode non-optional. What you've essentially done is made those instructions permanently available to 370 mode. It might have been better to have created a brand new module called, say, crypt370, that provided such instructions ONLY to the 370 architecture.

That way dyncrypt would remain the same, providing crypto for ONLY 390 and Z, and crypt370 providing it ONLY for 370. That way loading/unloading (ldmod/rmmod) dyncrypt would not impact 370 at all, and loading/unloading (ldmod/rmmod) crypt370 would not impact 390/Z at all either.

But hey, whatever works. To each their own I guess. :)


[...]
> Well, I am of course curious how John managed to get into
> a situation in which those instructions seemed to work out
> of the box in S/370 mode. I haven't seen that answered up
> to now though.

I'm rather curious about that myself. John?


> But you may> be right: A bug might have gotten introduced
> in Hyperion at a later date than when I forked TK4- Hercules...

Well I just tried the same test as you (but using my hyperion, not the official one) and whether dyncrypt is loaded or not, cipher instructions *always* program check (or at least LM does; I didn't check all of them).

So yeah, I too am rather curious as to what pretense John's specious claim is based upon.

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

['John P. Hartmann' [e-mail] [hercules-390]]

The error:

***@notAtom:~/src/hyperion$ make km.core && ./onetest km
make: 'km.core' is up to date.
Files: ./km.tst
Variable ptrsize is set to "8".
Variable platform is set to "Linux".
>>>>> line 122: Storage at R:0000000000000200 compare mismatch.
... Want: 00000000 00000000 00000000 00000000
... Have: F0000000 00000000 00000000 00000000
>>>>> line 126: Storage at R:0000000000000080 compare mismatch.
... Want: 00020001
... Have: 00000000

The display for the program check code is not in error:
HHC02290I R:0000000000000080 00000000

The .tst file:

*Testcase KM fc0
sysclear
archlvl z
*
ostailor null
loadcore "$(testpath)/km.core"
runtest .1
*Compare
* Display parameter block
r 200.10
*Want F0703838 00002828 00000000 00000000
r 8c.4
*Want 00000000

archlvl esame
runtest .1
r 200.10
*Want F0000000 00000000 00000000 00000000
r 8c.4
*Want 00000000

archlvl esa
runtest .1
r 200.10
*Want F0000000 00000000 00000000 00000000
r 8c.4
*Want 00000000

* This test case should fail as KM is not a 370 instruction
archlvl 370
*Program 1
runtest .1
r 200.10
*Want 00000000 00000000 00000000 00000000
r 8c.4
*Want 00020001
*Done

The program:

km TITLE 'Cipher message. Test all architecture modes.'
*
* This file was put into the public domain 2017-01-06
* by John P. Hartmann. You can use it for anything you like,
* as long as this notice remains.
*
km start 0
using km,15
dc x'0080 0000',a(go)
org km+104 Program new
stop dc x'000a 0000',a(0) Expected in 370, but not in ESA
org km+140
ds f pgmcode
org km+x'1a0' Restart
dc x'0000000180000000',ad(go)
org km+x'1c0' SVC new
dc x'0002000180000000',ad(0)
org km+x'1d0' Program
dc x'0002000180000000',ad(x'deaddead') Not expected in z or ESA
org km+x'200'
cando ds xl16
go equ *
sr 0,0 query
la 1,cando
xc cando,cando
km 2,4 Store
ltr 14,14
bnzr 14
lpsw stop
*
end

The log:

HHC01413I Hercules version 4.0.0 (4.0.0.8696)
HHC01414I (C) Copyright 1999-2016 by Roger Bowler, Jan Jaeger, and others
HHC01414I Commit 4ce7a6d939397ed183e8256afb984b57def08584.
HHC01415I Build date: Dec 30 2016 at 22:30:09
HHC01417I Built with: GCC 5.4.0 20160609
HHC01417I Build type: GNU/Linux x86_64 host architecture build
HHC01417I Modes: S/370 ESA/390 z/Arch
HHC01417I Max CPU Engines: 128
HHC01417I Using setresuid() for setting privileges
HHC01417I Using POSIX threads Threading Model
HHC01417I Using Error-Checking Mutex Locking Model
HHC01417I With Syncio support
HHC01417I With Shared Devices support
HHC01417I With Dynamic loading support
HHC01417I Using shared libraries
HHC01417I With External GUI support
HHC01417I With IPV6 support
HHC01417I With HTTP Server support
HHC01417I With sqrtl support
HHC01417I With SIGABEND handler
HHC01417I Without CCKD BZIP2 support
HHC01417I Without HET BZIP2 support
HHC01417I With ZLIB support
HHC01417I With Regular Expressions support
HHC01417I Without Object REXX support
HHC01417I Without Regina REXX support
HHC01417I With Automatic Operator support
HHC01417I Without National Language Support
HHC01417I Machine dependent assists: cmpxchg1 cmpxchg4 cmpxchg8
hatomics=atomicIntrinsics
HHC01417I Running on: notAtom (Linux-4.4.0-57-generic x86_64) MP=4
HHC00019W Hercules IS running in test mode
HHC00150I Crypto module loaded (c) Copyright 2003-2016 by Bernard van
der Helm
HHC00151I Activated facility: Message Security Assist
HHC00151I Activated facility: Message Security Assist Extension 1, 2, 3
and 4
HHC00100I Thread id 00007f979ad53700, prio 2147483647, name Processor
CP00 started
HHC00100I Thread id 00007f979ac52700, prio 2147483647, name Timer started
HHC00811I Processor CP00: architecture mode z/Arch
HHC01603I * Configuration file for running tests using "runtest"
HHC01603I * The console printer/keyboard must be subchannel 0
HHC02260I Script 1: begin processing file allTests.testin
HHC01603I defsym testpath .
HHC01603I * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
HHC01603I *
HHC01603I * Start of test file ./km.tst date 2017-01-06
18:06:29.774946436 +0000 in /home/john/src/hyperion
HHC01603I *
HHC01603I *Testcase KM fc0
HHC01603I sysclear
HHC00811I Processor CP00: architecture mode ESA/390
HHC02311I sysclear completed
HHC01603I archlvl z
HHC00811I Processor CP00: architecture mode z/Arch
HHC02204I archmode set to z/Arch
HHC01603I *
HHC01603I ostailor null
HHC01603I loadcore "./km.core"
HHC02250I Loading file ./km.core to location 0
HHC02249I Operation complete
HHC02336I Script 1: test: test starting
HHC02339I Script 1: test: duration limit: 0.100000 seconds
HHC02228I restart key pressed
HHC02333I Script 1: test: running...
HHC00809I Processor CP00: disabled wait state 0002000000000000
0000000000000000
HHC02334I Script 1: test: test ended
HHC02338I Script 1: test: actual duration: 0.000169 seconds
HHC01603I *Compare
HHC01603I * Display parameter block
HHC01603I r 200.10
HHC02290I A:0000000000000000 K:06
HHC02290I R:0000000000000200 F0703838 00002828 00000000 00000000
0...............
HHC01603I *Want F0703838 00002828 00000000 00000000
HHC01603I r 8c.4
HHC02290I A:0000000000000000 K:06
HHC02290I R:0000000000000080 00000000
....
HHC01603I *Want 00000000
HHC01603I archlvl esame
HHC02204I archmode set to z/Arch
HHC02336I Script 1: test: test starting
HHC02339I Script 1: test: duration limit: 0.100000 seconds
HHC02228I restart key pressed
HHC02333I Script 1: test: running...
HHC00809I Processor CP00: disabled wait state 0002000000000000
0000000000000000
HHC02334I Script 1: test: test ended
HHC02338I Script 1: test: actual duration: 0.000073 seconds
HHC01603I r 200.10
HHC02290I A:0000000000000000 K:06
HHC02290I R:0000000000000200 F0000000 00000000 00000000 00000000
0...............
HHC01603I *Want F0000000 00000000 00000000 00000000
HHC01603I r 8c.4
HHC02290I A:0000000000000000 K:06
HHC02290I R:0000000000000080 00000000
....
HHC01603I *Want 00000000
HHC01603I archlvl esa
HHC02205E Invalid argument esa
HHC02336I Script 1: test: test starting
HHC02339I Script 1: test: duration limit: 0.100000 seconds
HHC02228I restart key pressed
HHC02333I Script 1: test: running...
HHC00809I Processor CP00: disabled wait state 0002000000000000
0000000000000000
HHC02334I Script 1: test: test ended
HHC02338I Script 1: test: actual duration: 0.000055 seconds
HHC01603I r 200.10
HHC02290I A:0000000000000000 K:06
HHC02290I R:0000000000000200 F0000000 00000000 00000000 00000000
0...............
HHC01603I *Want F0000000 00000000 00000000 00000000
HHC01603I r 8c.4
HHC02290I A:0000000000000000 K:06
HHC02290I R:0000000000000080 00000000
....
HHC01603I *Want 00000000
HHC01603I archlvl 370
HHC02205E Invalid argument 370
HHC01603I *Program 1
HHC02336I Script 1: test: test starting
HHC02339I Script 1: test: duration limit: 0.100000 seconds
HHC02228I restart key pressed
HHC02333I Script 1: test: running...
HHC00809I Processor CP00: disabled wait state 0002000000000000
0000000000000000
HHC02334I Script 1: test: test ended
HHC02338I Script 1: test: actual duration: 0.000030 seconds
HHC01603I r 200.10
HHC02290I A:0000000000000000 K:06
HHC02290I R:0000000000000200 F0000000 00000000 00000000 00000000
0...............
HHC01603I *Want 00000000 00000000 00000000 00000000
HHC01603I r 8c.4
HHC02290I A:0000000000000000 K:06
HHC02290I R:0000000000000080 00000000
....
HHC01603I *Want 00020001
HHC01603I *Done


On 07/01/17 16:58, ''Fish' (David B. Trout)' ***@gmail.com
[hercules-390] wrote:
> So yeah, I too am rather curious as to what pretense John's specious
> claim is based upon.

['John P. Hartmann' [e-mail] [hercules-390]]

HHC02205E Invalid argument 370

So the the 370 test case ran in ESA mode.

After a couple of other adjustments:

Test KM fc0. 13 OK compares. All pass.

Apologies all round.

Ivan, in the next update, can we have the dancing girls and the beer
garten, please. Surely the all PoOs allow that too!

On 07/01/17 16:58, ''Fish' (David B. Trout)' ***@gmail.com
[hercules-390] wrote:
> So yeah, I too am rather curious as to what pretense John's specious
> claim is based upon.

[[e-mail] [hercules-390]]

As an end-user of Hercules/Hyperion and not someone associated with the development of the emulator, I feel compelled to briefly weigh in on this subject, so that a view from the "other side" can be heard by those who have done Hercules development in the past.

I can certainly see both sides of the argument in this thread and one could make a case for either view. As someone who has spent the last several years in my career using z/OS on a real z/Series box, I am familiar with most of the z/Architecture instructions and have used a good number of them, including KM, at one time or another.

Since most of us must necessarily use the old S/370 operating systems such as VM/370 and MVS 3.8J because of the lack of legal availability of z/OS and others, I wish that I could use the later instructions that became available after System/370 even while in S370 mode. Why can't I issue KM from a VM/370 virtual machine if I want to? Why can't I issue the non-privileged instructions from ESA and z/Architecture that would work in S/370 mode if only the emulator would allow it?

I understand how the instructions work and I understand the limitations of the S/370 architecture. The point being, as an experienced assembler programmer I can determine when it is ok for me to issue a KM or a ICMY (for example) and therefore I know when they would work just fine in the older architectural mode.

I urge the Hercules/Hyperion developers not to inhibit the use of any later generation instructions from operating in ARCHMODE S/370 that themselves do not alter the architecture.

Regards,
Bob

[Maarten Hoes [e-mail] [hercules-390]]

Hi,


First and foremost, let me formally state that I'm mostly a lurker around
here, that I do not in any way mean to offend anyone, and that the
following is strictly my personal opinion, which starts and ends there.
Having said that :

To me personally, Hercules/Hyperion is a hardware emulator. An emulator of
hardware that at some point in time was actually produced. As such, I
honestly feel that the main goal should be to emulate those pieces of
hardware as accurately/closely as possible. If the real hardware (or
'model', 'type', etc.) was capable of doing something, then I feel the
emulator should aspire (within real world restrictions of course, like but
not limited to the spare time and effort that volunteer developers whish to
spend on the code) to emulate that as closely as possible. And if the real
hardware could not do something, then the emulator should not do so either.

In short, in my ideal world: if the real hardware the emulator aspires to
emulate can/could do something, then so should the emulator. If the real
hardware couldn't, then neither should the emulator.

I will crawl back under my rock now.


- Maarten




On Sat, Jan 7, 2017 at 6:32 PM, ***@sbcglobal.net [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
>
> As an end-user of Hercules/Hyperion and not someone associated with the
> development of the emulator, I feel compelled to briefly weigh in on this
> subject, so that a view from the "other side" can be heard by those who
> have done Hercules development in the past.
>
>
>
> I can certainly see both sides of the argument in this thread and one
> could make a case for either view. As someone who has spent the last
> several years in my career using z/OS on a real z/Series box, I am familiar
> with most of the z/Architecture instructions and have used a good number of
> them, including KM, at one time or another.
>
>
>
> Since most of us must necessarily use the old S/370 operating systems such
> as VM/370 and MVS 3.8J because of the lack of legal availability of z/OS
> and others, I wish that I could use the later instructions that became
> available after System/370 even while in S370 mode. Why can't I issue KM
> from a VM/370 virtual machine if I want to? Why can't I issue the
> non-privileged instructions from ESA and z/Architecture that would work in
> S/370 mode if only the emulator would allow it?
>
>
>
> I understand how the instructions work and I understand the limitations of
> the S/370 architecture. The point being, as an experienced assembler
> programmer I can determine when it is ok for me to issue a KM or a ICMY
> (for example) and therefore I know when they would work just fine in the
> older architectural mode.
>
>
>
> I urge the Hercules/Hyperion developers not to inhibit the use of any
> later generation instructions from operating in ARCHMODE S/370 that
> themselves do not alter the architecture.
>
>
>
> Regards,
>
> Bob
>
>
>

[[e-mail] [hercules-390]]

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

> Since most of us must necessarily use
> the old S/370 operating systems such
> as VM/370 and MVS 3.8J because of
> the lack of legal availability of z/OS
> and others, I wish that I could use the
> later instructions that became available
> after System/370 even while in S370 mode.

Note that the latest Hercules/380 beta
enables almost all S/390 and z/Arch
instructions in S/370 mode.

I've only actually attempted to use a
small number of z/Arch instructions
though, like SAM24, SAM31, SAM64,
STG, STGM, LGR.

They all work fine, as does writing to
memory above the 2 GiB bar.

BFN. Paul.

[[e-mail] [hercules-390]]

>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
> I urge the Hercules/Hyperion developers not to inhibit the
> use of any later generation instructions from operating in
> ARCHMODE S/370 that themselves do not alter the architecture.
>
Hi Bob


I fully support your statement.


It's perfectly clear that we have conflicting objectives here:


If the objective is to emulate an existing system (or a previously existing system), then all instructions that are/were not available on the original must also not be available on the emulated system.


If, however, the objective is to emulate a system that is upwardly compatible to an existing system (or a previously existing system, or even to a system that never existed), targeting to allow users to run code written for a system (existing or not) that isn't accessible to them and to even write such code, then one should drive up the emulation to the maximum level possible that remains compatible with the original. Or, in terms of instructions, one should emulate as many instructions of the inaccessible system as possible.


As one cannot know in advance whether a user of the emulator will require the first (closest possible to an original) or the second (maximum subset of the functionality of another system) objective fulfilled, one simply needs to provide both, ideally selectable at run time.


Thus, from my personal point of view, it's not discussable _if_ to provide both in an easily selectable way but only _how_ to do it, or, speaking in current Hercules terms, by adding distinct ARCHLVLs or by providing loadable modules to enable the instructions in question.


Personally, I currently prefer the loadable modules approach (which is why I did it this way in TK4- Hercules). CEx-level management of the current Hyperion developers seems to prefer the multiple ARCHLVL approach.


For me it's that simple: Time will tell, which of these approaches is most useful to end users. And my personal oracle: Any development approach trying to actively prevent the usage of additional instructions will kill Hercules on the long run, unless the modern operating systems would be made available more openly by IBM as this is the case today.


So, to get back to your statement: TK4- Hercules (the Hercules that comes with the TK4- appliance) might not always have the latest and greatest bells and whistles implemented, but it will always be a clean S/370 system when it comes out of the box, which can easily be switched, even without needing to restart, to have the maximum possible additional instructions available. See the README of the current TK4- Update 08 system on how to switch the instructions in question on and off (as of this writing we are talking about over 300 additional instructions) .


Cheers
JÃŒrgen

['John P. Hartmann' [e-mail] [hercules-390]]

To my mind we have two camps here, each with a laudable aim.

There are those who (unspecified how) build software for real current
iron. They want to see only what IBM supplies (that is no Dancing Girls
(m/f) or Pull Beer instruction); and then there are what I would call
"recreational users" of the various (by now highly modified) IBM
software in the public domain.

Right now it seems that Hyperion development is mainly the former type.
As a result, they perhaps have little time or inclination to maintain
non-essential parts.

Bolt-on stuff could live in a separate git hub project, which would be
in line with current thinking. For example, the windows GUI interface
might go outboard similarly, as might even the logger. In the final
analysis, the Hyperion project would produce something that takes
commands form standard input and produces standard output. (That is
what is actually happening; it is just hidden deep in the bowels.)

Issue 183 (https://github.com/hercules-390/hyperion/issues/183) is open,
but please keep the soapbox at home. Thank you.

On 08/01/17 13:16, ***@id.ethz.ch [hercules-390] wrote:
>
>
>>
>> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>> I urge the Hercules/Hyperion developers not to inhibit the
>> use of any later generation instructions from operating in
>> ARCHMODE S/370 that themselves do not alter the architecture.
>>
> Hi Bob
>
> I fully support your statement.
>
> It's perfectly clear that we have conflicting objectives here:
>
> If the objective is to emulate an existing system (or a previously
> existing system), then all instructions that are/were not available on
> the original must also not be available on the emulated system.
>
> If, however, the objective is to emulate a system that is upwardly
> compatible to an existing system (or a previously existing system, or
> even to a system that never existed), targeting to allow users to run
> code written for a system (existing or not) that isn't accessible to
> them and to even write such code, then one should drive up the emulation
> to the maximum level possible that remains compatible with the original.
> Or, in terms of instructions, one should emulate as many instructions of
> the inaccessible system as possible.
>
> As one cannot know in advance whether a user of the emulator will
> require the first (closest possible to an original) or the second
> (maximum subset of the functionality of another system) objective
> fulfilled, one simply needs to provide both, ideally selectable at run time.
>
> Thus, from my personal point of view, it's not discussable _if_ to
> provide both in an easily selectable way but only _how_ to do it, or,
> speaking in current Hercules terms, by adding distinct ARCHLVLs or by
> providing loadable modules to enable the instructions in question.
>
> Personally, I currently prefer the loadable modules approach (which is
> why I did it this way in TK4- Hercules). CEx-level management of the
> current Hyperion developers seems to prefer the multiple ARCHLVL approach.
>
> For me it's that simple: Time will tell, which of these approaches is
> most useful to end users. And my personal oracle: Any development
> approach trying to actively prevent the usage of additional instructions
> will kill Hercules on the long run, unless the modern operating
> systems would be made available more openly by IBM as this is the case
> today.
>
> So, to get back to your statement: TK4- Hercules (the Hercules that
> comes with the TK4- appliance) might not always have the latest and
> greatest bells and whistles implemented, but it will always be a clean
> S/370 system when it comes out of the box, which can easily be switched,
> even without needing to restart, to have the maximum possible additional
> instructions available. See the README of the current TK4- Update 08
> system on how to switch the instructions in question on and off (as of
> this writing we are talking about over 300 additional instructions) .
>
> Cheers
> JÃŒrgen
>
>
>

[Ivan Warren [e-mail] [hercules-390]]

On 1/8/2017 2:31 PM, 'John P. Hartmann' ***@gmail.com
[hercules-390] wrote:
> To my mind we have two camps here, each with a laudable aim.
>
> There are those who (unspecified how) build software for real current
> iron.
Note : Give me an example of 2 IBM built machines which have a
comparable behavior
> They want to see only what IBM supplies (that is no Dancing Girls
> (m/f) or Pull Beer instruction); and then there are what I would call
> "recreational users" of the various (by now highly modified) IBM
> software in the public domain.
That's the target - however, they are all within the architectural
constraints.
>
> Right now it seems that Hyperion development is mainly the former type.
> As a result, they perhaps have little time or inclination to maintain
> non-essential parts.
There are essential parts which are NOT maintained.... (think the broken
I/O subsystem)
>
> Bolt-on stuff could live in a separate git hub project, which would be
> in line with current thinking. For example, the windows GUI interface
> might go outboard similarly, as might even the logger. In the final
> analysis, the Hyperion project would produce something that takes
> commands form standard input and produces standard output. (That is
> what is actually happening; it is just hidden deep in the bowels.)
>
> Issue 183 (https://github.com/hercules-390/hyperion/issues/183) is open,
> but please keep the soapbox at home. Thank you.
>
I will post there



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Hi JÃŒrgen,


I was unaware of the availability of "ldmod s37x", as I rarely use MVS 3.8J and have not kept up with the updates. After learning about it from your post, I issued the command for my VM/370 setup and then attempted to execute a few later generation instructions. It works perfectly.


This is a very acceptable solution for those who want to use these instructions and not impose anything permanent on those who would rather not have them available in keeping with a more "pure" architecture.


Thanks for the information!


Regards,
Bob




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

>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
> I urge the
Hercules/Hyperion developers not to inhibit the > use of any later generation instructions from operating in
> ARCHMODE S/370 that themselves do not alter the architecture.
>
Hi Bob


I fully support your statement.


It's perfectly clear that we have conflicting objectives here:


If the objective is to emulate an existing system (or a previously existing system), then all instructions that are/were not available on the original must also not be available on the emulated system.


If, however, the objective is to emulate a system that is upwardly compatible to an existing system (or a previously existing system, or even to a system that never existed), targeting to allow users to run code written for a system (existing or not) that isn't accessible to them and to even write such code, then one should drive up the emulation to the maximum level possible that remains compatible with the original. Or, in terms of instructions, one should emulate as many instructions of the inaccessible system as possible.


As one cannot know in advance whether a user of the emulator will require the first (closest possible to an original) or the second (maximum subset of the functionality of another system) objective fulfilled, one simply needs to provide both, ideally selectable at run time.


Thus, from my personal point of view, it's not discussable _if_ to provide both in an easily selectable way but only _how_ to do it, or, speaking in current Hercules terms, by adding distinct ARCHLVLs or by providing loadable modules to enable the instructions in question.


Personally, I currently prefer the loadable modules approach (which is why I did it this way in TK4- Hercules). CEx-level management of the current Hyperion developers seems to prefer the multiple ARCHLVL approach.


For me it's that simple: Time will tell, which of these approaches is most useful to end users. And my personal oracle: Any development approach trying to actively prevent the usage of additional instructions will kill Hercules on the long run, unless the modern operating systems would be made available more openly by IBM as this is the case today.


So, to get back to your statement: TK4- Hercules (the Hercules that comes with the TK4- appliance) might not always have the latest and greatest bells and whistles implemented, but it will always be a clean S/370 system when it comes out of the box, which can easily be switched, even without needing to restart, to have the maximum possible additional instructions available. See the README of the current TK4- Update 08 system on how to switch the instructions in question on and off (as of this writing we are talking about over 300 additional instructions) .


Cheers
JÃŒrgen

[[e-mail] [hercules-390]]

Hi Bob


just a few additional remarks:
The s37x loadable module was introduced originally by Ivan Warren, I think around 2010. Since then there didn't happen much with respect to this module and what you'll find in today's Hyperion is (mostly) still the level from 2010. In Spring 2016 I did a major refurbishment of the module (and the components it's depending on, namely opcode.[ch], archlvl.c, feat370.h, esame.c, general[123].c. The objective was to make _all_ eligible instructions available as opposed to the few that were originally implemented. "All" means in that context, all that were supported by Sandhawk Hercules as of December 2012, which was the point in time, when I "forked" (it's not "officially" a fork) TK4- Hercules from Sandhawk. Although I generally feed back changes I make to TK4- Hercules into the main lines (Hyperion and Spinhawk), I didn't do so with s37x.c et al, because some changes I made would simply not be acceptable for the those lines, at least not as quick and dirty as I did it. In the course of these changes I also made the crypto instructions available in S/370 mode. As far as I know, TK4- Hercules currently is the only variant of Hercules doing this, which is why I was so surprised when John stated he ran into this with a "standard" version of Hercules. In total: While not being ahead of the Hyperion or Spinhawk in very many aspects, TK4- Hercules is ahead in terms of the S/370 instruction set extensions through dyncrypt and s37x. That holds true not only for MVS 3.8j but also for VM/370, which of course runs fine on TK4- Hercules too (well, you might find one instruction which will make you scratch your head in a VM/370 environment, but nothing that will harm operations in any aspect).



Have fun!


Cheers
JÃŒrgen

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


Hi JÃŒrgen,


I was unaware of the availability of "ldmod s37x", as I rarely use MVS 3.8J and have not kept up with the updates. After learning about it from your post, I issued the command for my VM/370 setup and then attempted to execute a few later generation instructions. It works perfectly.


This is a very acceptable solution for those who want to use these instructions and not impose anything permanent on those who would rather not have them available in keeping with a more "pure" architecture.


Thanks for the information!


Regards,
Bob




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

>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
> I urge the
Hercules/Hyperion developers not to inhibit the > use of any later generation instructions from operating in
> ARCHMODE S/370 that themselves do not alter the architecture.
>
Hi Bob


I fully support your statement.


It's perfectly clear that we have conflicting objectives here:


If the objective is to emulate an existing system (or a previously existing system), then all instructions that are/were not available on the original must also not be available on the emulated system.


If, however, the objective is to emulate a system that is upwardly compatible to an existing system (or a previously existing system, or even to a system that never existed), targeting to allow users to run code written for a system (existing or not) that isn't accessible to them and to even write such code, then one should drive up the emulation to the maximum level possible that remains compatible with the original. Or, in terms of instructions, one should emulate as many instructions of the inaccessible system as possible.


As one cannot know in advance whether a user of the emulator will require the first (closest possible to an original) or the second (maximum subset of the functionality of another system) objective fulfilled, one simply needs to provide both, ideally selectable at run time.


Thus, from my personal point of view, it's not discussable _if_ to provide both in an easily selectable way but only _how_ to do it, or, speaking in current Hercules terms, by adding distinct ARCHLVLs or by providing loadable modules to enable the instructions in question.


Personally, I currently prefer the loadable modules approach (which is why I did it this way in TK4- Hercules). CEx-level management of the current Hyperion developers seems to prefer the multiple ARCHLVL approach.


For me it's that simple: Time will tell, which of these approaches is most useful to end users. And my personal oracle: Any development approach trying to actively prevent the usage of additional instructions will kill Hercules on the long run, unless the modern operating systems would be made available more openly by IBM as this is the case today.


So, to get back to your statement: TK4- Hercules (the Hercules that comes with the TK4- appliance) might not always have the latest and greatest bells and whistles implemented, but it will always be a clean S/370 system when it comes out of the box, which can easily be switched, even without needing to restart, to have the maximum possible additional instructions available. See the README of the current TK4- Update 08 system on how to switch the instructions in question on and off (as of this writing we are talking about over 300 additional instructions) .


Cheers
JÃŒrgen

[[e-mail] [hercules-390]]

Hi JÃŒrgen,

I was not aware of the history of s37x. I was disappointed to find out that today's Hyperion apparently does not have the changes to s37x that you introduced in your TK4- update 08. This is because I am also using Peter Jansen's CTCE support and the important changes that he put in place in October 2016 would not be in your June 2016 dated Hercules update. I guess I could bring everything together and recompile and rebuild in order to get everything at the right level, but I have found the build process to be rather daunting under Windows. I'm weak in this PC-based stuff, having been a mainframe assembler system programmer all of my career.

I'm not sure all of these forks of Hercules/Hyperion are a good thing, at least from an end-user point of view. I long for the old days where we could simply upgrade from Hercules 3.05 to 3.07 (for example) and get the latest stuff. The situation now is complicated. However, having been a contributor myself (I am the author of the DIAG58 and LDF modifications to VM/370 Sixpack) I understand the implications of trying to produce stuff and maintain it, all in your free time and with free labor.

As for the one instruction that might not work as expected in a VM/370 environment, I understand the nature of EPSW and what it means in a virtual machine as a non-privileged instruction.

Regards,
Bob


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


Hi Bob


just a few additional remarks:
The s37x loadable module was introduced originally by Ivan Warren, I think around 2010. Since then there didn't happen much with respect to this module and what you'll find in today's Hyperion is (mostly) still the level from 2010. In Spring 2016 I did a major refurbishment of the module (and the components it's depending on, namely opcode.[ch], archlvl.c, feat370.h, esame.c, general[123].c. The objective was to make _all_ eligible instructions available as opposed to the few that were originally implemented. "All" means in that context, all that were supported by Sandhawk Hercules as of December 2012, which was the point in time, when I "forked" (it's not "officially" a fork) TK4- Hercules from Sandhawk. Although I generally feed back changes I make to TK4- Hercules into the main lines (Hyperion and Spinhawk), I didn't do so with s37x.c et al, because some changes I made would simply not be acceptable for the those lines, at least not as quick and dirty as I did it. In the course of these changes I also made the crypto instructions available in S/370 mode. As far as I know, TK4- Hercules currently is the only variant of Hercules doing this, which is why I was so surprised when John stated he ran into this with a "standard" version of Hercules. In total: While not being ahead of the Hyperion or Spinhawk in very many aspects, TK4- Hercules is ahead in terms of the S/370 instruction set extensions through dyncrypt and s37x. That holds true not only for MVS 3.8j but also for VM/370, which of course runs fine on TK4- Hercules too (well, you might find one instruction which will make you scratch your head in a VM/370 environment, but nothing that will harm operations in any aspect).



Have fun!


Cheers
JÃŒrgen

[[e-mail] [hercules-390]]

Hi Bob
>
> I was disappointed to find out that today's Hyperion apparently does not
> have the changes to s37x that you introduced in your TK4- update 08.
>
I fully understand this. However, as you are seeing just now, there are very many opinions on that matter around, none of them being completely wrong or absolutely right and particularly none of them providing a vision on how to satisfy all requirements in that area, using a single solution. Last spring I didn't want to run into this discussion, because I'm very sure it had prevented me from getting TK4- Update 08 out in a useful time frame. So, besides the technical effort to implement it "clean enough" for Hyperion, this was one of the reasons why I up to now didn't try to feed it back into Hyperion.


For the time being I don't expect quick changes in Hyperion to happen. It will need some time until the developers will have found a consolidated view on how to proceed. Btw.: From time to time I'm also one of the developers, but from time to time I get kicked out or kick myself out for various reasons. Currently I'm one of them again, let's see for how long.


So, until I see a smooth way to go forward with Hyperion and/or Spinhawk, I'll continue to provide the s37x enhancements only with TK4- Hercules. I don't consider this really a problem, as for the targeted S/370 operating systems the newer versions of Hercules (Hyperion & Spinhawk) don't bring significant enhancements... well, with one important exception:
>
> This is because I am also using Peter Jansen's CTCE support and
> the important changes that he put in place in October 2016 would not
> be in your June 2016 dated Hercules update.
>
Yes, Peter's CTCE implementation is an important enhancement not only for the modern operating systems but also for the S/370 systems. For that reason I back-ported it from the level it had in June to TK4- Hercules, but of course the October 2016 changes didn't make it into the Update 08 which distributes the binaries I built in June 2016.


The good news: Currently I'm at implementing some enhancements to the TCPIP (X'75') instruction (originally requested by Mike Raybourn) which will require me to build new binaries. At the same time I'll integrate Peter's October 2016 changes to the CTCE. Currently two contributors are on the brink of releasing some exciting new stuff, which will bring unexpected new and enhanced functionality into TK4-. This stuff seems so important to me that I decided to make a dedicated TK4- Update containing the new binaries and these two contributions, i.e. the JES3 variant I talked about earlier will come out one update later. That means, you'll shortly have the latest CTCE stuff available in TK4- Hercules. As I don't want to spoil the fun of the two contributors, I'll not yet reveal what those two other goodies are .


Cheers
JÃŒrgen




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

Hi JÃŒrgen,

I was not aware of the history of s37x. I was disappointed to find out that today's Hyperion apparently does not have the changes to s37x that you introduced in your TK4- update 08. This is because I am also using Peter Jansen's CTCE support and the important changes that he put in place in October 2016 would not be in your June 2016 dated Hercules update. I guess I could bring everything together and recompile and rebuild in order to get everything at the right level, but I have found the build process to be rather daunting under Windows. I'm weak in this PC-based stuff, having been a mainframe assembler system programmer all of my career.

I'm not sure all of these forks of Hercules/Hyperion are a good thing, at least from an end-user point of view. I long for the old days where we could simply upgrade from Hercules 3.05 to 3.07 (for example) and get the latest stuff. The situation now is complicated. However, having been a contributor myself (I am the author of the DIAG58 and LDF modifications to VM/370 Sixpack) I understand the implications of trying to produce stuff and maintain it, all in your free time and with free labor.

As for the one instruction that might not work as expected in a VM/370 environment, I understand the nature of EPSW and what it means in a virtual machine as a non-privileged instruction.

Regards,
Bob


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


Hi Bob


just a few additional remarks:
The s37x loadable module was introduced originally by Ivan Warren, I think around 2010. Since then there didn't happen much with respect to this module and what you'll find in today's Hyperion is (mostly) still the level from 2010. In Spring 2016 I did a major refurbishment of the module (and the components it's depending on, namely opcode.[ch], archlvl.c, feat370.h, esame.c, general[123].c. The objective was to make _all_ eligible instructions available as opposed to the few that were originally implemented. "All" means in that context, all that were supported by Sandhawk Hercules as of December 2012, which was the point in time, when I "forked" (it's not "officially" a fork) TK4- Hercules from Sandhawk. Although I generally feed back changes I make to TK4- Hercules into the main lines (Hyperion and Spinhawk), I didn't do so with s37x.c et al, because some changes I made would simply not be acceptable for the those lines, at least not as quick and dirty as I did it. In the course of these changes I also made the crypto instructions available in S/370 mode. As far as I know, TK4- Hercules currently is the only variant of Hercules doing this, which is why I was so surprised when John stated he ran into this with a "standard" version of Hercules. In total: While not being ahead of the Hyperion or Spinhawk in very many aspects, TK4- Hercules is ahead in terms of the S/370 instruction set extensions through dyncrypt and s37x. That holds true not only for MVS 3.8j but also for VM/370, which of course runs fine on TK4- Hercules too (well, you might find one instruction which will make you scratch your head in a VM/370 environment, but nothing that will harm operations in any aspect).



Have fun!


Cheers
JÃŒrgen

[Ivan Warren [e-mail] [hercules-390]]

On 1/9/2017 12:26 AM, ***@yahoo.com.au [hercules-390] wrote:
> On the subject of extra instructions,
> would it be possible to have the
> existing
>
> #define FEATURE_ESAME
>
> split into:
>
> #define FEATURE_ESAME_PSW
> #define FEATURE_ESAME_INST
>
> So that I can enable the ESAME instructions,
> like SAM64, without enabling the ESAME
> PSW (I wish to continue using a "slightly"
> modified EC PSW).
>
> The reason for doing this is that I wish
> to use the 64-bit instructions on MVS 3.8j,
> but MVS 3.8j is unable to preserve a
> full-sized z/Arch PSW.
>
> Thanks. Paul.
>
THAT would be a complete abomination. it would break principles of
operations (extra instructions do NOT).

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

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

> #define FEATURE_ESAME_PSW
> #define FEATURE_ESAME_INST

> THAT would be a complete abomination. it would break principles of
> operations (extra instructions do NOT).

Having two defines instead of one, which
is all I asked for, is neither an abomination
nor does it break any principles of
operation anywhere in the universe.
Especially not the S/380 POP which
is the one I am following.

BFN. Paul.

[Ivan Warren [e-mail] [hercules-390]]

On 1/9/2017 1:06 AM, ***@yahoo.com.au [hercules-390] wrote:
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
>> #define FEATURE_ESAME_PSW
>> #define FEATURE_ESAME_INST
>> THAT would be a complete abomination. it would break principles of
>> operations (extra instructions do NOT).
> Having two defines instead of one, which
> is all I asked for, is neither an abomination
> nor does it break any principles of
> operation anywhere in the universe.
> Especially not the S/380 POP which
> is the one I am following.
>
>
What again is the S/380 IBM manual number ?

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

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

>> Especially not the S/380 POP which
>> is the one I am following.

> What again is the S/380 IBM manual number ?

In the same way that Fujitsu MSP
doesn't have an IBM manual
number, even though it is very
similar to IBM machines, S/380
was also not produced by IBM,
so also doesn't have an IBM
manual number.

Is that a problem? Is there a
reason you don't want to allow
small, non-default changes to
Hercules to support non-iBM
machines like Fujitsu MSP
and/or Jujitsu MVS/380?

Or do you just like being a dog
in a manger?

BFN. Paul.

[Ivan Warren [e-mail] [hercules-390]]

On 1/9/2017 1:26 AM, ***@yahoo.com.au [hercules-390] wrote:
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
>>> Especially not the S/380 POP which
>>> is the one I am following.
>> What again is the S/380 IBM manual number ?
> In the same way that Fujitsu MSP
> doesn't have an IBM manual
> number, even though it is very
> similar to IBM machines, S/380
> was also not produced by IBM,
> so also doesn't have an IBM
> manual number.
>
> Is that a problem? Is there a
> reason you don't want to allow
> small, non-default changes to
> Hercules to support non-iBM
> machines like Fujitsu MSP
> and/or Jujitsu MVS/380?
>
> Or do you just like being a dog
> in a manger?
>
> BFN. Paul.
>
An entirely different project.

You may as well create an Intel processor emulator...

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

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

>> Is that a problem? Is there a
>> reason you don't want to allow
>> small, non-default changes to
>> Hercules to support non-iBM
>> machines like Fujitsu MSP
>> and/or Jujitsu MVS/380?

> An entirely different project.

> You may as well create an Intel processor emulator...

No, this is simply not true.

There is a vast difference between
modifying Hercules to support
slightly different machines, such as
S/360, S/380 or Fujitsu than
modifying Hercules to support
Intel processors.

I simply do not believe you cannot
tell the difference.

We can't have a sensible discussion
if you're going to pretend to not be
able to see a difference.

BFN. Paul.

[Joe Monk [e-mail] [hercules-390]]

Hercules is not a FUJITSU emulator. It is an IBM emulator.

But just to show you the abomination you are asking for, go look at lines
161-301 of cpu.c.

Joe

On Sun, Jan 8, 2017 at 6:36 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
> >> Is that a problem? Is there a
> >> reason you don't want to allow
> >> small, non-default changes to
> >> Hercules to support non-iBM
> >> machines like Fujitsu MSP
> >> and/or Jujitsu MVS/380?
>
> > An entirely different project.
>
> > You may as well create an Intel processor emulator...
>
> No, this is simply not true.
>
> There is a vast difference between
> modifying Hercules to support
> slightly different machines, such as
> S/360, S/380 or Fujitsu than
> modifying Hercules to support
> Intel processors.
>
> I simply do not believe you cannot
> tell the difference.
>
> We can't have a sensible discussion
> if you're going to pretend to not be
> able to see a difference.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-390]]

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

> Hercules is not a FUJITSU emulator. It is an IBM emulator.

There is no reason for that to be set in
stone. You may as well say that OMA
tape support shouldn't be in Hercules
because that is from OMA, not IBM.

It is no skin off your nose to support
Fujitsu, or S/360 or S/380 or OMA
extensions (ie more options than
OMA provided).

The actual change I asked for was
completely innocuous, making a
distinction between ESAME
instructions and CPU.

BFN. Paul.

[Joe Monk [e-mail] [hercules-390]]

"The actual change I asked for was
completely innocuous,"

No the change you asked for was to turn off the ESAME PSW while leaving
everything else about ESAME enabled. Not innocuous at all.

Joe

On Sun, Jan 8, 2017 at 6:59 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
> > Hercules is not a FUJITSU emulator. It is an IBM emulator.
>
> There is no reason for that to be set in
> stone. You may as well say that OMA
> tape support shouldn't be in Hercules
> because that is from OMA, not IBM.
>
> It is no skin off your nose to support
> Fujitsu, or S/360 or S/380 or OMA
> extensions (ie more options than
> OMA provided).
>
> The actual change I asked for was
> completely innocuous, making a
> distinction between ESAME
> instructions and CPU.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-390]]

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

>> The actual change I asked for was
>> completely innocuous,

> No the change you asked for was to turn
> off the ESAME PSW while leaving
> everything else about ESAME enabled.
> Not innocuous at all.

No, that was a change that *I* was going
to make to Hercules/380. Whether that
is innocuous or not is a separate debate.

The only change I asked of the Hercules
team was to split one define into two,
which is completely innocuous and
doesn't harm you in the slightest.

I am interested to know why you would go
out of your way to prevent me from getting
those 2 defines implemented. What's in it
for you?

BFN. Paul.

[Joe Monk [e-mail] [hercules-390]]

"The only change I asked of the Hercules
team was to split one define into two,
which is completely innocuous and
doesn't harm you in the slightest."

There are no less than 37 code modules in hercules that rely on
FEATURE_ESAME. Asking the hercules developers for nonsense tasks like
splitting that define distracts them from fixing the IO subsystem and other
things on the issue list that currently dont work correctly.

Joe

On Sun, Jan 8, 2017 at 7:31 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
> >> The actual change I asked for was
> >> completely innocuous,
>
> > No the change you asked for was to turn
> > off the ESAME PSW while leaving
> > everything else about ESAME enabled.
> > Not innocuous at all.
>
> No, that was a change that *I* was going
> to make to Hercules/380. Whether that
> is innocuous or not is a separate debate.
>
> The only change I asked of the Hercules
> team was to split one define into two,
> which is completely innocuous and
> doesn't harm you in the slightest.
>
> I am interested to know why you would go
> out of your way to prevent me from getting
> those 2 defines implemented. What's in it
> for you?
>
> BFN. Paul.
>
>

[[e-mail] [hercules-390]]

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

>> The only change I asked of the Hercules
>> team was to split one define into two,
>> which is completely innocuous and
>> doesn't harm you in the slightest.

> There are no less than 37 code modules
> in hercules that rely on FEATURE_ESAME

I would hope that most of them can be
globally changed from FEATURE_ESAME
to FEATURE_ESAME_INST and that
only a much smaller number of changes
would be required to switch to
FEATURE_ESAME_PSW.

> Asking the hercules developers for nonsense
> tasks like splitting that define distracts them
> from fixing the IO subsystem and other things
> on the issue list that currently dont work correctly.

Ok, fair enough. I understand your
position, even though I obviously
think the change is far from being
nonsense, just because you
personally don't have a use for
64-bit programming on a free
operating system.

BFN. Paul.

[Joe Monk [e-mail] [hercules-390]]

Besides, if what I'm reading is true, there is a major change coming in the
core design of hercules which is going to break all your S380 stuff anyway.

https://github.com/hercules-390/hyperion/issues/183

Joe

On Sun, Jan 8, 2017 at 7:52 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
> >> The only change I asked of the Hercules
> >> team was to split one define into two,
> >> which is completely innocuous and
> >> doesn't harm you in the slightest.
>
> > There are no less than 37 code modules
> > in hercules that rely on FEATURE_ESAME
>
> I would hope that most of them can be
> globally changed from FEATURE_ESAME
> to FEATURE_ESAME_INST and that
> only a much smaller number of changes
> would be required to switch to
> FEATURE_ESAME_PSW.
>
> > Asking the hercules developers for nonsense
> > tasks like splitting that define distracts them
> > from fixing the IO subsystem and other things
> > on the issue list that currently dont work correctly.
>
> Ok, fair enough. I understand your
> position, even though I obviously
> think the change is far from being
> nonsense, just because you
> personally don't have a use for
> 64-bit programming on a free
> operating system.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-390]]

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

> Besides, if what I'm reading is true, there
> is a major change coming in the core
> design of hercules which is going to break
> all your S380 stuff anyway.

I read that link, but didn't interpret it the
same way you seem to have done.

Regardless, I have a 2c suggestion:

I would suggest assuming/hypothesizing
that for some unspecified reason, it so
happens that it is quite normal for
customers with z/Arch hardware to
also wish to run old OSes, such as
MVS 3.8j or DOS R34 or PDOS/370.
ie not just the applications, but the
operating systems too.

As such, customers for the last 30
years have told IBM that they must
provide fully upwardly-compatible
hardware.

Which means that S/370 I/O etc
still works on z/Arch, although an
operating system or a hardware
switch can choose to switch from S/370
I/O to S/390 I/O and back again,
whatever it likes.

If the world/IBM had followed the
above approach, and we had a
machine that was capable of
anything, what would Hercules
look like?

I would suggest that Hercules
would only come in one flavor,
ie z/Arch, and people can and
do directly run MVS 3.8j on
z/Arch.

Once you have that paradigm in
place you can then work on ways
of *optionally* dumbing down
z/Arch+ to actual IBM machines
like S/360 where unaligned
addresses cause exceptions.

BFN. Paul.

[[e-mail] [hercules-390]]

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

> I would suggest that Hercules
> would only come in one flavor,
> ie z/Arch, and people can and
> do directly run MVS 3.8j on
> z/Arch.

> Once you have that paradigm in
> place you can then work on ways
> of *optionally* dumbing down
> z/Arch+ to actual IBM machines
> like S/360 where unaligned
> addresses cause exceptions.

And I would further suggest that the
only "dumbing down" that would be
required is to go from z/Arch+ to
z/Arch.

The thing people want to avoid is
writing code using Hercules on z/Arch+
and then finding it doesn't work on
a real z/Arch because real z/Arch
doesn't have "SSK" for example.
And customers will say things like
"for god's sake, didn't you test it
on a real z/Arch even ONCE???".

Whereas we don't have the same
problem with MVS 3.8j users. They
will almost certainly be using
z/Arch+ themselves so that they
can run software targeted to MVS 3.8j
that uses the newer z/Arch instructions.
There is little incentive for them to
say "no, no, I want real S/370, not
z/Arch+".

On the off-chance that the MVS 3.8j
user is using real S/370 hardware or
insists on using an old Hercules that
doesn't support z/Arch+, they are
unlikely to say "didn't you bozos test
your software even once on a real
S/370?". Even if they do say that,
they're not paying customers anyway.
Instead, they'll just report the problem
and the developer will hopefully
remove the non-S/370 instruction at
some point in the future. No real
embarrassment.

Note that I'm not ruling out the
possibility of the various dumb-down
options, like enforcing alignment on
a S/360 mode, but I don't think we
need the CPU op-code table with
3 distinct flavors anymore.

I personally have z/Arch instructions
in my S/370 target, and I note that
base Hercules already allows that to
be done (I just added more to the
list - in fact, I think I added almost
all of them to the list, they just
haven't been tested). I would suggest
that if z/Arch+ was available in Hercules,
very few people would go to the effort
of dumbing it down. All of this - base
Hercules plus Hercules/380, means
that the "370" specification in opcode.c
is pretty much meaningless already,
and I don't think it achieves much of
practical value.

Only dumbing z/Arch+ to z/Arch is of
critical importance.

BFN. Paul.

[Joe Monk [e-mail] [hercules-390]]

Bottom line: If you really feel it is something that should happen, go to
hyperion issues on GitHub and put it in as an issue. Then the developers
will decide.

We can't do anything here by wasting hot air.

Joe

On Mon, Jan 9, 2017 at 8:06 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
> > I would suggest that Hercules
> > would only come in one flavor,
> > ie z/Arch, and people can and
> > do directly run MVS 3.8j on
> > z/Arch.
>
> > Once you have that paradigm in
> > place you can then work on ways
> > of *optionally* dumbing down
> > z/Arch+ to actual IBM machines
> > like S/360 where unaligned
> > addresses cause exceptions.
>
> And I would further suggest that the
> only "dumbing down" that would be
> required is to go from z/Arch+ to
> z/Arch.
>
> The thing people want to avoid is
> writing code using Hercules on z/Arch+
> and then finding it doesn't work on
> a real z/Arch because real z/Arch
> doesn't have "SSK" for example.
> And customers will say things like
> "for god's sake, didn't you test it
> on a real z/Arch even ONCE???".
>
> Whereas we don't have the same
> problem with MVS 3.8j users. They
> will almost certainly be using
> z/Arch+ themselves so that they
> can run software targeted to MVS 3.8j
> that uses the newer z/Arch instructions.
> There is little incentive for them to
> say "no, no, I want real S/370, not
> z/Arch+".
>
> On the off-chance that the MVS 3.8j
> user is using real S/370 hardware or
> insists on using an old Hercules that
> doesn't support z/Arch+, they are
> unlikely to say "didn't you bozos test
> your software even once on a real
> S/370?". Even if they do say that,
> they're not paying customers anyway.
> Instead, they'll just report the problem
> and the developer will hopefully
> remove the non-S/370 instruction at
> some point in the future. No real
> embarrassment.
>
> Note that I'm not ruling out the
> possibility of the various dumb-down
> options, like enforcing alignment on
> a S/360 mode, but I don't think we
> need the CPU op-code table with
> 3 distinct flavors anymore.
>
> I personally have z/Arch instructions
> in my S/370 target, and I note that
> base Hercules already allows that to
> be done (I just added more to the
> list - in fact, I think I added almost
> all of them to the list, they just
> haven't been tested). I would suggest
> that if z/Arch+ was available in Hercules,
> very few people would go to the effort
> of dumbing it down. All of this - base
> Hercules plus Hercules/380, means
> that the "370" specification in opcode.c
> is pretty much meaningless already,
> and I don't think it achieves much of
> practical value.
>
> Only dumbing z/Arch+ to z/Arch is of
> critical importance.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-390]]

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

> Bottom line: If you really feel it is something
> that should happen, go to hyperion issues
> on GitHub and put it in as an issue. Then the
> developers will decide.

> We can't do anything here by wasting hot air.

My suggestions don't just target the
Hyperion target. I post them here so
that anyone with a fork may choose
to implement them.

BFN. Paul.

[Joe Monk [e-mail] [hercules-390]]

"My suggestions don't just target the
Hyperion target..."

Then why hijack a thread that is specifically about Hyperion and its
features?

John Hartmann specifically started this thread to talk about Hyperion and
ARCHLVL.

Joe

On Mon, Jan 9, 2017 at 8:55 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
> > Bottom line: If you really feel it is something
> > that should happen, go to hyperion issues
> > on GitHub and put it in as an issue. Then the
> > developers will decide.
>
> > We can't do anything here by wasting hot air.
>
> My suggestions don't just target the
> Hyperion target. I post them here so
> that anyone with a fork may choose
> to implement them.
>
> BFN. Paul.
>
>

[Tony Harminc [e-mail] [hercules-390]]

On 10 January 2017 at 07:08, Joe Monk ***@gmail.com wrote:

> John Hartmann specifically started this thread to talk about Hyperion and
> ARCHLVL.


I don't think so. In his words "For the benefit of the bystanders [that's
essentially all of us, evidently], my original announcement was one of
policy; it was not a request for discussion."

So, although lots of discussion has in fact taken place here, it still
sounds as though it was just an announcement of how things will be, and if
you don't like such diktat... "If you think the current behaviour of
Hyperion is cute, now is the time to create your own fork of Hyperion (or
stick with spinhawk)".

Tony H.

[[e-mail] [hercules-390]]

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

>> My suggestions don't just target the
>> Hyperion target...

> Then why hijack a thread that is specifically
> about Hyperion and its features?

> John Hartmann specifically started this
> thread to talk about Hyperion and ARCHLVL.

My comments are also targeted at Hyperion,
in fact that would be my main target.

Regardless, is this the first time you've ever
seen a thread veer slightly away from the
original topic?

BFN. Paul.

[Joe Monk [e-mail] [hercules-390]]

"so that they can run software targeted to MVS 3.8j"

I'm not aware of ANY production sites running MVS3.8J.

Joe

On Mon, Jan 9, 2017 at 8:06 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
> > I would suggest that Hercules
> > would only come in one flavor,
> > ie z/Arch, and people can and
> > do directly run MVS 3.8j on
> > z/Arch.
>
> > Once you have that paradigm in
> > place you can then work on ways
> > of *optionally* dumbing down
> > z/Arch+ to actual IBM machines
> > like S/360 where unaligned
> > addresses cause exceptions.
>
> And I would further suggest that the
> only "dumbing down" that would be
> required is to go from z/Arch+ to
> z/Arch.
>
> The thing people want to avoid is
> writing code using Hercules on z/Arch+
> and then finding it doesn't work on
> a real z/Arch because real z/Arch
> doesn't have "SSK" for example.
> And customers will say things like
> "for god's sake, didn't you test it
> on a real z/Arch even ONCE???".
>
> Whereas we don't have the same
> problem with MVS 3.8j users. They
> will almost certainly be using
> z/Arch+ themselves so that they
> can run software targeted to MVS 3.8j
> that uses the newer z/Arch instructions.
> There is little incentive for them to
> say "no, no, I want real S/370, not
> z/Arch+".
>
> On the off-chance that the MVS 3.8j
> user is using real S/370 hardware or
> insists on using an old Hercules that
> doesn't support z/Arch+, they are
> unlikely to say "didn't you bozos test
> your software even once on a real
> S/370?". Even if they do say that,
> they're not paying customers anyway.
> Instead, they'll just report the problem
> and the developer will hopefully
> remove the non-S/370 instruction at
> some point in the future. No real
> embarrassment.
>
> Note that I'm not ruling out the
> possibility of the various dumb-down
> options, like enforcing alignment on
> a S/360 mode, but I don't think we
> need the CPU op-code table with
> 3 distinct flavors anymore.
>
> I personally have z/Arch instructions
> in my S/370 target, and I note that
> base Hercules already allows that to
> be done (I just added more to the
> list - in fact, I think I added almost
> all of them to the list, they just
> haven't been tested). I would suggest
> that if z/Arch+ was available in Hercules,
> very few people would go to the effort
> of dumbing it down. All of this - base
> Hercules plus Hercules/380, means
> that the "370" specification in opcode.c
> is pretty much meaningless already,
> and I don't think it achieves much of
> practical value.
>
> Only dumbing z/Arch+ to z/Arch is of
> critical importance.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-390]]

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

>> so that they can run software targeted to MVS 3.8j

> I'm not aware of ANY production sites running MVS3.8J.

That's exactly my point.

We only really need a z/Arch+ that is one
hardware device that can run ANYTHING,
plus a z/Arch (no "+") that doesn't support
BCMODE, doesn't support SSK, doesn't
support S/370 I/O etc.

Those are the only two modes required.
The rest is just having fun by denying
the z/Arch instructions or whatever. No
commercial user cares.

BFN. Paul.

['Dave Wade' [e-mail] [hercules-390]]

Gentleman,



I thought that this code was always intended to be split. The idea was that we could do things the other way round. So have a full XA/ESA memory model with 370 i/o paradigms, or visa versa. This would allow folks to produce an XA/ESA version of an existing 370 mode OS without having to re-write both the paging and i/o subsystems at the same time.



Dave



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 09 January 2017 01:46
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-390] Instruction leakage into 370 mode.








"The only change I asked of the Hercules
team was to split one define into two,
which is completely innocuous and
doesn't harm you in the slightest."



There are no less than 37 code modules in hercules that rely on FEATURE_ESAME. Asking the hercules developers for nonsense tasks like splitting that define distracts them from fixing the IO subsystem and other things on the issue list that currently dont work correctly.



Joe



On Sun, Jan 8, 2017 at 7:31 PM, ***@yahoo.com.au <mailto:***@yahoo.com.au> [hercules-390] <hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> > wrote:



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

>> The actual change I asked for was
>> completely innocuous,

> No the change you asked for was to turn
> off the ESAME PSW while leaving
> everything else about ESAME enabled.
> Not innocuous at all.

No, that was a change that *I* was going
to make to Hercules/380. Whether that
is innocuous or not is a separate debate.

The only change I asked of the Hercules
team was to split one define into two,
which is completely innocuous and
doesn't harm you in the slightest.

I am interested to know why you would go
out of your way to prevent me from getting
those 2 defines implemented. What's in it
for you?

BFN. Paul.

[[e-mail] [hercules-390]]

- - - In hercules-***@yahoogroups.com, <***@... wrote:
> On 1/9/2017 12:26 AM, ***@... mailto:***@... [hercules-390] wrote:
>> On the subject of extra instructions,
>>would it be possible to have the
>>existing
>> #define FEATURE_ESAME
>>split into:
>> #define FEATURE_ESAME_PSW
>> #define FEATURE_ESAME_INST
>> So that I can enable the ESAME instructions,
>>like SAM64, without enabling the ESAME
>>PSW (I wish to continue using a "slightly"
>>modified EC PSW).
>> The reason for doing this is that I wish
>>to use the 64-bit instructions on MVS 3.8j,
>>but MVS 3.8j is unable to preserve a
>>full-sized z/Arch PSW.
>> Thanks. Paul.
> THAT would be a complete abomination. it would break
>principles of operations (extra instructions do NOT).
> --Ivan
> [Non-text portions of this message have been removed]

So adding extra instructions is an abomination
because
adding extra instructions is not an abomination?

[Ivan Warren [e-mail] [hercules-390]]

On 1/9/2017 11:32 AM, ***@yahoo.com [hercules-390] wrote:
>
> So adding extra instructions is an abomination
> because
> adding extra instructions is not an abomination?
>
>
No.. Not raising an exception when a bit in the PSW is set that
EXPLICITLY requires an exception to be raised *IS* a deviation ! (when
bit 12 is 1 and bit 32 is 1 then an early specification exception occurs).

However, there is NOTHING in the S/370 Principles of Operation that
indicates that instructions not described in the manual should raise a
PIC 1 - It actually DOES state that instructions not described *MAY* not
raise an exception - this is explicitly described as model dependent.

Therefore S/380 *IS* an abomination (it breaks EVERY virtualization, and
system protection rules since it allows storage access without a
supervisor/hypervisor control)... however KM working in S/370 is NOT an
abomination - just a model dependent feature.

--Ivan



[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

- - - In hercules-***@yahoogroups.com, <***@...>wrote:
>On 1/9/2017 11:32 AM, ***@... mailto:***@... [hercules-390] wrote:
>> So adding extra instructions is an abomination
>>because
>> adding extra instructions is not an abomination?
> No.. Not raising an exception when a bit in the PSW is set that
>EXPLICITLY requires an exception to be raised *IS* a deviation ! (when
>bit 12 is 1 and bit 32 is 1 then an early specification exception occurs).
> However, there is NOTHING in the S/370 Principles of Operation that
>indicates that instructions not described in the manual should raise a
>PIC 1 - It actually DOES state that instructions not described *MAY* not
>raise an exception - this is explicitly described as model dependent.
> Therefore S/380 *IS* an abomination (it breaks EVERY virtualization, and
>system protection rules since it allows storage access without a
>supervisor/hypervisor control)... however KM working in S/370 is NOT an
>abomination - just a model dependent feature.
> --Ivan
> [Non-text portions of this message have been removed]

Paul was asking to add extra instructions.

Paul clearly stated that he wanted to *avoid* changing the
PSW anymore than he already had.

If dropping a S370-24bit restriction to use a S370-31bit feature
is an abomination, then Hercules dropping S360 restrictions to
run on a S370-24bit emulator is the same.
So are both Hercules and IBM an abomination on how S360
runs on a S370-24bit system?

The argument that someone on planet Earth may someday
want to have an option for an AMODE 31 PSW to cause a
program interruption on a S370-24bit emulator will not happen.

If you include sentient beings in the Milky Way that don't
know what Hercules is, still close to zero chance of finding
anyone or sentient being wanting that option.

Now the Universe is larger and there is a small chance that
some sentient being that doesn't know what Hercules is
might want the option of a program interruption if they knew
what Hercules is.

But if there is a multiverse, then your chances go up if you
were able to distribute to all parallel universes then the option
might be exercised.

Hercules was originally designed to be useful but for almost
ten years there has been an argument blocking a major use
of Hercules.

You cover blocking by calling dropping an unwanted
restriction an abomination.

I just say that forcing the marketing restriction for the
purpose of blocking progress is a shame and I am glad
that I am not involved in anyway.

[Joe Monk [e-mail] [hercules-390]]

"If dropping a S370-24bit restriction to use a S370-31bit feature
is an abomination, then Hercules dropping S360 restrictions to
run on a S370-24bit emulator is the same.
So are both Hercules and IBM an abomination on how S360
runs on a S370-24bit system?"

A 370/158 can run MVT and MFT (OS/360) with no changes to the hardware.

A 370/158 cannot run MVS/XA in 31 bit mode, partially because it doesn't
have the instruction set, and is not capable of being updated with the
instruction set to do so.

A 4381 can run MVT, MFT, MVS, and MVS/XA.

A 3090 can run MVT, MFT, MVS, MVS/XA, and MVS/ESA.

A 370/158, 4381, and 3090 are all S/370 processors.

It's not a marketing restriction. Certain features are available on certain
models.

Paul's abomination is the equivalent of trying to run MVS/ESA on a 370/158.

Joe


On Mon, Jan 9, 2017 at 10:36 AM, ***@yahoo.com [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> - - - In hercules-***@yahoogroups.com, <***@...>wrote:
> >On 1/9/2017 11:32 AM, ***@... mailto:***@... [hercules-390]
> wrote:
> >> So adding extra instructions is an abomination
> >>because
> >> adding extra instructions is not an abomination?
> > No.. Not raising an exception when a bit in the PSW is set that
> >EXPLICITLY requires an exception to be raised *IS* a deviation ! (when
> >bit 12 is 1 and bit 32 is 1 then an early specification exception occurs).
> > However, there is NOTHING in the S/370 Principles of Operation that
> >indicates that instructions not described in the manual should raise a
> >PIC 1 - It actually DOES state that instructions not described *MAY* not
> >raise an exception - this is explicitly described as model dependent.
> > Therefore S/380 *IS* an abomination (it breaks EVERY virtualization, and
> >system protection rules since it allows storage access without a
> >supervisor/hypervisor control)... however KM working in S/370 is NOT an
> >abomination - just a model dependent feature.
> > --Ivan
> > [Non-text portions of this message have been removed]
>
> Paul was asking to add extra instructions.
>
> Paul clearly stated that he wanted to *avoid* changing the
> PSW anymore than he already had.
>
> If dropping a S370-24bit restriction to use a S370-31bit feature
> is an abomination, then Hercules dropping S360 restrictions to
> run on a S370-24bit emulator is the same.
> So are both Hercules and IBM an abomination on how S360
> runs on a S370-24bit system?
>
> The argument that someone on planet Earth may someday
> want to have an option for an AMODE 31 PSW to cause a
> program interruption on a S370-24bit emulator will not happen.
>
> If you include sentient beings in the Milky Way that don't
> know what Hercules is, still close to zero chance of finding
> anyone or sentient being wanting that option.
>
> Now the Universe is larger and there is a small chance that
> some sentient being that doesn't know what Hercules is
> might want the option of a program interruption if they knew
> what Hercules is.
>
> But if there is a multiverse, then your chances go up if you
> were able to distribute to all parallel universes then the option
> might be exercised.
>
> Hercules was originally designed to be useful but for almost
> ten years there has been an argument blocking a major use
> of Hercules.
>
> You cover blocking by calling dropping an unwanted
> restriction an abomination.
>
> I just say that forcing the marketing restriction for the
> purpose of blocking progress is a shame and I am glad
> that I am not involved in anyway.
>
>

[[e-mail] [hercules-390]]

- - - In hercules-***@yahoogroups.com, <***@...> wrote:
>> "If dropping a S370-24bit restriction to use a S370-31bit feature
>>is an abomination, then Hercules dropping S360 restrictions to
>>run on a S370-24bit emulator is the same.
>> So are both Hercules and IBM an abomination on how S360
>>runs on a S370-24bit system?"
> A 370/158 can run MVT and MFT (OS/360) with no changes to the hardware.

Yes, but the S360 restrictions are lost.
Now we need to remove S370-24bit marketing restrictions.

> A 370/158 cannot run MVS/XA in 31 bit mode, partially because
>it doesn't have the instruction set, and is not capable of being
>updated with the instruction set to do so.

Yes, not without an emulator.
Put Paul's code on it, get a license and no issue.

> A 4381 can run MVT, MFT, MVS, and MVS/XA.

Been there, done that, and got the tee shirt.
It was a 64MB 4381 with MVS/SP3 and then later MVS/XA

> A 3090 can run MVT, MFT, MVS, MVS/XA, and MVS/ESA.
>A 370/158, 4381, and 3090 are all S/370 processors.

Yes, S370-31bit does run on a 4381 and 3090 as previously
noted by:
SA22-7085-0_S370-XA_Principles_of_Operation_Mar83.pdf
SA22-7085-1_S370-XA_Principles_of_Operation_Jan87.pdf
that pre-date:
GA22-7000-10_370_Principles_of_Operation_Sep87.pdf
and also give specs for bits enabled in the PSW for AMODE 31

> It's not a marketing restriction. Certain features are available
>on certain models.

It is a marketing restriction.
IBM had PCM that would have jumped on that immediately.
The restrictions served no other purpose and still don't.

I worked for a PCM that allowed more than two processors by
removing the blocks in MVS 3.8j which cost IBM business.

>Paul's abomination is the equivalent of trying to run MVS/ESA
>on a 370/158.
> Joe
- - - old notes snipped - - -

If Paul can get a license and the hardware and wants to run
MVS/ESA on a S370-24bit system, more power to him.
I suspect that his butchered GCC with his butchered
Hercules could be easily adapted.
Getting enough memory to do the initial compile would
be an issue but compiles could be done on his OS380
or P.C. cross-system compiles.

It is still shameful that ten years of effort have been spent
blocking the removal of unwanted restrictions.
Hercules already has the code to allow AMODE 31,
it is just politics or worse preventing its use.
Same for adding the fifth format of STOR, segment, and
page tables. Hercules already has the code but use
is blocked for the already mentioned politics or worse.

Aren't we proud of the wasted ten years? Not.

[Joe Monk [e-mail] [hercules-390]]

Sounds more like you're grinding a personal ax.

Joe

On Mon, Jan 9, 2017 at 12:05 PM, ***@yahoo.com [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> - - - In hercules-***@yahoogroups.com, <***@...> wrote:
> >> "If dropping a S370-24bit restriction to use a S370-31bit feature
> >>is an abomination, then Hercules dropping S360 restrictions to
> >>run on a S370-24bit emulator is the same.
> >> So are both Hercules and IBM an abomination on how S360
> >>runs on a S370-24bit system?"
> > A 370/158 can run MVT and MFT (OS/360) with no changes to the hardware.
>
> Yes, but the S360 restrictions are lost.
> Now we need to remove S370-24bit marketing restrictions.
>
> > A 370/158 cannot run MVS/XA in 31 bit mode, partially because
> >it doesn't have the instruction set, and is not capable of being
> >updated with the instruction set to do so.
>
> Yes, not without an emulator.
> Put Paul's code on it, get a license and no issue.
>
> > A 4381 can run MVT, MFT, MVS, and MVS/XA.
>
> Been there, done that, and got the tee shirt.
> It was a 64MB 4381 with MVS/SP3 and then later MVS/XA
>
> > A 3090 can run MVT, MFT, MVS, MVS/XA, and MVS/ESA.
> >A 370/158, 4381, and 3090 are all S/370 processors.
>
> Yes, S370-31bit does run on a 4381 and 3090 as previously
> noted by:
> SA22-7085-0_S370-XA_Principles_of_Operation_Mar83.pdf
> SA22-7085-1_S370-XA_Principles_of_Operation_Jan87.pdf
> that pre-date:
> GA22-7000-10_370_Principles_of_Operation_Sep87.pdf
> and also give specs for bits enabled in the PSW for AMODE 31
>
> > It's not a marketing restriction. Certain features are available
> >on certain models.
>
> It is a marketing restriction.
> IBM had PCM that would have jumped on that immediately.
> The restrictions served no other purpose and still don't.
>
> I worked for a PCM that allowed more than two processors by
> removing the blocks in MVS 3.8j which cost IBM business.
>
> >Paul's abomination is the equivalent of trying to run MVS/ESA
> >on a 370/158.
> > Joe
> - - - old notes snipped - - -
>
> If Paul can get a license and the hardware and wants to run
> MVS/ESA on a S370-24bit system, more power to him.
> I suspect that his butchered GCC with his butchered
> Hercules could be easily adapted.
> Getting enough memory to do the initial compile would
> be an issue but compiles could be done on his OS380
> or P.C. cross-system compiles.
>
> It is still shameful that ten years of effort have been spent
> blocking the removal of unwanted restrictions.
> Hercules already has the code to allow AMODE 31,
> it is just politics or worse preventing its use.
> Same for adding the fifth format of STOR, segment, and
> page tables. Hercules already has the code but use
> is blocked for the already mentioned politics or worse.
>
> Aren't we proud of the wasted ten years? Not.
>
>

[[e-mail] [hercules-390]]

- - - In hercules-***@yahoogroups.com, <***@...> wrote:
> Sounds more like you're grinding a personal ax.
> Joe
- - - old notes snipped - - -

No personal ax but also no reason for you to switch from the
facts to comments about the person pointing them out.

Ignoring S360-16 bit and S360-32bit:

S360-24bit had an architectural limit of
16MB real memory
zero virtual memory.

IBM had what some might call an abomination but others
might call progress which brings us to early S370-24 bit.

S370-24bit early had an architectural limit of
16MB real memory
16MB virtual memory

IBM had what some might call an abomination but others
might call progress which brings us to later S370-24 bit.

S370-24bit later had an architectural limit of
2GB real memory
16MB virtual memory

For marketing reasons, 2GB virtual memory was skipped.

IBM had what some might call an abomination but others
might call progress which brings us to S370-31bit.

S370-31bit had an architectural limit of
2GB real memory
2GB virtual memory

IBM had what some might call an abomination but others
might call progress which brings us to 64bit systems.

Hercules has the code for all but Hercules politics calls
progress an abomination. Everyone must build and
maintain there own out-of-date butchery of Hercules if
they want reasonable features that harm no one else.

We have AMODE 31, TCPIP, CTCE, TDF, but people
download a politically incomplete package then they
may need to match, merge, and rebuild themselves
or other people must maintain the butchery for them.

Blocking the removal of restrictions would harm no one.
No real reason to block the removal of the restrictions,
but that is the facts.

[Joe Monk [e-mail] [hercules-390]]

"S360-24bit had an architectural limit of
16MB real memory
zero virtual memory."

Nope. The 360/40 had virtual memory. As a matter of fact, early VM(CP-40)
was developed on a 360/40 with virtual memory and OS/360 running as a guest.

Joe

On Mon, Jan 9, 2017 at 3:16 PM, ***@yahoo.com [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> - - - In hercules-***@yahoogroups.com, <***@...> wrote:
> > Sounds more like you're grinding a personal ax.
> > Joe
> - - - old notes snipped - - -
>
> No personal ax but also no reason for you to switch from the
> facts to comments about the person pointing them out.
>
> Ignoring S360-16 bit and S360-32bit:
>
> S360-24bit had an architectural limit of
> 16MB real memory
> zero virtual memory.
>
> IBM had what some might call an abomination but others
> might call progress which brings us to early S370-24 bit.
>
> S370-24bit early had an architectural limit of
> 16MB real memory
> 16MB virtual memory
>
> IBM had what some might call an abomination but others
> might call progress which brings us to later S370-24 bit.
>
> S370-24bit later had an architectural limit of
> 2GB real memory
> 16MB virtual memory
>
> For marketing reasons, 2GB virtual memory was skipped.
>
> IBM had what some might call an abomination but others
> might call progress which brings us to S370-31bit.
>
> S370-31bit had an architectural limit of
> 2GB real memory
> 2GB virtual memory
>
> IBM had what some might call an abomination but others
> might call progress which brings us to 64bit systems.
>
> Hercules has the code for all but Hercules politics calls
> progress an abomination. Everyone must build and
> maintain there own out-of-date butchery of Hercules if
> they want reasonable features that harm no one else.
>
> We have AMODE 31, TCPIP, CTCE, TDF, but people
> download a politically incomplete package then they
> may need to match, merge, and rebuild themselves
> or other people must maintain the butchery for them.
>
> Blocking the removal of restrictions would harm no one.
> No real reason to block the removal of the restrictions,
> but that is the facts.
>
>

[[e-mail] [hercules-390]]

- - - In hercules-***@yahoogroups.com, <***@...> wrote: >>"S360-24bit had an architectural limit of >>16MB real memory
>>zero virtual memory." > Nope. The 360/40 had virtual memory. As a matter of fact, early
>VM(CP-40) was developed on a 360/40 with virtual memory and
>OS/360 running as a guest.
>Joe

- - - old notes snipped - - -


Perhaps I forgot to define a page data set for the S360/40 that I ran?
We alternated between stand-alone programs and MFT because
without virtual memory, we didn't have much memory to run much.


More likely is that for your S360/40, some type of bolt-on box was
added for virtual memory development. Thanks for that tidbit.


You didn't mention that a S360/67 could sort-of emulate
S360-24bit but could have virtual memory.


None have anything to do with progress being an abomination.

[[e-mail] [hercules-390]]

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

> Therefore S/380 *IS* an abomination (it
> breaks EVERY virtualization, and
> system protection rules since it allows
> storage access without a
> supervisor/hypervisor control)

This is a red herring, but regardless,
you're stuck in a rut.

Jason Winter produced a flavor of
S/380 that had memory protection
in 2009. It only worked with MVS
though, but it provided the protected
memory for all MVS jobs.

I implemented Laddie's S/380 design
in 2010, which also allows memory
protection, but it requires OS modifications
to work, and so far only PDOS/380 has
been written to make use of that.

In 2016 somitcw and myself I came up
with a new idea of how to implement
S/380, which was to use Hercules 64-bit
and give every ATL user their own 2 GiB
chunk of memory, thus also offering
memory protection. This has not yet
been implemented, and that is a request
for another day.

The multiple designs of S/380 storage have
nothing to do with the simple and polite
request I made to split the ESAME define
into instructions and PSW.

This is no skin off anyone's nose, as it is
a perfectly logical split that affects no-one
negatively. It just makes the separate
aspects of ESAME displayed better.

BFN. Paul.

[Charles Anthony [e-mail] [hercules-390]]

On Mon, Jan 9, 2017 at 4:03 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
>
> The multiple designs of S/380 storage have
> nothing to do with the simple and polite
> request I made to split the ESAME define
> into instructions and PSW.
>
> This is no skin off anyone's nose, as it is
> a perfectly logical split that affects no-one
> negatively. It just makes the separate
> aspects of ESAME displayed better.
>
>
From the sidelines:


$ grep ESAME *.[ch] | wc -l
1141

This may be a conceptually simple request, but implementation is a lot of
work.

-- Charles

[[e-mail] [hercules-390]]

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

> The multiple designs of S/380 storage have
> nothing to do with the simple and polite
> request I made to split the ESAME define
> into instructions and PSW.

> From the sidelines:

> $ grep ESAME *.[ch] | wc -l

> This may be a conceptually simple request,
> but implementation is a lot of work.

Ok, sure. If it is considered to be a big
job, that's fine. What's not fine is to
tie it into ONE of MANY possible ATL
storage designs and write the whole
thing off as an abomination, which
it isn't, in any way.

Secondly, practically every occurrence
of "ESAME" is in fact an instruction,
not a PSW, and as such, a global
change from FEATURE_ESAME
to FEATURE_ESAME_INST is a
trivial task.

Or alternatively, we can just leave
FEATURE_ESAME to *mean*
"ESAME instruction", and just
introduce a new ESAME_PSW for
the references that involve a PSW
rather than instruction.

In addition, I don't even need it to
be accurate at first. I just want, as I
come across them, any reference
to the z/Arch PSW to be changed
to ESAME_PSW, so that it becomes
accurate over time.

load_psw and store_psw in cpu.c
plus SET_ADDRESSING_MODE
in opcode.h are the ones I know
of in Hercules 3.07 that I can
remember. I think if there are others
that I haven't found they are
apparently not affecting me.

BFN. Paul.

[Joe Monk [e-mail] [hercules-390]]

"load_psw and store_psw in cpu.c"

Apparently you missed the ARCH_DEP in front of load and store psw:

void ARCH_DEP(store_psw) (REGS *regs, BYTE *addr)

int ARCH_DEP(load_psw) (REGS *regs, BYTE *addr)

Joe




On Mon, Jan 9, 2017 at 6:24 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
> > The multiple designs of S/380 storage have
> > nothing to do with the simple and polite
> > request I made to split the ESAME define
> > into instructions and PSW.
>
> > From the sidelines:
>
> > $ grep ESAME *.[ch] | wc -l
>
> > This may be a conceptually simple request,
> > but implementation is a lot of work.
>
> Ok, sure. If it is considered to be a big
> job, that's fine. What's not fine is to
> tie it into ONE of MANY possible ATL
> storage designs and write the whole
> thing off as an abomination, which
> it isn't, in any way.
>
> Secondly, practically every occurrence
> of "ESAME" is in fact an instruction,
> not a PSW, and as such, a global
> change from FEATURE_ESAME
> to FEATURE_ESAME_INST is a
> trivial task.
>
> Or alternatively, we can just leave
> FEATURE_ESAME to *mean*
> "ESAME instruction", and just
> introduce a new ESAME_PSW for
> the references that involve a PSW
> rather than instruction.
>
> In addition, I don't even need it to
> be accurate at first. I just want, as I
> come across them, any reference
> to the z/Arch PSW to be changed
> to ESAME_PSW, so that it becomes
> accurate over time.
>
> load_psw and store_psw in cpu.c
> plus SET_ADDRESSING_MODE
> in opcode.h are the ones I know
> of in Hercules 3.07 that I can
> remember. I think if there are others
> that I haven't found they are
> apparently not affecting me.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-390]]

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

>> load_psw and store_psw in cpu.c

> Apparently you missed the ARCH_DEP
> in front of load and store psw:
> void ARCH_DEP(store_psw) (REGS *regs, BYTE *addr)
> int ARCH_DEP(load_psw) (REGS *regs, BYTE *addr)

I don't know what your point is.

In S/370 mode, for the above functions,
I need to ensure that
FEATURE_ESAME_PSW is *not* in
effect, even though I have *enabled*
FEATURE_ESAME_INST in S/370
mode.

Again - in S/370 mode I want SAM64
to work, but not have an ESAME PSW.
I need ESAME instructions, but not
ESAME PSW.

BFN. Paul.

[Joe Monk [e-mail] [hercules-390]]

Right. So write a module, similar to S37X that can be loaded with ldmod.
Problem Solved.

And since you're such a fabulous C++ programmer, you should have no
problems following the pattern already there.

Joe

On Mon, Jan 9, 2017 at 6:49 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
> >> load_psw and store_psw in cpu.c
>
> > Apparently you missed the ARCH_DEP
> > in front of load and store psw:
> > void ARCH_DEP(store_psw) (REGS *regs, BYTE *addr)
> > int ARCH_DEP(load_psw) (REGS *regs, BYTE *addr)
>
> I don't know what your point is.
>
> In S/370 mode, for the above functions,
> I need to ensure that
> FEATURE_ESAME_PSW is *not* in
> effect, even though I have *enabled*
> FEATURE_ESAME_INST in S/370
> mode.
>
> Again - in S/370 mode I want SAM64
> to work, but not have an ESAME PSW.
> I need ESAME instructions, but not
> ESAME PSW.
>
> BFN. Paul.
>
>

[[e-mail] [hercules-390]]

- - - In hercules-***@yahoogroups.com, <***@...> wrote:
> Right. So write a module, similar to S37X that can be loaded
>with ldmod. Problem Solved.
> And since you're such a fabulous C++ programmer, you should
>have no problems following the pattern already there.
> Joe
- - - old notes snipped - - -

Every time someone request a Hercules feature be added,
your answer of "write your own Hercules" may not always be the
most appropriate or kindest answer.

P.S. We already have multiple versions of S37X which I see as an
issue. Put one complete S37X module available in Hercules and
Paul might slow down asking for feature splits in Hercules source.
Complete should include SAM64, SAM31, SAM24, TAM, BSM,
BASSM, KM, and many other instructions.

[[e-mail] [hercules-390]]

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

> Right. So write a module, similar to S37X
> that can be loaded with ldmod. Problem Solved.

S37X is only one part of the equation. I
have actually already got that covered
with this change:

C:\devel\hercules>cvs diff -r 1.12 -r 1.13 opcode.h
Index: opcode.h
===================================================================
RCS file: c:\cvsroot/hercules/opcode.h,v
retrieving revision 1.12
retrieving revision 1.13
diff -r1.12 -r1.13
88a89,91
> #ifdef FEATURE_S380
> #define GENx___x___x900 GENx37Xx___x900
> #else
96a100
> #endif
106a111,113
> #ifdef FEATURE_S380
> #define GENx___x390x900 GENx37Xx390x900
> #else
114a122
> #endif


The other part of the change is to make sure
that the ESAME instructions are actually
being compiled in. They are all hidden
behind #ifdef ESAME directives. They need
to be opened up for 370 mode, and that
means #defining ESAME. Which has the
side-effect of enabling the ESAME PSW,
which is what I wish to avoid.

> And since you're such a fabulous C++
> programmer, you should have no
> problems following the pattern already there.

Sorry, you're the one who seems to be
claiming to be the expert on Hercules
design. I've already told you how I
would do it, but you seem to know
better.

BFN. Paul.

[Charles Anthony [e-mail] [hercules-390]]

On Mon, Jan 9, 2017 at 4:24 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> ---In hercules-***@yahoogroups.com, <***@...> wrote :
>
> > The multiple designs of S/380 storage have
> > nothing to do with the simple and polite
> > request I made to split the ESAME define
> > into instructions and PSW.
>
> > From the sidelines:
>
> > $ grep ESAME *.[ch] | wc -l
>
> > This may be a conceptually simple request,
> > but implementation is a lot of work.
>
> Ok, sure. If it is considered to be a big
> job, that's fine. What's not fine is to
> tie it into ONE of MANY possible ATL
> storage designs and write the whole
> thing off as an abomination, which
> it isn't, in any way.
>
>
Okay; I gotta side with the other guys.

> Secondly, practically every occurrence
> of "ESAME" is in fact an instruction,
> not a PSW, and as such, a global
> change from FEATURE_ESAME
> to FEATURE_ESAME_INST is a
> trivial task.
>
> No, it is not.


> Or alternatively, we can just leave
> FEATURE_ESAME to *mean*
> "ESAME instruction", and just
> introduce a new ESAME_PSW for
> the references that involve a PSW
> rather than instruction.
>
> But, as I understand it, it is not trivial to separate out the PSW and the
instructions. Again, conceptually simple, but work.


> In addition, I don't even need it to
> be accurate at first. I just want, as I
> come across them, any reference
> to the z/Arch PSW to be changed
> to ESAME_PSW, so that it becomes
> accurate over time.
>
>
It you can't do something well, then don't do it.

An inaccurate emulation does more damage then not doing it.

load_psw and store_psw in cpu.c
> plus SET_ADDRESSING_MODE
> in opcode.h are the ones I know
> of in Hercules 3.07 that I can
> remember. I think if there are others
> that I haven't found they are
> apparently not affecting me.
>
>
My point. You have a poor grasp of the complexity of the change.

As I said, I side with the other guys. You are a troll. PLONK.

-- Charles

[[e-mail] [hercules-390]]

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

>> Secondly, practically every occurrence
>> of "ESAME" is in fact an instruction,
>> not a PSW, and as such, a global
>> change from FEATURE_ESAME
>> to FEATURE_ESAME_INST is a
>> trivial task.

> No, it is not.

Yes it is, and I will volunteer to do the
global change if anyone else thinks it
is difficult to do.

>> In addition, I don't even need it to
>> be accurate at first. I just want, as I
>> come across them, any reference
>> to the z/Arch PSW to be changed
>> to ESAME_PSW, so that it becomes
>> accurate over time.

> It you can't do something well, then don't do it.

Wrong. Demanding perfection from day 1
is the wrong thing to do.

> An inaccurate emulation does more damage then not doing it.

Not so. It works identically as before, and
as I am the actual user of this change, I
can tell you with 100% certainty that I
would rather have deficiencies in this
change than not have it at all. I can
fix deficiencies as I find them.

> My point. You have a poor grasp of
> the complexity of the change.

I don't believe that is true, but regardless
you have failed to defend your position.

> As I said, I side with the other guys. You
> are a troll. PLONK.

Wow. The technical issue of an ESAME
define causes people to go off the rails ...
again! If I were to explain this to a lay
person, they would refuse to believe
that a friggin define could possibly be
an emotional issue.

BFN. Paul.

[[e-mail] [hercules-390]]

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

If you have anything relevant to post, please do.

Feel free to include attempts to insult and claim sides,
but please sneak in something to contribute also.

[[e-mail] [hercules-390]]

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

> If you have anything relevant to post, please do.

> Feel free to include attempts to insult and claim sides,
> but please sneak in something to contribute also.

Yes, well said. I'm well-versed at deleting
all the nasty emotional stuff, but please
for god's sake include some technical
information to make it worth the time
doing all that deletion (and/or responding
in kind), as these are in fact TECHNICAL
forums and we have a TECHNICAL
question to be answered, along with any
nastiness some can't help themselves
from adding.

BFN. Paul.

[Charles Anthony [e-mail] [hercules-390]]

On Mon, Jan 9, 2017 at 5:32 PM, ***@yahoo.com.au [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
> Yes, well said. I'm well-versed at deleting
> all the nasty emotional stuff, but please
> for god's sake include some technical
> information to make it worth the time
> doing all that deletion (and/or responding
> in kind), as these are in fact TECHNICAL
> forums and we have a TECHNICAL
> question to be answered, along with any
> nastiness some can't help themselves
> from adding.
>
> BFN. Paul.
>
I apologize to the forum for any indecorous remarks I may have made.

-- Charles

[[e-mail] [hercules-390]]

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

>> Yes, well said. I'm well-versed at deleting
>> all the nasty emotional stuff, but please

> I apologize to the forum for any indecorous
> remarks I may have made.

Thankyou. It is a very rare event on these
forums for someone to admit they did
something wrong.

BFN. Paul.

[[e-mail] [hercules-390]]

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

> As I said, I side with the other guys. You are a troll. PLONK.

BTW, this reminds me of the Young Ones,
which I recommend everyone watch if
you haven't already:

http://www.ratman.biz/archive/young_ones/bambi.html

Neil: [reading the title of the notebook] "O-Level History Notes"?
Rick: Yes, bit of pretty bloody billiant luck, eh? We're doing exactly the same period as I did for O-Level!
Neil: [Reading from the notebook] "Prick is a wonker. Signed, the rest of the class."
Rick: Ah, yes, now, that was a sort of "in joke" that we had in my form. Actually, I was incredibly popular and everyone thought I was great.
Neil: "...I agree with the rest of the class. Signed, Teacher."


BFN. Paul.

[[e-mail] [hercules-390]]

- - - In hercules-***@yahoogroups.com, <***@...> wrote:
- - - beginning snipped - - -
> In 2016 somitcw and myself I came up
>with a new idea of how to implement
>S/380, which was to use Hercules 64-bit
>and give every ATL user their own 2 GiB
>chunk of memory, thus also offering
>memory protection. This has not yet
>been implemented, and that is a request
>for another day.

My final suggestion was for Hercules to give
each address space that requested above the
16MB line it a separate MALLOC memory for that
address space's above the 16MB line memory
frames. 31bit or 64bit no matter.
A mechanization to tell Hercules how much
to MALLOC and later remove the MALLOCed
memory would be nice and efficient but not
absolutely required.

If there was any lack of protection,
it would be in Hercules code.

The lack of memory protection protests are
just a red herring to justify not removing
unwanted restrictions.
Just like calling removing unwanted
restrictions an abomination.

The disagreement will never be resolved
by using logic. Its politics.

[[e-mail] [hercules-390]]

- - - In hercules-***@yahoogroups.com, <***@...> wrote:
> Hi JÃŒrgen, > I was unaware of the availability of "ldmod s37x", as I rarely use MVS 3.8J and
>have not kept up with the updates. After learning about it from your post, I issued
>the command for my VM/370 setup and then attempted to execute a few later
>generation instructions. It works perfectly.
> This is a very acceptable solution for those who want to use these instructions
>and not impose anything permanent on those who would rather not have them
>available in keeping with a more "pure" architecture.
> Thanks for the information!
> Regards,
> Bob
- - - old notes snipped - - -

I don't need them anylonger,
but it seems silly to allow S370/31-bit instructions in S370/24-bit systems
but blocking S370/31-bit features like CR0.10 and PSW.32

IBM marketing restrictions should be removed just like the S360
memory boundary alignment and other restrictions were removed.

If someone wants a weird configuration file option to restore memory
boundaries, page table size limits, and AMODE restrictions, let them
add them add another Hercules branch that no one else can see.

[[e-mail] [hercules-390]]

somitcw


I was talking about clean 24-bit S/370 only. And I was saying "all _eligible_ instructions". I never said something like _all_ instructions. So, in particular, I didn't activate any instruction that requires or makes no sense in 31- or 64-addressing environments. In the TK4- environment I don't care about and don't support any not/never existing 31-bit architecture, but of course I don't prevent anyone from building such an architecture on top of TK4-.


JÃŒrgen



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

- - - In hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com, <***@...> wrote:
> Hi JÃŒrgen, > I was unaware of the availability of "ldmod s37x", as I rarely use MVS 3.8J and
>have not kept up with the updates. After learning about it from your post, I issued
>the command for my VM/370 setup and then attempted to execute a few later
>generation instructions. It works perfectly.
> This is a very acceptable solution for those who want to use these instructions
>and not impose anything permanent on those who would rather not have them
>available in keeping with a more "pure" architecture.
> Thanks for the information!
> Regards,
> Bob
- - - old notes snipped - - -

I don't need them anylonger,
but it seems silly to allow S370/31-bit instructions in S370/24-bit systems
but blocking S370/31-bit features like CR0.10 and PSW.32

IBM marketing restrictions should be removed just like the S360
memory boundary alignment and other restrictions were removed.

If someone wants a weird configuration file option to restore memory
boundaries, page table size limits, and AMODE restrictions, let them
add them add another Hercules branch that no one else can see.

[[e-mail] [hercules-390]]

oops, sorry, of course I meant


"I didn't activate any instruction that requires or makes sense only in 31- or 64-addressing environments"

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

somitcw


I was talking about clean 24-bit S/370 only. And I was saying "all _eligible_ instructions". I never said something like _all_ instructions. So, in particular, I didn't activate any instruction that requires or makes no sense in 31- or 64-addressing environments. In the TK4- environment I don't care about and don't support any not/never existing 31-bit architecture, but of course I don't prevent anyone from building such an architecture on top of TK4-.


JÃŒrgen



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

- - - In hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com, <***@...> wrote:
> Hi JÃŒrgen, > I was unaware of the availability of "ldmod s37x", as I rarely use MVS 3.8J and
>have not kept up with the updates. After learning about it from your post, I issued
>the command for my VM/370 setup and then attempted to execute a few later
>generation instructions. It works perfectly.
> This is a very acceptable solution for those who want to use these instructions
>and not impose anything permanent on those who would rather not have them
>available in keeping with a more "pure" architecture.
> Thanks for the information!
> Regards,
> Bob
- - - old notes snipped - - -

I don't need them anylonger,
but it seems silly to allow S370/31-bit instructions in S370/24-bit systems
but blocking S370/31-bit features like CR0.10 and PSW.32

IBM marketing restrictions should be removed just like the S360
memory boundary alignment and other restrictions were removed.

If someone wants a weird configuration file option to restore memory
boundaries, page table size limits, and AMODE restrictions, let them
add them add another Hercules branch that no one else can see.

[[e-mail] [hercules-390]]

- - - In hercules-***@yahoogroups.com, <***@...> wrote:
> oops, sorry, of course I meant
> "I didn't activate any instruction that requires or makes sense only
>in 31- or 64-addressing environments"
- - - old notes snipped - - -

What did they do to you to make an effort to exclude them?

CR0.10 affects no specific instruction, just optional STOR format,
optional segment table format, and optional page table format
that is already coded for S370-31bit.

PSW.32 affects more how an LA, BALR, BSM, BASSM, and
other instruction operate than whether they makes your sense
or not.
What possible good do you get blocking SAM24 and TAM ?
Why even block SAM31 or SAM64?
Let someone get a specification exception or other PIC or be
allowed to run?

Why not allow them all and allow the CR0.10 and PSW.32
features from the older S370-31 bit Principle of Operation?

SA22-7085-0_S370-XA_Principles_of_Operation_Mar83.pdf
SA22-7085-1_S370-XA_Principles_of_Operation_Jan87.pdf

then either four-and-a-half years or 8 months later:

GA22-7000-10_370_Principles_of_Operation_Sep87.pdf

The biggest impact would be deciding how TB and a few
other supervisor instructions would operate.
In S370-24bit, a TB instruction is always a 31 bit address.
In S370-32bit, a TB address depends on PSW AMODE.
I believe that a few related like RRBE, ISKE, and SSKE are
the same?
No real issue, just decisions to make.
I personally would go with "always a 31-bit address" for
ARCHLVL S360/S370 and would never expect any
crap byte bits set to change the address.

[[e-mail] [hercules-390]]

- - - In hercules-***@yahoogroups.com, <***@...> wrote:
- - - beginning snipped - - -
> SA22-7085-0_S370-XA_Principles_of_Operation_Mar83.pdf
> SA22-7085-1_S370-XA_Principles_of_Operation_Jan87.pdf
>then either four-and-a-half years or 8 months later:
> GA22-7000-10_370_Principles_of_Operation_Sep87.pdf
- - - ending snipped - - -

My GA22-7000-9 IBM System/370 Principles of Operation claims
May83 so another but smaller overlap.

[Maarten Hoes [e-mail] [hercules-390]]

Hi 'somitcw' (sorry, I didn't catch your real name ?),


On Sun, Jan 8, 2017 at 5:42 PM, ***@yahoo.com [hercules-390] <
hercules-***@yahoogroups.com> wrote:

>
>
>
> If someone wants a weird configuration file option to restore memory
> boundaries, page table size limits, and AMODE restrictions, let them
> add them add another Hercules branch that no one else can see.
>

Sounds like you're the perfect candidate to fork off your own
hercules/hyperion branch to do whatever you feel like with it.
;)


- Maarten

[[e-mail] [hercules-390]]

- - - In hercules-***@yahoogroups.com, <***@...> wrote :
> Hi 'somitcw' (sorry, I didn't catch your real name ?),
>On Sun, Jan 8, 2017 at 5:42 PM, ***@... mailto:***@... [hercules-390]
><hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com> wrote:
>> If someone wants a weird configuration file option to restore memory
>>boundaries, page table size limits, and AMODE restrictions, let them
>>add them add another Hercules branch that no one else can see.
> Sounds like you're the perfect candidate to fork off your own hercules/hyperion
>branch to do whatever you feel like with it.
>;)
> - Maarten

Old Hercules 3.12
Incomplete Hyperion development fork.
Fish fork.
S380 always out-of-date fork.
TK4-minus always out-of-date fork
My ten year old request to drop a couple of marketing
restrictions that I'm too old to write code to use anymore.

And any poor user that needs two or more features must manually
update Hercules/Hyperion/Fish/S380/TK4-minus/Relaxed to be
current, merge, and build their own Hercules?

Sounds more like politics than programming which would not
be the option that I would have chosen.

[Ivan Warren [e-mail] [hercules-390]]

On 1/7/2017 6:30 PM, 'John P. Hartmann' ***@gmail.com
[hercules-390] wrote:
> HHC02205E Invalid argument 370
>
> So the the 370 test case ran in ESA mode.
>
> After a couple of other adjustments:
>
> Test KM fc0. 13 OK compares. All pass.
>
> Apologies all round.
>
> Ivan, in the next update, can we have the dancing girls and the beer
> garten, please. Surely the all PoOs allow that too!
>
>
If the POO permits and authorizes (and it does) girls & beers - I have
no issue with it

The POO defines what is permitted, and is forbidden... And none of these
definitions say ANYTHING about those instructions.

If I want to define an instruction that creates Girls and Beer (or Strip
Guys for the developer girls) - then I will still say : Nothing in any
Principles of Operation forbids it !

I however would see no object inside the context of the project - But
allowing Crypto, allowing gcc beyond gcc 3.2 to run in problem state in
legacy operating systems... I'm all for it.

--Ivan



[Non-text portions of this message have been removed]

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

[...]
> Well I just tried the same test as you (but using my
> hyperion, not the official one) and whether dyncrypt
> is loaded or not, cipher instructions *always* program
> check (or at least LM does; I didn't check all of them).
^^
^^

Should be "KM" of course. (Not LM)

['John P. Hartmann' [e-mail] [hercules-390]]

These days x'00' is architected as causing an operation exception. CICS
just had too many of them.

On 06/01/17 20:14, Ivan Warren ***@vmfacility.fr [hercules-390] wrote:
> Only 1 opcode is pretty much guaranteed to generate a PIC 1 : That's
> opcode X'00'.


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

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

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/

[Tony Harminc [e-mail] [hercules-390]]

On 6 January 2017 at 14:16, Ivan Warren ***@vmfacility.fr wrote:
> The only exception was introduced in a late z/Arch POP that specifies
> that opcode X'00' will generate an operation exception (PIC 1). All the
> others specify that there is great chance that no instruction will ever
> be assigned to opcode X'00' and that it *MAY* generate a PIC 1....

The wording and practice changed. As I posted a while back:

The S/370 Principles of Operation GA22-7000 says that "The
operation code 00, with a two-byte instruction format, and the set of
sixteen 16-bit operation codes B2E0 to B2EF, with a four-byte
instruction format, are allocated for software uses where indication
of invalid operation is required. It is improbable that these
operation codes will ever be assigned to an instruction implemented in
the CPU."

However in the zArch Principles of Operation, the wording in the
corresponding place is more than a little different: "Operation code
00 hex will never be assigned to an instruction implemented in the
CPU." And indeed two from the formerly "improbable" range (B2E8 and
B2EC) have been assigned as part of the transactional execution
facility.

Why they did this, I doubt anyone outside Poughkeepsie knows. But at
least 00 *is* now guaranteed to fail!

Tony H.

[Tony Harminc [e-mail] [hercules-390]]

On 6 January 2017 at 13:34, 'John P. Hartmann' ***@gmail.com wrote:
> This will be fixed in the fullness of time as I build test cases that
> fail to program check. Unless someone convinces me he will implement an
> ARCHLVL for such abominations and thus restore out-of-box behaviour to
> the expected state.

This is clearly the correct way to do things - an ARCHLVL 370+ or
something. Or ARCHLVL=370xx where xx matches the POO level. Really,
how hard can it be?

There are multiple customers for Hercules, with very different
expectations. Why should those who want some problem state
instructions from zArch or XA or ESA/370 not be allowed them with a
suitable run-time option? If we want true S/360 fidelity (to say
nothing of the /67 and /44), there is more work to do, e.g. lots of
PIC 6s are needed for improper boundary alignment, things like ICM,
MVCL, etc must be removed, along with the control registers, the TOD
clock, and probably a few more.

Tony H.

[Joe Monk [e-mail] [hercules-390]]

Concur 100%.

Joe

On Fri, Jan 6, 2017 at 2:25 PM, Tony Harminc ***@gmail.com
[hercules-390] <hercules-***@yahoogroups.com> wrote:

>
>
> On 6 January 2017 at 13:34, 'John P. Hartmann' ***@gmail.com wrote:
> > This will be fixed in the fullness of time as I build test cases that
> > fail to program check. Unless someone convinces me he will implement an
> > ARCHLVL for such abominations and thus restore out-of-box behaviour to
> > the expected state.
>
> This is clearly the correct way to do things - an ARCHLVL 370+ or
> something. Or ARCHLVL=370xx where xx matches the POO level. Really,
> how hard can it be?
>
> There are multiple customers for Hercules, with very different
> expectations. Why should those who want some problem state
> instructions from zArch or XA or ESA/370 not be allowed them with a
> suitable run-time option? If we want true S/360 fidelity (to say
> nothing of the /67 and /44), there is more work to do, e.g. lots of
> PIC 6s are needed for improper boundary alignment, things like ICM,
> MVCL, etc must be removed, along with the control registers, the TOD
> clock, and probably a few more.
>
> Tony H.
>
>

['John P. Hartmann' [e-mail] [hercules-390]]

ICM & MVCL were in the base 370. They stay; there is no attempt at
simulating a 360.

On 06/01/17 20:25, Tony Harminc ***@gmail.com [hercules-390] wrote:
>
>
> On 6 January 2017 at 13:34, 'John P. Hartmann' ***@gmail.com wrote:
>> This will be fixed in the fullness of time as I build test cases that
>> fail to program check. Unless someone convinces me he will implement an
>> ARCHLVL for such abominations and thus restore out-of-box behaviour to
>> the expected state.
>
> This is clearly the correct way to do things - an ARCHLVL 370+ or
> something. Or ARCHLVL=370xx where xx matches the POO level. Really,
> how hard can it be?
>
> There are multiple customers for Hercules, with very different
> expectations. Why should those who want some problem state
> instructions from zArch or XA or ESA/370 not be allowed them with a
> suitable run-time option? If we want true S/360 fidelity (to say
> nothing of the /67 and /44), there is more work to do, e.g. lots of
> PIC 6s are needed for improper boundary alignment, things like ICM,
> MVCL, etc must be removed, along with the control registers, the TOD
> clock, and probably a few more.
>
> Tony H.
>
>

[Tony Harminc [e-mail] [hercules-390]]

On 6 January 2017 at 16:00, 'John P. Hartmann' ***@gmail.com wrote:
> ICM & MVCL were in the base 370. They stay; there is no attempt at
> simulating a 360.

Well sure. But if you are going to complain that the presence of some
zArch opcodes in Hercules-running-as-370 will break a copy of DOS/360
with a 1401 emulator because the OS fails to receive a program check,
then you should just as much complain about other failure-to-fail
aspects of that 360-targeted OS when it runs on Hercules as 370.

Or... Agree that the idea of simulating S/360 and various other
variations on the general pre-XA architecture is a good one, and we
are just waiting for someone to implement it. We had someone here not
long ago who wanted 360/91 simulation. That too could be done, though
in the end it was probably not necessary for him.

Tony H.

[[e-mail] [hercules-390]]

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

>

>> On 6 January 2017 at 13:34, 'John P. Hartmann' ***@... mailto:***@... wrote:
>>
>> This will be fixed in the fullness of time as I build test cases that

>> fail to program check. Unless someone convinces me he will implement an

>> ARCHLVL for such abominations and thus restore out-of-box behaviour to

>> the expected state.

>

> This is clearly the correct way to do things - an ARCHLVL 370+ or

> something. Or ARCHLVL=370xx where xx matches the POO level. Really,

> how hard can it be?

>
Hi Tony


Well, yes, how hard can it be? However, no one did it up to now...


While I fully agree that a specific ARCHLVL per abomination would be a clean solution, there might nonetheless exist some practicability arguments speaking against going down this road:
As you say, there are many Hercules users with many different requirements. The number of different ARCHLVLs needed to satisfy those might be significantly larger than one. Even John uses the word abomination in plural. The current list of features, archmodes and abominations already has a certain complexity...
Changing to a different archlvl (even only changing a single feature) can be disruptive... at least it requires the CPs to be in the stopped state, i.e. it interrupts system operation.
Personally I think, that for the purpose of just adding a certain subset of later instructions to S/370 it is fully sufficient to use dynamic modules (like for example dyncrypt or s37x). These can easily be tailored to individual needs and can be loaded and unloaded without any impact on operations. And without any need to mess around with ARCHLVLs.
Just my 5¢.


Cheers
JÃŒrgen