Conference bulova::decw_jan-89_to_nov-90

I'll give you the "approximate" reason and let someone else give an official
party line if one exists:

Basically in the time we had, we could not insure ourselves that the account
would really be captive.  It has always been VMS's philosophy to not give a
partial solution which implies that a problem has been fixed when there are
in fact known problems.  One example of this is the customer desire for a
"logout.com".  There are so many ways to end a session that VMS has never been
able to guarantee that logout.com will always be run.

Similar for DECwindows.  There are so many ways to do so many bizzare things in
DW that we were not confident that we could implement captive accounts.  Thus
we chose to say that they are unsupported.

Note that in the original example, you can work around the logout.com problem
by defining a symbol lo*gout which executes logout.com.  However, this does not
keep someone from saying STOP/ID=0 or RU SYS$SYSTEM:LOGINOUT etc etc.  Similarly
one can put commands in DECW$LOGIN.COM to run some specific applications and
never run the session manager.  There are lots of holes in this approach too.

Does this help?

Burns

    We had long debates about what "captive" would even mean for the
    workstation environment.  As I recall, in V1 FT we had some vocal
    FT sites, but little agreement on the requirements.
    
    Captive is basically defined on CC terminals as "the user never gets
    to a DCL prompt".  This makes possible the substituting of an entire
    environment (like AI1) without the user being aware.  What does that
    mean for DECwindows?  Not being able to run certain apps? Having a
    different window manager?  Not having a session mgr (or a different
    one)?  Not ever seeing a DECterm or Fileview?
    
    The basic environment is customizable enough to achieve most of these
    without "Captive" support.  
    
    What is your customer's notion of what captive should be on their
    workstations?

>> What does captive even mean?

For my customer (and myself, in my old system manager days), captive means:

1.  The user can't run any applications except those we specifically
    authorize.

2.  The user can't enter DCL commands.

3.  The user can't create files of arbitrary size or names, except under
    the control of our applications, which are trusted to protect our
    disk utilizations and still give the user better feedback than 
    "disk quota exceeded".

The main reasons for captivity of users, from our perspective, are keeping
the user from snooping around or causing malicious damage through DCL or
user-written programs, and to keep our always limited disk space from
being accidently or purposely filled up.

No guaranties are expected, though that would be nice.  What we want is 
clear advice to system managers:  This is what you need to do to set up
your system so:

1.  Upon login, User A is restricted to one particular application.

or

2.  Upon login, User B is allowed this particular list of applications.

I realize that my simplistic view of security leaves much to be desired.
But wouldn't it be nice to implement this much at least, rather than just
saying "You can't have captive users under DECwindows"?

Thanks,
JPB

Software Delivery
St. Louis (STO)

    RE: .3
    
    While many of the resource issues raised in .3 may make sense when a
    user is accessing a large Time-sharing system via a CCT, it is unclear
    to me that it makes sense in the case where I have put a whole
    workstation on the user's desk. I believe that as we migrate more and
    more users from the time-sharing environment to the desktop environment
    we need to help customers re-address what they are trying to accomplish
    with "captive" accounts. One good question to ask is:
    
    "If I place an 80386 based PC on your user's desk, how would you lock
    them into a 'captive' environment and prevent them from running
    whatever PC based piece of software they chose to bring to work?"
    
    I believe that usual answer is probably "we don't, it is a different
    situation". We need to help customers see that a DECwindows environment
    is also a different situation.

The common one I hear is a shop floor environment where they just want 
to run their application upon login.  We should at least provide for
that.  They (rightly) expect more from us than a pc. 

...Just thought I'd grap the "mike", for a second here, and 
get up on my soapbox...

re: .4

>>> < Note 2703.4 by LNKUGL::BOWMAN "Bob Bowman, CSC/CS SPACE Team" >
>>>          -< I think we are placing customers in a new environment... >-
>>>
>>>    RE: .3
>>>    
?????? While many of the resource issues raised in .3 may make sense when a
?????? user is accessing a large Time-sharing system via a CCT, it is unclear
>>>    to me that it makes sense in the case where I have put a whole
?????? workstation on the user's desk. I believe that as we migrate more and
?????? more users from the time-sharing environment to the desktop environment
>>>    we need to help customers re-address what they are trying to accomplish
>>>    with "captive" accounts. One good question to ask is:
>>>    
>>>    "If I place an 80386 based PC on your user's desk, how would you lock
>>>    them into a 'captive' environment and prevent them from running
>>>    whatever PC based piece of software they chose to bring to work?"
>>>    
>>>    I believe that usual answer is probably "we don't, it is a different
?????? situation". We need to help customers see that a DECwindows environment
?????? is also a different situation.


