Kbase 18578: Summary of Progress Issues Regarding Y2K Year 2000
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/16/2008 |
|
Status: Unverified
FIX:
Progress Software Corporation has developed a Product Life Cycle document that describes the product development and technical support resources that are available during a product's life span. This document details the product stages, starting with First Customer Shipment (FCS) to eventual retirement.
Products that have been retired as of January 1, 2000, will not be tested further for Y2K issues. If issues were previously encountered in such products, all Progress customers have been advised to upgrade to a current Y2K-ready version. This policy applies to all Progress 4GL product families.
For example:
- All Version 6.x products were retired January 1, 2000.
They are therefore excluded from the list of Y2K-ready products. If you encounter a Y2K-related issue (or any other technical issue) in a Version 6.x product, you are advised to upgrade to a currently supported version of the product.
- Similarly, Version 8.2C was retired March 1, 1999.
It is excluded from the list of Y2K-ready products. If you encounter problems with Version 8.2C, you will be asked to upgrade to Version 8.3 for resolution.
Since Version 8.2C is in use by many customers, it should be added that at this time Progress does not know of any Y2K date-related issues with the version, aside from the fact that any new features for date handling that were added to
Versions 8.3 or 9.0 are missing from 8.2C.
Progress is committed to maintaining the latest information about Y2K readiness on the Y2K page at the Progress web site:
http://www.progress.com/y2k
------------------------
The following issues that might impact a Progress application in terms of Y2K. Some of these issues are not specifically Y2K-related, but they can affect date handling and they are clearly noted as such. They are included for the sake of completeness.
This list is not intended as a guarantee of product Y2K compliance. It is provided for informational purposes only. The list was updated with Versions 7.3E, 8.1B, 8.2A, and all later versions.
- AS/400 year when 1-3 digits are entered:
In the date format 99/99/9999 as used on the AS/400, when only one digit is entered into the screen for the year, all the missing digits are taken from the current year with the century taken from the -yy setting.
For example, in the date 01/01/1, the the current year should be 1991 and not 1901. This is fixed in Version 6.2D2P and later.
AS/400 date logic in Progress is as follows:
If the screen I/O is being used and less than the number of expected digits are entered for the year, the -yy setting is used to determine the century and the
rest of the digits are filled in using the current year.
For example, if the actual year is 1999 and -yy is set to 1750, and if 01/01/0 is entered for a date the result is 01/01/1790. Here, the "17" in 1790 is taken from the -yy setting (1750) and the "9" from the current year, 1999. The "0" in 1790 is taken from the "0" entered by the user.
- Report Builder and display of year 2000+ using 2 digits:
When a 2-digit format is used in Report Builder to display a year, in versions prior to 8.0A, it is not possible to display a year outside of the current century. The year is displayed as "??" unless a 4-digit format is used. This is fixed in Version 8.0A.
- ESQL/C and the -yy parameter:
In versions prior to 8.1A, ESQL/C encountered problems when -yy was set to any value other than the default. This is fixed in Version 8.1A and later. This is also fixed in Version 7.3E08 and later on MS Windows.
- -yy value and 4-digit year displays:
In many earlier Progress versions, the -yy value was ignored if you had a 4-digit display format for the year and you keyed .in only 1 or 2 digits.
This problem does not exist in Versions 7.3E, 8.2A and later. On these versions the default value of -yy (which is 1950 -- see item above) is used when you have a date display format for 4 digits for the year, but then you key in only 1 or 2 digits.
This change is also patched in the following versions, although it is important to note that the default value for -yy in all of these is 1900 and not 1950:
Platform Commercial Version Patch Version
DEC ALPHA OPEN VMS 6.2N05 6.2N14
DEC ALPHA OPEN VMS 7.3C11 7.3C13
DEC VAX OPEN VMS 6.2N05 6.2N14
DEC VAX OPEN VMS 7.3C11 7.3C13
DG/UX 88K 6.3E02 6.3E24
DG/UX 88K 7.3C01 7.3C19
DIGITAL UNIX 6.3C03 6.3C13
DOS 7.3B 7.3B21
HP-UX 8.1A 8.1A04
HP-UX 6.3F01 6.3F17
IBM AIX 8.1A 8.1A05
IBM AIX 6.3F01 6.3F19
MIPS V.4 6.3F04 6.3F11
MS WINDOWS 8.1A 8.1A04
SCO/UNIX 6.3F01 6.3F12
SCO/UNIX 8.1A 8.1A04
SEQUENT PTX 6.3F02 6.3F07
SEQUENT PTX 7.3C04 7.3C18
SUN SOLARIS 6.3F02 6.3F13
SUN SOLARIS 8.1A 8.1A04
SUN/OS 6.3F01 6.3F05
UNIX V.4 6.3F06 6.3F11
UNIX V.4 8.1A 8.1A04
This change is also documented in Progress Solution 18152, "-yy Behavior When 1 or 2 digits Used for 4-digit Year Format".
- Default for -yy startup parameter changed from 1900 to 1950:
This is changed in Versions 7.3E, 8.1B, 8.2A, and all later versions. The only platforms patched were DEC Alpha and VAC OpenVMS (in patch release 6.2N14) and Sequent PTX (in patch release 7.3C18.)
For Native 4GL on the AS/400, this change is added to Version 8.0C60. (There are no problems running client/server because the client version is used.)
- Session:year-offset added as an alternative to -yy:
This session handle attribute is added to Version 8.2A and later. It allows 4GL access to the -yy setting.
- -d ydm or -d ymd with 99/99/9999 format:
On earlier versions, when you working with -d set to ydm or ymd, Progress fails to adjust the year format properly. The year shows with 2 digits rather than 4, and the date component in the last position is displayed with 4 digits rather than 2.
For example, 11/18/97 gives 97/18/0011 instead of 1997/18/11.This is fixed in Version 8.3A and was patched in the Windows NT 32 Intel port in 8.2C07.
(This issue is not specifically related to Y2K. It applies more to general date handling in the 4GL.)
This change is also documented in Progress Solution 15941, "4-digit Year With -d ydm or ymd and Date Format 99/99/9999".
- Report Builder and -yy:
In versions prior to 8.3A the -yy setting is ignored in the Report Builder date filter. If the date 01/01/00 is specified in the filter dialog, Report Builder expands the date to 01/01/1900 regardless of the -yy setting. This is fixed in Version 8.3A.
In 8.3A and later versions, the default -yy setting for Report Builder is 1950, keeping it consistent with the rest of Progress.
- Report Builder calculated fields using dates:
Prior to Version 8.3A, ca.lculated fields using dates might not work properly if 4-digit years are used. For example, if you have three calculated fields (dd = "01", mm = "01", yy = "1996") and add them together to create a fourth calculated field where, for example, testdate = date(dd + mm + yy), the result is "?". This problem is fixed in Version 8.3A and later.
(This issue is not specific to Y2K readiness but applies more to general date handling in Report Builder.)
- Startup parameter -yr4def added:
A new startup parameter called -yr4def is added to Version 9.0A to ensure that when the Data Dictionary dumps date fields, the fields are dumped with a 4-digit format for the year (as opposed to 2, that occurs if the date range you export falls within the -yy range).
This startup has the same effect on the 4GL functions MESSAGE, EXPORT, and PUT UNFORMATTED.
- PROMON and -yy:
On versions prior to 9.0A, the Database Status screen in the PROMON utility might display years after 1999 incorrectly. This is fixed in Version 9.0A and later.
----------------------
Y2K issues in other products include the following:
- Roundtable and Y2K:
You should contact the Starbase Corporation directly concerning Starbase products and the year 2000. These products include Roundtable and Roundtable Lite. Progress is unable to provide Y2K information for Starbase products.
- Actuate and Y2K:
You should contact Actuate Corporation directly concerning their products and the year 2000. This includes Actuate Versions 2.x and 3.x. Progress is unable to provide Y2K information for Actuate products.
- Known MS-Windows problem when system date reaches 2038:
Due to the 32-bit nature of the MS Windows platform, the C runtime function
time() reaches its maximum date of January 18, 2038 at 19:14:07 (2^31 or 2,147,483,648 seconds from January 1, 1970, 00:00:00.)
This problem prevents Progress Versions 8.3A, 9.0A, and later from starting when the current system date equals or exceeds this limit.
On earlier Progress versions, a GPF results. A fix in Progress is dependent on a fix from Microsoft. A Microsoft knowledgebase article (Q125494) discusses this issue from Microsoft's perspective. It is likely that future migration of MS-Windows to 64-bit (or better) machines will remedy the problem.
This problem is also documented in Progress Solution 18458, "MS-Windows Problem When System Date Reaches Year 2038"..