Computer, computer system, and data transfer method

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application is related to and claims priority from Japanese Patent Application No. 2000-205509, filed on Jul. 6, 2000.

BACKGROUND OF THE INVENTION

[0002] The present invention relates generally to data transfer between computer systems and more particularly to techniques for transferring data between computer systems were each employs a storage unit storing data in a different format.

[0003] As their external storage unit, mainframe hosts employ a magnetic disk unit which uses a variable-sized record data format to store data. Conventionally, this type of magnetic disk unit has a CKD (Count Key Data) interface which enables access to variable-sized record data. That is, conventionally, storage of variable-sized record format data is physically implemented in a magnetic disk unit having a CKD interface.

[0004] Recently, there have been employed magnetic disk units which are relatively inexpensive and used in open hosts such as personal computers and workstations, and which use a fixed-sized block (FBA: Fixed Block Architecture) format to store data. For example, RAID (Redundant Array of Inexpensive Disks) composed of a plurality of such magnetic disk units has become widely used. As described by a paper entitled “A Case for Redundant Arrays of Inexpensive Disks (RAID)” by D. Patterson, G. Gibson, and R. H. Kartz (ACM SIGMOD Conference, Chicago, Ill., June 1988, pp. 109-116), which was published in ACM SIGMOD Conference at the University of Illinois, Chicago, RAID is a technique in which a plurality of relatively inexpensive and low-reliability disk units are connected to distribute and store data to a plurality of disk units in order to realize performance enhancement by transferring data in parallel, and high availability by storing redundant data.

[0005] Incidentally, a “disk unit” recognized by a host maybe either an actual disk unit or a RAID composed of a plurality of disk units. To discriminate disk units in these two layers, a disk unit recognized by a host is hereinafter called a “logical disk unit”, while a “physical disk unit” refers to an actual disk unit which has a CKD interface and stores CKD format data, or which has an FBA interface and stores FBA format data.

[0006] Further, hereinafter, a variable-sized record format used by mainframe hosts is called the “CKD format”; a disk unit which has a CKD interface and stores data in the CKD format is called a “CKD disk unit”; and a disk unit which stores data in the FBA format is called an “FBA disk unit”.

[0007] Still further, hereinafter, a CKD disk unit recognized by a host is called a “logical CKD disk unit”, while an FBA disk unit recognized by a host is called a “logical FBA disk unit”. On the other hand, an actual CKD disk unit is called a “physical CKD disk unit”, while an actual FBA disk unit is called a “physical FBA disk unit”.

[0008] When it is not necessary to discriminate between a logical FBA disk unit and a physical FBA disk unit, they are each simply called an FBA disk unit, while when it is not necessary to discriminate between a logical CKD disk unit and a physical CKD disk unit, they are each simply called a CKD disk unit. It should be noted that a logical FBA disk unit and a physical FBA disk unit may be actually the same FBA disk unit, and similarly, a logical CKD disk unit and a physical CKD disk unit may be the same CKD disk unit.

[0009] As described above, a physical FBA disk unit used for RAID has a SCSI interface, etc. and stores data in the FBA format. Therefore, in a storage system connected to a mainframe host to receive CKD format data from a CKD interface and write the data into a physical disk unit of the FBA format, it is necessary to incorporate a transformation mechanism transforming the CKD format to the FBA format as well as its reverse transformation mechanism.

[0010] For example, a mainframe computer which has a SCSI interface and incorporates an FBA disk unit in its frame is a Mutiprise 2000, produced by IBM Corp. of Armonk N.Y. In this mainframe, the CPU issues a group of commands (CCW: Channel Command Word) to access CKD format data as input/output requests. And a disk control processor dedicated for input/output control of built-in disk units receives/understands the requests, transforms them to a group of commands (SCSI commands) to access FBA format data, and inputs/outputs the data to/from an FBA disk unit. This transformation mechanism makes it possible to use an FBA disk unit as an external storage unit for a mainframe computer without changing application programs and the OS which conventionally assume use of a CKD disk unit. Another example of a format transformation mechanism of this type is disclosed in, for example, Japanese Laid-Open Patent Publication No. 6-150557 (1994).

[0011] In order to support administrative decision making by obtaining actual sales results and analyzing market needs, needs for OLAP and data mining utilizing business data held by enterprise systems which use a mainframe host are recently increasing. To accommodate the needs, a data linkage function has become important in which basic data stored in databases implemented in CKD disk units of mainframe computers is transferred to PCs and workstations, and used there.

[0012] As a method for transferring data stored in a CKD disk unit of such a mainframe computer to an open host (for example a PC or workstation), the data may be transferred between the hosts through a network such as a LAN. However, this method imposes a load on both hosts and the network, which might have an adverse influence such as reduced execution speed of other business operations. To cope with this problem, a technique disclosed in U.S. Pat. No. 5,983,317 issued Nov. 9, 1999 and U.S. Pat. No. 6,041,391 issued Mar. 21, 2000, transfers data as follows.

[0013] A storage unit composed of a physical FBA disk unit and a disk controller is connected to both a mainframe host and an open host. The disk controller of this disk unit operates so that the mainframe host recognizes the physical FBA disk unit as a logical CKD disk unit A, while the open host recognizes the same physical FBA disk unit as a logical FBA disk unit B.

[0014] First, the mainframe host reads out transfer target data stored in another CKD disk unit, generates intermediate data, and stores it in the logical CKD disk unit A. At that time, the disk controller transforms the transfer data from the CKD format to the FBA format, and writes it into the physical FBA disk unit according to a write request issued from the mainframe host to write the transfer data to the logical CKD disk unit. This transformation is performed so that count fields and data fields of the data of the CKD format remain and are included in the transformed data of the FBA format after the transformation.

[0015] Next, the open host requests access to the intermediate data written into the logical FBA disk unit B. The disk controller reads from the physical FBA disk unit the intermediate data to which access has been requested, and transfers the data to the open host without changing its FBA format.

[0016] The open host recognizes the CKD format data included in the transferred FBA format data, and performs processes such as extraction of necessary data excluding count fields, and character code conversion before using the data.

[0017] According to the above technique disclosed in U.S. Pat. Nos. 5,983,317 and 6,041,391, in order to transfer data stored in a CKD disk unit of a mainframe host to an open host, it is necessary to perform two input/output operations: writing of transfer target data read from the CKD disk unit into a physical FBA disk unit and reading of the transfer target data from the physical FBA disk unit. Because of this, it takes time to transfer data.

[0018] Thus there is a need to transfer data between host systems each handling data of a different format, at higher speed.

SUMMARY OF THE INVENTION

[0019] The present invention provides techniques, including a method and system, for transferring data between computer systems, for example, a mainframe and a Personal Computer (PC), having storage systems of different formats, efficiently.

[0020] One exemplary embodiment provides a method for transferring data from a first system, having a first processor and a first memory, using a first format to a second system, having a second processor and a second memory, using a second format. The method includes a first system receiving data of a first format from a first disk unit; processing the data of the first format into transformed data, where the transformed data is the data transformed into the second format; storing the transformed data in the first memory; and sending the transformed data from the first memory to the second system responsive to a request from the second system.

[0021] Another embodiment of the present invention transfer data of different formats at high speeds. This embodiment provides a computer having a processor for issuing an access command to access data of a first format, and a memory, the computer adopting the following configuration.

[0022] The computer comprises: an interface for receiving from another computer an access command to access data of a second format different from the first format; first command processing means for, according to a write command issued by the processor to write data of the first format, receiving the data, and storing the data in the memory; and second command processing means for, according to a read command issued by the another computer to read data of the second format, reading out the data stored in the memory by the first command processing means, and transferring the data to the another computer.

[0023] In another embodiment of the present invention a method for transferring data from the first computer to a second computer is provided; the method includes: a step of, according to a write command issued by a processor of the first computer to write data of a first format (for example, a variable-sized record format), storing the data in a memory of the first computer; and a step of, according to a read command issued by a second computer to read data of a second format (for example, a fixed-sized block format), transferring the data stored in the memory from the first computer to the second computer.

[0024] That is, the processor of the above first computer does not need to perform an input/output operation on a physical storage unit after acquiring the data to be transferred. Therefore, it is possible to transfer data at higher speed. Furthermore, since writing of data into a memory by the processor of the first computer and reading of the data from the memory by the second computer are each performed using a storage unit access of a type supported by each command-issuing computer, it is not necessary to change the architecture of each command-issuing computer, making it possible to utilize existing resources.

[0025] In one embodiment of the present invention software is provided. Specifically, software stored in a computer readable medium for transferring data from a first format at a first system, comprising a first processor and a first memory, to a second format at a second system, comprising a second processor and a second memory. The software including: code for receiving data of a first format from a first disk unit by said first system; code for processing said data of said first format into transformed data, wherein said transformed data is said data transformed into said second format; code for storing said transformed data in said first memory; and code for sending said transformed data from said first memory to said second system responsive to a request from said second computer.

[0026] In another embodiment a computer readable medium for storing code is provided. The code is for accessing data by a first computer, wherein said first computer, having a fixed-sized block storage unit storing data of a fixed-sized block format, accesses information stored in a second computer, including a variable-sized record storage unit storing data of a variable-sized record format. The computer readable medium includes: code for emulating a logical fixed-sized block storage unit by use of a storage area of said second computer in which information read from said variable-sized record storage unit is stored; and code for accessing information in said logical fixed-sized block storage unit from said first computer.

BRIEF DESCRIPTION OF THE DRAWINGS

[0027]FIG. 1 is a block diagram showing the configuration of a computer system according to a first embodiment of the present invention.

[0028] FIGS. <b>2</b>(<i>a</i>) and <b>2</b>(<i>b</i>) are diagrams showing a CKD data format used by an embodiment of the present invention.

[0029]FIG. 3 is a diagram showing an FBA data format used by an embodiment of the present invention.

[0030]FIG. 4 is a diagram showing a configuration of a disk cache according to the first embodiment of the present invention.

[0031]FIG. 5 is a diagram showing a configuration of cache allocation information according to the first embodiment of the present invention.

[0032]FIG. 6 is a diagram showing a configuration of segment control information according to the first embodiment of the present invention.

[0033]FIG. 7 is a flowchart showing the processing procedure for a CKD command process according to the first embodiment of the present invention.

[0034]FIG. 8 is a flowchart showing the processing procedure for an FBA command process according to the first embodiment of the present invention.

[0035]FIG. 9 is a flowchart showing the processing procedure for a transfer data generation process according to the first embodiment of the present invention.

[0036]FIG. 10 is a flowchart showing the processing procedure for a data transferring process according to the first embodiment of the present invention.

[0037]FIG. 11 is a block diagram showing the configuration of a computer system according to the first embodiment of the present invention.

[0038]FIG. 12 is a flowchart showing the processing procedure for a transfer data generation process according to a second embodiment of the present invention.

[0039]FIG. 13 is a flowchart showing the processing procedure for a formatting process according to the second embodiment of the present invention.

[0040]FIG. 14 is a flowchart showing the processing procedure for a data transferring process according to the second embodiment of the present invention.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

[0041] A first embodiment of the present invention will be first described.

[0042]FIG. 1 shows the configuration of the first embodiment of the present invention. As shown in the figure, a computer system according to this embodiment comprises a mainframe host <b>100</b>, an FBA disk unit <b>150</b> connected to the mainframe host <b>100</b>, a CKD disk unit <b>151</b> also connected to the mainframe host <b>100</b>, an open host <b>160</b>, and an FBA disk unit <b>152</b> connected to the open host <b>160</b>.

[0043] The mainframe host <b>100</b> comprises at least one CPU <b>101</b>, at least one storage control processor <b>102</b>, a main storage <b>103</b>, at least one accessing unit for FBA data <b>104</b>, at least one accessing unit for CKD data <b>105</b>, and at least one receiving unit for FBA data access <b>106</b>.

[0044] The open host <b>160</b> comprises a CPU <b>120</b>. The open host may be, for example, a PC or workstation. Application processes implemented by application programs and the OS run in the CPU <b>120</b>. The OS performs such controls as allocation of memory for running application processes, and management of the file system, etc. An application process accesses an external storage unit through the OS. In this embodiment, a transfer data transferring process <b>124</b> including a format transformation process <b>125</b> is implemented in the CPU <b>101</b> as one of application processes.

[0045] The open host <b>160</b> and the mainframe host <b>100</b> are connected to each other through a communication line for FBA access <b>170</b> and a communication line <b>140</b>. Specifically, the communication line for FBA access <b>170</b> is formed by, for example, a SCSI bus, while the communication line <b>140</b> is formed by a LAN, etc.

[0046] In the mainframe host <b>100</b>, application processes, such as a Database management system, implemented by application programs and the OS run in the CPU <b>101</b>. The OS performs such controls as allocation of memory for running application processes, and management of the file system, etc. An application process accesses an external storage unit through the OS. In this embodiment, a transfer data generation process <b>121</b> is implemented in the CPU <b>101</b> as one of application processes.

