System and method for redirection of host data access to multiple non-host file systems or data stores

Abstract

The present invention discloses a system and method for automatic redirection of record-based data access to host files to multiple non-host file systems having non-record-based access comprising a redirector engine, a redirector server and at least one handler. The redirector engine, located on the host side, gets automatic control for each request of a host application (e.g., a read/write request), interprets a property list containing information on whether and how redirection for that request should be processed, makes a redirect decision based on information received from the property list, and establishes a communication with its assigned redirector server. The redirector server, located on a non-host system, handles communication with the redirector engine and the handler, performs data conversions if required and passes control to the handler assigned in the property list. The handler component converts the initial request into a request specific to the non-host file system, controls the execution of the request, and returns the result to the redirector engine. A main advantage of the present invention is that heterogeneous systems using different file systems can work on the same data store without any modification of the host applications themselves. A synchronization of data between the host system and non-host systems can be selected very easily by setting the appropriate parameter in the property list. The data can be stored in different file systems or data stores simultaneously. Finally, the host program is able to access data in different file system, in different encoding formats at the same time in real time.

Description

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates to a system and method for accessing data stored on non-host systems with multiple non-host file systems and, in particular, to a system and method for accessing non-host data via host application programs using record-based access methods.

[0003] 2. Description of the Related Art

[0004] Application programs in the host environment frequently use record-based access methods. For example, the IBM VSE/ESA host operating system uses the record-based access method Virtual Storage Access Method (VSAM) to access data. VSAM does not provide information relating to the internal structure of the data; the application itself must provide this information. Furthermore, host data is stored in EBCDIC (Extended Binary-Coded Decimal Interchange Code) format. EBCDIC is a binary code for alphabetic and numeric characters that IBM has developed for its larger operating systems. In each EBCDIC file, each alphabetic or numeric character is represented by an 8-bit binary number. In contrast to the VSAM data access method, data access methods for non-host file systems use a table row providing information about the structure of the data to be accessed. The application itself does not provide any information relating to the structure of the data to be accessed. Furthermore, data of non-host systems is stored in ASCII format. ASCII is the most common format for text files in computers on the Internet. In an ASCII file, each alphabetic, numeric, or special character is represented by a 7-binary digit number. Therefore, the VSAM access method is not compatible with any access method for non-host systems.

[0005] Host systems use a great number of applications, which have been developed over a long period of time. New technologies like Internet technologies or e-business applications are mainly based on UNIX platforms using non-record-based access methods. Therefore, the major growth in the future is not located in the host system environment using proprietary record-based access methods like VSAM, but in the UNIX or Linux environment using non-record-based access methods. In order to protect the investments in the host sector, it is desirable that the host applications can work without any change with data stored on the new platforms.

[0006] Furthermore, VSAM data must be transferred from the host environment to the UNIX or Linux environment in a relatively simple way.

SUMMARY OF THE INVENTION

[0007] It is therefore an object of the present invention to provide a system and method of data access by existing host applications to data stored on non-host systems using non-host access methods without changing the host applications themselves.

[0008] It is a further object of the present invention to easily provide data from the host systems to the non-host systems using multiple non-host file systems.

[0009] It is a further object of the present invention to store the data in different remote file systems simultaneously.

[0010] Finally, it is an object of the present invention to provide synchronisation of data between the host and the non-host system.

[0011] These objects are achieved by the features of the independent claims. Further preferred embodiments of the present inventions are laid down in the dependent claims.

[0012] The present invention contemplates a system and method for automatic redirection of record-based data access to host files to multiple non-host file systems having non-record-based access comprising a redirector engine, a redirector server and at least one handler. The redirector engine, located on the host side, gets automatic control for each request of a host application (e.g., a read/write request), interprets a property list containing information on whether and how redirection for that request should be processed, makes a redirect decision based on information received from the property list, and establishes a communication with its assigned redirector server. The redirector server, located at a non-host system, handles communication with the redirector engine and the handler, makes data conversion if required and passes control to the handler specified in the property list. The handler component converts the initial request into a request specific to the non-host file system, controls the execution of the request, and returns the result to the redirector engine.

[0013] A main advantage of the present invention is that heterogeneous systems using different file systems can work on the same data store without any modification of the host applications themselves. A synchronization of data between host system and non-host systems can be selected very easily by setting the appropriate parameter in the property list. The data can be stored in different file systems or data stores simultaneously. Finally, a host program is able to access data in different file system, in different encoding formats, at the same time in real time.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Embodiments of the present invention will now be described, by a way of example, with reference to the accompanying drawings, in which:

[0015] FIG. 1 shows a preferred embodiment of the inventive redirector.

[0016] FIG. 2 shows the structure and the content of a parameter list as used by the present invention.

