Conference csc32::consolemanager

    >1. TCP/IP is being installed and is in use on some nodes.  We have 200+ 
    >nodes at this site. The user's guide says to use TSM to set up terminal
    >server characteristics to allow TCP/IP connections.
    
    >We use DECserver 200, 500, and 700's connected to all types of systems
    >(VAX, AXP, and RS/6000's).  DECnet will be phased out this summer.  What
    >terminal server characteristics need to be changed for TCP/IP?
    
    First of all the, the DS200's and DS500's are incapable of TELNET
    connections. To my knowledge, the only servers capable of TELNET are
    the DS700, DS300( using Clearwater 2.0 or above) and the DS90M's.
    
    Here are the steps necessary to get a connection:
    
    1. Decide on a TCP/IP nodename and address for the server *and* find
       out what the IP network mask is for the network that the server
       is connected to . Remember an internet is a network of networks and
       this is a routable protocol so the decserver and the PCM engine *may
       be on different networks* so don't just look at the network mask
       configged on the PCM engine and take it for granted that the masks
       are the same. You want wierd problems????.... then don't set up
       consistent network masks on nodes on the same network.
    
    Anyway, with all this knowledge we can now do the following in UCX on
    the 3100-80 PCM engine:
    
    UCX> SET HOST decserver-node-name/ADDRESS=ip-address/ALISA="alias-name"
    
    Typically you only alias so that the node can be reached via a
    case-insensiteve nodename. Example, our server is called DS300 and it's
    address is 128.1.111.1. Here iS the command I would use in UCX to make
    this server known:
    
    UCX> SET HOST DS300/ADDRESS=128.1.111.1/ALIAS="ds300"
    
    Now attach to the server via TSM or NCP, turn privs on. Continuing to
    use our DS300 example above here are the commands necessary on the
    server. Also, we will just say that our network mask is 255.255.0.0 :
    
    Local> DEFINE INTERNET ADDRESS 1281.111.1
    Local> DEFINE INTERNET MASK 255.255.0.0
    
    So now we have the server itsefl defined in UCX and the server knows
    it's network address and mask, so now we have to set up the ports.
    Again continuing our DS300 example we know that the DS300 has 16 ports.
    The DS300 has 17 listener numbers that can be used. The are 23 and 2001
    - 2016. 23 is setup as the console port on the server. We can
    actually do a TELNET DS300 from any node that knows about the
    decserver and we'll get a # prompt aking for a password just as we
    would from TSM etc. So this leaves listener numbers 2001-2016 available
    for ech of our 16 ports. Obviously, the sane thing to do is associate
    port 1 with listener 2001, port 2 with listener 2002 and so on. With
    all this in mind here are the server commands to set the ports up for
    telnet listeners:
    
    Local> DEFINE TELNET LISTENER 20xx PORT xx
    
    where xx is the listener and port number. You can omit the leading 0
    on PORT xx specifier. Repeat this command for as many ports as you
    need. The do the following once for each port you defined above:
    
    Local> DEFINE TELNET LISTENER 20xx CONNECT ENABLE
    
    This enables connections to this port. if you do perform this command
    the connection request from PCM will be rejected. 
    
    To test these ports you can do the following from the PCM engine to
    test them:
    
    $ TELNET DS300 20xx
    
    If the ports are wired to their respective service nodes you will
    actually be accessing the console on that system. There are some
    TELNET characteristics that may need to be set on the server ports such
    as character echoing and but I haven't had to change anything
    from their default settings yet. If I trip over something I'll post
    it here.
    
    The next step is to update you PCM configuration to use TELNET
    listeners instead of LAT.
    
    >4. Using TSM to logout the ports
    
    If the lines connected initially then PCM will notice that the
    connection has been lost and will try to regain the connection every
    150 seconds or 2 1/2 minutes. You will need to wait at least 2 1/2
    minutes after you logout the server ports before a connection attempt
    is made. Of course the CONNECT command shouldn't crash with an
    ACCVIO. I hope this was logged in the QAR system with the stack dump 
    included in the QAR? Now if PCM never made a connection to the server
    port because of some network problem or port config problem, then you
    will have to restart PCM to get the connection. This is the way VCS
    worked and it appears this is the way PCM works if I understand things
    correctly. PCM allows 10 seconds for this "console open" to complete
    successfully.  
    
    Regs,
      Dan

 Regarding the accvio extracting log file info, this
 smells suspiciously of log file corruption, is there
 any chance of getting the .LOG .EVENT and .TIME files
 to us so we can take a look.

 We dont beleive there is a problem with RS6000 systems
 as other people have successfully connected these systems
 and managed them.

Cheers,
Phil