Difference: SettingEnvironmentVariables (1 vs. 5)

Revision 52016-01-21 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="APPXEnvironmentVariables"

Setting Environment Variables

Line: 12 to 12
 

Global OS Environment Variables

Changed:
<
<
The "classic" and most general place to set environment variables is at the OS level. In Windows, they are set in the autoexec.bat or System Environment on APPX/Client machine. In UNIX, they are typically set in /etc/profile

Among the BENEFITS are that they are:

  • Familiar to APPX veterans
  • Convenient if you have a mixture of Telnet and APPX/Client Users
  • Easy to verify what the values are by "set | more"
>
>
The "classic" and most general place to set environment variables is at the OS level. In Windows, they are set in autoexec.bat or the System Environment (Computer Properties, Advanced System Settings, Advanced Tab, Environment Variables button. Might require a reboot to take effect). In UNIX, they are typically set in /etc/profile

BENEFITS:

  • Familiar to APPX veterans
  • Convenient if you have a mixture of character and GUI Users
  • Easy to verify what the values are by "set | more"
 

DISADVANTAGES:

Changed:
<
<
  • variables tend to end up scattered around
  • using a mixture of OS and appx.env variables leaves you with variable settings in any of many different places. This can be hard to debug!
  • for non-APPX/Client users, user must log out and log back in again before changes in variable values can take effect
  • for APPX/Client users, the WinAppxD System Service must be stopped and restarted, or the NT must be rebooted, before changes in variable values can take effect
  • /etc/profile, NT system environment settings, and shared autoexec.bat files.
  • convenient if you have a mix of Telnet and APPX/Client users.
  • easy to verify variable values with "set |more" at a command prompt.
>
>
  • variables tend to end up scattered around
  • using a mixture of OS and appx.env variables leaves you with variable settings in any of many different places. This can be hard to debug!
  • In character mode, the user must log out and log back in again before changes in variable values can take effect
  • The Login Manager must be restarted and the users must log out and in again before changes in variable values can take effect
 

Per-user OS Environment Variables

Deleted:
<
<
  • UNIX's ~/.profile, or Windows non-shared autoexec.bat

  • Not applicable for APPX/Client

  • For variables set on a per-user basis

It is only useful in "shared disk" configurations on Windows, and for UNIX Telnet access to APPX.

Overrides any OS settings.

 
Changed:
<
<
Also overrides any global appx.env settings.
>
>
For character mode users on a Linux/Unix system you can set environment variables in their ~/.profile. This will override any OS settings or any appx.env settings.
 
Changed:
<
<

Startup script or batch files

>
>
This does not work for users that connect via the Login Manager.

Startup script files

 
Changed:
<
<
The next technique for setting APPX-related environment variables, is to do so directly in the script or batch file invoked by system users to start APPX, or invoked by the system to start AppxD.
>
>
If you use a script to start APPX for your character mode users, you can set them in the script.
 

BENEFIT:

Changed:
<
<
  • If the site already maintains a script or batch file, to start APPX, this may be convenient
  • Like appx.env, does not require reboots or system logout/logins for changes to take effect, just exiting and re-entering APPX
>
>
  • Convenient
  • Like appx.env, does not require reboots or system logout/logins for changes to take effect, just exiting and re-entering APPX
 

DISADVANTAGES:

Changed:
<
<
  • If you don't already have an APPX startup script or batch file, for some other site-specific purpose, you probably don't want to add one. It's another file to maintain and remember the purpose of.
  • Doesn't offer anything beyond appx.env's functionality, if you're not already doing other things in an APPX startup script that need scripting or batch file programming capabilities
  • If someone ever runs APPX by invoking APPX.EXE directly, your script's variable settings won't be executed
  • Only affects non-APPX/Client users
  • Convenient for sites who customize APPX startup by using a batch file

BENEFIT (start-appxd.sh):

  • It's already there

DISADVANTAGE (start-appxd.sh):

  • site administrators should be careful to back up this file prior to an APPX upgrade in case a new version includes an updated template start-appxd.sh file

AppxD startup script (UNIX only)

  • only affects APPX/Client users
  • similar to appx.env, allows all variable settings in one file

Global appx.env Environment Variables

The recommended method for setting environment variables is in Global appx.env.

  • $APPXPATH/appx.env
  • convenient if you have a mix of Telnet and APPX/Client users
  • all variables in a single file

Per-user appx.env Environment Variables

Per-user appx.env is not available for APPX/Client users.

>
>
  • Only works for character mode users
  • If you don't already have an APPX startup script or batch file, for some other site-specific purpose, you probably don't want to add one. It's another file to maintain and remember the purpose of.
  • Doesn't offer anything beyond appx.env's functionality, if you're not already doing other things in an APPX startup script that need scripting or batch file programming capabilities
  • If someone ever runs APPX by invoking the engine directly, your script's variable settings won't be executed

Login Manager

 
Changed:
<
<
It is only useful in "shared disk" configurations on Windows, and for UNIX Telnet access to APPX.

Overrides any OS settings. Also overrides any global appx.env settings.

  • ~/appx.env or C:\appx.env
  • not applicable for APPX/Client
  • for variables set on a per-user basis

>
>
This technique involves changing the settings of the Login Manager. See Login Manager For Unix/Linux or Login Manager For Windows.

BENEFIT:

  • You can set up different ports with different settings

DISADVANTAGE:

  • Does not work for character mode users

Global appx.env Environment Variables

 
Added:
>
>
The recommended method for setting environment variables is in the appx.env file ($APPXPATH/appx.env).

BENEFIT:

  • convenient if you have a mix of Telnet and APPX/Client users
  • all variables in a single file

DISADVANTAGE:

  • Affects all users, you cannot set up different variables on a per port or per user basis
 

Setting Environment Variables on the Command line

Changed:
<
<
You can also set environment variables from the command line. Just prefix the variable with 2 dashes as follows:
>
>
You can also set environment variables from the command line. Just prefix the variable with 2 dashes as follows on the command line:
  appx --APPX_SQL_LOG=c:\logs\appx.log --APPX_CMD_LOG=0xFFFFFFFF

This will set APPX_SQL_LOG and APPX_CMD_LOG for the duration of this session only.

Changed:
<
<

Gotchas

>
>

Common Problems

  Tech support sees various issues related to environment variables come up on a regular basis. Since forewarned is forearmed, here they are.

APPX_PRT_FI_DIR must have trailing slash

Determines where APPX creates report files. Examples in UNIX and Windows:

Changed:
<
<
$ export APPX_PRT_FI_DIR=/tmp/pat/
C:\> set APPX_PRT_FI_DIR=\\server\printfiles\pat\
>
>
$ export APPX_PRT_FI_DIR=/tmp/pat/
C:\> set APPX_PRT_FI_DIR=\\server\printfiles\pat\
 

Make sure path names are valid

Changed:
<
<
For any variable requiring a file or directory pathname, make sure that all directories in the path exist. On UNIX (or when editing appx_print for UniQue), make sure that the case you use in the variable setting matches the actual case of the filename. A mistake here can cause log files to not appear, or APPX to behave incorrectly.
>
>
For any variable requiring a file or directory pathname, make sure that all directories in the path exist. Make sure that the case you use in the variable setting matches the actual case of the filename for those environments that are case sensitive. A mistake here can cause log files to not appear, or APPX to behave incorrectly.
 

Setting a variable in .profile for a APPX/Client user will have no effect

While a variable set in a UNIX .profile will affect a user's APPX session if they Telnet in to the APPX machine, it won't affect a APPX/Client login. Since we directly start up APPX from APPX/Client, rather than going through a Command Shell as with Telnet, no shell initialization files are processed.

Deleted:
<
<

Clicking "Apply" after a change, won't update a running copy of WinAppxD

WinAppxD runs as a system service. As such, the only way to get WinAppxD (and subsequent APPX/Client sessions started from it) to recognize changes in the system environment is to reboot the server.

 

Comments:

Read what other users have said about this page or add your own comments.


Changed:
<
<

<--/commentPlugin-->
>
>

<--/commentPlugin-->

Revision 42014-06-20 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="APPXEnvironmentVariables"

Setting Environment Variables

Changed:
<
<
APPX offers five levels at which environment variables may be set:
>
>
APPX offers six levels at which environment variables may be set:
 
Line: 10 to 10
  Specific Environment Variables are documented in detail at Environment Variables List.
