Google
 

Trailing-Edge - PDP-10 Archives - BB-H348C-RM_1982 - swskit-v21/documentation/installation-hints.mem
There are no other files named installation-hints.mem in the archive.


        +---------------+
        ! d i g i t a l !   I N T E R O F F I C E  M E M O R A N D U
        M
        +---------------+

        To:  Software Support

                                               Date: 24-Jun-82
                                               From: TSG/NCSS   
                                               Loc:  MR1-2/H22



        Subj: Debugging DECnet-20 V2.0/V2.1


        The following is a list of known problems and  peculiarities
        of  DECnet-20  V2.0 and V2.1.  As far as possible, they will
        be listed is the order in which  you  might  encounter  them
        during   an   installation.   Techniques  to  diagnose  each
        situation will also be mentioned.


    1.  The most  common  problem  encountered  at  installation  is
        broken  hardware.  At various times the following items have
        been broken;

        a.  Cables - between device and modem, or between modems

        b.  Modems - broken or switch settings wrong

        c.  DTE - broken or switches wrong

        d.  DN20 - mapping hardware, MOS memory

        If there appears to be hardware problems, be sure that Field
        Service  runs  the  diagnostics  for the DN20 and the set of
        diagnostics that  test  data  transfer  in  both  directions
        ACROSS  the  DTE.   The  normal DN20 diagnostic package only
        tests the DN20 and reports  its  findings  across  the  DL11
        link.  It does not test the DTE.


    2.  The KMC11's, DUP11's, and DMC11's must  have  the  following
        CSR  and  vector  addresses.   Be warned, some Field Service
        diagnostics run with the  devices  at  different  locations.
        After  diagnostics  are  run,  be  sure  that FS has set the
        devices to the following values.        

                Device          CSR             Vector addr

                KMC11           160540          540     ;incr by 10
                DUP11           160300          570     ;incr by 10
                DMC11           160740          670     ;incr by 10
                                                              Page 2
