[hercules-390] Scrambled configuration causes weird MAINSIZE restriction

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

A Hercules user, Peppe A.K.A. Giuseppe Vitillaro, reported an issue on
group hercules-os380 which identified another issue.
His Hercules configuration file had his initial ARCHLVL before MAINSIZE.
His MAINSIZE was rejected with a message that MAINSIZE was invalid.
S/370-24bit and S/370-31bit both have instructions that access 31-bit real
memory: ISKE, SSKE, RRBE, and TB.
S/370-24bit and S/370-31bit both use extended IDAW for 31-bit I/O real addresses.
Hercules has been trying to allow the Hercules configuration file to be scrambled.
One line of code appears to break both IBM most current S/370-24bit Principles of
Operation and Hercules attempt to allow a scrambled configuration file.

My test:

HHC01413I Hercules version 4.0.0.9176-SDL-g4ee084f9 (4.0.0.9176)
HHC01414I (C) Copyright 1999-2018 by Roger Bowler, Jan Jaeger, and others
HHC01417I ** The SoftDevLabs version of Hercules **
HHC01415I Build date: Apr 3 2018 at 16:34:16
HHC01417I Built with: Microsoft Visual Studio 2008 (MSVC 150030729 1)
HHC01417I Build type: Windows MSVC AMD64 host architecture build
HHC01417I Modes: S/370 ESA/390 z/Arch
HHC01417I Max CPU Engines: 64
...
* * * following line is how Hercules starts, it is not from any command * * *
Processor CP00: architecture mode z/Arch
...
HHC00811I Processor CP00: architecture mode S/370
HHC02204I ARCHLVL set to S/370 HHC02204I LPARNUM set to BASIC HHC01451E Invalid value 160 specified for MAINSIZE HHC01441E Config file[46] conf/Turnkey_MVS.conf: error processing statement: MAINSIZE 160

