Note +++ Note +++ Note +++ Note +++ Note +++ Note +++ Note +++ Note +++ Note +++ Note There is a new binary distribution available. It does not require CYGWIN in any form or flavour, as it is built using a native Windows based compiler (Microsoft Visual Studio C++ Express). These binaries are available fromTo use those new binaries, unpack/install them into a directory in your path, and run the hercules executable. That's all Note +++ Note +++ Note +++ Note +++ Note +++ Note +++ Note +++ Note +++ Note +++ Note
This article is about the production release versions of Hercules. If you are interested in a more current version from the developers' source tree, take a look at the Hercules Snapshot page
There is a small article on How to build the Hercules binaries on Windows which describes in a step-by-step manner how to create the Hercules executables. If that effort seems too much for you, you might consider to download pre-built binaries by clicking on the appropriate field in the table below
If you want to run the prebuilt binaries you will need a small subset of the Cygwin package, basically the runtime environment.
In order to build your own binaries you will need a more or less complete development environment of Cygwin. For more information take a look at the Installing Cygwin document.
The latest prebuilt windows binaries for Hercules 3.04 have been built using Cygwin 1.5.15. It is therefore recommended that you use this or a higher level of Cygwin for running the binaries
I don't think you need any special software on your Linux box to build binaries from the source archives. To compile your own binaries you will need normal development tools, like gcc, make, etc.
Once you have acquired the necessary software tools (see above) you need to do the following
on your desktop or by entering the bash command in a Windows command box
mkdir -p/hercdist
tar -xvzf hercules-V.RR.tar.gz
| |
| +-------- release
+---------- version
where hercules-V.RR.tar.gz is the name of the distribution archive for version
V and release RR
will create a new directory hercdist/hercules-V.RR
./configure && make && make install-strip
In order to find out which configuration options are available you should enter
./configure --help | less
Version 3.02 RELEASE NOTES
- TODO
Version 3.01 RELEASE NOTES
- Support for z990 crypto instructions is conditional on the presence of the
glibcrypt library.
If Hercules is BUILT, the development files for glibcrypt should be available.
When hercules is RUN, the runtime files for glibcrypt should be installed.
Depending on the level of glibcrypt used to *build* hercules, the associated
level of glibcrypt should also be present on the target machine. On systems
supporting shared library versioning, multiple levels of the glibcrypt
runtime libraries can be installed simultaneously, ensuring availability
of the z990 crypto instructions, regardless of the level of glibcrypt with
which hercules was initially built.
- CTC and LCS devices now ++MUST++ specify ALL addresses on the configuration
statement.
Example:
0A00.2 LCS .....
0B00.2 CTCI ....
or
0A00.4 LCS -oat hercules.oat
or
0A00-0A03 LCS -oat hercules.oat
or
0A00 LCS -oat hercules.oat
0A01 LCS
0A02 LCS
0A03 LCS
Previously (i.e. with version 3.00), only the first (even numbered) device
needed to be defined and Herc would automatically define the odd numbered
device for you. Starting with Hercules version 3.01 however, you now need
to define BOTH devices, just like you did with versions prior to 3.00.
Once again, starting with version 3.01, you **MUST** define BOTH DEVICES.
-------------------------------------------------------------------------------
Version 3.00 RELEASE NOTES
- Reminder that CTCI device handling was changed as follows:
- The CTCI-W32 protocol is deprecated. You should use the CTCI protocol
instead.
- You MUST NOT define both even/odd CTCI device pairs in your configuration
file. You should ONLY define the first even numbered device. Hercules will
automatically define the odd numbered device for you. If you define the
odd numbered device by mistake, an open error will occur on that device.
This is by design. See the README.NETWORKING document for further details.
- Hercules Dynamic Loader support: starting with version 3.00, Hercules now
contains support for the dynamic loading of certain modules upon startup on
some platforms (e.g. Linux and Windows for example). As a result of this new
feature, "Hercules" itself now no longer consists of just the 'hercules.exe'
module by itself, but rather consists of BOTH the 'hercules.exe' program AS
WELL AS whatever dynamic modules (DLLs) that accompany it.
As a result if this change, whenever you install a new version of Hercules,
you must ensure that you ALSO install the accompanying new versions of the
new dynamic modules as well. Attempting to use a version of Hercules with a
dynamic module that was not specifically built for that version will cause
loading of that dynamic module to fail.
You CANNOT mix versions of Hercules with differing versions of dynamically
loaded modules.
Ensure that your library path LD_LIBRARY_PATH is set correctly such that it
includes the directory of your Hercules executables. Especially, message
HHCCF042E will indicate that system is unable to locate necessary loadable
modules.
- ECPS:VM: Do not use ECPS:VM (See README.ECPSVM) in an AP or MP environment
in VM/370. If AP=YES or MP=YES is coded in DMKSYS and the AP/MP control
file is used to build the CP nucleus and NUMCPU is set to more than 1 in
the hercules.cnf file, any of LOK001, LOK003 or other abends will occur.
This occurs because the Hercules ECPS:VM CP Assist implementation is not
MP safe, and particularily, attemps VM dispatching without holding necessary
AP or MP locks.
- Due to the change in Hercules' "mainstor" memory allocation technique to
address a "double memory consumption" bug in Cygwin's malloc implementation,
some Windows Hercules users may experience an "out of memory" error whenever
Hercules is started with a large MAINSIZE configuration file value:
"HHCCF031S Cannot obtain nnnMB main storage"
This error will most likely occur (if it does at all) for those users who
have manually adjusted their Cygwin "heap_chunk_in_mb" Windows registry
setting value (in order to allow them to specify a large MAINSIZE value
when running Hercules). If this problem does occur (i.e. if you DO happen
to experience the above mentioned "HHCCF031S Cannot obtain main storage"
error with this new release of Hercules), then either REDUCE your "heap_
chunk_in_mb" value (yes, that's correct: REDUCE it; i.e. change it to a
SMALLER value) or else remove it altogether (so as to let it default).
Detailed explanation:
History/background: Cygwin has a built-in limit to the amount of memory
that may be allocated in one chunk. If you try 'malloc'ing more than this
limit, you will receive an "out of memory" error. Since many Hercules users
specify large MAINSIZE values in their configuration file, they sometimes
experience this problem.
The suggested workaround to this "problem" was to add a "heap_chunk_in_mb"
registry value to Cygwin's registry settings with a large enough value such
that Cygwin would then be able to satisfy Hercules' 'malloc' request for
such a large MAINSIZE value.
This worked fine until sometime around version 1.3.15 of Cygwin, at which
time they began using a different 'malloc' technique that unfortunately
causes TWICE as much Windows virtual memory to be allocated for any large
memory allocation (the technical reasons of which are explained in comments
in source member config.c where mainsize is being allocated).
In order to address this double memory allocation issue in Cygwin's malloc
implementation, Hercules was changed to use mmap to allocate its mainstor
rather than malloc (which, unlike malloc, does NOT inadvertently allocate
twice as Windows virtual storage than was requested), which did indeed re-
solve the "double memory allocation" problem.
Unfortunately however, because Cygwin's malloc and mmap logic each consume
completely different portions of Windows' virtual memory, the more memory
that is reserved for malloc usage (via using a larger "heap_chunk_in_mb"
value), the LESS becomes available for mmap usage!
Thus, while increasing your "heap_chunk_in_mb" registry value USED to HELP
[to allow you to allocate larger amounts of mainstor (MAINSIZE)], it NOW
causes the complete OPPOSITE effect: it ends up PREVENTING you from being
able to 'mmap' as much storage as you'd like to have!
Conclusion:
Therefore, if you are currently using the "heap_chunk_in_mb" registry value
setting to allow you to allocate large MAINSIZE values, then starting with
version 3.00 of Hercules you need to DESCREASE your "heap_chunk_in_mb" value
(or remove it altogether and let it default) in order to leave enough memory
remaining for Hercules (Cygwin actually) to be able to satisfy its 'mmap'
request for your desired MAINSIZE amount.
The following Hercules versions are currently available for download:
| Source Archive | Precompiled Binaries | ||||
|---|---|---|---|---|---|
| CPU | Windows | Linux | OSX | ||
| Emulated Processors | |||||
| 2 | 8 | ||||
|
Hercules Version: 3.04
Release Date: 2006-02-22 Cygwin Version: 1.5.15 Source Archive: 
|
i586 |
|
|
|
|
| i686 |
|
|
|||
| p4 |
|
|
|||
|
Hercules Version: 3.03.1
Release Date: 2005-12-31 Cygwin Version: 1.5.15 Source Archive:
|
i586 |
|
|
|
|
| i686 |
|
|
|||
| p4 |
|
|
|||
|
Hercules Version: 3.03
Release Date: 2005-12-21 Cygwin Version: 1.5.15 Source Archive:
|
i586 |
|
|
|
|
| i686 |
|
|
|||
| p4 |
|
|
|||
|
Hercules Version: 3.02
Release Date: 2004-12-11 Cygwin Version: 1.5.12 Source Archive:
|
i586 |
|
|
|
|
| i686 |
|
|
|||
| p4 |
|
|
|||
|
Hercules Version: 3.01
Release Date: 2003-12-01 Cygwin Version: 1.5.5 Source Archive:
|
i586 |
|
|
|
|
| i686 |
|
|
|||
| p4 |
|
|
|||
|
Hercules Version: 3.00
Release Date: 2003-10-03 Cygwin Version: 1.5.5 Source Archive:
|
i586 |
|
|
|
|
| i686 |
|
|
|||
| p4 |
|
|
|||
|
Hercules Version: 2.17.1
Release Date: 2003-02-09 Cygwin Version: 1.3.22 Source Archive:
|
i586 |
|
|
|
|
| i686 |
|
|
|||
| p4 |
|
|
|||