Testing for a LAN device with $GETDVI

[Galen Tackett]

Is there something I can easily check with $GETDVI (or other user-mode means) to determine if a given device uses the LAN driver?

Right now I'm using a brute force approach by checking if the device type is one of a long list of known LAN device types--DT$_DEUNA and cousins listed in DCDEF.H.

You can't just check the device type against a single range from a minimum to a maximum value. You'd have to check against a number of "discontiguous" ranges plus specific single values.

Perhaps there is some indicator, buried in all the other stuff available from $GETDVI or other mechanisms, that says "I'm a LAN device"?

I'm pretty familiar with $GETDVI and the LAN driver $QIO interface but perhaps I've overlooked something...

[Ian Miller.]

is that LAN seperate from network class device?

[Galen Tackett]

Ian,

Does "network class device" mean a device with DC$_SCOM for its device class? If so, I believe a number of non-LAN devices have that type too; for example maybe the old point to point DECnet devices like the DMC32. (I don't have one to check but that's what my rusty memory tells me.)

I wish it was as easy as checking for that device class...

Galen

[Wim Van den Wyngaert]

One of the bits of devchar says "I'm a network device". I think that's the base for "network device" in show dev.

Wim

[Ian Miller.]

does looking for DVI$_ACPTYPE = DVI$C_ACP_NET help?

or DEV$V_NET in DEVCHAR?

[David Jones_21]

pseudo-device drivers like BGDRIVER set the "network device" bit as well, though they seem to set the ACPTYPE as well.

Why do you need to know?

[Ian Miller.]

and if you do find a DMC32 be nice to it as its probably feeling a bit tired :-)

[Galen Tackett]

David (and all),

> Why do you need to know?

It's just a small part of my eternal quest for truth. :-)

Actually, I've written a few network utilities that try to automatically locate a LAN device to use, if the user hasn't specified one on the command line.

They do this via a routine that scans all the devices of class DC$_SCOM and ignoring those that aren't LAN devices. Currently whenever VMS introduces a new LAN device type, I have to edit this routine to add the new device. The routine is not pretty--it has a giant switch() statement--but it works.


One of these utilities listens for MOP System ID messages and builds a sorted tree of them. The user can interactively display a decoded version of the MOP SYSID frame. A related one sends a MOP Request ID message to a specified target LAN address, then decodes the response (if there is one.)

They may not be particularly useful to others but I wish I could somehow make these utilities available. My employer is understandably very sensitive to releasing even small programs--especially on machine readable media. Somebody has to sign off on security, and somebody else authorizing release of proprietary information. Neither of these somebodies is likely to ever know that I even exist.)

[Ian Miller.]

"One of these utilities listens for MOP System ID messages "

I wrote one of those once and may have even corresponded with you in a former life (I worked for Softel and you had a more tolkienesque name).

Parhaps I can dig it up.

[Volker Halle]

Galen,

wouldn't the first character of the OpenVMS device name give a clue about whether it's a LAN interface ?

Excn - CSMA/CD
Fxcn - FDDI
Txcn - TokenRing
Hxcn - ATM

Volker.

[Robert Brooks_1]

Hi,

Take a look at dvi$_net. Or, from DCL . . .

$ write sys$output f$getdvi( "ewa0", "net" )
TRUE

-- Rob

[Karl Rohwedder]

I attached a part if the T4$CONFIG DCL routine, which tries to displays a list of all network devices, perhaps you can get some ideas from it.

regards Kalle

[Galen Tackett]

Ian,

You said,

I wrote one of those once and may have even corresponded with you in a former life (I worked for Softel and you had a more tolkienesque name).


Indeed! I remember this now. Way back when I worked for Lockheed Martin I used to use "finarfin" in one of my e-mail addresses--to this day it's still my AIM screen name. The code I have now is probably a distant descendant of what I was working on at the time.

Volker,

Did you forget Xcnn and Icnn? :-)

Your idea looks pretty good. It would certainly simplify the code and would probably reduce the amount of future work to keep it up to date. After all, the device names for newly introduced LAN devices usually "piggyback" onto the first character of some older device's name. It's seldom that one pops up with a previously unused first character.

Maybe I'm trying too hard to be thorough, for a program that no one but me uses or would probably care about in the first place. But that's just the perfectionist in me showing... :-)

Robert,

As David posted earlier, BG0: and perhaps other network pseudo-device drivers set the NET bit too. (And perhaps the drivers for old synchronous devices like the DMC11, DMR11, etc...)

Karl,

Thanks for the snippet of DCL from T4$CONFIG. A couple of things popped into my head while reading it:

1) (Minor nit with the code) There are some constant declarations that could be moved outside of a loop, perhaps for an infinitesimal increase in performance. Where T4$CONFIG.COM has this:

$ Get_Network_Device:
$ Field_Number = 4
$ Ucb$M_OnLine = %X10
$ Ucb$M_Template = %X2000
$ Dev$M_Net = %X2000

Couldn't at least the Ucb$... and Dev$... assignments be moved to somewhere like the beginning of the procedure?

2) I wonder how LANCP knows what is a LAN device and what isn't? Clearly it's smart enough to know that not every device with DC$_SCOM is a LAN device. Or maybe it too has a list of all known LAN device name prefixes that has to be edited whenever a new one is added.

All,

Thanks everyone. All your replies will help me decide what to do. And more discussion is still welcome...

[Volker Halle · Accepted solution]

Galen,

yes, LANACP uses a built-in table of MEDIUM and CONTROLLER letters to try to form valid device names:

char dev_medium[] = {"CEEEEEEEEEEEEFFFFFFFFHHHHHIIIIIXXX"};
char dev_cntrlr[] = {"LBCFILORSTWXZACOQRWXZCORWZCORWZEQZ"};

So this goes from CLu0, EBu0 all the way to XZu0 (with u=A,...,Z)

Volker.

[Galen Tackett]

Volker,

The way that you say LANACP does it suits me just fine. I'll probably work that into a future release.

Disclaimer:
This is not a commitment to produce a future version. (Of course I'm the only one who uses it, so I'm only dislaiming this to myself. ;-)

[Galen Tackett]

The information provided by Volker Halle will do the trick for my application.