[0047] The main storage <b>103</b> is used as areas for storing data and programs employed by each CPU <b>101</b>, and a disk cache area <b>107</b> used to input/output data to/from the FBA disk unit <b>150</b>. Furthermore, the main storage <b>103</b> stores cache control information <b>108</b> for controlling data in the disk cache <b>107</b>, and storage control information <b>109</b> for controlling each disk unit.

[0048] The storage control processor <b>102</b> has a CKD command process <b>122</b> for emulating a logical CKD disk unit using the FBA disk unit <b>150</b> for host programs such as the OS.

[0049] Generally, a host program can handle only CKD disk units. Therefore, in order for a host program to be able to access the FBA disk unit <b>150</b> as a logical CKD disk unit, the CKD command process <b>122</b> emulates the logical CKD disk unit using the disk cache <b>107</b>, the FBA disk unit <b>150</b>, and the storage control information <b>109</b> described later.

[0050] Specifically, the CKD command process <b>122</b> performs mapping control between a logical CKD disk unit and the FBA disk unit <b>150</b>, in addition to reception of a request for access to a CKD disk unit, and an input/output operation on the FBA disk unit <b>150</b> using the disk cache <b>107</b> as described later.

[0051] The storage control processor <b>102</b> also has an FBA command process <b>123</b> for emulating a logical FBA disk unit using the FBA disk unit <b>150</b> for the open host <b>160</b>. The FBA command process <b>123</b> receives a request for access to the logical FBA disk unit from the open host <b>160</b> through the receiving unit for FBA access <b>106</b>, and performs input/output operation on the FBA disk unit <b>150</b> using the disk cache <b>107</b> described later.

[0052] The storage control processor <b>102</b> still also has an invalidation process <b>129</b> for controlling invalidation of data in the disk cache <b>107</b>.

[0053] The accessing unit for FBA data <b>104</b> connects the mainframe host <b>100</b> with the FBA disk unit <b>150</b>, and transfers access interface commands and data in the FBA format between them.

[0054] The accessing unit for CKD data <b>105</b> connects the mainframe host <b>100</b> with the CKD disk unit <b>151</b>, and transfers access interface commands and data in the CKD format between them.

[0055] The receiving unit for FBA data access <b>106</b> connects the open host <b>160</b> to the mainframe host <b>100</b>, receives access interface commands in the FBA format transmitted from the open host <b>160</b>, and delivers the commands to the storage control processor <b>102</b>. Furthermore, the receiving unit for FBA data access <b>106</b> controls the transfer of access target data between the mainframe host <b>100</b> and the open host <b>160</b>.

[0056] The communication line <b>140</b> is used for communications between the mainframe host <b>100</b> and the open host <b>160</b>. In this embodiment, the line is used only for event notifications such as notification of completion of intermediate data generation. Because of this, it is not necessary to employ a high-speed or wide-band communication line as the communication line <b>140</b>.

[0057] The communication lines for FBA access <b>170</b> connect between the accessing unit for FBA data <b>104</b> and the FBA disk unit <b>150</b>, between the receiving unit for FBA data access <b>106</b> and the open host <b>160</b>, and between the open host <b>160</b> and an FBA disk unit <b>152</b>. Communications using a communication protocol such as a SCSI for FBA disk units are carried out through the communication lines <b>170</b>.

[0058] A communication line for CKD access <b>171</b> connects between the accessing unit for CKD data <b>105</b> and the CKD disk unit <b>151</b>. Communications using a communication protocol for CKD disk units are carried out through the communication line <b>171</b>.

[0059] It should be noted that the communication lines for FBA access <b>170</b> and the communication line for CKD access <b>171</b> may be formed by either parallel channels using metal cables or serial channels using optical fiber cables.

[0060] Next, description will be made of the relationship between the FBA format, which is a recording format for the FBA disk unit <b>150</b>, and the CKD format, which is a recording format for logical CKD disk units emulated using the FBA disk unit <b>150</b>.

[0061] As shown in FIG. 2(<i>a</i>), the storage area of a logical CKD disk unit is composed of a plurality of fixed-sized CKD tracks. Each CKD track is composed of one home address (HA) <b>510</b> and one or more records <b>500</b>. HA <b>510</b> is the first field of each CKD track (located at the head of the track).

[0062] Each record <b>500</b> includes one or more fields, that is, a count field <b>501</b> and a data field <b>502</b>, and, depending on the case, a key field (not shown) before the data field. The count field <b>501</b> is a fixed-sized field, and stores the address of the record <b>500</b> and the length of the next fields (the above data field <b>502</b> and the key field). The length of each record <b>500</b> is allowed to be varied, that is, the length of the data field <b>502</b> can differ from one record <b>500</b> to another. To accommodate this, each count field <b>501</b> stores the length of the data field <b>502</b> of the record and the length of the key field, which makes it possible to obtain the length of each field of the record by referring to its count field <b>501</b>. The address of each record <b>500</b> is indicated by a set of a cylinder number, a head number, and a record number.

[0063] On the other hand, as shown in FIG. 3, the storage area of the FBA disk unit <b>150</b> is composed of a plurality of FBA tracks. Each FBA track is composed of blocks <b>600</b> which are predetermined-fixed-sized areas, and each block <b>600</b> is uniquely numbered in the FBA disk unit <b>150</b>. Therefore, to access an area in the FBA disk unit <b>150</b>, it is enough to specify the number of the first block <b>600</b> of the area, and the number of the blocks <b>600</b> which follow the first block and correspond to the area.

[0064] In this embodiment, the FBA disk unit <b>150</b> as described above is used to emulate a logical CKD disk unit, each CKD track in the logical CKD disk is assigned to enough blocks <b>600</b> to store the CKD track, and the contents of each CKD track are stored in the corresponding blocks <b>600</b>.

[0065] The above assignment is performed as follows.

[0066] First, as shown in FIG. 2(<i>b</i>), each CKD track is divided into portions the size of the fixed-sized block <b>600</b>, and the head portion of the first CKD track indicated by both the cylinder number <b>0</b> and the head number <b>0</b> is assigned to the head block <b>600</b> indicated by the number <b>0</b>. Then, CKD track portions which follow the head portion are assigned to the subsequent blocks <b>600</b> until the entire first CKD track is assigned. After that, the head portion of the CKD track indicated by the cylinder number <b>0</b> and the head number <b>1</b> is assigned to the next subsequent block <b>600</b>. By repeating the above procedure, the entire portions of each CKD track are assigned to corresponding blocks <b>600</b>.

[0067] In this case, since the length of each CKD track is fixedly decided by the type of logical CKD disk unit employed, the following formulas give the head block number of blocks <b>600</b> storing a CKD track and the number of blocks per tack from the address of the CKD track.

number of blocks per CKD track=&lt;CKD track capacity/block capacity&gt;  (Formula 1)

number of head block of CKD track=(cylinder number*number of heads+head number)*number of blocks per CKD track  (Formula 2)

[0068] In the above formula 1, &lt;x&gt; denotes a minimum integer equal to or more than x. For example, when the capacity of the block <b>600</b> is 2048 bytes and the capacity of a CKD track is 52K bytes and the number of heads is 15, the number of blocks per track is calculated to be &lt;25.39 . . . &gt;, that is, 26. In this case, the number of the head block of the CKD track indicated by the cylinder number <b>0</b> and the head number <b>1</b> is 26, while the number of the head block of the CKD track indicated by the cylinder number <b>100</b> and the head number <b>5</b> is 39,130.

[0069] A set of blocks <b>600</b> to which a CKD track is assigned is hereinafter called a block group.

[0070] Next, description will be made of the disk cache area <b>107</b>, the cache control information <b>108</b>, and the storage control information <b>109</b> implemented in the main storage <b>103</b> of the mainframe host <b>100</b>.

[0071] First, the storage control information <b>109</b> will be described.

[0072] The storage control information <b>109</b> holds information indicating the mapping between FBA disk units <b>150</b> and logical CKD disk units. Specifically, the storage control information <b>109</b> stores information on each logical CKD disk unit, such as the number and the capacity of an FBA disk unit <b>150</b> assigned to the logical CKD disk unit, and the type, the track length, the number of cylinders, the number of heads, etc. of the logical CKD disk unit. On the other hand, the number of a logical CKD disk unit assigned to each FBA disk unit <b>150</b> is also stored. As for an FBA disk unit <b>150</b> to which no logical CKD disk unit has been assigned, the entry field stores information indicating no assignment.

[0073] As described above, based on the storage control information <b>109</b>, the CKD command process <b>122</b> emulates a logical CKD disk unit using the FBA disk unit <b>150</b>.

[0074] Next, the disk cache <b>107</b> will be described.

[0075] The disk cache <b>107</b> temporally stores data read from the FBA disk unit <b>150</b> as well as data to be written to the FBA disk unit <b>150</b>.

[0076]FIG. 4 shows a configuration of the disk cache <b>107</b>.

[0077] According to the example shown in the figure, the disk cache <b>107</b> is divided into small fixed-sized portions called segments <b>200</b>. One segment <b>200</b> stores one block group (CKD track).

[0078] Finally, the cache control information <b>108</b> will be described.

[0079] The cache control information <b>108</b> is used to control the disk cache <b>107</b>, and stores control information such as assignment of a segment <b>200</b> to each block group.

[0080]FIG. 5 shows cache allocation information <b>300</b> included in the cache control information <b>108</b>, while FIG. 6 shows segment control information <b>410</b> also included in the cache control information <b>108</b>.

[0081] In FIG. 5, the cache allocation information <b>300</b> is composed of a number of segment control information pointers <b>301</b> equal to the total number of block groups, each pointer indicating whether a segment <b>200</b> has been assigned to one of the block groups in the FBA disk unit <b>150</b>. The NULL value is set to a segment control information pointer <b>301</b> for a block group to which a segment <b>200</b> has not been assigned, while to a segment control information pointer <b>310</b> for a block group to which a segment <b>200</b> has been assigned, the position of the segment control information <b>410</b>, described later, corresponding to the segment <b>200</b> is set.

[0082] A valid segment control information queue pointer <b>302</b>, a free segment control information queue pointer <b>303</b>, and a resident segment control information queue pointer <b>304</b> are root pointers each pointing to the corresponding queue. The valid segment control information queue is formed by sequentially pointing to each piece of segment control information <b>410</b> already assigned to a block group, one piece pointing to the next, using a pointer in the segment control information <b>410</b> itself, while the free segment control information queue is formed by sequentially pointing to each piece of segment control information <b>410</b> not assigned to a block group, one piece pointing to the next, using a pointer in the segment control information <b>410</b> itself. Furthermore, the resident segment control information queue is formed by sequentially pointing to each piece of segment control information <b>410</b> already assigned to a block group which is designated as a resident target, one piece pointing to the next, using a pointer in the segment control information <b>410</b> itself.

[0083] Cache residency information <b>305</b> indicates whether each block group is designated as a cache resident. Here, a cache resident means that a block group is stored in the disk cache <b>107</b> for a predetermined period of time or a period of time specified by the cache residency information <b>305</b>. It should be noted that the cache residency information <b>305</b> may be a flag employed for each block group, that is, each CKD track, indicating whether the block group should be a cache resident. Alternatively, the cache residency information <b>305</b> may indicate the first track address of CKD tracks and the number of the tracks assigned to each range of block groups designated as a cache resident. In this embodiment, the storage control processor <b>102</b> sets the cache residency information <b>305</b> according to a residency instruction given by an application process running in the CPU <b>101</b> using channel commands, etc., or a residency instruction from a service processor. The residency instruction used in this embodiment specifies the range of CKD tracks corresponding to a range of resident-target block groups as a resident range, using the logical CKD disk unit number and the address of the first CKD track and the number of tracks indicating the target range. To reset a resident range, the storage control processor <b>102</b> changes the cache residency information <b>305</b> also according to a residency instruction given by an application process running in the CPU <b>101</b> using channel commands, etc., or a residency instruction from a service processor.

[0084] Referring to FIG. 6, the segment control information <b>410</b> is provided for each segment <b>200</b> in the disk cache <b>107</b>. An assigned block group <b>400</b> in the segment control information <b>410</b> stores the CKD disk unit number and the disk address of the CKD track assigned to a block group to which the corresponding segment <b>200</b> has been assigned. A segment pointer <b>401</b> stores the address of the corresponding segment <b>200</b> in the disk cache <b>107</b>. A validation flag <b>402</b> indicates whether data stored in the segment <b>200</b> is valid. The validation flag <b>402</b> is set ON when a block group read from the FBA disk unit <b>150</b> is stored in the segment <b>200</b>, while it is set OFF when cache allocation to the segment <b>200</b> is cancelled. A dirty flag <b>403</b> indicates that a change operation (write operation) on a block group stored in the segment <b>200</b> is still being performed, or the change is not reflected in the FBA disk unit <b>150</b> due to a fault or some other reason. A segment queue pointer <b>404</b> is actually composed of a valid segment control information queue pointer, a free segment control information queue pointer, and a resident segment control information queue pointer. They are used to form queues such as the valid segment control information queue and the free segment control information queue as described above, and each point to the position of the next segment control information <b>410</b> in the respective queue. A resident flag <b>405</b> indicates whether the corresponding segment <b>200</b> is set to be resident.

[0085] Using the disk cache <b>107</b> and the cache control information <b>108</b> as described above, the invalidation process <b>129</b> monitors each piece of segment control information <b>410</b>. And when a write operation is performed on the segment <b>200</b> corresponding to segment control information <b>410</b> designated as a resident target by the resident flag <b>405</b>, the invalidation process <b>129</b> leaves the write data resident in the disk cache <b>107</b> without discarding it for a predetermined period of time or a period of time specified by the cache residency information <b>305</b> event after the write data was written into a disk unit. When a write operation is performed on the segment <b>200</b> corresponding to segment control information <b>410</b> not designated as a resident target by the resident flag <b>405</b>, on the other hand, the invalidation process <b>129</b> controls the cache staying time of the write data using a known method such as the LRU method after the write data was written into a disk unit.

[0086] Next, description will be made of access operation on the FBA disk unit <b>150</b> or a logical CKD disk unit corresponding to the FBA disk unit <b>150</b>, and the CKD disk unit <b>151</b> in a configuration as described above.

[0087] Incidentally, in the following descriptions, it is assumed that CCW is used as commands for the access interface of a logical CKD disk emulated by the CKD disk unit <b>151</b> or the FBA disk unit <b>150</b>, while SCSI commands are used as commands for the access interface of the FBA disk unit <b>150</b>.

[0088] Furthermore, in the following descriptions, for clarification, it is assumed that when a host program in the mainframe host <b>100</b> accesses a logical CKD disk unit corresponding to the FBA disk unit <b>150</b>, a CKD track is used as the access data unit, while when the open host <b>160</b> accesses the FBA disk unit <b>150</b>, a block group is used as the access data unit.

[0089] When a host program in the mainframe host <b>100</b> accesses the CKD disk unit <b>151</b>, a read request CCW is sent to the CKD disk unit <b>151</b> directly from the CPU <b>101</b> through the accessing unit for CKD data <b>105</b> in order to access CKD format data. On a read access, CKD format data is read from the CKD disk unit <b>151</b>, and transferred to the originator of the access request, while on a write access, CKD format data received from the originator of the access request is written into the CKD disk unit <b>151</b>.

[0090] When a host program in the mainframe host <b>100</b> accesses a logical CKD disk unit emulated by the FBA disk unit <b>150</b>, the CKD command process <b>122</b> in the storage control processor <b>102</b> receives a read/write request CCW from the CPU <b>101</b>. Upon receiving the request, the CKD command process <b>122</b> performs the processing shown in FIG. 7.

[0091] First, step <b>801</b> calculates the address of a block group in the FBA disk unit <b>150</b> to which the access target CKD has been assigned, based on the read/write request CCW received from the CPU <b>101</b>. Specifically, based on a logical CKD disk unit number specified as an access position and the storage control information <b>109</b>, the position in the FBA disk unit <b>150</b> corresponding to the head position of the logical CKD disk unit is calculated. Using this position as a reference, based on a CKD track size and a CKD track number specified as an access position, a block group to which the access-target CKD track has been assigned is obtained by use of the formula (2) described above. A block group to which an access-target CKD track is assigned is hereinafter called an access-target block group.

[0092] The access command type is determined at step <b>802</b>. If it is a read command, the process flow proceeds to step <b>803</b>, while if it is a write command, the process flow proceeds to step <b>820</b>.

[0093] At step <b>803</b>, it is determined whether a segment <b>200</b> has been assigned to the access-target block group by checking the cache control information <b>108</b>. If a segment <b>200</b> has not been assigned to the access-target block group, the process flow proceeds to step <b>804</b> at which a segment <b>200</b> is assigned. Assignment of a segment <b>200</b> is performed by selecting a piece of segment control information <b>410</b> connected to the free segment control information queue, transferring it to the valid segment control information queue, and registering the address of the transferred segment control information <b>410</b> in a segment control information pointer <b>301</b> in the cache allocation information <b>300</b>.

[0094] At step <b>805</b>, it is determined whether the access-target block group is in a range designated as a resident target by checking the cache control information <b>108</b>. If it is in a resident target range, the process flow proceeds to step <b>806</b> at which the resident flag <b>405</b> of the segment control information <b>410</b> assigned to the access-target block group is set ON, and this segment control information <b>410</b> is connected to the resident segment control information queue.

[0095] Step <b>807</b> checks whether the validation flag <b>402</b> in the segment control information <b>410</b> for the segment <b>200</b> assigned to the access-target block group is ON to determine whether the access-target block group is stored in the segment <b>200</b>. If it is stored in the segment, this state is hereinafter called a cache hit state, while if it is not stored, on the other hand, this is called a cache miss state. In the case of a cache miss state, the process flow proceeds to step <b>808</b> at which a read request SCSI command to read the access-target block group is issued to the FBA disk unit <b>150</b>. With this, the access-target block group is read from the FBA disk unit <b>150</b>, and stored in the segment <b>200</b> assigned to the access-target block group. Then, the validation flag <b>402</b> in the segment control information <b>410</b> for this segment <b>200</b> is set ON.

[0096] Step <b>809</b> transfers the data stored in the segment <b>200</b> to an area in the main storage <b>103</b> used by the CPU <b>101</b> as its data area.

[0097] Step <b>810</b> notifies the CPU <b>101</b> of the completion of input/output processing requested by the CPU <b>101</b>. It should be noted that issuance of the notification to the CPU <b>101</b> is performed by issuing to the CPU <b>101</b> an interruption indicating the completion.

[0098] On the other hand, if the access command type is determined to be a write command at step <b>802</b>, a flow of processes at steps <b>820</b> through <b>824</b> is performed. Processes at steps <b>820</b> through <b>823</b> are the same as those at steps <b>803</b> through <b>806</b> for the read processing.

