hercules-390 / hyperion

Hercules 390
Other
251 stars 70 forks source link

Incorrect CPU serial number stored by STIDP in S/370 mode #227

Closed PeterCoghlan closed 7 years ago

PeterCoghlan commented 7 years ago

The first byte of the CPU serial number stored by STIDP in S/370 mode is not correct as the following test program illustrates: archmode s/370 cpuserial 123456 r 100=b2020000 psw ia=100 t+ start r 0 This results in the following output: HHC01603I archmode s/370 HHC02204I archmode set to S/370 + HHC01603I cpuserial 123456 HHC02204I cpuserial set to 123456 HHC01603I r 100=b2020000 HHC02290I A:0000000000000000 K:06 HHC02290I R:00000100 B2020000 .... HHC01603I psw ia=100 HHC02278I Program status word: 0000000000000100 HHC02300I sm=00 pk=0 cmwp=0 as=pri cc=0 pm=0 am=24 ia=100 HHC01603I t+ HHC02229I Instruction tracing on HHC01603I start HHC00834I Processor CP00: running state selected HHC02324I PSW=0000000000000100 INST=B2020000 STIDP 0(0) store_cpu_id HHC02326I R:00000000:K:06=00000000 00000000 00000000 00000000 ................ HHC02269I GR00=00000000 GR01=00000000 GR02=00000000 GR03=00000000 HHC02269I GR04=00000000 GR05=00000000 GR06=00000000 GR07=00000000 HHC02269I GR08=00000000 GR09=00000000 GR10=00000000 GR11=00000000 HHC02269I GR12=00000000 GR13=00000000 GR14=00000000 GR15=00000000 HHC02271I CR00=000000E0 CR01=00000000 CR02=00000000 CR03=00000000 HHC02271I CR04=00000000 CR05=00000000 CR06=00000000 CR07=00000000 HHC02271I CR08=00000000 CR09=00000000 CR10=00000000 CR11=00000000 HHC02271I CR12=00000000 CR13=00000000 CR14=C2000000 CR15=00000000 [snip] HHC01603I r 0 HHC02290I A:0000000000000000 K:06 HHC02290I R:00000000 00013456 30900000 00000000 00000000 ..Ì.È........... HHC02290I R:00000010 00000000 00000000 00000000 00000000 ................ HHC02290I R:00000020 00000000 00000000 00000001 40000002 ............ ... HHC02290I R:00000030 00000000 00000000 00000000 00000000 ................

PeterCoghlan commented 7 years ago

Github ate my lineends :-( I'll give it one more try:

archmode s/370 cpuserial 123456 r 100=b2020000 psw ia=100 t+ start r 0

resulting in 00013456 30900000 being stored.

Fish-Git commented 7 years ago

Hi Peter!

PEBKAC.    ;-)

Please review the following information and then try again:

When you take the above information into account, the CPU ID is stored exactly as it should be (i.e. as expected):

