Hercules Release Notes and Known Issues

Release notes for the SDL version of Hercules 4.2 Hyperion

CCKD64 Support

Version 4.2 of SDL Hercules Hyperion introduces support for very large Compressed CKD (CCKD) dasd image files, called CCKD64, which can be larger than 4GB in size.

The designed maximum file size that the original default implementation of CCKD supported was (and still is) 4GB. If a compressed CCKD dasd image file (or any of its associated shadow files) reaches a file size of 4GB, unrecoverable I/O errors occur since 4GB was (and still is) the architected maximum size that a CCKD dasd (or any of its shadows) grow to. (This is caused by the use of 32-bit file offsets being used in the original design.)

With the introduction of CCKD64 support however, the new CCKD64 file format uses 64-bit file offsets, thus allowing CCKD64 format compressed dasd image files (and their associated shadow files) to grow up to the theoretical maximum of 18EB in size. The actual maximum size that any operating system file can be, however, is limited by the operating system itself as well as the format of the file system that the file resides on. On Windows systems using NTFS volumes for example, the actual maximum supported file size is 16TB.

In order to take advantage of the new CCKD64 file format, existing dasd images in the old CCKD compressed format must first be converted to the new CCKD64 compressed format using either the new 'convto64' utility (recommended), new images created in the new format using the new 'dasdinit64' utility, or else existing old format images copied to the new format using the new 'dasdcopy64' utility.

In addition to dasdinit64 and dasdcopy64, there are also corresponding CCKD64 versions of the cckdcdsk utility called cckdcdsk64, a CCKD64 version of the cckdcomp utility called cckdcomp64, a CCKD64 version of the cckdswap utility called cckdswap64, a CCKD64 version of the cckddiag utility called cckddiag64, a CCKD64 version of the dasdconv utility called dasdconv64, and a CCKD64 version of the dasdload utility called dasdload64.

The existing dasdls, dasdcat, dasdpdsu dasdisup, and dasdseq utilities do not have corresponding CCKD64 versions. However, all of them do support the new CCKD64 file format in addition to the existing CCKD file format. They just don't have separate executable names ending in '64' since they have all been updated to support either the new or old format automatically.

More information about the new CCKD64 file format can be found on the "Compressed Dasd Emulation" web page.

Release notes for the SDL version of Hercules 4.1 Hyperion

External Packages

Select source code and associated functionality has been moved out of the Hercules repository and into separately maintained External Package repositories. Refer to the README.EXTPKG document for more information.

Minimum supported Windows platform is now Windows Vista

The new minimum supported Windows platform is now Windows Vista. All Hercules users still running older versions of Windows should upgrade to at least Windows Vista or greater, with Windows 7 being preferred.

The ability to define process and thread priorities has been removed

Previously, Hercules supported various commands/statements that allowed the tweaking of Hercules's various internal thread priorities (HERCPRIO, CPUPRIO, TODPRIO, etc). This ability has been removed. Such statements in your configuration file will now cause a "deprecated and ignored" warning message instead. You should remove all such statements from your configuration file.

ARCHLVL and FACILITY command changes

The FACILITY command was completely redesigned and rewritten in order to more properly support and enforce the concept of prerequisite facilities (i.e. a facility presuming/requiring some other facility). As part of this rewrite the ARCHLVL command functionality to enable/disable/query facilities was moved into a new separate FACILITY command such that the ARCHLVL command now only deals with setting/querying the architecture mode. To enable/disable/query facilities, use the new FACILITY command.

Additionally, the facility names used in the FACILITY command to enable, disable or query a facility have also been changed. All defined facilities now begin with a 3-digit facility bit number in addition to their abbreviated facility name. This was done to ensure the correct facility was being enabled or disabled due to the similarity of some facility names. For example, the previously named "ASN_LX_REUSE" facility is now named "006_ASN_LX_REUSE". Similarly, the previously named "PFPO" facility is now named "044_PFPO".

For a detailed list of the new abbreviated (short) facility names, use the "FACILITY QUERY ..." command.

"ASN and LX Reuse" now defaults to enabled for z/Architecture

