IOSAS Abend 378-1C z/OS 1.13

[mikewalham]

Hello All,

When I start a z/OS 1.13 system in Hercules 3.09, I receive an Abend 378-1C in IOSAS.
I don't have the problem in a real CPC with excatly the same system.
Has anyone had the problem ?
Thanks for your help.

DUMPID=001 REQUESTED BY JOB (IOSAS )
DUMP TITLE=COMPON=IOS BUILD CHANNEL TABLE,COMPID=SC1C3,ISSUER=I
OSVCHPT
IEF196I IEF237I 0A20 ALLOCATED TO SYS00003
IEF196I IEF237I 0A20 ALLOCATED TO SYS00014
IEF196I IEA995I SYMPTOM DUMP OUTPUT
IEF196I SYSTEM COMPLETION CODE=378 REASON CODE=0000001C
IEF196I TIME=20.35.24 SEQ=00006 CPU=0000 ASID=0014
IEF196I PSW AT TIME OF ERROR 070C1000 8158B386 ILC 2 INTC 0D
IEF196I NO ACTIVE MODULE FOUND
IEF196I NAME=UNKNOWN
IEF196I DATA AT PSW 0158B380 - 00181610 0A0D98DC D0088910
IEF196I AR/GR 0: 009FF358/84000000 1: 00000000/84378000
IEF196I 2: 00000000/00000000 3: 00000001/0000F703
IEF196I 4: 00000000/009FF358 5: 00000000/00000001
IEF196I 6: 00000000/00FD9E58 7: 00000000/00000378
IEF196I 8: 00000000/0000001C 9: 00000000/00003C2C
IEF196I A: 00000000/00000000 B: 00000000/00000378
IEF196I C: 00000000/00000004 D: 00000000/022ECAE8
IEF196I E: 00000000/87F6D8BE F: 00000001/0000001C
IEF196I END OF SYMPTOM DUMP
IEA995I SYMPTOM DUMP OUTPUT 736
SYSTEM COMPLETION CODE=378 REASON CODE=0000001C
TIME=20.35.24 SEQ=00006 CPU=0000 ASID=0014
PSW AT TIME OF ERROR 070C1000 8158B386 ILC 2 INTC 0D
NO ACTIVE MODULE FOUND
NAME=UNKNOWN
DATA AT PSW 0158B380 - 00181610 0A0D98DC D0088910
AR/GR 0: 009FF358/84000000 1: 00000000/84378000
2: 00000000/00000000 3: 00000001/0000F703
4: 00000000/009FF358 5: 00000000/00000001
6: 00000000/00FD9E58 7: 00000000/00000378
8: 00000000/0000001C 9: 00000000/00003C2C
A: 00000000/00000000 B: 00000000/00000378
C: 00000000/00000004 D: 00000000/022ECAE8
E: 00000000/87F6D8BE F: 00000001/0000001C
END OF SYMPTOM DUMP

[zach [e-mail] [hercules-390]]

Has anyone found why this is happening or have a resolution for it?
Brian

Yes I know this was two years ago. But I am getting the same error ie:

DUMPID=001 REQUESTED BY JOB (IOSAS )
DUMP TITLE=COMPON=IOS BUILD CHANNEL TABLE,COMPID=SC1C3,ISSUER=IOSVCHPT
Abend 378-1C in IOSAS


But the chain seems to have no resolution so was wondering if there was
a solution.

Thank You

Zach

[[e-mail] [hercules-390]]

I probably can't help but it would be useful to someone who knows more what level of MVS are you running when this occurs: MVS 3.8J with no PTFs? Turnkey 3? Turnkey 4-? OS/390? z/OS? As of what date? What are you doing at the time: System Startup? System shutdown? Running some code you wrote?

The abend code indicates that IOS tried to free storage with an address of zero - I know nothing of IOS code but that sounds unusual to me - like something bad got passed to IOS or something got overlaid.

Jim

