[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference kernel::csguk_systems

Title:CSGUK_SYSTEMS
Notice:No restrictions on keyword creation
Moderator:KERNEL::ADAMS
Created:Wed Mar 01 1989
Last Modified:Thu Nov 28 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:242
Total number of notes:1855

174.0. "Taking SW calls/products" by COMICS::GLEDHILL () Sun Apr 24 1994 02:49

here are my thoughts on the systems group taking software calls/products.
I did once hear the suggestion that systems take some/all calls on
decps,vcs,aes,acb,infoserver 

Doesn't seem very efficient to take on products where
there are extensive skills in vms already. Also will build up vms skills better
by taking more mainstream calls, than products. Decps requires quite a lot of
vms experience, vcs and decps are quite high profile with customers so those
sort of calls can get quite hot. (managers like playing with decps). Aes may
be a better one as the aes skills in the group are good, but then a lot of the 
aes expertise got moved to vms recently.

Suggest.. (thanks dave)
Concentrate on system availability problems to start with, then system 
management calls. Get the call flow for all  availablity type problems routed 
to the systems que if not already. As well as crashes/hangs -> booting, startup 
problems, standalone backup etc. If want system mgt, a lot of the aes 'how to
do types' are good and can be worked on ooh. (I have checked with ops-support it
would be possible to get the vms aes calls routed to the systems queue at
certain times - it would not be feasable to get them to dynamically change it
depending on workload, the queue manager would have to re route them if too busy
or no skills. (Also the load could be split by assigning say a half an hour on 
each queue.)

One suggestion would be for the systems queue to take (some of) them after say 
15:00 as that is the highest availablity period. The calls once taken could 
be worked on during (any) slack periods during the evening/night shift. 

On the other hand having a vms hunt line might be more useful and would be
easier to control - more likely to get stitched with something you know nothing
about that way...



New products different story, as no existing skills anyway. Acb is one. To 
support it we will need to set it up, but need some harware (modems and
decservers) I suggest we set up on ryrgrs if Brian thinks it it worth doing
for the call volumes.

Infoserver, maybe in between, there are some skills in vms, but don't think 
there are any gurus on it (maybe I am wrong). Also because it involves storage
and comms might be a good one to go for??
T.RTitleUserPersonal
Name
DateLines
174.1KERNEL::ANTHONYSun Apr 24 1994 19:5523
    
    	My thoughts:
    
    	we should consider a combination approach:
    
    	o	take on ONE product to build up the product skills, but
    		more important is to get used to product support way of 
    	        working, ie we take on both the h/w and s/w support.
    		I'm open as to which product we select.
    
    	o	take on a proportion of mainstream vms calls.
    		- either live and/or aes logged.    live calls are easy, we
    		  have dedicated vms handsets that can be passed around the
    	          group. However we do it, we must have a means to
    		  selectively turn them off as call volumes vary.
    		  This could be from as little as 1/2 hr a day to start
    		  with
    
    	o	Get vms queue manager to route all system availability
    		problems to SYSTEMS queue, and get router update to say
   		 this
    
    	Brian
174.2KERNEL::ANTHONYFri May 13 1994 23:4712
    
    	well It's been some time since we visited this note.
    
    	If you read the CIG minutes, you will see an action on me
    	to look at integrating some VMS work into the group.
    
    	The minutes spell out my proposal...
    
    	can you let me have your views please... replies here will
    	do nicely!
    
    	Brian  
174.3KERNEL::ANTHONYSat May 14 1994 00:033
    
    	forgot to say CIG minutes are in 165.32
    <