Conference azur::mcc

    Some questions and comments:

1) What is the exact command that you are attempting that causes this error?

2) Is this specific to a DECserver 200 (VERY unlikely), or does it happen
   to any station?  Is the DECserver 200 registered?

3) Are there any other error messages accompanying the one listed?  There
   should be an associated system error along with the MCC one.

4) Does the TEST STATION command work?  The TEST MCC 0 ETHERNET_AM command
   only verifies that the ETHERNET_AM is installed, not that it is working.

5) Do any of the Bridge AM commands work?

One likely cause of this error is insufficient privs.  You need LOG_IO and
PHY_IO privs to use the Bridge & Station AMs.  I would expect with the
error that you're seeing that none of the STATION or BRIDGE commands would
work, since they all need to "start the ethernet device".

					Wayne

	
	Inorder asked;

1) mcc>show station 08-00-2b-09-ad-f4 all char

2) The decserver is registered, and the same error message was received with
   any station we tried.

3)  Judging from the previous notes there should be another error message
    however the customer said there were no more messages.(customers are less
    than accurate however)

4) Hadn't tried the test station command will try this.

5) The bridge commands worked after we stumbled through the no priv problem
   to which you refer.  We got the wonderful could not complete attempted 
   operation error then as well, but I found the solution in notes.

	The customer has installed EMS on a proper workstation and was 
complaining that even though he is running under the system account with
LOG_IO and PHY_IO when he starts mcc from the fileview menu he doesn't 
have the required privileges.  Got him to use a decterm and set proc/priv=all
and thats how we knew we had a priviledge problem yesterday.  

	I don't have a station upon which to verify this, but I would assume
that after the installation of EMS, the Fileview menu is setup correctly such
that if you are using the system account that the required privileges are there
to run mcc.   


Scott

Wayne 

	I asked the customer to try the test station <address> and that 
        returned successfully.  The bridge commands still work ok.

	If we do a show station (name or address) all status
						  all count
						  all char
	
	we get the strtdeverror with no supplemental error message.

	show station XXXX all ident  

	we get cannot communicate with target
	

	What does a test station command do that it would complete successfully
	as compared with a show station command that returns the above to 
	errors?

	

Scott

>	I asked the customer to try the test station <address> and that 
>       returned successfully.  The bridge commands still work ok.

Now we're getting somewhere.  TEST STATION uses a different protocol type than
SHOW STATION.

>	What does a test station command do that it would complete successfully
>	as compared with a show station command that returns the above to 
>	errors?

Because they use different protocol types, one command can fail due to some
type of protocol interaction, while the other keeps working.  This is what
I suspect is happening here.  A few more questions:

1)  How is the station registered?  As ENETV2_ONLY, IEEE802_ONLY, DEC_ENETV2,
    or DEC_IEEE802?  This will help us pin down exactly what function is
    failing.  I'll guess that it's probably either DEC_ENETV2 or DEC_IEEE802.

2)  Are you running any of the following products:  VMS Configurator, TSM,
    or DECelms?  If we didn't co-ordinate things properly, then it's possible
    for there to be a protocol interaction with these products.


					Wayne

1) The station is registered as function supported=DEC_ENETV2.  Which command
    uses what protocol type?

2) The customer is running TSM.  We had used TSM to see if we could connect to
   the decserver in question.  



Scott

Has the customer tried running without TSM?

My guess would be a conflict with the Remote Console (Ethernet AM doing REQ-ID
while TSM is using Remote Console).

	Found that the customer was running ethernim in the background and
when we turn off ethernim we can issue show commands sucessfully.  I found 
also that if TSM has a connection to a server than we also receive the same
error message.

	I would still like to know the difference in protocol usage.


Scott

The limitation in running with NMCC/VAX ETHERnim is already documented
in the BMS Release Notes in the Ethernet AM "Restrictions" section.

The limitation in running with TSM is NOT currently documented. We will
add it to the BMS Release Notes...

						Chris 

>	I would still like to know the difference in protocol usage.

The SHOW STATION command sends a REQUEST-ID message using the Remote Console
protocol, which ETHERnim also uses when LISTENing, and TSM uses for Console
Connect.  In order to successfully share this protocol, certain parameters
in the P2 buffer on the $QIO must match in values.  We've been working on
this, but obviously we're not quite there yet.  We're continuing to attempt
to resolve this so that the various products can work together, but it has
proved to be a bit more difficult that we originally anticipated.

						Wayne

	Thanks for the information.  I can't really fault the customer for not
remembering that bullet in the 145 pages of release notes for EMS V2.0.

	


Scott

    
    FYI, I think that the compatibility problem between ETHERnim and TSM no
    longer exists.  I am running the ETHERnim background listener while
    connecting to various servers via TSM without any problem.  There used
    to be a problem where TSM was losing packets to the ETHERnim listener,
    but we re-wrote some of our console carrier to fix that.
    
    In fact, TSM has no problems, to my knowledge, with any product except
    for DECelms.  Any other application which does not exclusively lock the
    MOP remote console co-exists with TSM just fine. (hint - PLEASE DO NOT
    lock the remote console exclusively!)
    
     - Linda

Hi Linda,

Did you try issuing REQUEST-IDs from ETHERnim while TSM had a connection
established to a server (but not necessarily the system getting REQID'd)?

						Chris

    Hi Chris,
    
    I enabled all the background tasks at once while TSM had a connection
    established to a server to try and make TSM drop the connection. 
    Everything worked just fine.  ETHERnim was listening for SYSIDs and
    issuing REQIDs.  Is that what you meant?
    
    Back in TSM V1.3-01, we changed the way TSM communicated with the
    servers.  We always post a read before sending a REQID.  Then when the
    SYSID comes back, TSM has a read request waiting for it so the SYSIDs no
    longer automatically went to ETHERnim.  Also, since TSM is using the MOP
    protocol is shared-limited mode, TSM only gets SYSIDs addressed to the
    host system, not multicasts.  This means that TSM doesn't get any of
    the SYSIDs that ETHERnim is listening for.
    
     - Linda