VB5 Strange Behaviour When Calling Cobol DLL 
Author Message
 VB5 Strange Behaviour When Calling Cobol DLL

I have a DLL that I've created using Micro Focus Cobol (v4).  I'm calling a
routine in the DLL that is expecting a large string (> 1k) to be passed by
reference.  When I call this routine from a Visual Basic 5 program, I get a
lot of strange behaviour.  Often the entire VB IDE just shuts down without a
word of warning.  Other times (varied by changing the size of the string
parameter that is being passed) I get a VB warning saying that I'm passing
the wrong number of parameters, or using the wrong calling convention to
reach the DLL.  I am as certain as I can be that the data area being passed
from VB, and the data area expected by the Cobol DLL, are identical.

What I'm not certain of is that I'm using the correct call convention.  Does
anyone know the specifics of VB5's calling convention?  Does it push
parameters onto the stack left-to-right, or right-to-left (although with
only 1 parameter in my case, this shouldn't matter)?  Does it expect the
called routine to clean up the stack?

It gets stranger, though:  if I reduce the size of the string enough, it
works!!  I can't figure out why.  Using several different Cobol DLL's that
I've created, each of them has a different, but very specific (e.g. 683
bytes in one case), size of string that it will accept.  If the string is
even 1 byte longer, the whole thing bombs.

And it gets worse:  In VB, I have some code like this:

   Declare Sub CobolDLL Lib "MyCobol.DLL" Alias "MyCobol"

   Dim MyParmString as MyParmStringType

   MyParmString = "Stuff"
   call CobolDLL_X(MyParmString)

   Sub CobolDLL_X(ParmString as MyParmStringType)
      call CobolDLL(ParmString)
   End Sub

This above code causes the behaviour I've mentioned above.  However, if I
call CobolDLL directory, instead of indirectly going through the routine
CobolDLL_X, I have no problems!  Does anyone know what's up with that?

Any ideas would be greatly appreciated!  Thanks,

Paul



Mon, 30 Apr 2001 03:00:00 GMT  
 VB5 Strange Behaviour When Calling Cobol DLL
Quote:

> I have a DLL that I've created using Micro Focus Cobol (v4).  I'm calling a
> routine in the DLL that is expecting a large string (> 1k) to be passed by
> reference.  When I call this routine from a Visual Basic 5 program, I get a
> lot of strange behaviour.  Often the entire VB IDE just shuts down without a
> word of warning.  Other times (varied by changing the size of the string
> parameter that is being passed) I get a VB warning saying that I'm passing
> the wrong number of parameters, or using the wrong calling convention to
> reach the DLL.  I am as certain as I can be that the data area being passed
> from VB, and the data area expected by the Cobol DLL, are identical.

> What I'm not certain of is that I'm using the correct call convention.  Does
> anyone know the specifics of VB5's calling convention?  Does it push
> parameters onto the stack left-to-right, or right-to-left (although with
> only 1 parameter in my case, this shouldn't matter)?  Does it expect the
> called routine to clean up the stack?

> It gets stranger, though:  if I reduce the size of the string enough, it
> works!!  I can't figure out why.  Using several different Cobol DLL's that
> I've created, each of them has a different, but very specific (e.g. 683
> bytes in one case), size of string that it will accept.  If the string is
> even 1 byte longer, the whole thing bombs.

> And it gets worse:  In VB, I have some code like this:

>    Declare Sub CobolDLL Lib "MyCobol.DLL" Alias "MyCobol"

>    Dim MyParmString as MyParmStringType

>    MyParmString = "Stuff"
>    call CobolDLL_X(MyParmString)

>    Sub CobolDLL_X(ParmString as MyParmStringType)
>       call CobolDLL(ParmString)
>    End Sub

> This above code causes the behaviour I've mentioned above.  However, if I
> call CobolDLL directory, instead of indirectly going through the routine
> CobolDLL_X, I have no problems!  Does anyone know what's up with that?

> Any ideas would be greatly appreciated!  Thanks,

> Paul

I'm just guessing with limited VB experience, but you haven't defined
what type of object MyParmStringType is.  Do you need to define it as a
string variable with a specific length ?  I think your definition
creates a variant type, with perhaps extra bytes associated to define
it's length.  Try defining it as string, with a length of 256 (which may
be a max for string, I don't know), and see how it operates.