[Robert Prins [e-mail] [hercules-390]]

Have you read the title of this post?

IOSAS Abend 378-1C ***z/OS 1.13***

Robert

Post by ***@yahoo.com [hercules-390]
I probably can't help but it would be useful to someone who knows more
what level of MVS are you running when this occurs: MVS 3.8J with no PTFs?
Turnkey 3? Turnkey 4-? OS/390? z/OS? As of what date? What are you doing at
the time: System Startup? System shutdown? Running some code you wrote?
The abend code indicates that IOS tried to free storage with an address of
zero - I know nothing of IOS code but that sounds unusual to me - like
something bad got passed to IOS or something got overlaid.
Jim

[[e-mail] [hercules-390]]

Yes but that does not necessarily mean that is the OS on which Zach is experiencing the error.

Jim

[[e-mail] [hercules-390]]

Hi,

There are two known solutions to this problem(see below). The error is caused when IOSAS is at the end of it's configuration processing during the IPL and it has noticed that the emulated hardware (which he thinks is the physical hardware) and the IODF image of that hardware don't match, so he does the best he can and in the end tries to free all of the storage areas that he had getmained. One of those areas is zero bytes long (because there was nothing to get it for), and when IOSAS issues the freemain with zero bytes, it gets the abend.

The first solution is the one that most people seem to take (because it's a lot less work), but it doesn't really "fix" anything. That solution is to set a SLIP for the S378 for IOSAS that will bypass the dump processing. As I said, it doesn't really fix anything, but you will be able to IPL without the dump and it will go a bit faster since it (the dump) won't be captured. You will still get the message that the dump occurred, but that's all, the dump itself will be skipped.

The second (in my opinion better) solution is to generate a new IODF that matches a) supported hardware for the version of z/OS you are using, and b) is in LPAR mode instead of BASIC mode. Most people seem to have taken the ADCD system in some form which has the IODF's generated in BASIC mode for some old 9672 or H80 (I think), and they are telling Hercules that they are emulating something that z/OS actually likes (z10, etc.). Unfortunately, that creates a logic issue for IOSAS when it is doing all of it's whiz-bang stuff at IPL. If you generate a new LPAR mode IODF for a 2097 (z10) or 2827(ec12) with a CPUVERID of "FD", you will find that the problem will go away.

It's not super-hard to generate the IODF, but for most people, especially those who use the ADCD in the first place, it's beyond their capabilities and comfort level, so they opt for solution number one above.

Since there is no damage/harm from the abend in the first place, just skipping the dump is an acceptable solution for those that don't want to put the effort into generating a new IODF that matches.

If you are using Hercules with z/OS I am going to assume that you are doing it legally, and that means that you probably have a "real" mainframe that you can just copy the IODF from and make the changes to your Hercules defs to match it. If you bought the laptop hardware/software you wouldn't be reading this far into the entry and it wouldn't apply to you anyway. :)

If necessary I can post the line you insert into the parmlib member to set the SLIP, but I'm sure most people can look it up as fast as I can.

Brian

[zach [e-mail] [hercules-390]]

On 1/01/2017 12:58 PM, ***@SyzygyInc.com [hercules-390] wrote:
Brian
This makes a lot of sense.
Having played with IODFs in the past I thought that would be the way to go.
BUT I don't see hercules handles ChpIDs.
If I create a processor thus:

Processor ID . . . . . . . . : HOME
Support level:
XMP, 2097 support
Processor type . . . . . . . . 2097 +
Processor model . . . . . . . E26 +
Configuration mode . . . . . . LPAR +

When I try to create a partition I see this:
CSS Devices in SS0 Devices
/ ID Maximum + Actual Maximum
_ 0 65280 0 65535
_ 1 65280 0 65535
_ 2 65280 0 65535
_ 3 65280 0 65535

I know of channel sets but have not played with them. I figured I
would use channel set 0 since I understand that is almost the same as no
channels set.
I then run into the problem that the current channels are types not
support by z10's

I can see why people just set a slip trap.
Did you actually do the new IODF ?
Is there a simpler way to it for hercules
and I am therefore over thinking it ?

Thank you
Zach

Hi,
There are two known solutions to this problem(see below). The error is
caused when IOSAS is at the end of it's configuration processing
during the IPL and it has noticed that the emulated hardware (which he
thinks is the physical hardware) and the IODF image of that hardware
don't match, so he does the best he can and in the end tries to free
all of the storage areas that he had getmained. One of those areas is
zero bytes long (because there was nothing to get it for), and when
IOSAS issues the freemain with zero bytes, it gets the abend.
The first solution is the one that most people seem to take (because
it's a lot less work), but it doesn't really "fix" anything. That
solution is to set a SLIP for the S378 for IOSAS that will bypass the
dump processing. As I said, it doesn't really fix anything, but you
will be able to IPL without the dump and it will go a bit faster since
it (the dump) won't be captured. You will still get the message that
the dump occurred, but that's all, the dump itself will be skipped.
The second (in my opinion better) solution is to generate a new IODF
that matches a) supported hardware for the version of z/OS you are
using, and b) is in LPAR mode instead of BASIC mode. Most people seem
to have taken the ADCD system in some form which has the IODF's
generated in BASIC mode for some old 9672 or H80 (I think), and they
are telling Hercules that they are emulating something that z/OS
actually likes (z10, etc.). Unfortunately, that creates a logic issue
for IOSAS when it is doing all of it's whiz-bang stuff at IPL. If you
generate a new LPAR mode IODF for a 2097 (z10) or 2827(ec12) with a
CPUVERID of "FD", you will find that the problem will go away.
It's not super-hard to generate the IODF, but for most people,
especially those who use the ADCD in the first place, it's beyond
their capabilities and comfort level, so they opt for solution number
one above.
Since there is no damage/harm from the abend in the first place, just
skipping the dump is an acceptable solution for those that don't want
to put the effort into generating a new IODF that matches.
If you are using Hercules with z/OS I am going to assume that you are
doing it legally, and that means that you probably have a "real"
mainframe that you can just copy the IODF from and make the changes to
your Hercules defs to match it. If you bought the laptop
hardware/software you wouldn't be reading this far into the entry and
it wouldn't apply to you anyway. :)
If necessary I can post the line you insert into the parmlib member to
set the SLIP, but I'm sure most people can look it up as fast as I can.
Brian

[[e-mail] [hercules-390]]

Hi,

Yes, you are definitely overthinking things.

the z10 defaults to 4 CSS, but you can define everything to CSS-0.

It will help if you treat it like a new piece of hardware and map it out on paper first. Once that's done, just add the control units and the devices. Don't forget to add your consoles. You don't need to be fancy, just put in the stuff you need to IPL it, and make sure that your Hercules config matches what you created. Then just IPL. You can add more devices later. Don't add devices you can't emulate (nothing with the word "HIPER" in front of it). Once it's complete you should be able to IPL with no problems.

Sometimes people take their IODF from their "real" hardware and forget to remove the stuff they can't emulate which will cause problems again. Your goal is just to make IOS happy with the devices you create. Also don't forget that your 3390's use 3990 control units.

It can seem like a difficult process if you let it get in front of you instead of you following your plan, so just take your time.

Brian

[zach [e-mail] [hercules-390]]

Hi Brian
That helped.
I have built an IODF for z10 (CPU type 2097).
And it is in LPAR mode.

I defined some disk & consoles.
I IPL'd it and the system comes up quite happily (using my IODF
according to D IOS,CONFIG)


However I still got the issue
"DUMP TITLE=COMPON=IOS BUILD CHANNEL TABLE,COMPID=SC1C3,ISSUER=IOSVCHPT"
"SYSTEM COMPLETION CODE=378 REASON CODE=0000001C"

Is there a step I have missed ?
Cheers
Zach

Post by ***@SyzygyInc.com [hercules-390]
Hi,
Yes, you are definitely overthinking things.
the z10 defaults to 4 CSS, but you can define everything to CSS-0.
It will help if you treat it like a new piece of hardware and map it
out on paper first. Once that's done, just add the control units and
the devices. Don't forget to add your consoles. You don't need to be
fancy, just put in the stuff you need to IPL it, and make sure that
your Hercules config matches what you created. Then just IPL. You can
add more devices later. Don't add devices you can't emulate (nothing
with the word "HIPER" in front of it). Once it's complete you should
be able to IPL with no problems.
Sometimes people take their IODF from their "real" hardware and forget
to remove the stuff they can't emulate which will cause problems
again. Your goal is just to make IOS happy with the devices you
create. Also don't forget that your 3390's use 3990 control units.
It can seem like a difficult process if you let it get in front of you
instead of you following your plan, so just take your time.
Brian

[[e-mail] [hercules-390]]

Hmm,

no, if you defined the hardware okay and it shows as being valid, then there is no reason for the abend any more. Can you please send or post your Hercules cnf file?

In the mean time, place this as the FIRST line of you COMMND00 parmlib member (assuming you are using COMMND00):

COM='SLIP SET,C=378,ID=S378,A=NODUMP,J=IOSAS,END'

At least while we are looking into this, you won't get the dump any more and it should speed your IPL a bit.

What level of z/OS are you running currently under Hercules and what version of Hercules are you running (i.e. Version, build, etc.). Is the the 32 or 64bit version? Is it Fish's version?

Brian

[zach [e-mail] [hercules-390]]

Hi Brian
Here is the conf file
It is Hyperion 64bit; since I am using Hercgui I believe it is Fish's
version.

# Hercules Emulator Control file...
# Description:
# MaxShutdownSecs: 15
# LoadUnit: 0A80
# RCFile:
# LogoFile:
# IgnoreParseErrors: 0
# HercGUI Version: 1.13.0.4238
PANTITLE "z/OS 2.10"
ARCHLVL z/Arch # (Hyperion 4.x)
ARCHLVL ENABLE ASN_LX_REUSE
ARCHLVL ENABLE BIT44
MAXCPU 4
ENGINES CP,CP,CP,CP
NUMCPU 4
HERCPRIO 0
TODPRIO -20
DEVPRIO 8
CPUPRIO 15
AUTO_SCSI_MOUNT NO
CNSLPORT 3270
CONKPALV (3,1,10)
CODEPAGE default
CPUMODEL 2097
CPUSERIAL 097654
CPUVERID 00
DEVTMAX 8
DIAG8CMD ENABLE NOECHO
ECPSVM NO
MODPATH .
LEGACYSENSEID DISABLE
LOADPARM 0A8229M.
LPARNUM 01
LPARNAME HERCULES
MAINSIZE 1024
MANUFACTURER HRC
MODEL EMULATOR "" "" ""
MOUNTED_TAPE_REINIT DISALLOW
OSTAILOR Z/OS
PANRATE 50
PGMPRDOS LICENSED
PLANT ZZ
SHCMDOPT ENABLE NODIAG8
SYSEPOCH 1900
TIMERINT 50
TRACEOPT TRADITIONAL
TZOFFSET +0000
XPNDSIZE 0
YROFFSET 0

Post by ***@SyzygyInc.com [hercules-390]
Hmm,
no, if you defined the hardware okay and it shows as being valid, then
there is no reason for the abend any more. Can you please send or post
your Hercules cnf file?
In the mean time, place this as the FIRST line of you COMMND00 parmlib
COM='SLIP SET,C=378,ID=S378,A=NODUMP,J=IOSAS,END'
At least while we are looking into this, you won't get the dump any
more and it should speed your IPL a bit.
What level of z/OS are you running currently under Hercules and what
version of Hercules are you running (i.e. Version, build, etc.). Is
the the 32 or 64bit version? Is it Fish's version?
Brian

