1. Field of the Invention
The present invention relates generally to file systems, and in particular, to a method, apparatus, and article of manufacture for solving the difficulty incurred by a program on one computer (the client) being completely reliant on the internal file structure of another computer (the server) in order to access the server's files.
2. Description of the Related Art
Computer use has proliferated and continues to expand as technological capabilities rapidly increase. With this proliferation, the development and use of different computers running different types of operating system having different internal file systems has also increased. In a network environment, the different computers may attempt to communicate with each other including transmitting/receiving information and services to/from each other. However, when a computer program attempts to access a file on any other particular computer, the computer program is subjected to the quirks of the file system upon that computer. This includes the fact that the program trying to access the file needs to know both the name of the file, and where the file actually resides internally on the computer. Such information may not be known or may be difficult or impossible to learn and/or use. Accordingly, a method is needed for accessing information on files without knowledge of a computer's underlying file structure. These problems may be better understood by describing prior art file systems and network communications.
Depending on the type of operating system a computer is executing, the internal file system varies considerably. For example, if a computer is running the Windows™ operating system, the file system may be composed of one or more drives; either local within the computer or logically mapped to a network connection. Each drive is assigned a letter, starting from C (A and B are reserved) and ending at Z, followed by a colon (:) character. Within a given drive exists a hierarchical directory structure, using variable length names and the backward slash (\) character to indicate a level in the hierarchy. Examples of a hierarchical directory structure in the Windows operating system include those illustrated in Table 1:
TABLE 1C:\TempA directory name called Temp located onthe C drive.C:\Temp\FredA directory called Temp further containinga sub-directory called Fred.C:\Temp\Fred\file.txtA file residing in the Fred sub-directory ofthe Temp directory.
If a computer is running the UNDX™ operating system, the file system is composed of one or more “mount” points; either local within the computer or logically mapped to a network connection. Each mount point is assigned a name, and is referenced using two forward slashes (//). Within a given mount point exists a hierarchical directory structure, using variable length names and the forward slash (/) character to indicate a level in the hierarchy. Examples of a hierarchical directory structure in the UNIX™ operating system include those in Table 2:
TABLE 2//TempA directory name called Temp located onthe default mount point.//Temp/FredA directory called Temp further containinga sub-directory called Fred.//Temp/Fred/file.txtA file residing in the Fred sub-directory ofthe Temp directory.
If a computer is running the OS/390™ operating system, the file system is composed of one or more high-level prefix names that are controlled by a central catalog. Beneath the high level prefix lies one or more 1 to 8 character names, separated by a period (.) character, with a total length not exceeding 44 characters.
The combination of high-level prefix and the period-delimited suffix is called a “dataset name”. There are many types of datasets on OS/390. Each of the datasets further complicates the indicated format. One of the more common datasets is called a Partition Dataset or PDS. A PDS may contain one ore more files, indicated by use of open and close parentheses ( ). Examples of a hierarchical data structure in the OS/390 operating system include those illustrated in Table 3:
TABLE 3HILEV.temp.fred.FileA dataset containing many files.HILEV.temp.fred.File(txt)A dataset name calledHILEV.temp.fred.file containing a filecalled txt.
The details of the file systems are not necessary for understanding the present invention. However, it should be recognized that the file systems are all different. In this regard, a computer program trying to access a file on any particular computer is subjected to the quirks and details of the file system upon that computer. Such details include the fact that the program trying to access the file needs to know both the name of the file, and where the file actually resides internally on the other computer.
The prior art necessity for knowledge of the file system details may be illustrated by the following example. Assume three different computers (servers) are communicating: one running OS/390, one running Windows™, and the third one running UNIX. Each server houses a copy of a file. In each case, the file is the same in the sense that its content is identical. It is only the file system upon which the file resides that varies from one machine to the next.
A fourth computer, acting as a client, wishes to retrieve this file from any server. The client does not care which server it retrieves the file from, since the file will be the same no matter which server handles the request. Thus when the client connects with the server, it wishes to merely “ask for the file” without the need to care about the server's file system. To paraphrase in English, the client request may be “Excuse me server, could you please give me file X?” as distinct from “Excuse me server, could you please give me file X which you have located in quadrant Y of partition Z on drive Q?”
When considering the second request above, it should be clear that the client would not know that this particular server uses the term “quadrant” while a different server may use the term “directory” while the third server may use the term “fandangle”. Furthermore, even if the client could be made to be completely sensitive to the server's file system and know the proper form for requesting a file (e.g., the client speaks in the vocabulary of the server), the client would not know where the file actually was located. In other words, the client request may be “Excuse me server number 2, I speak your language, so could you please refer to drive C, directory Alpha, delimiter ‘\’, sub-directory Beta, and send me a copy of file X?” In response, the server may return the file to the client. However, to personify the server with human emotion, the server may respond: “Hello Client, yes here is file X, but how did you know where I had it located?”
In view of the above, it may be understood that a program trying to access a file in the prior art needs to know both the name of the file and where the file actually resides internally on the other computer. Gaining and maintaining such knowledge is problematic.