Bob
--
----------------------------------------------------------------------
                  Bob Berman   -    West Hartford, CT                

                  THE TRUE TERRORISTS IN AMERICA ARE                  
          THE PEOPLE WHO DEMAND TO SEE THE STORE MANAGER !            
----+----+----+----+----+----+----+----+----+----+----+----+----+----+



Mon, 30 Apr 2001 03:00:00 GMT  
 VB5 Strange Behaviour When Calling Cobol DLL

Quote:
>I'm just guessing with limited VB experience, but you haven't defined
>what type of object MyParmStringType is.  Do you need to define it as a
>string variable with a specific length ?  I think your definition

You're quite right, I forgot that bit...but only in my example.  I've got
that type defined as a group of fixed-length strings, something like this:

Type MyParmStringType
   Parm1 as string * 1
   Parm2 as string * 80
   Parm3 as string * 5
End Type



Mon, 30 Apr 2001 03:00:00 GMT  
 VB5 Strange Behaviour When Calling Cobol DLL
vb passes parameters using the Pascal calling convention.

assuming : Declare Sub CobolDLL Lib "MyCobol.DLL" Alias "MyCobol"

you can't use: call CobolDLL(ParmString)

assuming :  Type MyParmStringType
                        Parm1 as string * 1
                        Parm2 as string * 80
                        Parm3 as string * 5
                     End Type

you can't use : MyParmString = "Stuff"

er.. which version of vb are you using ?

Quote:

>   Declare Sub CobolDLL Lib "MyCobol.DLL" Alias "MyCobol"

> Type MyParmStringType
>    Parm1 as string * 1
>    Parm2 as string * 80
>    Parm3 as string * 5
> End Type

>   Dim MyParmString as MyParmStringType

>   MyParmString = "Stuff"
>   call CobolDLL_X(MyParmString)

>   Sub CobolDLL_X(ParmString as MyParmStringType)
>      call CobolDLL(ParmString)
>   End Sub



Mon, 30 Apr 2001 03:00:00 GMT  
 VB5 Strange Behaviour When Calling Cobol DLL

Quote:

(snip)>
>Type MyParmStringType
>   Parm1 as string * 1
>   Parm2 as string * 80
>   Parm3 as string * 5
>End Type

Without thinking about this more than a few seconds ...... be aware that
internally VB5 aligns structure members on 4-byte boundaries, so variables
of the above type actually take 92 bytes in memory. Is your Cobol compiler
set to pack the same way?


Mon, 30 Apr 2001 03:00:00 GMT  
 VB5 Strange Behaviour When Calling Cobol DLL

Quote:

>Without thinking about this more than a few seconds ...... be aware that
>internally VB5 aligns structure members on 4-byte boundaries, so variables
>of the above type actually take 92 bytes in memory. Is your Cobol compiler
>set to pack the same way?

!! This is useful information !!  Are you sure about this?  I'm using VB5.
I'm quite certain that the Cobol compiler is not aligning on DW
boundaries....Also, I know that VB does some internal conversion (especially
to convert Unicode to ASCII) before calling any subroutine/function, so
maybe it unaligns the data in a separate workspace before pushing the
address on the stack?


Tue, 01 May 2001 03:00:00 GMT  
 VB5 Strange Behaviour When Calling Cobol DLL

Quote:

>vb passes parameters using the pascal calling convention.

Thanks.  Do you know if VB5 is like this as well?

Quote:
>assuming : Declare Sub CobolDLL Lib "MyCobol.DLL" Alias "MyCobol"

>you can't use: call CobolDLL(ParmString)

Hmmm, I missed some stuff while trying to simplify!  I actually have
something more like this:

   Declare Sub CobolDLL Lib "MyCobol.DLL" Alias "MyCobol" (ParmString as
MyParmStringType)

I think that makes a bit more sense.

Quote:
>assuming :  Type MyParmStringType
>                        Parm1 as string * 1
>                        Parm2 as string * 80
>                        Parm3 as string * 5
>                     End Type

>you can't use : MyParmString = "Stuff"

