Re: Passing values to PowerCOBOL DLL

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 conversion to DotNET
    ... COBOL from the seventies, which have been converted and migrated ... Presentation layer. ... comes to platform change. ... I think it was a major oversight in PowerCOBOL. ...
    (comp.lang.cobol)
  • Re: Treeviews
    ... Neither PowerCOBOL nor NETCobol have ever "excluded collections". ... Java and OO COBOL. ... WebintMT AS "WebintMT". ... Now block the constructed record into the output buffer... ...
    (comp.lang.cobol)
  • Re: Thoughts on passing values to PowerCOBOL DLL
    ... COBOL thrust upon them. ... At my age I sometimes have trouble finding my ... then this would be a matter of "uniqueness of reference", ... I think as you become more familiar with it (even through use of PowerCOBOL) ...
    (comp.lang.cobol)
  • Re: Passing values to PowerCOBOL DLL
    ... I don't know much about that M$ stuff, nor PowerCobol, but this conversation you two just had made me think "What nice posts." ... I've had that working in the past but wanted to use the OLE control approach instead. ... the custom properties and custom methods to refer/set the data. ... 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. ...
    (comp.lang.cobol)
  • Re: [experiences] Fujitsu NetCOBOL for .NET
    ... >> possible to work with COBOL data files ... >> provided by fujitsu? ... They have no migration tool to move from PowerCOBOL to NET ... both NetCOBOL and PowerCOBOL is nothing less than abysmal. ...
    (comp.lang.cobol)