US20070124302A1

US20070124302A1 - Mapping a Source File From a Source System To a Target System

Info

Publication number: US20070124302A1
Application number: US11/668,212
Authority: US
Inventors: David Korn; Glenn Fowler
Original assignee: AT&T Corp
Current assignee: BAMPTON TECHNOLOGIES LLC
Priority date: 2005-04-27
Filing date: 2007-01-29
Publication date: 2007-05-31
Also published as: EP1717719A1; CA2544899A1; US7958133B2; US20060248521A1

Abstract

A method includes defining a file attribute indicator based on an attribute associated with a source file and based on a mapping policy. The source file has a source filename and the source file is migrated to a target system from a source system. The target filename is based on the source filename and the file attribute indicator. The target filename is used by a target application of the target system to process the source file. The target application is the source application configured for use on the target system.

Description

RELATED APPLICATION

This application is a continuation-in-part of U.S. patent application Ser. No. 11/311,423 entitled “Application Conversion of Source Data,” filed Dec. 20, 2005, which is incorporated herein by reference in its entirety.

BACKGROUND

Embodiments of the invention relate generally to the migration of data and, more particularly, to a method and apparatus for migrating data from a source system to a target system.
One problem encountered when migrating a source application from a source platform to a target platform is the compatibility of the source application with the target platform. Often, the source application is ported to the target system with minimal modifications because modifying portions of the source application for complete compatibility with the target system can be complicated and/or prohibitively expensive. Incompatibilities, such as differences in operating systems/functions, file storage directory structures, and so forth can cause the source application of the source platform to fail in processing source data on the target platform. For example, a source application that has been migrated to a target platform may fail at the time of execution on the target platform because an operating system of the target platform may not be configured with the same functionality as a source operating system of a source platform. Thus there is a need for a method and apparatus that can be used to mitigate problems associated with migration of a source application to a target platform.

SUMMARY OF THE INVENTION

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is described with reference to the accompanying drawings. In the drawings, identical or like reference numbers indicate identical or functionally similar elements.
FIG. 1 is a schematic diagram of an embodiment of the invention.
FIG. 2 is a flowchart illustrating an embodiment of the invention.
FIG. 3 is a figure illustrating the processing of source data on a target system according to the flowchart in FIG. 2.
FIG. 4 is a flowchart illustrating an embodiment of the invention.
FIG. 5 is a flowchart illustrating an embodiment of the invention
FIG. 6 is a schematic diagram that illustrates a copy module that is configured to define a target filename associated with a source file/data that is migrated from a source system to a target system, according to an embodiment of the invention.
FIG. 7 is a table that illustrates an example of indicators of file attributes included in UNIX filenames based on a mapping policy and based on MVS filenames, according to an embodiment of the invention.
FIG. 8 is a flowchart that illustrates processing related to a source file migrated from a source system to a target system, according to an embodiment of the invention.
FIG. 9 is a flowchart that illustrates processing related to a source file when the source file is requested at a target system, according to an embodiment of the invention.
FIG. 10 is a flowchart that illustrates a method related to source file compression, according to an embodiment of the invention.

DETAILED DESCRIPTION

