Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!info-vax
From: GKN%OAK.SAINET.MFENET@LLL-MFE.ARPA
Newsgroups: mod.computers.vax
Subject: Micom/DHU-11 problem
Message-ID: <8601110745.AA11283@ucbvax.berkeley.edu>
Date: Fri, 10-Jan-86 08:08:00 EST
Article-I.D.: ucbvax.8601110745.AA11283
Posted: Fri Jan 10 08:08:00 1986
Date-Received: Sun, 12-Jan-86 00:11:13 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 52
Approved: info-vax@sri-kl.arpa

Date:    Fri, 10-JAN-1986 08:09 EST
To:      Info-VAX@SRI-KL.Arpa
Message-ID: <[OAK.SAINET.MFENET].59401E00.008E8CFA.GKN>
US-Mail:   Science Applications;  P.O. Box 2501;  Oak Ridge, TN  37831
Telephone: (615) 482-9031
X-VMS-Mail-To: ARPA%"Info-VAX@SRI-KL.Arpa"

        We have a VAX 785 running VMS.  It has two DHU11's.  Terminal
        access is at 9600 baud and goes through a MICOM 600 port
        ...
               The user sees the Username: prompt, but after
        the first character of their username is echoed back, it appears
        as if everything is hung.
        ...
                Once a line exhibits the problem, it remains that way
        until a system boot.  The problem does not hit one particular
        line, it seems relatively random.

        Anybody every see this before?  Any ideas?  It's getting to be a
        pain to disable the ports at the port selector.  DEC has pretty
        much given up, although they suspect it is something the MICOM is
        doing.

I asked our resident Micom wizard about this, and this is what he had to
say:

        Sounds like an interesting/fun problem. My gutt feel is that something
is causing the Character SILO or Buffer on the DHU-11 to think it's full, or
that the Processor has gone to lunch when in actuality this hasn't occured
because character echoing still goes on.

        I have had no experience with the DHU-11, but quite a bit of exposure
to the Micom 600's. I have never known the Micom to generate data at all on it's
own. Since you're running at 9600 baud, The Micom quad modules uart is actually
communicating to the interface hardware. You say the problem moves around to
different ports, thus eliminating one particular Micom interface module. 
Might the problem manefest in more ways also? ie; dropping ctrl leads, RTS, CTS,
DTR. 

One thing we experienced here when we connected the Micom to a CS-11 emulating
DMF-32 was pins 4&5 had to be jumpered, otherwise the Vax would drop DTR in
the middle of a user session (which was less than 2 minutes typically) which
at that time killed their process because the micom would immediately force
a disconnect.

I'ld be happy do discuss things with you if you think it might help.
My Name is Mike Brough , SAIC, (619-458-2538)..


Mike can also be reached as:  Brough%LAJ.SAInet@LLL-MFE.Arpa

gkn