Enabling Native Security

Contents
ce17
Contents
2
Native Security Tables
Native Security Tables let you protect the functional side of your system. Native security protects your environments, systems, and subsystems from unauthorized access. In addition, element names can be defined for use only within specific systems or subsystems.
You can use the
CA Endevor® SCM
External Security Interface (ESI) instead of native security if you want to integrate your existing security package with
CA Endevor SCM
.
For more information about ESI, see The External Security Interface (ESI). For more information about deciding whether ESI is an appropriate security option for your installation, see Security Options.
CA Endevor SCM
uses three tables to restrict access to functions and inventory levels:
  • Access Security Table
    Defines the environment(s) to which each user has access. One Access Security Table exists for each installed site.
    The Access Security Table must always be present in each site.
  • User Security Table
    Defines the systems/subsystems available to each user within a particular environment, and for each system/subsystem combination, the level of activity for which each user is permitted access (browse-only, delete, add).
    There is one User Security Table for each environment.
  • Resource Security Table
    Defines any elements that are restricted to particular a system/subsystem, and for each restricted element, the type of action for which the restriction applies.
    This table is defined separately for each environment and there is only one Resource Security Table for each environment.
To prevent user access to specific systems/subsystems or environments, define the Access Security Table and the User Security Table. To prevent unauthorized access to elements and actions, explicitly define the Resource Security Table. More security checking is available through User Exit 1.
Native security tables are checked by the system at a series of security control points. The following sections describe the role of security control points in the
CA Endevor SCM
processing flow.
Security Control Points
Security control is handled automatically through a series of security control points. Each control point invokes a routine that checks access and user privileges that are defined in the native security tables.
This figure illustrates the strategic locations of security control points in the
CA Endevor SCM
processing flow. Each security control point controls access to functions and inventories occurring below it.
This figure illustrates the strategic locations of security control points in the processing flow.
For example, the Environment Selection security control point controls access to the Environment menu. The Primary Options security control point controls access to the Primary Options menu. Note the Environment Selection security control point appearing beneath the Batch Options menu. This point regulates access to elements and functions available through the Batch Options and Package Options menus.
In this figure, at each control point, the product checks the native security tables. The product then establishes the access privileges that are defined for a user, environment, system, or subsystem.
This figure illustrates how CA SCM for Mainframe establishes the access privileges.
Environment Selection Security Control Point
This control point (also referred to as the Environment Access security control point) checks the Access Security Table to determine environment access privileges. This security check occurs before building the Environment Selection menu used to gain access to an environment.
Primary Options Security Control Point
This control point checks the User Security Table to determine a user primary option privileges. These privileges include the Defaults, Display, Foreground, Batch, Environment, and Tutorial options. This security check occurs before building the Primary Options menu for an environment after access has been granted through the Environment Selection menu.
Foreground Options Security Control Point
This control point checks the User Security Table to determine user foreground options. These privileges include Display, Add/Update, Retrieve, Generate, Move, Delete, Print, and Signin options. This security check occurs before building the Foreground Options menu for an environment.
The Action Initiation Security Control Point
This control point occurs:
  • Before a cast operation during package processing, if the Defaults Table PKGCSEC flag is set to Y.
  • Before an inspect operation during package processing, if the Defaults Table PKGISEC is set to Y.
  • During package verification processing.
  • Before performing a 
    CA Endevor SCM
     action.
The Action Initiation security control point checks the User Security Table to determine a user action privileges as defined by the user access level. These privileges include actions, such as ADD, RETRIEVE, GENERATE, MOVE, DISPLAY, ALTER, ARCHIVE, RESTORE, COPY, LIST, SIGNOUT OVERRIDE, and ALL options.
Package Actions Security Control Point
This Package Actions security control point occurs before performing the requested package action.
The actions that are used to create and use packages are not controlled by native security. ESI can control them.
Defining User Exit Modules
Define a user exit module at exit point 1:
  1. Supplement the menu-building checks the system makes at each security control point.
  2. Supplement the action-request authorization that occurs at each security control point.
