Re: OPA0 Console connection

In article <ops6doi7fxzgicya@hyrrokkin>, "Tom Linden" <tom@xxxxxxxxxx> writes:
:On Tue, 14 Mar 2006 00:10:22 GMT, Hoff Hoffman <hoff@xxxxxxxxx> wrote:
:> Even more interesting, COM1 and COM2 don't always map the same
:> way, as these can be an OP device or a TT device based on the
:> system firmware configuration.
:
:Just to make sure I understand, of the two ports (in this case) one being
:TTA0 and the other OPA0, do I have to be on OPA0 to speak to SRM or can I
:also do it from TTA0?

The ports are COM1 and COM2, and what the operating system calls them
and what the firmware calls them and what the documentation calls them
aren't necessarily tied together. The settings vary. I've tried to
make that clear in the FAQ, and have further tried to make it clear
what tends to modify the names. Key factors can be the OpenVMS release
involved and whether or not the console is set to SERIAL or GRAPHICS.

If it were easily solvable, this likely would already have been put to
bed, of course.

:Well it would be nice to have names like $9$dvd instead of $9$DQA0:
:or $9$floppy instead of $9$DVA0:

You have that capability now, of course.

As for my preferences, I avoid physical device names where I can,
seeking to isolate these into SYLOGICALS.COM or into similar
procedures or data stores. (This makes my code more portable
across the various OpenVMS I use boxes -- I already use logical
names widely.) I tend to use DISK$vollab volume labels where I
can, and can and do use application-specific logical names (or
some other data store) when required. As mentioned.

FWIW, $ is also a character reserved to HP and to registered products,
so I'd not use that in any site-specific logical names and in any files,
objects, logical names, etc., associated with unregistered products.

As for your own naming preferences, define your own logical names (sans
the $ character), and use these to specifically identify your devices --
what you're asking for here with these function-specific names seems
reasonable on its face, but it turns into a massively complex problem.
You can easily set up KEDNOS_DVD or KEDNOS1_DVD1 or whatever you want,
of course.

-=-

Physical device names are a convenience that is generated by the
operating system to allow programmers and system managers (humans)
to identify and to differentiate devices, of course -- and while we
could certainly (try to) make these names prettier, we are currently
using a device naming solution that is intended to generate both
short and unique names. Names that are "pretty", cluster-unique,
reproducibly-generated when relatively small changes are made, *and*
device-specific is a non-trivial problem to solve, after all.

As for why this is interesting, when you have a CD-R blank loaded in
a DVD drive, for instance, it's going to call itself a CD-R currently
and a dozen other things will be available as and when needed. What
do you want the algorithm to call it? This further assumes we can
get to the device to ask it what it is -- SCSI, USB and Fibre Channel
devices can come and go, after all, and we depend on PACKACK and MOUNT
to figure out what's out there. Some devices don't appear until they
have something to do -- and USB devices are really often just SCSI
devices that can go "unavailable" at any given moment.

We punted this naming and device identification stuff some years ago
(and particularly when y'all wanted to be able to connect anything to
anything, without having to upgrade to have OpenVMS support), and we
now simply ask the devices "what do you call yourself" where we can.
We don't try to do much with that, other than to display it. (We're
largely left with that MicroVAX subroutine stuff I mentioned earlier;
with that SYLOGICALS.TEMPLATE stuff.) Remember the old DT$ and DC$
codes? With the dynamic device and dynamic system recognition, we
largely moth-balled those old built-in mechanisms.

Newer devices can have unique names, usually a WWID, UUID or GUID
string -- but you don't want to have to enter these manually. And
not all new devices have these -- or have anything unique -- present,
and older and commodity devices -- such as those you and other folks
are likely using -- simply don't have these identifying values widely
available. And we don't have -- barring device-local storage or a
way to map the device serial number -- a construct which doesn't
exist for all devices -- back to a "pretty" name using a local data
store. (Then there's all the "fun" of initializing all that, too.)

And again, this device name is to allow humans to figure out where
the I/O goes -- OpenVMS itself doesn't need to have device names for
correct operation. (We don't have device names when we configure
stuff, for instance. We just need an algorthm that allows us to
generate the requisite device name, and to ensure it's a relatively
consistently and uniquely generated name.)

We're doing further work in the general area of devices and device
naming, but I'm not presently in a position to discuss that work --
and the results of that work probably won't affect this particular
case, in any event.


:> You just haven't seen the problem yet. Anything that can or does
:> generate a framing error on the line will trigger the halt.

:OK, I understand, you can't leave it attached too long, and how long is
:that?

Just a little less than when that next framing error will arrive,
of course.

So long as communications and power and signals are stable, these
sorts of connections tend to be stable. When they go weird and
the Alpha SRM console then sees the arrival of the framing error
(the BREAK -- when enabled), the Alpha system will then halt.

--

FWIW, Integrity servers largely solve the remote console access with
the available management processor (MP) option -- you can perform most
of the typical management operations entirely remotely, using the MP.
The classic serial line connection is still around, particularly if
you do not have the MP installed in the Integrity server.

--

Now if y'all will excuse me, I have a little open source code that
I'm working with and that I need to sort out, and the behaviour it
is presently manifesting is just, um, well, something that I have
yet to fathom. (And as my build of that code is now finished, it's
off to plumb the depths...)

---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[\0100]hp.com

.

Relevant Pages

  • Device Naming: (was OPA0 Console connection)
    ... The ports are COM1 and COM2, and what the operating system calls them ... Key factors can be the OpenVMS release ... As for your own naming preferences, define your own logical names (sans ... Just a little less than when that next framing error will arrive, ...
    (comp.os.vms)
  • Updated VMS Information
    ... Favorite Operating System Survey] ... We will be doing OpenVMS Technical ... PL/I for OpenVM HTML Documentation kit ... In response to demand we are please to offer all the PL/I documentation ...
    (comp.os.vms)
  • Re: Why OpenVMS is better than linux ...
    ... > OpenVMS is the most well designed computer operating system in the ... How many VMS systems are sitting idle or shut down with valid licenses? ... because of the costs of maintaining VMS, DEC-type hardware and related ...
    (comp.os.linux.security)
  • Re: Why OpenVMS is better than linux ...
    ... >> OpenVMS is the most well designed computer operating system in the ... How many VMS systems are sitting idle or shut down with valid licenses? ... > because of the costs of maintaining VMS, DEC-type hardware and related ...
    (comp.os.linux.security)
  • Re: does any one know of location on architecture of VMS i.e in graphical form
    ... slightly different variations) in most books discussing OpenVMS OS ... architecture. ... Practically all generic texts and university courses on Operating System ... To begin to acquire the real knowledge needed to understand and compare ...
    (comp.os.vms)