JPH0392942A - How files are stored and accessed - Google Patents

Abstract

(57) [Summary] This bulletin contains application data before electronic filing, so abstract data is not recorded.

Description

Detailed Description of the Invention [Field of Industrial Application] The present invention relates to a file storage method and an access method in a computer system, and in particular, a file storage method that can be suitably applied to a distributed processing system in which a plurality of processors are connected via a network. and how to access it.

[Conventional technology]

Conventionally, the logical minimum unit for file recording is a file, and although it may be divided into physical units such as tracks or extents, files have not been logically divided and recorded. Furthermore, in order to make the system more reliable, a method of multiplexing disks, which are physical storage media, has been used as a means of dealing with file corruption due to disk failure.

Regarding the former technique, for example, J, J. Wallence et
Computer, August
1984 (pp. 31-39)
ing for Ultrahigh Avai
lablity2The Unix RTR Ope
rating System, and for the latter, Nikkei Electronics May 9 issue (1983), pp.
．． 171-202R Fault Tolerant Computer System" and the Stratus computer system.

[Problem M to be solved by the invention] In an office processor system, etc., reliability is not required to multiplex all files, and mask files etc.
By simply multiplexing some important files, the reliability required for the system can be satisfied. If the conventional disk multiplexing method described above is applied to such a system, files that do not need to be multiplexed will be multiplexed, resulting in an unnecessary increase in disk capacity and high costs. occurs.

Furthermore, in the case of files that require multiplexing, such as mask files, what is really important and requires multiplexing are specific items within the file, such as items that take a fixed value and items that take a variable value. Variable items in files with
Or it may be only certain records. The above-mentioned conventional technology has a problem in that it cannot satisfy such requirements.

Also, if you define a file at the time of allocation, even if the structure of the record is exactly the same as that of other files, you cannot access these files as one, and you cannot access each file individually. There was also a problem that the efficiency and usability of search processing etc. were not good because each access had to be specified.

The present invention has been made in view of the above circumstances, and its purpose is to solve the above-mentioned problems in the conventional technology, and to improve the efficiency of use of storage media and the ease of use of files. and provide access methods.

[Means for Solving the Problems] The above-mentioned object of the present invention is to provide a computer system having a processor and a storage device for storing data, in which a file, which is a collection of information, can be arbitrarily stored in the storage device. A file storage method characterized by storing files in logical units, a file storage method characterized by multiplexing files in arbitrary logical units, and the processor described above in response to file access requests. This is achieved by a file access method characterized by determining the storage location of a target file from information in a table within its own processor and accessing the file.

[Operation] In the file storage method according to the present invention, the user defines and allocates file divisions. Furthermore, among the divided files, those with high importance are multiplexed, and the multiplexed files are allocated to separate storage devices. In this way, files can be allocated flexibly according to the storage device status and the user's ease of use. Note that file grouping can also be defined by the user and multiple files can be accessed at once.

[Example J Hereinafter, an example of the present invention will be described in detail based on the drawings.

FIG. 1 is a diagram showing an example of a system configuration to which the present invention is applied. In the figure, 10, 20. 30 is a processor, and each processor has a fixed disk <13.23.33) and a floppy disk (1l, 2
1.31) and a terminal (+2.22.32) are connected. Each processor mentioned above is connected to network l. Note that although this embodiment shows an example in which a bus type network is applied, this may be any type of network. Here, file A(2) is recorded on the fixed disk I3 of the processor 10.

In addition, the user saves file A(2) to small file A, (
3), small file A, (4), and save each small file to the fixed disk 23 and 33.
5), and record it as small file A (6).

As a result, file A is multiplexed, and file A
(2), Small file A, (5), Small file A, (6)
Even if a failure occurs in one of them, as long as the other two files are normal, the user can access the normal file and the user's processing will not be affected.

In this example, the file is recorded on a fixed disk, but it may also be recorded on a floppy disk, a magnetic tape connected to the processor, or a memory within the processor. In addition, although the above figure shows a configuration in which three processors are connected via a network, any number of processors may be connected, and even if there is only one processor, multiple storage devices connected to this processor may be connected. Even if files are divided and stored inside, the file access method remains the same. Below, a file recording method and an access method will be explained based on the configuration shown in FIG.

