IPL with Wait state 07C reason code 0A in z/OS 2.4 Hercules 4.7

[itailleur]

Hello, Today, I've just installed Hercules 4.7 from git an when I IPLed z/OS 2.4 on it, it stopped with a wait state 07C reason code 0A

z/OS 2.2 works fine

Before I installed Hercules 4.7, I was on level 4.4 and the same z/OS 2.4 system worked fine

The IBM documentation says about this wait state:

0A The system was IPLed from an unsupported virtual machine environment. System action: The system enters a nonrestartable wait state.

Operator response: Notify the system programmer.

System programmer response: IPL the system from a supported virtual machine. Search problem reporting databases for a fix for the problem. If not fix exists, contact the IBM Support Center.

Regards. itailleur

[Fish-Git]

Please review:

• "SUBMITTING PROBLEM REPORTS"

and attach the required files. Specifically, we need to see your Hercules configuration and log files.

[itailleur]

Hello, The Hercules version is: Hercules version 4.7.0.11119-SDL-gf7d2360a The home OS is Opensuse 15.2 The guest OS is z/OS 2.4 PUT2401 applied (ie compat z/OS 3.1 included) The problem is repeatable conf and log files below:

• herczos24-1.conf.txt
• herczos24.log.txt

[Fish-Git]

The guest OS is z/OS 2.4 PUT2401 applied (ie compat z/OS 3.1 included)

I am not a z/OS expert, but I suspect your problem is that, because of the z/OS 3.1 compatibility that you added to it, might now be expecting certain required z/Architecture features to be present.

Try adding the following facility statements to your configuration file:

FACILITY  ENABLE     054   # 054_EE_CMPSC             Entropy-Encoding-Compression Facility
FACILITY  ENABLE     129   # 129_ZVECTOR              Vector Facility for z/Architecture
FACILITY  ENABLE     130   # 130_INSTR_EXEC_PROT      Instruction-Execution-Protection Facility
FACILITY  ENABLE     134   # 134_ZVECTOR_PACK_DEC     Vector Packed-Decimal Facility
FACILITY  ENABLE     135   # 135_ZVECTOR_ENH_1        Vector-Enhancements Facility 1
FACILITY  ENABLE     148   # 148_VECTOR_ENH_2         Vector-Enhancements Facility 2
FACILITY  ENABLE     152   # 152_VECT_PACKDEC_ENH     Vector-Packed-Decimal-Enhancement Facility
FACILITY  ENABLE     192   # 192_VECT_PACKDEC_ENH_2   Vector-Packed-Decimal-Enhancement Facility 2

Also, you configuration file is not a plain ASCII text file. Thus you are getting the error:

11:22:25 HHC01441E Config file[1] herczos24-1.conf: error processing statement: CPUSERIAL 0004F0
11:22:25 HHC00007I Previous message from function 'process_config' at script.c(431)

Your file begins with the a X'EFBBBF` byte order mark, which Hercules does not understand. You need to convert it to a plain ASCII file.

Please let us know whether the suggested facility statements resolves your issue or not.

[itailleur]

Thank you for your answer. I converted yhe conf file to ascii and it's better I added all the facility statements you gave me but the result is the same wait state 07C reason code 0A Maybe it's related to the toleration PTF of the new validated boot functionnality (z16 and z/OS 2.5 and above), but I'm suprised it works with hercules 4.4 z_OS Validated Boot White Paper.pdf

[itailleur]

After searching a bit more, I think the problem is related to this APAR https://www.ibm.com/support/pages/apar/OA62744

[Fish-Git]

I know nothing about APARs. As I said, I am not a z/OS person. I am only a Hercules developer. A Hercules developer who is familiar with z/Architecture. If the problem is not related to z/Architecture (i.e. if the problem is related to z/OS itself), then I do not feel obligated to try and resolve it.

Given that z/OS 3.1 (as well as z/OS 2.5 too) require the z/Architecture Vector Facility (facility number 129 and other associated facilities as well) in order to IPL and run successfully -- (which is not supported in Hercules 4.7 Hyperion, but which is under active development for eventual support in version 4.8) -- I am going to close this GitHub Issue as Unknown/Unresolved.

Hopefully we will have a 4.8 development version of Hercules soon, that you will be able to test with. But for now, there is nothing more we can do. Sorry!

[itailleur]

Ok, I understand your point of view. For my part, I do not know Hercules, however it is clear that z/OS 2.4 with OA62744 applied works on Hercules 4.4 development version and this same z/OS system does not work on any higher version of Hercules.

[Fish-Git]

FWIW, I have z/OS 2.4 too, and it works just fine for me with Hercules 4.5, 4.6 and 4.7. But I probably don't have OA62744 applied either.

Have you tried the 'develop' branch of Hercules yet?

[itailleur]

It doesn't work better with the latest development version 4.8.

Can you tell me if in your z/OS 2.4 you have the APAR OA62744 applied? To do this, do a “find OA62744” in SYS1.MACLIB(CVT).

[Fish-Git]

Can you tell me if in your z/OS 2.4 you have the APAR OA62744 applied? To do this, do a “find OA62744” in SYS1.MACLIB(CVT).

Not found.

[itailleur]

