Open System Services Programmer's Guide

Table 45 Message_Data (Access Control) (continued)
DescriptionTypeField
The OSS object's new group. Valid only for the chgrp()
function.
int (4 bytes)NewGroup
The file mode.int (4 bytes)Mode
The new file mode for the chmod() function.int (4 bytes)NewMode
Also the open or access type for the open(),
open64(), FILE_OPEN_ and access() APIs.
TRUE indicates the file belongs to a restricted-access
fileset.
BooleanIsRestrictedFileset
A future expansion area; currently filled with zeros.24 bytesFEA
OSS SEEP Design
The following restrictions and considerations for the OSS SEEP design are applicable to both the
OSS SEEP process and its child processes.
• The OSS SEEP must be a Guardian process.
• The OSS SEEP must be multithreaded and must not perform waited I/O.
• The OSS SEEP must not use any OSS functions that involve OSS name server interaction.
• The OSS SEEP must consider the final close message from the OSS name server as a stop
message and do a graceful shutdown of itself.
• Do not specify $SYSTEM.SYSTEM.NULL as the SEEPPROGFILENAME attribute.
• The OSS SEEP must open its $RECEIVE queue and respond to the handshake message from
the OSS name server in order to complete the initialization.
• In the case of a primary OSS name server failure and backup takeover during the initialization
phase, the OSS SEEP might receive a second handshake message, which is sent from the new
primary. The OSS SEEP is expected to reply to this handshake message.
• The OSS SEEP must set the BypassSafeguard bit.
• The OSS SEEP is required to call PROCESS_GETINFOLIST_ to determine whether the process
performing the file operation is an OSS process (or not) and to retrieve the OSS pathname of
that program. (The OSS name server does not include this information in the message sent to
the OSS SEEP.)
IMPORTANT: Attribute 158 must be used in the call to PROCESS_GETINFOLIST_ to obtain
the fully qualified OSS program pathname for the OSS program. Using attribute 93 can lead
to a deadlock between the OSS SEEP process and the OSS name server process.
OSS SEEP-Related EMS Events
The OSS name server generates EMS events to $0 and $ZLOG for each of the following conditions:
• The OSS SEEP is successfully started. The EMS event reports the OSS SEEP state change from
STOPPED to RUNNING.
• The OSS SEEP is stopped or an OSS SEEP death occurs. The EMS event reports the OSS SEEP
state change from RUNNING to STOPPED.
• The OSS SEEP failed to start. The EMS event reports the OSS SEEP state change from STOPPED
to STOPPED with the error indicating the reason for failure.
OSS SEEP Programming 283