[[e-mail] [hercules-390]]

Post by zach ***@yahoo.com.au [hercules-390]
Hi Brian
Here is the conf file
It is Hyperion 64bit; since I am using Hercgui
I believe it is Fish's version.

I suggest you post the first bit of your
hercules.log file which should contain
the Hercules version number, something
like this:

18:35:47 Hercules Version 3.07:380-4.x
18:35:47 (c)Copyright 1999-2010 by Roger Bowler, Jan Jaeger, and others
18:35:47 Built on Dec 7 2016 at 12:43:32
18:35:47 Build information:
18:35:47 Windows (MSVC) build for AMD64
18:35:47 Modes: S/370 S/380 ESA/390 z/Arch
18:35:47 Max CPU Engines: 8
18:35:47 Using fthreads instead of pthreads
18:35:47 Dynamic loading support
18:35:47 Using shared libraries
18:35:47 HTTP Server support
18:35:47 No SIGABEND handler
18:35:47 Regular Expressions support
18:35:47 Automatic Operator support
18:35:47 Machine dependent assists: cmpxchg1 cmpxchg4 cmpxchg8
18:35:47 Running on PAUL-DELL Windows_NT-6.2 AMD64 MP=8


BFN. Paul.

[zach [e-mail] [hercules-390]]

Hi Brian
Here is the conf file
It is Hyperion 64bit; since I am using Hercgui I believe it is Fish's
version.
As per Paul's suggestion, which I should have thought of, I am also
including the start of the log file.



# Hercules Emulator Control file...
# Description:
# MaxShutdownSecs: 15
# LoadUnit: 0A80
# RCFile:
# LogoFile:
# IgnoreParseErrors: 0
# HercGUI Version: 1.13.0.4238
PANTITLE "z/OS 2.10"
ARCHLVL z/Arch # (Hyperion 4.x)
ARCHLVL ENABLE ASN_LX_REUSE
ARCHLVL ENABLE BIT44
MAXCPU 4
ENGINES CP,CP,CP,CP
NUMCPU 4
HERCPRIO 0
TODPRIO -20
DEVPRIO 8
CPUPRIO 15
AUTO_SCSI_MOUNT NO
CNSLPORT 3270
CONKPALV (3,1,10)
CODEPAGE default
CPUMODEL 2097
CPUSERIAL 097654
CPUVERID 00
DEVTMAX 8
DIAG8CMD ENABLE NOECHO
ECPSVM NO
MODPATH .
LEGACYSENSEID DISABLE
LOADPARM 0A8229M.
LPARNUM 01
LPARNAME HERCULES
MAINSIZE 1024
MANUFACTURER HRC
MODEL EMULATOR "" "" ""
MOUNTED_TAPE_REINIT DISALLOW
OSTAILOR Z/OS
PANRATE 50
PGMPRDOS LICENSED
PLANT ZZ
SHCMDOPT ENABLE NODIAG8
SYSEPOCH 1900
TIMERINT 50
TRACEOPT TRADITIONAL
TZOFFSET +0000
XPNDSIZE 0
YROFFSET 0
========================================

Log file