Speaking as the PC DECwindows Product Manager, I find this view somewhat 
"interesting", though sometimes very frustrating.  To ME, DECwindows (and
X-11, MOTIF, etc.) is NOT just a GUI to a single-user desktop appliance.
To me, and to lots of potential users, one of the most attractive applications
of this technology is the ability to use a convenient, standard GUI to access
applications on one or more remote systems...simultaneously (even).  

Given THIS view, discussions of DECwindows and timesharing systems are NOT
mutually exclusive, as this reply seems to imply.  In fact, the noter in reply
.3 never did say whether the system being accessed was a workstation, was
a local system, was a single-user system, a timesharing system, a cluster,
or what...the noter simply stated a perceived customer need regarding this
user interface.

I haven't offered any technical solution to this problem, nor can I.  I only
wanted to point out that the SYSTEM usage model (timesharing or single-user)
has little to do with the user interface employed (GUI or CLI).

...and now, back to our regularly scheduled noting, already in progress.

John

                     <<< Note 2703.6 by SPCTRM::GORCZYCA >>>

> Given THIS view, discussions of DECwindows and timesharing systems are NOT
> mutually exclusive, as this reply seems to imply.  In fact, the noter in reply
> .3 never did say whether the system being accessed was a workstation, was
> a local system, was a single-user system, a timesharing system, a cluster,
> or what...the noter simply stated a perceived customer need regarding this
> user interface.

Not that it matters much, since John hit it on the head, but the system
I was talking about was a large, multi-cluster imstallation within the
U.S. Air Force.  They have diskless workstations acting as SET HOST 
machines, and are beginning to phase in DECwindows applications as well.

The management problem is that users, being users, if given the oportunity 
will create clutter in their directories, will attempt to push the security 
envelope, and will make mistakes.

A 386 PC mistake is local to the machine.  A standalone workstation mistake
running a local application is local to the machine.  A mistake in a
distributed environment can be distributed, and can affect other users
as well.  In this particular case, a 24-hour-a-day command and control
system could suffer interruptions or tempory shutdowns, due to basically
simple resource control issues.

Even localizing resource problems to the workstation resource is not
sufficient, when round the clock access is a requirement, and the resource
is shared among several shifts of workers.

If you trust your applications ( a big "if"), then you must focus on 
the potential for user-based problems, either accidental or intentional.

Given that the GUI enviornment is at its best when the user is least
restricted, and that the complexity of restricting it is such that
guarantees cannot be made, I understand why we make no promises.

BUT, I still firmly believe that the poor system manager in the field,
being presented with the challenge of managing workstation technology needs
some documented guidelines.  Specifically, what the pitfalls are, what can
be done to limit, if not stop access, and so forth.

I am not whining, nor even complaining.  I am wishing.  I am remembering
the sense of awe I felt back in 1983 when the field service guy left, and
I had a bare VAX 780 with VMS, and it was up to me to set up my users'
environment.  No one at my company knew more than I did about VMS, and I
had had 1 week of system manager school.  I learned a lot of hard lessons
over the next year, and made some bad decisions about resource allocation
and security that caused problems for longer than that.

New system managers today, in the same position, only with clusters,
networks, workstations, hackers, and more concern with corporate security,
need more support than I had, and while exploring the power of the new
technology need help in finding ways to monitor and limit as well.

This soapbox is now free for the next guy.  Sorry for the length.
JPB

Given the lack of time and resources and the lack of understanding of what
captive means, I think that it made sense not to implement anything.

However, after more than a year of field experience, it doesn't seem that there
is a clear definition of what is needed, only the statement that captive is
required.

In the absence of more information of what customers want, I suggest that
captive be defined as

	1. the session manager does not bring up its window, nor does it
	   activate any applications from the startup list.
	2. it invokes DECW$LOGIN if one exists, if not, it exits
	3. when DECW$LOGIN exists, then the session manager exits

This means that the system manager can either create a terminal window with
a captive command procedure (DECW$LOGIN would still not be an interactive
session), but why a workstation would be needed to run a DCL session I don't
understand.