Exit 1 can only further restrict security; it cannot override restrictions that your site security package imposes.
How
CA Endevor SCM
Reads the Security Tables
When verifying access to site components,
CA Endevor SCM
uses the first applicable entry it encounters in each security table.
User Access
To verify user access to an environment,
CA Endevor SCM
checks the Access Security Table for a userid entry that applies for that user. A match to the requesting user ID (user ID 7, for example) could be a full mask ($$$$$$$$), a partial name (USER$), or an exact match on the name (user ID 7) for the User Security and Resource Security tables. For the Access Security Table, you can use a single mask character ($) to specify a full mask for system and subsystem security.
CA Endevor SCM
uses the most restrictive specification that matches the user ID to validate the access.
System or Subsystem Access
To verify user access to a system and subsystem,
CA Endevor SCM
checks the User Security Table for the first entry that applies for that user, matching to a full mask ($), a partial name (USER$), or an exact match on the name (user ID 7). The product uses the specifications that are defined by this entry to validate the access.
Resource Restrictions
To check for restrictions that apply when performing actions,
CA Endevor SCM
looks in the Resource Security Table for an entry that applies to the element specified for the current action (CAELE1, for example). The match by element (resource) name is based on a full mask ($), a partial name (C$), or an exact match to the name (CAELE1).
If
CA Endevor SCM
does not find a table entry for the element, processing continues. If it does find a table entry for the element,
CA Endevor SCM
checks to see if that entry includes the system and subsystem that is specified in the action, matching the table entry system/subsystem name that is based on a full mask, a partial name, or an exact match. If the entry includes the system/subsystem for the action request,
CA Endevor SCM
allows the action if the access level required for the action is specified in the table entry.
If the appropriate access level is not specified
explicitly
in the table entry,
CA Endevor SCM
does not allow the action.
How to Implement Native Security
Follow these steps:
  1. Define the Access, User, and Resource Security Tables to control access to the environments, systems/subsystems, and elements you want to protect from unauthorized access.
  2. Assemble and link-edit each security table that you have defined.
  3. Update the Defaults Table to reference the security tables you have defined.
  4. After you test your functional security, copy the security table that you defined and the new Defaults table, into an authorized library.
  5. Perform an IPL or an LLA refresh.
If you are testing your security system, you do not need to issue an LLA refresh each time that you edit a native security table if the tables are not in an authorized linklist library. When you are ready for production mode, copy your security tables into an authorized linklist library for security, and issue an LLA refresh.
The following sections explain each step in greater detail.
Define Your Native Security Tables
To enable native security, define the native security tables to control access to the inventories and functions you want to protect.
If you do not define the native security tables, these functions are unprotected.
Follow these steps:
  1. Access the native security table you want to define.
  2. Enter the appropriate CONSDEF macros.
    1. The native security table is defined.
  3. Assemble and link-edit the table.
  4. Update the Defaults Table.
  5. Perform an LLA refresh if the table is in an authorized linklist library.
Enter CONSDEF Macros
You use a series of CONSDEF macros to define each security table. Once the CONSDEF macros have been assembled and link-edited successfully for each table, the table definition is complete. The table goes into effect once the Defaults Table is updated. Instructions for updating the Defaults Table appear in Modifying the Defaults Table. Before you code the CONSDEF macros, review the following processes:
  • How to use coding conventions
  • How to specify a mask
  • How the product reads security definitions
For more information about defining each security table, see How to Define the Access Security Table.
If a user is in the product while a security table is being updated or edited, the administrator must exit and reenter the product for the new table to take effect.
Using Coding Conventions
When coding CONSDEF macros, follow the standard IBM rules:
  • Place all macro specifications between columns 2 and 71 of the definition deck. To continue across cards, enter an
    X
    in column 72 and start the continuation card in column 16.
  • Include at least one space between the macro name, CONSDEF, and the first keyword parameter, TYPE. Do not include any more spaces. An exception applies for literal operands, where spaces can be included between the surrounding (single) quotes.
  • Specify each macro keyword fully. You cannot use a shortened version of any keyword.
Security Definition Order
CA Endevor SCM
uses the most restrictive parameters to determine security checks for each user (Access Security Table and User Security Table) and each resource (Resource Security Table).
In the following example, users having IDs that start with the letters CADEV, except for the two exceptions, have access to all systems and subsystems, for all types of processing.
 CONSDEF TYPE=USER,USERID=CADEV1,SYSDEF=((FINANCE,$,N))  CONSDEF TYPE=USER,USERID=CADEV8,SYSDEF=(($,$,N))  CONSDEF TYPE=USER,USERID=CADEV$,SYSDEF=(($,$,ADMPRSUZ,BV))
