Conference forty2::mailbus

It usually means that at the transport layer, the remote system did not respond
to the CR TPDU.

    Scott,
    
    so many thanks for your quick reply.
    
    What do I have to look for, since from another system I do not have any
    problem and unfortunately I do not have any documentation with me.
    
    Ciao,
            paola

Well, I would start by making sure the address being used by both systems is the
same; the address which is failing is:

network address:.MTA84-RAPIDO.CLNS%AA00040002F8

Is this the same address that the other system is using?  if it is, then some
more information about network topology - is the failing system behind a bridge
that might be filtering this address for some reason?

Are you seeing any network errors on your ethernet controller? 

Given the address format, the destination system would appear to be another
DIGITAL system - does SET HOST work if you try to reach it?

It might also be worth trying an OSI Transport trace to verify that the CR TPDU
is in fact being sent.

    Scott,
    
    I have checked the network address and it is OK.
    MTA84-RAPIDO is an Ultrix 5900 backbone, and we have set up a trace on
    the OSI transport there and nothing has been logged (apparently the
    VMS system does not even reach the backbone, but the funny thing is
    that messages are not being sent only in outgoing but they can be
    received).
    
    I have run traces both on OSI transport and on OSAK and I enclose them
    for you to give a look and to give me some suggestions.
    
    Mnay thanks for your time and cooperation.
    
    Ciao,
          paola
    
    
Issued T-CONNECT request at 15:09:01 on 21-MAY-1997 
    
   15 00 0B 00  C  L  N  S  %  A  A  0  0  0  4  0  0  0  2  F  8 10 00 0C 00  M
    T  A  8  4  -  R  A  P  I  D  O 08 00 06 00 11 00 00 00 08 00 07 00 00 00 00
   00 08 00 FD FF 01 00 00 00 07 00 0D 00  M  R  X


CTF V1.0-00                                                       Page 1        
Trace started on 21-MAY-1997 15:58:37.55  Analyzed on 21-MAY-1997 16:05:24.81   
Trace File [MB$.MRX]CTF$TRACE.DAT;2     Output File [MB$.MRX]PAOLA.TRACE;2      
-----------+----+-----+-----+<---------------Transport-Header----------------------->++---------------------------------------------
    Time   |Evnt|Data |TC_id|Li Ty Cdt  Dst  Src  RC Nr/      Variable               ||Data                                         
hh mm ss cc|    |Size |     |           Ref  Ref  /E Yr-Tu-Nr Part                   ||                                             
-----------+----+-----+-----+<------------------------------------------------------>++---------------------------------------------
15:58:37.55|  Tx|  104|002D |3A CR 04   0000 002D             01 11 30 30 31 32 2F 31||
15:58:42.55|  Tx|  104|002D |3A CR 04   0000 002D             01 11 30 30 31 32 2F 31||
15:58:47.55|  Tx|  104|002D |3A CR 04   0000 002D             01 11 30 30 31 32 2F 31||
15:58:52.55|  Tx|  104|002D |3A CR 04   0000 002D             01 11 30 30 31 32 2F 31||
15:58:57.55|  Tx|  104|002D |3A CR 04   0000 002D             01 11 30 30 31 32 2F 31||
15:59:02.55|  Tx|  104|002D |3A CR 04   0000 002D             01 11 30 30 31 32 2F 31||
15:59:07.55|  Tx|  104|002D |3A CR 04   0000 002D             01 11 30 30 31 32 2F 31||
15:59:12.55|  Tx|  104|002D |3A CR 04   0000 002D             01 11 30 30 31 32 2F 31||
15:59:17.55|  Tx|   55|002D |09 DR      0000 002D 00          E0 01 81               ||
15:59:37.55|  Tx|   55|002D |09 DR      0000 002D 00          E0 01 81               ||
15:59:57.55|  Tx|   55|002D |09 DR      0000 002D 00          E0 01 81               ||
16:00:17.55|  Tx|   55|002D |09 DR      0000 002D 00          E0 01 81               ||
16:00:37.55|  Tx|   55|002D |09 DR      0000 002D 00          E0 01 81               ||
16:00:57.55|  Tx|   55|002D |09 DR      0000 002D 00          E0 01 81               ||
16:01:17.55|  Tx|   55|002D |09 DR      0000 002D 00          E0 01 81               ||
16:01:37.55|  Tx|   55|002D |09 DR      0000 002D 00          E0 01 81               ||
16:01:57.55|  Tx|   55|002D |09 DR      0000 002D 00          E0 01 81               ||
 
TRACE ANA CTF$TRACE.DAT;/WID=132/DATA=(A,H)/NOTRUNCATE/OUTPUT=PAOLA.TRACE
    

Things still point to an addressing problem or a network problem.  Possibly the
other system is simply ignoring the CR TPDU's but I'm not sure why it would do
that.

The OSI Transport trace shows OSI Transport trying to send a CR TPDU to the
remote system and we are not getting a response back - hence the timeout error.

Does SET HOST work to this other system?  Are you logging any errors on your
ethernet controller?  What does the network topology look like?  Is it possible
that there is a bridge between the two systems that might be doing some
filtering?

Really, it looks like X.400 and OSAK and OSI Transport are working fine on the
sending system (assuming the addressing is in fact correct).  You'll need to
look further down the stack and/or at the remote system.

--Scott

    Scott,
    
    thanks ever so much for your time and suggestions.
    I have just made aware of the fact lately the customer has changed 
    between the two sites the bridge with a router and I assume this router 
    might do some filtering the bridge did not.
    
    I will check the network better, and let you know which are the
    results.
    
    The SET HOST works properly, but awfully slow.
    
    Keep you posted.
    
    Ciao,
              paola

    As stated in the previous reply, we have checked all the filters on the
    routers, and we removed all possible filters that could have caused the
    problem (FE, F0), but unfortunately the problem still persist.
    
    So we ended up by "sniffering" the network, but without very good
    success...for the time being.
    
    The funniest thing is:
    
    NODE A (where everything is working)
    NODE B (where the problem is)
    NODE C (the ultrix backbone through where the messages should pass)
    
    1) if I send a message from node A to node B it is correctly registered
    on mrx$log.log on node A, then registered on the mta (node C), it is
    not registered as incoming on the mrx$log.log of node B, but it is
    received on the receipient account.
    
    2) if I send a message from node B to node A, it gets stuch in MRX with
    the device time-out error
    
    3) if then I do a REPLY to message 1), no log is recorded on
    mrx$log.log on node B, but it is recorded on the log of the MTA (node
    C) and is it recorded on the mrx$log.log of node A and received on the
    original sender account.
    
    The type of addressing we are using is
    
    surname@1=it@2=ptpostel@3=fiat400@4=lanc@5=its@MRX_RAPIDO
    
    MRX_RAPIDO is the mailbox 
    
    in the reply the address is built in the same way, except for the fact
    MRX_RAPIDO becomes MRX_RAPIDO@V62008
    
    In fact, if I address manually a message from node B to node A and
    instead of just specifying MRX_RAPIDO as mailbox, I add @V62008 (alias
    name for node A), the the message still is not recorded on the
    mrx$log.log on node B, but I can find it on the mta log and on
    mrx$log.log of node A.
    
    All considered, can anyone please tell me if, for some reason, the
    mailbox can be corrupted ?
    
    I will try to recreate it, and let you know the results, but if anyone
    has any idea it would be very much appreciated.
    
    Thanks and best regards,
                            paola 

    I have deleted and re-created the mailbox and the mta, plus we have
    rebooted the system but unfortunately the behaviour is always the same.
    
    Enclosed for anyone to give a look, the show sess/full where the is no
    last connection time and even the SCI is showed up only when the
    session beceoms inactive.
    
    Any idea is very very much appreciated.
    
    Ciao,
                    paola
  
            MRX  Sessions
  
  
SCI : MRX970529114333Z46                                  29-MAY-1997 11:59:05.6
MRX session id : 1546                                     MRX Ref : 1
Creation Time                : 29-MAY-1997 11:43:33.52
Last Connection Time         :
Connection Attempts          : 2
Message Router Mailbox       : MRX_RAPIDO
Window Size        (Neg/Def) : 19 / 19
Checkpoint Size    (Neg/Def) : 63 / 63   Kbytes
Number Of Retries            : 40
Retry Time                   : 15
Disconnect Time              : 1
Attribute                    : Initiator, Monologue, P1
State                        : Inactive  Suspended
Connection address           : .MTA84-RAPIDO.CLNS%AA00040002F8
Activity ID (Hex) / Count    : 000000000000  /  0
    

At the transport layer, indications are that you are still having a network
problem.  I would suggest comparing a transport trace of the SEND case (which
fails) with the REPLY case (which succeeds) - I don't remember much about MRX
and MAILBUS, but it sounds to me like SEND and REPLY may be using two different
transports and or paths.  For example, if REPLY was using DECnet for some
reason, then since you've stated that SET HOST works, I would expect REPLY to
work, and in addition, you wouldn't see an OSI Transport connection being used
between the two systems.  If SEND (which already appears to use OSI Transport)
continues to fail and you have an OSI Transport trace with the same repeated CR
TPDU's, then you *must* have something on the network which is blocking OSI
Transport between the two systems (or the destination system is for some reason
ignoring the CR TPDU's).

And while this doesn't appear to be a product deficiency (and hence not an
engineering issue), but a configuration issue (probably with the network), you
should probably begin escalating this to find some local person (country or
geography) that has additional expertise and can assist you in further problem
isolation and resolution.

--Scott

    Scott,
    
    you were perfectly right: the problem is related to a non-Digital
    router which does not allow OSI transport to pass.
    
    Thanks very much.
    
    Ciao,
         paola