That should be clear from reading the manual (not even the programmer's guide) - please have a look and if this isn't the case then that should be fixed, maybe you can check and draft an entry / change?
Currently it is at least in the NEWS file as follows:
**New-stdoptions:cobol2014COBOL2014StandardxopenX/OpenCOBOLStandardmf-strictMicroFocusCOBOLcompatibility-strictibm-strictIBMCOBOLcompatibility-strictibm-strictMVS/VMCOBOLcompatibility-strictacuACUCOBOL-GTcompatibilityacu-strictACUCOBOL-GTcompatibility-strictbs2000BS2000COBOLcompatibility(backagain)bs2000-strictBS2000COBOLcompatibility-strictrmRM-COBOLcompatibilityrm-strictRM-COBOLcompatibility-strictNote:TheGnuCOBOLcompilertriestolimitboththefeature-setandreservedwordstothespecifiedcompilerwhenthe"strict"dialectsareused.COBOLsourcescompiledwiththesedialectsarethereforelikelytocompilewiththespecifiedcompilerandviceversa:sourcesthatwerecompiledonthespecifiedcompilershouldcompilewithoutanyissueswithGnuCOBOL.Withthe"non-strict"dialectsGnuCOBOLwillactivatethecompletefeature-setwhereitdoesn'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 intrinsic functions that are actually available as intrinsic functions depend on the -std used. Function names that aren'tmarkedasintrinsicfunctionsbythecurrent-stdcanbeusedfreelyasuserdefinedwordsorevenasuserdefinedfunctions.**new-fformatdialectoption,andextendedSOURCEFORMATdirectives,withthefollowingnewlysupportedreference-formats(inadditiontoFIXED/FREE):COBOL85Fixed-formformatwithenforcementofAreaACOBOLXGCOS7extendedformatCRTICOBOLFree-formformatTERMINALACUCOBOL-GTTerminalformatVARIABLEMicroFocusVariableFixed-formformatXCARDICOBOLxCard(extendedcard)formatXOPENX/OpenFree-formformatTheseformatscomewithAreaAenforcement(exceptforXOPEN),thatcheckswhetherdivision,section,andparagraphnamesstartinAreaA(i.e,beforemarginB),andsodolevelindicatorsFD,SD,RD,andCD,andlevelnumbers01,and77.Theunderlyingchecksareenabledordisabledbydefaultusingdialectoption`areacheck`,andthenwith`$SET AREACHECK`and`$SET NOAREACHECK`compilerdirectives.Asaresultofreferenceformatbeingadialectoption,AreaAenforcementisavailableandenabledbydefaultfordialectsBS2000COBOL,CARealiaII,COBOL85,GCOSCOBOL,IBMCOBOL,MVS/VMCOBOL,RM-COBOL,andX/OpenCOBOL.AreaAenforcementadditionallyenablesdetectionofmissingperiodsbeforelevelnumbersthatlieinAreaAintheDATADIVISION,andbeforeparagraphandsectionnamesinthePROCEDUREDIVISION.Moregenerally,some,butnotall,missingperiodscanbereportedandrecoveredfrom.Thisisconfigurablewithoption`missing-period`.
... and more, that discuss dialect options.
The most important part is:
* if you use a -strict option, then the behaviour is according to that dialect and features are limited to what the dialect supports, that's especially true for reserved words (which are not unlikely to create problems in case of same user-defined names [for example NOTHING]), intrinsic functions and registers; if a feature does not conflict at all with a dialect it may still be available; we definitely don't drop any CBL routines, for example (you could create those in other compilers as well, after all)
* non-strict are "identical behaviour" (for example initialization and soon possibly also runtime checks) but with all features (and reserved words) enabled that don't directly conflict with that dialect
If you start a migration and/or need to "still compile and run" on the other compiler: use the strict one; if you then want to use GnuCOBOL's features because that is already done, then use the non-strict one, possible unreserving single words that conflict with your code.
If you want to be portable between compilers use xopen/cobol85 (because that's widely supported) or the newer COBOL standards (but many features of that aren't available in other compilers).
If you start with a new COBOL project and want to stick to GnuCOBOL in the future: just use the default.
And in any case there's the option to manually override any dialect option on the command line or write your own conf file that includes a dialect, then overrides what you want different and only reference that by --conf.
To learn more about the dialect options: check cobc --help (or directly cobc/config.def) and the config files itself.
To see what reserved words / intrinsics / registers are active: use cobc's --list options after using -std/-conf (and maybe -f[not-]reserved).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you very much for the complete and exhaustive answer.
If I understood correctly then to simplify as an example:
with -std=default
it compiles accepting the specifications of all compilers (COBOL 85, 2002, 2014, Acu, IBM, MF, RM, Realia etc ..) and also the additional ones that only GnuCOBOL has. In other words it compiles with everything that is described in the Programmer's Guide.
with -std=acu-strict
it compiles accepting only the specifications of AcuCOBOL
with -std=acu
it compiles accepting both the specifications of AcuCOBOL and those of GnuCOBOL but does not accept the typical specifications of other compilers.
Did I understand correctly ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nearly. Some features that are exotic and/or potentially conflicting are disabled per default.
For example some ODO variants only work in some dialects.
The PG should describe all and may have elements like "this rule does not apply for all dialects" in special cases like data items after OCCURS DEPENDING ON, but otherwise should just have a general note about features possibly being dialect specific syntax (for example POS) or work different depending on dialect.
When you specify the option
-std=<dialect>for example-std=acuor-std=acu-strictwhat exactly is the effect ?That should be clear from reading the manual (not even the programmer's guide) - please have a look and if this isn't the case then that should be fixed, maybe you can check and draft an entry / change?
Currently it is at least in the NEWS file as follows:
... and more, that discuss dialect options.
The most important part is:
* if you use a -strict option, then the behaviour is according to that dialect and features are limited to what the dialect supports, that's especially true for reserved words (which are not unlikely to create problems in case of same user-defined names [for example NOTHING]), intrinsic functions and registers; if a feature does not conflict at all with a dialect it may still be available; we definitely don't drop any CBL routines, for example (you could create those in other compilers as well, after all)
* non-strict are "identical behaviour" (for example initialization and soon possibly also runtime checks) but with all features (and reserved words) enabled that don't directly conflict with that dialect
If you start a migration and/or need to "still compile and run" on the other compiler: use the strict one; if you then want to use GnuCOBOL's features because that is already done, then use the non-strict one, possible unreserving single words that conflict with your code.
If you want to be portable between compilers use xopen/cobol85 (because that's widely supported) or the newer COBOL standards (but many features of that aren't available in other compilers).
If you start with a new COBOL project and want to stick to GnuCOBOL in the future: just use the default.
And in any case there's the option to manually override any dialect option on the command line or write your own conf file that includes a dialect, then overrides what you want different and only reference that by --conf.
To learn more about the dialect options: check
cobc --help(or directly cobc/config.def) and the config files itself.To see what reserved words / intrinsics / registers are active: use cobc's
--listoptions after using-std/-conf(and maybe-f[not-]reserved).Thank you very much for the complete and exhaustive answer.
If I understood correctly then to simplify as an example:
with
-std=defaultit compiles accepting the specifications of all compilers (COBOL 85, 2002, 2014, Acu, IBM, MF, RM, Realia etc ..) and also the additional ones that only GnuCOBOL has. In other words it compiles with everything that is described in the Programmer's Guide.
with
-std=acu-strictit compiles accepting only the specifications of AcuCOBOL
with
-std=acuit compiles accepting both the specifications of AcuCOBOL and those of GnuCOBOL but does not accept the typical specifications of other compilers.
Did I understand correctly ?
Nearly. Some features that are exotic and/or potentially conflicting are disabled per default.
For example some ODO variants only work in some dialects.
The PG should describe all and may have elements like "this rule does not apply for all dialects" in special cases like data items after OCCURS DEPENDING ON, but otherwise should just have a general note about features possibly being dialect specific syntax (for example POS) or work different depending on dialect.
Now added to PG & PR in section 10.