System for multi-volume, write-behind data storage in a distributed processing system

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 09/136,149, filed Aug. 18, 1998, entitled “SYSTEM FOR MULTI-VOLUME, WRITE-BEHIND DATA STORAGE IN A DISTRIBUTED PROCESSING SYSTEM,” the entirety of which is hereby incorporated herein by reference. Further, this application contains subject matter which is related to the subject matter of the following applications, each of which is assigned to the same assignee as this application and filed on the same day as this application. Each of the below-listed applications is hereby incorporated herein by reference in its entirety:

“METHOD FOR MULTI-VOLUME, WRITE-BEHIND DATA STORAGE IN A DISTRIBUTED PROCESSING SYSTEM,” by Cadden et al., U.S. Pat. No. 6,223,262 and

“MULTI-VOLUME, WRITE-BEHIND DATA STORAGE IN A DISTRIBUTED PROCESSING SYSTEM,” by Cadden et al., U.S. Pat. No. 6,216,209.

TECHNICAL FIELD

The present invention relates to mass storage of computer systems. More particularly, the invention relates to a write-behind enablement process which allows writing of data to multiple volumes of storage media associated with one or more server nodes in a distributed processing environment.

BACKGROUND OF THE INVENTION

In a distributed client/server storage environment, a client process will send data for storage to a remote server node, which writes the data to the actual storage medium. The ability to write data to remote storage medium allows an application program to use hardware that is associated with processors other than the one the application program is running on. The sharing of hardware resources in this way is a main advantage of a distributed computing environment. In order to improve performance within such an environment, it is desirable that the client program write several blocks of data to the server node for storage before reading a response from the server node to see if the transferred blocks of data have been written correctly. This technique of writing to the server node multiple blocks of data before confirming at a predetermined interval that the data has been correctly written is referred to as a “write-behind” function. With this function, communication overhead and delays between the client and server are minimized.

One difficulty with the write-behind process occurs because the client node does not continually check for status after sending each block of data. It will not be notified that the storage medium is full until the predetermined number of blocks have been sent to the server. Thus, the client node may only be notified of an end of volume condition after it has sent several additional blocks of data following the first block of data that would not fit in the storage medium.

One way that previous products have handled this problem is to require the client program to know the size of the storage medium before writing to it. As the client writes blocks of data to the storage medium, it knows that after a pre-specified number of blocks it must stop writing, and transition to a new storage medium. By doing this, the client never sends extra blocks to the server that cannot be written to the existing medium, and the problem is avoided.

There are two penalties for requiring the client to know the size of the storage media ahead of time. The first is that it is inconvenient to the programmer who must specify the storage medium size. The second is that in order to be safe, the maximum number of blocks is often not written to the storage medium. Thus, part of each storage medium may go unused.

In view of the above, a different approach to data transfer interfacing of the client and server nodes is desired.

DISCLOSURE OF THE INVENTION

Briefly summarized, in a first aspect a distributed processing system is presented which has multiple processors. One processor is designated a client node and one or more other processors each comprise a server node. The server node has at least one storage medium associated therewith. The client node is adapted to write blocks of data from a client process running thereon to a first storage medium of a first server node of the distributed processing system. The writing continues until a physical end of storage is reached for the first storage medium, and the physical end of storage is reached without the size of the first storage medium having been predetermined. The client node and the first server node are adapted to switch between blocks of data from the first storage medium to a second storage medium of a second server node of the distributed processing system, wherein the switching is transparent to the client process of the client node. Further, the writing of blocks of data from the client node to the first storage medium comprises a write-behind operation, and the first server node periodically notifies the client node whether previously received blocks of data have been correctly written to the first storage medium.

