Controlling VTAM LU 6.2 bind

You can control which type 6.2 logical units can establish sessions with each other. This includes the ability to use RACF® to specify the values used in password-on-bind processing. For more information, see RACF and APPC, z/OS Communications Server: SNA Programmer's LU 6.2 Guide, or z/OS MVS Planning: APPC/MVS Management.

To do this, perform the following steps:

  1. Ask your VTAM® system programmer for the following information for each VTAM LU 6.2 pair:
    • The network ID and the LU identifiers for each member of the pair.
    • Whether or not a password is required for session verification based on the VERIFY option specified on the VTAM APPL statement for the LU in SYS1.VTAMLST. (This password is referred to as the session key in your RACF definitions.)
    • Whether or not the NQNAME option is specified for the ACB. If it is specified, this indicates that network-qualified names support is enabled.
  2. For each LU 6.2 pair, create two profiles in the APPCLU class.
    On one system, enter one of the following RDEFINE commands. If network-qualified names support is not enabled, enter:
    RDEFINE APPCLU local-netid.luid1.luid2 UACC(NONE)
    If network-qualified names support is enabled, enter:
    RDEFINE APPCLU local-netid.luid1.remote-netid.luid2 UACC(NONE)
    On the other system, enter one of the following RDEFINE commands. If network-qualified names support is not enabled, enter:
    RDEFINE APPCLU local-netid.luid2.luid1 UACC(NONE)
    If network-qualified names support is enabled, enter:
    RDEFINE APPCLU local-netid.luid2.remote-netid.luid1 UACC(NONE)
    where:
    local-netid, remote-netid
    are the network IDs (NETID) of the partners. These IDs are specified on the VTAM start option NETID, which is in the ATCSTRxx member of SYS1.VTAMLST.
    luid1, luid2
    are the LU names of the partners. In each case, the first LU name specified is the local LU name, and the second LU name is the partner LU name.

    For each profile created, the first LU name specified (luid1) is the primary LU on that system.

    Rule: Do not specify an asterisk (*) or any other generic character for the first two qualifiers (netid and luid).

  3. Define the attributes of the sessions between the partners of each LU pair. You do this by defining a SESSION segment for each APPCLU profile using the SESSION option of the RDEFINE and RALTER commands. You can specify the following information in each SESSION segment:
    CONVSEC
    Specifies the level or levels of security checking performed for each conversation between the partners of the LU pair.
    INTERVAL
    Specifies the maximum number of days the session key is valid before it must be changed.
    LOCK
    Indicates that a session between the partners of the LU pair cannot be established.
    SESSKEY(session-key)
    Specifies the password used to verify sessions between the partners of this LU pair. If specified, the SESSKEY value must be the same in both APPCLU profiles for this LU pair. A session key might be required based on the VERIFY option specified on the VTAM APPL statement for this LU pair.
    Note: Session keys are 64-bit data encryption standard (DES) keys. With 64-bit DES encryption, 8 of the 64 bits are reserved for use as parity bits. This means that those 8 bits are not part of the 56-key. In hexadecimal notation, the DES parity bits are: X'0101 0101 0101 0101'. Therefore, any two 64-bit keys are equivalent if their only difference is in one or more of these parity bits. For example, the following SESSKEY values, although appearing to be quite different, are equivalent because they differ only in the last bit of each byte:
    BDF0KM4Q (X'C2C4 C6F0 D2D4 F4D8'
    CEG1LN5R (X'C3C5 C7F1 D3D5 F5D9'

    For detailed information about using the RDEFINE and RALTER commands to define options in the SESSION segment, see z/OS Security Server RACF Command Language Reference.

  4. Optionally, for maintenance purposes, give users and groups appropriate access authority:
    PERMIT profile-name CLASS(APPCLU) ID(userid or groupname)
       ACCESS(access-authority)
    where access-authority is one of the following:
    NONE
    Allows no access to the profile
    READ
    Allows users to list the profile (for example, using the RLIST and SEARCH commands)
    UPDATE
    Is the same as READ
    CONTROL
    Is the same as READ
    ALTER
    Allows users to change the profile (if the profile is discrete)
  5. When you are ready to start using the protection defined in the profiles, activate the APPCLU class on every system on which you want to use the APPCLU profiles:
    SETROPTS CLASSACT(APPCLU)
    Note: You cannot issue the SETROPTS RACLIST command for the APPCLU class. VTAM does this for you (using RACROUTE REQUEST=LIST).

    To activate your APPCLU profile changes for an active application, issue the VTAM MODIFY PROFILES command to refresh the RACF profiles in storage. For syntax and usage information about the MODIFY PROFILES command, see z/OS Communications Server: SNA Programmer's LU 6.2 Guide.

Example:

Suppose there are two large nodes, one in New York and the other in Tokyo.

Network-qualified names support is not enabled.

Figure 1. Example of two network LU partners
Example of two network LU partners
On the New York node, perform the following steps:
  1. Define a profile for the Tokyo LU partner:
    RDEFINE APPCLU MVSNET1.NEWYORK.TOKYOREM SESSION(SESSKEY(KEY1)) UACC(NONE)
  2. Activate the APPCLU class:
    SETROPTS CLASSACT(APPCLU)
On the Tokyo node, perform the following steps:
  1. Define a profile for the New York LU partner:
    RDEFINE APPCLU MVSNET2.TOKYO.NYREM SESSION(SESSKEY(KEY1)) UACC(NONE)
  2. Activate the APPCLU class:
    SETROPTS CLASSACT(APPCLU)