Silicon Graphics, Inc.
OpenVault
Administrative Interface
Command Line Interface Design

ov_stat

usage: ov_stat [-S <server_name>] [-acdfhlnpqsu] [-L <library name>] [-D <drive name>]

ov_stat shows the status of the ov_server and associated components. When arguments are not supplied, ov_stat shows the up/down status of the default server specified in the environment variable OVSERVER.

ov_stat arguments add either additional status items to the output or add detail to the output.

The ov_stat command has the following options:

-S

get status on the OpenVault server on the named host rather than on the default host.

-a

show info on all status items

-c

show configuration information on status items [libraries: capacity, form factors, slots, bays; drives: mode names, form factors, cartridge types, characterstics]

-d

show known drives with up/down, occupied status, time (of | since) last use

-f

show full status, giving more detailed info on each status item. [this option may not be needed]

-h

show short usage message

-l

show known libraries with up/down status

-n

do not display header information for listed items

-p

show applications registered / connected to the OpenVault server

-q

show task queue for ov_server, and drives and libraries if the -L, -l, -D, or -d options are specified

-s

show slot map for libraries (when used with -l or -L)

-u

show up/down status for system (and devices and libraries if -l, -L, -d, or -D options are used). This is the default return info but is not supplied if other arguments are specified unless -u is also specified

-L

show status on named library only. Each library to be listed must be preceded by a -L, e.g.: -L lib1 -L lib2

-D

show status on named drive only as per -L option

Examples:

ov_stat (no arguments)

shows up/down status of the OpenVault server

shows up/down status of the OpenVault server on the host "bitbucket", with info on libraries named "Odetics_1" and "Exa_3", with slot maps and queues for the server and both libraries.

show all available OpenVault server information

Questions: Should there be a -e flag to show errors, and if so, how many and for which system?

Environment variables:

OVSERVER

default host name of system running OpenVault system

ov_lscarts

usage:

ov_lscarts [-S <server_name >] [-A <app name >] [-L <library name>] [-D <drive name>] [-acefhHilopPrstuv] [-T <attribute name>] [-C <cartID>] [<PCLs>]

ov_lscarts shows info on cartridges known to an OpenVault server. When arguments are not supplied, ov_lscarts shows summary info on all carts known to the default server specified in the environment variable OVSERVER.

ov_lscarts arguments allow the selection of additional items to be displayed or add detail to the output.

Carts are listed by PCL by default, but optionally can be listed by cartID. Carts are also specified by PCL by default, but optionally may be specified by cartID. Additional information can be requested through specifying the appropriate option.

-S

show info for carts on the OpenVault server on the named host rather than on the default host

-A

show carts associated only with named application. Each application to be listed must be preceded by a -A, e.g.: -A backup_app -A archive_app

-D

show carts located only in the named drives as per the -A option

-a

show application which owns each cart

-c

list carts by cartID (instead of by PCL)

-C

show info for the specified cartID as per the -A option

-f

full listing. shows all attributes for each cart, with values for non-standard attributes printed following the attribute name (for alpha 1, show most data)

-h

show short usage message

-i

show the cartID

-l

long listing. includes PCL, cartID, cart type, app name, group, partition(s),vol name(s)

-p

show group to which cart is assigned

-P

show info on groups (names, number of assigned/free carts, priority)

-r

show partitions

-s

show cartridge state

-t

show the cartridge type

-T

list carts with info on the named attribute

-v

show the volumes on each cart

-w

show where the cartridge is (library name, bay name, slot name)

Options not implemented in Alpha 1 release:

-e

show carts which are marked for eject

-H

show hash value for the cart

-L

show carts located only in the named libraries as per the -A option

-o

show storage info (library, slot assignment, presence in slot, and if loaded in a drive, name of that drive)

-T

list carts with info on the named attribute

-u

show usage info (number of reads/writes/mounts, max number of reads/writes/mounts, locked, % used)

Examples:

ov_lscarts (no arguments)

