But with all things you have to know what is there first...
     Here are a few lines that will assemble messages and write them into a
     file by the name of the adsm message number, plus add a time stamp.
     Two things chap my behind...
     1) multiple line messages with no consistant continuation indicator
     2) 98% of ADSM messages end in '.' -bout 2% don't ARGH!!
     so here you can see what messages show up and if you don't care about
     seeing them you can re-create the files as links to /dev/null
     then depending on where you want to put the work load you can either
     check each line against something you want to be notified on OR run a
     job every hour to tail every file in the directory and look at the
     date/time...

     over time my attitude has become "if it ain't gonna crash the server
     it can wait 'till morning"  a bad tape will still be bad in the
     morning and the data will still be gone... and if it is a client
     performing a restore (vs a backup or migration to tape) that triggered
     the mount (thus the error) then they will call someone who will call
     someone who will eventually call me... so I can at least get 30 more
     minutes sleep!

     # start a console session
     /usr/lpp/adsm/bin/dsmadmc -serv=$ADSMSERV -cons -id=xxxx -pass=xxxx |&
     # initial output of console session is junk so get ready to pitch it
     LINEOUT=TRASH
     read -p LINEIN
     while [ $? -eq 0 ] ; do
       # find the start of an ADSM message
       echo $LINEIN | grep ^AN[R,S][0-9][0-9][0-9][0-9][I,W,K,E,S,D]
     1>/dev/null 2>&1
       if [ $? -eq 0 ] ; then # found first line of a message
         # write last msg
         MSGID=$( echo $LINEOUT | cut -d" " -f1 )
         echo $ADSMSERV $(date +%a_%D_%H:%M:%S) $LINEOUT >>
     $WKDIR/$ADSMSERV/$MSGID
         # save the new msg
         LINEOUT=$LINEIN
       else
         # build on the existing msg
         LINEOUT=$LINEOUT' '$LINEIN # tack on next line of msg
       fi
       read -p LINEIN
     done




______________________________ Reply Separator _________________________________
Subject: Monitoring ADSM for errors.
Author:  ADSM-L (ADSM-L AT VM.MARIST DOT EDU) at unix,mime
Date:    5/19/97 10:55 PM


Howdy All,
I am currently revisiting the way we monitor ADSM's activity.
Our environment is 20 nodes backing up to 1 server (all on an SP) overnight.
We use NetView to monitor the file dsmerror.log. This issues all sorts of
messages that don't need to be passed onto NetView.
The manual "ADSM for AIX: Advanced Topics" recommends monitoring the console
log instead of the dsmerror.log (but doesn't say why).
The console log is piped out to /dev/null. Is this the norm?
Is there a mechanism for pruning the console log or dsmerror.log?
It also says to monitor for specific messages & ignore the rest.
I think it would be better to take a sample of the most common messages &
filter out the messages you don't need to see. This way should ADSM issue any
new messages (in future versions) we won't be ignoring them.

What's the consensus, monitor the console log or dsmerror.log?
What does everyone else do?

I'd welcome any opinions/advise before I start scripting.

Role:                               Unix System Administrator
Style:                              The Thinking Man's Clown
Name:                               wayneg AT au1.ibm DOT com
Life:       "Imagination is more important than knowledge"   Albert Einstein

--MimeMultipartBoundary--
=========================================================================