IBM Power Ideas Portal
This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
If the system does not change to support 2040, this will be like the change for 2000.
We have DDS files that have *DMY format. Some of these fields are expiry dates, and therefore the problem is real for us. Not in 20 years. Now!
These applications were written pre-Y2K. IBM has always promised that in AS400 world, you can write and RPG program once and run it for decades, and has always fulfilled this promise. But if the *DMY field type is limited to 2039 permanently, then the promise is broken. The amount of effort to modify this is monumental, and may result in simply getting rid of the AS400 and looking for a new ERP
sadly, by the year 2040, the AS/400 will gone and forgotten...
Since this request was opened against "Languages - RPG", only the RPG programming aspect of this request is being considered. Separate RFEs should be opened for the issues with SQL and display files.
IBM does not intend to provide a solution to this request at this time, so it is being closed. If IBM did provide a solution for this within the RPG language, it would probably be in the form of a new built-in function, or a new parameter for an existing built-in function, and RPG programmers would have to modify their source. Since RPG programmers would already be modifying their source, programmers could write their own procedures to return a 6-digit numeric value in MDY or YMD or DMY form.
For example
dcl-proc mdy_num export;
dcl-pi *n packed(6);
theDate date(*iso) const;
end-pi;
dcl-ds *n;
iso_date date(*iso);
yy zoned(2) overlay(iso_date : 3);
mm zoned(2) overlay(iso_date : 6);
dd zoned(2) overlay(iso_date : 9);
end-ds;
dcl-s date6 packed(6);
iso_date = theDate;
date6 = mm * 10000 + dd * 100 + yy;
return date6;
end-proc;
Matt_Tyler , it is not so simple. If a program does Input from a table to a screen and from the screen back to a DB Table, the result will become corrupted.
Example: Date 2041-01-01 is brought from DB table to screen, it becomes 01/01/41 . when the used odes not do any change to the date, and the program update the DB based on what is on the screen, it becomes 1941-01-01.
The solution is to have an edit code, and use just 8 digit date. the edit code will be only on the screen, but in this case it will be an edit code of ouput only and witho
but any option for the user to change it.
Frankly IBM needs to allow for century truncation without errors and just let us go from 10 character date to 8 without worry. I do need to use 8 character dates on screen when there is not enough room for everything. I just don't want to have to constantly code a monitor then do the truncation in my code.
Lochi1991 wrote: "The "solution" to change the comparer from 40 to 80 would be a solution for the next 40 Years".
It's not a bullet proof solution. If for any reason there is any historic data from 1960 or even non-historica data like birth day etc., it will suddenly get conveted to 2060 and give wrong results! IBM I which has a high reputation of stability, cannot afford to go that way.
The least IBM should do is to add a compile option, that checks any statments in the program that refer to 6 digits dates, and not let to compile.
This will give a tool for programmers to start cleaning the code towards year 2040.
There is still a problem, sometimes there is not enough room on the screen to display an 8 digit date, and therefore a 6 digits date is used to display the only 6 digit of the date. I would suggest an edit code or edit word that does it. (Maybe *MDY for a date in foramt mm/dd/yy etc).
If that is done, maybe one more type of edit word: *MD to dispaly just the month and day. Behind the scenes, like in every edit word or edit code will be the real 8 digit date. This may give also a date edit code for Timestamps to dispaly only the date portion of the time stamp, or the opposite: to display only the time portion of a timestamp.
In my first Company we compared the year lower 80 then it's 20. centuary, otherweise 19. centuary. Maybe IBM should change the Limit of 40. I don't think, that most user have Data from 1940. With time comes that the Problem with 2040 will increase. The "solution" to change the comparer from 40 to 80 would be a solution for the next 40 Years. :-)