Deleted:
<
<

 

Global OS Environment Variables

The "classic" and most general place to set environment variables is at the OS level. In Windows, they are set in the autoexec.bat or System Environment on APPX/Client machine. In UNIX, they are typically set in /etc/profile

Line: 22 to 17
 
  • Familiar to APPX veterans
  • Convenient if you have a mixture of Telnet and APPX/Client Users
  • Easy to verify what the values are by "set | more"

DISADVANTAGES:

  • variables tend to end up scattered around
  • using a mixture of OS and appx.env variables leaves you with variable settings in any of many different places. This can be hard to debug!
  • for non-APPX/Client users, user must log out and log back in again before changes in variable values can take effect
  • for APPX/Client users, the WinAppxD System Service must be stopped and restarted, or the NT must be rebooted, before changes in variable values can take effect
  • /etc/profile, NT system environment settings, and shared autoexec.bat files.
  • convenient if you have a mix of Telnet and APPX/Client users.
  • easy to verify variable values with "set |more" at a command prompt.
Deleted:
<
<

 

Per-user OS Environment Variables

  • UNIX's ~/.profile, or Windows non-shared autoexec.bat

Line: 37 to 28
  Also overrides any global appx.env settings.
Deleted:
<
<

 

Startup script or batch files

The next technique for setting APPX-related environment variables, is to do so directly in the script or batch file invoked by system users to start APPX, or invoked by the system to start AppxD.

Line: 55 to 41
 
  • site administrators should be careful to back up this file prior to an APPX upgrade in case a new version includes an updated template start-appxd.sh file

AppxD startup script (UNIX only)

  • only affects APPX/Client users
  • similar to appx.env, allows all variable settings in one file
Deleted:
<
<


 

Global appx.env Environment Variables

The recommended method for setting environment variables is in Global appx.env.

  • $APPXPATH/appx.env
  • convenient if you have a mix of Telnet and APPX/Client users
  • all variables in a single file
Deleted:
<
<


 

Per-user appx.env Environment Variables

Per-user appx.env is not available for APPX/Client users.

Line: 71 to 55
 Overrides any OS settings. Also overrides any global appx.env settings.
  • ~/appx.env or C:\appx.env
  • not applicable for APPX/Client
  • for variables set on a per-user basis

Changed:
<
<


>
>

Setting Environment Variables on the Command line

You can also set environment variables from the command line. Just prefix the variable with 2 dashes as follows:

appx --APPX_SQL_LOG=c:\logs\appx.log --APPX_CMD_LOG=0xFFFFFFFF

This will set APPX_SQL_LOG and APPX_CMD_LOG for the duration of this session only.

 

Gotchas

Tech support sees various issues related to environment variables come up on a regular basis. Since forewarned is forearmed, here they are.

Revision 32012-02-29 - ChrisBrower

Line: 1 to 1
 
META TOPICPARENT name="APPXEnvironmentVariables"

Setting Environment Variables

Line: 89 to 89
 

Clicking "Apply" after a change, won't update a running copy of WinAppxD

WinAppxD runs as a system service. As such, the only way to get WinAppxD (and subsequent APPX/Client sessions started from it) to recognize changes in the system environment is to reboot the server. \ No newline at end of file

Added:
>
>

Comments:

Read what other users have said about this page or add your own comments.



<--/commentPlugin-->
 \ No newline at end of file

Revision 22012-02-28 - ChrisBrower

Line: 1 to 1
 
META TOPICPARENT name="APPXEnvironmentVariables"

Setting Environment Variables

Line: 8 to 8
  General Environment Variable information can be found at APPX Environment Variables.
Changed:
<
<
Specific Environment Variables are documented in detail at Environment Variables List.
>
>
Specific Environment Variables are documented in detail at Environment Variables List.
 

Revision 12012-02-28 - ChrisBrower

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="APPXEnvironmentVariables"

Setting Environment Variables

APPX offers five levels at which environment variables may be set:

General Environment Variable information can be found at APPX Environment Variables.

Specific Environment Variables are documented in detail at Environment Variables List.


Global OS Environment Variables

The "classic" and most general place to set environment variables is at the OS level. In Windows, they are set in the autoexec.bat or System Environment on APPX/Client machine. In UNIX, they are typically set in /etc/profile

