Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F8/00—Arrangements for software engineering
  • G06F8/70—Software maintenance or management
  • G06F8/78—Methods to solve the "Year 2000" [Y2K] problem

Definitions

• the present invention relates to software systems and in particular to software systems for virtualizing arbitrary data within software system program and data files to any desired format.
• the year 2000 problem stems mostly from application programs and their corresponding data that use 2 digits to represent the year rather than 4 digits.
• a large number of these programs were written by application programmers back in the 1960's and 1970's who never expected that their software would still be used 20 or 30 years later in the year 2000.
• these programs were written at a time when every byte of storage memory space was valuable. Every opportunity to reduce the storage requirements of programs and databases was taken advantage of.
• 2 digits to represent year data was widely used and quickly became the customary practice of the trade. Rather than being tossed out, as time passed, new features were added and updates made to these legacy applications, mostly written for mainframe and minicomputers, in order to keep them current.
• the year 2000 problem is compounded when one considers the possible ramifications of using 2 digits to store the year. Any arithmetic calculation that subtracts year data runs the risk of being off when using years 2000 and beyond. Two-digit date information cannot be compared correctly if the dates are in different centuries. In addition, sorting algorithms will not sort correctly records that include years 2000 and beyond. For example, the year 2003, represented by 03, will be sorted before the year 1996, represented by 96. In addition, leap year and other day/week month calculations will be off. For example, the year 2000 is a leap year whereas 1900 is not. In addition, the dates of the week and month are not the same in, for example, the years 2001 and 1 01.
• Another solution is to use a windowing technique which externalizes the 2-digit year into a 4-digit representation.
• This technique uses a fixed or rolling window of 100 years to determine whether the 2-digit year is 19xx or 20xx.
• a number of years to be used for each century is specified. For example, numbers 00 to 20 might represent years 2000 to 2020. Thus the numbers 21 to 99 represent the years 1921 to 1999.
• An advantage of this technique is that there is no need to expand the 2-digit year to a 4-digit format.
• a disadvantage is that a problem exists if years beyond the 100 year range are needed.
• any databases that use the 2-digit year as an index will not work because of the discontinuous step from 20 to 21. And from 99 to 00.
• a third solution is to encode and compress the 2-digit date field to hold 4 digits.
• An advantage of this solution is that there is no need to expand the 2-digit year data format to 4-digit year format.
• a disadvantage of this solution is that all programs that access this data file must be modified to handle the compressed/encoded 4-digit year format.
• FIG. 1 Illustrated in prior art Figure 1 is a diagram showing the potential problems involved in using some of the prior art solutions discussed above. Depicting a small group of programs, Programs A 12, B 14, C 16 and D 18 are shown accessing one or more related data Files A 20, B 22, C 24 and D 26.
• Program A for example, is shown with links to Files A, B and C. If Program A is converted to 4-digit year format, before it can be released into production, data Files A, B and C must also be converted, otherwise Program A will not work. Program B, however, accesses Files A, C and D, thus changing Program A also effects the operation of Program B. Therefore, it can be seen in a typical scenario the conversion of one program or data file cannot be done independently of other programs and/or data file, since they typically are interdependent among one another.
• the present invention solves the problem inherent in the prior art solutions by providing a mechanism of virtualizing any arbitrary data field in a data file so as to be presented having any desired format.
• This mechanism is directly applicable to the year 2000 data problem described above.
• the present invention operates by severing the link between the program conversion process and the data file conversion process.
• the present invention assumes control each time a converted program reads or writes a record of a data file that has not yet been converted. Converting records during I/O operations, enables a converted program to access an unconverted data file as if it were converted.
• the invention converts the date fields in a read record to a new format that is implementation specific before passing it on to the program.
• the dates are defined in the new format (e.g. 4-digit year format) which the program expects to see.
• Unconverted programs continue to access the actual unconverted data file.
• the present invention provides the converted program with a virtual converted view of an unconverted data file.
• the invention similarly converts data having the new format, (e.g., 4-digit year format dates) to the old format before writing records to an unconverted data file.
• one aspect of the present invention provides a system of virtualizing any arbitrary data field of a data file as to be present the data file in any desired format.
• enable legacy software applications may be adapted to the upcoming change in year from 1999 to 2000.
• Another aspect of the present invention provides for adapting legacy application programs to the year 2000 requiring only conversions to application programs and allowing data files to remain intact with original 2-digit year format data. It is yet another object of the present invention to eliminate the requirement that all application programs and data files be converted to a new, e.g., 4-digit year, format at once. Initially, application programs can be converted and subsequently data files may be converted.
• a data adapting system for virtualizing an arbitrary data field, having an original format, of a data file to present the data in a desired format.
• the system utilizes a data conversion definition, suitably created by a user.
• the data conversion definition containes indicia of: record types in the data file; fields in the record type used to identify the record type, and their values; and data fields corresponding to the data to be virtualized and the corresponding format thereof.
• At least one conversion routine is provided to map the data fields within the records of the data file to the new format.
• a data adapter intercepts read requests from the program and, utilizing the conversion routine, substitutes in a record read from the data file, data having the desired format for data having the original format, and intercepts write requests from the program and, utilizing the conversion routine, substitute in a record written to the data file, data having the original format for data having the desired format.
• the original data format may be a 2-digit year format and the desired data format a 4-digit year format.
• the system may also include a program generator for generating, the conversion routine(s) utilizing the Data conversion definition.
• the program generator includes a first (e.g., high level language) program generator, which high level language generator utilizes the Data conversion definition to generate a first (e.g., high level) program, which determines the mapping ( e.g., lengths and offsets) of the data fields in the data file.
• a second program generator processes the output of the high level program to generate the conversion routine.
• Fig. 1 is a prior art illustration of a sample scenario involving multiple application programs accessing multiple data files
• Fig. 2 is a high level block diagram illustrating the application of the data adapter of the present invention toa sample data processing scenario
• Fig. 3 is a high level block diagram illustrating the data adapter system of the present invention applied to a sample data processing scenario
• Fig. 4 is a high level block diagram illustrating in more detail the data adapter system of the present invention.
• Fig. 5 is a high level flow diagram illustrating the initialize routine of the present invention
• Fig. 6 is a high level flow diagram illustrating the 'OPEN' hook routine of the present invention
• Fig. 7 is a high level flow diagram illustrating the Input/Output (I O) read routine of the present invention.
• Fig. 8 is a high level flow diagram illustrating the I/O write routine of the present invention
• Fig. 9 is a high level block diagram illustrating in more detail the conversion routing generator of the present invention
• Fig. 10 is a high level block diagram illustrating in more detail the COBOL program generator of the present invention
• Fig. 11 is the contents of a sample Data conversion definition used in conjunction with the conversion routine generator
• Fig. 12 is high level block diagram illustrating the data adapter system of the present invention as applied to the conversion of data files to 4-digit year format
• Fig. 13 is a data diagram illustrating the 8-byte representation of 4-digit year format data encoded and compressed into the original 6-byte 2-digit year format.
• FIG. 2 A high level block diagram illustrating the application of a data adapter, generally referenced 10, of the present invention to a sample data processing scenario is shown in Figure 2.
• a data adapter generally referenced 10
• Figure 2 A high level block diagram illustrating the application of a data adapter, generally referenced 10, of the present invention to a sample data processing scenario is shown in Figure 2.
• Figure 2 An example of the year 2000 date problem discussed above is used throughout this disclosure. The illustration of the present invention using the year 2000 problem in no way limits the suitability of the present invention to other non date related applications.
• the present invention can be applied to any system where it is desired to virtually change the formatting of arbitrary data fields in a data source such as a data file, computer screen memory, magnetic tape, etc.
• Program A 28 represents an unconverted program and Program B 30 represents a program that has been converted.
• converted refers the process of changing data from one type of format to another type of format.
• the term converted refers to the process of changing every 2-digit year reference in the original program file to 4-digit year format. This includes any reference to dates, comparison of dates, arithmetic operations on one or more dates, etc.
• Unconverted data file 32 is the original date file that still retains the original 2-digit year format.
• Data adapter 10 functions to intercept all I O calls from Program B and perform a virtual change of data format. In this example, all 2-digit year dates obtained from unconverted data file 32 are replaced with 4-digit year format dates. Thus, the fact that data adapter 10 is intercepting all I O calls is transparent to Program B. It expects and receives 4-digit year formatted information.
• data adapter 10 converts the 4-digit year format into 2-digit year format before actually writing the date data to the data file.
• Data adapter thus allows both unconverted programs that still expect 2-digit year format data to execute side by side with programs already converted to handle 4-digit format year data.
• An advantage of using data adapter 10 to virtualize data having an old format to data having a new desired format is that it permits Management Information System (MIS) personnel, or anybody else responsible for handling data formatting changes, to convert application programs at their own pace. It is no longer necessary now to simultaneously place in to production all programs and data files at once. Conversion projects may proceed at any desired pace since both converted and unconverted programs can exist simultaneously. For data files to be converted, however, all program files that access that particular data file must have been previously converted.
• MIS Management Information System
• data adaptor 10 cooperates with one or more conversion routines 46 which define the desired transformation.
• Data adaptor 10 and conversion routines 46 are collectively referred to as data adapter system 42.
• data adapter system 42 suitably cooperates with a conversion routine generator 44, employed to generate one or more conversion routines 46 from one or more data conversion definitions (rules) 38 and indicia of a converted header, e.g., a converted header file 40, provided by the user.
• a data conversion definition (rule) 38 is provided for each data item format to be converted.
• Conversion routines 46 are used by data adapter 10 to convert selected data items (e.g. date data) to and from first, e.g. 2-digit year and second, e.g. 4-digit year, formats.
• a data conversion definition 38 and a converted header file 40 are input to conversion routine generator 44.
• Indicia of a header corresponding to the original, unconverted date e.g., an old header file 34 is input to non-converted program 28 which accesses an unconverted data file 32.
• Data adapter 10 accesses unconverted data file 32 in addition to receiving I/O requests from a converted program 48.
• Converted header file 40 also is used together with the converted program as input to the compiler.
• data adapter 10 utilizes one or more conversion routines 46 in performing the actual conversions of data to and from unconverted data file 32.
• the conversion routines may be externally generated by conversion routine generator 44, described in more detail below, from data conversion definition(s) 38, and converted header file 40.
• Converted header file 40 defines the data structure after designated data items are transformed from the first to second format, e.g., contains all the data declarations of the original program with date related data expanded to 4-digit year format.
• Data conversion definition 38 suitably contains explicit definitions, e.g., position, type, etc., of date related data contained in the converted header file.
• data adapter system 42 may include an internal (integral) conversion routine generator, or a built in (e.g., hard-coded) conversion routine suitable for the type of data to be converted.
• an internal (integral) conversion routine generator or a built in (e.g., hard-coded) conversion routine suitable for the type of data to be converted.
• a hard-coded conversion routine created either manually or by other automated means, is of particular utility in instances where the different data types and formats involved in an application are relatively few in number, and unchanging.
• Both converted and non-converted programs may operate side by side upon the same unconverted data file 32.
• Non-converted program 28 using the first, e.g., 2-digit year date format, accesses unconverted data file as normal.
• Converted program 48 has been converted to handle the second format, e.g., 4-digit year formatted date information.
• a suitable data adapter 10 comprises an execution-time data adapter 47, conversion routines 46, an OPEN' hook routine 58 and an initialize routine 56.
• Converted program 30 comprises a sequence of instructions/statements in which all references to the designated data items have been converted from the first to the second format, e.g., all date references in converted program 30 have previously been converted from 2-digit to 4-digit year formats.
• Figure 4 illustrates the typical sequence of COBOL statements used in a converted program that has been updated to handle the second, e.g., 4-digit year, format data.
• converted program 30 triggers data adapter 10 through a single call to initialization routine 56, added at the beginning of the application program. No other change to the program or the program's job control language (JCL) is required to launch the data adapter. Once flagged, the data adapter interprets all I O operations on converted data files and activates the conversion routines.
• JCL job control language
• the call to initialization routine 56 identifies the files that are to be converted, and associates those files with corresponding conversion routines 46.
• the parameters of the call include pairs of file names.
• the first file name is the name of the data file that is to be handled and the second is the name of the conversion routine associated with the data file specified in the first file name. More than one [data file, conversion routine] pair may be listed in the call to initialize routine 56.
• Initialize routine 56 in adaptor 10 functions to set up hooking or trapping for an 'OPEN' command or statement.
• 'OPEN' hook routine 58 is executed.
• the OPEN hook routine functions to set up additional hooking for I/O reads and writes and then calls the original 'OPEN' routine.
• converted program 30 When a read or write statement is reached, in converted program 30, program control is switched to data adapter 10.
• the data adapter utilizes conversion routines 46 in converting or virtualizing data having the original format to data having the desired new format. In particular, in the year 2000 example, 2-digit year data is converted to and from 4-digit year data.
• the data adapter also calls an original I/O routine 62 to actually perform the read or the write to unconverted data file 64.
• the data is virtualized and the application program is unaware that the data originally had the old formatting.
• Co-existing simultaneously with converted program 30, non-converted program 28 suitably directly accesses 2-digit year information from unconverted data file 64.
• the first step performed is to install hooks or software trapping using, e.g., SVC screening techniques, well known to those skilled in the art (step 72).
• the conversion routines are loaded into memory for speedy access (step 74).
• the file is on the call statement list, it is then determined whether the data file is to have its, e.g., date year information converted (step 82), suitably by reference to an indication of whether to convert a data file in the data conversion definition 38 ( Figure 3).
• date year information in a data file associated with a converted program is converted from first to second format, e.g., 2-digit to 4-digit year format, it may still be desirable to retain the associated statements (i.e., CALL initialize, OPEN, etc.) in the converted programs. Removing these statements, initially needed to set up the year information, requires additional testing and maintenance time, and there will likely be hundreds of such converted programs that do not need this extra code because all their associated data fields have already been converted to 4-digit year format.
• the next step is to modify the Data Control Blocks (DCBs) that were provided by the application program to accommodate those file attribute(s) such as record length, is different where the actual presentation and virtual presentation may differ.
• DCBs Data Control Blocks
• I/O routine hooking is installed by modifying the access method routine in the corresponding DCB (step 84).
• the DCB exit is also modified in order to properly install I/O routine hooking (step 86).
• I/O hooking is in place, the original OPEN routine 60 is executed (step 88).
• Data adapter 10 comprises an I/O read process ( Figure 7) and an I/O write process (Figure 8).
• the original I O read routine 62 ( Figure 4) is initially executed.
• the conversion routine 46 generated previously, corresponding to the data file, is called to perform the actual first format to second format, e.g., 2-digit to 4-digit year format, conversion (step 92).
• the converted, e.g., 4-digit year, format data is passed to the calling converted application program 30 (step 94).
• the record to be written to the data file is passed to the hooked I/O write routine of Figure 8 (step 100).
• the data file's corresponding conversion routine 46 is called to perform the actual second format to first format, e.g., 4-digit to 2-digit, conversion on the record (step 102).
• the original I/O routine 62 Figure 4
• the I/O read and write routines of the present invention permit data file 32, which retains its original, e.g., 2-digit year, format data, to be virtually converted to the second, e.g., 4-digit year, format.
• conversion routines 46 may be hard-coded or generated by an internal (integral) conversion routine generator. However, in instances where a number of different data types and formats involved in an application, e.g., the application operates upon data having a number of different record formats, conversion routines 46 are preferably generated by conversion routine generator 44 external to adaptor 10, to maximize flexibility. From a user's perspective, use of conversion routine generator greatly simplifies the task of defining lengths and offsets of the data fields within a data file that need to be converted; a user is able to specify lengths and offsets in the language of the application, e.g., COBOL, rather than in a more cryptic type fashion.
• COBOL e.g., COBOL
• Data conversion definition 38 e.g., a data definition file
• converted header file 40 is the original header file modified in accordance with the second format, e.g., with expanded date field sizes (2-digit year fields have been expanded to 4-digit year fields).
• Indicia of data conversion definition 38 is input to a suitable program generator (step 110).
• the programming language COBOL is suitably used in the exemplary embodiment here described. However, other programming languages would work just as well. One skilled in the art could substitute other programming languages and other platforms to perform the teachings of the present invention.
• program generator 110 is to generate a program (e.g., in COBOL) that can be used to determine for all the data fields in the data file, the lengths and byte offsets used in the conversion routine, and whether or not they are to be converted (e.g., to 4-digit year data).
• a program e.g., in COBOL
• the COBOL program source output from the COBOL program generator is compiled and linked (step 112) using a standard COBOL compiler and linker.
• the converted header file 40 is used as input during the step of compiling and linking.
• Converted header file 40 provides all the data file data definitions (i.e., structures, arrays, variables, etc.) needed by the COBOL program to access the data file.
• the output object code is then executed (step 114).
• the executed program preferably uses a novel technique to determine the offsets, displacements, size and type of the data field and other variables within the data file.
• the technique involves filling a record with hex FF in every byte. Data are then selectively written to the record. The record is then scanned and the position and length of the non-FF data is determined. The non-FF data corresponds to the data fields within the record.
• This technique is performed by assembler routines invoked by the COBOL program.
• the binary length and offset (displacement) output of the COBOL program is input to an assembler program generator (step 116).
• the assembly program generator uses the output of the
• COBOL program to generate the source code for the conversion routines.
• the assembly source code is then compiled (i.e., assembled) and linked using standard development tools (step 118).
• the object code output from the conversion routine generator is the executable conversion routine.
• the COBOL program generator will now be described in more detail. A high level block diagram illustrating the syntax structure used by the COBOL program generator is shown in Figure 10.
• Data files sometimes include records with different formats, or records with varying information.
• Data conversion definitions 38 include the information necessary to identify the various types of records, as well as the particular logic to be employed in the conversion.
• Data conversion definition 38 suitably includes a header definition 132 followed by a body 140.
• Header definition 132 suitably includes a FILE-ID structure 134, a default statement 136 and a conversion protocol 138.
• conversion protocol 138 suitably comprises a window-year protocol statement defining the lowest date assumed to be in the 20th century; all earlier dates (lower numbers) are assumed to be in the 21st century.
• the body 140 of a data conversion definition 38 can be either a single type record definition
• a single type record 142 suitably includes a record statement 144 followed by a data description 146.
• the data description 146 can be an array definition 148 or it can be one or more data type definitions 150 (indicated by the star '*' symbol).
• An array definition 148 suitably includes an array statement 152, a recursive data description 154 and an end array statement 156.
• a data type definition 150 suitably begins with a data item, date, type name (of the format YYMMDD, for example) followed by a list of data names of this type 160. If desired, conversion protocols different from the protocol specified in statement 138 of the header definition 132 can be utilized for different data item types. In such case a data type protocol statement 161 , e.g., window year protocol, may be provided as part of the data type definition.
• a multiple type record definition 162 suitably includes one or more record type statements 163 (indicated by the star '*' symbol). Each record type statement 163 suitably includes a record header statement 164, recursive body 166 and end record type statement 168. A record type header 164 suitably includes either a record type statement 165 or a default type statement 167. A multiple type record 162 may have many record type statements and one default type statement as the last record type header for this multiple type record.
• FIG. 11 An example of a Data conversion definition used as input to the conversion routine generator is illustrated in Figure 11.
• the initial step in applying the data adapter entails defining the data fields.
• the FILE-ID 134 'BANKIN' is used as the reference to the data file and its generated conversion routines.
• the default statements 136, under 'DEFAULTS,' are to convert the data file and use old output formatting.
• the window-year statement 138 indicates a 20 year window, meaning dates 00 to 20 are translated to 2000 to 2020 and dates 21 to 99 are translated to 1921 through 1999.
• the 'COPY BANKIN' statement functions to include the contents of the copy book or header file associated with the 'BANKIN' data file.
• the record type statement 164 'BK-RECORD-TYPE' follows the record definition section. The next four TYPE statements 142 describe various date fields in the 'BANKIN' data file.
• the last section is a DEFAULT-TYPE statement for the case when the data field does not fit any of the previous type statements.
• the advantage of using this technique to define the date fields is that the definitions are simple and easily understood.
• the programming language data names are used to specify the date fields, making it unnecessary for the user to manually calculate the field's position, thus saving time and eliminating errors.
• the converted system is 'live' in that changes can be made to the record definitions at any time. To have the data adapter use these changes only the Data Definition file needs to be recompiled and the changes will automatically be reflected in the conversion routines rebuilt by the conversion routine generator.
• a conversion routine 46 has been previously generated by the conversion routine generator 44 and employed to convert all the records in an unconverted data file 32, e.g., having 2-digit year format data, into a converted data file 172 at one time.
• unconverted data file 170 is no longer needed, since no other programs need access to it.
• converted program 174 directly accesses data file 172 without the necessity of data adapter 10.
• the conversion process can be disabled by changing the DEFAULTS statement in the Data conversion definition to 'CONVERT NO.' Making this change will prevent the data adapter from operating on the data file, and the programs, without any need for recompilation, will receive the records directly from the file. If the programs need to be run using historical or backup files 176 that were not converted, the data adapter can be triggered for a specific run by adding a control statement to the job control language (JCL). In an alternative embodiment, the data adapter can selectively convert the data files containing records with both first and second formats. For example, it may be desirable that a program have the capacity to operate upon both converted and non-converted data, such as in an instance where data is converted on-the-fly, as accessed in normal operation.
• such a file might have two types of records: records having dates in the original 2-digit year format; and records with expanded 4-digit year format but which are stored in place of the old date, leaving the record length unchanged.
• the expanded date information is suitably stored as a 6 byte (11 digits) packed decimal number.
• Date field 180 is the 2-digit year format of the original unconverted data.
• Data field 182 is corresponding converted 4-digit year data, as expected by the program stored in packed format in the same length (6 byte) field as the original data field.
• the field length and record length of the data file remains unchanged.
• the data file contains a mixture of both year formats.
• the data adapter uses the internal representation of these two types to distinguish between them.
• the program always receives expanded 4-digit year format data as the method in which the dates are stored is transparent to it.
• all of the records in data file 32 may be converted at one time, as described above, and the conversion feature activated only when unconverted data must be accessed.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• General Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Devices For Executing Special Programs (AREA)

Applications Claiming Priority (5)

Publications (2)

Family

ID=27090979

Family Applications (1)

Country Status (5)

Families Citing this family (5)

• 1997
  • 1997-04-09 AU AU24494/97A patent/AU711020B2/en not_active Ceased
  • 1997-04-09 IL IL12648397A patent/IL126483A/en not_active IP Right Cessation
  • 1997-04-09 WO PCT/US1997/005870 patent/WO1997038379A1/en not_active Application Discontinuation
  • 1997-04-09 JP JP53646097A patent/JP2002503361A/ja not_active Ceased
  • 1997-04-09 EP EP97920260A patent/EP1008061A1/en not_active Withdrawn

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events