  Multiple Application Instances? 
 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.
 