[0099] Step <b>824</b> transfers and stores the write data into the segment <b>200</b> assigned to the access-target block group, sets ON both the dirty flag <b>403</b> and the validation flag <b>402</b>. Step <b>825</b> issues to the FBA disk unit <b>150</b> a write request SCSI command to write the write data stored in the segment <b>200</b> into the access-target block group. When writing of the write data is completed, the dirty flag <b>403</b> in the segment control information <b>410</b> is set OFF. Finally, at step <b>810</b>, the CPU <b>101</b> is notified of the completion of input/output processing requested by the CPU <b>101</b> itself.

[0100] When the open host <b>160</b> accesses a logical FBA disk unit emulated by the FBA disk unit <b>150</b>, the receiving unit for FBA access <b>106</b> receives a read/write access request SCSI command from the open host <b>160</b>, and delivers it to the FBA command process <b>123</b> in the storage control processor <b>102</b>. Upon receiving this command, the FBA command process <b>123</b> performs the processing shown in FIG. 8.

[0101] First, step <b>901</b> determines the access-target block group in the FBA disk unit <b>150</b> based on a block number specified by the SCSI command. In this embodiment, it is assumed that a block in a logical FBA disk unit emulated by the FBA disk unit <b>150</b> is mapped to a block of the same block number in the FBA disk unit <b>150</b>. In this case, the block number specified by the SCSI command directly determines the access-target block group in the FBA disk unit <b>150</b>. Since processes performed at steps <b>902</b> through <b>908</b> are the same as those at steps <b>802</b> through <b>808</b> in FIG. 7, their explanation will be omitted.

[0102] Step <b>909</b> transfers data of the access-target block group already stored in the segment <b>200</b> or newly stored in the segment <b>200</b> at step <b>908</b> to the open host.

[0103] Step <b>910</b> notifies the open host of the completion of requested input/output processing. The notification is made through the receiving unit for FBA data access <b>106</b>.

[0104] Since processes performed at steps <b>920</b> through <b>925</b> are the same as those at steps <b>820</b> through <b>825</b> in FIG. 7, their explanation will be omitted.

[0105] Description will be made below of an operation in which data stored in the CKD disk unit <b>151</b> is transferred from the mainframe host <b>100</b> to the open host <b>160</b> in a computer system as described above.

[0106] In this data transfer, the CPU <b>101</b> in the mainframe host <b>100</b> uses the transfer data generation process <b>121</b> to generate transfer data and notify the open host <b>160</b> of the results, and, upon receiving the notification, the open host <b>160</b> performs data transfer processing.

[0107] First, description will be made of processing performed in the transfer data generation process <b>121</b>.

[0108] Incidentally, it is assumed that before any processing is performed in the transfer data generation process <b>121</b>, based on the residency instruction described above, an entire logical CKD disk unit emulated by the FBA disk unit <b>150</b> or a range of CKD tracks used to store intermediate data, described later, is designated as a resident range so as to set the corresponding block groups to be resident.

[0109] As shown in FIG. 9, the transfer data generation process <b>121</b> reads transfer target data from the CKD disk unit <b>151</b>, and stores it in the main storage <b>103</b> at step <b>701</b>. At that time, the transfer data generation process <b>121</b> issues a read request CCW to read the target data of the CKD format from the CKD disk unit <b>151</b> through the accessing unit for CKD data <b>105</b>.

[0110] Step <b>702</b> generates intermediate data of the CKD format from data <b>130</b> of the CKD format read into the main storage <b>103</b>. The intermediate data is obtained by converting records <b>500</b> in the CKD format data <b>130</b> into a general-purpose form. When this transformation is not necessary, the read CKD format data <b>130</b> may be used as the intermediate data as it is.

[0111] Step <b>703</b> issues a write request CCW to write the generated intermediate data into CKD tracks in a designated resident-target range in a logical CKD disk unit emulated by the FBA disk unit <b>150</b>. Upon receiving this CCW, the CKD command process <b>122</b> writes the intermediate data of the CKD format into the logical CKD disk unit emulated by the FBA disk unit <b>150</b>.

[0112] Step <b>704</b> checks whether the above processing has been completed on all target data, and if not all target data has been processed, the process flow returns to step <b>701</b> from which the above processing is repeated. If the above processes at steps <b>701</b> through <b>703</b> have been completed on all target data, the process flow goes to step <b>705</b>.

[0113] Step <b>705</b> notifies the open host <b>160</b> of the completion of generation of the transfer data. This notification includes the unit number of the logical CKD disk unit storing the intermediate data and the tack size as well as information used for the open host <b>160</b> to determine the address of the intermediate data in the logical CKD disk unit. Here, the first track number and the number of the tracks storing the intermediate data are used as the information to determine the address of the intermediate data in the logical CKD disk unit.

[0114] When the open host <b>160</b> has received this notification, its data transferring process <b>124</b> performs the following processing.

[0115] At step <b>1001</b> shown in FIG. 10, the data transferring process <b>124</b> calculates the address of the intermediate data in a logical FBA disk unit emulated by the FBA disk unit <b>150</b> based on the unit number of the logical CKD disk unit storing the intermediate data, and information indicating the position of the intermediate data in the logical CKD disk unit sent from the mainframe host <b>100</b>.

[0116] Specifically, for example, the position in the FBA disk unit <b>150</b> corresponding to the head position of the logical CKD disk unit is obtained. Using this position as a reference, based on the track size and the first track number, the address of the head block in the FBA disk unit <b>150</b> storing the intermediate data is calculated by use of the formula (2) described above. In addition, the number of blocks in the FBA disk unit <b>150</b> storing the intermediate data is calculated from the number of the tracks by use of the formula (1) described above. In this embodiment, since it is assumed that a block in a logical FBA disk unit emulated by the FBA disk unit <b>150</b> is mapped to a block of the same block number in the FBA disk unit <b>150</b>, an address in the FBA disk unit <b>150</b> corresponds to the same address in a logical FBA disk unit emulated by the FBA disk unit <b>150</b>. Incidentally, other information necessary to calculate the address of the intermediate data in the logical FBA disk unit emulated by the FBA disk unit <b>150</b> based on the unit number of the logical CKD disk unit storing the intermediate data and information indicating the position of the intermediate data in the logical CKD disk unit, as described above, is either set in the open host beforehand, or supplied from the mainframe host to the open host together with the logical CKD disk unit number, the track size, and information for specifying other addresses in the logical CKD disk unit.

