What's up at Revelation Technologies?

Check out:

http://www.revelation.com/RevNews1.htm

quote … ANDOVER, MA- By some estimates, companies have spent

more than $50 gazillion dollars combing systems for equipment

that could malfunction if the Year 2000 is misread as 1900. It's

the so-called Y2K bug. As a developer, ask yourself how will

you be spending New Years Eve: biting your nails as the

minute hand reaches towards midnight or partying as the ball

drops in Times Square? Y2K fever has hit hard at Revelation

Software.

Since Y2K is not a problem for the Revelation developer the

company is celebrating …end quote

Pardon? My experience and that of many of my customers indicates that Revelation is most definitely a candidate for Y2K problems!

Why post a comprehensive explanation of what sort of things can go wrong re Y2K e.g.

http://www.revelation.com/WEBSITE/knowledge.nsf/07dbcbabb6b3e379852566f50064cf25/fe92e645dbd4ac9b852565bc0058c525?OpenDocument

and then deny that we have Y2K work to do on our Revelation applications?

Is Jim Acquaviva that much out of touch with the real world? How many developers will believe this false assurance that they have nothing to

worry about? I think this is irresponsible.

Yes, I do currently earn a living auditing and fixing Y2K bugged Revelation code but that does not mean I have only my own self-interest in mind when harping on about Y2K issues. There are Y2K problems in Revelation code, some are very serious and some could severely affect an organisation's viability if not fixed.

Some of my customers run mission-critical systems written in Revelation. I am unable to comment on who they are or the problems they have found. Perhaps they or others who have checked their code for Y2K bugs would like to inform Jim Acquaviva that unfortunately you cannot assume Revelation code is free of Y2K bugs.

Jim and others who are misguided on this issue may find this web site of interest.

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

Jocelyn Amon

finsol@ts.co.nz

If someone sits down and writes a program in C and that program isn't Y2K compliant, is it the C compilers fault or the programmers fault?

Advanced Revelation and OpenInsight are highly flexable tools. But they are TOOLS to design and deploy systems that programmers build. If a programmer used the tools in a fashion that leaves flaws that are preventing the application from being Y2K compliant, is it the tools fault or is it the programmers fault?

Revelation points out where potential flaws are in their article. They then tell you about inconsistancies such as the 0-29 and 30-99 year assumption for 2 digit years which could pose problems if you stay with a D2 format. They then go on to tell you about where to look for potential problems in the systems and what to do to fix it (change to D4 format, etc…)

Having bad Y2K style logic such as the following is common in some systems…

Example of inconsistancies that are application specific:

(prompt from data entry window)

Enter Expiration date: (mmyy) __ (entered as 0699, for June 1999)

* code fragment

ExpireMonth=Expires 1, 2

ExpireYear =Expires -2, 2

Today=OConv( Date(), "D2/" )

ThisMonth=Today 1, 2

ThisYear =Today -2, 2

If ExpireYear < ThisYear then

• booboo 00 us less than 99 but 2000 is greater than 1999

• thus it will flag 2000 expires as being expired already…

.

.

.

This kind of error has shown up in many systems already and has been corrected by PROGRAMMERS. This is a design flaw (programming error) not a tool fault. Such things need to be found and fixed by developers.

From what I read in Revelations paper, it is assuring developers that the TOOLS are sound and that there is nothing that is internal to the tools to be concerned about for Y2K. Thus developers who are working with tools that are not being developed anymore (ARev), are still safe to continue making a living designing and developing systems with these tools.

It also points out areas where potential problems can be found but, Revelation didn't build the apps you are fixing – programmers did – and it is not Revelations fault if the application is not Y2K.

So, as for your condemnation of Revelation for not 'being more concerned about Y2K', I have to disagree with you on this issue. They have put together a paper that outlines problems and what can be done to fix them when they are found. If you need to vent, find the folks who wrote the … stuff origionally and shoot THEM for it.

Mark Martin

Jocelyn… i have noticed that many of people are attempting to create unreasonable and incorrect fear into some minds about a Y2K.

Jocelyn… i want to be perfectly clear!!!

1) if you are speaking for a company and this company has found Y2K problems in revelation… why is it you are keeping them a secret!!!

2) to verify that you are genuine… i would like you to explain how revelation internally handles dates for me.

3) please answer correctly how the following date are internally converted…

 12/31/1999

 01/01/2000

 02/28/2000

 02/29/2000

 03/01/2000

 09/30/2000

 10/01/2000

 11/31/2000 this one is a double check!!!!

