-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disallow LPARNUM nn for ARCHLVL S/370 without FORCE option #256
Comments
Then you break something. System configuration statements should, and always have been, independent of the architecture level. However, in S/370 mode, STIDP should always return a format 0 CPUID (that is, it should return the length of the MCEL whether the LPAR is greater than 16 or not) |
Then how do you propose to eliminate the described "Surprise!" factor, as well as the other obvious surprise factor that would occur when the user queries the current LPARNUM/CPUIDFMT setting? That is to say, if the ARCHLVL is set to S/370 but the LPARNUM remains 01 and the CPUIDFMT remains 1, but yet, the STIDP instruction ignores both settings and stores a BASIC mode CPUID instead (completely ignoring the current LPARNUM/CPUIDFMT setting), wouldn't that too lead to a "Surprise!" situation? More than that, how would someone who purposely wanted to run S/370 in "LPAR mode" accomplish that? That is to say, if a user purposely wanted the STIDP instruction to store a LPAR-mode CPUID (i.e. a non- BASIC mode CPUID), how would they request/accomplish that?
I would tend to agree! Mark however (who wrote our LPARNUM/CPUIDFMT logic), might not. Furthermore, such a change, as explained above, would make it impossible for a user to request the STIDP instruction to store a non-BASIC mode CPUID. Your proposed change would break things too! So what's the answer? What's the compromise here? How can we achieve both of our goals? What do you suggest? |
NOTE! Below edited by Fish! I hope I got it right! At run time (past IMPL/POR), we are either in S/370 architecture mode, or in XA or better: 370 only supports Format-0 CPUID format. (STIDP should NEVER return a Format-1 CPUID!) CPUIDFMT 0 is specified, or there is no CPUIDFMT statement: STIDP returns a Format-0 CPUID, and ignores the LPARNUM. CPUIDFMT 1 is specified: Issue warning at IMPL/POR, do as if CPUIDFMT was set to 0. CPUIDFMT 1 FORCE: Issue a warning at IMPL/POR, STIDP returns a Format-1 CPUID. (You're on your own on this one!) XA or better (S/370 XA, ESA, S/390, z/Arch): No CPUIDFMT: If LPARNUM is less than 16, STIDP returns a Format-0 CPUID. If LPARNUM is greater than 16, a Format-1 CPUID is returned. CPUIDFMT 0 is specified: STIDP returns a Format-0 CPUID regardless of the LPARNUM specified. CPUIDFMT 1 is specified: STIDP returns a Format-1 CPUID regardless of the LPARNUM specified. If LPARNUM wasn't specified, set it to 0. |
Hmmm... So you're proposing a |
For 370:
I would add that not only should we issuing a warning for the CPUIDFMT statement (letting them know we're ignoring it), but also one for any LPARNUM statement they might also provide (letting them know the same thing: we're ignoring it). |
Where in Hercules code should the above checks be made? In each of the I'm thinking maybe we should code a new Does that sound reasonable? Or do you have a different/better idea on how to implement this suggested change? Thanks! (anyone else is also free to jump in with their own ideas or opinions on this matter too!) |
In almost all cases, when a user sets
ARCHLVL S/370
they expect theSTIDP
(Store CPU ID) instruction to store the CPU ID in Basic Mode format (i.e. they expectLPARNUM
andCPUIDFMT
to be set toBASIC
such that theSTIDP
instruction then stores the CPU ID in the expected format).This was the reason for the "Limited automatic LPARNUM updating when setting certain architecture modes" change made to v4.1
However, as explained in the above mentioned v4.1 Release Notes:
This leads to unexpected behavior (introduces a "Surprise!" factor that the "Limited automatic LPARNUM updating when setting certain architecture modes" change was attempting to eliminate (or at least reduce the likelihood of occurring)) when a given configuration file happens to contain a "stray" (accidental)
LPARNUM 01
statement (that they forgot to remove) several statements after theirARCHLVL S/370
statement.Such an unintentional (but quite easy to make) user configuration error can cause much confusion and wasted time and effort trying to discover why their basic-mode (non-LPAR-aware) 370 guest O/S is failing to IPL or otherwise behave correctly.
As explained, the cause of this unexpected behavior is Hercules's need to support LPAR-370 mode, thereby causing Hercules to accept without complaint or warning their unintended
LPARNUM 01
statement that happens to follow theirARCHLVL 370
statement.It is requested that a new
FORCE
option be introduced to theLPARNUM
statement handling that would cause a numeric LPARNUM statement to be rejected if submitted without the new FORCE option for ARCHLVL 370. That is to say, the new FORCE option would only be required when the ARCHLVL is 370 and 370 LPAR mode was truly wanted. If the ARCHLVL is 390 or z/Arch, then a numeric LPARNUM statement would be accepted as-is without the FORCE option, just like today, so the requested change would only impact those rare individuals who actually do want to run in 370 LPAR mode. For the vast majority of the 370 crowd the change would neatly eliminate the unintended/disastrous "Surprise!" factor that could otherwise very easily occur.The text was updated successfully, but these errors were encountered: