| Newsgroups |
gmane.comp.emulators.hercules390.mvs |
| Message-ID |
<[email protected]> |
Fish,
It also appears that ES/9000 CPU's allowed multiple S/370 LPARs but how they presented this to the OS I don't know.
https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP9000.html
was the LPAR number hidden from the OS....
.... do S/370 OS's know about LPARs and how should Hercules behave when one is defined.
Perhaps Hercules is behaving badly...
Dave
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: 21 September 2019 13:37
> To: [email protected]
> Subject: RE: [H390-MVS] Re: Wait State 00050064
>
> Robert Schreiber wrote:
>
> > Well, This was "set" using the Hercules X64 GUI.
>
> [...]
> > Yes, they are in alphabetical order in the cnf. I *assume* that was
> > done by the gui when it saved it?
>
> Yes.
>
>
> > Also, why did the gui let me set LPARNUM 01 when I had set S/370?
>
> Because Hercules allows it.
>
>
> > 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 ARCHLVL S/370
> > has been set.
>
> Correct.
>
>
> > In this case, perhaps LPARNUM should refuse to do what I did unless
> > something like LPARNUM 01 FORCES370 is specified?
>
> That's actually not a bad idea.
>
> Given that specifying an LPARNUM *other* than the expected BASIC (for 370)
> is "unusual" (valid but very out of the ordinary), requiring an extra argument to
> confirm that yes, this is indeed what you meant to do, is actually a good idea. It
> still allows e.g. LPARNUM 01 to be specified even for archlvl 370, but also
> catches/prevents accidental mistakes such as yours (leading to much confusion
> and wasted time, which is not good).
>
> Let me see what I can do...
>
>
> [...]
> > 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.
>
> My apologies. Let me see what can be done to try and prevent something like
> that from happening in the future.
>
>
> > 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.
>
> And we appreciate you taking the time to do so. We all learn from each other
> that way.
>
>
> > It seems to me that the gui is "just" a front-end for configuration
> > and running Hercules 4.
>
> Correct.
>
>
> > Now, there's a value add from that, but it would seem that better
> > error checking would be appropriate.
>
> I've tried hard to code HercGUI to catch user errors before they reach
> Hercules, but this was one that slipped by (because, as explained, it's VALID to
> Hercules). I'll try to add code to HercGUI to popup with a
> warning/confirmation dialog in such a situation too (in addition Hercules's
> modified handling of the situation as per your suggestion). Those two changes
> together should I hope prevent this from ever happening again.
>
>
> > The design question is whether or not Hercules should be doing it
> > and/or the gui?
>
> Definitely both. Not everyone uses the GUI. Some people prefer running
> Hercules directly from the Command Prompt (although why I'll never know).
>
>
> [...]
> > 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.
>
> Not necessarily (or so I'm told).
>
> While I personally don't have any experience with such machines (my
> background is DOS/VSE and VM/SP 5 on 370/158, IBM 4381, etc), I am told
> some systems allowed running System/370 mode within an LPAR. Hence the
> reason for Hercules supporting it (the code for which I did not personally write).
>
>
> > 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.
>
> Agreed. As I said, your "FORCES370" suggestion is a good one. Let me see
> what I can do about implementing it for you.
>
> Thank you for your feedback, Robert. It is very much appreciated.
>
> Take care.
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: [email protected]
>
>
>
>
>
>
> ------------------------------------
> Posted by: "\"Fish\" \(David B. Trout\)" <[email protected]>
> ------------------------------------
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>