Or the system manager could run a DECwindows application.

If this is along the lines of what is required, then I suggest writing it up
as a QAR suggestion (emphasizing the customer desire for this feature).
If this is a major CSC support problem or is resulting on lost sales, then
this cost needs to be quantified and given to DECwindows product management.

However, this will not get a quick solution because code has been frozen and
testing is in progress for most of the software shippig this calendar year.
To make changes at this point would compromise the product quality and that
is something that everyone agrees (I hope) needs to increase, not merely
remain the same or worse, decrease.

    
    I don't think that .8 is useful.  What I would think would be better
    is a way to restrict the session manager window depending on something
    in the users UAF.  If say the session manager "customize" menu item can
    be disabled (or each menu item in the customize window disabled) aas
    well as perhaps also allowing the diabling of the "Pause" feature -
    then reasonable "captive"-type accounts can be implemented.  The system
    manager sets up the application menu and then disables the users
    ability to change it as well as the ability to pause the workstation.
    
    For a "single application" situation, you restrict the application to
    just the one you want and autostart it.
    
    A little more "workstationish" and a little more useful.
    

    How about a (supported) tool for allowing the system manager to set
    session manager's resource file, which would then enable/disable the
    various session manager menu options.  This could be combined with a
    mechanism to force session manager to read a system resource file, not
    writeable by the user.
    
    Barry

    Thanks for the replies. Sorry for the delay in getting back - I 've had
    a week off.
    
    .3 sums up what is wanted in the captive account fairly neatly.  The
    reason the customer wants it is that his environment consists of mainly
    VT300's and users are restricted to running only those applications
    that they need to do their jobs. he is bringing in more workstations
    and these are shared, so until there is a VS3100 per user he needs to
    provide the same type of environment.  I believe that this should be
    done by giving the system manager a means of customising the Session
    Manager.
    
    	dave

G'day,
	Having read all this I'll just ask a simple questionor two.

	1) Is it possible to disable the customise option on the SM?

	2) If so, how?

thanks,
Andrew

    Unless it was put forward as a requirement for DW v3, don't expect to
    see it.
    
    
    /andy/

Re .0,.3

Adding another twist that hasn't seemed to be addressed here, but seems
relevant.  What about the VT1XXX type terminal?  Clearly, not the power
orcomplexity of a standalone system, but it still leaves the problem
of dealing (in a correctly configured environment) with a "dumb" terminal
with access to DECWindows.  I, too have a customer that wants to captivate
the user base into AI1 (and somehow tie all of the applications into its
menu system, including the PATRAN type stuff).  Clear as mud.  The contract
requirements state that the users must (should) be flagged at least as
restricted.  The tone of this note seems to be that this is difficult if
not just plain old S.O.L.

Bob Blunt
EIS/SEGD

There's definitely substantial reason for having the DECwindows equivalent of a
captive account, in my opinion. I have run up against this requirement myself-
in doing overnight DTM DECwindows testing. I must leave a workstation logged in,
but have no desire to allow said workstation to do squat apart from serving as
a "display station" for the application, which runs on a remote host.

I would think the most straightforward appraoch would be for the DECwindows
folks to offer a separate UID, which excludes the Customize option entirely, or
at least vastly limits it. Sigh- not at the moment, I guess.

Since I couldn't wait for DECwindows to include this option, I "rolled my own."
It's a real hack, but serves the purpose for at least my own needs.

Copy DECW$SESSION.DAT to the user's home directory, and eliminate from it all
applications which the user isn't supposed to access. Remove the user's write
privilege to the user's home directory. Lastly, associate the user with an
account, creating a dummy one if need be, and set the user's account job limit
to 1. (I *told* you it was a hack!) This eliminates any ability to create
additional DECterms by adding a new menu application and definition.

The result is a DECwindows user which is quite lame indeed. I'm not sure if
anyone else has a use for this technique, but there it is. By the way, if anyone
sees a hole in it, please let me know.

RE: .16

  You could always just add

*CustomizePulldown.sensitive: False

  to your xdefaults file.  This will 'grey' out the customize pulldown option
preventing the user from using it.

					-=> Jim <=-

That's perfect- I just didn't know about the resource.