The "ASN and LX Reuse" facility (STFL bit 6) is now enabled by default for the z/Architecture mode, as it should have been all along. It is still disabled by default for the ESA/390 architecture mode however.

In earlier versions of Hercules it defaulted to disabled requiring those running z/Architecture guest operating systems to have to manually add an FACILITY ENABLE 006_ASN_LX_REUSE statement to their configuration file. Such statements are now no longer necessary.

MAXCPU and NUMCPU statements

The combination of NUMCPU and MAXCPU controls the behavior of how many CPU engines will be configured online upon startup and how many can be configured online later. In previous versions this was controlled via the NUMCPU statement and the compile-time constant 'MAX_CPU_ENGINES'.

For compatibility with previous versions of Hercules, if MAXCPU is not specified its value defaults to NUMCPU. If neither is specified it defaults to 1.

HTTPROOT and HTTPPORT statements are now fully deprecated

Any httproot or httpport statements are now rejected as invalid statements. All users still using either statement format in their configuration files must now replace all occurrences with http root ... and http port ... instead.

New and improved CMPSC Compression Call 2012 instruction implementation is now the default

The default implementation for the CMPSC Compression Call instruction is now the new cmpsc_2012 implementation. The previous legacy implementation no longer exists. Refer to the README.CMPSC document of the source code distribution for more information.

The sequence of certain configuration file statements is important

The ARCHLVL statement (previously called ARCHMODE for example, defines the initial architectural mode of the system) should generally precede (come before) any FACILITY statements that enable or disable a given architectural feature.

For example: on certain IBM operating systems the z/Architecture "PFPO Facility" must be enabled or the system will not IPL. While at the time of this writing Hercules does not currently support the Perform Floating-Point Operation (PFPO) Facility, the STFLE facility bit can nonetheless be forcibly enabled anyway via the FACILITY ENABLE BIT44 configuration file statement. Since the facility is a z/Architecture-only feature however, your initial architecture must either be set to "z/Arch" beforehand, or else you need to specify the optional [archlvl] parameter on your FACILITY ENABLE BIT44 statement. This usually means your "ARCHLVL z/Arch" statement must come before your "FACILITY ENABLE BIT44" statement in your configuration file. Otherwise the PFPO Facility would not get enabled.

With the introduction of limited automatic LPAR-mode/BASIC-mode switching (see next item below), LPARNUM statements should follow ARCHLVL statements if LPAR mode is truly desired for ARCHLVL S/370 (which is usually not the case).

The ARCHLVL and LPARNUM statements are currently the only known configuration file statements whose sequence matters. The order of all other configuration file statements should not currently matter. This may change in the future however, so be sure to always carefully read through the RELEASE NOTES (this document) with each new update to Hercules.

Limited automatic LPARNUM updating when setting certain architecture modes

When ARCHLVL S/370 is set, LPARNUM is now automatically changed to BASIC (which also changes CPUIDFMT to BASIC as well), and when ARCHLVL z/Arch is set, it is then changed back to the default LPARNUM 1 again (which also automatically changes the CPUIDFMT back to 0 as well), but only when needed.

That is to say, the automatic switching to and from LPARNUM BASIC (and CPUIDFMT BASIC) and LPARNUM 1 (and CPUIDFMT 0) only occurs when needed (and only when switching between S/370 and z/Arch). If LPARNUM (and CPUIDFMT) are already set to the expected values they will not be changed. When ARCHLVL ESA/390 is set however, LPARNUM and CPUIDFMT are never changed from their current values.

This new behavior was introduced to eliminate the "surprise" factor that would otherwise occur when, if the LPARNUM remained set to 1 (or some other number), not doing so causes the STIDP (Store CPU ID) instruction to be stored in an otherwise unexpected format. In most all situations when a Hercules user sets ARCHLVL S/370, they are truly expecting the LPARNUM and CPUIDFMT to be set to BASIC such that the STIDP instruction then stores the CPU ID in the expected format.

For the unusual case where users actually do want to run a System/370 Operating System within an LPAR, you will need to manually re-set your LPARNUM and CPUIDFMT values back to their numeric values after setting ARCHLVL S/370. That is to say, one should always follow their ARCHLVL S/370 statement with a LPARNUM n|nn statement (and CPUIDFMT statement too if needed) if LPAR mode for S/370 is truly desired.