Subj: Debugging DECnet-20 V2.0/V2.1


        If the devices are not at these addresses, either  the  LOAD
        NODE  command  will  fail or the DN20 will load but the node
        will not come on-line.  Watch the job  running  NETCON  with
        SYSDPY  when  you  do  the LOAD NODE.  The load will hang or
        fail while reading file DTEMPT.BIN, or the nodename.SYS file
        will   load,  but  the  DCN:node-TOPOL-??   connect  to  the
        topology task in the DN20 will not be made.


    3.  The UETP directories must have a USER GROUP  100,  otherwise
        the  UETP  certification  and  verification tests will fail.
        When creating DNV2LN.LIN on  page  10-36,  be  sure  to  use
        uppercase  input.  Also, be sure there are no blank lines in
        the file.  If these precautions are not taken, the DN20 will
        crash during the UETP test.


    4.  Whenever possible for a first build, take the  defaults  for
        NETGEN.  There''l be time enough later to try to tune buffer
        sizes, etc.  Watch out for the following:
        a.  You can't configure your nodename.SYS for  more  devices
            than are physically installed on the DN20.  If you build
            a system image for 2 KDP's and there  is  only  one  KDP
            installed,  CHK11 will fail when it looks for the second
            KDP.  Check the CHK11 output with SYSERR.  If the output
            is  truncated  in  SYSERR, the following may let you see
            the CHK11 output on a TTY:.  While loading do -

               COPY DLn: TTY:         (where n is the DTE  )

        b.  All node-name and  node-numbers  in  the  network  (this
            includes  KL's,  DECnet  DN20's,  and  DN200's)  must be
            unique.

        c.  Do NOT change the Transmit Password  from  the  default.
            It must be DECNET20.  When the DN20 node inits to the KL
            after being loaded,  NETCON  expects  to  see  DECNET20.
            There  is currently no way to change the password on the
            KL so if the Transmit Password is changed, the node init
            will  fail.  Watching with SYSDPY, the nodename.SYS file
            loads,  but  the  DN20  crashes  without  every   coming
            on-line.

            If a remote system requires node verification  from  the
            -20,  the  remote  system's Receive Password for the -20
            MUST be DECNET20.

        d.  The default for hardware is 1 KDP (KMC/DUP combination).
            To  add  a  second  KDP  (DUP  added to the KMC), do the
            following -

                NETGEN> EXCLUDE KDP 0
                NETGEN> INCLUDE KDP 0
                    Number of DUP11's on KDP 0:  2
                                                              Page 3
Subj: Debugging DECnet-20 V2.0/V2.1


            If you simply do INCLUDE DUP, you will end up  with  one
            KDP  and one DUP.  You CAN build a system image for LESS
            hardware than is on the DN20.  This  is  useful  if  you
            believe  that one of the devices may be broken or at the
            wrong address  and  Field  Service  is  not  immediately
            available.   If  you  suspect  a  device  is broken, try
            building a system without it.

        e.  Don't forget to specify the  DTE     that  you  will  be
            loading across.

        f.  Do a SAVE to NETGEN to save the configuration file.   If
            there is a problem and you must contact the hot-line, we
            will need to know this information.


    5.  When the batch job BUILD-ALL completes, check  BUILD-ALL.LOG
        to  be  sure  that  no  errors  were  generated  during  the
        task-build.


    6.  Run VNP20 on a hardcopy  terminal,  under  PHOTO,  or  under
        PTYCON  with  logging.   The  memory map that it produces is
        very important for debugging purposes.


    7.  Be sure that all four NETCON servers are running  (SRV:NCU).
        If  they  are  not all there, the LOAD may fail with a "line
        communications error".  ADVISE the line running  NETCON,  C,
        RESET,  and  restart  NETCON.  This also clears all requests
        from the NCP queue.

        It is a good idea not to run NETCON under  SYSJOB  for  this
        reason.


    8.  "Unimplemented NETCON command" - The version  of  NCPTAB.REL
        for linked into OPR and NETCON must be the same.


    9.  Remove  all  loop-back  connectors  from  the  lines  before
        LOADing  the DN20.  If a loop-back connector is left on, the
        DN20 will load, you will see

                ---NODE dn20-nodename ONLINE---
                ---NODE dn20-nodename OFFLINE---

        When the DN20 comes online it sends out node  init  messages
        on  all  declared  lines.  If the loop-back connector is on,
        the node init message is reflected back to  the  DN20.   The
        DN20  sees  a  node  init  from a node with the same name as
        itself and crashes.  This will also happen if  another  node
        in the network has the same nodename.
                                                              Page 4
Subj: Debugging DECnet-20 V2.0/V2.1


        a.  Check for loop-back plugs on the cables.

        b.  NCP> DUMP NODE dn20-nodename TO file.DMP
            NCP> EX
            CONN <DN20-1>       ;MAP, STB files for this DN20
            RUN MCBDA
            MCBDA>file.DMP/STANDARD/LIST:file.STD
            MCBDA>/EXIT

            Look at file.STD and  see  if  there  are  two  or  more
            entries in the Node table for the same node name.

    10.  TEST72 is the pre-packaged procedure for local testing.  We
        have seen the following:

        Device          Type/Speed      Comments

        KMC/DUP         EIA < 19.2kb    Works, but be careful.
        Reboot 
                                        the KL, run test.  If it
        doesn't
                                        work, start at re-boot of
        KL.
        Remote DMC      V.35            TEST72 doesn't work, use -
                                        NCP>SET ST LINE DMC0 MAINT
                                            put loop-back plug on
                                        NCP>LOOP LINE DMC0
        Local DMC                       Loopback testing doesn't
        work 
                                        for DMC's with integral
        modems.

    10.  Any time you have  to  unplug  a  KDP  line  (to  insert  a
        datascope,  add a loop-back connector, connect or disconnect
        a modem) do -

                NCP> SET STATE LINE KDPxy OFF

        There is a problem with the KDP, it will hang  the  line  if
        you  unplug  it  when the state of the line is ON.  The only
        way to recover this line for a DN20 is to re-LOAD the  DN20.
        For  a  2020  system  you would have to reboot the system or
        force the KMC initialization code to by  using  MDDT.   When
        you  are  done  playing  with the line, set the state of the
        line back ON.

    11.  Loop-back does not work for a remote  56kb  DMC11  (DN21-BB
        with integral modem and coaxial cable).


    12.  Running the UETP loopback testing may  jump  all  over  the
        DN20.   Once  the  testing  is  done, reload the DN20 before
        trying to do anything usefull with the network.
                                                              Page 5
Subj: Debugging DECnet-20 V2.0/V2.1


        If the loop-back test doesn't  work  and  the  other  DECnet
        system  is  available,  try connecting directly to the other
        system.  There are potential bugs in the test package  which
        might  be  avoided.   More often than not, the DECnet linkup
        between two systems will work when the loop-back test fails.

    13.  If a remote node won't come on-line, a datascope will  show
        you if the DDCMP START and STACK messages are being sent and
        received successfully.  This is  useful  for  isolating  bad
        cables, modems, and lien drivers.

        If the DDCMP STACK and STACK succeed, but the NSP node  init
        and  verification  fail,  you can then check the node names,
        node numbers, and transmit password.

    14.  The following  are  known  problems  with  DECnet-20  V2.0.
        Patches  are  available through SIRUS.  All the patches have
        been incorporated into DECnet-20 V2.1 which has just gone to
        SDC.

        a.  NSP does not handle zero-length records.  (NSPSRV, IO) 
                20-DECNET20-003

        b.  Monitor dies with RESBAZ BUGHLT.  (NSPSRV)

        c.  AUTO-LOAD fails for DN20. (NETCON)
                20-DECNET20-001

        d.  MCB crashes with garbage in node table.  (MCB's NSP)
                20-MCB-001

        e.  Resource allocation failure when using DECnet.  NSP
                links hang in DI sent in KL and/or MCB.  (MCB's NSP)
                20-MCB-002


    15.  If the DN20 crashes unexpectedly, get a dump and run MCBDA.

                MCBDA>file.dump/ANALYZE

        This output gives an english-language reason for the  crash.
        Occasionally, this points directly at the problem.

        a.  Power Fail - doing a dump of a  running  front-end  will
            report this.

        b.  Memory management failure - it even reports the area  of
            memory.

        c.  It shows the User AC's and PC, the Kernel's AC's, APR's,
            and  PC, and shows the module where the failure occured.
            With a bit of manuevering, it is possible  to  find  the
            instruction   in  the  MCB  that  failed  based  on  the
            information contained here.
                                                              Page 6
Subj: Debugging DECnet-20 V2.0/V2.1


            Finally, some pointers to keep in  mind  while  doing  a
            DECnet  installation.   It  also  includes some cautions
            which, for one reason or another, could not be put  into
            the manual.

        1.  Be sure to read the beginning of chapter 9,  up  to  and
            including   section   9.3,   before   plowing  into  the
            installation at section 9.4.

        2.  Allow enough time for installation.  Your  first  DECnet
            installation  will  take  longer than usual, because the
            procedures will be new to you.  In  addition,  there  is
            always  the  possibility  of hardware problems which are
            uncovered at installation time.  These can take time  to
            diagnose   and  fix.   The  manual  gives  an  estimated
            installation time of two hours.  This is about right  if
            the  hardware  is  operational and you are familiar with
            the procedure.  Otherwise,  don't  be  surprised  if  it
            takes longer.

        3.  If your site has purchased the RJE option,  install  the
            task-to-task  software  first and make sure it's running
            properly before installing  the  DN200  software.   This
            limits  the number of things you have to look at in case
            something goes wrong.

        4.  If you are building DECnet for a 32K DN20, you will have
            to  build two front ends.  (See the beware file for more
            information.) To avoid confusion,  build  these  in  two
            separate areas, say, <DN20-1> and <DN20-2>.

        5.  In all cases, read the DECNET.BWR on the DECnet20 SWSKIT
            before doing an installation.