Re: anyone else have anything blow up from 2013?
From: Mark D Powell <Mark.Powell2_at_hp.com>
Date: Tue, 15 Jan 2013 06:20:58 -0800 (PST)
Message-ID: <bafcd673-c3e1-488f-9c6e-12cd40ef8941_at_googlegroups.com>
On Monday, January 14, 2013 6:28:50 PM UTC-5, John Hurley wrote:
> Minor small application had a table with a DATE column but using it ( via views to cobol ... obviously cobol cannot deal with Oracle DATE column types ) as CHAR(6) field and thinking of it as YYYYMM ... Oracle had triggers on views viewing the field as RRMMDD and doing some translation back and forth ( TO_DATE and TO_CHAR obviously along with NVL and defaults ). It all worked ( feeding in data like '201212' and '200907' and getting back same data until we rolled into 2013. App blew up feeding in 201301 ( year 2020 month 13 day 01 ) ... looking at quick change back to CHAR(6) from DATE column definition. No thanks but I had no hand in designing it ... just a time bomb waiting for a 13 Month ...
Date: Tue, 15 Jan 2013 06:20:58 -0800 (PST)
Message-ID: <bafcd673-c3e1-488f-9c6e-12cd40ef8941_at_googlegroups.com>
On Monday, January 14, 2013 6:28:50 PM UTC-5, John Hurley wrote:
> Minor small application had a table with a DATE column but using it ( via views to cobol ... obviously cobol cannot deal with Oracle DATE column types ) as CHAR(6) field and thinking of it as YYYYMM ... Oracle had triggers on views viewing the field as RRMMDD and doing some translation back and forth ( TO_DATE and TO_CHAR obviously along with NVL and defaults ). It all worked ( feeding in data like '201212' and '200907' and getting back same data until we rolled into 2013. App blew up feeding in 201301 ( year 2020 month 13 day 01 ) ... looking at quick change back to CHAR(6) from DATE column definition. No thanks but I had no hand in designing it ... just a time bomb waiting for a 13 Month ...
John, it has been years since I worked on a COBOL program and I do not remember COBOL having a native date data type. We had a couple of date formatting and manipulation sub-programs that we used to format and calculate past/future dates. It would seem that your issue is really a conversion logic issue rather than an Oracle or COBOL issue.
HTH -- Mark D Powell -- Received on Tue Jan 15 2013 - 15:20:58 CET