From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 10-DEC-1990 16:22:41.77
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	RE: DSSI issues

Received:  by crdgw1.ge.com (5.57/GE 1.80)
	 id AA25817; Sat, 8 Dec 90 12:44:56 EST
Received: From CHX400.SWITCH.CH by CRVAX.SRI.COM with TCP; Fri,  7 DEC 90 17:37:13 PST
Received: from chvax.UUCP by chx400.switch.ch (5.61/Ultrix2.4-C)
	id AA16253; Sat, 8 Dec 90 02:31:05 +0100
Received: by chvax.uucp (5.57/1.34)
	id AA25921; Fri, 7 Dec 90 19:16:37 +0100 (MET)
Message-Id: <9012071816.AA25921@chvax.uucp>
Received: by zhmicro.uu.ch (DECUS UUCP w/Smail);
          Fri,  7 Dec 90 16:30:34 MET
Date: Fri,  7 Dec 90 16:30:34 MET
From: chvax!Ed Klavins@crdgw1, chvax!Micrognosis@crdgw1,
        +41-1-242 1450 <chvax!zhmicro.uu.ch!eklavins@crdgw1>
To: chvax!sri.com!info-vax
Subject: RE: DSSI issues
X-Vms-Mail-To: UUCP%"chvax!sri.com!info-vax"

In article <6356.275bae3d@decus.com.au>, mcintosh@decus.com.au writes:

>> ... Since the
>> PIDRIVER/embedded DSSI adapter seems to emulate full CI-port functionality,
>> it seems as if the DSSI is used for SYSAPPS as well as the MSCP message
>> traffic in the dual-host configurations.  Can anyone confirm this?
>
>It all depends when you enable the Ethernet for SCS communications or not (as
>of VMS V5.3-1). If NISCS_LOAD_PEA0 is set to 1 then the SCS messages go across
>the Ethernet via the PEDRIVER. If NISCS_LOAD_PEA0 is 0 then the SCS messages go
>across the DSSI via the PIDRIVER. We have several DSSI systems, some set up
>with SCS going across Ethernet and some with SCS going across the DSSI.
>

On the boot nodes in our cluster, which are dual-host 3400's, both the
PEDRIVER and PIDRIVER are loaded. NISCS_LOAD_PEA0 is set to 1. Examing the
error log's on the boot nodes, there are entries such as the following:

 SCS NODE: GRETEL                                              VAX/VMS V5.3-1

 ERL$LOGMESSAGE ENTRY  KA640  CPU REV# 6.  FW REV# 5.3

 DSSI   SUB-SYSTEM, _GRETEL$PIA0:

       VIRTUAL CIRCUIT TIMEOUT

       LOCAL STATION ADDRESS, 000000000006 (HEX)
       LOCAL SYSTEM ID, 000000005002 (HEX)

       REMOTE STATION ADDRESS, 000000000007 (HEX)
       REMOTE SYSTEM ID, 000000005001 (HEX)
 
...when the other DSSI boot node goes down and...

 SCS NODE: GRETEL                                              VAX/VMS V5.3-1

 ERL$LOGMESSAGE ENTRY  KA640  CPU REV# 6.  FW REV# 5.3

 NI-SCS SUB-SYSTEM, _GRETEL$PEA0:

       PORT HAS CLOSED VIRTUAL CIRCUIT

       LOCAL STATION ADDRESS, FFFFFFFFFF00 (HEX)
       LOCAL SYSTEM ID, 000000005002 (HEX)

       REMOTE STATION ADDRESS, 0000000000C7 (HEX)
       REMOTE SYSTEM ID, 000000005072 (HEX)

when a satellite node goes down.

Whenever a satellite node goes down, an entry is
recorded from the NI-SCS subsystem PEA0. The virtual circuit with the
remote system 5072, which is the node with SCS address 20594 (DECnte id
20.114) is closed. This is as expected -- the SCS traffic for the
satellites travels over the ethernet.

When the other boot node connected to the DSSI goes down, an entry is
recorded from the DSSI subsystem, PIA0. The remote id is 5001, which is
SCS address 20481, the address of the other boot node.

Doesn't this seem to indicate that SCS traffic between the two DSSI nodes
travels over the DSSI bus, even when the ethernet is connected (and
NISCS_LOAD_PEA0 is set to 1)? 

Note that the PIA0 message is VIRTUAL CIRCUIT TIMEOUT and the PEA0 message
is PORT HAS CLOSED VIRTUAL CIRCUIT -- 

This seems confusing to me in light of what I have read here recently.

Ed.
-----------------------------------------------------------------------------
 Ed Klavins           ! UUCP: 100012.41@compuserve.com,eklavins@zhmicro.uu.ch
 Micrognosis, Zuerich ! PSI:  PSI%+22847941073::EKLAVINS