C calling MicroFocus DLL 
Author Message
 C calling MicroFocus DLL

Hello,

I am attempting to call a DLL developed in MicroFocus COBOL from a C
application and am having some difficulty with a parameter to be
passed.

The DLL expects a parameter to conform to the following:

01  AAA.
     05 BBB         PIC X(2).
     05 CCC         PIC 9(4).
     05 DDD    PIC 9(2).
     05 EEE         PIC X(8).
     05 FFF SYNCHRONIZED.
          10 GGG         POINTER.
          10 GGG-LENGTH  PIC 9(9) COMP-5.
          10 HHH         POINTER.
          10 HHH-LENGTH  PIC 9(9) COMP-5.

Any help in constructing this parameter in C would be appreciated.

Jay

Jay Reich



Fri, 01 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Quote:

> The DLL expects a parameter to conform to the following:
[SNIP]
> Any help in constructing this parameter in C would be appreciated.

Hi Jay Reich,

Sorry, but the standard C language does not know about DLLs and does
not support interfacing to other programming languages. Both is very
system specific. Since DLL sounds very much like Windows, I would
suggest that you ask in one of the Windows newsgroups out there.
Here is one that might get you started:

Stephan
(initiator of the campaign against grumpiness in c.l.c)



Fri, 01 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Quote:

> Hello,

> I am attempting to call a DLL developed in MicroFocus COBOL from a C
> application and am having some difficulty with a parameter to be
> passed.

> The DLL expects a parameter to conform to the following:

> 01  AAA.
>      05 BBB         PIC X(2).
>      05 CCC         PIC 9(4).
>      05 DDD    PIC 9(2).
>      05 EEE         PIC X(8).
>      05 FFF SYNCHRONIZED.
>           10 GGG         POINTER.
>           10 GGG-LENGTH  PIC 9(9) COMP-5.
>           10 HHH         POINTER.
>           10 HHH-LENGTH  PIC 9(9) COMP-5.

> Any help in constructing this parameter in C would be appreciated.

> Jay

This should work OK,, presuming you know how to set up/call a Cobol DLL
from a C-prog..
(Hint: Use LoadLibary Windows-API)

NOTE the next pragma!!!!!

#pragma pack(1)

struct _AAA
{
  unsigned char[2]    BBB;
  unsigned char[4]    CCC;
  unsigned char[2]    DDD;
  unsigned char[8]    EEE;
  void * GGG;
  long GGG_LENGTH;
  void * HHH;
  long HHH_LENGTH;

Quote:
}  AAA;

The above is just a suggestion... I've not coded/tested this, and do not
know what you want to achieve.., but I've written a few programs in MF
Cobol which are called from C/C++...even passing function pointers
(PROCEDURE POINTER) that works fine...
(I use *only* dynamic loading.. as stating linking is a real pain to
link/run in my opinion.. Then you don't have to link in the Cobol RTS in
your C-app, as the dynamic load of the Cobol DLL will also load the
Cobol RTS)

*****
/Geir



Fri, 01 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Quote:


> > The DLL expects a parameter to conform to the following:
> [SNIP]
> > Any help in constructing this parameter in C would be appreciated.

> Hi Jay Reich,

> Sorry, but the standard C language does not know about DLLs and does
> not support interfacing to other programming languages. Both is very
> system specific. Since DLL sounds very much like Windows, I would
> suggest that you ask in one of the Windows newsgroups out there.
> Here is one that might get you started:

> Stephan
> (initiator of the campaign against grumpiness in c.l.c)

Sorry, but this isn't true with regard to Microfocus DLL's.  Microfocus
has an emulation of the c structure/data representation called
'CALL-CONVENTION'.  I have attached a DB2/UDB V5.0 call from a
User-Defined function (which expects a C calling convention and
microfocus handles it correctly).

Enjoy.

