A while back, Rex Warren <[log in to unmask]> wrote:
>We have an HP 3000 series 52 running MPE V P 2 or something like
>that.  It has a lanic card but we are having trouble connecting to our
>LAN.  We get a transport warning or error whenever a 802.3 packet is
>sent over the net.  Considering we have just switched over to newer
>banyan and novell on our lan for PC's we have a lot of 802.3 packets.
 
Quite some time ago I ran across this and found that it had to do with
PCs sending semi-bogus 802.3 broadcast packets on the LAN.  (I don't
remember the details of the bogosity, but I think it was a feature of
Netware.)  When the 3000 saw one of these it displayed a "TRANSLATOR
ERROR #312" message on the console; this was particularly annoying
because the message is about half a screenful.
 
At that point in time, for V-delta-5 (I think) you had to get a patch
that would disable generation of the message.  There was some mention
of this in SupportLine, too, I think.
 
More recently, I ran into it when TWG's 3000s got moved to a different
subnet.  And as a result I found a different solution....
 
Now, under 2P and later, you don't need a patch, you just need to
disable console (and probably disk) logging of the message with NMMGR.
Note that I don't recommend doing this unless you've already
established the source of the problem, because I don't know what other
messages may be hidden behind the relevant logging subsystem and
class.
 
Run NMMGR; open config file NMCONFIG.PUB.SYS.  Select Config (f2).
Go to LOGGING (f2).  Modify subsystem name SUB0008 (f6).  Modify
class CLAS0002 (f6).
 
You will see flags for enabling console logging and disc logging.  The
console flag, or maybe both, is probably set to 'Y'.  You probably
want to set both of these to 'N'.  That should make the 3000 discard
the message instead of logging it to the console or to disc.
 
Note that you will need to get the NM log process to restart so that
it will re-read this.  I think the only supported way to do this is
a warmstart.
 
So how did I find the subsystem and class?  Well, the 3000s were moved
from an isolated subnet where they had no traffic to trigger this message.
When they first tried, it turned out that the logging class wasn't there
for the subsystem, and so I got messages about that.  I fixed that, then
started getting the real messages, then went back and disabled logging
as above.
 
(NB- Rex and I have already exchanged e-mail privately about this,
but I thought I ought to post the solution after I had a chance to
tidy it up a bit and go find his original article to make it look
like a proper follow-up.  Boy, it's nice to come home and find a
two-week expire time.)
 
-Frank McConnell, not speaking for The Wollongong Group
 <[log in to unmask]> at home, <[log in to unmask]> at work