[0017] FIG. 3 shows the method steps of an open request according to the present invention.

[0018] FIG. 4 shows the method steps of a read/write request according to the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

[0019] FIG. 1 shows a preferred embodiment of the present invention implemented partly on a host system or mainframe 2 (e.g., an IBM eServer with an IBM VSE/ESA operating system) and partly on a non-host system 6 (e.g., a system with any UNIX-like operating system). The host system 2 includes host applications 12 using VSAM 10 for accessing VSAM data 8. The VSAM data 8 is stored in EBCDIC-encoded format. The non-host system 6 uses a non-record-based access method (e.g., a relational access method) that is not compatible with the access methods of the host system 2. Furthermore, the data of the non-host system 6 is stored in ASCII-encoded format. The inventive redirector consists of the following three components: a redirector engine 18, a redirector server 20, and a handler 22. Redirector engine 18 is installed on the host system side 2, and redirector server 20 and handler 22 are installed on the non-host system side 6.

[0020] The redirector engine 18 has the following functionalities:

[0021] 1. It gets control for each VSAM request initiated by a host application program 12. (Redirector engine 18 uses an exit in the host data access method 10 to intercept all requests.)

[0022] 2. It interprets a property list (FIG. 2) using information from the VSAM request.

[0023] 3. It makes the decision to redirect the request to a non-host file system by using information in the property list.

[0024] 4. It handles communication with the redirector server 20 located on the non-host system 6 and the non-record-based access method.

[0025] 5. Optionally it can be selected that the redirected request is executed on the non-host system 6 only or in synchronization on the host system 2 as well (see description to FIG. 2).

[0026] The redirector server 20 has the following functionalities:

[0027] 1. It handles communication between redirector engine 18 and handler 22.

[0028] 2. It performs automatic data conversion from the encoded data format of the host system 2 to the encoded data format of the non-host system 6.

[0029] 3. It automatically passes control to the appropriate handler 22 via a handler interface 23.

[0030] 4. Optionally there is provided a common handler interface 23 for all handlers 22, so that new handlers can be implemented easily.

[0031] The handler 22 has the following functionalities:

[0032] 1. It automatically converts an initial request into a request specific to a non-host file system 24 (may be one or more requests depending on the non-host file system).

[0033] 2. It transforms the data corresponding to the request built.

[0034] 3. It controls execution of the request built.

[0035] 4. It returns the result via the redirector server 20 and the redirector engine 18 to the host application 12.

[0036] In the embodiment shown, the communication between redirector engine 18 and redirector server 20 is established by using the TCP/IP (Transmission Control Protocol/Internet Protocol) protocol.

[0037] The redirector 18, 20, 22 handles requests for VSAM data 8 and redirects them to any non-host data store/file system 24 supported by the handler 22 identified in the property list to be described below. Using the redirector 18, 20, 22, existing host applications 12 on IBM VSE/ESA written in any programming language and running in a batch or online environment (e.g., CICS) can be used without any modification.

[0038] FIG. 2 shows the structure and content of a property file 1 used by the present invention. The property file 1 contains the parameters for redirecting the requests to a non-host system 6. The parameters of the property file 1 can be changed or extended by an administrator at any time.

[0039] A preferred embodiment of the property file 1 is the list shown in FIG. 2, which contains following parameters:

[0040] Catalogue 2 and filename 4: specify for which host catalogue and filename a redirection should be applied; if the host file is not identified in the property list a redirection cannot take place.

[0041] Exit 6: specifies the host program that will be invoked for the file.

[0042] Owner 8 (either VSAM or REDIR): specifies whether the redirection should be used as a synchronization tool; VSAM in the property list means to work with the original VSAM data and to work synchronously with the data store on the non-host system. This allows one to have the same data on the host as well as on the non-host system, however in another data format. REDIR in the property list is used when no synchronization is required and all data is used from the non-host system. The real-time access to data from the non-host system is transparent to the host application.

[0043] IP (Internet Protocol) address 10 and Port 12: specify the network address of the non-host system and the port to be used.

[0044] Handler 14: specifies the handler to be invoked by the redirector server.

[0045] Options 16: specifies access or manipulation options for data.

[0046] The above-explained property list 1 is only a preferred embodiment. The property list 1 may be extended by further parameters.

[0047] FIG. 3 shows the method steps of an open request according to the present invention.

[0048] The host application 12 initiates an open request via an ACB (access control block) containing a filename and a catalogue name (step 40). With both items of information a control block structure is built in the memory of the host for further requests (step 80). The control block structure contains information about the organization and accessing of the file to be accessed. For each open request such a control block structure is built.

