Hercules Version 3: Technical Support


Paid Support

Hercules does not have any official (formal) paid support in place...

...HOWEVER...

I'm sure if you ask the group whether or not there's anyone out there willing to provide it, you'll probably get more than one response.     ;-)

I know for a fact that at least one person is already providing Hercules Technical Support on a paid basis, and as I said, I'm sure there are probably others out there who are either already doing it, or at least willing to do it, too. All you have to do is ask (any of the people involved with Hercules (users and/or developers)) and I'm sure more than one would be willing to provide it to you for a reasonable agreed-upon fee.

Your best approach for obtaining fee-paid tecnical support for Hercules would be to post an inquiry to the main Hercules-390 forum (see next section below) and simply ask whether anyone out there would be willing to provide it. As I said, I'm sure there are probably many people out there who would be willing to do so for the right price.


Free Support

Since Hercules is an Open Source product owned by no one in particular and copyrighted by many (lots of very sharp people have contributed over the years to Hercules's success), there doesn't exist any type of official "Technical Support Department" within any type of company or anything (like there usually is for closed-source products).

Instead, as with most Open Source products, there simply exists a dedicated group of individuals and enthusiasts who are willing to put in their spare time helping others with whatever problems and/or questions others may have regarding it. This dedicated group of Hercules enthusiasts is known as "our user community", and it honstly does, in this author's o=localhost:1234 HERCRDR file3.txt file4.txt HERCRDR override:5678 filefive.txt HERCRDR 192.168.0.1:5678 666.txt 777.txt 888.txt 999.txt Returns: -1 unclassified error 0 file(s) successfully submitted 1 no route to host (bad sock_spec or connection refused) 2 timeout value exceeded while trying to connect 3 transmission error (e.g. connection prematurely closed) 4 file not found (or other file error)

How to submit jobs directly from SPF/PC

If you are lucky enough to have a copy of SPF/PC Version 4 or SPF/Pro (produced by CTC but unfortunately no longer available), then you can capture the authentic mainframe experience by submitting jobs directly from your edit session. The SUB command can be implemented by means of a REXX macro, such as this one provided by Volker Bandke:


/* +----------------------------- REXX -----------------------------+ */
/*                                                                    */
/*      Name: D:\APPS\SPFPRO\REXX\USER\SUB.SPF                        */
/*                                                                    */
/*      Type: SPF edit macro                                          */
/*                                                                    */
/*      Desc: submit JCL to MVS 3.8                                   */
/*                                                                    */
/*      Creation date: 24 Aug 1999, creation time: 18:49:40           */
/*                                                                    */
/*      Author: (c) Volker Bandke                                     */
/*                                                                    */
/* +----------------------------------------------------------------+ */
'isredit macro (p1 p2 p3 p4 p5 p6 p7 p8 p9)'
"ISREDIT (member) = MEMBER"
"ISPEXEC CONTROL ERRORS CANCEL"
parse upper var member file '.' ext
do
'ISREDIT REPLACE' $$$$$$$$.SPF '.ZF .ZL'
ADDRESS "CMD" "HERCRDR 192.168.1.102:3505 $$$$$$$$.SPF"
zedsmsg = 'File submitted'
zedlmsg = 'The member '||member||' has been submitted to MVS'
'ispexec setmsg msg(isrz000)'
ADDRESS "CMD" "DELETE $$$$$$$$.SPF"
end
EXIT 0

Submitting jobs from Unix

Using a Perl script

Malcolm Beattie has provided a simple Perl script which can submit jobs using either TCP/IP or Unix Domain Sockets.

The script is invoked using one of the following command formats:
hercsub 192.168.1.102:3505 dummy.jcl
hercsub /tmp/hercrdr.00C dummy jcl

Here is the sample script:


============== hercsub ================
#!/usr/bin/perl
use Socket;
use IO::Socket::UNIX;
use IO::Socket::INET;

if (@ARGV < 1) {
  print STDERR "Usage: hercsub socket_spec [job]\n";
  exit 2;
}

my $spec = shift @ARGV;
my $sock;

if ($spec =~ m{^/}) {
  $sock = IO::Socket::UNIX->new(Peer => $spec);
} else {
  $sock = IO::Socket::INET->new(PeerAddr => $spec);
}

die "Failed to connect to socket $spec: $!\n" unless defined($sock);

while (<>) {
  print $sock $_;
}
========== end of hercsub =============

Using the netcat program

The netcat (nc) program can also be used to submit files to a Hercules reader via TCP/IP.

Install netcat (which is useful for innumerable other things as well) and use:
nc -w1 localhost 1234 < dummy.jcl

For more information, type man nc.


Last updated 3 October 2003 ./usr/share/hercules/hercrnot.html0000644000000000000000000002157410357104474016166 0ustar rootroot Hercules Version 3: Release Notes and Known Issues

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 dy