========================================
17:57:31.085 ******** HHC046I Acceptance of PGMPRDOS LICENSED setting
verified
17:57:31.086 ******** Program to be executed =
F:/Hercules4/Hercules4-64Bit/Hercules.exe
17:57:31.086 ******** Control file to be used =
F:/Hercules4/config/zos210-N.conf
17:57:31.171 Hercules started; process-id=00001740
17:57:31.375 00001740 HHC01413I Hercules version 4.0.0.8675-gd0eefbf
(4.0.0.8675)
17:57:31.375 00001740 HHC01414I (C) Copyright 1999-2016 by Roger Bowler,
Jan Jaeger, and others
17:57:31.375 00001740 HHC01415I Build date: Nov 27 2016 at 06:17:55
17:57:31.375 00001740 HHC01417I ** The unofficial SoftDevLabs version of
Hercules **
17:57:31.375 00001740 HHC01417I Built with: Microsoft Visual C 150030729 1
17:57:31.375 00001740 HHC01417I Build type: Windows MSVC AMD64 host
architecture build
17:57:31.375 00001740 HHC01417I Modes: S/370 ESA/390 z/Arch
17:57:31.375 00001740 HHC01417I Max CPU Engines: 64
17:57:31.375 00001740 HHC01417I Using Fish threads Threading Model
17:57:31.375 00001740 HHC01417I Using Error-Checking Mutex Locking Model
17:57:31.375 00001740 HHC01417I With Syncio support
17:57:31.375 00001740 HHC01417I With Shared Devices support
17:57:31.375 00001740 HHC01417I With Dynamic loading support
17:57:31.375 00001740 HHC01417I Using shared libraries
17:57:31.375 00001740 HHC01417I With External GUI support
17:57:31.375 00001740 HHC01417I With Partial TCP keepalive support
17:57:31.375 00001740 HHC01417I With IPV6 support
17:57:31.375 00001740 HHC01417I With HTTP Server support
17:57:31.375 00001740 HHC01417I With sqrtl support
17:57:31.375 00001740 HHC01417I Without SIGABEND handler
17:57:31.375 00001740 HHC01417I With CCKD BZIP2 support
17:57:31.375 00001740 HHC01417I With HET BZIP2 support
17:57:31.375 00001740 HHC01417I With ZLIB support
17:57:31.375 00001740 HHC01417I With Regular Expressions support
17:57:31.375 00001740 HHC01417I With Object REXX support
17:57:31.375 00001740 HHC01417I Without Regina REXX support
17:57:31.375 00001740 HHC01417I With Automatic Operator support
17:57:31.375 00001740 HHC01417I Without National Language Support
17:57:31.375 00001740 HHC01417I Machine dependent assists: cmpxchg1
cmpxchg4 cmpxchg8 hatomics=msvcIntrinsics
17:57:31.375 00001740 HHC01417I Running on: DROPBEAR (Windows-6.2.9200
Intel(R) x64) LP=8, Cores=4, CPUs=1


Thanks
Zach

Post by ***@SyzygyInc.com [hercules-390]
Hmm,
no, if you defined the hardware okay and it shows as being valid,
then there is no reason for the abend any more. Can you please send
or post your Hercules cnf file?
In the mean time, place this as the FIRST line of you COMMND00
COM='SLIP SET,C=378,ID=S378,A=NODUMP,J=IOSAS,END'
At least while we are looking into this, you won't get the dump any
more and it should speed your IPL a bit.
What level of z/OS are you running currently under Hercules and what
version of Hercules are you running (i.e. Version, build, etc.). Is
the the 32 or 64bit version? Is it Fish's version?
Brian

[[e-mail] [hercules-390]]

There appears to be only a few differences between yours and mine. Also, I don't use Hyperion, I use V3.12 from the hercules-390.eu http://www.hercules-390.eu/ web page.

