Re: COBOL...to be, or not to be...
- From: "P. Raulerson" <paul.rl@xxxxxxxxxxxxxx>
- Date: Sun, 19 Nov 2006 22:13:46 -0600
I post to the net so rarely these days, I almost forgot how, so if this
shows up as a duplicate, apologies. :)
Pete - don't forgot to check out IBM VisualAGE Cobol, now wrapped up in the
Websphere Developent Client for zSeries I think.
It is not radically expensive - and has not runtime costs on workstations.
Fully capable workstation programs, as well as client/server
style programs, database access, etc. Really good stuff, and in the process
of being re-worked yet again. The GUI is different from Visual Basic style
stuff, but not difficult to get a tooth into.
Secondly, consider the iSeries as a deployment platform. Cobol runs just
great on the platform, and the development environment is indeed "sweet".
COBOL is nowhere near as well supported in the Workstation world of the
iSeries crowd as RPG is, but there is always VisualAGE RPG, which is
surprising COBOL-like now (RPG IV with free format coding rules) and does
integrate well with Windows. Also allows you to create and distribute fully
functional workstation programs, again with no runtime.
..NET is nice, and I do like it, as long as I don't have to code in it... ;)
But there are some neat products out there that integrate to it just fine
without the craziness of some of the COBOL vendors. I do believe that some
of our COBOL vendors are going crazy trying to squeeze money out of existing
customers rather than trying to innovate and encourage users. They don't
understand that runtimes are the kiss of death in today's enterprise
environment. IBM does understand that well.
Also, when you call for support on IBM COBOL, you don't get a 1st level
flunky who tries to push you off. You get routed to someone who darn well
knows what they are talking about, and will go way out of their way to help
you. That alone is enough to make me recommend the switch.
(That is not universal at IBM - I had some idiot in entitlements tell me
that the service contract on a brand new blade center had expired in October
of 2004. At 3am in the morning, and with a blade Center IBM did not even
start selling until May of this year. )
-Paul
"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4sb1opFuk3ulU1@xxxxxxxxxxxxxxxxxxxxx
I have given a fair bit of thought to how I might best go about moving my
investment in COBOL to a new environment.
Specifically, I want to be able to use the DotNet framework and classes in
my applications.
In case anyone else is considering a similar move I thought I'd post what
I considered and how it's going.
(What follows is a VERY condensed subset of my thoughts - there were
experiments and a great deal of considering which is not mentioned here.)
Option 1: Buy Fujitsu DotNET COBOL and simply migrate the code base.
PROS:
Easy and unlikely to be problematic, as all my existing COBOL code is
currently either PowerCOBOL or NetCOBOL.
No runtime fees.
CONS:
It costs several thousand dollars and they are not keen to sell it to me.
Several enquiries went unacknowledged and unanswered.
Support in the past has been diabolical.
Would need to convert PowerCOBOL to Forms or similar... (Could be
fun...:-))
Option 2: Buy MicroFocus Server Express.
PROS:
Professional approach from posts by their people in CLC.
Comparatively large user base and good support forum.
CONS:
Probably need a lot more tailoring of code to migrate it.
Same price range as Fujitsu, plus run time fees...
Company is not entirely stable.
Bad experience in the past; I remember VisOC...
Runtime fees. (This actually made it non-viable for me...)
DECISION:
Given that these are the two players I would consider as "possibles" (no
offense to the others...) I needed to review the whole question of whether
there is any future in COBOL development or whether it is better to simply
go with the flow and move completely to Java, or C++ or VB or C# (all of
the latter three can use the DotNet framework and generate managed code
(MSIL)).
I have a huge investment in code which has accumulated over 20 years of
writing COBOL on PCs (and I have some modules which I wrote on the
mainframe then converted to the PC). I COULD just write it all off but it
would make me very sad to do so.
Although I enjoyed VB and revised my opinion of it when I used it to
tailor an IBM toolset recently, I still don't think of it as being a true
OO language. On the other hand C# was designed to be, and was designed
specifically for the DotNet framework, using the experience gained with
Java and C.
So C# looked like the most likely candidate.
A few weeks ago, I downloaded (fror FREE) the Visual Studio 2005 and C#
Express version. I don't claim to be an expert yet, but I am certainly
progressing and it is good fun. Using C# gives good insight into how the
DotNet Framework works, what Classes are available, and why using it is a
Good Thing. I already knew that Visual Studio is a useful tool, but VS
2005 is really good.
At first I was bracing myself to have to convert all the existing COBOL
code to C# (I planned to automate this if it proved to be necessary) and
expected it to take at least a year. I am pleased to report it simply
isn't necessary.
Because I have opted for an OO approach and built most of my functions
into encapsulated components, there is nothing to convert. C# in the
DotNet environment will gladly handle COM and ActiveX components as
"unmanaged code" and interfacing to them is a doddle. I can use C# to
"glue" my old components into new applications and to develop new ones
that use the DotNet classes and 100% managed code.
This means that the old components will still use the COBOL runtime, but
the RTS is installed (if it hasn't been already) as part of the Component
registration and install that is used to set up the component in the first
place.
When I have a few applications that use both managed and unmanaged code
running, and am satisifed that everything works properly,I'll probably buy
the full VS 2005 and C# compiler. Given that and Java, and the fact that
I'm really not planning doing many more major apps., I think that will be
the end of COBOL for me.
I'm pleased about the new stuff, but kind of sad also...
Pete.
.
- Follow-Ups:
- Re: COBOL...to be, or not to be...
- From: Pete Dashwood
- Re: COBOL...to be, or not to be...
- From: P. Raulerson
- Re: COBOL...to be, or not to be...
- References:
- COBOL...to be, or not to be...
- From: Pete Dashwood
- COBOL...to be, or not to be...
- Prev by Date: Re: [OT] Rather Polite of Him, Wouldn't You Say?
- Next by Date: Re: COBOL...to be, or not to be...
- Previous by thread: COBOL...to be, or not to be...
- Next by thread: Re: COBOL...to be, or not to be...
- Index(es):