shows summary info on all carts known to the default server specified in the environment variable OVSERVER.

lists cartridges known to the OpenVault server on the host "bitbucket", assigned to the application "networker", in long format

list all available information for all known carts on the default server

ov_lsvols

usage:

ov_lsvols [-S <server_name>] [-ahiln1] [-A <app name>] [<volIDs>]

ov_lsvols shows info on volumes known to an OpenVault server. When arguments are not supplied, ov_lsvols shows summary info on all volumes known to the default server specified in the environment variable OVSERVER.

ov_lsvols arguments allow the selection of additional items to be displayed or add detail to the output.

volumes are always listed by the application's volume ID. Additional information can be requested through specifying the desired option.

-S

show info for volumes on the OpenVault server on the named host rather than on the default host

-a

show application which owns each volume

-h

show short usage message

-i

show cartID for cart which contains this volume

-l

long listing. includes volume name, cart ID, app name, and partitions

-A

show volumes associated only with named application. Each application to be listed must be preceded by a -A, e.g.: -A backup_app -A archive_app

Examples:

ov_lsvols (no arguments)

shows summary info on all volumes known to the default server specified in the environment variable OVSERVER.

lists volumes known to the OpenVault server on the host "bitbucket", assigned to the application "networker", in long format

lists volume information in long format for the volumes named "Vol_001" and "Vol-abcd"

ov_report

usage:

ov_report [-S <server_name>] [-L <library name>] [-D <drive name>] [-acehow] [-t <seconds>] [-l <count>] [-m <minutes>]

ov_report displays current OpenVault system messages by scanning the OpenVault message log table and selecting pertinent information to display. When arguments are not supplied, ov_report lists current warning, error and operator intervention messages on the default server specified in the environment variable OVSERVER.

-S

display report info on the OpenVault server on the named host rather than on the default host.

-L

limit reports to messages pertaining to the named library

-D

limit reports to messages pertaining to the named drive

-a

report on advisory messages. The default behavior is to report on warning, error, and operator messages. Specification of the any of the -a, -e, -o, or -w arguments causes only the specified information to be displayed.

-c

report information continuously, updating the screen every XXX seconds. The refresh rate can be set using the -t option.

-e

report on error messages

-h

show short usage message

-l

show last <count> messages

-m

show messages which are less than <minutes> old

-o

report on operator intervention messages

-w

report on warning messages

-t

sets update interval for continuous update to the specified number of seconds. Implies -c

Implementation note: Messages to the OpenVault log file will include a sequence number. This allows a response to be posted to a given message, thus resolving the error or request. Unanswered requests are current, e.g. an operator message to load a specified cartridge into a library would be current (and hence displayed by ov_report) until either the cartridge was loaded or the request cancelled. Once either of these events takes place, the message would no longer be current and hence not displayed by ov_report.

ov_cart

usage:

ov_cart [-S <server_name>] [-n] [-h] <PCL> (<attr name> <attr value>) [(<attr name> <attr value>) ...] [-d <attr name> ...]

allows entry and modification of info on carts such that they will be recognized when inserted into a library with correct form factor, media type, etc. This function must be used for each cart before the cart can be used by an OpenVault client.

-S

enter data for carts on the OpenVault server on the named host rather than on the default host

-n

indicates that this is a new cartridge; checks for collision with existing PCLs. If this flag is not present, the PCL must already be in the catalog

-h

show short usage message

<PCL>

the physical cartridge label that identifies the cart which is to have attributes entered/or modified

(<attr name> <attr value>)

pairs of attribute names and values to be entered/modified

-d <attr name>

deletes an attribute (only works for extended attributes)

ov_part

usage:

ov_part [-S <server_name>] [-n] [-h] (-n <cartID> -p <partition name> -s <side> ) | ( <cartID> -p <partition name> [ -s <side>] ) [ -z <size>] [-a (TRUE|FALSE) ] [-b <bit format>]