The diagram in FIG. 1 illustrates a personal computer application 160 receiving, processing, and manipulating mainframe data 130 from a mainframe computer 100. Manipulating includes functions such as reading data, performing mathematical operations, writing data, and executing programs. The mainframe data 130 contains character data portions and numeric data portions that are encoded, based on data type, in a mainframe encoding for use by the mainframe application 110. The personal computer application 160 is a version of the mainframe application 110 configured for use on a personal computer 150. Although the applications 110 and 160 are the same application, since the mainframe data 130 is encoded in a mainframe encoding, the mainframe data 130 cannot be directly manipulated by the personal computer application 160 using compiler libraries that are configured to manipulate data that is encoded for the personal computer application 160.
The file format information, however, used by the personal computer application 160 is the same as the file format information used by the mainframe application 110 to process the mainframe data 130. Even if the mainframe data 130 contains records with variable lengths and different mixtures of data types such as numeric data and character data that are not in fixed positions, the file format information specifies the locations of records and contains field layout information that describe the lengths and locations of data types within each record. Simply put, the file format information specifies the portions of the mainframe data 130 that are character data and the portions of the mainframe data 130 that are numeric data. The personal computer application 160 can use the common file format information to parse the character and numeric portions of the mainframe data 130. Before manipulating the mainframe data 130, the personal computer application 160 parses the mainframe data 130 using the file format information and converts the parsed data using a modified compiler library 170 that is modified to convert the mainframe data 130 into an encoding that can be manipulated by the personal computer application 160. The personal computer application 160 itself is not modified, but the compiler libraries called by the personal computer application 160 are modified. The compiler and application could be coded in any programming language, such as COBOL and C++, used for manipulating a variety of datasets in encodings such as EBCDIC, ASCII, binary, and packed decimal.
Assume, for example, that the portion of the mainframe data 130 that is a character data type is encoded in an EBCDIC encoding and that the personal computer application 160 manipulates character data that is encoded in an ASCII encoding. Also, assume that the personal computer application 160 can manipulate binary data and that the numeric data in the mainframe data 130 is encoded in a binary encoding. When the personal computer application 160 uses the numeric data, which is encoded in a binary encoding, the personal computer application 160 can manipulate the data normally. However, when using the portions of the mainframe data 130 that are character data, the compiler library used by the personal computer application 160 for manipulating character data can be modified so that the character data, when retrieved using file format information, can be converted from the EBCDIC characters into ASCII characters. The personal computer application 160 is not modified, only the selected compiler library used by the personal computer application 160 for manipulating character data is modified to convert the mainframe data 130 into an encoding usable by the personal computer application 160.
In alternative embodiments, data can be converted from any type of source system using source data encoded in a source encoding to any type of target system using a target application to convert the source data into a target encoding that calls modified target libraries. For example, the source system and target system can both be mainframe computers that are configured to read data encoded in different encodings.
Also, rather than modifying the compiler libraries used by the target system, the compiler libraries on the source system can be modified so that the source application produces data that can be read by an application migrated to the target system. In some embodiments, both the libraries on the source and target system can be modified.
In separate embodiments, the location of the source data can be on the source system or can be transmitted to the target system for use. Also, the data types used by the source and target systems are not necessarily confined to character and numeric data types. For example, the source data accessed by a target system can contain other data types such as symbolic data as well as character and numeric data.
Using the approach of modifying compiler libraries to convert data rather than modifying system applications, a multiplicity of migrated system applications using unique file format information can convert/process and then manipulate source data from a source system. The structure or variability that can occur in file format information will not be a factor in data conversion. For example, assume that several applications written in COBOL are migrated from a mainframe computer using mainframe data to a personal computer that will manipulate the mainframe data. Also assume that the mainframe computer manipulates data in an EBCDIC encoding and that the personal computer normally manipulates data encoded in an ASCII encoding. If the COBOL compiler libraries on the personal computer are modified for use by one of the applications, the other COBOL applications that have been migrated to the personal computer can call and use the same modified COBOL compiler libraries. Therefore, each of the several applications will be able to manipulate mainframe data by leveraging their own unique file format information to parse mainframe data and by using the common set of modified COBOL compiler libraries. Each of the applications migrated to the personal computer will not have to be specifically modified to manipulate the EBCDIC encoded mainframe data.
FIG. 2 is a flowchart that illustrates an embodiment of the process of converting/processing source data encoded in a source encoding for use by a target application that manipulates data in a target encoding. The target application calls modified libraries within a modified compiler to convert data so that the target application can manipulate the source data. The flowchart illustrates that the source data in a source encoding is retrieved by a target application 200. The source data retrieved can be a sub-set of source data from a source dataset or an entire source dataset. The source data can contain any combination of character and/or numeric data in a format that can be interpreted by a target application using file format information. The character data in the source data is encoded in a source character encoding and the numeric data in the source data is encoded in a source numeric encoding.
After the source data has been retrieved, the characters and numbers are converted by a modified compiler into a target character encoding 210. The conversion can be performed by a library within the compiler that has been modified to perform the conversion. For example, the library used by the target application to access data can be modified to perform the conversion when accessing the source data. The character data from the source data that was in the source character encoding is converted into the target character encoding that can be directly manipulated by the target application. The numeric data, however, is converted into a target character encoding that cannot be manipulated by the target application. The numeric data in a target character encoding is an intermediate encoding that cannot be manipulated directly by a source application or directly by the target application without further processing.
When character data is selected from the source data for manipulation by the target application using file format information 220, the character data in the target character encoding is manipulated by the target application 230. The manipulation can include operations such as reading and writing character data. In this embodiment, further conversion of the character data into a different encoding is not required for the target application to manipulate data because the character data is encoded in the target character encoding.
When numeric data is selected from the source data for manipulation by the target application 240 using file format information, the numeric data is converted by the modified compiler to the target numeric encoding 250. For example, the read compiler library used by the target application to read binary data can be modified so that the numeric data, when read, is converted from the source numeric data in the target character encoding into the target numeric encoding. In separate embodiments, any compiler library or combination of compiler libraries from the compiler can be modified to convert the source numeric data in the target character encoding into the target numeric encoding. The compiler libraries that are modified to perform the conversion of the encoded data can be optimized such that the overhead for conversion is minimized and processing time is virtually transparent to a user.
After the data is in an encoding that can be manipulated by the target application, the numeric data is manipulated by the target application 260. The manipulation can include operations such as simply reading the data or the execution of a combination of mathematical operations.
The numeric data is converted from the target numeric encoding into the target character encoding 270 after the data has been manipulated by the target application. The conversion can be performed by any library from the compiler that has been modified to perform the conversion. For example, the write compiler library used by the target application to write binary data can be modified so that the numeric data, when written, is converted from the target numeric encoding into the target character encoding.
The source data in the target character encoding is then converted to the source encoding by the modified compiler 280. This final conversion returns the source data to its original encoding in the source encoding. The conversion can be performed by a library within the compiler that has been modified to perform the conversion. For example, a library used by the target application to write data can be modified to perform the conversion when writing the source data.
In separate embodiments, the conversion of characters and numbers into different encodings does not necessarily have to be performed by modified compiler libraries that make up a modified compiler, the conversion can be performed by any combination of software, functions, and/or hardware that is somehow invoked by the target application.
In alternative embodiments, the source data can be converted from a source encoding that encodes characters and numbers in separate encodings into an intermediate encoding that is a target numeric encoding rather than a target character encoding. In this scenario, the numeric data can be manipulated without additional conversion, but the character data in the target numeric encoding would have to be converted into a target character encoding before the character data can be manipulated.
In yet other embodiments, the intermediate encoding can be an encoding that is unrelated to a target character encoding or target numeric encoding. Both the character data and the numeric data would have to be converted from the intermediate encoding into an encoding that can be manipulated by the target application.
FIG. 3 illustrates an embodiment implementing the flow illustrated in FIG. 2. The source data encoded in an EBCDIC encoding is being converted for use by a target application that normally manipulates data in an ASCII encoding. The source data 300 contains both character portions that are encoded in EBCDIC encoding and numeric data that is encoded in a binary encoding. The source data 300 can be a sub-set of source data from a source dataset or an entire source dataset. Each 8-bit byte from the source data, including the binary data in the binary encoding, is converted to ASCII 310. The result is source data in an ASCII encoding 320 where both the character and numeric portions of the source data have been read as EBCDIC characters and converted to an ASCII encoding. The numeric portion of the data is in a mangled intermediate encoding.
When numeric data is retrieved for manipulation using file format information, the numeric data in ASCII encoding is converted to a binary encoding for manipulation 330. This involves the use of a compiler library that can translate binary data which was read as EBCDIC character data and converted to an ASCII encoding back into binary data. After the translation is completed, the portion of numeric source data in a binary encoding 340 can now be manipulated. In this embodiment, the numeric data is only read and is not modified. After the manipulation of the data is completed, the source data in the binary encoding 340 is converted to the ASCII character encoding 350.
The source data in the ASCII encoding 360 is converted to the original EBCDIC encoding 370 by converting each 8-bit byte from the ASCII character encoding, including the intermediate encoding of the binary portion of the data, to the EBCDIC character encoding. The result is the source data encoded in the EBCDIC encoding 380 that includes both a binary encoding for numeric portions of data and the EBCDIC character encoding for the character portions of data.
Although the embodiment described above involves the conversion of 8-bit bytes, the method can be applied to binary streams where characters and numbers are represented by any bit length or even variable bit lengths.
FIG. 4 is a flowchart that illustrates an embodiment of the process of converting source data encoded in a source encoding for use by a target application that manipulates data in a target encoding. The target application calls modified libraries within a modified compiler to convert data so that the target application can manipulate the source data. In this embodiment, the source data is already converted to the target character encoding (intermediate encoding) before being retrieved by the target application 400. The flowchart illustrates that the source data encoded in the target character encoding is retrieved by a target application 400.
When character data, using file format information, is selected from the source data for manipulation by the target application 420, the character data in the target character encoding is manipulated by the target application 430. The flowchart illustrates that after manipulating the source character data encoded in the target character encoding, the source character data is stored/written in the target character encoding 480.
When numeric data is selected from the source data for manipulation by the target application 440 using file format information, the numeric data is converted by the modified compiler to the target numeric encoding 450. After the data is in an encoding that can be manipulated by the target application, the numeric data is manipulated by the target application 460. The numeric data is converted from the target numeric encoding into the target character encoding 470 after the data has been manipulated by the target application. The flowchart illustrates the source numeric data is stored/written in the target character encoding 480.
FIG. 5 is a flowchart that illustrates an embodiment that allows for the manipulation of source data by a target application using a compiler that contains libraries that have been modified. In this embodiment, the source data is already converted to the target character encoding (intermediate encoding) before being retrieved by the target application 500. Character data is retrieved by the target application 520 using file format information, manipulated by the target application 520, and is stored/written by the target application in the target character encoding 530.
However, when numeric data is selected for manipulation by the target application using file format information 540, the numeric data is manipulated using mathematical libraries that have been modified such that the target application can manipulate the numeric data in the target character encoding 550. For example, if the bytes in a numeric portion of source data was originally encoded in a binary encoding and was converted to an intermediate ASCII character encoding, a compiler library can be modified to execute a mathematical operation such as a subtract operation using bytes in the intermediate ASCII character encoding.
After the data has been manipulated, the numeric data is stored/written in the target character encoding 560.
In some embodiments, modification of one or more libraries associated with a source application and/or modification of a filename (e.g., filename syntax) associated with source data can be used to overcome one or more incompatibilities (e.g., differences in operating systems/functions, file storage directory structures, and so forth) that can cause a source application of a source system platform to fail in processing the source data upon migrations to a target system platform. This can occur in situations where the source application is translated into object code that can be executed at the target system without modifying incompatible portions of the source application to be compatible with the target system. For example, a source application that has been migrated to a target system may fail at the time of execution at the target system because an operating system of the target system may not be configured with the same functionality as a source operating system of a source system. As a specific example, a multiple virtual storage (MVS) application configured to receive information associated with an MVS file (e.g., file format information) from an MVS operating system can fail after being migrated to a UNIX system because the UNIX system may not be configured to provide all of the information required by the MVS application. Similarly, the techniques described above can be applied to remedy incompatibilities between, for example, a Windows OS and a UNIX system. In some instances, the source application is ported to the target system with few modifications because modifying portions of the source application for compatibility with the target system can be complicated and/or prohibitively expensive.
In some embodiments, before or after migrating source data (e.g., source file) from a source system to a target system that is based on a different platform (e.g., different operating system), a target filename associated with the source data can be defined to include information that can be used by a modified library at the target system. For example, a target filename can be defined based on information associated with a source file to include data that is critical for processing the source file by a source application that has been migrated onto a target system (i.e., migrated application). The critical data can be, for example, file attribute information such as file formats, data field type information, compression information, etc. that would normally be provided by a source system, but not readily available on a target system. FIGS. 6 through 10 illustrate examples of apparatus and methods related to migration of source data such that a source application of a source system can process the source data at a target system.
FIG. 6 is a schematic diagram that illustrates a copy module 640 that is configured to define a target filename 634 associated with a source file/data 630 that is migrated from a source system 600 to a target system 650, according to an embodiment of the invention. A modified library 690 of the target system 650 is configured to use the indicators of data included in the target filename 634 to facilitate processing of the source file/data 630 by the target application 670.
The source system 600 operates based on a source operating system 620 and the target system 650 operates based on a target operating system 680 (i.e., different operating platform). In this embodiment, the target system 650 includes a target application 670 that corresponds to a source application 610 that has been migrated to the target system 650 from the source system 600 (e.g., modified compiler libraries, translated into different object code for use on the target platform, etc.). The target application 670 can be referred to as a migrated application. The target application 670 is migrated directly from the source system 600 such that the changes necessary for migrating are reduced (e.g., little or no modifications of source code). As a result, the target application 670 is configured to substantially behave on the target system 650 as the source application 610 would behave on the source system 600.
Specifically, the source application 610 is configured to receive file attributes (e.g., file format, field length, field type, compression information, etc.) associated with the source file/data 630 from the source operating system 620 to process the source file/data 630. The source operating system 620 is configured to provide the file attributes to the source application 610 at the time that the source application 610 processes the source file/data 630. Consequently, the target application 670 (as an application that has been migrated from the source system 600) is also configured to rely on the target operating system 680 for file attributes in order to process the source file/data 630 on the target system 650. In this embodiment, the target filename 634 associated with the source file/data 630 is configured to include file attribute indicators that can be extracted (e.g., parsed), interpreted (e.g., translated) and/or provided to/for the target application 670 by the modified library 690.
The copy module 640 is configured to use a mapping policy 645 to convert a source filename 632 associated with the source file/data 630 to the target filename 634 before, after, and/or at the time that the source file/data 630 is migrated to the target system 650. The copy module 640 can be configured to interface with the source operating system 620 and/or use the mapping policy 645 to determine which file attribute indicators to include in the target filename 634 associated with a specific source file/data 630. For example, the copy module 640 can receive file attributes from the source system 600 and use the mapping policy 645 to determine how indicators of the file attributes should be included in the target filename 634. The indicators can be appended/incorporated at any point (e.g., suffix/prefix) within the target filename 634, included as extensions to the target filename 634, encoded into a code that can be decoded, and so forth. An example of file attribute indicators included in a target filename based on a mapping policy is shown in FIG. 7.
Because the target application 670 is migrated from the source system 600 with few modifications, the target application 670, in some embodiments, will often use the source filename 632 to call source files/data 630 at the target system 650. The modified library 690 can include one or more library functions that use the mapping policy to decode the source filename 632 into the corresponding target filename 634 so that the target application can retrieve and/or process the source file/data 630 at the target system 650. This process is described in more detail in connection with FIG. 9.
In some embodiments, a mapping policy (not shown) at the target system 650 can be used to create a new file at the target system 650 using the target application 670. Creation of a new file by the target application 670, for example, can be triggered by a user. The target application 670 can use the mapping policy (e.g., included in the modified library 690) to create the new file such that new file is compatible with the target system 650 rather than compatible with the source system 600. For example, the target application 670 can create a filename for the new file such that the filename has a syntax that is compatible with and useful in the target application 670/target system 650. The filename created for the new file can include indicators of file attributes associated with the new file.
As shown in FIG. 6, the copy module 640 and mapping policy 645 are included in the source system 600 and used to export the source file/data 630 to the target system 650. In some embodiments, the copy module 640 and/or mapping policy 645 can be included in the target system 650. If included in the target system 650, the copy module can be configured to import the source file/data 630.
In some embodiments, the copy module 640 and/or mapping policy 645 can be included in a separate system (not shown) that is associated with the source system 600 and/or the target system 650. In some embodiments, the copy module 640 can be implemented as one or more modules in hardware and/or software. In some embodiments, the mapping policy 645 can be implemented as part of the hardware and/or software of the copy module 640. In some embodiments, the mapping policy 645 can be a separate file, such as a table and/or set of threshold conditions/values, that is accessed by the copy module 640.
In some embodiments, the mapping policy 645 can be defined as a static policy by, for example, a user. In some embodiments, the mapping policy 645 can be dynamically updated. The mapping policy 645 can be a global or semi-global mapping policy associated with other applications (not shown) in addition to the source applications 610. In some embodiments, a separate mapping policy can be associated with each of several source applications and/or target systems.
FIG. 7 is a table 795 that illustrates an example of indicators of file attributes included in UNIX filenames 755 based on a mapping policy and based on MVS filenames 705, according to an embodiment of the invention. The table 795 shown in FIG. 7 is related to a transfer (e.g., sending, copying) of source files from an MVS system to a UNIX system and includes an MVS 780 portion and a UNIX 790 portion. The table 795 illustrates MVS filenames 705 that are each associated with an MVS data/file 700. The MVS system is based on a flat filename structure whereas the UNIX system is based on a hierarchical directory structure.
The MVS file attributes 785 that are included in table 795 are MVS format 710, MVS record length 715, MVS compression 720, and MVS compression type 725. The MVS format 710 indicates the types of fields (e.g., variable, fixed, etc.) that are included in the corresponding MVS data/file 700. For example, MVS data/file C3 has a fixed field MVS format. The MVS record length 715 indicates the length of a record (e.g., maximum number of bytes within a record) within a field of an MVS data/file 700. For example, MVS data/file B2 has an MVS record length of less than or equal to 50 bytes. The MVS compression column 720 indicates whether or not a particular MVS data/file 700 is compressed. For example, MVS data/file A1 is compressed as indicated by the “yes” in the MVS compression column 720. The MVS compression type column 725 indicates the type of compression of an MVS data/file 700 (e.g., zip, gzip, bzip). For example, MVS data/file B2 is compressed in a type 2 compression.
The MVS system (e.g., MVS operating system) is configured to provide one or more of the MVS file attributes 785 to an MVS application before, after, and/or at the time that the MVS data/file 700 is accessed/processed by the MVS application.
The UNIX directory 750 and the indicators in the UNIX filenames 755 are derived based on the MVS filename 705 and based on the MVS file attributes 785 according to a mapping policy. The mapping policy can be used to determine if and how the MVS 780 information associated with an MVS data/file 700 should be migrated to the UNIX system. In this embodiment, the mapping policy is used to create and include indicators of the MVS file attributes 785 in the UNIX filenames 755. The mapping policy can be, for example, a set of computer executable/readable rules in hardware and/or software used to define the UNIX directories 750 and the UNIX filenames 755 based on the MVS 780 information.
In this embodiment, the UNIX filename “C%v200.qz” stored in UNIX directory “A/B” is determined/defined based on the MVS 780 information associated with MVS data/file A1 according to a mapping policy. The “C” portion of the UNIX filename 755 is derived from the last portion (after the final period “.”) of the MVS filename 705. This portion of the UNIX filename (without indicators of file attributes) can be referred to as the root of the filename. The “A/B” UNIX directory 750, which is a hierarchical directory, is derived from the first portion (before the final period “.”) of the flat MVS filename 705.
The “%v” portion of the UNIX filename 755 is used to represent the fact that the MVS data/file A1 contains variable length records. The “200” portion of the UNIX filename 755 directly after the “%v” is used to indicate that the MVS data/file A1 includes records that are at most 200 bytes. The “qz” portion of the UNIX filename 755 is used to indicate that the MVS data/file A1 is compressed. In this embodiment, the compression type 725 is not included in the UNIX filename 755 because the compression type 725 can typically be determined by an application associated with the UNIX system. In some embodiments, the MVS compression type 725 is included in the UNIX filename 755.
FIG. 8 is a flowchart that illustrates processing related to a source file migrated from a source system to a target system, according to an embodiment of the invention. A source filename associated with a source file (also can be referred to as a source data file) is received at 800. The source filename can be received at, for example, a copy module. The copy module can be configured to transfer a source file associated with the source filename to a target system. The source filename can be provided to the source file from a list of source files that are to be transferred to a target system.
A file attribute associated with the source file is received at 810. The file attribute can be received from a source operating system configured to determine the file attribute information using, for example, a function call or a standard application program interface (API) call.
A target filename is defined based on the source filename, the file attribute and/or a mapping policy at 820. The target filename can be defined using a copy module at the source system and/or target system. Indicators (e.g., alphanumeric) of the file attributes can be included in the target filename by the copy module. The mapping policy, in some embodiments, can be a user-defined mapping policy that is integrated into the copy module. In some embodiments, the mapping policy can be used to determine which of several file attributes to include in the target filename.
The source file and corresponding target filename are transferred to a target system at 830. In other words, the source file is stored at the target system using the target filename defined at 820. In some embodiments, the source file can also be stored in a specific directory location that is derived from, for example, the source filename associated with the source file.
In some embodiments, the target filename can be parsed by a target application so that the target application can extract the indicators of file attributes from the target filename. The target application can translate the indicators into file attribute information that can be used by the target application to process the file associated with the target filename. The parsing and/or translation can be accomplished using a mapping policy used to create the target filename. The mapping policy can be included in a compiler library associated with the target application.
FIG. 9 is a flowchart that illustrates processing related to a source file when the source file is requested at a target system, according to an embodiment of the invention. The source file can be requested at the target system by a target application at 900. The target application, in this embodiment, uses the source filename to call the source file because the target application is a version of a source application that has been migrated from a source system and includes function calls and filenames as they were included in the source application.
A modified compiler library is used to determine the target filename at 910. The target filename can be determined based on the source filename and using a mapping policy that was used to create the target filename. For example, the target filename can be determined by applying the mapping policy to the source filename. The target filename can then be used by the target application to retrieve the source file at the target system. In some embodiments, the modified compiler library can be associated with the target application and/or can be associated with an operating system. In some embodiments, only the root of the target filename is determined and the source file is retrieved using only the root of the target filename.
File attribute information associated with the source file is extracted from the target filename using the modified compiler library at 920. The file attribute information can be determined based on a mapping policy that was used to create indicators of file attribute information included in the target filename. In some embodiments, the target application relies on an operating system (e.g., runtime library of a compiler) to retrieve the file attribute information for the target application. The target application and/or operating system can translate the indicators into file attribute information (e.g., based on the mapping policy) such that the file attribute information can be used by the target application to process the file associated with the target filename. The mapping policy can be included in a compiler library associated with the target application and/or operating system.
The file attribute information can then be used by the target application to process the source file at the target system at 930. Using the extracted file attribute information, the target application can be executed at the target system in substantially the same way that it was executed at the source system. The translation of the source filename to the target filename, retrieval of the file attributes from the target filename, etc. can be substantially transparent to the target application.
FIG. 10 is a flowchart that illustrates a method related to source file compression, according to an embodiment of the invention. A source filename associated with a source file is received at 1000 and the source file is compressed based on a mapping policy at 1010. In some embodiments, the source filename can be received at, for example, a copy module. The copy module can be configured to compress or can be configured to trigger the compression of the source file.
A target filename is defined based on the source filename, the compression information and/or a mapping policy at 1020. The target filename can be defined using a copy module at the source system and/or target system. Indicators (e.g., alphanumeric) that the source file has compressed can be included in the target filename by the copy module (e.g., “.qz” suffix). The mapping policy, in some embodiments, can be a user-defined mapping policy that is integrated into the copy module.
After the source file and corresponding target filename are transferred to a target system at 1030, the source file can be requested at a target system using a target application at 1040. The target application can request the source file using the source filename. In some embodiments, the target application can request the source file using the target filename (e.g., root of the target filename) if the target application is configured to use the target filename. The target filename can be parsed using a modified library to determine whether the source file is compressed at 1050. For example, an indicator (included in the target filename) that indicates that the source file has been compressed can be extracted from the target filename. The modified library can be configured to use the mapping policy to determine whether the indicator is indicating that the source file is compressed. The modified library can be used by a target application and/or an operating system associated with the target application to determine whether the source file is compressed.
The source file is decompressed based on compression information included in the source file at 1060. The source file can include, for example, a file header that includes information about the type of compression used to compress the source file. The target application can use the information in the file header to decompress the source file.
While various embodiments of the invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the invention should not be limited by any of the above-described embodiments, but should be defined only in accordance with the following claims and their equivalents. While the invention has been particularly shown and described with reference to specific embodiments thereof, it will be understood that various changes in form and details may be made.

