Conference 44.370::system_management

    
    the decwindows version hasn't proved too robust to date....keeps
    crashing !

I've been using it on the workstation and had no problems, perhaps its another 
case of a decwindows mismatch rather than LSE (see earlier note on notes problem
 which is now ok!).

Nigel

There are several bugs with lse v3.0 (see lse_bugs notes conference) which
are supposed to be fixed in V3.1. I crash it once a week or so but I managed to
crash the previous version of lse about as much.

Surely the increase in usability hence productivity justify the installation
of lse V3

Mark

I agree with the last statement Mark, other applications crash much more often,
and we still use those ( I support some of them! )

Any chance of an 'official' reply on this one?

Nigel

    The question is much wider then LSE; Now that we have so many
    workstations, we should be using them efficiently. 
    
    In my book, that means using the DW versions of all of VAXset, rather
    than just using 'em as multi-window VDU's. (even though they do improve
    efficiency even by using them like that!)
    
    There are a couple of points to consider; them major one is what impact
    is there by upgrading to VAXset V9 (or whatever the latest version
    is...) - Do we need to re-build or convert libraries?
    
    If the answer is no, then I reckon we can blast VAXset 9 everywhere, as
    there is no EASE impact.
    
    Even if the DW versions are not fully robust, is the VDU version
    robust?
    If it is, then we have a fallback that WS users can use, so again, I
    reckon we can blast V9 everywhere...
    If it does die on a WS, does it corrupt anything?
    
    The problem is I don't know the answers, I'm hardly there, and I'm on
    holiday soon....
    
    Try speaking to Jerry Thompson, he may be able to help, but he's out
    quite a lot too....
    
    Here's a radical alternative; speak to your manager, and get his OK to
    spend a few days on this - do the research, and find out *exactly* what
    the status is - install V9 on one of the boot nodes, and check it out.
    
    If it looks OK, and the conversions are either not needed, or are easy,
    then we can plan to get it onto the main clusters.
    
    FUTURS and CURRNT are both running VMS V5.3; PASTIT will be at the end
    of August, so we can install it everywhere.
    
    If you do decide to do this, please co-ordinate with either Jerry or
    Keith as one of them should be around...
    
    Peter.
    
    
    

    Would we need far higher quotas on the main clusters??
    
    
    Performance of the main clusters as it is is not startlingly
    brilliant.. Surely running Vaxset tools on them as batch jobs will degrade
    performence even more?? (less image activation, but more processes)
    
    David
    
    
    
    

I'll see what the boss fella says. I was using the DW version of VAXset 18 
months ago when I was part of SWAS/Uk local Engineering, so they're not exactly
fresh out development products, and we do sell them to customers.

Given the appropriate privs on the relevant machines I'll gladly do the the leg
work, after all the inability to use the workstation as a workstation rather
than a VT with 7 sessions frustrates me as much as the next deccie.

The boot node I'm on already has the DW LSE, no problems for me to date, however
I do have continuing problems with xlib errors, so while I'm at it I'll look
at those too. DW CMS is excellent too, similar interface as that used in DW 
notes.

Nigel

re .6

>   Performance of the main clusters as it is is not startlingly
>    brilliant.. Surely running Vaxset tools on them as batch jobs will degrade
>    performence even more?? (less image activation, but more processes)

Having seven vt lookalike windows running the vaxset suff would be just as 
inefficient.

ps. The main cluster performance seems ok to me.
  

Mark

    Let's try to avoid the rathole, but I undestood the performance ofthe
    three main clusters was OK... if I'm wrong, please let me know;
    it may be we need to do some preparatory work for a CPU upgrade or two.
    
    Of course, I hardly ever use the main clusters!!!
    
    Pleae use a new note if anyone wished to discuss the performance (or
    lack of) on the main clusters.
    
    Peter.

    Well...
    
    
    PASTIT has been up and down like er... no, I'm not allowed to say what
    I think of it...                                               
    
    the point I was trying to make was, if I were developing a program,
    I'd reserve it from CMS, work on it, test it, retest it,  and replace it.
    
    With a Terminal, I'd do that all from one session. 
    
    I doubt I'd do that with Decwindows.
    
    
    David

	I welcome your offer to install the software yourself Nigel.
