Re: Cobol for Visual sutdio

Pete Dashwood wrote:
"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.

..... and if Ballmer has his way, a migration away from COBOL ?

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)

That sounds a bit of a sweeping statement. I can understand that as a
F/J user you could make such a statement, but with respect to M/F, are
you generalising or do you have specifics ? They ain't dumb - for a
price, Fixpacks, they will keep their COBOL products in sync with
dotNet. They had Java OO inter-change classes back when you were
claiming here in CLC you hadn't got F/J support for Java.

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 :-

Wish you hadn't written that. Yours and my concept of 'granules'
(methods) differ widely. You finish up with several Sections in a method
- to me an absolute No, No ! Did you for some $12 get a second-hand copy
of Arranga/Coyle from amazon - most of their methods are no more than a
few lines of code. If you are dismissive of them, let me quote an old
army saying from Mesopotamia days, "They were in Baghdad before you were
in dad's bag". And Wilson Price (I'll get back on that, eventually),
take a look at his F-I-R-S-T Book sat on your bookshelf - can I make it
any clearer. Agreed his tutorial style examples start with a Procedural
and just flows down the page - take a closer look when he writes methods
in OO classes. Years ago, and be assured with no reference to you, in a
general enquiry from me, I asked how do you feel about a mix of
Procedural and Classes for OO - "Not impressed", he replied. "Get away
from Procedural formats and keep your methods small".

, 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 was fascinated by the inter-change between you and Robert on the above,
the use of 'sets' and 'tables' (???). I'll mention it in 'Last Hurrah
Part 2 - OO Factory'. Even just for info, it sounds like an extremely
interesting concept. Seriously, how do you know that can't be done in OO
COBOL ? Or did you do it using OO COBOL rather than C# ?

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

Get ready to tear your hair out :-). I just looked using your link .

- Blue banner at top with unreadable menu bar because of colour choice.
The word "PROCESS" stands out boldly.
- big white space
- followed by a closing blue banner.

Guess I just have to stop using Mozilla if I want to see your gems :-). Correction; I just ran it again before sending this. I noticed the small 'Home' top right, clicked on that and took me to your home page with the picture of a building being constructed. Didn't go beyond that.


Quite seriously - that other topic "M/F OO COBOL graduates". It could just give COBOL a shot in the arm. COBOL (Procedural) is NOT a difficult language to learn; I was completely self-taught. If somebody can come up with a text, from a developer's point-of-view, gently easing their way through the OO concepts (as applied to COBOL), then it might possibly have a fighting chance to disprove all your dire predictions.
You are after all, just one man crying 'Chicken Little'.

I really want to tackle OO Factory and then basically I bugger off out of here.


Jimmy
.

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: Cobol for Visual sutdio
    ... People interested in using COBOL with Visual studio might do well to look at ... While the video may not be "entertaining" it does get the job done and I ... I am persuaded that the best approach if you are considering migration is ... and Data Access has huge advantages. ...
    (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 ... 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)