In another aspect, a distributed processing system is presented wherein multiple processors are coupled together, one processor comprising a client node and one or more other processors each comprising a server node. Each server node has at least one storage medium associated therewith. The client node is adapted to write blocks of data from a client process of the client node to a first storage medium of the at least one storage medium associated with a first server node of the distributed processing system. The writing continues until a physical end of the first storage medium is reached, wherein the physical end of the storage medium is reached without having predetermined a size of the first storage medium. The system further includes means for switching the writing of blocks of data to a second storage medium after reaching the physical end of the first storage medium. The second storage medium is either associated with the first server node or is associated with a second server node of the system. The writing of blocks of data to the first storage medium comprises a write-behind operation wherein the first server periodically notifies the client node whether previously received blocks of data have been correctly written to the first storage medium. The client node is adapted to ascertain for the client process how many blocks of data were written to the first storage medium.

In a still further aspect, a distributed processing system is presented wherein multiple processors are coupled together. One processor comprises a client node and one or more other processors comprise server nodes. Each server node has at least one storage medium associated therewith. The client node is adapted for writing blocks of data from a client process to a first storage medium associated with a first server node of the system. The writing continues until a physical end of the first storage medium is reached. The physical end of the first storage medium is reached without having predetermined a size of available storage in the first storage medium. The system also includes means for writing a header label to a second storage medium when the end of the first storage medium is reached. The second storage medium comprises a storage medium associated with the first server node or a storage medium associated with a second server node of the system. Means for switching is provided for switching the writing of blocks of data to the second storage medium after the physical end of the first storage medium is reached. The writing of blocks of data to the first storage medium comprises a write-behind operation wherein the first server node periodically notifies the client node whether previously received blocks of data have been written correctly to the first storage medium.

The concepts presented herein produce numerous advantages over conventional client/server interfacing for a write-behind process in a distributed processing environment. First, enhanced flexibility is provided by allowing the client application to store blocks of data to storage media associated with different processors within the distributed environment. Thus, a client application may switch writing blocks of data from a first tape mounted on a first drive on a first processor to a second tape mounted on a second drive of a second processor in the distributed processing system. Further, with an application programming interface as described herein, it is possible for client programs to track exactly how many blocks of data have been written to each storage medium so that future access to a specific block of data on a specific storage medium is possible. Advantageously, enhanced flexibility is provided herein to the client application for the client program to write its own headers. The multi-volume data transfer process disclosed herein allows a client process to use the full capacity of the storage medium in a multiple tape volume backup without requiring prior knowledge on the size of each tape when writing the blocks of data. Thus, the present invention provides better storage performance within a distributed tape environment.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-described objects, advantages and features of the present invention, as well as others, will be more readily understood from the following detailed description of certain preferred embodiments of the invention, when considered in conjunction with the accompanying drawings in which:

FIG. 1 is a schematic diagram of a distributed data processing system usable with the present invention;

FIG. 2 is a simplified block diagram of a distributed processing system incorporating data storage concepts in accordance with the present invention;

FIG. 3 is a diagram of “write-behind” data transfers between a client program on a client node and a server program on a server node in the distributed system of FIG. 2, wherein the server program confirms to the client program the correct writing of blocks of data to the storage medium every n data blocks;

FIG. 4 is a diagram of data transfers occurring when a physical end of the storage medium receiving the blocks of data is reached and confirmation of correct writing of each block of data has been sent from the server to the client;

FIG. 5 is a diagram of “write-behind” data transfers occurring between the client program and the server program, with an end of physical storage medium being reached after writing data block m;

FIG. 6 is a diagram of “write-behind” data transfers occurring between the client program and server program, showing a switch in writing from a first storage medium on a first server node to a second storage medium on a second server node;

FIG. 7 is a diagram of “write-behind” data transfers occurring between the client program and the server program, wherein data blocks m+1 through m+x transferred from the client program to the server program are returned unwritten after the server has noted that the present storage medium is full;

FIG. 8 is a diagram of a client program starting the new server to enable the switching of writing of blocks of data from a full storage medium to a new storage medium associated with the new server;

FIG. 9 is a diagram of the client program writing labels to the server program for storage prior to writing blocks of data to a storage medium in accordance with the present invention;