Among the BENEFITS are that they are:

  • Familiar to APPX veterans
  • Convenient if you have a mixture of Telnet and APPX/Client Users
  • Easy to verify what the values are by "set | more"

DISADVANTAGES:

  • variables tend to end up scattered around
  • using a mixture of OS and appx.env variables leaves you with variable settings in any of many different places. This can be hard to debug!
  • for non-APPX/Client users, user must log out and log back in again before changes in variable values can take effect
  • for APPX/Client users, the WinAppxD System Service must be stopped and restarted, or the NT must be rebooted, before changes in variable values can take effect
  • /etc/profile, NT system environment settings, and shared autoexec.bat files.
  • convenient if you have a mix of Telnet and APPX/Client users.
  • easy to verify variable values with "set |more" at a command prompt.

Per-user OS Environment Variables

  • UNIX's ~/.profile, or Windows non-shared autoexec.bat

  • Not applicable for APPX/Client

  • For variables set on a per-user basis

It is only useful in "shared disk" configurations on Windows, and for UNIX Telnet access to APPX.

Overrides any OS settings.

Also overrides any global appx.env settings.


Startup script or batch files

The next technique for setting APPX-related environment variables, is to do so directly in the script or batch file invoked by system users to start APPX, or invoked by the system to start AppxD.

BENEFIT:

  • If the site already maintains a script or batch file, to start APPX, this may be convenient
  • Like appx.env, does not require reboots or system logout/logins for changes to take effect, just exiting and re-entering APPX

DISADVANTAGES:

  • If you don't already have an APPX startup script or batch file, for some other site-specific purpose, you probably don't want to add one. It's another file to maintain and remember the purpose of.
  • Doesn't offer anything beyond appx.env's functionality, if you're not already doing other things in an APPX startup script that need scripting or batch file programming capabilities
  • If someone ever runs APPX by invoking APPX.EXE directly, your script's variable settings won't be executed
  • Only affects non-APPX/Client users
  • Convenient for sites who customize APPX startup by using a batch file

BENEFIT (start-appxd.sh):

  • It's already there

DISADVANTAGE (start-appxd.sh):

  • site administrators should be careful to back up this file prior to an APPX upgrade in case a new version includes an updated template start-appxd.sh file

AppxD startup script (UNIX only)

  • only affects APPX/Client users
  • similar to appx.env, allows all variable settings in one file


Global appx.env Environment Variables

The recommended method for setting environment variables is in Global appx.env.

  • $APPXPATH/appx.env
  • convenient if you have a mix of Telnet and APPX/Client users
  • all variables in a single file


Per-user appx.env Environment Variables

Per-user appx.env is not available for APPX/Client users.

It is only useful in "shared disk" configurations on Windows, and for UNIX Telnet access to APPX.

Overrides any OS settings. Also overrides any global appx.env settings.

  • ~/appx.env or C:\appx.env
  • not applicable for APPX/Client
  • for variables set on a per-user basis


Gotchas

Tech support sees various issues related to environment variables come up on a regular basis. Since forewarned is forearmed, here they are.

APPX_PRT_FI_DIR must have trailing slash

Determines where APPX creates report files. Examples in UNIX and Windows:

$ export APPX_PRT_FI_DIR=/tmp/pat/
C:\> set APPX_PRT_FI_DIR=\\server\printfiles\pat\

Make sure path names are valid

For any variable requiring a file or directory pathname, make sure that all directories in the path exist. On UNIX (or when editing appx_print for UniQue), make sure that the case you use in the variable setting matches the actual case of the filename. A mistake here can cause log files to not appear, or APPX to behave incorrectly.

Setting a variable in .profile for a APPX/Client user will have no effect

While a variable set in a UNIX .profile will affect a user's APPX session if they Telnet in to the APPX machine, it won't affect a APPX/Client login. Since we directly start up APPX from APPX/Client, rather than going through a Command Shell as with Telnet, no shell initialization files are processed.

Clicking "Apply" after a change, won't update a running copy of WinAppxD

WinAppxD runs as a system service. As such, the only way to get WinAppxD (and subsequent APPX/Client sessions started from it) to recognize changes in the system environment is to reboot the server.

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback