OraApps-2000 list
Date: Thu, 4 Mar 1999 16:52:45 -0500 (EST)
From: Francois Gendron
Subject: ADMIN - Y2K Related postings.
All, Just a reminder that Y2K related postings should not be sent to the OraApps-L list
but rather to the OraApps-2000 list. Please ensure that all futur postings are sent to the
OraApps-2000 list. To subscribe to the OraApps-2000 list, send:
To: listproc@cpa.qc.ca
Subject: (No subject)
SUBSCRIBE OraApps-2000 Your real name
(No signature)
Thanks, -- François Gendron Oracle Applications Advisor Champagne, Parent & Associés
Inc. Tél: (514) 942-6287 Fax: (450) 651-7375
Oracle 7.3.3.5 and Application 10.7.
Date: Mon, 29 Mar 1999 07:50:09 -0800 (PST)
From: Dominique Bertrand dbertrand@yahoo.com
Subject: Y2K
Hi all I have Oracle 7.3.3.5 and Application 10.7.
I want to know if this oracle version is Y2K compliant, because in november 1998 a Oracle
white paper said all version since 7.1 was fully compliant and know Oracle white paper
said just since 7.3.4 .
Anibody can i explain me Any help will be appreciated tanks Dominique
Date: Mon, 29 Mar 1999 10:57:04 -0500
From: "Cotten, Jim" Jim.Cotten@respironics.com
Subject: RE: Y2K
With the patches it might be. You still have to test to ensure that your use of the system
will not have problems in Y2K
Date: Tue, 30 Mar 1999 08:34:22 +1000
From: "Bevin Watson"bevin.watson@abs.gov.au
Cc: dbertrand@yahoo.com
Subject: Y2K
It may be compliant, but not supported which effectively means not compliant. You need to
get your database to 7.3.4. You also need to apply the server side patches to get you to,
basically, prod 16.1. There is a list of these on metalink.
Date: Tue, 30 Mar 1999 10:07:32 +1000
From: Schwerdt Mark
Subject: RE: Y2K
The latest Y2K White Paper (v4.1.0.0.16, March 12 1999) states on p 29
"In Oracle 7.0 thru 7.3.3, Cumulative Exports may not include the correct tables for
the first cumulative export in the year 2000. The bug number for this error is 778615. In
addition, some V$ tables have VARCHAR2 columns which include date related information. eg
V$LOG.FIRST_TIME V$LOG_HISTORY.TIME. This does not cause any operational problems but may
affect any scripts which use information in these views. Refer to tech supprt bulletin for
bug number 817753 for workaround information."
So, even if you are prepared to risk not doing the database upgrade prior to 1/1/2000, you
may get some unexpected results from your backup processes if you are not on 7.3.4 by
then, if you are using cumulative exports.
thanks Mark Schwerdt Frontline Consulting (currently at City of Melbourne)
DateMon, 29 Mar 1999 22:31:04 -0600
From"Jim Basler" jim_basler@intervoice.com
SubjectReY2K
Although 10.7 is "compliant" there are oversights that have to be dealt with.
Much like a car manufacturer may pass the NTSA , there are sometimes oversights that cause
a manufacturer to have to recall a portion of their product. That is how I characterize
the patch set that Oracle has for their Applications (10.7). There are some very important
things that were overlooked the first time around.
Be sure to apply these BEFORE your fiscal Year 2000. With GL this is particularaly
important.
Date: Tue, 30 Mar 1999 01:05:53 -0800 (PST)
From: david solomon david_solomon_uk@yahoo.com
Subject: Re: Y2K
Dominique, Initially, Oracle are saying that the white paper does not include versions
prior to 7.3.4 is because they thought these old versions are not supported; but actually
they are. Oracle are saying were are almost certain that 7.3.2 and above are compliant. I
will update you when I get a full confirmation on this hopefully today.
Regards David
Date Format
Date: Mon, 12 Apr 1999 13:13:15 -0300
From: Melanie Perry Melanie.Perry@moncton.org
Subject: RE: Date Format ( DD/MM/YY)
Hi there
I have done much research on this subject and I have pretty much summed up this Y2K date
problem :
set NLS_DATE_FORMAT (in the init.ora file) at the server level to
DD-MON-YYYY
Will NOT covert the century based on the 2-digit year you enter, it uses the current
century as the default
ie 01-JAN-33 will store 01-JAN-1933 (if done today)
01-JAN-99 will store 01-JAN-1999 (if done today)
01-JAN-00 will store 01-JAN-1900 (if done today)
01-JAN-1933 will store 01-JAN-1933
01-JAN-1999 will store 01-JAN-1999
01-JAN-2000 will store 01-JAN-2000
DD-MON-RRRR
WILL convert the century based a formula from Oracle
- Years 00-49 will store a century as 20
- Years 50-99 will store a century as 19
ie 01-JAN-33 will store 01-JAN-2033 (if done today)
01-JAN-99 will store 01-JAN-1999 (if done today)
01-JAN-00 will store 01-JAN-2000 (if done today)
01-JAN-1933 will store 01-JAN-1933
01-JAN-1999 will store 01-JAN-1999
01-JAN-2000 will store 01-JAN-2000
Also, take note, you must change this in the REGISRTY also on everyones PC or it will not
be 100% compliant.
Basically, if you have a ORACLE FORMS screen that does NOT have the century, then this is
the only situation where you must take the above into consideration. Whenever the Century
is supplied, then the database stores that value...it never over-writes or converts an
entered value. It will, however, convert a date if the century is NOT specified.
Melanie Perry SSA \ DBA The City of Moncton Moncton, NB Canada
AP and Y2K
Date: Thu, 15 Apr 1999 15:12:00 EDT
From: RBoren7458@aol.com
Subject: Re: AP Patch Set Q, Y2k
Just an FYI: patch 727560 will not make you totally y2k . ref note 69549.1 posted today
under "Y2K and Date Related Issues"
Character Cumulative patch 727560
Since patch 727560 was made available, two additional issues have been identified.
Bug# 567627 - Character Only: If you enter an expense report week ending date with the
format of MMDDYY after the year 2000 (example: 011500), you get an error message and
cannot proceed with the entry. (Note that there is a workaround for this issue. You can
use a date format of DD-MON-YY and it will work correctly).
Bug# 531151 - If you submit Batch Approval and leave the "End Invoice Date"
parameter blank, then Payables does not select invoices for approval which have an invoice
date 31-DEC-1999. (Note that there is a workaround for this issue. You can submit Approval
with a specific "End Invoice Date& quot; parameter value in the year 2000 and the
program will work correctly).
The fixes for both of these issues are available as one- off patches under the bug
numbers. Or you can apply Patch Set Q which includes the fixes for these issues.
Date: Thu, 15 Apr 1999 16:55:54 -0400
From: Denise Sanders DeniseS@benjerry.com
Subject: RE: AP Patch Set Q, Y2k and the Update Payment Schedule form
I applied patch 853344 which solved all my Update Payment Schedule problems introduced
with Patchset Q.
Y2K compliant Oracle products
Date: Thu, 22 Apr 1999 09:41:29 -0500
From: Alan Hyland alan_hyland@saan.ca
Subject: Re: Y2K compliant Oracle products
To get Oracle's latest declaration of what products are Y2k compliant, take a look at this
white paper:
http://www.oracle.com/year2000/2000/white2000.pdf
The document above states that Oracle 7.3.4 and greater is Y2k compliant. The previous
version of Oracle's Year 2000 Compliance White paper stated that Oracle 7.1 and greater is
Y2k compliant. In the latest version, Oracle calls anything below 7.3.4
"desupported", which means either not currently supported through Oraclemetals
or will not be supported past December 31,1999. In other words, lower versions than 7.3.4
may be Y2k compliant, but if there's a problem on Jan.1,2000, don't expect help from
Oracle. Sounds like a little CYA going on here.
Oracle was also offering free upgrades to supported versions, look at the news release for
more details: (the offer ends Apr.30/99)
http://www.oraclecanada.com/virtualpress/releases/990225_Upgrade2000.htm
Patches and Y2K
"Tayyab, Arshia" Arshia.Tayyab@fluke.com 07/07 12:53 PM
1. We are analyzing the need of Oracle Y2k testing? Can some one give me example of why it
is necessary to do Y2K testing for Oracle? Our management is NOT convinced that we need to
test Oracle because Oracle says "they are compliant".I am interested in specific
examples and scenarios from the industry. Thanks, Arshi Project Manager Fluke 425-356-6379
From: Deborah Linke [mailto:LINKE@wapa.gov]
Sent: Thursday, July 08, 1999 10:47 AM
Subject: Re: Oracle Y2k Testing
Oracle requires a certain patch level to be Y2k compliant. The list of patches can be
found on Metalink. If you have not applied all of these patches, you may have problems. In
addition, Oracle continues to update the patch lists.
We had patched to their recommended level and still found that we had three or four little
problems that showed up during testing. If you have done any extensions or enhancements,
that alone is a good reason to test Y2k compliance.
Deborah M. Linke
Western Area Power Administration
303-275-1618
Date: Fri, 09 Jul 1999 08:46:10 -0400
From: "Dawn M. Duvall" dduvall@mitretek.org
Subject: RE: Oracle Y2k Testing
Regarding the current patches required for Projects compliance, I received an e-mail from
Melanie Bock via another forum that indicated the current metalink information for
Projects is obsolete. The current information is that there are three additional bugs:
849531, 865757, and 875281. These are in Patchset J (855491/855493) which is available on
metalink. 728732 still doesn't appear to be included in any patchset. 865757 is available
as a one-off on Patchset F. 849531 is available as a one-off, dependent on Patchset G.
875281 is only available in Patchset J. PTE has patch 410821. As of today, there are no
Y2K bugs being worked in Patchset K or in the "top ten" list.
Hope this helps.
Dawn Duvall
Mitretek Systems
Deborah, Can you please elaborate on the three or four little problems you've
encountered? Just curious if they might be issues we should look into. We are up on all of
the latest 'Y2K' patches for our modules in 10.7, with the exception of OE and INV. Any
information would be great.
Thanks, Kristie
LINKE@wapa.gov on 07/08/99 05:49:24 PM
cc: (bcc: Betty Petro/KIS/Kodak/US)
Subject: Re: RE: Oracle Y2k Testing
The FA to Project Accounting Interface errored out because of date error, not sure that
it's Y2k related. Lockbox report in AR prints with wrong date, but correct date shows in
the system. AP Late Payment and Payment Due Date Reprots have the wrong Fiscal Year.
kbrown@es.com 07/08 10:58 AM
Date: Fri, 9 Jul 1999 10:17:45 -0400
From: Betty.Petro@dankasi.com
Subject: Re: RE: Oracle Y2k Testing
Deborah,
What are the actual names of the reports in Payables that you are referencing below? I ran
all the Payables reports, the only problem I ran into was the 1099 Payments report which
errored out.
Also, Metalink states that there is a problem with the Cash Requirment report and requires
patch # 812177. They say the report errors out when a pay through date in the year 2000 is
entered. We have not applied this patch yet. The interesting this is that when I run the
Cash Requirement report with a pay through date in the year 2000 it runs fine. Has anyone
had a similar experience?
Thanks Betty Petro
Date: Fri, 09 Jul 1999 16:37:49 -0600
From: "Deborah Linke" LINKE@wapa.gov
Subject: Re: RE: Oracle Y2k Testing
The Due Date Calculation Report.
Date: Fri, 09 Jul 1999 16:29:38 -0600
From: "Deborah Linke" LINKE@wapa.gov
To: Scott_Van_Bebber@ccmail.sgo.sony.com, oraapps-l@cpa.qc.ca
Subject: Re: RE: Oracle Y2k Testing
Sure The FA to Project Accounting Interface errored out because of date error, not sure
that it's Y2k related. Lockbox report in AR prints with wrong date, but correct date shows
in the system. AP Payment Due Date Calculation Report has the wrong Fiscal Year.
Deborah M. Linke
Western Area Power Administration
303-275-1618
Metalink for list of all Y2K patches
Date: Fri, 09 Jul 1999 11:44:37 PDT
From: "J P Bhamu" jpbhamu@hotmail.com
Subject: ftp site?? Metalink
Hi Friends,
I was looking at the Metalink site for all the patches for Y2k compliance for my 10.7 NCA
version of applications. But could not find a comprehensive list/excel sheet which
mentions every patch which is supposed to be applied for the Y2k complaince.
I am logging to version 2.0 of the Metalink. Any help will be greatly appreciated.
thanks in advance. jp bhamu
Date: Fri, 9 Jul 1999 12:35:47 -0700
From: Karen Blackwell KBlackwell@rockshox.com
Subject: RE: ftp site?? Metalink
I cannot find this on Metalink 2.0 also. But it is on 1.7. Try this link to get to the
appropriate web page:
http://support.oracle.com/metalink/index.html
If not, then log into Metalink 1.7, and click over to the Y2000 pages they have listed.
Good luck!
FYI
Karen Blackwell
DBA/SA
RockShox, Inc.
Y2K testing process
Date: Mon, 2 Aug 1999 00:56:58 -0700
From: Wendy Low wlow@coretec.com
Cc: "'wlow@coretec.com'" wlow@coretec.com
Subject: Y2K Testing
Hi to all Oracle experts,
We are preparing Y2K testing for 10.7NCA (GL, AP, AR, FA, PA). Our approach is to test
several critical dates, ex: 12/31/99, 01/01/00, 01/03/00..., using one week to test each
important date in all modules. Thru out the first week, we'll test 12/31/99 w/all the
modules at the same time and the second week, testing 01/01/00 and so forth. One reason of
using one week time frame for each date is other than testing Oracle apps, there are many
custom programs and interfaces that also needed to be tested.
Questions:
1. DBAs brought up the possible problems in backdating system date- Ex: The first day of
first week testing, we'll set system clock/date to be 12/31/99. But since the clock
continues, on the second day of testing, it will become 01/01/00. Since we are still
testing for 12/31/99 in the first week, we have to set the clock as 12/31/99 again. DBA
suggested possible problems w/that, like database might have problems to be brought up.
But we talked to Oracle and they said, for most cases, it's fine. There might be more
problems to bring dates forward than backward. Other inputs?!
2. Since it's only August right now, should we physically close all the months between now
and Nov before we start testing in all modules or does it not matter?! (start testing for
12/31/99 and close that month w/the previous months open?!)
Please advice and all early replies are greatly appreciated.
Wendy
Date: Mon, 02 Aug 1999 09:30:12 -0400
From: "Dawn M. Duvall" dduvall@mitretek.org
Subject: RE: Y2K Testing
Wendy,
We haven't had any problems with setting the dates forward (databases are shut down and
system is rebooted for each date change). We did have a problem with redo logs out of sync
when we tried to set the date backwards. I think GL requires that all periods be opened in
order; I know PA doesn't care; I am not sure about all the others.
Hope this helps. Dawn
Date: Mon, 2 Aug 1999 08:45:07 -0500
From: "Robertson, Cassandra F." cfrobert@southernco.com
Subject: RE: Y2K Testing
Wendy,
We did not have a problem with moving dates forward. I did read somewhere that it was not
suggested once dates were moved forward to move them back again. We tested each date with
no problem with restarting the database with the dates. And we did not have to close any
months before testing either.
Hope this helps.
Be Blessed!!!
Cassandra Robertson
Southern LINC - CIS Operations
(desk) 678-443-1619
(LINC) 770-550-0484 PRVT ID. 4484
* cfrobert@southernco.com
Date: Mon, 2 Aug 1999 09:59:28 -0400
From: "Lau, Gabby" gLau@wssc.dst.md.us
Subject: RE: Y2K Testing
Some points to consider:
* Are you going to test for 2/29/2000? Just that it is a leap year and to make sure the
system does not have any problem.
* You should never leave a previous month open if you are closing a following month. You
need to close the months in between.
* Why turn the system clock to 12/31/99. Why not simulate what would actually happen and
turn the clock to say 12/28/99 and let it roll over to 1/1/00?
Gabby
Date: Mon, 2 Aug 1999 22:50:14 +0530
From: "Mehra, Varun (CAP, GECSI)" Varun.Mehra@geind.GE.com
Subject: RE: Y2K Testing
Wendy/Everyone
We at GE Capital have recently finished an intensive Y2K compliance testing exercise. We
are live on AP, GL, FA and AR Rel 10.7 16.1 Prodn SC, each packed with their own custom
programs and reports. We run our Apps on HP-UX 10.20. During the test we were constantly
in touch with both Oracle and HP. The issue here for the test on our site was to test for
ten (10) sensitive dates and since we are a sigma-six driven organisation, this entailed
the exercise to include every minute detail. So what are the learnings out of this
marathon exercise that lasted well within a week -
1. There are no problems in taking the system date forward and then getting it backward.
2. The Application modules have to be tested for their functionality as on the sensitive
date.
3. We created a special calendar and a special set-of-book and tested each date sensitive
portion of Apps functionality, complete with our custom programs and report outputs.
4. This also included exporting data to a spreadsheet and printing cheques on a dummy
stationary series.
5. We tested for Sept 09, 1999, Dec 31, 1999, Jan 01, 2000, Feb 28, 2000, Feb 29, 2000,
Mar 01, 2000, Feb 27, 2001, Mar 01, 2001, Dec 31, 2034 and Jan 01, 2035. And we brought
the system back to June 1999.
These were however preceded by a backup exercise to the minute of the root, finroot,
appl_top, oracle and databases.
Hope these experiene help. These worked for us. Best wishes to you.
Varun Mehra
Manager-Systems
GE Capital India
Date: Mon, 02 Aug 1999 11:01:41 -0700
From: "sean smith" kiowasean@zdnetmail.com
Subject: RE: Y2K Testing
We also just completed our Y2k compliance testing. The comments below (above) sum up
pretty well what we discovered. However, one thing we learned was that you must allow
considerable time to roll forward FA. Since each months depreciation must be run
sequentially, for each book (Corp, Federal Tax etc.) you must allow about a week (depends
on how many tax books you have) for this exercise.
Also, I concur that rolling the date forward was no problem, but rolling back is really
not an option. So plan on setting the date to 12/25 or something and running your tests
for 12/31 over the course of a few days. We even had a little Christmas party when the
clock was set to 12/25.
Date: Mon, 2 Aug 1999 14:14:31 -0400
From: "McElhinny, Steve A." Steve.McElhinny@alcoa.com
Cc: "Lacy, Mike J." Mike.Lacy@alcoa.com,
Subject: RE: Y2K Testing
Gentlemen -
I'm seeing opposing answers to the same question "Can I move my dates backwards after
rolling them forwards".
We completed 10.7 char testing June 1998 (INV, OE, PO, WIP, BOM), but now we're moving to
10.7 NCA, and planned on performing some Y2K testing along with full functionality
testing. If we so desire, would we be able to roll the clock forward through a series of
dates, then set it back to current date? Or would we be better off restoring the server
from a full backup once we've completed all of our testing?
Steve McElhinny Steve.McElhinny@alcoa.com
Date: Mon, 02 Aug 1999 11:22:32 -0700
From: "sean smith" kiowasean@zdnetmail.com
Subject: RE: Y2K Testing
We didn't actually try to roll the date back, we restored from backups. However,
logically, I would think rolling the date back would have some problems. Many forms only
allow you to enter a date equal to or greater than the sys_date. What if you update a
record with a date of 12/29/99 and then roll back you system date to 8/31/99. It seems to
me that would be asking for trouble. Plus what's the point of "testing" a date
rollback. I can't think of any reason one would ever do that.
Date: Mon, 02 Aug 1999 15:19:39 -0400
From: "Dawn M. Duvall" dduvall@mitretek.org
Subject: RE: Y2K testing
The problem we did encounter in trying to roll the clock back was as follows: Usually
between each series of tests when we want to go back to a previous date, we restore from a
backup of that date and reset the clock. During the latest restore, ops decided they
wanted to set the clock at a different point from that at which the backup was taken, and
they could not bring up one of the instances (the Peoplesoft instance) because the redo
logs timestamps did not match the database file timestamps. It is processes like archive
logging with validation/ synchronization that depends on system timestamps that make
rolling the clock back a risky situation.
Dawn