Conference help::decnet-osi_for_vms

If you're connected to and registered on the Easynet, there's nothing to it
besides running NET$CONFIGURE and answering the right questions.  I wonder how
come you can't see any DTSS servers?

Paul

    >If you're connected to and registered on the Easynet, there's nothing
    >to it besides running NET$CONFIGURE and answering the right questions.
    >I wonder how come you can't see any DTSS servers?
    
    Boy, you live a sheltered life in DEC.
    
    The reason that he can't see any time servers is that his site
    hasn't provided any on the LAN that he's connected to.  The reason that
    he can't see any of the global time servers is that he doesn't have
    DECdns configured.  The reason that he doesn't have DECdns configured
    is that there are no DECdns servers on his LAN because the site hasn't
    provided any.
    
    The reason that they don't exist and won't exist is for the same reason
    that we're getting rid of All-in-1.
    
    It is critical to shutdown the VMS systems running ai1 so that we can
    say that we've saved a million dollars.  If we can't save that million
    dollars, how can we justify spending 25 million for the replacement
    system.
    
    Likewise, we're replacing VTX applications with WaitWaitWait
    applications.  Instead of being able to use a 64kbit link to run VTX,
    we need to upgrade to multiple T1 links, we need to develop the new
    apps, and we need to absorb the costs of all the time people spend
    waiting for web pages to download.  We can justify the millions in
    spending by the ability to avoid spending a few tens of thousands on
    the evil proprietary ISO OSI protocols.
    
    			only slightly ;-)

    Back to the base note.
    
    What you suspect is correct.  All the supporting infrastructure
    has been left behind or out and out demolished.
    
    You want a local node database, but as you suspect, NETUPDATE does
    not apply.  People have done the pieces, but no one has done the
    whole thing.  Someone posted a note in the NETUPDATE conference
    indicating that there was a new version in the works, but his address
    is no longer valid.  He is either history or he's been dumped into
    Exchange and probably doesn't have a VMS system available to post any
    new notes.
    
    Since I'm guessing that there are no DECdns servers on the LAN (since
    there are no DTSS servers on the LAN), this means that you need to know
    the address of an operational DECdns server somewhere in the WAN.  Good
    luck finding that if you don't have DECdns configured.
    
    I can help you with the DTSS problem.  Using
    SYS$COMMON:[SYSMGR]DTSS$CONFIG_TEMPLATE.DAT;1 as a template, manually
    configure the following DTSS servers using lines like the following:
    
    global DECNET leder1
    global DECNET leder2
    global DECNET cvg
    global DECNET mulp
    global DECNET twick
    
    I'm assuming that you have a local name database; if you don't have a
    complete database, I think that the following will work:
    
    
    global DECNET 39.577
    global DECNET 39.983
    global DECNET 39.534
    global DECNET 39.984
    global DECNET 39.945
    
    Ok, I'll tell you how to configure DECdns....
    
    Invoke the configure process thusly:
    	@sys$manager:net$configure advanced
    Select the option to change the name, option 2.
    Respond DECdns,local to the query about directory service.
    You will then be asked about naming information; enter DEC:.BXB.ALLOUT
    to the DECdns name and LOCAL:.ALLOUT to LOCAL.  etc.
    It will then begin the process of "renaming" the system.  One step
    will involve trying to find the DECdns nameserver for the DEC
    namespace.  That will fail and it will give you a list of options
    like X.500 which is bogus and then ask you to select one.  Choose
    "none of the above".  It will then ask if you are creating a new
    namespace; answer no.  It will then ask if you want to use a WAN
    dns server and say yes or whatever.  When it asks for the NSAP or
    address, enter "29.113".  That should connect to the DECdns server at
    BXB.  If that fails and it comes back and asks you again, try 24.491.
    It will then spew out a bunch of stuff, close your eyes, looking won't
    be useful.
    
    Once that is done, exit from the configure process.  DECnet will now
    (try to) update DECdns with your system's address towers.  You can
    see if this is working by showing node information a la:
    	$ mc decnet_register sho node .bxb.bxbdn1
    	$ mc decnet_register sho node anchor   (or .lkg.anchor )
    	$ mc decnet_register sho node glutny   (or .pko.glutny )
    	$ mc decnet_register sho node allout
    
    If that seems to work, but you are willing to maintain a local
    database (using decnet_register import/export and a DECnet classic
    database) then you will probably want to "rename" the node again
    and change the order to "local,decdns".
    
    If this seems as complicated as IP, well, there is a difference.
    If you run into problems, you can send me mail and I can look into
    your system some more and determine what might be wrong.  Unlike IP
    configuration, remote network management is installed automatically
    with DECnet and doesn't require trying to figure out how to get SNMP
    working.  And I find NCL at least a order of magnitude easier to use
    than snmpwalk; make that two orders of magnitude.
    
    

Isn't the right answer to .0 "ask your network manager"?

I'd be concerned about him setting up a configuration the "network management"
people on site don't know about.

