CA2236815A1

CA2236815A1 - Two-digit hybrid radix year numbers for year 2000 and beyond

Info

Publication number: CA2236815A1
Application number: CA002236815A
Authority: CA
Inventors: Decao Mao
Original assignee: Individual
Current assignee: Individual
Priority date: 1996-09-18
Filing date: 1997-03-20
Publication date: 1997-10-02
Also published as: EP0871932A1; EP0871932A4; US5668989A; BR9711080A

Abstract

A method and related input/output devices for using biased 2 digit "hybrid radix" numeric fields for inputting, generating, storing, processing, and outputting year numbers ranging from 1900 to 2059 and beyond in a data processing system (fig. 1A). In a hybrid radix 2 digit year number, the higher digit is treated as hexadecimal (or in other radix), but displayed in a decimal-like style with font patterns 0-9 and '0, '1, '2, '3, etc. (fig. 1B). While the lower digit is treated as ordinary decimal, so that the year 1900 is represented and processed as 00 while the year 2000 as '00. For applications written with high level languages such as COBOL and SQL, the method can be embodied solely in the system side (compiler, other system software and/or hardware), and no change other than a re-compilation with a new compiler is needed for existing application software. Compatibility with existing data files and databases is automatically maintained.

Description

=~
CA 0223681~ 1998-0~-0~

.

Two-Digit Hybrid Radix Year Numbers For Year 2(}00 And Bey~nd Background-Field of Invention Most existing application software in business data processing area treat a date in a format similar to "MM/DD/YY" or "YY/DDD", using 2 digits to carry the last 2 digits of a 4 digit year number, resulting in 2 digit year numbers. For example, the year number 1996 is input, stored, processed, and displayed as "96". However, starting at year 2000, this will cause problems because "00" could be interpreted as either " I S~OQ"
or "2000", and for example the length of a period from 1996 to 2900 could be negative if 96 is subtracted from 00. This problem is known as the "Year 2000 (Y2K) Problem"
in the industry, and has been considered a crisis.
This invention solves the problem by nh~nging the data input/output mec h~nism the storage and processing of 2 digit numbers, such that the higher digit of a 2 digit number is treated as hexadecimal, and thus 160 (instead of 100) yeas can be represented with a 2 digit year number. No change is needed for application software source code in high level ~ng~ es; year numbers beyond 1999 are still 2 digit; the displayed and printed out year numbers are decimal-like and self-explanatory. With this invention, the existing software can continue to work 60 more years until the year 2059.

~ackground-Description of prior Art The "Year 2000 Problem" has been noticed and considered catastrophic since l 99~, but so far actually no effective and easy solution is proposed for the problem.

CA 0223681~ 1998-0~-0 W O 97/36222 PCT~US91/0~34 , IBM proposed several solutions~ mainly:
I) Gontinlling to ~Ise 2 digit year numbers with a configurable "sliding centurywindow'7. For example, use numbers 60 to 99 to represent years 1960 to 1999, and 00 to 59 to represent years 2U00 to 2059 While the sliding window mechanism is implemented in the system side, the application software need be modified to setup and change the window accordingly. However, for some, if not all, applications this solution is not practical, because a window of 100 years could be too small, forexample it is quite possible a person born in 1920is still alive in 2020. The existing databases and/or data files make the situation even worse, because before a window can be decided for a particular application a user has to know what is the earliest year number stored in the databases andlor data files.
2) Changing year n~lmbers from 2 digit into 4 or 3 digit IBM announced their new4 digit (year number) compliant system software which will provide 4 digit year numbers to the applications, therefore newly developed application software can begin to use 4 digit year numbers. ~Iowever, existing application software source code need be modiffed to use 4 digit year numbers before a re-compilation.

