Release date: 20 December 2005
The new integrated console printer-keyboard is emulated on the hercules console. Commands are sent to the console by means of a command character. (default '/', thus a logon command is sent by /logon)
Starting from release 3.03 the glibcrypt library is no longer needed.
Release date: 11 December 2004
This is a new feature of z/Architecture which can cause problems with
certain versions of operating systems running in ARCHLVL=2 mode without
the so-called "Driver 55" fixes. To avoid such problems, specify
ASN_AND_LX_REUSE DISABLE in the configuration file.
Release date: 30 November 2003
An error in the 3.00 configuration script caused many users to have to override the default modules and HTTP documents directory in the Hercules configuration file, or by setting an environment variable. This error has been corrected. Hercules also now reports the actual directory that it uses by default for these files at startup time. If you specified the MODPATH or HTTPROOT configuration file statements because you encountered problems, you should examine the messages printed at startup to see if the default directories are now correct, and remove the statements if so.
In general, MODPATH and HTTPROOT should not have to be specified except in unusual circumstances.
In conjunction with the fix above, the default directories of the Windows distributed binaries have been changed. The new directories are under C:\cygwin\usr\local (which is the same as /usr/local under the Cygwin environment). No action is needed unless you have specified the MODPATH or HTTPROOT configuration file entries; if so, see the previous note.
Support for z990 crypto instructions is conditional on the presence of the glibcrypt library. When 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. Previously (i.e. with version 3.00), only the first (even numbered) device needed to be defined and Hercules 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.
Release date: 3 October 2003
In addition, 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.
Starting with version 3.00, Hercules now contains support for the dynamic loading of certain modules upon startup on Linux, Windows, and Mac OS X. This support should also work on any platform supported by GNU libtool. 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 of 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 (set by the environment variable
LD_LIBRARY_PATH) set correctly such that it includes the directory of your
Hercules dynamic load libraries. If you see message HHCCF042E,
which indicates that the system is unable to locate necessary loadable
modules, this is likely your problem. This should not be necessary if you
have a binary download, but if you're building from source, especially if
you've previously installed a binary package, this should be the first thing
you do.
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
particularly, attempts VM dispatching without holding necessary AP or MP
locks.
Due to the change in the "mainstor" memory allocation technique used by Hercules 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 error with
this new release of Hercules), then either reduce your
heap_chunk_in_mb value (yes, that's correct: reduce it,
as in change it to a smaller value) or else remove it altogether (so
as to let it default).
A complete discussion of this issue is in the RELEASE.NOTES file in the source distribution.
There is a known problem with thread priority handling under Mac OS X. The OS X threading model is different from the one classically used in Linux. This causes failures to set the timer thread priority, and slow performance as all of Hercules is set to a low execution priority. This will be fixed in a future release. A workaround, for now, for slow performance is to add the statement
CPUPRIO 0
to your Hercules configuration file.
A possibly related problem is that Hercules fails in random ways when using the NPTL (new POSIX threads library) library under Linux. This library is used by default in Red Hat 9, and possibly other systems. If problems are encountered on a very recent version of Linux, try issuing the command
export LD_ASSUME_KERNEL=2.4.1
before starting Hercules.
If you have a question about Hercules, see the Hercules Frequently-Asked Questions page.
Last updated $Date$ $Revision$