JPH03260719A - Library device - Google Patents

Abstract

PURPOSE:To omit the development of software for support of a library device by providing a virtual/real driving address corresponding table of a medium into a library controller. CONSTITUTION:A library controller 100 is provided with a corresponding table 101 where the virtual drive addresses are corresponded to the position addresses of a library cell of a medium are set opposite to the actual addresses of a drive 50 where the medium is set. A host device designates only the virtual drive addresses, and the controller 100 allocates the real drive address showing the drive 50 by reference to the table 101 and at the same time moves the medium corresponding to the due virtual drive address to an accessor 60. There fore, the accessor 60 can be hidden to the host device and the medium is actu ally moved under the control of the controller 100. Thus, it is not required to develop the software for support of a library device.

Description

[Detailed Description of the Invention] [Required by IIA] Regarding a library device that controls the movement of media between a cell and a read/write device, this document is issued by a host device for the purpose of eliminating the need for software development to support the library device. In the library device, the library control device t [
A correspondence table between a virtual drive address corresponding to a position address of a medium in a library cell and a real drive address indicating an address of a drive in which the medium is actually set is provided in the I device, and the library control device The correspondence table is indexed based on the virtual drive address indicated by the command received from the host device, the real drive address is assigned to the received virtual drive address, and the accessor is instructed to assign the real drive address to the received virtual drive address. The device is configured to issue instructions to move the corresponding media.

(Industrial Application Field) The present invention relates to a library device, and more particularly to a library device that controls the movement of media between a cell and a reading/writing device.

Some computer peripheral devices have media that can be replaced manually by the user, while others cannot.

Media that can be exchanged include those that can be exchanged manually and those that cannot be exchanged manually and must be exchanged using a handling robot.The latter is called a library device.

FIG. 5 shows a configuration diagram of a library system having this library device. In the figure, 10 is a central processing unit f (C
PU), 20 is a block multiplexer channel (BM
In C), input/output processing is performed independently of the CPU 10. 30
is a library device, and the library control device 40. Reading/writing device (drive) 50. It consists of an accessor 60 and a library self 0. Library control device ff401. In accordance with commands sent from the tBMc20, detailed control instructions are issued to the drive 50 and accelerator 'l1j60.

The drive 50 is a device that reads edge data recorded on a medium and polishes data on the medium. Also, accessor 6
0 is a handling robot that takes out a medium from a desired storage chamber of Library Self 0, which is a warehouse that stores media in a plurality of storage chambers, moves it, loads it into the drive 50, and reads or writes it. The medium that has been read and written is taken out from the drive 50, and moved and stored in the original storage room of the library self 0.

In a library system with such a configuration, cp
It is required to minimize development changes in the uio software.

[Conventional technology]

Figure 6 shows library control [l] in a conventional library device.
A configuration diagram of an example of a device is shown. In the same figure, 41 is 8MC20
42 is a data buffer, and 43 is a drive interface, which interfaces between the buffer 42 and the drive 50.

When a read (READ) command is issued, the buffer 42 receives data read by the drive 50 via the drive interface 43 and transfers it to the 8MC20 via the channel interface 41. When the (WRITE) command is issued, data transferred from the 8MC 20 via the channel interface 41 is input, and this data is transferred via the drive interface 43 to the drive 50. This buff? The operation of 42 is controlled by commands input from a microprocessor (MPU) 45 via a variable controller 44.

The MPU 45 controls the entire library control device 140, and controls the back 742 via the buffer control unit 44, and also controls the back 742 from the 8MC 20 to the channel interface 4.
Interprets and executes commands sent via 1.

Instructions for operating the MPU 45 are stored in the control storage section 46 as microcode.

When the MPU 45 receives the command, it transfers the command to the drive 5.
When it is interpreted as an instruction for 0, it sends a detailed instruction to the drive 50 via the drive interface 43, and on the other hand, when it is interpreted as an instruction for the accessor 60, it sends a detailed instruction to the accessor 60 via the accessor interface 47. Send.

Next, the operation of the conventional library device will be explained with reference to the command processing sequence diagram of FIG. 7 and the like. From the perspective of the CPU 10, which is a host device of the library device 30, the drive 50 and the accessor 60 each have a device number, and different device numbers are assigned under one library control device @40. Commands for the drive 50 include read and write commands, and the accessor 6
Among the commands for 0, there is a move (MOVe) command. There are other commands besides these, but they are not necessary for this explanation, so they are omitted. Here, the case of read command processing will be explained. In write command processing, the data transfer direction is simply opposite to that of the read command.

Note that normally the locate (LO) command is executed before the read command.
CArE) command is provided, and the locate command specifies how many blocks of data are to be read from which address on the medium.

First, the CPU 10 issues a move command to the accessor 60 (step 71 in FIG. 7). This move command usually consists of a 4-byte parameter as shown in Figure 8, and the first 2 bytes are the original medium position address 9.
1, and the remaining two bytes indicate the destination medium address 92. Here, the move command indicates the drive 50 where the original medium location address 91 is address X of library self 0 and the destination medium address 92 is address Y. Note that in normal usage, the parameters of the above move command are from library self 0 to drive 50. Although it is from the drive 50 to the library self 0, it may be from the drive to the drive or from the library cell to the library cell.

By issuing the move command in step 71 above, the library control device 40 sends a control command to the accessor 60 to move the medium in the storage chamber at address X of library self 0 to the drive 50 at address Y. When the movement of the medium ends, the CPU 10 is notified of the end of the command (step 72 in FIG. 7). drive 50
Since the medium has been inserted, the medium is made readable/writable, and then a not ready-to-ready message is sent to the library III control device 40.
to Ready) interrupt (step 7
3) The library control device 40 handles the interrupt as 8MC.
20 (step 74).
.

CPLJlo issues a command to the drive 50 using the locate read command chain (step 75).
If the medium is an optical disk, after performing seek and rotation operations on the drive 50, transfer the data of the medium read by the drive 50, and notify the end of the command after transferring the data. (Step 7
6).

Based on this command completion notification, CPIJlo stops the rotation of the medium to the drive 50 and transfers the medium to the drive 50.
A command (dismount command) for making it possible to take out the library is issued to the library control device 40 via the 8MC 20 (step 77).

Library! The 1III\Al 140 executes this dismount command, enables the medium to be removed from the drive 50, and notifies the CPU 10 of the completion of the command via the 8MC 20 (step 78).

As a result, CPLJlo issues a move command to the library control m+ device 40 via the 8MC 20, indicating that the parameter is to move the medium from the drive 50 at address Y to address X in library self 0 for the accessor 60 (step 79 ).

Based on this move command, the library control device 40 waits for the end of the movement of the medium and notifies the CPU 10 of the end of the command (step 80).

[Problem to be solved by the invention]

However, the above-mentioned conventional library device has a CPU of 10
The movement of the accessor 60 is controlled based on the move command from the library device 30.
In order to support it with O8 (operating system) of PU10, it is necessary to make considerable modifications to the software of the CPU 10, and as a result, there is a disadvantage that the inability of the software increases.

The present invention has been made in view of the above points, and an object of the present invention is to provide a library device that can eliminate the need for software development to support the library device.

[Means to solve the problem]

FIG. 1 shows a basic configuration diagram of the present invention. The present invention is based on a library system m+ system [100, drive 50. In a library device consisting of an accessor 60 and a library self 0, a correspondence table is provided in the library system all device 100 between a virtual drive address corresponding to a position address of a medium and a real address indicating the address of the actual drive in which the medium is set. 101, and a library control fl device 10
0 allocates a real drive address to the received virtual drive address by indexing the correspondence table 101 based on the virtual drive address indicated by the command received from the host device,
The medium corresponding to the received virtual drive address is set in the drive 50 of the real drive address.

[Effect]

The higher-level device of the library device specifies only the virtual drive address indicating the medium to be recorded/reproduced by the drive 50. Thereby, the library control device 100 refers to the correspondence table to allocate a real drive address indicating the drive 50, and moves the medium corresponding to the virtual drive address to the accessor 60. Therefore, in the present invention, the accessor 60 can be made invisible from the host device;
The library IIIt [] device 100 performs the actual movement of media.
This can be done based on control by.

[Example] Figure 2 shows libraries t and II l that form the main part of the present invention.
[A configuration diagram of an embodiment of the present invention is shown.] In the figure, the same components as in FIGS. 1 and 6 are denoted by the same reference numerals, and their explanations will be omitted. This embodiment is an example of an optical disk library, and the real drive is one of the drives 50, and the library self-drive is 0.
The following description will be made assuming that each of eight cells (storage chambers) contains an optical disk. The virtual drive/real drive correspondence table 101 in FIG. 2 is indexed (referenced) by the MPU 45.

Next, the command processing sequence and the contents of the correspondence table 101 according to this embodiment will be explained with reference to FIGS. 3 and 4. In the initial state, it is assumed that no medium is set in the drive 50 yet. In this case, correspondence table 1
As shown in FIG. 4(A), 01 corresponds to the virtual drive address on a one-to-one basis with the cell address of library self 0.
In addition, since no medium is set in the drive 50, all virtual drive addresses are invalid, and correspondence between virtual drive addresses and real drive addresses has not yet been established.

In this state, when a command is issued to a predetermined virtual drive from a CPU not shown in FIG. The real drive correspondence table 101hl is searched for a cell address corresponding to the input virtual drive and a real drive address that is not currently in use (step 112). Here, for example, if virtual drive 2 is activated, the cell address of cell 2 can be found from the correspondence table 101 shown in FIG. Since it is not allocated, library control 1
The device 100 has real drive 0 (this is 1) in virtual drive 2.
1). The unity and correspondence table 101 is shown in Figure 4 (
8) is changed as shown in FIG.