FIG. 10 is a diagram of “write-behind” data transfers occurring between a client program and a new server program for writing previously returned data blocks to the new storage medium associated with the new server node in accordance with the present invention;

FIG. 11 is a diagram of “write-behind” data transfers between the client and new server showing writing of data blocks m+x+1 . . . , after returned data blocks m+1 through m+x have been written by the client node to the new storage medium in accordance with the present invention;

FIG. 12 is a flowchart of one embodiment of client processing for multi-volume, “write-behind” data transfers in accordance with the principles of the present invention;

FIG. 13 is a flowchart of one embodiment of the client Application Programming Interface (API client) and server data transfers/processings for an API open call from the client node to the server node in accordance with the present invention;

FIG. 14 is a flowchart of one embodiment of an API write call by the client node to the server node in accordance with the present invention;

FIG. 15 is a flowchart of one embodiment of a “QueryWriteBuffer” API call by the client node to the server node in accordance with the present invention;

FIG. 16 is a flowchart of one embodiment of a “FlushWriteBuffer” API call by the client node to the server node in accordance with the present invention; and

FIG. 17 is a flowchart of one embodiment of an API close call by the client node to the server node in accordance with the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

FIG. 1 is a schematic diagram of a distributed computer system <b>100</b> useable with the present invention. The distributed computer system <b>100</b> may be an IBM RISC System/6000 Scalable POWERparallel Systems (SP) distributed computer system available from International Business Machines Corporation of Armonk, N.Y. The embodiment disclosed in FIG. 1 is an SP computer having a total of 8 frames, with each frame having up to 16 nodes, for a total of 128 nodes. All of the nodes <b>106</b> are joined by a local area network (LAN) <b>102</b>. Each node <b>106</b> is a computer itself, and may be a RISC System/6000 workstation, as is well-known by those skilled in the art.

All of the nodes in a frame of the SP computer <b>100</b> are included in a LAN segment which is joined by the other LAN segments through LAN gates <b>104</b>. Also connected to the LAN <b>102</b>, is a control workstation (CWS) <b>112</b> which controls operation of the SP computer <b>100</b>. The control workstation has a direct access storage device (DASD) <b>114</b> referred to as the System Shared Disk on which is stored the system data repository (SDR) files. The SDR files include such information as a list of nodes that are in the system and their configuration, and includes resources and object definitions for each of the nodes <b>106</b>. Each node <b>106</b> also includes a DASD device <b>107</b> for storing data processed by the SP computer <b>100</b>.

In one embodiment, the nodes in each frame are also connected to an IBM Scalable POWERparallel switch (SPS) <b>105</b>. Each of the SPS switches <b>105</b> of each frame is connected to neighboring SPS switches <b>105</b> of other frames by a bus <b>110</b>.

As is well understood in the art, the CWS node <b>112</b> sends system data and control signals to the frames of the SP computer <b>100</b> by means of the LAN <b>102</b> while messages and data may be sent from one to another of the nodes <b>106</b> by means of the high performance switches <b>105</b>.

FIG. 2 depicts a simplified diagram of a distributed computer system <b>200</b> usable with the present invention. System <b>200</b> includes multiple processors, each of which may comprise an IBM RISC System/6000 Scalable POWERparallel Systems (SP) as referenced above in connection with FIG. <b>1</b>. In this example, one processor comprises a client node <b>210</b> (node A), and two other processors comprise server nodes <b>220</b> &amp; <b>230</b> (nodes B &amp; C). Node A <b>210</b> communicates with node B <b>220</b> and node C <b>230</b> across a network <b>215</b> as described above. A client program runs on client node <b>210</b>. The client program, which is also referred to as the client process, client application or user application, employs an application programming interface (API) <b>225</b> for writing blocks of data into storage media <b>240</b> associated with server node B <b>220</b> and/or storage media <b>250</b> associated with server node C <b>230</b>.