[0049] After the successful opening of a file, VSAM 10 activates the redirector engine 18 without informing the application 12. Using the information contained in the open request, the redirector engine 18 reads the property list 1 and checks for an entry with the same catalogue and filename parameters to determine whether a redirection should take place at all; a redirection only takes place when the filename and catalogue name of the open request are contained in an entry of the property list 1 (step 100).

[0050] The owner parameter is not checked for an open request, only for a read/write request (FIG. 4) as described below. However, the IP address, port and handler name are used for each redirection of an VSAM open request. More particularly, the redirector engine 18 opens a session with the redirector server 20 using the IP address and port address contained in the property list 1 and sends a data package with a parameter list containing the type of request (open in this case), filename, catalogue name, and name of the handler 22; the data package is sent to the redirector server using TCP/IP protocol (step 120).

[0051] The redirector server 20 performs data conversion of the package if required and invokes the handler 22 specified in the parameter list (step 140). Upon being invoked, the handler 22 executes a file system-specific request (e.g., DB2 SQL connect . . . ) corresponding to the VSAM open request using the information contained in the parameter list (step 160). After a successful open, a return message is sent from the handler 22 via the redirector server 20 to the redirector engine 18, giving back control to the host program 12 (step 180).

[0052] FIG. 4 shows the method steps for a read/write request according to the present invention. The host application 12 generates a write request containing data to be modified (step 45). The redirector engine 18 then gets control and creates a parameter list including the type of request (here a write request), data to be modified, filename, catalogue name, and handler name by using the parameters from the property file 1. A data package containing the parameter list is directly sent via the redirector server 20 to the handler 22 specified in the property list (steps 65, 85). Communication parameters like IP address and IP port are not needed since the communication is still open from the open request. Preferably, at first the handler 22 prepares the data received in a more usable structure independent of the addressed non-host file system requirements. This operation is done in memory (e.g., memory of the file system or cache). Dependent on the respective file system, one or more requests are created and executed as a unit or single transaction (step 105). The assigned handler 22 transforms the request into the corresponding file-specific request (e.g., SELECT (read) or INSERT (write) and executes it. It is also possible to use more handlers 22 to read/write the data to another file system.

[0053] Upon the completion of execution on the non-host system 6, control is given back to the redirector engine 18, and further execution on the host system 2 depends on the owner specified in the property list 1 (step 125). If the owner specified in the property list 1 is REDIR (step 165), control is given back to the host application 12 without accessing VSAM 10 (step 185). On the other hand, if the owner specified in the property list 1 is VSAM (step 166), normal VSAM processing of the request is continued and the write request is also performed on the VSAM data 8, thereby securing a synchronization between the VSAM data 8 and the non-VSAM data 24 (step 186). Control is then given back to the application program 12 (step 187).

[0054] The owner parameter therefore has an important function of allowing use of the redirector engine 18 either as a synchronization mechanism between different file systems or as a simple redirection to other common data stores. With the large number of host applications in various programming languages running on a host system (e.g. IBM VSE/ESA), it is very important to let them run unchanged with data stored on different platforms (e.g., relational databases, flat files) in real time.

[0055] In the case of read requests, the original host data structure is rebuilt before the data is returned to the host application 12. The handler 22 is responsible for this step. In the next step the data conversion from ASCII to EBCDIC takes place by redirector server 20 and then the data is sent via the redirector engine 18 to host application 12.

[0056] The invention also allows one to migrate host data to another non-host file system 24 by using the redirector as follows. The property list 1 is prepared in such a way that the owner parameter is VSAM. The options parameter in the property list 1 is set to “migrate”. That means that any host application 12 that entirely reads the host file will cause a migration of this data via the specified handler 22. The host application 12 initiates a read request to the host data. The redirector 18 engine is automatically invoked and takes control of the read process. The owner parameter in the property list 1 is in this case VSAM, which means that the read is done by VSAM 10. After the read process is done and host data is in memory, the redirector engine 18 interprets the option parameter, which is migrate. In this case the parameter list created includes the type of request, which is set to write data. The parameter list is sent to the handler 22 via the redirector server 20.

[0057] The main advantages of the present invention may be summarized as follows. Unchanged host applications can access via their traditional access methods (record-based access) data residing in different platforms using non-record-based access methods. The redirection decision is made for each individual request. A synchronization of data between host system and non-host systems can be selected very easily by setting the appropriate parameter in the property list. The data can be stored in different file systems or data stores simultaneously. Finally, the host program is able to access data in different file system, in different encoding formats at the same time in real time.

Claims

1. A system for automatic redirection of a record-based data access via a request for host data stored on a host system to a non-record-based data access to data stored on a non-host system, said host system having a host application which generates requests for said host data, comprising: a redirector engine associated with the host system which receives an initial request for host data from said host application; a handler associated with the non-host system which converts a request for host data into a request specific to the non-record-based data access; and a redirector server associated with the non-host system which intermediates between said redirector engine and said handler to pass said request for host data to said handler and to return a result of said non-record-based data access to said host application:

2. The system of claim 1 in which said redirector server returns said result to said host application via said redirector engine.

3. The system of claim 1 in which said host system has a record-based access component for accessing said host data and said non-host system has a non-record-based access component for accessing said data stored on said non-host system.

4. The system of claim 1 in which said redirector server performs data conversion if required.

5. The system of claim 1 in which said redirector engine interprets a property list containing information on whether and how redirection for the initial request should be processed and makes a redirect decision based on information received from the property list.

6. The system of claim 5 in which said redirector server passes control to a handler specified by the property list.

7. The system of claim 5 in which said property list contains parameters for catalogue name, filename, owner, IP address, port, and handler.

8. The system of claim 1 in which the initial request is of a given type, said redirector engine sending a data package to said redirector server containing information about said request type.

9. The system of claim 8 in which said request type is an open request, a read request, or a write request.

10. The system of claim 1 in which said redirector engine sends a data package to said redirector server containing one or more parameters identifying data to be accessed.

11. The system of claim 10 in which said parameters include catalogue name and filename.

12. The system of claim 1 in which said redirector engine sends a data package to said redirector server specifying a handler.

13. The system of claim 1 in which said handler is located on the non-host system .

14. A non-host system using a non-record-based access component for accessing data stored on said non-host system, said non-host system having communication with a host system using a system for automatic redirection of a record-based data access via a request for host data stored on said host system to a non-record-based data access to said data stored on said non-host system, said non-host system comprising: a handler which processes a request for host data as a non-record-based data access to data stored on said non-host system; and a redirector server which intermediates between said host system and said handler to pass a request for host data from said host system to said handler and to return a result of said non-record-based data access to said host system.

15. The system of claim 14 in which said redirector server passes said request for host data to one of a plurality of handlers on said non-host system as specified for said request by said host system.

16. The system of claim 14 in which said handler converts a request for host data into a request specific to the non-record-based data access.

17. A system for automatic redirection of a record-based data access via a request for host data stored on a host system to a non-record-based data access to data stored on a non-host system, said host system having a host application which generates requests for host data and a record-based access component for accessing said host data, comprising: a redirector engine associated with the host system which intercepts a request for host data from said host application to said record-based access component and redirects said request to said non-host system for processing as a non-record-based data access to data stored on said non-host system.

18. The system of claim 17 in which said redirector engine accesses an entry in a property list corresponding to the host data being requested to determine whether to redirect said request to said non-host system.

19. The system of claim 17 in which said redirector accesses an entry in a property list corresponding to the host data being requested to determine which of a plurality of host systems to redirect said request to.

20. The system of claim 17 in which said redirector engine receives a result of said non-record-based data access from said non-host system and returns said result to said host application.

21. A method for processing a request for record-based data originating from a host system on a non-host system using a non-record-based access component for accessing non-record-based data stored on said non-host system, said method comprising the steps of: receiving a request for record-based data from said host system; processing said request for record-based data as a non-record-based data access to said non-record-based data stored on said non-host system; and returning a result of said non-record-based data access to said host application.

22. The method of claim 21 in which said processing step comprises the step of converting said request for record-based data into a request specific to the non-record-based data access.

23. A computer program product stored on a computer-readable medium, containing software code which executes the method of claim 21 if the code is run on a computer.

24. A method for automatic redirection of a record-based data access via a request for host data stored on a host system to a non-record-based data access to data stored on a non-host system, said host system having a host application which generates requests for host data and a record-based access component for accessing said host data, comprising the steps of: intercepting a request for host data from said host application to said record-based access component; and redirecting said request to said non-host system for processing as a non-record-based data access to data stored on said non-host system.

25. The method of claim 24, further comprising the step of: accessing an entry in a property list corresponding to the host data being requested to determine whether to redirect said request to said non-host system.

26. The method of claim 24, further comprising the step of: accessing an entry in a property list corresponding to the host data being requested to determine which of a plurality of host systems to redirect said request to.

27. The method of claim 24, further comprising the steps of: receiving a result of said non-record-based data access from said non-host system; and returning said result to said host application.

28. The method of claim 24 in which said steps are performed on said host system, said method further comprising the following steps performed on said non-host system: receiving said request for host data from said host system; processing said request for host data as a non-record-based data access to data stored on said non-host system; and returning a result of said non-record-based data access to said host system.

29. The method of claim 28, further comprising the following steps performed on said host system: receiving said result of said non-record-based data access from said non-host system; and returning said result to said host application.

30. A computer program product stored on a computer-readable medium, containing software code which executes the method of claim 24 if the code is run on a computer.