Same again.  I actually populate the submembers, rather than the parent data
type directly.  Sorry for the confusion.

Quote:
>er.. which version of vb are you using ?

VB5

Thanks for looking!

Paul

Quote:

>>   Declare Sub CobolDLL Lib "MyCobol.DLL" Alias "MyCobol"

>> Type MyParmStringType
>>    Parm1 as string * 1
>>    Parm2 as string * 80
>>    Parm3 as string * 5
>> End Type

>>   Dim MyParmString as MyParmStringType

>>   MyParmString = "Stuff"
>>   call CobolDLL_X(MyParmString)

>>   Sub CobolDLL_X(ParmString as MyParmStringType)
>>      call CobolDLL(ParmString)
>>   End Sub



Tue, 01 May 2001 03:00:00 GMT  
 VB5 Strange Behaviour When Calling Cobol DLL
<<...internally VB5 aligns structure members on 4-byte boundaries...>>

Quote:
>!! This is useful information !!  Are you sure about this?  I'm using VB5.
>I'm quite certain that the Cobol compiler is not aligning on DW
>boundaries....Also, I know that VB does some internal conversion
(especially
>to convert Unicode to ASCII) before calling any subroutine/function, so
>maybe it unaligns the data in a separate workspace before pushing the
>address on the stack?

Yes, I'm sure about it. I think you're probably correct, though, that VB
unaligns the data before making a DLL call. So, it may not be an issue for
you.

I ran into the alignment problem in a convoluted kinda way - I had found
that VB5 will not do an "OPEN xxx FOR BINARY ACCESS READ" on a file that's
on a network device which is shared read-only (as opposed to full), so I
wrote a small C routine in a DLL that opens a file and gets binary data. I
was "getting" it into a VB user-defined-type containing a mix of ints,
longs, and fixed strings....

Unlike a regular VB "Get", which transparently unpacks the binary data and
puts it into the correct variables in a structure, my function ("MyFileGet")
puts the raw data directly into memory beginning at the start of the
structure. Because of the internal 4-byte alignment of the structure
members, some of the data ends up in the wrong place.

I did some research and found out that the 4-byte alignment is documented.
There's no compiler option to change it.



Thu, 03 May 2001 03:00:00 GMT  
 VB5 Strange Behaviour When Calling Cobol DLL

Quote:

>I have a DLL that I've created using Micro Focus Cobol (v4).  I'm calling a
>routine in the DLL that is expecting a large string (> 1k) to be passed by
>reference.  When I call this routine from a Visual Basic 5 program, I get a
>lot of strange behaviour.  Often the entire VB IDE just shuts down without a
>word of warning.  Other times (varied by changing the size of the string
>parameter that is being passed) I get a VB warning saying that I'm passing
>the wrong number of parameters, or using the wrong calling convention to
>reach the DLL.  I am as certain as I can be that the data area being passed
>from VB, and the data area expected by the Cobol DLL, are identical.
>What I'm not certain of is that I'm using the correct call convention.  Does
>anyone know the specifics of VB5's calling convention?  Does it push
>parameters onto the stack left-to-right, or right-to-left (although with
>only 1 parameter in my case, this shouldn't matter)?  Does it expect the
>called routine to clean up the stack?
>It gets stranger, though:  if I reduce the size of the string enough, it
>works!!  I can't figure out why.  Using several different Cobol DLL's that
>I've created, each of them has a different, but very specific (e.g. 683
>bytes in one case), size of string that it will accept.  If the string is
>even 1 byte longer, the whole thing bombs.
>And it gets worse:  In VB, I have some code like this:
>   Declare Sub CobolDLL Lib "MyCobol.DLL" Alias "MyCobol"
>   Dim MyParmString as MyParmStringType
>   MyParmString = "Stuff"
>   call CobolDLL_X(MyParmString)
>   Sub CobolDLL_X(ParmString as MyParmStringType)
>      call CobolDLL(ParmString)
>   End Sub
>This above code causes the behaviour I've mentioned above.  However, if I
>call CobolDLL directory, instead of indirectly going through the routine
>CobolDLL_X, I have no problems!  Does anyone know what's up with that?
>Any ideas would be greatly appreciated!  Thanks,
>Paul

