JP3925246B2 - Computer system - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a computer system, and more particularly to the use of a storage device having both an interface according to a count key data format and an interface according to a fixed length block format.
[0002]
[Prior art]
There are known in the prior art for file sharing or file conversion between different operating systems. For example, PCFS (4S) of the device and network interface of JLE Reference Manual 3 issued by Nippon Sun Microsystems, Inc. describes a function for accessing files of the MS-DOS operating system from a UNIX operating system. .
(JLE is a trademark of Japan Sun Microsystems, Inc. UNIX is a registered trademark of X / Open Company Ltd. in the United States and other countries. MS-DOS is a registered trademark of Microsoft Corporation in the United States and other countries. Is a registered trademark.)
[0003]
[Problems to be solved by the invention]
In recent years, so-called downsizing, in which operations that have been conventionally performed on mainframes using so-called open systems such as personal computers and workstations, have been actively performed.
[0004]
Open systems perform disk access according to a fixed-length block format, whereas mainframes traditionally perform disk access according to a count key data format. For this reason, there is a problem that a disk used in a mainframe cannot be used in an open system. Since a large amount of business information is already stored on the disk used in the mainframe, there is a great demand from customers to access this disk from an open system even if downsizing is performed. There are a distributed database and a file transfer as a technique for answering this request, but there are drawbacks such as a high network load and a need to change an existing business program.
[0005]
In the present invention, the disk has both an interface according to the count key data format and an interface according to the fixed-length block format, the disk is accessed from an open system, and business information stored from the mainframe is used. It is possible.
[0006]
There is nothing known in the prior art about the usage of a storage device having both an interface according to the count key data format and an interface according to the fixed-length block format, particularly the function of sharing data between the two interfaces.
[0007]
[Means for Solving the Problems]
The present invention relates to a record system having a count key data format specified by a cylinder number, a head number, and a record number in a computer system including a storage device having both an interface according to a count key data format and an interface according to a fixed length block format. Means for mutually converting addresses in a fixed-length block format specified by an LBA (Logical Block Address); means for accessing records stored in a storage device in a count key data format by an interface in accordance with the fixed-length block format; A computer system having means for extracting only user data from the record, and means for interpreting and using the user data of the record according to a predetermined format is provided.
[0008]
Further, the present invention provides a means for accessing data by an interface according to a count key data format and managing the data, a means for accessing data by an interface according to a fixed-length block format, and a means for managing the data. When a certain means uses data, a computer system is provided having means for letting the other means know that the other means is using the other means.
[0009]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, the present invention will be described in more detail with reference to embodiments shown in the drawings.
[0010]
-Embodiment of the first invention-
FIG. 1 is a block diagram showing the principal parts of a computer system according to the first embodiment of the present invention.
[0011]
The CPU 10 has a SCSI (Small Computer System Interface) interface 60. The CPU 11 has a channel interface 70. The disk controller 80 is connected to the CPU 10 via the SCSI interface 61 and is connected to the CPU 11 via the channel interface 71. The SCSI bus 65 connects the SCSI interfaces 60 and 61. A channel cable 75 connects the channel interfaces 70 and 71.
[0012]
A configuration in which the SCSI interfaces 60 to 61 are interfaces according to an arbitrary fixed-length block format is also possible. A configuration in which the channel interfaces 70 to 71 are interfaces according to an arbitrary count key data format is also possible.
[0013]
Hereinafter, the count key data format is referred to as CKD format, and the fixed-length block format is referred to as FBA (Fixed Block Architecture) format. A CKD record is called a CKD record.
[0014]
The CPU 10 is controlled by the UNIX operating system 40. The CPU 11 is controlled by a VOS3 (Virtual-storage Operating System 3) operating system 50 of Hitachi, Ltd. A configuration in which the UNIX operating system 40 is an arbitrary operating system that supports the SCSI interface is also possible. A configuration in which the VOS3 operating system 50 is an arbitrary operating system that supports the channel interface is also possible.
[0015]
In the CPU 10 and CPU 11, application programs 20 and 21 operate, respectively. The application programs 20 and 21 are described in a programming language COBOL and access a VSAM ESDS (Virtual Storage Access Method Entry-Sequenced Data Set) in the disk controller 80. The VSAM ESDS may be configured as an arbitrary data set or an arbitrary file for an arbitrary access method for accessing data stored in the CKD format.
[0016]
The VOS3 operating system 50 includes a VSAM 55. The VSAM 55 makes the data stored in the disk controller 80 accessible from the application program 21 as a record of the VSAM data set.
[0017]
FIG. 2 is a configuration diagram of a main part of the UNIX operating system 40.
The UNIX operating system 40 includes a file management function 150 and a SCSI device driver 155. Light features related to the embodiment of the present invention such as a memory management function and a process management function are omitted. The SCSI device driver 155 controls the SCSI interface 60 and accesses the disk controllers 80 and 180. The disk controllers 80 and 180 are connected to the SCSI interface 60 via the SCSI bus 65. The disk controller 80 stores a VSAM data set, and the disk controller 180 stores an FFS (Berkeley Fast File System) file. FFS is a file system format that is standardly supported by the file management function 150 of the UNIX operating system 40. On the other hand, it is assumed that the file management function 150 of the UNIX operating system 40 does not support access to the VSAM data set.
[0018]
The ls command 160 is a command for displaying a list of files existing in a specified directory. A disk access request of the ls command 160 issued by designating a directory with FFS included in the disk controller 180 is processed by the file management function 150 and the SCSI device driver 155 to access the disk controller 180.
[0019]
On the other hand, the disk access request of the CKD record access library 35 is processed only by the SCSI device driver 155 without going through the file management function 150 and accesses the disk controller 80. In this case, attribute information of each VSAM data set stored in the disk controller 80, physical storage location information, and the like are not provided from the UNIX operating system 40 to the CKD record access library 35. In the CKD record access library 35, the entire disk controller 80 is only seen as one file. Such an access method is called raw IO.
[0020]
The UNIX operating system 40 distinguishes the two disk access requests by the file name. If a character special file name is specified as the file name to be accessed, access is made by raw IO, and if any other normal file name is specified, access is via the file management function 150. An example of a character special file name is / dev / rsd1c.
[0021]
Returning to FIG. 1, the CPU 10 includes a VSAM access library 30 and a CKD record access library 35. The CKD record access library 35 converts the CKD record access request issued by the VSAM access library 30 into an FBA format access request, gives it to the UNIX operating system 40, converts the result into the CKD format, and converts the result into the VSAM access library. Return to 30. The VSAM access library 30 refers to the data structure for controlling the VSAM stored in the disk controller 80 and uses the data stored in the disk controller 80 as a record of the VSAM data set from the application program 20. Make it accessible.
[0022]
A configuration in which the file management function 150 of the UNIX operating system 40 supports access to the VSAM data set is also possible. In this case, the VSAM access library 30 and the CKD record access library 35 are implemented as part of the UNIX operating system.
[0023]
The disk control device 80 includes a buffer 90 and a disk device 100. The disk device 100 stores a CKD record 110. The disk controller 80 provides access to a record specifying a cylinder number, a head number, and a record number according to the CKD format via the channel interface 71. Hereinafter, the record address represented by the cylinder number, head number, and record number is referred to as CCHHR. The track address represented by the cylinder number and head number is called CCHH.
[0024]
Further, the disk controller 80 also provides access according to the FBA format via the SCSI interface 61. In this case, it is assumed that the block length is 512 bytes, and cylinder 0, head 0, and record 1 have a 0th LBA (Logical Block Address). Addressing and accessing the CKD record stored in the disk controller 80 according to the FBA format will be described later.
[0025]
Data stored in the disk device 100 is identified by the cylinder number, the head number, and the byte position from the head of the track where the data is stored. It is assumed that the cylinder number and head number of the data in the disk device 100 are the same as the cylinder number and head number specified when the data is accessed from the CPU 11 via the channel interface 71. Different configurations are possible. A configuration in which data stored in the disk device 100 is identified by an LBA is also possible. In that case, a means for mutually converting the cylinder number, head number and record number specified when accessed from the CPU 11 via the channel interface 71 and the LBA is required. This configuration will be described later as an embodiment of the second invention.
[0026]
A configuration with a plurality of disk devices 100 is also possible.
The disk device 100 is capable of storing a maximum of 64 kilobytes of data per track, and this is hereinafter referred to as track capacity. The buffer 90 has a size equivalent to the track capacity. The track capacity multiplied by the number of heads is called the cylinder capacity.
[0027]
FIG. 3 is a flowchart of processing of the application program 20.
Application program 20 opens one VSAM ESDS, written in COBOL and stored in disk controller 80, reads the first record in the data set, displays it on the console, and closes the data set Then it ends.
[0028]
In step 1100, the data set is opened. The description format in COBOL is the OPEN INPUT data set name, which indicates that the specified data set is opened for reading only. As a result, the VSAM access library 30 is called. The process performed there is shown in FIG. This will be described later.
[0029]
In step 1110, the VSAM record is read. The description format in COBOL is the READ data set name RECORD INTO unique name, which indicates that one VSAM record is read from the specified data set and put in the variable of the application program 20 indicated by the unique name. As a result, the VSAM access library 30 is called. The processing performed there is shown in FIG. This will be described later.
[0030]
In step 1120, the VSAM record read in step 1110 is displayed on the console.
[0031]
In step 1130, the data set is closed. As a result, the VSAM access library 30 is called. The processing performed there is shown in FIG. This will be described later.
This completes the processing of the application program 20.
[0032]
FIG. 4 is a flowchart of the VSAM ESDS open process 1100 performed by the VSAM access library 30.
In step 500, the raw IO function of the UNIX operating system 40 is opened. More precisely, the character special file corresponding to the disk controller 80 is opened. In the embodiment of the present invention, it is assumed that all VSAM ESDS exist in the disk controller 80. A configuration in which a plurality of disk devices are connected to the CPU 10 is also possible. In that case, a means for determining in which disk device it exists from the designated data set name is required.
[0033]
In step 510, the VSAM access library 30 reads the standard volume label from the disk controller 80 using the function of the CKD record access library 35.
[0034]
The standard volume label is written at a specific location of the disk device and has a VTOC (Volume Table of Content) address. The standard volume label is read by designating the specific CCHHR and calling the CKD record reading process shown in FIG. The CKD record reading process will be described later. The VOS3 operating system 50 creates one VTOC for each disk device. The VTOC has management information for all data sets included in the disk device.
[0035]
In step 510, the CTOCHR of the VTOC is obtained from the data portion of the standard volume label.
The VTOC is a collection of records of a key part 44 bytes and a data part 96 bytes. Each record is called a DSCB (Dataset Control Block). There are various forms of DSCB. In the format 1 DSCB, the key part is a data set name, and the data part has information on the attribute of the data set and the assigned physical storage position. A physical storage area to which a data set is allocated is called an extent. An extent is identified by the cylinder number and track number that it occupies.
[0036]
In step 520, the first record of the VTOC is read by using the function of the CKD record access library 35.
[0037]
Step 530 checks if this is format 1 DSCB and the key part is equal to the specified data set name. If the condition is satisfied, the process proceeds to step 550. Otherwise, go to step 540.
[0038]
In step 550, since this is the target data set format 1 DSCB, it is copied to a local variable of the VSAM access library 30 and returned to the caller. This completes the VSAM ESDS open process.
[0039]
In step 540, the record address is advanced, the next DSCB is prepared for reading, and the process returns to step 520.
[0040]
FIG. These are flowcharts of the VSAM ESDS read processing 1110 performed by the VSAM access library 30.
[0041]
All VSAM records contained in a VSAM ESDS are ordered in the order in which they were created. The VSAM access library 30 always stores the current VSAM record position to be processed, which is hereinafter referred to as a current record. The current record is the first VSAM record when the data set is opened. When read, the current record becomes the next VSAM record.
[0042]
In VSAM, the unit of transfer with the disk device is called CI (Control Interval). The CI includes VSAM records and management information on unused space in the CI. The VSAM access library 30 identifies a VSAM record by the RBA (Relative Byte Address) of the CI in which it is included and the serial number of the VSAM record in the CI.
[0043]
In step 600, the target RBA is the RBA of the CI including the current record.
In step 610, an extent including the target RBA is searched. This means that the CCHHR in which data having the offset is actually stored is obtained from the offset in the data set.
[0044]
An example of read processing immediately after opening of VSAM ESDS is described below. At this time, the current record is included in the first CI of the VSAM ESDS, and the RBA of the CI is 0. The format 1 DSCB has an array of extent information, and records the start CCHH and end CCHH of the extent for each extent. The array of extent information is arranged in ascending order of the corresponding RBA. In the present example, since the target RBA is 0, it is clearly included in the first record of the first extent. As a result, the target CCHH is the start CCHH indicated by the first extent information recorded in the format 1 DSCB. Also, since user data cannot be stored in record 0, it can be seen that R is 1.
[0045]
In step 620, the CCHHR obtained in step 610 is designated and the CKD record reading process shown in FIG. 7 is called. When the CI is composed of a plurality of CKD records, the CKD record reading process is called for that number.
[0046]
In step 630, the control information in the CI is referred to search for the target VSAM record in the CI. It has the current record serial number.
In step 640, the VSAM record is copied to the unique name that is a variable of the application program 20.
[0047]
In step 650, the current record is set as the next VSAM record.
This completes the VSAM ESDS read process.
[0048]
FIG. 6 is a flowchart of the VSAM ESDS closing process 1130 performed by the VSAM access library 30.
[0049]
In step 1000, the raw IO function of the UNIX operating system 40 is closed. More precisely, the character special file corresponding to the disk controller 80 is closed.
[0050]
In step 1010, the work area is released.
This completes the VSAM ESDS closing process.
[0051]
FIG. 7 is a flowchart of the CKD record reading process performed by the CKD record access library 35. The CKD record reading process is called from the VSAM access library 30, reads a record having the designated CCHHR from the disk controller 80, and returns its key part and data part.
[0052]
In step 400, the LBA corresponding to the head of the track including the record having the designated CCHHR is calculated. However, in the following, for division /, only the integer part is the quotient.
[0053]
LBA = (CC * cylinder capacity + HH * track capacity) / block length
In step 410, data is read from the disk controller 80 via the SCSI interface 60 from the LBA by one track length using the low IO function of the UNIX operating system 40. The reason for using the low IO function is that the file management function of the UNIX operating system 40 cannot be used because the UNIX operating system 40 does not support access to the VSAM data set.
[0054]
In step 420, the record address processed in step 430 is set to the head of the track.
[0055]
In step 430, the record ID included in the count part of the record is checked to check whether the record has the designated CCHHR. If the designated CCHHR is held, the process proceeds to step 440. Otherwise, go to step 450.
[0056]
In step 440, since the target record is found, the key part and the data part are returned to the caller, and the process is terminated.
[0057]
In step 450, the length of the key part and data part of the current record is added to the record address, and the record address to be processed next is returned to step 430. The length of the key part and data part of the record is written in the count part of the record.
[0058]
As described above, in the process shown in FIG. 7, one track is always read from the disk controller 80 when the CKD record read process is called once. A configuration in which data of recently accessed tracks is cached and the disk controller 80 is not accessed when the same track is requested is also possible.
[0059]
FIG. 8 is a flowchart of the SCSI READ process performed by the disk controller 80. This process is performed on the disk controller 80 side as a result of using the raw IO function of the UNIX operating system 40 in step 410 of the CKD record reading process of FIG.
[0060]
In step 200, the disk controller 80 receives a SCSI READ command from the CPU 10 via the SCSI interface 61.
[0061]
In step 210, the LBA of the target data is obtained from the received CDB (Command Descriptor Block), and is converted into the cylinder number and head number of the disk device 100.
[0062]
Cylinder number = (LBA * block length) / cylinder capacity
Head number = ((LBA * block length)% cylinder capacity) / track capacity
Byte position from the beginning of the track = (LBA * block length)% track capacity
% Represents the remainder. That is, for integers m and n, n% m represents the remainder obtained by dividing n by m.
[0063]
In step 220, the track having the designated cylinder number and head number is read into the buffer 90. The format of the track read into the buffer 90 at this time is shown in FIG.
[0064]
FIG. 9 shows the arrangement of data stored in the disk device 100 on a track. Reference numerals 300 to 345 denote actual physical data arrangement on the track. On the other hand, reference numeral 380 shows the format of the track read into the buffer 90 in step 220 of FIG. Reference numerals 390, 392, and 394 indicate formats in which data indicated by 380 is transferred to the CPU 10 via the SCSI interface 61.
[0065]
Reference numeral 300 denotes an index marker, which indicates the start of a track. Reference numeral 305 denotes a home address, which indicates the track status and ID. 310 is a count part of record 0, and 315 is a data part of record 0. The count part is the first field of each record and indicates the state, position, and length of the record. Record 0 is the first record in the track and cannot store user data. 320, 325, and 330 are the count part, key part, and data part of record 1, respectively. 335, 340, and 345 are the count part, key part, and data part of record 2, respectively. The following records were omitted. Between each field 305 to 345, an area called a gap has a predetermined length and no data is stored.
[0066]
The 380 track format is a field in which the count part, the key part, and the data part of record 1 and below are continuously arranged in the fields 305 to 345.
[0067]
Actually, ECC (Error Correcting Code) and the like existing in fields 305 to 345 are not included in 380, but the difference is not shown in FIG. 3 for simplicity.
[0068]
Reference numerals 390, 392, and 394 denote blocks having a length of 512 bytes, which is the block length of the disk controller 80. In 390, 392, and 394, the data indicated by 380 is sequentially stored in the order of the count part, the key part, and the data part. CKD record boundaries do not always match block boundaries.
[0069]
As shown in FIG. 9, the home address 305 and the record 0 cannot be seen from the SCSI interface 61. Of course, ECC and gaps are not visible.
[0070]
The track capacity, which is the length of the buffer 90, is not the maximum value of user data stored in the track, but the maximum value including the count part of each record, the home address, and the length of record 0. To do.
[0071]
Returning to FIG. 8, in step 230, data is transferred to the CPU 10 via the SCSI interface 61 from the block specified by the byte position from the beginning of the track obtained in step 210 in the buffer 90.
[0072]
In step 240, it is determined whether the data has been transferred to the end of the track. If the data is transferred to the end of the track, the process proceeds to step 250. Otherwise, go to step 270. Transfer to the end of the track means that the last byte of the last record of the track has been transferred.
[0073]
In step 250, 0 is transferred to the end of the block currently being transferred. This is hereinafter referred to as padding. The reason why this processing is necessary is shown below.
[0074]
In CKD format, the amount of data that can be stored in a track varies depending on the record length. For this reason, generally, the capacity of the data actually stored in the track is not a multiple of the block length, which is 512 bytes in the present case. If the padding of step 250 is not performed, the data of different tracks are mixed in one block when this disc is read in the FBA format. This complicates the processing of the CKD record access library 35 of the CPU 10. In the embodiment of the present invention, the padding of step 250 is performed to ensure that the track always starts from a block boundary. A configuration without padding in step 250 is also possible. Other than 0 can be used as data to be transferred for padding.
[0075]
In step 260, the cylinder number and head number of the next track are calculated. In step 270, it is checked whether all the blocks designated by the CDB have been transferred. When all the data has been transferred, the read process is terminated. If not all have been transferred, the byte position from the beginning of the track is set to 0 and the process returns to step 220.
[0076]
However, in the embodiment of the present invention, the CKD record access library 35 always accesses only one track as shown in Step 410 of FIG. For this reason, although the details depend on the processing of the UNIX operating system 40, it is generally considered that the track having the next track address calculated in step 260 is not read in step 220.
[0077]
As described above, in the processing of FIG. 8, as described with reference to FIG.
[0078]
-Embodiment of the second invention-
FIG. 10 is a block diagram showing the principal part of the computer system according to the second embodiment of this invention.
[0079]
In the configuration of the computer system according to the second embodiment of the present invention, the disk device 100 of the disk controller 80 according to the first embodiment is changed to a disk device 100 ′ accessed in the FBA format. It is a configuration. A configuration having a plurality of disk devices 100 'is also possible, and this is shown in FIG. FIG. 18 will be described later.
[0080]
This disk device 100 ′ has a block length of 512 bytes and provides access by LBA. The storage of the CKD record 110 in the disk device and the access to the CPU 11 according to the CKD format via the channel interface 71 are the same as in the first embodiment.
[0081]
FIG. 11 shows the arrangement of data stored in the disk device 100 ′. Reference numerals 2000, 2002, and 2004 are blocks having track data stored in the disk device 100 ', each having a length of 512 bytes. Reference numeral 380 ′ denotes a track format read into the buffer 90. Reference numerals 390, 392, and 394 indicate formats in which data indicated by 380 'is transferred to the CPU 10 via the SCSI interface 61. 390, 392 and 394 are the same as in FIG.
[0082]
2000 includes a home address and record 0. This is because the disk controller 80 needs to process a so-called format write command peculiar to the CKD format and retain the written data in order to receive access according to the CKD format via the channel interface 71. Because. Examples of format write commands include WRITE HOME ADDRESS and WRITE COUNT, KEY, AND DATA.
[0083]
The data indicated by 380 'is a series of 2000, 2002, and 2004 data, and there is also a home address and record 0.
[0084]
FIG. 12 is a flowchart of SCSI READ processing performed by the disk controller 80. The flowchart of FIG. 12 is obtained by adding step 2100 and step 2110 to the flowchart of FIG. 8 of the first embodiment.
[0085]
In step 2100, the CCHH calculated from the LBA specified in the CDB in the previous step 210 is further recalculated into an LBA.
[0086]
LBA = (CC * cylinder capacity + HH * track capacity) / block length
The cylinder capacity and the track capacity are what the disk controller 80 shows to the CPU 11 via the channel interface 71. The block length is an attribute of the disk device 100 ′ and is 512 bytes. When a configuration having a plurality of disk devices 100 ′ is adopted, a means for determining in which disk device a track having the target CCHH exists is required, and the calculation of the LBA becomes complicated.
[0087]
In step 220 ′, 2000, 2002, 2004 and subsequent blocks are read from the disk device 100 ′ into the buffer 90 by one track. The buffer 90 stores data indicated by 380 ′.
[0088]
In step 2110, the start position of the count part of record 1 is determined on the data in buffer 90. For this purpose, the length of record 0 is obtained by looking at the count portion of record 0, and only the length of the home address is added to the head position of buffer 90. This processing is necessary because the home address and record 0 are not transferred to the CPU 10 via the SCSI interface 61.
[0089]
In step 230, transfer is performed from record 1 located in step 2110.
Since the following processing is the same as that of FIG. 8 of the first embodiment, description thereof will be omitted.
[0090]
FIG. 18 is a configuration diagram of the main part of a computer system in which the disk device 100 ′ of the computer system according to the second embodiment of the present invention is replaced with a disk device 100 ″ having a half capacity and a disk device 2500. Data distribution to each disk device is performed in units of tracks, and even-numbered track numbers are stored in the disk device 2500 and odd-numbered track numbers are stored in the disk device 100 ″.
[0091]
-Third embodiment of the invention-
FIG. 13 is a configuration diagram of the main part of the computer system according to the third embodiment of this invention.
[0092]
The configuration of the computer system according to the third embodiment of the present invention is such that the CKD record access library 35 according to the first embodiment is replaced with a CKD record access library 35 ″ having a slightly different function. is there.
[0093]
The main differences between the embodiment of the present invention and the embodiment of the first invention will be briefly described below.
[0094]
In the embodiment of the first invention, it is the CKD record access library 35 of the CPU 10 that removes the count part from the CKD record, but in the embodiment of the present invention, the disk controller 80 does this.
[0095]
Accordingly, in the embodiment of the first invention, the CKD record access library 35 reads data from the disk controller 80 in units of tracks, but in the embodiment of the present invention, it reads data in units of blocks. In the embodiment of the present invention, since the data received by the CKD record access library 35 via the SCSI interface 60 is not provided with a count unit, this alone does not determine the record boundary. However, this is not a problem when accessing VSAM. The reason for this will be described below.
[0096]
In VSAM, a physical record stored in a disk device does not correspond to a VSAM record handled by an application program that is a VSAM user. The storage to the disk device, that is, the allocation of the CKD record is performed for each CI. Each CKD record storing CI does not have a key part, and the length of the data part is the same for all CKD records belonging to the same VSAM data set, and is determined by VSAM to an appropriate length such as 1024 bytes. When the disk controller 80 accesses the data stored in the CKD format in the FBA format by performing the padding process in step 250 of FIG. 8, the track boundary in the CKD format crosses the block boundary in the FBA format. Guarantee that it will not come off. Therefore, if the LBA at the beginning of the track is given, the position of the target record can be easily obtained from the record number and the record length.
[0097]
Further, the fact that the data received by the CKD record access library 35 does not have a count part does not cause a problem in accessing the VTOC. The VTOC is a collection of records of a key part 44 bytes and a data part 96 bytes. Therefore, as in the case of VSAM, it is easy to obtain the record position.
[0098]
That is, the CKD record access library 35 can find a record boundary by being taught from the host program, in this case, the VSAM access library 30, what type of record is stored in the track currently being processed. Is possible. For this reason, a counting part is not necessary.
[0099]
However, some access methods other than VSAM handle CKD records of an arbitrary length, and therefore there are some methods to which the system of the embodiment of the present invention cannot be applied.
[0100]
FIG. 14 shows the arrangement of data stored in the disk device 100 on a track. Reference numerals 300 to 345 are the same as those in FIG. 9, and show the actual physical data arrangement on the track. 380 "indicates the format of the track read into the buffer 90. 390" and 392 "indicate the format when the data indicated by 380" is transferred to the CPU 10 via the SCSI interface 61. It is shown.
[0101]
The track format of 380 "is a collection of only the key part and data part of record 1 and below of the fields 305 to 345.
[0102]
FIG. 15 is a flowchart of the CKD record reading process performed by the CKD record access library 35 ″.
[0103]
In step 2200, the LBA of the block including the record having the designated CCHHR is calculated. R is the record number of the target record.
[0104]
LBA = (CC * cylinder capacity + HH * track capacity) / block length + ((R-1) * record length) / block length
The first term is the start address of the track containing the target record, and the second term is the offset on the track.
[0105]
Furthermore, the start offset of the target record within the block is
Offset within block = ((R-1) * Record length)% Block length
It is.
[0106]
In step 2210, using the low IO function of the UNIX operating system 40, from the LBA, only ((record length + (block length-1)) / block length) blocks, or if the record crosses blocks, further Data is read from the disk controller 80 via the SCSI interface 60 for an extra block.
[0107]
In step 2220, the read data address + in-block offset is used as a key part, and the end address of the key part is returned as a data part to the caller, and the process ends.
[0108]
The CKD record reading process will be described with reference to FIG.
The CKD record access library 35 ″ receives a request to read the VTOC record 4 from the VSAM access library 30. The VTOC starts from the record 1 at the head of the track. The block length is 512 bytes and the record length is the key part. Is 44 bytes and the data part is 96 bytes, for a total of 140 bytes.
[0109]
LBA = (CC * cylinder capacity + HH * track capacity) / 512 +
((4-1) * 140) / 512
And
Intra-block offset = ((4-1) * 140)% 512 = 420.
[0110]
In Step 2210, (140+ (512-1)) / 512 + 1 = 2
A block is read.
[0111]
In step 2220, the address of the 420th byte from the beginning of the read data is returned to the VSAM access library 30 as the key part and the address of the 464th byte as the data part.
[0112]
-Fourth embodiment of the invention-
FIG. 16 is a main part configuration diagram of the computer system according to the fourth embodiment of this invention.
[0113]
In the configuration of the computer system according to the fourth embodiment of the present invention, the VSAM access library 30 according to the first embodiment is replaced with a VSAM access library 30 ′ ″ having a slightly different function, and the CPU 11 In this configuration, VTOC utility 2300 is added.
[0114]
The main differences between the embodiment of the present invention and the embodiment of the first invention will be briefly described below.
[0115]
In the VSAM OPEN process shown in FIG. 4, the VSAM access library 30 according to the first invention reads the standard volume label and VTOC in order to search for the format 1 DSCB of the designated data set name. The VSAM access library 30 ′ ″ according to the embodiment of the present invention uses data obtained by the VTOC utility 2300 for that purpose, and does not access the disk controller 80.
[0116]
The VTOC utility 2300 operates on the VOS3 operating system 50 and accesses the disk controller 80 to obtain the format 1 DSCB of the target data set. The VOS3 operating system 50 is provided with a macro that does this and is called the OBTAIN (SEARCH) macro. The VTOC utility 2300 issues the OBTAIN (SEARCH) macro with the target data set name specified. The VOS3 operating system 50 accesses the VTOC and returns the resulting format 1 DSCB to the VTOC utility 2300.
[0117]
When the VOS3 operating system 50 accesses the VTOC, it generally uses the VTOC index or the CCW (Channel Command Word) that searches for a record having a specified key part. The VSAM access library 30 according to the embodiment of the present invention is faster than steps 505 to 540 of the VSAM OPEN process shown in FIG.
[0118]
FIG. 17 is a flowchart of the VSAM ESDS open process performed by the VSAM access library 30 ′ ″.
[0119]
In step 500, the raw IO function of the UNIX operating system 40 is opened.
[0120]
In step 2400, the VSAM access library 30 ′ ″ obtains the format 1 DSCB from the VTOC utility 2300. Specifically, the VTOC utility 2300 may be called using program-to-program communication to return the result, or the VTOC utility 2300 may be executed in advance, and the result may be input from a console by a human.
[0121]
In step 550, the format 1 DSCB is copied to a local variable in the VSAM access library 30 and the process returns to the caller. This completes the VSAM ESDS open process.
[0122]
-Embodiment of the fifth invention-
FIG. 19 is a block diagram showing the principal parts of the computer system according to the fifth embodiment of the present invention.
[0123]
In the configuration of the computer system according to the fifth embodiment of the present invention, the VSAM access library 30 according to the first embodiment is replaced with a VSAM access library 30 ″ ″ having a slightly different function, and further to the CPU 11. The lock utility 2600 is added.
[0124]
The embodiment of the present invention has a mechanism for solving the following problems that the embodiment of the first invention has.
[0125]
The VOS3 operating system 50 accesses data by an interface according to the count key data format and manages the data, and the UNIX operating system 40 accesses data by an interface according to the fixed-length block format and manages the data. Both operating systems have information on whether or not each data set in the disk device 100 is in use in the memory managed by each operating system. For this reason, it is not known which data set each other is using. For this reason, it is impossible to prevent a problem that the application program 21 operating on the VOS3 operating system 50 deletes the data set currently referred to by the application program 20 operating on the UNIX operating system 40. Such a defect must be avoided because it may cause malfunction of the application program or operating system or destruction of the data set. For this reason, the embodiment of the present invention has a lock utility 2600.
[0126]
The lock utility 2600 is a program that runs on the VOS3 operating system 50. The lock utility 2600 requests the VOS3 operating system 50 to use the data set that the VSAM access library 30 ″ ″ intends to access in accordance with the request of the VSAM access library 30 ″ ″. However, the lock utility 2600 does not access the data set requested for use. The UNIX operating system 40 accesses the data set via the SCSI interface. The VOS3 operating system 50 is provided with a macro for requesting use of a data set as necessary, and this is called a DYNALLOC macro. When the VSAM access library 30 ″ ″ tries to access a data set, the VSAM access library 30 ″ ″ specifies the data set name and calls the lock utility 2600. The lock utility 2600 issues the DYNALLOC macro with the target data set name specified. As a result, the data set to be accessed by the UNIX operating system 40 is also considered to be in use by the VOS3 operating system 50, so that the above-described trouble due to access conflict can be prevented.
[0127]
FIG. 20 is a flowchart of the VSAM ESDS open process performed by the VSAM access library 30 ″ ″.
[0128]
In step 2700, the VSAM access library 30 "" designates the name of the data set to be opened and calls the lock utility 2600. Specifically, there is a method of calling the lock utility 2600 using inter-program communication. The lock utility 2600 issues a DYNALLOC macro to the VOS3 operating system 50 to request use of the data set. As a result, the data set cannot be accessed from an application program running on the VOS3 operating system 50.
[0129]
The following processing is the same as that in FIG.
[0130]
FIG. 21 is a flowchart of the VSAM ESDS closing process performed by the VSAM access library 30 ″ ″.
[0131]
In step 2800, the VSAM access library 30 "" designates the name of the data set to be closed and calls the lock utility 2600. The lock utility 2600 issues a DYNALLOC macro to the VOS3 operating system 50 to signal the end of use of the data set. As a result, the data set can be accessed from an application program running on the VOS3 operating system 50.
[0132]
The following processing is the same as in FIG.
[0133]
In the embodiment of the present invention, a data set opened by the VSAM access library 30 ″ ″ cannot be accessed at all from an application program operating on the VOS 3 operating system 50. For example, it is possible to allow reading of the data set but not update. For this purpose, the VSAM access library 30 ″ ″ may give the lock utility 2600 a sharing mode of the data set in addition to the data set name, and the lock utility 2600 may issue a DYNALLOC macro according to the sharing mode.
[0134]
The VSAM access library 30 "" uses the lock utility 2600 to create a new data set managed by the VOS3 operating system 50 in the disk device 100 according to the request of the application program 20 running on the UNIX operating system 40. can do. Similarly, a data set can be deleted, or the size of an existing data set can be expanded or reduced.
[0135]
【The invention's effect】
According to the computer system of the present invention, data can be shared between the mainframe and the open system. As a result, a more flexible, inexpensive and high-performance computer system can be configured.
[Brief description of the drawings]
FIG. 1 is a main part configuration diagram of a computer system according to a first embodiment of this invention;
FIG. 2 is a main part configuration diagram of the UNIX operating system according to the first embodiment of this invention;
FIG. 3 is a flowchart showing a processing procedure of an application program according to the embodiment of the first invention of the present invention.
FIG. 4 is a flowchart showing a procedure of VSAM OPEN processing according to the first embodiment of this invention;
FIG. 5 is a flowchart showing a VSAM READ processing procedure according to the first embodiment of this invention;
FIG. 6 is a flowchart showing a procedure of VSAM CLOSE processing according to the first embodiment of this invention;
FIG. 7 is a flowchart illustrating a procedure of CKD record reading processing according to the first embodiment of this invention;
FIG. 8 is a flowchart illustrating a SCSI READ processing procedure according to the first embodiment of this invention;
FIG. 9 is a data structure diagram of a track format according to the embodiment of the first invention of the present invention.
FIG. 10 is a block diagram showing the main part of a computer system according to an embodiment of the second invention of the present invention.
FIG. 11 is a data structure diagram of a track format according to the embodiment of the second invention of the present invention.
FIG. 12 is a flowchart illustrating a SCSI READ processing procedure according to the second embodiment of this invention;
FIG. 13 is a block diagram showing the main part of a computer system according to a third embodiment of the present invention.
FIG. 14 is a data structure diagram of a track format according to the third embodiment of the present invention.
FIG. 15 is a flowchart illustrating a procedure of CKD record reading processing according to the third embodiment of this invention;
FIG. 16 is a block diagram showing the principal parts of a computer system according to an embodiment of the fourth invention of the present invention;
FIG. 17 is a flowchart showing a procedure of VSAM OPEN processing according to the fourth embodiment of this invention;
FIG. 18 is a block diagram showing the principal parts of a computer system according to an embodiment of the second invention of the present invention;
FIG. 19 is a block diagram showing the principal parts of a computer system according to an embodiment of the fifth invention of the present invention.
FIG. 20 is a flowchart showing a VSAM OPEN processing procedure according to the fifth embodiment of the present invention;
FIG. 21 is a flowchart showing a VSAM CLOSE processing procedure according to the fifth embodiment of the present invention;
[Explanation of symbols]
10, 11 CPU
20, 21 Application program
30, 30 ''', 30 "" VSAM access library
35, 35 "CKD record access library
40 UNIX operating system
50 VOS3 operating system
60, 61 SCSI interface
70, 71 channel interface
80 disk controller
90 buffers
100, 100 ', 100 "" disk device

Claims (17)

A first calculator;
A second calculator;
A storage system connected to the first computer and the second computer;
A computer system comprising:
The storage device system includes the first 1 A first interface according to a count key data format connected to the calculator of
A second interface according to a fixed-length block format connected to the second computer;
A storage device,
Said 1 The calculator 1 To the storage system via the interface. 1 Send data for
The storage device system includes the first 1 Is stored in the storage device,
The storage device stores position information indicating a storage position of the first data in the storage device;
The second computer acquires the position information from the storage device via the second interface;
Converting the position information into position information according to a fixed-length block format;
A computer system, wherein an access request including position information converted into a fixed-length block format is transmitted to the storage device system via the second interface. The computer system according to claim 1,
The storage device stores data according to a count key data format,
The storage system transmits second data in accordance with a count key data format including the first data to the second computer based on the access request received from the second computer. A computer system. A computer system according to claim 2, wherein
The computer system, wherein the second interface is SCSI. A computer system according to claim 2, wherein
The second computer selects a data part from the second data according to the count key data format, and causes the application program to use the data stored in the data part. A computer system according to claim 4, wherein
The computer system according to claim 2, wherein the second data is data stored in a track in the storage device in which the first data is stored. A storage system;
A first computer connected to the storage device system via a first interface according to a count key data format of the storage device system;
A second computer connected to the storage device system via a second interface according to the fixed-length block format of the storage device system,
The first computer transmits first data to the storage device system via the first interface;
The storage device system receives first data from the first computer via the first interface, stores the first data in a storage device included in the storage device system,
The second computer obtains storage location information of the first data stored in the storage device in the storage device from the storage device system via the second interface. Then, the storage device system is accessed based on the storage position information, and the second data stored in the track in the storage device in which the first data is stored is transmitted through the second interface. A computer system characterized by receiving data. A computer system according to claim 6, wherein
The second data is data according to a count key data format, and the second computer extracts a data part from the second data, and an application program executed by the second computer for data in the data part A computer system characterized by having it used. A computer system according to claim 7, wherein
The storage location information acquired from the storage device system by the second computer is data according to the count key data format,
The second computer converts the storage location information into data according to a fixed-length block format, and accesses the storage device system by transmitting an access request having the converted data to the storage device system. A computer system. A first interface according to a count key data format connected to the first computer;
A second interface according to a fixed-length block format connected to a second computer;
A storage device,
Receiving first data from the first computer via the first interface;
Storing the first data in the storage device;
In response to a request from the second computer, position information in accordance with a count key data format indicating the storage position of the first data stored in the storage device in the storage device, Output from the interface
An access request having location information indicating a storage location of the first data converted into the fixed-length block format by the second computer is received from the second computer via the second interface. ,
A storage system that transmits second data including the first data to the second computer based on the received position information. The storage device system according to claim 9,
The storage device system stores data according to a count key data format, and the second data is data according to a count key data format. The storage device system according to claim 10,
The storage system according to claim 2, wherein the second interface is SCSI. The storage device system according to claim 10,
Of the second data transmitted to the second computer, data in the data portion is selected by the second computer, and the application program of the second computer is executed on the data in the data portion A storage system characterized by causing the system to be used. The storage device system according to claim 12, wherein
The storage device system, wherein the second data is data stored in a track in the storage device in which the first data is stored. A storage system connected to a first computer and a second computer,
A first interface for receiving from the first computer first data according to a count key data format;
A storage device for storing the first data;
According to the request received from the second computer, the storage location information of the first data stored in the storage device is transmitted to the second computer, and the second computer based on the storage location information is transmitted. The second data stored in a track in the storage device in which the first data is stored in response to the access request is received from the second data And a second interface according to a fixed-length block format for transmission to a computer. 15. The storage device system according to claim 14, wherein
The second data transmitted from the second interface to the second computer is data according to the count key data format, and data in the data portion of the second data is executed by the second computer. A storage system characterized by being used by an application program. The storage device system according to claim 15, comprising:
The storage location information transmitted from the second interface to the second computer is data according to the count key data format, and an access request received by the second interface from the second computer is the second A storage system comprising: storage location information converted from a count key data format to a fixed-length block format by the computer. The storage device system according to claim 16, wherein
The storage system according to claim 1, wherein the second interface is a channel interface, and the second interface is a SCSI interface.

Images