Each storage media <b>240</b> &amp; <b>250</b> may comprise one or more storage medium. Examples of storage medium or devices usable with this invention include magnetic-tape units, direct-access storage devices (DASD), optical disks, printers, teleprocessing devices, communication controllers and sensor-based equipment, including optical devices. A preferred embodiment of the invention is described herein in relation to a particular storage device, i.e., magnetic-tape storage; however, it will be apparent to one of ordinary skill in the art that the invention is also applicable to the other storage devices noted. In the embodiment shown, storage media <b>240</b> includes a first tape drive and storage media <b>250</b> includes a second tape drive.

As briefly noted above, the present invention is directed to handling multiple volume tape data transfers in a distributed environment such as depicted in FIGS. 1 &amp; 2, where a “write-behind” process is employed to write the storage volumes. Numerous difficulties with implementing this process are first identified below, then solved pursuant to the present invention.

Continuing to reference FIG. 2, the client program within client node A sends blocks of data for storage to a remote tape server, e.g., the server program of server node B <b>220</b>. The tape server then writes the actual tape, i.e., storage media <b>240</b>, with the blocks of data. In order to improve performance, it is desirable that the client program write several blocks to the server before reading a response from the server to see if the blocks have been written correctly. As noted, the technique is referred to in the art as “write-behind” processing.

FIG. 3 depicts an example of the data transfers between the client program and the server program in a properly operating write-behind process. Multiple blocks of data (block 1 . . . block n) are forwarded from the client program to the server program, which periodically responds with a read response back to the client program. The first read response comprises an indication of whether block 1 . . . block n of data have been correctly written to the tape. Assuming that the blocks of data have been correctly written, the process continues with the next n blocks of data (blocks n+1 . . . 2n), after which a next read response is returned from the server program to the client program.

In a multi-volume storage implementation, when a tape becomes full, the server program must recognize the end of tape condition and respond to the client program by indicating that one or more received blocks of data could not be written. In one example, the client program must then tell the server program to mount a new tape (i.e., initiate a new storage medium), after which the client program must resend the blocks of data that could not be written to the server program for writing to the new tape, along with any remaining blocks of data. This process must be repeated each time a tape becomes full. Conventionally, loss of blocks of data has been avoided in a multi-volume implementation by predetermining the size of the tape and terminating transfer of data from the client node to the server node commensurate with reaching the end of tape.

FIG. 4 presents a diagram of an ideal end of tape process. After sending block m, the server program responds to the client program by indicating that the storage tape is full either prior to or partially through block m. The client program instructs the server program to switch to a new tape, i.e., assuming multiple storage tapes are available at the designated server node. The server program returns a response to the client program confirming the switch to the new tape and the block of data m is re-transmitted along with any remaining blocks of data m+1 . . . .

A first difficulty appears in a write-behind operation because the client program does not check for status after sending each block of data. Thus, the client program may not be notified of the end of tape condition until it has sent several blocks of data after a first data block that would not fit on the current tape storage. FIG. 5 presents an example of this problem. Blocks m through m+1 are forwarded from the client program to the server program for storage. At some subsequent point in time, the server program responds to the client program by indicating that the tape reached full upon receipt of block m. The client program sends a command to the server program to switch to a new tape, and the server program responds with a response confirming the switch to the new tape. Thereafter, the client program continues to send data beginning with block of data m+x+1. However, blocks of data m+1 . . . m+x would have been lost in this case and the resulting multi-volume tape would be missing data.

A second difficulty, related to the first problem, is that the client program may need to know exactly how many blocks of data have been written to each storage medium or volume. Certain applications rely on this information to access specific blocks of data from multiple volume data sets. If the client node knows how many blocks of data were written to each tape, then the applications running thereon can read a specific block of data quickly by loading only the volume that contains the block of data to be read. Using the “write-behind” process makes it more difficult for the client program to know exactly how many blocks of data have been written to each volume, i.e., assuming that each volume size has not been predetermined prior to writing the blocks of data.

