RE: DFSMShsm & 3592 carts & money
- From: Terry.Traylor@xxxxxxxxxxxx (Traylor, Terry)
- Date: 11 Jan 2006 08:13:20 -0800
Shane,
Consider implementing HSM Auxiliary Address Space to separate daily
functions from recall. This way you can have HSM performing recalls at
a higher service class while the daily functions run at a lower service
class. See documentation excerpts below.
HSM Multiple Address Space
Multiple Address Space Support
Each Address Space runs as unique DFSMShsm host
Up to 39 DFSMShsm hosts per HSMplex
Benefits
Different hosts can be assigned different functions
Different hosts can be assigned different Workload Manager (WLM)
Velocity Goals
Reduces SYSZTIOT contention for DASD/Tape allocations
Improved availability
Increased Tasking Levels of most functions in DFSMShsm
MAIN versus AUX hosts
HOSTMODE=MAIN
* One per system image
* Handles implicit recalls, HSEND commands, batch and TSO end user
requests
* Manages ABARS secondary address spaces
* This is the default HOSTMODE
HOSTMODE=AUX
* Multiple per system image
* Scheduled Automatic Functions
* PSM, SSM, Interval
* Autobackup
* Autodump
* Explicit requests using Console Commands, Netview or EMCS
The primary host can be either a MAIN or an AUX host. Having an AUX
host designated as the primary host reduces contention between its
"level functions" and the responsibilities unique to the MAIN host, such
as recalls and deletes.
There are several advantages to starting more than one DFSMShsm host in
a 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.
Terry Traylor
charlesSCHWAB
TIS Mainframe Storage Management
tis-mfs-storage
(602) 977-5154
WARNING: All email sent to or from this address will be received by the
Charles Schwab corporate e-mail system and is subject to archival and
review by someone other than the recipient.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@xxxxxxxxxxxx
Behalf Of ibm-main
Sent: Wednesday, January 11, 2006 12:56 AM
To: IBM-MAIN@xxxxxxxxxxx
Subject: Re: DFSMShsm & 3592 carts & money
From: "Gibney, Dave"
: Run it a single purpose z/OS.e LPAR :) I wish I had this option.
:
: I run HSM on a fairly low priority class. When we're CPU tight I
drop
: it even further.
: But, you are right, it runs all the time and recycle and tapecopy
can
: take hours or even days. And our DR is mostly hypothetical :(
HSM load is being pushed to SAP R3 LPAR(s) where the licensing is also
advantageous.
Recall response has high visibility, and is *enormously* impacted by the
TMM traffic. As are all the other HSM functions.
I've been pushing for a VTS solution for years.
Shane ...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Prev by Date: Re: LPAR config and short engine question
- Next by Date: DB2 Data Sharing
- Previous by thread: RE: DFSMShsm & 3592 carts & money
- Next by thread: RE: DFSMShsm & 3592 carts & money
- Index(es):
Relevant Pages
|
