how, exactly, is SYS$NODE defined?
Phillip Helbig---remove CLOTHES to reply
the moment, but even in the future I probably won't run it on all my
systems. However, SYS$NODE is needed by some other applications, in
particular DECwindows (perhaps only to say "Welcome to SYS$NODE" and
"Session Manager on SYS$NODE") and (I'm not sure about this) LAT. Thus,
I have been defining it /SYSTEM/EXEC relatively early in the startup
sequence. Is this the proper way to define it? I'm pretty sure
/SYSTEM/EXEC is correct, but what about /TRANS?
AEF
$ SHOW LOG/FUL SYS$NODE
"SYS$NODE" [exec,crelog] = "IDS15::" [terminal] (LNM$SYSTEM_TABLE)
Yes, /SYS/EXEC is correct, but to match the real SYS$NODE you also need
/TRAN=TERMINAL. But you'll still be missing the crelog part and I don't
think you can do that part with DCL! But if your app is only asking for
the node name it shouldn't matter.
Whether it is a good idea or not to define SYS$NODE outside of running
DECnet I can't say.
Hoff Hoffman
:SYS$NODE is normally defined by DECnet. I'm not running any DECnet at
You should not need to define it. If DECwindows thinks it needs it,
then that would arguably be a bug in either DECwindows (for needing
it) or in OpenVMS (for not defining it if DECnet is not around).
What versions of OpenVMS and DECwindows?
The usual definition is /SYS/EXEC/TRAN=TERM, FWIW.
---------------------------- #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[at]hp.com
norm.r...@metso.com
"AEF" <spamsi...@yahoo.com> wrote on 05/05/2005 12:57:46 PM:
>
> Phillip Helbig---remove CLOTHES to reply wrote:
> > SYS$NODE is normally defined by DECnet. I'm not running any DECnet
> at
> > the moment, but even in the future I probably won't run it on all my
> > systems. However, SYS$NODE is needed by some other applications, in
> > particular DECwindows (perhaps only to say "Welcome to SYS$NODE" and
> > "Session Manager on SYS$NODE") and (I'm not sure about this) LAT.
> Thus,
> > I have been defining it /SYSTEM/EXEC relatively early in the startup
> > sequence. Is this the proper way to define it? I'm pretty sure
> > /SYSTEM/EXEC is correct, but what about /TRANS?
>
>
> $ SHOW LOG/FUL SYS$NODE
> "SYS$NODE" [exec,crelog] = "IDS15::" [terminal] (LNM$SYSTEM_TABLE)
>
> Yes, /SYS/EXEC is correct, but to match the real SYS$NODE you also need
> /TRAN=TERMINAL. But you'll still be missing the crelog part and I don't
> think you can do that part with DCL! But if your app is only asking for
> the node name it shouldn't matter.
>
> Whether it is a good idea or not to define SYS$NODE outside of running
> DECnet I can't say.
>
There are at least 3 ways to get the node_name:
$say "<",f$getsyi("scsnode"),">"
<NODEA >
$say "<",f$getsyi("nodename"),">"
<NODEA>
$say "<",f$trnlnm("sys$node"),">"
<NODEA::>
$
If you are not running DECnet, perhaps one of the others will work.
Hoff Hoffman
:There are at least 3 ways to get the node_name:
:
:$say "<",f$getsyi("scsnode"),">"
:<NODEA >
:$say "<",f$getsyi("nodename"),">"
:<NODEA>
:$say "<",f$trnlnm("sys$node"),">"
:<NODEA::>
:$
:
:If you are not running DECnet, perhaps one of the others will work.
I'll see if I can't free up some code either for inclusion in a future
RTL or for the Freeware, as I've a routine that gathers the name from
about a dozen different spots. Two routines, actually -- one looks for
a series of names from biggest (cluster) to smallest (local node) and
the other basically reverses that. The two routines are each a dozen
or so logical name translations.
Phillip Helbig---remove CLOTHES to reply
"AEF" <spamsi...@yahoo.com> writes:
> $ SHOW LOG/FUL SYS$NODE
> "SYS$NODE" [exec,crelog] = "IDS15::" [terminal] (LNM$SYSTEM_TABLE)
>
> Yes, /SYS/EXEC is correct, but to match the real SYS$NODE you also need
> /TRAN=TERMINAL. But you'll still be missing the crelog part and I don't
> think you can do that part with DCL! But if your app is only asking for
> the node name it shouldn't matter.
What is CRELOG?
> Whether it is a good idea or not to define SYS$NODE outside of running
> DECnet I can't say.
Apparently it doesn't hurt. I don't think any software would check to
see if it is defined to determine whether DECnet is running. It seems
that DECwindows assumes that DECnet exists---that might have been a
valid assumption in the early days, but not anymore. Fortunately, the
OS and DECnet are more or less separate now, MONITOR can run over TCPIP
etc. (I think PHONE still wants DECnet, though.)
Phillip Helbig---remove CLOTHES to reply
Hoffman) writes:
> You should not need to define it. If DECwindows thinks it needs it,
> then that would arguably be a bug in either DECwindows (for needing
> it) or in OpenVMS (for not defining it if DECnet is not around).
That's the way I see it.
> What versions of OpenVMS and DECwindows?
7.3 VAX, 7.3-1 ALPHA, the latest available DECwindows for each. (I plan
to upgrade to 7.3-2 and, I believe, a newer DECwindows around the middle
of May.)
On VAX, the "Session Manager" displays the node name, as does the login
box. On ALPHA with CDE, the login box displays the node name. These
want SYS$NODE. (I don't see why the code couldn't use
F$GETSYI("SCSNODE").)
John Laird
(Phillip Helbig---remove CLOTHES to reply) wrote:
>What is CRELOG?
SYS$CRELOG (and DELLOG and TRNLOG) predated their xxxLNM replacements. For
no doubt sound technical reasons that I couldn't begin to explain, a bit is
reserved in the logical name flags to indicate that CRELOG was used to
create the entry. TRNLOG was much easier to program than TRNLNM for simple
use, and there is still a LIB$SYS_TRNLOG "equivalent".
--
I'm an analog man in a digital world.
Mail john rather than nospam...
Phillip Helbig---remove CLOTHES to reply
> There are at least 3 ways to get the node_name:
>
> $say "<",f$getsyi("scsnode"),">"
> <NODEA >
> $say "<",f$getsyi("nodename"),">"
> <NODEA>
> $say "<",f$trnlnm("sys$node"),">"
> <NODEA::>
> $
>
> If you are not running DECnet, perhaps one of the others will work.
It's not a problem FOR ME to get the node name, but rather DECwindows
uses only SYS$NODE.
AEF
Hoff Hoffman wrote:
> In article <d5df13$22t$2...@online.de>, hel...@astro.multiCLOTHESvax.de
(Phillip Helbig---remove CLOTHES to reply) writes:
> :SYS$NODE is normally defined by DECnet. I'm not running any DECnet
at
> :the moment, but even in the future I probably won't run it on all my
> :systems. However, SYS$NODE is needed by some other applications, in
> :particular DECwindows (perhaps only to say "Welcome to SYS$NODE" and
> :"Session Manager on SYS$NODE") and (I'm not sure about this) LAT.
Thus,
> :I have been defining it /SYSTEM/EXEC relatively early in the startup
> :sequence. Is this the proper way to define it? I'm pretty sure
> :/SYSTEM/EXEC is correct, but what about /TRANS?
>
> You should not need to define it. If DECwindows thinks it needs
it,
> then that would arguably be a bug in either DECwindows (for needing
> it) or in OpenVMS (for not defining it if DECnet is not around).
Is this something new, that SYS$NODE is defined by VMS even when DECnet
is not running? (New since VMS v6.2, i.e.)
[...]
Phillip Helbig---remove CLOTHES to reply
<spamsi...@yahoo.com> writes:
> > You should not need to define it. If DECwindows thinks it needs
> it,
> > then that would arguably be a bug in either DECwindows (for needing
> > it) or in OpenVMS (for not defining it if DECnet is not around).
>
> Is this something new, that SYS$NODE is defined by VMS even when DECnet
> is not running? (New since VMS v6.2, i.e.)
I think Hoff was saying that it is a bug that VMS does NOT define it, if
it needs it when DECnet is not running, or, alternatively, it is a bug
in DECwindows for wanting to use it instead of, say, SCSNODE.
FredK
DECwindows doesn't "need" DECwindows to be running, I run without
DECnet installed at all, just using TCPIP. However, it is pretty apparent
that circa 1993 or so, the code that implements gethostname inside
DECwindows assumes SYS$NODE is defined, otherwise you get a
null string return.
I'd report this as a bug, but aside from say a quick & dirty fix in DTLOGIN,
a "real" fix to the gethostname code will need careful visual inspection and
testing of a number of things in the X11 code.
"Phillip Helbig---remove CLOTHES to reply" <hel...@astro.multiCLOTHESvax.de>
wrote in message news:d5e3gd$178$1...@online.de...
Dave Froble
Ok, I may be way off base.
Run SYSGEN and then SHOW SCSNODE.
I've always thought that was the source of the logical. Never really
looked to check on that. I fon't think that you need to define the
logical, I think VMS does it at startup.
Could be wrong.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. Fax: 724-529-0596
DFE Ultralights, Inc. E-Mail: da...@tsoft-inc.com
170 Grimplin Road
Vanderbilt, PA 15486
David J Dachtera
>
Then, maybe this would be good enough:
$ IF F$TRNLNM( "SYS$NODE" ) .EQS. "" THEN -
$ DEFINE/SYSTEM/EXEC SYS$NODE 'F$GETSYI("NODENAME")'::/TRAN=TERM
Do that in SYLOGICALS.COM or SYSTARTUP_VMS.COM, as appropriate.
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Coming soon:
Unofficial OpenVMS Marketing Home Page
Phillip Helbig---remove CLOTHES to reply
<fred....@nospam.dec.com> writes:
> DECwindows doesn't "need" DECwindows to be running, I run without
> DECnet installed at all, just using TCPIP. However, it is pretty apparent
> that circa 1993 or so, the code that implements gethostname inside
> DECwindows assumes SYS$NODE is defined, otherwise you get a
> null string return.
Right; that's what I'm referring to.
Phillip Helbig---remove CLOTHES to reply
<djesys...@comcast.net> writes:
> Then, maybe this would be good enough:
>
> $ IF F$TRNLNM( "SYS$NODE" ) .EQS. "" THEN -
> $ DEFINE/SYSTEM/EXEC SYS$NODE 'F$GETSYI("NODENAME")'::/TRAN=TERM
I do something similar, using SCSNODE and F$EDIT with TRIM. Can't get
the CRELOG in there, but for telling DECwindows the node name this seems
good enough.
FredK
"Phillip Helbig---remove CLOTHES to reply" <hel...@astro.multiCLOTHESvax.de>
wrote in message news:d5eqke$lgs$1...@online.de...
Bob Koehler
>
> Run SYSGEN and then SHOW SCSNODE.
>
> I've always thought that was the source of the logical. Never really
> looked to check on that. I fon't think that you need to define the
> logical, I think VMS does it at startup.
DECnet defined SYS$NODE long before clusters existed and SCSNODE was
added to SYSGEN.
Hoff Hoffman
:In article <1115328634....@z14g2000cwz.googlegroups.com>, "AEF"
:> Is this something new, that SYS$NODE is defined by VMS even when DECnet
:> is not running? (New since VMS v6.2, i.e.)
:
:I think Hoff was saying that it is a bug that VMS does NOT define it, if
:it needs it when DECnet is not running, or, alternatively, it is a bug
:in DECwindows for wanting to use it instead of, say, SCSNODE.
Correct. Either DECwindows shouldn't expect it to be present in all
cases, or (if it needs it) then OpenVMS should provide the definition
when DECnet is absent. I do need to sort out the details before I log
an internal report of this behaviour -- what specifically within
DECwindows was looking for SYS$NODE.
As I mentioned (somewhere) I have code that looks for the local node
name based on a series of system calls and particularly (mostly) a
series of logical name translations. This would probably be best
added into one of the RTLs, as there are more than a few products
and packages around -- I wrote the code and now use it in several of
my applications -- that want to know the name of the node, and do
not want to know which of the various names or network stacks or
such are present; that don't need nor want to know the source of
the node name.
FredK
%LocalHost% from the welcome string with the result of gethostname,
which if you trace it several layers deep calls FNM_GET_HOSTNAME
in the FULLNAME module on the VMS master pack (!), which in turn
translates SYS$NODE.
Fixing the DTLOGIN issue locally is fairly simple. The reql question is
if the rest of the code should be examined for the use of gethostname.
Since I was complaining, I also requested TCPIP to be added to the
default transport list ;-)
"Hoff Hoffman" <ho...@hp.nospam> wrote in message
news:JrMee.5008$Ak1....@news.cpqcorp.net...
Dave Froble
Ah, and since I always have DECnet, its always been there for me.
Phillip Helbig---remove CLOTHES to reply
<fred....@nospam.dec.com> writes:
> I've opened an internal bug report on it.
Thanks. It's nice to see that users of VMS workstations (I have several
at home, and also one at work, where I spend almost all of my day) are
still taken into consideration!
Phillip Helbig---remove CLOTHES to reply
Hoffman) writes:
> Correct. Either DECwindows shouldn't expect it to be present in all
> cases, or (if it needs it) then OpenVMS should provide the definition
> when DECnet is absent. I do need to sort out the details before I log
> an internal report of this behaviour -- what specifically within
> DECwindows was looking for SYS$NODE.
Note that Fred Kleinsorge has stated here that he has opened an internal
bug report.
All I've noticed is the login box on both CDE/ALPHA and traditional/VAX
and the "Session Manager" toolbar in the traditional interface.
Phillip Helbig---remove CLOTHES to reply
<fred....@nospam.dec.com> writes:
> A PTR case is logged. DECwindows in this case replaces the string
> %LocalHost% from the welcome string with the result of gethostname,
> which if you trace it several layers deep calls FNM_GET_HOSTNAME
> in the FULLNAME module on the VMS master pack (!), which in turn
> translates SYS$NODE. ^^^^^^^^^^^
Wow! Reminds me of watching Felix the Cat back when I was 4 or 5 years
old, where the Master Cylinder character appeared. It wasn't until a
few years later, when watching my father work on the car, that he
mentioned in passing "that's the master cylinder". I couldn't
understand at all why my father would make a reference to Felix the Cat.
:-)
> Fixing the DTLOGIN issue locally is fairly simple. The reql question is
> if the rest of the code should be examined for the use of gethostname.
Does this refer to just CDE/ALPHA (I've never used the traditional
interface on ALPHA and don't even know if it exists) or to the
traditional/VAX interface as well (where there is the same problem with
the login box, but also for the session-manager toolbar).
> Since I was complaining, I also requested TCPIP to be added to the
> default transport list ;-)
That has to be the single most common problem I've encountered. "Why
doesn't my display work?" Display set correctly on remote machine,
check. Security allows remote connections, check. Transport TCPIP
allowed?
FredK
> In article <ZMNee.5016$ro1....@news.cpqcorp.net>, "FredK"
>
> > Fixing the DTLOGIN issue locally is fairly simple. The reql question is
> > if the rest of the code should be examined for the use of gethostname.
>
> Does this refer to just CDE/ALPHA (I've never used the traditional
> interface on ALPHA and don't even know if it exists) or to the
> traditional/VAX interface as well (where there is the same problem with
> the login box, but also for the session-manager toolbar).
>
Well. The *VAX* code is a seperate entity. The "traditional" Motif desktop
on the other hand, probably also uses the result of the same call. My
quick check started in DTLOGIN, which led to XMU, which led to XLIB
which led to FULLNAME.
> > Since I was complaining, I also requested TCPIP to be added to the
> > default transport list ;-)
>
> That has to be the single most common problem I've encountered. "Why
> doesn't my display work?" Display set correctly on remote machine,
> check. Security allows remote connections, check. Transport TCPIP
> allowed?
>
Yes. It's always bugged me a little.