A Production Environment is a live environment being used to support an actual, live instance of LeasePak being used to conduct a real-world leasing business. This means that there are some restrictions on accessing the LLDB and its software.
Production Environments are always linked to the live build. The drivers for a Production environment are always setup to connect via a link to an exe directory in the $live build. Production Environment configuration data is always read-only, owned by the $NSTADMIN or by the $NSTDBA roles (see LeasePak Server Roles).
A Test Environment is intended to connect to a test-type of database. The Test Environment has looser permissions on its directory tree than does a Production Environment. It provides access to the LeasePak drivers via a directory populated with individual links to the drivers in the associated build. This allows individual drivers in the Test Environment to be replaced with experimental or special drivers to perform testing on the database. The Test Environment's tree structure is illustrated at Environment Tree.
The Test Environment may be constructed to point to the $live build, or it may be constructed to point to the build currently marked as $live and to keep pointing to that build, even if it is no longer the $live build, or it may be constructed to point to a particular build identified by Build Id on the command line.
See Setting up a Test Database below.
The Visitor Environment is configured to "visit" a "host environment" and to use the host's LLDB, but with a different build. The Visitor Environment tree (see Visitor Tree) is outwardly the same as a Production or Test Environment tree. If examined carefully, though, it can be seen that most of the directories in the Visitor Environment tree are in fact just links to directories in its host environment or in its build. In fact, the $uetc and $uexe directories are the only two actual directories in the Visitor Environment.
The Visitor Environment links to directories in the designated build, or, notably, to directories in the host environment, such as the $ueop directories and the $udata directory. Because it is sharing the database of the host environment, it cannot have independent EOP or data directories, as these represent an intrinsic part of the LLDB, and must remain in synch with it.
The Visitor Environment is not allowed to do bulk write or configuration operations to the LLDB. This includes disallowing db_add_login, db_add_user, db_restore, db_trunc_rhr, db_create (and all of its sub-programs), and all conversion programs.
The Visitor Environment is useful for training new users, or for testing new builds against live data, as it limits the user's ability to make massive changes to the data.
No, the Host Environment is not the fourth of three types of LeasePak environments. Any environment created without the -c (closed) flag may be a host environment. Otherwise the host environment is a full-fledged Production or Test environment. A Visitor Environment cannot be a host to yet another Visitor Environment.
$uetc/logdb.* — This file declares shell variables that describe how the environment and LLDB fit together. Of interest here is $MSIDB_TYPE with the value ORA or SYB; $MSIDB_DBNAME and $MSIDB_OWNER, plus the $MSIDB_SERVER, representing the DBMS, the name of the LLDB, the owner of the LLDB and the database server.
Note that the logdb.* files are three in number in every environment. These three files, with the extensions .msirc, .com, and .lpkd, have substantially the same content, expressed in three different notations, and are compatible with, respectively, the shell, the batch queues, and the LeasePak daemon, leasepakd.
In a visitor environment, the logdb.* files are all actually links to the files in the host environment with the same name.
Every environment that is not a visitor environment, has a configuration file named physdb.msirc. This file describes the physical database in terms of the hardware (disk) resources that it occupies. This is done by listing the DBMS-configured storage segments that the LLDB uses.
It is strongly recommended that this file be maintained by the DBAs so that there is a record of the segments used to build a LLDB. The Oracle implementation only allows for a single tablespace per LLDB, though additional datafiles can be allocated to that tablespace. The Sybase implementation allows multiple $MSIDB_SEGnn entries in the physdb.msirc file, and will construct the LLDB using all of the entries, where each $MSIDB_SEGnn is a space allocation on some sybdevice.
See also the discussion of storage segments.
When the Administrator creates a new non-Administrative User Account, it can be configured for LeasePak without assigning it to an environment. However, of course, the user must be given access to an environment in order to use LeasePak, by a person wielding the credentials of the owner of the environment's LLDB to execute db_add_user (see also LeasePak Server Roles for more information about the $MSIDB_OWNER's role).
The LeasePak Supervisor must also give the user a Security Record using the [U0706]Security update.
The $MSIDB_OWNER (the DBO) is created or assigned to the LLDB when db_create is executed by the Administrator. The various commands that require the $MSIDB_OWNER's password always figure out who the owner is because the commands always access the LLDB via the environment. The user executing the commands thus only needs to know the password for the DBO, not the DBO's actual user name.
When a LeasePak user connects to LeasePak via a PC workstation running the LeasePak Client software, s/he passes along the environment name to connect to, and the LeasePak daemon, leasepakd, also consults the environment configuration files in $uetc to determine the particulars about the LLDB.