|
HP OpenVMS Systemsask the wizard |
|
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.
|