Here, since the received command is a locate read, the library control device 100 uses the accelerator +J6 shown in FIG.
A command is sent via the accessor interface 47 in FIG. 2 to transfer the medium in cell 2 to cell 1 to the drive 50 at the address of real drive O (step 113 in FIG. 3).

When the above medium is loaded by the accessor 60, the drive 50, which is the real drive 0, performs loading,
When the steady rotation is reached and read/write 1~ is enabled, a ready-to-ready interrupt is made to the library control device 100 (step 11 in Fig. 3).
4).

When the library controller 100 receives an upper interrupt from the drive 50, it sends the seek address and the block address of the read data to the drive 50, instructs the drive 50 to start the operation, and thereby causes the drive 50 to move the read head to the target block. The data is transferred to the CPU 10 via the 8MC20 in FIG. 5 where the transferred data is recorded (step 115 in FIG.
).

When the execution of the command is completed, the library control device 100 shown in FIG. 2 issues a dismount command to the drive 50 to stop the rotation of the motor of the drive 50 and unload the medium in the drive 50 so that the medium in the drive 50 can be removed.
and also notifies CPLJ of the end of the command (
Step 116 in FIG. 3).

The library control device 100 then sends a command to the accessor 60 of FIG. When the medium is moved from the drive 50 to the library self 0 and the completion of the movement is received from the accessor 60, the contents of the correspondence table 101 are returned to the state shown in FIG. 8MC20 to notify CPU10 (step 117 in FIG. 3).

In this way, according to this embodiment, it appears to the CPU 10 that there are as many drives 50 as there are media, and by simply instructing the virtual drive address, the library control device 100 is in charge of actually controlling the accessor 60. Since this is done based on the correspondence table 101, a new library device software!・The library device can be made usable without developing.

If another virtual drive is activated while the accessor 60 is moving with a medium on it, the library control device 100 responds with a CPU heavy status while the accessor 60 loads the medium. After returning to the original cell address 2 of library self 0, a busy-to-free report is sent to the CPU immediately after the command completion report.
send to

Although the present embodiment has been described with one drive 50 (actual drive), two or more drives may be used, and in that case, the plurality of drives 50 are sequentially used in a predetermined order.

〔Effect of the invention〕

As described above, according to the present invention, accessors and library cells are obtained from the software of the central processing unit.

Since the real drive is hidden from view and the library control device actually moves the accessor, it is no longer necessary to issue the move command that was previously required, and it is now necessary to υ vote the library Hfl with O8 of CPLJ. It has the advantage of being able to prevent

[Brief explanation of drawings]

Figure 1 is a diagram of the principle configuration of the present invention. Figure 2 is a diagram of the configuration of an embodiment of the main parts of the invention. Figure 3 is a command processing sequence diagram of an embodiment of the invention. Figure 4 is a correspondence table. 5 is a configuration diagram of a library system, FIG. 6 is a configuration diagram of an example of a conventional library control device, and FIG. 7 is a command processing sequence diagram of an example of a conventional 5A system. FIG. 8 is a diagram showing the format i- of the move command parameters. In the figure, 50 is a drive, 60 is an accelerator v1, 70 is a library cell, 100 is a library control device, and 101 is a virtual drive real drive correspondence table. Command processing of the embodiment of the present invention/-Kens diagram Figure 3 Figure 8 shows the formant of Bukoma/TonoP-lameta Figure 8 Figure 8 shows how the contents of the correspondence table change

Claims (1)

[Scope of Claims] A command issued from a host device is received, and the library control device (100) interprets the command. Based on the result, the accessor (60) moves the medium to the drive (50).
) or to a library cell (70), the library control device (100) contains a virtual drive address that corresponds to the position address of the medium in the library cell (70), and the location where the medium is actually set. A correspondence table (101) indicating the address of the drive (50) to which the library control device (10) is stored is provided.
0) indexes the correspondence table (101) based on the virtual drive address indicated by the command received from the host device, allocates the real drive address to the received virtual drive address, and
A library device characterized in that the library device sends a command to move a medium corresponding to the received virtual drive address to the library device.