Conference kernel::csguk_systems

    Feedback from CIG meeting of 28th Jan.
    
    Areas that have been raised as concerns and are to be followed up by
    me. 
    
    Problems with dialout
    With RDC modems being used less and less, they are not getting regular
    testing by use. We need assurances that they are working when we need
    them.
    Status. To be done.
    
    Call logging with IS and OPS Support. 
    There are problems with logging calls. Phones are constantly engaged, and 
    there is very little feedback once a call has been logged. There is no
    access to CHOPS to see the call status. A suggestion for overcoming
    both of these problems was to approach IS and OPS Support with the
    proposal that they use NICE. This would allow anyone in the building
    to log a call at any time, as well as track it's progress.
    Status. To be done.
    
      
    Stars / Tima
    Investigate ways of improving it.
    I will follow this up but I would like ideas on what to ask for. eg the
    ability to search for a quoted string.
    Status.  Waiting for you to mail me with your wishes.
    
    Backup systems needed.
    There is concern at the way systems with tools (NICE, TIMA, PARTS etc)
    are taken down without providing a backup system to work on. This never
    used to be the case. We need IS to consult with out of hours workers
    before planned cluster shutdowns.
    Status. To be done 
    
    Tima Tools long delays.
    Normally a tool should be recieved within a day.
    After requesting a tool on Tima Tools, it can sometimes take days to
    reach here.
    Status. Done
    Solution. There are batch queues running both here and in Valbonne
    which your request can be stuck in. If you need a tool urgently, see
    Opps Support and ask for your request be placed at the head of the
    queue. If its stuck in our queue, Opps Support will move it, if it's in
    the Valbonne queue, they can log a Valbonne call on your behalf, asking
    for the same thing to happen. 
    

Gentlemen,

The last Systems CIG meeting was held on the Friday 28th January 1994.
As part of my remit is to look into the issues under the topic 
'WORKPLACE', I wish to pass on the following information which some of 
you may already be aware of.

One of the sub-topics was 'Shift Car Park - misuse'. My understanding of 
this is that some employees who did/do not work shift were/are using the 
car parking slots marked as "SHIFT PARKING ONLY". I have been told that 
these slots are actually for anyone who has a need to be in the CSC OOH.

There is a proposal (not sure from whom - possibly the HEALTH & SAFETY 
TEAM and/or MANAGEMENT TEAM) to change the current system as follows:

A gate would be put in place where the current disabled car parking slot 
is; the disabled car parking slot would be an access/exit pathway and 
for use by any disabled person with a wheelchair. The disabled car 
parking slot would now be the next slot along i.e. adjacent to where it 
is now. As there maybe some concerns regarding security, the proposed 
gate would probably be locked OOH. Approximately fifteen of the 
following slots would be designated as 'VISITING CUSTOMER PARKING'. This 
would be where the current 'SHIFT PARKING ONLY' slots are now. These 
slots would be for their designated use between the hours of 09:00 to 
16:00 after which they could be used by employees who need to be in the 
CSC OOH. It has been said that the use of the 'VISITING CUSTOMER 
PARKING' slots would be monitored and enforced.

If any of you have any concerns/feedback, then please send me a mail 
message and I will approach the necessary team/person to voice these 
concerns.

Regards, Norman Bland (Systems CIG Group member)

    Stars/Tima
    
    Any improvements that just give you what you ask for, would be better.
    We need to get away from "Having to know the answer, to be able to 
    ask the question"
    
    Quoted strings might help things.
    
    How about something like being able to work down from a broad initial
    query, down to a specific, eg
    
    CLUSTER --> 9000 --> CIXCD --> HSJ40 --> MICROCODE
    
    to end up with just those articles relevant to the words searched on.
    				       --------
    Is there any way that one could be flagged of articles in databases,
    other than those currently selected ??
    
    As there is a limit to the databases that can be selected at any one
    time, and this will have a bearing on the search time, unless we know
    where articles are, we have no way of knowing that we have found all
    the available data.
    

    
    Can we have an award for whoever comes up with a workable fix, that
    caters for the following problems;
    
    1. IS accept that we work in "Real Time" mode and improve availability/
       reliability/fix times accordingly.
    
    2. IS accept that they manage the systems on our behalf and therefore 
       should treat us as their "Customers".

    

    
Some of you with long memories might remember from when our CIG first got
going, after vast amounts of measurements, the number one item on our list was
the joining of hardware and software groups. This was to be done in two stages,
the first the joining of the VAX group with FASTRACK Systems engineers and
secondly the merging of Systems and VMS. This was NOT to make software
engineers out of the systems engineers, but to give us a future as SYSTEMS
ENGINEERS (Hardware and System type problems that currently go in the VMS
queue).

I think most people agree that the first part of plan has now worked very well
and high on the list of current concerns fed back into the CIG was, our future
as individuals and as a group.

Brian took on the task of mailing all members of the systems group for ideas on
how we might achieve this second part of our original decision, but as he is
away this week, this note will give everyone the chance to start thinking about
our future direction.


Concerns from the meeting and ones I have heard expressed outside, include:

o It was agreed that looking in the VMS when we had no call, was not going to
  work.
o There is little to be gained by making high level Systems engineers into
  bottom of the ladder VMS engineers.
o There needs to be a fair way of distributing the work.
o There is nothing to be gained by forcing people into work they are not ready
  for or have little interest in.
o We can't take on extra work while we have so much dross in the systems queue.

I'm sure that there are others and they should be taken into account.

If you have ideas on the "structure of the future" that will create
OPPORTUNITIES for a secure and interesting future, please reply to this note


