# Hercules Version 3: Release Notes and Known Issues

## Release notes for release 3.03

Release date: 20 December 2005

New device types 1052-C and 3215-C

  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)

Message Security Assist

  Starting from release 3.03 the glibcrypt library is no longer needed.

## Release notes for release 3.02

Release date: 11 December 2004

ASN-and-LX-reuse facility

  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 notes for release 3.01

Release date: 30 November 2003

Library modules and HTTP documents default directories

  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.

Windows default directories

  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.

Message Security Assist

  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 device numbers

  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 notes for release 3.00

Release date: 3 October 2003

CTCI device changes
  - The CTCI-W32 protocol is deprecated. You should use the CTCI protocol instead.
  - The VMNET protocol is also deprecated. Not even its author uses it any more. Every system on which Hercules is now prebuilt has the TUN/TAP driver functionality available in one form or another, and it's much more robust.
  Both of these will go away in a future release.

  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.

Hercules Dynamic Loader support

  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.

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 particularly, attempts VM dispatching without holding necessary AP or MP locks.

Memory allocation on Windows

  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.

Thread priority and other problems

  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$