Conference bulova::decw_jan-89_to_nov-90

	I create the logical in a command file called by LOGIN.COM and
	DECW$LOGIN.COM.  Unfortunately, due to a bug, DECterm doesn't
	recognize the logical.

							mike

Re .0,.1
    
>   ... DECterm doesn't recognize the logical. 
    
    That's still more than I'm getting ... I can't even get the &'%$&
    session manager to recognise the logical (ie., the DECW$SM_COLOR.DAT
    and _GENERAL.DAT files still clutter up my login directory). 
    
    At what point does DECW reference the logical name ? I'm defining
    it in my LOGIN.COM - is that too late ? Should later operations
    reference the current translation ? They don't appear to ...
    Does it have to be in a specific table (currently loading into JOB)
    or at an elevated mode ?
    
    Grateful for any assistance,
    Frank

Any clients which are started as spawned subprocesses of your session manager
process will recognize a process, job or group wide definition of
DECW$USER_DEFAULTS set in your DECW$LOGIN.COM (I would not recommend using group
unless you have only one account per group).  Any clients running from or as
spawned subprocesses of a DECterm login will recognize a process, job or group
wide definition set in LOGIN.COM.  If DEC$LOGIN.COM comes before LOGIN.COM
during a normal session startup.  Keep this in mind when doing group wide
definitions.  In general, I would recommend using job logicals as these will
effect subprocesses which do not have a CLI (ie: RUN/PROC FOO).

The DECterm controller process, the window manager and the session manager
do not respond too these logical definitions (except a group wide definition
which might have been hanging around from before).  That is because they are
detached processes and make no attempt to invoke LOGIN.COM or DECW$LOGIN.COM
within their job (for various reliability reasons).

If you redefine system wide (or group wide during systartup_v5.com) the
value for DECW$USER_DEFAULTS tyen you can move all .DAT files.  Otherwise,
*.DECTERM, DECW$SM_*.DAT and DECW$XDEFAULTS.DAT must be in SYS$LOGIN.

My suggested long term solution would be to allow specification of an alternate
location for DECW$USER_DEFAULTS and DECW$LOGIN.COM in SYSUAF.DAT as can be
done with LOGIN.COM.  But that is another issue altogether.

Dick

    > If you redefine system wide (or group wide during systartup_v5.com) the
    > value for DECW$USER_DEFAULTS tyen you can move all .DAT files.  Otherwise,
    > *.DECTERM, DECW$SM_*.DAT and DECW$XDEFAULTS.DAT must be in SYS$LOGIN.
    
    I tried both these (group and system) and in neither case were my
    defaults files found when I quit and restarted my session.
    
    I sure wish it would work...

If the logical is defined GROUP or SYSTEM in SYSTARTUP_V5.COM that should work,
unless they have done something like referenced a specific logical name table.
If that is the case, then you might try the decw$logical_names table.

Again, this should be done in SYSTARTUP_V5.COM and then not touched in
DECW$LOGIN.COM.

Dick

How about a related topic to the DECW$USER_DEFAULTS issue?

I understand that the resource list is obtained from a hierarchy of files.
The way it has been explained to me is that the resources are destructively
merged in the following order:

1. Application class name in DECW$SYSTEM_DEFAULTS. For example, a file
   for clock is named DECW$CLOCK.DAT.

2. Application class name in DECW$USER_DEFAULTS. Same name as above.

3. SYS$LOGIN:DECW$XDEFAULTS.DAT

4. Resource file pointed to by the logical DECW$ENVIRONMENT OR a file
   in SYS$LOGIN:DECW$XDEFAULTS-host.DAT, where host is the node where the
   client is being executed.

I know 1-3 are correct, but I cannot seem to get 4 to work.  Should the
logical go in DECW$LOGIN.COM? Is there a particular table it should go in?
I tried just the DECW$XDEFAULTS-host.DAT also and could not get it to work.

Any ideas what I might be doing wrong?

David