I have been working with VB calling COBOL for some time now, and the
first and most important thing I have found is that you must ensure
that any parameters passed have a length of a multiple of 4.

This even goes as far as passing numeric data. If you want it to work,
and work reliably, then convert all numbers to usage display items
with a multiple of four bytes, and do the same with the UDT in your VB
program. Ensure that your linkge section and the UDT match exactly,
and you will be OK.

We also have a number of utilities which will convert a COBOL FD
copybook into VB UDT's with all the support code which goes along with
them.

The attatched .ZIP may give you some ideas

Best regards,

Gordon Wallace.



Sat, 05 May 2001 03:00:00 GMT  
 VB5 Strange Behaviour When Calling Cobol DLL

Quote:


>>I have a DLL that I've created using Micro Focus Cobol (v4).  I'm calling
a
>>routine in the DLL that is expecting a large string (> 1k) to be passed by
>>reference.  When I call this routine from a Visual Basic 5 program, I get
a
>>lot of strange behaviour.  Often the entire VB IDE just shuts down without
a
>>word of warning.  Other times (varied by changing the size of the string
>>parameter that is being passed) I get a VB warning saying that I'm passing
>>the wrong number of parameters, or using the wrong calling convention to
>>reach the DLL.  I am as certain as I can be that the data area being
passed
>>from VB, and the data area expected by the Cobol DLL, are identical.

>>What I'm not certain of is that I'm using the correct call convention.
Does
>>anyone know the specifics of VB5's calling convention?  Does it push
>>parameters onto the stack left-to-right, or right-to-left (although with
>>only 1 parameter in my case, this shouldn't matter)?  Does it expect the
>>called routine to clean up the stack?

>>It gets stranger, though:  if I reduce the size of the string enough, it
>>works!!  I can't figure out why.  Using several different Cobol DLL's that
>>I've created, each of them has a different, but very specific (e.g. 683
>>bytes in one case), size of string that it will accept.  If the string is
>>even 1 byte longer, the whole thing bombs.

>>And it gets worse:  In VB, I have some code like this:

>>   Declare Sub CobolDLL Lib "MyCobol.DLL" Alias "MyCobol"

>>   Dim MyParmString as MyParmStringType

>>   MyParmString = "Stuff"
>>   call CobolDLL_X(MyParmString)

>>   Sub CobolDLL_X(ParmString as MyParmStringType)
>>      call CobolDLL(ParmString)
>>   End Sub

>>This above code causes the behaviour I've mentioned above.  However, if I
>>call CobolDLL directory, instead of indirectly going through the routine
>>CobolDLL_X, I have no problems!  Does anyone know what's up with that?

>>Any ideas would be greatly appreciated!  Thanks,

>>Paul

>I have been working with VB calling COBOL for some time now, and the
>first and most important thing I have found is that you must ensure
>that any parameters passed have a length of a multiple of 4.

>This even goes as far as passing numeric data. If you want it to work,
>and work reliably, then convert all numbers to usage display items
>with a multiple of four bytes, and do the same with the UDT in your VB
>program. Ensure that your linkge section and the UDT match exactly,
>and you will be OK.

>We also have a number of utilities which will convert a COBOL FD
>copybook into VB UDT's with all the support code which goes along with
>them.

>The attatched .ZIP may give you some ideas

>Best regards,

>Gordon Wallace.

attatched .ZIP ?  vbdem.zip didn't appear with your posting in my newsreader
(Outlook Express running as an adjunct to Outlook 98.)  Did you really send
it, or did my newsgroup server (at MSN) screen it out?


Sun, 06 May 2001 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Calling Visual Object Cobol DLL′s From VB5

2. calling a MF COBOL .dll (ver 3.2.50) from VB5

3. Calling a VB5 DLL from Microfocus COBOL

4. MF-COBOL and DLL's: Call shows strange errors

5. VB5 calling CW4 DLLs

6. MF COBOL CALLED FROM VB5

7. Strange Cobol-behaviour

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

9. Salford F77 + VB5/6 ..DLL possible?

10. RM/COBOL, VB5 and VanGui problem

11. Calling fortran routine in VB5

12. Calling COBOL DLL from JAVA

 

 
Powered by phpBB® Forum Software