The differences I see are :
ALRF ENABLE in mine (yours doesn't have one)
CPUMODEL 2098 (yours is a 2097)
CPUVERID FD (yours is 00)
DIAG8CMD DISABLE NOECHO (yours is enable)
MAINSIZE 12288 (yours is 1024)
MANUFACTURER IBM (yours is HRC)
MODEL E10 "" "" "" (yours is "emulator")
PLANT 02 (yours is zz)
I also have 8 engines and 8 cpus, but you have 4, which I don't think can cause any problems.

Since we are talking about a piece of software that is abending when freeing empty storage due to not having a listed device so doesn't understand the hardware it's presented with, and not giving it a model or version that explains things better might be a problem, but on the other hand, maybe it's hyperion.

While I look into this, be sure to code the SLIP.

Brian

[zach [e-mail] [hercules-390]]

Hi Brian

Well I tried changing all but the ALRF, memory and number of CPU's -
which made no difference.
I seem to recall that ALRF was replaced by "ARCHLVL ENABLE ASN_LX_REUSE"
but a quick search did not show me where I found this.


(strictly I changed the memory to 12288. But a couple of times I got
Wait 038 abends - not enough memory. Since I only have 8GB on my
machine I can accept this as being a hardware limitation)
I also reduced the number of volumes being used down to 18 from
previously having about 90.

Did not seem to make a difference.
(yes the slip, as expected, speeds up the IPL)

Thanks
Zach

Post by ***@SyzygyInc.com [hercules-390]
There appears to be only a few differences between yours and mine.
Also, I don't use Hyperion, I use V3.12 from the hercules-390.eu
<http://www.hercules-390.eu/> web page.
ALRF ENABLE in mine (yours doesn't have one)
CPUMODEL 2098 (yours is a 2097)
CPUVERID FD (yours is 00)
DIAG8CMD DISABLE NOECHO (yours is enable)
MAINSIZE 12288 (yours is 1024)
MANUFACTURER IBM (yours is HRC)
MODEL E10 "" "" "" (yours is "emulator")
PLANT 02 (yours is zz)
I also have 8 engines and 8 cpus, but you have 4, which I don't think
can cause any problems.
Since we are talking about a piece of software that is abending when
freeing empty storage due to not having a listed device so doesn't
understand the hardware it's presented with, and not giving it a model
or version that explains things better might be a problem, but on the
other hand, maybe it's hyperion.
While I look into this, be sure to code the SLIP.
Brian

[[e-mail] [hercules-390]]

Since your PC only has 8GB, you should probably be giving no more than 6GB to Hercules for z/OS. It will take the memory and not give it back until you shut Hercules/zOS down.

I'm hoping someone that is running hyperion instead of version 3.12 of Hercules can chime in if they are having the IOSAS ABEND problem. I can't seem to reproduce it on my system.

I'm using the 64bit version of Herc 3.12, maybe that makes the difference. When I had the problem, creating a new IODF with LPAR support fixed it. Originally I coded a z/890 then later moved to a newer hardware definition so that doesn't appear to cause the problem.

Maybe Fish can tell us if he sees the problem on his system.

Brian

[[e-mail] [hercules-390]]

Post by ***@SyzygyInc.com [hercules-390]
Since your PC only has 8GB, you should
probably be giving no more than 6GB to
Hercules for z/OS. It will take the memory
and not give it back until you shut
Hercules/zOS down.

Why should that be a problem? Windows/Unix
should be paging out any Hercules memory
that isn't being used if someone else needs
it. And paging it back in if Hercules/zOS
needs it.

BFN. Paul.

[[e-mail] [hercules-390]]

Hercules appears to allocate the "real" memory and sets it aside for his use. I don't think he can use pagable memory that way. At least, he does appear to know the difference, I have tried to use more than I have physically on my system previously and it would never allow it. When I built my new PC, I installed 64GB of memory, so giving 16GB to Hercules is not a problem. It also seems to be able to run very fast with it. I have tried it with more than 16GB, and it doesn't appear to alter anything (throughput-wise), so I took it back away.

Brian

[[e-mail] [hercules-390]]

Post by ***@SyzygyInc.com [hercules-390]
Hercules appears to allocate the "real"
memory and sets it aside for his use.

As far as I know, and "certainly" in the
case of 3.07, Hercules just does a
standard malloc() which gets virtual
memory from Windows. Of course
if Windows is able to, it will keep all
that memory in real memory.

Post by ***@SyzygyInc.com [hercules-390]
I have tried to use more than I have
physically on my system previously
and it would never allow it.

With a 3.07 derived 64-bit Hercules I
was able to allocate 15 GB even
though I only have 8 GB of real
memory.

So long as there is sufficient hard
disk space, Windows should allow
you to give more memory to
Hercules than you actually have
real memory on your computer.

Of course, if you are actually
intensively using such extra
memory, it will start to page like
hell, ie your hard disk light will
be on all the time.

Post by ***@SyzygyInc.com [hercules-390]
I have tried it with more than 16GB,
and it doesn't appear to alter anything
(throughput-wise), so I took it back away.

This is to be expected if you are not
intensively using more than 16 GB
of memory for some real application.

Even when I do a large C compile it
does it all in about 60 MiB of memory,
so it is not surprising you aren't seeing
any benefit of lots of memory to your
system. You would need to test with
an artificial program instead.

BFN. Paul.

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Brian Westerman wrote:

[...]

Post by ***@SyzygyInc.com [hercules-390]
I have tried to use more than I have physically on my
system previously and it would never allow it.

I don't wish to have yet another thread "hijacked" by steering it too far off its original topic, BUT...

Then at the time, either: a) you must have been using a rather unusual version of Hercules (an experimental "AWE" (Address Windowing Extension) one perhaps? (which would abort if unable to acquire the real Windows memory needed)), or: b) it was a 32-bit version of Hercules running on 32-bit Windows and you were trying to set a MAINSIZE greater than about 2GB or so (or more than about 3GB - 4GB or so (I think) on 64-bit Windows), because what you imply should simply NOT occur.