A third problem is identified when it is considered that the second tape may be associated with a different tape drive, and that tape drive may reside on a different machine or server node than the first tape drive (see FIG. <b>2</b>). In this case, a new server program must be contacted or started on the new node, and all blocks of data that could not be written to the first tape must be sent to the new node for writing on the second tape. FIG. 6 presents an example of the data transfer occurring in this scenario.

As shown in FIG. 6, blocks of data m . . . m+x are forwarded from the client program to a first server program. Thereafter, the first server program provides a response to the client program indicating that the first tape was full after receipt of block m. The client program then closes the connection or stops the first tape server and contacts or starts a second tape server on a new node. A new storage tape is mounted by the second server program and a response is sent from the second server program to the client program confirming switching writing of blocks of data to the second tape. Thereafter, blocks of data m+x+1 are forwarded from the client program to the second server program for writing to the second tape. The error in this example, obviously, is a loss of blocks of data m+1 . . . m+x. Correct handling of data requires that these blocks of data be transferred from the first server node (e.g., server node B of FIG. 2) to the second server node (e.g., server node C of FIG. <b>2</b>).

Preferably, the solution to the first three problems identified above will be packaged in an application programming interface (API) so that multiple client applications can use common commands. The client programs call entry points, such as open, close, and write in order to write blocks of data to storage. This creates a fourth difficulty however. Certain client programs need to write customized header labels on the tapes commensurate with the storage of data.

Thus, when a logical end of tape condition is encountered, the client program will preferably be able to do the following:

1. Switch volumes;

2. Write header labels to the new volume;

3. Write the blocks that previously couldn't be written to the current volume to the new volume; and

4. Continue writing to the new tape from the point at which the logical end of the prior volume was encountered.

To summarize, the present invention is directed to handling multiple volume tape data transfers in a distributed environment where write-behind processing is employed. Four main difficulties in accomplishing this are identified:

1. The client program is not notified immediately when a tape is full, therefore, it may send several data blocks which cannot be stored on the receiving tape before the client program is notified of the end of tape condition;

2. The client program must be able to find out how many blocks of data have been written to each tape;

3. The next volume of a multi-volume file may need to be written on a different machine than the preceding volume; and

4. A program calling an API that handles the first three difficulties may want to write its own header label(s) to the next volume.

The solution presented herein addresses each of these problems. Note that the invention assumes that writing of blocks of data to the first tape is performed without any intelligence to predetermine the size of the storage medium and thereby anticipate termination of writing upon reaching end of tape. With the exception of label writing, the end of tape processing and data handling presented herein is preferably transparent to the client program.

One embodiment of a general process flow in accordance with the principles of the present invention is first outlined and then described in greater detail below. As an overview, processing in accordance with the present invention includes:

1. A client program calling a tape API open function (discussed below) to open a file;

2. The client program then calls a tape API write function (discussed below) to write blocks of data to the tape;

3. When the end of tape condition is detected at the server program, the server sets a flag to indicate that all blocks of data received from this point on should be sent back to the client program. This will cause the data transfer flow depicted in FIG. <b>7</b>.

The figure assumes that end of tape is reached after block m. Upon indicating to the client program that the tape is full after block m, the server program returns unwritten data blocks m+1 . . . m+x;

4. The tape API write call returns a value to the calling program that indicates an end of volume condition has occurred;

5. The client program receives the unwritten blocks that the server program returns to it and buffers them in a “write-behind buffer” so that the data blocks can be written to a next tape;

6. The calling program then calls the tape API close (discussed below) and open functions to switch to a new volume. If the new volume resides on another machine (i.e., a different processor or node), this will cause a new tape server to be contacted or started as depicted in FIG. 8;

7. If the calling program is writing its own header labels, then the calling program calls the tape API write function to write the header labels for the new tape as shown in FIG. 9;

8. The client program now calls the tape API “FlushWriteBuffer” function (discussed below) to “flush” the unwritten data blocks in the write-behind buffer (that were received from the server program in step <b>4</b> ). As shown in FIG. 10, these “flushed” blocks of data (i.e., data blocks m+1 . . . m+x) are forwarded from the client program to, for example, the new server program; and

