| Newsgroups |
gmane.comp.emulators.hercules390.mvs |
| Message-ID |
<[email protected]> |
Well, This was "set" using the Hercules X64 GUI. I put set in quotes
since, I *think*, that that was part of the sample CNF that came with
it. Not really sure where this CNF came from. I'm fairly new to
Hercules and assumed the sample LPARNUM 01 meant 1 "LPAR", i.e. "no" LPAR.
My CNF that is saved by the GUI looks like this...
#
# Hercules Emulator Control file...
#
# Description: R Schreiber System
# MaxShutdownSecs: 15
# LoadUnit: 0150
# RCFile:
# LogoFile:
# IgnoreParseErrors: 0
# HercGUI Version: 1.15.0.5224
#
# System parameters
*
ARCHLVL S/370*
MAXCPU 1
ENGINES CP
NUMCPU 1
AUTO_SCSI_MOUNT NO
CNSLPORT 3270
CONKPALV (3,1,10)
CODEPAGE default
CPUMODEL 0168
CPUSERIAL 123456
CPUVERID 00
DEVTMAX 8
DIAG8CMD DISABLE NOECHO
ECPSVM NO
HTTP PORT 80 NOAUTH
MODPATH .
LEGACYSENSEID DISABLE
*LPARNUM BASIC*
LPARNAME HERCULES
MAINSIZE 16
MANUFACTURER HRC
MODEL EMULATOR "" "" ""
MOUNTED_TAPE_REINIT DISALLOW
NETDEV 192.168.1.2
OSTAILOR OS/390
PANOPT FULLPATH
PANRATE 50
PGMPRDOS RESTRICTED
PLANT ZZ
SHCMDOPT DISABLE NODIAG8
SYSEPOCH 1900
TIMERINT 50
TRACEOPT TRADITIONAL
TZOFFSET -0500
XPNDSIZE 0
YROFFSET 0
Re: "Your downfall sounds like it was likely caused by your setting
LPARNUM after having set ARCHLVL S/370. Am I right? Since 'A' comes
before 'L' this is not entirely unexpected. "
Yes, they are in alphabetical order in the cnf. I *assume* that was done
by the gui when it saved it? Also, why did the gui let me set LPARNUM 01
when I had set S/370?
So, it seems that the code for ARCHLVL checks it, but the code for
LPARNUM does not argue about value of 01 when a prior ARCHLEVEL S/370
has been set. In this case, perhaps
LPARNUM should refuse to do what I did unless something like
LPARNUM 01 FORCES370
is specified?
I had an old, working, CNF for Hercules 3 that was much simpler...
ARCHMODE S/370
CPUSERIAL 134001
CPUMODEL 0168
MAINSIZE 16 # 16MB Main Storage
XPNDSIZE 0
CNSLPORT 3270 # Vista3270 connect to ip:3270
NUMCPU 2
SYSEPOCH 1900 # TOD clock=0 in Jan 0, 1900
PANRATE 250 # Update panel every 250 ms
Note that that old one did not specify LPARNUM at all, so it must have
defaulted to BASIC in that case.
Also there is a sample mvs.cnf for a 3.8 system that does not specify
LPARNUM either. Had I used that I would have been better off.
Clearly this is a user/learning curve error, but the effect was
"devastating" in that I had an MVS image that I could not IPL and it
took some pretty expert knowledge to figure out what was wrong. In the
surrounding, older comments, on this thread you can see that a lot of
guessing was going on and it was never resolved. Now we don't know if
the original problem was the same issue as here, but I just wanted to
document at least one thing that I found to cause it.
It seems to me that the gui is "just" a front-end for configuration and
running Hercules 4. Now, there's a value add from that, but it would
seem that better error checking would be appropriate. The design
question is whether or not Hercules should be doing it and/or the gui? I
don't have enough experience with H or the gui to have an intelligent
opinion yet.
I am also assuming that ARCHLVL S/370 means that H will not do anything
that not defined in that architecture. From what I think I've read here
is that STIDP did something that was not allowed in S/370? If so, then
that's a bug in mind.
Now I certainly can see the usefulness of allowing non-standard
behaviors and relaxing the "rules", but only with proper "overrides" in
the config file.
On 9/20/2019 5:34 PM, ''Fish' (David B. Trout)' [email protected]
[H390-MVS] wrote:
> Robert Schreiber wrote:
>
> [...]
>> Perhaps it might have been nice for Hercules to flag
>> the LPARNUM 01 since it's inconsistent with ARCHLVL
>> S/370?
> https://sdl-hercules-390.github.io/html/hercconf.html#ARCHLVL
> https://sdl-hercules-390.github.io/html/hercconf.html#LPARNUM
>
>
> https://sdl-hercules-390.github.io/html/hercrnot.html#4.1
>
>
> "Limited automatic LPARNUM updating when setting
> certain architecture modes"
>
> [...]
>
> "For the unusual case where users actually do want to run a
> System/370 Operating System within an LPAR, you will need
> to manually re-set your LPARNUM and CPUIDFMT values back to
> their numeric values after setting ARCHLVL S/370. That is
> to say, one should always follow their ARCHLVL S/370 statement
> with a LPARNUM n|nn statement (and CPUIDFMT statement too
> if needed) if LPAR mode for S/370 is truly desired."
>
>
> Your downfall sounds like it was likely caused by your setting LPARNUM after having set ARCHLVL S/370. Am I right? Since 'A' comes before 'L' this is not entirely unexpected.
>
> However, I would have thought the messages that are automatically issued when ARCHLVL is set to S/370 should have been enough of a clue:
>
> HHC01603I archlvl s/370
> HHC00811I Processor CP00: architecture mode S/370
> HHC02204I ARCHLVL set to S/370
> HHC02204I LPARNUM set to BASIC
>
>
> 'Tis wise to closely review one's Hercules logfile before submitting problem reports. ;-)
>