The two exceptions, CADEV1 and CADEV8, are restricted in the following ways:
  • User CADEV1 can access all systems except FINANCE.
  • User CADEV8 cannot access any system.
How to Define the Access Security Table
You use the Access Security Table to specify the environments to which each user has access. You do so by specifying the unique Stage 1 name for the environment you want to access. One Access Security table exists for each installed site.
Sample access security table source is provided in member ACCSTABL of installation library iprfx.iqual.CSIQSRC.
You define access to environments directly for each user ID or for groups of users. When you specify access for a group, each group must be associated with the specific user IDs included in the group (before or after the group-level definition).
You might use the following specification, for example, to let user DMS access the stage names that you specify. This model lets user DMS access the Stage 1 name in the environment in which it is located:
 TYPE=USER,USERID=DMS,SYSDEF=((stage1-name,$,R),(stage1-name,$,R))
Or, you might permit access to the stage names you specify through group DVLP, then associate user DMS with that group:
 TYPE=USER,GROUP=DVLP,SYSDEF=((stage1-name,$,R),(stage1-name,$,R))  TYPE=USER,USERID=DMS,GROUP=DVLP
To define the Access Security Table, enter CONSDEF macros in the following format:
 CONSDEF TYPE=START,TABLE=USER Form 1:  CONSDEF  TYPE=USER,USERID=user-id,SYSDEF=((stage1-name,$,R)...) Form 2:  CONSDEF  TYPE=USER,GROUP=group-name,SYSDEF=((stage1-name,$,R)...) Form 3:  CONSDEF  TYPE=USER,USERID=user-id,GROUP=group-name  CONSDEF  TYPE=END,TABLE=USER
Use any combination of these statements. Each statement must start with the TYPE=START macro and end with the TYPE=END macro.
Assign each stage in each environment a unique name. Because you are specifying access to environments using the stage name, ensure that each stage name is unique, across environments.
  • type=start,table=user
    Defines the beginning of the Access Security Table definition.
  • type=end,table=user
    Terminates the table definition.
  • type=user
    Either defines the environments accessible to a particular user or group (forms 1 and 2) or associates a user with a group-level access definition (form 3). The TYPE=USER macros can be coded in any order. Be sure, however, that each group associated with a user (form 3) has a corresponding group access definition (form 2).
    A user must be given explicit permission through the TYPE=USER statements to process in a 
    CA Endevor SCM
     environment.
  • type=user Parameters
    Each TYPE=USER parameter is described next.
  • userid=
    userid
    Defines the users for which access information is being specified (form 1) or, if used with a GROUP specification (form 3), the ID of the users who are associated with the group-name. The userid can end with a mask character to include all users having IDs that start with the characters specified or it can be specified as eight mask characters, $$$$$$$$ to include all users. The following parameter specifies all users having IDs that start with AN:
    USERID=AN$
    If your site has userids containing a $, you can change the $ mask to another character. Edit the iprfx.iqual.CSIQOPTN library member MASKMAC and change the &CHAR=$ to another character. In the following example, the mask character is set to @:
    MASKMAC &STRIP=NO,&CHAR=@,&MAXLTH=8 
  • group=
    group-name
    Defines the group (1-8 characters) for which access information is being specified (form 2) or, if used with a user ID specification (form 3), the group that is associated with the specified userid. Group names are specific to this macro; they are not referenced elsewhere within
    CA Endevor SCM
    . A group name might be, for example, PAYROLL, QA, DBA, SYSTEMS, and so forth. After a group is defined, all users who are associated with the group acquire access to the environments defined for the group.
  • sysdef=((
    stage1-name
    ,$,r))
    Specifies an environment to which the user (form 1) or group (form 2) has access. The environment is defined in terms of the stage1-name that is defined for the environment. We recommend using different stage names for each environment. The second and third positional parameters within the SYSDEF specification must be the characters $ and R, respectively.
    The mask character is supported for stage1-name. Generally, however, it is easier to repeat the operands within the parentheses when defining access to multiple environments, as shown in the sample:
    SYSDEF=((stage-1-name,$,R),(stage-1-name,$,R))
