Cobol - Passing values to PowerCOBOL DLL

Author

Passing values to PowerCOBOL DLL

Robin Lee

2007-03-29, 9:55 pm

There'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. I'm using VB6 and Fujitsu 6.1

Here's what I've accomplished so far ... a working COBOL program that accesses a
data file and displays the records in a listbox on a relatively simple PowerCOBOL
form. That part is easy.

The form is compiled into a DLL which I have registered and referenced in a VB
project. The form is inserted as a control on the VB form and appears to function
as intended when the VB program is executed.

All that is pretty amazing for an old timer such as myself. Frankly I'm amazed it
actually works, considering if all this were written in COBOL alone it could be
easily accomplished with a simple CALL statement.

But to be of any value, the VB program must pass a customer ID to the COBOL code to
specify which records to display. I'm guessing it's not as simple as adding a
LINKAGE section and PROCEDURE DIVISION USING clause to the PowerCOBOL DLL (I'm
guessing that such syntax is not supported).

COBOL-85 syntax is specified in the PowerCOBOL project properties as I'd like to
keep this simple and not delve into OOCOBOL if possible. I'm just using the COBOL
component to prototype some data access which will later be done in SQL.

Again, passing this value is probably simple to do but I don't know where to look.
The ADTOOLS website appears to be down... anybody know what's up with that?
Thanks for any pointers.

Pete Dashwood

2007-03-30, 3:55 am

"Robin Lee" <robinlee@news.com> wrote in message
news:1N2dnSfFON3R-JHbnZ2dnUVZ_hGdnZ2d@giganews.com...
> There'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. I'm
> using VB6 and Fujitsu 6.1
>
> Here's what I've accomplished so far ... a working COBOL program that
> accesses a data file and displays the records in a listbox on a relatively
> simple PowerCOBOL form. That part is easy.
>
> The form is compiled into a DLL which I have registered and referenced in
> a VB project.

Is it registered as a COM DLL? Sounds as if it is... (Did you use the
PowerCOBOL COM template at the start of your Project?)

> The form is inserted as a control on the VB form and appears to function
> as intended when the VB program is executed.
>
It's always great (and constantly surprising) when things work, isn't it
:-) ? I have exactly the same reaction even after thousands of successes...
:-)

> All that is pretty amazing for an old timer such as myself.

Yes, very well done. Good job.

>Frankly I'm amazed it actually works, considering if all this were written
>in COBOL alone it could be easily accomplished with a simple CALL
>statement.

No, it couldn't. You couldn't (easily) build your PowerCOBOL form in COBOL,
for a start... Remember, PowerCOBOL is a "quick build" GUI environment;
dragging and dropping controls onto a form is much easier than laboriously
creating them through the Windows API...

Not only that, but what you have now is an OLE/COM server .DLL that was
created for you without you having to do anything particular. You can
manipulate this from VB or anything else, drop it on a Web page or use it
from a desktop application. Value has been added that you are not even aware
of... :-).

>
> But to be of any value, the VB program must pass a customer ID to the
> COBOL code to specify which records to display. I'm guessing it's not as
> simple as adding a LINKAGE section and PROCEDURE DIVISION USING clause to
> the PowerCOBOL DLL (I'm guessing that such syntax is not supported).

Why would you guess that when it is a matter of minutes to check it out? Of
course you can pass parameters to your PowerCOBOL and the procedure Division
definitely does support Linkage. But it is only your METHOD linkage that
needs to specify the parameter, so you should specify it there. (See below)

Unless you are using JMPCINT2/3 from VB (and I take it you're not, because
it is much better to treat the PowerCOBOL as a COM server, and this doesn't
require the VB form loading interface), you can manipulate your PowerCOBOL
form just as you would ANY Automation server from VB or VBA.

Declare the CustomerID in the Working-Storage of your PowerCOBOL Form and
give it the attributes GLOBAL EXTERNAL.

01 CustID pic x(whatever) GLOBAL EXTERNAL.

It is now visible to any PowerCOBOL controls or event processes that need to
use it.

So now your problem comes down to "How do I set this from VB, so that
PowerCOBOL can pick it up?".

I don't have time to set up and try this, but, if you declare your
customerID in VB as...

Dim $CustID PUBLIC

(this has to be at the Class, Interface, or Module level, you can't do it
within a procedure), you may be agreeably surprised to find it is
automatically passed to your PowerCOBOL form and pops up in the
Working-Storage where you defined it as above...) (This relies on some
hopeful assumptions on my part regarding the inprocess instantiation of COM
servers and is unlikely to work :-), but it is worth a try...)

Assuming that doesn't happen (it would be much too easy :-)), the following
will definitely work...

I take it your Form has a Method that accesses the database and displays the
ListView/dropdown? Let's say this method is called "GetMyData". You write it
as COBOL code in the event processing of the PowerCOBOL form (NEW
Procedure)

Define a linkage section and matching PD USING but make the custID
definition in Linkage 8192 bytes (this is what COM passes when it
"translates" your string from VB to COM to COBOL). You should immediately
move it to the working-storage definition defined above and only reference
that in your procedure.

VB...(may not be 100% I have neither VB nor COBOL on the machine I'm writing
this on...)

SET oleCOBOLForm = <registered ProgID of the form ...use an Object Browser
if you're not sure what it is... maybe something like
"PowerCOBOL.PowerCOBOLForm1", I really don't know.>

oleCOBOLForm.GetMyData($custID)

The above is a very specific (but workable) way of getting to the PowerCOBOL
form, however, there may be shortcuts. It is quite some time since I worked
with PowerCOBOL and there is probably a default procedure that runs
automatically when the form is invoked (if not, you can certainly put
something in the form OPEN event code).
>
> COBOL-85 syntax is specified in the PowerCOBOL project properties as I'd
> like to keep this simple and not delve into OOCOBOL if possible.

You already delved inot OOCOBOL as soon as you created the form in
PowerCOBOL :-). Fortunately, like the good "quick build" tool it is,
PowerCOBOL does not require a knowledge of OO. (It helps if you have it, but
certainly not essential. I was using PowerCOBOL effectively before I learned
OO.)

> I'm just using the COBOL component to prototype some data access which
> will later be done in SQL.

Pity. Have a look at ADO.NET. It is light years ahead of embedded SQL...
and easily callable from both COBOL and VB (although you might need .NET
versions of the compilers.) C# is free and automatically gives access to the
full DotNET Framework Class Library, including ADO.NET. Did I mention it is
fun to learn and write and it can access all your existing COBOL...:-)?
>
> Again, passing this value is probably simple to do but I don't know where
> to look. The ADTOOLS website appears to be down... anybody know what's up
> with that?

It was down two w

s ago when I went there to check some documentation;
fortunately I found what I needed on a CD :-)

> Thanks for any pointers.
>

Let's know how you get on...

Pete.

Pete Dashwood

2007-03-30, 9:55 pm

"Michael Russell" <Michael.Russell@msn.com> wrote in message
news:0ZGdnSNOxZrw3JDbRVnyiAA@pipex.net...
> Top post:
>
> 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.

Jolly decent of you to acknowledge that, Michael :-)

Usenet CAN be civilized and people can actually get help here (I have, on
numerous occasions).

Robin's post struck a chord with me because I've also been where he is
going.

Actually, when one of us wins, we all kind of win... :-)

Pete.
<snip>

Sponsored Links