But we should try out a pilot LAVC solution first rather than blatt the 
upgrades on every cluster... just in case there are implications we havn't 
realised yet.

	AlsoWe should use DFS more extensively than at present.
CMS + DFS work very well together. I think we could design a solution that would
reduce the compute loading on the main clusters, allow those who want the
latest tools the freedom to use them without affecting anyone else, and use
the power of the workstations more effectively both as interfaces and as compute
engines.

	I'll be in SBP this week, in G11/2.

LSE V3.0 is on futures so surely does not need further testing.

Mark

Jerry,  I like the idea but I'm not simply talking of accessing cms libraries.
Most of the workstation users need to access the various application environments
on the various clusters, and as such need logical names etc defining on their 
node to allow them to work. surely the simpler solution is installation of the
relevant products on the clusters after checking that they have no impact. If
my understanding of your suggestion is correct then there would be some 
considerable amount of initial setup required by yourselves to allow remote 
access via DFS to the application environments.

Nigel

	Yes you've understood me correctly. DFS *does* allow you to access 
applications environments on remote machines. Steve Draper and Glenn Addleton
have already demonstrated this during the development of CVPD. And yes there is
considerable setup effort involved. 

	But, having gone through the pain of setting it up, you get some
benefits, namely:

more freedom to install and use the tools you want to
later versions of operating system software (= better DECwindows interfaces)
less contention for compute time on the main clusters
greater use of the 3VUP power of the VS3100's when you need it

	If we install non-EASE versions of products on the clusters then
experience shows that at the *next* EASE upgrade there is a fair chance that
the wrong version of the product will reappear causing havoc while the kit is
relocated, reinstalled and maybe damaged files repaired. I know you've offered
to install the kits in this instance, but can you guarantee to keep tabs
on the effects of the next EASE upgrade on this and and all the other products
that might be installed in the next 6-12 months and beyond?

	Can we talk about this offline some more. I can't type fast enough.

I didn't realise that you'd done this before, my concerns about your suggestion
were based around this being something new - I'm all for it since you've
demonstated that it can be done. I'll pop down sometime soon.

thanks for your help and interest

Nigel

    Why not get everyone interested around a table, say Thursday at 10:00
    am, when we can try and sort this out?
    
    Could someone arrange a room, or we could use Steve Drapers old
    office?
    
    Peter.
    

	OK, I've booked the Intrepid room (F2-2a)from 10-12:00, Thursday 9th Aug.
Take this as an invitation to all ADGites with workstations, and anyone else
who could contribute to a discussion about distributed processing and
software development.

Please call me if you want to attend, the room I've booked is quite small!

	Hi Mob,

	I have a problem with LSE and DECWindows on CURRNT at the moment.

	I've set the display back to my workstation, but I get the following
	error when trying to use LSE

DAW> lse/inter=decw COP$DISK_DEV_UKO:[REF]CPS_UKO_INT_BEN_CHN_PRG.RPA;
%TPU-W-PARSEFAIL, error parsing LSE$DEFAULTS
-RMS-F-DEV, error in device name or inappropriate device type for operation
%TPU-W-PARSEFAIL, error parsing !AS
DAW>

	Anyone got any ideas ?

	Wob

Is this the first time you've tried it?

You seem to be getting a TPU error - did you convert your ini file for
the latest version of TPU last time round?

I'm back at SBP tomorrow morning - come and see me them if it's still
broke.

Cheers, Peter.

P.S. can CURRNT "see" your w/s OK, and are you certain the security is
set up right? You can get misleading messages if either are wrong!

>>Is this the first time you've tried it?

Yes

I searched the LSE conference last night, and it turns out that the following
logical needs to be defined:

$DEFINE LSE$DEFAULTS SYS$LIBRARY:LSE$DEFAULTS.DAT

Thanks Peter anyway !