On Mar 13, 7:48=A0pm, "Pete Dashwood"
<dashw...@[EMAIL PROTECTED]
> wrote:
> "Robin Lee" <robin...@[EMAIL PROTECTED]
> wrote in message
>
> news:h5Wdnfw9o_SqLUTanZ2dnUVZ_veinZ2d@[EMAIL PROTECTED]
>
> > Pete - I'm moving our apps slowly and gradually to C#, based primarily
o=
n
> > some things you've said in the past in this forum. These days I don't
kn=
ow
> > 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
up=
on
> > 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. =A0Handles the User interface. It might be GUI,
it
> might be speech, it might be VR... whatever it is, for output, it is
drive=
n
> 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. =A0 Its inputs are the buffers from the
presentat=
ion
> 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
shoul=
d
> 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
fro=
m
> >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
ve=
ry
> 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
rewri=
te
> > 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
n=
o
> > 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
us=
ed
> 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
mor=
e
> 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
deskto=
p,
> 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
wi=
th
> 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
doi=
ng
> 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."
Peter,
You realize of course there is no conversion/extraction routines for
PowerCOBOL, right? All the information is in the PPJ file. If you take
a look in the file itself (try using a hex editor) you will see one
heck of a mess. I mentioned creating a PowerCOBOL to .NET converter
back in 2002 but Japan said 'No way, there was no need for one'. I
tried to make it work but quickly realized the PPJ was very convoluted
and hard to determine what was in it and more im****tantly how it was
organized. Plus, you're walking in the managed -vs- unmanaged code
issue. You may have something inside the code snippets that would be
unmanaged that will not work inside the managed compiler.
Best recommendation is to segment out everything into layers (typical
3-tier works best), recreate the GUI in WinForms, try to recompile the
COBOL into NETCOBOL (if you can afford the compiler) or convert it to
C#. Fujitsu really has their head way up a dark area on this one. Hope
this helps...
|
