Conference kernel::csguk_systems

    
    Norm,
    
    Sound like a good idea, but why don't we follow the same pattern 
    as other groups, utilising queues for similar ideas.
    
    The queue should be  "SYSTEMS_WAIT" to match others such as VMS_WAIT
    AES_WAIT etc etc.
    
    Brian.
    

    
    	I spoke to Norm (Pettet) about the problem of calls hanging around
    	in the systems queue.  Ideally the systems queue should just be
    	for calls waiting to be diagnosed.. ie no-one has done ANY work
    	on them.  We should all aim to see this queue at 0
    
    	So I agree with Norm we should use our Hold or Wait queue for this
    	purpose.. However I think we are in danger of using it as a 
    	dumping ground.  I think we need to tighten up our act on call
    	ownership.. The only reason that a call should be in the wait
    	queue is when we go off shift (end of a shift cycle)
    	or take time out for hols or training.   If you are doing a week
    	of days and you have a call that requires the customer to take
    	some action and you are expecting the customer to call in before
    	the end of you shift cycle, then you should own the call.
    	(my opinion!)  
    
    	what do you think?

    I vote yes. The name doesn't matter but we may as well conform to 
    what our colleagues in the other parts of the VMS group are doing.  
    
    roland
    (we should never have got rid of the VAX_DEFER queue :-))

    
    Re .2
    
    I agree that we _must_ avoid having a dumping ground.
    
    If one of us has a call, where the customer will be contacting us at
    a known time, then the call owner should retain the call.
    
    I suggest that only those calls where the customer call back is
    unknown, should be in the HOLD/WAIT/DEFER queue. However, how should 
    we handle calls diagnosed OOH, where there is a need for someone to
    call the customer at the start of the next working day ????????
    
    The SYSTEMS group queue should only contain calls requiring action.
    Should this queue include those needing a call to the customer ??
    
    Brian Adams.
    

>    The SYSTEMS group queue should only contain calls requiring action.
>    Should this queue include those needing a call to the customer ??

All calls requiring action AFTER the end of the shift that first first saw the
call and BEFORE that shift starts again (e.g. nights end to nights begin) SHOULD
be in the (SYSTEMS) queue (i.e. less than 16 hours wait time).

All calls waiting for a reply from a customer, and the reply is expected while
the current call owner is working SHOULD remain in the call OWNER's queue

All calls that expect a reply from a customer, and the reply is expected at a 
time when the current call owner is NOT working, AND the expected wait time is 
MORE than 24 hours, MAY optionally be put into the (BUG_HOLD) queue.

Queue names in (brackets) subject to change as the group sees fit...

	Comments ??	JT:

    I agree with you John, the BUG_HOLD re SYS_WAIT queue SHOULD NOT be
    used as a dumping ground for requests requiring action. We all work
    shift and there can be times when we aren't in the office for an
    extended period of time or alternatively working night shift and unable
    to speak to customer. It is at these times SYS_HOLD queue can be used I
    believe -  especially when customer is going to take some action and get
    back to us.
    
    
    Norm

    
    	It seems we are mostly in agreement.
    
    	The underlying point is there should be more call/problem
    	ownership.  i.e. don't move the problem onto someone else
    	when you go home, unless you know some action is required 
    	before you return.  Going off shift is not an excuse to dump
    	a call.
    
    	o	calls are routed to SYS_HOLD only when you know
    		the customer has an outstanding action (and he will call us)
    		before you return to work.
        
    	o	calls are routed to SYSTEMS only when you know there is
    		an action on us before you return to work.  (but more
    		preferable pass to a colleague who will take on call ownership)
    
    	o	long term problems (i.e. many weeks or months), where the 
    		customer is requiring an action either by him or us should
    		be owned by a resource controller.
    
    	
    	does this fit the bill?

    The last reply seems perfectly OK to me, except for one issue. We
    currently have SYSTEMS, BUG_HOLD, MONITOR and are now proposing
    SYS_HOLD. That will be four queues + your own, I hope it is not going
    to grow any larger.
    I hope also that the SYS_HOLD (if it comes into being) does not become
    a general dumping ground. Do we need a MONITOR queue?
    
    Norman Bland

    Norm,
    
    	The proposal is to rename BUG_HOLD to SYS_HOLD not create a new
    queue. 
    
    SYSTEMS 	queue - used for LIVE requests
    SYS_HOLD 	queue - used for requests not requiring immediate attention
    			this could include monitor requests if necessary.
    
    I don't believe there is a need any longer for a MONITOR queue.
    
    

    Norm from the other Norm.
    
    Sounds fine by me now I understand. Two queues, what could be simpler.
    OK, before some wag gets in with how about one or even none :-)
    
    NB

