Is 2E impacted by the 2020 Computer Bug (Y2020 Bug)?

Products

• CA 2E

Issue/Introduction

Is 2E impacted by the 2020 Computer Bug (Y2020 Bug)?

Environment

2E

Cause

Programmers wanting to avoid the Y2K bug had two broad options: entirely rewrite their code or adopt a quick fix called “windowing”, which would treat all dates from 00 to 20, as from the 2000s, rather than the 1900s.  An estimated 80% of computers fixed in 1999 used the quicker, cheaper option.  

Resolution

Non-screen 2E functions, 2E Built-in functions related to Date data type, Any 2E generated Date fields and Generated database file's date fields by 2E are free from any kind of Y2K/Y2020 related date bugs. Because the 2E date-related data types DT#, D8#, DTE, TS# contain either a full year or at least contains century. So, 2E date related builtin functions like *DATE INCREMENT,*DURATION will not follow the windowing approach. Hence all these are free from any kind of Y2K/Y2020 related date bugs.   

However, 2E Screen functions (EDTFIL, DSPFIL, PMTRCD, etc..) will follow the concept of the external and internal field while dealing with date data types.  For any of 2E date data types(with Edit Code = 'Y'), 2E will show only 6 digit external date on the screen. So as part of the conversion from 6 digits displayed external format to actual internal date format it will use windowing approach based on cut-off year mentioned in the Y2CTOFF data area of the run time library (FYI - YCUTOFF model value and Y2CTOFF data area are interrelated). It will Retrieve the 'cut-off' year YY from the data area. So valid and possible years are the window of 100 (i.e from 19YY to 1999 and again from 2000 to 20(YY-1)).
For example, if the data area value set to 1950 then it will have a window of 100 years such as from 1950 to 1999 and again from 2000 to 2049.

As it supports the only window of 100 years to show on-screen (in case of Screen function w/ 2-digit year input/output with Edit Code = 'Y'), it is always good to analyze the end customer database value and find the oldest year.  Let us say 19XX and then put that value in YCUTOFF model value and most importantly Y2CTOFF data area value in run time library such that we will cover most of the years (i.e from 19XX to 1999 and again from 2000 to 20(XX-1)).

Note: For now, there is no Y2K/Y2020 kind of bug for the 2E screen except you configured the Y2CTOFF with 1920 and using the Screen function w/ 2-digit year input/output with Edit Code = 'Y'. That means it will work without any issue until the Y2CTOFF data area value (i.e if the data area configured as 19YY then it will work without any issue until 20(YY-1) even though we used the Screen function w/ 2-digit year input/output with Edit Code = 'Y').

As we know, because of this "Screen function w/ 2-digit year input/output with Edit Code = 'Y'" displaying only 6 digit date format irrespective of any date data type indirectly it is putting the restriction on storage of the date in the database (even though it capable of store more years as it has 7 lengths (CYYMMDD) or 8 length date(YYYYMMDD)) while inserting data. 

Recommendations:

1.  From the above analysis, it is suggested to use the Edit Code '/' for date fields if possible on the screen functions so that it will show the full 4 digit year and hence total cut-off/100 years windowing logic will be gone and hence it will work a lot more than a window of 100 years.

2.  If you still want to use the Screen function w/ 2-digit year input/output with Edit Code = 'Y', then please configure the Y2CTOFF data area in run time library wisely as per the end customer database such that to use the whole 100 years.