Paul is right: Hercules does a simple malloc (calloc actually but that's not germane) for the specified MAINSIZE amount and it matters NOT how much real physical RAM you have installed on your system. It only matters how large your (Hercules's) virtual address space is (which for 32-bit Windows (or 32-bit Hercules on 64-bit Windows) is 2GB and for 64-bit Hercules on 64-bit Windows is 8TB!).

Paul is also right that if you specify a MAINSIZE significantly greater than the amount of physical RAM you have installed on your system (and your guest running under Hercules makes heavy use of its emulated "real" storage) then the performance of your Windows host system will come to a crawl due to Windows "thrashing" trying to accommodate Hercules's large virtual storage requirement (working set).

My general rule is also the same as his: never specify a MAINSIZE larger than however much real RAM you have installed on your real system minus about 2GB or so. This ensures Windows will have at least 2GB (1GB absolute minimum) for itself and all of the other stuff it needs it for (e.g. all of its many services and whatever other programs you might be running such as web browsers, the Windows Explorer shell itself, etc).

Post by ***@SyzygyInc.com [hercules-390]
When I built my new PC, I installed 64GB of memory, so giving
16GB to Hercules is not a problem. It also seems to be able to
run very fast with it. I have tried it with more than 16GB,
and it doesn't appear to alter anything (throughput-wise), so
I took it back away.

I've only got 16GB and typically give Hercules 8GB and noticed the same thing as you: giving it more doesn't seem to speed things up any. In fact, (ahem) "MVS" (cough) probably doesn't even use more than 4GB or so I'm guessing (depending on what you're running on it of course).

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Brian_Westerman wrote:

[...]

Post by ***@SyzygyInc.com [hercules-390]
Maybe Fish can tell us if he sees the problem on his system.

Nope. Both 1.10s and 2.1s seem to run just fine(*).

[[e-mail] [hercules-390]]

I can bring up 1.12, 1.13, 2.1 and 2.2 with no problems myself.

I wonder what is different between his system and mine pretend-hardware wise.

Brian

[[e-mail] [hercules-390]]

That's interesting; I've always just let it abend and I clear the dumps after a while. I don't use the ADCD though, and the iodf used is the same one used when the system is ipl'd on the real hardware. I'm pretty sure I have the cpu set right, model, plant etc. and it has always abended.

Still, something to play around with. Current issue is that something in this last RSU for z/OS 2.2 causes a 9064 wait, before system parameters come up. GA version is fine, but not this current update. Can't see it being a z/vm issue.