15.3 Galaxywide Global Sections
The SHMEM privilege is required to create an object in
Galaxy shared memory. The right to map to an existing sec-
tion is controlled through normal access control mechanisms.
SHMEM is not needed to map an existing section. Note
that the VMS$MEM_RESIDENT_USER identifier, which is
needed to create an ordinary memory resident section is not
required for galaxywide sections.
Creating and mapping galaxywide memory sections is ac-
complished through the same services used to create memory
resident sections. The following services now recognize the
SEC$M_SHMGS flag:
SYS$CREATE_GDZRO
SYS$CRMPSC_GDZRO_64
SYS$MGBLSC_64
SYS$DGBLSC
SYS$CREATE_GDZRO and SYS$CRMPSC_GDZRO_64
can also return new status codes. To be supplied-more
details about these:
SS$_INV_ Shared memory is not valid.
SHMEM
SS$_INSFRPGS Insufficient free shared pages or private pages.
SS$_NOBREAK A Galaxy lock is held by another node and was not
broken.
SS$_LOCK_ A Galaxy lock timed out.
TIMEOUT
$ INSTALL LIST/GLOBAL and $ SHOW MEMORY also
know about glaxywide sections. To be supplied-some
additional documentation about these.
Galaxywide sections are using their own name space. Just as
you could always use the same name to identify system global
sections and group global sections for various owner UICs,
you can now also have galaxywide system global sections and
galaxywide group global sections all with the same name.
Galaxywide sections also have their own security classes:
GLXSYS_GLOBAL_SECTION
GLXGRP_GLOBAL_SECTION
These security classes are used with the $GET_SECURITY,
$SET_SECURITY system services, and the SET/SHOW
SECURITY DCL commands:
These new security classes are only valid in a Galaxy envi-
ronment. They are not recognized on a non-galaxy node.
You can only retrieve and affect security attributes of galaxy-
wide global sections if they exist on your sharing instance.
Audit messages for galaxywide sections look like this:
%%%%%%%%% OPCOM 20-MAR-1998 10:44:43.71 %%%%%%%% (from node GLX1 at 20-MAR-1998 10:44:43.85)
Message from user AUDIT$SERVER on GLX1
Security alarm (SECURITY) on GLX1, system id: 19955
Auditable event: Object creation
Event information: global section map request
Event time: 20-MAR-1998 10:44:43.84
PID: 2040011A
Process name: ANDY
Username: ANDY
Process owner: [ANDY]
Terminal name: RTA1:
Image name: MILKY$DKA100:[ANDY]SHM_MAP.EXE;1
Object class name: GLXGRP_GLOBAL_SECTION
Object name: [47]WAY____D99DDB03_0$MY_SECTION
Secondary object name: <galaxywide global section>
Access requested: READ,WRITE
Deaccess key: 8450C610
Status: %SYSTEM-S-CREATED, file or section did not exist; has
been created
Note the "Object name" record: the object name displayed
here uniquely identifies the section in the OpenVMS Galaxy.
The fields are as follows:
[47] (only for group global sections) identifies the
UIC group of the section creator.
WAY_ __ _D99DDB03_ An identifier for the sharing community.
0$
MY_SECTION The name of the section as specified by the
user.
The user can only specify the section name and class for re-
quests to set or show the security profile. The UIC is always
obtained from the current process and the community iden-
tifier is obtained from the community in which the process
executes.
The output for a galaxywide system global section differs only
in the fields "Object class name" and "Objects name". The ob-
ject name for this type of section does not include a group
identification field:
Object class GLXSYS_GLOBAL_SECTION
name:
Object name: WAY_ __ _D99DDB03_0$SYSTEM_SECTION
Important Security Notes
Security attributes for a galaxywide memory section
must appear identical to a process no matter on what
instance it is executing.
This can be achieved by having all instances partici-
pating in this sharing community also participate in
a "homogeneous" OpenVMS Cluster where all nodes
share the security related files:
SYSUAF.DAT, SYSUAFALT.DAT (system autho-
rization file)
RIGHTSLIST.DAT (rights database)
VMS$OBJECTS.DAT (objects database)
In particular, automatic propagation of protection
changes to a galaxywide section requires that the
same physical file (VMS$OBJECTS.DAT) is used by
all sharing instances.
If your installation does not share these files through-
out the Galaxy, the creator of a galaxywide shared
section must ensure that the section has the same se-
curity attributes on each instances. This may require
manual intervention.