This topic describes the capabilities and functions of DFSMShsm
and the uses for DFSMShsm control data sets. When you map these functions
against the storage management needs of your installation, you might
want to allocate certain subsets of functions to specific DFSMShsm
hosts. In this context, a host is a DFSMShsm address space that performs
automatic functions, such as migration. Secondary address spaces that
perform aggregate backups and recovery (ABARS) belong to the main
host and are not themselves considered hosts.
One z/OS® image can have
more than one DFSMShsm host. In a sysplex, multiple z/OS images can each have one or more hosts, all
sharing the same set of control data sets (an HSMplex).
There are two possible modes of host activity that you can specify
at startup time for any host: HOSTMODE=MAIN (the default) and HOSTMODE=AUX.
- HOSTMODE=MAIN
- This (main) DFSMShsm host
- Processes implicit requests, such as recalls, or deletes migrated
data sets, from user address spaces
- Processes explicit commands from TSO, such as HSENDCMD and HBACKDS,
as well as requests from batch jobs, such as ARCINBAK
- Manages ABARS secondary address spaces
- Allows MODIFY commands from a console or from an HSM Monitor/Tuner
(HMT)
- Can run automatic backup, dump, and space management
- HOSTMODE=AUX
- This (auxiliary) DFSMShsm host
- Allows MODIFY commands from a console or from an HSM Monitor/Tuner
(HMT)
- Can run automatic backup, dump, or space management
In addition, another keyword PRIMARY identifies the primary host
in an HSMplex.
Rule: Within one z/OS image, all started hosts must be running DFSMShsm
V2R10, or a later release.
Note: - Up to 39 DFSMShsm hosts can be started concurrently in an HSMplex.
- Within one z/OS image,
any started host running on V2R10 or subsequent releases can share
data with any host running on prior releases in the same HSMplex,
but from a different z/OS image.
- An HSMplex can consist of both single and multiple DFSMShsm-host
environments.
There are several advantages to starting more than one DFSMShsm
host in an z/OS image:
- Multiple DFSMShsm address spaces mean less work per address space
and less contention between functions, because each SYSZTIOT resource
serializes only functions in its address space.
- Multiple DFSMShsm address spaces mean that each address space
that is doing some part of DFSMShsm’s work can have an appropriate MVS™ dispatching priority for that
type of work.
- Multiple DFSMShsm address spaces provide a larger number of tasks
that perform any given DFSMShsm function; for example, migration.
- DFSMShsm functions that operate in more than one address space
allow more MIPs that are allocated to DFSMShsm functions.
Within a single z/OS image,
you can have one of the following combinations, all sharing the same
set of control data sets:
- One main host
- One main host and one or more auxiliary hosts
Note: Because you can start up or shut down hosts in any
order, another permitted (but normally temporary) combination is one
or more auxiliary hosts without a main host.