HP-UX SNAplus2 R7 NOF Programmer's Guide

NOF API Verbs
DEFINE_SECURITY_ACCESS_LIST
• 120 seconds (2 minutes) for AP_HIGH
• 60 seconds (1 minute) for AP_NETWORK
3.42.3 Returned Parameters: Successful Execution
If the verb executes successfully, SNAplus2 returns the following parameters:
primary_rc
AP_OK
3.42.4 Returned Parameters: Parameter Check
If the verb does not execute because of a parameter error, SNAplus2 returns the following parameters:
primary_rc
AP_PARAMETER_CHECK
secondary_rc
Possible values are:
AP_INVALID_PATH_SWITCH_TIMES
The
path_switch_times parameter was not valid; for example, you may have specified a value for one
transmission priority that exceeds the value specified for a lower transmission priority.
Appendix B, Common Return Codes lists further secondary return codes associated with
AP_PARAMETER_CHECK
,
which are common to all NOF verbs.
3.42.5 Returned Parameters: Other Conditions
Appendix B, Common Return Codes lists further combinations of primary and secondary return codes that are
common to all NOF verbs.
3.43 DEFINE_SECURITY_ACCESS_LIST
DEFINE_SECURITY_ACCESS_LIST defines a list of users who can access a particular local LU or invokable TP,
so that access to that LU or TP is restricted to the named users. It can also be used to add user names to an existing
security access list. The user names in the list are defined using the DEFINE_USERID_PASSWORD verb.
To restrict access for a particular local LU or invokable TP, you need to do the following.
1. Ensure that each authorized user of the LU or TP is defined using the DEFINE_USERID_PASSWORD verb.
2. Use the DEFINE_SECURITY_ACCESS_LIST verb to define a security access list containing all of these user
IDs.
3. Specify the name of this security access list on the DEFINE_LOCAL_LU or DEFINE_TP verb that defines the
LU or TP.
When an incoming Allocate request arrives for a local LU or an invokable TP that has a security access list defined,
the invoking application must indicate that conversation security is to be used, and specify a user ID. In addition to
the standard conversation security checking (against user IDs specified using the DEFINE_USERID_PASSWORD
verb), SNAplus2 checks the user ID in the incoming allocate request against the security access list defined for the
LU or TP, and rejects the conversation if the user ID does not match. If both the LU and the TP have security
access lists defined, the user ID must be in both lists.
252