Why is it that, when your computer is misbehaving, the system administrator says it's an application problem, the application programmer says it's a hardware problem, the hardware technician says it's a system administration issue, and the systems programmer quietly closes his office door and tries to disappear. It is often difficult for geophysicists to determine who is the best contact in case of computer problems. Here I describe the computing disciplines most relevant to geophysicists, and their areas of expertise. This will help in the selection of the most appropriate support person and help get past the dreaded "Help Line" questions, "Is it turned on? Is it plugged in?"
Recall from earlier Systems articles that there are four main components to a computer system: hardware, operating system, application programs, and users. These can be viewed as layers of abstraction with hardware at the lowest level, followed at increasingly higher levels by the operating system, application programs, and users . Hard ware is ultimately responsible for all computation and data storage. The operating system provides an interface between hardware and application programs. The application programs, in turn, provide an interface between the operating system and the users. Users are people using the rest of the system to solve computational problems. Analogous to these layers are four disciplines: hardware specialists, systems programmers, applications programmers, and geophysicists. Hardware specialists design, build, diagnose, or repair hardware. Systems programmers are specialists in the use and operation of operating system. Applications programmers write programs which implement geophysical algorithms such as filtering, stacking, and migrations. In this context geophysicists are the users.
Although design and development of hardware and software follow this layered model closely, system support is usually divided differently, consisting of geophysicists, application support specialists, and system administrators. Geophysicists don't usually consider themselves in a support role, but geophysical colleagues who have extensive experience with an application can be invaluable in problem solving. They will often find user errors such as the use of incorrect datasets or erroneous geophysical parameters. (For example, a hand-edited 3-D geometry with a misplaced decimal point which puts a receiver in the vicinity of the Moon can produce very peculiar behaviour.) Geophysical colleagues thus provide support for the top layer in the system hierarchy. The second group, the application support specialists, are experts in the optimal operation of applications by geophysicists and thus encompass the top two layers of the system hierarchy. They often work directly with geophysicists in the configuration of applications to achieve specific goals, and to identify application defects. Application defects and requests for application enhancement are referred to the appropriate application programmer. Finally, the system administrators are responsible for the overall administration of computers and their attached hardware with the goal of maximizing their usability to the geophysicist. Thus they encompass the bottom two and the top layers of the system hierarchy. They configure the net work and disk and tape drives, layout file systems, add user accounts, install revised operating systems and third party applications, and generally keep the computer's house clean. They interact directly with geophysicists on issues involving the operating system and hardware, often referring hardware problems to a hardware technician.
There are some relatively straightforward guidelines which can help geophysicists to decide who, from these three support disciplines, is best to call for a specific problem. If an application gives unexpected results, it is best to check with a geophysical colleague who is familiar with the application; the problem may merely be a misunderstanding of the "algorithm, the use of the wrong algorithm, or incorrect parameters. However, if an application produces incorrect results although the datasets and parameters are correct, the problem is likely in the application and should be referred to the application support specialist. Under UNIX, applications which terminate with the message "Segmentation violation", "Bus Error", or "Core dumped" are almost certainly themselves at fault. These messages are generated by the operating system when a process attempts to access memory illegally. If any of these messages appears, the application support specialist should be contacted. The problem will likely be referred to an applications programmer who will want detailed information about the application's use prior to and during failure: the exact sequence of keyboard and mouse operations, input and output dataset information, and all error messages (whether the user considers them relevant or not). As a general rule, system administrators should be contacted in case of any computer problem not attributable to the application or geophysicist. These typically include unresponsive windows, keyboard, or mouse, or blank monitors; file system quotas, missing files and the inability to read, write, or create files; network problems such as unreachable or unknown hosts; electronic-mail; security and passwords; and, of course, file archival and restoration and disaster recovery. Computers which reboot themselves are of particular interest to system administrators as these usually indicate a serious problem with the hardware or, more rarely, with the operating system itself. Hardware problems often manifest themselves through system anomalies and are thus usually diagnosed by the system administrator, then referred to a hardware technician. However, there are some obvious indicators of defective hardware: dark indicator lights which are normally illuminated; illuminated indicator lights which are normally dark; strange noises; and smoke or flames.
It appears that systems programmers have escaped responsibility for any problems!
They do play an important role in computer support, but usually work with system administrators and applications programmers rather than directly with users. For the systems programmer, diagnosis of software problems is usually straightforward, if at times tedious. The only tough decision is whether the problem is in hardware. After my last diagnostic attempt, my hardware colleagues gave me a simple rule: "If it's smoking, it's hardware." They now call me "Smokin' Mark." It's a long story.