On 2011-12-22 11:45, hvlems at zonnet.nl wrote: My comments on booting a decserver in combination with the ncp database are limited to VMS. And fairly old versions of VMS. Of course RSX responds faster since it doesn't need/use that overhead. I would not be surprised if this have stayed the same in newer versions. I would guess it is more tied to Phase IV VMS. I would not be surprised if lancp was a result of the fallout from phase V. Yes, RSX have much less overhead than VMS, along with much less architecture overhead of PDP-11 compared to a VAX or Alpha. Can't really tell what the overhead of Itanium is, but I bet it is substantial. Running at GHz speed of course hides that pretty well... :-) When Sampsa tried to boot his DS200 its load request messages showed up on my LAN. Nothing arrived in time for the DS200 apparently. My uplink is fairly slow so that could be the cause. The extra overhead of the uplink could be an issue, but not necessarily. We're talking about a single packet or two in each direction before the boot machine is decided. But I know that on a local ethernet segment, RSX machines normally boots the DECservers, even with VAX 4000 machines on the same segment. That aside, a question Johnny. VMS and ncp will only service a load host request if the mac address of the target host is registered and thus known. Does RSX service the request provided it can locate the requested filename? Yes, and no. :-) The MOP boot request itself can hold a requested boot image file name. The request also contains the type of device. RSX will only handle boot requests from devices that it approves of. This is really silly, but the MOP boot server in RSX have a list of devices it accepts requests from. If the request pass that list, the server looks in the default directory for the file requested, and will server. If you have registered the address in the node name database, you have also give a file name in that database. If no file name is in the boot request, it will use the file name in the database. If both names exist, I'm not sure which one it will use. So, even if I have the boot image for a VXT1200, for instance, RSX will not boot it. The reason is, I think, that RSX supports both secondary and tertiary boot images, and there are some possibly odd things going on with secondary boot images (I really should check more things up here, but I think that for booting when both secondary and tertiary image is needed, the secondary image is calculated from the device type and fed, and then the tertiary image comes, which the secondary boot can handle). But almost nothing use those anyway, and for tertiary boot images, the device type is pretty much irrelevant. Oh well, another thing I'd like to fix one of these days... It was not my intention to support a dedicated area, 13 or whichever. My point was that decservers be kept in local areas. Given the way VMS, ultrix-32 and Tru64 respond that makes sense I also think that for times when people do want to set up DECservers, or whatever, in their databases, it would make more sense to place them in the same area they have the rest of the stuff. I have not checked in Tru64, but I didn't think Ultrix made such a connection. But thinking of it now, I have probably only ran lat, and never dnet on Ultrix... Johnny -----Original Message----- From: Johnny Billquist<bqt at softjar.se> Sender: owner-hecnet at Update.UU.SE Date: Thu, 22 Dec 2011 11:18:31 To:<hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet Tunnel Links defined - area 13 On 2011-12-22 10:22, hvlems at zonnet.nl wrote: As everybody here knows, Decservers don't use decnet but needed an entry in the ncp database for MOM to figure out where the software was to be found. Later on LANCP was introduced for that purpose. Actually not really true. Or maybe that is true for VMS then. It is not true for RSX. RSX boots DECservers happily without any information in the nodename database. And you can also connect to the admin serial port with MOP without having an entry in the nodename database. Since we're not exactly short of areas, let alone node addresses there's no reason why we cannot reserve an area for them. OTOH I doubt we'll boot a decserver across the bridges (perhaps Sampsa will try that). So I'll keep my DS100 in area 44, it is 44.8 (ASTAAT, At). We're not short on either, but we are definitely much closer to running out of areas than node numbers. At the moment, we are standing at 28 allocated areas, soon to be atleast 29. That is close to 50%. But I'll leave area 13 alone for now, to make you happy. :-) And for your information, MIM regularly boots DECservers over the bridge... Mine and Updates, but occasionally also others. And RSX normally starts booting a DECserver before VMS have even started thinking about the request. :-) To quote a piece of the RSX kernel: ;+ ; If we cannot process a clock interrupt within 10 seconds, we are ; no longer processing in real time, and we may as well become ; a VAX ... Call an end to this ... NOW! ;- BGCK$A BF.SAN,BE.IDC,<FATAL> ;;; System massively confused :-) Johnny -----Original Message----- From: Johnny Billquist<bqt at softjar.se> Sender: owner-hecnet at Update.UU.SE Date: Thu, 22 Dec 2011 04:11:10 To:<hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet Tunnel Links defined On 2011-12-22 04:04, Steve Davidson wrote: Two things: First I would like to continue to reserve area 13. All the documentation about DECserver management refers to it. Could you point me to some of that documentation? I've not seen any of it, and I don't really at all understand the point of even setting up information in the nodename database for DECservers, which don't even speak DECnet to begin with. (And I do have DECservers up and running, as well as manuals...) I know that, from a convenience point of view, you can use the name as a short cut for specifying the MAC address and circuit, but having an area reserved for such a simple detail seems excessive. Second SG1 is a VS4000/30 (VLC). It is small, quiet, and cheap to run - all very important features. If I remember correctly, LEGATO is the same platform for the exact purpose. The only difference between my Multnet "gateway" is that it can accommodate dynamic-DNS at the other end. Cool. I guess that platform should be enough to handle normal HECnet traffic even if we grow some more. How do you deal with dynamic IP addresses? PS One more network is in the wings. You should be getting email about it soon enough if you have not already. Nothing yet. Johnny -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Wednesday, December 21, 2011 9:58 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] Multinet Tunnel Links defined Current list as of right now: .ncp sho act are Active areas summary as of 22-DEC-11 03:53:33 Next Area State Circuit Node 1 Reachable 1.13 (MIM) 2 Reachable UNA-0 19.41 (SG1) 3 Reachable UNA-0 19.41 (SG1) 4 Reachable UNA-0 4.249 (SLAVE) 6 Reachable UNA-0 6.1 (STAR69) 8 Reachable UNA-0 19.41 (SG1) 11 Reachable UNA-0 11.2 (MAISA) 19 Reachable UNA-0 19.41 (SG1) 20 Reachable UNA-0 19.41 (SG1) 33 Reachable UNA-0 19.41 (SG1) 42 Reachable UNA-0 42.1 (CANADA) 44 Reachable UNA-0 44.21 (NIKKEL) 54 Reachable UNA-0 19.41 (SG1) 59 Reachable UNA-0 19.41 (SG1) . That is 14 areas, and I'm talking to one more guy who wants a new area, which would bring us to 15. Anyone object to me giving him area 13? It was asked to be reserved for DECserver management, but I don't really see the point of having an area for that purpose. But if you can convince me... :-) Also, SG1:: is quite a hub from the bridge point of view. Lots of connections coming through there. Nice. :-) What type of machine is it? Johnny On 2011-12-21 18:29, Steve Davidson wrote: At the moment 13 areas are up and running - this list only show 10. Hopefully sometime today we will be at 14. We're working on it! :-) -Steve -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Tuesday, December 20, 2011 5:44 PM To: hecnet at Update.UU.SE Subject: Re: [HECnet] Multinet Tunnel Links defined On 2011-12-20 22:34, Steve Davidson wrote: I have defined (or redefined) tunnels for areas 3 and 6 for both GORVAX:: and SG1::. These are effective immediately. Enjoy! Cool. Area 3 is up according to MIM. Pretty... .ncp sho act are Active areas summary as of 20-DEC-11 23:42:41 Next Area State Circuit Node 1 Reachable 1.13 (MIM) 3 Reachable UNA-0 19.41 (SG1) 4 Reachable UNA-0 4.249 (SLAVE) 6 Reachable UNA-0 19.41 (SG1) 8 Reachable UNA-0 19.41 (SG1) 11 Reachable UNA-0 11.2 (MAISA) 19 Reachable UNA-0 19.41 (SG1) 20 Reachable UNA-0 19.41 (SG1) 33 Reachable UNA-0 19.41 (SG1) 42 Reachable UNA-0 42.1 (CANADA) . Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol