Conference bulova::decw_jan-89_to_nov-90

    Dunno about your problem, but try the memory management stuff detailed
    a few topics back for improving performance in a constrained memory
    environment.
    
    
    /andy/

I'm in an environment where I have / need access to many different systems. In
the past, I created customized Fileview menu options which allowed me to easily
start a Fileview on a remote system. From that I could easily manipulate files,
start applications, create detached Processes with DECterms, etc.

I essentially did this by running VUE$MASTER.EXE with the display pointed back
to my workstation. I could do what ever I needed, and when I quit from the
Fileview menu on that system, I was essentially just logging out.

Now with the current V3, I can no longer do this, as Vue$master is really a 
session manager, and choosing Quit from the session manager will force a server
reset, blowing away everything else I'm doing.

I have therefore entered a QAR to request a method to be able to continue my
work as before. What I need is a VUE$SLAVE.EXE which just gives me plain old
Fileview, without the session manager quit/reset problem.

I'm hoping enough others make use of Fileview in this fashion that it will be
worth the effort of Dev. to find a solution.

RE: .0


If I were you, with a 6MB VS2000 system, I would install EWS (see 
HELIX::EWS) and run the sytem as an X window Terminal.  


-bill

re .2

$define decw$vuenoreset 1
will disable the end session reset of the server.  to kill it off,
why not just use the close button in the window menu.

ps, there's also $define decw$vuenoautostart 1 to not autostart any
of the clients.  Both of these can be used as command line switches.
They are both undocumented now, I don't know if they will be in the
future.

Jackie

    
    RE .3
    
    I was running EWS when I was using DECwindows v2 but when I upgraded to
    v3 I wouldn't come up with the login box.  I eventually gave up on it
    and that is why we are having this discussion.  Are you running v3 with
    EWS?  If so, did you have to change anything?
    
    I even reinstalled EWS but it still didn't work.  If I find the time, 
    I will probably try to get it up and running again if I don't find a
    solution to this problem.
    
    Dan

