Menu

std= directives

2023-03-06
2023-03-06
  • Paul Richards

    Paul Richards - 2023-03-06

    I posted this yesterday but when I try to access Simon's reply I get:
    "410 Gone
    This resource is no longer available. No forwarding address is given."

    I'm hoping this repost will let me see replies:
    GnuCOBOL uses various facilities to determine the COBOL dialect to be used.

    So setting std=85, I presume, causes the compiler to produce code in accordance with the COBOL 85 standard without any extensions.

    Setting std=mf-strict, I presume, causes compilation strictly in accordance with Micro Focus rules which will be a COBOL 85 standard plus Micro Focus's proprietary extensions.

    So what additional facilities does std=mf provide over and above the mf-strict directive? And what does GnuCOBOL not implement when using mf-strict?

    I know these are very basic questions and I have been usiing GnuCOBOL for several years without properly understanding the differences. I would welcome clarification.

    Thanks

     
  • Paul Richards

    Paul Richards - 2023-03-06

    Sorry, I still get the same error. Can you cut'n'paste Simon's response here?

     
    • Vincent (Bryan) Coen

      On 06/03/2023 23:00, Paul Richards wrote:

      Sorry, I still get the same error. Can you cut'n'paste Simon's
      response here?

      From Simons post :

      From the NEWS file
      https://sourceforge.net/p/gnucobol/code/HEAD/tree/tags/gnucobol-3.2-preview/NEWS:


      New |-std| options

      |cobol2014| COBOL 2014 Standard
      |xopen| X/Open COBOL Standard
      |mf-strict| Micro Focus COBOL compatibility - strict
      |ibm-strict| IBM COBOL compatibility - strict
      |ibm-strict| MVS/VM COBOL compatibility - strict
      |acu| ACUCOBOL-GT compatibility
      |acu-strict| ACUCOBOL-GT compatibility - strict
      |bs2000| BS2000 COBOL compatibility (back again)
      |bs2000-strict| BS2000 COBOL compatibility - strict
      |rm| RM-COBOL compatibility
      |rm-strict| RM-COBOL compatibility - strict
      |gcos| GCOS compatibility
      |gcos-strict| GCOS compatibility - strict

      Note:
      

      The GnuCOBOL compiler tries to limit both the feature-set and reserved
      words to the specified compiler when the "strict" dialects are used.
      COBOL sources compiled with these dialects are therefore likely to
      compile with the specified compiler and vice versa: sources that were
      compiled on the specified compiler should compile without any issues
      with GnuCOBOL.

      With the "non-strict" dialects GnuCOBOL will activate the complete
      feature-set where it doesn't directly conflict with the specified
      dialect, including reserved words and GnuCOBOL specific extensions.
      COBOL sources compiled with these dialects therefore may work only with
      GnuCOBOL. COBOL sources may need a change because of rich feature-set
      and reserved words in GnuCOBOL, otherwise offending words may be removed
      by |-fno-reserved=word|.
      COBOL-85, X/Open COBOL, COBOL 2002 and COBOL 2014 are always "strict".

      The functions that are actually available as intrinsic functions depend
      on the -std used. Function names that aren't marked as intrinsic
      functions by the current -std can be used freely as user defined words
      or even as user defined functions.


      That, I guess should answer most of the questions, I also guess
      something similar can be found in the Programmer's Guide.

      So what additional facilities does std=mf provide over and above the
      mf-strict directive? And what does GnuCOBOL not implement when using
      mf-strict?
      

      Short answer: GnuCOBOL adds /all/ that |-std-default| provides with the
      "lax" std dialects.
      This brings in several intrinsic functions that are not supported by
      that dialect originally and removes some restrictions (like
      word/literal/... length). Similar you get COBOL support (for example you
      get |END-DISPLAY| and |ALLOCATE| as well as |BINARY-INT| and a lot of
      others in |-std=mvs-strict| - with the "cost" that "old" code may not be
      able to compile because of the huge increased number of reserved words
      (which you may un-reserve), and if coding against the lax syntax it may
      not compile on the "original" system (developing with the strict then
      only syntax-check against the lax dialect can help to write more
      portable code).

      My personal Rule of thumb: * don't specify |-std| if there's no explicit
      reason * specify a strict standard when you target the dialect's
      environment (you want to compile the programs on the other environment
      later) - depending on the version of the target you may need to
      unreserve some words (if they were added in a later version, a good
      example may be |-fnot-reserved=JSON,XML|) * specify a strict dialect
      when you know the source is matching this dialect and it doesn't seem to
      compile/work correctly

      You may have a look at the details by inspecting the "config" directory
      and comparing the word lists + dialect configurations.

       
  • Paul Richards

    Paul Richards - 2023-03-06

    Thanks, Vincent.

     
    • Vincent (Bryan) Coen

      On 06/03/2023 23:50, Paul Richards wrote:

      Thanks, Vincent.

      I am going to look at adding this text into chapter 10/11 of the PR / PG
      as soon as I have time.

       

Anonymous
Anonymous

Add attachments
Cancel