9. As shown in FIG. 11, data transfer continues as normal from this point forward until all blocks of data have been written to the new tape or an end of tape condition is reached at the new tape, after which the process outlined above would repeat.

FIG. 12 is a flowchart of one embodiment of client program processing in accordance with the principles of the present invention. Note that one embodiment for allocating a tape device, opening and closing a tape file and writing data to tape is available from an International Business Machines Corporation publication entitled “IBM Network Tape Access and Control System for AIX and IBM NetTape Tape Library Connections User's Guide and Reference”, Release 1.1, Fourth Edition (August, 1996) (http://www.rs6000. ibm.com/resource/aix_resource/sp_books/nettape/index.html), and International Business Machines Corporation publication entitled “IBM Network Tape Access and Control System for AIX and IBM NetTape Tape Library Connections User's Guide and Reference”, Release 1.2, Fifth Edition (August, 1997) (http://www.rs6000.ibm.com/software/appfinder/datamanagement.html), the entirety of both of which are hereby incorporated herein by reference.

As shown in FIG. 12, processing begins by the client program calling the API “open function” to start the server and mount a tape <b>310</b>, which in actuality comprises two API functions. In particular, API “allocate” will start the server if it has not been started and will mount the tape, while API “open” will open the tape for writing of data thereto. One embodiment of this combined API “open function” is depicted in FIG. <b>13</b>. Initially, the API client determines whether the server is running <b>500</b>. If “no”, then the server is started <b>510</b> and connection between the client and server is confirmed <b>520</b> &amp; <b>530</b>. If the server is already running, then the API client proceeds to send an open command <b>540</b> to the server. The open command is received at the server <b>550</b> and tape storage is mounted and opened <b>560</b>. Results of this process are then returned <b>570</b> to the API client which reads the results <b>580</b>. Upon confirming the opening of the tape storage, the API client returns to point of call <b>590</b>.

Returning to FIG. 12, after starting the server and mounting the tape, the client program calls the API write function to write a tape label <b>320</b>, after which inquiry is made whether there are more blocks of data to be written <b>330</b>. If “yes”, then the API write function is called to write the first/next block of data to the tape <b>340</b>. After writing to the tape, processing inquires whether the tape is full <b>360</b>. If the tape is not full and there are more blocks of data to be written, then the client program continues in a loop to call the API write function and sequentially write the multiple blocks of data to the tape. Once there are no more blocks, then the API close function is called to close and unmount the tape <b>350</b>.

FIG. 14 presents one embodiment of API and server write processing. The API write command sends a first/next block of data to the server <b>600</b>. The block of data is received at the server from the client <b>605</b> and the server program determines whether the data block should be saved <b>615</b>. Data blocks should be saved if they cannot currently be written to tape. If “no”, then the block of data is written to the tape <b>625</b>, after which the server determines whether the tape is full <b>635</b>. If the tape is full, then a flag is set to indicate that all future received blocks of data should be saved for return <b>645</b>. Once the flag is set, processing proceeds (from inquiry <b>615</b> ) to save the block of data <b>655</b>.

The server process next determines whether it is time to send a reply to the API client <b>665</b>. If “no”, then the write process is complete <b>675</b>. Otherwise, a reply is sent to the API client <b>685</b>. Returning to the API client, after sending a block of data, the API client determines whether it is time to receive a reply <b>620</b>. If “no”, then the process returns to point of call <b>670</b>. Assuming that a reply is to be received, then the API client receives the reply from the server <b>630</b>.

At the server, after sending the reply, the server determines whether there are blocks of data saved that need to be returned to the API client <b>695</b>. If “no”, processing is complete <b>705</b>. In parallel, the API client is determining whether there are saved blocks at the server which need to be returned to the client <b>640</b>. If there are blocks saved at the server that are to be returned to the client, then a first/next block is sent from the server to the API client <b>715</b>. The server then determines whether there are additional saved blocks of data <b>725</b> and if “yes”, the server continues in the loop until all data blocks have been sent. In parallel, the API client receives the first/next block <b>650</b> from the server and inquires whether there are additional data blocks saved at the server <b>660</b>. If “yes”, the API client continues in a receive loop until all data blocks have been received, after which return is made to the point of call <b>670</b>. At the server, once all data blocks have been forwarded to the API client, the save flag is reset so that future blocks of data will be written to tape <b>735</b>.

One embodiment of the API “close function” is depicted in FIG. <b>17</b>. This “close function” comprises two actual API functions, namely, “close” which closes the tape to further writing of data, and “unallocate” which unmounts the tape. As shown, a command to close <b>900</b> is sent from the client API to the server node which receives the close command <b>910</b> and closes the file, which may, for example, include unmounting the tape if magnetic tape storage is employed <b>920</b>. Confirmation of the closing of the file is then sent <b>930</b> from the server program back to the API client which receives the response <b>940</b>, and thereafter returns to point of call <b>950</b>.

Returning t o FIG. 12, assuming that a physical end of tape is reached without writing all blocks of data to the tape, then processing calls an API “QueryWriteBuffer” function to find out how many blocks have been sent back from the server program to the client program <b>370</b>. Again, the blocks of data returned to the client program are held in a write-behind buffer. The API “QueryWriteBuffer” function is a new interface call in accordance with the present invention which allows, for example, the client program to determine how many blocks have been written to each tape, and to write header information at the start of each tape as described below. With the server write-behind feature enabled, applications can use the “QueryWriteBuffer” interface call to query the number of remaining write-behind buffers which didn't get written to the current tape when the tape server encounters an end of tape situation. Applications can calculate the number of blocks is written to the current tape using the following formula: <maths><math overflow="scroll"><mrow><mtable><mtr><mtd><mrow><mi>actual</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>number</mi></mrow></mtd></mtr><mtr><mtd><mrow><mrow><mrow><mi>of</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>data</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>blocks</mi></mrow><mo></mo><mstyle><mtext> </mtext></mstyle><mo>=</mo></mrow><mo></mo><mstyle><mtext> </mtext></mstyle></mrow></mtd></mtr><mtr><mtd><mrow><mi>written</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>to</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>the</mi></mrow></mtd></mtr><mtr><mtd><mrow><mi>current</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>tape</mi></mrow></mtd></mtr><mtr><mtd><mstyle><mtext> </mtext></mstyle></mtd></mtr></mtable><mo></mo><mtable><mtr><mtd><mrow><mi>cumulated</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>number</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>return</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>value</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>of</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>the</mi></mrow></mtd></mtr><mtr><mtd><mtable><mtr><mtd><mtable><mtr><mtd><mrow><mi>of</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>data</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>blocks</mi></mrow></mtd><mtd><mrow><mstyle><mtext> </mtext></mstyle><mo>-</mo></mrow></mtd><mtd><mrow><mstyle><mtext> </mtext></mstyle><mo></mo><mrow><mrow><msup><mo> </mo><mi>``</mi></msup><mo></mo><mi>Query</mi></mrow><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>Write</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><msup><mi>Buffer</mi><mi>″</mi></msup></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mi>written</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>since</mi></mrow></mtd><mtd><mstyle><mtext> </mtext></mstyle></mtd><mtd><mrow><mrow><mi>interface</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>call</mi></mrow><mo></mo><mstyle><mtext> </mtext></mstyle></mrow></mtd></mtr></mtable></mtd></mtr><mtr><mtd><mtable><mtr><mtd><mrow><mi>opening</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>the</mi><mo></mo><mstyle><mtext> </mtext></mstyle><mo></mo><mi>current</mi></mrow></mtd></mtr><mtr><mtd><mi>tape</mi></mtd></mtr></mtable></mtd></mtr></mtable></mtd></mtr></mtable></mrow></math><img id="EMI-M00001" file="US06289422-20010911-M00001.TIF" img-content="math" img-format="tif" /><attachments><attachment idref="MATHEMATICA-00001" attachment-type="nb" file="US06289422-20010911-M00001.NB" /></attachments></maths>

FIG. 15 presents one embodiment of the API “QueryWriteBuffer” function process. Again, this process is called after reaching the physical end of tape of a first storage medium, where blocks of data have been returned to the client node and are currently being held in the write-behind buffer. The client API determines how many blocks have been sent from the server to the client using one or more conventional counters or count mechanisms. After determining the number of data blocks, the process returns <b>810</b> to point of call.

Subsequent to determining how many blocks of data have been returned to the client program, the client process calls the API close function to close and unmount the current tape <b>380</b>. The API close function could be implemented as depicted in FIG. 17, and described above.

Continuing with FIG. 12, after closing the current tape, the API open function is called by the client process <b>390</b>. If desired, a new server program can be started on a new processor of the distributed processing system, where a new tape is mounted for receiving blocks of data from the client program. Note that the same process described herein can be used to switch between any number of additional tapes and the claims presented are intended to encompass any such implementation. The switching to a new processor, i.e., a new server node, is optional and based upon the amount of tape storage available at the first server node. Assuming that the first server node has multiple tapes, then as noted, switching can occur between tapes without changing the server node.

After writing a label to the new tape, the API client calls the “FlushWriteBuffer” function to send the unwritten blocks (that were received into the write-behind buffer from the first server process) to the current server where they will be written to the new tape <b>410</b>. FIG. 16 depicts one embodiment of the “FlushwriteBuffer” function. As shown, the API client initially determines whether there is a block of data in the return buffer <b>820</b>. If so, then the next block of data is forwarded <b>830</b> to the new server process where it is received <b>840</b>. The received block of data is written to the new tape <b>850</b>. After all blocks of data have been written to the new tape, return is made to point of call <b>860</b>. After completing the API “FlushWriteBuffer” function, processing (of FIG. 12) returns to inquire whether there are any more blocks to write to tape <b>330</b>.

As noted, the “QueryWriteBuffer” and “FlushWriteBuffer” functions allow a calling program to determine how many blocks have been written to each tape, and to write returned data blocks to a new tape after switching tapes. If an application needs to write its own header information at the beginning of a tape volume, it can define the configurable options within the tape client configuration file as:

client.wbh yes

client.flush no

If the “client.flush” option is set to “no”, the tape server will not write the remaining write-behind buffers to the beginning of the next tape volume until the application calls the “FlushwriteBuffer” function. With the new “FlushWriteBuffer” interface call, after the volume switch event has occurred, the application can write its own header information to the beginning of the tape and then invoke the “FlushWriteBuffer” interface call to write the remaining write-behind buffers before continuing with the normal write operation. If the “QueryWriteBuffer” call is successful, the call returns the number of blocks of data in the write-behind buffers of the device. Otherwise, it returns an error condition. To use the “FlushWriteBuffer” function, the tape server write-behind feature must be enabled without automatic buffer flushing. This can be done by specifying the following key words in the tape client configuration file:

client.wbh yes

client.flush no

If the call is successful, the value “<b>0</b>” is returned. Otherwise, an error condition code is generated.

The present invention can be included, for example, in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. This media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The articles of manufacture can be included as part of the computer system or sold separately.

Additionally, at least one program storage device readable by machine, tangibly embodying at least one program of instructions executable by the machine, to perform the capabilities of the present invention, can be provided.

The flow diagrams depicted herein are provided by way of example. There may be variations to these diagrams or the steps (or operations) described herein without departing from the spirit of the invention. For instance, in certain cases, the steps may be performed in differing order, or steps may be added, deleted or modified. All of these variations are considered to comprise part of the present invention as recited in the appended claims.

While the invention has been described in detail herein in accordance with certain preferred embodiments thereof, many modifications and changes therein may be effected by those skilled in the art. Accordingly, it is intended by the appended claims to cover all such modifications and changes as fall within the true spirit and scope of the invention.