Sequencing the SIGNON, SWAP NODE, and SIGNOFF Commands

Edit online

When you issue SIGNON, SWAP NODE, and SIGNOFF commands, the sequence in which you issue these commands is important, as shown in the following examples.

Example 1: Terminating Two Sessions with One SIGNOFF Command

The following example shows a DGADBATC SIGNON to two different nodes and the use of the SWAP NODE command. The SIGNOFF command in this example causes IBM® Connect:Direct® to terminate both sessions, because the active session at signoff is the master session.

/* NETMAP = CD.NETMAP, BOSTON IS ACTIVE (MASTER) */
  SIGNON   USERID=(SAM) NODE=CD.BOSTON
/* SIGN ON TO JERSEY */
  SIGNON   USERID=(SAM) NODE=CD.JERSEY
/* SUBMIT COPY ON JERSEY */
  SUB  PROC=COPY1
/* SWAP TO BOSTON */
  SWAP NODE  CD.BOSTON
/* SUBMIT COPY ON BOSTON */
  SUB PROC=COPY1
/* SIGN OFF BOTH NODES (terminating master session)*/
  SIGNOFF

Example 2: Terminating a Master Session with the SIGNOFF Command

In the following example, the first SIGNOFF command terminates the CD.NEWYORK node because it is the last SIGNON command issued. The second SIGNOFF command terminates both the CD.JERSEY and CD.BOSTON nodes because the first SIGNOFF command made the master session the active session and signing off the master session signs off all other sessions.

/* NETMAP = CD.NETMAP, BOSTON IS ACTIVE (MASTER */
  SIGNON   USERID=(SAM) NODE=CD.BOSTON
/* SIGN ON TO JERSEY */
  SIGNON   USERID=(SAM) NODE=CD.JERSEY
/* SIGN ON TO NEWYORK */
  SIGNON   USERID=(SAM) NODE=CD.NEWYORK
/* BOSTON IS ACTIVE AFTER SIGNOFF TO CD.NEWYORK */
  SIGNOFF
/* SIGN OFF ALL SESSIONS (terminating master session) */
  SIGNOFF

Example 3: Terminating a Non-Master Session with the SIGNOFF Command

The following example illustrates that whenever a SIGNOFF command is issued to a non-master session, the master session automatically becomes active again regardless of the order in which the nodes are signed on.

If you try to swap to a node that is already active, the SWAP NODE command is ignored. The USERID (or any other user ID specified) must be a user record in the IBM Connect:Direct authorization file or a valid ID for the security subsystem in use, to sign on to the node.

/* NETMAP = CD.NETMAP, BOSTON IS ACTIVE (MASTER)  */
  SIGNON     USERID=(SAM) NODE=CD.BOSTON
/* SIGN ON TO JERSEY */
  SIGNON     USERID=(SAM) NODE=CD.JERSEY
/* SIGN ON TO NEWYORK */
  SIGNON     USERID=(SAM) NODE=CD.NEWYORK
/* NEWYORK ACTIVE */
  SIGNOFF
/* SIGN ON TO JERSEY */
  SWAP NODE   CD.JERSEY
/* JERSEY ACTIVE */
  SIGNOFF
/* SIGN OFF ALL SESSIONS */
  SIGNOFF