RE: IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNP10 INITIALIZATION

Rick Spencer wrote:

> I should have added the log and config files.  Unfortunately,
> I can't seem to figure out how to attach the files,

The hercules-390 Yahoo list is unfortunately configured to not allow attachments.


> so I have to copy and paste them in this conversation.

That's fine.

Just as an FYI, in case at some point in the future you need to include a large file with your problem report, you can upload it to the group's Files area: just click on the Files folder icon near the top of the screen just beneath the group's banner image, which will take you to:

  https://groups.yahoo.com/neo/groups/hercules-390/files

where you can then upload your file. Then just mention that file in your posting.  For configuration files and smallish log files however, just pasting them inline like you did is fine.


[...]
> HERCPRIO             0
> TODPRIO              -20
> DEVPRIO              8
> CPUPRIO              0

FYI: Starting with SDL Hyperion 4.1, priority statements are no longer supported and are ignored.  You should remove these.  (Besides, the values you're using are the defaults anyway, so you don't need them.)


[...]
> ECPSVM               YES TRAP

I highly question this statement!  z/OS is *not* VM/370!  I tried it with my own z/OS 1.10 system and fortunately it doesn't seem to make a difference..  Nevertheless, it doesn't belong and I would suggest removing it.


> HTTPPORT             80 NOAUTH

FYI: The HTTPPORT and HTTPROOT statements have been deprecated.  You should replace them with HTTP statements instead ("HTTP ROOT xxx..." and "HTTP PORT xxx...").  But again, this is not your problem.


> ARCHLVL   ENABLE BIT44
> ARCHLVL ENABLE 006_ASN_LX_REUSE

FYI: These should be replaced with "FACILITY" statements instead.  (But again, this isn't you problem.)  (And besides that, you don't need either one!  Starting with SDL Hyperion 4.1, ASN_LX_REUSE facility 6 is enabled by default for z/Arch and z/OS 1.10 doesn't need the PFPO facility.)


[...]
> 201D    3390    E:/zos1pk/zos1pk.3000
> 201E    3390    E:/zos1pk/zoswk1.3001

Are these two volumes important?  I suspect they might be since, according to your log file further below, they're missing.

I also don't see a LOADPARM statement anywhere.  I see in your log file further below, that you manually entered one after your first IPL attempt failed, but it didn't help any.  Nevertheless, I suspect this might be your problem (or related to your problem):

What the heck is loadparm "RA"?!  I've never seen that particular loadparm anywhere before.  Have you perhaps customized your system so that loadparm "RA" causes access to one of your two missing volumes?  Could that be your problem?  Have you tried using a more normal loadparm such as "WS"?  Does that work?  If it does, I suspect your problem is your loadparm possibly coupled with the fact that you're missing two of your volumes.  You might have forgotten to copy them over to your new system.  You probably copied all of the z/OS 1.10 volumes, but forgot those two?

According to what I'm seeing, "RA" is not a valid loadparm:

  http://dtsc.dfw.ibm.com/MVSDS/'HTTPD2.ADCD.GLOBAL.HTML(READM12S)'#Header_08
  http://dtsc.dfw.ibm.com/MVSDS/'HTTPD2.ADCD.GLOBAL.SHTML(READM21Z)'#Header_08


[...]
> 21:27:07.266 000013EC HHC00401E 0:201D CKD file
> E:/zos1pk/zos1pk.3000: open error: not found
> 21:27:07.266 000013EC HHC01463E 0:201D device
> initialization failed
> 21:27:07.266 000013EC HHC00401E 0:201E CKD file
> E:/zos1pk/zoswk1.3001: open error: not found
> 21:27:07.266 000013EC HHC01463E 0:201E device
> initialization failed

Could this be your problem?  (Coupled with the weird loadparm you're using?)


[...]
> 21:28:25.844 000013EC HHC00801I Processor CP00: Fixed-point-divide
> exception code 0009  ilc 2
> 21:28:25.844 000013EC HHC02324I CP00: PSW=0704000080000000
> 0000000001553098 INST=1DE4         DR    14,4
> divide_register

THIS is *very* likely your problem!  Why this is occurring I don't know.


[...]
> 21:28:25.844 000013EC  IEA304W SYSTEM WAIT STATE CODE 80009064 DURING
> IEAVNP10 INITIALIZATION
> 21:28:25.844 000013EC HHC00809I Processor CP00: disabled wait state
> 0002000080000000 0000000000009064


I seem to vaguely recall this "DR" fixed-point-divide exception problem happening a LONG time ago with some version of z/OS (perhaps it was even 1.10??), but it does not happen for me.  What version of 1.10 are you using?  Summer? (i.e. ADCD z/OS 1.10s)  Or some other version?  I'm using 1.10s (summer) and z/OS IPLs and runs fine for me with SDL Hyperion 4.1.

Have you tried *removing* the PFPO (bit44) statement?  Does that help any?

Something else to try:

  http://hercules390.996247.n3.nabble.com/System-wait-state-code-80009064-during-IEAVNP10-hercules-4-00-td39322.html


   "I have resolved the problem, but may have uncovered
    an error in Hercules. 

   "By trail (sic) and error editing the config-file I
    discovered that I was able to successfully IPL if
    I changed 

   "ENGINES CP,AP,IP to ENGINES CP. "


which I find to be quite interesting.  I'm using CP,CP,CP,CP,CP,IP but even if I change it to CP,CP,CP,CP,AP,IP it still works just fine.  z/OS 1.10 IPLs and comes up just fine.  Why that made a difference for that one particular person I don't know.  You might want to do some more googling for the fixed-point-divide exception problem (with or without the "IEAVNP10" keyword) to see if you can discover some additional clues as to what the problem might be.

I'm sorry I don't have a definitive answer for you, but hopefully I've provided you with enough clues for you to now figure things out for yourself?

Good luck!

p.s. What the heck is loadparm "RA"??!!!


-- 
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [email protected]