Solution solely from the system side is considered not possible. This is because the system per se, either the hardware or the software, can not distin~li~h which particular 2 digit field is used for a year number (and which is not) In the mean time, a 2 digit field is considered anyway too small for year numbers after 1999 if sliding century window is not used. Although theoretically the space for a 2 digit field can accommodate at least 256 states if it is used to carry a hexadecimal number, theinput/output and the processing remain problems (for example, no user will accept the idea to use either "60h" or "x'60" to represent the year 1996), and more importantly the compatibility between the new software and the existing data files and databases is a big problem.
Therefore, most efforts are focused on the application software side, and ch~nping these 2 digit fields into 3 or ~ digit seemed to be the only practical approach. Gary I~).
Brown predicted in his book "Advanced ANSI COBO:I_ with Structured , CA 0223681~ 1998-0~-0~

Prog~ ing" (second edition, 1~9~, Wiley ~ Sons, page 371) that this would "keep thousands of maintenance programmers busy in the last year of this century".
~Jnfortunately7 the change is by no means trivial and cheap. An article on the recent (Aug. 19, 1~6) issue ofthe Fortune m~g~7ine even referred the project to be "thebiggest single information project the world has e.ver faced" (page 54).
There has been hot discussion on the Internet for a while on the field size changes, mainly focused on how to olg~ e and implement such a project. Some companies announced comp~lter tools to scan application software source codes, single out these 2 digit fields and change them "automatically" based on some patte.rn-matching or rule-based analysis.
However, the enforcement of such changes is not only expensive, but also dangerous. There is no systematic way which can guarantee that all applop,iate 2 digit fields can be singled out and changed, no matter by human or by some computer tools.
Furthermore, the 2 digit year number fields are not only pe~vasive in the existing programs, but also in the existing data. files and databases. That means the data. files and the database schema and contents also need be changed. For on-line applications, the blackout time per se, during the data file and/or database conversion, might be unacceptable Finally, the change from 2 digit into 4 digit could also cause problems on the user interface.

O~jects and Advantages This invention so1ves the problem solely in the system side for application software in high level l~n~-~ges (such as COBOL). For these applications, no change other than a re-compilation (with a new compiler) is needed for the source programs. All the data files need no change, and all the databases will continue to work with a re-compiled DE~MS while no change is needed for the database schema and contents.
Solving the problem solely in the system side has many advantages. At first, thechanges, no mater in hardware or in software~ are mllch cheaper. Comparing to the cost the application software and database changes could cause, the cost for thehardware and system sofLware changes (to embody this invention) is almost negligible.

CA 0223681~ 1998-0~-0~