https://github.com/hercules-390/hyperion/blob/master/hsccmd.c
/* Validate storage sizes by architecture; minimums handled in * config.c */
if ( (!mainsize && sysblk.maxcpu > 0) || /* 0 only valid if MAXCPU 0 */
( sysblk.arch_mode == ARCH_370 && /* 64M maximum for S/370 support */
The GIT version of spinhawk, hercules-3.13, doesn't show this glitch.

What's going on? Why?

Playing:

HHC01603I archlvl s370
HHC00811I Processor CP00: architecture mode S/370
HHC02204I ARCHLVL set to S/370
HHC02204I LPARNUM set to BASIC
HHC01603I mainsize 65
HHC01451E Invalid value 65 specified for mainsize
HHC01603I mainsize 64
HHC17003I MAIN storage is 64M (mainsize); storage is not locked
HHC01603I archlvl esame
HHC00811I Processor CP00: architecture mode z/Arch
HHC02204I ARCHLVL set to z/Arch
HHC02204I LPARNUM set to 1
HHC02204I CPUIDFMT set to 0
HHC01603I mainsize 65
HHC17003I MAIN storage is 65M (mainsize); storage is not locked
HHC01603I archlvl s370
HHC00811I Processor CP00: architecture mode S/370
HHC02204I ARCHLVL set to S/370
HHC02204I LPARNUM set to BASIC

[Mike Schwab [e-mail] [hercules-390]]

S/370 had enough unused bits to expand physical memory to 64MiB of
real memory, mapping multiple 16MiB address spaces over it. IBM 3084
was the first one with 64MB. https://en.wikipedia.org/wiki/IBM_308X

Post by ***@yahoo.com [hercules-390]
A Hercules user, Peppe A.K.A. Giuseppe Vitillaro, reported an issue on
group hercules-os380 which identified another issue.
His Hercules configuration file had his initial ARCHLVL before MAINSIZE.
His MAINSIZE was rejected with a message that MAINSIZE was invalid.
S/370-24bit and S/370-31bit both have instructions that access 31-bit real
memory: ISKE, SSKE, RRBE, and TB.
S/370-24bit and S/370-31bit both use extended IDAW for 31-bit I/O real addresses.
Hercules has been trying to allow the Hercules configuration file to be scrambled.
One line of code appears to break both IBM most current S/370-24bit Principles of
Operation and Hercules attempt to allow a scrambled configuration file.
HHC01413I Hercules version 4.0.0.9176-SDL-g4ee084f9 (4.0.0.9176)
HHC01414I (C) Copyright 1999-2018 by Roger Bowler, Jan Jaeger, and others
HHC01417I ** The SoftDevLabs version of Hercules **
HHC01415I Build date: Apr 3 2018 at 16:34:16
HHC01417I Built with: Microsoft Visual Studio 2008 (MSVC 150030729 1)
HHC01417I Build type: Windows MSVC AMD64 host architecture build
HHC01417I Modes: S/370 ESA/390 z/Arch
HHC01417I Max CPU Engines: 64
....
* * * following line is how Hercules starts, it is not from any command * * *
Processor CP00: architecture mode z/Arch
....
HHC00811I Processor CP00: architecture mode S/370
HHC02204I ARCHLVL set to S/370 HHC02204I LPARNUM set to BASIC HHC01451E Invalid value 160 specified for MAINSIZE HHC01441E Config file[46] conf/Turnkey_MVS.conf: error processing statement: MAINSIZE 160

https://github.com/hercules-390/hyperion/blob/master/hsccmd.c
/* Validate storage sizes by architecture; minimums handled in * config.c */
if ( (!mainsize && sysblk.maxcpu > 0) || /* 0 only valid if MAXCPU 0 */
( sysblk.arch_mode == ARCH_370 && /* 64M maximum for S/370 support */
The GIT version of spinhawk, hercules-3.13, doesn't show this glitch.

What's going on? Why?
HHC01603I archlvl s370
HHC00811I Processor CP00: architecture mode S/370
HHC02204I ARCHLVL set to S/370
HHC02204I LPARNUM set to BASIC
HHC01603I mainsize 65
HHC01451E Invalid value 65 specified for mainsize
HHC01603I mainsize 64
HHC17003I MAIN storage is 64M (mainsize); storage is not locked
HHC01603I archlvl esame
HHC00811I Processor CP00: architecture mode z/Arch
HHC02204I ARCHLVL set to z/Arch
HHC02204I LPARNUM set to 1
HHC02204I CPUIDFMT set to 0
HHC01603I mainsize 65
HHC17003I MAIN storage is 65M (mainsize); storage is not locked
HHC01603I archlvl s370
HHC00811I Processor CP00: architecture mode S/370
HHC02204I ARCHLVL set to S/370
HHC02204I LPARNUM set to BASIC
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

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

Post by Mike Schwab ***@gmail.com [hercules-390]
S/370 had enough unused bits to expand physical memory to 64MiB of
real memory, mapping multiple 16MiB address spaces over it. IBM 3084
was the first one with 64MB. https://en.wikipedia.org/wiki/IBM_308X
https://en.wikipedia.org/wiki/IBM_308X

- - - old note snipped - - -

Post by Mike Schwab ***@gmail.com [hercules-390]
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Yes, paging maximum real memory use, not a real memory limit, is
where I assUme the weird value was picked up from.
IBM had room to go to 28-bit as in 256MB real memory for paging
memory frames only but at the time didn't have the hardware to
sell and didn't need to help their competition.

The 64MB could be picked for the maximum block size in a CCW ?
A stand-alone dump would have to chain a CCW for more memory.
I would command chain for multiple blocks on tape, but maybe that's me?
Or could the 64MB be the size on my 4381-T92E memory?
But the most current S370-24bit Principles of Operation makes
it clear that I/O IDAW and logical addresses in instructions are limited to
31-bit A.K.A. 2GB which is what is needed.

Many operating systems don't allow a user application to have over
8MB for private virtual memory.
I'm glad that 8MB operating system virtual memory maximum wasn't the
number picked for the maximum architecture real memory size.
I also hope that makes no sense to anyone.

The change also adding a forced Hercules configuration file order is
not good either.

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

Post by ***@yahoo.com [hercules-390]
The change also adding a forced Hercules configuration file order is
not good either.

I concur.

There shouldn't be a restriction on MAINSIZE based on architecture
(maybe a warning... but that's it). There is nothing that restricts a
S/370 system from having more than 64MB of storage (only a restriction
on how much can be used).

Furthermore, as indicated, machine configuration statement order
shouldn't be an issue (at least for backward compatibility).

I think hercules should honor the storage size indicated - regardless of
the final chosen architectural mode !

--Ivan



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

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by ***@yahoo.com [hercules-390]
The change also adding a forced Hercules configuration file order is
not good either.

I concur.
There shouldn't be a restriction on MAINSIZE based on architecture
(maybe a warning... but that's it). There is nothing that restricts a
S/370 system from having more than 64MB of storage (only a restriction
on how much can be used).
Furthermore, as indicated, machine configuration statement order
shouldn't be an issue (at least for backward compatibility).
I think hercules should honor the storage size indicated - regardless of
the final chosen architectural mode !
--Ivan

I agree, a warning may be acceptable, a restriction
seems to much. A config parser which depends from the order,
may become a nightmare.

Peppe.

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

[Mike Schwab [e-mail] [hercules-390]]

Well, APL/360 did set an 8MiB limit. Since the actual hardware didn't
reach that size for another decade after its release, that was
reasonable.
Aren't you trying to create a S/380 hardware definition that includes
new features that S/370 didn't actually have?

Post by ***@yahoo.com [hercules-390]

Post by Mike Schwab ***@gmail.com [hercules-390]
S/370 had enough unused bits to expand physical memory to 64MiB of
real memory, mapping multiple 16MiB address spaces over it. IBM 3084
was the first one with 64MB. https://en.wikipedia.org/wiki/IBM_308X
https://en.wikipedia.org/wiki/IBM_308X

- - - old note snipped - - -

Post by Mike Schwab ***@gmail.com [hercules-390]
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Yes, paging maximum real memory use, not a real memory limit, is
where I assUme the weird value was picked up from.
IBM had room to go to 28-bit as in 256MB real memory for paging
memory frames only but at the time didn't have the hardware to
sell and didn't need to help their competition.
The 64MB could be picked for the maximum block size in a CCW ?
A stand-alone dump would have to chain a CCW for more memory.
I would command chain for multiple blocks on tape, but maybe that's me?
Or could the 64MB be the size on my 4381-T92E memory?
But the most current S370-24bit Principles of Operation makes
it clear that I/O IDAW and logical addresses in instructions are limited to
31-bit A.K.A. 2GB which is what is needed.
Many operating systems don't allow a user application to have over
8MB for private virtual memory.
I'm glad that 8MB operating system virtual memory maximum wasn't the
number picked for the maximum architecture real memory size.
I also hope that makes no sense to anyone.
The change also adding a forced Hercules configuration file order is
not good either.
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

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

Post by Mike Schwab ***@gmail.com [hercules-390]
Well, APL/360 did set an 8MiB limit. Since the actual hardware didn't
reach that size for another decade after its release, that was
reasonable.
Aren't you trying to create a S/380 hardware definition that includes
new features that S/370 didn't actually have?

That's not the issue !

The issue is :

ARCHLVL S/370
MAINSIZE 128M

will fail

MAINSIZE 128M
ARCHLVL S/370

Will succeed !

You could have a 3090 with 128M of memory and run it in S/370 mode...
(you could only use 64M though), but it worked...

--Ivan



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

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

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

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
That's not the issue !
ARCHLVL S/370
MAINSIZE 128M
will fail
MAINSIZE 128M
ARCHLVL S/370
Will succeed !
You could have a 3090 with 128M of memory and run it in S/370 mode...
(you could only use 64M though), but it worked...
--Ivan
[Non-text portions of this message have been removed]

Did you try to access real memory above 64MB on the
3090 in S/370-24bit mode?
Did it work or did IBM fix it or was the Principles of Operation changed?

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

Post by ***@yahoo.com [hercules-390]
- - - old note snipped - - -

Post by Ivan Warren ***@vmfacility.fr [hercules-390]
That's not the issue !
ARCHLVL S/370
MAINSIZE 128M
will fail
MAINSIZE 128M
ARCHLVL S/370
Will succeed !
You could have a 3090 with 128M of memory and run it in S/370 mode...
(you could only use 64M though), but it worked...
--Ivan
[Non-text portions of this message have been removed]

Did you try to access real memory above 64MB on the
3090 in S/370-24bit mode?
Did it work or did IBM fix it or was the Principles of Operation changed?

That's irrelevant.. It worked in the sense that you could have a
configuration with more than 64MB of main storage in S/370 mode (It
didn't *fail* in the sense that you could still Power ON/IML the beast -
even if you couldn't really make any use of the extra storage).

--Ivan



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

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

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Well, APL/360 did set an 8MiB limit. Since the actual hardware
didn't reach that size for another decade after its release,
that was reasonable.
Aren't you trying to create a S/380 hardware definition that
includes new features that S/370 didn't actually have?

That's not the issue !
ARCHLVL S/370
MAINSIZE 128M
will fail
MAINSIZE 128M
ARCHLVL S/370
Will succeed !
You could have a 3090 with 128M of memory and run it in S/370
mode... (you could only use 64M though), but it worked...

Agreed. The second should fail with the same error or at least throw a warning. But again, just as I instructed somitcw, please create a new github issue for this problem so I/we can discuss/track its progress there:


https://github.com/Fish-Git/hyperion/issues


Thanks!

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

Well, APL/360 did set an 8MiB limit. Since the actual hardware didn't
reach that size for another decade after its release, that was
reasonable.
Aren't you trying to create a S/380 hardware definition that includes
new features that S/370 didn't actually have?

- - - old notes snipped - - -

Not me. Other people are using OS/380 and their
modified Hercules 3.07 doesn't have the bug.
I've never used S/380 or tested it.

I'm just trying to fix Hercules configuration file
statement order and make ARCHLVL S370 come close
to matching the most current S/370-24bit Principles of
Operation.

If the ARCHLVL S370 PSW.32 worked like is says in the
S/370-31bit Principles of Operation, I might play with it.

With a couple of changes to follow IBM's lead, S/380 could
match IBM systems much better, but ARCHLVL S370 will
never allow the two S/370-31bit features needed.

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

somitcw wrote:

[...]

Post by ***@yahoo.com [hercules-390]
HHC00811I Processor CP00: architecture mode S/370
HHC02204I ARCHLVL set to S/370
HHC02204I LPARNUM set to BASIC
HHC01451E Invalid value 160 specified for MAINSIZE
error processing statement: MAINSIZE 160

https://github.com/hercules-390/hyperion/blob/master/hsccmd.c

[...]

Post by ***@yahoo.com [hercules-390]

( sysblk.arch_mode == ARCH_370 && /* 64M maximum for S/370 support */
The GIT version of spinhawk, hercules-3.13, doesn't show this glitch.

What's going on? Why?

Ask Mark Gaubatz (dasdman). He's the one that made that commit way back in 2012:


Revision: 72fda10bbd394648b2ae7525b4a6174dc938ef92
Author: dasdman <@>
Date: 9/4/2012 3:39:35 PM
Message: Update mainsize and xpndsize postfix handling;
allow main memory storage sizes on 4K boundaries
for values less than 16M.
----
Modified: bldcfg.c
Modified: config.c
Modified: hinlines.h
Modified: hsccmd.c
Modified: hscloc.c
Modified: html/hercconf.html

Post by ***@yahoo.com [hercules-390]
HHC01603I archlvl s370
HHC00811I Processor CP00: architecture mode S/370
HHC02204I ARCHLVL set to S/370
HHC02204I LPARNUM set to BASIC
HHC01603I mainsize 65
HHC01451E Invalid value 65 specified for mainsize
HHC01603I mainsize 64
HHC17003I MAIN storage is 64M (mainsize); storage is not locked
HHC01603I archlvl esame
HHC00811I Processor CP00: architecture mode z/Arch
HHC02204I ARCHLVL set to z/Arch
HHC02204I LPARNUM set to 1
HHC02204I CPUIDFMT set to 0
HHC01603I mainsize 65
HHC17003I MAIN storage is 65M (mainsize); storage is not locked
HHC01603I archlvl s370
HHC00811I Processor CP00: architecture mode S/370
HHC02204I ARCHLVL set to S/370
HHC02204I LPARNUM set to BASIC

Please create a new GitHub Issue for this bug:

https://github.com/Fish-Git/hyperion/issues


so I can track the problem from there. Mark's change on the face of it seems reasonable, but as Ivan wrote in a subsequent reply, there should at least be a warning when archlvl 3/370 is set to let you know the original mainsize has been changed from what you originally specified.

But again, I don't want to argue/discuss the issue here. Please create a github issue and we and anyone else can all discuss the issue there along with the merits (pros and cons) of whatever various proposed solutions we may come up with.

Thanks.

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

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

https://github.com/Fish-Git/hyperion/issues https://github.com/Fish-Git/hyperion/issues

- - - ending snipped - - -

Issue #94 has been opened:
https://github.com/Fish-Git/hyperion/issues/94