9. Shared Device Support
9.1 Basics
Shared Device Support (see also "General Information" manual) allows multiple Hercules instances to
share devices. The device will be local to one Hercules instance and remote to all other Hercules in-
stances. The local instance is the server for that device and the remote instances are the clients. It is
possible that each instance acts as both a client and a server. If a local instance declares a device as
remote on another instance and on this remote instance the device is defined again as remote on a third
instance, then the original instance will have to hop through this second instance to get to the real device.
It is not necessary to IPL an operating system on the device server. Any number of Hercules instances
can act as a server in a "HERCPLEX".
When "SHRDPORT" is specified in the Hercules configuration the thread "shared_server" is started at the
end of Hercules initialization. If Shared Device Support is requested on a device statement then the Her-
cules instances cannot initialize these devices until the server is started on each system. In this case the
device trying to access a server gets the 'connecting' bit set on in the DEVBLK and the device still needs
to initialize. After the shared server is started a thread is attached for each device that is connecting to
complete the connection (the device init handler).
9.2 Caching
Cached records (i.e. CKD tracks or FBA blocks) are kept independently on both the client and server
sides. Whenever the client issues a START request to initiate a channel program, the server will return a
list of records to purge from the clients cache. These will have been updated by other clients since the
last START request. If the list is too large the server will indicate that the client should purge all records
for the device.
9.3 Compression
Data that would normally be transferred uncompressed between the client and the host can optionally be
compressed by specifying the "COMP=n" keyword on the device configuration statement (see below) or
on the attach command. The value n of the "COMP=n" keyword is the zlib compression parameter which
must be a number between 1 and 9. A value closer to 1 means less compression but less processor time
to perform the compression. A value closer to 9 means the data is compressed more but also more pro-
cessor time is required to compress the data.
If the server is on localhost then you should not specify compression. Otherwise you are just stealing
processor time from Hercules to facilitate compression/decompression. If the server is on a local network
then a low value such as 1, 2 or 3 is recommended. There is a tradeoff curve, attempting to trade CPU
cycles for network traffic to derive an optimal throughput.
If the devices on the server are compressed devices (i.e. CCKD or CFBA) then the records (track images
or block groups) may be transferred compressed regardless of the "COMP=n" settings. This depends on
whether the client supports the compression type (zlib or bzip2) of the record on the server and whether
the record is actually compressed in the server cache.
An example may help to explain this: Suppose on the client that you execute one or more channel pro-
grams to read a record on a CKD track, update a record on the same track, and then read another (or the
same) record on the track. For the first read the server will read the track image and pass it to the client
as it was originally compressed in the file. To update a portion of the track image the server must uncom-
press the track image so data in it can be updated. When the client next reads from the track image the
track image is uncompressed.
