"frostyndus@[EMAIL PROTECTED]
" <cblkid@[EMAIL PROTECTED]
> wrote in message
news:58560a05-d6e5-4785-a2d9-53c68c07a27f@[EMAIL PROTECTED]
Mar 13, 7:48 pm, "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
>> >> 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."
>
>Peter,
>
>You realize of course there is no conversion/extraction routines for
>PowerCOBOL, right?
Yes. I think it was a major oversight in PowerCOBOL. I have remedied it by
writing my own tools.
>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.
Yes, I have done that and I know... :-) Fortunately, this is not the only
source of information for a PowerCOBOL project.
>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.
I have spent the last several months working in this area for some
projects
of my own. I have it pretty well sussed now
and have found a number of tricks and workarounds that ensure existing
Fujitsu PowerCOBOL or NetCOBOL can run as unmanaged.
I have no problems in this area, although I sweated it for several weeks
when I first started.
>
>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#.
I think you mean NetCOBOL for .NET?
No, you can recompile the COBOL into standard Fujitsu NetCOBOL ("COBOL
90")
and simply wrap it as a COM component.
COM components run extremely well as unmanaged code in .NET. I've done it
and was very happy with the results.
That's why I'm offering the service here. If enough people are interested,
I'll upgrade my existing tools to professional
standard and either sell the tools or sell the service for as low a price
as
possible, so that the PowerCOBOL
user base is not stranded.
So far, there has been no response, so it looks like being a non-starter.
I
suspect PowerCOBOL developers have already started moving their
PowerCOBOL apps into something else, or maybe they just don't realise the
train wreck that is waiting when Fujitsu pulls sup****t
for PowerCOBOL, and their clients start running more modern applications
(with a dfferent look and feel, like Vista Aero...) alongside the
PowerCOBOL
apps.
I'm really not bothered either way, as I have now completed moving my own
apps out of PowerCOBOL and will gradually replace the COBOL with
C# when it makes sense to do so. All current development is in C#,
including
the tools I wrote for doing the PowerCOBOL extraction.
>Fujitsu really has their head way up a dark area on this one. Hope
>this helps...
:-) No comment. Thanks very much for your post. It is good to know I'm
not
the only one concerned about this... :-)
I see the migration as:
1. Extract and re-refactor user written COBOL code (scripts and event
processing) within PowerCOBOL application, and wrap it as COM.
(This can be entirely automated. What I have currently does about 80%
of
it, but I'll upgrade it to 100% if there is interest.)
2. Convert PowerCOBOL GUI to .NET forms. (Mainly manual at present, but I
would look at automating this if there were enough interested parties)
3. Update C# form event handlers with COBOL event processing. (Can be
fully
automated. It is just calls to the
COM components, which will run as unmanaged code)
4. Update the C# form with the COBOL scripts. (Can be fully automated. It
is
just calls to the
COM components, which will run as unmanaged code)
5. Check it out and amend manually where necessary.
I can also offer ISAM to RDB data conversion at the same time, as an
optional extra.
(I have migration tools for this written in C# and they have proved
extremely successful)
Data access code conversion is mainly manual at present, but, again, I
would
look at automating this if there was enough interest.
Thanks again for your response.
Pete.
--
"I used to write COBOL...now I can do anything."
|
