An Approach to Dealing with Technical Problems

1
An Approach to Dealing with Technical Problems
UKIUA Roadshow April 2004

• Steve Roberts Acebyte Ltd
• www.acebyteltd.demon.co.uk

2
Abstract

• This session will discuss an approach towards
• dealing with technical problems and issues that
  arise
• in a support and development environment.
• Although biased towards CA-Advantage IDMS the
• session deals with approaching problem solving
• in a generic sense rather than addressing any
  specific
• IDMS problems.

3
Content

• Attitude
• Approach
• Support
• Problems sources
• Dealing with CA Support

4
Content

• Attitude

5
Attitude

• The key to solving technical problems is to have
  the right attitude towards dealing with the issue
  that has arisen.
• Having the wrong attitude in your approach will
  cloud the issue, waste time and potentially
  antagonise the people that you interact with when
  dealing with the issue

6
Attitude

• Wrong, wrong, wrong
• The software doesnt work
• Theres something wrong with IDMS, it keeps
  making my program abend
• Its not doing what Im telling it to do
• Ive been in IT for 30 years, do you think I
  havent checked that my JCL is pointing to the
  right datasets. Blah Blah Blah

7
Attitude

• Your first thought should always be
• What have I/we done wrong ?

8
Attitude

• Its the simple things that catch you out
• Check the basics
• Check the Obvious
• Dont Assume
• Prove it

9
Content

• Attitude

• Approach

10
Approach

• Problems differ in cause, effect and the impact
  that they have. Therefore depending on the type
  of problem or impact it has will determine the
  specific approach taken.
• However, the general approach should be the same.

11
Approach

• What is perceived to be the problem ?
• Always try and get a clear description of what
  the problem is perceived to be. When possible
  talk to the person who is having the problem.
• How does the problem show itself ?
• Actions ? Effects
• Is the problem isolated ?
• Is is affecting more than one user ?
• Is it affecting more than one program
• Are other systems affected ?

12
Approach

• Is the problem recreatable ?
• Does it occur every time the action is performed
  ?
• Does it occur whatever data is used ?
• What has changed ?
• User Action
• Program
• Database
• Environment

13
Approach

• What supporting materials are available ?
• Messages / Error Codes
• Screen Shots
• Output Listings
• Dumps / logs
• Compile Listings (ideal)
• Source Listings (not ideal)

14
Content

• Attitude

• Approach

• Support

15
Support

• Tracking System
• Knowledge Base
• Site Contacts
• Escalation Procedures
• Line Management
• Authority

16
Tracking Systems Knowledge Bases

• A tracking system is a process that allows you to
  log and track the status of a problem
• Knowledge bases generally are tracking systems
  but also allow the ability to assign and search
  on keywords to find previously reported issues
  and solutions
• Most tracking systems are not knowledge bases
  because they lack the fundamental feature of
  keyword assignment and searching

17
Tracking problems

• Have a system in place to record your problems
• A manual process if nothing else exists,
  recording in a book or file
• This allows you to
• Document
• Provide Ownership
• Prioritise
• Track
• Review
• Escalate

18
Tracking System

• Have a process in place to log and track problems
• Use the official tracking system if there is one
• If it doesnt support keyword assignment or
  searching, try and find a way to look back at
  previous issues
• Perhaps you could use your User ID as part of the
  description
• If there is no official tracking system
• Record it manually in a log book
• Use PC facilities to log it
• The post-it note tracking system tends not to
  work very well

19
Knowledge Bases

• Your own knowledge
• Your colleagues knowledge
• In-House Help systems
• Tracking Systems
• CA Support Connect
• Other Vendors Knowledge bases
• User Group Forums
• Intranet / Internet

20
Site Contacts

• Try and maintain an accessible list of contacts
  in -
• Operations
• Ops Support
• Op System Support
• Development
• Help Desk
• Line management

21
Escalation Procedures

• If you provide support you should clearly
  document and make available your escalation
  procedures.
• If you are a customer of a support provider you
  should make yourself aware of their escalation
  procedures.

22
Line Management