An examination of the relevant code leads me to conclude that the
DECW$Environment logical has not yet been implemented for VMS.

    Does this mean that DECW$XDEFAULTS-hostname.DAT is also not
    implemented or is it just the DECW$ENVIRONMENT logical?
    
    Thanks for the info,
    
    David
    

In the section of code which I assume should handle this, the ULTRIX thread
creates a filename of the mentioned type and returns success. The VMS thread
returns false. My conclusion is that there is a location in code where this 
can (will?) be implemented, but there is nothing there yet.

    Thanks!
    

    
    Ok, lets try this again...  perhaps I'm missing something here.
    
    If I set DECW$USER_DEFAULTS in SYSTARTUP_V5.COM then everyone who uses
    my workstation will have find his/her defaults in the same directory,
    in fact, there will only be one communal copy of "user" defaults.  This
    may be  an incorrect interpretation on my part, but I really can't see
    how useful this could be.  What one really wants is the ability to move
    all his/her defaults out of SYS$LOGIN to some reasonable place in
    his/her personal file hierarchy.
    
    If I set DECW$USER_DEFAULTS in my DECW$LOGIN.COM then it doesn't effect
    the session manager because the session manager is already running.  It
    will, however, effect all other processes from then on.  Lastly, if I
    set it in my LOGIN.COM it will then effect only those things run from
    that point on.
    
    Can someone provide a definitive analysis of what the effects would be
    if it were set in each place and how setting it in the
    DECW$LOGICAL_NAMES or the system/process/job tables would effect this
    translation?  I.e., do DECwindows programs check the DECW$LOGICAL_NAMES
    table first?
    
    Someone suggested a new field in SYSUAF.DAT to allow the moving of
    DECwindows data files (the same way login.com can be moved).  This
    seems reasonable but could take forever to get implemented.  A good
    interim solution I would think would be to have the session manager
    look in some username parameterized subdirectory of a globally defined
    user defaults area (i.e., SYS$COMMON:[DECW$DEFAULTS.USER.TDELLAFERA])
    or allow there to be a single redirect file that a user can place
    in SYS$LOGIN that contains the name of the directory for all DECwindows
    defaults.
    
    						Still looking for a better
    						defaults mouse trap,
    						Tony...
    

Re: .-1

Or... Some way to have a command file executed between the time
decw$loginout validates the username/password and the time the
session manager is started.  This would also allow (I think) one to
specify his own window manager on a per-user basis...

    What about defaults files used by clients running on remote,
    non-display nodes?
    
    I run Notes on a big VAX with which my VS2000 is MIVC'd. The logical
    DECW$USER_DEFAULTS on the big VAX points to my SYS$LOGIN. I want to
    create a private copy of NOTES$DEFAULTS.DAT. I assume if I put it in my
    SYS$LOGIN directory it will be found, but when is it read? Every time
    the remote client starts up? 
    
    If the defaults file is read when the client runs, then I should be
    able to redefine DECW$USER_DEFAULTS in my LOGIN.COM on that node. I run
    the remote client with RUN/DETACH SYS$SYSTEM:LOGINOUT, so my LOGIN.COM
    should be executed in the context of the client's process, true? And if
    the client is Notes, and it's looking for NOTES$DEFAULTS.DAT in
    DECW$USER_DEFAULTS: before DECW$SYSTEM_DEFAULTS:, then it should all
    come together, true?

    RE: .11, .12

    How about modifying SYS$MANAGER:DECW$STARTSM.COM?  I haven't tried it,
    but this might be a way to answer both the "where are my resource
    files" and "what is my window manager" (try redefining DECW$WINMGREXE?)
    questions.  I think/hope STARTSM runs in the context of the user who
    has logged in.

    Of course, the next DECwindows/VMS update that comes along may clobber
    DECW$STARTSM :-(

    Just a thought.  I'll have to try this myself the next time I get on a
    workstation... 

    Mike Endsley
    SWS @ STO