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).