OK, thanks a lot.

This tends to support the hypothesis that if APAR OA62744 is applied then z/OS 2.4 nor z/OS 2.5 will not work under Hercules.

There will be the same problem with z/OS 3.1.

What I understand is that with this evolution, there is new information that STSI provides (and therefore there should be new settings in Hercules for this) and that z/OS controls.

On the other hand, I don't understand why this works with Hercules 4.4 development version and not on higher versions.

[Fish-Git]

There will be the same problem with z/OS 3.1.

Well ... Believe it or not, z/OS 3.1 IPLs and runs just fine with the 4.8 development version of Hercules. It fails to IPL with the official 4.7 release version of course (disabled wait 07B code 23), but it IPLs and runs just fine with the 4.8 'develop' branch.

What I understand is that with this evolution, there is new information that STSI provides (and therefore there should be new settings in Hercules for this) and that z/OS controls.

After reviewing APAR OA62744 (most of which I did not understand), that would seem to be true. Unfortunately however, there is no public information that I could find that describes the new changes to the STSI instruction.

On the other hand, I don't understand why this works with Hercules 4.4 development version and not on higher versions.

Me neither! When I try IPLing z/OS 3.1 with Hercules version 4.4 or 4.4.1, it fails with disabled wait 07B reason 22. Why it works for you is a mystery!

[itailleur]

Thank you for your answer It's a great news that z/OS3.1 works fine I would have bet the opposite This is becoming more and more mysterious My only consolation is that I am not the only one having this problem as it is described inside #459 issue

[Fish-Git]

Maybe it's your other statements?

I'm using:

LPARNAME       HERCULES
LPARNUM        01
CPUMODEL       $(z14ZR1)     # i.e. 3907
CPUVERID       00
MODEL          EMULATOR "" "" ""
MANUFACTURER   HRC
PLANT          ZZ

whereas you're using:

LPARNAME       LP01
LPARNUM        01
CPUMODEL       3906          # i.e. ($Z14)
##CPUVERID     FD            # (IMPLIED because not specified!)
MODEL          H43
MANUFACTURER   IBM
PLANT          84

Try changing your CPUMODEL to 3907 and adding a CPUVERID statement set to 00. (Maybe it's the implied CPUVERID FD that is implying virtual machine, which is what is causing your 07C 0A?)

Also be sure to always specify ALL of the facilities I mentioned earlier too.

I don't know what else to say. z/OS 3.1 runs fine under the 4.8 development version of Hercules. I have no idea why your z/OS 2.x with that APAR does not work.

Patient: "Doctor! Doctor! It hurts when I do this!" Doctor: "Then don't do that!"

[Fish-Git]

More Information:

• https://sdl-hercules-390.github.io/html/hercconf.html#CPUVERID

The default cpuverid version code at startup is FD, and that value will be stored by the STIDP instruction -- even for z/Arch -- unless and UNTIL you set it to a different value via the cpuverid command/statement.

[...]

(But as explained, at startup, the value stored will still be FD even for z/Arch, since that is Hercules's default version code value. This means if you want your STIDP version code to be 00 for z/Arch, then you must use a cpuverid command/statement in your configuration file to set it to that value.)

[itailleur]

I updated my conf file with just CPUVERID 00 (and all the new facilities you mentioned). I used 4.8 Hercules Dev and it WORKS! I only have one word to say: CONGRATULATIONS!

Thank you so much!

PS: Did you try CPUVERID FD with z/OS 3.1/Hercules 4.8 dev?

[Fish-Git]

I updated my conf file with just CPUVERID 00 (and all the new facilities you mentioned). I used 4.8 Hercules Dev and it WORKS!

FANTASTIC!   I am very happy that we have figured out your problem!  :-D

I only have one word to say: CONGRATULATIONS!

Thank you.  :)

Thank you so much!

You are very welcome, itailleur.   (I don't know your real name)   I am glad I could help.

PS: Did you try CPUVERID FD with z/OS 3.1/Hercules 4.8 dev?

No. Why would I? CPUVERID FD makes no sense. Only CPUVERID 00 makes sense. That's what I always use.

[itailleur]

Hello,

I reviewed the latest POP version. FD has meaning now (level 3) in z/ARCH, this was not the case before.

Thanks again.

By the way, my first name is Isabelle.

[Fish-Git]

By the way, my first name is Isabelle.

Pleased to meet you, Isabelle.  :)

My real name is David Trout, but I've been professionally known by all of my friends, acquaintances and coworkers as Fish for the past 50+ years.

[itailleur]

Hello,

Sorry to disturb you again but I have another wait state (05D) in Hercules 4.7 and 4.8 dev (It works fine on 4.6, 4.5, 4.4) Is it a bug or a bad conf file ? it will probably be obvious to you

This a more complex configuration because it is a base SYSPLEX with 2 systems. They communicate with CTCE

The problem is on the System 2 It access and share disks with Shared Device server

I join you the conf and log files System 1 herczos24-1ctce2.conf.txt herczos241.log

System 2 herczos24-2ctce2.conf.txt herczos242.log

[Fish-Git]

This is a completely different problem than the one your originally reported. Please create a separate new GitHub Issue for this new problem.