[0117] Step <b>1002</b> issues to the mainframe host <b>100</b> a read request SCSI command to read at the obtained address in the logical FBA disk unit. This read request is delivered to the storage control processor <b>102</b> through the accessing unit for FBA data <b>106</b> in the mainframe host <b>100</b>, and as a result, the intermediate data is transferred from the mainframe host <b>100</b> to the data transferring process <b>124</b>.

[0118] Then, at step <b>1003</b>, the format transformation process <b>125</b> searches the transferred intermediate data for the count fields <b>501</b> to specify the data fields <b>502</b>, and extracts only the data fields <b>502</b>. At that time, the format transformation process <b>125</b> may carry out Chinese character code conversion necessary for the open host <b>160</b> to use the data fields <b>502</b>, at the same time. Then, at step <b>1004</b>, data subjected to extraction and code conversion at step <b>1003</b> is written in the FBA disk unit <b>152</b>.

[0119] At step <b>1005</b>, it is determined whether all intermediate data has been processed. If all the data has been processed, the process flow ends; otherwise, the process flow returns to step <b>1002</b>.

[0120] The above transfer processing is summarized as follows.

[0121] The transfer data generation process <b>121</b> in the CPU <b>101</b> first reads target data from the CKD disk unit <b>151</b> and generates intermediate data <b>131</b> so that the data will be written in a range set in advance as a resident target in a logical CKD disk unit emulated by the FBA disk unit <b>150</b>. The CKD command process <b>122</b> in the storage control processor <b>102</b> actually writes the data in this logical CKD disk unit. At that time, the CKD command process <b>122</b> causes the intermediate data to stay resident in the disk cache <b>107</b> according to setting given by a residency instruction in advance. After completing generation of the intermediate data, the transfer data generation process <b>121</b> notifies the open host <b>160</b> of the completion of the generation. When the open host <b>160</b> has received the notification from the transfer data generation process <b>121</b>, its data transferring process <b>124</b> is activated. The data transferring process <b>124</b> issues to the mainframe host <b>100</b> a read request to read the intermediate data from the logical FBA disk unit emulated by the FBA disk unit <b>150</b>. This read request is received by the receiving unit for FBA data access <b>106</b>, and transferred to the storage control processor <b>102</b>. In the storage control processor <b>102</b>, the FBA command process <b>123</b> performs a read operation to read out data resident in the disk cache <b>107</b>, and transfers the data to the open host <b>160</b>.

[0122] Description will be made of a second embodiment according to the present invention.

[0123] This embodiment is different from the first embodiment in that extraction of the data fields <b>502</b> from intermediate data and Chinese character code conversion, which are carried out by the open host <b>160</b> in the first embodiment, are performed on the mainframe host side <b>100</b>.

[0124] As shown in FIG. 11, in this embodiment, a transfer data generation process <b>1110</b> in the CPU <b>101</b> generates intermediate data <b>131</b>, and writes it in a logical CKD disk unit as is the case with the above first embodiment. Then, a CKD command process <b>122</b> in a storage control processor <b>102</b> causes the intermediate data <b>131</b> to stay resident in a disk cache <b>107</b>. After that, a formatting process <b>1120</b> in the storage control processor <b>102</b> extracts data fields <b>502</b> from the intermediate data <b>131</b> stored in the CKD format, carries out Chinese character code conversion, etc. on the data fields <b>502</b> to generate converted data <b>1130</b>. Then, the converted data <b>1130</b> is made resident in the disk cache <b>107</b>, separately. After this process has been completed, the formatting process <b>1120</b> supplies the open host <b>160</b> with the address of the converted data <b>1130</b>. In the open host <b>160</b>, a data transferring process <b>124</b> reads the converted data.

[0125] More specifically, in this embodiment, the transfer data generation process <b>1110</b> performs the processing shown in FIG. 12.

[0126] After processes at steps <b>1201</b> through <b>1204</b> are performed in the same way as processes at steps <b>701</b> through <b>704</b> shown in FIG. 9 according to the above first embodiment, step <b>1205</b> notifies the storage control processor <b>102</b> of completion of generation of the intermediate data, and activates the format transformation process <b>1120</b>. This completion notification is issued with the number of the logical CKD disk unit storing the intermediate data <b>131</b>, the track size, and information for specifying the intermediate data attached to it.

[0127] Furthermore, the formatting process <b>1120</b> in the storage control processor <b>102</b> performs the processing shown in FIG. 13.

[0128] First, based on intermediate data position information sent from the transfer data generation process <b>1110</b>, step <b>1301</b> determines a target logical CKD disk unit and the address. At step <b>1302</b>, when the target intermediate data <b>131</b> does not exist in the disk cache <b>107</b>, the data is read into the disk cache <b>107</b>.

[0129] Then, step <b>1303</b> searches the intermediate data <b>131</b> in the disk cache <b>107</b> for count fields <b>501</b> to determine data fields <b>502</b>, and extracts only the data fields <b>502</b>. At that time, Chinese character code conversion, etc. may be carried out at the same time. At step <b>1304</b>, the converted intermediate data <b>1130</b> subjected to extraction and code conversion at step <b>1303</b> is written into another FBA disk unit <b>150</b><i>b </i>not assigned to any logical CKD disk unit. At that time, the entire FBA disk unit <b>150</b><i>b </i>or an area storing the data <b>1130</b> is made resident in the disk cache <b>107</b>. Incidentally, the intermediate data <b>1130</b> read from the disk cache <b>107</b> may be directly stored in an area in the disk cache <b>107</b> assigned to the FBA disk unit <b>150</b><i>b </i>after the data is subjected to format transformation.

[0130] Then, at step <b>1305</b>, it is determined whether all intermediate data has been processed. If all the data has been processed, the process flow proceeds to step <b>1306</b>; otherwise, the process flow proceeds to step <b>1302</b>.

[0131] At step <b>1306</b>, the transfer data generation process <b>1110</b> notifies the open host <b>160</b> of completion of generation of the converted intermediate data <b>1130</b>, and activates a data transferring process <b>1160</b>. This notification is issued with the number of the logical FBA disk unit <b>150</b><i>b </i>storing the converted intermediate data <b>1130</b>, the number of the head block, and the size attached to it.

[0132] The data transferring process <b>1160</b> in the open host <b>160</b> performs the following processing.

