z/OS JES2 Initialization and Tuning Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Altering destination processing through DESTDEF

z/OS JES2 Initialization and Tuning Guide
SA32-0991-00

JES2 destination processing recognizes certain destination prefixes as having a special meaning. This can cause problems if an installation is using those special prefixes as TSO/E userids: notify messages and netmail files might not reach the intended users. Installations can use options on the DESTDEF initialization statement to prevent these problems. These options alter which prefixes JES2 destination processing recognizes and which it does not.

These are the options on the DESTDEF statement that an installation uses to control which prefixes JES2 recognizes:
Ndest
Nodal routing Nnnnn and NnnnnRmmmm
Rdest
Remote routing Rmmmm and NnnnnRmmmm
RMdest
Remote routing RMmmmm
RMTdest
Remote routing RMTmmmm
Udest
Special local routing Unnnn

When any of these options are set to ‘USER’, JES2 no longer recognizes any special meaning for the corresponding destinations. This applies to JCL, JES2 control statements (JECL), commands, and dynamic allocation processing. For initialization statement processing, JES2 ignores the meaning of these prefixes for all destination identifiers that appear after the DESTDEF statement in the initialization stream unless performing a hot start. If this is a hot start, the values from when JES2 was last active apply to the entire initialization deck.

To avoid different interpretations of destinations on a hot start, the DESTDEF statement should appear early in the initialization stream and before any references to destinations.

The DEST= parameter on the DESTID(jxxxxxxx) initialization statement and the $T DESTID and $ADD DESTID operator commands are the only places where DESTDEF options never apply. This allows for the creation of destids that route output to a remote even when DESTDEF RDEST=USER.

To illustrate how the DESTDEF initialization statements can be used to enforce particular policies at an installation, consider the following two examples, in which both RDEST=User and SHOWUSER=WITHlocal.

The $T O command routes all the SYSOUT from job 4 to userid ‘R0007’. This installation can require all JCL and JES2 control statements submitting jobs to specify all userids with the single-letter prefix ‘R’, while still using ‘RM’ (RMDEST=User) and ‘RMT’ (RMTDEST=User) to specify remote workstations.

In response to the operator command:
$TOJ4,ALL,D=R0007
JES2 displays:
$HASP686 OUTPUT(IRRDPTAB)  OUTGRP=2.1.1,BURST=NO,FCB=****,
$HASP686                   FLASH=****,FORMS=STD,HOLD=(NONE),
$HASP686                   HOLDRC=,OUTDISP=HOLD,PAGES=,
$HASP686                   PRIORITY=144,PRMODE=LINE,QUEUE=A,
$HASP686                   RECORDS=(4 OF 4),ROUTECDE=LOCAL.R0007,
$HASP686                   SECLABEL=,TSOAVAIL=YES,UCS=****,
$HASP686                   USERID=++++++++,WRITER=

In this example, the route code ‘LOCAL.R0007’ indicates a userid of R0007 at the local node.

This installation can alter the meaning of ‘R0007’ by dynamically adding a destid through the following command from the operator console:
$ADD DESTID(R0007),DEST=R7
JES2 displays:
$HASP822 DESTID(R0007)    DEST=R7,STATUS=DESTID,PRIMARY=NO
Now, if an operator enters the command:
$TOJ5,ALL,D=R0007
JES2 displays:
$HASP686 OUTPUT(IRRDPTAB)  OUTGRP=2.1.1,BURST=NO,FCB=****,
$HASP686                   FLASH=****,FORMS=STD,HOLD=(NONE),
$HASP686                   HOLDRC=,OUTDISP=HOLD,PAGES=,
$HASP686                   PRIORITY=144,PRMODE=LINE,QUEUE=A,
$HASP686                   RECORDS=(4 OF 4),ROUTECDE=R0007,
$HASP686                   SECLABEL=,TSOAVAIL=YES,UCS=****,
$HASP686                   USERID=++++++++,WRITER=

In this example, the route code ‘R0007’ indicates the destid R0007 rather than a user destination.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014