Generating VTAM generic resource support

To generate VTAM® generic resource support for your CICS® TORs, you must:

  1. Use the GRNAME system initialization parameter to define the generic resource name under which CICS is to register to VTAM. To comply with the CICS naming conventions, it is recommended that you pad the name to the permitted 8 characters with one of the characters #, @, or $.

    For example:

    GRNAME=CICSH###

    For details of the GRNAME system initialization parameter, see the CICS System Definition Guide. The CICS naming conventions are described in the System/390 MVS Sysplex Application Migration manual.

  2. Use an APPL statement to define the attributes of each participating TOR to VTAM. The attributes defined on each individual APPL statement should be identical. The name on each APPL statement must be unique. It identifies the TOR individually, within the generic resource group.
  3. Shut down each terminal-owning region cleanly before registering it as a member of the generic resource. "Cleanly" means that CICS must be shut down by means of a CEMT PERFORM SHUTDOWN NOSDTRAN command. A CEMT PERFORM SHUTDOWN IMMEDIATE is not sufficient; nor is a CICS failure followed by a cold start. You should specify NOSDTRAN to prevent the possibility of the shutdown assist transaction force closing VTAM or performing an immediate shutdown. (The default shutdown assist transaction, DFHCESD, is described in the CICS Operations and Utilities Guide.)

    If CICS has not been shut down cleanly before you try to register it as a member of a generic resource, VTAM may (due to the existence of persistent sessions) fail to register it, and issue a return code-feedback (RTNCD-FDB2) of X'14', X'86'. (VTAM RTNCD-FDB2s are described in the OS/390 eNetwork Communications Server: SNA Programming manual.) To correct this, you must restart CICS (with the same APPLID), and use a CEMT PERFORM SHUTDOWN NOSDTRAN command to shut it down cleanly. Alternatively, if you have written a batch program to end affinities (see topic Writing a batch program to end affinities), you might be able to use it to achieve the same effect. As part of its processing, the skeleton program described in topic Writing a batch program to end affinities opens the original VTAM ACB with the original APPLID, unbinds any persisting sessions, and closes the ACB.

Notes:
  1. If your CICSplex comprises separate terminal-owning regions and application-owning regions, you should not include TORs and AORs in the same generic resource group.
  2. You cannot use VTAM generic resources with XRF. If you specify 'YES' on the XRF system initialization parameter, any value specified for GRNAME is ignored.
  3. If you specify a valid generic resource name on GRNAME, you should specify only name1 on the APPLID system initialization parameter. (If you do specify both name1 and name2 on the APPLID parameter, CICS ignores name1 and uses name2 as the VTAM applid.)

For detailed information about generating VTAM generic resource support, see the OS/390 eNetwork Communications Server: SNA Network Implementation.

Related tasks
Planning your CICSplex to use VTAM generic resources
Defining connections in a generic resource environment
Migrating a TOR to a generic resource
Removing a TOR from a generic resource
Moving a TOR to a different generic resource
Setting up inter-sysplex communications between generic resources
Ending affinities
Using ATI with generic resources
Using the ISSUE PASS command
Dealing with special cases
Related reference
Prerequisites for VTAM generic resources
Rules checklist
[[ Contents Previous Page | Next Page Index ]]