8.194 YROFFSET (Set TOD clock offset from actual date)

8.194.1 Function

The YROFFSET command specifies the number of years the TOD clock is offset from the actual date.
Positive numbers will move the clock forward in time while negative numbers will move it backward. A
common value for non-Y2K-compliant operating systems is YROFFSET -28 which has the advantage that
the day of the week and the presence or absence of February 29 is the same as the current year.

8.194.2 Syntax

Descriptive

+years -years

Diagram

+years ¬¬¬§¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬ÊÍ

-years

8.194.3 Parameter

+years

Specifies the number of years the TOD clock is offset positive from the actual date.
This value may not be specified as greater than +/-142 years, the total range of the
TOD clock. Specifying a value that causes the computed TOD clock year to be
more than 142 years later than SYSEPOCH will produce unexpected results.

-years

Specifies the number of years the TOD clock is offset positive from the actual date.
This value may not be specified as greater than +/-142 years, the total range of the
TOD clock. Specifying a value that causes the computed TOD clock year to be
earlier than the value of SYSEPOCH will produce unexpected results.

8.194.4 Examples

Example 1:

Specify 28 years to offset the TOD clock from the actual date.

HHC00013I Herc command: 'yroffset -28'

HHC02204I yroffset set to -28

Figure 347: YROFFSET command

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.