,1 Second, but more importantly, it is much safer, because that means the effort iscentrali~ed. The hardware and/or system software (compilers and database management systems) venders can concentrate better resources into the projects, and ha~e better quality control. Although the 2 digit year number fields are defined in the application programs, all the processing and arithmetic operations are eventually exeGuted by the system resources. That means no one single field can bypass or escape from the system control, as long as the system hardware and software are properly designed and implemented. Third, it is much more effective, once the new hardware and/or system software are available, users need only to upgrade their hal .lw~r~ and system sof~ware (compilers, database management systems, etc.~, and then re-compile their application programs. At last, because no change is needed for the application software and the databases, thç blackout during the transition can be reduced to the minim~l Descrip~ion This invention solves the "Year 2000 Problem" from 3 tightly related perspectives.
Input/output, which involves how to input a biased (with an offset of 1900) 2 digit hybrid radix num~er representing a year number in the 1 9()Q - 2059 range from the keyboard, and display or print out the number in a 2 digit decimal-like field. Also, how the system can generate a consistent 2 digit ''currçnt year number" after year 1999.
Storage, namely how to store a year number beyond year 1999 in a 2 digit field in the memory, in a way which is co.~ Lible to the e~isting software and databases.~ rl ~ce;,;,.,~g, how to apply arithmetic operations to such ~. digit fields to get correct results.

Fig. 1 illustrates the difference between the numeric key pads of an ordinary ~eyboard and a modified keyboard, the "keyboard 2000". Six new keys, key '0, '1, '2, '~, '4, and '~, are added, each represents the first digit of a decade af~er year 1999.

CA 0223681~ 1998-0~-0~

Accordingly, six new digit font patterns are created and embodied for displayingand/or printing out.
For examplç, Icey 'O will be used for a year of 200x, while key '1 will be used for a year of 201x, and the like. The six particular exchange codes, generated by the keyboard or sent to the screen or printer, depend on the system, and is flexible. It could be in "escape sequence", ASCII, EBCDIC, ~oned decimal, proprietary internal coding, and so forth. For example, in 8 bit ASCII, codes BOh to B5h might be used for digits 'O to'5, whiie 30h to 35h are used for digits Q to 5.
An alternative is to use the "shi~" or other similar "meta" keys together with the ordinary numeric keys. In that case the same numeric keys O - 5 are shared to generate either digits 0-~ or digits 'O '~.
In business applications, computer systems use a "packed" or "unpacked" ~CD
code to carry, or store, a. decimal digit. In Packed BCD, 4 bits are used to represent one ofthe 10 possible decimal digits (O to 9). However, 4 bits can actually be used to represent one of 16 d~ " states, 6 states are wasted in packed BCl:) coding (more are wasted in unpacked B~ coding). Taking advantage of this fact, this inventionuses 4-bit BC~ code as hexadecimal, to carry the 6 newly added hex~decim~l, but decimal-like, "digits" 'O to'~, together with the 10 oldh~aly decimal digits in a special way.
The use of the 6 extra states in a 4-bit BCI) code is conditional, it is only applied to the second digi~ before the dec ~I point ~either explicit or implicit) if this digit is the most significant digit in the number, and it follows some special procedures and arithmetic rules, which I will describe. In this way, in a 2 digit year number the first (lower) digit is in radix 10, while the second digit is in radix 16, and therefore is called a "hybrid radix" mlmber.
The concept of hybrid radix is not new, for example in a month number the seconddigit is actually in radix 1. E~owever, appiying the concept to year numbers, artificially ~naking a year mlmber hybrid radix, which otherwise is pure decimal in comrnon sense, leads to the solution of the "Year 2000 Problem".

CA 0223681~ 1998-0~-0~