If there are `command line options' for FileView, they are set to the wrong
defaults.  I have been recommending that FileView be used in the manner Bob
Bowman suggests in .2 for years; too many people will be adversely affected
by the current operation.

Note that instructions for running FileView in this manner are contained in
VMS DECwindows User's Guide, Chapter 9 - Running Applications Across the Network,
Section 3 - Running Applications from a DCL Command Line.

re: .4

I have tried both DECW$VUENOAUTOSTART and DECW$VUENORESET and I can only get
DECW$VUENOAUTOSTART to have any effect. I login, choose the DECTerm option from
the Applications menu, and in the resulting decterm I type:

$define decw$vuenoreset 1
$define decw$vuenoautostart 1
$run sys$system:vue$master


This does indeed start a second "Fileview Session" and none of the Autostart
applications startup automatically. So far, so good. I then see if the reset
has been disabled:

I first try the suggestion for using the "Close" option on the window frame 
menu. This option causes no resulting action whatsoever. I then try the
"End Session" item from the Session Menu. This causes a dialog box to ask me
if I really want to end the session. Confirming Ok on this immediately causes
a server reset, and all applications are gone! I have not yet tried these
as command line options. (I assume one needs to do the following:???

$vue$master=="$vue$master"
$vue$master -noreset -noautostart

Is this correct?

I agree with .6... this will cause no end of headaches for customers (and hence
customer support!) Please make this work, and make the default actions be
noreset and noautostart. The non-default actions can be explicitly requested
during the login sequence, where they are usually desired.

re .6  
Yes, I agree too, it's on the list of things to do, hopefully it will get done.

re .7

Ok, try this:  Go into the Menus... dialog in the session manager.  Is the
verb quit there?  (I don't remember if it's there by default).  If not add
it to the list. Add it to your Session Menu.  If it isn't already defined, 
define it to be "=VUEexitCallback".  

re .5 There are people successfully running EWS and V3 in our cluster.  I
don't know if anything had to be changed.  Mike Foley, are you reading this?  
Do you know?

Jackie Ferguson

RE: .8

Thanks. Adding Quit to the Session Menu was easy. Quit indeed causes the session
to disappear, without a server reset. This appears to be independent of the
logical mentioned earlier (DECW$VUENORESET). 

I still think the defaults should be NOAUTOSTART, and NORESET with Quit in the
session menu. The defaults should be geared to not letting the user easily get 
into trouble.

Thanks.

Bear in mind that the "default" is to run locally as the session manager, and
in this case, you would want autostart and reset working.  How about if we
could make each of these a resource?  You may want to submit a QAR to formally 
suggest your ideas.

Jackie

FileView running as the session manager is a special case and while it might
be the most common case, starting up a FileView on screen 1 or starting FileView
on another system is the default case, if for no other reasons than this is
what a lot of people have in their command procedures.  If you think that this
is an optional work item, then I hope you are going to be willing to work in
the CSCs answering the phone explaining this particular change in behavior.

    RE: .10
    
    I'll update the open QAR I have on this issue. (I think it is 459...)
    
    Resources would be fine as long as the *default* when a customer says
    
    $run sys$system:vue$master
    
    is to not autostart and to not reset. Surely we can make our supplied
    command procedures do whatever non-standard setup is necessary to
    get a login session manager started correctly, leaving the default case
    to what most customers expect *after* they are logged in.

    Not having touched DW V3, I infer from the previous notes the
    following WAGs.
    
    It sounds as if someone noticed they were running off Fileview all the
    time and didn't use Session Manager much, and concluded that the two
    could be combined.  Personally I haven't gotten to the point (yet) of
    autostarting Fileview and running off it, nor to start Fileview from
    the big node in the cluster and display to my workstation.  But it's
    tempting for me to speculate that whoever decided that Fileview could
    double as Session Manager, that they autostart a local Fileview and
    they don't run in more than one environment like some of us do. 
    
    However, observe that when your Fileview is not your only Fileview, you
    can't make it behave like a Session Manager; at least don't assume it's
    the only Session Manager.
    
    I don't know if the answer should be that the local Fileview is the
    Session Manager, but all remote Fileviews should have the Session
    Manager functions disabled.
    
    (If I'm totally offbase, at least this is a view of a naive user.)
    
    --Simon
    

re .11: 

>If you think that this is an optional work item, then I hope you are going to
>be willing to work in the CSCs answering the phone explaining this particular 
>change in behavior.

I said in .8 that I agree with you.  Where did I say that I decided that this 
was optional?  Where did I say that I was responsible for making this decision,
or for even doing the work?  This is not the forum for making requests for 
features, take it up with the product manager or project leader if you think 
it is important.  There is a tight schedule, and not enough people to do all 
the work.  Some things that fall off the list are not falling because we don't 
think they are unimportant, just that there are other things that are more 
important.  If you get in touch with the people who make these decisions, maybe
you can convince them to change their priorities.  

re .12:

I just read your QAR, there probably isn't a need to update it unless you
want to change the priority (currently listed as medium).  I was suggesting
that others who didn't like the current behavior also enter QARs or make
their wishes known in other places than here.

Jackie Ferguson
(FileView devo, not the project leader)

.13
>    It sounds as if someone noticed they were running off Fileview all the
>    time and didn't use Session Manager much, and concluded that the two
>    could be combined.
...
>    tempting for me to speculate that whoever decided that Fileview could
>    double as Session Manager, that they autostart a local Fileview and
>    they don't run in more than one environment like some of us do. 

This is not the case, Simon.  There had been many requests throughout version
1 and 2 of DECwindows to add functionality to the session manager that was
currently in FileView.  Starting applications was one which was added to the
session manager hastily in version 2 and which did not completely do the
job.  For instance, the applications could only be run detached, and there
was no way to see an error log.  It was also confusing that there were two
ways to start applications and that they were different, but many nontechnical
users didn't understand the differences.  The decision was made to start with
FileView as a base, since it had more of the functionality of the final 
environment than the Session Manager did.  

What you are seeing in V3 is not everything that had been planned.  It is not
the case that someone didn't want detached processes, for instance, and that's
why they haven't been added.  Ditto for remote applications.  If remote 
startup were there as was originally planned, then these discussions about
having to run vue$master on other nodes wouldn't be as much of a problem.

There will be more functionality in EFT than there is now.  What will be there
specifically, I don't know.  I just know that everyone on the project is working
hard to get as much done as possible.

Jackie

    Just to let you know (in case I haven't said it elsewhere), I *do* like
    the new features in the session manager. I now have a very easy, very
    customizable, method to login, and go for a cup of coffee while my 20+
    applications startup. How can I do this? I have added an automatic
    Pause Screen on the autostart menu, so almost immediately, my
    workstation is paused, meaning I'm free to be up and around and not
    worry about someone sitting in my cube and playing while I'm gone.
    (This also means I always have a pause window, so I also autostart
    XSETROOT to place a picture on the pause window...)
    
    In general, I feel *much* more in control. Thanks for the efforts in
    this area.