On the same general topic, are there any plans to document the resources for
all "standard" DECwindows clients? I'm a contract employee, and believe me, the
"public" documentation available is not sufficient. In this regard, DECwindows
really represents "value lost" in comparison to MIT X.

Thanks again for the tip.

I recently spent some time investigating the pseudo-captive (I'm calling it
"restricted") account support that we're offering in DECwindows V3.  Here's
what I came up with.

				-- Bob

	Restricted Account Support In The DECwindows V3 Session Manager

DECwindows does not support true captive accounts, i.e. accounts with the
CAPTIVE flag in the UAF record.  However, the DECwindows V3 Session Manager
does provide hooks for setting up restricted DECwindows accounts.  If a user
logs in to a resticted DECwindows account through the DECwindows login box
he or she will run in a restricted environment set up by the system
manager.  Since the CAPTIVE flag is not set, however, the user can still
log in to the account on a terminal or with SET HOST and reach the DCL
prompt.

There are at least three ways to set up a restricted DECwindows account:

	1. Define DECW$SESSIONCOM so that when the user logs in, LOGINOUT
	   will run a command file other than DECW$STARTSM.COM.  This
	   bypasses the Session Manager altogether.

	2. Define DECW$SESSIONMAIN so that DECW$STARTSM.COM will run
	   the specified command file instead of running VUE$MASTER.EXE.
	   The Session Manager will read resource files and execute login
	   command files, but there will be no system menu bar.  With this
	   method it is also necessary to ensure that the End Session command
	   will not prompt for confirmation.

	3. Start the Session Manager normally, but customize its menus to
	   remove any command that would let the user start an undesired
	   application.  With this method there will be a system menu bar,
	   which will let the user enter whatever customization dialog boxes
	   the system manager doesn't disable.

To illustrate these three methods of setting up restricted DECwindows
accounts, each of the following examples will set up an account,
[BOOK_READER], that can only run the Book Reader application.

Method 1: Defining DECW$SESSIONCOM

DECW$SESSIONCOM is a logical name that determines the command file that is
run to start the session manager.  The default command file is
SYS$MANAGER: DECW$STARTSM.COM.  You can run a private command file instead
by defining the symbol DECW$SESSIONCOM in SYS$MANAGER:
DECW$PRIVATE_APPS_SETUP.COM.  If this symbol is defined, SYS$MANAGER:
DECW$STARTAPPS.COM will define the DECW$SESSIONCOM logical name in the
system logical name table.

Since DECW$SESSIONCOM is defined in the system logical name table it
affects session manager startup for every username.  Your private command
file will have to check the username that it is running under, and run
the normal DECW$STARTSM.COM procedure for non-restricted accounts.

Note that with this method, startup command procedures normally started
from DECW$STARTSM.COM are not run: SYLOGIN.COM, LOGIN.COM,
DECW$SYLOGIN.COM and DECW$LOGIN.COM.

	Step 1.  Create the command procedure.

	$ CREATE SYS$MANAGER:PRIVATE_SESSIONCOM.COM
	$!
	$! Check to see if this is the restricted DECwindows account.  If it
	$! isn't, run the normal procedure to start the session manager.
	$!
	$ username = F$USER()
	$ IF F$LOCATE( "BOOK_READER", username ) .NE. F$LENGTH( username ) -
		THEN GOTO restricted
	$!
	$! Normal, non-restricted DECwindows login
	$!
	$ @SYS$MANAGER:DECW$STARTSM
	$ EXIT
	$!
	$! Restricted DECwindows login.  Run the Book Reader and then exit.
	$!
	$ restricted:
	$!
	$ RUN SYS$SYSTEM:DECW$WSINIT
	$ display = F$LOGICAL("decw$display")
	$ RUN/DETACHED/OUTPUT='display' SYS$SYSTEM:DECW$MWM
	$ RUN SYS$SYSTEM:DECW$BOOKREADER
	$ endsession := $DECW$ENDSESSION
	$ endsession -noprompt
	$ STOP/ID=0
	^Z

	DECW$WSINIT reads in resource files and changes the input cursor
	from the watch cursor to the normal arrow cursor.  DECW$MWM is the
	Motif window manager.  Its SYS$OUTPUT needs to be set to the
	translation of DECW$DISPLAY so that DECW$DISPLAY will be defined
	correctly in the detached process.  DECW$ENDSESSION resets the
	server and brings up a new login box.  The -noprompt qualifier
	prevents DECW$ENDSESSION from asking the user whether to really
	end the session (if the user cancelled the end session the
	workstation would be unusable, since Book Reader would have exited
	and there would be no login box).  STOP/ID=0 logs out the process
	without writing an error message to SYS$OUTPUT.

	Step 2.  Define the DECW$SESSIONCOM symbol in
		 DECW$PRIVATE_APPS_SETUP.COM

	If SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM doesn't already exist,
	create it from the template file:

	$ COPY SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.TEMPLATE -
	       SYS$COMMON:[SYSMGR]DECW$PRIVATE_APPS_SETUP.COM

	Next, edit this cmmand procedure to define DECW$SESSIONCOM

	$ DECW$SESSIONCOM :== SYS$MANAGER:PRIVATE_SESSIONCOM.COM

	Step 3.  Restart DECwindows

	This step is necessary so that the changes to
	DECW$PRIVATE_APPS_SETUP.COM will take effect.

	$ @SYS$MANAGER:DECW$STARTUP RESTART

	Step 4.  Log in to the restricted account on a DECwindows system.

	After entering the username and password of the restricted account,
	the Book Reader application will start up and there will not be a
	system menu bar.  When the user exits from Book Reader, the
	PRIVATE_SESSIONCOM.COM procedure will do an End Session
	and then log out.  The End Session command puts up a DECwindows
	login box.

