AMASS, DataMgr, EMASS, FileServ, and VolServ are either trademarks or registered
trademarks of ADIC, Advanced Digital Information Corporation. DAS is a trademark of
Grau, an ADIC subsidiary. All other product names and identifications are trademarks or
registered trademarks of their respective manufacturers.
Use, duplication, or disclosure of either the software or documentation is subject to
restrictions set forth by the U.S. Government in FAR 52.227-19(c)(2) and subparagraph
(c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 52.2277013 and/or in similar or following clauses in the FAR, DoD, or NASA FAR Supplement.
Technical Assistance
ADIC Technical Assistance Center:
•In the USA and Canada, call 1-800-827-3822.
•Outside the USA and Canada, call 303-874-0188 or toll-free 00800-9999-3822.
•Send e-mail to: support@adic.com.
Documentation
Although the material contained herein has been carefully reviewed, ADIC does not
warrant it to be free of errors or omissions. We reserve the right to make corrections,
updates, revisions, or changes to the information contained herein.
•Send e-mail to: techdocs@adic.com
READER COMMENT FORM
ADIC includes this Form in an effort to provide the best possible documentation to our
customers. Please take a few moments to mail or FAX your response to:
ADIC USA
Tel.: +1 303-705-3900
Fax: +1-303-792-2465
ATAC: 1-800-827-3822
http://www.adic.com
ADIC Europe
ZAC des Basses Auges
1, rue Alfred de Vigny
78112 Fourqueux, France
Tel.: +33.1.3087.5300
Fax: +33.1.3087.5301
Information was complete.AgreeDisagree
Information was easy to find.AgreeDisagree
Information was easy to follow.AgreeDisagree
Is there anything you especially like or dislike about the organization, presentation,
or writing in this manual?_______________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
Book TitleDocument Number
Customer NameTelephone
E-mail Address
Company Name
Address
City, State, Zip
This book describes the VolServ application programming
interface (API). The API consists of functions, iterators,
symbolic names, type definitions, and data structures.
Using the API provides the programmer with the ability to
directly manipulate VolServ file system metadata and media.
This book is written for programmers who are creating or
modifying an application that requires tight control over data in
the file system managed by VolServ
This book contains the following chapters:
Chapter 1: Getting Started — Describes API types and
naming conventions, dispatch routines and global
parameters,.and error handling.
Chapter 2:Functions — Alphabetical list of API function
calls.
Appendix A: Valid Status Fields — A matrix shows which
status fields are valid for each command.
Appendix B: Error Codes.
Appendix C: Mount Example.
6-01004-01 Rev APrefaceP-3
API Guide
Conventions
The conventions used throughout the VolServ technical books
are listed below:
ConventionExample
Screen text, file names, program names, and
commands are in Courier font.
The root prompt is shown as a number
symbol.
What you should type in is shown in Courier bold font.
Site-specific variables are in a Times italics
font.
A backward slash ( \ ) denotes the input is
continued onto the next line; the printed page
is just not wide enough to accommodate the
line.
Pressing <Return> after each command is
assumed.
Request to add a new volume:
Volume group will be “20”
Volume position will be “A123”.
# su root
vsarchiveqry
tar -xvf tapedevicename
#
remsh nodename -n dd if=/dev \
/tapedevicename/bs=20b | tar xvfb \
- 20
(You should type the entire command witho ut
the backward slash.)
A menu name with an arrow refers to a
sequence of menus.
P-4Preface6-01004-01 Rev A
Config-->MediaType-->Redefine
API Guide
Preface
Books
The books described below are part of the technical
documentation set, and are shipped on CD along with the
VolServ software:
Overview
Provides an ov erview of VolServ . Co ntains a
glossary.
Installing VolServ
Describes server requirements, installation
instructions, troubleshooting procedures,
and configuration parameters.
Using the VolServ GUI
Describes how to perform system
administrative tasks using th e graphical user
interface.
API Guide
Provides a list of API functions.
Administrative Tasks
Describes how to perform system
administrative tasks using VolServ
commands.
Command Reference
Contains a list of VolServ commands
Error Messages
Provides corrective action f or system log
errors.
Quick Reference Card
Summarizes commands.
Online Books
The documentation CD contains VolServ book files and
requires the Adobe® Acrobat® Reader to view the
accompanying electronic documentation. The Reader allows
you to view and navigate the electronic documentation files yet
preserves the page design and graphics from the printed books.
6-01004-01 Rev APrefaceP-5
API Guide
Related
Publications
Related PublicationsDescription
“Release Notes”For each version of VolServ, the “Release Notes” contain:
“Product Alerts”Informs customers of technical problems and solutions.
“Product Bulletins”Conveys technical information—not problems—to
The publications described in the table below are created and
distributed on an as-needed basis.
• Summary of enhancements.
• Describes:
- Fixed problems.
- Known problems.
- Installation and configuration issues.
•Lists:
- Operating system patches.
- System requirements.
customers.
Contact
Publications
Department
Secured Web
Site
To make corrections or to comment on VolServ publications,
please contact Software Technical Publications at our e-mail
address: techdocs@adic.com.
To receive access to the secured site on our home page containing technical product information (Release Notes, Product
Alerts, Product Bulletins, FAQs), visit http://partners.adic.com/
and follow the password request procedure. In return, ADIC
will send you instructions and a password.
Naming conventions.
Global parameters.
Error handling.
API functions.2
Valid staus fields.A
Error codes.B
Mount example .C
Refer To
Chapter
1
1-2Getting Started6-01004-01 Rev A
API Guide
API Directory
Structure
All files necessary for client interface to the VolServ software
are contained in the volserv/vsapi directory by default.
However, the installer may choose a different location during
execution of the installation script, except that the vsapi
directory is always appended to the specified location. Refer to
Installing VolServ for more information.
Client software may use the API to interface to VolServ
software. Clients are responsible for creating and linking their
own applications to the appropriate API header and library files.
The default API directory structure is shown in follo wing f igure
and defined in the table below.
/volserv/vsapi
/lib/include/man
/util
Getting Started
DirectoryContents
includeContains six header files used by API library.
libContains the API library.
manContains man pages for all VolServ API library
functions.
6-01004-01 Rev AGetting Started1-3
API Guide
DirectoryContents
utilContains various utilities used to clean up
configuration problems, save copies of
VolServ software logs, change the number
sequence of label pattern generation, or to
perform maintenance.
1-4Getting Started6-01004-01 Rev A
API Guide
Application
Program
Interface
Extensible
The VolServ Application Programmer’s Interface (API) allows
a programmer to interface with VolServ. The VolServ API is a
set of ‘C’ library routines, written for a UNIX system, that the
client software uses to communicate with VolServ.
Getting Started
The VolServ API allows the user to send commands, receive
command statuses, and receive VolServ MediaClass
notifications.
The VolServ API interface uses the VolServ Remote Procedure
Call (RPC) interface to communicate with VolServ. All features
available in the VolServ RPC interface are supported in the
VolServ API.
The VolServ API is extensible. An y change in the VolServ RPC
interface is handled by the API. Thus, the client program does
not have to be updated to maintain compatibility when the
VolServ RPC interface is modified. The client program is
updated only to use new VolServ features.
Consistent
Portable
Flexible
6-01004-01 Rev AGetting Started1-5
The VolServ API is consistent. All commands and their related
functions have the same interface and operate similarly.
The VolServ API is designed to be highly portable to other
platforms. (If the client program is ported to a platform
supported by the VolServ API, the client program does not need
to be concerned with VolServ connectivity.)
The VolServ API is flexible. A client program can send a
command to VolServ and either
API Guide
•Wait for final status before continuing processing
(synchronous processing).
•Or, continue processing after VolServ has received the
command. The client software receives the command’s
status at a later time (asynchronous processing).
A client program can also mix these operation modes.
1-6Getting Started6-01004-01 Rev A
API Guide
Client
Interface
Summary
The figure below illustrates th e communication paths supported
by VolServ:
Clients using
Commands in
Client scripts
Client Software
using API
Client Software
using
RPC/XDR protocol
Command
Line
Interface
API
RPC
RPC
RPC
VolServ
The following outline shows the flow of information through
these communication paths.
•Clients using the Command Line Interface and Client
Scripts.
Getting Started
-The client-to-client script issues a request from the
command line.
-The CLI software performs first-lev el v alidation on the
request and forwards the request to the API software.
-The API software serializes the request into XDR
format and transmits the request to VolServ using the
RPC/XDR protocol.
-VolServ returns data and/or status to the API software
using the RPC/XDR protocol.
6-01004-01 Rev AGetting Started1-7
API Guide
-The API software deserializes the data and/or status
from the XDR formats and forwards the information to
the CLI software.
-The CLI software formats the data and/or status and
forwards this information to the client that issued the
request.
-The client/client script processes the data and/or status
returned by the CLI software.
•Client software using the API.
-The client software issues a request to the API
software by calling an API function/routine.
-The API software serializes the request into XDR
format and transmits the request to VolServ using the
RPC/XDR protocol.
-VolServ returns data and/or status to the API software
using the RPC/XDR protocol.
-The API software deserializes the data and/or status
from the XDR formats and forwards the information to
the client software.
-The client software processes the data and/or status
returned by the API software.
•Client software using the RPC/XDR protocol.
-The client software serializes the request into XDR
format and transmits the request to VolServ using the
RPC/XDR protocol.
-VolServ returns data and/or status to the client
software using the RPC/XDR protocol.
-The client software deserializes the information from
the XDR format and processes the returned
information.
1-8Getting Started6-01004-01 Rev A
API Guide
Unsolicited
Communication
VolServ can generate unsolicited communication after specific
client and operator commands. This unsolicited communication
is referred to in some VolServ documentation as “Callbacks” or
“Notifications.”
Getting Started
Unsolicited communication from VolServ can be directed to
either:
•A preselected RPC address.
•Or, to an internet address associated with an enterprise. The
RPC address or enterprise assigned for unsolicited
communication is assignable at the MediaClass level. Refer
to the Command Reference book for detailed information
about defining unsolicited communication parameters for a
MediaClass group.
This address is used as the receiver for unsolicited messages
that VolServ transmits. These messages are transmitted at
the completion of VolServ processing that had an impact on
any medium associated with the particular MediaClass
group.
Running the following commands: VSCMD_Import,
VSCMD_Export, VSCMD_CheckIn, VSCMD_CheckOut,
VSCMD_Mount, VSCMD_Dismount,
VSCMD_Reclassify can generate unsolicited communication
from VolServ. This unsolicited communication is returned to
the client issuing the command only if that client is specified in
the processing parameters as the destination for all unsolicited
communication for the MediaClass group.
6-01004-01 Rev AGetting Started1-9
and
API Guide
VolServ API
Integration
To integrate the VolServ API in a client application, the client
includes the header file vs_client.h in the source modules
that reference the VolServ API types and functions. The client
then links the program with the VolServ API library
libvsapi.a with the -lvsapi option for the cc or ld
commands.
The following five header files are delivered with the VolServ
API:
Header FilesDescription
vs_client.hIncludes the VolServ API header files needed
by the client.
vs_defs.hIncludes the VolServ API definitions needed
for the parameter lists.
vs_types.hIncludes the VolServ API types and
enumerations.
vs_globals.hIncludes the VolServ API global variables that
are accessible to the client.
vs_proto.h Includes the prototypes for all VolServ API
functions.
Before any command can be sent by the client program, the
VolServ API must by initialized with a call to
VS_Initialize. The routine VS_Initialize creates and
initializes the APIs required variables and creates a
communication link with VolServ. Before the client program
terminates, it calls the
VS_Terminate routine to allow the
VolServ API to clean up its processing.
For example:
/* get volserv host name from the user */
printf ( “Enter the name of the VolServ host
computer ==> “ );
scanf ( “%s”, vshost );
/* initialize the VolServ API. */
/* returns TRUE if successful, */
/* FALSE if fails. */
if ( VS_Initialize ( vshost, 0, 30 ) )
{
/* send and create commands */
.............
/* allow VolServ API to */
/* terminate properly */
VS_Terminate();
}
else
{
printf ( “Error initializing VolServ
API” );
}
}
Getting Started
6-01004-01 Rev AGetting Started1-11
API Guide
API Types
Objects
API objects and handles are described below.
The VolServ API uses an object-oriented metaphor for tracking
VolServ items. Each object contains several fields that describe
the object, routines that create and destroy the object, and
routines that access the data contained within the object.
The following objects mirror items found in VolServ: archive,
archive media class, archive type capacity, component, drive,
drive pool, enterprise group, enterprise connection, media,
MediaClass group, media type, mount selection expression,
mount selection criteria, mount selection criteria group, and
request. These objects usually store information relating only to
their VolServ counterparts.
Note
The following objects are specific to the VolServ API:
command, error, notify, status, and table. These objects
contain information about the associated command and its
statuses.
Handles
A handle is a pointer to a VolServ API object. An object is
created by an initialization routine that returns a handle that
points to the newly allocated object. After a handle is created, it
is passed as a parameter to the routines that access the handle’s
data.
1-12Getting Started6-01004-01 Rev A
API Guide
Each handle has the four base routines descried in the table
below:
RoutineDescription
initializerThe initializer creates and initializes the data
held by the handle and re turns a pointer to the
client that is used as a parameter to the
destructor, assignment, and accessor
functions.
destructerThe destructor frees the space held by the
handle.
assignmentThe assignment function allows the client to
assign values to fields within the handle . A call
to the assignment function takes a variable
argument list that includes a handle and a list
of identifier-value pairs. The handle identifies
the handle for which field values are being
assigned. An identifier-value pair identifies the
field for which a value is being assigned and
the value being assigned to that fie ld.
accessorThe accessor function allows the client to
retrieve v alues f rom fields wit hin the ha ndle. A
call to the accessor function takes a variable
argument list that includes a handle and a list
of identifier-pointer pairs. The handle identifies
the handle for which field values are to be
retrieved. An identifier-pointer pair identifies
the field for which the value is to be retrieved
and a pointer to the location where the field
value is to be stored.
Getting Started
The following example creates a command handle and uses the
assignment function to set the priority field within the command
object to a value of 10.
The table below describes the API naming conventions:
Conventions
ItemDescription
HandlesHandle names start with the VST prefix, followed by the specific
object name, and end with the HANDLE suffix. The name shou ld be
in all capitals. For example:
TypesTypes are defined in a client-accessed header file begin with the
VST prefix. For example:
DefinitionsDefinitions that are defined in the client definition header file
should begin with the VSD prefix. For example:
VSD_DRIVE_NAME_LEN
EnumerationsEn umerations ha v e two con ventions t o follo w. The type begins with
the VST prefix. The values inside the enumeration structure begin
with the VSE prefix.
For example:
typedef enum {
VSE_DRIVETYPE_NONE
= 0,
VSE_DRIVETYPE_MAGTAPE =1
} VST_DRIVE_TYPE
VST_DRIVE_HANDLE
VST_DRIVE_ID
Getting Started
Global VariablesGlobal variables begin with the VSG prefix. For example:
VSG_ERROR_CODE
IdentifiersIdentifiers that are used in the “assignment” and “accessor”
functions to identify the field being accessed within each handle
begin with the VSID prefix. The following identifier is for a drive
identifier, for example:
6-01004-01 Rev AGetting Started1-15
VSID_DRIVE_ID
API Guide
ItemDescription
FunctionsFunction names used in the VolServ API also follow a specific set
of rules. All function names exist in the format of the VS prefix,
followed by the object name, and ending with a condensed
description of the function. The following example shows the
overall form of function names:
VS_objectname_functiondescription()
The function descriptions also follo w a naming conv ention, with the
description coming from the following list: “GetFields”, “SetFields”,
“Create”, and “Destroy.” Refer to the following example:
The “GetFields” and “SetFields” functions each take a
variable argument list beginning with a handle. After the
handle, the client specifies identifier-parameter pairs (or
triples in some cases). These identifiers tell the function what
field is to be accessed. The parameter tells the function either
the value to be assigned to the field or the location where the
filed value is to be retrie v ed. The identif ier VSID_ENDFIELD
must appear at the end of the variable argument list. Refer to
the following example:
Function names that map directly to a VolServ Command
begin with the VSCMD prefix, followed by the command
name. Refer to the following example:
VSCMD_command_option
ollowing is an actual command:
The f
VSCMD_DriveQuery
( VS_COMMAND_HANDLE, …);
6-01004-01 Rev AGetting Started1-17
API Guide
ItemDescription
Parameter DefaultsTwo levels of default settings used in the API software—global
defaults and command-specific defaults.
• Global defaults are initialized at startup and can be set or
retrieved using the
VS_Global_SetFields() and
VS_Global_GetFields() calls.
• Command-specific defaults are set using the
VSCMD_commandname_SetDefaults() calls.
If command-specific defaults are set for a specific command (e.g.,
mount), they override the global defaults for all requests for
execution of that command. To override a default parameter value
for a specific instance of a command request, the parameter
identifier and the value to be used for the parameter can be
submitted on the command request (e.g.,
itself.
VSCMD_Mount())
1-18Getting Started6-01004-01 Rev A
API Guide
Dispatch
Routines
Dispatch routines are functions within the client software that
the API automatically calls when status messages or
MediaClass callbacks are received from VolServ. The dispatch
routine for MediaClass callbacks (also referred to as
notifications) is described on the man page for
VS_Notify_SetFields(l).
Dispatch routines for status messages are set for all requests
with the VS_Global_SetFields() call, for all requests of a
given type with the VSCMD_request_SetDefaults() call, or as
part of the call that sends the VolServ request.
Dispatch routines are prototyped as follows:
•void dispatchroutine(VST_COMMAND_HANDLE handle)
The dispatch routine takes one argument. This is the command
handle for the request that received status.
Getting Started
6-01004-01 Rev AGetting Started1-19
API Guide
Global
Parameters
Global parameters are a group of parameters that are used by
the API for all VolServ requests. Most of these are sent to
VolServ, but some serve as control information for the API. The
following table describe these parameters.
Global ParameterDescription
VSID_CLIENT_DISPATCHPointer to the dispatch function for all commands.
VSID_ENTERPRISE_ID Identifier of the enterprise, if any, to receive intermediate and
final status on every command requ est.
VSID_NOTIFY_DISPATCH Pointer to the dispatch function used for notification
(MediaClass callback) processing.
VSID_PRIORITY
(defaults to 15)
VSID_RETRY_LIMITNumber of times the API software is to retry for command
Execution priority assigned to every command request.
Values range from 1 (highest) to 32 (lowest).
status from VolServ before returning a time-out to the client
software.
Total length of time the API software waits for a command
status from VolServ is (VSID_RETRY_LIMIT plus1) multiplied
by the VSID_TIMEOUT_VALUE.
VSID_RETRY_LIMIT is not applicable when the API software
executes in asynchronous mode.
VSID_STATUS_WAIT_FLAGStatus wait flag for all commands. This flag controls whether
the API operates in synchronous or asynchronous mode. If its
value TRUE, the API waits for status (operate in synchronous
mode.) If its value is FALSE, the API operates in asynchronous
mode.
VSID_TIMEOUT_VALUE Amount of time, in seconds, VolServ waits for status before
timing-out to the client software for this request.
VSID_USER_FIELDA 16-character field provided for user information. Information
entered in this field is echoed back to the user in every status
message returned for each command. Neither the API
software nor VolServ uses USER_FIELD.
1-20Getting Started6-01004-01 Rev A
API Guide
Global
Variables
The following global variables are available to any software
using the VolServ API.
Global VariableDescription
VSG_ErrorGlobal error handle. It is set if an
error condition occurs in a
function that does not use a
command handle. This includes
the utility functions, handle
functions, and the functions that
set request- specific defaults.
See the man page for
VS_Error_GetFields to learn
how to access error codes.
VSG_Command_ReceivedPointer to t he command handle
whose status was just received
from VolServ. The
VSG_Command_Received can
only be used in asynchronous
processing.
Getting Started
6-01004-01 Rev AGetting Started1-21
API Guide
API Error
Handling
The API differentiates between:
•Errors that occur during API processing.
•Errors that occur within VolServ.
To accomplish this, there are two identifying parts for each
error—the first part identifies where the error occurred—the
second part identifies the specific error.
The API tracks errors by using error handles. There is an error
handle associated with each command, as well as a global error
handle. The global error handle is used to track errors that
cannot be associated directly with a command (e.g., bad handle
type and null handle).
The error code returned by the API is of the form: AAANNN,
where AAA is a three-letter string designating where the error
originates, and NNN is a numeric code designating the specific
error. The three-letter string maps either to an API object or to
VolServ. The numeric code represents either an API internal
error or the VolServ error code returned in the command’s
status.
The following example shows how to access an error code:
int numcode,objcode;
VST_ERROR_CODEerrcode;
VST_ERROR_HANDLEerrorhandle;
To send a command to VolServ, the client has to create a
command handle in which the request and its status is kept. The
command handle holds the information needed for the VolServ
API to process the command. The information in the command
handle is general for all commands (e.g., priority, time-out
values). Most fields are defaulted to values that can be
overridden by the client.
Each command has one entry point - a call of the form:
VSCMD_commandname
Each command accepts the command handle and a variable
length argument list with parameter name and value pairs. Each
parameter name and value pair specifies a command option and
its corresponding value.
The options are divided into two parts: the general command
options and the command-specific options. The general
command options are fields contained in all requests (e.g.,
priority). The specific command options are fields particular to
that type of request (e.g., archive name for the archive vary
command). A specific command option may not be unique to
one command, it can be used in several different commands.
Each command call returns a boolean value that indicates its
success or failure.
Options that are not passed in the argument list are defaulted to
command-specific defaults. These defaults are kept on a
command basis and can be set to client-desired values. The
function to set command-specific defaults is of the form:
VSCMD_commandname_SetDefaults
The defaults are specified in a v ariable length argument list with
parameter name value pairs. The values in the command
parameter list supersede global default values. See the
following example:
These two commands perform the same function as the
previous example. The VSCMD_Mount_SetDefaults function
sets command-specific defaults for all future Mount commands
within this process. When the Mount command is issued, the
parameters that are not specified are defaulted to the current
command-specific defaults. The defaults specified by
VSCMD_Mount_SetDefaults are valid only for Mount
commands.
Command
Status
After each status received from VolServ, the pertinent status
fields are stored in a status handle within the command handle.
The client can get the status handle from the command handle
with the VS_Command_GetFields function. After the status
handle is obtained, any command-specific field associated with
the status can be obtained through the
VS_Status_GetFields function. See to the following
The VolServ API allows for both asynchronous and
synchronous processing of VolServ commands.
For asynchronous processing, the VolServ API returns control
to the client after initial status is received.
2
VSCMD_
1
cmd
4
5
Client
Program
1. Client Program calls the command function (VSCMD_cmd).
2. The VSCMD_cmd calls the Volume Server.
3. VolServ returns initial status to VSCMD_cmd.
4. VSCMD_cmd returns control to the Client Program.
5. The Client Program calls the VS_Select loop to wait for status.
8
3
VS_Select
6
7
VS_CallBack
Volume
Server
6. VS_Select calls the command specific VS_CallBack.
7. VS_CallBack returns status to the VS_Select.
8. VS_Select returns status to the Client Program.
To receive subsequent status from VolServ API, the client
invokes the VolServ APIs
VS_Select function. It is the
responsibility of the client to place the VolServ API into its
select loop so all subsequent statuses can be received. In
asynchronous processing, the client can issue multiple VolServ
commands and immediately receive their statuses.
1-28Getting Started6-01004-01 Rev A
API Guide
Asynchronous processing also gives the client more control
over the processing en vironment. The VSID_RETRY_LIMIT is
not applicable when the API software executes in asynchronous
mode. If the VSID_STATUS_WAIT_FLAG value is FALSE, the
API operates in asynchronous mode.
Getting Started
Synchronous
For synchronous processing, the VolServ API returns control to
the client only after final status (or time-out) is received.
2
VSCMD_
cmd
4
8
1
Client
Program
1. Client Program calls the command function (VSCMD_cmd).
2. The VSCMD_cmd calls the Volume Server.
3. VolServ returns initial status to VSCMD_cmd.
4. VSCMD_cmd calls the VS_Select loop to wait for status.
5. VS_Select calls the command specific VS_Callback.
6. VS_Callback returns status to VS_Select.
7. VS_Select returns control to VSCMD_cmd.
8. VSCMD_cmd returns control to the Client Program.
7
3
VS_Select
6
VS_CallBack
5
Volume
Server
Synchronous processing allows processing of only one
command at a time. If the VSID_STATUS_WAIT_FLAG value is
TRUE, the API operates in synchronous mode.
6-01004-01 Rev AGetting Started1-29
API Guide
API Functions
The API function descriptions in this book are presented as
follows:
FunctionDescription
vsapiProvides a general introduction t o V olSe rv
API processing.
VS_cmdnameDescribes functions used to create,
destroy, assign, and access handles.
These functions are listed in alphabetical
within the subgroup.
VSCMD_cmdnameDescribes how a user accesses VS
commands through the API. These
functions are listed in alphabetical order
within the subgroup. The VolServ API
allows for both asynchronous and
synchronous processing of VolServ
commands.
VS_Archive_Destroy deallocates an archive handle that
was allocated with VS_Archive_Create. An archive
handle is used to pass archive information to and from VolServ.
109printf(“Enter Config State ==> “);
110ConfigState = atoi(gets(input));;
111/* set the fields in the handle */
112rc = VS_Archive_SetFields(h,
113VSID_ARCHIVE_NAME,
After VS_Archive_Destroy has been called for an archive
handle, that handle is no longer valid and should not be used.
6-01004-01 Rev AAPI Functions2-13
API Guide
See Also
•vsapi(l),
•VS_Archive_Create(l),
•VS_Archive_GetFields(l),
•VS_Archive_SetFields(l),
•VS_Error_GetFields(l)
2-14API Functions6-01004-01 Rev A
API Guide
VS_Archive_
GetFields
Synopsis
VS_Archive_GetFields retrieves information associated
with an archive handle. An archive handle is used to pass
archive information to and from VolServ.
Arguments•handle = Archive handle where information is retrieved.
•“…” = Variable length argument list consisting of pairs of
arguments. Each pair of arguments consists of a parameter
identifier, followed by a pointer to a location where the
value of the parameter may be stored. The parameter
identifiers and types this function accepts are shown in the
following "Parameters" paragraph.
•VSID_ENDFIELD = Required at the end of the variable
length argument list to indicate the end of the list.
Pointer to a boole an flag that indicates
whether the archive is currently being
configured or reconfigured.
Valid VSID_ARCHIVE_CONFG_STATE values
are enumerated in the vs_types.h file.
Pointer to the location of the archive’ s console
display.
API Guide
Parameter TypeDescription
VSID_ARCHIVE_FILL_MODE
(VST_ARCHIVE_FILL_MODE*)
Pointer to th e method of allocatin g bins to ne w
media as they are entered into an archive.
VSID_ARCHIVE_FILL_MODE is applicable
only to the DataShelf and DataLibrary
archives. Valid VSID_ARCHIVE_FILL_MODE
values are enumerated in the vs_types.h file.
VSID_ARCHIVE_MODE
(VST_ARCHIVE_MODE *)
Pointer that specifies whether this archive is
attended by an operator to handle media
movement commands that require human
intervention. Valid VSID_ARCHIVE_MODE
values are enumerated in the vs_types.h file.
VSID_ARCHIVE_NAME
(VST_ARCHIVE_NAME)
Pointer to the name of this archive. Valid
archive names may contain up to 16
alphanumeric characters, including spaces.
Leading and trailing spaces are not permitted.
VSID_ARCHIVE_TYPE
(VST_ARCHIVE_TYPE *)
Pointer to the type of this archive. Valid
VSID_ARCHIVE_TYPE values are
enumerated in the vs_types.h file.
VSID_ARCHIVEMEDIACLASS_HANDLE (int)Index of the archive media class handle in the
MediaClass capacity table.
(VST_ARCHIVEMEDIACLASS_HANDLE *)Pointer to the first archive media class handle
Index of the archiv e med ia class handle in the
MediaClass capacity table.
Pointer to the location to store the archive
media class handle.
VSID_ARCHIVEMEDIACLASS_HANDLE_TA
BLE (VST_TABLE_HANDLE *)
Pointer to the MediaClass capacity (in table
format) for this archive.
VSID_COMP_STATE (VST_COMP_STATE *) Pointer to the operational state of this archive.
Valid VSID_COMP_STATE values are
enumerated in the vs_types.h file.
VSID_DRIVE_ID (int)Index of the drive in the drive identifier table.
2-16API Functions6-01004-01 Rev A
API Guide
Parameter TypeDescription
(VST_DRIVE_ID *)Pointer to the first drive id in the driv e identifier
table.
VSID_DRIVE_ID_ENTRY
(int, VST_Drive_ID *)
Index of the drive in the drive identifier table.
Pointer to the location to store the drive
identifier
VSID_DRIVE_ID_TABLE
(VST_TABLE_HANDLE *)
Pointer to the drives (in table format)
associated with this archive.
VSID_MEDIA_ID (int)Index of the medium in the media identifier
table.
(VST_MEDIA_ID ) Pointer to the first media id in the media
identifier table.
VSID_MEDIA_ID_ENTRY (int, VST_
MEDIA_ID)
Index of the medium in the media identifier
table.
Pointer to the location to store the media
identifier.
VSID_MEDIA_ID_TABLE
(VST_TABLE_HANDLE *)
VSID_NUMBER_ARCHIVEMEDIACLASS_H
ANDLES (int *)
Pointer to the media identifiers (in table
format) that are currently in this archive.
Pointer to the number of archive media class
handles present in the archive media class
handle table.
VSID_NUMBER_DRIVE_ID (int *) Pointer to the number of drive ids present in
the drive id table.
Functions
VSID_NUMBER_MEDIA_IDS (int *) Pointer to the number of media ids present in
the media id table.
VSID_NUMBER_TYPECAPACITY_HANDLE
S (int *)
Pointer to the n umber of type capacity handles
present in the type capacity handle table.
VSID_TYPECAPACITY_HANDLE (int) Index of the type capacity handle in the table.
(VST_TYPECAPACITY_HANDLE *) Pointer to the first archive type capacity
•VSE_FALSE - API failure - An appropriate error code is set
in VSG_Error.
•VSE_ERR_BADFIELD - An invalid parameter was
specified.
•VSE_ERR_BADHANDLE - Specified handle was not an
archive handle.
•VSE_ERR_NULLHANDLE - Specified handle was a null
pointer.
Index of the type capacity handle in the
MediaType capacity table.
Pointer to the location to store the type
capacity handle.
Pointer to the type capacity (in table format)
for this archive.
•VSE_ERR_OUTOFRANGE - An index value was out of
range.
2-18API Functions6-01004-01 Rev A
API Guide
Example129/**************************************
***********
130*
131* FUNCTION: vst_print_archive
132*
133* PURPOSE:
134* This function prints out the
information stored in
135* an archive handle.
136*
137* PARAMETERS:
138* h : the archive handle to print
139*
140***************************************
i, &MediaID,
214 VSID_ENDFIELD);
215printf(“Media ID Entry #%d =
%s\n”,i,MediaID);
216 }
217 }
218
219 if (ClassCapacityTable !=
(VST_TABLE_HANDLE) NULL)
220 {
221 /* Get # of entries */
222
VS_Table_GetFields(ClassCapacityT
able,
223
VSID_NUMBER_ENTRIES, &n,
224 VSID_ENDFIELD);
225 for ( i = 0; i < n; i++)
226 {
227
VS_Table_GetFields(ClassCapacityT
able,
228 VSID_TABLE_ENTRY, i,
&arcmc_handle,
229VSID_ENDFIELD);
230
vst_print_archivemediaclass(arcmc
_handle);
231 }
232 }
233
234 if (TypeCapacityHandleTable !=
(VST_TABLE_HANDLE) NULL)
235 {
2-22API Functions6-01004-01 Rev A
API Guide
236 /* Get # of entries */
237
VS_Table_GetFields(TypeCapacityHa
ndleTable,
238
VSID_NUMBER_ENTRIES, &n,
239 VSID_ENDFIELD);
240 for ( i = 0; i < n; i++)
241 {
242
VS_Table_GetFields(TypeCapacityHa
ndleTable,
243 VSID_TABLE_ENTRY, i,
&typecap_handle,
244 VSID_ENDFIELD);
245
vst_print_typecapacity(typecap_ha
ndle);
246 }
247 }
248}
Functions
Notes
Note
If the argument list does not end with VSID_ENDFIELD,
unpredictable results occur.
VolServ assigns additional bins according to one of two
user-specified algorithms: “wrap” or “first fill.” Using the wrap
algorithm, VolServ assigns additional bins in order until the last
bin in the archive has been assigned. VolServ then wraps to the
first physical bin, goes through the bins in order, and assigns
empty bins as they are encountered. Using the first fill
algorithm, VolServ starts looking for an av ailable bin at the f irst
physical bin location. The first empty, on-line bin encountered
is assigned.
6-01004-01 Rev AAPI Functions2-23
API Guide
The VST_ARCHIVEMEDIACLASS_HANDLE, VST_DRIVE_ID,
VST_MEDIA_ID, and VST_TYPECAPACITY_HANDLE
parameters require that two arguments be passed instead of one.
•The first argument passed is the entry number in the
appropriate table.
•The second argument is Pointer to the location where the
value is stored.
See Also
•vsapi(l),
•VS_Archive_Create(l),
•VS_Archive_Destroy(l),
•VS_Archive_SetFields(l),
•VS_ArchiveMediaClass_GetFields(l),
•VS_ArchiveMediaClass_SetFields(l),
•VS_Error_GetFields(l),
•VS_Table_GetFields(l),
•VS_TypeCapacity_GetFields(l),
•VS_TypeCapacity_SetFields(l),
•VSCMD_Archive_Query(l
2-24API Functions6-01004-01 Rev A
API Guide
VS_Archive_S
etFields
Synopsis
VS_Archive_SetFields sets the value of one or more
field in an archive handle. An archive handle is used to pass
archive information to and from VolServ.
Arguments•handle = Archive handle where information is stored.
•“…” = Variable length argument list consisting of pairs of
arguments. Each pair of arguments consists of a parameter
identifier, followed by the value of the field to store. The
parameter identifiers and types this function accepts are
shown in the following "Parameters" paragraph.
•VSID_ENDFIELD = Required at the end of the variable
length argument list to indicate the end of the list.
A boolean flag that indicates whether the
archive is currently being configured or
reconfigured. Valid
VSID_ARCHIVE_CONFIG_STATE values are
enumerated in the vs_types.h file.
The location of the archive’s console display.
API Guide
Parameter TypeDescription
VSID_ARCHIVE_FILL_MODE
(VST_ARCHIVE_FILL_MODE)
VSID_ARCHIVEMEDIACLASS_HANDLE_TA
BLE (VST_TABLE_HANDLE)
VSID_ARCHIVE_MODE
(VST_ARCHIVE_MODE)
VSID_ARCHIVE_NAME
(VST_ARCHIVE_NAME)
VSID_ARCHIVE_TYPE
(VST_ARCHIVE_TYPE)
The method of allocating bins to ne w media as
they are entered into an archive.
VSID_ARCHIVE_FILL_MODE is applicable
only to the DataShelf and DataLibrary
archives.
Valid VSID_ARCHIVE_FILL_MODE values
are enumerated in the vs_types.h file.
The MediaClass capacity (in table format) for
this archive.
Specifies whether this archive is attended by
an operator to handle media movement
commands that require human intervention.
Valid VSID_ARCHIVE_MODE values are
enumerated in the vs_types.h file.
The name of this archive . Valid archive names
may contain up to 16 alph anumeric
characters, including spaces. Leading and
trailing spaces are not permitted.
Type of this archive. Valid
VSID_ARCHIVE_TYPE values are
enumerated in the vs_types.h file.
VSID_COMP_STATE (VST_COMP_STATE) The operational state of this archive. Valid
VSID_COMP_STATE values are enumerated
in the vs_types.h file.
VSID_DRIVE_ID_TABLE
(VST_TABLE_HANDLE)
VSID_MEDIA_ID_TABLE
(VST_TABLE_HANDLE)
VSID_TYPECAPACITY_HANDLE_TABLE
(VST_TABLE_HANDLE)
2-26API Functions6-01004-01 Rev A
The drive identifiers (in table format)
associated with this archive.
The media identifiers (in table format) that are
currently in this archive.
The type capacity (in table format) for this
archive.
API Guide
Return Values
VS_Archive_SetFields returns:
•VSE_TRUE - Successful execution.
•VSE_FALSE - API failure - An appropriate error code is set
in VSG_Error.
•VSE_ERR_BADHANDLE - Specified handle was not a
criteria handle.
•VSE_ERR_BADSIZE - The value passed for a string
parameter exceeds the maximum allowable length for that
parameter.
•VSE_ERR_NULLHANDLE - Specified handle was a null
pointer.
•VSE_ERR_NULLSTRING - A null value was passed to a
string argument.
Example249/**************************************
***********
250*
251* FUNCTION: vst_archive_handle
252*
253* PURPOSE:
254* This function tests an archive handle.
255*
256* PARAMETERS:
257* none
258*
259***************************************
If the argument list does not end with VSID_ENDFIELD,
unpredictable results occur.
6-01004-01 Rev AAPI Functions2-29
API Guide
VolServ assigns additional bins according to one of two
user-specified algorithms: “wrap” or “first fill.” Using the wrap
algorithm, VolServ assigns additional bins in order until the last
bin in the archive has been assigned. VolServ then wraps to the
first physical bin, goes through the bins in order, and assigns
empty bins as they are encountered. Using the first fill
algorithm, VolServ starts looking for an av ailable bin at the f irst
physical bin location. The first empty, on-line bin encountered
is assigned.
2-30API Functions6-01004-01 Rev A
API Guide
See Also
•vsapi(l),
•VS_Archive_Create(l),
•VS_Archive_Destroy(l),
•VS_Archive_SetFields(l),
•VS_ArchiveMediaClass_GetFields(l),
•VS_ArchiveMediaClass_SetFields(l),
•VS_Error_GetFields(l),
•VS_Global_SetFields(l),
•VS_Table_Create(l),
•VS_Table_Destroy(l),
•VS_Table_GeFields(l),
•VS_Table_SetFields(l),
•VS_TypeCapacity_GetFields(l),
•VS_TypeCapacity_SetFields(l)
Functions
6-01004-01 Rev AAPI Functions2-31
API Guide
VS_Archive
MediaClass_
Create
Synopsis
VS_ArchiveMediaClass_Create allocates a VolServ
API archive media class handle. An archive media class handle
is used to pass archive media class information to and from
VolServ.
After VS_ArchiveMediaClass_Destroy has been called for an
archive media class handle, that ha ndle is no longer valid and
should not be used.
6-01004-01 Rev AAPI Functions2-39
API Guide
See Also
•vsapi(l),
•VS_ArchiveMediaClass_Create(l),
•VS_ArchiveMediaClass_GetFields(l),
•VS_ArchiveMediaClass_SetFields(l),
•VS_Error_GetFields(l)
2-40API Functions6-01004-01 Rev A
API Guide
VS_Archive
MediaClass_
GetFields
Synopsis
VS_ArchiveMediaClass_GetFields retrieves
information associated with an archive media class handle. An
archive media class handle is used to pass archive media class
information to and from VolServ.
Arguments•handle =Archive media class handle where information is
retrieved.
•“…” = Variable length argument list consisting of pairs of
arguments. Each pair of arguments consists of a parameter
identifier, followed by a pointer to a location where the
value of the parameter may be stored. The parameter
identifiers and types this function accepts are shown in the
following "Parameters" paragraph.
Functions
•VSID_ENDFIELD = Required at the end of the variable
length argument list to indicate the end of the list.
Parameters
Parameter TypeDescription
VSID_ARCHIVE_ACTION
(VST_ARCHIVE_ACTION_OPTION*)
6-01004-01 Rev AAPI Functions2-41
Pointer to th e archiv e a ction VolServ is to take
when the number of media in the archive
media class exceeds the specified high mark
threshold. Valid VSID_ARCHIVE_ACTION
values are enumerated in the vs_types.h file.
API Guide
Parameter TypeDescription
VSID_ARCHIVE_NAME
(VST_ARCHIVE_NAME)
Pointer to the name of the archive associated
with the archive media class relationship. Valid
archive names may contain up to 16
alphanumeric characters, including spaces.
Leading and trailing spaces are not permitted.
VSID_CAPACITY (VST_CAPACITY *) Pointer to the percentage of the total
MediaClass capacity that can be stored in this
archive.
VSID_COMPONENT_HANDLE_TABLE
(VST_TABLE_HANDLE *)
Pointer to the preferred locations for media
assigned to this archive media class.
VSID_FILL_LEVEL (VST_FILL_LEVEL *) Pointer to the number of media currently in
this archive media class.
VSID_HIGH_MARK (VST_HIGH_MARK *) The percentage of VSID_CAPACITY above
which the specified migration policy option is
performed or initiated. This field is applicable
only if VSID_ARCHIVE_ACTION is set to
VSE_ARCHIVE_ACTION_NOTIFY or
VSE_ARCHIVE_ACTION_MIG.
VSID_LOW_MARK (VST_LOW_MARK *) Pointer to the p ercentage of the archiv e medi a
class capacity below which automatic
migration of media out of the archive media
class stops. This field is applicable only if
VSID_ARCHIVE_ACTION is set to
VSE_ARCHIVE_ACTION_NOTIFY or
VSE_ARCHIVE_ACTION_MIG.
VSID_MEDIA_CLASS_NAME
(VST_MEDIA_CLASS_NAME)
Pointer to the MediaClass name associated
with the archive media class relationship.
V alid MediaClass names may con tain up to 16
alphanumeric characters, including spaces.
Leading and trailing spaces are not permitted.
2-42API Functions6-01004-01 Rev A
Parameter TypeDescription
API Guide
VSID_MEDIA_TYPE_NAME
(VST_MEDIA_TYPE_NAME)
VSID_MIGRATION_PRIORITY
(VST_PRIORITY *)
VSID_NUMBER_COMPONENT_HANDLES
(int *)
VSID_PERCENT (VST_PERCENT *) Pointer to the percentage of the media
VSID_TARGET_ARCHIVE_NAME
(VST_ARCHIVE_NAME)
Return Values
VS_ArchiveMediaClass_GetFields returns:
Pointer to the media type associated with the
archive media class. Valid media type names
may contain up to 16 alph anumeric
characters, including spaces. Leading and
trailing spaces are not permitted.
Pointer to the migration priority to be applied
to this archive media class.
Pointer to the number of component handles
present in the component handle table.
assigned to the related MediaClass group
allowed in the archive associated with the
archive media class relationship.
Pointer to the destination archive for media
automatically migrated out of this archive
media class. Valid archive names may co ntain
up to 16 alphanumeric characters, including
spaces. Leading and trailing spaces are not
permitted.
Functions
•VSE_TRUE - Successful execution.
•VSE_FALSE - API failure - An appropriate error code is set
in VSG_Error.
•VSE_ERR_BADFIELD - An invalid parameter was
specified.
•VSE_ERR_BADHANDLE - Specified handle was not an
archive media class handle.
•VSE_ERR_NULLHANDLE - Specified handle was a null
pointer.
6-01004-01 Rev AAPI Functions2-43
API Guide
Example1/****************************************
*********
2*
3* FUNCTION: vst_print_archivemediaclass
4*
5* PURPOSE:
6* This function prints out the
information stored in
7* an Archive Media Class handle.
8*
9* PARAMETERS:
10 * h : the Archive Media Class handle to