Conference decwet::networker

(also at URL: ftp://www.zso.dec.com/pub/networker/CSC/dmo.support.template )

----------------------------------------------------------------------


 Ask Customer for the following:
        EBU version (it has to be either 2.0.10 or 2.0.12 - DMO works ONLY
                with 2.0.10 for scheduled backups. For manual ONLY backups
                DMO works with either)
        Oracle Version (for example: 7.1.6, or 7.3.1, or 7.3.2)
        DMO version (V1.0 or V1.0A [or DMO V2])
        did they re-link EBU executables with the NetWorker libobk (y/n)

  There are 3 typical areas of customer difficulty with DMO:
    1) connectivity to NetWorker Server
    2) EBU+DMO
    3) scheduled backups
  Since #3 builds on #2, and 2 builds on #1, if a customer is calling about a
  problem in one area, get them to insure they can do the LOWER level FIRST.
  Ergo:
      #1)
        Can customer do the following, LOGGED IN AS ORACLE USER:
          cd $OBK_HOME/scripts  (or whereve the script really is)
          save -s<server> -lfull -bDefault <scriptname>
        (if the script starts being saved to the NetWorker Server, this
         indicates connectivity - this is good)
        IF NOT - the matter is between the NSR Client and NSR Server - THIS IS 
        NOT A DMO PROBLEM. Check normal NSR config things (names, IP address, 
        /etc/hosts, Client resource fields, etc).
      #2)
        (log in as user Oracle for this step)
          Can they issue:
                oracle> setenv NSR_SERVER <servername>
                oracle> setenv NSR_GROUP Default
                oracle> obackup <script> 
          successfully?? 
          NO: <<<<PROVIDE ANALYSIS MATERIAL>>>>
          YES: this indicates EBU+DMO libobk work and form connections to the
                NetWorker server
      #3)
          Are they doing scheduled backups using DMO??
          NO: Skip this step.
          YES: have they set up the NetWorker Server according to the 
               Admin Guide, Chapter 3?
               NO: Review Ch 3, and if problem persists, Call Back.
               YES: <<<<PROVIDE ANALYSIS MATERIAL>>>>

If the CSC or the customer does not know how to procur any part requested in 
 this template, that is OK!!  Please indicate in the case, and I will
 instruct. This will help our Mission Critical Customers get satisfactory
 support from you folks at the CSC in a professional manner (and help 
 NetWorker Engineering support you!).

----------------------------------------------------------------------
<<<<PROVIDE ANALYSIS MATERIAL>>>>

Provide VERBATIM output please!!

#1 - NetWorker Client-side:
        log into NetWorker Client system as user oracle.
        % script /tmp/4dmoeng.cli
        % echo "Oracle version is: "
        % echo "EBU version is: "
        % echo "Call Case is (ex: IPMT CFS.12345, or Call Number 12345-0000: "
        % printenv | egrep 'ORA|NSR|OBK'
        % which uasm
        % which save
        % which obackup
        % ls -l /usr/shlib/libobk*
        % ls -l /usr/bin/*obk*
        % ls -l /usr/bin/oback*
        % cd $OBK_HOME/scripts     (or wherever it really is)
        % pwd
        -- edit the obackup <script> IN ANOTHER WINDOW and include lines:
        --      log = "/tmp/4dmoeng.log"
        --      trace = "/tmp/4dmoeng.trc"
        % obackup <script>
        % exit         (to end script)

        % tar cvf /tmp/4dmoeng.cli.tar \
          /tmp/4dmoeng.cli /tmp/4dmoeng.log /tmp/4dmoeng.trc
        % compress /tmp/4dmoeng.cli.tar
        % uuencode /tmp/4dmoeng.cli.tar.Z /tmp/4dmoeng.cli.tar.Z > \
            /tmp/4dmoeng.cli.tar.Z.uu
        -- email /tmp/4dmoeng.cli.tar.Z.uu to the CSC, or to
           DECWET::DMO_SUPPORT for analysis. 

#2 - NetWorker Server-side (ONLY IF DOING SCHEDULED SAVES!)
        log into NetWorker Server system as root.
        % script /tmp/4dmoeng.svr
        % echo "server IP name is: (example: foo.bar.bel.com) "
        % echo "client IP name is: "
        % echo "Call Case is (ex: IPMT CFS.12345, or Call Number 12345-0000: "
        %
        % nsrwatch
        % q  (after it displays 1 time)
        %
        % nsradmin
        nsradmin> types
        nsradmin> print type: nsr 
        nsradmin> print type: nsr client
        nsradmin> print type: nsr schedule
        nsradmin> print type: nsr label
        nsradmin> print type: nsr directive
        nsradmin> print type: nsr group
        nsradmin> print type: nsr pool
        nsradmin> quit
        % exit          (to end script)

        % compress /tmp/4dmoeng.srv
        % uuencode /tmp/4dmoeng.srv.Z /tmp/4dmoeng.srv.Z > \
           tmp/4dmoeng.srv.Z.uu
        -- email /tmp/4dmoeng.srv.Z.uu to the CSC, or to
           DECWET::DMO_SUPPORT for analysis. 

Just found out that:

   Oracle OPS works with EBU V2.1

   Oracle OPS works with a patched EBU 2.0.12.4 - you *must* contact
	Oracle, and the patch *must be developed*.

   Legato claims DMO V2.0 works with EBU V2.1 (I have not been able to
  	build a test system yet, so cannot make the same claim)

My 2cents: wait for V2.1 EBU, since it will be out in May 1997 timeframe.