Ken

    

	

	Here are some possible ways of merging the VMS and
	Systems groups:

	{I'll start off with my preferred method}

	suggestion 1
	------------


	Based on re-aligning the queue structure of the 2 groups.

	The new queue structure would look something like:(4 queues)

	VMS				P1Q
	---				---
	vms calls (as is)		critical impact	 
	bugchecks			system down and wont boot
	aes				cluster/system hangs
	(no p1 calls)			(all p1 calls)

	HW				HOLD
	--				----
	all identifiable hw calls:	all calls that require no immediate
					action:
	machine checks			waiting for dump to be sent in 
	memory errors			waiting for customer action
	engineer hw tech assists        (all calls p4 and p5)
	pdp and monitors.........
    	..VERY short term only..
    	..only until we tell the field what
    	..product we will support..

	the manpower from the 2 groups would be divided into teams:

    	either:
    
	1. use the current vms structure, and add a further team(s) made up
	   from systems people

	or:

	2. make up new teams from a general pool, dispersing the systems
	   and VMS people.

	Each team led by a team leader.  The team leaders would ensure
	that *all* queues are serviced in a timely manner.
             -----
	

	Suggestion 2
	------------

	Based on the current queue structure

	Systems group continue as is, but either:

	1. supply one person to VMS when manpower >= 5 on days.

	or

	2. each person in Systems is goaled to take n calls from VMS
	   per day or week when manpower >= 5.

	
	Suggestion 3
	------------

	Based on the current queue structure.

	Team Leader assigned to Systems (new VMS team); ensure that
	the new team will prioritize work such that both the SYSTEMS and
	VMS queues get serviced.


	NOTE: all 3 suggestions to work initially monday-friday 09:00-17:30.
	      out of hours cover will continue as is, in the medium term.


	Comments:
	---------

	All 3 suggestions are valid in that they will go some way towards
	resolving the queue problems (too many calls in VMS!)

	Suggestion 2, is rigid in that Systems will only supply manpower
	when manning levels permit... thus we cannot guarantee help to VMS
	Further, when we could supply help, it maybe at a time when help is
	NOT required! 

	Suggestion 3, is more flexible in that the Team Leader would access
	the workload as ongoing (hourly/daily/weekly); and move manpower
	between the queues as required.


	It is my belief that the way we should progress is on the lines of
	suggestion 1.

	Why?	Well we know in Systems that most (>50% at least!) of our
	work is VMS related.. so why not treat these calls as VMS calls?

	What are the real problem situations that affect out customers?
	Is it the odd workstation or microvax that has a bugcheck, or is it
	the the cluster hang/no boot situations?

	We need to prioritize our work such that the run of the mill bugcheck
	(where the system reboots) does not get priority over a VMS call
	where the impact to the customer's operation could be *much* higher.

	The proposed queue structure will put emphasis on the P1 calls 
	because they will be more visible.  It will free up manpower
	in the old Systems group to handle VMS calls. 

	Out of hours we would have a far more flexible approach as the
	new VMS and HW queues would be worked by the available resources
	working as a team. 

	From today's experience (wed 9th) we have (counting me) 7 in
    	the systems group available for work.  Most of the morning the
    	Systems queue has been at 0.  How many of us are aware of the
    	40+ calls in VMS? 
      
    	The point is that unless we have a structured approach to the
    	problem we will never come to successful solution.   Also,
    	are you aware that while there maybe 0 calls in our queue, there
    	are *always* some calls in VMS que that we could and should be doing.
    
    	What I mean is that for many calls, it's a toss of a coin where
    	that get routed.  You will be suprised that many of the calls that
    	we deal with on a daily basis, (and consider to be our bread and
    	butter) also go to VMS.  A typical example of this is "how to
    	set up a dump file".  A lot of these calls are better dealt
    	with by systems...    VMS are not aware of this!
    
    	A further example is last friday afternoon... in Systems we had
    	our queue under control.  We did not blow any responses or upset
    	(or loose!) any customers.   in VMS, by 17:30, there were 35 calls
    	left unanswered.  The majority of these calls would not be picked
    	up until the following monday.  I looked at all of these calls and
    	noted down which could have been handled by *any* systems engineer.
    	I counted 15 calls... some of which not only could have been
    	handled by us, but we would have done a better (and more efficient)
    	job.
    	
        What do you think?  
    
    	cheers
    
    	Brian.
    

	cheers

	Brian

    
    Re .7
    
    Let's just step back and take an overall look at the Open VMS group.
    
    We are already a part of that, we share the same manager, our group
    sign says "Open VMS", and most of our work, (apart from as in note
    166) is VMS.
    
    The VMS group is made up of several groups, within the whole. We have
    a Backup Support Group, we have two teams, with team leaders, we have
    specialists dealing with specific layered products, eg UCX etc.
    We also have ourselves, dealing with Systems problems on any system
    capable of running VMS.
    
    My view of our group, for the future, is "That part of the overall VMS
    Group, which deals with Systems problems." This means that we would be
    what I certainly want to be, i.e SYSTEMS ENGINEERS.
    
    Currently we still have physical barriers (AKA Cupboards) between us
    and the rest of the group. Also we sit at one end of the group, but so
    does the Backup Support Group. However, in their case, there is no 
    physical separation.
    
    As to queues etc, we must not just think of ourselves, we have to
    involve everyone concerned. In my view, this means getting together
    our CIG and any other VMS CIG, to arrive at a common acceptable
    solution.
    
    So lets get this started as soon as possible, and work together, for
    the good of the overall group, the customers, the company etc etc.
    If we fulfil personal aspirations, along the way, then so much the 
    better.
    
    Brian.
    

    As I have already discussed with several people within the group, I
    believe that there is no point in physically moving in order to bring
    about a merge with the VMS group but to remove the personal library
    cupboards which are seen as a 'barrier' is something that could be
    brought about quickly. This of course assumes that all affected
    parties are agreeable.
    
    Norman Bland

    There has been some discussion on the problems of incorrect AES calls
    arriving in systems queue from dsn%hardware.
    
    This is a list of address a customer can choose for a call to end up
    in. The "systems" queue is the destination for both dsn%hardware and
    dsn%systems_hardware.   
    
    The customer has plenty of choice to correctly route a call so that
    makes dsn%hardware a bit of a catch all. No need for it to be directed
    to systems.
    
    
    
     DSNlink Mail Address              Product Name
     
    -------------------------------------------------------------------------
      DSN%HELP                   Help With Using DSNlink Mail
      DSN%OPENCALLS              List of Open Service Requests
      DSN%DISKS_HARDWARE         Disk storage hardware service request
      DSN%TAPES_HARDWARE         Magnetic tape storage hardware service
                                 request
      DSN%PRINTERS_HARDWARE      Hard copy device hardware service request
      DSN%COMMUNICATIONS_HARDWARE
                                 Communications device hardware service
                                 request
      DSN%SYSTEMS_HARDWARE       System hardware service request
      DSN%HARDWARE               Other hardware service request, not
                                 included above
      DSN%PC_COMMS_SOFTWARE      Personal computer communications software
      DSN%COMMS_SOFTWARE         All other communications software
      DSN%PC_OFFICE_AUTOMATION   Personal computer office automation
                                 products
      DSN%OFFICE_AUTOMATION      All other office automation products
      DSN%DATABASE_SOFTWARE      All database products
      DSN%TRANSACTION_PROCESSING All transaction processing products
      DSN%DEC-TCPIP              DEC TCP/IP Services for OpenVMS
      DSN%ULTRIX                 ULTRIX operating system and layered
                                 products
      DSN%UNIX                   UNIX operating systems
      DSN%PROGRAMMING            All languages and systems programming
      DSN%GRAPHICS               All Graphics related products
      DSN%OPENVMS                Open VMS operating system and layered
                                 products
      DSN%VMS                    VMS operating system and layered products
      DSN%RSX                    RSX operating system and layered products
      DSN%RT                     RT11 operating system and layered products
      DSN%RSTS                   RSTS/E operating system and layered
                                 products
      DSN%DSM                    DSM operating system and layered products
      DSN%SOFTWARE               All other software not covered above
      DSN%DSN                    DSNlink specific service request
    
    

    
    re .9 Norman
    
    I agree we should not move just for the sake of it.   
    
    A move to disperse us within VMS will not necessarily produce any 
    benefits to us or solve the problems of the VMS teams.
    
    I think we need to agree on a strategy and structure that will address
    both our problems and those of VMS.  Then decide if a move is
    desirable, or necessary.
    
    I see no short term gain in moving the cupboards.
    
    Brian  

    
    re .10
    
    Why does the catch all DSN%HARDWARE end up in systems ???
    
    It seems to me that if a call does not fall into any of the other
    categories, then such calls should default to some exception group,
    or alternatively, the correct mail address should be available to the
    customer, eg Where does he send a VT420 call ???
    
    

From:	KERNEL::BLAND        "In a world of individuals, comparison is a senseless activity" 14-FEB-1994 13:26:29.86
To:	@POST:SYSTEMS.DIS
CC:	BLAND
Subj:	CIG FEEDBACK 3

        %%%%%%%%%%%%%%%%%%
        % SYSTEMS GROUP  %
        % CIG COMMUNIQUE %
        %%%%%%%%%%%%%%%%%%
                                                        13th February 1994
        Gentlemen,

                   ALL CONSTRUCTIVE FEEDBACK GRATEFULLY RECEIVED. 

        All the comments and points made  below  are  based on my own feelings 
        and those expressed by  other  members  of  the 'Systems Group' either 
        over 'the years' or more recently. It  is  not intended to be a dictum 
        but to simply bring  about  some  action  rather  than just expressing 
        words. My endeavour is that within  a  very  short period of time, and 
        with general consensus,  to  assist  in  bringing  about the necessary 
        changes.

        We have spoken about  the  need  to  stop  accepting hardware calls on 
        various Systems/Options that we  add   little   or   no value to. This 
        discussion has been repeated  at  regular  intervals  for probably the 
        past three years  without  any  appreciable  change  in our procedures 
        within the 'Systems Hardware' arena.

        With the reduction in  manpower  within  the  C.S.C.  and  the need to 
        assist with other non-hardware related calls,  we need to make a rapid 
        decision as to what hardware related  calls  should no longer be dealt 
        with in the C.S.C.; having made  this decision, and with the agreement 
        of management, we need to  convey  the  new  message to the all M.C.S. 
        personnel, with speed and clarity. Below, I have constructed a list of 
        systems/options and what the  appropriate  action  should/could be for 
        this type of call. Many thanks  to  all those that have contributed to 
        this discussion either verbally or via a MEMO and the CSG Notefile.
        
        Explanation of terms and abbreviations used:

        o - S.C.                Service Centre
        o - Local Support       Support from that engineers S.C.
        o - C.S.C. Support      Support from the Customer Support Centre
        o - COMMS S.P.          Comms multi-port devices (single port problem)
        o - P.G. decision       Printers Group decision
        o - N.L.                Not logged (non-remedial call)
        o - A.G.                Appropriate group
        o - UPS                 Un-interruptable Power Supply
        o - PCS                 Power Conditioning System
        o - PDS                 Power Distribution System 

        OPTION                  CUSTOMER CALL           ENGINEER CALL   
	----------------------------------------------------------------------
        MD300 Scanner           Route to S.C.           Local Support
        All Monitors            Route to S.C.           Local Support
	All Terminals		Route to S.C.		Local Support       *
        All PDP11's             Route to S.C.           CSC Support
        All Micro-PDP11's       Route to S.C.           CSC Support  
        All Comms S.P.          Route to S.C.           CSC Support
        All Printers            Route to P.G.           P.G. decision       *
        Cable/Pins              N.L. if non-remedial    CSC Support
        Any DAS directed        N.L. if non-remedial    CSC Support
        Environmental           Route to A.G.           Route to A.G.       *
        UPS/PCS/PDS             Route to A.G.           Route to A.G.       *
	Any AES			Route to A.G.		Route to A.G.       *
        Any AES/planned         Route to S.C.           Route to S.C.       +
	VXT2000			Route to Graphics	Route to Graphics   *

        * CSC/Local Support OOH on a 'best effort' basis
        + Calls from customers requesting system moves/re-configuration
        + Calls from engineers requesting call to be route to Service Centre

        The above list may not be  comprehensive  and  there  may be a need to 
        modify the procedure, i.e.  'All  PDP11's'  or  should we still accept 
        PDP11's with an RD link. OK,  PDP11  calls  with RD links are 'few and 
        far  between'  these  days,  nevertheless  I  believe  an  unequivocal 
        statement is required.

        I personally do not  believe  any  measurements  on  the above type of 
        calls are required (measurements have been made before). It is more to 
        the point that 'we add little value to these calls' as opposed to 'how 
        much of our time is consumed on  these calls'. Any gain in time saved, 
        however small, should be  gratefully  accepted  and   not   used as an 
        excuse for no action. 

        The intention would be for the necessary filtering/routing of calls to 
        be carried out by a 'Resource Controller' or the response group(s).

        Regards, Norman Bland (Systems CIG member)

    
    
    	I think Norman's list is just about right.
    
    	3 points:
    
     1	OOH should be defined as outside of the prime hours of 08:00 to
    	18:00 Monday to Friday.
    
     2	I don't believe we have the skills to support VXT's even ooh
    
     3  No printer calls goto SYSTEMS queue in prime hours. 
    
    	Brian

    
    	A brief (simple?) explanation of my proposed new structure:
    
    	1. we merge systems and vms to form a new integrated group.
    	   (name to be decided)
    
    	2. we have a new queue structure to support the new group:
    
    		a VMS queue       and a HW queue
    
    	   all identifiable "h/w" calls go direct to the HW queue.
           everything else goes to VMS. ***see below***
    
    	3. the "ex" systems engineers will work from both queues.
           the "ex" vms engineers work from the VMS queue
    	  
    	4. the queue managers or resource controllers ensure both queues are
    	   kept under control and response times are met 
    
    *** 5. The P1Q is used as now to highlight all P1 calls. (as now)
    
     	6. The queue structures operate for 24hrs, but outside of prime
    	   hours monday-friday, we maintain the systems and vms shift
    	   rotas.
    
    	please give your views on this.. is it a viable solution?
    
    	If you want to read on, I'll explain why I think this is the way to
    	go:
    
    	Since Warrington VMS was shutdown, there is a critical situation
    	with the VMS queue (nothing like stating the obvious!)
    
    	There are many calls in the VMS queue, where response times are
    	blown.
    
    	There are many calls in the VMS queue, where "systems" expertise
    	could and should be used.. these are "our" calls currently being
    	handled by VMS.
    
    	VMS backup support should not be used to "frontline" VMS calls.
    	
    	VMS backup support should be for backup  only and "heavy" crashdump
    	analysis.
    
    	Frontline VMS should be done by VMS specialists and SYSTEMS 
    	specialists.
    
    	We should provide support and training where required for all
    	individuals involved.
    
    	Above all we should be customer focused.. not internally focused.
    	We need to organise ourselves to satisfy the demands of the
    	customer. 
    	
    	Brian 
    
                               

    
    	A further clarification ..
    
    	The new intergrated "VMS" group would comprise 3
    	areas of specialisation:
    
    	VMS specialists (as they are now)
    	VMS "systems" specialists (us)
    	VMS backup support.
    
    	The VMS specialists front line VMS calls and also take on
    	"in-depth"  VMS work.
    
    	The VMS "Systems" specialists also frontline VMS calls, but in 
    	addition do the majority of the bugcheck and crash analysis work 
    	(as we do now.. remember all crashes go in the VMS queue). 
    	They also work the "HW" queue.
    	They become a multi-skilled sub group ie true "systems" engineers. 
    
    	The VMS backup group continue in a backup role, but support BOTH
    	the VMS specialists and the VMS Systems specialists.  They would
    	not take calls directly from the VMS queue (as they are having to
    	do now).    
    
    
    	Brian.

      
    
    	I have a major problem with this notes string. I have seen a number
    	of replies saying "this is where we should be","this is what we
    	should do","I envisage this structure". This is MANAGER-SPEAK. 
    	MANAGER-SPEAK and CIG's are different entities.
    
    	I seem to remember that one of the criteria for any CIG action
    	was stats (no change without measurement etc etc). I have seen a
    	number of new schemes proposed, but no stats to back them up. 
    
    	New structures look very nice, but whether these are valid for 
    	the real state of affairs is another matter. We have no measures
    	to say if they are or not. 
    
    	What worries me (and this is something I have seen in past couple
    	of weeks) is that we are leaping feet first into a whole bunch of VMS 
    	calls that we THINK we know the answer to, only to find that the
    	customers aren't quite as stupid as we first thought. We then spend 
    	some considerable time attempting to diagnose a problem while calls
    	which we are being goaled to fix are stacking up in the SYSTEMS
    	queue (bye-bye the 2.5% joke payment). Then we end up with two lots 
    	of pissed off customers, the ones who THOUGHT they were talking to 
    	TSC (forgive the old language) and those who WANTED to speak to RDC 
    	(forgive the old language).
    
    	My personal opinion is.... let's see exactly what is expected (and
    	why, after all, this present situation is the result of some pretty
    	crap decisions in the past few months) and then decide, in
    	conjunction with the VMS group, what would be the best way forward.
    	It's very nice saying "we can work from two queues and you can't"
    	but if it means that our core job isn't done then we loose all the
    	ground we gained when OOH diagnosis was turned off.
    
    	
    	Also, there have been lots of "lets not deal with device XYZ calls"
    	replies. What I would like to see is how much impact dealing with
    	XYZ calls has on us, especially when it's something that we don't
    	diagnose anyway and just re-route. The overhead for these calls is
    	(I suspect) very small. Lets measure this before suggesting that
    	the DSN%HARDWARE needs to be rerouted (to who for Gods sake, there
    	are bugger all people left !!).
    
    
    	CIG is spelt with a "C" for Continuous Improvement, not an "S" for
    	Special Interest or a "P" for Personal Immortality.
    
    	                            
    

    Chaps,
    
    	I thought I ought to clarify my involvement in the CIG and how you
    can help me. I have been tasked with Call Management. This involves the
    following:-
    
    	1) Technical Competence
    	2) Response
    	3) Contract status
    	4) Call Management - VAX-Systems specific
    
    	I am going to conduct a survey, with Sue Jackson's permission, of
    CCD and Response personnel. This will highlight where the problems are
    with regard to training, database issues and group response. I believe
    the problems we suffer from miss-routing/logging of requests are a
    training issue with perhaps database management problems. The survey
    will address items  1  & 2.  Contract status is an issue the CSC
    doesn't have much control over but I will seek out any information I
    can and will report back to the CIG.
    
    	As regards the Call Management - VAX-Systems specific I believe this
    is more involved and includes a) Live call handling, b) Response and
    c) Type of request. 
    
    	In order to tackle (a) and (b) I think we need to establish the
    type of requests we process, in what time (OOH/Prime) and from what
    queue we handle requests from. Shortly all VAX-System engineer's will
    recieve a survey form. This will determine the type of request we
    process and when. I expect the survey will last for 2 weeks but this
    will be decided by the CIG.
    
    
    	If there are any issues come and see me.
    
    		Regards,
    			Norm

	re .17
	
	Woa.. Dave hang on in there

	At least you have responded and we can get some discussion going..:)

	This CIG thing has been an on-going activity since over a year ago.
	OK there has been a lull in the progress when we had to recover
	from loosing a couple of engineers... new shift rotas etc.
	BUT there was good work done in the past CIG that should
	not be ignored.

	I agree that we DO need to measure. Lets start this activity asap.
	However there is no reason for us not to discuss the alternatives
	(and problems we have) while the measuring activity takes place.
	
	Going back to the old CIG, you may remember that the alternative
	resructure proposal we chose was #2.
			       -----	
	This proposal was summarised by the statement:
	(talking about the future)

	"the skills required in diagnosis will be based around diagnosing
	complex "systems" and "storage" problems along with the associated
	software.  With this in mind we suggest that all barriers between
	h/w and s/w groups are removed to form the above new diagnosis
	groups." 

	The (then) proposed groupings suggested a VAX/VMS group that covered
	the following products:  VMS S/W, VAX and ALPHA Systems, Bugchecks,
	etc.

	We made the first step in achieving the above by rebuilding the 
	SYSTEMS group and sitting them along'side the VMS Group.

	The next step?  who knows.  This we must discuss.

	I don't want to go on too long, but I must say we should not be
	insular.  The VMS queue problems are our problems as well.
	We know due to manpower resrictions, that we are not going to solve
	the problems by employing more specialists.. the only alternative
	is to better utilise the resources we have.

	I think it's time the two CIG's (VMS and SYSTEMS) got tegether.

	  
	Brian.

    Eeeh by gum there's words being tossed about here like confetti. Some
    of 'em are even being picked up and tossed again in the hope that the
    repetition will add weight to them. 
    
    
         
    The major theme running through here concerns our connections with
    the VMS group. Should those connections be closer or not? What would it
    gain us if they were? We've heard much about the benefits to the VMS
    group - what about the reverse angle? When I came in on Wednesday for
    the evening shift there were 6 calls and 4 specialists in the systems
    arena. There were 19 calls and 19 specialists in the VMS arena and that
    doesn't count the bodies in the London VMS group. That means that there 
    was a better body/call count in their group. 
    
	Question:
    	What benefit would have been seen by the customers who had calls 
        in the Systems queue if we had been more closely aligned to the 
        VMS group and had our calls in that queue? 
    	
    			{My belief - none.}
    
    
    Sure there are times when we have 0 calls and VMS are strapped and we
    can help them out by taking calls out of their queue and I'm sure we'll
    all try to do that when the opportunity arises. We need to make sure VMS 
    are aware that we're doing it. I believe there's a perception problem
    in this area in that VMS believe we're a bunch of coffin-dodgers who
    spend our time talking about how the woman next door spilled nail varnish
    on her cat or fiddling with DECwrite or jawing about how things were
    different when we were just snappers. {I've heard VMS folks talking about 
    us along those lines. I can understand how they get that impression
    too.} Well, I have news - things weren't so different in the past. I
    can remember the VMS manager wandering round the building desperately
    looking for help with the 50-odd calls in the VMS queue. Remember when
    we had the chance to spend a week at a time working in the VMS group in
    the TSC? There were many attempts at schemes to fix things then but
    most were just papering over the cracks.
    
	My thoughts:
    	You can't get a quart out of a pint pot. If there are enough calls
        for 30 specialists then 30 specialists should be employed. (I made
        up those numbers for illustration ONLY). Robbing Peter to pay Paul
        is not the answer and I don't believe our customers should play
        Peter to the Paul that is serviced by the VMS folks. 
    
    		What's the answer? If I knew that I'd bottle it and sell
    		it. One things for certain: there are too few people
    		chasing too much work in the VMS and Systems groups in the
    		08:00 - 18:00 time frame. There are peaks and troughs which
    		can muck up the manning but VMS seem to be manned (or wommaned
    		for the Politically Correct) for the troughs rather than
    		the average. What's required is an increase in bodies or 
    		a decrease in work. I know which answer I'd prefer and I
    		think we all know that it won't happen so the workload has
    		to be decreased or spread around a bit. However we need to
    		be careful how we do it. It's easy to say get rid of
    		certain types of call but the problem is we often have to
    		look at them before we know if they fall into the category
    		that get's chucked away. They also don't form a large part
                of our workload and often don't involve much time. However
    		I think our filter (Debbie!) is perhaps shielding us from a
    		lot of this stuff so when she leaves (sad music plays
    		gently in the background) we may notice them a bit more.  
		Especially the ones where Debbie rings several people in this 
		building and the local offices before getting the call moved.
    		We've already noticed that the resource controllers that have 
		replaced Debbie when she's been away have not been as good 
		so we have to look closely at getting these calls out of our 
		hair but we must be careful not to throw out the baby with the 
		bathwater.
		
		Telesupport: I believe we should not refuse any engineer calls,
		be they on VXT2000 or VAX9000. Even if we just read a passage 
		from a manual to them or tell them we have no skills and they
		should ring their own support group. Telesupport I define as 
		support for an engineer with a problem while on site or when
		getting ready to go to site.
		
		Tech assist: This is where a call comes from sales support or 
		someone in a DEC office who can't or won't find the info 
		themselves. (e.g. what's supoorted on a unibus on a 6300)
		We could handle these but we must make it clear to anyone 
		logging a call like this that it will be looked at when all
		the real work is done.


    I want to be an engineer. I like hardware. I like software a bit less
    than hardware but I enjoy the challenge of VMS system management related 
    calls and bugchecks. I'll happily tackle all the calls that are within
    our current remit (no guarantees about the quality I'll bring to it
    :-)) and I'm sure we all do that. I'll have a go at the more unusual 
    calls that can be found in the VMS queue and our queue when time allows.

	Final bit: (sighs of relief are allowed, help yourself :-))
	I'm yet to be convinced that being subhumed into the VMS group would
	be good for us as systems engineers or the customers and engineers who 
	rely on us when they have problems. We've been placed in the VMS group 
	once and then removed at a later date. On neither occasion did the VMS
	people themselves want the move to happen. The moves were the result of 
	a dictat from above. We are in H2V because we're perceived as a 
	hardware function by those who determine policy and ultimately control
	our destiny and we have to prove to them that we would be a benefit to
	the VMS group to allow us a permanent move. There would be no point in
	trying to prove it to those people above if at the end of the day the
	VMS group don't want us anyway. We need to prove to the VMS group that 
	we would be a benefit to them so we have to sell ourselves and our
	skills to the VMS group. Before we try to convince the VMS group we 
	have to convince ourselves that WE want to do it and there's the rub. 
	We are not all convinced it would be a good thing at this moment in 
	time. Part of the problem there is that we don't understand how much
	of an overlap there is between our work and that of the VMS group. "No 
	change without measurement". We must know why we're making a change. We
	agreed a while ago that the idea of an eventual integration was a good
	one and I believe we should still work towards it as a group but we 
	need to go together as a group and be sure that it's done because there
	is a benefit to our customers, to DEC and to us all and not done solely
	for personal reasons.



