DECW on VMS V5.5.2

[VAXman-]

I found that I had a McroVAX-3100-80 lying about (and a few other system
surprises I'd fogotten I had) and I installed V5.5-2 on for testing of my
DCL Debugger. However, I cannot seem to get DECWindows to function.

I've set the display to a VAXstation-4000 model 96 as:

$ SET DISPLAY/CREATE/NODE=VS4096/TRANSPORT=DECNET/EXEC

However, $ CREATE/TERMINAL returns:

%NONAME-E-NOMSG, Message number 02DBC01A
%SYSTEM-F-IVLOGNAM, invalid logical name


Running DECW$TERMINAL shows a few more details:

$ SPAWN MCR DECW$TERMINAL
%DCL-S-SPAWNED, process SYSTEM_1 spawned
%DCL-S-ATTACHED, terminal now attached to process SYSTEM_1
X Toolkit Warning: DRM: I18NOpenFile: Couldn't open file DECW$TERMINAL - DRMFailure
X Toolkit Warning: Drm__OpenHierarchy: - DRMFailure
Unable to open DRM User Interface Definition:

DECW$TERMINAL
PTY exiting.

%NONAME-E-NOMSG, Message number 02DBC01A
%NONAME-E-NOMSG, Message number 02DBC01A
%DCL-S-RETURNED, control returned to process SYSTEM
%NONAME-E-NOMSG, Message number 02DBC01A


I went back to DECW$TAILOR everything DECWindow onto this system but I still
get this error. What am I missing?

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

[Chris Scheers]

VAXman- @SendSpamHere.ORG wrote:
> I found that I had a McroVAX-3100-80 lying about (and a few other system
> surprises I'd fogotten I had) and I installed V5.5-2 on for testing of my
> DCL Debugger. However, I cannot seem to get DECWindows to function.
>
> I've set the display to a VAXstation-4000 model 96 as:
>
> $ SET DISPLAY/CREATE/NODE=VS4096/TRANSPORT=DECNET/EXEC
>
> However, $ CREATE/TERMINAL returns:
>
> %NONAME-E-NOMSG, Message number 02DBC01A
> %SYSTEM-F-IVLOGNAM, invalid logical name
>
>
> Running DECW$TERMINAL shows a few more details:
>
> $ SPAWN MCR DECW$TERMINAL
> %DCL-S-SPAWNED, process SYSTEM_1 spawned
> %DCL-S-ATTACHED, terminal now attached to process SYSTEM_1
> X Toolkit Warning: DRM: I18NOpenFile: Couldn't open file DECW$TERMINAL - DRMFailure
> X Toolkit Warning: Drm__OpenHierarchy: - DRMFailure
> Unable to open DRM User Interface Definition:

Under VMS 5.5-2, I don't normally use the /EXEC switch to SET DISPLAY,
but it might be needed for a detached process.

Things that come to mind:

What does "SHOW LOG DECW$DISPLAY" show?

Are the two nodes clustered?

Is there a DECwindows license installed?

Does VS4096 have an appropriate proxy?

--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ch...@applied-synergy.com
Fax: 817-237-3074

[VAXman-]

In article <kmu4ku$vle$1...@dont-email.me>, Chris Scheers <ch...@applied-synergy.com> writes:
>VAXman- @SendSpamHere.ORG wrote:
>> I found that I had a McroVAX-3100-80 lying about (and a few other system
>> surprises I'd fogotten I had) and I installed V5.5-2 on for testing of my
>> DCL Debugger. However, I cannot seem to get DECWindows to function.
>>
>> I've set the display to a VAXstation-4000 model 96 as:
>>
>> $ SET DISPLAY/CREATE/NODE=VS4096/TRANSPORT=DECNET/EXEC
>>
>> However, $ CREATE/TERMINAL returns:
>>
>> %NONAME-E-NOMSG, Message number 02DBC01A
>> %SYSTEM-F-IVLOGNAM, invalid logical name
>>
>>
>> Running DECW$TERMINAL shows a few more details:
>>
>> $ SPAWN MCR DECW$TERMINAL
>> %DCL-S-SPAWNED, process SYSTEM_1 spawned
>> %DCL-S-ATTACHED, terminal now attached to process SYSTEM_1
>> X Toolkit Warning: DRM: I18NOpenFile: Couldn't open file DECW$TERMINAL - DRMFailure
>> X Toolkit Warning: Drm__OpenHierarchy: - DRMFailure
>> Unable to open DRM User Interface Definition:
>
>Under VMS 5.5-2, I don't normally use the /EXEC switch to SET DISPLAY,
>but it might be needed for a detached process.
>
>Things that come to mind:
>
>What does "SHOW LOG DECW$DISPLAY" show?

$ SHOW DISPLAY

Device: WSA2: [exec]
Node: VS4096
Transport: DECNET
Server: 0
Screen: 0

$ SHOW LOGICAL DECW$DISPLAY
"DECW$DISPLAY" = "_WSA2:" (LNM$PROCESS_TABLE)

>Are the two nodes clustered?

No.

>Is there a DECwindows license installed?

Yes.

>Does VS4096 have an appropriate proxy?

Proxy to and from both exsits:

MV3180 <=> VS4096

FWIW, I'm able to run DECW$PUZZLE, for example, from other VAXen, Alpha
and Integrity to the VS4096. On the MicroVAX 3100-80 with V5.5-2 gives
me an issue.

[Steven Schweda]

I know nothing, but ...

> [...] I don't normally use the /EXEC switch to SET DISPLAY,
> [...]

Nor I, but it seems to make no obvious difference on my
V5.5-2 system, which seems to work just fine.

My Google search for the error message (%x02DBC01A ->
"%DECW-E-CANT_OPEN_DRM, Can't open DRM database") found only
one (old) similar question, with no solution.

> Does VS4096 have an appropriate proxy?

Does DECwindows care about a proxy? The "New Desktop"
Style Manager Security gizmo might matter, but I'd expect
proxies not to. (And I'd expect some different complaint if
a security setting were the problem.)

Should I assume that SYS$MANAGER:DECW$STARTUP.COM gets run
at system start-up? And RESTART doesn't help? And AUTOGEN
has made any required adjustments (and not got stuck in a
loop)?

> X Toolkit Warning: DRM: I18NOpenFile: Couldn't open file
> DECW$TERMINAL - DRMFailure

Anything to do with the presence or absence of the I18N
stuff? (Was that a separate kit?)

[VAXman-]

I installed this from the most convenient source -- the Hobbyist V1 CD.

Yesterday, I reinstalled everything from actual d|i|g|i|t|a|l media [*]
-- VMS055 and DECW055, VMSMUP055, VMS2U055 and DW-Motif (this DW-Motif
kit was from the same ConDist CD I used before). Upon reinstallation,
DECWindows is now functioning as it should. Is something amuck on that
Hobbyist V1 distro? Who knows? But it does seem likely.

Now I can go back to what I was working on when I started this install
of V5.5-2.

[*] Thanks to my wife who recently sorted and indexed several thousand
CDs that had been salvaged from flood waters. Sadly, much old doc. and
tape wasn't so lucky.

[Steven Schweda]

> [...] Is something amuck on that Hobbyist V1 distro? [...]

Not in my experience.

[Bob Koehler]

In article <59eb3c90-99e9-42bf...@j4g2000yqc.googlegroups.com>, Steven Schweda <sms.an...@gmail.com> writes:

>> [...] Is something amuck on that Hobbyist V1 distro? [...]
>
> Not in my experience.

IIRC, I saw a similar (same?) error after installing the hobbyist
8.4 distro on my Alpha. Previously, everything had been installed
from H kits (DEC mastered CD or magtape).

I seem to recall there was a change to the available DECwindows
authorization techniques (adding something that HP-UX had) and
needing to tell VMS to use the previous style.

But I thought it was something new, that would not have been around
to cause problems for VMS 5.x. And I don't recall ever seeing it
on a VAX.

Sadly, all my Alphas are kaput now, so I can't look into it.

[Stephen Hoffman]

On 2013-05-15 18:42:06 +0000, Bob Koehler said:

> I seem to recall there was a change to the available DECwindows
> authorization techniques (adding something that HP-UX had) and
> needing to tell VMS to use the previous style.

In terms of the products looking for one of a set of license PAKs,
nothing changed.

OpenVMS on I64 did get the Operating Environment (OE) PAKs that enabled
a variety of products. The OE PAKs are basically the same scheme as
the old NAS NET-APP-SUPP license PAKs that were around an eon or two
ago, too, and AFAIK were implemented using the same LMF mechanisms as
the NAS PAKs used.

--
Pure Personal Opinion | HoffmanLabs LLC

[Simon Clubley]

I think Bob is talking about the authorisation capabilities within the
X11 based protocols themselves which allow access by other devices to the
machine in question and not the LMF based authorisation for DECwindows.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Jojimbo]

On May 14, 9:01 am, VAXman- @SendSpamHere.ORG wrote:
> I found that I had a McroVAX-3100-80 lying about (and a few other system

<snip>

> $ SPAWN MCR DECW$TERMINAL
> %DCL-S-SPAWNED, process SYSTEM_1 spawned
> %DCL-S-ATTACHED, terminal now attached to process SYSTEM_1
> X Toolkit Warning: DRM: I18NOpenFile: Couldn't open file DECW$TERMINAL - DRMFailure
> X Toolkit Warning: Drm__OpenHierarchy:  - DRMFailure
> Unable to open DRM User Interface Definition:
>
>  DECW$TERMINAL
> PTY exiting.
>
> %NONAME-E-NOMSG, Message number 02DBC01A
> %NONAME-E-NOMSG, Message number 02DBC01A
> %DCL-S-RETURNED, control returned to process SYSTEM
> %NONAME-E-NOMSG, Message number 02DBC01A
>
> I went back to DECW$TAILOR everything DECWindow onto this system but I still
> get this error. What am I missing?
>

You are missing the DRM file for decw$terminal. Or it's not in the
right place or some logical is not right. This is going way back so
pardon my memory but I always used to troubleshoot these kinds of
problems with:

$ MCR DECW$CLOCK

It has better error messages. Another approach would be to set watch/
file/class=all and then run your application so it will display what
file it's looking for. Sorry, don't have any system available to try
this on. Good luck.

[Jojimbo]

A bit more information that might help. These decwindows applications
had some resources/settings stored in UID files. The openheirarchy
call loaded them into the X resource manager database. I found this
note about the examples that were provided that shows an example of
this type of failure:


V1.2

The UID files used by the Motif example programs must be located in
either the current directory, DECW$SYSTEM_DEFAULTS, or your DECW
$USER_DEFAULTS directory. DECwindows Motif does not support accessing
remote UID files using the DECNET (DECnet or DECnet-Plus) transport.
As a result, the default directories do not support a node name
specification. Entering a node name in the UID directory specification
fails to start the application and results in an error similar to the
following:


X Toolkit Warning: I18NOpenFile: Could not open file decburger.uid -
MrmNOT_FOUND
can't open hierarchy

The UID files can be copied from the DECW$EXAMPLES directory. To
access a remote UID file, either copy the file to a local node on the
cluster, or use Distributed File System (DFS) to mount the disk that
contains the file on the cluster.

So check the two mentioned logicals to see if there is an DECW
$TERMINAL.UID file available.

On a related note, maybe set watch file didn't exist in VMS 5.52? But
doing the exercise on another VAX may still be helpful to see where
it's looking.

On a further note, am I the only one who ever wrote a DECWINDOWS
application using UIL? See if you can find my long lost DEC/VAX
professional article and you can learn how it all works..

Regards, Jim

[VAXman-]

In article <054ad5d6-280c-4a9a...@n5g2000pbg.googlegroups.com>, Jojimbo <jjges...@gmail.com> writes:

>On May 14, 9:01=A0am, VAXman- @SendSpamHere.ORG wrote:
>> I found that I had a McroVAX-3100-80 lying about (and a few other system
><snip>
>> $ SPAWN MCR DECW$TERMINAL
>> %DCL-S-SPAWNED, process SYSTEM_1 spawned
>> %DCL-S-ATTACHED, terminal now attached to process SYSTEM_1

>> X Toolkit Warning: DRM: I18NOpenFile: Couldn't open file DECW$TERMINAL - =
>DRMFailure
>> X Toolkit Warning: Drm__OpenHierarchy: =A0- DRMFailure

>> Unable to open DRM User Interface Definition:
>>

>> =A0DECW$TERMINAL

>> PTY exiting.
>>
>> %NONAME-E-NOMSG, Message number 02DBC01A
>> %NONAME-E-NOMSG, Message number 02DBC01A
>> %DCL-S-RETURNED, control returned to process SYSTEM
>> %NONAME-E-NOMSG, Message number 02DBC01A
>>

>> I went back to DECW$TAILOR everything DECWindow onto this system but I st=

>ill
>> get this error. What am I missing?
>>
>You are missing the DRM file for decw$terminal. Or it's not in the
>right place or some logical is not right. This is going way back so
>pardon my memory but I always used to troubleshoot these kinds of
>problems with:
>
>$ MCR DECW$CLOCK
>
>It has better error messages. Another approach would be to set watch/

>file/class=3Dall and then run your application so it will display what

>file it's looking for. Sorry, don't have any system available to try
>this on. Good luck.

That's exactly what I did; however, the DECW$TERMINAL.UID file was there.
There were some accesses which SET WATCH FILE called out as 00000910 --
no such file -- but I didn't know what those were. Anyway, reinstalling
from the d|i|g|i|t|a|l supplied media seemed to have provided me what was
missing.

[Jojimbo]

On May 16, 1:12 pm, VAXman- @SendSpamHere.ORG wrote:

Glad it worked out, but it just seems so M$SFT'y to resolve a problem
by reinstalling. But then I suppose picking through a 20+ year old
distribution is a bit much to expect these days. It was fun looking
up some of that stuff anyway.

Regards, Jim

[Bob Koehler]

In article <kn0ihj$r6p$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
> On 2013-05-15 18:42:06 +0000, Bob Koehler said:
>
>> I seem to recall there was a change to the available DECwindows
>> authorization techniques (adding something that HP-UX had) and
>> needing to tell VMS to use the previous style.
>
> In terms of the products looking for one of a set of license PAKs,
> nothing changed.

I'm talking X11 client/server authorization, not product licenses.

[Bob Koehler]

In article <cf263941-18f3-40c0...@fz1g2000pbb.googlegroups.com>, Jojimbo <jjges...@gmail.com> writes:
>
> On a further note, am I the only one who ever wrote a DECWINDOWS
> application using UIL? See if you can find my long lost DEC/VAX
> professional article and you can learn how it all works..

No. We had a couple of large systems which utilized UIL. We
also had a couple of fellows who swore we should never do that.

Sadly, one of the systems was written by FORTRAN programmers, for
FORTRAN programmers (there's a reason I don't write it Fortran). So
the fellow who was leading the effort for that system insisted both
systems use DEC's Fortran interface to X11. This caused the system
to remain stuck on some VMS 5.x release when X11 calls changed (R3
to R4 transition?) and DEC provided tools to migrate C.

[Stephen Hoffman]

Ah, OK.

Basic authorization has been unchanged AFAIK.

The XDM support was added, and has been several different bags of hurt
in the last decade or so. The decw$xauth tool and MIT Magic Cookie
support was added circa DECwindows V1.3; circa OpenVMS Alpha V7.3-2;
circa 2003. Not available for OpenVMS VAX.

There was a duplicate-cookie error that was discussed here. VAXman was
bitten that bug, apparently added in TCP/IP Services V5.7 and since
slain. AFAIK, the current stuff does work.

Getting XDM to work has been fodder for a number of discussions over
the years, too.