This chapter describes the environments supported by
3.1 Environment Types
There are a number of environments supported by SysWorkstm. Each of these environments falls into one of 7 categories as listed in Table 3-1.
|Common||Application common - supports a multi class CMS library and any non version oriented non production application utilities.|
|Development||Application development - supports work and user subdirectories and a mainline of descent in CMS.|
|Maintenance||Application maintenance - supports work and user sub-directories and a variant line of descent in CMS.|
|Development Testing||Application testing - supports work sub-directories and a mainline of CMS descent. Development environments are migrated to development testing environments.|
|Maintenance Testing||Application testing - supports work sub-directories and a variant of CMS descent. Maintence environments are migrated to maintenance testing environments.|
|Production||Application production - supports no work or CMS library.|
|Other||Non application environments - used for USER and GROUP environments.|
Each environment code must be between 2 and 5 characters long.
3.1.1 Application Common
The application common environment is used to manage a common CMS
library with multiple classes for all versions and environments of an
application. It may also be used to store application utilities which
are nt part of the actual application software which is subject to
version and change control. The default application common environment
code shipped with SysWorkstm is APPL.
The application development environments are used to develop new
versions of applications. A new version is commonly stored as the
mainline in a CMS library. A typical development environment code is
The application maintenance environments are used to maintain existing
versions of an application. A maintenance release is commonly stored as
a variant stream in a CMS library. A typical maintenance environment
code is MNT.
3.1.4 Development Testing
The application development testing environments are used to test new
versions of an application before final migration into production. A
typical development testing environment code is DTST.
3.1.5 Maintence Testing
The application maintenance testing environments are used to test
maintenance releases of an application before final migration into
production. A typical maintenance testing environment code is MTST.
The application production environments. There must be at least one application production environment with a code of PROD in which SysWorkstm itself resides. Other typical production style environment codes include PRD.
Typically only one (or two if the site preferred code differs from the
SysWorkstm required code) production style environment will
be used. If multiple production versions need to be supported within a
given cluster, the preferred option is to use trailing letters, eg.
PRODA, PRDB etc.
The other environments are not used by applications. There are two
shipped with and required by SysWorkstm, these being USER
and GROUP. The USER environment is used to manage users and the GROUP
environment is used to manage groups of users which do not require the
formality of an application.
A typical set of environments is illustrated in Table 3-2
|Environment Code||Usage||Developer Directories||appl_CMS_PATH||appl_CMS_VARIANT|
|FDEV||Future Development||Yes||None||None 1|
|DTST||Development Testing||Yes at public level; No at higher levels||appl_DTST||None 1|
|MTST||Maintenance Testing||Yes at public level; No at higher levels||appl_MTST||A|
This chapter describes the actions performed and hooks used at login time.
The OpenVMS username of a user must be between 2 and 12 characters long.
This section describes the interaction between SysWorks and
DECwindows/Motif. Each DECwindows application or utility has code by
which it is distinguished within SysWorks. Table 4-1 lists the
current DECwindows applications and/or utilities supported by SysWorks.
4.1.1 Profile Library
Users and developers gain access to DECwindows applications and utilities through profile files. Access to the SysWorks enhanced profile files is gained through the search list logical name SWRK_VUE_LIBRARY. Each item in this search list specifies a system user class or application environment to which the user has access.
Example 4-1 shows a typical translation of SWRK_VUE_LIBRARY.
|Example 4-1 Typical SWRK_VUE_LIBRARY logical name|
$ show logical SWRK_VUE_library "SWRK_VUE_LIBRARY" = "SWRK_DAT_ROOT:[ALL]" (LNM_JACKSON_SL) = "SWRK_DAT_ROOT:[DEVELOPER]" = "SWRK_DAT_ROOT:[OPERATOR]" = "SWRK_DAT_ROOT:[PATHWORKS]" = "SWRK_DAT_ROOT:[SYSTEM_MANAGER]" = "SWRK_DAT_ROOT:[USER]" = "DISK_DEV3:[SWRK.DAT]" = "DISK_PROD2:[SWRK.DAT]" = "DISK_APPL3:[SWPUB.DAT]" = "DISK_DEV3:[SWPUB.DAT]" = "DISK_DTST3:[SWPUB.DAT]" = "DISK_MNT3:[SWPUB.DAT]" = "DISK_MTST3:[SWPUB.DAT]" "SWRK_VUE_LIBRARY" = "SWRK_DAT_ROOT:[NEVER]" (LNM$SYSTEM_TABLE)
A search list is used rather than security on the profile files because DECwindows produces errors when attempting to access a profile file to which the user or developer cannot gain access.
When SysWorks is installed with a license level of Administrator or above, access is granted by the various user management procedures If SysWorks is installed with a lower license level (eg. SysWorks Developer) this access is granted in the site specific file SWRK_LCL_DIR:SWRK_ALTERNATIVE_IDENTIFIERS.DAT which contains a list of SysWorks standard identifier names followed by optional site specific identifiers.
Example 4-2 illustrates a site specific view list. In this example all users would gain access to the DEVELOPER system users class profiles, the users JONES_AB and MINTER_BM would gain access to the SYSTEM_MANAGER system users class profiles, and holders of the FINDEV identifier would gain access to the profiles associated with the FIN application in development.
|Example 4-2 Typical SWRK_ALTERNATIVE_IDENTIFIERS.DAT|
!++ ! ! File: ! SWRK_ALTERNATIVE_IDENTIFIERS ! ! Purpose: ! Provide ACME Widgets public ! System User Classes and Application ! Environment User Classes ! ! History: ! 20-Aug-1992 by Simon L. Jackson ! Initial version ! !-- S_ALLIN1 S_DEVELOPER S_USER A_FIN_DEV_MGR CAPSUP A_FIN_MNT_MGR CAPSUP A_MAN_DEV_MGR DSSSUP A_MAN_MNT_MGR DSSSUP A_RIM_DEV_MGR FRSSUP A_RIM_MNT_MGR FRSSUP
Applications and groups may have DECwidnows profiles. These must reside
in the application or group's data directories. A typical use of these
profiles is to have some predefined views for developers. Note that if
SysWorks is installed at the Administrator level or higer, a template
profile file including a terminal menu item is created when the
application environment is created. These profile files may be created
ond modified using the Create Public Profile item from the
Utilities => Any Item menu.
4.1.3 DECwindows Application Execution Context
In Table 4-1, the Move column indicates whether SysWorks attempts to execute a CONTEXT APPLICATION, GROUP, HOME or USER command prior to executing the application or utility, and a HOME command afterwards. The application, group or user to which the process context will be moved is determined from the default directory inherited from the initiating view.
For example, if the view has a directory of DISK_DEV4:[FIN.WRK.JONES_AB], the APPLICATION command used will set the process context to the development environment of the FIN application. If the move indicator is No, a search is made for a sub-directory of DISK_USER:[username.dw-appl-code] to act as the default directory for the application or utility excecution. If this is not found, the users DECwindows sub-directory (eg. DISK_USER:[username.DECW] or if not present the users SYS$LOGIN: directory) is used.
Before each application or utility is started, a search is made of the
users DECwindows directory (either DISK_USER:[username.DECW]
or the users SYS$LOGIN: directory) for a command procedure with a name
of the format dw-appl-code_ENTER.COM. If this is found it is
executed after any move as described above and before the application
or utility is started. Similarly a search is made for a DCL command
procedure with a name of the format dw-appl-code_EXIT.COM, and
if found, this is executed after the application or utility finishes,
but before any move home is done. See section 3.2 for more details.
SysWorks provides the DECTERM and NETTERM DCL commands and a Session Manager pulldown menu for creating DECterms around the network. The DECTERM command and the Terminals => DECterm menu item create a DECterm on the local node.
The NETTERM command and the Terminals => Remote DECterm menu item create DECterms on other nodes.
Although the effect of DECTERM and NETTERM 0 (where the zero implies the current node to DECnet) may appear the same, the method used is quite different. Because these commands utilize resource files and an enhanced template is supplied with SysWorks, the first time that a user saves their terminal options on a cluster, they will have to specify Options => Save Named Options rather then Options => Save Options to save their preferred defaults in their DECwindows directory.
|ACAS||Yes||ACA Services DECwindows interface|
|ADVISE||No||DECpc Performance Adviser|
|BASIC||Yes||Interactive Basic for OpenVMS|
|CREATE_PUBLIC_PROFILE||No||Create a public DECwindows profile file|
|DEBUG||Yes||Multi session DECset debugger|
|DOCUMENT_GRAPHICS||Yes||DECdocument Graphics Editor|
|ISOSAHEDRON||No||DECwindows example isosahedron|
|LINKWORKS_SETUP||No||Linkworks login setup|
|MESSAGES||No||Extended message window setup|
|MWM||No||DECwindows Window Manager|
|POLYCENTRE_FILE_OPTIMISER||No||POLYCENTRE File Optimiser (Defragmenter)|
|PRINT_SCREEN||No||DECwindows Print Screen|
|PURGE_WINDOW_PROCESSES||No||SysWorks unused DECwindow process purge|
|SOFTPC||No||SoftPC DECwindows interface|
|UPDATE_SYSTEM_PROFILE||No||Update a system DECwindows profile|
|Big Moon||1280 x 1024 moon background|
|Fish||Fish game background|
|Garden||Lush colorful garden background|
|Isosahedron||DECwindows example isosahedron|
|Moon||1024 x 864 moon background|
This section describes the command procedures used during login.
The user DECW$LOGIN.COM procedure is normally executed during a DECwindows session manager startup.
The system DECW$SYLOGIN.COM procedure is normally executed during a DECwindows session manager startup.
The user ENTER.COM procedure, which is searched for in [user-name.SFT] and then in SYS$LOGIN:, is executed by the USER command when the user moves from an application, group or home environment to their user environment.
The user EXIT.COM procedure, which is searched for in [user-name.SFT] and then in SYS$LOGIN:, is executed by the USER command when the user moves from their user environment to an application, group or home environment.
The user HOME.COM procedure, which is searched for in [user-name.SFT] and then in SYS$LOGIN:, is executed by the HOME command when the user moves from an application, group or user environment back to their home environment.
A DECwindows enter procedure, which is searched for in [user-name.DECW] and then in SYS$LOGIN:, is used to perform DECwindows application specific activities prior to the execution of a DECwindows application.
For example the procedure [user.DECW]CMS_ENTER.COM might contain commands to define the CMS library to be related to the current default directory as passed from the session manager or FileView. DECwindows application codes include: Code Application CMS CMS DTM DTM WRITE DECwrite
A DECwindows exit procedure, which is searched for in [user-name.DECW] and then in SYS$LOGIN:, is used to perform DECwindows application specific activities after the execution of a DECwindows application.
For example the procedure [user-name.DECW]CMS_EXIT.COM might contain commands to deassign the clear the default CMS library. DECwindows application codes are listed under the dw-appl-code_ENTER.COM section.
A DECwindows login procedure, which is searched for in [user-name.DECW] and then in SYS$LOGIN:, is used to perform DECwindows application specific activities prior to the first execution of the application image. For example the procedure [user-name.DECW]CMS_LOGIN.COM might contain commands to define a CMS library search list of all the CMS librariues that the user has access to.
The user LOGICAL.COM procedure, which is searched for in [user-name.SFT] and then in SYS$LOGIN:, is used to define user based logical names in either the process, job or user logical name tables. This procedure should use the DEFAPP and DEFROT commands to define the logical names