Re: Passing values to PowerCOBOL DLL

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.

Regards

Michael

Robin Lee wrote:
Pete Dashwood wrote:
"Robin Lee" <robinlee@xxxxxxxx> wrote in message
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 .... the VB program must pass a customer ID to the COBOL code to specify which records to display.

Finally got this working, as described below after a few notes here...

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)


Okay I was wrong (though it still didn't work). Adding linkage and usage
compiled clean but generated a Fuji exception error in VB6.exe upon execution.
I quickly abandoned that avenue.

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)...

The JMP2/3 libs are referenced frequently in the docs in reference to COBOL97 DLL's but never in context of PowerCOBOL. I've had that working in the past but wanted to use the OLE control approach instead (and not beat what will ultimately become a dead horse).

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.


I had no luck with EXTERNAL as the variable was still not visible to VB.

But it did eventually lead me to the following snippet in the Users Guide:

POW_ug.pdf (Users Guide)
Page 366 Chapter 9. PowerCOBOL Programming Techniques
Figure 9.7 A Global External data declaration in the form's WORKING-STORAGE section.

... global or external data can be used only when the Script
Language property of a module is "0-COBOL85 Language Mode".

If you wish to share data when the Script Language property is
"0-OOCOBOL Language Mode", create an ActiveX control and use
the custom properties and custom methods to refer/set the data.

(end quote)

So ultimately I removed the EXTERNAL clause and changed the project to OO-COBOL.

I had already tried adding a "custom property" named CustID to the form, which was visible in VB and I could set to a value within VB but seemed unable to reference it within COBOL. What I eventually discovered was that reference to CustID had to be *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.


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...

FYI I am already using ADO in most of the current Fujitsu code, and I have the full VS-2005 setup on another machine and have recommended to the client that we/they move away from COBOL *and* VB and ultimately target C# as the platform of choice, based upon some earlier discussions in this forum. But over a decade has passed since my experience using C++ and I want to get some prototype code working now using what is installed in the customer base, which is VB6 and Fuji 6.1

It's a long story about how a company tried to accomplish some very sophisticated business functions by hiring an inexperienced programmer who knew VB but nothing of accounting or business practices. They went under, and the new owner brought back the old timer who resurrected the old COBOL code and got it working on the new platform. But the writing is on the wall... I wouldn't feel right using COBOL for any new projects, as much as I love it (full circle... my earlier reference to the dead horse).


Let's know how you get on...

Pete.

Thanks for helping me keep my head above water.
-Rob
.

Relevant Pages

  • Re: PowerCOBOL and DCOM
    ... An activeX control - generally - requires a window (called a ... for DCOM - does not. ... > I have been assisting another Fujitsu PowerCOBOL user to get a system ... > This is the first time I have tried deploying it under DCOM. ...
    (comp.lang.cobol)
  • Re: janus gridex powercobol code sample
    ... Are you looking for COBOL examples? ... Mostly I'd need the code to popolate the grid ... In PowerCOBOL go to the "Add custom controls" menu. ... The Janus Grid icon should now appear on the PowerCOBOL control toolbox. ...
    (comp.lang.cobol)
  • Re: janus gridex powercobol code sample
    ... from a sequential file or other variable. ... Install the ActiveX control and note where it is installed. ... In PowerCOBOL go to the "Add custom controls" menu. ... The Janus Grid icon should now appear on the PowerCOBOL control ...
    (comp.lang.cobol)
  • Re: janus gridex powercobol code sample
    ... from a sequential file or other variable. ... In PowerCOBOL go to the "Add custom controls" menu. ... The Janus Grid icon should now appear on the PowerCOBOL control toolbox.. ...
    (comp.lang.cobol)
  • Re: Passing values to PowerCOBOL DLL
    ... simple as adding a LINKAGE section and PROCEDURE DIVISION USING clause to the PowerCOBOL DLL. ... I've had that working in the past but wanted to use the OLE control approach instead. ... I had already tried adding a "custom property" named CustID to the form, which was visible in VB and I could set to a value within VB but seemed unable to reference it within COBOL. ... and the new owner brought back the old timer who resurrected the old COBOL code and got it working on the new platform. ...
    (comp.lang.cobol)