allows entry and modification of info on partitions to allow allocation of volumes on a piece of media. Allows setting of partition allocatable bit so that a partition can be allocated or reallocated (after being deallocated by the owner application).

-S

enter data for carts on the OpenVault server on the named host rather than on the default host

<-a>

controls whether the partition is allocatable. If set to TRUE, the partition may be allocated by an application program. If FALSE, the partition is not available for allocation.

-n

indicates that this is a new partition; checks for collision with existing partitions of the same name on the same side of the cartridge. If this flag is not present, the partition must already exist in the OpenVault catalog.

-h

show short usage message

<cart ID>

the system assigned unique cartridge ID that identifies the cart which is to have partition info entered or modified

<-p>

allows specification of the name of a partition to be created or modified.

<partition name>

the name to be used to refer to a partition being created or modified. Partition names must be unique on each side of an individual cartridge.

<-s>

allows specification of the name of the side on which a partition is tp be created or modified.

<side>

the name of the side on which the partition to be created or modified resides. If modifying a partition, side does not have to be specified if the partition name is unique on the cartridge.

<-b>

allows specification of the partition bit format.

<-z>

allows specification of the size of the partition (in megabytes)

ov_vol

usage:

ov_vol [-S <server_name>] [-n] [-h] <app_name>. <volume_name> (<attr name> <attr value>) [(<attr name> <attr value>) ...] [-d <attr name> ...]

allows entry and modification of info on volumes to allow apps to operate on volume attributes. This function must be used for each volume before it may be used by an OpenVault client.

-S

enter data for volumes on the OpenVault server on the named host rather than on the default host

-n

indicates that this is a new volume; checks for collision with existing volume names within an application's name space. When a volume is created, standard attributes will be be assigned to the volume and given default values if the values are not specified. If this flag is not present, the volume name must already be in the catalog

-h

show short usage message

<app_name>

the name of the application to which the volume will belong. In Revision 1, volumes will be owned by only one application.

<volume_name>

a name which identifies the volume which is to have attributes entered/or modified

(<attr name> <attr value>)

pairs of attribute names and values to be entered/modified

-d <attr name>

deletes an attribute (only works for extended attributes)

ov_eject

usage:

ov_eject [-S <server_name>] [-h] ( -l <library name> -s <slot> ) | ( <PCL> | [-C <cartIDs>] )

allows eject of one or more carts from a library. Carts may be specified by PCL, cartID or by location through specifying library, bay (if there is more than one bay) and slot. Catalog entries for carts are marked for eject. If the library is capable of automatically performing an eject, the cart is ejected. If not, an operator message is generated indicating the cartridge to be removed and the operator must interact with the appropriate LCP to physically remove the cartridge.

-S

eject carts controlled by the OpenVault server on the named host rather than on the default host

-C

eject carts specified in the list of cartIDs (instead of listing by PCL)

-l

specifies an eject based on location. The library name must follow, as must arguments for the library bay (if there is more than one bay) and slot name

-b

allows specification of the bay for a location-based eject

-s

allows specification of the slot for a location-based eject

-h

show short usage message

ov_inject

usage:

ov_inject [-S <server_name>] [-ch] (-n <count>) <library name>

signals a library to open its inject port to accept an insert of a cartridge or magazine. The library name is required. Injects can be requested for only one library per invocation of this command.

-S

inject carts on the OpenVault server on the named host rather than on the default host

-c

inject carts continuously until the operator reports "done"

-h

show short usage message

-n

inject <count> cartridges into the library

ov_devctrl

usage:

ov_devctrl [-S <server_name>] -dev <device name> - [ (activate|deactivate <hostname>) | enable|disable | reset | (scan [ -r <start slot> <end slot>]) ] [-h]

ov_devctrl allows the operator to control devices. Libraries and drives may be enabled/disabled or reset. Libraries can be signaled to inventory their contents in full or in part in order to resynchronize the state of a library with the OpenVault server. The library status and contents of slot map are polled and and used to update the catalog on the OpenVault server.

