Conference kernel::csguk_systems

    
    Seeing as _most_ other diagnosis groups in the building have either
    their own hardware, or access to such hardware, it seems to me that
    the Systems group has, for a long time, not pushed hard enough to
    obtain the equipment that it supports.
    
    It must be very apparent to customers that we often talk to them 
    about systems that we've never seen. In some cases, this doesn't 
    matter too much, but with the changes in the area of field engineers,
    it will become more & more difficult to provide Telesupport or
    Diagnosis, without having the hardware available. This in turn could
    lead to customer dis-satisfaction and loss of contracts to third
    parties, because the _Digital-Advantage_ would no longer exist.
    
    There is, in this building, a considerable amount of hardware, 
    supposedly for troubleshooting purposes, but it is often so jealously
    guarded by its "owners" that other groups either don't know about it
    or cannot utilise it.
    
    Some sort of rationalisation is long overdue, and some overall control
    is necessary, but where the ability to do the job and provide the 
    required level of service to our customers is concerned, we cannot
    afford not to have this equipment available somewhere in the building.
    
    

Vax4000-50 upgrade for RYRGRS
Replace JENSEN in list with AlphaStation 400 model 4/233, same size box, new 
   product (faster :-)
Add storage array such as BA350 & HSD05, but preferably more modern equivalent, 
   for DUMPS disks.
Add DSSI interface for whichever Alpha system we choose to cluster with RYRGRS

	JT:

    
    	We have to first decide which products (h/w), operating systems
    	and applications we will support and then put in the resources
    	for those products. - if we have a business need for the kit
    	then there can be no excuses..
    
    	We will be the experts on AXP and VMS dump analysis, so me must
    	have systems available for troubleshooting purposes:
    		o an alpha box running vms that we can crash (but normally
    		  up)
    		o a fast vax that can serve the dumps disks
     		o add on hardware for building a small troubleshooting
    		  multi-architecture cluster
    
    	we will be the experts on AES multi-platform, so we need:
    		o an AES test system for vms
    		o an AES test system for osf
    	
    	we need another Alpha box that will be a general troubleshooting
    	node that has multiple boots:  vms, osf and nt.
    		o used to troubleshoot alpha boot problems / pal updates /
    		o used to boot osf to build up osf skills
    		o used to boot nt to build up nt skills
     
    	Traditionally our problem has been that we only supported large
    	vaxes.. as we diversify, there is a need for this kit.
    
    	Brian

>    	We will be the experts on AXP and VMS dump analysis, so me must
>    	have systems available for troubleshooting purposes:
>    		o an alpha box running vms that we can crash (but normally
>    		  up)
>    		o a fast vax that can serve the dumps disks
>     		o add on hardware for building a small troubleshooting
>    		  multi-architecture cluster

	An Alpha box. 
	A fast Vax (VAX4000-50 Upgrade to RYRGRS ??)
	Shared storage for DUMP files external to either node.
 
	This H/W should be used to build a mixed architecture cluster, 
	with both nodes having direct access to the shared disks (DSSI?) 
	These disks should primarily be used for DUMP analysis on either
	aarchitecture. 
	This cluster should be setup so that either node can be temporarily 
	disconnected and run standalone for trouble-shooting purposes.
	Each node should have a local system disk and a controller for 
	access to the shared storage bus. Each system disk should be built 
	with 2 roots, 1 with a private startup for standalone use, the other
	setup for normal cluster boot. The cluster common files, UAF etc, 
	should be on the shared storage disks.

	Agree with second Alpha node for multi-boot & config troubleshooting.

	I see as desireable the ability to support cross-architecture booting
	this means another Alpha node with a minimum of 2 internal disks, 
	1 for Alpha boot disk, the other for Vax boot disk.

	Summary of minimum needs as I see it.

	2 Alpha boxes. at least 1 with DSSI.
	1 fast Vax or 4000-50 upgrade for RYRGRS.
	1 DSSI storage box (BA350 with HSD05 or more modern equiv)
	Optionally a third Alpha box for a cross-arch bootserver.

	JT:
	

I agree with .1 that there is a load of stuff that we should be able to share.
Also from outside the building. However much stuff we buy there is always going
to be something we need that we dont' have. There should be a method of finding
what is available elsewhere that can be used, after all the kit
is all owned by the same company (in theory.) 

Re: ryrgrs, do we really a seperate system. I find it a pain having
dumps spread over 3 different places (comics,medler, ryrgrs). I would prefer
ryrgrs merged into medler or comics. As it got it own system disk it could
easily be take out if needed for standalone work.

Re: alpha systems we have haydes and fatslg for troubleshooting as well
as snooty in comics (if needed). I'm sure it would be handy to have some of the 
smaller alpha systems, but would access to one elsewhere in the company on an
as needed basis do?. Are there any little (1000,2000) axp systems @crescent 
that we can use (is there still an arc?). For the multiple booting thing could
haydes be set up so it could boot into medler (or use snooty if needs be - I 
don't know of any reason why it is needed in comics all the time??). 
	  
From a Sw point at least, We need to build up medler as a troubleshooting 
environment, ie existing/new? systems/equipment in the building
should be arranged so they can easily connect/boot  into medler nodes for 
trouble-shooting purposes - should be a
variety of system disks available for different versions of vms on the normal
medler nodes  AND on other systems that can connect to them (eg ryrgrs, haydes,
runner jlybly..). This should make it easier to set up different combinations 
of versions-hw eg for cluster/multiple-boot problems. 

The aes setups sound a good plan, there should be an acb system as well for
support (is it still vms group doing that?).


If the company wants to spend money should be on more bums on seats:
if so - we might have more time to work out how to use what we already have more
effectively. 

dg.


PS how easy do you think it would be to get a survey of all the kit in the
uk (say) AND an arrangement whereby anyone in dec can share kit when needed.
As I said above there is always going to be something that we need + haven't 
got whatever we buy.
(reminds me of when I was trying to find an smp 65/66 system to try reproduce
a decps problem  - and couldn't get one).