roland
    
    
    now then, where's that note about dross......

    
    	Roland, you make some good points..
    
    	We need to be very clear (as a group) on the direction we are 
    	headed, so the more we discuss this the better.
    
    	I'll reply in full to your (Brief ?) entry later, when I get the
    	time.
    
    	Brian

    
    
	This is my reply to Roland's 165.20
    
    	(trying to keep it brief but there are many points raised here)
        
    	    
         
>    The major theme running through here concerns our connections with
>    the VMS group. Should those connections be closer or not? What would it
>    gain us if they were? We've heard much about the benefits to the VMS
>    group - what about the reverse angle? 
    
     this is a two way gain.  We have more to gain than VMS.. but the real
    benefit will be to our customers.. 
    
>       When I came in on Wednesday for
>    the evening shift there were 6 calls and 4 specialists in the systems
>    arena. There were 19 calls and 19 specialists in the VMS arena and that
>    doesn't count the bodies in the London VMS group. That means that there 
>    was a better body/call count in their group. 
    
>	Question:
>    	What benefit would have been seen by the customers who had calls 
>        in the Systems queue if we had been more closely aligned to the 
>        VMS group and had our calls in that queue? 
    
	Because the skills we would have developed (over time) in working
    	this way would enable us to be better engineers.  (true systems 
    	engineers). The knock on benefit to our customers would be enormous.
    	
    
>    Sure there are times when we have 0 calls and VMS are strapped and we
>    can help them out by taking calls out of their queue and I'm sure we'll
>    all try to do that when the opportunity arises. We need to make sure VMS 
>    are aware that we're doing it. 
    
     This works fine in the short term and while there is enthusiasm.
    However we need a long term solution that will gain us significant
    improvements in customer satisfaction.  This means consistency, day
    to day.
     	
>    I believe there's a perception problem.......
    
    agreed, and that's a major problem. we are seen as a h/w group.
    How can this be so if a significant proportion of our work is in s/w?
    
>    Well, I have news - things weren't so different in the past. I
>    can remember the VMS manager wandering round the building desperately
>    looking for help with the 50-odd calls in the VMS queue. Remember when
>    we had the chance to spend a week at a time working in the VMS group in
>    the TSC? There were many attempts at schemes to fix things then but
>    most were just papering over the cracks.
    
     this is my point.. let's sit down with the management, and vms
    and fix the problem for good.  There is so much duplication and skills
    wastage (and shortage) there *has* to be a better way of working.	
    
>        My thoughts:
>    	You can't get a quart out of a pint pot. If there are enough calls
>        for 30 specialists then 30 specialists should be employed. (I made
        
    Agreed, but you can use the skills we (us and vms) have in a more
    efficient way.  Develop those skills further and you go a long way
    to solving the problem.
    	 
>		What's the answer? If I knew that I'd bottle it and sell
>    		it. 
    
    and make a fortune? :-)
    
>    One things for certain: there are too few people
>    chasing too much work in the VMS and Systems groups in the
>    08:00 - 18:00 time frame. 
    
    Agreed, so let us change the *way* we work and see if the problem
    changes.  At the end of the day it's customers that matter. Has anyone
    asked them what they want?  Why do we spend "n" hours looking at a 
    single bugcheck on a workstation that rebooted last friday,  but ignore
    the s/w call from the *same* customer until the following day?
    My suggested solution would include some mechanism of prioritising our
    work. Imagine the situation where the customer was dealing with the
    same engineer... who could prioritise the work.. perhaps look at both
    problems together (the problems may even be related).  My mind boggles
    at the savings and advances we could make here.
    
>    		....... However
>    		I think our filter (Debbie!) is perhaps shielding us from a
>    		lot of this stuff so when she leaves (sad music plays
>    		gently in the background) we may notice them a bit more.  
>		Especially the ones where Debbie rings several people in this 
>		building and the local offices before getting the call moved.
>    		We've already noticed that the resource controllers that have 
>		replaced Debbie when she's been away have not been as good 
	       
    Yes, when will management learn that efficient resource controlling
    is crucial to our operation.  In the days of RDC we did it ourselves.
    (and we were in control).  Once you appoint someone to this post, and 
    you start to rely on them they have to be 100%.  
    I am coming round to thinking that a remote resource controller, 
    who in not integrated into the group is more a hindrance than a help.
    
    
>		Telesupport: I believe we should not refuse any engineer calls,
>		be they on VXT2000 or VAX9000. Even if we just read a passage 
>		from a manual to them or tell them we have no skills and they
>		should ring their own support group. 
    
    I'm still to be convinced on this.  I agree this is true for ooh, where
    we are the only resource available.
     

>    I want to be an engineer. I like hardware. 
    
    So do I.  But I want to be a "systems" engineer, who has an understanding
    of both h/w and s/w.  I have a good understanding of the h/w (I hope!)
    but to gain experience on s/w requires exposure to s/w problems and
    issues.  I don't want to be a low level s/w enginner, but a high
    level systems engineer and solve customer's problems. 
    
>    I'll happily tackle all the calls that are within
>    our current remit (no guarantees about the quality I'll bring to it
>    :-)) and I'm sure we all do that. 
    
    A significant proportion of the calls in our current remit get routed
    to the VMS queue. The response to these calls varies greatly from day
    to day.   The VMS group are (on the whole) not aware of the problems we
    can look at so they don't always get us involved. (even if they do it's 
    usually after the LSDT has blown).  
    
    This is an every day occurance, not the exception. Most of this work
    would be better (or equally) handled by engineers with "systems" skills. 
    
>    	 We've been placed in the VMS group 
>	once and then removed at a later date. On neither occasion did the VMS
>	people themselves want the move to happen. The moves were the result of 
>	a dictat from above....
    
    	Dictats from above .. mmmm .. do they understand our work?
        That's why we need to fix the problems ourselves.
    
>    				... We are in H2V because we're perceived as a 
>	hardware function by those who determine policy and ultimately control
>	our destiny..
    
    	That is our problem, until we merge our function within VMS,
    	we will always be seen as h/w engineers, and not system engineers. 
        The people whe determine policy are too far removed, (and therefore
    	do not understand our function)
    	
>	.. Part of the problem there is that we don't understand how much
>	of an overlap there is between our work and that of the VMS group. "No 
>	change without measurement". 
    
    	I will provide this measurement
    
>     We agreed a while ago that the idea of an eventual integration was a good
>     one and I believe we should still work towards it as a group but we 
>     need to go together as a group and be sure that it's done because there
>     is a benefit to our customers, to DEC and to us all and not done solely
>     for personal reasons.

    	I want us to integrate (as a group) into VMS because the time is 
    right.   
    
    The time is right? yes, for us, for VMS and for our customers.
    
    Why?  	
    
    A significant proportion of our work is s/w
    There is overlap and duplication between the two groups.
    Futher development by ourselves a systems engineers needs s/w exposure
    We are wrongly perceived as a h/w only group.
    We loose a lot of our work in the vms queue
    We loose customer satisfaction because of the above.
    The future is systems, not h/w engineers who dabble in s/w (when time
    allows)... Lets do it right and get the recognition we deserve.


    Brian