FIG. 2 shows the logical structure of a typical file. The file 40 consists of records l to n that logically form one group.

When a file is divided, for example, records 1 and 2 become one small file, records 3 to n become another small file, and so on. How the file is divided can be determined by the user. An example of division will be explained with reference to FIG.

FIG. 3(a) shows the customer mask file before division. The records in the customer mask file are code 51,
It consists of items such as customer name 52, address 53, telephone number 54, and person in charge name 56. Moreover, FIG. 3(b) is an example in which the above-mentioned customer mask file is divided by address. Small file 1 collects records whose address is Tokyo,
Small file 2 is a collection of records of customers in Kanagawa Prefecture. If we divide it in this way and record small file 1 in the storage device of the processor in the Tokyo branch and small file 2 in the storage device of the processor in the Kanagawa branch, records of customers in Tokyo that are frequently accessed at the Tokyo branch will be stored in the storage device of the Tokyo branch. Therefore, it can be processed quickly. FIG. 3(C) shows an example in which the customer mask file is divided by person in charge. Here, the small file 1 is a file containing records of person A in charge, the small file 2 is a file containing records of person B in charge, and the small file 3 is a file containing records of person C in charge. By dividing in this way, a protection code can be added to each small file to prevent person A from accidentally updating or deleting records of person B.

Next, the file management table that the user registers when dividing a file will be explained. FIG. 4 shows an example of the structure of the file management table. The file management table 60 includes a small file name 61 and a record name 62.
, storage device name 63, and address 64. This file management table 60 is created corresponding to the file before division. The name of the divided small file is written in the small file name 6I. The record name 62 contains the names of all records contained in the small file, the storage device name 63 contains the name of the storage device in which the small file is recorded, and the address 64 contains the name of the storage device in which the small file is stored. It will show what is in the address.

If the small files are multiplexed, the locations of all the multiplexed small files are written in the storage device name 63 and address 64. The definition of the above file management table is
done by the user. When a user accesses a file, the user reads the corresponding file management table based on the file name and record name before division, and determines which small file the specified record is in, and which address of which storage device the small file is located in. Read about it and access it.

If the storage device is connected to another processor, both operating systems communicate over the network.

Hereinafter, in accordance with the system configuration shown in FIG. 1 and the operating system flowchart shown in FIG. The operation of this embodiment will be explained.

A user, from a terminal 32 connected to a processor 30,
When an access request is made to a record in the small file A1, the operating system of the processor 30 searches the file management table (step 91), learns that the record is located in the same processor 20 as the processor 10 (step 92), and performs a step 95. Then, send an access message to small file A. The processors 10 and 20 access the small file A1 and send the result to the processor 3.
0, and processor 30 performs step 96 . 97
The received result is returned to the terminal. Note that the processor 30
If there is a file A, it is directly accessed (step 93) and the result is displayed (step 94).

According to this embodiment, as described above, the user can access the record without being aware of which storage device the record is located in.
File access can be performed in the same way as before. It is assumed that the file management table is stored on a fixed disk or a floppy disk.

Next, file access in a multiprocessor system will be described as another embodiment of the present invention. A feature of this case is that there is no need to add the address of the other processor to messages on the network.

FIG. 6 shows an example of the structure of the file management table used in this embodiment. All processors on the multiprocessor have a file management table 70. This file management table 70 has a file name 71
, small file name 72. Record name 73, storage device name 74
, address 75. This file management table 70 includes all file names recorded in the storage device within the processor. The small file name is described, and furthermore, the record name within each small file, the storage device name and address in which each small file exists are described.