000200 IDENTIFICATION DIVISION.
000300 PROGRAM-ID.    'UXA101'.
000400*AUTHOR.        MCJUNKIN CORPORATION.
000500*REMARKS.       INVENTORY RECORD INSERT UDF.
000600* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
000700* PROGRAM CHANGE LOG                                            *
000800* NO.   DATE   WHO ACTION                                       *
000900* === ======== === ============================================ *
001000* 000 07/19/96 RRP INITIAL CODE WRITE.                          *
001100* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
001200/
001300* MICROFOCUS COBOL EMULATES THE C++ CALLING CONVENTION BY USING
001400* THE 'CALL-CONVENTION' SPECIAL NAMES PARAMETER BELOW ACCOMPANIED
001500* BY THE 'C-CALL-CONVENTION' VARIABLE ON EACH ENTRY POINT
001600* (INCLUDING THE PROCEDURE DIVISION).
001700 ENVIRONMENT DIVISION.
001800 CONFIGURATION SECTION.
001900 SPECIAL-NAMES.
002000     CALL-CONVENTION 0 IS C-CALL-CONVENTION.
002100*
002200 INPUT-OUTPUT SECTION.
002300 FILE-CONTROL.
002400$SET CALLFH
002500$SET FILETYPE"0"
002600     SELECT VXAUP-LOG            ASSIGN SYS010-UR-1442R-S
002700     ORGANIZATION IS SEQUENTIAL.
002800     SELECT VXAUP                ASSIGN SYS011-UR-1442R-S
002900     ORGANIZATION IS SEQUENTIAL.
003000*
003100 DATA DIVISION.
003200 FILE SECTION.
003300 FD  VXAUP-LOG                   LABEL RECORDS ARE STANDARD.
003400 01  VXAUP-LOG-RECORD            PIC X(80).
003500 FD  VXAUP                       LABEL RECORDS ARE STANDARD.
003600 01  VXAUP-RECORD                PIC X(1024).
003700*
003800 WORKING-STORAGE SECTION.
003900 01  THE-DATE                    PIC X(06) VALUE SPACES.
004000 01  THE-TIME                    PIC X(08) VALUE SPACES.
004100 01  VXAUP-LOG-FILE-OPENED       PIC X(01).
004200 01  VXAUP-FILE-OPENED           PIC X(01).
004300 01  SYS010-UR-1442R-S           PIC X(40) VALUE
004400     'E:\PFOC\DATA\VXAUP.LOG'.
004500 01  SYS011-UR-1442R-S           PIC X(40) VALUE
004600     'E:\PFOC\DATA\VXAUP.DAT'.
004700 01  W1-WORK.
004800     05  W1-FIELD                PIC X(40).
004900     05  W1-DATA                 PIC X(40).
005000*
005100     COPY MXARUP.
005200*
005300 LINKAGE SECTION.
005400 01  INVEN-LOCATION-ID           PIC X(08).
005500 01  INVEN-ITEM-ID               PIC X(08).
005600 01  INVEN-MATERIAL-TYPE         PIC X(02).
005700 01  INVEN-OWNER                 PIC X(01).
005800 01  INVEN-VENDOR                PIC X(10).
005900 01  INVEN-RESTOCK-BRANCH        PIC X(08).
006000 01  INVEN-BLEED-DOWN            PIC X(01).
006100 01  INVEN-BLEED-DOWN-COST       PIC X(14).
006200 01  INVEN-CAPITOL-SPARES        PIC X(01).
006300 01  INVEN-OPEN                  PIC X(14).
006400 01  INVEN-ALLOCATED             PIC X(14).
006500 01  INVEN-DUE                   PIC X(14).
006600 01  INVEN-LAST-DATE             PIC X(10).
006700 01  INVEN-LAST-TIME             PIC X(08).
006800 01  INVEN-LAST-USER-ID          PIC X(08).
006900 01  UXA101-RETURN-CODE          PIC S9(4) COMP-5.
007000 01  INVEN-LOCATION-ID-L         PIC S9(4) COMP-5.
007100 01  INVEN-ITEM-ID-L             PIC S9(4) COMP-5.
007200 01  INVEN-MATERIAL-TYPE-L       PIC S9(4) COMP-5.
007300 01  INVEN-OWNER-L               PIC S9(4) COMP-5.
007400 01  INVEN-VENDOR-L              PIC S9(4) COMP-5.
007500 01  INVEN-RESTOCK-BRANCH-L      PIC S9(4) COMP-5.
007600 01  INVEN-BLEED-DOWN-L          PIC S9(4) COMP-5.
007700 01  INVEN-BLEED-DOWN-COST-L     PIC S9(4) COMP-5.
007800 01  INVEN-CAPITOL-SPARES-L      PIC S9(4) COMP-5.
007900 01  INVEN-OPEN-L                PIC S9(4) COMP-5.
008000 01  INVEN-ALLOCATED-L           PIC S9(4) COMP-5.
008100 01  INVEN-DUE-L                 PIC S9(4) COMP-5.
008200 01  INVEN-LAST-DATE-L           PIC S9(4) COMP-5.
008300 01  INVEN-LAST-TIME-L           PIC S9(4) COMP-5.
008400 01  INVEN-LAST-USER-ID-L        PIC S9(4) COMP-5.
008500 01  UXA101-RETURN-CODE-L        PIC S9(4) COMP-5.
008600 01  UDF-SQLSTATE                PIC X(06).
008700 01  UDF-FNAME                   PIC X(28).
008800 01  UDF-FSPECNAME               PIC X(19).
008900 01  UDF-MSGTEXT                 PIC X(71).
009000/
009100 PROCEDURE DIVISION C-CALL-CONVENTION
009200     USING
009300     INVEN-LOCATION-ID
009400     INVEN-ITEM-ID
009500     INVEN-MATERIAL-TYPE
009600     INVEN-OWNER
009700     INVEN-VENDOR
009800     INVEN-RESTOCK-BRANCH
009900     INVEN-BLEED-DOWN
010000     INVEN-BLEED-DOWN-COST
010100     INVEN-CAPITOL-SPARES
010200     INVEN-OPEN
010300     INVEN-ALLOCATED
010400     INVEN-DUE
010500     INVEN-LAST-DATE
010600     INVEN-LAST-TIME
010700     INVEN-LAST-USER-ID
010800     UXA101-RETURN-CODE
010900     INVEN-LOCATION-ID-L
011000     INVEN-ITEM-ID-L
011100     INVEN-MATERIAL-TYPE-L
011200     INVEN-OWNER-L
011300     INVEN-VENDOR-L
011400     INVEN-RESTOCK-BRANCH-L
011500     INVEN-BLEED-DOWN-L
011600     INVEN-BLEED-DOWN-COST-L
011700     INVEN-CAPITOL-SPARES-L
011800     INVEN-OPEN-L
011900     INVEN-ALLOCATED-L
012000     INVEN-DUE-L
012100     INVEN-LAST-DATE-L
012200     INVEN-LAST-TIME-L
012300     INVEN-LAST-USER-ID-L
012400     UXA101-RETURN-CODE-L
012500     UDF-SQLSTATE
012600     UDF-FNAME
012700     UDF-FSPECNAME
012800     UDF-MSGTEXT.
012900/
013000*****************************************************************
013100* CSA.INVENTORY - INSERT - AFTER                                *
013200*****************************************************************
013300 0000-CONTROL SECTION.
013400*
013500 0010-DATE-TIME.
013600     MOVE ZEROES                 TO UXA101-RETURN-CODE.
013700     MOVE ZEROES                 TO UXA101-RETURN-CODE-L.
013800     ACCEPT THE-DATE             FROM DATE.
013900     ACCEPT THE-TIME             FROM TIME.
014000*
014100 0020-VXAUP-LOG.
014200     MOVE SPACES                 TO VXAUP-LOG-RECORD.
014300     STRING 'UXA101 - '             DELIMITED BY SIZE
014400            'INVOKED FOR INVENTORY' DELIMITED BY SIZE
014500            ' INSERT (AFTER) ON '   DELIMITED BY SIZE
014600            THE-DATE                DELIMITED BY SIZE
014700            ' AT '                  DELIMITED BY SIZE
014800            THE-TIME                DELIMITED BY SIZE
014900            '.'                     DELIMITED BY SIZE
015000            INTO VXAUP-LOG-RECORD.
015100     PERFORM 0100-VXAUP-LOG-WRITE.
015200*
015300 0030-VXAUP-DAT.
015400     MOVE LOW-VALUES             TO XA101.
015500     MOVE '101'                  TO XA101-TRANSACTION.
015600     MOVE UDF-FNAME              TO XA101-UDF-FNAME.
015700     MOVE THE-DATE               TO XA101-TXN-DATE.
015800     MOVE THE-TIME               TO XA101-TXN-TIME.
015900     IF   INVEN-LOCATION-ID-L    IS NUMERIC
016000      AND INVEN-LOCATION-ID-L    IS LESS THAN ZEROES
016100          NEXT SENTENCE
016200     ELSE MOVE INVEN-LOCATION-ID TO XA101-LOCATION-ID.
016300     IF   INVEN-ITEM-ID-L        IS NUMERIC
016400      AND INVEN-ITEM-ID-L        IS LESS THAN ZEROES
016500          NEXT SENTENCE
016600     ELSE MOVE INVEN-ITEM-ID     TO XA101-ITEM-ID.
016700     IF   INVEN-MATERIAL-TYPE-L  IS NUMERIC
016800      AND INVEN-MATERIAL-TYPE-L  IS LESS THAN ZEROES
016900          NEXT SENTENCE
017000     ELSE MOVE INVEN-MATERIAL-TYPE
017100                                 TO XA101-MATERIAL-TYPE.
017200     IF   INVEN-OWNER-L          IS NUMERIC
017300      AND INVEN-OWNER-L          IS LESS THAN ZEROES
017400          NEXT SENTENCE
017500     ELSE MOVE INVEN-OWNER       TO XA101-OWNER.
017600     IF   INVEN-VENDOR-L         IS NUMERIC
017700      AND INVEN-VENDOR-L         IS LESS THAN ZEROES
017800          NEXT SENTENCE
017900     ELSE MOVE INVEN-VENDOR      TO XA101-VENDOR.
018000     IF   INVEN-RESTOCK-BRANCH-L IS NUMERIC
018100      AND INVEN-RESTOCK-BRANCH-L IS LESS THAN ZEROES
018200          NEXT SENTENCE
018300     ELSE MOVE INVEN-RESTOCK-BRANCH
018400                                 TO XA101-RESTOCK-BRANCH.
018500     IF   INVEN-BLEED-DOWN-L     IS NUMERIC
018600      AND INVEN-BLEED-DOWN-L     IS LESS THAN ZEROES
018700          NEXT SENTENCE
018800     ELSE MOVE INVEN-BLEED-DOWN  TO XA101-BLEED-DOWN.
018900     IF   INVEN-BLEED-DOWN-COST-L
019000                                 IS NUMERIC
019100      AND INVEN-BLEED-DOWN-COST-L
019200                                 IS LESS THAN ZEROES
019300          NEXT SENTENCE
019400     ELSE MOVE INVEN-BLEED-DOWN-COST
019500                                 TO XA101-BLEED-DOWN-COST.
019600     IF   INVEN-CAPITOL-SPARES-L IS NUMERIC
019700      AND INVEN-CAPITOL-SPARES-L IS LESS THAN ZEROES
019800          NEXT SENTENCE
019900     ELSE MOVE INVEN-CAPITOL-SPARES
020000                                 TO XA101-CAPITOL-SPARES.
020100     IF   INVEN-OPEN-L           IS NUMERIC
020200      AND INVEN-OPEN-L           IS LESS THAN ZEROES
020300          NEXT SENTENCE
020400     ELSE MOVE INVEN-OPEN        TO XA101-OPEN.
020500     IF   INVEN-ALLOCATED-L      IS NUMERIC
020600      AND INVEN-ALLOCATED-L      IS LESS THAN ZEROES
020700          NEXT SENTENCE
020800     ELSE MOVE INVEN-ALLOCATED   TO
...