4) i truly believe that you are not clear or even have a hint on the method of storing dates internally.

5) the Y2K problem is so serious that i know you can not seriously ignore this and also at the same time be serious about your opinion of revelation and a Y2K problem that you believe revelation has.

note: oh by the way if the 4 digit year is upseting you then you may make them all a 2 digit year. oh and i know they would convert the same either way.

this reply is no joke! it is not ment to be a joke! it is ment to be a serious reply to a potential Y2K problem. although i consider the scare tactics of some companies to be the worse Y2K problem there is… if you can prove that there is a Y2K problem with revelation then i do know you would be raking in the bucks. the trick here is you must prove it first!

oh and by the way… i can prove that revelation does not have a Y2K problem. oops…………

Since we've had record usage of our ReSource ™ decompiling service this year, and completed many assignments checking and correcting AREV applications, I can say first hand that Y2K is an issue for our community!

Nonetheless, I'm surprised that acrimonious discussion of Y2K issues is propping up at this late date.

Since it is, let me contribute my views, mainly for the benefit of users who may not have a deep understanding of the development issues underlying the applications they use and depend on.

1) Yes, AREV and OI handle dates superbly - always have and always will. The tools do not need fixing. AREV did have a small "Y10K" problem centered around 5/17/95, when the internal date representation kicked over from 4 digits to 5. This problem won't recur until 10/14/2241… To be prepared for this impending crisis (the 100K problem will be 10 times greater then the 10K problem), we will soon have our comprehensive "Y100K" web site running, filled with offers for expensive analysis and correction services. (Humor-impaired readers, please ignore the last sentence.)

2) No, applications are not necessarily Y2K compliant. Programmers can do anything they want to (and AREV programmers are noted for their independence and originality), and any application not developed with Y2K considerations in mind may run into problems. Since there are a significant number of "ancient" REV and AREV applications still providing excellent service, these must be audited and possible problems corrected.

The single most prevalent problem we've encountered is the use of month-year fields (yymm, mmyy, etc), which are most often used to represent accounting periods. These items, and any others that store 2-digit years, as opposed to just entering and displaying them, definitely present Y2K problems, and require code analysis to detect and correct.

Since many older applications have missing or version-ambiguous source code, and equally missing developers, decompiling has proven to be a valuable aid in making correction an alternative to application replacement. I know the idea of decompiling Rbasic is akin to gun control in its power to trigger moral indignation outbursts (I particularly hope no one is dangerously passionate about both issues simultaneously), but decompiling is just another tool – and a good one. I'm quite proud of the fact that no one has ever been illegally deprived of revenue by virtue of the hundreds of decompiling jobs we've done over the past 8 years.

John

Why are you only quite proud? We're VERY proud that we've never deprived others of legitimate revenue by decompiling . It doesn't take a lot of time to prove ownership before decompiling n'est-ce pas?

As for Y2K… the issue exists as lots of people here can testify - we've all done our fair share of Y2K audits and Jocelyn has done even more. Sure the newsletter is flippant but it is marketing material not gospel! Ad hominems remain unwelcome, so in Jocelyn's defence Scott, she knows whereof she speaks, so please don't call her technical ability into question on this. She has probably examined the Y2K issue more closely than most people in this forum so she is a little more sensitive to perceived negations than most. Whether the vehemence of her reaction is justified is moot. Anybody who knows her views on this issue would have been surprised if she didn't post! Personally I was surprised it took her that long to react! I expected a similar posting a week or so ago when I first read the newsletter!

Meanwhile back at the ad hominems Jocelyn, I doubt Jim wrote the article and I doubt he is out of touch with the Y2K issue. This was simply marketing. You may consider it ill-conceived. That is your right, however the home page links both the Newsletter and the Y2K section and the Y2K section VERY explicitly says (and I quote directly) Please note that Revelation's products are software development and deployment tools. Revelation has no control over the ultimate quality or accuracy of products developed and deployed using Revelation tools. Therefore, Revelation provides no warranty whatsoever in connection with Year 2000 compliance of any software, application, operating system or hardware developed by third parties using Revelation products.

Just FWIW

amcauley@sprezzatura.com

Sprezzatura Group

World Leaders in all things RevSoft

To be constructive here:

(a) AREV and OI are (as installed from Revelation Software disks) 100% Y2K compliant

