How to get help

In order to improve the efficiency of the lab's operations, we would like to set a few guidelines for obtaining help with problems. This document is intended to assist you in deciding who and how to ask for help. It deals mainly with the computers and their software. The first section is an outline of the procedure you should follow to report a problem; the second is a more complete description, with examples; the third is a list of our staff and areas in which they can be of help; and the fourth is a suggested format for reporting a problem. It is VERY important that you report problems; obviously, if we don't know about them, we can't fix them.

SECTION I

1. reproduce the problem. does it do the same thing twice?
2. determine the source of the error. which program is it? is it really an error?
3. make sure you know EXACTLY what is wrong.
4. decide how urgent the problem is.
5. report the problem to the appropriate person in the appropriate manner. be sure to let them know if you aren't going to be around to help them track it down.

SECTION II

1. The first thing that should be done when you have a problem is to try to reproduce it. You will have to exercise your own judgement as to whether or not this is safe, but if something doesn't work, it is important to know if it always fails to work, or if it only fails sometimes. In general, it probably won't hurt to try to run the same program again. You should write down exactly what you think you did, and then try to do it again.
2. If it still fails, you need to try to determine if it is really an error, and if so, the source of the error. The best way to determine if it is an error is to check the documentation to see if the program really does what you think it does. If it is a system program, you should check the UNIX documentation, located on the shelves in the main area; if it is a local program, check whatever written documentation you may have. (If you have trouble with the UNIX manuals, let us know and we'll help.) You can tell if a program is local from where it is; if it is in /usr/exp, it is local; if it is in /usr/local/bin, it is probably local; if it isn't in either place, it is a system program. If it is a shell script, you should try to run the program(s) directly. The same kind of thing is true of menu programs like vt_X and mapX; which program did you try to run (from the menu) when the problem occurred (vt1, seq, vt2, etc)? There are two useful commands for determining where a program is and what it is: the command 'which' will tell you where the program is, and the command 'file' will tell you whether it is a binary or a shell script.
3. Please try to be specific. It isn't at all helpful for one of us to be told that a program or workstation doesn't work; we need more information. If the program gives you a message, you should write it down. Some messages are designed so that you can check on the problem yourself. For instance, if one of the vt programs says:

/rawdata/100/100: can't open file

then you need to check for the existence of /rawdata/100/100. Note that you have to look for this file on the machine that you are trying to run the program on; just because /rawdata/100/100 exists on excel1 doesn't mean that it exists on loire; it should, but may not.

4) How urgent is the problem? Is there something else you can be doing while the problem gets fixed, or does it need immediate attention? If a problem is not urgent, it would be best to send mail to the person who needs to fix it; this will usually get you a response within 10 or 15 minutes, and is much less intrusive than a personal visit. Regardless of whether you go directly to the person or send mail, try to have a complete and accurate description of the problem; many problems can be fixed from another terminal if the fixer has a good description of what's wrong.

5) Having decided how to report the problem (i.e., in person or by mail), and having obtained all the necessary information, you have to decide to whom to report it. The list below tells who is responsible for various programs and hardware; try to direct your problem to the appropriate person. Please do not report a problem and then disappear; we may need your help in determining exactly what needs to be done.

SECTION III

People:

Ned Danieley (ndd): all vt, clb and map software, all sun workstations, C and UNIX, recovering lost files, optical disks, printers, latex, general help.

Pat Wolf (pdw): mapping system, Pat's graphics.

Wanda Krassowska (wanda): gradient shell scripts, cube data display (pcube), discrimination function (discrim), pair1, test potentials and gradients.

SECTION IV

Problem report format (with comments in parenthesis):

Your name and the date (especially important if you have a problem when no one else is around. problems should always be reported, even if they occur on weekends).

Workstation on which the problem occurred (if you are running the program on another machine, include the names of both machines).

program being run (include arguments).

error message (if any).

accurate description of problem (this should require more than three or four words. 'Keyboard is stuck' is not an accurate description of a problem. Does anything appear on the screen when you type? If so, what?).