Re: Thoughts on passing values to PowerCOBOL DLL
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 31 Mar 2007 12:39:49 +1200
"Robin Lee" <robinlee@xxxxxxxx> wrote in message
news:JIWdnZY8ZdV8_pDbnZ2dnUVZ_qGjnZ2d@xxxxxxxxxxxxxxx
Michael Russell wrote:
I don't know much about that M$ stuff, nor PowerCobol, but this
conversation you two just had made me think "What nice posts."
That's 'nice' as in written well, courteous & helpful. Great stuff, if
you don't mind my saying so.
Regards
Michael
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.
What I eventually discovered was that reference to CustID had to beThere's probably something simple that I've overlooked, but it's not
obvious to me how to pass a value to a PowerCOBOL DLL called from VB.
*explicit* in the form "CustID of Control1", even though the project has
only one form and only one control. After that everything fell into
place.
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 week. 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.
.
- References:
- Passing values to PowerCOBOL DLL
- From: Robin Lee
- Re: Passing values to PowerCOBOL DLL
- From: Pete Dashwood
- Re: Passing values to PowerCOBOL DLL
- From: Robin Lee
- Re: Passing values to PowerCOBOL DLL
- From: Michael Russell
- Re: Thoughts on passing values to PowerCOBOL DLL
- From: Robin Lee
- Passing values to PowerCOBOL DLL
- Prev by Date: Re: New "base document" available
- Next by Date: Re: New "base document" available
- Previous by thread: Re: Thoughts on passing values to PowerCOBOL DLL
- Next by thread: Re: Passing values to PowerCOBOL DLL
- Index(es):
Relevant Pages
|
