How to identify if system is a server or workstation

[Hoff · Accepted solution]

That's an easy one. HP tells us they don't *have* workstations for OpenVMS. Workstations don't exist and haven't existed in the available product line for some years.

Itanium workstations were cancelled around (before?) OpenVMS was available on Itanium (and much fanfare and FID ensued), and the Alpha workstations got cancelled a decade or more ago. (IIRC, it was DEC that cancelled the Alpha workstation products.)

Ok; yes; that's a somewhat facetious (but factual) response.

Now what's your real question?

[Wim Van den Wyngaert]

We once had a 8400 that said "microvax" as hw_name. I think a jumper was wrong somewhere.

Wim

[Hoff]

FID in my reply was intended to the FUD.

What I haven't seen mentioned in this thread: it's entirely possible to have very nice DECwindows graphics from a box with NO graphics controller. None.

I can aim the X11 displays back at the local Mac OS X box, and do graphics work quite nicely.

So I can (and do) run DECwindows applications on one or more headless and graphics-less servers in parallel, aiming the graphics displays back an the local X11 server.

[Joseph Huber_1]

But I would not call the VMS system a workstation if headless:
the workstation is the MAC which acts as x11 display server.

I think the OP should explain what he wants to achieve by programmatically (DCL) determine which kind of system is in use:
conditionally (not )starting certain services ?
limiting number of interactive logins ?

[Peter Zeiszler]

Vineet - What are you really trying to find out? You can get the model number from the system. write sys$output f$getsyi("hw_name")

Whether its used as a "workstation" or "server" is dependent on how you use it. We have "workstations" that only provide quorum votes and we have "workstations" that provided disk services and x-windowing for users (was our CDE servers).

What are you using this data for?

[Willem Grooters]

The distcintion is artifical, and based on historical use.
"Server" was the big iron, humming in a conditioned environment, and you would do your work on these machines using connected dumb terminals.
When networks became more common, and workload could be distributed to smaller machines more and more intelligence was built in these terminals - growing to "Workstations" that would rely on the server for software, and, well, services. Quite often, these machines could do local processing in stead relying on teh remote system (causing huge load on the network). Think of graphical applications: Better do the presentation locally, but have the data be stored on, and prepared on the server.

Today, these "workstations" have at least the same processor power as the early servers, if not exceeding it. So they can be used as a server without a problem (in most cases). Most can, and do both.

Remains a FUNCTIONAL distinction, but that has nothing to with the hardware of OS.

[Vineet Deshpande]

Hi All,

Sorry for my absence from this thread in the last few days.

Basically I am working for a product which finds out information about a remote system. This includes data about memory, processor, storage devices etc.

I am also supposed to show if the system is a "server" or a "workstation". There is a different icon for both in the GUI.

Hence I wanted to know if:-
1)OpenVMS does make that distinction? i.e. can OpenVMS be present on a server as well as a workstation?

2) Is there any command which can give me this information?

If as Hoff says there are no "workstations" it'll make my job easier but I need to be sure about that.

Thanks,

Vineet

[Robert Gezelter]

Vineet,

There is no reliable distinction (a la Windows) between a server and a workstation. OpenVMS is OpenVMS.

The same hardware platform is often used as a server, a workstation, or both. If it has a graphics head, it is often referred to as a workstation, but that may be merely a matter of packaging, the machine in question may be the corporate DNS, email, www, or file server.

That said, for the purposes of iconography, perhaps a check for the presence of a graphics adapter would be appropriate (as noted earlier, X-Windows is present on quite a few server systems for the console and for remote access).

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

> There is no reliable distinction [...]

Well, if you go back to old VAX hardware,
there were different license classes for
VAX/VMS on a MicroVAX (full-function), a
VAXserver (no interactive users), and a
VAXstation (graphics). A VAXstation 3100
with no keyboard plugged in was seen as a
VAXserver 3100, for example, and might fail
to work as expected because its VMS license
was then no good. Pull the graphics card(s)
from a VAXstation 3200, and it becomes a
MicroVAX 3600. (It's a miracle!)

However, the original question is pretty
close to completely meaningless. Around
here:

alp $ write sys$output f$getsyi( "hw_name")
COMPAQ Professional Workstation XP1000

So it calls itself a "Workstation", but it
could call itself anything and still do the
same work.

> I am also supposed to show if the system is
> a "server" or a "workstation". There is a
> different icon for both in the GUI.

Do what you want. If you can find a VMS user
who actually cares which icon you use for a
particular VMS system, be sure to report
back. Or if you can define the difference
between the two system types.

[Hoff]

An icon??!?!?

If this is not already abundantly clear: you'll almost certainly get this distinction wrong in some subset of the available cases, and you'll add support calls and support costs because of that. (That statement is not aimed at you personally, it's aimed at the difficulty of the problem itself. I'd have trouble with this.)

Display the system model name and move on to the next UI issue.

You could conceivably build a table that maps the system model id value to icon -- that table is very likely static for both Alpha and VAX. For the Integrity Itanium boxes, it's anyone's guess as to what systems are arriving.

You'll end up maintaining a table and shipping table updates from time to time -- and still getting it wrong for either the specific environment or for a new model on occasion. (For a variation of this matter, search for the "dynamic system recognition" (DSR) changes that were made to OpenVMS eons ago; OpenVMS punted this sort of a distinction out to the system hardware itself; out to the console.

Here, I'd simply use a default icon and let the end user select the icon for the particular system. Trump whole the issue and the whole process. Let the user select icons from their own local use. Give'm a box of pretty shiny and reasonably cogent icons, and they'll be happy.

A good first best task here is to go read Jakob Nielsen and Donald Norman's design books, too. I'd suggest a look at design processes involved here as a whole, too, because folks that work directly on software and hardware tend to be quite bad at UI design, and at icon design. Good UI design can differentiate an enterprise product, too.

There are good (free) tools that do this sort of system monitoring and related for OpenVMS, BTW. (Been meaning to get one of the better ones around that's not already tied into OpenVMS over, too.)