Patent Publication Number: US-2007124302-A1

Title: Mapping a Source File From a Source System To a 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  
      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. 
    
    
     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 C 3  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 B 2  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 A 1  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 B 2  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 A 1  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 A 1  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 A 1  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 A 1  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.