JPH028928A - Data buffer control system - Google Patents

Abstract

PURPOSE:To efficiently use a data buffer area without increasing the overhead of a program by expanding and preferentially only assigning specific data buffer areas in corresponding to the number of peripheral devices in workable states. CONSTITUTION:Only magnetic tape driving devices (MTU) 9 in workable states are connected to a magnetic tape controller (MTC) 10. The MTC 10 divides its buffer 5 into segments by the number of the MTUs 9 connected to the MTC 10 and assigns the segments to the MTUs 9. Therefore, the memory area of the buffer 5 can be utilized to the maximum. In this case, the number of the MTUs 9, the working controlled by a host system, is forcibly limited and the data buffer area is assigned to the limited number of MTUs 9 in workable states only so that the utilizing efficiency of the buffer 5 can be improved further. In addition, it is also possible to preferentially designate expansion of the segment size to be assigned to the buffer 5 or a specific segment size to a specific segment by setting the hardware at the time of installation or by means of commands from the host system.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a technique that is effective in efficiently using a data buffer in a peripheral subsystem such as a magnetic tape device equipped with a data buffer.

[Conventional technology]

In recent years, in subsystems such as magnetic tape drives, in order to compensate for the low drive performance of the tape due to the removal of the vacuum column, a data amount/nof has been set up between the host system and the tape drive to reduce the number of writes per write. /The processing capacity is improved by processing multiple data blocks in a punch-like manner during a read operation. In addition to this, the input/output of the data blocks to the data buffer is performed asynchronously and independently from the host device, thereby controlling input/output while allowing multiple data blocks of different tape drives to reside on the data buffer. has been adopted.

In a system configuration including such a data buffer, how to efficiently allocate the data buffer space to each tape drive device has become an essential consideration in order to improve processing efficiency.

As such a data buffer control method, the following two methods are used.
Two methods are common.

The first method is to fixedly allocate segments equal to the number of all tape drive IIII devices in advance, and is the most common method among this type of data buffer control method.

The second method, as described in Japanese Unexamined Patent Publication No. 57-152028, is a method in which each segment is dynamically assigned to a plurality of tape drive devices by a microprogram.

[Problem to be solved by the invention]

However, according to the first method, segments are fixedly allocated, even for tape drives that are not actually in operation, which results in wasted data buffer area on the sofa due to the amount of data. For example, even if the number of tape drives in operation is small, the result is a wait for free data buffer space, and it cannot be said that efficient data/(tape) usage is realized. .

Regarding this point, according to the second method, the size of each segment is adjusted by microprogram control, so there is flexibility, and efficient use of the data/Nl area is possible. However, in this method, when conflicts occur between segments due to changes in the amount of data, this is adjusted using microprogram software, which has the disadvantage of increasing microprogram overhead. .

The present invention has been made by focusing on the above three problems,
The purpose is to provide a technique that can realize efficient use of data buffer area without increasing microprogram overhead.

The above-mentioned objects and novel features of the present invention will become apparent from the description of the present specification and the accompanying drawings.

[Means to solve the problem]

A brief overview of typical inventions disclosed in this application is as follows.

That is, a means for detecting whether or not the peripheral device is ready for operation in the peripheral control device, a means for allocating a data buffer based on the detection result, a control means for controlling the allocation process, and a specific one. or means for notifying the control means of the allocation amount or allocation priority of data buffer areas for two or more peripheral devices, and only a specific data buffer area that corresponds to the number of peripheral devices that are ready for operation. This is a data buffer control method that expands or preferentially allocates data.

[Effect]

According to the above-mentioned means, since it is first detected whether the peripheral device is in the operable state, there is no need to wastefully allocate data buffers to the peripheral device in the power-off state, and data buffers for the peripheral device in the operable state are not allocated. At the time of allocation, the control means is notified of the allocation amount or allocation priority of the data buffer area of a specific peripheral device, so that flexible data buffer allocation is possible without increasing overhead in the microprogram.

〔Example〕

FIG. 1 is a conceptual diagram showing a system configuration for realizing a data buffer control method in hardware, which is an embodiment of the present invention, and FIG.
Conceptual diagram of a data buffer in a virtual peripheral subsystem consisting of one peripheral control device and n peripheral control devices, Part 3
The figure shows two magnetic tape control devices and 16 in this embodiment.
A conceptual diagram of data buffer division in a cartridge-type magnetic tape subsystem consisting of a magnetic tape drive unit and a magnetic tape drive device. Figures 4 (a) to (C) are example models showing the state in which the data buffer is divided into segments of variable length. 5 is an explanatory diagram showing the data buffer management table managed by the microprocessor, and FIG.
An explanatory diagram showing the internal structure of the data buffer management table shown in the figure, FIG. 7 is an explanatory diagram showing the MTU management table managed by the microprocessor, and FIG.
An explanatory diagram showing the MTU monitoring register included in the U monitoring circuit, and FIGS. 9 to 16 are flowcharts showing the procedure of data buffer control according to the present invention, respectively.

First, prior to a specific explanation, the concept of a method for dividing data buffers in peripheral subsystems in this embodiment will be briefly explained. FIG. 2 shows a data buffer 1 in a virtual peripheral subsystem consisting of m IOCs (peripheral control devices) 102 and n 00 (peripheral devices) 105.
This shows the division concept of 03. In the figure, it is assumed that m units of l0C102 and n units of l0U105 are all powered on, and each IoU105 is connected to any one of l0CID2 by control line 104. .

Under such a system configuration, the data buffer 103 for each l0C 102 is divided into m/n segments (SEG
), there will be n routes.

This means that a storage area is secured on the data buffer 103 for all of the data buffers 103 and 5, and the data buffer 103 can be used efficiently.

As a specific example, FIG. This shows the division. The functions of MT[J9 and MTClo, 10 will be explained below.

All MTUs 9 are connected to both MTCs 10 and 10' by control lines 20, but MTCIo
, normally on the 10° side, for example, MTC10 is MTU#O
~#7, MTCI O' is MT U#8~#15,
The share of the MTU 9 to be connected is determined by a certain agreement.

Therefore, for example any MTC 10 or 10'
Even if one of the MTU9 is powered off due to some reason such as a failure, all MTU9 (#0 to #
15) can be accessed.

The connection mode between the above MTU9 and MTC10 is ■MTC
Connection status with IO, ■Connection status with MTCIO°, ■
A state in which it is not connected to any MTClO, 10° (hereinafter simply referred to as the "neutral state"), and ■ a power supply O
It is divided into four modes of FF state, and each of these states is constantly monitored by the MTC 10.

Here, one MTCIO (10°) whose share is determined is preferentially connected to the above MTU9, and the other MTCIO' (
10) can be cut off.