Claims

1. A method, comprising:

receiving a file attribute associated with a source file having a source filename, the source file being associated with a source system, the file attribute being used by a source application to process the source file; and

defining a target filename based on the source filename and an indicator of the file attribute, the indicator being used by a target application of a target system to process the source file at the target system, the target application being the source application configured for use on the target system.

2. The method of claim 1, wherein the target filename includes a portion of the source filename, the defining includes incorporating an indicator of the file attribute into the target filename.

3. The method of claim 1, wherein a file system of the source system is based on a non-hierarchical file system, a file system of the target system is based on a hierarchical file system, the source file being migrated from the source system to the target system.

4. The method of claim 1, wherein the file attribute is determined by a source operating system of a source system.

5. The method of claim 1, further comprising:

extracting at the target system the indicator from the target filename using a modified compiler library associated with the target application.

6. The method of claim 1, wherein the file attribute is received at the target system and the target filename is defined at the target system.

7. The method of claim 1, wherein the file attribute is received at the source system and the target filename is defined at the source system,

the method further comprising:

sending the target filename and corresponding source file to the target system.

8. The method of claim 1, wherein the file attribute includes at least one of a record length, a file format, or a compression attribute.

9. The method of claim 1, further comprising:

requesting at the target system the source file using at least a portion of the target filename; and

