z/OS Security Server RACF Security Administrator's Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Sample output from automatic direction

z/OS Security Server RACF Security Administrator's Guide
SA23-2289-00

Some sample output from automatic command direction follows:

  ADDUSER issued at 10:42:33 on 4/1/98 was processed at NODE1.LAURIE
  on 4/1/98 at 10:43:45
  Command was propagated by automatic direction from NODE2.LAURIE
  
   COMMAND ISSUED:  ADDUSER (ANDREW) PASSWORD()
   NAME('####################') AUTHORITY(USE) NOSPECIAL UACC(NONE)
   NOOPERATIONS NOADSP NOGRPACC NOAUDIT
  
   COMMAND OUTPUT:
   IRRR008I Command succeeded. There are no messages.
  RDEFINE issued at 12:33:41 on 4/1/98 was processed at NODE1.LAURIE
  on 4/1/98 at 12:35:02
  Command was propagated by automatic direction from NODE2.LAURIE
  
   COMMAND ISSUED:  RDEFINE RRSFDATA AUTODIRECT.**  UACC(NONE)
  
   COMMAND OUTPUT:
   ICH10102I AUTODIRECT.** ALREADY DEFINED TO CLASS RRSFDATA. 
When errors occur during automatic direction of commands, the command output appropriately reflects what happened.

If an unexpected error occurred while trying to automatically direct a command to a remote node, the output might be similar to the following:

  RDEFINE issued at 12:33:41 on 4/1/98 was *not* processed at NODEA.LAURIE
  Command was *not* propagated by automatic direction from NODEB.LAURIE
  
   COMMAND ISSUED:  RDEFINE RRSFDATA AUTODIRECT.**  UACC(NONE)
  
   ERROR INFORMATION:
   IRRR016I Command was not sent. Processing code is 502.
If an unexpected error occurs after an automatically directed command arrives at a remote node, the output might look as follows:
  RDEFINE issued at 12:33:41 on 4/1/98 was *not* processed at NODEA.LAURIE
  Command was propagated by automatic direction from NODEB.LAURIE
  
   COMMAND ISSUED:  RDEFINE RRSFDATA AUTODIRECT.**  UACC(NONE)
  
   ERROR INFORMATION:
   IRRC010I UNABLE TO ESTABLISH RACF ENVIRONMENT FOR COMMAND RDEFINE.
   IRRC012I TARGET USER ID NODEA.LAURIE DOES NOT EXIST.
All time stamps shown in the RRSFLIST data set are initially recorded as Greenwich Mean Time (GMT). These time stamps are meant to show the relative sequence in which the commands were entered and processed. When output or notify information is written into the RRSFLIST data set, these times are converted from GMT into local times. The time stamps are as accurate as possible, but they are not intended to give the exact, precise times of events. In addition, the accuracy of the time stamps depends on how accurately you have set your system clocks.
Note: RRSF assumes that either all nodes in the RRSF network have their clocks set to GMT and have appropriate local time offsets in SYS1.PARMLIB, or that all nodes have their clock set to local time in the same time zone. Any other configuration will cause errors in the timestamps shown in an RRSFLIST data set.

Some sample output from automatic direction of application updates follows.

Sample output for a successful RACDEF request:

  Application update request issued at 15:42:33 on 4/1/98
  was processed at NODE2.RACFU01
  on 4/1/98 at 15:43:45
  Request was propagated by automatic direction from NODE1.RACFU01
  
   REQUEST ISSUED: RACDEF TYPE=DEFINE, NEWNAME FROM NODE1.RACFU01
  
   REQUEST OUTPUT:
   IRRR101I Application update request completed successfully
            for class DATASET, profile name MYNEW.PROFILE.
Note: NEWNAME is for DATASET or FILE class only (RENAMES).
Sample output for a successful ICHEINTY request:
  Application update request issued at 15:51:33 on 4/11/98
  was processed at NODE2.RACFU01
  on 4/11/98 at 15:53:45
  Request was propagated by automatic direction from NODE1.RACFU01
  
   REQUEST ISSUED: ICHEINTY ALTER operation from NODE1.RACFU01
  
   REQUEST OUTPUT:
   IRRR101I Application update request completed successfully
            for class $MYCLASS, profile name MYNEW.PROFILE.
Sample output for a successful RACROUTE request:
  Application update request issued at 15:51:33 on 4/13/98
  was processed at NODE2.RACFU01
  on 4/13/98 at 15:53:45
  Request was propagated by automatic direction from NODE1.RACFU01
  
   REQUEST ISSUED: RACROUTE REQUEST=EXTRACT from NODE1.RACFU01
  
   REQUEST OUTPUT:
   IRRR101I Application update request completed successfully
            for class $MYCLASS, profile name MYNEW.PROFILE. 
If a request is unsuccessful or if an abend occurs because of the status of the RACF® database on the target, one of three messages is issued:
  • IRRR102I if the request type was an ICHEINTY or RACDEF or RACXTRT
  • IRRR103I if the request type was a RACROUTE
  • IRRR104I if an abend occurred processing a RACROUTE, ICHEINTY, RACDEF, or RACXTRT.

Password synchronization requests initiated by automatic password direction return the following output:

  Password synchronization request issued at 15:03:58 on 04/18/98 was
  processed at NODE2.TSOUSER on 04/18/98 at 15:04:00
  Request was propagated by automatic direction from NODE1.TSOUSER
  
   REQUEST ISSUED: From user TSOUSER at NODE1
  
   REQUEST OUTPUT:
   IRRC013I Password synchronized successfully for TSOUSER at NODE2 and
   TSOUSER at NODE1.
The general output format of error messages is the same.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014