Note that although 2 digit hybrid radix is specially chosen for year numbers, in a system embodying this invention all 2 digit numbers are in hybrid radi~, the system need not to distin~ h whether a particular 2 digit number is a year number. This is because decimal is a true subset of hexadecimal, and difference exists only if the value is larger than g on the second digit, which in 2 digit pure decimal means overfiow. This is why we don't need to single out these numbers representing a year number from the application source programs, and why it is automatically compatible with existing databases and data files.
Special procedures apply when a number (numeric field) is entered, or to be displayed or printed. Fig. 2 and Fig. 3 are flowcharts illustrating the procedures. When a number is entered, the second digit is alic-wed to carry a hexadecimal value (O-g, and '0~5), if the integer potion is a 2 digit field. Accordingly, when a number is displayed (left to right), eve~y digit is a normal decimal digit except the second (higher) digit of a 2 digit field which is hexadecimal. The following examples further explain ho~v the digits are input, stored, and intel~r~Led.
stora~e value. ou~put reason [l~L2~L'3][4~ _ --- invalid, not a 2 digit field;
r3]C4] --- --- invalid, not the higher digit;
[1]~2]r3][4~1234 I234 normal pure decimal, t3][41 34 34 the second digit is the highest digit, but is 3.
1'3][4~ 134 '34 the second digit is the highest digit, and is '3.
In summary, the special rules for the input, storage, and inte~ L~Lion of the second digit before the decimal point are:
~ The second digit is decimal if it is not the highest digit in a field.
~ If the second digit is the highest digit in a field, then its value is stored and interpreted as hexadecimal, using symbols 'O to'5 to represent value 10 to 1~.
Flow chart Fig. 4 illustrates how to expand a 2 digit field into 3 digit (or longer) ~eld.
Note that hçre the word '~1eld" means a smallest logicai unit of storage space. For example, a 2 digit year number is such a unit, which can not be further divided CA 0223681~ 1998-0~-0~

logically, aithough physically it can. For a date in "M:M/~D/YY" format, for example, physically the whole date is carried in a 6 digit string, however the year n~mber is carried in a 2 digit field, and therefore the second digit is in hexadecimal. Although the ~M field is also 2 digit, and th~ls the second digit is also hexadecimal, but the existing software must already ~limin~ted the possibilities to have a value greater than 1 on this digit.
Since the second digit before the decimal point is in a different radix, we need some special procedures and rules for its arithmetic operations as well. Fig. 5, Fig. 6, and Fig. 7 are ffowcharts for the special arithmetic procedures for ADl~ and SUB
operations.
For an AD3~) operation, all digits follow ordinary decimal rules, except the second digit which follows the hexadecimal rules if and oniy it is the highest digit in a field. In addition, if the second digit is the highest digit, and a hexadecimal carry is generated from this digit position, then the sum is adjusted by adding a h to the second digit to make it consistent with pure decimal. The procedure is illustrated in Fig. 5. Following are several examples:
~rithm(:fi~ before 2nddig~t C~arr~ fromthe r ~_.k'. ;.. ~1 ~ighest digit A~lju~ ll Overflow 36 + 95 = '31, Yes, NO, NO, NQ;
036 + Q95 = 1~1, NO, NO, NQ, NO;
76 + 95 = 11, Yes, Yes, 11 + 60 = 71, Yes.
In pure decimal, the fact a carry is generated from the highest digit indicates an overflow. Usually, like in COBOL, a "size-error" condition will be raised in such a case For 2 digit numbers, since they are now in hybrid radix, a size-error is raised if and only if the sum is greater than 159.
Similarly, for a SUBtract operation, there is no difference if the fields are not 2 digit fields. In practice, a SUB operation is almost always reduced into add the complement ~5f the subtrahend to the minuend. Accordingly, for a SUB operation on 2 digit fields a 1 5's complement is taken for the second digit, while for the first digit a 9's complement is taken. Because of this, 2 special mles are applied CA 0223681~ 1998-0~-0~

I ) The result is adjusted by subtracting a ~i from the second digit.
2) The hexadecimal carry is inverted, and I OO's complement is taken and the result is negative if carry is generated (after inverting~.
The procedure, applicable if both operands are 2 digit, is illustrated in Fig. 6, and following are several examples:
l) 23 - 12 = 23 + '47 + 1 = 71, 71 - 60 = 1 17 2) 12 - 23 = 12 + '3~ + 1 = '4g, '4g - ~0 = 89, and 100 - ~ = -117 3) 91 - 72=gl + ~7+ 1 = 7~, 7~-60= 19, 4) 72 - ~1 = 72 + 68 + 1 = '~1, '41 - 6~ = 81, and 100 - 81 =-19;
~ ) gl - 12 - ~1 + '47 + I = '3g, '39 - 6~ = 79;
~) 12 - 91 = 12 + 68 + I = ~ 1 - 60 = 21, and 100 - 21 =-7~7 In example 1, the subtrahend 1~. is changed into its complement '47, and the sum is incremented by one (as usual). No hexadecimal carry is generated in this case because the carry is inverted, although in the normal sense we do have a carry because the result is greater than l ~ er adjustment, the result is a positive 11.
In contrast, in example 2 a hexadecimal carry is generated, again because it is inverted, aithough the result on the second digit is not greater than 1~. Because of this, lQO's complement is taken after the adjustment, and the result is negative.
The prQcedure applies oniy if both operands are 2 digit (or less). If either theminuend or the subtrahend is longer than 2 digits, then thç ~ digit one is expanded into a 3 digit buffer, and then normal decimal rules appiy. A simpler implement~tion, is to expand the minuend and subtrahend into two 3 digit BCD buffers first, even if both are 2 digit, then execute ordinary decimal SUB there7 and finaily convert the result back into 2 digit. In this way, the expansion automatically compensated the needed adjustment after a sub operation. I did not provide a flowchart for converting back, because it is simply the reverse of the expansion. discarding the third digit and adding a 10 to the second digit if the third digit is 1.
"Compare" is actually a SUB operation, it follows the same rules for SUB, but does not physicaliy change the minllen~i CA 0223681~ 1998-0~-0~

These rules are dirrr~,~ ell( to either pure decimal or pure hexadecimal, and are applied conditionally, therefore it might be called C'conditional hybrid radi~".
I did not describe the MULTIPLY and DIVIDE operations explicitly, because they are similar, once the rules on how to interpret the second digit how to expand are defined, the further processing is straightforward. For example, all 2 digit fields can be expanded irto 3 digit buffers (Fig. 4~ before a multiply or divide operation is executed.
Unpacked BCD uses ~ bits to represent a decimal digit, with the last 4 bits g the same as thç ~orresponding packed BCD code. Therefore, the same rules also apply to unpacked BCD codes.

For application software written in high level languages, such as COBOL and SQL,the arithmetic procedures can be embodied purely in the system software. The flowcharts can be easily turned into codes in various languages, and can then beembodied in compilers and/or other system software (such as subroutine libraries~
database management systems, etc.) Particularly, the changes can be implemented as subroutines embedded either in the code generation potion of a compiler or in libraries, depending on the particular l~ng~lage. All the related input/output, processing, and arithrnetic operations are t}~n.~l~ted into ca!ls to these subroutines.
In addition, software changes are also needed in two other aspects:
1 ) Generating the current year number in accordance to the special mles. For example, in COBOL, the "ACCEPT FROM DATE" statement should return'00 (rather than 00) in the YY field in year 2000. The implementation for this is straightforward.
2) Allowing the six newly added digits pass the various range checks. For example, in COBOL the "IS NVMERlC" clause and other related mech~ni~m~ should recognize '0 to '5 as numeric values. Again the implementation is straightforward.

_ Following is an example on how to embody this invention in a COBOL compiler, by either developing a new one or modifying an existing one.

CA 02236815 l99X-05-05 ~ Code implementing the "ACCEPT" statement is enhanced. The input procedure illustrated in fiowchart Fig. 2, plus the keyboard changes illustrated in Fig. 1, and the change for "ACCEPT FROM DATE" are embodied here.
~ Code implementing the 'I)ISPLAY" statement~ is enhanced. The output procedure illustrated in flowchart Fig. 3, and possibly the font change as well, are implemented here.
~ Code implementing the "MOVE" statement is changed. The mles for expanding a 2 digit field (Fig. 4), and the reverse, are embodied here.
~ Code implementing the C'ADD", "SUBTRACT", "M~JLTIPLY"~ "DIVIDE'~, and "COM:PUTE" statements are enhanced. The mles and procedures for arithmetic operations are embodied here.
~ Code implem~nting the ~ "L<=~ >=~, and ">" operators arç enhanced to adapt to the new code for SUB operation (Fig. 6 or Fig. 7).
~ The dcfinitions for NrJMERIC and ALPHA~NU~ are enhanced to include the six ne.w digits. Typically the "IS NUMERIC" clause, "IS NOT NIJMI~IC" clause, and the INSPECT statement wili call a common routine something like is_digit() to do a range check, and the change is embodied here.

While this is a pure software impl~.m~nt~tion, some rules can also be implemented as halJw~l~ or firmware. In addition7 while the example is for COBOL compiler, similar changes can be implemented for other prog~ ....ing l~n~ges, such as PL/I, and/or other system software, like database management systems, and query l~n~lla~es sush as SQL.

In the input./output side, as described before, six new exchange codes are defined, six new keys or key combinations are added to the keyboard, and six new font patterns are added to the output device. To generate exchange code for each of these new keys, ~ecessary circuitry or a combination of circuitry and software is also added, but which is quite simple. Similarly, to display or print out each of the new font patterns, necessary circuitry or a combination of circuitry and software is added in the output CA 0223681~ 1998-0~-0~

WO 97/36222 PCT/US97/1~5345 device, and which is simple again. The font patterns can be stored either in the output device, or in the host machine, depending on the particular architecture.

User lnterface and Operation Essentially the user interface of existing software remains ~mchanged, except that 6 new keys, or key combinations, and 6 new font patterns, namely 'Q, '1,'2, '3,'4, and '5, are added to the input and output devices respec.tively. When a user is prompted to enter a 2 digit year number, the 6 ne.wly added digits can be used together with the 10 normal digits (0 - 10). For example, "'00" will represent the year 2000, and so forth.
The 6 new hexadecimal numeric font patterns are decimal-like and self-explanatory, because each contains a pattern of its decima! counterpart, namely the corresponding decimal digit.
The change has no impact on all numeric fields which are not 2 digit. For 2 digit numeric fields other than year numbers, in most cases there is no impact, because these numbers are input or ge.nerated in range 0 - 9~. Howe.ver, in certain special cases there is a minor impact which is discussed following.

D;sadvant~sg~
For a ~ digit numeric field other than a year number, if arithmetic operation isapplied, and the programmer relies on the system to raise a size-error when the result is larger than 99, now a size error is raised only if the result is larger than 159. ~or pl~, if 76 is added to ~0, the sum should be 26 together with a size-error in pure decimal. However, because the second digit is now hexadecimal, the sum will be '26 without si~e error. This may or may not be considered a problem, if '26 is interpre.ted as 1~6. On the other hand, the result is the same if 76 is added to 90, namely a sum of 66 together with a si~e-error..

~;ummary7 Ramification, and Scope of Invention Year numbers are represented with 2 digit hybrid radix numbers, in which the higher digit is input, generated, stored, processed, and output as hexadecimal, but displayed in CA 0223681~ 1998-0~-0~

.
a decimal-like way with font patterns Q - 9 and '0 - '5, while the lower digit is treated as ordinary decimal. For application software in high level IRng~lages, such as COBOL
and SQI" the method can be solçly embodied in the system side, mainly in compilers, thus no change to the existing application source code other than a re-compilation is needed, and compatibility with existing data files and databases is automatically i"t~i.,ed.
While my description contains many specificity's, these should not ~e construed as limitations on the scope of the invention, but rather as several exemplification of a few preferred embodiments thereof. Many other variations are possible. Following areseveral examples.

The method can be applied to unpacked BCD coding as well. Further, some systems may use special coding other than BCD, but this will not change the fact that a 4 bit field has 16 difl~e~ bit combinations and of which only 10 are used to represent a decimal digit, while a 3 bit field is too small for a decimal digit. Therefore, as long as a field can be used for a decimal digit, it can also be used for R hexadecimal digit, and thus the method described in this description can be embodied. Note that the radix of the higher digit does not have to be hexadecimal. For unpacked B~D, since more bits are used, a radix of larger than 16 cab be used, and more font patterns can be created accordIngly.
As described earlier, the result of an ADD operation will be incorrect without adjustment if a hexadecimal carry is generated from the higher digit of a 2 digit field.
Howevçr, for software relying on exception hRnr~ling in which the result is ignored upon overfiow, the adjustment is optional.
While most of the business appl;cation so~ware were written in high level iRnsgl]~geS, a small potion ofthe existing application software rnight be written in assembly IRng~ es For application software in assembly l~n~l~ges, although the changes can no longer be solely made in the system side7 this invention can still be emkodied in the application side to maintain the compatibility with the existing data f~les, databases, and user interfaces.

CA 0223681~ 1998-0~-0~

On the other hand, for some modern high level pro~ ,.",.;~-g l~n~ges with operator overloading, such as C++, it is also viable to embody this invention in the application software, by overloading the operators (+, -, *, ~, >, <, =, and so forth) with new ones which incorporate the described nules and procedures.
Also, a micro processor can be designed to embody the arithmetic nules in the ALIJ
hardware, either hard wired or micro-coded, and either as new instmctions, or as a revised version of the old instructions. A BCD adder typically consists of two 4-bit binary (hexadecimal~ adders and a decimal carry generator. ~o implement the special rules for the second digit, only minor changes are needed: using the field si~e to select either the decimal carry or the hexadecimal carry, and the result adjustment circuitry.
Further, while the invention can be embodied on general purposed computers, it can also be embodied on special purposed computers or other apparah~s with micro-processors, such as Point-Of-Sale machine, and so forth.

Accordingly, the scope of the invention should be determined not by the embodiments illustrated, but by the append claims and their legal equivalents.

Claims

Claims I clam:

1. A method for using 2 digit "hybrid radix" numeric fields for inputting, generating, storing, processing, and outputting year numbers ranging from 1900 to 2059 and beyond in a data processing system, comprising the steps of:
a) representing a 4 digit decimal year number with a biased 2 digit hybrid radixyear number, with the most significant digit in a predetermined radix ranging from 11 to 20, and a decimal least significant digit, and b) inputting the higher digit of a 2 digit hybrid radix year number in said radix, from an input device capable of entering 2 digit hybrid radix numbers, and storing the digit in the most significant digit position of a 2 digit numeric field in said radix, and inputting the lower digit of the number in decimal, and storing the digit in the least significant digit position of said 2 digit numeric field, and optionally b') whenever necessary, generating such a 2 digit hybrid radix year number, and storing the generated number in a 2 digit numeric field, and optionally c) whenever a computational operation is to be applied to a stored 2 digit hybrid radix number, applying said radix arithmetic rules to the most significant digit, and applying decimal arithmetic rules to the least significant digit, and c') alternatively, whenever a computational operation is to be applied to a stored 2 digit hybrid radix number, expanding the number into 3 digit decimal first, thenapplying decimal arithmetic rules to all the digits and converting the result back into 2 digit, and optionally d) outputting the stored 2 digit hybrid radix year number to an output device capable of displaying or printing 2 digit hybrid radix numbers, with the higher digit in said radix and the lower digit in decimal, and e) providing a central processor to carry out said operations.
whereby a compatibility with the 2 digit pure decimal year numbers used in the existing data files, database records, software, and user interface, can be maintained after year 1999.

2. An improved data processing machine providing functions for inputting, outputting, and computing 2 digit hybrid radix year numbers ranging from 1900 to2059 and beyond.

3. An improved input device providing function for inputting 2 digit hybrid radix year numbers, with means including circuitry and an apparatus selected from the group consisting of a keyboard, a keypad, and a pointing device, for providing conversion from predetermined user's actions, selected from the group consisting of hitting a key, hitting a combination, clicking a key, and clicking a key combination, to the transmitting of predetermined exchange codes representing 2 digit hybrid radix year numbers.

4. The device of Claim 3 is integrated together with a central processor.

5. An improved displaying device proving function for displaying 2 digit hybrid radix year numbers, with means including circuitry and structure for providing conversion from received predetermined exchange code representing the higher digit of a 2 digit hybrid radix year number in predetermined radix to a predetermined visible decimal-like pattern containing a recognizable pattern of its decimal counterpart.

6. The device of Claim 5 is integrated together with a central processor.

7. The device of Claim 5 is integrated together with an input device.

8 An improved printing device providing function for printing out 2 digit hybridradix year numbers, with means including circuitry and structure for providing conversion from received predetermined exchange code representing the higher digit of a 2 digit hybrid radix year number in predetermined radix to a predetermined visible decimal-like pattern containing a recognizable pattern of its decimal counterpart

9. The device of Claim 8 is integrated together with a central processor.

10.The device of Claim 8 is integrated together with an input device.