Conference noted::sns

    
    Changing the decnet_wanted symbol default value to false should work
    indeed; however, may I get the installation logfile in order to check
    what went wrong and possibly correct it for next patch/release?
    
    Thanks,
    
    	-- Olivier.
    

    Hi, Olivier,
    
    Sorry for the delay in my answer.
    
    'decnet_wanted' was changed to 'false', but the installation was 
    NOT successful.
    It will take me some time to get the logfiles (with both symbol
    definitions) from the customer. As soon as I do, I will append those
    here.
    
    Regards,
    Galia.

    Hi, Olivier,
    
    Talked to the customer again. I was not informed well - the
    installation WAS successful, but later the sns$startup.com tried to use
    ncl, and crashed. We want to know, whether setting a remark on
    those lines refferencing DECnet will solve the problem, or are there 
    any other places where DECnet is used (though not started)?
    
    As for the installation with 'decnet_wanted' true, the problem is with
    ncl commands used later during the installation. It will take time to
    get a log from that customer (security problems), so to make a long
    story short, just  take a look in that KITINSTAL.COM -  you will 
    surely see the problem using ncl (or ncp) if DECnet not started.
    
    Thanks,
    Galia.

    Hello Galia,
    
    I missed that point about the sns$startup.com procedure indeed...
    
    Commenting out the ncl related lines should make the deal.
    You'll have to modify the sns$ivp.com as well, so that the following
    code:
    
      $ SENSE WATCHDOGS
        ADD MESSAGE/LOG "SNS IVP Test"
        DELETE MESSAGE/LOG "SNS IVP Test"
        EXIT
    
    would become:
    
      $ SENSE WATCHDOGS
        ADD MESSAGE/TRANSPORT=TCPIP/LOG "SNS IVP Test"
        DELETE MESSAGE/TRANSPORT=TCPIP/LOG "SNS IVP Test"
        EXIT
    
    The Agent itself will try to declare itself as a DECnet application
    service, and issue some error messages into its logfile that you
    may just ignore...  The error handling allows it to continue, assuming
    an alternative transport layer is available.
    
    I added, into the recentmost Agent code, a check for the _NET: device
    presence as well as for an associated ACP process existence (any
    volunteer to test it against DECnet phase V?).  I'll add that check into
    the installation, verification and startup procedures as well
    so that DECnet avoidance would happen automatically.
    
    This check could be something as:
    
      $ decnet_ready := true
      $ pid=f$getdvi("_NET:","acppid")
      $ if .not. $status
      $ then decnet_ready := false
      $ else
      $   if pid .eqs. "" then decnet_ready := false
      $ endif
    
    
    Best Regards,
    
    	-- Olivier.

    I modified the kitinstal.com for the ECO04, so that it will ask the
    user for DECnet usage, just as it already did for TCP/IP.  This will
    allow you to instal the kit on non-DECnet nodes without editing it.
    
    To be more confident in my changes into the startup and IVP procedures,
    I'd like to get the output of the following 3 commands on your
    non-DECNet node:
    
    	$ write sys$output f$getdvi( "net0", "exists" )
    	$ write sys$output f$getdvi( "net0", "mnt" )
    	$ write sys$output f$getdvi( "net0", "acppid" )
    
    Thanks,
    
    	-- Olivier.
    

    Hi,
    
    Following the instructions in previous .*, the ECO3 was successfully 
    started on a non-DECnet node.
    
    Data you've been asking for:
    
    "exists" - false
    "mnt" - %SYSTEM-W-NOSUCHDEV
    "acppid" - %SYSTEM-W-NOSUCHDEV
    
    By the way, is there anything new about PSW V2.3 (OpenVMS V7.1
    support) ?  I read, that some Polycenter products for V7.1 should be
    released this March (nowadays), but PSW is not one of them.
    Many of our customers are very surprised to find out, that they can not
    upgrade VMS because of PSW.
    Can you update on this issue, please? 
    
    Thanks,
    Galia.
    

    Jim Burton just posted the updated schedule, including PSW V2.3, into
    the POLYCENTER conference...
    
    PSW V2.3 for OpenVMS v7.1 project is merely waiting for me to become a CA
    employee and move to the U.S. before it can start.  Hence the delay ;-)
    
    I'm sorry for the inconvenience...
    
    Best Regards,
    
    	-- Olivier.