Electrical computers and digital processing systems: multicomput – Remote data accessing
Reexamination Certificate
2000-01-07
2004-04-06
Dharia, Rupal (Department: 2141)
Electrical computers and digital processing systems: multicomput
Remote data accessing
C709S219000, C709S249000, C711S147000, C711S151000
Reexamination Certificate
active
06718372
ABSTRACT:
FIELD OF THE INVENTION
The present invention generally relates to data storage and data access systems, and more particularly, to systems and techniques which provide access to shared data for applications that perform on computer systems.
BACKGROUND OF THE INVENTION
The ability of modem computer and data processing systems to share data has largely contributed to the popularity and rapid expansion of computer networking industries such as the Internet. In response to this insatiable demand, computer system and software developers have created various prior art data sharing mechanisms to allow one or more computer systems to obtain access to data created, stored, or maintained by another computer system. Generally, computer systems that share data do so over a network using a standardized client/server protocol for data exchange. Many such client/server protocols exist, examples of which include database access protocols, file sharing protocols, and world wide web (WWW) based protocols. Other data sharing systems have been developed to allow two computer systems to share data from a commonly shared storage device having a direct connection to each computer.
FIG. 1
illustrates an example of a commonly used prior art client/server data sharing mechanism called the “Network File System (NFS).” Sun Microsystems, Inc. of Mountain View, California developed NFS and owns NFS as a trademark. Many commercial operating systems incorporate NFS and its widespread use has allowed NFS to become an industry standard for sharing data between networked computer systems. In the illustrated example, a mainframe computer
102
operates using the MVS operating system
105
to allow software applications (e.g., a database program, not specifically shown) that execute on the mainframe
102
to create and store data in records and MVS data sets (not shown) within the storage device
110
according to an MVS specific format. An NFS Server
109
, provided as part of the MVS operating system
105
, “understands” how to properly access the MVS data stored in the MVS data sets within the storage device
110
. In other words, the NFS server
109
is customized for MVS and can read MVS data sets. The NFS Server
109
can “export” MVS data maintained within the storage device
110
onto the network
113
(e.g., a TCP/IP network) for access by other remote computer systems such as the Unix workstation
101
. The NFS server
109
only allows file local systems to be exported in this manner. In other words, the same computing system (i.e., mainframe
102
in this example) that maintains and manages file systems and data in the storage device
110
must execute the NFS server
109
which can export those file systems.
A systems manager (a person, not shown) responsible for managing workstation
101
can configure the NFS client
108
, provided as part of the Unix operating system
104
to “mount” the MVS file system that is “exported” by the NFS server
109
. Once the NFS client
108
has “mounted” the “exported” file system over the network
113
, the application
106
that executes on workstation
101
can have access to (e.g., can read and write) data on the storage device
110
via the NFS client
108
. Generally, the NFS client
108
provides such data access to the application
106
over the network
113
in real time, just as if the storage device
110
containing the data were coupled locally (e.g., via a direct disk drive connection such as a SCSI cable) to the workstation
101
. By way of example, when the application
106
makes operating system calls to access data on the storage device
110
(e.g., uses a function such as fopen( ) to open data), the operating system passes such calls to the NFS client
108
which relays the calls to the NFS server
109
using a standard set of NFS protocol messages. The NFS server
109
receives the NFS protocol messages, and, using its knowledge of the MVS data and storage formats, carries out the requested commands (e.g., read and/or write) on data within MVS data sets maintained in the storage device
110
.
Developers of NFS (e.g.,
109
) often customized an NFS server to the operating system in which it resides (MVS in this example). This allows the NFS server to “serve” data created or maintained by that operating system to one or more NFS clients (e.g.,
108
) over the network
113
. Likewise, developers custom design NFS clients (e.g.,
108
) for the operating system (e.g.
104
) in which they will execute to allow applications (e.g.,
106
) that execute on that operating system to access data over the network
113
without regard for the type of host platform (e.g., MVS mainframe
102
) that is serving the data.
The most commercially available version of NFS (NFS Version 3) has been widely adopted for remote data access and incorporates about fifteen standardized NFS protocol messages or commands, which collectively comprise the NFS protocol. The NFS clients and NFS server can exchange these messages. Examples of NFS messages exchanged between the NFS client and NFS server are READ, WRITE, MKDIR, RMDIR, RENAME, LINK, MKNOD, and so forth. Those skilled in the art will recognize that these NFS message closely parallel file system commands used to manipulate directories (e.g., mkdir( ), rmdir( )), files (e.g., read( ), write( )), and data structures (e.g., link( )) associated with file systems.
NFS protocol messages and commands generally allow an NFS client operating on most types of host computer platforms or operating systems (e.g., Unix, Windows, and so forth) to access an NFS server that serves data from most any other type of host platform or operating system. Incompatibilities of operating system calls and data and/or file storage formats between the client (e.g. Unix workstation
101
) and server (e.g., Mainframe
102
) are largely hidden from the application
106
. For example, if application
106
uses a Unix command to list files (e.g., an “ls” command) contained within a file system provided by the NFS client
108
(i.e., served from NFS server
109
), the NFS client
108
may send a standard NFS protocol massage called “READDIR” to the NFS server
109
. The NFS server
109
receives the READIR NFS protocol message and can use a corresponding MVS command to obtain, for instance, MVS catalog information containing the names of data sets stored on the storage device
110
. The NFS server (e.g.,
109
) can also use the NFS protocol to return data from the storage device
110
(e.g., data from an MVS data set) over the network
113
back to the NFS client (e.g.,
108
) to satisfy the access requests.
FIG. 2
illustrates another prior art technique for obtaining access to data stored on a remote computer system. The technique illustrated in
FIG. 2
uses a standardized protocol called the file transfer protocol (FTP) to provide a connection
113
between an FTP server
121
and an FTP client
120
to transfer an entire file, for example, from the mainframe
102
to the workstation
101
. Generally, whereas NFS (
FIG. 1
) requires a systems manager to mount and export an NFS file system to the workstation
101
, in
FIG. 2
, a user application
106
can invoke the FTP client
120
directly using an FTP command to cause the FTP client
120
to request the entire contents of one or more files from the FTP server
121
. In response to such an FTP command, the FTP client
120
provides standard FTP protocol messages over network
113
to the FTP server
121
. In response to such messages, the FTP server
121
finds and then transfers the entire contents of the requested file(s) obtained from the storage device
110
back to the FTP client
120
on the workstation
101
via the network
113
. The FTP client
121
receives the data during the transfer and stores the data into a file created within the local storage device
125
(e.g., local hard disk) on the workstation
101
. Once the transfer is complete, the FTP session (i.e., the FTP protocol communications between the FTP client and FTP server) is over and the application
106
can access the copy of the
Chapin & Huang LLC
Chapin, Esq. Barry W.
Dharia Rupal
EMC Corporation
Pollack Melvin H.
LandOfFree
Methods and apparatus for providing access by a first... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods and apparatus for providing access by a first..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods and apparatus for providing access by a first... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3245330