Chaps,

	The decision has been made by the CIG to rename the BUG_HOLD queue to
SYS_WAIT. This change will take place 9-May-1994. I suggest we change the 
"Opt Typ" NICE field to reflect why the request is in the SYS_WAIT queue.
I propose the following "Opt Types" :-

Opt Type		Explanation
========		=========

BUG/W			Awaiting dump on tape
HANG			System has been hanging customer may callback
TUNE			Customer is/has adjusting SYSGEN parameter and will 
			call back
MONITOR			Customer and/or CSC monitoring
ENG			Engineer is returning to site sometime in future.


	The Opt Types BUG/D, BUG/T, BUG/A *should* not be used in SYS_WAIT 
queue as these are considered "LIVE" requests requiring attention.

The guidelines for using the SYS_WAIT queue are:-

1) Route request to SYS_WAIT queue if we are awaiting crash dump on tape as per 
   BUG_HOLD queue rules.

2) Route MONITOR requests to SYS_WAIT unless we are connected or continuing 
   monitor.

3) Requests where we are waiting for a reply, from the customer, and the reply 
   is expected while the current request owner is working, then the request 
   *should* remain in current request owner's queue and *NOT* routed to 
   SYS_WAIT.

4) Requests where we are waiting for a reply, from the customer, and the reply
   is to be expected while the current request owner is *NOT* working then the
   request should be routed to SYS_WAIT queue. The LSDT should be changed to
   reflect a date when the customer should have rung us back. 
   
5) The "LIVE" call handling engineer's will be monitoring SYS_WAIT queue, 
   should a request be found in the SYS_WAIT queue that has passed its LSDT 
   then that request will either be routed to SYSTEMS queue or the LIVE call 
   handling engineer will ring customer and action the request themselves.

6) Every effort should be made to ensure, as far as possible, that requests
   are OWNED and not routed to SYS_WAIT queue. However it doesn't make sense
   to keep routing a request to different engineer's at end of shift just to 
   avoid putting the request into SYS_WAIT queue.

7) SYS_WAIT queue is *NOT* to be used as a dumping ground for requests, 
   engineer's should try and route requests to other engineer's (with their 
   permission) queue as far as possible. This ensures request ownership is 
   maintained.

8) Long term problems, requests requiring validation, contract discrepancies or
   complaints should be routed to Resource Controller for actioning and request
   should *NOT* to be routed to SYS_WAIT. 


	To summarise:-

SYSTEMS request queue will be used ONLY for LIVE requests