determining at the target system the file attribute associated with the source file based on the indicator.

10. The method of claim 1, wherein a source data from the source file is processed by the target application using a modified compiler library, the source data being encoded in a source encoding, the source data having one or more portions encoded in the source encoding based on data type, the modified compiler library being configured to convert at least one portion of the source data into an encoding that can be manipulated by the target application.

11. A method, comprising:

determining at a target system a file attribute associated with a source file based on an indicator of the file attribute included in a target filename, the source file being migrated to the target system from a source system, the target filename being defined based on a source filename associated with the source file and the file attribute; and

processing the source file at the target system using a target application based on the indicator of the file attribute, the target application being the source application configured for use on the target system.

12. The method of claim 11, wherein the file attribute is determined by a source operating system of the source system.

13. The method of claim 11, wherein the determining includes determining using a modified compiler library associated with the target application.

14. The method of claim 11, wherein the determining includes determining based on a mapping policy.

15. The method of claim 11, wherein a file system of the source system is based on a non-hierarchical file system, a file system of the target system is based on a hierarchical file system.

16. The method of claim 11, wherein a source data from the source file is processed by the target application using a modified compiler library, the source data being encoded in a source encoding, the source data having one or more portions encoded in the source encoding based on data type, the modified compiler library being configured to convert at least one portion of the source data into an encoding that can be manipulated by the target application.

17. A method, comprising:

defining a file attribute indicator based on an attribute associated with a source file and based on a mapping policy, the source file having a source filename, the source file being migrated to a target system from a source system; and

defining a target filename based on the source filename and the file attribute indicator, the target filename being used by a target application of the target system to process the source file, the target application being the source application configured for use on the target system.

18. The method of claim 17, wherein the mapping policy is a user-defined policy, the user-defined policy is based on a syntax of the source filename.

19. The method of claim 17, further comprising:

compressing the source file when a condition associated the mapping policy is satisfied; and

decompressing the source file based on the file attribute indicator when the source file is processed at the target system by the target application.

20. The method of claim 17, wherein a file system of the source system is based on a non-hierarchical file system, a file system of the target system is based on a hierarchical file system.