• Needs to Provide
• Escalation
• Reporting Path
• Conflict Decision
• Authority
• Liaison
• Shield
• Resources

23
Authority

• You need to have the necessary authorities to
  deal with issues
• This does not mean that you always have the
  authority to do everything
• You should have necessary authorities in place
  for your normal working practices
• There should also be a process in place that
  allows additional authorities to be granted when
  required

24
Content

• Attitude

• Approach

• Support

• Problem Sources

25
Problem Sources

• Personal
• Problems you encounter performing your own
  workload
• Reported Problems
• Problems reported outside your group usually
  through a help desk or tracking system
• Development
• Compilation, data definition, data, access, run
  time performance issues
• Production
• Normally higher priority and often critical

26
Problem Sources - Personal

• Do you have personal problems ?
• What have I done wrong?
• Does what I am doing make sense?
• Check the obvious, do not assume
• Correct version/library/data/JCL
• Get someone to check what you are doing

27
Problem Sources - Personal

• Re-run with different data or in a different
  environment Is it recreatable ?
• What differences are there ?
• Has this ever worked ?
• Collect supporting materials
• Check knowledgebase's

28
Problem Sources - Personal

• Log your problem on your tracking system
• Describe the problem clearly
• Document checks already performed
• When resolved, clearly document the solution
• Review the problem to determine if it can be
  avoided in the future

29
Reported Problems

• Contacts
• Reporter
• End user contact
• User ?Helpdesk ?You
• Details get lost in translation
• Where possible speak to the end user

30
Reported Problem

• Determine Impact
• Repeatable or Re-creatable
• Users affected
• Where are they ? What floor ? What Building ?
• Data affected
• Systems affected

31
Development Issues

• Program Abends/Functionality/Performance
• Insist on access to the compiled listing
• If run time doesnt match insist on
  re-compilation and recreation
• Where not feasible access to source listing is
  not ideal but better than nothing
• Check the obvious

32
Production Issues

• Symptoms
• Whose affected
• Whats affected
• Critical / Non-Critical
• Collect Supporting Materials

33
Production Issues - Critical

• Dont panic, assess the situation clearly before
  deciding on a course of action
• Shield yourself
• Deal with the issue not the constant queries
  about the issue
• Either your line manager should deal with this as
  they should be part of the escalation process or
  appoint someone else in the group to deal with it

34
Production Issues - Critical

• For business critical situations where the issue
  is seriously affecting the business process, you
  must already have or a process to obtain the
  necessary authorities to deal with the situation.
• Authority to cancel tasks/programs/jobs
• Authority to recycle the CV

35
Production Issues - Critical

• Data recovery situations
• Clearly define what is required
• Do not rush into anything as you may damage your
  recovery path
• Best advice seen in a recovery manual
• Task 1 Sit down have a cup of coffee and think
  about what you need to do next

36
Production Issues

• Critical Signs
• Anytime you check a CV you should perform a
  health check by looking at
• the systems critical signs
• CPU I/O
• Access
• Journals
• Logs (DC JES)
• Workload
• Pools (Storage Program)

37
Critical Signs

• CPU
• Is CV using CPU ?
• Is it maxed out on an engine ?
• 25 on a 4 engine box running uni-tasking
• No CPU or just ticking
• No work to perform or not getting dispatched

38
Critical Signs

• I/O
• Is CV performing I/O ?
• Little or no I/O buts lots of CPU ?
• possible loop

39
Critical Signs

• Access
• Can you access the system ?
• DC
• CICS

40
Critical Signs

• Journals
• Display the journals ?
• Ideally 1 active others should be free
• If other journals show offloading or condensing,
  are the offload jobs OK
• Is the active journal being updated ?

41
Critical Signs

• Logs
• Look at the last messages written to the jeslog,
  anything unusual ?
• Oper w crit log to see how full the log is
• Does it need offloading ?
• Check log offload jobs
• OLP to check last message written to the DCLOG,
  anything unusual ?

42
Critical Signs

• Workload
• Is CV processing a workload ?
• OPER W AC TA
• OPER W DB
• Are tasks turning over (I.e. tasks ending and new
  tasks starting)
• Any tasks hanging around ?
• Whats being waited on ?
• DCMT DIS ACT TASK

43
Critical Signs

• Pools
• Are storage pools OK ?
• DCMT DIS ALL STOR
• Any SOS ?
• Check LOCKMON Status for overflow
• Are program pools OK ?
• Ideally should only see loads into unused space

44
Content

• Attitude

• Approach

• Support

• Problem Sources

• Dealing with CA Support

45
Dealing with CA

• Technical Support are there to help and support
  you
• Its an important relationship
• Listen
• Dont be arrogant
• Be Honest
• Dont use them as a scapegoat
• Educate them in your business

46
Dealing with CA Support

• Listen
• For what information they require
• To what they suggest
• CA will check the obvious first
• A large percentage of issues logged with CA are
  user created problems
• If you are asked to check something that you have
  already checked. Tell them you have checked it
  but you will check it again (i.e. prove it to
  them)

47
Dealing with CA Support

• Listen
• Remember CA have access to a larger knowledge
  base about issues than you have
• If there are 9,999 issues saying X happens
  because you have done Y, then dont argue about
  it. Check it out. In other words check the obvious

48
Dealing with CA Support

• Dont be arrogant
• OK you have used IDMS for 30 years, but dont
  dismiss something just because you think thats a
  mistake a junior DBA would make.
• Be humble, admit it when you were wrong
• The worst customers are those who dismiss every
  CA suggestion with No its not that, without
  even considering it as an option.

49
Dealing with CA Support

• Be Honest
• Whats Changed ?
• Nothing. It wasnt me I havent been anywhere
  near it
• Tell them everything you have done.
• Dont leave out something that youve done which
  you think you shouldnt have done
• We all make mistakes, admit it when you have made
  an error

50
Dealing with CA Support

• Be Honest
• Dont cry wolf !
• Be honest with your assessment of your issue
  priority
• If you report every issue as critical and keep
  hounding CA for a resolution how are they
  supposed to re-act when you DO have a business
  critical issue ?

51
Dealing with CA Support

• Dont use them as a scapegoat
• If a problem persists and has been outstanding
  for a period of time, dont blame CA unless you
  have always promptly provided the feedback they
  have requested
• Remember CAs tracking system tracks everything.
  If your manager calls CA and starts asking why
  has it taken six weeks to resolve a issue, can
  you be sure CAs tracking system will not show
  that they have been waiting 5 and a half weeks
  for you to provide information they have asked
  for ?

52
Dealing with CA Support

• Educate them in your business
• CA technical support deal with hundreds of
  different issues related to many different
  businesss.
• They become isolated from the day to day demands
  that constrain DBAs, (i.e. change control,
  scheduling) but they are not unsympathetic.
• Some issues will seem minor to them but may be a
  major problem to you because of the way your
  business uses it.
• CA will want to know when an issue is business
  critical so that they can react appropriately.

53
Dealing with CA Support

• Educate them in your business
• Document in issues logged with CA or discuss with
  the CA technician the reasons why a specific
  issue is a concern for your business.
• Also CA will say all you have to do is . Most
  of the time DBAs cannot simply just Do it.
  They are constrained by change control, timing
  issues and resources to perform tasks. Again make
  CA aware when you cannot just Do it, give them
  an estimate when you can try to Do it, they
  will log this and check back with you at the
  appropriate time.

54
Dealing with CA Support

• Salesmen
• Do not confuse sales people with the CA
  technical support people.
• Salesmen come and go (quite often) but the
  technical professionals remain.
• Do not let your good relationship with CA
  technical support be tainted by problems or
  issues you have with the sales people.

55
Dealing with CA Support

• Escalation
• Contact the local CA technician dealing with your
  issue
• Discuss your concerns with them
• Ask them to increase priority
• If you yourself are getting pressure to resolve
  the issue make them aware of this (but dont say
  you are when you are not)

56
Content

• Attitude

• Approach

• Support

• Problem Sources

• Dealing with CA Support

57
Summary

• Right Attitude
• Consistent Approach
• Build positive relationship with CA support

58
Questions
?