SYS_WAIT request queue will be used for requests where an action is required, 
         either by customer, engineer or Systems engineer and the request
         isn't considered "LIVE". 


	Regards,

		Norm Pettet


    

    Norman,
    
    I has perused not 171.11 and I cannot see any issues yet. I will
    probably print it off and study it more carefully.
    
    The only concern I have is the following:
    
    >> The decision has been made by the CIG to rename the BUG_HOLD queue to
    >> SYS_WAIT. This change will take place 9-May-1994.
    
    I thought we were going to put this suggestion forward as an
    improvement and wait for the response of the group (i.e. those that
    were not at the last CIG meeting) rather than impose it.
    
    Please note that I am happy with the proposal - did I miss the point
    somewhere.
    
    Regards, the other Norman

    
    	I missed the CIG discussions on this so I'll put my input
    	from reading 171.11
    
    	I'm happy with the proposed change, from bug_hold to sys_wait
    
    	However I think we need to make it clear from the start that
    	the sys_wait queue will not be there for dumping calls.
    
    	So which calls should be put there?
    
    	my views:
    
    	BUG/W is ok, no change from now.
    
    	I'm not too happy with HANG or TUNE, they are too specific, 
    	i.e. there are other reasons to "hold" a call, and it give us 
    	an easy option to unload a call with this type of problem.
    
    	I'd like to see just 2 other option types:
    
    	CUST, we are waiting for a customer to take some action
    	ENG,  we are waiting for an engineer to take some action
    
    	AND for both the above, there is no action on us until
    	the engineer or customer contacts us.
    
    	I think Monitor calls should be considered 'live' and be placed
    	in the systems queue.  It is all too easy to miss a monitor if
    	it's put in a "waiting" queue.
    
    	I'm not too happy with setting up rigid guidelines for when a 
    	call should or should not be placed in the queue.  I would
    	like to see us pick up our own wait calls when back on shift.
    	e.g. if after eves, nights or week off, then any calls that you
    	have had 'waiting' should be returned to your own queue.
    
    	Brian
    	

    re. 13
    
    > However I think we need to make it clear from the start that
    > the sys_wait queue will not be there for dumping calls.
    
    That was clearly stated as an objective at the CIG, i.e. it should not
    be used as a dumping ground. It is up to all of us to ensure that it
    does not.
    
    > So which calls should be put there?
    
    It is likely, having make the above statement, that this will be found
    by previous and any new experiences.
    
    > CUST, we are waiting for a customer to take some action
    > ENG,  we are waiting for an engineer to take some action
    > 
    > AND for both the above, there is no action on us until
    > customer or engineer calls back.
    
    Other than the BUG/W, these are the only two at the moment that I see
    as relevant as well.
    
    As for a MONITOR, in general this should be someones queue but there may
    be a time when we are asked to stop monitoring but are asked to hold on
    to the call.
    Once again as long as the onus is on the customer or the engineer to
    call us, or a spefic time is given to wake up the call, then this is as
    above (sys_wait).
    
    Norman Bland

    Ref: .12
    
    Norm,
    
    	I had a word with JT and he said he was happy for the queue to be
    renamed. That means everyone else has the oportunity to voice their
    opinions before the change takes place on 9-May-1994:09:30.
    
    Ref: .13
    
    Brian,
    
    	I see no problems with using CUST & ENG Opt types, What do other
    engineer's think?.
    
    
    Norm

    
    
    I'm not happy to have the TUNE & HANG call types waiting around in
    a wait queue.
    
    TUNE calls.
    
    While I can appreciate that customers may need time to implement
    suggestions and some even get back to us with the results. 
    
    BUT.
    
    If we have made suggestions for tuning a system, we are already moving
    towards consultancy (Money) and if the customer does come back, it will
    be almost certainly to ask for more assistance. I feel that the call
    has now become 100% consultancy.
    
    The better way to handle these calls, having given the customer some 
    initial hints, is to make it quite clear that "If you require further
    help to tune your system, please log another call, referring to the
    current one, but on the understanding that the new call is
    consultancy".
    Then close the current call.
    
    HANG CALLS
    
    Similar to the above, but from experience, those hangs that are not
    attributable to tuning problems, either come back very quickly or
    hang around for a long time.
    
    My suggestion is that if a hang is not tuning (Consultancy) and is
    likely to return quite quickly, then the call owner keeps the call.
    If the hang is likely to be at some indeterminate time in the future,
    then close the current call, asking the customer to refer to it, when
    the system hangs again, and have them log a new call.
    
    Two other points
    
    NO DUMPING GROUND.
    
    NO ACTION REQD BY US, ie the customer calls to re-activate the call.
    
    Should calls stay in the Wait queue, past their sell by date, then 
    maybe the live call handlers might route them back to whoever put
    them into the queue, provided said person is available.
    A better move, would be for anyone deferring a call into the wait 
    queue, to be personally responsible for checking that action has taken
    place by the due time, and actioning the call personally if not.
    
    Brian Adams

    To summerise Opt Types:-
    
    CUST	; Awaiting customer to take an action & ring back
    ENG		; Awaiting engineer to take an action & ring back
    MON		; Monitor request that couldn't be routed to another queue
    BUG/W	; As per BUG_HOLD rules, ie awaiting crash dump on tape
    CSC		; Awaiting an action by CSC ( awaiting TA90 ? )
    
    	Reminder - the BUG_HOLD queue will be renamed to SYS_WAIT on
    
    			Monday 9th May 1994 09:30
    
    
    Norm

    Having read through all thes replies again to ensure that I haven't got
    the wrong end of the stick, I note the following:
    
    o - There appears to be general concensus for this move by positive
    comments/feedback entered; or by the total lack of any comment from
    some individuals - the assumption being made here is that that
    individual has NO reason why we should not go ahead with the change.
    
    o - There would appear to be a bit of a HANGUP on 'HANG' type calls :-)
    Do I deduce some concensus for the following.
    
      - Hangs should NOT be placed in the SYS_WAIT queue.
      - Hangs should be diagnosed and closed with customer agreement in a
        similar manner to other calls.
      - If the customer insists that the call be left OPEN, then that call
      - stays in the individuals queue (unless the call is escalated to
        another individual).
    
    Comments please.
    
    Something that was discussed at the last CIG meeeting (28/APR/94), from
    which I had an action placed on me, was the management of calls in the
    SYS_WAIT queue. It is all very well saying that the ONUS is on the
    CUSTOMER or ENGINEER call back to 'AWAKEN' a call but we all know that
    this will not always happen at the expected time. The following was put
    forward a a proposal.
    
    LIVE CALL handlers should as a background task, MONITOR the calls in the
    SYS_WAIT queue to see if the LSDT has expired. If it has they should
    arrange for another group member to action that call (NOT themselves -
    if they are on the phone, it makes it more difficult for them to handle
    live calls). This relies on the indivdual who places the call in the
    SYS_WAIT queue to put a realistic time (as agreed with customer/engineer)
    in the LSDT field (it's better here than embedded in a an 'A'
    description as it can be seen more readily). If the action has not be
    carried out by customer or engineer and they need more time, then
    simple update the call with the new (agreed) LSDT and place the call in
    the SYS_WAIT queue again. The above action should help in preventing a
    call getting abondoned because no one called back. I see a scan of the
    SYS_WAIT queue, once in the morning and maybe once in the afternoon as
    sufficient (minimum overhead on live call handlers).
    
    Comments please.
    
    Norman Bland
    

    
    In an ideal world, the customer/engineer would call back by the
    agreed time. this would make the queue self managing.
    
    However as this will not be the case, I agree that the live call
    handlers should eyeball the queue twice a day and get someone to
    deal with any expired calls.
    
    As a belt & braces option on this, we could also expect that whoever
    originally puts a call "on ice", has a duty to check that an agreed
    action occurs at the appropriate time. eg I place a call into the
    queue, prior to going on leave/course etc. If action should take 
    place while I'm away, then when I return, I must check that the call
    has been actioned, and handle it, if not.

    
    A further thought, having seen some calls still untouched when 
    starting evening shift :-
    
    Should the "live call handlers" also ensure that any priority 4
    call, left overnight, is dealt with on time next day. I don't mean
    that they personally handle the call, but prompt A.N.Other to do so.