However, the file management table 70 only describes file information within each processor, and does not describe file information of other processors. Figure 7 shows
FIG. 2 is a diagram showing an example of the structure of a message sent to network I when a file is accessed. This file access message 80 consists of a file access identifier 81, a file name 82, a record name 83, a request/response identifier 84, and data 85. File access identifier 81
is added to distinguish file access messages from other messages. The file name 82 and record name 83 contain the target file name and record name, respectively, and the request/response identifier 84 identifies whether this message requests file access or is a response to a request. It is for the purpose of The operation of each processor during file access will be explained below using FIG. 8 under the system configuration shown in FIG. 1.

When a user requests file access from the terminal 12 connected to the processor 10, the processor 10 produces a file access message 80 having the structure shown in FIG. At this time, the request/response identifier 84 indicates the request. The created message is sent to Processor 1
0 to the network 1 as a file access message I (to, and at the same time, it is also taken in by the processor 10 itself. At this time, the processor 10
Remember that you requested file access.

All processors on the network receive the message +00 requesting file access. Then, it is checked from the file management table 70 in the own processor whether the requested file and record exist in the own processor. The processor 20 uses the file management table 7
0 does not have the requested file and record, so
do nothing. Since the requested file and record are registered in the file management table 70, the processor 30 stores the fixed disk 3 on which the file is recorded.
3 and sends the result to network l as a file access message +01.

At this time, the request/response identifier 84 indicates the request.

All processors that have received message +01 determine whether the response message corresponds to the request message they issued, based on the file name 82 and record name 83 in the message. Since processor 20 does not respond to the request message it issued, it does nothing. Since the processor 10 is a response to the request message sent by itself, the data 86 in the message is sent to the terminal]2
Return to. Note that if the files are multiplexed, the same message will be received multiple times, so
It is necessary to maintain consistency among these messages. This consistency processing will be described in detail later in an embodiment centered on file multiplexing.

In the embodiment described above, by importing the file access message to the transmitting processor itself, each processor can perform the same operation regardless of which processor's storage device stores the target file access message and record. , even if there are multiple small files, it can operate without being aware of which files are in other processors.

Furthermore, in this embodiment, even if the same record exists in different small files, there is no effect, and more flexible file allocation becomes possible. Furthermore, even if a file is expanded or a storage device or processor goes down, each processor does not have file information about other processors, so there is an advantage that it will not be affected. In particular, even when a downtime occurs, file access can continue if files are multiplexed to other processors.

Another embodiment of the present invention will be described using FIG. 9. This embodiment relates to a file access method in which files having the same item configuration in records are grouped into one group, and when a user accesses a file, the group name is specified as the file.

Figure 9 shows the configuration of the file management table.
This file management table +10 has file names I11,
Record name 112, storage device name 1l3, address 11
It consists of 4. This file management table +10 is
It is set up for each group. In this case, the item 6l of small file name 6l in the file management table 60 of FIG. 4 is changed to file name Ill, and the definition and access method are the same as the above-mentioned method.

FIG. 10 shows the structure of a file management table used in yet another embodiment of the present invention.

This embodiment is a modification of the embodiment shown in FIGS. 6 to 8, in which files having the same record structure are grouped instead of dividing the files. The file management table +20 shown in this embodiment has group name 1
21, file name 122, record name 123, storage device name 124, and address +25. In this embodiment, when a user accesses a file,
Specify the group name and record name. A file management table 120 is provided for each processor. 11th
The figure is a configuration diagram of a file access message sent on network l. This file access message 130 includes a file access identifier 13l, a group name 132, a record name 133l, a request/response identifier 134
, consists of 135 data. This is the file name 82 of the file access message 80 shown in FIG. 7 replaced with the group name + 32, and the operation of each processor is the same as that described based on FIGS. 7 and 8. The same is true.

The advantage of this embodiment is that by grouping existing files, file access by the user can be simplified. You can also multiplex files,
Even if it is expanded or deleted, it does not affect other processors and the user can access it without being aware of it.

Another embodiment that focuses on multiplexing files will be described below.

FIG. 12 is a diagram illustrating how to hold multiple files made possible by the present invention. FIG. 4(a) shows an overview of file unit multiplexing. In the figure, +0.
20, 30, . . . are processors, and each processor has a terminal 12, 22, 32, . . . and a fixed disk +3. 23, 33, . . . are connected.