Surely you're not setting up the first node on site?


John Saunders
DECdns Engineering

Speaking from experience, local network management people at the smaller sites
probably do not care, nor do they want to know about DECnet-Plus nodes on the
network (they have other things to worry about).  When I went thru this exercise
at DVO a few years back, it was made very clear to me that "you are on your own
- just make sure that the system is correctly registered."

Depending on your site, the infrastructure may not exist to fully support
DECnet-Plus, or it may have been removed; or because of the connection you have
to the easynet, it may not be available (for example, I dial-up the EASYnet,
consequently, the work LAN I have at home, which is the length of a T-connector
with two terminators doesn't have a DNS server or DTSS server available).  Even
when I was on the DVO LAN, I quickly learned that relying on a DNS server was
sure to get me in trouble, and more than once a rogue DTSS server with the wrong
time kept life interesting.

My suggestion, use local for your nameservice and block the DTSS messages, or
simply disable/delete DTSS after DECnet has started.

--Scott

    Thank you for the suggestions.
    
    I am not sure that PKO qualifies as a "smaller site", but I am the
    first person I have found hereabouts who admits to using DECnet-Plus
    "live". Silly me believing the install guide. Whoever wrote it should
    be shot.
    
    So I have to either do a bunch of really wierd and risky looking
    "renaming" stuff, and pretend I am in BXB, or stick with "LOCAL" and
    gradually get my node name database out of date? Do I have that right?
    
    And it automatically intalls something that lets anyone on the net mess
    around on my system?
    
    And is there a good way to just tell DTSS to drop dead? I have never
    used it and never missed it in previous years, I doubt that it can
    improve my quality of life much at this point, and it sounds like even
    if I got it working, all it can cause is trouble.
    
    Is there a way to use the "regular" name servers that exist on the
    network?  (nodes  jaxom, shonsu, ...) Or does DECnet plus need some
    special kind of name server? 
    
    Is there a way to go back to "good old DECnet", which seemed to more or
    less work? Or is that also fraught with peril? Or am I supposed to be
    doing "DECnet over TCP/IP"? Does that do everything (mail, notes,...),
    or does that just get me into deeper trouble?
    

Bob,
	Here's some more help.  I have a batch job that I run weekly that
updates my LOCAL database with the latest snapshot of the Easynet database. 
Check out note 2135.0.  Pete wrote a nice little procedure that will update your
LOCAL database.  You can run it as often as you like.  I run it once a week. 
Beware, the LOG file can get quite large due to the fact that DECNET_REGISTER
counts the nodes as it processes them.

	Mulp gave you some good info on getting yourself connected to a DNS
server at another site.  If you don't want to run NET$CONFIGURE multiple times
just to fix DNS, you can configure it directly with
SYS$MANAGER:DNS$CONFIGURE.COM.  Pick option 2.  Another DNS server you could try
to connect to is MELMAC (17.164) in NIO.  

	Good luck!  If you have any further questions just ask!

	Regards,
		David Fox
		Network Systems Test Group

>Whoever wrote it should be shot.

Specific suggestions for improving the documentation are always appreciated.

>or stick with "LOCAL" and
>    gradually get my node name database out of date? Do I have that right?

Using local is no different than DECnet-Classic in the fact that the database
can get out of date.

>    And it automatically intalls something that lets anyone on the net mess
>    around on my system?

Wrong.  Just like with DECnet-Classic, DECnet-Plus has a management application
that by default lets other people *look* at various DECnet attributes on your
system.  It still requires a priv'd account for someone to be able to change
those attributes.

>    And is there a good way to just tell DTSS to drop dead?

There isn't anyway to get DTSS to not start with DECnet-Plus, however, you can
disable/delete it after DECnet-Plus has started.  A simple command procedure
executed by your system specific startup:
$ mcr ncl
NCL> disable dtss
NCL> delete dtss

Frankly, I haven't found any problems just letting DTSS run, even though I
haven't pointed it at any time servers - I block the DTSS event messages about
"too few servers"

>Or am I supposed to be
>    doing "DECnet over TCP/IP"? Does that do everything (mail, notes,...),
>    or does that just get me into deeper trouble?

You can do that if you want, but you may not need too.  I used DECnet over IP
because my connection to the easynet is over a SLIP dialup line.  The only
reason you would be required to use DECnet over IP is if your underlying
transport connection was strictly IP.

--Scott

From another note of mine that I found in here...

"There is one little gotcha that you should be aware of.  You can run Pete's    
 tool to convert the NETNODE_REMOTE.DAT to a LOCAL file.  It works fine.  The   
 gotcha is that you *MUST* reboot the system, or maybe shutdown DECnet and      
 restart, before DECnet/OSI (CDI) will recognize the new version of the         
 database. It's unfortunate but that's the way it is... at least with DECnet/OSI
 V6.3."  

I still do the reboot occasionally as I think the restriction is still in place
even with V7.1.

	David