Re: Cobol for Visual sutdio

Concerning the interchange between Michael Wojcik and Pete Dashwood (snipped in
this note)

As someone with an historical bias toward both COBOL and Micro Focus (<G> not
MicroFocus), here is what I come away with from the exchange:

1) Each release of Micro Focus products for the .NET environment provides more
and more support for those programming language and development features that
are available for other languages (especially C#) in the VisualStudio and .NET
development and deployment environments.

2) If there are existing features that current (or prospective) customers might
want/need, then MF seem response in providing the language and environment
features.

3) Obtaining the development environment for C# (with VS and .NET) is relatively
inexpensive. Running such applications on single machines or in network
environments is FREE (but does assume a .NET environment).

4) Obtaining the Micro Focus (for .NET / VS) development environment is
expensive. Deploying such applications to single machines is expensive;
deploying it to unlimited environments is VERY expensive.

5) Converting existing procedural COBOL business logic to C# (or Java) or any
other non-COBOL language (and non-COBOL OO environment) is both expensive and
error-prone. (I understand their are more and more automated "solutions" to
this, but I am unaware of any "major mainframe - for example - application"
success stories using truly automated solutions. *IF* (admittedly questionable)
one has a large COBOL base of existing (procedural) code AND an adequate trained
programming force, then transitioning to COBOL (even OO COBOL) with .NET / VS is
significantly less resource intensive then a conversion to another language and
paradigm.

6) If a site is finding it more and more difficult to find the resources to
maintain (and enhance) an existing COBOL base of applications but can (easily?
cheaply?) find an adequate supply of C# programmers, then a migration AWAY from
COBOL *sooner* than later seems both advisable and cost effective.

***

Bottom-Line:
I see *no* overwhelming reason why a shop would/should do significant NEW
development in Micro Focus or any other COBOL product - unless they have a fully
trained "new style" COBOL development force and no C# or Java (or other "new
language" programming staff - or if they are doing so for an IBM mainframe only
deployment environment.
For shops with sufficient COBOL development staff and a large base of existing
COBOL applications, then moving to a COBOL .NET environment (and I think Micro
Focus beats Fujitsu on this - but others may disagree), then it is a question of
whether the cost of conversion (of staff and applications) outweighs the
(significant) cost of implementing a Micro Focus development and deployment
environment. I see "language capabilities" as irrelevant. I *do* see the "free
run-time environment" of Fujitsu to be a valid consideration for those wishing
to stay with COBOL in a .NET (VS) environment, but (personally) just as Fujitsu
has NOT stayed current with its IBM dialect support, I do not see them staying
current (or as current) with .NET as MF does, so this run-time price advantage
is (to me) probably insufficient reason to select it over MF in a rapidly
changing .NET (Microsoft, PC, etc) deployment environment.
It is NOT surprising (given the above) that the MF target audience (even for
..NET) and especially their development AND DEPLOYMENT pricing/costs is targeted
at large existing COBOL (probably IBM mainframe) shops. For them, that solution
*is* cost effective; for individual (and small ISV) developers, the "stay with
COBOL" solution wouldn't be cost effective at any price that MF could stay in
business with.

Obviously, YMMV <G>

--
Bill Klein
wmklein <at> ix.netcom.com


.

Relevant Pages

  • Re: How would you do this?
    ... Standard and IBM hasn't implemented USAGE BINARY-CHAR or any other BINARY-xxx ... The best way to do this in Enterprise COBOL is to say ... returns a "32-bit map" with information about what environment a program is ... Use the LE "bit manipulation" routines? ...
    (comp.lang.cobol)
  • Re: Cobol for Visual sutdio
    ... As someone with an historical bias toward both COBOL and Micro Focus ( ... Each release of Micro Focus products for the .NET environment provides ... The REAL cost of COBOL is the labour intensive ongoing maintenance of source ...
    (comp.lang.cobol)
  • Re: command line arguments like on mainframe under fujitsu
    ... then I think it is important that the workstation environment support ... It may or may not be worth adding here, that Fujitsu is RELATIVELY unusual ... to be "migration inhibitor" for some IBM mainframe COBOL customers. ...
    (comp.lang.cobol)
  • Re: Command-Line / Environment variable acess (new thread)
    ... facilities from within COBOL? ... With respect to command line arguments, ... With respect to environment variables, ... X/Open COBOL; but only to the extent that ...
    (comp.lang.cobol)
  • Re: Command-Line / Environment variable acess (new thread)
    ... facilities from within COBOL? ... With respect to command line arguments, ... With respect to environment variables, ... X/Open COBOL; but only to the extent that ...
    (comp.lang.cobol)