AREV, DOS & Y2K (AREV Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== AREV, DOS & Y2K (AREV Specific) ====
=== At 30 AUG 1999 01:35:41PM Maggie Woo wrote: ===
 
{{tag>"AREV Specific"}}
 
<QUOTE>
Hello All,



I have a client who wants to know how it's possible that AREV is Y2K compliant if it runs in DOS.  Apparently, the word is, if it is a DOS application, it can't be Y2K compliant.  Is there a statement that describes the relationship between DOS Y2K non-compliancy and AREV Y2K compliancy?



Their effort is aimed at removing anything on their servers that is not Y2K compliant (regardless of whether it has potential to harm or in any way affect other network resources).



TIA,



Maggie Woo

mwoo@tnc.org
</QUOTE>
----

=== At 30 AUG 1999 04:26PM steveD wrote:  ===

<QUOTE>Maggie:

First, Revtech has posted ARev-specific Y2K info on this site. However, what your colleagues are no doubt concerned with is (a) DOS itself and/or (b) the BIOS on the workstations where ARev executes. Look to Microsft's site for DOS version-specific Y2K info. Only the BIOS and/or workstation manufacturer can tell if you fi the BIOs on your workstations is Y2K compliant. At the end of the day, ARev can only process what the machine (e.g. workstation) hjands it, so whgile your *application* may be 100% compliant, your hardware may not.



That being said, it is absolutely possible to have a Y2K ready DOS ARev application, especially when running on modern hardware and newer releases of Win95/Win98.  The proof is in the testing!

</QUOTE>

----

=== At 30 AUG 1999 04:49PM Maggie wrote:  ===

<QUOTE>Thanks!

</QUOTE>

----

=== At 30 AUG 1999 05:25PM Steve Smith wrote:  ===

<QUOTE>AREV asks DOS for the date, DOS asks the BIOS, and the BIOS asks the RTC (real-time-clock). The DATE() (returning DOS system date) and DIR() functions (returning file time date stamp) are the only potential problem candidates on this basis.



I'd be very surprised if you had any Y2K dramas in AREV courtesy of DOS. 



Ensure your AREV Y2K audit checks for both DATE() and DIR() usage.



Steve

</QUOTE>

----

=== At 30 AUG 1999 07:02PM Capt'n Kirk wrote:  ===

<QUOTE>]Their effort is aimed at removing anything on their servers that is ]not Y2K compliant (regardless of whether it has potential to harm or ]in any way affect other network resources).



So then, to this way of thinking, if the Lunch Room has an automatic coffee maker that is not Y2K they will close the Lunch Room down?

</QUOTE>

----

=== At 31 AUG 1999 11:38AM Tom Ayers wrote:  ===

<QUOTE>Although Dos has a few Y2K issues in a few areas, you can always get the date from dos in four digit form, regardless of any settings (Windows is just a prettier version of dos).  Int 21 function 2a returns the date in the registers, with the CX register containing the full four digit year.  It has a range from 1980 through 2099.  This has been in place since Dos 1.00.



You may have a problem with the RTC or BIOS however.  These problems 

are specific to the motherboard of the computer you are running on.  If it gives DOS the wrong date, DOS will feed the wrong date to AREV.



Of course if you had this problem, Windows would also have the wrong date.



Hope this helps,

Tom Ayers

</QUOTE>

----

=== At 31 AUG 1999 02:08PM Victor Engel wrote:  ===

<QUOTE>... and TIMEDATE()?

</QUOTE>

----

=== At 31 AUG 1999 02:18PM Chicken Little wrote:  ===

<QUOTE>"Is there a statement that describes the relationship between DOS Y2K non-compliancy and AREV Y2K compliancy?"



How about, "The sky is falling!"

</QUOTE>

----

=== At 31 AUG 1999 03:47PM Eric Emu wrote:  ===

<QUOTE>The ground is rising, the ground is rising.



</QUOTE>

----

=== At 31 AUG 1999 03:50PM Steve Smith wrote:  ===

<QUOTE>And timedate(), although as this is more frequently used for time date stamps, it's probably of less concern. ICONV and klutzy datediff routines will be the major Y2K culprits. Then faulty RTCs.



Steve

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=0F7D63F9C94DFBFD852567DD0060A6B6|View this thread on the  forum...]]