Method 2:  Defining DECW$SESSIONMAIN

When DECW$STARTSM.COM is started (i.e. if DECW$SESSIONCOM has its default
value), it starts the session manager by executing the DCL command stored
in the logical name DECW$SESSIONMAIN.  To define this logical name, edit
SYS$MANAGER:PRIVATE_APPS_SETUP.COM so that it defines the symbol
DECW$SESSIONMAIN to be the DCL command to execute.

This is similar to method 1 except that DECW$STARTSM.COM will execute the
SYLOGIN.COM, LOGIN.COM, DECW$SYLOGIN.COM and DECW$LOGIN.COM command
procedures.  Also, DECW$STARTSM.COM will execute DECW$WSINIT.COM, so there
is no need for the private commadn procedure to do this.

Normally DECW$STARTSM.COM will execute DECW$ENDSESSION.EXE and STOP/ID=0
after the DECW$SESSIONMAIN command has exited, but in our case it is
important to make sure End Session doesn't prompt for confirmation (because
if the user cancels the End Session the workstation will be unusable).
For this reason, the private command procedure for this example will
explicitly run DECW$ENDSESSION with the -noprompt switch.

	Step 1.  Create the command procedure.

	$ CREATE SYS$MANAGER:PRIVATE_SESSIONMAIN.COM
	$!
	$! Check to see if this is the restricted DECwindows account.  If it
	$! isn't, run the normal procedure to start the session manager.
	$!
	$ username = F$USER()
	$ IF F$LOCATE( "BOOK_READER", username ) .NE. F$LENGTH( username ) -
		THEN GOTO restricted
	$!
	$! Normal, non-restricted DECwindows login
	$!
	$ RUN SYS$SYSTEM:DECW$VUEMASTER
	$ EXIT
	$!
	$! Restricted DECwindows login.  Run the Book Reader and then exit.
	$!
	$ restricted:
	$!
	$ display = F$LOGICAL("decw$display")
	$ RUN/DETACHED/OUTPUT='display' SYS$SYSTEM:DECW$MWM
	$ RUN SYS$SYSTEM:DECW$BOOKREADER
	$ endsession := $DECW$ENDSESSION
	$ endsession -noprompt
	$ STOP/ID=0
	^Z

	DECW$MWM is the Motif window manager.  Its SYS$OUTPUT needs to be
	set to the translation of DECW$DISPLAY so that DECW$DISPLAY will
	be defined correctly in the detached process.  DECW$ENDSESSION
	resets the server and brings up a new login box.  The -noprompt
	qualifier prevents DECW$ENDSESSION from asking the user whether to
	really end the session (if the user cancelled the end session the
	workstation would be unusable, since Book Reader would have exited
	and there would be no login box).  STOP/ID=0 logs out the process
	without writing an error message to SYS$OUTPUT.

	Step 2.  Define the DECW$SESSIONMAIN symbol in
		 DECW$PRIVATE_APPS_SETUP.COM

	If SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM doesn't already exist,
	create it from the template file:

	$ COPY SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.TEMPLATE -
	       SYS$COMMON:[SYSMGR]DECW$PRIVATE_APPS_SETUP.COM

	Next, edit this command procedure to define DECW$SESSIONMAIN. Note
	that the symbol has to be defined as a DCL command, unlike
	DECW$SESSIONCOM which is defined as the name of a command
	procedure.

	$ DECW$SESSIONMAIN :== @SYS$MANAGER:PRIVATE_SESSIONMAIN.COM

	Step 3.  Restart DECwindows

	This step is necessary so that the changes to
	DECW$PRIVATE_APPS_SETUP.COM will take effect.

	$ @SYS$MANAGER:DECW$STARTUP RESTART

	Step 4.  Log in to the restricted account on a DECwindows system.

	After entering the username and password of the restricted account,
	the Book Reader application will start up and there will not be a
	system menu bar.  When the user exits from Book Reader, the
	PRIVATE_SESSIONMAIN.COM procedure will do an End Session
	and then log out.  The End Session command puts up a DECwindows
	login box.