read more »



Fri, 01 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Quote:

> Sorry, but this isn't true with regard to Microfocus DLL's.  Microfocus
> has an emulation of the c structure/data representation called
> 'CALL-CONVENTION'.  I have attached a DB2/UDB V5.0 call from a
> User-Defined function (which expects a C calling convention and
> microfocus handles it correctly).

<- snip-of-ugly-old-style-monocase-COBOL ;-) ->

CALL-CONVENTION 0 is unnecessary... as this is the standard calling
convention for both MF Cobol and classic C.

If you need to call various WinAPI's, this construct is vital though..
but with other values..

*****
/Geir



Sat, 02 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Quote:


> > Sorry, but the standard C language does not know about DLLs and does
> > not support interfacing to other programming languages. Both is very
> > system specific. Since DLL sounds very much like Windows, I would
> > suggest that you ask in one of the Windows newsgroups out there.
> > Here is one that might get you started:

> Sorry, but this isn't true with regard to Microfocus DLL's.  

Oh yes it is. Which part of my statement do you consider to be
not true ?

I am talking about *standard C*, because this was crossposted to
the "comp.lang.c" newsgroup and there is *NO* support for mixed
language programming or DLLs in standard C. Any attempt at this
kind of support is *always* system and compiler specific.

[snippets excessively large rest of posting]

