We need to know if the RevG development system and runtimes are Y2K compliant. We know this goes way back, however, we will have several customers that will still be in RevG into the year 2000.

We know that the Julian dates will be fine. Are there any other parts to the software that will have issues?

Someone in the OI forum said that there are third-party patches to the RevG ICONV routine. Anyone have the patch?

Please check our web page at URL:

http://www.ts.co.nz/~finsol/scan.htm

There are still vendors of Revelation and Advanced Revelation packages who claim that because their development environment is Year 2000 compliant, therefore the software developed in Revelation will also be Year 2000 compliant.

Unfortunately this will not be the case. There are still many Revelation software packages which will fail to work correctly in the Year 2000 and many that could fail well before then. Although it is tempting to put it off and fix it when there are problems, your should be aware of the risks in doing so.

Our web site lists examples of the types of problems that can occur - these maybe quite surprising to many users of Revelation.

We are offering Revelation Year 2000 audit software free to:

- small to medium sized applications

- non-profit organisations

Many of the larger companies have recognised the need to audit their software but I am concerned that not many of the smaller companies recognise this. Very few have taken us up on our free offer of software. Our software will assist immensely in ensuring a thorough audit is done and will also save at least 80% of the involved - possibly more. At the very least, do ensure that you get a free copy of our Revealtion & Y2K manual - please email me for this.

Time is running out and I encourage you to do an audit of not only your Revelation software but all software, hardware and any device that is reliant on embedded systems. This is vital in ensuring the future viability of your organisation and that of any clients whom you support.

There is a vast amount of information available on the internet on this subject. I have been working actively in the area of Year 2000 problem awareness over the past few months and have had articles published on the subject. These are written from a programmer's perspective of the problem and can be accessed at:

at URL:

http://www.ts.co.nz/~finsol/y2k_articles.htm

Jocelyn Amon

I don't know that Rev internal date format could be called 'Julian'.

I take this to mean the relative day number of the year - so such a date would be expressed YYDDD. (ie today is 98308)

'Pickian' date is the day number relative to Gregorian date 01/01/1967. (today is 11282).

We have a modified ICONV (RTP26) that makes it smarter and easier for our applications - it might not suit everyone. If you would like to try it. post your Email address and I will send a copy.

I would be interested in oconv fix for g2b. I was contacted

by two different companies that plan to continue to use g2b

into 2000+

Thanks, Rich

[email protected]

Please send it to [email protected]

Thanks

I'd really like a copy too, Chris. I have all this legacy REV G2B code to support and I'd be appreciative of any help you can offer. I was thinking of replacing the date ICONVs/OCONVs here just the other day for our Y2K compliance efforts - the routines which I support leave a lot to be desired.

Steve

[email protected]

On 11/19 Chris Vaughn mentioned he had a fix for the g2 problem

with iconv. Chris I would very much like a copy.

my system shows

1.1.1 as 01-01-2001 & 1.1.01 as 01-01-0001

thru

1.1.9 as 01-01-2009 & 1.1.09 as 10-10-0009

my email address is [email protected]

Also it appears that I am missing the recover.link program

for g2b if anyone has a copy of it.

Question for Revelation, is Revelation going to isssue their

own correction for the Iconv problem in G2b

Hi Chris,

I too have isolated the Revg Y2K issue to the ICONV program in that if the years 0-29 are entered as such it converts to the internal date properly, however, if 00 01 02 - 09 are entered or intercepted via a system default date instead of 0 1 2 - 9, it does not.

I would greatly appreciate a copy of your modified ICONV(RTP26).

Thanks,

Janet

Please send to [email protected]

Thanks again,

Janet

Chris,

 Can I still get a copy of the modified ICONV/OCONV for REVG2B? My email address is [email protected].   Thanks.

View this thread on the forum...