An LCP can be thought of as a black-box language translator device and/or a device management module. The LCP is responsible for performing the tasks that the MLM Core asks it to do while efficiently managing the resources of the library. It speaks ALI with the MLM Core, and some device-specific language to the library itself. Examples of device-specific languages include: SCSI media-changer protocol, ADIC serial encoding, Storage Tek ACSLS, and EMASS DAS.
Here are some semi-formal descriptions of the assumptions that the OpenVault system makes about cartridge accessibility for any given LCP.
Note that under certain failure circumstances (eg: the bay in the middle stops working) this rule may not hold true, but this failure case should not be seen as a reason to change the definition of a library or how your LCP relates to it.
For example, a linked set of 5 silos with pass-through ports sufficient to move any cartridge to any drive in the complex must be controlled by one LCP. On the other hand, a set of 5 silos that do not have the required passthrough ports to move any cartridge to any drive must be structured as separate libraries with separate LCPs.
The MLM Core assumes that the LCP will do dependency analysis on the queued commands before it reorders them. The LCP must be able to handle move slot22 to slot12 followed by move slot12 to slot32 This has the net effect, when executed in the given order, of moving the contents of slot22 to slot32. If dependency analysis were not done and the commands were reordered, one command would fail and the cartridge would end up in slot12.
| mount and unmount |
Implementing the mount command for a library that has multiple
transfer agents (cartridge moving devices) that can operate simultaneously
may be the most significant determiner of LCP architecture.
If the interface to the library is a blocking interface,
you may be forced to have several cooperating processes.
For example, if once you start the command to the library your process may be blocked from executing until the command has completed, you will likely be forced to have multiple cooperating processes in order achieve any form of simultaneous operations and/or responsive interactions with the MLM Core. |
| move | The move command should be easy. |
| eject |
The eject command is likely to be extremely library dependent.
Deciding how to use the pair of eject and openPort
commands to get efficient and easy import/export of cartridges
for the target library is delicate.
The eject command identifies a cartridge to push out, and the openPort command prepares the library for physical access to the cartridge inventory. The basic semantics of those two commands cannot be changed, but the LCP writer is free to associate implementation-dependent responsibilities with each command as they see fit. For example, in some robotic libraries the eject command might bear most of the processing burden, while for another library, the openPort command might bear most of the burden. When a cartridge is ejected it must immediately and permanently disappear from the slotmap maintained in the MLM Core by the LCP. This implies that an LCP that cannot immediately push the cartridge out of the library must be prepared to persistently (ie: in the OpenVault database) store the fact that a particular slotID (and therefore PCL) has been marked for ejection and filter that PCL out of the slotmap that it pushes into the MLM Core. The LCP is free to mark a slotID as non-existent in order to accomplish this. The LCP must recall this information from the OpenVault database upon booting. |
| openPort |
The openPort command is likely to be extremely library dependent.
It prepares the library for physical access to the cartridge inventory.
It is used both in conjunction with the eject command in order
to accomplish cartridge export (see above)
and by itself in order to accomplish cartridge import.
The basic semantics of the command cannot be changed, but the LCP writer is free to associate implementation-dependent responsibilities with it as they see fit. |
| activate enable |
The activate enable command on small to medium libraries can be
implemented as a full scan of the PCLs in the library
(ie: a barcode inventory).
When the inventory has completed, the LCP should send the ready
command to tell OpenVault that it is now ready to accept cartridge operations,
then respond to the activate command itself.
It is likely to be common to poll small SCSI-based libraries looking for changes in library state. That polling should start when an activate command is received. At boot time, an LCP is assumed to be inactive in the sense of the activate disable command. On very large libraries with intelligent controllers, it may be necessary to implement a reliable cache of the slotmap on a local disk so as to avoid the penalty of rescanning all of the PCLs in such a library. Note that such a disk-based cache is highly discouraged. |
| activate disable | The activate disable command should turn off all communication between the LCP and the library. For example, it is likely to be common to poll small SCSI-based libraries looking for changes in library state. That polling should stop when an activate disable command is received. |
| config | Using the partial form of the config command implies checking the current slotmap information from the library itself and sending to the MLM Core only those slotIDs that have changed. This extra work is probably only justified on the largest libraries. |
| message | The LCP writer must decide on when to send a message to the operator versus the administrator, and what severity levels to associate with each possible error condition that the library can generate. There will be some guidelines for who to send the message to based on the assumed functions of the operator versus the administrator, and some guidelines for severity level based on the amount of interruption to library service that any given error can cause. |
| ready |
The ready command should be sent as soon as the LCP believes
that it and the library can respond to a cartridge movement operation.
An LCP is assumed to be inactive (as in the activate disable command) at boot time. The MLM Core will send an activate command when it believes this LCP should be controlling the library (remember that dual-ported robots are possible). The delay before sending the ready command is how we represent the time delay while we are scanning barcodes or doing any other start-time initialization that is required. |
| ready not |
The ready not command should be sent whenever the LCP
detects a condition that would prevent it from responding to a
cartridge movement operation, even if no such operation is currently present.
Queued commands at the time the condition is detected should be returned with an error. |
| attribute | The loglevel attribute affects the operation of the LCP. Parsing the set operation and then the value requires some work, but is required in order to allow the MLM Core to control the verbosity of status messages originating in the LCP. |
| show | Parsing the show command and responding to simple informational queries should be fairly easy. The attributes requested will likely simply be listed in a table along with their (implementation constant?) values. For example, the number of slots in a library may be a fixed constant depending only on the model of library. |
| cancel | The cancel command could be ignored by an LCP if the LCP writer were to completely single-thread the LCP. Ie: delay sending the ACK for the current command back to the MLM Core until the current command has completed executing. This will eliminate the need to have and manage a queue of tasks, at the expense of potentially slower response times. |
| response | The response statement is used to return the result or error status of a prior command received from the Core. |
| form factor | This will likely be simply an implementation constant. |
| slotID | This is probably just an appropriate sprintf()/sscanf() combination. |
| bayID | This is probably just an appropriate sprintf()/sscanf() combination. |
| messages | The text associated with a message command |