I have a socket application that was written in VB (to which I don't have access to the source code) that calls a Progress application, which calls an external C library function that puts messages to IBM WebSphere. The C library function works fine from dozens of other Progress applications, but gets a Memory Violation when its called by this "socket program".
The library is called by a .i file which looks like:
&GLOBAL-DEFINE libmq "/path/to/library.so"
PROCEDURE send_q EXTERNAL {&libmq} CDECL :
define input parameter dest as char.
define input parameter msg as char.
define input parameter msgLen as long.
define return parameter returnStatus as long.
END PROCEDURE.
I tried executing the procedure using hard coded values that are known to work in other programs and I get the same memory violation.
Any direction would be appreciated.
I have a socket application that was written in VB (to which I don't have access to the source code) that calls a Progress application, which calls an external C library function that puts messages to IBM WebSphere. The C library function works fine from dozens of other Progress applications, but gets a Memory Violation when its called by this "socket program".
The library is called by a .i file which looks like:
&GLOBAL-DEFINE libmq "/path/to/library.so"
PROCEDURE send_q EXTERNAL {&libmq} CDECL :
define input parameter dest as char.
define input parameter msg as char.
define input parameter msgLen as long.
define return parameter returnStatus as long.
END PROCEDURE.
I tried executing the procedure using hard coded values that are known to work in other programs and I get the same memory violation.
Any direction would be appreciated.
Flag this post as spam/abuse.
The signature of the send_q function might provide some insight (I could look it up online, but there is no guarantee that the one I find is the one you are using).
Is there a difference in the platforms between where it works and where it doesn't? You mention VB, which AFAIK is Windows only, but the library has a .so extension suggesting unix. OS versions and bitness might be important.
When you used the known good values, did you pass them directly from ABL, or did they go through this VB program? If through the VB program, I would suggest trying them from ABL directly. If it fails only from VB, then it would suggest the values are being extracted incorrectly in the AVM prior to passing to the DLL.
You could also log a call with TS requesting assistance on the protrace.