In addition, for MTU 9 other than the one assigned to it, it detects whether or not it is connected to the other MTCl Oo (10), and if it is in an unconnected state, that is, in a neutral state, it It is possible to connect the above MTU9 to (MTCIO (10'')). Since such control is possible, for example, it is possible to maintain the other MTCIO' in the power OFF state and turn one MTCIO off. ○
In case of N state, 16 MTs with MTC10 only
It is also possible to have all of U9 (#O to #15) in a connected state.

Note that when one MTClO is in an operating state and the other MTC 10° changes from power OFF to ON state, it is possible to detect this on the MTC 10 side, for example, as follows.

That is, when one of the MTCs 10 is in operation,
MTU 9 in a neutral state not connected to the MTC 10
exists, the other MTCIO" is powered off
→When the state changes to ON, MTU9 in the above neutral state
is connected to the other MTCIO and becomes the root. As a result, the MTU9 changes from the "neutral state" mode to the "MTC10" mode.
The connection status with MTCIO is switched to "connection status", and the connection with MTCIO is cut off.
When CIQ detects that the connection between itself and the MTU9 is cut off, it turns on the power of the other MTU9.
Able to recognize the condition.

On the contrary, the other MTC10' is powered ON-〇F.
Even when the state changes to F, one MTCIO changes the MTU9 to which it is not connected from the blocked state to the “neutral state”.
It can be recognized by switching to the mode.

In the above explanation, we have explained the case where the power-on work on the MTU9 side has already been completed in the power-up sequence stage at 08 o'clock of the power supply of MTCIo, 10°, but at this time there is an MTU9 that is in the power-off state In this case, when the MTC 1010' attempts to connect the IMTU 9, it recognizes the power OFF state of the MTU 9, so it is possible to skip to another MTU 9 without connecting to the MTU 9. Therefore, M.T.C.
Inside the Io, 10', an unnecessary data buffer area (5) for the MTU 9 of the power supply FF state is not secured.

From the above explanation, only the MTU9 that is ready for operation is connected to the MTCIO, and the MTCIO that is connected to itself
By dividing and allocating the data buffer 5 into segments as many as the number of U9s, it is possible to make maximum use of the storage area of the data buffer 5. At this time, it is also possible to forcibly limit the MTUs 9 whose operation is controlled by the host system and allocate data buffers only to the limited MTUs 9 that are in an operable state, further increasing the usage efficiency of the data buffers 5. be able to.

Furthermore, MTUQ
It is also possible to specify that the segment size allocated to the data buffer 5 in the data buffer 5 is to be enlarged preferentially only for a specific segment, or to specify the segment size itself at that time.

Examples of the data buffer 5 divided as described above are shown in FIGS. 4(a) to 4(C).

Figure (a) shows the configuration inside the data buffer 5 of the MTC 10, in which MTCIo, 10' and 16
This is an example of the basic configuration when all of the MTUs 9 (#Q to #15) are in the power ON state. Here, 8 MTU9s (#0
~#7), the data/< buffer 5 is equally divided into eight segments.

In the same figure (b), only one MTClo is in the Ni0N state, the other MTCIO' is in the power OFF state, and M
TU9 (#O to #15) are all in the power ON state. Here, since the other MTCloo is in the power OFF state, the data buffer 5 in one MTCloo is in charge of all 16 MTU9s (#0 to #15), and the state is evenly divided into 16 segments. It has become.

Figure (C) has the same settings as Figure (a), but
A specific segment (segment D) within the data buffer 5 is enlarged preferentially over other segments (1 to 7) due to hardware settings at the time of installation or commands from a host system.

Next, a hardware configuration for performing the data buffer control described above will be described.

FIG. 1 shows an example of the system configuration in this embodiment, and includes a CPU (main control unit) 1, a main storage device 2, a pair of channels 3, 3, and MTCIo, 10 connected to this. ' and multiple MTU9.

The CPU 1 and the main memory device 2 are connected by a control line 11 and a bus line 12, and the main memory device 2 and the channel 3
, 3° are connected by bus lines 13 and 13', respectively.

In the figure - MTClo, 1 indicated by the area surrounded by a light chain line
0° is the control line 24.2 for channels 3 and 3 above.
4' and bus lines 14 and 14', respectively. On the other hand, for each MTU9, bus line 1
7, 17'' and control lines 20, 20'.

In the internal configuration of the MTCI 0, 10°, the microprocessor 7 as a control means is a part that performs basic control in this embodiment, and uses the data on the memory 8 and controls the CPU via control lines 18, 20° 21. Controls the side transfer circuit 4, the MTU side transfer circuit 6, and the MTU 9.

In the figure, a memory 8 is accessible from the microprocessor 7 via a bus line 19, and the memory 8 contains microprograms as well as various tables such as a data buffer management table 50, an MTU management table, etc., which will be described later. types are stored.

The data buffer 5 includes the CPU side transfer circuit 4 and the MTU
It is connected to the side transfer circuit 6 via bus lines 15 and 16, respectively, and functions as a data buffer that temporarily stores the transferred data during data transfer between the channel 3 and the MTU 9.

The microprocessor 7 can independently start the CPU-side transfer circuit 4 and the MTU-side transfer circuit 6 using the control lines 18 and 21, and both transfer circuits 46 are capable of starting up the CPU-side transfer circuit 4 and the MTU-side transfer circuit 6 using the control lines 18 and 21. between data buffer 5 and channel 3, and data buffer 5
It is possible to perform data transfer between the MTU 9 and the MTU 9 simultaneously and in parallel. therefore,
After the microprocessor 7 gives a startup instruction to each of the transfer circuits 4 and 6, it is released from these data transfer processes. Completion of data transfer to the microprocessor 7 is notified from both transfer paths 4 and 6 via control lines 18 and 21. Note that the microprocessor 7 can also directly access the data buffer 5 via the control line 30.

The bus line 22 and the control line 23 are for communicating between the microprocessors 7.7 in each MTCI010', and through this communication, for example, the channel 3 connected to one MTC10 and the It is possible to transfer data to and from the data buffer 5 of the other party, and to mutually recognize the operating status of the other party.

The installation register 25 is a register for storing information regarding option settings and operation mode settings of the sub-system, and the content settings for the installation register 25 can be directly input by an operator during sub-system installation work or maintenance work, for example.・It is possible to confirm. Furthermore, the contents once written are retained until the power source is turned off. The contents of the installation register 25 manually entered as described above are read out by the microprocessor 7 via the control line 26 at any time.

The MTU monitoring circuit 28 connects each MTU 9 through the control line 27.
Every 7ji #i state (ON or OFF), MTCIo,
It has a function of monitoring the connection state with the microprocessor 10' and notifying the microprocessor 7 of this information via the control line 29, and is provided with an MTU monitoring register 80, which will be described later.

Next, the configuration inside the memory 8 will be explained using FIGS. 5 to 8.

FIG. 5 shows a data buffer management table 50 in the memory 8 managed by the microprocessor 7, and is composed of the following fields.

That is, "data buffer status" 51 indicates the operating status of the data buffer 5, and "data buffer status" 51 indicates the MTU 9 connected to the data buffer 5.
"self-connected MTU" 52, "reconfiguration ready MTU" 53, which indicates an MTU that is ready for reconfiguration; "segment size 54, which indicates the segment size per MTog;
The above-mentioned installation register 25 or host device (C
It consists of a "segment specific MTU" 52 indicating the MTU 9 specified to give priority to the allocated segment by P Ul), and a "segment specific size" 56 indicating the segment size at this time.

FIG. 6 shows a more detailed structure of the "data buffer status" 51 in the data buffer management table 50, and includes, for example, a 1-bit "waiting for reconfiguration" indicating that the data buffer 5 is waiting for reconfiguration. ``Contains 60.

FIG. 7 shows the configuration of an MTU management table 70 formed in the memory 8 similarly to the data buffer management table 50 described above. The MTU management table 70 is the MTU
Although table areas for all 16 MTUs 9 are prepared regardless of the connection status of the MTUs 9 or the power ON/OFF state, only the configuration of the MTU management table 70 for one MTU 9 will be explained as a representative.

In other words, the field configuration is "M T
"U status" 71, "Segment start address" 72 indicating the start address of the allocated segment, "Segment end address" 73 also indicating the end address, "Command code 74" indicating the command code received from the upper system (CPUl), etc. It consists of

FIG. 8 shows the internal configuration of the MTU monitoring register 80 included in the MTU monitoring circuit 28.
It is composed of a plurality of fields each indicating the connection state with the TC 10.

That is, in FIG. 8, a "power OFF state" 81 indicates the power state of the MTU 9, a "neutral state" 82 indicates that the MTU 9 is in the power ON state and is not connected to any MTClo, 10", and MTC10' on hand
It consists of the following bits: ``Connect to other party's MTC'' 83, which indicates that the blade is connected to (10), and ``Connect to own blade's MTC'', which indicates that it is connected to the own blade's MTCIO (10'). Each bit is set or reset depending on each situation.The above-mentioned MTU monitoring circuit 28 notifies the microprocessor 7 of this change in status.Therefore, the microprocessor 7 detects the changes in the bits. This makes it possible to recognize changes in the connection state of the MTU 9.

Next, the data buffer control procedure by the microprocessor 7 will be explained using FIGS. 9 to 16.

FIG. 9 is a flow diagram showing the initial data buffer allocation process when the MTCIO is powered off and turned on.

That is, at the stage when the MTC 10 is turned on,
First, MTU initial connection processing (step 901) is executed.

Details of this MTU initial connection processing are shown in FIG. That is, in FIG. 10, MTUs that share connections for each predetermined MTC (for example, MTClo is MTU#0~
#7, MTC10' indicates the process of detecting the status of MTU9 based on MTUs #8 to #15, etc.).

That is, first, the microprocessor 7 has its own (MTCI)
The contents of the MTU monitoring register 80 are taken in with respect to the MTU 9 that O) is assigned to, and it is detected whether or not the MTU 9 is in a power OFF state (step 1001).

At this time, if the power is ON, connection with the target MTU 9 is executed via the control line 20 (1
002). As a result, the "connect to own blade MTC" bit 84 is set in the MTU monitoring register 80 for the MTU 9 in hardware. Furthermore, the MTU9
In order to remember that the MTU 9 is connected to the MTC 10, a bit of the MTU 9 is set in the "self-connected MTU" 52 of the data buffer management table 50 (1003).

In addition, for the microprocessor 7, the target MTU 9 is the power supply ○F.
If it is in the F state, no connection is made to the MTCIO.

This means that it is not necessary to allocate data to the data buffer 5 because data cannot be transferred to the MTU 9 in the power-off state. Such processing can prevent unnecessary storage areas from being created on the data buffer 5. All MTCs 9 (MTU #O to #7) whose own MTC 10 shares the above processing are checked (1004). Next, microprocessor 7
is an MTU (#8 to #15) that is not shared by itself (MTCIO), that is, is shared by the other party (MTCIOo).
), the contents of the MTU monitoring register 80 are read, and it is checked whether it is in a neutral state (power ON and not connected to either the MTC 10 or 10°) (1005). Here, when the relevant MTU is in the neutral state, due to factors such as the power of the other MTCIO' being in the OFF state, the connection with the M'I'CIO° that should originally be shared is not being made. ,
Executes connection with own MTCIO (1006.10
07). These connection processes are performed in the same manner as steps 1002 and 1003 described above. Also applicable MT
When U is not in the neutral state, it is connected to the other party's MTC 10° or the corresponding MTU is in a power OFF state, so it does not connect to its own MTC 10. MTC9 where such processing is shared by the other party's MTCIOo
Check all of (#8 to #16) and (100
8) Complete the MTU initial connection process.

After completing the MTU initial connection process as described above, return to FIG. 9 and transfer the contents of the "self-connected MTO" 52 determined in the above process to the work register A (not shown) set in the CPU side transfer circuit 4. Import (902). This work register A is set by the number of MTUs 9 connected in the above process.

Subsequently, segments within the data buffer 5 are allocated, but here, the data buffer 5 is first equally divided by the number of MTCs 9 connected to itself (MTCIO). That is, first, the segment size per MTC 9 is calculated by dividing the total data buffer size by the number of working registers A set above (903). The start address of the data buffer is fetched (904), and then whether there is something in the installation register 25 that specifies the segment to be allocated (is there something to preferentially enlarge the segment) or something that specifies the segment size to allocate? Check if there is one (905).

There is something to specify the above segment (906)
, and if it exists in the work register A set above (907), segment identification processing (90
Execute 8). The procedure of this segment specifying process will be explained below using FIG. 16.

In this process, first, after determining the segment start address for the specified MTC9 (1601)
, if it is determined that the segment size has been specified (<1602), the segment furthest address is determined based on the specified segment size (1603). Subsequently, the segment start address of the MTC 9 to be assigned next is calculated (1604), and the segment specifying process is completed. On the other hand, if the segment size is not specified (1602), the segment size already calculated by equal division in step 903 of FIG. 9 is multiplied by a predetermined value (
In this figure, an expanded segment size (in this figure, it is doubled as an example) is allocated (1605), and the segment start address of the allocated MTC 9 is calculated (1606), and the segment specifying process is completed.

In this figure, a case is described in which segment identification processing is performed for only one MTC 9, but it is also possible to perform segment identification processing for a plurality of MTC 9 through similar processing.

After the segment specifying process described above is completed, return to FIG. 9 again and use the corresponding M The one corresponding to T U is deleted (909). As a result, if there are no more MTC9s to be allocated (work register A-0), the process ends (910). On the other hand, if there is still MTU9 to be allocated (working register A
≠0), the remaining data buffer size is divided by the number of working registers A to calculate a new segment size that is evenly divided (911).

After determining the segment end address (912°913) and segment start address (914) in the remaining equally divided data buffer area,
The contents of the corresponding work register are deleted (915).

The above processing is performed on all remaining working registers, that is, MT
After repeating U9, the initial data buffer allocation process is completed when the value of work register A becomes 0.

An example of a data buffer allocated in this way is shown in FIG. 4(C), in which only segment 0 is specified and enlarged preferentially compared to other segments 1 to 7. ing.

When the initial data buffer allocation process described above with reference to FIG. 9 is completed, the data buffer control according to this embodiment is shifted to the scan process shown in FIG. 11.

The scanning process is characterized in that the operating status of each MTU 9 is monitored, and if there is a change in these MTUs 9, the data buffer 5 is reconfigured. This scanning process will be explained below with reference to FIG. 11.

In the scan process, it is first determined whether the state of the data buffer is in the reconfiguration waiting state (described later) (1
101). In other words, when it is in the reconfiguration waiting state, the next MTU state change monitoring process (1102) is skipped to prevent setting a new reconfiguration waiting state. Specifically, in this MTU state change monitoring process (1102), the following process is performed. The outline of the MTU status change monitoring process (1102) will be explained below using FIG. 12.

The MTU monitoring circuit 28 constantly monitors the status of each MTU 9 (1201), and when a change is detected here, it checks the MTU monitoring register 80 described in FIG. 8. Such a change is detected by the microprocessor 7, for example, when a bit (not shown) in the MTU monitoring register 80 is set to "state change detected". At this time, if there is any change, the uMTU9 will change its own MTCI.
Determine whether or not it is possible to connect to the O side (1202), and if this is not possible, “Connect to the other party’s MTC” 83 or “
This means that the power OFF state has changed to "81",
The "self-connected MTU" 52 of the data buffer management table 50 shown in FIG. 5 is reset (1203), and the reconfiguration waiting state, that is, the "reconfiguration ready MTU" 53 is set (1207). On the other hand, if it is determined in step 1202 that it is possible to connect to its own MTC 10, it is determined whether or not it is in the "neutral state" 82.
04), if it is in the “neutral state” 82, the target MTU9
is connected to its own MTC 10 (1205), and the “0-connected iMTU” 52 of the data buffer management table 50 is set.
(1206). Check the above process for all MTU9 whose status has changed (1208),
The “state change occurred” bit (not shown) in the MTU monitoring register 80 is reset via the control line 29 (12
09).

After the above MTU status change monitoring process (1102) is completed, the activation detection shown in FIG. 11 is performed. That is, the microprocessor 7 detects activation of channel 3 through the control line 24 (1103).

If activation of channel 3 is detected here, it is detected whether it is in a reconfiguration waiting state (1104)
. Here, reconfiguration means resetting the data buffer 5, and in the case of waiting for reconfiguration, command retry processing (1106) is performed via the control line 24 until the reconfiguration processing is completed. Activation of channel 3 is reserved.

If it is not in the state of waiting for reconfiguration, it accepts the command and starts executing it (1104). Next, the command reception execution process (1104) will be explained using FIG.

In the command reception execution processing (Fig. 13), the command is first stored in the command code "74 on 0 on the MTU management table (1301). Next, the contents of the received command are analyzed and this is If it is a data buffer control command that specifies an allocated segment (1302), MTU 9 according to the command is set as “segment specific MTU” on the data buffer management table 50.
55 (1303), and if there is a segment size specification (1304), the specified segment size is registered in the "segment specific size 56", and a reconfiguration wait state is set (1306). ), I
Finish. Note that in step 1302, if the command is other than a data buffer control command, known processing is executed, but its details will be omitted. After the above command acceptance execution processing (1105) is completed, it is determined again whether or not it is a reconfiguration waiting state and a bear (1105).
07), if the state is waiting for reconfiguration,
It performs reconfiguration preparation processing for all MTUs 9 to which it is connected (1108, 1109). Here, the reconfiguration preparation process is performed according to the procedure shown in FIG.

That is, in the reconfiguration preparation process (FIG. 14), first, among the MTUs 9 connected to itself, an arbitrary MTU 9 for which reconfiguration preparation has not yet been completed is checked (1401). That is, if it is checked that there is no data in the data buffer 5 (1402), the reconfiguration ready state is set without performing any preparation operation.

On the other hand, if data exists in the data buffer 5, it is determined whether it is read data (RD) or write data (WD) (1403).

“Command code” 74 of MTU management table 70
If it is write data (WD), wait until all data is written on the tape of MTU 9 as a reconfiguration preparation process. On the other hand, if it is read data (RD), the operating state of the CPU side transfer circuit 4 is checked using the control line 18 (1404), and if it is operating, the data is transferred to channel 3 as a reconfiguration preparation process. Wait for the transfer to complete. Further, when the CPU side transfer circuit 4 is not in an operating state, the data existing in the data buffer 5 is regarded as so-called pre-read data, the tape position of the MTU 9 is returned by the amount of data, and the reconfiguration preparation process is completed (1406 ).

Next, in step 1108 of FIG. 11, self (
When preparations for reconfiguration of all MTUs 9 connected to the MTCIO) are completed, reconfiguration processing (1110) is performed.

The processing procedure of the reconfiguration process (1110) will be explained using FIG. 15.

In the reconfiguration process, data buffers 5 are first allocated equally to each MTU 9, similar to the initial data buffer allocation process described in FIG. That is, MTU 9 is ready to reconfigure all data buffer sizes.
The single data buffer size is calculated by dividing by the number of devices (1501). Furthermore, after once determining the start address of the data buffer (1502), it is determined whether the "segment specific MTU" 55 exists or not, and whether it exists in the "reconfiguration ready MTU" 53. (1503, 1504), and if these conditions are met, segment identification processing (150
5) is executed. This segment identification process (1505
) is the same as that explained in FIG. 6 above, so the explanation here will be omitted.

After the above segment specifying process (1505) is completed, the allocated MTU 9 is deleted from the “reconfiguration ready MTO” 53 of the data buffer management table 50. As a result, M T U to be further allocated
9 exists, divide the remaining total data buffer size evenly by the number of MTU9s to be allocated (
1508), calculate the new segment size, calculate the final address (1509, 1510) and start address (1511) of these segments, and when all allocations are completed, "<1512.1513)" in the data buffer management table 50. Reset the "wait for reconfiguration" 6o in the data buffer status "51" (1514), and complete the reconfiguration process.

As described above, in this embodiment, the entire storage area of the data buffer 5 is allocated to all MTUs 9 that are ready for operation at the start of operation, so that efficient use of the data buffer 5 is realized. MTU in operational state
The maximum data buffer space is secured according to the number of 9 units, and throughput is improved.

Further, since the data buffer is reconfigured based on changes in the state of MTCIo, 10° or MTU9, efficient use of the data buffer is possible even after the system starts operating.

Furthermore, when allocating data buffers, it is possible to preferentially expand the data buffer allocation amount for one or more specific MTU9s, so for example, multiple processing tasks (for example, batch processing and real-time processing) can be When using a system configuration like this, it becomes easy to selectively prioritize and process specific tasks.

Although the invention made by the present inventor has been specifically explained above based on Examples, it goes without saying that the present invention is not limited to the above Examples and can be modified in various ways without departing from the gist thereof. Nor.

For example, in the embodiment, MTCIO was mainly described as a self-blade, but MTC10° may also be used. Further, although the case where two MTCls (1,10') are used has been described, only one or three or more MTCls may be used.

〔Effect of the invention〕

A brief explanation of the effects obtained by typical inventions disclosed in this application is as follows.

That is, according to the present invention, after detecting whether the peripheral device is ready for operation, the control means detects the allocation amount or allocation priority of the data buffer area of a specific peripheral device. There is no need to allocate data buffers to the device, and an increase in microprogram overhead can be prevented, making it possible to realize efficient and flexible data buffer allocation.

[Brief Description of the Drawings] Fig. 1 is a conceptual diagram showing a system configuration for realizing a data buffer control method in hardware, which is an embodiment of the present invention, and Fig. 2 is a data buffer control system of the embodiment. Fig. 3 is a conceptual diagram of a data buffer in a virtual peripheral subsystem consisting of m peripheral control devices and n peripheral control devices. A conceptual diagram of data buffer division in a cartridge-type magnetic tape subsystem consisting of a subsystem, Figures 4(a) to (C) are actual model diagrams showing the state in which the data buffer is divided into segments of variable length, and Figure 5 is a micro FIG. 6 is an explanatory diagram showing the internal structure of the data buffer management table shown in FIG. 5 above. FIG. 7 is an explanatory diagram showing the data buffer management table managed by the microprocessor.
FIG. 8 is an explanatory diagram showing the TU management table, FIG. 8 is an explanatory diagram showing the MTU monitoring register included in the MTU monitoring circuit, and FIGS. 9 to 16 are flowcharts showing the procedure of data buffer control according to the present invention. It is. ■...cpu <main control unit), 2...main memory, 3,3゛...channel, 4...CPU side transfer circuit, 5...data buffer, 6...MTtJ side Transfer circuit, 7... Microprocessor (control means), 8.
...Memory, 9...MTU (magnetic tape drive unit),
10.10”...MTC (magnetic tape control unit),
11... Control line, 12, 13.13° 14, 14°
, 15, 16. 17, 17' ... bus line, 18.
... Control line, 19... Bus line, 20, 20°, 21.
...Control line, 22...Bus line, 23,24.24...
・Control line, 25...Installation register, 26.2
7... Control line, 28... MTU monitoring circuit, 29.3
0...Control line, 50...Data buffer management table, 70...M T U management table, 80...M
TU monitoring register, 102... l0C (peripheral control unit), 103... data buffer, 105... IOU
(Peripheral device), 104... Control line, A... Work register. Agent Patent Attorney Daiwa Tsutsui MTClo MTC10' Fig. 10 MTU initial connection processing Cni = D Fig. Fig. Fig. 2n- (I1j Isu■--IJOFF□ Fig. 14 Reconfiguration preparation processing)

Claims (1)

[Claims] 1. One or more peripheral control devices provided with data buffers are provided between a host device and a plurality of peripheral devices, and the peripheral control device controls whether the peripheral devices are ready for operation. means for detecting availability; means for allocating a data buffer based on the detection result; control means for controlling the allocation process; and means for notifying the control means of the allocation priority order, and it is possible to expand or preferentially allocate only a specific data buffer area corresponding to the number of peripheral devices in an operational state. Characteristic data buffer control method. 2. When allocating the data buffer mentioned above, once the data buffer area is allocated evenly to the number of peripheral devices that are ready for operation, the allocation amount or allocation priority of the data buffer area to one or more peripheral devices is determined. 2. The data buffer control method according to claim 1, wherein if the ranking is specified, reallocation is performed based on the specified content. 3. After allocating the data buffer, the device has means for monitoring the operational status of the peripheral devices and notifying the control means of changes in the status of the peripheral devices, and the number of peripheral devices that are in an operational state as a result of monitoring by the means. 2. The data buffer control method according to claim 1, wherein when a change in the number of devices is detected, the data buffer is reallocated in accordance with the changed number of devices.