[0133] As shown in FIG. 14, step <b>1401</b> issues to the mainframe host <b>100</b> a read request to read the converted data <b>1130</b> according to the address of the converted data in the FBA disk unit <b>150</b><i>b </i>given by the transfer data generation process <b>1110</b>. With this, the converted data <b>1130</b> will be read. This read request is delivered to the storage control processor <b>102</b> through an accessing unit for FBA data <b>106</b> in the mainframe host <b>100</b> and is processed, and as a result, the converted data <b>1130</b> is transferred to the open host <b>160</b>. Step <b>1402</b> writes the read-out data into an FBA disk unit <b>152</b> connected to the open host <b>160</b>. Then, at step <b>1403</b>, it is determined whether all intermediate data has been processed. If all the data has been processed, the process flow ends; otherwise, the process flow returns to step <b>1401</b>.

[0134] According to each embodiment described above, transfer target data stored in the CKD disk unit <b>151</b> is made resident in a disk cache by writing the data in a logical CKD disk unit emulated by the FBA disk unit <b>150</b>. The transfer target data is transferred from the disk cache to the open host <b>160</b> when the open host <b>160</b> reads the data from a logical FBA disk unit emulated by the FBA disk unit <b>150</b>.

[0135] Therefore, the number of required input/output operations on an actual physical disk unit is only one, that is, reading of data from the CKD disk unit <b>151</b>. This makes it possible to transfer data at higher speed, compared with the conventional method. At the time of such a data transfer, it is a storage control processor that performs disk cache control including resident control, and receives/analyzes/processes an FBA access request from the FBA data access interface. Therefore, at that time, applications and the OS running in the CPU only write transfer target data in a logical CKD disk unit emulated by the FBA disk unit <b>150</b>. This means that it is not especially necessary to modify the applications and the OS for the above data transfer.

[0136] It should be noted that the present invention is not limited to the above embodiments as various modifications will become possible without departing from the sprit and the scope thereof.

[0137] For example, in the above embodiments, data is transferred from the mainframe host <b>100</b> to the open host <b>160</b>. However, by reversing the procedure of this transfer, data may be transferred from the open host <b>160</b> to the mainframe host <b>100</b> using the disk cache <b>107</b> of this embodiment.

[0138] For example, the open host <b>160</b> writes transfer data in a range designated in advance as a resident target in a logical FBA disk unit emulated by the FBA disk unit <b>150</b>.

[0139] At that time, the FBA command process <b>123</b> causes the intermediate data to be resident in the disk cache <b>107</b> according to setting given by a residency instruction issued in advance. Then, the transfer data generation process <b>121</b> in the mainframe host <b>100</b> issues a read request to read the transfer data from a logical CKD disk unit emulated by the FBA disk unit <b>150</b>. The CKD command process <b>122</b> reads out the transfer data resident in the disk cache, transforms it into the CKD format, and writes the converted data in the CKD disk unit <b>151</b>. Here, information necessary to recognize the positions of the resident area and the transfer data storage area in a logical FBA disk unit and a logical CKD disk unit is suitably exchanged between, for example, the open host <b>160</b> and the mainframe host <b>100</b> so that both can obtain the necessary information.

[0140] Furthermore, in the above embodiments, although a track is used as the access data unit when accessing intermediate data, a record may be used as the access data unit instead. In this case, however, the CKD command process <b>122</b>, the FBA command process <b>123</b>, etc. must calculate the position of a target record, and perform a write/read operation on each individual record. Furthermore, when variable-sized records are used, it is necessary to calculate the position of a target record based on its count field. In this case, before writing a record, it is necessary to read a block group including the record into a disk cache.

[0141] In the above embodiments, transfer target data is stored in the CKD disk unit <b>151</b>. However, the target data may be in a logical CKD disk unit emulated by the FBA disk unit <b>150</b>. In this case, the transfer data generation process <b>121</b> reads the target data from the logical CKD disk unit emulated by the FBA disk unit <b>150</b> instead of the CKD disk unit <b>151</b>. Furthermore, the FBA disk unit <b>150</b> may be a logical FBA disk unit emulated by a RAID. In this case, the storage control processor may perform the emulation of the logical FBA disk unit using the RAID, that is, perform such controls as mapping control between the logical FBA disk unit and physical FBA disk units constituting the RAID, and access control to each physical FBA disk unit, as the storage control information <b>107</b>, or alternatively a control processor employed in the RAID may perform the above controls.

[0142] In the above embodiments, a data set name as described in Japanese Laid-Open Patent Publication No. 9-258908 (1997) may be used as information which specifies the address of intermediate data in a logical CKD disk unit and which is supplied from the mainframe host <b>100</b> to the open host <b>160</b>. In this case, the open host <b>160</b> refers to data set control information for the logical CKD disk unit, as employed by the invention described in the above patent publication, to obtain the address and the size of the data set in the logical CKD disk unit, and converts this address to an address for FBA access.

[0143] Furthermore, the above embodiments employ the so-called store through system in which writing into the disk cache <b>107</b> is synchronized with writing into the FBA disk unit <b>150</b>. However, embodiments of the present invention can be applied to the so-called store back system in which writing into the disk cache <b>107</b> and writing into the FBA disk unit <b>150</b> are performed asynchronously. In this case, when a write operation is to be performed on a range designated as a resident target in a logical CKD disk unit or a logical FBA disk unit, even after occurrence of a predetermined event causes the write data to be written into the FBA disk unit emulating these disk units as in the case of a known store back system, the data may be left resident in the disk cache <b>107</b> for a predetermined period of time or a period of time specified by the cache residency information <b>305</b> without discarding the data. It should be noted that in the case of a store back system, to prevent loss of unreflected data, it is desirable to duplex the disk cache <b>107</b> or adopt a non-volatile system by use of batteries so as to enhance availability, or to add check codes, etc. so as to detect loss of unreflected data.

[0144] Even though the above embodiments actually employ the FBA disk unit <b>150</b>, when a logical CKD disk unit emulated by the FBA disk unit <b>150</b> is used only for data transfer to the open host <b>160</b>, the FBA disk unit <b>150</b> may not be used. Instead of using the FBA disk unit, areas in the main storage or areas in a memory separately provided may be used to emulate a logical variable-sized record storage unit or a logical fixed-sized block storage unit, which are emulated by the FBA disk unit <b>150</b> in the above embodiments.

[0145] Although the above functionality has generally been described in terms of specific hardware and software, it would be recognized that the invention has a much broader range of applicability. For example, the software functionality can be further combined or even separated. Similarly, the hardware functionality can be further combined, or even separated. The software functionality can be implemented in terms of hardware or a combination of hardware and software. Similarly, the hardware functionality can be implemented in software or a combination of hardware and software. Any number of different combinations can occur depending upon the application.

[0146] Many modifications and variations of the present invention are possible in light of the above teachings. Therefore, it is to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described.