Do you consider it a good idea to flood newsgroups with such very
large postings ? Wouldn't it be nicer to demonstrate to principle
and offer the full code via e-mail or WEB page ?

Stephan
(initiator of the campaign against grumpiness in c.l.c)



Sat, 02 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Calling the DLL is not the problem, getting the data types right is. :)
C and COBOL have radically different data types, although MF COBOL can
emulate most of the C data types. COBOL also uses fixed-length strings,
which can be a problem. COBOL has no pointers, although newer
versions have an explicit POINTER type, function pointers, and
other stuff borrowed from C.

The biggest gotcha is that MF COBOL stores binary words in *MAINFRAME*
byte order, regardless of the platform. Intel machines use the opposite
byte order. You can either use the non-standard (or if it is standard,
little-used) COMP-5 in COBOL to use the *native* byte order, or use
COMP and write endian conversion routines on the C end. It's vital to
realize this if you are using Intel or trying to write portable C code
that will follow your MF COBOL app around to different platforms.
You'll wake up one day and nothing will work on an Intel machine and
you'll have no idea why if you don't realize this.

Scott
--
Look at Softbase Systems' client/server tools, www.softbase.com
Check out the Essential 97 package for Windows 95 www.skwc.com/essent
All my other cool web pages are available from that site too!
My demo tape, artwork, poetry, The Windows 95 Book FAQ, and more.



