Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Complete set of ydb_* environment variables corresponding to all gtm*/GTM* environment variables #209

Closed
nars1 opened this issue Apr 25, 2018 · 0 comments
Closed

Complete set of ydb_* environment variables corresponding to all gtm*/GTM* environment variables #209

nars1 opened this issue Apr 25, 2018 · 0 comments
Assignees
@nars1
Labels
enhancement
Milestone
r122

Comments

@nars1
Copy link
Collaborator

nars1 commented Apr 25, 2018 •
edited by ksbhaskar
Loading

Final Release Note

YottaDB has a complete set of environment variables with "ydb_" prefixes for environment variables with "gtm" and "GTM" prefixes. For example, ydb_routines is the equivalent of gtmroutines, ydb_chset is the equivalent of gtm_chset, ydb_repl_instance is the equivalent of gtm_repl_instance etc. YottaDB continues to support the gtm* environment variable if the corresponding ydb_* environment variable is not defined. If both variables are defined, the ydb_* definition takes precedence. The full list of environment variables is in the Environment Variables section of the Administration and Operations Guide. (#209)

Description

Currently there are a few gtm* environment variables that have ydb_* equivalents. For example,

gtm_dist -> ydb_dist
gtmgbldir -> ydb_gbldir
gtm_zmaxtptime -> ydb_maxtptime
gtmdbglvl -> ydb_dbglvl

But there are a host of other such environment variables (more than 100) supported by GT.M with a gtm* prefix that need corresponding ydb* names. It would be desirable to migrate all of them.

Draft Release Note

YottaDB now supports environment variables of the form ydb_* for every environment variable of the form gtm* supported by GT.M. For example, ydb_routines is the equivalent of gtmroutines, ydb_chset is the equivalent of gtm_chset, ydb_repl_instance is the equivalent of gtm_repl_instance etc. YottaDB continues to support the gtm* environment variable if the corresponding ydb_* environment variable is not defined. But if both variables are defined, the ydb_* definition takes precedence. The full list of supported environment variables and their names can be found in the YottaDB documentation.
@nars1 nars1 added this to the r130 milestone Apr 25, 2018
@nars1 nars1 self-assigned this Apr 25, 2018
nars1 added a commit to nars1/YottaDB that referenced this issue Apr 26, 2018
@nars1
[YottaDB#209] Add support for ydb_* environment variables correspondi…
61d9ba6 
…ng to all gtm*/GTM* environment variables

* In YottaDB r1.20, support for only a few ydb* environment variables was added
  (gtm_dist -> ydb_dist, gtmgbldir -> ydb_gbldir, gtm_zmaxtptime -> ydb_maxtptime and
  gtmdbglvl -> ydb_dbglvl). But there are 100+ environment variables that need similar
  support (e.g. gtmroutines -> ydb_routines, gtm_chset -> ydb_chset,
  gtm_repl_instance -> ydb_repl_instance, etc.). That is, YottaDB should recognize all
  the gtm* environment variables (for backward compatibility) but also recognize the
  new ydb_* environment variables. If both types of variables are defined, the ydb_*
  definition should override the gtm* definition. That recognition of all env vars
  is the purpose of this commit.

* A new file ydb_logicals_tab.h now defines all the gtm* environment variables and
  the corresponding ydb_* environment variables that YottaDB cares about. GT.M
  environment variables could start with gtm, gtm_, GTM or GTM_. They could be lower
  case or upper case. But the new YottaDB environment variables always start with ydb_
  and are always lower case. And because of this new file, gtm_logicals.h is no longer
  needed and is nixed.

* As part of this, previously unused env var names like gtm_jnl_statsdb,
  gtm_gvdupsetnoop are now removed.

* gtm_env_init.c, gtm_env_init_sp.c (and a few others like mstack_size_init.c) are
  now reworked to call new functions ydb_trans_numeric(), ydb_logical_truth_value(),
  ydb_trans_log_name() which are passed an index into the environment variable name
  table instead of the actual name of the env var; This way the functions will then
  know the corresponding ydb and gtm prefixed env var names for the passed in index
  and first check the ydb* name if it exists and if not use the gtm* env var.

* In ydb_trans_logname(), the ydb* env var is set to the gtm* env var if only the latter
  is defined.

* All existing calls of trans_log_name() were examined and if they involved a gtm*
  environment variable as input, they are now converted to ydb_trans_log_name().
  Calls which do not involve gtm* specific environment variables continue to stay as is.

* Any error message which involved an undefined environment variable now indicates both
  the ydb* and gtm* environment variable name (ydb*/gtm* syntax) now that we check both
  env vars and signal an undef only if both are undefined (e.g. REPLINSTUNDEF etc.).
  But any error message that is issued afterwards (i.e. after verifying that at least one
  of the two environment variables are defined) is now changed to indicate the correct
  name (ydb* or gtm*) depending on which definition prevailed (e.g. LOGTOOLONG etc.).

* A new function ydb_getenv() was implemented to migrate usages of getenv/GETENV. Like
  ydb_trans_log_name(), this also accepts an index into the environment name arrays
  (ydbenvname[] or gtmenv name[]) and looks at both env var names to decide which one
  takes effect. But unlike ydb_trans_log_name(), this does not do any error handling to
  keep it lightweight. This is because we need ydb_getenv() in places like the gtmsecshr
  wrapper and the encryption plugin. Both would get bloated with a lot of code if
  rts_error() etc. was present in ydb_getenv(). This also meant that ydb_getenv() does
  not do a setenv() of the ydb* env var like ydb_trans_log_name() does (as otherwise
  we would need to handle errors from the setenv()). It is upto the caller of ydb_getenv()
  to handle any needed setenv(). Because ydb_getenv() in turn requires access to the
  ydbenvname[] and gtmenvname[] arrays, a new file minimal_gbldefs.c holds these arrays
  and since this requires ydb_logicals.h and ydb_logicals_tab.h, all these files are now
  included in the encryption plugin too. While at this, a cygwin-only gtm_getenv()
  function is now nixed.

* Almost all existing usages of getenv/GETENV were migrated to ydb_getenv(). The remaining
  ones were renamed as getenv() and the GETENV macro nixed. Some AIX-only getenv/GETENV
  code blocks were removed as that is not anyways a supported platform.

* gtm* env var references in .hlp files were renamed to corresponding ydb* env varnames.
  This also involved fixing references to gtmroutines/gtm_zmaxtptime in *.hlp files to
  instead be ydb_routines/ydb_maxtptime (missed out in r1.20).

* Finally, almost all usages of gtm* strings found in the gtmenvname[] column of
  ydb_logicals_tab.h were changed to their corresponding ydb* strings (ydbenvname[] column)
  An exception is "gtm_sysid" in the mstr "default_sysid". That stays as is (i.e. not "ydb_sysid")
  to preserve backward compatibility with GT.M since $SYSTEM is an ISV that applications use.
nars1 added a commit that referenced this issue Apr 27, 2018
@nars1
[#209] Add support for ydb_* environment variables corresponding to a…
9af7f58 
…ll gtm*/GTM* environment variables

* In YottaDB r1.20, support for only a few ydb* environment variables was added
  (gtm_dist -> ydb_dist, gtmgbldir -> ydb_gbldir, gtm_zmaxtptime -> ydb_maxtptime and
  gtmdbglvl -> ydb_dbglvl). But there are 100+ environment variables that need similar
  support (e.g. gtmroutines -> ydb_routines, gtm_chset -> ydb_chset,
  gtm_repl_instance -> ydb_repl_instance, etc.). That is, YottaDB should recognize all
  the gtm* environment variables (for backward compatibility) but also recognize the
  new ydb_* environment variables. If both types of variables are defined, the ydb_*
  definition should override the gtm* definition. That recognition of all env vars
  is the purpose of this commit.

* A new file ydb_logicals_tab.h now defines all the gtm* environment variables and
  the corresponding ydb_* environment variables that YottaDB cares about. GT.M
  environment variables could start with gtm, gtm_, GTM or GTM_. They could be lower
  case or upper case. But the new YottaDB environment variables always start with ydb_
  and are always lower case. And because of this new file, gtm_logicals.h is no longer
  needed and is nixed.

* As part of this, previously unused env var names like gtm_jnl_statsdb,
  gtm_gvdupsetnoop are now removed.

* gtm_env_init.c, gtm_env_init_sp.c (and a few others like mstack_size_init.c) are
  now reworked to call new functions ydb_trans_numeric(), ydb_logical_truth_value(),
  ydb_trans_log_name() which are passed an index into the environment variable name
  table instead of the actual name of the env var; This way the functions will then
  know the corresponding ydb and gtm prefixed env var names for the passed in index
  and first check the ydb* name if it exists and if not use the gtm* env var.

* In ydb_trans_logname(), the ydb* env var is set to the gtm* env var if only the latter
  is defined.

* All existing calls of trans_log_name() were examined and if they involved a gtm*
  environment variable as input, they are now converted to ydb_trans_log_name().
  Calls which do not involve gtm* specific environment variables continue to stay as is.

* Any error message which involved an undefined environment variable now indicates both
  the ydb* and gtm* environment variable name (ydb*/gtm* syntax) now that we check both
  env vars and signal an undef only if both are undefined (e.g. REPLINSTUNDEF etc.).
  But any error message that is issued afterwards (i.e. after verifying that at least one
  of the two environment variables are defined) is now changed to indicate the correct
  name (ydb* or gtm*) depending on which definition prevailed (e.g. LOGTOOLONG etc.).

* A new function ydb_getenv() was implemented to migrate usages of getenv/GETENV. Like
  ydb_trans_log_name(), this also accepts an index into the environment name arrays
  (ydbenvname[] or gtmenv name[]) and looks at both env var names to decide which one
  takes effect. But unlike ydb_trans_log_name(), this does not do any error handling to
  keep it lightweight. This is because we need ydb_getenv() in places like the gtmsecshr
  wrapper and the encryption plugin. Both would get bloated with a lot of code if
  rts_error() etc. was present in ydb_getenv(). This also meant that ydb_getenv() does
  not do a setenv() of the ydb* env var like ydb_trans_log_name() does (as otherwise
  we would need to handle errors from the setenv()). It is upto the caller of ydb_getenv()
  to handle any needed setenv(). Because ydb_getenv() in turn requires access to the
  ydbenvname[] and gtmenvname[] arrays, a new file minimal_gbldefs.c holds these arrays
  and since this requires ydb_logicals.h and ydb_logicals_tab.h, all these files are now
  included in the encryption plugin too. While at this, a cygwin-only gtm_getenv()
  function is now nixed.

* Almost all existing usages of getenv/GETENV were migrated to ydb_getenv(). The remaining
  ones were renamed as getenv() and the GETENV macro nixed. Some AIX-only getenv/GETENV
  code blocks were removed as that is not anyways a supported platform.

* gtm* env var references in .hlp files were renamed to corresponding ydb* env varnames.
  This also involved fixing references to gtmroutines/gtm_zmaxtptime in *.hlp files to
  instead be ydb_routines/ydb_maxtptime (missed out in r1.20).

* Finally, almost all usages of gtm* strings found in the gtmenvname[] column of
  ydb_logicals_tab.h were changed to their corresponding ydb* strings (ydbenvname[] column)
  An exception is "gtm_sysid" in the mstr "default_sysid". That stays as is (i.e. not "ydb_sysid")
  to preserve backward compatibility with GT.M since $SYSTEM is an ISV that applications use.
@nars1 nars1 closed this as completed Apr 27, 2018
nars1 added a commit to nars1/YottaDB that referenced this issue Apr 30, 2018
@nars1
[YottaDB#209] Temporary snapshot-files/sockets created by YottaDB sho…
7fd5d44 
…uld have ydb_ prefix (not gtm_*); Cleanup of unused stuff
nars1 added a commit that referenced this issue Apr 30, 2018
@nars1
[#209] Temporary snapshot-files/sockets created by YottaDB should hav…
cbb7e94 
…e ydb_ prefix (not gtm_*); Cleanup of unused stuff
nars1 added a commit to nars1/YottaDB that referenced this issue May 2, 2018
@nars1
[YottaDB#209] Temporary relinkctl files created by YottaDB have ydb-r…
f2e3416 
…elinkctl prefix (not gtm-relinkctl); Rename fis-gtm references help files to yottadb
nars1 added a commit that referenced this issue May 2, 2018
@nars1
[#209] Temporary relinkctl files created by YottaDB have ydb-relinkct…
f1e4994 
…l prefix (not gtm-relinkctl); Rename fis-gtm references help files to yottadb
nars1 added a commit to YottaDB/YDBTest that referenced this issue May 2, 2018
@nars1
[YottaDB/YDB#209] Temporary relinkctl files created by YottaDB have y…
273d7a0 
…db-relinkctl prefix (not gtm-relinkctl)
@ksbhaskar ksbhaskar changed the title Add support for ydb_* environment variables corresponding to all gtm*/GTM* environment variables ydb_* environment variables corresponding to all gtm*/GTM* environment variables May 8, 2018
@ksbhaskar ksbhaskar changed the title ydb_* environment variables corresponding to all gtm*/GTM* environment variables Complete set of ydb_* environment variables corresponding to all gtm*/GTM* environment variables May 8, 2018
nars1 added a commit to nars1/YottaDBtest that referenced this issue May 11, 2018
@nars1
[YottaDB#209] Add ydb_passwd to CRYPTINIT error message text in refer…
de530a4 
…ence files

The code changes in YottaDB/YDB#209 changed the CRYPTINIT error message text
to also indicate the absence of ydb_passwd environment variable too (not just
gtm_passwd).
nars1 added a commit to YottaDB/YDBTest that referenced this issue May 11, 2018
@nars1
[#209] Add ydb_passwd to CRYPTINIT error message text in reference files
132c500 
The code changes in YottaDB/YDB#209 changed the CRYPTINIT error message text
to also indicate the absence of ydb_passwd environment variable too (not just
gtm_passwd).
chathaway-codes pushed a commit that referenced this issue Sep 20, 2018
@nars1
[#309] ydb_env_set should not clear gtm_prompt env var in case ydb_pr…
06a4be1 
…ompt env var is undefined

ydb_env_set called ydbenv.mpt which checked if ydb_prompt is defined and if so generated a
line that set gtm_prompt env var to the value of $ydb_prompt. This had an issue starting
YottaDB r1.22 when ydb_prompt env var is undefined but gtm_prompt env var is defined.

Some context first. As part of #209 in r1.22, support was added for ydb_* environment variables
to automatically inherit the value of gtm_* environment variables at process startup if the
ydb_* variable is not defined but the gtm_* variable is. Because of this change, a scenario
where a mumps process is started with gtm_prompt defined and ydb_prompt not defined implies
ydb_prompt env var is set at process startup to the same value so inside M code one can never
find themselves in a situation where ydb_prompt is undefined and gtm_prompt is defined.
Because of this, in ydbenv.mpt, in r1.22 and later versions, one would always go inside the
below else condition in ydbenv.mpt.
	else  write "export gtm_prompt=$ydb_prompt",!

But since this is a generated file that is sourced by the parent script (ydb_env_set) after
the mumps process terminates, ydb_prompt env var is undefined at that point and so the env
var gtm_prompt gets set to "" inside ydb_env_set and after it returns to the caller.

This is now fixed by removing the entire block of code which tried to generate shell commands
to set gtm_prompt and/or ydb_prompt to the appropriate values. None of this is needed since
YottaDB automatically handles the case where only one of gtm_prompt/ydb_prompt is defined.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nars1 nars1

Labels
enhancement
Projects
None yet
Milestone
r122
Development

No branches or pull requests
1 participant
@nars1