Assemble and Link-Edit the Access Security Table
You can use an SMP/E USERMOD to assemble and link-edit ACCSTABL after it has been customized. Alternatively, edit the sample JCL BC1JTABL and use it to assemble and link source module ACCSTABL outside of SMP/E. BC1JTABL is supplied in the installation library iprfx.iqual.CSIQJCL.
After you define the Access Security Table, verify that the JCL is correct. Run the job to assemble and link-edit the new table. The name of the table is specified as the SYSLMOD member name in the JCL.
The output load module for the table is placed in the LOADLIB established during installation.
For testing purposes, you can copy the Access Security Table to a standard load library. When you are ready for production mode, copy the load module to an authorized LINKLIST library. After a link-edit, update the Defaults Table to point to the new Access Security Table. Set the ACCSTBL Defaults Table parameter in the TYPE=MAIN macro to identify the SYSLMOD DD member name that is assigned in the JCL.
How to Define the User Security Table
The User Security Table specifies the systems and subsystems to which each user has access, within a particular environment. For each system/subsystem to which a user has access, the table also specifies the types of processing allowed (retrieve-only, add, update). One User Security Table exists for each environment.
Sample user security table source is provided in member USERTABL of installation library
iprfx.iqual.CSIQSRC
.
You can define access to the systems and subsystems directly for each userid or for groups of users. Where you specify access at the group level, each group must be associated with the specific user IDs included in the group.
You might use the following specification, for example, to allow user DMS access to the Finance and GL systems (all subsystems). The user can access the Finance system to move (M), generate (P), or display (B) elements, and the GL system to display only.
 TYPE=USER,USERID=DMS,SYSDEF=((FINANCE,$,MP,B),(GL,$,,B))
Alternatively, you might permit this access through group ACCT, then associate user DMS with that group:
 TYPE=USER,GROUP=ACCT,SYSDEF=((FINANCE,$,MP,B),(GL,$,,B))  TYPE=USER,USERID=DMS,GROUP=ACCT
