| Pete Dashwood 2007-03-30, 9:55 pm |
|
"Robin Lee" <robinlee@news.com> wrote in message
news:JIWdnZY8ZdV8_pDbnZ2dnUVZ_qGjnZ2d@gi
ganews.com...
> Michael Russell wrote:
>
> Thank you Michael. Your comments are very much appreciated. Perhaps too
> often a call for help meets with remarks such as "do your own homework"
> (okay, sometimes it's justified).
>
> I'm guessing that most of us here are seasoned COBOL programmers, that is,
> probably 50 years of age or older, with a few younger readers who have had
> COBOL thrust upon them. At my age I sometimes have trouble finding my
> eyeglasses, which I'm wearing! In such cases it's 'nice' to have an
> objective pair of eyes to help guide us.
>
> In this case, it turned out that the problem was indeed "something simple
> I've overlooked". Even when a module has only a single object, and that
> object has only a single property, then that property must be referenced
> explicitly.
>
> If we were speaking of programs and variables (which these in fact are)
> then this would be a matter of "uniqueness of reference", which in COBOL
> means that a fully qualified reference need only be specified when
> necessary to avoid ambiguity.
>
> But this isn't COBOL, it's object oriented programming.
> Perhaps some things *are* better done by committee.
>
I think as you become more familiar with it (even through use of PowerCOBOL)
you'll feel a bit better about it :-).
It is tedious to make explicit object references in COBOL as you have had
to. There are, in fact, a number of shortcuts to get around this, but to a
COBOL eye they look "foreign". (Check out the "Shrthand form" of Object
referencing in OO COBOL or, another alternative is to simply set an object
reference to the "thing" you are writing a long phrase to describe...These
are thngs you pick up as you go along and they become less unfamiliar as you
use them.
The important thing is that by encapsulating your functionality into a COM
server you have, in effect, "future-proofed" it.
I opted for this path about 10 years ago and started making everything COM
components. As I got into it, I realised there are many subtle advantages in
using components rather than simply CALLing a .DLL or sub-program.
PowerCOBOL will probably not be supported much longer by Fujitsu, but if all
your code is components, it doesn't matter. You don't maintain them anyway.
(At least, once a few mental adjustments are made, you realise that there is
no need to, and doing so is actually counter productive... it is a different
mindset and I've given up trying to explain it here...like explaining "red"
to a blind man :-); to be fair, without an understanding and some practice
in OO it is simply a foreign concept.) The point is that you can leverage
all of your components into the New Age and run them as unmanaged code. This
buys you time to redevelop whatever needs redevelopment or maintenance and
gradually phase out your COM components over time as they are replaced by
managed code that is platform and language independent. I think equipping
your client for the future was one of the responsibilities you are taking
on; this is a good way to address that.
[color=darkred]
There were a few things in your solution that I could've commented on and I
understand why some of the things you tried didn't work. I was working from
the assumption you were using the COM (OLE has been replaced) model, when
you were actually using standard COBOL. My bad, you did say that you were
trying not to get into OO.:-)
Never mind, you got it working and that is everything in the final analysis.
:-)
I completely endorse your stated path (it is certainly working for me... I'm
finding now that all my legacy components run faultlessly under DotNET using
Interop Services, and the final hurdle (getting them to run as a Web
Service) was conquered last w . Dot NET simply works; it is great.
C# is a really good transition to make, although, as we know, fashions
change with languages. I am finding there are many subtle things included in
C# that aren't even in Java, (it also simplifies and unifies elements that
require separate attention in Java, like simple types as one immediate
example) and I believe it will be around for some time. The new release of
it that will support Lambda functions innately (they require a bit of smoke
and mirrors to implement currently) is due out soon and I'm looking forward
to getting that.
Best of luck with your enterprise, Robin, and if you need any further help
with OO or PowerCOBOL, there are a number of people here (besides myself)
who can probably help. I believe I may not be the only one moving to C#,
also... :-)
Pete.
|