INFO-VAX Mon, 07 Jul 2008 Volume 2008 : Issue 376 Contents: Integrity/Itanium/IA64 OpenVMS Installation/SPL Media in UK? Re: Integrity/Itanium/IA64 OpenVMS Installation/SPL Media in UK? Re: Integrity/Itanium/IA64 OpenVMS Installation/SPL Media in UK? Re: Question about NTP.CONF master and local-master commands Re: Question about NTP.CONF master and local-master commands Re: Show of support for Distributed NetBeans Re: Show of support for Distributed NetBeans ---------------------------------------------------------------------- Date: Sun, 6 Jul 2008 13:55:01 -0700 (PDT) From: urbancamo Subject: Integrity/Itanium/IA64 OpenVMS Installation/SPL Media in UK? Message-ID: <7327126f-080e-43d1-918c-f7a4dbb1b05a@79g2000hsk.googlegroups.com> Hi, Is there anyone in the UK able to lend me Integrity installation media for OpenVMS, preferably with the associated Software Product Library? Any help gratefully appreciated. I will cover any costs incurred. Thanks, Mark. ------------------------------ Date: Sun, 06 Jul 2008 21:11:35 GMT From: "Colin Butcher" Subject: Re: Integrity/Itanium/IA64 OpenVMS Installation/SPL Media in UK? Message-ID: Well, depending on what use you're putting the systems to (especially if you're doing contracting or consulting), I recommend DSPP membership and obtaining your media kits and license PAKs through the DSPP route. -- Cheers, Colin (http://www.xdelta.co.uk). Legacy = Stuff that works properly! ------------------------------ Date: Sun, 06 Jul 2008 17:40:54 -0500 From: David J Dachtera Subject: Re: Integrity/Itanium/IA64 OpenVMS Installation/SPL Media in UK? Message-ID: <487149F6.2BDB14E8@spam.comcast.net> Colin Butcher wrote: > > Well, depending on what use you're putting the systems to (especially if > you're doing contracting or consulting), I recommend DSPP membership and > obtaining your media kits and license PAKs through the DSPP route. > > -- > Cheers, Colin (http://www.xdelta.co.uk). > Legacy = Stuff that works properly! I'm guessing this was a hobbyist inquiry. I'd consider doing I64, also, but for the dearth of media. D.J.D. ------------------------------ Date: Sun, 6 Jul 2008 15:32:11 -0700 (PDT) From: AEF Subject: Re: Question about NTP.CONF master and local-master commands Message-ID: <4ecd42eb-1bc1-4804-b5f5-984fd8c50b60@c58g2000hsc.googlegroups.com> On Jul 3, 10:37 pm, John Santos wrote: > AEF wrote: > > Hello, > > > [Also posted to vmsnet.networks.tcp-ip.tcpware.] > > > What is the point of the local-master and master commands? Can't you > > just use the server command to point nodes to the "local-master"? > > > Suppose I have a fleet of VAX systems in London and another in NYC and > > a non-VMS NTP server in our NYC office. Can't I just have each London > > VAX point to a particular London VAX and have that particular London > > VAX point to a set of VAX systems in NYC or even our NTP server (which > > is NOT a VAX system). And then if the WAN goes down, all the London > > VAX systems would then sync off the "local-master" London VAX? > > > local-master in London (node A): > > server NYC VAX system NY1 prefer > > server NYC VAX system NY2 > > > local-master in London (node A): > > server NYC VAX (or NYC NTP source) > > > Other London VAX systems: > > server node-A prefer > > server node-B > > > NY1 and NY2: > > server non-VAX NTP-system > > > Wouldn't this work? Why would I need a local-master or master commands > > anywhere, and if so where and how? > > > Sorry if this is a stupid question, but I've been looking on the net > > and in the FM and still don't see the point. > > > BTW, I'm running TCPware 5.3-3. > > > Thanks! > > > AEF > > If I understand NTP correctly, you use "local-master" when you > want that system to use it's own internal clock as the master > clock for all the systems that use it as a time server, when it > can't talk to an external time server. (If the WAN connection > dies, use this system as the master until it comes back.) You > would use "master" for a server that doesn't have any external > access (an isolated network), so it can't synchronize with an > external timeserver, or for a server that had an internal atomic > clock or had it's system clock set by an atomic clock or WWV > receiver, or could otherwise be regarded as an authoritative > time server. > > If you are syncing with an external time service (from your > ISP or NIST or someplace), you wouldn't use either, unless > you are worried about losing WAN connectivity. > > You could set up 2 or 3 London VAXes as local servers, peering > with each other and getting served by your NYC systems. Then > if one of them is down, the rest of the London VAXes can sync > from the other two, and the 3 London servers, syncing with each > other, will converge on the NYC time more quickly, averaging > out individual clock and latency differences. > > In NYC, have 2 or 3 VAXes sync with the non-VMS server (peering > with each other), and serving the rest of the NYC VAXes (and > the London servers.) That way, if one of the VAXes is down, or > the NYC NTP server is down, the other systems still have a reasonably > accurate time source. > > In NTP terms, the different levels of servers are called strata. > > Stratum 1 would be the non-VMS NYC server (unless it is syncing > with an external server, in which case increment all the stratum > numbers appropriately.) Stratum 2 would be 3 NYC server VAXes. > Stratum 3 would be the rest of the NYC VAXes and the London > server VAXes. Stratum 4 would be the rest of the London VAXes. > > Stratum numbers are determined dynamically. If the NYC NTP > server goes away, the NYC VAX servers will automatically bump to > stratum 1, and so forth for the others. > > The 3 NYC server VAXes would all have > > server NYC-NTP-SERVER > peer NYCVAX2 > peer NYCVAX3 > > (or NYCVAX1 & NYCVAX3 for NYCVAX2, or NYCVAX1 and NYCVAX2 for > NYCVAX3) > > The 3 London server VAXes would have > > server NYCVAX1 > server NYCVAX2 > server NYCVAX3 > peer LondonVAX2 > peer LondonVAX3 > > (substituting appropriately for LondonVAX2 and 3.) > > All the other NYC VAXes would have: > > server NYCVAX1 > server NYCVAX2 > server NYCVAX3 > > and all the other London VAXes would have: > > server LondonVAX1 > server LondonVAX2 > server LondonVAX3 > > in there respective NTP.CONF files. > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 I've got it set up pretty much like you recommended, but included "peer self" commands to save a lot of editing trouble. So far it's working like a charm! Thanks again. AEF ------------------------------ Date: Sun, 06 Jul 2008 23:44:31 GMT From: John Santos Subject: Re: Question about NTP.CONF master and local-master commands Message-ID: In article <3ec340fb-9aad-4166-800b- 6eb39588368c@z66g2000hsc.googlegroups.com>, spamsink2001@yahoo.com says... > On Jul 3, 10:37 pm, John Santos wrote: > > AEF wrote: > > > Hello, > > > > > [Also posted to vmsnet.networks.tcp-ip.tcpware.] > > > > > What is the point of the local-master and master commands? Can't you > > > just use the server command to point nodes to the "local-master"? > > > > > Suppose I have a fleet of VAX systems in London and another in NYC and > > > a non-VMS NTP server in our NYC office. Can't I just have each London > > > VAX point to a particular London VAX and have that particular London > > > VAX point to a set of VAX systems in NYC or even our NTP server (which > > > is NOT a VAX system). And then if the WAN goes down, all the London > > > VAX systems would then sync off the "local-master" London VAX? > > > > > local-master in London (node A): > > > server NYC VAX system NY1 prefer > > > server NYC VAX system NY2 > > > > > local-master in London (node A): > > > server NYC VAX (or NYC NTP source) > > > > > Other London VAX systems: > > > server node-A prefer > > > server node-B > > > > > NY1 and NY2: > > > server non-VAX NTP-system > > > > > Wouldn't this work? Why would I need a local-master or master commands > > > anywhere, and if so where and how? > > > > > Sorry if this is a stupid question, but I've been looking on the net > > > and in the FM and still don't see the point. > > > > > BTW, I'm running TCPware 5.3-3. > > > > > Thanks! > > > > > AEF > > Hi John! Thanks for your speedy reply. I'm hoping to finish this by > Sunday afternoon. > > > If I understand NTP correctly, you use "local-master" when you > > want that system to use it's own internal clock as the master > > clock for all the systems that use it as a time server, when it > > can't talk to an external time server. (If the WAN connection > > dies, use this system as the master until it comes back.) You > > would use "master" for a server that doesn't have any external > > access (an isolated network), so it can't synchronize with an > > external timeserver, or for a server that had an internal atomic > > clock or had it's system clock set by an atomic clock or WWV > > receiver, or could otherwise be regarded as an authoritative > > time server. > > OK, I eventually figured this out. I want to use local-master for > three nodes in NYC and three in London. > > > If you are syncing with an external time service (from your > > ISP or NIST or someplace), you wouldn't use either, unless > > you are worried about losing WAN connectivity. > > We have an NTP server in our data center and I want to sync off of > that. But it may become unreachable due to a crash, a network problem, > etc. So I want to use local-master as described above. > > > You could set up 2 or 3 London VAXes as local servers, peering > > with each other and getting served by your NYC systems. Then > > if one of them is down, the rest of the London VAXes can sync > > from the other two, and the 3 London servers, syncing with each > > other, will converge on the NYC time more quickly, averaging > > out individual clock and latency differences. > > Can you explain the point of the peer command? I still don't get that. > I think your later questions about peers stem from this, so if I explain it adequately, I won't have to answer them :-) Peers compare their clocks and average them. This gets a more accurate time and converges on an accurate time more quickly than a single client trying to sync with a server. The farther away the server is (in hops, latency, etc., rather than in pure physical distance, though of course physical distance matters), the more inaccurate the clock will be. NTP attempts to compensate for delays and variations in the round-trip time between the clients and the servers, but on the Internet, strange things can happen (dropped packets, routes changing due to circuits going up an down or due to congestion, etc.) A bunch of peers at one site can compare their clocks and average them. They can also compare the round-trip times to the server(s) and get a better idea of how to compensate. If the link to the remote server goes down, the local servers, by peering, can keep time for the local network much more accurately than a single server could. They can compensate for inaccurate hardware clocks, missed interrupts etc. (These things are unlikely to affect all the local servers identically, so if two of them notice the third is out of whack, they'll all set their times to most closely match the 2 still in sync, and the odds are it it will be a more accurate time.) I'm not sure you actually want to use local-master on any of the local servers unless you *know* that particular server has an extremely accurate clock (like it's being set by an atomic clock or radio time signal, rather than just by counting cycles of a typical PC-grade clock chip, which is what most Alphas, Itaniums, and "recent" VAXes use. I think you are better off just declaring a bunch (3 or so) of them as peers, and letting them average their clocks. When the link to the remote master is up, all the local servers will sync off it anyway, so it doesn't matter if they are local-masters or not. It's only when they've lost contact that it matters. So peers 1) average their clocks to compensate for clock speed variations, 2) compare delays (and variations in delays) when talking to their server(s) which lets them converge on the correct time more quickly, 3) when isolated from the servers keep more accurate time for longer and 4) when one of the peers reboots, it will get back into sync much more quickly than if it was relying only on the remote server. > > > > In NYC, have 2 or 3 VAXes sync with the non-VMS server (peering > > with each other), and serving the rest of the NYC VAXes (and > > the London servers.) That way, if one of the VAXes is down, or > > the NYC NTP server is down, the other systems still have a reasonably > > accurate time source. > > But why do I need the peer commands as opposed to server commands? > > [...] If the server is down, the peers will sync with each other. If any of them had previously synced with the server (before it went down), they'll collectively keep better time until the server comes back. > > The 3 NYC server VAXes would all have > > > > server NYC-NTP-SERVER > > peer NYCVAX2 > > peer NYCVAX3 > > > > (or NYCVAX1 & NYCVAX3 for NYCVAX2, or NYCVAX1 and NYCVAX2 for > > NYCVAX3) > > > > The 3 London server VAXes would have > > > > server NYCVAX1 > > server NYCVAX2 > > server NYCVAX3 > > peer LondonVAX2 > > peer LondonVAX3 > > > > (substituting appropriately for LondonVAX2 and 3.) > > Looks fine, but I still don't see why you need peer instead of server > or why it's better. Can you please explain it? > What do you mean "instead of"? Do you want to tell system A that it's server is system B, and tell system B its server is system A? That makes no sense to me, and I think would keep the systems from ever syncing their clocks. Is your question "why have peers at all?" or is it "Why use the keyword peer instead of server for the other servers in the same LAN?" I think I explained why to have peers above. Why to treat the NYC servers as servers and the other London ones as peers, is the NYC servers are "closer" to the official NTP server (which is presumably either syncing with a more accurate clock on the Internet, or getting it's time from some other, accurate source, such as a WWV receiver). You could ADD the NTP server (which I called NYC-NTP-SERVER above) as a 4th NTP server in the London configs, but once the NYC VAX servers have synced, they would be just as good, and it's considered bad manners to bother the higher up servers excessively. (That's why you don't just put "server NYC-NTP-SERVER" as the entire ntp.conf file on *all* the VAXes. Doing it heirarchically drastically reduces the network traffic on the WAN links and the load on the higher stratum servers, while not affecting accuracy very much. > Also, in the example in the TCPware Mgmt. manual, they have peer > commands that "peer" with themselves! Example: > > ; NTP configuration on 192.168.67.3 > local-master 12 > server 192.168.67.1 > server 192.168.34.1 > server 192.168.34.2 > peer 192.168.67.3 > > What's the point of that, or is it a typo on TCPware's part? Maybe so you can use the same ntp.conf on all the nodes. I didn't know this worked, if it does, it would reduce management headaches since you would only have to maintain 2 or 3 different NTP.CONF files instead of a different one for each server. (One for all clients (or one all clients in each area), one for all local servers, and maybe a global one for higher stratum servers.) In your case, you could have 4 distinct NTP.CONF's (NYC clients, London clients, NYC servers and London servers) vs. 8 NTP.CONFs (NYC clients, London clients, and one for each of your 6 servers.) > > > All the other NYC VAXes would have: > > > > server NYCVAX1 > > server NYCVAX2 > > server NYCVAX3 > > > > and all the other London VAXes would have: > > > > server LondonVAX1 > > server LondonVAX2 > > server LondonVAX3 > > > > in there respective NTP.CONF files. > > Yes, this is what I was going to do for them. > > But... would it make sense to add "server NYC-NTP-SERVER" to all the > VAX systems in case the three local-masters in NYC go down or are > taken down, or am I being to paranoid, or is that a bad idea for some > other reason? Or should I just add "peer this city" as in the example in the TCPware manual? > > BTW, my motivation is to have all the times correct based on UTC, and > if I lose connection to the data center's NTP server, at least have > all the VAX systems synchronized to each other. > > Thanks again. NTP *always* works on UTC. For VMS systems which are usually/often based on the local time zone, the NTP client has to convert the UTC time to local time before setting the clock, and the NTP server has to convert the local clock time to UTC before supplying it to clients. It doesn't matter if your systems are all running on UTC or if some are on London time and others are on NYC (Eastern US) time, or anything else, TCPware and/or HP TCP/IP's NTP software takes care of this. I assume windows NTP clients do the same. Most (all?) Unix systems keep their system clock in UTC, so it isn't an issue for them. > > > > > -- > > John Santos > > Evans Griffiths & Hart, Inc. > > 781-861-0670 ext 539 > > AEF > -- John ------------------------------ Date: Sun, 06 Jul 2008 13:38:54 -0700 From: Marty Kuhrt Subject: Re: Show of support for Distributed NetBeans Message-ID: <_ZmdnYyE-sDCsOzVnZ2dnUVZ_hWdnZ2d@speakeasy.net> IanMiller wrote: > On Jun 17, 12:08 pm, issinoho wrote: >> Chaps, >> >> Just thought I'd show a bit of support for the Distributed NetBeans >> product. Not sure how many of you are using it or have tried it but it >> really is a terrific addition to the development options on OpenVMS. >> >> I recently finished porting a rather large commercial control system >> from VAX C to I64 and did it the old-fashioned character-cell way >> which although perfectly acceptable felt a bit archaic in this day and >> age. >> >> I installed and ran NetBeans and it handled the entire project >> flawlessly; in fact, I was editing and compiling the code base from >> within a modern Windows IDE back onto the VMS server. From a standing >> start this took all of about 3 hours and involved C, MMS and FMS. >> >> So, a slap on the back to the team involved and thanks for this. > > I think it's an interesting thing but it was in beta for so long that > NetBeans has moved on to V6. I hope they get the next version out the > door quicker. I'd also like to see more documentation on how to debug the IDE Server and associated stuff on the VMS side. They have some examples in the online docs on how to set stuff up, but only if nothing "bad" happens. I've been trying to get it to work on my development system without much luck. Using an FTP file system project I cannot seem to get the remote machine to sync. The IDE server is running and it seems to be responding to the diagnostics and compile requests. I can manually ftp from the client to the server without problem, but the ide client doesn't seem to be able to do it. If the files aren't sync'd then the compile just says "FNF". ------------------------------ Date: Mon, 7 Jul 2008 05:48:31 +0800 From: "Richard Maher" Subject: Re: Show of support for Distributed NetBeans Message-ID: Hi, I'm not trying to stir up a NetBeans vs Eclipse discussion here, but I have just read this: - http://www.openvms.org/stories.php?story=08/07/04/0015580 and was wondering if anyone had tried it or had any opinions about how the two IDEs compare and contrast on VMS. I guess one's free and the other costs, and one runs on VMS and the other is "distributed"? Personally, I'm happy with TPU and would prefer more substantial infrastructure software on VMS (such as that XHR$ library) but I am interested in what other's have tried or are looking for in an IDE on VMS. NetBeans would seem to be a better fit for GlassFish (when the IMM team come out of the closet with it) but, apparently, "Customers can increase productivity with HP OpenVMS and eCube's NXTware Eclipse," says Ann McQuaid. Can't say fairer than that eh? Of course, given the current levels of VMS application "development" going on outside of Ann-world one wonders why we need a new DE at all, let alone an Integrated one :-( Regards Richard Maher "Marty Kuhrt" wrote in message news:_ZmdnYyE-sDCsOzVnZ2dnUVZ_hWdnZ2d@speakeasy.net... > IanMiller wrote: > > On Jun 17, 12:08 pm, issinoho wrote: > >> Chaps, > >> > >> Just thought I'd show a bit of support for the Distributed NetBeans > >> product. Not sure how many of you are using it or have tried it but it > >> really is a terrific addition to the development options on OpenVMS. > >> > >> I recently finished porting a rather large commercial control system > >> from VAX C to I64 and did it the old-fashioned character-cell way > >> which although perfectly acceptable felt a bit archaic in this day and > >> age. > >> > >> I installed and ran NetBeans and it handled the entire project > >> flawlessly; in fact, I was editing and compiling the code base from > >> within a modern Windows IDE back onto the VMS server. From a standing > >> start this took all of about 3 hours and involved C, MMS and FMS. > >> > >> So, a slap on the back to the team involved and thanks for this. > > > > I think it's an interesting thing but it was in beta for so long that > > NetBeans has moved on to V6. I hope they get the next version out the > > door quicker. > > I'd also like to see more documentation on how to debug the IDE Server > and associated stuff on the VMS side. They have some examples in the > online docs on how to set stuff up, but only if nothing "bad" happens. > I've been trying to get it to work on my development system without much > luck. > > Using an FTP file system project I cannot seem to get the remote machine > to sync. The IDE server is running and it seems to be responding to the > diagnostics and compile requests. I can manually ftp from the client > to the server without problem, but the ide client doesn't seem to be > able to do it. If the files aren't sync'd then the compile just says "FNF". ------------------------------ End of INFO-VAX 2008.376 ************************