Software support service checklist

In order to understand and resolve your software support service request in the most expedient way, it is important that you gather information about the problem and have it on hand when discussing the situation with the software specialist.

The following problem information is required:

Definition of the problem
It is very important that you are as specific as possible in explaining a problem or question to our software specialists. Our specialists want to be sure that they provide you with exactly the right solution. The better they understand your specific problem scenario, the better they are able to resolve it. To assist you with problem identification, seess the Problem Resolution Worksheet (Appendix A).
Background information
If possible, obtain all data about a problem soon after the problem occurs. Otherwise, updates to the system can cause discrepancies in the data. Ask yourself the following questions:
- What levels of software were you running when the problem occurred? Include all relevant products, for example: operating system and related products.
- Has the problem happened before, or is this an isolated problem?
- What steps led to the failure?
- Can the problem be recreated? If so, what steps are required?
- Have any changes been made to the system? (workload, hardware, netware or software)
- Were any messages or other diagnostic information produced? If yes, what were they?
- It is helpful to have the message number(s) of any messages received when you place the call for support or to document in the ETR.
- Define your technical problem statements in specific terms and provide the version and release level of the product(s) in question.
Relevant diagnosis information
It is often necessary that our software support specialists analyze specific diagnostic information, such as storage dumps and traces, in order to resolve your problem. Gathering this information is often the most critical step in resolving your problem. Product specific diagnostic documentation can be very helpful in identifying what information is typically required to resolve problems. You should keep all problem data until the problem is resolved or until the data is successfully transmitted to IBM®. The following are examples of problem data that the support center might ask you to provide:
- Any changes made to the system recently, preceding when the problem began occurring (for example, PTFs or new products installed or new hardware).
- Problem type (for example: abend, hang, loop)
- Search arguments
- Dump data, see Invoking IPCS as a background job
- Failing input request: macro, command, or statement
- SDWAVRA keys, lengths, and contents
- Offset of the failing instruction into the module or CSECT
- Accompanying messages: identifiers and texts
- Logrec report, if used
- All printed output and output data sets related to the problem
- Data on any related problems
- Module name and level
- Name and level of the operating system(s) with a list of program temporary fixes (PTF) applied at the time of the problem and all installation modifications, exits, and products with other than Class A service
- Other problem data developed while using the diagnosis book for the component, subsystem, or program

Severity level

You must assign a severity level based on the business impact of the problem you are reporting. The severity levels and examples table contains the descriptions of the severity levels.

Table 1. Severity levels and examples
Severity	Definition
1	Critical Impact/System Down: Business critical software component is inoperable or critical interface has failed. This indicates you are unable to use the program resulting in a critical impact on operations. This condition requires an immediate solution.
2	Significant impact: A software component is severely restricted in its use, causing significant business impact. This indicates the program is usable but is severely limited.
3	Moderate impact; A noncritical software component is malfunctioning, causing moderate business impact. This indicates the program is usable with less significant features.
4	Minimal impact; A noncritical software component is malfunctioning, causing minimal impact, or a nontechnical request is made.

Mention the following items that apply to your situation:
- If you are under business deadline pressure
- When you are available (for example, when you will be able to work with IBM Software Support)
- Where you can be reached
- A knowledgeable alternate contact with whom IBM can speak
- Other open problems (PMRs/Incidents) with IBM regarding this service request
- If you are participating in an early support program (ESP)
- If you have researched this situation before calling IBM and have detailed information or documentation to provide for the problem.