Do you relink the ACUCOBOL-GT runtime?

What are your reasons for relinking the ACU-GT runtime?

If you're adding functionality by including C functions, is there a reason you can't create a DLL or Shared Object Library (SO) and call that instead?

If you're adding support for your own File System, is there a way we can make that easier, so that you can write your own DLL or SO instead?

Are you relinking for some other reason? What?

I am just curious.

  • We used to re-link the runtime, but now we put our C & C functions into a DLL.

    The main reason is we need non-blocking socket functions. We also implemented several other useful routines - things that are just easier to do in C than in Cobol, or are more performant in C.
  • Hi
    We have a product that emulate an HP3000 system on other platforms (HPUX, AIX, SOLARIS, LINUX,WINDOWS).
    In order to emulate this file system we trap ACUCOBOL file system access and redirect to our own File system.
    To do that we are re-linking the ACU-GT runtime to trap standard and indexed file system access.

    We also have tools that directly calls the ACU Vision file system API (v5_xxx functions).
    By the way if someone has the new v6_xxx prototyping, for C language, let me know (ACU changed their Vision API from v5_xxx to v6_xxx in ACU V10 and the API is not documented).
    Have all a nice day
    JMJ (Using ACU since ACU V5)
  • Hi Jean-Marc,

    The Vision API document and the "relink kit" have been updated for the v6_ change. You should be able to request those from tech support. Nothing other than the function names changed this time, so you can just change the function names to v6_. There is a section in vision.h that does this with macros. (The API names have historically been updated when a new file format is introduced. In the past this sometimes meant that new parameters were added, etc., but that has not happened the last few revisions.)