Conference 7.286::postscript_printing

    Alfonso,
    
    	Can you connect to the printer via the lps$console using the decnet
    address instead of the decent node name? Ie,
    
    	mcr lps$console 63.29 vs. mcr lps$console lps20
    
    If you can connect then you have a naming cache problem. use the
    utility in sys$system:decnet_register and using the add/modify function
    from the menu modify the decnet data for the printers. Make sure that a
    phase 4 synonym is added. Try the console again. If that fails then the
    naming cache needs to be flushed. use the following command to flush
    the cache:
    
     NCL> FLUSH SESSION CONTROL NAMING CACHE ENTRY "*"
    
    
    Renis

	Renis,

	I have tried to establish a connection using the address instead of
	node name, but is does not work either.

	The naming cache is working fine and the synonym exists all well, as I
	can see though the CDI$TRACE.

	Than you,
	Alfonso.

    I had a problem like this and discovered that I had to move the printer
    from area 61 to area 62 to get it to work.  The network group had no
    explanation.  
    
    The boot uses information stored locally, but I expect that the daemon
    uses normal DECnet channels.  So if there is a bad backtranslation for
    the printer, it won't work.  Even an existing tower might cause a
    problem. I think you need to keep pursuing this as a DECnet/OSI issue. 
    It should work; it does at the site I mentioned.  You might try
    bringing something else up with that name to see if works; just make
    sure you stick to phase IV.  
    
    Are these new names, or were they used before?
    
    Ben

	
   >	Are these new names, or were they used before?	

	I have been working for two years with these names and the LPS being
	loaded from the AXP system. 

	When I make a connection through 'mc lps$console' from both, AXP and 
	VAX systems, at the same time, I get into the console from the AXP, 
	but from the VAX the connection does not suceed. Instead, the following
	message appears repeatedly on the console:
   		
		 (CCr) Receive failure 9 occurred before start of session

	If I stop the daemon associated with the LPS, the message is not
	shown.

	Definately this is a DECnet/OSI problem. Here you are an example
	where the hidden area node LPSBAR can't be accesed from the VMS
	system:

$  mc sys$update:decnet_migrate
DECNET_MIGRATE> show path from zqoacb to LPSBAR

Communication open failure
Node:  LPSBAR
Error: no response from application

...

DECNET_MIGRATE> show path from zqoacb to DEC:.DNA_HIDDEN.2H0204

Communication open failure
Node:  DEC:.DNA_HIDDEN.2H0204
Error: no response from application


	Alfonso.

    I couldn't get the SHOW PATH command to work on my system.  But I still
    think it might be easier to get a new name since OSI doesn't like this
    name. 
    
    Could there be some definition setup on the system that works?  Look
    for a cached name over there.  You can also use DECNET_REGISTER or use
    Sys$system:cdi_cache_dump to dump the cache to an .TMP file and search
    for the name.  Maybe the definition in the network is wrong, but
    somebody made an accommodation for it on the system that does work. 
    You might want to contact WAN support.  In the U.S. they have a DTN of
    226-5001.  Not sure if they handle other countries.  
    
    Ben

	Hello,
	
	Finally, this is a DECnet/OSI issue, related with a filter for hidden
	area nodes from V6.3-5.

	See note DECNET_OSI-FOR_VMS 3957.

	Thank you,
	Alfonso.