Re: Micro Focus COBOL runtime, /clr:pure, etc.

biblepolyglotte@xxxxxxxxx wrote:

I'll definitely try the Generate Directives File setting. However, you
didn't say anything about an equivalent for /clr:pure.

We can produce pure (and verifiable) MSIL from .NET COBOL. But that's
not the same thing as not having any Micro Focus runtime requirements.

Microsoft's /clr:pure creates an assembly that contains only managed
code. (/clr by itself allows a mix of managed and unmanaged code.)

That's the default with MF .NET COBOL's ILGEN directive. To get impure
code, you add a reference to an unmanaged DLL, or use the ILNATIVE
directive to add an unmanaged DLL to the assembly.

Microsoft's /clr:safe generates a pure, verifiable assembly. The Micro
Focus equivalent is ILVERIFY.

But even verifiable assemblies can depend on assemblies that aren't
part of the .NET Framework. And all MF COBOL assemblies have
dependencies on the MF managed COBOL runtime assemblies.

COBOL programs typically do lots of things that aren't MSIL primitive
operations - things like handling edited data types, converting
between COBOL data types and .NET native types, handling complex COBOL
verbs such as INSPECT. And .NET COBOL programs can be written in
procedural fashion; that requires implementing non-OO constructs with
OO mechanisms under the covers. (PERFORMed paragraphs and sections are
wrapped as methods, and so forth.) All of that requires a lot of
support at runtime, and that's what the license pays for.

As Pete and others have pointed out, this does mean that you can't use
MF COBOL to create freeware or shareware programs that can be used by
anyone with just the .NET Framework installed. You *can* create
programs that can be used by anyone with a commercial, academic, or
personal version of MF COBOL installed. (And soon there will be some
kind of licensing arrangements for running in Azure and other clouds;
I don't know what those will look like.)

I'm sympathetic to people who'd like to be able to write open-source
MF COBOL programs. But I also understand the business decisions behind
the current licensing models. We're not Microsoft; we don't make money
when people buy the Windows application stack to run programs created
with the free version of Visual Studio.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
.

Relevant Pages

  • Re: Microfocus & Oracle data types
    ... >I'm not sure that I suggested using any particular compiler directives to ... Believe me I *really* can complain when necessary. ... or thereabouts and I had switched from RM/COBOL to MS COBOL (not their ... Haven't received your diskette". ...
    (comp.lang.cobol)
  • Re: Old broken COBOL programs from the 70s and 80s
    ... Will people please comment on these old broken COBOL programs from the ... I'll take issue with your limitation on the BASIC language, ... acronym for COmmon Business Oriented Language., ...
    (comp.lang.cobol)
  • Re: Microsoft Cobol 5.0 Help Needed
    ... Original MF Cobol compilers (CIS Cobol of 1978 and its predecessor ... error is the byte offset of the failure, not a source code line number. ... With OPT"0" the COPYLIST REF directives will give the offsets of the ... int code _before_ the generator has turned this into machine code. ...
    (comp.lang.cobol)
  • Re: Microsoft Cobol 5.0 Help Needed
    ... Original MF Cobol compilers (CIS Cobol of 1978 and its predecessor ... error is the byte offset of the failure, not a source code line number. ... With OPT"0" the COPYLIST REF directives will give the offsets of the ... int code _before_ the generator has turned this into machine code. ...
    (comp.lang.cobol)
  • Re: Problems that occur in production
    ... I'm looking for information about problems that could occur in production ... with Cobol programs and that could generate abend. ... In our course "Enterprise COBOL Update I: ...
    (bit.listserv.ibm-main)