Re: Cobol for Visual sutdio



"Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
news:ge9tvk12feu@xxxxxxxxxxxxxxxxxxxx
Pete Dashwood wrote:

2. Moving COBOL to another platform does not address the underlying
problem
with procedural code, which is the paradigm itself.

True, but writing new OO .NET COBOL does. And the beauty of CLR is
that you can move your procedural COBOL, get it running, and then
rewrite pieces on your schedule - in OO COBOL or any other .NET language.

Yes, that is the approach I'm advocating.

There could be advantages in moving everything "as is" before refactoring.

Certainly, it keeps the Business running and stabilises it in the new
environment.

For small businesses it may be too expensive, but if it can be afforded, it
is not a bad thing to do.

(neither of the major COBOL for .NET
implemenations can use the full facilities of the environment that are
available through C#, for instance)

Getting close. You can now use (and create) custom attributes and
reflection, delegates, enumerations, events, generics, overloaded
operators, properties, value types, and so on in MF .NET COBOL. You
can write WCF clients and services, and host the latter under IIS and
WPAS. Use Winforms and Webforms. No LINQ support yet, but ADO.NET
works fine (and you can use EXEC SQL, though ADO.NET is preferable).

.NET COBOL will always be COBOL, of course. Even in a highly .NETish
program you'll still have idiosyncrasies like level numbers for object
members and quotation marks around all literal type and method names:

------
$set ilusing "System"
$set ilusing "System.Text"
class-id. testcobol.
static.
method-id. main.
local-storage section.
*> Define a .NET array of System.Byte
01 stuff binary-char unsigned occurs any.
*> Define a .NET System.String
01 stuff-string string.
01 msg string.
*> Define a reference to a .NET System.Text.ASCIIEncoding
01 encoding type "ASCIIEncoding".
procedure division.
*> Allocate the array and set its contents
*> There are various ways to do this...
set size of stuff to 5
set content of stuff to ("C" "O" "B" "O" "L")
*> Create encoding and convert array to string
set encoding to new "ASCIIEncoding"
set stuff-string to encoding::"GetString"(stuff)
*> Create another string using System.String.Format
set msg to type "String"::"Format"
(
"stuff-string is '{0}', and is {1:d} bytes long"
stuff-string
stuff-string::"Length"
)
display msg
end method main.
end static.
end class testcobol.
------

And that's not the case with languages created for .NET, such as C#.
But other languages that have been reworked into .NET, like C++.NET,
are just as bad, if not worse.
--
Michael Wojcik
Micro Focus

This is an excellent response, Michael.

I saw it after I posted in response to your previous in the same thread.

I'm impressed that the list you gave is the same one (almost) that I gave
you. Obviously, MicroFocus .NET COBOL has come a long way since the first
implementations.

Thanks for this.

Pete.
--
"I used to write COBOL...now I can do anything."


.