MacX25: Servers Cannot Communicate

I've installed MacX25 software on two Macintosh IIX 8/80 computers. These MacX25 servers are located in two different countries (Italy and Germany), and cannot communicate with one another.

The MacX25 servers will communicate with other X.25 hosts, but cannot call one another. A special X.25 trace tool returns the following error:

Call connect failed
CLR DTE O CALL CLEARED, REMOTE DTE ORIGINATED FOR REASON 140
RETURN CODE= 0X0281=641, STATUS CODE= 0X8000=

On the Admin Log of MacX.25 appears:
Server "Dres MI" incoming call to addr "xxx" refused
call originated from address "xxx"

I tried to use and modify different parameter a file for MacX25. I have checked every setting with a technician from SPRINT.
The Diagnostic code decimal 140 error is "Call with Incorrect Source Address", referring to the Network User ID or source address/DNIC. This means your calling gateway's address or address format is incorrect. The CUG number, if required, may also be incorrect.

Since you are attempting to log into another MacX25 server, that MacX25 server MUST be set up to receive calls! A MacX25 server by itself won't answer incoming calls.

* You'll need to be running the Apple Internet Router (AIR) AppleTalk/X.25 Wide Area Extension, or some other application on that server that makes MacX25 library calls to enable it to receive calls. If you are running the AIR X.25 Wide Area Extension, you'll need to set the port configuration to receive calls.

* You'll need to configure that receiving server's parameter file: open the parameter file, select Channel Allocation, select either two-way or incoming channels.

To imbed your local MacX25 server's X.25 address, launch ResEdit, open and edit the resource Xadd with your DNIC.

There are sometimes slight variations in addressee conventions used on private PDNs, such as you may need to precede the DNIC with an ASCII character, perhaps a 1 or 0. Since your calls on the public PDN work, but your calls on the point-to-point line do not, you'll want to inquire about any special calling/receiving conventions at some point required by that one PDN's "switch".
Published Date: Feb 19, 2012