Slot maps can become unsynchronized (i.e., the information that the library has on which PCLs are in which slots and/or occupied status of each slot does not match the OpenVault server's view of that information) through system error or if carts are removed/inserted from a library manually without initiating an automatic rescan. An inventory with ov_devctrl will always cause a copy of the library's slot map to be uploaded to the server. A physical rescan of the contents of the library may be performed by the library, but some libraries will not accept a command to physically rescan their contents. In these cases, the libraries current view of its contents will be uploaded.

-S

control devices on the OpenVault server on the named host rather than on the default host

-enable

specifies that the named device should be considered available for use by OpenVault

-disable

specifies that the named device should be considered unavailable for use by OpenVault. This cuts off access to the device; OpenVault will not attempt to communicate with it

-activate

signals an LCP or DCP associated with the named device on the specified host to commence communicating with the device. If another LCP or DCP on another host is already active, then that LCP or DCP is switched to the inactive state, thus performing a switch of control operation from one host/control program to another. This command together with the deactivate commands is the primary method of controlling communication with multi-ported devices

-deactivate

signals an LCP or DCP associated with the named device and the specified authorization key to stop communicating with the device

-reset

signals the library or drive to perform its initialization sequence

-scan

for libraries only, tells the device to scan PCLs, limited to the specified range of slots if the -r option is specified and if the library supports partial scans of PCLs

-h

show short usage message

-r

specifies a range of slots to scan. All of the slots with names in the lexicographic range of the start slot through end slot will be scanned. If this option is not specified, all slots will be scanned.

ov_mount

usage:

ov_mount [-S <server_name>] [-h] [ -d <drive name> ] ( -C <cartID> | <PCL> )

ov_mount allows the operator to mount a cartridge in a drive so that the operator may examine it. A device name is returned which can be used to access the cartridge with external programs. The operator can specify the cartridge by either PCL or cartID. The operator can specify a particular drive on which the cart should be mounted. An error is generated if the specified drive and cartridge have incompatible formats. If no drive is specified, then any drive with compatible format to the cart may be used and its device name will be returned. The drive will be owned by root and permissions will be set to 600. After the drive is mounted, a subshell will be started. The drive may be accessed from that subshell.

-S

mount carts on the OpenVault server on the named host rather than on the default host

-C

allows the specification of a cart to be mounted by cartID instead of by PCL.

-d

allow the specification of a particular drive by OpenVault system name as the mount location for the cartridge. If no drive name is provided, the system will automatically pick an available drive which is compatible with the cart's format and mount the cart there.

-h

show short usage message

ov_unmount

usage:

ov_unmount [-S <server_name>] [-fh] [ -d <drive name> ] ( -C <cartID> | <PCL> )

ov_unmount allows the operator to unmount a cartridge which is loaded in a drive. This command would normally be used to unmount a cart which was loaded with the ov_mount command, but it may also be used to unmount a cart loaded by an OpenVault app which has died.

The operator can specify the cartridge by either PCL or cartID. In addition, the operator can specify a particular drive which should be unmounted. This should be used when the cartID or PCL of a cart loaded in a drive is not known.

-S

unmount carts on the OpenVault server on the named host rather than on the default host

-C

allows the specification of a cart to be unmounted by cartID instead of by PCL.

-d

allow the specification of a particular drive to be unmounted by OpenVault system name.

-f

force an unmount of a cart that was mounted by an OpenVault app (i.e., not mounted with an ov_mount command).

-h

show short usage message

ov_move

usage:

ov_move [-S <server_name>] [-h] (<PCL> | -C <cartID> | -L <library name> <origin slot ID> ) <destination slot ID>

ov_move allows the operator to move cartridges within a library for purposes such as organizing carts by app, changing proximity to a drive, or packing carts into an ejectable magazine. Carts to be moved may be specified by PCL, cartID, or library with slot name. Destination addresses are specified by slot name. Carts may only be moved within a library.

-S

move carts on the OpenVault server on the named host rather than on the default host

-C

allows the specification of the cart to be moved by cartID instead of by PCL.

-L

allows operator to specify cart to be moved by library name and slot name.

-h

show short usage message

ov_cancel

usage: ov_cancel [-S <server_name>] [-r <string>] [-h] [ <task ID> ]

ov_cancel allows the operator to reject task requests queued by an OpenVault server. Cancels are sent to the default server specified in the environment variable OVSERVER. If the task request is still pending when this command is issued, the request is removed from the OpenVault server's task queue, and an explanatory message is sent to the requesting task if one is provided by the operator. If a task ID is not specified, ov_cancel displays a list of outstanding task requests plus a short usage message.

-S

cancel tasks on the OpenVault server on the named host rather than on the default host

-r

allows the operator to supply a text string explaining why the request was canceled

-h

show short usage message

ov_clean

usage: ov_clean [-S <server_name>] [-hin] [-d <drive name;%gt;] [ -C <cartID> | <PCL> ]

ov_clean allows the operator to clean a drive in a library in the OpenVault system. The drive is specified by supplying the the OpenVault-system name for the drive. The specific cleaning cart to be used may be specified by PCL or cartID. If a cart specification is not provided, then the OpenVault system will attempt to find and use an appropriate cleaning cartridge.

If no arguments are provided a list of drives will be output with any information on the cleaning state of the drive (e.g., date last cleaned, number of read/write errors).

-S

clean drives on the OpenVault server on the named host rather than on the default host

-C

allows the specification of the cleaning cart to be used by cartID instead of by PCL.

-i

display available cleaning info on the specified drive

-n

do not perform the cleaning operation. This can be used to determine whether a cleaning cartridge is available or which cleaning cartridge would be used if a particular cleaning cart was not specified.

-h

show short usage message

ov_purge

usage:

ov_purge [-S <server_name >] [-hn] [<PCLs>] [-C <cartIDs>]

ov_purge removes the catalog record for a specific cart on the default OpenVault server. All information about the cartridge is lost, including side and partition data. If volumes exist on a cartridge, an error is reported and the catalog entry for the cartridge is NOT deleted. All volumes on a cartridge must be deallocated before a cartridge can be purged. Caution: This function should only be used when a cart is destroyed or otherwise expected to never be seen again by the OpenVault system.

Carts are specified by PCL by default, but optionally can be specified by cartID.

-S

purge a catalog record on the OpenVault server on the named host rather than on the default host

-n

no-verify. The ov_purge operation is destructive, thus a confirmation request is issued which requires an interactive response. This option allows the confirmation prompt to be suppressed.

-C

delete the catalog entries for the carts specified in the list of cartIDs. When this option is not used carts are specified by PCL

-h

show short usage message

ov_auth

usage:

ov_auth [-S <server_name >] [-hr] [ -a <app-names> ] [ -H <hostnames> ] [ -k <auth-key> ]

ov_auth allows the administrator to specify authorization keys for OpenVault client applications or library and drive control programs (LCPs and DCPs). When no authorization keys are specified, ov_auth lists the keys for the applications or hosts specified in the command line arguments

-S

perform operations on the OpenVault system located on the named host rather than on the default host

-r

remove the keys for the specified apps. If no hostnames are specified, then all keys for the specified apps will be removed. If apps and hostnames are specified, then only the keys for the apps on those hosts will be removed. If only hostnames are specified, then keys for all apps on the specified host will be removed.

-a

add or remove authorization keys for the applications specified. One or more apps may be included in this argument list. An asterisk may be specified as wildcard to indicate "all applications"

-H

add or remove authorization keys for on the listed hosts. One or more apps may be included in this argument list. An asterisk may be specified as wildcard to indicate "all hosts"

-k

a user specified authorization key should follow this argument. This key must also be placed in the configuration file for each app on each host from which it is run. The special key of "none" disables authorization for the OpenVault system for this app or hostname. If no key is specified, ov_auth lists the keys for the apps and hosts specified.

-h

show short usage message

ov_config

usage:

ov_config [-S <server_name >] [-hn] [ -d <debug level> ] [ -D <debug file name> ] [ -l <log file level> ] [ -L <log file name> ]

ov_config allows the administrator to set various configuration options on the OpenVault server.

-S

configure the OpenVault system located on the named host rather than on the default host

-d

sets the debug level. The default value of zero causes all debug messages to be turned off. Positive values produce increasingly detailed debug messages to be sent to the debug file. Supported values are 0 through 5.

-D

sets the filename to which debug messages are written. The default filename is /var/adm/ov_debug_messages.

-l

sets the logging level. A value of zero causes all logging messages to be suppressed. The default value of 1 causes normal logging messages to be sent to the log file. Higher values produce increasingly detailed log messages. Supported values are 0 through 5.

-L

sets the filename to which log messages are written. The default filename is /var/adm/ov_logfile

-h

show short usage message

Require additional options to:

• configure system policy (hash check (not in rev 1), etc.)
• allow sharing of carts between apps (not in rev 1)

  Question: should we support reservation of slots/bays by application in rev 1 or at all? // Not in rev 1.

  Note: a list of cart form factors will not be kept by the OpenVault system. Such a file may be useful to have around though as a reminder to the admin/operator of the valid types.

  Note: There is no "register" command for applications. Applications are registered by specifying an authorization key for each app. If there is no authorization key, then the app can not connect to the OpenVault server. [Implementation note: This may break down on large systems where different apps have the same name. It may be necessary to identify apps by name and host to map them to unique app ID's within OpenVault.]

ov_group

usage:

ov_group [-S <server_name >] [-acdhlr] [ <group name list> ] [ -A <application list> | ANY ] [-p <cart group priority> ] [ -q <cart group app priority> ]

ov_group allows the administrator to create and delete groups, and to control which applications may have access to the media in each group. When no arguments are provided, the default action is to list the current groups and the apps that may use each of them.

-S

manage groups on the OpenVault system located on the named host rather than on the default host

-a

add the specified applications to the authorized list for the specified groups.

-c

create the named groups with access allowed to the applications specified with the -A argument. The special name "ANY" allows any application to use cartridges from a group.

-d

delete the named groups. [Implementation note: need to determine behavior when a group is deleted while carts are still in it. Possibilities are: 1) do not allow deletion while there are carts in the group, 2) any carts in the named group go into the "default" group.]

-l

list the groups in the OpenVault system with the applications that may use each of them. (default option)

-n

do not display header information for listed items

-p

set the cartridge group priority.

-q

set the cartridge group application priority.

-r

remove the specified applications from the authorized list for the specified groups.

-A

list of applications to be added to / removed from list of apps with permission to use the specified groups.

-h

show short usage message

ov_drivegroup

usage:

ov_drivegroup [-S <server_name >] [-acdhlnr] [ <drive group name list> ] [ -A <application list> | ANY ] [ -t <drive group unload time> ] [ -p <drive group app priority> ] [ -q <drive group app unload time> ]

ov_drivegroup allows the administrator to create and delete drive groups, and to control which applications may have access to the drives in each group. When no arguments are provided, the default action is to list the current drive groups and the apps that may use each of them.

-S

manage drive groups on the OpenVault system located on the named host rather than on the default host

-a

add the specified applications to the authorized list for the specified drive groups.

-c

create the named drive groups with access allowed to the applications specified with the -A argument. The special name "ANY" allows any application to use drives from a group.

-d

delete the named drive groups. [Implementation note: need to determine behavior when a group is deleted while drives are still in it. Possibilities are: 1) do not allow deletion while there are drives in the group, 2) any drives in the named group go into the "default" group.]

-l

list the drive groups in the OpenVault system with the applications that may use each of them. (default option)

-n

do not display header information for listed items

-p

set the drive group application priority.

-q

set the drive group application unload time.

-r

remove the specified applications from the authorized list for the specified groups.

-t

set the drive group unload time.

-A

list of applications to be added to / removed from list of apps with permission to use the specified drive groups.

-h

show short usage message

Administrative Application Interface (AAPI) to the OpenVault server

• report task queue list (requests) for a device and OpenVault server
• set / report log and debug levels for a device and OpenVault server
• set / report log files
• set / report hash usage for [apps|carts|libraries]
• set / report LCP modes (slot stable or optimized) [not in rev. 1]
• create / modify cart data

Implementation (includes error detection & recovery)

Each command will be processed as follows:

• parse command string, create AAPI function call
• open a CAPI channel
• send function call
• wait for reply
• close connection
• display the result

Command lines containing unrecognized keywords or arguments will be rejected with error messages to standard error. Checks for excessive input length or invalid input will also generate errors.

Interfaces (internal/external)

Open issues

More info is required in library config files than is specified in the boot document. Libraries with variable internal configuration need info on which slots / form factors as this info may not be available by query to the library.

User mounts, i.e. code to allow individual users to function as clients so that they may perform library functions (e.g. mount / dismount media) are not performed by the Open Vault admin interface. These are allowed through utilities such as the User Mount Shell (umsh).

If the administrator attempts to delete an application that has tapes assigned to it, does the library function generate an error or should the administrative interface generate an error? The intent is that some portion of the system will report an error. All media for an application must be deallocated before the application is deleted.

The LCP/DCP/OpenVault document specifies that there will be individual config files for each of these elements. Will a single interface access each of these files, or will there be individual programs to manage each file?

Note on manual reversion for libraries:

It is a requirement for the system that if a robotic mechanism fails, then the media contained in that robot be available for manual mount by a human operator. Current plans include a mechanism to automatically configure a manual LCP based on the LCP for the library that failed; the slot map with contents and drive configuration will be transferred to a manual LCP. The manual LCP will issue messages to an operator console requesting movement of carts which would normally be performed by the robotic mechanism. This will allow uninterrupted access to critical data during periods of robotic mechanism downtime. Conversely, a similar mechanism will be provided to transfer data and control back to the robotic LCP when it is returned to service.

Unknown cart locations: when a cartridge is ejected from a library its location becomes "unknown" until it is inserted into another library. It is desirable that if an application requests a cartridge with such an unknown location that the request NOT immediately fail as the operator might be able to take action to service the request. One way this might work is that upon receiving the mount request from an application, the server would note that the cart location is unknown, and then issue an alert to the OpenVault operator asking for intervention. If the cartridge is readily available to the operator, it can be inserted into a library (including a "manual library") which would allow the request to be satisfied. If the cartridge or operator was not available, the request could time-out, which would send an an appropriate error message back to the application, or the operator could specifically reject the request. The final details of this function have yet to be finalized.

Some robots have holders that can be reconfigured to accept carts with different form factors. The syntax and semantics of an ov_config option to deal with this is not yet defined.

Identifying a tape by its headers is a non-trivial task. Loss of a physical label on a cart and/or operator error could result in an app overwriting a tape from another app. Some risk could be reduced if apps shared a common tape header format. If each app can determine that a tape that was loaded for it does not belong to it and which app it belongs to, then we could provide greater assurance that a tape will not be inadvertently overwritten. We should consider proposing such a format so that conforming apps can share a library with greater confidence.

Security issue: The operator needs to be able to change certain cart attributes, but this also provides the power to really screw things up. If a cart mount is rejected because of a bad hash, the operator may legitimately need to reassign the hash as the cart may have been modified off-site. On the other hand, it could signify that the wrong cart has been provided to the app, such as if the robot read a PCL incorrectly or a person switched the barcodes (either inadvertently or deliberately). Perhaps the attributes that the operator may change should be examines and restricted, but it appears that a certain amount of training and trust will be required.

Testing

Once library routines are available, test scripts will be written to call the administrative routines to verify correct handling of all critical administrative functions and as many non-critical functions as possible. These will include correct configuration of libraries, handling of media, handling of clients (applications), and output of status information.