Specifying SYSOUT destination through user routing

Insulation from configuration changes can also be achieved for different nodes in a network through user routing. Installations at nodes 1, 2, and 3 can logically move a printer from Node 2 to Node 3 without causing Node 1 to make any changes.

For example, consider the following figure. An installation has eliminated printer 1 from NODE2. Work that had printed on printer 1 should be routed to printer 3 at node 3. End users and application programs on nodes 1, 2, and 3 all route SYSOUT to the printer using a destid of ‘TOM’. Figure 1 shows the DESTID values before and after the move.

Figure 1. Moving Printers without Notifying Other Nodes

BEFORE
At Node1:  DESTID(TOM) DEST=N2.TOM

At Node2:  DESTID(TOM) DEST=N2.U5
           PRT(1) START=YES,SEP=NO,UNIT=0008,R=U5

At Node3:  DESTID(TOM) DEST=N2.TOM

AFTER
At Node1:  DESTID(TOM) DEST=N2.TOM

At Node2:  DESTID(TOM) DEST=N3.TOM

At Node3:  DESTID(TOM) DEST=N3.U3
           PRT(3) START=YES,SEP=NO,UNIT=000A,R=U3

Notice in Figure 1, the DESTID(TOM) on node 1 was not changed. Node 1 defined the destination identifier ‘TOM’ as meaning: Route the SYSOUT to whatever ‘TOM’ is on node 2. Before the move, ‘TOM’ on node 2 was the special local routing ‘U5’. After the move, ‘TOM’ on node 2 was updated to route the SYSOUT to whatever ‘TOM’ is on node 3. This technique of routing a destid to user routings at other nodes allows configuration changes at one site without the need to update all other nodes simultaneously.

The use of symbolic route codes allows an installation to associate a meaningful name(s) with a remote or special local routing. Care must be used when creating a DESTID with a symbolic DEST= parameter if that parameter is also used as a DESTID subscript or node name in the same initialization stream. JES2 enforces an order-dependency of destination definitions:

Destinations defined within the same initialization stream.
JES2 will allow the use of a symbolic DEST= parameter if it is:
- Never defined as a DESTID subscript or node name in the same initialization stream. In this case, the symbolic DEST= parameter is treated as if it were a userid.
- Used as a DESTID subscript or node name in an initialization statement that occurs earlier in the initialization stream. In this case, the destination will resolve to that defined for the first initialization statement. This ‘look-up’ will continue until a non-user route code is encountered.
If a DESTID is created with a symbolic DEST= parameter, and that parameter is used as a DESTID subscript or node name later in the same initialization stream, JES2 will treat it as an error condition. Message $HASP512 will be issued to indicate an error for the first DESTID statement.
Destinations defined using the JES2 $ADD command.
JES2 will resolve destinations defined using a $ADD DESTID(jxxxxxxx), DEST=symbolic_parameter in a method similar to that described above for DESTID statements that appear in initialization streams. The following rules apply if the symbolic DEST= parameter is:
- Used as a DESTID subscript or a node name in the initialization deck, the destination will resolve to that defined by the initialization statement.
- Used as a DESTID subscript in a previous $ADD DESTID(jxxxxxxx) command, the destination will resolve to that defined by that (previous) command.
- Not already defined as a destination it will always resolve to the DEST= parameter value, regardless of whether it is defined in a subsequent $ADD command.

Table 1 shows how an installation can use symbolic route codes to allow users to route SYSOUT to one node using several different destination names.

SYSOUT can be routed to node N10 using the destination names defined in the initialization stream, ‘NYC’ and ‘BIGAPPLE’. SYSOUT can also be routed to N10 using destination name NEWYORK after the first $ADD command is issued. Because NODE10 is defined as N10 in the third $ADD command, the fourth $ADD command can use route code NODE10 to define destination BIGCITY, which again resolves to node N10.

Table 1. How JES2 resolves destinations with symbolic route codes
Initialization statements/JES2 commands	JCL destination	Resolved destination
DESTID(BIGAPPLE) DEST=N10 DESTID(NYC) DEST=BIGAPPLE N(10) NAME=RUDYJ	BIGAPPLE	N10
	NYC	N10
$ADD DESTID(NEWYORK), DEST=BIGAPPLE	NEWYORK	N10
$ADD DESTID(NYCITY), DEST=N10	NYCITY	NODE10*
$ADD DESTID(NODE10), DEST=N10 $ADD DESTID(BIGCITY), DEST=NODE10	NYCITY	NODE10*
	BIGCITY	N10
* Destination NYCITY will always resolve to NODE10, because NODE10 was not yet defined.

Table 2 illustrates the error case described in the ‘initialization statement’ section above. Symbolic DEST= parameter BIGAPPLE is used in the first initialization statement. However, DESTID BIGAPPLE is created in a subsequent initialization statement. JES2 will issue message HASP512 to indicate that DESTID NYC is in error.

Table 2. How JES2 Resolves Destinations with Symbolic Route Codes
Initialization statements/JES2 commands	JCL destination	Resolved destination
DESTID(NYC) DEST=BIGAPPLE DESTID(BIGAPPLE) DEST=N10	NYC	LOCAL
DESTID(NYC) DEST=BIGAPPLE DESTID(BIGAPPLE) DEST=N10	BIGAPPLE	N10