Hi folks! Been a bit busy the last few days. Nabbed a copy of Microsoft Visual Studio 6.0 from work, and have had my head stuck... Studio is the latest and greatest from Microsoft for programmers, a combo of (Visual) Basic, C++, Java++, FoxPro, and InterDev, plus some "Back Office" stuff. I've been playing with it at work for a while, but now that I have it home, I'm really in trouble...

Now the Y2K part. MS tech says that VS 6.0 Y2K testing is "yet to be completed," although they do expect a report this month (check their website). I also understand that VS had a service pack released last month, SP/2. Now, I'm not sure yet if SP/2 addressed any Y2K issues, but since Win/NT SP/5, also released last month, does address Y2K issues, I wouldn't be surprised. After all, we are talking about the developers, aka programmers, here.

So, let me see if I have this figured out. The state of the art tools and compilers that Microsoft is pushing at Windows and Web programmers (an almost exact quote from the manual cover), has not yet been tested for Y2K compliance. The operating system, esp NT, the business oriented product, has had several "service packs" released to address the Y2K issue. Some say, my cpmpany included, that the answer to solving some of the old mainframe problems, is in "new technology." Overall, I agree. Looking at a system, see what comes in, and what goes out, and doing it over from scratch is often a good idea. Piles of rat's nest Cobol and Assembly programs, decades old, worked on by who knows how many programmers, that all think differently, we are better off starting over sometimes...

So, all of my PRO friends out there, what are th2 Y2K issues with Visual Studio 6.0, and the host Operating Systems, Windows/95/98/NT/2000? What is already in production using these development tools? When they were placed in production, what SP level were they at? Did they all get "recompiled" with the latest "compliant" SP? Well, I guess it's no big deal, as long as you don't call one of the functions that DO HAVE A Y2K PROBLEM...

Compliant with minor issues. Yea, like the minor issue of the old mainframe operating system returning a two didgt year. Remember that one? No problem. <:)=

And the tick goes on...

-- Sysman (y2kboard@yahoo.com), May 18, 1999

Answers

PS - Didgt, nice typo. DID GT (greater than (99)), yea, the old IBM engineer knew, but DOD said no! Hummm... <:)=

-- Sysman (y2kboard@yahoo.com), May 18, 1999.

Haven't done much with the other stuff yet, but have been working with MS Foxpro on a program for some Real Estate folks (no, not in Texas, in Indiana - know somebody will claim I am working for CPR if I don't put that in). The manual says to ensure Y2K compliance use the command SET STRICTDATE ON and it will not permit any noncompliant usage of dates or of functions that are not Y2K compliant. Throws an error when you try to call such a function. When I get time (a couple of weeks probably) I am going to recompile an old (and quite large) Dbase/Clipper MS-DOS program in Foxpro with STRICTDATE ON and see what happens.

-- Paul Davis (davisp1953@yahoo.com), May 18, 1999.

Howdy Paul,

I've never done much with xBase, but I do have a good friend that has been with it since the DBase days. I do know that at lease CLIPPER had a "SET CENTURY" command, or something like that. My question is why >>> ALL <<< of the other "older" languages didn't. Would have made this problem MUCH easier. Jeez, we've only known about this since, what, 1960??? <:)=

-- Sysman (y2kboard@yahoo.com), May 19, 1999.

"Nabbed a copy of Microsoft Visual Studio 6.0..."

[GRIN] I thought you used "real" computers!

Beware the dark side of the force Sysman. Once you go down that path, consume you it will. [/GRIN]

-- Anonymous99 (Anonymous99@Anonymous99.xxx), May 19, 1999.

I always rather thought that it was not of concern because the programmers always assumed the code would be replaced, rather than torn apart and core modules reused the way it was.

I think I have said this before, but back about 85/86 I knew a Phd who was part owner/programmer/analyst for one of the very first food distributers to offer the complete ordering/inventory/barcode scanner packages to grocery stores. Scan it, put it in the computer, and send it directly to the distributor and he makes up the order to bring you back up to the level you desired when you set the program up. One of the partners was very concerned that the first version of the program was not Y2K compliant. Lost contact with him while he was just starting on the next update - but it was supposed to address the Y2K thing among other issues. Now that program was entirely written in Clipper - except for some utilities in C that were needed to download the barcode program into the scanners. And his plan was to use 4 digit dates and SET CENTURY ON to become Y2K compliant. He felt that for Clipper, it was not a big deal. (Of course, nobody called it Y2K compliant back then - more something like - it should run OK after the Year 2000.)

-- Paul Davis (davisp1953@yahoo.com), May 19, 1999.

Doesn't my handle say it all? I was happy as a clam back in DOS Clipper days, but had to go to Microsucks stuff to make a living.

-- vbProg (vbProg@MicrosoftAndIntelSuck.com), May 19, 1999.

Can't address all of it, but I use Interdev and SQL-Server. SQL 6.5 last I checked had a problem with the job scheduler, but the actual data format for the date is a count of minutes or microseconds (depending on precision you choose) from a start date. I think the scheduler has been fixed in version 7. VBScript code in IIS seems to work just fine, haven't tested exhaustively but all the date functions I'm using are doing fine.

-- Shimrod (shimrod@lycosmail.com), May 19, 1999.