COBOL binds by calling the core library like any other external routine, using the CALL statement with BY VALUE and BY REFERENCE as appropriate. This works on distributed COBOL — Micro Focus, GnuCOBOL and similar — where a USB device is physically reachable.
WORKING-STORAGE SECTION.
COPY KEYNUB.
PROCEDURE DIVISION.
CALL "licdf_open" USING BY REFERENCE WS-SERIAL
RETURNING KN-HANDLE
IF KN-HANDLE NOT > 0
DISPLAY "No KeyNub license dongle found"
MOVE 16 TO RETURN-CODE
STOP RUN
END-IF
CALL "licdf_session_open" USING BY VALUE KN-HANDLE
RETURNING KN-STATUS
CALL "licdf_close" USING BY VALUE KN-HANDLE
RETURNING KN-STATUS.Code language: PHP (php)Where This Applies, and Where It Does Not
To be straightforward: this is for COBOL running on Windows, Linux or a Unix where a USB dongle can be attached. If your COBOL runs on z/OS, a USB device in a laptop is not the answer to your licensing question and we will not pretend otherwise.
Where it does apply, the usual situation is a vendor-supplied COBOL business application installed at customer sites, where the licensed instance count has drifted over the years and nobody can prove what it should be. A dongle per installation makes that countable again without rewriting anything.
Getting the Library Loaded
One deployment detail costs more time here than anything else. GnuCOBOL resolves CALL targets at run time through libcob rather than at link time, so linking the native library into the executable is not enough: name it in COB_PRE_LOAD, without its prefix or file extension, and point COB_LIBRARY_PATH at the directory holding it. Get that wrong and the failure is a module-not-found error at run time, which reads like a missing program rather than a missing library.
The binding ships as a copybook you COPY into working storage, carrying the status codes, the flag bits and the picture clauses, and is verified with GnuCOBOL 3.2.
Shipping the Native Library with a COBOL Application
The binding is a copybook over the SDK’s flat API, verified with GnuCOBOL 3.2. Nothing is linked at compile time: GnuCOBOL resolves CALL "licdf_..." by name at run time, so the platform’s keynub_licdongle_flat library must be on the runtime’s module path (COB_LIBRARY_PATH) or on the system search path. Use COMP-5 for the integer arguments, not COMP.
On Windows, a MinGW-built GnuCOBOL and an MSVC-built library use different C runtimes; the SDK’s flat API passes only integers, pointers and caller-owned buffers across that boundary. On Linux, install the udev rule from NATIVES.md once, so that ordinary users may open the device.
Questions COBOL Developers Ask
Which COBOL Compilers Does the Binding Support?
GnuCOBOL 3.2 is verified; the calling conventions are the standard ones for CALL with BY REFERENCE and BY VALUE, so other compilers that call C by name apply.
Can a COBOL Program on a PC Be Protected with a Hardware Dongle?
Yes. Rate tables, fee schedules and calculation parameters are what a COBOL program lives on; ship them sealed with the dongle and decrypt them at start, so that the program has nothing to compute with unless the dongle is present.
Does a COBOL Application Need Administrator Rights to Talk to the Dongle?
No, and no driver either: the dongle is a USB HID device that the operating systems handle with their built-in class drivers. On Linux, install the shipped udev rule once so that ordinary users may open it; without the rule the SDK reports access denied and names the cause in its error detail.
Does a COBOL License Check Need an Internet Connection?
No. Verification is a local exchange between your program and the dongle over USB: the SDK checks the dongle’s certificate chain to KeyNub’s root and runs a live challenge-response. There is no activation server and no account, so the check works on air-gapped machines.
Who Can Read the License Records on a Dongle?
Anyone holding the dongle: a program opens a session and reads records, and can decrypt data sealed for that dongle. Writing records, erasing them and incrementing counters need your write key. What the dongle guarantees is that none of it is available without the dongle present.
Can a License Written from COBOL Be Read by a Program in Another Language?
Yes. Every binding drives the same core library and the same dongle, and records and sealed data are language-neutral bytes. Your issuing tool can be written in one language and your product in another.
Code
Runnable sample: cobol/verify-and-read.cbl. Binding source: bindings/cobol. Both are Apache-2.0, in the public SDK repository; the prebuilt native libraries are in the repository’s natives/ folder, one per platform.
All supported languages · All industries · Buy a KeyNub · Ask us something