00:19:40 HHC01413I Hercules version 4.0.0.8865-SDL-gbebcde2a (4.0.0.8865)
00:19:40 HHC01414I (C) Copyright 1999-2017 by Roger Bowler, Jan Jaeger, and others
00:19:40 HHC01417I ** The SoftDevLabs version of Hercules **
00:19:40 HHC01415I Build date: May 24 2017 at 11:16:13
00:19:40 HHC01417I Built with: Microsoft Visual C 150030729 1
00:19:40 HHC01417I Build type: Windows MSVC AMD64 host architecture build
00:19:40 HHC01417I Modes: S/370 ESA/390 z/Arch
00:19:40 HHC01417I Max CPU Engines: 64
00:19:40 HHC01417I Using   shared libraries
00:19:40 HHC01417I Using   Fish threads Threading Model
00:19:40 HHC01417I Using   Error-Checking Mutex Locking Model
00:19:40 HHC01417I With    Shared Devices support
00:19:40 HHC01417I With    Dynamic loading support
00:19:40 HHC01417I With    External GUI support
00:19:40 HHC01417I With    Partial TCP keepalive support
00:19:40 HHC01417I With    IPV6 support
00:19:40 HHC01417I With    HTTP Server support
00:19:40 HHC01417I With    sqrtl support
00:19:40 HHC01417I Without SIGABEND handler
00:19:40 HHC01417I With    CCKD BZIP2 support
00:19:40 HHC01417I With    HET BZIP2 support
00:19:40 HHC01417I With    ZLIB support
00:19:40 HHC01417I With    Regular Expressions support
00:19:40 HHC01417I With    Object REXX support
00:19:40 HHC01417I With    Regina REXX support
00:19:40 HHC01417I With    Automatic Operator support
00:19:40 HHC01417I Without National Language Support
00:19:40 HHC01417I Machine dependent assists: cmpxchg1 cmpxchg4 cmpxchg8 hatomics=msvcIntrinsics
00:19:40 HHC01417I Running on: WIN7 (Windows-6.1.7601 Intel(R) x64) LP=8, Cores=8, CPUs=2
00:19:40 HHC01417I Built with decNumber external package version 3.68.0.65-g16013c6
00:19:40 HHC01417I Built with SoftFloat external package version 3.1.0.66-g8e258f8
00:19:40 HHC01417I Built with telnet external package version 1.0.0.27-g4e7798e
00:19:40 HHC00018W Hercules is NOT running in elevated mode
00:19:40 HHC02323W This build of Hercules has only partial TCP keepalive support
00:19:40 HHC01508I HDL: loadable module directory is C:\Users\Fish\Documents\Visual Studio 2008\Projects\Hercules\_GIT\_Fish\_BitBucket\_prometheus-0
00:19:40 HHC00150I Crypto module loaded (c) Copyright 2003-2016 by Bernard van der Helm
00:19:40 HHC01417I Built with crypto external package version 1.0.0.12-gc3f9343
00:19:40 HHC00151I Activated facility: Message Security Assist
00:19:40 HHC00151I Activated facility: Message Security Assist Extension 1, 2, 3 and 4
00:19:40 HHC17531E REXX(Regina) dlopen 'regina.dll' failed: The specified module could not be found.
00:19:40 HHC17528I REXX(OORexx) VERSION: REXX-ooRexx_4.2.0(MT)_64-bit 6.04 22 Feb 2014
00:19:40 HHC17529I REXX(OORexx) SOURCE:  WindowsNT
00:19:40 HHC17525I REXX(OORexx) Rexx has been started/enabled
00:19:40 HHC17500I REXX(OORexx) Mode            : Subroutine
00:19:40 HHC17500I REXX(OORexx) MsgLevel        : Off
00:19:40 HHC17500I REXX(OORexx) MsgPrefix       : Off
00:19:40 HHC17500I REXX(OORexx) ErrPrefix       : Off
00:19:40 HHC17500I REXX(OORexx) Resolver        : On
00:19:40 HHC17500I REXX(OORexx) SysPath    (44) : On
00:19:40 HHC17500I REXX(OORexx) RexxPath   ( 0) :
00:19:40 HHC17500I REXX(OORexx) Extensions ( 8) : .REXX;.rexx;.REX;.rex;.CMD;.cmd;.RX;.rx
00:19:40 HHC00100I Thread id 000011e8, prio 15, name Processor CP00 started
00:19:40 HHC00100I Thread id 00003278, prio -20, name Timer started
00:19:40 HHC00811I Processor CP00: architecture mode z/Arch
00:19:40 HHC02204I CPUSERIAL      set to 002623
00:19:40 HHC02204I CPUMODEL       set to 3090
00:19:40 HHC02204I model          set to hardware(EMULATOR) capacity(EMULATOR) perm() temp()
00:19:41 HHC02204I PLANT          set to ZZ
00:19:41 HHC02204I manufacturer   set to HRC
00:19:41 HHC02204I LPARNAME       set to HERCULES
00:19:41 HHC02204I CPUVERID       set to FD
00:19:41 HHC17003I MAIN     storage is 64M (mainsize); storage is not locked
00:19:41 HHC17003I EXPANDED storage is 0 (xpndsize); storage is not locked
00:19:41 HHC02204I NUMCPU         set to 1
00:19:41 HHC02204I MAXCPU         set to 8
00:19:41 HHC02204I archmode       set to z/Arch
00:19:41 HHC00898I Facility(ASN_LX_REUSE) disabled for archmode ESA/390
00:19:41 HHC00898I Facility(ASN_LX_REUSE) disabled for archmode z/Arch
00:19:41 HHC02204I LOADPARM       set to 0120....
00:19:41 HHC02204I TZOFFSET       set to +0200
00:19:41 HHC01474I Using internal codepage conversion table default
00:19:41 HHC02204I DIAG8CMD       set to DISABLE  NOECHO
00:19:41 HHC02204I port           set to port=8081 noauth
00:19:41 HHC01807I HTTP server signaled to start
00:19:41 HHC02204I PANRATE        set to FAST
00:19:41 HHC17012I MSGLEVEL = verbose nodebug noemsgloc
00:19:41 HHC00100I Thread id 00002f30, prio  0, name HTTP server started
00:19:41 HHC01801E HTTP server: invalid root directory: 'C:\Users\Fish\Documents\Visual Studio 2008\Projects\Hercules\_GIT\_Fish\_BitBucket\_prometheus-0\msvc.amd64.bin\html': No such file or directory
00:19:41 HHC01803I HTTP server waiting for requests on port 8081
00:19:41 HHC00100I Thread id 000023d0, prio  0, name Console connection started
00:19:41 HHC01024I Waiting for console connections on port 3270
00:19:50 HHC01603I script c:\users\fish\downloads\fishtest.txt
00:19:50 HHC02260I Script 1: begin processing file c:/users/fish/downloads/fishtest.txt
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I archmode s/370
00:19:50 HHC00811I Processor CP00: architecture mode S/370
00:19:50 HHC02204I archmode       set to S/370
00:19:50 HHC01603I maxcpu 1
00:19:50 HHC02204I maxcpu         set to 1
00:19:50 HHC01603I numcpu 1
00:19:50 HHC02204I numcpu         set to 1
00:19:50 HHC01603I lparnum basic
00:19:50 HHC02204I lparnum        set to BASIC
00:19:50 HHC01603I cpumodel   3158
00:19:50 HHC02204I cpumodel       set to 3158
00:19:50 HHC01603I cpuserial  123456
00:19:50 HHC02204I cpuserial      set to 123456
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I maxcpu
00:19:50 HHC02203I maxcpu        : 1
00:19:50 HHC01603I numcpu
00:19:50 HHC02203I numcpu        : 1
00:19:50 HHC01603I lparnum
00:19:50 HHC02203I lparnum       : BASIC
00:19:50 HHC01603I cpuserial
00:19:50 HHC02203I cpuserial     : 123456
00:19:50 HHC01603I cpumodel
00:19:50 HHC02203I cpumodel      : 3158
00:19:50 HHC01603I *
00:19:50 HHC01603I cpuidfmt
00:19:50 HHC02203I cpuidfmt      : BASIC
00:19:50 HHC01603I cpuverid
00:19:50 HHC02203I cpuverid      : FD
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I r 100=b2020000
00:19:50 HHC02290I A:0000000000000000  K:06
00:19:50 HHC02290I R:00000100  B2020000                             ....
00:19:50 HHC01603I r 68=000200000000DEAD
00:19:50 HHC02290I A:0000000000000000  K:06
00:19:50 HHC02290I R:00000060                    00020000 0000DEAD          .......[
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I psw ia=100
00:19:50 HHC02278I Program status word: 0000000000000100
00:19:50 HHC02300I sm=00 pk=0 cmwp=0 as=pri cc=0 pm=0 am=24 ia=100
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I t+
00:19:50 HHC02229I Instruction tracing on 
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I start
00:19:50 HHC00834I Processor CP00: running state selected
00:19:50 HHC01603I *
00:19:50 HHC02324I PSW=0000000000000100 INST=B2020000     STIDP 0(0)                   store_cpu_id
00:19:50 HHC02326I R:00000000:K:06=00000000 00000000 00000000 00000000  ................
00:19:50 HHC02269I GR00=00000000 GR01=00000000 GR02=00000000 GR03=00000000
00:19:50 HHC02269I GR04=00000000 GR05=00000000 GR06=00000000 GR07=00000000
00:19:50 HHC02269I GR08=00000000 GR09=00000000 GR10=00000000 GR11=00000000
00:19:50 HHC02269I GR12=00000000 GR13=00000000 GR14=00000000 GR15=00000000
00:19:50 HHC02271I CR00=000000E0 CR01=00000000 CR02=00000000 CR03=00000000
00:19:50 HHC02271I CR04=00000000 CR05=00000000 CR06=00000000 CR07=00000000
00:19:50 HHC02271I CR08=00000000 CR09=00000000 CR10=00000000 CR11=00000000
00:19:50 HHC02271I CR12=00000000 CR13=00000000 CR14=C2000000 CR15=00000000
00:19:50 HHC02324I PSW=0000000080000104 INST=0000         ????? ,                      ?
00:19:50 HHC02269I GR00=00000000 GR01=00000000 GR02=00000000 GR03=00000000
00:19:50 HHC02269I GR04=00000000 GR05=00000000 GR06=00000000 GR07=00000000
00:19:50 HHC02269I GR08=00000000 GR09=00000000 GR10=00000000 GR11=00000000
00:19:50 HHC02269I GR12=00000000 GR13=00000000 GR14=00000000 GR15=00000000
00:19:50 HHC01603I *
00:19:50 HHC00801I Processor CP00: Operation exception code 0001  ilc 2
00:19:50 HHC01603I *
00:19:50 HHC02324I PSW=0000000140000106 INST=0000         ????? ,                      ?
00:19:50 HHC02269I GR00=00000000 GR01=00000000 GR02=00000000 GR03=00000000
00:19:50 HHC02269I GR04=00000000 GR05=00000000 GR06=00000000 GR07=00000000
00:19:50 HHC02269I GR08=00000000 GR09=00000000 GR10=00000000 GR11=00000000
00:19:50 HHC02269I GR12=00000000 GR13=00000000 GR14=00000000 GR15=00000000
00:19:50 HHC02262I Script 1: processing paused for 200 milliseconds...
00:19:50 HHC00800I Processor CP00: loaded wait state PSW 00020000 4000DEAD
00:19:50 HHC00809I Processor CP00: disabled wait state 00020000 4000DEAD
00:19:50 HHC02263I Script 1: processing resumed...
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I maxcpu
00:19:50 HHC02203I maxcpu        : 1
00:19:50 HHC01603I numcpu
00:19:50 HHC02203I numcpu        : 1
00:19:50 HHC01603I lparnum
00:19:50 HHC02203I lparnum       : BASIC
00:19:50 HHC01603I cpuserial
00:19:50 HHC02203I cpuserial     : 123456
00:19:50 HHC01603I cpumodel
00:19:50 HHC02203I cpumodel      : 3158
00:19:50 HHC01603I cpuidfmt
00:19:50 HHC02203I cpuidfmt      : BASIC
00:19:50 HHC01603I cpuverid
00:19:50 HHC02203I cpuverid      : FD
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I r 0.8
00:19:50 HHC02290I A:0000000000000000  K:06
00:19:50 HHC02290I R:00000000  FD123456 31580000                    ........
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC01603I *
00:19:50 HHC02264I Script 1: file c:/users/fish/downloads/fishtest.txt processing ended
00:19:54 HHC01603I exit
00:19:54 HHC01420I Begin Hercules shutdown
00:19:54 HHC01423I Calling termination routines
00:19:54 HHC00101I Thread id 00003278, prio -20, name Timer ended
00:19:54 HHC00101I Thread id 00002f30, prio  0, name HTTP server ended
00:19:54 HHC00101I Thread id 000011e8, prio 15, name Processor CP00 ended
00:19:54 HHC00101I Thread id 000023d0, prio  0, name Console connection ended
00:19:54 HHC01427I Main storage released
00:19:54 HHC01427I Expanded storage released
00:19:54 HHC01422I Configuration released
00:19:55 HHC02103I Logger: logger thread terminating

Hope that helps!

PeterCoghlan commented 7 years ago

Looks like I can have what I asked for but not what I wanted :-)

