Skip to main content

Hi.   Did a utility program to use the RMNet libraries.  Tested with 10.3.1 in linux.  Used the librmnet64.so library.   If I use the -y method of loading the library, it works and the various "methods" are available.  eg) NetInit, HttpPost, NetFree, and NetCleanup.   But if I instead try to load it using:   call "./librmnet64.so" there is no error, but the methods are not available either.  I just get an error message: NetInit: Program missing or inaccessible

A symbol dump reveals the library has RMDLLNetInit, but trying to call that directly fails as well.

Does the library have to load via -y or am I missing a configuration option?

Hi.   Did a utility program to use the RMNet libraries.  Tested with 10.3.1 in linux.  Used the librmnet64.so library.   If I use the -y method of loading the library, it works and the various "methods" are available.  eg) NetInit, HttpPost, NetFree, and NetCleanup.   But if I instead try to load it using:   call "./librmnet64.so" there is no error, but the methods are not available either.  I just get an error message: NetInit: Program missing or inaccessible

A symbol dump reveals the library has RMDLLNetInit, but trying to call that directly fails as well.

Does the library have to load via -y or am I missing a configuration option?

Yes, you must specify the library on the command line with the y option.  The library is loaded during run unit initialization.  There is preprocessing done to establish the calling interface for the entry points.

Yes, you must specify the library on the command line with the y option.  The library is loaded during run unit initialization.  There is preprocessing done to establish the calling interface for the entry points.

Thank you.   Can you explain why this library requires different handling from other .so files?  The reference manual for CALL says: See Working with Windows Technologies and Working with C and C++ Programs for information about calling subroutines in DLLs and UNIX shared libraries. When we review that guide, it reviews various methods, and the interesting one is the 3rd method in the 2nd note "Load the DLL or shared object during program execution with a CALL statement..."

Calling C Programs in DLLs or Shared Object Libraries

The simplest way to call a C program from ACUCOBOL-GT is to:

  1. Package the routine into a Windows DLL or UNIX/Linux shared object library.
  2. Load the DLL or shared object at startup by using one of the following options:
    • Use the "-y" runtime option
    • Use the SHARED_LIBRARY_LIST runtime configuration variable
    • Load the DLL or shared object during program execution with a CALL statement or via the SHARED_LIBRARY_LIST variable and a SET ENVIRONMENT statement.

Thank you.   Can you explain why this library requires different handling from other .so files?  The reference manual for CALL says: See Working with Windows Technologies and Working with C and C++ Programs for information about calling subroutines in DLLs and UNIX shared libraries. When we review that guide, it reviews various methods, and the interesting one is the 3rd method in the 2nd note "Load the DLL or shared object during program execution with a CALL statement..."

Calling C Programs in DLLs or Shared Object Libraries

The simplest way to call a C program from ACUCOBOL-GT is to:

  1. Package the routine into a Windows DLL or UNIX/Linux shared object library.
  2. Load the DLL or shared object at startup by using one of the following options:
    • Use the "-y" runtime option
    • Use the SHARED_LIBRARY_LIST runtime configuration variable
    • Load the DLL or shared object during program execution with a CALL statement or via the SHARED_LIBRARY_LIST variable and a SET ENVIRONMENT statement.

I came from the RM branch of the family so I don't have a definitive answer.  My answer is based on the fact this module was migrated from the RM product line.  The entry points in the DLL use a parameter binding technique that is a bit more 'COBOL friendly' than a typical DLL providing a raw C-based API.

I came from the RM branch of the family so I don't have a definitive answer.  My answer is based on the fact this module was migrated from the RM product line.  The entry points in the DLL use a parameter binding technique that is a bit more 'COBOL friendly' than a typical DLL providing a raw C-based API.

Thank you.   That is plenty of explanation, and much appreciated. 

Terms & ConditionsAccessibility statement