Method 3.  Customizing the Session Manager

In this method the Session Manager is started normally, but you customize
its menus to remove prevent the user from starting any applications that
are not auto-started.  You can choose which customization menus the user
has access to.

	Step 1. Log in to the restricted account on a DECwindows system

	After entering the username and password of the restricted account,
	the Session Manager will start up.

	Step 2. Auto-start the application(s) that the user will have
		access to

	Bring up the Automatic Startup dialog box from the Session
	Manager's Options menu.  Remove any undesired applications, such
	as FileView, from the auto-start list by clicking on the name of
	the application and then clicking on Remove.  Don't remove Window
	Manager or Session Events from the auto-start list.  Then add
	Bookreader (for this example) to the list by clicking on the word
	Bookreader in the list of applications.  Click on OK to exit the
	dialog box and save your auto-start settings.

	Step 3. Remove Applications from the system menu bar

	Bring up the Menu Bar dialog box from the Options menu.  Remove
	Applications from the menu bar by clicking on the word Applications
	and then clicking on Remove.  Click on OK to exit the dialog box.

	Step 4. Save your menu bar settings

	Select the Save Menu Bar... command in the Options menu.

	Step 5. Remove undesired items from the Options menu

	Bring up the Menus dialog box from the Options menu.  Click on
	the word Options in the Menu Names list box.  Then remove the
	following items from the menu by clicking on the name of the item
	in the Items in Menu list box and then clicking on the Remove
	button: Automatic Startup..., Menus..., Menu Bar..., Save Menu
	Bar..., and Restore Default Menu Bar....  To make the menu look
	better you should also remove the separator at the bottom of the
	menu (indicated with a row of dots).  You should also remove any
	other menu items that you don't want users to have access to in
	the restricted account, such as Security.

	After removing all unwanted menu items, click on OK to exit the
	dialog box and save your menu settings.

	Step 6. End the session

	Selecting End Session from the Session menu will log you out of the
	restricted account and bring up the DECwindows login box.

	Step 7. Log back in to the restricted account

	To test your changes, log in to the restricted account from the
	DECwindows login box.  The Bookreader and the Session Manager
	should start up by default, and you should not be able to start
	amy other application.  To log out, use the End Session command.
	Note that with this method it does no harm for the user to cancel
	the End Session command, since the session manager will still be
	running.

If you decide later to make the account unrestricted again, or if you want
to make changes in a dialog box that you have removed from the system menu
bar, you will have to delete or rename the file VUE$SMPROFILE.VUE$DAT in
the restricted account's SYS$LOGIN directory.

Re: .17

You mention a resource I didn't know about.

There must be loads more that I and other people don't know of. 

Which documentation has a list of all the resource avaialble in Motif and the
values that can be associated to them?

Thanks in advance,

Simon. (Not a MOTIF expert...)

Hi- the resource answer to my note referred, I thought, to a DECwindows
resource, not a Motif resource. The latter are well documented in the OSF's
Reference series, I think- I'm not sure which manual contains the resource
specifications. (The DECwindows resources are the ones that still seem to be
somewhat shrouded in mystery...)

    The Motif Window Manager Resource specifications are in part II of the
    OSF Programmers Guide.