U.S. patent application number 11/668212 was filed with the patent office on 2007-05-31 for mapping a source file from a source system to a target system.
Invention is credited to Glenn Fowler, David Korn.
Application Number | 20070124302 11/668212 |
Document ID | / |
Family ID | 36576205 |
Filed Date | 2007-05-31 |
United States Patent
Application |
20070124302 |
Kind Code |
A1 |
Korn; David ; et
al. |
May 31, 2007 |
Mapping a Source File From a Source System To a Target System
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.
Inventors: |
Korn; David; (New York,
NY) ; Fowler; Glenn; (Scotch Plains, NJ) |
Correspondence
Address: |
COOLEY GODWARD KRONISH LLP;ATTN: PATENT GROUP
Suite 500
1200 - 19th Street, NW
WASHINGTON
DC
20036-2402
US
|
Family ID: |
36576205 |
Appl. No.: |
11/668212 |
Filed: |
January 29, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11311423 |
Dec 20, 2005 |
|
|
|
11668212 |
Jan 29, 2007 |
|
|
|
60675183 |
Apr 27, 2005 |
|
|
|
Current U.S.
Class: |
1/1 ;
707/999.006; 707/E17.006 |
Current CPC
Class: |
G06F 16/258 20190101;
Y10S 707/99936 20130101; Y10S 707/99942 20130101 |
Class at
Publication: |
707/006 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
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.
Description
RELATED APPLICATION
[0001] 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
[0002] 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.
[0003] 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
[0004] 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
[0005] 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.
[0006] FIG. 1 is a schematic diagram of an embodiment of the
invention.
[0007] FIG. 2 is a flowchart illustrating an embodiment of the
invention.
[0008] FIG. 3 is a figure illustrating the processing of source
data on a target system according to the flowchart in FIG. 2.
[0009] FIG. 4 is a flowchart illustrating an embodiment of the
invention.
[0010] FIG. 5 is a flowchart illustrating an embodiment of the
invention
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] FIG. 10 is a flowchart that illustrates a method related to
source file compression, according to an embodiment of the
invention.
DETAILED DESCRIPTION
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] After the data has been manipulated, the numeric data is
stored/written in the target character encoding 560.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
* * * * *