Contact technical support

Once you've determined to the best of your abilities that the problem isn't some misunderstanding of the function call or utility you're using, or a mere typo, you may enter the realm of QSS's technical support department. This is nothing to be afraid of — most customers are extremely pleased with the level of technical support they get from QSS.

There are two ways of contacting QNX's technical support group: by phone or via the web. QSS's website (at http://www.qnx.com), has a Community area called Foundry27, at http://community.qnx.com/sf/sfmain/do/home which is full of useful information and files.

Before we talk about which method you should use, there are a few things you can do to make the turnaround time on your bug report much shorter.

Describe the problem
Often customers try to fix the problems themselves by trying various things that come to mind. This is great. Unfortunately, what tends to happen is that customers get frustrated and post messages something like:
Precise information
To supply this information, state what you had expected to happen, and what actually happened. In our above example, a much better problem description would have been:
Versions
The next thing that you should supply is the versions of the various commands that you may have been using. This can be done by using the ls and cksum commands. For our example above, you'll want to tell tech support which version of the telnet command you were using, and the version of the TCP/IP protocol stack etc.
If you're using a beta…
If you're using a beta version of the product (i.e., you're on QSS's list of beta sites), all the above information is critical, because you'll typically be using different versions of the software than what is released. Note, however, that the technical support department generally doesn't handle telephone support of beta products. The only way to get help on these is to post in the conference or, if the developer has requested direct contact, talk to the developer. Posting is generally the best solution anyway, because then other members of the beta conference can see what problems are out there and can learn what the solution is (i.e., if it's a bug, what the workaround for it is). In any event, the above information is crucial in order to determine which products you have from the beta release and which ones are stock.
Reproduce the problem
One of the first things that tech support usually wants to know is, Does it happen just once in a blue moon, or can you make it happen on demand?
Narrow it down
Even if it's reproducible, tech support most likely doesn't want to see 6000 lines of C code with a problem buried in the middle of it.

Parent topic: Calling 911