More architecturally compliant Channel Subsystem implementation

Hercules 4.x Hyperion's channel subsystem implementation now more closely adheres to published and unpublished architectural specifications. It does not precisely adhere to the complete specification but it does adhere much more closely than ever before (and definitely more closely than the legacy implementation still used in the older spinhawk 3.xx series of Hercules).

If you experience any anomalies in the behavior of your guest operating system, verify that you are using architecurally valid/correct configuration settings that your guest operating system expects.

Pay particular attention to your ARCHLVL, LPARNUM, CPUIDFMT, CPUMODEL, CPUSERIAL, CPUVERID, MODEL, PLANT and MANUFACTURER values since they typically have a direct impact on how certain guest operating systems behave.

Configuration file statements and panel commands handled identically

Most configuration file statements are now available as and processed as panel commands. Most valid configuration file statements may now also be entered as a panel command. Most panel commands are now also allowed as configuration file statements. See the documentation for full details.

Improved ECPSVM Support

Hyperion 4.x now provides a mostly complete ECPSVM CP/VM Assist implementation. While still not 100% complete, support for many new assists has been added and several bugs have been fixed. Refer to the README.ECPSVM document for more detailed information.

Integrated Rexx support

Rexx support was first added to Hercules by Jan Jaeger in 2010 and has been gradually enhanced over the years by both Enrico Sorichetti and Jan Jaeger as well as a few other people too.

If you have Rexx installed on your host and Hercules is built with the Rexx build option (the default for the SDL version of Hyperion), then Rexx scripts can be run directly from within the Hercules environment (i.e. directly from the Hercules HMC command line via the Hercules exec command).

Rexx scripts, when run within Hercules via the 'exec' command, can Address the HERCULES enviroment allowing you to issue Hercules commands and retrieve the results via the builtin 'AWSCMD' Rexx function call.

For more information please refer to the new Hercules Integrated Rexx Support web page.

SHCMDOPT defaults change

The defaults for the SHCMDOPT have changed. The old defaults were ENABLE DIAG8. The new defaults are DISABLE NODIAG8. This was done for security reasons.

SHCMDOPT option also controls Rexx EXEC command

The ENABLE and DISABLE option of the SHCMDOPT command now also controls the Rexx exec command as well as the sh command. That is to say, the Rexx exec command is now properly treated as a host shell command. Thus, enabling or disabling the execution of host shell commands via the SHCMDOPT option now also enables or disables execution of the exec command as well. This was done for security reasons.

Change to DIAG8CMD ECHO behavior

The behavior of the DIAG8CMD command's ECHO and NOECHO options has changed. Previosuly the echo/noecho option had a a direct impact on the data that was placed into the Diagnose 8 instruction's response buffer. This has been fixed so that now it does not.

Previously, specifying the ECHO option caused audit trail messages HHC01950I and HHC01603I to also appear in the instruction's response buffer, whereas now only the command's actual output is placed into the response buffer. The ECHO option now properly controls only the issuing of the HHC01950I and HHC01603I audit messages to both the panel and hardcopy logfile, but does not otherwise impact in any way what is placed into the instruction's response buffer, as was the original intent for this option.

3088, CTCI-W32, CTCT and VMNET support dropped

Support for 3088, CTCI-W32, CTCT and VMNET devices has been dropped. 3088 Channel-To-Channel Adapter support (which was the original intent of CTCT) has instead been replaced with Peter Jansen's vastly improved Enhanced Channel-To-Channel (CTCE) device support, which provides true Extended mode Channel-To-Channel Adapter capabilities, allowing you to use GRS to connect multiple Hercules instances together in a type of Sysplex.

CAPPING support removed

Previous versions of Hercules supported a "CAPPING" configuration statement designed to purposely reduce performance to ensure that your MIPS rate never exceeded the specified value. This functionality has now been removed.

New NETDEV configuration file statement

A new NETDEV configuration file statement is now supported to allow you to specify which host network adapter should be used by default for Hercules communications devices. It only represents a default and can be overridden on the device statements themselves. Refer to the documentation for the "NETDEV" statement for more information.

