DOWN or when the user application is aborted.
NOTES:
1. All open requests to the Core Server will call the Gatekeeping Service open API
(gk_Open). This includes opens that end up invoking a stage.
2. Any stage call that is invoked on behalf of open will NOT call the Gatekeeping Service
stage API (gk_Stage). (e.g. The ftp site stage <filename> command will use the
Gatekeeping Service open API, gk_Open, rather than the Gatekeeping Service stage API,
gk_Stage.)
3. Direct calls to stage (hpss_Stage, hpss_StageCallBack) will call the Gatekeeping Service
stage API (gk_Stage).
4. If the site is monitoring Authorized Caller requests then the site policy interface won't be
allowed to deny or delay these requests, however it will still be allowed to monitor these
requests. For example, if a site is monitoring Authorized Caller and Open requests, then
the site gk_site_Open interface will be called for open requests f rom users and the
gk_site_OpenStats interface will be called for open requests due an authori zed caller
request (e.g. migration by the MPS). The site policy can NOT return an error for the open
due to migration, however it can keep track of the count of opens by authorized callers to
possibly be used in determining policy for open requests by regular users. Authorized
Caller requests are determined by the Core Server and are requests for special servi ces for
MPS and XFS. These services rely on timely responses, thus gatekeeping is not allowed to
deny or delay these special types of requests.
5. The Client API uses the environment variable HPSS_GKTOTAL_DELAY to place a
maximum limit on the number of seconds a call will delay because of HPSS_ERETRY
status codes returned from the Gatekeeper. See Section 13.1: Client API Configurati on of
the HPSS Management Guide for more information.
Refer to HPSS Programmer's Reference, Volume 1 for further specifications and guidelines on
implementing the Site Interfaces.
3.10. Stor age Characteristics Cons iderations
This section defines key concepts of HPSS storage and the impact the concepts have on HPSS
configuration and operation. These concepts, in addition to the policie s described above, have a
significant impact on the usability of HPSS.
Before an HPSS system can be used, the administrator must create a description of how the s ystem is
to be viewed by the HPSS software. This process consists of learning as much about the intende d and
desired usage of the system as possible from the HPSS users and then using this information to
determine HPSS hardware requirements and the configuration of the hardware to provide the desired
performance. The process of organizing the available hardware into a desired configurati on results in
the creation of a number of HPSS metadata objects. The primary objects created are classes of
service, storage hierarchies, and storage classes.
A Storage Class is used by HPSS to define the basic characteristics of storage media. The se
characteristics include the media type (the make and model), the media block size (the length of e ach
basic block of data on the media), the transfer rate, and the size of media volumes. These are the
physical characteristics of the media. Individual media volumes described in a Storage Class are
called Physical Volumes (PVs) in HPSS.
Storage Classes also define the way in which Physical Volumes are grouped to form Virtual Volumes
HPSS Installation Guide July 2008
Release 6.2 (Revision 2.0) 101