Sat, 02 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Quote:

>Calling the DLL is not the problem, getting the data types right is.
>  some snippage <
>The biggest gotcha is that MF COBOL stores binary words in *MAINFRAME*
>byte order, regardless of the platform. Intel machines use the opposite
>byte order. You can either use the non-standard (or if it is standard,
>little-used) COMP-5 in COBOL to use the *native* byte order, or use
>COMP and write endian conversion routines on the C end. It's vital to
>realize this if you are using Intel or trying to write portable C code
>that will follow your MF COBOL app around to different platforms.
>You'll wake up one day and nothing will work on an Intel machine and
>you'll have no idea why if you don't realize this.

>Scott
>--
>Look at Softbase Systems' client/server tools, www.softbase.com
>Check out the Essential 97 package for Windows 95 www.skwc.com/essent
>All my other cool web pages are available from that site too!
>My demo tape, artwork, poetry, The Windows 95 Book FAQ, and more.

If your Micro Focus "USAGE BINARY" (currently the only COBOL Standard binary
data type) is being stored in MAINFRAME (big-endian) format, then I suggest
that you check your compiler options.  You are probably using the IBMCOMP
compiler options which is going to cause you MANY more problems than just
this - if your intent is to develop portable many-platform COBOL/C
applications.  (Of course, if your target is an IBM OpenMVS system, you may
still want to use it - but even for IBM AIX it isn't the correct compiler
option.)

Note: As the original post was a question explicitly about using Micro Focus
COBOL, then all the data types that you mention are no problem at all.  They
already support pointers, procedure-pointers, RETURNING values, parameters
passed by VALUE , etc. I would be first to admit that if the original
question concerned using "Standard COBOL," many of these items would be a
problem today - which is why they are being addressed by the current draft
of the next COBOL Standard.



Sat, 02 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

While your point about it not being standar "C" is correct, that's not
really the point here.  This was a "how do you do that" deal and the
poster took the opportunity to use your post to respond and add the
necessary information.  It's a nice thing to do.  I can't tell you the
number of time, I have found these code examples and large postings to
be invaluable.

Quote:
> Do you consider it a good idea to flood newsgroups with such very
> large postings ? Wouldn't it be nicer to demonstrate to principle
> and offer the full code via e-mail or WEB page ?

> Stephan
> (initiator of the campaign against grumpiness in c.l.c)

Your remark kind of violates your signature line.

Thane - revelator of grumps



Sat, 02 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Quote:


> While your point about it not being standar "C" is correct, that's not
> really the point here.  This was a "how do you do that" deal and the
> poster took the opportunity to use your post to respond and add the
> necessary information.  It's a nice thing to do.  I can't tell you the
> number of time, I have found these code examples and large postings to
> be invaluable.

> > Do you consider it a good idea to flood newsgroups with such very
> > large postings ? Wouldn't it be nicer to demonstrate to principle
> > and offer the full code via e-mail or WEB page ?