Enter the CONSDEF macros using the following format to define the User Security Table:
 CONSDEF TYPE=START,TABLE=USER Form 1:  CONSDEF TYPE=USER,USERID=user-id,[UNTIL=yyddd,]                       X                  SYSDEF=((sys-name,subsys-name,access1,access2)... Form 2:  CONSDEF TYPE=USER,GROUP=group-name,[UNTIL=yyddd,]                     X                  SYSDEF=((sys-name,subsys-name,access1,access2)... Form 3:  CONSDEF TYPE=USER,USERID=user-id,GROUP=group-name  CONSDEF TYPE=END,TABLE=USER   
Use any combination of these statements. They must start with the TYPE=START macro and end with the TYPE=END macro.
  • type=start,table=user
    Defines the beginning of the User Security Table definition.
  • type=end,table=user
    Terminates the table definition.
  • type=user
    Either defines the systems and subsystems accessible to a particular user or group (forms 1 and 2) or associates a user with a group-level access definition (form 3). The type=user macros can be coded in any order. Make sure, however, that each group associated with a user (form 3) has a corresponding group access definition (form 2).
    In order for a user to have access to a particular system/subsystem configuration, that user must be given explicit permission to process within that configuration, for the type of access desired.
  • type=user Parameters
    Each TYPE=USER parameter is described next:
    • userid=
      user-id
    Defines the users for which access information is being specified (form 1), or, if used with a group specification (form 3), the ID of the users who are associated with the group-name. The user-id can end with a mask character to include all users having IDs that start with the characters specified, or it can be specified as eight mask characters, $$$$$$$$, to include all users. The following parameter specifies all users with IDs that start with AN:
    USERID=AN$
    If your site has user IDs containing a $, you can change the $ mask to another character. Edit the iprfx.iqual.CSIQOPTN library member MASKMAC and change the &CHAR=$ to another character. In the following example, the mask character is set to @:
    MASKMAC &STRIP=NO,&CHAR=@,&MAXLTH=8 
    • group=
      group-name
    Defines the group (up to eight characters) for which access information is being specified (form 2) or, if used with a user ID specification (form 3), the group that is associated with the specified user-id. Group names are specific to this macro; they are not referenced elsewhere within
    CA Endevor SCM
    . A group name might be, for example, Payroll, QA, DBA, Systems, and so forth. After a group is defined, all users who are associated with the group acquire access to the configurations defined for the group.
    • [until=
      yyddd
      ]
    Defines the (Julian) date through which the defined access is valid. This parameter is optional. If omitted, there is no expiration on the definition.
    • sysdef=( (
      sys-name,subsys-name,access1,access2
      )...)
      Specifies a system/subsystem/access-level configuration to which the user (form 1) or group (form 2) has access. The configuration is defined using four positional parameters:
    • sys-name
      The
      CA Endevor SCM
      system to which the user has access (restricted according to the
      subsys-name
      and access codes specified).
    • subsys-name
      The name of the subsystem to which the user has access within the system that is named as option 1 (and restricted according to the access codes).
    • access1
      A list of single-character codes that identify the types of access for which the user is authorized within the system and subsystem named. Do not include a separator character between multiple codes within each access specification. The
      access1
      parameter specifies all types of access except Display and Archive, which must be specified using
      access2
      . If you want to specify Display or Archive access only, include a positional comma for
      access1
      . If you do not want Display or Archive access, do not include a final positional comma.
    • access2
      A list of single-character codes that identify the types of access for which the user is authorized within the system and subsystem named. Specify Display and Archive using
      access2
      .
The following table details access codes for the
access1
and
access2
variables:
Access Code
access1
access2
Access Level
A
X
 
Add
B
 
X
Display
D
x
 
Delete
M
x
 
Move
P
x
 
Generate
R
x
 
Retrieve
S
x
 
Signout override
U
x
 
Update
V
 
x
Archive
Z
x
 
Environment administration
N
x
 
No access
The
sys-name
and
subsys-name
variables can end with a mask character (for example, DEV$), to include all systems/subsystems starting with the same characters; or you can use a single mask character to include all systems or subsystems. For example, the following statement specifies add-access for all subsystems within systems beginning with the characters GL:
SYSDEF=((GL$,$,A))
To allow access to multiple configurations, repeat the operands within the parentheses:
SYSDEF=((sys,subsys,access,access),(sys,subsys,access,access)...)
The following table describes the access levels necessary for various types of
CA Endevor SCM
processing. Access levels for moves and transfers appear in a separate table that follows this table.
Action
Access Level
Access Code
Add
Add
A
Update
Update
U
Retrieve
Retrieve
R
Generate (Stage 1 or Entry Stage)
Generate
P
Generate (Stage 2 nonentry)
Move
M
Display
Retrieve or Display
R or B
Delete (Stage 1 or Entry)
Delete
D
Delete (Stage 2 nonentry)
Move
M
Signin
Retrieve
R
Print
Retrieve or Display
R or B
Alter (stage 1 or Entry stage)
Update
U
Alter (Stage 2 nonentry)
Move
M
Archive
Archive
V
Restore to Stage 1 or Entry Stage
Add
A
Restore to Stage 2 nonentry
Move
M
Copy
None
 
List
Display
B
Signout override
Signout Override
S
All (element type Process)
Environment management
Z
Checks while building the primary Options Menu:
 
 
Include Defaults option
None
 
Include Display option
Retrieve or Display
R or B
Include Foreground option
Retrieve
R
Include Batch option
Retrieve
R
Include Environment option
Environment management
Z
Include Tutorial option
None
 
Checks while building the Foreground Options menu:
 
 
Include Option
None
--
Include Add/Update option
Add or Update
A or U
Include Retrieve option
Retrieve
R
Include Generate option
Generate
P
Include Delete option
Delete
D
Include Print option
Retrieve or Display
R or B
Include Signin option
Retrieve
R
Moves and transfers often involve combined actions and source and target considerations that require special access codes. The following table provides the access codes that are required for performing moves and transfers according to stage, source, and target parameters.
Action
Access Level
Access Code
Moves From:
 
 
Stage 1, Stage 2, and entry stage
Move
M
Moves To:
 
 
Stage 1 or Entry Stage
Add
A
Stage 2 nonentry
Move
M
Transfers From:
 
 
Stage 1 or Entry Stage, no Delete
Retrieve
R
Stage 1 or Entry Stage, with Delete
Delete
D
Stage 2 nonentry no Delete
Retrieve
R
Stage 2 nonentry with Delete
Move
M
Transfers To:
Transfers to a target destination do not permit a delete. 
 
 
Stage 1 or Entry Stage
Add
A
Stage 2 nonentry
Move
M
How to Assemble and Link-Edit the User Security Table
Use an SMP/E USERMOD to assemble and link-edit your user security table. Alternatively, edit the sample JCL BC1JTABL and use it to assemble and link-edit your table outside of SMP/E. BC1JTABL is located in the installation library
iprfx.iqual.CSIQJCL
. BC1JTABL includes a step with a default name of USERTABL for the user security table. Verify that this name and the rest of the JCL is correct before submitting this job.
This step assembles and link-edits the new table. The name of the new table is specified as SYSLMOD member name in the JCL.
The output load module for the table is placed in the LOADLIB established during installation.
For testing purposes, you can copy the User Security Table to a standard load library. When you are ready for production mode, copy the load module to an authorized LINKLIST library.
Follow these steps:
  1. Update the Defaults Table (C1DEFLTS).
    1. This step points to the new User Security Table.
  2. Set the USERTBL parameter in the TYPE=ENVRNMNT macro to
    1. This step identifies the SYSLMOD DD member name that is assigned in the JCL.
Note:
See How to Modify the Defaults Table for a brief description of this procedure.
How to Define the Resource Security Table
The Resource Security Table defines element names that are restricted tosystems or subsystems, within a particular environment. For each restricted element name, the table also specifies the types of processing for which the restriction applies (retrieve-only, add, update). One Resource Security Table exists for each environment.
Sample resource security table source is provided in member RSCTTABL of installation library iprfx.iqual.CSIQSRC.
You can define resource security directly for each resource (element name), or you can define it for groups of resources. When you specify security at the group level, each group must be associated with the specific element names included in the group.
For example, you would use the following specification to indicate that any element names starting with the characters ACCT can only be added to the ACCOUNTS subsystem of the FINANCE system:
 TYPE=RESOURCE,RNAME=ACCT$,SYSDEF=((FINANCE,ACCOUNTS,A))
This example does not limit the ACCOUNTS subsystem (FINANCE system) to element names starting with the characters ACCT. The example prevents these element names from being added to other systems or subsystems.
If your site has element names containing a $ you can change the $ mask to another character. Edit the iprfx.iqual.CSIQOPTN library member MASKMAC and change the &CHAR=$ to another character. In the following example, the mask character is set to @:
MASKMAC &STRIP=NO,&CHAR=@,&MAXLTH=8 
To illustrate a group-level specification, you would use the following definition to indicate that element names beginning with the characters AP or AR can only be added to the FINANCE or GL systems, any subsystem:
 TYPE=RESOURCE,GROUP=XYZ,SYSDEF=((FINANCE,$,A),(GL,$,A))  TYPE=RESOURCE,RNAME=AP$,GROUP=XYZ  TYPE=RESOURCE,RNAME=AR$,GROUP=XYZ
To define the Resource Security Table, enter CONSDEF macros in the following format:
 CONSDEF TYPE=START,TABLE=RESOURCE Form 1:  CONSDEF  TYPE=RESOURCE, RNAME=element-name,[UNTIL=yyddd,]            X                SYSDEF=((sys-name,subsys-name,access1,access2)...) Form 2:  CONSDEF TYPE=RESOURCE,GROUP=group-name,[UNTIL=yyddd,]                X                SYSDEF=((sys-name,subsys-name,access1,access2)...) Form 3:  CONSDEF TYPE=RESOURCE,RNAME=element-name,GROUP=group-name  CONSDEF     TYPE=END,TABLE=RESOURCE
Use any combination of these statements. They must start with the TYPE=START macro and end with the TYPE=END macro.
  • type=start,table=resource
    Defines this point as the beginning of the Resource Security Table definition.
  • type=end,table=resource
    Terminates the table definition.
  • type=resource
    Defines an element name that is restricted to a particular system and subsystem (form 1) or a group of element names that are restricted to a particular system and subsystem (form 2) or associates an element name with a group-level definition (form 3). The TYPE=RESOURCE macros can be coded in any order. Make sure, however, that each group associated with an element name (form 3) has a corresponding group definition (form 2).
    In order for a restriction to apply for an element name, that name must be associated with the types of processing (access levels) for which the restriction applies (retrieve-only, add, update).
  • type=user Parameters
    Each TYPE=RESOURCE parameter is described next:
    • rname=
      element-name
      Defines the element names for which a restriction is being specified (form 1) or, if used with a group specification (form 3), the element names associated with the group-name. The element-name can end with a single mask character to include all element names that start with the characters specified, or it can be specified with eight mask characters, ($$$$$$$$), to include all element names. The following parameter specifies all element names that start with the characters FIN:
      RNAME=FIN$
    • group=
      group-name
      Defines the group (up to eight characters) for which a restriction is being defined (form 2), or, if used with an RNAME specification (form 3), the group that is associated with the specified element-name. Group names are specific to this macro; they are not referenced elsewhere within
      CA Endevor SCM
      . A group name might be, for example, Payroll, QA, DBA, Systems, and so forth. After a group is defined, all element names that are associated with the group acquire the restrictions that are defined for the group.
    • [until=
      yyddd
      ]
      Defines the (Julian) date through which the defined restriction is valid. This parameter is optional. If omitted, there is no expiration on the definition.
    • sysdef=( (
      sys-name,subsys-name,access1,access2
      )...)
      Specifies the system/subsystem configuration to which the element name (form 1) or group (form 2) is restricted. The configuration is defined using four positional parameters:
      • sys-name
        The name of the
        CA Endevor SCM
        system to which the element name is restricted. You can use a single mask character ($) to specify all system names.
      • subsys-name
        The name of the subsystem to which the element name is restricted, within the system named. You can use a single mask character ($) to specify all subsystem names.
      • access1
        A list of single-character codes that identify the types of access under which the element name is restricted, within the system and subsystem named. Within each access specification, do not include a separator character between multiple codes. The parameter
        access1
        specifies all types of access except Display and Archive, which must be specified using
        access2
        .
      • access2
        A list of single-character codes that identify the types of access under which the element name is restricted, within the system and subsystem named.
If you want to specify Display or Archive access only, include a positional comma for
access1
. If you do not want Display or Archive access, you do not need to include a final positional comma.
For more information about the correct access codes, see How to Define the User Security Table.
The
sys-name
and
subsys-name
variables can end with a mask character (for example, DEV$) to include all systems/subsystems that start with the characters specified, or they can be specified as a single mask character to include all systems and subsystems.
To restrict element names to any of several configurations, repeat the operands within the parentheses:
 SYSDEF=((syse,subsys,access,access),(sys,subsys,access,access)...)
How to Assemble and Link-Edit the Resource Security Table
Use a SMP/E USERMOD to assemble and link-edit your resource security table. Alternatively, you can edit the sample JCL BC1JTABL to assemble and link-edit your table outside of SMP/E. BC1JTABL is located in the installation library iprfx.iqual.CSIQJCL. BC1JTABL has a step, with a default name of RSCTTABL, for the resource security table. Make sure that this name and the rest of the JCL is correct before submitting this job.
This step assembles and link-edits the new table. The name of the new table is specified as SYSLMOD member name in the JCL.
The output load module for the table is placed in the LOADLIB established during installation.
For testing purposes, you can copy the User Security Table to a standard load library. When you are ready for production mode, copy the load module to an authorized LINKLIST library.
Follow these steps:
  1. Update the Defaults Table (C1DEFLTS).
    1. This action points to the new User Security Table.
  2. Set the RSCETBL parameter in the TYPE=ENVRNMNT macro to identify the SYSLMOD DD member name that is assigned in the JCL.
How to Modify the Defaults Table
To enable native security
  1. Modify the Defaults Table to reference the security tables you have defined.
  2. Copy the Defaults Table into an authorized load library. Complete this step 
    after
    you complete security definition testing.
  3. Perform an LLA refresh.
To modify the Defaults Table
  1. Specify the following parameters in the Defaults Table.
  2. TYPE=MAIN Parameters
    • ACCSTBL
      A name (up to eight characters) of the Access Security Table in use at your site.
  3. TYPE=ENVRNMN: Parameters:
    • USERTBL
      A name (up to eight characters) of the User Security Table for this environment.
    • RSCETBL
      A name (up to eight characters) of the Resource Security Table for this environment.
Use an SMP/E USERMOD to assemble and link-edit C1DEFLTS after it has been customized. Alternatively, edit the sample JCL BC1JTABL and use it to assemble and link source module C1DEFLTS outside of SMP/E. BC1JTABL is located in the installation library iprfx.iqual.CSIQJCL. This table stores the defaults table in uprfx.uqual.CSIQAUTU as member C1DEFLTS.
For more information about updating and modifying the Defaults Table and about load libraries, see Administrating.