Hey Walter,

>>FWIW, I saw a TechNet presentation of .NET and CLR about 6 weeks ago in which it was demonstrated that COBOL code was compiled into a CLR program. The presenter stated that the goal was for 'any ECMA compliant language' (European Community Manufacturers Association) to eventually be included.
>
>hmmmm, that's news to me. Still I doubt what this means to the COBOL language. Are all COBOL language elements in it, or does it still require some add-ons.

I don't know anything about about language completeness or additional add-on requirements. The TechNet presenter simply loaded the VS .NET IDE, opened the VS .NET text editor, began typing in a few statements, one of which was a statement indicating to the CLR compiler that subsequent lines of code would be COBOL, compiled and ran it producing a COBOL "Hello World!!" program. She then added that the Orlando DevCon responded with a standing ovation when it was understood that CLR compiled COBOL could most typically be useful for making calls to other legacy COBOL routines.

>At least you'll have a choice as a COBOL programmer, compile to the CLR or in its own environment; As a VB7 programmer you won't....

I understand. At the recent VFP DevCon in Miami, Robert Greene characherized it like (paraphrase) "VS in a tool, VB is a language, VC++ is a language...VFP is a tool."

>Don't get me wrong, but if VFP.next is not backwards compatible and does not have the choice to compile to the CLR or not, then I'll vote against. I'm against any course that forces VFP developers to rewrite their applications to take advantage of .NET .

Ah, to CLR or not to CLR! I dunno... I would like to see VFP retain it's "tool" charachter. And with the exception of CLR, it would appear that VFP is .NET-abled as the rest of VS .NET

Steven-