> > Stephan
> > (initiator of the campaign against grumpiness in c.l.c)

> Your remark kind of violates your signature line.

> Thane - revelator of grumps

Thanks for defending my posting; and, "well said" at that! :)
I hope the 'snippet of ugly monocase COBOL' was helpful to someone!
Maybe the call-convention isn't required for some C++ programs, but
since DB2/2 UDB requires a C call convention and data type structure I
found it to be necessary (and especially the COMP-5 data type you'll
notice buried in the code) for datalengths, etc.  Be extremely careful
using COMP-3 type structures because they inevitably have low-values in
them that don't exactly work in C (one of the strange things about
mixing languages, I guess, that got me once).


Sat, 02 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Quote:

>  I would be first to admit that if the original
> question concerned using "Standard COBOL," many of these items would be a
> problem today - which is why they are being addressed by the current draft
> of the next COBOL Standard.

Are you saying that the draft COBOL Standard addresses parameter passing
between languages?  Well it's about time!  Currently, it is possible to
write a system which uses Standard COBOL and Standard Fortan and
Standard C and Standard Pascal, but even though every bit of every
program adheres to the standard, it's a major conversion to rehost the
system because all the standards have incompatible definitions of data.

I'm glad that the standardizers have seen the light, and realize it is
not possible to have two truly standardized languages until you have
standardized the passing of data between them.

And DLLs too!  I'm glad that COBOL will finally have syntax for calling
and defining DLLs.  The closest thing the existing standard has is the
1974 IPC mechanism, which is hard to implement on every known platform,
and far less useful mechanisms that are easy to implemenet.  But the DLL
interface is kewl; it's a lot like the library mechanism on Unisys A
Series.  I'm glad that's in the COBOL draft.

--

L  |/   I prefer the word "Sardonic"  8^)

v  | \  1-310-542-6013                       Please reply without spam
e    |\
Y    |/ Panic in the Year Zero Zero:  http://members.aol.com/PanicYr00
o    |\ 33rd term revealed.  Is it easy yet?:
u    |/                 http://members.aol.com/PanicYr00/Sequence.html



Sat, 02 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Quote:

>While your point about it not being standar "C" is correct, that's not
>really the point here.

This is often a point that is made here in comp.lang.c.  I would not
be surprised if comp.lang.cobol follows a different philosophy.

Quote:
>This was a "how do you do that" deal and the poster took the
>opportunity to use your post to respond and add the necessary
>information.  It's a nice thing to do.  I can't tell you the number
>of time, I have found these code examples and large postings to be
>invaluable.

This may be true, but you weren't listening to Stephan.  He was not
against the poster providing an example, just a different medium for
doing so.

Quote:
>> Do you consider it a good idea to flood newsgroups with such very
>> large postings ? Wouldn't it be nicer to demonstrate to principle
>> and offer the full code via e-mail or WEB page ?

>> Stephan
>> (initiator of the campaign against grumpiness in c.l.c)

This is often a very sensible thing to do, especially for examples of
a large-ish nature.  Certainly it's nice to show someone how to do
something.  But, it probably would have been nicer to post such a
large COBOL listing exclusively in comp.lang.cobol rather than cross
posted to comp.lang.c.  And, Stephan suggests that he would have not
objected if the post had simply provided a pointer to the COBOL
implementation.

Quote:
>Your remark kind of violates your signature line.

>Thane - revelator of grumps

There was nothing grumpy about his request.  He asked what would be a
nicer thing to do.

I have redirected followups to comp.lang.c.

--

http://www.cs.wustl.edu/~jxh/        Washington University in Saint Louis

Quote:
>>>>>>>>>>>>> I use *SpamBeGone* <URL:http://www.internz.com/SpamBeGone/>



Sun, 03 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Sorry for being misleading.  The datatypes should be handled (by the draft
Standard) - but the DLLs won't be - at least I don't think they will be. I
have never really understood all the problems with calling DLLs versus other
CALLs so this may be solved by some of the new features, e.g.
CALLING-CONVENTIONS but I don't know for certain.  I should also add that
MUCH of the new "inter-language" support is still implementor defined (for
semantics) but the syntax will (finally) be portable.

--
+ +
+   Bill Klein -
         "C" is a nice letter to START the name of your programming language
with
      but I wouldn't want to end up there.

Quote:


>>  I would be first to admit that if the original
>> question concerned using "Standard COBOL," many of these items would be a
>> problem today - which is why they are being addressed by the current
draft
>> of the next COBOL Standard.

>Are you saying that the draft COBOL Standard addresses parameter passing
>between languages?  Well it's about time!  Currently, it is possible to
>write a system which uses Standard COBOL and Standard Fortan and
>Standard C and Standard Pascal, but even though every bit of every
>program adheres to the standard, it's a major conversion to rehost the
>system because all the standards have incompatible definitions of data.

>I'm glad that the standardizers have seen the light, and realize it is
>not possible to have two truly standardized languages until you have
>standardized the passing of data between them.

>And DLLs too!  I'm glad that COBOL will finally have syntax for calling
>and defining DLLs.  The closest thing the existing standard has is the
>1974 IPC mechanism, which is hard to implement on every known platform,
>and far less useful mechanisms that are easy to implemenet.  But the DLL
>interface is kewl; it's a lot like the library mechanism on Unisys A
>Series.  I'm glad that's in the COBOL draft.

>--

>L  |/   I prefer the word "Sardonic"  8^)

>v  | \  1-310-542-6013                       Please reply without spam
>e    |\
>Y    |/ Panic in the Year Zero Zero:  http://members.aol.com/PanicYr00
>o    |\ 33rd term revealed.  Is it easy yet?:
>u    |/                 http://members.aol.com/PanicYr00/Sequence.html



Sun, 03 Sep 2000 03:00:00 GMT  
 C calling MicroFocus DLL

Quote:

> Are you saying that the draft COBOL Standard addresses parameter passing
> between languages?

It attempts to do so without specifically stating what language is being
called.

Quote:
> Well it's about time!  Currently, it is possible to
> write a system which uses Standard COBOL and Standard Fortan and
> Standard C and Standard Pascal, but even though every bit of every
> program adheres to the standard, it's a major conversion to rehost the
> system because all the standards have incompatible definitions of data.

That problem still exists.

Quote:
> I'm glad that the standardizers have seen the light, and realize it is
> not possible to have two truly standardized languages until you have
> standardized the passing of data between them.

We standardizers have not seen the light completely.  There was an
attempt to define a standard calling protocol as well as standard data
types at ISO (ISO/IEC JTC 1/SC22/WG11 - I was convenor of the group for
a while), but it more or less was ignored by all but the COBOL standards
group.  The C group apparently felt that they were the only language
that mattered so they had no interest in communication with other
langugages.

Quote:
> And DLLs too!  I'm glad that COBOL will finally have syntax for calling
> and defining DLLs.  The closest thing the existing standard has is the
> 1974 IPC mechanism, which is hard to implement on every known platform,

I never had trouble implementing it on about six different platforms.  I
wonder what is hard.

Quote:
> and far less useful mechanisms that are easy to implemenet.  But the DLL
> interface is kewl; it's a lot like the library mechanism on Unisys A
> Series.  I'm glad that's in the COBOL draft.

I assume by DLL you mean the REPOSITORY paragraph (which is not related
to the classical definition of a DLL).  Tandem COBOL has an even cooler
method that figures out what you are calling and coerces the calling
mechanism and parameters into what that expects.  The REPOSITORY can
accomplish the same thing.  There was also an attempt at ISO to
standardize repositories but that never got all that far primarly due to
resistance by the language groups (mainly C and Ada).

--
Don Nelson
COBOL Development, Tandem Computers, Inc.
Member, NCITS J4 and ISO/IEC JTC1/SC22 WG4 COBOL Committees

No clever quotes here



Sun, 03 Sep 2000 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Microfocus dll called from Java eats memory

2. MicroFocus calls to third party DLL's

3. Calling a VB5 DLL from Microfocus COBOL

4. Calling Windows DLL from MicroFocus Cobol

5. Microfocus calling DLLs

6. How to setup a procedure in a DLL that calls a procedure in another DLL

7. to CS: or not to CS: in F-PC assembler

8. Help on Net Express COBOL dll and calling the DLL from VB program

9. Intel complier for calling DLL and build Dll

10. Mixed Language - DVF 6.0 DLL calling Delphi4 DLL

11. VC++ dlls calling FORTRAN dlls

12. Calling DLLs from TCL using ffidl or dll - please help

 

 
Powered by phpBB® Forum Software