How to Submit a Technical Solution to Novell
Articles and Tips: tip
01 Mar 1997
Many of you are familiar with the Technical Information Documents (TIDs) that Novell's Technical Support Division provides. Although these TIDs cover a wide variety of issues, Novell recognizes that the channel and end-users solve many problems that are not completely documented in the information Novell provides. Novell now offers the ability for Novell Partners and customers to prepare and submit their own solutions to Novell so that others won't have to go through what you just did when troubleshooting a networking problem.
While this may sound like a labor of love, realize how invaluable your technical expertise can be to those who are just coming up to speed or who can't find an answer to a particular networking problem. And isn't that the basic purpose of online chat forums and magazines such as this one? The ability to write up your solutions allows you to include your expertise as part of the information base that benefits the channel as a whole.
All problem-solving information that is received by Novell must first be verified by our support engineers. It is then published in TID format in all of Novell's electronic distribution media: the Novell Support Connection web site, the Novell Support Connection CD-ROM, NetWire on CompuServe, and the Novell FaxBack service.
Any Novell Service Partner who has a Novell Personal Identification Number (PIN) can enter a Solution Document by going to the Novell Support Connection web page at http://support.novell.com and selecting the Partner Options link. From the Partner Options page, select the Solution Submission link. You'll see a Solution Document page similar to the one shown in Figure 1.
Figure 1: Novell Support Connections' Solution Document entry page
Here, you must fill out the submission form that includes your last name, your Internet e-mail address (for notification regarding the submitted information), and your PIN. (This requires that you have a current service agreement with Novell. If you do not have an active PIN, call 1 800 858-4000 or contact your local support center.) Click Continue after reading the terms of agreement.
You are given a number of choices to properly categorize your solution. First, select the Product Class to which the product belongs; click Continue to further select a specific product from the list of available products. Finally, select a product module for the product you selected. This brings you to the Solutions Document page, where you will see the following headings:
Title (required, 45 character limit)
Under each heading there is an "Example" link that takes you to the related information in the help file. Let's look at each of the headings and see what constitutes good and bad examples.
Title of the TID
When selecting a title, be specific to the problem that is being addresses in the TID. If at all possible, fit the exact error message in the title--do not paraphrase. Titles can only be 45 characters long, so be exact. Use initial capital letters for each word in the title.
Examples of good titles are:
NE2000.COM 11/25/XX Causing GPF In Windows
NWDRV-3.00-30 Unicode Table Error
Examples of bad titles include:
Problem with NE2000 Card
The bad example titles are not specific enough to identify the problem and can be misleading. Even though the information contained in the TID would probably solve the problem of the person who is searching for answers, the title is not specific enough to entice the person to read the TID. Since the title is the key to the rest of the solution, it must be accurate and descriptive.
Use the Symptoms heading to describe completely the problems that the user or administrator actually sees. If the problem is an error, type the exact syntax of the error. Errors that are incorrectly typed will not be found when the error is typed in the search field. The more complete the description of the symptoms, the easier it will be to find the problem and solution.
An example of a good Symptoms field entry is:
The user was getting the error "NWDRV-3.00-30. There was a problem loading the unicode tables. All NetWare Directory Services functions are disabled" while starting Windows for Workgroups. The problem started happening after upgrading Windows 3.1 on the workstation to Windows for Workgroups.
An example of a bad Symptoms field entry is:
I got an error about being unable to load the unicode tables when trying to start Windows.
Administrators will look at the Symptoms heading after scanning the list of titles to see if the problem/solution that is given relates to the problem they are experiencing. If the symptoms are not clear or poorly written, the TID is usually rejected as a valid source of information--even if the solution fixes the problem. Make the symptom description clear, descriptive, and use the correct syntax.
Use the Causes field to describe completely the cause of the problems that the user or administrator actually sees. The more complete the description of the causes, the easier it will be to find related problems that are not addressed by the TID.
Many times a TID will be the source of a solution even if the solution itself is not contained in the TID. This happens when the TID causes the administrator to start another line of troubleshooting that leads to the eventual solution of the problem.
An example of a good Causes field entry is:
The error was caused because the wrong version of NETWARE.DRV (xx/xx/xx) existed in the WINDOWS\SYSTEM subdirectory.
Examples of bad Causes field entries are:
Wrong Driver loaded.
The Causes field is left blank.
Use the Troubleshooting field to describe the steps taken to troubleshoot the problem. The more complete the description of the Troubleshooting steps, the easier it will be to find solutions related to problems that the TID does not address.
An example of a good Troubleshooting field entry is:
The user booted the workstation, reloaded WFWG, updated the NE2000.COM driver from xx/xx/xx to xx/xx/xx, and removed the W16 jumper from the NE2000 board.
Examples of bad Troubleshooting field entries are:
Updated the driver, reloaded the software.
The Troubleshooting field is left blank
Use the Solution field to describe the complete steps that you used to solve the problem. The solution should be specific, listing names and dates of drivers, exact filenames, and any other information used in solving the problem.
An example of a good Solution field entry is:
Copied the updated version of NETWARE.DRV (xx/xx/xx from the 1.21 version of the NetWare DOS Requester found at http://support.novell.com/home/client/doswin/) to the WINDOWS\SYSTEM subdirectory. Rebooted the workstation and the problem was solved.
An example of a bad Solution field entry is:
Updated NETWARE.DRV and the problem went away.
The Hardware Configuration field is used to link related hardware problems. If all TIDs have correct hardware information, problems related to hardware platforms can be more easily identified.
Examples of good Hardware Configuration field entries are:
Compaq Proliant 2000 Model 5/66
Dell SCSI Array Controller/Driver - A06
Examples of bad Hardware Configuration field entries are:
No information listed at all
The Software Configuration field is used to link related software problems. If all TIDs have correct software information, problems related to software platforms can be more easily identified.
An example of a good Software Configuration field entry is:
VLM 1.2, Windows 95, WordPerfect for Windows v6.1
Examples of bad Software Configuration field entries are:
No information listed at all
Some Last Guidelines
Many times a TID will be the source of a solution even if the solution is not contained in the TID. This often happens when the TID causes the administrator to start another line of troubleshooting that leads to the solution of the problem. Take the time to make your entries as clear and descriptive as possible. Throughout your TID, use third-person language; in other words, use "the user" rather than "he or she" or "I."
As a final note, do not use the solutions submission form as a request for technical support or to ask technical questions. You can submit technical questions to Novell through the Electronic Incident feature (go to http://support.novell.com/partner/ and select the Electronic Incident link).
Information and solutions are vital to the continuing success of the networking industry. Novell recognizes that we solve and document only a fraction of the solutions that the industry solves. Please take the time to contribute your solutions to the rest of the industry!
* Originally published in Novell AppNotes
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.