| Newsgroups |
gmane.comp.emulators.hercules390.mvs |
| Message-ID |
<[email protected]> |
S/370 has no idea what an LPAR is. Thus, the fact that its running in
one should be shielded so that it cannot be confused. @Tony_Harminc
correctly pointed out that the image expects the machine to look/act
like GA22-7000-10. The problem that I caused myself was because STIDP
did not adhere to the S/370 spec with the configuration that I (wrongly)
created.
bob
On 9/21/2019 9:35 AM, 'Dave Wade' [email protected] [H390-MVS] wrote:
> 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
>>
>>
>>
>