DECServer 200/700 downline firmware location

[Fredrik.eriksson]

Hi all,

I have a question about DECServer 200 and 700. I need to move the firmwares for these machines to another OpenVMS machine. I've figured out that WWENG2.SYS is for my 700 and PRO801ENG.SYS is for my 200s.

But I can't seem to find where in the CLI I can change the location from where to get the firmware or how it retrieves it (which filetransfer protocol and such. Mostly so I know what to do on my new OpenVMS machine).

The "show server" just prints what software is loaded but no "firmware server".

Anyone have any ideas?
Does the DECServers broadcast that they want a firmware and the OpenVMS machine serves them the correct file or how does it work?

Best regards
Fredrik Eriksson

[Hoff · Accepted solution]

This configuration change is server-side.

Not on the MOP client.

Here is how configure and operate MOP downloads via DECnet Phase IV, LANCP and DECnet-Plus:

http://labs.hoffmanlabs.com/node/183
http://labs.hoffmanlabs.com/node/233
http://labs.hoffmanlabs.com/node/234

[Fredrik.eriksson]

Thank you Hoff, this explains it alot better then my understanding of it.

I have a quick question thou. The noknowncircuits option passed with /dll from LANCP.
Does this work?
I found that I also have an old printer downlining it's firmware from the old OpenVMS machine and this one have to be available.

If I've understood the help properly the noknowncircuits option should just give the firmware (if it's in LAN$DLL: directory) if a MOP DLL request is recieved, am I correct in assuming this when I configure my LANCP for MOP DLL?

Btw, both my OpenVMS machines are running 7.3-2 with DECnet phase V.

Which leads me to another question. We're running NCP MOP on the old machines, is there any problems of using LANCP instead on the new ones and what are the major diffrences between LANCP MOP and NCP MOP?

Best regards
Fredrik Eriksson

[Hoff]

>I have a quick question thou. The noknowncircuits option passed with /dll from LANCP. Does this work?

If it doesn't work, well, check that your ECO kits are current and then go log a bug with HP.

Given a reasonably-functioning network and a given a typically segmented network, a host simply shouldn't see (frequent) MOP downloads. Given that and given the negligible overhead of a MOP request, I've never needed to investigate this.

>If I've understood the help properly the noknowncircuits option should just give the firmware (if it's in LAN$DLL: directory) if a MOP DLL request is recieved, am I correct in assuming this when I configure my LANCP for MOP DLL?

The documentation on that option seems obfuscated. Either the MOP client is known or not. If the client is not known, then that knob controls whether the box will (or will not) then search for the requested filename. Nothing more.

If your servers can't have a process start once every minute or two and run a directory search, you've likely other performance issues and other configuration issues to look at here. One or more hardware upgrades are long overdue, or your timing requirements are sufficiently close to the margins that that the box should not be running MOP or any unnecessary activities.

Or you've got a whole pile of MOP boxes or cluster satellites begging for bootstraps, and you might want to find out why.

(A big cluster cold-start was probably the worst case here for MOP, but that wasn't centrally the load from the MOP traffic. And there are ways to stage the bootstraps, if you do have a large cluster with insufficient boot- and disk-server bandwidth for a full cold-start.)

>Which leads me to another question. We're running NCP MOP on the old machines, is there any problems of using LANCP instead on the new ones and what are the major diffrences between LANCP MOP and NCP MOP?

MOP is MOP.

MOP is not particularly connected to DECnet. (It's rather like LAT or cluster satellite bootstraps in terms of the protocol's coexistence with DECnet. There are enough shared pieces that folks think there's more of a connection and a relationship than there really is.)

My general preference is for LANCP. With LANCP, I don't need to sort out the particulars of the DECnet stack and network interfaces to get the MOP-based network devices working as LANCP is present on all V6.2 and later systems. And if I use LANCP, I don't have to deal with MOP if and when I'm swapping DECnet stacks, or when I'm swapping out DECnet.

[Fredrik.eriksson]

Thank you for that lengthy description :)

My concerns for this seems somewhat unfounded now.
I've already configured LANCP to use MOP and I found it suprisingly easy to set up node definitions.

I still haven't turned NCP MOP off on my second node since I'm guessing this won't be a problem (both machines contains the same firmware files) even if the new one answers the request.

Going try this out properly on monday morning when I have some more time to actually do a reboot test with one of my DECServers.

Best regards
Fredrik Eriksson

[Hoff]

>... still haven't turned NCP MOP off on my second node since I'm guessing this won't be a problem (both machines contains the same firmware files) even if the new one answers the request...

First "answer" wins. The other slower-responding host(s) will typically see a line open error; they'll see the LAN is busy and presume another host might be answering the MOP request.

[Fredrik.eriksson]

I've shutdown the MOP on my old server with "mc ncl disable mop" and rebooted one of my decservers and it picked up the downline load request perfectly :).

Best regards
Fredrik Eriksson