The Question is:
In a mixed OpenVMS cluster we have:
2 New Alphas (ES40 dual processor) on VMS V7.3
3 Vaxes on VMS 6.2
3 times in the last 10 days the cluster has refused user logns. VMS prompts for
a username but then fails to prompt dor a password and the user is left
hanging. This happens on ALL machines in the cluster simultaneously so we are
unable to get any informa
tion from the cluster.
[alternate e-mail is firstname.lastname@example.org]
The Answer is :
Please upgrade your OpenVMS VAX systems to V7.3 -- V7.0 was NOT a
major upgrade for OpenVMS VAX, and your span of cluster versions
is rather long.
Apply the available mandatory ECO kits for the OpenVMS release(s)
Ensure that you have all files that must be common within an OpenVMS
Cluster configured as common -- see SYLOGICALS.TEMPLATE on OpenVMS
V7.2 and later for a list of these files.
You will need to determine the pattern of the hanging -- is this a
hang effecting a single user (or maybe a few users with records
sharing a bucket within the SYSUAF file), or are the effects this
hang rather more widespread?
Do you have a mix of low-priority jobs and interactive jobs running
when the stall occurs? (It is possible that a low-priority process
(eg: batch job sending MAIL) can acquire a lock that will block
higher-priority jobs for some interval -- this is why the PIXSCAN
system parameter exists.)
The output of ANALYZE/SYSTEM (SDA) or particularly an AMDS or
Availability Manager trace would be very useful. If you have a
session where SDA can be invoked, locate the stalled process,
set the context to that process, and SHOW PROCESS/LOCK. The
stalled process will probably be running LOGINOUT.EXE. (Newer
versions of SDA have better lock-tracking capabilities.)
Tracking lock contention using tools such as AMDS and Availability
Manager is rather easier than tracking locks using SDA.
Do you have errors being logged on any system?
Please contact the Compaq Customer Support Center, as additional
details on this stall/hang will be required.