Each processor is connected to network l. Note that although this embodiment shows an example in which a bus type network is applied, this may be any type of network. Further, each processor may be connected to a plurality of terminals and a plurality of disks.

By configuring as described above, it is possible to multiplex only important files (files A, B, and C in the figure). That is, in FIG. 12(a), file A (201,
201') is multiplexed to the disk of processor IQ, 20, and file B (202, 202'') is multiplexed to the disk of processor 10.30, file C
(203, 203') is the processor 20. 30
are multiplexed on each disk. On the other hand, files D (204), E (206), F (205)
is not multiplexed. According to this embodiment, files that require multiplexing and files that do not need to be multiplexed can be mixed and flexibly arranged on the disks of each processor.

FIG. 12(b) shows an outline of multiplexing in units of data items, which is another embodiment of the present invention.

Each symbol in the figure has the same meaning as in FIG. 12(a). In this embodiment, it is also possible to multiplex only the main data items (in, it. in the figure) in the file. That is, as a backup of file A (2.01) in the disk of processor 10, data items it,, it. It becomes possible to have a subset file a of file A (hereinafter referred to as a "backup file") consisting of the following files on the disk of the processor 30.

Furthermore, a backup item definition file 2010 indicating items to be backed up is set in the disk of the processor 30 that has the backup file a. It is assumed that this definition file 2010 is defined by an operator when a backup file is created. Note that if the target file is a file that is searched by key, such as IsAM, the backup file has not only the necessary data items but also a key area.

This is to enable key searches even for backup files.

The details of the operation of this embodiment will be explained below with reference to FIGS. 13 to 17.

FIG. 13 is a diagram showing the structure of a file access message transmitted over network l.

This file access message 140 includes a content code 14l indicating the content of the message, and a source address (SA) that stores the processor number that generated this message.
42, a serial number (C) necessary for transmission +43, information (S I ) indicating the application program (AP) that accesses the file 144, and data 145. The above content code +41 is area FNM section 14
]a and an ID section +41b indicating the type of message (file access request/file access response). In the following explanation, it is assumed that the file name is unique, and the contents of the FNM section 141a are as follows.
Use file name.

However, instead of the name, a code, number, etc. corresponding to the file may be used.

The above 81 section 144 is information indicating an application program (AP) that accesses the file. This S
The I section +44 is separated from the area P NO 144 a for storing the processor number during AP execution and the area TNO 144 b for storing the number indicating the program under execution. Data 145 is an area for storing information to be transmitted.

FIG. 14 is a diagram showing the module and table configuration within the processor 10 shown in FIG. 12. Note that the processors 20, 30, . . . also have a similar configuration.

The network interface 30l, terminal interface 3I3, and disk interface 314 are modules for interfacing with the network 1, terminal +2, and disk 13, respectively. The communication management module 302 determines whether the received message is necessary for its own processor based on the content code 141 of the file access message received from the network I, and if it is a necessary message, inputs it. In addition to the function of storing the message in the message area 305, the output message area 306 has the function of broadcasting the message on the network l via the network interface 301. At this time, in the same way as for network reception messages, it is determined whether or not the outgoing message is necessary for the own processor, and if necessary, the outgoing message is stored in the input message area 305. do.

Here, it is assumed that the input message area 305 and the output message area 306 store transmitted and received messages corresponding to content codes. Content code table 30
3 contains the content code corresponding to the file in the disk connected to the own processor, specifically, the above-mentioned FNM section 141.
"r file name of the file in the own disk" is set in "a", and a content code in which a code indicating "access request" is set is registered in the ID section 14lb. These content codes are automatically set when the processor is started up. The communication management module 302 compares the content code in the received message with the content code registered in the content code table 303, and imports the matching message into its own processor.

The received SI table 304 contains the SI part 1 of the received message.
This table stores the contents of 44 in correspondence with the contents code. The terminal management module 310 stores the input data from the terminal 12 in the terminal output buffer 307, and at the same time stores the output data to the terminal in the terminal output buffer 307 into the terminal interface 3.
It has a function to display on the terminal via 13. The AP execution management module 308 is a module that manages the AP executed within its own processor, and passes messages received from the network and terminals to the AP, and transmits data sent from the AP to the network and terminals, respectively. It has a function to perform processing to send data to.

The transmission S table 315 is the AP execution module 3
This is a table in which the contents of the SI part of the message sent by No. 08 to the network are stored in correspondence with the above-mentioned contents code. The AP execution area 311 is an area where AP is executed. The file management table 309 and file management module 312 are for managing access to files within the own disk.

Next, the processing of the communication management module 302 when receiving a message from the network 1 will be explained based on FIG. 15.

The communication management module 302 that has received the message via the network interface 301 first compares the content code of the received message with the content of the content code table 303 (step 400), and registers the matching code in the content code table 303. If the
The process proceeds to step 401, and if it is not registered, the received message is discarded (step 404). In step 401, the content code of the received SI message and the S
It is determined whether the content matching the 1 part is registered in the reception Sl table 304. If it has already been registered, the received message is discarded in step 404 because the same message has already been received. If they do not match, the received message is a new one, so first, write the content code and SI part contents of the received message to the received S■ table 304! ! The received message is then recorded in the input message area 305 (step 403).

As described above, this process is also performed on outgoing messages.

Next, a file access method in the embodiment shown in FIG. 12(a) will be explained. First, processing in the AP execution management module 308 will be explained.

(1) The AP startup command input by the user from the processing terminal 12 of the AP execution management module when starting the AP is
It is imported into the AP execution management module 308 via the terminal management module 310. , the AP execution management module 308 loads the AP specified by the user from the disk into the AP execution area 311 and starts it. At this time, the content code corresponding to the file accessed by the activated AP is registered in the content code table 303. Note that information regarding files accessed by the AP is defined in advance within the AP, or is specified by the user when inputting the AP startup command. This content code is deleted by the AP execution management module 308 when the AP execution ends.

(2) Processing of the AP execution management module when the AP issues a file access command The AP activated in (1) specifies the name of the file to be accessed and the content of the access, and issues a file access command. This access command is taken in by the AP execution management module, creates a message with the content code etc. set as below, and sends it to the output message area 306.
Store in.

■Content code section FNM section: File name specified by the AP ID section: Code indicating access request ■SI section: PNQ section: Own processor number TNO section: Number assigned to the AP that issued the file access command (e.g. (task number, process number) ■Data section: Access details specified by the AP Also, at this time, the FNM section 141a and sr set in the above
The contents of the section 144 are registered in the transmission Sl table 315.

Through the above processing, the message stored in the output message area 306 is broadcast to the network 1 by the communication management module 302.

Next, regarding the processing in the file management module,
This will be explained using FIGS. 16 and 17.

FIG. 16 shows an example of the configuration of the file management table 309 mentioned above. This file management table 309 has rows 3091 and 30 corresponding to files in its own disk.
It is composed of 92,..., and each line is the file name 3.
091 a, Physical location information 309l indicating the disk where the file is stored and the position within the disk
b and an SI part 3091c of an access message for that file. Of these, it is assumed that the file name 3091a and the physical location information 309lb are set in advance at the time of file allocation.

FIG. 17 is a flow diagram showing the processing of the file management module 312 when receiving the file access request message broadcasted on the network I by the processing of the AP execution management module 308 described above. The file access request message broadcast on network l is processed by the communication management module 302 shown in FIG. be taken in.

The file management module 312 imports this file access request message from the input message area 305 (step 50l), and stores the contents of the SI part in the imported message in the file management table 305.
(step 502). Next, the file access process specified in the data part of the message is executed based on the physical location information 309lb in the file management table 309 described above (step 503).Furthermore, based on the result of the above process, Content code section 14+, SI shown in FIG.
A file access response message is created with the section l44 and data section +45 set as shown below (step 504).
, is stored in the output message area 306 (step 5
05).

■Content code section: FNM section: File name of the accessed file ID section: Code indicating access response ■SI section: File management table Sr in step 502
Set the value stored in #. Data section: Set file access result contents. Through the above processing, the file access response message stored in the output message area 306 is broadcast onto the network 1 by the communication management module. This message is captured by the processor executing the AP that issued the file access request. The AP execution management module 308 in this processor checks whether the FNM part in the content code part and the SI part contents in the received file access response message are registered in the transmission SI table 315, and if they are registered. Only then, the message is passed to the AP that generated the access request.

The overall flow of the above-mentioned processing is summarized in FIG.

FIG. 18 shows the same configuration as previously shown in FIG. 12(a), in which the AP 600 running in the processor 10 is connected to the processor 20. The flow of messages when accessing file C (203, 203') multiplexed in 30 disks is shown. The file access request generated by the AP 600 is handled by the AP execution management module 3.
08, the communication management module 302 broadcasts it on the network 1 as a file access request message 590 for the above-mentioned file C.

Message 590, described above, is sent to processors 20 and 30.
Each of these processors has its own
Access file C (203, 203') in the own disk. Furthermore, processor 20. 30 independently generate file access response messages 591, 591' based on the access results of files C (203, 203') in their own disks, and broadcast them on the network 1. Here, the same contents as the SI part of the message 590 are set in the SI part of the above-mentioned messages 591 and 591' by the processing of the file management module 312 shown in FIG. Both of the response messages 591 and 591' are taken into the processor 10, and are processed by the processing steps 400 to 404 of the communication management module 302 shown in FIG.
Only messages received first are passed to AP 600.

As explained above, according to this embodiment, only important files can be multiplexed, and the AP side can access those files without being aware of the multiplicity of files. There is an effect. Also,
These multiplexed files are each updated independently, so disk 13. 23 becomes inaccessible, the AP 600 can continue its processing without being aware of it. In the above embodiment, the case where the AP accesses a file on the disk of another processor has been explained as an example, but the file on the own disk can be accessed in exactly the same way.

Next, regarding the embodiment shown in FIG. 12(b), the 19th
This will be explained with reference to FIGS. FIG. 19(a) is a diagram showing the contents of the file management table 309 in this embodiment. As in the previous embodiment, the file management table 309 has rows 309 corresponding to files in its own disk.
+', 3092', ..., each line contains a file name 3091a, physical location information 309lb
' and the SI part 3091 c of the access message
It's intimidating. Furthermore, the flag 3091 d' is an area used in this embodiment, and indicates that the file in the local disk is a backup file (file a in FIG. 12(b)).
This is a flag indicating whether or not.

FIG. 19(b) is a diagram showing the contents of the backup itext definition file shown in FIG. 12(b). This file is defined for each backup file when the backup file is created, and indicates what data items the backup file is composed of. Specifically, as shown in this figure, row 2 corresponding to each data diagram (in the example of FIG. 12(b), it3 and it4) constituting the backup file is
010], 20102,... Each row has an item name 20101 indicating the name of the data item.
a, i indicating the starting position within the record of the main file (file A in the example in Figure 12(b)) of the data item;
tem start position 2010lb and itel length 20101c indicating the length of the data item. With this information, you can create a backup file. It becomes possible to recognize where on the main file A the data item backed up in a is located.

In this embodiment as well, the process of generating a file access request message and the process of capturing a file access response message on the processor side during AP execution are exactly the same as in the previous embodiment. Therefore, the flow of file access request message processing in the file management module 312 will be explained below with reference to FIG. In this example, the main file and backup file are:
They are managed as files with the same file name.
Therefore, the file access request message for file A in FIG. 12(b) is received not only by the processor 20 but also by the processor 30.

The file management module 312 first takes in a file access request message from the input message area (step 701), and in step 702 stores the SI part in the message in the SI part of the row corresponding to the accessed file in the file management table. . Next, in step 703, the flag area of the row corresponding to the accessed file in the file management table is referred to to determine whether the file in the own disk is a backup file or a main file. If it is a backup file, it is determined whether the access request content is a file write request (step 704), and if it is other than a write request, the process is directly terminated. For writing requests,
Based on the contents of the backup i ten definition file,
Only the written content corresponding to the data item being backed up is extracted, the content is written to the backup file in the own disk, and the process ends (step 705). In the example of FIG. 12(b), itl, it2
, jt3 and it4, jt3 and it4 are extracted. In addition, in step 703, if the file is the main file, step 503 shown in FIG.
Processing steps 706 to 708 similar to steps 706 to 505 are performed.

The processing method in the embodiment described above makes it possible to have a backup file containing only the main items in a certain file on a separate disk and to update these files in parallel. For this reason, for example, the 12th [i
In the system shown in 1(b), even if file A becomes inaccessible, it is possible to recover the contents of file A based on backup file a. In addition, A can continue with only the data items in backup file a.
If P exists, the backup-side file management module can generate a response message consisting only of the backup data items on its own disk when receiving a file read request, so that if the main file A becomes inaccessible, However, it is possible to degenerate the AP business content and continue processing.

In addition, in the above embodiment, if the data item of the main file can be separated into a fixed part, that is, a part that does not change even when a file is updated, and a variable part, that is, a part that is changed by a file update, then the variable part multiplexed on disk as a backup file,
By providing a fixed part on a floppy disk (FD), for example, it is possible to continue AP operations even if the main file cannot be accessed. This example will be described below as another embodiment with reference to FIG. 21.

FIG. 21 shows the 12th [i! This system has the same configuration as I(b), but a floppy disk 3l is connected to the processor 30, and a file a'(201'') consisting of data items ill and it2 is set in it. , itl, it2 are fixed parts,
It is assumed that it3 and jt2 are variable parts. Under such a configuration, it is possible to continue the AP business by performing the following processing in response to a file read request generated when file A is accessed.

■File a (201”) and file a' (
201''), the data item of the record corresponding to the file read request is read.

■■, file a (201”) and file a' (
201'') are combined to generate a record corresponding to the record of main file A.

The record generated in ■■ is sent onto network l as a file access response message.

In the above explanation, it is assumed that the files or data items to be multiplexed are multiplexed within the disks of different processors, but this can also be multiplexed between multiple disks connected to the same processor. Needless to say, it is.

In each of the embodiments described above, the unit of storage/multiplexing is one type each, such as file unit, record unit, data item unit, etc., but the following example is given as a method of mixing these types. be able to. The access method is the same as in each of the embodiments described above, but the storage unit and file management table are different from those in the embodiments described above. FIG. 2 is a diagram showing an example system configuration. Processors 10, 20, 30. 40 are connected by a bus network l. Each processor includes a magnetic disk device 13, 23, 33. 43 is connected. File A is stored on disk l3, and disks 23, 33. 43 stores a portion of file A. In other words, file a on disk 23
1 contains the record number 1.2 in file A, and file a on disk 33 contains the data item it.
2.It3 item is also in file a of disk 43 with record numbers 3 and 4, and data item i
Data of t2 and it3 are stored.

FIG. 23 shows the structure of the file management table of this embodiment. This file management table l000 is
It consists of file name tool, data item name +002, record number +003, and storage device name I004. Note that the file management table of each processor records information on all files stored in the storage device connected to the processor itself. When a file access request message occurs within its own processor or another processor, each processor checks from the file management table whether data corresponding to the request message exists in the storage device within its own processor, and if data exists, In response to the request, it performs update and reference processing, and returns a response message to the requester.

Here, the stored data item names and record numbers are recorded in the file management table, but instead of recording the names, there is also a method of recording the data items to be stored and the conditions of the records. For example, if you indicate a range of record numbers, all records within that range will be stored. Using this method, the method of recording the file management table is simplified.

In the above embodiment, files, data items. Since it is possible to combine and store various logical units such as record units,
Allows for more flexible and fine-grained file storage and multiplexing.

Each of the above-mentioned embodiments is shown as an embodiment of the present invention, and it goes without saying that the present invention is not limited thereto.

〔Effect of the invention〕

As described in detail above, according to the present invention, in a computer system having a processor and a storage device for storing data, a file that is a collection of information is stored in the storage device in an arbitrary logical manner. Since the files are stored and multiplexed in large units, it is possible to realize a file storage method and an access method that can improve the utilization efficiency of storage media and the ease of file use.

[Brief explanation of drawings]

Figure 1 is a system configuration diagram of an embodiment of the present invention, Figure 2 is a diagram showing the logical structure of files, Figure 3 is a diagram showing examples of file usage and division, and Figure 4 is file management. Table configuration diagram, Figure 5 is a flowchart of the operating system when accessing a file, 6th rgJ is a diagram showing a file management table of another embodiment, Figure 7 is a configuration diagram of a file access message, and Figure 8 is a diagram showing another example A system configuration diagram of an embodiment, FIGS. 9 and 10 are file management table configuration diagrams of another embodiment, FIG. 11 is a configuration diagram of a file access message, and FIG. 12 is a system configuration diagram of yet another embodiment. , FIG. 13 is a diagram showing the configuration of a file access message, FIG. 14 is a diagram showing the internal configuration of the processor, FIG. 15 is a processing flowchart of the communication management module, and FIG. 16 is a diagram showing the file management table of another embodiment. , 17th
The figure is a processing flowchart of the AP execution field module, Figures 18, 21, and 22 are system configuration diagrams showing other embodiments, and Figures 19 and 23 are the configurations of the file management table, etc. The figure shown in FIG. 20 is a processing flowchart of a file access request message. 2: File before division, 3, 4: File after division, 5
．． 6: Multiplexed file, 10, 20. 30:
Processor, 11, 21, 3]: Floppy disk, 12, 22, 32: Terminal, +3. 23, 3
3: Fixed disk. Fig. 2 Fig. 5 Overetting system flowchart Fig. 7 Fig. 8 Fig. 1 3 Fig. 1 5 Fig. Biff Fig. 7

Claims (1)

[Claims] 1. In a computer system having a processor and a storage device for storing data, a file, which is a collection of information, is stored in the storage device in arbitrary logical units. A file storage method characterized by: 2. In a distributed processing system in which a plurality of processors each connected to a storage device are connected by a transmission medium, a file, which is a collection of information, is stored in the storage device in arbitrary logical units. A file storage method characterized by: 3. The file storage method according to claim 1 or 2, wherein the arbitrary logical unit is a file. 4. The file storage method according to claim 1 or 2, wherein the arbitrary logical unit is a data item constituting a record. 5. The file storage method according to claim 1 or 2, wherein the arbitrary logical unit is a record. 6. The file storage method according to claim 3, wherein the processor has a table of information regarding data items of storage devices in the system. 7. The file storage method according to claim 3, wherein the processor has a table of information regarding records of storage devices in the system. 8. In a computer system having a processor and a plurality of storage devices for storing data, it is possible to multiplex files, which are collections of information, in arbitrary logical units in the plurality of storage devices. Characteristic file storage method. 9. In a distributed processing system in which a plurality of processors each connected to a storage device are connected by a transmission medium, files that are a collection of information are multiplexed in arbitrary logical units within the storage device. A file storage method characterized by: 10. The file storage method according to claim 8 or 9, wherein the arbitrary logical unit is a file. 11. The file storage method according to claim 8 or 9, wherein the arbitrary logical unit is a data item constituting a record. 12. The file storage method according to claim 8 or 9, wherein the arbitrary logical unit is a record. 13. The file storage method according to claim 10, wherein the processor has a table of information regarding data items of storage devices in the system. 14. The file storage method according to claim 10, wherein the processor has a table of information regarding records of storage devices in the system. 15. The file storage method according to claim 8 or 9, wherein the processor has a table of information regarding data items in a storage device connected to the processor. 16. The file storage method according to claim 8 or 9, wherein the processor has a table of information regarding records in a storage device connected to the processor. 17. The file access method according to claim 15, wherein, in response to a file access request, the processor determines the storage location of the target data item from information in the table and accesses the file. 18. The file access method according to claim 15, wherein, in response to a file access request, the processor determines the storage location of the target record from information in the table and accesses the file.