When configuring Hercules as an S/370 system, it seems counterintuitive to have to dial down LPARNUM. Shouldn't Hercules assume a very basic S/370 configuration and allow it to be dialed up by configuring features which were added later in the S/370 lifetime?

As far as I know, the sample configuration files supplied with various VM/370 distributions include CPUSERIAL specifications but do not specify LPARNUM. Hyperion ends up defaulting LPARNUM to 1 and this ends up mangling the serial number as displayed by CPWATCH and by CP QUERY CPUID for example.

Fish-Git commented 7 years ago

You make a good point, Peter. Setting ARCHLVL S/370 should set LPARNUM to BASIC.

I shall make the change.(*)

@dasdman ? Would you agree?

Followup question: When were LPARs introduced? (I.e. Was there ever such a thing as a S/370 machine with LPARs? Where most ESA/390 machines LPAR machines? Should the same change be made for archlvl esa/390?)


(*) To my SDL fish-git/hyperion. (As I'm no longer a Hercules developer I no longer have commit access to hercules-390/hyperion so someone else is going to have to make the fix there.)

jphartmann commented 7 years ago

XA introduced the SIE instruction, which is the basis for VM/XA and LPAR.

No S/370 machine implemented LPAR.

dasdman commented 7 years ago

On 05/25/2017 06:00 PM, Fish-Git wrote:

You make a good point, Peter. Setting |ARCHLVL S/370| should set |LPARNUM| to |BASIC|.

I shall make the change.(*)

@dasdman https://github.com/dasdman ? Would you agree?

Strongly disagree. Please reread points in prior post. If one is specifically working with an OS that is not using a hot dispatcher, then and only then should LPARNUM be set to BASIC. Please note that there are distributed mods to earlier operating systems that also cause the use of a hot dispatcher with the CPUs never entering a wait state while operating.

On "real hardware," a hot dispatcher uses what are otherwise unused cycles on the machine and always runs the real machine at 100% real CPU. Not a problem as the cycles, power, and heat were otherwise just going to waste. But unless one is running Xeon processors on systems that consume that same amount of power regardless of CPU load, it makes no sense, unless the OS is highly sensitive to both the STIDP format and contents (which is usually not the case), OR one is running an OS on Hercules at an average CPU utilization of 100-104% by scheduler percentages. At this level, the hot dispatcher is very helpful in that it gains about 3-6% in additional CPU cycles.

Sidebar: I had forgotten about this until I was suddenly running at 100% CPU with no load. It took a while to re-register the fact; Hercules stated 100% CPU while the OS displays stated an "idle" load of less than 3%.

Followup question: When were LPARs introduced?

From IBM, and not as an RPQ or special feature, 1988, with the release of ESA hardware. From others, latter half of the 1970s.

(I.e. Was there ever such a thing as a S/370 machine with LPARs?

Yes, but not directly from Blue (Wikipedia entry for LPAR leaves a lot to be desired, but personal memory and experience are neither acceptable nor proper for corrections or input).

Where most ESA/390 machines LPAR machines?

All machines supporting ESA/390 were PR/SM/LPAR/MDF based machines; some could be switched to BASIC mode. I don't recall directly regarding the Hitachi machines as to whether or not they had LPARs, or, if so, when introduced.

Should the same change be made for archlvl esa/390?)

Absolutely not.

SIE (Start Interpretive Execution, aka 370/XA mode switching), started with the 3081 (per Lynn Wheeler http://www.garlic.com/~lynn/2012f.html#39 http://www.garlic.com/%7Elynn/2012f.html#39, previously an internal use only XA development tool), and formally came in with ESA capable hardware and the formal definition and introduction of PR/SM and MDF. Amdahl's predecessor product was also available in the latter half of the 1970's (of which I also crashed along with the Amdahl corporate data center while working on a new Amdahl product in alpha test in the production data center in late August of 1983 -- result was that the properly running error recovery code triggered a hypervisor partitioning error that then activated a real system reset and clear, leaving nothing of the multiple VM and MVS corporate data center operating systems to debug at any level).

dasdman

jphartmann commented 7 years ago

Oh, and let us not forget. Until the advent of ESA or was it 390, you could create an LPAR that ran S/370 mode on XA hardware with PR/SM. Lots of things in such a beast might be slightly unexpected, e.g., the rightmost bits of the TOD clock stored.

That should not effect the definition of a plain old S/370 system.

Fish-Git commented 7 years ago

dasdman wrote:

Fish-Git wrote:

I shall make the change.(*)

@dasdman https://github.com/dasdman ? Would you agree?

Strongly disagree. [...]

Which is (was) more common? Running a S/370 O/S on basic hardware (no lpars) or running it on a machine with lpars?

I personally would think the former would be (was) much more common than the latter. I mean, I certainly hear what you are saying, but I'm simply trying to eliminate "unexpected behavior" here.

Maybe we can condition the automatic setting of lparnum basic upon setting archmode S/370 on the current cpumodel setting? If the user's specified cpumodel was one known to not support lpars, then auto-switch lparnum to basic. Otherwise don't. Would that work?

I mean, I think we should do something!

PeterCoghlan commented 7 years ago

I have found that there may also be difficulties with the sequence of commands required to achieve an unmangled cpuid. If "maxcpu" is reduced from the default value to 1 after setting "cpuserial" and "lparnum" then the serial number remains mangled:

HHC01603I archmode
HHC02203I archmode      : z/Arch
HHC01603I archmode s/370
HHC00811I Processor CP00: architecture mode S/370
HHC02204I archmode       set to S/370
HHC01603I cpuserial
HHC02203I cpuserial     : 000001
HHC01603I cpuserial 123456
HHC02204I cpuserial      set to 123456
HHC01603I lparnum
HHC02203I lparnum       : 1
HHC01603I lparnum basic
HHC02204I lparnum        set to BASIC
HHC01603I maxcpu
HHC02203I maxcpu        : 4
HHC01603I maxcpu 1
HHC02204I maxcpu         set to 1
HHC01603I numcpu
HHC02203I numcpu        : 1
HHC01603I r 100=b2020000
HHC02290I A:0000000000000000  K:06
HHC02290I R:00000100  B2020000                             ....
HHC01603I psw ia=100
HHC02278I Program status word: 0000000000000100
HHC02300I sm=00 pk=0 cmwp=0 as=pri cc=0 pm=0 am=24 ia=100
HHC01603I start
HHC00834I Processor CP00: running state selected
[snip]
HHC01603I r 0
HHC02290I A:0000000000000000  K:06
HHC02290I R:00000000  FD023456 05860000 00000000 00000000  ù.Ì..f..........

My suspicion is that the "maxcpu" command is not causing the serial number returned by STIDP to be updated and it is only updated to reflect the current value of "maxcpu" when a "cpuserial", "cpumodel" or "lparnum" command is executed.

(Did serial numbers of CPUs in AP and MP machines always differ by just the first digit and was this always 0 or 1 for two processor machines?)

dasdman commented 7 years ago

On 05/29/2017 04:45 AM, PeterCoghlan wrote:

(Did serial numbers of CPUs in AP and MP machines always differ by just the first digit and was this always 0 or 1 for two processor machines?) It varied, depending on the frames and manufacturer. No true "set" rule. In reality, the current process is just as valid as any of the manufacturers. This is one of those cases where it is actually best to read the principles of operations as a guide. IBM did not mandate HOW serial numbers were done between manufacturers, which leaves it to the manufacturers on how to use the field.

The best analogy of the cpuserial setting is that of what used to be the frame serial number embossed into each physical frame. The manufactured source of the serial number would have the last n hexadecimal digits between the STIDP result and the physical frame then match in some fashion. For some manufacturers, it was the first digit that was used; for others, some other matching sequence.

In one series I worked on, there actually was an encased device on each frame that was read, and the system would red-light and throw errors if there was a mismatch between the CPUs and attached frames.

dasdman commented 7 years ago

On 05/29/2017 04:45 AM, PeterCoghlan wrote:

I have found that there may also be difficulties with the sequence of commands required to achieve an unmangled cpuid. If "maxcpu" is reduced from the default value to 1 after setting "cpuserial" and "lparnum" then the serial number remains mangled:

Peter, et al:

I reviewed the existing code (which I wrote) over the weekend. Working on the fix which is actually an error in MAXCPU handling. With the new fix, the CPU(s) must be stopped if the change would cause an effective change to CPUIDFMT when not in LPAR mode. This can happen when changing MAXCPU from 1 or to 1. This permits "the will" of certain and various Hercules users to continue (that is, be able to change MAXCPUs on the fly [grumble, grumble -- the original version I wrote intentionally forced a system reset since operating systems can't handle a changing CPUID]). Testing is now underway...

dasdman commented 7 years ago

Fixed, along with documentation updates.