A location for cartridges, with locality determined by similar access (mount) time. Typically, a bay is a physical grouping of cartridges in a common unit of housing, where cartridges are stored. A bay contains storage locations for cartridges, optional drives, and one or more transfer agents to move cartridges between storage locations and drives or other storage locations.

In a multibay library, each bay in the library is attached to at least one other bay in the same library. For each cartridge in the library, there is some path for moving that cartridge from its current bay to any other bay, with one or more transfer agents to move that cartridge.

A physical container for storage media. Each cartridge in the OpenVault system should have some kind of external identifying label (a physical cartridge label) that the library or an operator can verify. Part of the external label should be human readable. For automated libraries, another part of the label is machine readable--typically a barcode label that a laser scanner can interpret.

Cartridges can have multiple sides. If they do, their containing library should be able to move or mount cartridges to achieve a particular orientation, for example, “side A” up.

ALI commands are objects as far as ALI is concerned. When the MLM server sends an ALI command, it associates a task ID with that command. The sender may refer to that command later by using the same task ID, but only to cancel the command. When an LCP receives a command, it includes the task ID in command responses.

A device for accessing media inside a cartridge that has been mounted.

Each LCP knows the details of a removable media library, including its configuration and control procedures. An LCP is responsible for accomplishing tasks that the MLM server asks it to perform, primarily managing library resources. An LCP communicates with its library using some device-specific language.

An LCP can be seen as a black-box language translator, or a device management module. See Chapter 4, “Programming a Library Control Program (LCP)” for details about writing an LCP.

A door or opening where cartridges may be inserted into or removed from the library.

A library contains one or more housing units, called bays, for storing cartridges. Bays contain storage locations for cartridges, optional attached drives, and one or more transfer agents for moving cartridges between storage locations in the same or different bay (using the move command), or between storage locations and drives in the same or a different bay (using the mount and unmount commands).

A library provides some way to read or verify external labels affixed to cartridges. A removable media library also provides some means for inserting cartridges into and removing cartridges from the library.

Each library has a specific control method. For automated libraries, this is typically some physical control connection from a host. For a human operated library, this might be a connection to an operator console.

Typically, a library is a single automated device, with some sort of robotic transfer agent to move cartridges between storage locations and drives. Larger devices may include a number of bays attached with pass-through ports. A human operated vault, where tapes are stored on racks and transported between racks and drives by people, is another type of removable media library.

A storage location for a cartridge. It has a shape, or form factor, that determines which kinds of cartridges it can hold.

These are LCP private attributes. Developers may devise arbitrary attributes, and store them to and recover them from the MLM server persistent store. These attributes are opaque to the MLM server.

These are attributes that an LCP is required to support. Developers may store the loglevel mandatory attribute in the MLM server persistent store; so the LCP can recover it and resume logging at the same level across reboots.

List of bays in the library, with information on whether each bay is accessible or not

List of drives in the library, with information on whether there is a cartridge in each drive, and whether it is accessible

Array of elements, one per slot, provided by the LCP to help the MLM server operate and administer the library, including:

A text string provided by the LCP, which refers to a bay in the library. An LCP should choose bay IDs that are easy for a human operator to interpret. For multibay libraries, the bay ID is usually consistent with the device name or address for a bay.

The OpenVault client name refers to a specific removable media library. This is the name by which a client identifies itself in a hello command to the MLM server. For ALI clients, this is name that the MLM server associates with the library that is managed by the associated LCP.

Refers to an OpenVault removable media device.

The OpenVault instance name is arbitrary, but is needed in case there are multiple LCPs controlling the same library, so as to distinguish between LCPs with the same client (library) name.

Each LCP is uniquely named by a value pair including an OpenVault client name and an OpenVault instance name.

A physical cartridge label (PCL) refers to a cartridge. It is some form of identification on the outside of the cartridge, as opposed to being stored on media inside the cartridge. A PCL may contain a machine-readable label (barcode), but it must also contain a human-readable text portion.

Currently, there is no ALI support for port names. Port naming may be supported in a future version of OpenVault.

