Re: Cobol for Visual sutdio


"Nondisclosure007" <nondisclosure007@xxxxxxxxx> wrote in message
news:3e0efcba-4ea9-47a9-b362-084ba97255a4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I've seen the Fujitsu stuff, but is there anything for Visual Studio
2008? a compiler mostly?

People interested in using COBOL with Visual studio might do well to look at
some of these video tutorials:

http://www.microsoft.com/windowsserver/mainframe/training.mspx#cobol.net

This is a series of tutorials provided by MicroSoft, which demonstrates the
use of both Fujitsu (NeoKicks) and MicroFocus toolsets with Visual Studio
as part of a migration away from the mainframe platform.

Unfortunately, the videos are not "engaging" (although the presenter is
knowledgable) and there are some problems with being able to read screens.

This is a factual, fairly dry presentation which I found difficult to watch,
but I hung in there because the quality of the information is good and the
content overall is interesting.

The one I watched showed how to bring a mainframe CICS application into .NET
using ASP.NET to scale the application to the Web.

(He also discusses, in a quite unassuming way, why you might want to do
this...)

While the video may not be "entertaining" it does get the job done and I
developed more warmth for the presenter as I got to know him better :-)

He quoted some impressive companies who have migrated from the mainframe
into .NET but I liked the fact that he was not Evangelical in his approach.

I see the following two problems with this approach:

1. The tools (from both MicroFocus and Fujitsu) are expensive.
2. Moving COBOL to another platform does not address the underlying problem
with procedural code, which is the paradigm itself.

I am persuaded that the best approach if you are considering migration is
NOT to consider COBOL on .NET as an end point. (It may well be a good
starting point, though.)

Succesful migration WITH A FUTURE means layers (tiers) and objects. (This
means you are not "locked in" to COBOL, but you can still use it if you want
to. You can create objects that utilise the full capabilities of the .NET
Framework in modern languages (neither of the major COBOL for .NET
implemenations can use the full facilities of the environment that are
available through C#, for instance) and still have your legacy COBOL objects
continuing to work. It gives you choice; a direct migration of COBOL from
one platform to another doesn't do that, even though the migration is quite
straightforward using modern tools. (However, such a migration can extend
the life of your COBOL applications...))

COBOL programs are generally single tiered with direct access to data and
direct interaction with the user. Inserting interfaces between Presentation
and Data Access has huge advantages. Using objects means that each layer is
more "granular"; smaller granules means less overall impact when making
changes, using encapsulated objects means no regression testing. Data access
can be tuned without impact on program logic simply by optimizing Data
Access objects in the Data Access Layer. (I have been doing this recently
and managed to get from 180 rows per second returned on a cursor, to over
500, without change to application logic and using dynamic SQL...
Multithreading the Data Access Layer is very easy with an OO approach.)

I believe there are some later videos in the set of tutorials above which
deal with OO COBOL and I plan to look at them as soon as I get some time.

Meantime, I am still happy with the Dashwood Model for Migration :-)

(If you haven't already, please see the diagram on:
http://primacomputing.co.nz/cobdata/ShowMe.aspx?ptitle=Process
flowdiagram...&pcontent=images/MigrationProcessOverview.jpg



Pete.

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


.

Relevant Pages

  • Re: IBM COBOL Migration to Windows COBOL
    ... is easy to maintain eand enhance with "Windows" personael and resources. ... impact how such a migration should be made. ... I see no long term future in COBOL and it is advisable to open up ... Micro Focus is ACTIVELY maintaining IBM compatibility. ...
    (comp.lang.cobol)
  • Re: COBOL tools - and wher are you going (was: Experience with "cobol-it" cobol?
    ... migration" it is enough to get stuff running on the new platform. ... run existing applications under Windows without problem, ... You can write them in OO COBOL or you can use something else, ... Most modern languages support ...
    (comp.lang.cobol)
  • Re: Veryant takes on Pete Dashwood :-)
    ... I have spoken with Veryant and their product set is not doing what I ... the Migration Toolset. ... COBOL has no long term future. ... this extremely well so migration to one of these platform ...
    (comp.lang.cobol)
  • Re: Cobol for Visual sutdio
    ... People interested in using COBOL with Visual studio might do well to look at some of these video tutorials: ... This is a series of tutorials provided by MicroSoft, which demonstrates the use of both Fujitsu and MicroFocus toolsets with Visual Studio as part of a migration away from the mainframe platform. ... Inserting interfaces between Presentation and Data Access has huge advantages. ...
    (comp.lang.cobol)
  • Re: Cobol for Visual sutdio
    ... People interested in using COBOL with Visual studio might do well to look ... Studio as part of a migration away from the mainframe platform. ... It is a problem with the COBOL language so neither of them can implement it ...
    (comp.lang.cobol)