SupportLine -- or whatever IBM calls its phone-based technical support service these days -- is great once you get through and if you reach a knowledgeable staffer. However, what you may not know is that you have some of the same tools IBM reps have to try to find a fix to your problem. Doing it yourself can save you considerable time and get you a fix fast.
Seven steps to solve IBM software problems
Many of you may be familiar with the Analyze Problem utility built into OS/400 as it relates to messages sent to the QSYSOPR message queue. Sometimes an error message sent to the QSYSOPR message queue has an asterisk in front of it. This indicates that you can analyze the problem using a built-in utility by simply placing the cursor on the message and pressing F14.
The Analyze Problem utility is a good tool to help pinpoint the source of a hardware problem and guide you to a solution. But you can also use it to report software problems to IBM and automatically download PTFs. Here's how:
- Identify the problem. Look in the job log to locate the error message that describes the problem. Usually, this is the last escape message listed. For your initial attempt, go to the bottom of the job log and work your way backward until you find the last escape message. Then, make a note of the message ID, the "from" and "to" programs, and any error code(s) listed in the text of the message.
- Run the analyze problem utility. You can start the Analyze Problem utility directly from the command line with the ANZPRB command (You don't have to have a message on QSYSOPR with an asterisk next to it.) Assuming the problem is on your local AS/400, enter "ANZPRB *LOCAL." On the next screen choose either option 5 (problem during IPL) or option 6 (describe a job or program problem). If you choose option 5, IPL problem, the utility will step you through a series of questions -- simply follow the prompts. If you choose option 6, the analyze problem utility will next step you through a series of one or more screens so you can identify the failing component -- following the steps below.
- Select the erring component. You start with a list of all the licensed programs installed on the system and progressively narrow the selection until you are down to the component level. This part can be a little tricky if you are not familiar the components, but you can just make an educated guess -- it is not as important as getting the correct error message ID (step 1).
- Enter the message information. After you have selected the component, you will see the Specify Message Information screen. Here is where you enter the message information you collected in step 1. If the message text did not contain any type of error code, leave the Code field blank. Press Enter after completing the information.
- Specify a description. The next screen lets you enter a description for the problem. This is more for your use than IBM's, so enter something meaningful to you. When you analyze a problem, the system makes an entry in the problem database on your system. You can later work with the entries in this database (using the WRKPRB command) and the text you enter on this screen will help you identify the entries.
- Don't save APAR data. The next screen allows you to save information, such as job logs and spool files, you can use later in the rare event IBM turns the problem into an APAR. At this point, don't trouble yourself with this information; just enter an 'N' for Save APAR data.
- Prepare the service request. The next screen is the Report Problem screen. Choose option 1 (Prepare service request). From here, the process is similar to the SNDPTFORD command (Send PTF Order). The Verify Contact Information screen is shown followed by the severity and service provider selection screens. Finally, the reporting option selection screen is shown where you can choose to either report the problem now (option 1) or save it and report it later (option 2).
When you report the problem, the IBM database is searched
When you report the problem electronically via IBM's Electronic Customer Support (ECS) system, your system connects to an IBM system. The IBM system then searches its problem database for a record of the problem. If it finds a match and a PTF is available, the PTF will be downloaded to your system. If it cannot make a match, the IBM system will then assign it a problem number (i.e., service number) and log the problem (actually, even if a match is made, a problem number is always assigned). If needed, you can use the problem number later to follow-up on the problem with IBM.
A 90% hit rate
When a PTF already exists for the problem, we have experienced a 90% hit rate. Nine times out of 10, the IBM system will match the message information and download one or more PTFs. Furthermore, the downloaded PTFs almost always fix the problem. However, this hit rate is largely dependent on how carefully you collect and enter the problem information. Items such as message IDs, error codes, and the "from" and "to" programs are critical.
Use the WRKPRB command to report an unreported problem
If you need to go back and work with a problem that has already been described (e.g., you took option 2 on the reporting option selection screen and you want to report the problem now), you use the WRKPRB command (Work with Problems). You can just type "WRKPRB" and press Enter, in which case all the entries in your system's problem database will be shown. Or you can prompt the WRKPRB command and enter either the service number (i.e., problem number) assigned by the IBM system or the problem ID assigned by your system.
If you did not make a note of these numbers when you analyzed the problem, you can enter other information to help narrow the search. For example, you can display only those problems that are at PREPARED status or you can enter the date and time interval during which you remember creating the problem entry.
Ultimately, you will see the Work with Problems screen ,which will have a list of problems. Problems that have been analyzed, described and reported have a SENT status. Those that have been only analyzed and described, will have a PREPARED status, indicating that they are ready to send electronically. To report such a problem, select it with an option 8 (work with problem), then take option 2 on the ensuing screen (report problem).
-----------------------------------
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years experience programming for and managing AS/400-iSeries systems.
==================================
MORE INFORMATION
==================================
- General diagnostic process for WebSphere problems
To analyze problems running a WebSphere application, most users would agree with the "ugly" IBM support first response, "Have you applied all the PTFs you need for: OS/400, the HTTP server, WebSphere and Java?" Now that you've checked and the answer is yes, where do you go from here? Web development expert Jim Mason tells you.
- Squeezing more information out of DSPPTF
DSPPTF can be used to display PTF information for one individual product. However, with so many OS/400 products and features installed on a typical iSeries system, it can be a headache paging through every product using LICPGM(*ALL). There is another way that's a little faster and lets you search for specific PTFs number, PTF status indicators or certain information strings.
- Display a PTF without knowing the product number
Have you ever been in the situation when an IBM support employee asks you several times, "Do you have PTF SFXXXX installed?" They ask this without mentioning the product number. If so, you might want to try Sietse Witzenburg's command XDSPPTF.
