Question:

I don't have many problems with Warp, but when I do, I rarely get an answer when I post a question on the mailing lists or newsgroups. Why is this happening to me?

Answer:

Most likely, it's happening because you are not reporting the problem so that others can easily help you. OS/2 users are generally a helpful bunch, but they can't help you if you don't explain your problem so that others can be understood what you are saying. You want to make it easy for them to help you.

A problem report, to be useful, must contain sufficient detail and, at the same time, must not contain too much detail. Like you, other folks are busy too. They would prefer to not have to ask obvious questions and they would prefer not to have to wade through irrelevant details.

You must clearly state what the problem is, as you understand it. If you got a trap, you must state the kind of trap - kernel trap or application trap.

You should give a brief description of what you were doing when the problem occurred. If the problem requires a specific set of actions to recreate, you must state them. If the problem appears to occur randomly, state this.

Keep in mind that many OS/2 users may not be native speakers of your language. Keep your statements simple and direct.

Regardless of how frustrated you are, try to avoid complaining. This is rarely productive.

Before you post a request anywhere, you should do yourself a favor and spend a little time at

In the case of an application problem, it's never a bad idea to check any readme files that might have come with the application. These often contain workarounds to known problems.

If the error was accompanied by a message, you must report the message exactly as it appeared. If your memory is not perfect, keep pen and paper near your computer.

If the error report includes a register listing, you must report at least the cs:eip values. The entire list is better. If you would prefer to avoid writing down the screen full of numbers that comes with a kernel trap, use one of the tools that will record the information for you.

In these days of huge disk drives, the best solution is to install a trap dump partition. This will give you easy access to the registers along with more information than you will probably ever need.

If this is difficult on your setup, you can use DumpTrapScreen. There is also an older version of this tool on eCS CD#3. Look for regdump.cmd. These tools will extract the registers from the first diskette of a trap dump. See the TRAPDUMP help in the command reference for instructions on how to set up to record a trap dump.

The values themselves may not mean much to you, but the location of the trap is often the key to recognizing that your problem is a known problem with a known fix. You should plug the cs:eip value into a Goggle search before posting any requests for help.

Try to avoid giving too much irrelevant detail. Knowing that you are running a Blowfire motherboard is rarely useful when you have a dialup connection problem. In some obscure case, it may be relevant, but the information can always be provided later.

What is always relevant is the version of OS/2 you are running and with the FixPak level. If you are running a nonstandard kernel you should note the kernel date and revision level.

If the problem is an application failure, the version of the failing application is always relevant.

If you have a TCP/IP problem, the output of inetver is always relevant.

If your NIC does not work, the content of protocol.ini and lantran.log is always relevant as is the model number of your NIC and the driver version.

If the problem started when you made a change, don't forget to mention this along with what was changed.

If the problem requires specific steps to recreate, be sure to list them.

If the problem started after a crash or some sort of hardware failure, be sure to mention this.

If you have a popuplog.os2 report, be sure to include it. If you don't know what a popuplog.os2 is, read up on the SUPPRESSPOPUPS command and enable popuplog recording on your system.

Including extensive directory listings with a problem report are rarely useful. You can't always depend on the dates and sizes to clearly indicate which version of the software you are running.

If you have an Odin problem, use OdinBug to prepare the problem report. You'll find OdinBug in your System32 directory. OdinBug is an native OS/2 application, so don't try to run it with pe. It's also a good idea to read ReportingBugs.txt, which is in your top level Odin directory. This will help you understand the type of information the Odin developers need to resolve your problem.

OS/2 includes an extensive set of Problem Determination Tools. What is not included is extensive tutorials on how use these tools. Regardless, it's a good idea to review the .doc file in \os2\system\ras to get an idea of what's available. The files are text files that can be read with e or epm.

Once you understand your problem well enough to explain it to others, you need to consider the best place to post your request for assistance. Some folks tend to post to every list and group they can think of. This is usually not the most effective method. You may get multiple responses. However, if your problem is a known problem, you will get multiple duplicate responses which is no more helpful than a single response.

There's also a tendency for a post to multiple lists or groups to be ignored. Everyone concludes that someone else will answer elsewhere. After a few days, the post is forgotten by everyone, but you.

On the other hand, if your problem is not a known problem, you might find it difficult to keep track of multiple responses from multiple lists while troubleshooting the problem and trying suggestions.

It's usually better to limit your postings to a minimum set of lists or newsgroups. The OS/2 community is small enough and eclectic enough that users tend to monitor multiple lists and groups. If you post to the groups that are most relevant for your problem, it's unlikely that it will not be seen.

If you have an application problem and there's a support list or newsgroup for the application, that would be the obvious place to post first. If this does not result in a solution, you can always post to the more general lists and/or newsgroups later.

Finally, while your system is going up in smoke, keep in mind that while this is the first time you have seen this problem, it's probably not the first time the problem has been seen, even if Google does not provide an answer. Your goal is to provide enough information so others can easily recognize your problem as one with a known solution. If you are unlucky enough to have encountered a previously unknown problem, you want to minimize the effort it will take to find a solution. While all this is going on, watch out for the alligators.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.