New "t+-" Automatic Tracing command

A new "t+-" (tee-plus-minus) Automatic Tracing command has been created that may prove to be helpful in capturing guest issues that occur very early in the guest's IPL sequence. Refer to the "help t+-" help display for more information.

Default tape AUTOINIT option is now ON (enabled)

The AUTOINIT option controls whether device files for emulated tape volumes should be automatically created or not if they do not exist. The previous default was OFF. The new default is ON.

Diagnose X'F14' support removed

Hercules's Diagnose X'F14' functionality was designed to allow a Hercules guest to call into any host system DLL (Dynamic Link Library). Since its use (dubius to begin with) was determined to be a potential security risk (and the code didn't appear to be used anywhere anyway), support for it was removed.

System/370/390 Vector Facility instructions are now enabled by default

Hercules has always supported the System/370 and System/390 Vector Facility set of instructions but support for them was never enabled by default. This has now been corrected.

Hercules S/370 Instruction Extension Facility

A new Hercules S/370 Instruction Extension Facility has been implemented to replace the functionality previously provided by the "s37x.dll" dynamically loadable module. Please refer to the README.S37X document for more information.

Release notes for release 3.06

Tape "AUTOMOUNT" support

Starting with Hercules version 3.06 a new AUTOMOUNT option is available that allows guest operating systems to directly mount, unmount and query tape device filenames for themselves, without any intervention on the part of the Hercules operator.

Automount support is enabled via the AUTOMOUNT configuration file statement.

An example guest automount program for VSE called "TMOUNT" is provided in the util subdirectory of the Hercules source code distribution.

Briefly, the 0x4B (Set Diagnose) CCW is used to mount (or unmount) a file onto a tape drive, and the 0xE4 (Sense Id) CCW opcode is used to query the name of the currently mounted file.

For mounts, the 0x4B CCW specifies the filename of the file to be mounted onto the drive. The file MUST reside in the specified AUTOMOUNT directory or the automount request will be rejected. To unmount the currently mounted file, simply do a mount of the special filename "OFFLINE".

To query the name of the currently mounted file, the 0xE4 CCW is used. Note however that the 0xE4 (Sense Id) CCW opcode cannot be used by itself since the drive may also already natively support the Sense Id CCW opcode. Instead, it must be preceded by (command-chained from) a 0x4B CCW with a data transfer length of one byte. The following 0xE4 command is the one that then specifies the i/o buffer and buffer length of where the query function is to place the device's currently mounted host filename.

In summary:

        MOUNT:      X'4B', filename, X'20', length

        UNMOUNT:    (same thing but use filename "OFFLINE" instead)

        QUERY:      X'4B', buffer, X'60', 1
                    X'E4', buffer, X'20', buffersize

Again please refer to the provided TMOUNT program for a simple example of how automount support might be implmented on a guest operating system.

Release notes for release 3.05

Use 'startgui' if starting GUI program via 'sh' command

The 'conspawn' utility used to process 'sh' commands now recognizes a specially designed keyword "startgui" to accomodate automatic starting of Windows GUI applications via the .RC file or panel command-line.

If the first word following 'sh' is "startgui", then the "ShellExecute" API is used to start the requested program rather than the 'system()' API as otherwise.

The "startgui" keyword must always be used to start any Windows program that is not a command-line program. Hercules, itself being a command-line program, monitors the 'stderr' and 'stdout' pipes so it can log messages received from either pipe directly to the Hercules console log. Programs such as notepad however, because they are not command-line programs, do not use stdout/stderr thus causing Hercules to hang if "start" is used instead.

This rule applies regardless of how Hercules itself is started (i.e. via HercGUI or directly via the command-line) and regardless of whether the "start" command is wrapped in a batch file or not. That is to say, using the Hercules command "sh batchfile foobar" to start your batch file which then does "start notepad %1" still causes Hercules to hang until notepad first exits. Instead, you should ask Hercules to "sh startgui batchfile", and let the batchfile start notepad however it wants.

Real SCSI tape drive support