roland
    
    
    now then, where's that note about dross......

        %%%%%%%%%%%%%%%%%%
        % SYSTEMS GROUP  %
        % CIG COMMUNIQUE %
        %%%%%%%%%%%%%%%%%%
                                                        
        Gentlemen,                                      3rd March 1994

                   ALL CONSTRUCTIVE FEEDBACK GRATEFULLY RECEIEVED. 

        As a follow up to some of the  issues discussed in FEEDBACK 2, I had a 
        recent meeting with Debbie Hatton.  I  left  the meeting with a little 
        bit of information but also with a number of questions to be answered.
        The answers have not been forthcoming so I will be be asking Debbie in 
        the very near future if  she  has  been  able  to obtain the requested 
        information. The following has been gleaned.

        POWERFAIL PROTECTION
        --------------------

        o - All of the ground floor area is affected by not having UPS backup.
        o - Not sure whether the ground floor has S/B generator protection.
            It is believed  that  the  whole  building  is  protected  - to be 
            checked.
        o - To  provide  UPS  protection  for  the  ground  floor  would incur  
            considerable cost to resolve  and is unlikely to be funded - to be
            checked. 

        LIGHTING
        --------

        o - The inability of  being  able  to  control the lights in different 
            work areas on the ground floor,   would incur considerable cost to 
            resolve and is unlikely to be  funded.  To be checked with Johnson 
            Controls.

        CHAIRS
        ------

        o - Compliance with European law by January 1st 1997.
        o - If chair has castors then there must be at least five - stability.
        o - Required to have adjustable height and swivel.
        o - Not required to have a high back i.e. to head height.
        o - Back must be adjustable.

        SHIFT KITCHEN
        -------------

        o - Supply of Washing-up liquid  and  Dishwasher powder. I have yet to 
            speak to Pete Stevenson regarding this matter.
        o - There is currently a review  taking place with regard to the Shift 
            Kitchen usage. UK PMS are  wondering  why  our  building has to be 
            different to other DIGITAL buildings.
        o - Excessive quantities  of  milk  and  tea  bags are being consumed; 
            about 8 pints of milk/day and 400 tea bags/week.
        o - The Restaurant (canteen)  is  open  for tea/coffee between 08:30 - 
            10:30, 12:00 - 14:00 and 14:30  -  15:00. This is considered as an 
            alternative to those who do not want to use the drink machines.

        VENDING MACHINES
        ----------------
                
        o - Food machines can be topped-up more frequently if there is a need.
        o - GRANADA vending will be  approached  about reviewing the number of 
            50P coins available for change in the drink machines.
        o - The vending machine issues  need  to  be reviewed at a latter date 
            as new machines are currently being installed.

	WORKSTATION
	-----------

	A brief conversation with Magaret  Walsh  revealed that the ergonomics
	exercise mentioned in an earlier feedback memo, has to be accomplished
	by the end og March 1994. Watch this space.

        Regards, Norman Bland

    

	Mr Moderator,

	We appear to have several topics bundled into the same subject
	here, i.e CIG Information and Discussions on the Group Future.

	Can they please be separated out into new note(s) under 
	appropriate headings ???

	Having done that, please feel free to delete this reply.

	Brian.

	Re - several.

	We seem to have some basic differences, within the group, on 
	certain key issues.

	eg Should we merge with VMS and if so, how ??

	On this point, one or two replies have mentioned the fact, that
	our original CIG came up with a substantial majority in favor
	of a merger. What was not decided, was HOW.

	We now seem to have some group members changing their minds and
	almost opposing such a move. However, what we don't have is
	alternative suggestions. We cannot sit here forever, saying 
	"That won't work", "We must measure", "We are hardware people".

	Let's look at some facts.

	1. Every member of our group, is a SYSTEMS engineer in some degree,
	   i.e Has a combined Hardware/Software knowledge.

	2. The Hardware/Software we deal with is almost 100% Vax/VMS.

	3. Hardware is becoming easier to fix, and is becoming a commodity
	   product. Most new sales are small boxes, rather than mainframes.

	4. System problems are becoming ever more complex.

	5. Warrington CSC has gone, with the workload shifting to Viables.

	6. Hardware call volumes are not increasing.

	7. Software call volumes outstrip the available man/woman-power.

	8. WE HAVE THE SKILLS TO HANDLE A FAIR PROPORTION OF THOSE 
	   SOFTWARE CALLS.


	It would therefore seem reasonable to move to a situation where
	we, as SYSTEMS ENGINEERS, deal with those calls that we have the
	proper skills to handle, whether they be hardware or software.

	Also, let's not forget that whatever we do, is part of a 
	Continuous Improvement program. We may not get it 100% right, 
	first time, so we change or fine tune as required. We may take calls
	that turn out to require skills other than ours, but why cannot we
	then route such calls to the best resource. Are Frontline calls so 
	very different from our simpler calls, eg CRD errors ??. But who said
	we would only do those calls. Remember we need to make our skills
	count.

	I would also suggest that our group should read topic 259 in the
	VMS_TSC notes conference, which specifically raises the issue of
	the VMS queue problems. We need to address the situation that we
	do not figure prominently in any solution to that problem.

	You will see that they are thinking of taking, what might be 
	considered, drastic steps to handle the workload. A major item
	in this area, is "Chargeable issues". Certain aspects of our work
	come into this category, when Remedial, becomes Consultancy. We 
	must therefore be party to joint discussions. They are also talking
	of ways to handle patches. This affects us as well, as do so many
	of their problems.

	If you still think that a merger or joint group, or call it what you
	will, is a bad idea or a non-starter or whatever, then voice your
	opinion by all means, BUT SUGGEST ALTERNATIVES and do so soon. That 
	way we can LEAD, rather than be forced into decisions, as has 
	sometimes happened in the past.

         
        I suggest the SYSTEMS group should be. 
        
        A sub group of VMS_SYSTEMS engineers who still have broad cross 
        product skills having both hardware and software knowledge. We 
        already work well as a team and should stay as a team using our 
        skills to our customers and our advantage. 
        
        
        A large percentage of the time, we currently have enough work in 
        our SYSTEMS queue, but I believe that we should set up a 
        structure that will work in the future (and ensure that we are a 
        part of that future). 
        Taking the very simplest case of making the VMS and SYSTEMS queue 
        one VMSSYSTEMS queue, would mean that we do exactly the same work as 
        today (working on the same calls and speaking to the same 
        customers). It would also give us visibility of calls that 
        currently sit in the VMS queue before being sent to the SYSTEMS 
        queue. 
        
        This would mean NO CHANGE in the work we do today. 
        
        What this queue change would allow for is for us to make the 
        transition from currently spending say 60% of our time on 
        software / system problems, then next month 62%, then 63%, and so 
        on. In other words a gradual change as our traditional work goes 
        away and new skills grow.
        It would also give the VMS engineers visibility of what our 
        skills are which will lead to greater co-operation and speedier 
        resolution of customer problems. 
         
        Somthing to think about.
        
        Just look how the numbers in the old Systems (20) and Micros (8) 
        and Warrington (2) groups (total 30) have reduced by 2/3 in a 
        very short time. If we don't make the right decision now, well, 
        we have all seen the way the trend is going. 
                                  
        
        
        The hardware is changing with the older 9000, Nautilus and even 
        6000 systems replaced by 4000, 7000 and  Alpha systems. This has 
        lead to a great increase in reliability. At the same time, new 
        complex software is being introduced.  
        
        
        Systems are becoming more complex, with the expansion of 
        VAXcluster systems based on CI, DSSI, ethernet and FDDI. This 
        picture is being further complicated with the introduction of 
        Alpha VMS and the mix of Alpha VMS and open VMS in the same 
        cluster.
        
        To resolve  system problems, hardware and software engineers will 
        need to become true systems engineers with a knowledge of both 
        hardware and software. I believe we already are, but we are still 
        seen by many as purely hardware engineers; an image we need to 
        change.
        
        
        We have seen in the past how imposed changes  have failed. We 
        need to make these decisions ourselves. The direction has already 
        been decided by everyone via the CIG --- after much 
        measurement---. What we should be looking at now is how. 
         
        Very complex "system" problems which tend to take in depth 
        hardware and software skills to first, isolate and identify and 
        then to resolve. 
        Examples are: Intermittently hanging or crashing systems or 
        clusters. Currently these calls can go into either the VMS queue 
        or the SYSTEMS queue, depending on the wording the customer uses 
        when the call is logged, and not on where the skills are to 
        resolve the problem.
        
        Other considerations for quality diagnosis
        
        The vast range of DEC products, make it impossible for any 
        individual to have in-depth knowledge of anything except a small 
        range of equipment.
        
        VMS already have sub groups specialising in areas or products and 
        I believe that the skills in our group should be kept together as 
        a sub group. I, like most people in the group enjoy working on 
        hardware and have no desire to become 100% VMS software 
        engineers.
        
        Because systems are becoming very much more reliable, Field 
        engineers are not getting exposure to problems. It is not 
        uncommon for an Field engineer to go for months or years between 
        seeing the same type of problem. The Field engineers then have 
        the choice of making a guess at what will fix the problem or 
        contacting the CSC for support so there is a real need for us to 
        maintain our hardware skills.
        
        To be able to maintain a high quality of diagnosis we need a 
        critical mass of specialists working on products they are 
        experienced on, regardless of which queue the call may have been 
        placed in. All good reasons for working together as a group.
    
    
                               

    
    	Wow!  at last, some ideas on how we progress.
    
    	I quite like Ken's suggestion of just merging the VMS and Systems
    	queues. 
    
    	We are now starting to see some possible ways forward.
    
    	Another idea that came up when I was discussing the problems
    	with Norman Bland, is to move certain elements of the VMS work into
    	the Systems arena.  For example we could take on all no boot
    	situations (ie even when the customer says its a s/w problem),
    	all autogen and sysgen queries.. etc.  This is simplifying the
    	idea, but I hope you get the gist of it.  Long term we merge
     	with VMS.
    
    	Thus we have 3 possible ways of doing it:
    
    	1. My suggestion, move all our "s/w" work to the vms queue and
    	   work out of that queue plus a separate "h/w" queue only visible
    	   to us.  We become a sub-group within VMS and work the VMS queue
    	   for all our crash/hang work, but retain a responsibility for
    	   the h/w queue.
    	
    	2. Ken's suggestion that we simply merge the two queues, but again
    	   we maintain our identity and work as a subgroup within VMS.
    
    	3. Norm's suggestion of moving certain elements of VMS work over
    	   to us, with a longer term view of a complete merger.
    
    	
    	Now the question is, (from all the discussion gone on in the past
    	few weeks),  do we want to move forward towards being "systens"
    	engineers with equal h/w and s/w skills or do we stay as we are.
    
    	If we want to move forward, we'll have to decide on the "how"
    	pretty damm quick.
    
    	I'd like to hear what others have to say on this. (those who have
    	yet to reply to this note?)
    	
    	Lets get a concensus and go speak with BJ and VMS
                                                         

                                 
    	This reply is about out current measuring activity.
    
    	I fully understand the need for measuring our work to obtain
    	an accurate picture of what we do.  (and we can therfore make
    	good decisions based on that data).
    
    	However I fear that our current measuring activity will not 
    	produce an accurate picture of our work.  I guess is depends
    	on what we are setting out to prove.  We seem to be putting an
    	emphasis on a breakdown of call types by call volumes.  I think
    	an equally (more?) valid argument is call types by time taken 
    	per call. 
    
    	what does the team think?

    re .27
    
    Just to put a little more flavour on my suggestion:
    
    I have been talking to various people of late (including Brian
    Johnson), about our group becoming a sub-group within VMS. My
    motivation for this is that by being recognised as part of that group
    the transition to becoming a more software orientated engineer (as the
    hardware calls become less), will be easier. My suggestion was also to
    say run from two queues (no, I do not like Ken's idea); I propose two
    queues "SYSTEMS_HW" & "SYSTEMS_SW". As Brian Anthony said, I have
    suggested that certain types of calls go into the "SYSTEMS_SW" queue.
    By having two queues it should be easier to provide measurements (when
    required) on what hardware/software calls and what type we are doing.
    Having the "SYSTEMS_SW" with certain types of calls being put into that
    queue, we show a commitment to handling a percentage of the calls that
    go into the VMS queue (yet to be determined). This is of course on top
    of the software calls that we already do.
    
    Finally, I want to be seen as a SYSTEMS engineer, I want to improve my
    software skills - anyone else out there who wants to join me. OK, I
    know ther is. Keeping the name "SYSTEMS" in the two proposed queues, to
    me suggets calls for SYSTEMS engineers, not software engineers, not
    hardware engineers.
    
    Cheers, Norman

    .20>> ... We are in H2V because we're perceived as a hardware 
    .20>>function by those who determine policy and ultimately
    .20>>control our destiny..
    
    .22>That is our problem, until we merge our function within VMS,
    .22>we will always be seen as h/w engineers, and not system engineers.
    
    But we were merging with VMS when the people who matter stopped it
    and made us move back to a hardware CC. If they've done it once they
    could do it again. How are we to stop them? 
    
    
    
    .22>The people whe determine policy are too far removed, (and therefore
    .22>do not understand our function)
    
      ...but they still determine policy and will continue to do so. They
    won't change their policy unless we can show them a good reason for it.
    We can tell them we want to be part of VMS till we're blue in the face
    but if they decide we shouldn't be part of VMS then it won't happen.
    
    It would be nice to think we can make them understand our function.
    Perhaps the information currently being gathered will provide the evidence.
    It'll have to, really. Any previous information gathering exercises may
    not provide relevent information because the structures have changed so
    much. 
    
    	

    Gents,
           Thanks for an interesting read. How many VMS calls could you
    have taken whilst compiling this DROSS. (Just Joking).
    	   Seriously, both Andy and myself need your assistance in going
    forward. We need suggestions and we need them fast. 
    	   The first opportunity we would like to engage you in is
    the simple task of how we manage the Systems/VMS/Storageworks Units. 
    Clearly we would like to split the manpower ratio per manager as even as
    possible, without seeming to divide the H/W and Software businesses.
    	   The second is the if you want to go towards your "Systems"
    approach, we need to establish how, without degrading your H/W service,
    especially as we are entering into a CSC goal of achieving 50% live
    call hanling and 90% within an hour. 
           Finally, the structure now managed by Andy and myself WILL
    succeed and be the best in the Support Centre. We hope all of you will
    be proud to be in the Winning Team.
           I would suggest you get together to gather your collective
    thoughts by the end of the week.
    
    
    Thanks for your Support,
    
    Brian/Andy.

    Gentlemen & Angie,
    
    Below are the CIG minutes from the meeting held on the 28/APR/94.
    My thanks to Stella Smith for taking the minutes and providing the
    original write up. The minutes have been re-formatted by me.
    Please feel free to comment; your feedback is welcomed and necessary.
    
    Norman Bland
    
                MINUTES OF THE CIG MEETING HELD ON THURSDAY 28TH 
                        APRIL AT 3PM IN THE PIONEER ROOM


                Present: Ken Robb
                         Norman Pettet
                         Bruce Muir
                         Norman Bland (Chair)
                         Brian Anthony (from 4pm)
                         Mike Baldock (until 3:30pm)
              
              
        1. Review of Live Call handling

        It was generally agreed  that  this  was working and worthwhile. 
        Norman Pettet suggested  that  CCD  be  mailed  and requested to 
        allow the phone to  ring  for  a  longer  length  of time before 
        ringing off. Norman  Bland  read  out  two  suggestions of Brian 
        Adams, these being that:  all  response  groups use huntline and 
        that they ring for  a  reasonable  amount  of time. Norman Bland 
        also underlined the  importance  of  ensuring  somebody  takes a 
        person's calls while they are away from their desk.

        ACTION: Norman Pettet will  talk  to  CCD/Response about Brian's 
        comments.

        2. Problems with Dialling out

        It was put forward that more regular testing might be necessary, 
        although Mike Baldock  questioned  exactly  what  they  would be 
        testing for.

        ACTION: Ken Robb will speak to Pete Alvis about this.

        3. Call Logging with IS and OPS support

        There seem to  be  problems  with  logging  calls.  Mike Baldock 
        confirmed that OPS support  has  similar  problems and suggested 
        that if a request can be made  over the phone, a call should not 
        be logged. Otherwise it  should  be  logged  on NICE. Any issues 
        specific to OPS support to go to Mike Baldock.

        ACTION:  Norman  Bland  will  seek  further  evidence  of  these 
        problems throughout the group and bring them to the attention of 
        Murray Smith.

        4. Backup Systems

        There was  general  disappointment  with  the  present  practice 
        whereby systems are going down without prior warning and without 
        a back up system in place.  Mike Baldock stressed the importance 
        of good  communications  and  suggested  that  there  should  be 
        consultation. It was agreed that  perhaps  3  am-5 am might be a 
        good time for this work.

        ACTION: Mike  Baldock  will  keep  the  group  informed  on this 
        matter.

        5. NICE Call Handling

        5.1 Updating calls.

        There were a number of  suggestion  on how to update long-winded 
        calls, it being agreed  to  be  difficult  to find the pertinent 
        information with pages  of   description.  It  was reported that 
        Dave  Gledhill  had  put  forward   the   use  of  multiple  'P' 
        descriptions. The idea of using  a  template was put forward, in 
        order to simplify descriptions and Ken Robb said that this would 
        be easy enough  to  create  and  could  then  be  perfected with 
        experience. 

        Norman Bland suggested using one 'A' description with templates, 
        everyone using  the  same  template,  one  'P'  description  and 
        possibly  an  'S'   description.   Norman   Pettet  favoured  an 
        additional entry for  Crash  Dump  Analysis  which could include 
        more detail. The  following  descriptions  were generally agreed 
        upon:
 
        *  one  'A'  description  with   actions  by  specialists  using 
        templates.
 
        * one 'P'  description  with  problem  statements  using current 
        template.
 
        * one 'S' description if problem is solved by specialist.
 
        * a 'CDA' description with all the details and multiple entries.
 
        ACTION: Ken Robb will collect feedback on names for descriptions 
        and start designing templates.
 
        5.2 Call Ownership

        It was suggested that there be two  queues: a System Queue and a 
        System Hold (waiting action, not  live  calls). It was generally 
        felt that this was a good  idea  so  long  as the Wait queue was 
        regularly scanned and it was preferable  to  hand a call over to 
        someone rather than putting it  in  the  Wait queue. It was also 
        noted that the LSDT time  should  be  carefully observed so that 
        calls are not allowed to drag.
 
        ACTION: Norman Bland  will  put  these  ideas  to  others in the 
        group, and Norman Pettet will draw  up guidelines for how to put 
        this into action.

        6. Effectiveness of Group Resource Controller

        It was stressed that this discussion  was not a personal comment 
        on the individual controllers  concerned.  All  agreed that they 
        had been  particularly  fortunate  with  the  previous  resource 
        controller who had been  devoted  solely  to their group. Norman 
        Bland suggested  that  realistic  expectations  of  the resource 
        controller be laid down, whilst Norman Pettet stated that he was 
        happy with the  situation  as  it  stood  at  present. There was 
        discussion  on  whether  the  group   should  share  a  resource 
        controller with the VMS group and  what can actually be expected 
        of a resource controller  and  whether  they  can be expected to 
        back up  tapes.  It  was  commented  that  the  present resource 
        controller is undergoing training and  this was welcomed. It was 
        put forward  that  perhaps  two  resource  controllers  might be 
        better, with one responding to  problems and escalations and the 
        other responsible for dumps and patches.
 
        ACTION: Brian Anthony will  approach  Chris  Hall  to  ask if he 
        would be willing to take on  the  role of resource controller in 
        respects of escalations and problems.  Norman Bland will talk to 
        Mike Ayling re: drawing  up  guidelines  with  Angie Nash on the 
        role of the resource controller.

        7. System Statistics Review

        Bruce Muir presented the  System  Group  Statistics, showing the 
        total man  hours  against  the  type  of  calls,  and  expressed 
        disappointment at the  figure  of  8.14%  being unaccounted for. 
        There was general  discussion  on  the  statistics with comments 
        regarding the fluidity of  the  industry  and  the  need to make 
        management aware of the skills of  the group. Norman Pettet then 
        gave a detailed statistics  presentation, emphasising particular 
        statistics. He invited members to  view  the statistics at their 
        leisure after  the  meeting.  With  regards  to  the  number  of 
        terminal monitor problems and printer requests it was questioned 
        whether the group should be dealing  with these if they were not 
        actually adding  value  to  them.  It  was  agreed  to  let  the 
        situation regarding  terminal  monitor  problems  stand  for the 
        present whilst the terminal  diagnosis  centre  is being set up, 
        after which these requests should pass over to them.

        Norman Pettet brought up  the  problem  of  calls that have been 
        closed and tapes not returned, saying that when a call is closed 
        the tape should be erased,  sent  back  or patched. He suggested 
        that guidelines be drawn up  on  media handling so that everyone 
        is aware of the procedure ACTION  Bruce  Muir will draw up media 
        handling guidelines.

        7. VMS Integration  Brian  Anthony  pointed  out  that  from  the 
        statistics, it is probable that the  work on VAX hardware can be 
        expected to decrease dramatically  over  the  next 18 months and 
        that the group cannot expect to  see growth in the current areas 
        in which they work.  He  suggested  reskilling  in  the areas of 
        Infoserver and possibly ACB,  stressing  the importance of doing 
        hardware and  software  support  together  and  as  ACB  is just 
        starting to be supported it would be  a good time to take it on. 
        He also suggested taking  some  live  VMS  calls. There was some 
        discussion as to whether this  would  be  taking  on too much at 
        once.

        It was agreed that  the  group  should  try  to  get involved in 
        System Management Training. Brian  Anthony  put  forward a third 
        alternative of  taking  AES  logged  calls  perhaps  just during 
        maximum availability in the afternoon.

        ACTION: Ken Robb will put  these  proposals  to  the rest of the 
        group and find out general feeling. Brian Anthony will negotiate 
        with VMS. Ken and Brian will try to see that Infoserver training 
        is in place within 4-6 weeks and  Brian will find out more about 
        System Management Training.

        8. Date of the next meeting

        This was agreed to be on Thursday 19th May at 3 pm.

        The meeting closed at 5:30 pm.
    

    I had a meeting with Sue Jackson this morning. She has asked response
    to ring the hunt line for 3 rings. She will test the Systems hunt line
    (probably tomorrow) and check that it does indeed ring for 3 times as
    there is a doubt whether the phone system is working OK.
    
    Update later,
    
    
    		Norm

    
              MINUTES OF THE CIG MEETING HELD ON TUESDAY 17TH MAY
                           AT 3PM IN THE PIONEER ROOM

        
        Present:  Ken Robb
        Norman Pettet
        Bruce Muir
        Norman Bland (Chair)


        Norman Bland opened the meeting  by outlining the problem caused 
        by the sudden planning of  VMS  V6.1  seminars which lead to the 
        meeting being held at short  notice.  Consequently, there was no 
        formal agenda and he  suggested  that  the meeting be structured 
        around the minutes of the last meeting and to review progress on 
        the agreed actions.

        1. Review of Live Call Handling
        -------------------------------

        Norman Bland reminded  the  meeting  of  the  previous meeting's 
        discussion.
        
        Norman Pettet reported that he had spoken to Sue Jackson who has 
        mailed response groups requesting that  they allow the phones to 
        ring for a reasonable amount of time before hanging up. However, 
        both Ken Robb and  Bruce  Muir  reported  recent instances where 
        they had not been given enough time to answer phones.

        ACTION: Norman Pettet will go  back  to  Sue Jackson in order to 
                find ways to improve the situation.

        2. Problems with dialling out
        -----------------------------

        Norman Bland  briefly  reviewed  the  minutes  of  the  previous 
        meeting. 
        
        Ken Robb reported that he has  still  to  speak to Pete Alvis on 
        this subject.

        ACTION:  Ken Robb to speak to Pete Alvis.

        3. Call logging with IS and OPS support
        ---------------------------------------

        With reference to the agreed action  at the last meeting, Norman 
        Bland stated that he was still gathering feedback on problems of 
        logging calls and when he has  collected data he will bring this 
        to the attention of  Murray  Smith.
        
        Both Norman Pettet and Ken  Robb  commented on the importance of 
        prompt response by IS.

        ACTION: Norman Bland will continue  collecting feedback and then 
                pass this information on to Murray Smith.

        4. Back-up Systems
        ------------------

        Norman  Bland  commented  that  the  situation  seemed  to  have 
        improved  since  the  last  meeting  with  more  warning  having 
        recently been given when  systems  are  to  go  down and back-up 
        having been provided.
        
        Ken Robb suggested that this  again  was  a  problem with IS and 
        that they should be  made  aware  of  the  importance of back-up 
        system when another system is taken down.

        ACTION: Norman Bland will take this issue up with Murray Smith.

        5. NICE Call Handling
        ---------------------

        5.1 Updating Calls
        ------------------

        With reference to the  minutes  of  the  last  meeting, Ken Robb 
        reported  that  he  has  started   designing  templates  and  is 
        currently collecting feedback on them. He outlined the nature of 
        the templates which is:

        - one 'A' description, with basic information
        - Update descriptions
        - Trouble  Statement  descriptions  (for  extended  analysis) in 
          place of Crash Dump Analysis descriptions

         The problem and solution descriptions remain unchanged.

        5.2 Call ownership
        ------------------

        Norman Bland reminded the meeting  of  the actions agreed at the 
        last meeting whereby he  would  sound  out  other members of the 
        group on the question  of  having  two  queues and Norman Pettet 
        would draw up guidelines on how this could be put into practice.
         
        There followed discussion on the  question of ownership of calls 
        and it was suggested that if a  person  goes on shift and a call 
        passes the LSDT, it remains  that person's responsibility to get 
        back to the customer.
        
        Norman Bland put forward that Live Call Handlers be requested to 
        check the Wait queue twice a day  to flag calls that have passed 
        their LSDT, and this was generally  felt  to  be a good idea. It 
        was also agreed that if  possible,  calls  should be handed over 
        rather than going into the queue.

        ACTION: With reference to this  issue,  people were requested to 
                update the notes file.

        6. Effectiveness of group resource controller
        ---------------------------------------------

        Referring to the  agreed  actions  of  the  last meeting, Norman 
        Bland confirmed that he has spoken to Mike Ayling who has agreed 
        to  talk  to  Angie   about   establishing  Resource  Controller 
        guidelines. He also reported  that  Brian  Anthony has spoken to 
        Brian Johnson on the issue who has requested that Angie be given 
        more time to adjust to her  role. Accordingly, he has not spoken 
        to Chris Hall on the subject.
        
        Norman Pettet  expressed  disappointment  with  Brian  Johnson's 
        response, saying  he  felt  that  group  feeling  was  of  great 
        importance in this matter.

        Ken Robb pointed out that there were boundaries beyond which CIG 
        could not expect to have influence  and that the way others work 
        might be such an area.

        Norman Bland  stressed  the  difficulties  for  Angie  in  being 
        effective in so many  different  areas,  and  also that, to some 
        extent, Chris Hall already  acts  as  a  PR  man  for the group, 
        allowing the group to concentrate on their technical role.

        ACTION: On circulation of the  minutes,  the group will wait for 
                feedback before deciding on further action.


        7. Systems Statistics Review
        ----------------------------

        Norman Bland reported on  behalf  of  Brian  Anthony the opinion 
        that  System  Management  Training   was   more  important  than 
        Infoserver training. He  also  reported  that  System Management 
        Training would be running  over  the  coming  two weeks and Dave 
        Gledhill had plans to arrange more  Advanced courses. Due to low 
        availability figures over  August,  it  will  not  be possible to 
        attend training then and the  group  will  have to be looking to 
        Autumn for Infoserver training.

        Ken Robb stated that Dave  Gledhill  had  spoken  to VMS re: the 
        group taking Infoserver calls,  and  the  response had been that 
        because this area  was  low  volume  and  VMS  already have good 
        skills in this area, that  the  movement  of  calls might not be 
        particularly productive. The situation remains under review.

        Norman Bland reported that  Brian  Anthony  had  spoken to Brian 
        Johnson about the group taking live VMS calls, and Brian Johnson 
        had given a positive response.

        ACTION: Brian Anthony will talk  to  PMS about having two phones 
                installed for these calls.

        There was  brief  discussion  on  the  ACB  proposal,  it  being 
        suggested that the  group  sells  this  as  a  product  and then 
        supports it. It was  agreed  that  this  needs  to be researched 
        further, and for other group members to feed back on it.

        8. Media Cupboard
        -----------------

        Bruce Muir stated that he is still  in the process of drawing up 
        guidelines for keeping tabs on tapes.
        
        Norman Bland  expressed  his  dissatisfaction  with  the present 
        situation and Bruce Muir outlined proposals to improve it.

        9. Call Handling Survey
        -----------------------

        Norman Pettet passed round  the  survey  which has been compiled 
        with Sue Jackson's approval and  should provide useful feedback. 
        He stated that the survey is  aimed at 4 groups; Response, Focal 
        Call, CCD and NCC and aimed to find out how many of the problems 
        VAX were experiencing were particular to them or widespread.

        Norman Pettet presented the contents  of the report, showing how 
        it has been structured to  identify  strengths and weaknesses in 
        call handling, and commented that the date chosen for the survey 
        was arbitrary. He pointed out that  this  was an action agreed 2 
        meetings ago.

        10. Date for the next meeting
        -----------------------------

        Due to the shortage  of  manpower  over  the  next  two to three 
        months, another date was  not  agreed  and  will be decided upon 
        when availability allows.

        The meeting closed at 4.30pm.
    

              
              MINUTES OF THE CIG MEETING HELD ON TUESDAY 17TH MAY 
                           AT 3PM IN THE PIONEER ROOM
              
              
                Present: Ken Robb
                         Norman Pettet
                         Bruce Muir
                         Norman Bland (Chair)
              
        Norman Bland opened the meeting  by outlining the problem caused 
        by the sudden planning of  VMS  V6.1  seminars which lead to the 
        meeting being held at short  notice.  Consequently, there was no 
        formal agenda and he  suggested  that  the meeting be structured 
        around the minutes of the last meeting and to review progress on 
        the agreed actions.
             
        1. Review of Live Call Handling
        -------------------------------

        Norman Bland reminded  the  meeting  of  the  previous meeting's 
        discussion.
        
        Norman Pettet reported that he had spoken to Sue Jackson who has 
        mailed response groups requesting that  they allow the phones to 
        ring for a reasonable amount of time before hanging up. However, 
        both Ken Robb and  Bruce  Muir  reported  recent instances where 
        they had not been given enough time to answer phones.
             
        ACTION: Norman Pettet will go  back  to  Sue Jackson in order to 
        find ways to improve the situation.
             
        2. Problems of dialling out
        ---------------------------

        Norman Bland  briefly  reviewed  the  minutes  of  the  previous 
        meeting. Ken Robb reported that  he  has  still to speak to Pete 
        Alvis on this subject.
             
        ACTION: Ken Robb to speak to Pete Alvis.
             
        3. Call logging with IS and OPS support
        ---------------------------------------

        With reference to the agreed action  at the last meeting, Norman 
        Bland stated that he was still gathering feedback on problems of 
        logging calls and when he has  collected data he will bring this 
        to the attention of Murray Smith.
        
        Both Norman Pettet and Ken  Robb  commented on the importance of 
        prompt response by IS.
             
        ACTION: Norman Bland will continue  collecting feedback and then 
                pass this information on to Murray Smith.
             
        4. Back-up Systems
        ------------------

        Norman  Bland  commented  that  the  situation  seemed  to  have 
        improved  since  the  last  meeting  with  more  warning  having 
        recently been given when systems are  to  go down and no back-up 
        is being provided.  

        Ken Robb suggested that this  again  was  a  problem with IS and 
        that they should be made  aware  of  the importance of a back-up 
        system when another system is taken down down.
             
        ACTION: Norman Bland will take this issue up with Murray Smith.
             
        5. NICE Call Handling
        ---------------------

        5.1 Updating Calls
        ------------------

        With reference to the  minutes  of  the  last  meeting, Ken Robb 
        reported  that  he  has  started   designing  templates  and  is 
        currently collecting feedback on them. He outlined the nature of 
        the templates which is:
              
        - one 'A' description, with basic information
        - Update descriptions
        - Trouble  Statement  descriptions  (for  extended  analysis) in 
          place of Crash Dump Analysis descriptions
             
        The problem and solution descriptions remain unchanged.
             
        5.2 Call ownership
        ------------------

        Norman Bland reminded the meeting  of  the actions agreed at the 
        last meeting whereby he  would  sound  out  other members of the 
        group on the question  of  having  two  queues and Norman Pettet 
        would draw up guidelines on how this could be put into practice.

        There followed discussion on the question of ownership of calls. 
        It was suggested that when  a  person  puts  a  call in the wait 
        queue and then goes  off  shift,  that  when  they  come back on 
        shift, that the call remains  their  responsibility should it be 
        woken. Norman Bland  put  forward  that  Live  Call  Handlers be 
        requested to check the wait queue twice a day to flag calls that 
        have passed their LSDT, and this was generally felt to be a good 
        idea. It was  also  agreed  that  if  possible,  calls should be 
        handed over rather than going into the queue.
             
        ACTION: With reference to this  issue,  people were requested to 
                update the notes file.
             
        6. Effectiveness of group resource controller
        ---------------------------------------------

        Referring to the  agreed  actions  of  the  last meeting, Norman 
        Bland confirmed that he has spoken to Mike Ayling who has agreed 
        to  talk  to  Angie   about   establishing  Resource  Controller 
        guidelines. He also reported  that  Brian  Anthony has spoken to 
        Brian Johnson on the issue who has requested that Angie be given 
        more time to adjust to her  role. Accordingly, he has not spoken 
        to Chris Hall on the subject.

        Norman Pettet  expressed  disappointment  with  Brian  Johnson's 
        response, saying  he  felt  that  group  feeling  was  of  great 
        importance in the matter.
        
        Ken Robb pointed out that there were boundaries beyond which CIG 
        could not expect to have influence  and that the way others work 
        might be such an area.

        Norman Bland  stressed  the  difficulties  for  Angie  in  being 
        effective in so many  different  areas,  and  also that, to some 
        extent, Chris Hall already  acts  as  a  PR  man  for the group, 
        allowing the group to concentrate on their technical role.
              
        ACTION: On circulation of the  minutes,  the group will wait for 
                feedback before deciding on further action.
             
        7. Systems Statistics Review
        -----------------------------

        Norman Bland reported on  behalf  of  Brian  Anthony the opinion 
        that  System  Management  Training   was   more  important  than 
        Infoserver training. He  also  reported  that  System Management 
        Training would be running  over  the  coming  two weeks and Dave 
        Gledhill had plans to arrange more  Advanced courses. Due to low 
        availability figures over August,  it  will  not  be possible to 
        attend training then and the  group  will  have to be looking to 
        Autumn for Infoserver training.
        
        Ken Robb stated that Dave  Gledhill  had  spoken  to VMS re: the 
        group taking Infoserver calls,  and  the  response had been that 
        because this area  was  low  volume  and  VMS  already have good 
        skills in this area, that  the  movement  of  calls might not be 
        particularly productive. The situation remains under review.
        
        Norman Bland reported that  Brian  Anthony  had  spoken to Brian 
        Johnson about the group taking live VMS calls, and Brian Johnson 
        had given a positive response.
             
        ACTION: Brian Anthony will  talk  to  P,M  &  S about having two 
                phones installed for these calls.
        
        There was  brief  discussion  on  the  ACB  proposal,  it  being 
        suggested that the group looks  into  how  this product is being 
        promoted before looking at how to support it. It was agreed that 
        this needs to be researched further, and for other group members 
        to feed back on it.

        8. Media Cupboard
        -----------------

        Bruce Muir stated that he is still  in the process of drawing up 
        guidelines for keeping tabs on tapes.
        
        Norman Bland  expressed  his  dissatisfaction  with  the present 
        situation and Bruce Muir outlined proposals to improve it.
             
        9. Call Handling Survey
        -----------------------

        Norman Pettet passed round  the  survey  which has been compiled 
        with Sue Jackson's approval and should  provide useful feedback. 
        He stated that the survey is  aimed at 4 groups; Response, Focal 
        Call, CCD and NCC and aimed to find out how many of the problems 
        that Systems Diagnosis  were  experiencing,  were  particular to 
        them, or common  to  other  units.
        
        Norman Pettet presented the contents  of the report, showing how 
        it has been structured to  identify  strengths and weaknesses in 
        call handling, and commented that the date chosen for the survey 
        was arbitrary. He pointed out that  this  was an action agreed 2 
        meetings ago.
             
        10. Date for the next meeting
        -----------------------------

        Due to the shortage of manpower, another date was not agreed and 
        will be decided when availability can be determined.
             
        The meeting closed at 4.30pm.

	Hi All,

	here are my notes taken from the CIG last thursday:


	present: Brian Anthony, Brian Adams, Norman Bland, Dave Gledhill,
		 Angie Nash


	1. templates:	
	
	Most agreed that the new templates Ken has produced are much 
	better than the originals.  Most of the comments passed to
	me were about the old templates.  The new ones go a long
	way to simplifying the data input and are more user friendly
	to read.  We should try the new ones for a few weeks and
	review them again.

	The use of entering multiple "A" descriptions was discussed and all
	agreed this should stop. In summary we should use:
	A description for actions
	P description for standard update to branch
	TS for technical details
	CA for crash details (cut/paste from canasta)

	In general we thought that call write-ups (esp. bugchecks) needed to
	be clearer. For bugchecks, we need to detail the analysis in
	a logical order, and GIVE CONCLUSIONS learned so far, even if
	there are none, say so.  

	As an aside DG said when asking for dumps to be sent in we should
	ask for other info: here is part of the mail he sent me:
------------------------------------------------------------------------------
  "2. QUESTIONS TO ASK WHEN TAKING PROBLEM STATEMENT...

It seems little importance is taken to ascertaining the background to a
problem. Unless the systems crash/upgrade history is volunteered little 
attempt is made to get get this info. As a lot of calls are logged ooh/by
operators I think should make a definate step of asking to speak to the 
system manager. The update should SAY if the history is known or not.

I know a lot of dumps I get to look at there is an implication that the 
problem is a one-off, when I check further it turns out there is a whole load 
of history. This info could have been useful at an earlier stage.


3. THINGS TO INCLUDE IN THE DIAGNOSIS OF THE CRASH DUMP (ie TS)

Should include a number of things here, which are OFTEN missed out and could 
help me/whoever takes over the call, and also help the systems guy in diagnosing
the crash. (eg a check list). particularly relevant to get when dialing in
prior to tape sent in.

(I often try looking at updates of BUG/W call, there is rarely enough info to 
go on.)

SHould have a list of things to have in the update,

eg from sda

show sum, any unusual states
show pool/sum anything excessively used, running out of (if the command fails
we may have corruption).
how did we get to where we are, can find the code or not, what does show stack
and show call show.
what is the other cpu up to if on smp system.

etc...

Also, what about the hardware (considering the hardware background there seems 
little mention of it these days). The update should say what checks if any been
made, how much of the errorlog checked, if it is not available (bits missing/
didn't get written) . Other things errsnap..

4. WHAT SHOULD BE SENT IN WITH THE DUMP ON TAPE.  <<<<<read this!!!

As well as the dump how about the errorlog file(s) 
a dir/date of sys$loadable_images and sys$system *.exe and of
sys$update:*.txt.

THis will help detect any patches,3rd party stuff asa well.
(often people spend a lot of time trying to find the code in the listings,then
give up and give me the call. Normally this due to patches on the system with
the code in different places).

Can you put this on the notes file if you think ok to stimulate discussion.
This is so that we can devise a more comprehensive check list.
	
-----------------------------------------------------------------------------

	on with the minutes:

	Brian Adams will co-ordinate a review of the standard replies
	for CRD's Sysbugs etc.

	2. Live call handling (LCH)

	In general we all agreed that LCH was working as well as could
	be expected, given the call volumes and manning available in the
	group.  We noted that it was very difficult whan call volumes
	were high.  

	3. queue management, and resource controller:

	Angie noted that the problems she perceived were mainly due to
	her being remote, and us having to share her with another group.
	I have been informed that we will be getting out own dedicated
	resource controller (Shane Oliver) from January, so these
	problems will be resolved. 

	The two 'orange' people should still remain a focal point for 
	the resource controller. Angie noted that the branches do have
	visibility of the systems queue and the SLA states that if the
	branch has a problem with a call in the queue, they should call us.
	We should however, update the customer for any delay in diagnosis
	(resource controller task)

	4. Use of dumps disks:

	we thought that this should be sorted out (sorry Ken) by the
	systems managers of the two clusters, Ken and Geoff.

	I will be asking Ken to liase with Geoff to see if any rationalization
	can be done.

	5. use of DG:

	Dave said that he was reasonably happy with the current situation.
	He said it was more efficient for us to complete the call rather
	than him as he worked mainly ooh. This means we pass the call to Dave
	to sort/help out the diagnosis, when done he will put the call
	back into systems for one of us to update the customer the next day.
	(and delete dump and send back tapes/send out patch etc)
	
	Dave noted the problem of identifying the urgent BUG/D's once they
	are in the systems queue, (all at P 3). We discussed this for
	some time and came up with the idea of using the LRS field.

	LRS = A high priority (dump should be analysed ASAP)
	LRS = B normal
	LRS = C low priority e.g. customer asked us to look at a one off crash
		and the system has run ok since it bugchecked.
	 
	we can do a trial run for a couple of months to see how it works out
	
	When putting a BUG/W in SYS_WAIT update the LRS field as appropriate.

	You can see the LRS if you use the /sw swithch on list req/que/nam=
	command. 

	I think that just about covers it

	Brian