skip book previous and next navigation links
go up to top of book: HP OpenVMS Alpha Partitioning and Galaxy Guide HP OpenVMS Alpha Partitioning and Galaxy Guide
go to beginning of chapter: Shared Memory Programming Interfaces Shared Memory Programming Interfaces
go to previous page: System Services System Services
go to next page: OpenVMS Galaxy Device DriversOpenVMS Galaxy Device Drivers
end of book navigation links

Galaxy-wide Global Sections  



The SHMEM privilege is required to create an object in Galaxy shared memory. The right to map to an existing section 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 Galaxy-wide sections.

Creating and mapping Galaxy-wide memory sections is accomplished through the same services used to create memory resident sections. The following services now recognize the SEC$M_SHMGS flag:

SYS$CREATE_GDZRO and SYS$CRMPSC_GDZRO_64 can also return new status codes.

Status Code Description
SS$_INV_SHMEM
Shared memory is not valid.
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_TIMEOUT
A Galaxy lock timed out.

The INSTALL LIST/GLOBAL and SHOW MEMORY commands are also aware of Galaxy-wide sections.

Galaxy-wide 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 Galaxy-wide system global sections and Galaxy-wide group global sections all with the same name.

Galaxy-wide sections also have their own security classes:

These security classes are used with the $GET_SECURITY and $SET_SECURITY system services, and DCL commands SET/SHOW SECURITY.

These new security classes are only valid in a Galaxy environment. 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 Galaxy-wide sections look like this:

%%%%%%%%%  OPCOM  20-MAR-2002 10:44:43.71  %%%%%%%% (from node GLX1 at 20-MAR-2002 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-2002 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" field: 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_0$
An identifier for the sharing community.
MY_SECTION
The name of the section as specified by the user.

The user can only specify the section name and class for requests to set or show the security profile. The UIC is always obtained from the current process and the community identifier is obtained from the community in which the process executes.

The output for a Galaxy-wide system global section differs only in the fields "Object class name" and "Objects name." The object name for this type of section does not include a group identification field:

Object class name:
GLXSYS_GLOBAL_SECTION
Object name:
WAY____D99DDB03_0$SYSTEM_SECTION


Note

Security Notes: 



Security attributes for a Galaxy-wide memory section must appear identical to a process, no matter on what instance it is executing.

This can be achieved by having all instances participating in this sharing community also participate in a homogeneous OpenVMS Cluster, where all nodes share the security-related files:

  • SYSUAF.DAT, SYSUAFALT.DAT (system authorization file)


  • RIGHTSLIST.DAT (rights database)


  • VMS$OBJECTS.DAT (objects database)
In particular, automatic propagation of protection changes to a Galaxy-wide section requires that the same physical file (VMS$OBJECTS.DAT) is used by all sharing instances.

If your installation does not share these files throughout the Galaxy, the creator of a Galaxy-wide shared section must ensure that the section has the same security attributes on each instances. This may require manual intervention.



go to previous page: System Services System Services
go to next page: OpenVMS Galaxy Device DriversOpenVMS Galaxy Device Drivers