Real SCSI tape drives used with Hercules must provide a certain minimum set is "IBM compatible" support in their SCSI command set/behavior in order to work properly with Hercules. Furthermore, the Hercules device-type used on your device statement in your Hercules configuration file should match the the level of support/behavior that they provide.

For example, all SCSI tape drives used with Hercules must provide the ability to set variable-length blocks as well as long erase-gaps (long erase-gaps allows new data to be appended to the end of existing data without having to write a tape-mark to separate the new data from the old existing data first).

Another example would be using a model of SCSI tape drive that happens to report physical block-id values in a format different from the way real IBM mainframe tape drives report them. 3480/3490 tape drives for example report their block-ids (used in Read Block Id and Locate CCWs) in a very specific format wherein bits 1-7 of the high-order byte of the reported 4-byte block- id indicates the tape's physical "segment" location of where the lower 22- bit block number is physically located on the tape. (The block-id segment is used to allow the tape drive to quickly position itself to the approximate location where the desired block acually resides on the tape and thus allows high-speed positioning for the Locate CCW).

If the model of SCSI tape drive you are actually using with Hercules does not use this same block-id format however, then it cannot be used with Hercules as a 3480 or 3490 model tape drive with specially defined options.

If the SCSI tape drive you are using reports its block-ids using a 32-bit block-id value (the same way a 3590 model tape drive does), then similarly, it should be defined to Hercules as a model 3590 device-type as well (since that is how it is behaving with respect the format of the returned blockid values). It you wish to define it in Hercules as a model 3480 or 3490, then you will need to use specially defined options before it will work properly as the model drive you wish it to emulate.

With all that being said, it should be noted that PARTIAL support for 3590 device emulation is possible with judicious use the aforementioned special options, but full/complete 3590 support is unlikely due to lack of publicly available documentation. Details regarding 3590 CCW handling is restricted (confidential) IBM proprietary information, and is not normally available outside of IBM. Not long ago IBM was required by US law to publish such information, but unfortunately for Hercules, such is no longer the case.

For further information regarding use of SCSI attached tape drives with Hercules and their associated specially defined options, please refer to the section on SCSI tape drives in the Hercules's Device Configuration documentation.

Internal thread priorities changed on Windows for platform consistency

In order to ensure proper functioning of the TOD clock with older versions of guest operating systems, the default values of Hercules's internal thread priorities for the Windows version of Hercules were changed to be identical to those used by all other supported platforms. Originally, the default thread priority values for the Windows version of Hercules were:

              ***  3.04 (and prior) Default Priorities  ***

              Thread    Priority           Meaning
              -------   --------   ------------------------
              HERCPRIO     0        Normal Process priority

              DEVPRIO     -8        Above Normal  Thread priority
              TODPRIO      0        Normal        Thread priority
              CPUPRIO      0        Normal        Thread priority

which caused acceptable performance/functioning on most, but not all, guest operating systems. Beginning with version 3.05 however, the prioriries now default to:

              ***  3.05 (and later) Default  Priorities  ***

              Thread    Priority           Meaning
              -------   --------   ------------------------
              HERCPRIO     0        Normal Process priority

              TODPRIO    -20        Time Critical  Thread priority
              DEVPRIO      8        Below Normal   Thread priority
              CPUPRIO     15        Lowest         Thread priority

which may on more modern guest operating systems (which handle the TOD clock differently than do older less sophticated versions) cause a slight decrease in overall performance. If such is the case, the original default priorities (and thus the original behavior) can be obtained via addition of appropriate HERCPRIO, TODPRIO, DEVPRIO and CPUPRIO control file statements with values identical to the original version 3.04 default values.

Configuration file usability enhancements and Automatic Operator facility

Additional configuration file usability enhancements have been implemented in the form of a new 'INCLUDE' (and associated 'IGNORE') statement, allowing configuration files to "include" statements from a different named file.

Additonally, a new "enhanced" symbolic substitution syntax is now also supported. Refer to the Hercules "Configuration File" documentation for further information and details.

A rather nifty "Automatic Operator" facility has also been implemented in the current release as well. While not exactly a "configuration file usability enhancement", it is nevertheless something we hope might prove to be more useful/helpful to our many users. See the "README.HAO" document for more information.

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

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.


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


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.