Group-wide LOGIN Profiles Lower Risk, Decrease Cost

Making changes to SYS$MANAGER:SYLOGIN.COM is potentially hazardous. What seems like an insignificant change can have regrettable side effects. In some cases, a change made to enhance the interactive environment has caused production batch and detached processes to fail. In other cases, different parts of a user community find themselves at odds over a particular change. These difficulties are unnecessary. Enhancing SYS$MANAGER:SYLOGIN.COM to support group-specific login processing is straightforward, decreases risks of collateral damage, and simplifies system management workload.

Balancing safety and efficiency is often difficult. Local changes affect fewer users and are thus inherently safer than system-wide changes. System-wide changes have economies of scale, as well as being easier to police and manage. Changes to the login environment are no different than any other issue in this respect. System-wide changes have more risk than local changes. Changing login preferences on a more limited basis is far safer. While individual user logins are an obvious choice for limiting the scope and risk of changes, they are correspondingly harder to maintain and control. OpenVMS groups represent an intermediate choice; a natural dividing line where changes can be implemented with a balance of scale and risk. Groups are a not as broad a context as system-wide; yet they are a larger scale than individual users. Moderation reduces the risk and also limits the maintenance complexity. The risk of an error or mis-step is reduced when changes are made on a group-wide basis. For example, it is possible to make changes to the development environment without running the risk of adversely affecting production; even on the same OpenVMS instance.

Seen in this context, modifying SYS$MANAGER:SYLOGIN.COM is a crude bludgeon. Most changes are not global in scope; changes are most often local to a particular set of users within an installation. The SYLOGIN mechanism as distributed with OpenVMS is global in scope, executed when any process is created. OpenVMS also contains the tools needed to facilitate customizations on a more nuanced level. While the basic execution of SYS$MANAGER:SYLOGIN.COM is global; the SYLOGIN mechanism can be enhanced to provide finer precision (e.g., an individual OpenVMS group). It also reduces the scope and risks associated with the modifications. This installment of the OpenVMS Consultant will demonstrate how the SYLOGIN mechanism can be extended to include individual group processing. The specific processing is then controlled by a group leader. Most importantly, the group leader can be allowed to manage his users' environment without the need for system-level privileges.

This is the third installment in a series of columns on managing the SYLOGIN process. The general concepts, principles, and dangers of modifying files executed as part of initial process creation were the subject of the first installment (see SYS$MANAGER:SYLOGIN.COM: Flexibility Requires Prudence). The second installment, SYS$MANAGER:SYLOGIN.COM - Verification of SYLOGIN processing without disruption, discussed safe approaches to fault isolation when making changes to the SYLOGIN procedures.

This installment will discuss a different aspect: delegating group login profile maintenance to individual, relatively non-privileged group managers. It represents a straightforward approach toward achieving two important ends: the limitation of privilege, and delegation of responsibility.

Delegation is often underappreciated. Delegation is an important foundation of running large, diverse OpenVMS user communities. Delegation localizes responsibility for consequences within the group most affected by changes. Localization is beneficial whether the changes are correct, or whether the changes have errors. This leverages the organization more effectively than requiring the systems management group to perform these tasks. Delegating the management of group-wide resources to relatively non- privileged group managers was one of the foundations of my workshop at the 2004 HP World Conference, OpenVMS User Environments. Clearly, while group managers are responsible for modifications, the systems management group retains the authority to intervene as necessary. The delegation of authority for the group-wide environment is always within the limits established by the system authorization file (SYSUAF).

Similarly, the group directory tree, implemented as a DISK$[group name] logical name, with the appearance of a group-private disk (described in The OpenVMS Consultant: Logical Names: Part 5), is a similarly useful concept that can be used as a foundation for group-local initialization.

Group-private initializations also provide a proving ground for adaptations. If a change in the underlying environment is beneficial to one group, it may be worth consideration for another group. If such a change is found to be of widespread applicability, it can be considered for inclusion in the system-wide login, albeit at far reduced risk; having been already proven within one or more groups. Intermediate stages are also possible.

Providing group-specific SYLOGIN processing is straightforward. A simple modification to SYS$MANAGER:SYLOGIN.COM is all that is needed to facilitate group-specific login execution. As noted earlier, this enhancement is fully compatible with the OpenVMS hierarchy and philosophy.

Preferentially, I create a volume or pseudo-volume (e.g., rooted logical name) for each group. The rooted name approach (see Logical Names: Part 5) has the advantage of easing backup and volume management. Alternatively, groups can also be placed on their own logical disks (created and accessed using LDDRIVER). If an enterprise storage controller is in use, with support for virtual volumes, it becomes possible to create a volume for each group of the appropriate size for each group.

Implementing hierarchical SYLOGIN processing is simple. During SYLOGIN execution, a check is made to see if there is a group-defined login command file. There are a variety of ways that this can be accomplished. Some common techniques are:

As an example, the code to check for [0,0]GROUPLOGIN.COM is extremely simple, to wit:


The context of the executing group login profile is the same as that of SYLOGIN. Normally, I place the code relating to the group login as the last step of SYLOGIN execution, following the comments in the standard SYLOGIN.COM indicating place your site-specific LOGIN commands below. This is the point in the SYLOGIN code path where differing paths of execution coalesce back to a single execution path. This placement ensures that the group login profile is attempted for all processes.

The contents of the group login are completely up to those maintaining it. It can define DCL shortcuts;

The profile should contain a DCL GOTO section (see DCL Computed GOTO).

An example of the code that needs to be added to SYLOGIN, together with a simple skeleton of a group wide login profile can be found at

Group login profiles are a well-structured customization to the standard OpenVMS environment. As can be seen by the comments at the end of the supplied SYS$MANAGER:SYLOGIN.COM, there are already clearly marked locations for the inclusion of site-specific customizations; group logins are merely a structured way of extending standard SYLOGIN. This extension delegates group login profile management to non-privileged group managers while retaining system security. Changes to group-specific login profiles can only impact an individual group. The net result of this is lower costs through better control and a decrease in required maintenance effort.

URLs for referencing this entry

Picture of Robert Gezelter, CDP
RSS Feed Icon RSS Feed Icon
Follow us on Twitter
Bringing Details into Focus, Focused Innovation, Focused Solutions
Robert Gezelter Software Consultant Logo
+1 (718) 463 1079