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.