<< modifying the original runtime from Microsoft, who I guess should have
supplied the patch but didn't.>>

In terms of Microsoft supplying a fix, I doubt they would consider an unchangeable rollover any more of a fix than always interpreting it as 1900. So I don't expect to see them adopting this one like they did the fast pentium fix. And if you do have two applications that need two different rollovers, do you have to have two different ESLs? How do you make sure that the client is using the right one? You can't rename the files otherwise the exe wont find them. Y2KFOX allows you to change it at will. Of course I don't expect to see Microsoft adopting Y2KFOX either <g>.

<< How does y2kfox handle dates that are fed into ctod() functions as character strings? Does it interpret them as if entered from the keyboard and apply the rollover function to it >>

Yes, it applies the rollover.

<< Our source code has a lot of indexes created the following: STR(CTOD(somedatestring)- CTOD('01/01/01'),8,0) to &smkog..ndx. >>

Let me guess... SBT? <g> We have an SBT scanner that goes through your code and suggests changes. In this case you actually want 01/01/01 to be interpreted as 1901! Up until very recently, SBT was basically a port of the original dBase II version, so that is why you see all kinds of constructions like that.

<< Anyway, for our personal situation we are planning on porting the entire billing system into VFP in the spring. This will only be a temporary measure anyway. >>

A developers gotta do what a developers gotta do <g>.

Neil