🚀 go-pugleaf

In article <8703140624.AA11333@ucbvax.Berkeley.EDU> KROON@HGRRUG51.BITNET write
>Is there someone out there who is running PSI-access and who can explain
>me how to overcome the following problems?
>
>Assume node two nodes A and B linked via Ethernet. A is connected to a PSDN
>and is running PSI. B is linked to A via Decnet/Ethernet and is running
>PSI-ACCESS. A third node "FARAWAY" is connected to the same PSDN and also
>running PSI.

In order to have "standard services", eg. X.29 LOGIN and PSI_MAIL, accessible
BOTH in PSI Multi-Host node (A) AND PSI Access node (B), the node must be
identified in the PSDN call data packet. The simplest method is to use a
subaddress concatenated to the DTE address (DNIC). I've used this with a
MicroVAX (multi-host) and a DEC-20 (even that works!), but I suppose it
works the same on pure VAXen environment.

In the following instructions I "assign" the "base" DTE address (number) to
node A, and use subaddress 1 for node B. I've swapped the problems presented
because X.29 is simpler.

>Problem 2:
>
>SET HOST /X29 B, or PSIMAIL to PSI%B:SOMEONE doesn't work. Instead of
>accessing node B, node A is accessed.

For X.29 LOGIN to B, use the following NCP command in node A:

  NCP>SET MODULE X25-SERVER DESTINATION X29B -
   SUBADDRESS 1 CALL MASK FF CALL VALUE 01 NODE B PRIORITY 129

You can now test with: SET HOST/X29 nnnn1 where nnnn is the DTE address
of node A. If the call is rejected, check with NCP at node B: NCP SHOW
MODULE X29-SERVER (answer with CR to the question for destination) that
its state is ON. If not, turn it on with SET MODULE X29-SERVER STATE ON,
and retry. If it works now, use the NCP command DEFINE instead of SET in
node A to make the setup permanent. Tell outsiders that the DTE address
of node B is now nnnn1 (to be defined eg. in PSI$DTE_TABLE).
(This procedure is in PSI 3.2 Release notes, ch. 3.2.3, p. 3-2)

>Problem 1:
>
>If I send (psi)mail from B (the PSI-access node), using the destination addres
>PSI%FARAWAY::SOMEONE, the user SOMEONE at node FARAWAY receives the mail, but
>the From address in the mail header says that the mail was sent from node A
>instead of B.

That can't be fixed because node A (or in some cases the PSDN) uses the
"base" DTE address, ie. that of node A, as the caller's address when
issuing an X.25 call for outgoing PSI_MAIL. That is what a receiving
PSI_MAIL uses for sender's node identification (PSI%nnnn::). However,
received PSI_MAIL can be directed to node B with the same method as in
previous instructions with the following NCP command:

  NCP>SET MODULE X25-SERVER DESTINATION PSIMAILB -
   SUBADDRESS 1 -
   CALL MASK FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF -
   CALL VALUE FF00000056332E3020204D41494C2D3131 -
   NODE B PRIORITY 129

The call mask and value are the same as swown in PSI installation
instructions. (It's the X.25 "protocol identifier" for PSI_MAIL -
actually the first 4 bytes (FF and 3 zeros) are the protocol, and
the rest is string "V3.0 MAIL-11". I know because I programmed a
PSI_MAIL server for TOPS-20 (DEC-20).) You can now test with MAIL
to PSI%nnnn1::user. Should work, if you have installed PSI_MAIL in
node B using DEC procedures. Tell outsiders the "new" PSI_MAIL address
nnnn1 (or if they have already defined B in PSI$DTE_TABLE, then
PSI%B:: works OK). However, because PSI_MAIL from node B seems to
come from node A, receivers SHOULD NOT use REPLY in MAIL to answer
(it'll try to find B::user in A::). Tell users at node B to include
in their outgoing PSI_MAIL messages a note like:

"DO NOT USE REPLY TO THIS MESSAGE! Use SEND to PSI%nnnn1::me."

------------------------------------------------------------------------
  Kimmo Laaksonen                       uucp:   ..!mcvax!tut!santra!kla
  Helsinki University of Technology     BITNET: KLA@FINGATE
  Computing Centre                      PSI_MAIL:
  Otakaari 1                              PSI%(0)244203017::LK.LAAKSONEN
  SF-02150 Espoo
  Finland                               phone: int'l 358 0 451 2601