PAM Management Programming Manual
SPI Programming Considerations for the PAM
Subsystem
PAM Management Programming Manual—142481
3-9
Security
General programming considerations for handling errors that occur when using the
management-programming interfaces are discussed in the SPI Programming Manual.
Error-handling considerations for specific commands are described in Section 5,
Commands and Responses. The error numbers returned by the PAM subsystem are
described in Appendix A, Error Numbers and Error Lists.
Security
PAM subsystem commands are either sensitive or nonsensitive. Sensitive commands can
change the state or configuration of subsystem objects, start or stop tracing, or change
values of statistics counters; nonsensitive commands cannot. SCP allows sensitive
commands to be issued only by members of the super group (super ID 255) or the user
group that owns the PAMMAN process, $ZZPAM.
When an application that is not allowed to issue sensitive commands attempts to issue
one, SCP returns an error. For more information on sensitive commands, refer to
Section 5, Commands and Responses
.
Discontinuing a Command in Progress
The PAM subsystem supports the use of the token ZSPI-TKN-ALLOW-TYPE, which
allows an application to specify, in a command operating on multiple objects, whether or
not the PAM subsystem should continue immediately to the next object if it failed on the
previous one. If no value is specified for this token, the PAM subsystem continues to the
next object only if no errors or warnings occurred on the previous one.
When the PAM subsystem discontinues a command because of an error or a warning, it
immediately sends a reply message to the application. The reply message contains a
context token. The application can choose to resend the command with the context
token, causing the PAM subsystem to proceed to the next object, or the application can
choose to abandon the command.
General programming considerations for discontinuing a command in progress are
discussed in the SPI Common Extensions Manual.
Retrieving and Decoding Event Messages
Your application must take the following steps to retrieve and act upon event messages:
1. Declare a buffer of appropriate size for the Event Management Service (EMS)
GETEVENT command and its responses.
2. Start the EMS consumer distributor and open it with the #ZSPI qualifier on the
process name.
3. Format an EMS distributor CONTROL programmatic command to load a filter you
have written and to specify the source and destination of event messages, if desired.
(The filter selects which event messages you want your application to process.)
Send the CONTROL command to the consumer distributor using the mechanism
appropriate to your programming language (for example, a WRITEREAD call in
TAL).