(b) AREV uses a call to DOS int 21h to get the system date. It does not use the BIOS, and not the RTC.

© REVG2B has some date ICONV issues using 2 digit years for which there are several known fixes.

(d) The next critical date for AREV is day 65536 where some assembly language date conversions, (such as my own) may fail. (sometime in late 2057 A.D.)

I believe that we should be relatively confident in the code we have control over, and in that supplied by Revelation Software. Jocelyn's tools are of value as a first check, or as a double check, especially of larger AREV applications.

Steve.

The vast majority of programming languages are Y2K compliant. It is possible to write Y2K compliant applications in any language. Why then is Revelation being held up as an example of a language which has no Y2K problems?

I am not saying that Revelation is at fault. I love Revelation - it is the best programming language I have ever coded in. But I am not so blinded by this as to claim that it is somehow immune to Y2K. All programming languages are affected by this problem. Any programmer who believes otherwise may be in for a surprise sometime real soon.

I do have a mission to raise awareness on this topic but the vast majority of my effort has been directed at developers in other programming languages, in particular developers using Java, Perl and C/C++. There is a lot more code written in those languages and a lot of it is in mission critical software and a lot of it in embedded systems.

I have spent relatively little time informing Revelation and PICK users in general of this problem. I thought, perhaps wrongly, that our community was more clued up on the issue. So it was a shock to me to get Jim's view of the Y2K issue.

OK - you're the expert. Define "imbedded systems". Give us an example of an imbedded system running Perl or Java. 6502? 4004? SN7440 dual NAND gate? BC108??

Eric

Re: The RevTimes marketing piece

Geez, you gotta be kidding me….next thing you know, having a little fun will be illegal.

Just to save any potential controversy:

The jRev white paper really isnt on the NY Times bestseller list

There isn't a reviewer named Mia Brain, Eileen Forward or Wanda Around

Kurt Baker isnt on the FBI most wanted list (at this time anyway)

I appreciated the tongue in cheek humor of this marketing piece - I found it refreshing and different.

Ease up! and if you are concerned about Y2K go to the the Y2K section of the site, not some marketing piece.

Ima Palled

ok i see that the accounting period in the format of yymm would have a problem… or would it?????

if you consider this…

november 1999 is 9911 or 99-11

december 1999 is 9912 or 99-12

january 2000 is 10001 0r 100-01

i do use accounting periods in the format of yyyy-mm. i set up a conversion routine (iconv and oconv) that handles conversions for accounting period.

REPLY=2000-01' or REPLY=00-01' or REPLY=0-1' your choice.

PERIOD=ICONV(REPLY,'PERIOD') … period now becomes 200001.

PERIOD=OCONV(PERIOD,'PERIOD') … period now becomes 2000-01.

i guess if some code has the accounting period format to be "yymm" then there is a sort problem when the year 2000 becomes 00. see 99 comes after 00. and 1999 comes before 2000.

now we are getting somewhere!!! this Y2K thing is so minimal. just share concerns and examples!

hmmmm… unless you are out to make lots of money over so little an event.

Good.

If you wish to raise awareness of Y2K issues in programs that have been created that's fine. Insulting the tool vendor for errors that developers stumbled over doesn't strike me as a good way to gain support from them for such an effort though.

ARev and OI are not just programming languages. They are database products, screen layout tools, etc… As such, they are a suite of tools that enable developers to build applications of a sophisticated nature because they also incorporate a programming language with the rest of the package.

In a sophisticated application, it is quite easy to make a 2 digit year error when you are used to 2 digit years being functional. Why force folks to enter 4 digits when 2 will do or why manipulate 4 digits in a string when 2 will work?

The areas where the Y2K will surface are not really going to be gross blunt in-your-face style but more subtle in things like reports which won't return back all the records, accounting systems when they roll over for a new quarter or year, etc… These places are where it will blow up when it never has before and, yes, I agree people need to take a good look at their systems to insure that there are no such issues coded into the system.

I disagreed with your method of slamming Revelation for it and I still disagree with it being Revelations fault for these problems. They have provided a guide for some things to look out for. If you want them to provide MORE information, sent them feedback on it with your sugestions and request. Don't just jump on the web and start name calling. From my own experience, you'll get better results this way.

Mark Martin

Ok, give us an example of a large (over half a meter tall) flightless bird with manners or a even modicum of intelligence.

http://users.penn.com/~immortel/keystone.html

View this thread on the forum...