"Robin Lee" <robinlee@[EMAIL PROTECTED]
> wrote in message
news:h5Wdnfw9o_SqLUTanZ2dnUVZ_veinZ2d@[EMAIL PROTECTED]
> Pete - I'm moving our apps slowly and gradually to C#, based primarily
on
> some things you've said in the past in this forum. These days I don't
know
> just what to recommend to management. Our core apps are screen driven
> COBOL from the seventies, which have been converted and migrated across
> six different platforms over the past three decades.
Ouch!
Formerly I had been a strong proponent of COBOL for precisely that
> reason... relative hardware independence. Moving to another system
> involved modifying screen behavior and some minor differences in file
> system hosting (i.e, the behavior of ISAM on whatever database system
upon
> which it is implemented).
> Never simple but always do-able.
>
> Consequently, the core algorithms - the processing guts - could remain
> untouched,
> except where needed in order to accommodate changing business needs. The
> rest of the code however has been adulterated with kludge upon kludge to
> make it fit whatever platform we happened to be running on for the time
> being.
Maybe others can learn from this experience; SEPARATE applications into
tiers. Each tier is a layer:
1. Presentation layer. Handles the User interface. It might be GUI, it
might be speech, it might be VR... whatever it is, for output, it is
driven
from a shared data buffer which is "filled" from the second tier (business
logic), for input, it does whatever validations are required and p*****
VALID data into the second tier.
2. Business Logic Layer. Its inputs are the buffers from the
presentation
layer, it processes, and returns outputs to the presentation layer.
3. The Data Layer. Doesn't matter whether it is ISAM, VSAM, Hierarchical,
Network, or Relational Database, it simply deals with managing data. This
tier provides a service to the other two layers. Again, all inputs and
outputs to/from it are by means of in-memory buffers. NO other layer
should
contain data access or manipulation code embedded in it; instead, calls
should be made to this layer to provide the data service.
While the above is idealistic and pretty hard to achieve in practice, the
closer you can get to it, the less aggravation you will encounter when it
comes to platform change.
>Our most recent conversion was to SQL server using ADO with some help
from
>you and Frederico. But whether or not Microsoft will be the platform of
>choice another decade from now is not certain.
Absolutely. In IT few things are ever certain. However, choosing the most
popular platform means that you have more collective clout, more available
sup****t, and less chance of going under. Sadly, just like Betamax and VHS,
the most popular is not always the best...
> Same can be said for C#. So I'm not entirely sold.
Moving to C# is not really about the language; it is more about the
platform. .NET/Mono provides a level playing field where different
components, developed with different languages, can interact seamlessy and
transparently with each other, and play nicely together. C# is simply a
very
effective vehicle into the .NET framework. (It is also a more powerful
language than COBOL, though...)
>
> Note that what the programs actually do hasn't changed. Not that a
rewrite
> hasn't been tried before. Earlier this decade, I was canned and another
> team brought in to rewrite the most im****tant apps in a more "modern"
> language (read VB). Disastrous. Just seeing the results of someone's
> attempt to write a bill of materials explosion, which is essentially a
> mere training exercise when done in COBOL with ISAM - using in-memory
> tables and bubble sorts is almost humorous.
Probably not funny for the people who did it, but I take your point :-)
>
> Now I'm back in, and they're asking me what to do. Unfortunately I can
no
> longer recommend COBOL. Not because it can't do the job, but because
it's
> becoming less and less likely to remain viable.
Yes, sadly, that is the reality.
Nevertheless, it would be a pity to throw out the baby with the bath
water.
I'd try to encapsulate and isolate that COBOL business logic, maybe build
it
into COM components . (COM seems to have weathered the storms of change
remarkably well and most modern OO languages can interface to it pretty
easily. This means you can leverage your existing code into the new
environment and is one of the foundations of my proposal. Fortunately the
refactoring can be largely automated (at least, it can be in the Fujitsu
environment) and you end up with a series of COM components that can be
used
on the web or on the desktop and can run in the .NET environment.
>It sounds to me like your approach is yet another stop gap approach...
Yes it certainly is. But it is intended to keep things running while a
more
long term approach can be devised and implemented.
I believe there is a difference between a planned, phased migration, which
may involve some code refactoring, and a stop gap, which is usually just
another hastily applied BandAid... :-)
> essentially the same thing we've been doing for the past 30 years.
Well, not quite, but I can understand you thinking that.Up until
"recently"
we simply haven't had the possibility to refactor and encapsulate existing
functionality, in a way that allows it to be used on the Web or the
desktop,
and across environments and platforms.
> Good luck in your endeavor.
Thanks. I'm not sure there will even be any endeavour. If the response is
poor it may be because people are already moving off COBOL or are happy
with
a continuing COBOL solution using .NET COBOL Either way, I'm not gong to
invest a lot of time and effort into generalising and poli****ng approaches
that have worked for me, unless I am sure there will be SOME return on
doing
so. I want to help, but I'm not stupid... :-)
I can see where this would be a handy short term
> solution for those with large volumes of code.
It would be "short term" inasmuch as it would be part of a continuing and
phased migration path.
We've already been there and done it.
> Not using your technique, but with the same result.
Maybe :-) I hope the result will not be the same... :-)
Thanks very much for your response. Good luck with a solution.
Pete.
--
"I used to write COBOL...now I can do anything."
|
