 |
The Question is:
We are developers of a product which consists of a large no. of cooperative
processes. The processes apply most of the common OpenVMS mechanisms such as
locks, global sections, common event flags, mailboxes, logical names, etc.
Currently we run only one
instance of the product per Alpha. But we are wondering what it would take
to run 2 or more instances on the same Alpha. I have noticed that 2
processes can have the same name as long as their UICs are different. Which
other OpenVMS mechanisms are partiti
oned by UIC?
Thanks
The Answer is :
To keep the groups of processes entirely separate, the processes need
to be in different UIC groups. (There are also a few known cases where
it is possible -- though obviously undesired -- to encounter duplicate
process names within the same UIC group. This is a bug, and recent
OpenVMS updates reduce the incidence of this.) Suffice it to say, you
cannot totally rely on process names being unique.
Working through your objects:
Locks are potentially system or cluster wide regardless of UIC, but
to create a system wide lock requires privilege. Locks can also be
specified to be within a "resource domain". For details, please see
the OpenVMS Programming Concepts manual and the rsdm_id parameter to
the SYS$ENQ system service.
Global sections are potentially system-wide, but can also be bound
within a UIC group. A system-wide section requires privilege.
Common Event Flag clusters may only be shared between processes in the
same UIC group.
Mailboxes are inherently system wide (as is any other OpenVMS device)
but are subject to device protection masks and device ACLs, and -- in
the case of mailboxes, the mailbox logical names and protection masks
can be used to partition mailbox access to specific UIC groups.
(Mailboxes will be accessed via the associated logical name, device
protection mask or process privilege(s) or device ACL permitting.)
With the PRMMBX privilege, a permanent mailbox can be created with a
system wide logical name.
Logical names are defined in tables. There are a number of logical
name tables to choose from, with different levels of scope. By default,
the system provides LNM$PROCESS (private), LNM$JOB (visible to a process,
it's parent, siblings and children), LNM$GROUP (visible to all processes
with the same UIC group number), LNM$SYSTEM (system wide) and (in V7.2
and later) LNM$CLUSTER (cluster wide). In addition, you can create
specific logical names with arbitrary visibility. (For details on
the logical name tables used for the mailbox logical names, please see
the LNM$PERMANENT_MAILBOX and LNM$TEMPORARY_MAILBOX logical names.)
Without knowing how your application works, it is difficult to predict
how multiple instances might interact, if at all. By default, the
non-privileged use of any of the above mechanisms will probably limit
their use to within a single UIC group. It should therefore be possible
to run an independent instance in a second UIC group -- assuming data
files and other storage is also kept separate -- with no source code
modifications required.
Conversely, if you want the instances to interact, you may need to
modify the mechanisms you use if they must operate across UIC groups.
You will need to examine each case independently to check there is no
undesired interaction or insure that desired interaction works
correctly.
As another option (on specific Alpha platforms running OpenVMS Alpha
V7.2 or later), you can consider using the OpenVMS Galaxy mechanism,
and operate with multiple instances of OpenVMS and applications within
the same physical system enclosure. Each instance operating within
an OpenVMS Galaxy configuration appears to be unique node -- you can
use as many seperate copies of your existing application in parallel
as you have instances configured, and no source code changes are
required.
|
|
|
|
|