A text string provided by the LCP, which refers to a slot in the library. The slot ID must uniquely identify any slot under control of that LCP, and should be easy for a human operator to interpret. For libraries with explicit slot locations, slot ID is usually consistent with the device name or address for that slot.

Uniquely identifies a sender-generated command.

Starts and stops LCP interactions with the library. The activate command includes two variations. Note that once the LCP has established a session with the MLM server using the hello-welcome sequence, it may begin accepting ALI commands from the server. However, until it has successfully been activate enabled and is in ready state, it will resend ready lost state and fail ALI commands requiring access to its library with the error ALI_E_READY. The LCP uses one of the ALI/R ready command variations after processing the current command.

These are the variations of the activate command:

Sets and unsets named attributes in the LCP. You can think of attributes in an LCP as named memory locations that may cause operations to happen as a side effect of setting or reading them. Some attributes defined by an LCP may be read-only to the MLM server.

A list of mandatory attribute names appears in Table 3-1.

Forces the LCP to complete work on all commands received prior to the barrier command, before it begins working on any commands that might follow. This may require special processing for queued eject and openPort commands. For example, if an LCP normally flushes ejects with the openPort command, barrier should be rejected if the LCP has not already received an openPort command.

In general, an LCP is free to execute the commands it receives in any convenient order. Since there might be circumstances where the MLM server requires an explicit order for executing a sequence of commands, the barrier command can be employed to force ordering.

Prevents execution of a command that has been queued in the LCP but which the device has not yet started. The LCP may choose to cancel already started jobs on a best-effort basis.

---

Note: The cancel and response commands may not be cancelled.

---

Pushes, in conjunction with the openPort command, cartridges out of the library. It takes a (slot ID, PCL) pair for the cartridge that is to be operated on. The LCP should send the corresponding changes in its slot and drive maps to the MLM server.

The implementation of the eject command may vary from LCP to LCP, but there are three basic cases, as listed in Table 3-3.

When a cartridge is physically ejected, it must immediately disappear from the OpenVault slotmap maintained by the LCP. This implies that an LCP that cannot immediately push a cartridge out of the library must be prepared to inform OpenVault that a particular slot ID (and therefore PCL) has been marked for ejection. The LCP should mark this slot as inaccessible and push the information to the MLM server.

The LCP should recall this information from the OpenVault database upon booting, when OpenVault supports retrieval of LCP attributes from the MLM server's persistent storage.

Tells the LCP to clean up and exit.

The LCP should store any persistent LCP or library information in the OpenVault database, complete or cancel any pending ALI commands, send or abort any pending ALI/R commands, do shutdown processing as required by its interface to the library, send ready lost and goodbye commands to the MLM server, and exit.

Tells the communicating LCP to end this session.

Places a cartridge into a drive. The arguments to mount are a list of tuples (slot ID, PCL, side) and a drive name. The operation involves taking a cartridge from one of the given slots and putting it into the specified drive. For multisided cartridges, placement is according to a specified side orientation, for example “side A” up. The slot list may have just one element; if more than one is specified, the LCP decides which slot to use. The LCP should send the corresponding changes in its slot and drive maps to the MLM server.

---

Note: Multisided cartridges are not supported in OpenVault version 1.0.

---

Transfers a cartridge from one physical slot in the library to another physical slot. The move source is a slot ID, PCP pair, and the destination is a slot ID. The LCP should send the corresponding changes in its slot and drive maps to the MLM server.

Removes or allows, in conjunction with the eject command, cartridges to be removed from the library. It may also be used on its own to allow cartridges to be inserted into the library. The function of the openPort command is to prepare the library for an operator to gain physical access to cartridges. Once access is granted, cartridges may be removed from and inserted into the library. The implementation of openPort may vary from LCP to LCP, and a given library might be in a different class for export than for import, but there are three basic cases, as listed in Table 3-4.

See the description of the ready and ready not commands under ALI/R for more information on how an LCP becomes not ready, permitting its library to be temporarily not available during an openPort operation.

Asks the LCP to try and force the library to reinitialize. This may cause the library to perform internal diagnostics.

If a reset makes the library unavailable to process other requests for an extended time, the LCP should use the ready not command to tell the MLM server that its library is temporarily not available, followed by a ready command when the library becomes available again.

Acknowledges and indicates success or failure of an ALI/R command. The optional text portion of the response contains error details or command results.

Forces the LCP to verify or recheck the PCLs of all cartridges in the library. These are variations of the scan command:

If the library will be unavailable to process other requests during this time, the LCP should use the ready not command to tell the MLM server that the library is temporarily not available for other motion commands (such as mount, unmount, move, or eject), followed by a ready command when the library becomes available again.

Obtains the current value of an attribute. Some of the attributes defined by an LCP may be write-only to the MLM server.

For more information about LCP attributes, see Section 3.2.3.

Takes a cartridge out of a drive and returns it to a slot. The arguments to unmount are a drive name and a slot ID. The operation involves taking the cartridge from the drive and putting it into the given slot. Optionally, you can specify any for slot ID, and let the LCP choose where to return a cartridge. The LCP should send the corresponding changes in its slot and drive maps to the MLM server.

ALI/R commands are objects as far as ALI/R is concerned. When an LCP sends an ALI/R command, it associates a task ID with that command. The sender may refer to that command later by using the same task ID, but only to cancel the command. When the MLM server receives a command, it includes the task ID in command responses.

A text message to be entered into an MLM server-managed log, and perhaps displayed on some console by the MLM server, or one of its administrative applications.

Messages are associated with a severity level, or a level of urgency, which determines (along with site policy) whether the message text is stored in the MLM server logs, displayed on a library or OpenVault console for the operator, or both.

Refers to a text message of a given severity level.

Uniquely identifies a sender-generated command.

Sets and unsets named attributes in the MLM server, thereby creating persistent storage for whatever the LCP deems necessary. The MLM server simply stores these attributes; there are never any side effects of setting them. For background, see Section 3.1.3.

Prevents execution of a command that has already been queued in the MLM server but not yet started. The cancelled command returns response cancelled status, and the response for the cancel command itself follows.

---

Note: The cancel and response commands may not be cancelled.

---

Copies configuration information, especially about element map changes, from the LCP to the MLM server.

The MLM server stores a non-authoritative copy of all the element map information for all the LCPs it controls. Each LCP must use the config command in ALI/R to update the MLM server's copy of the element map information whenever it changes. The element map should change only as a result of administrator or operator actions.

In the full scope option, all information that the MLM server associates with the LCP is deleted and replaced with information listed in the config command. In the partial scope option, the MLM server replaces only pieces of LCP information that are listed in the config command.

Normally, the full scope option is employed at startup and when major changes to the library configuration occur, whereas partial scopeis employed when a cartridge movement operation happens. Very large libraries can initially use a partially populated full scope option followed by a series of partial scope commands, if this proves easier.

The config command does the following:

Tells the MLM server to end this session and clean up its end of the session. This protects against the accumulation of idle connections, since the MLM server has no way of detecting that an LCP exited other than the TCP/IP keepalive option. keepalive helps recover from process failures, but an LCP should send a goodbye before exiting to prevent unnecessary continuation of connection resources.

Sends a message of some severity level to the MLM server. The LCP loglevel attribute determines a limit on the severity level of messages sent to the MLM server. This command provides a mechanism for the LCP to send messages that the MLM server can convey to an operator and possibly a system administrator.

---

Note: This mechanism may change in future releases of OpenVault.

---

Tells the MLM server, along its variations, the current status of the library, and whether it is available for cartridge operations. Like the config command, the ready command is just a shorthand way of conveying attributes about ALI objects to the MLM server.

These are variations of the ready command:

See Section B.3 in Appendix B, for more information about ready states.

Acknowledges and indicates success or failure of an ALI command. The optional text portion of the response contains error details or command results.

Obtains the value of an attribute that the LCP previously stored in the MLM server.