#58 Add a runtime configuration file

[Simon Sobisch]

Many have thought of this already. Quoting Ron from an e-mail as he was the last one and he'll likely implement this "not that late" (therefore assigning the ticket to him):

I was thinking.... Micro Focus has a feature where all of the run-time options can be defined in a simple configuration file. The location of such a configuration file has a default but an env var can define an alternate location. Anyway, having a single configuration file for GNUCobol run-time behaviour might be something to do in the not too distant future. Such a feature would make it simpler for a site to standardize on the expected behaviour rather than leaving up to individuals to set the various env variables.

Here are the specs I've thought about

• Default configuration file: installpath\gnucobol_runtime.conf - copied over during installation, containing only comments [everything from an unquoted "#" on would be a comment] included (each configuration entry as it's output with cobcrun --runtime-env with a sample)
• Path can be overridden via environment var COB_RUNTIME_CONF
• new option -c for cobcrun, simply setting COB_RUNTIME_CONF to its parameter
• the very first thing in runtime initialisation would be to read the environment var: if it's set use this as file path, else the default
• if there is no file --> exit with error
• everything that is in the runtime configuration file and is no comment would be set into environment if there isn't an environment var for that entry already set

Simon

[Simon Sobisch]

Current state:

I don't think anymore that it would be a good idea to include the current defaults in the runtime.cfg as a real setting and use these (comment is the way to go) because this will break the current rules of secondary runtime variables.
Example:
Currently "default_cancel_mode = 0" in environment sets physical cancel to be active. If we would set the default "COB_PHYSICAL_CANCEL = no" in the standard configuration the secondary value from environment won't be read any more.

This leads to a standard configuration file what will only consist of comments. With the current implementation the whole file is parsed before initialisation starts (and nothing is done because of everything being a comment) after standard 'make install' but it's possible for the user to change the file and change the global behaviour that way.

A working version is available in the branch gc-runtime_configuration with r539 (necessary code changes in [r538]). Current path of standard runtime configuration file is installpath/config/runtime.cfg (next to cobol2002.conf, mf.conf, ...) - this may change.

Additional entries for runtime configuration file:

• !unset for removing a var already exported to environment before parsing the line
• !copy for inclusion of another runtime configuration file

Simon

[Ron Norman]

The way I had it coded was that if the environment variable was defined, that would override the corresponding value from the runtime.cfg file.

The precedence is:
1) env var
2) runtime.cfg
3) default value coded in table

Also, I can handle
keyword: value #Comments fine

The # would only be included if it was enclosed in quotes
keyword: "My#mark" #Comments follow

I had planned to handle setenv and unsetenv directives.

My plan is also to remove as much of the localized checking of environment variables from the libcob routines as I can safely do.

I had no plans to push runtime.cfg into the process environment.

My plan was the opposite. I planned to actually remove most of the code that was doing getenv in favour of having a single routine that checks environment and runtime.cfg and then stores the resulting value into a field in cob_global and then the rest of the libcob routines check the value in the cob_global data structure. (The runtime_env goes away completely.)

The exception is if runtime.cfg contains a 'setenv' directive then that and only that is pushed into the process environment.

But for the normal GnuCOBOL runtime options these just become values set into a field in 'cob_global'.

I had planned to handle 'setenv' and 'unsetenv' but I could also handle 'set' and 'unset' as equivalent. I also planned to handle things like: setenv DD_MYFILE ${HOME}/mydata

Please confirm this is your understanding as well.

[Ron Norman]

Maybe I confused things by using the word 'precedence'.
What this means is that env var overrides runtime.cfg and runtime.cfg overrides the default.
So effectively it is like setting all default values, then setting/processing all runtime.cfg keywords/directives and then check for env vars.
Although the code I write may not work exactly like that, then net result will be the same.

--
Cheers
Ron Norman

[Simon Sobisch]

Hi Ron,

as discussed by mail: please update runtime.cfg to contain every switch we currently have as a first commit.

Then explain how you'd handle the following:

• case 1: alias env var is set (example: default_cancel_mode = 0 --> physical cancel activated), runtime.cfg contains just the comment COB_PHYSICAL_CANCEL = NO, default var would be no physical cancel
• case 2: env var is set to force disabling (example: COB_PHYSICAL_CANCEL = NO --> physical cancel deactivated), runtime.cfg contains COB_PHYSICAL_CANCEL = YES
• case 3: env var is set (example: COB_PHYSICAL_CANCEL = YES --> physical cancel activated), runtime.cfg contains !unsetenv COB_PHYSICAL_CANCEL to use the default: no physical cancel
• case 4: env var is not set, runtime.cfg contains COB_PHYSICAL_CANCEL = YES and includes another configuration file which has !unsetenv COB_PHYSICAL_CANCEL and COB_PHYSICAL_CANCEL = YES to force this setting

Case 4 may be solved by adding !force (which overrides all earlier settings, no matter if they came from an environment var or from a previous configuration entry.

After we sorted this out you're free to change the gc-runtime_configuration this way.

I do think that with your change the runtime configuration file should not use the alias values - only evaluated during "phase 1" - environment vars.

I'm perfectly fine with the change of the current !unset to !unsetenv and "pollution of environment" only with !setenv. We may add !export to set an environment var from a current runtime setting (useful if sub processes should use the same setting) and if we add !export all the current implementation (all settings exported) would still be available.

As cob_global is exported I'm not sure if it's good to add the runtime values there, too. Looks like too much pollution to me. With the new configuration file as suggested by you --runtime-env should be changed to --print-[runtime-]settings and may even contain where the setting was taken from. With the given example it could be something like

COB_PHYSICAL_CANCEL:    no  (default)
COB_PHYSICAL_CANCEL:    yes (/installpath/runtime.cfg)
COB_PHYSICAL_CANCEL:    yes (env: default_cancel_mode = 0)
COB_PHYSICAL_CANCEL:    no  (env: COB_PHYSICAL_CANCEL = NO)

What is your opinion about these points?

Simon

[Ron Norman]

Changes are checked in and ready for Simon to test

[Simon Sobisch]

The teamwork between Ron (doing all the base-work) and me for this feature request was finished in runtime-configuration branch and finally merged to 2.0-branch in [r658].

Good work Ron.