THE SGI SCREAM-SAVER

Chemistry Department, Indiana University, May 1994
This newsletter is available at the beginning of each month and covers the chemistry SGI cluster and the software available on it. If you want to subscribe (specify hardcopy or e-mail preference), please send e-mail to Marty Pagel (mpagel@indiana.edu).

Items Covered in this Edition:


New Help on Available on Chemvgx

The distribution directory /local/examples has the following new help added:
.Xdefaults.example
a sample .Xdefaults file along with explanations to customize how windows and program start (see the discussion in item 3 below)
.login.example
a sample .login file and explanations

Archiving Your Files

The departmental SGIs will soon be backed up on a weekly basis. If you need to recover deleted files and directories, data can be extracted from departmental backup tapes. Due to space limitations, backup tapes will be recycled every two weeks. Thus, departmental backups are not long-term archives, and you should plan to back up data necessary for your research.
Medium                   Cost  Capacity  SGIs with

3.25 inch floppy disk    $1    1.2 MB    iumsc2
1/4 inch cartridge tape  $32   150 MB   
chemvgx
4 mm DAT tape            $20     2 GB   
To back up your data on a floppy drive, change directores to your home directory (type 'cd'), and insert the floppy disk into the drive in the Indigo box. All UNIX commands can be used to copy data to and from the /floppy directory, which is no different than the other UNIX directories.

For backups using a DAT or cartridge drive on the host SGI, insert the tape, then:
To create a new archive, type tar -cv filename(s)
To append to the archive, type tar -av filename(s)
To extract from the archive, type tar -xv filename(s)

For backups using a DAT or cartridge drive on a remote SGI througgh the network, insert the tape, then:
To create a new archive, type tar -cvBf remotename:/dev/tape filename(s)
To append to the archive, type tar -avBf remotename:/dev/tape filename(s)
to extract from the archive, type tar -xvBf remotename:/dev/tape filename(s)

Type man tar for more information. Note that the other popular backup utility, "Backup & Restore Utility" (also known as bru and used in the toolbox) does not allow files to be appended to the end of an existing archive. Appending and retrieving files can take a long time if there is a lot of data on the tape; while cartridge tapes cost more per megabyte (MB) than DAT tapes, they are more convenient when files must be routinely extracted that exist near the end of the tape.

As described in the March 1994 Scream-Saver newsletter, important files can be compressed, reducing the size of the file by abot 40%. PLEASE COMPRESS LARGE FILES WHEN ARCHIVING IS NOT APPROPRIATE. Also, save space on your tape or floppy by compressing your files or directories before archiving. Type compress filename to compress and rename your file filename.Z. Type uncompress filename.Z to uncompress this file. Directories can be compressed, and wildcard characters (* and ?) can be used. GNUzip does a better compression. Type gzip filename to compress and rename your file filename.gz; to uncompress, type gunzip filename.gz.


Using .Xdefaults to Set User Preferences

When you start a X11 program (meaning a program which opens a new window on the screen such as xterm, mosaic, xgopher, xrn, etc.), the way the windows appears on the screen (the fonts, the color of the background, the thickness of the borders, etc.) is controlled by a system file associated with that application which sits in the system area /usr/lib/X11/app-defaults. (They have names like XTerm, Mosaic, Xgopher, XRn, etc.) Fortunately, X11 (the windowing system on SGI) allows users to supersede these values by creating a file in their home directory called .Xdefaults. An example .Xdefaults file has been made available as /local/examples/.Xdefaults.example. Read the comments inside to learn more.

If you have further questions, please see Anurag Shankar in room 421C.


Keeping Track of the Jobs You Run

There is a way to look at all the job you are running on a machine at any time. It is the command ps. Do a ps -u username to see ALL jobs which that user is running (whether the user is logged in or not). For example, if I do a ps -u anurag on my machine right now, this is what I see:
   PID TTY      TIME COMD
 10420 ?        0:41 xterm
   561 ?        4:56 4Dwd
   566 ?        0:01 soundsch
 24564 pts/4    3:27 xwsh
 24565 pts/1    0:03 csh
   567 ?        0:11 toolches
   583 ?        0:03 xwsh
   586 pts/0    0:01 csh
 11503 ?       52:02 xclock
   802          0:00 
 24165 ?        0:00 rsh
   801 ?        0:00 rsh
   877 ?        1:10 xcalenda
 24166          0:00 
  4544 pts/1    4:45 xbiff
 29559 pts/4   525:12 gr_osvie
The first column lists the PID or the process ID, an important number. The next one is the TTY or the teletype (a window in this case) from which the process was started (not all process have a TTY, which is ok). The next field, TIME, shows the cumulative execution time (in hours:minutes), and the final field show the COMD, the command or the program which is running.

If a program (or more correctly, a process) has hung, you can kill it by doing kill -9 PID_of_the_process. In other words, if I noticed that my xcalendar program was messed up, I'd do a kill -9 877 to kill it.

There is another kind of job control in Unix. You can stop most programs which are running in the foreground by doing a control-Z. Let us consider an example. Let's say you want to start the program xcalendar. You type xcalendar in a window and the xcalendar window appears somewhere on the screen. If you look at the original window where you started xcalendar from, you will see that you don't get the Unix prompt back (since you asked that particular window to run xcalendar in the foreground). To get the prompt back, you do a control-Z. This stops the xcalendar program (stop here does not mean kill). The xcalendar program is still there, it is just stopped. To look at all the stopped or running programs, type jobs. You may see something like this:
[1] + Suspended xcalendar
The number in the square braces is the job number. You can bring the job in the foreground again by typing fg %1, where 1 is the job number. You can also have the program run in the background by doing a bg %1. This will run xcalendar in the background and you will always have access to the Unix prompt. You can also kill a job by doing a kill -9 %1. This can be a very useful way to do several things at once in the same window (and this is really why Unix has always been a multitasking environment, even before it had X-windows).

You could also have started the program to run in the background in the first place by typing xcalendar &. Putting the & (ampersand) at the end of a program name runs it in the background. Of course, if you log out, all such programs which are running will be killed. To run a program such that it is not killed (these are say background fortran jobs which you want to run overnight, not x-window programs), you would start it with the nohup option. You say nohup a.out & to keep a.out running even when you have logged out.

All this can be confusing but once you understand the basic idea behind it, you can do things a lot more efficiently. For example, you don't have to start a new window while editing a file with the vi editor just because you wanted to do something else. You could stop it, do the other thing, then do a fg to get back into the editor exactly where you had left it.


Color Printing Primer

People have had some problems recently with color printing. If you are running the cerius or sybyl, you have to do the following:
  1. Specify "Color PostScript" in the print menu
  2. Start the print manager from the system menu in the upper right. Now make PaintJetXL300 your default printer.
  3. Now ask it to print from inside sybyl or cerius.
Also, sometimes it refuses to print remotely, in which case you should try firing up these programs and try printing from floater1 (follow the same procedure there as well).

An X-window Primer

The X-window system (most of you are very likely aware of the name at least) is extremely powerful and the window system of choice on almost all Unix machines. The reason it is talked about so much is that it is network transparent. What does network transparent mean? Let's say that two (or more) machines, say floater1 and chemvgx, are connected over a network. If both are running X-windows, you can have either machine display windows on the other's screen. The simplest way you can do this is to log on to floater1, open a window on its screen, telnet to chemvgx, and start there an X-window program (such as xterm, xwsh, mosaic, xgopher, etc. These programs are called X-clients in the official lingo). Let's say you choose to run xgopher on chemvgx. When you fire it up, it will actually run on chemvgx (meaning that it will use chemvgx's CPU), but will open its window over the network on floater1's screen. Floater1's X-window system in this case acts as the X-server and the program xgopher as an X-client on chemvgx (this is the basic "client-server" concept).

The way the X-window system looks and feels on your particular machine is determined by which "window manager" the workstation vendor chooses to use. There are currently only two major choices - OpenLook and Motif. The Silicon Graphics machines use "4Dwm", an enhanced version of the Motif window manager (the original Motif window manager is normally "mwm"). (Sun workstations are the only ones these days which use the window manager "olwm" based on OpenLook.)

Some of you may wonder what practical uses this network transparency has. Well, for starters, you could log on to say a supercomputer in San Diego, and have it directly open a window on your workstation in front of you. It is like having one screen with ten windows open where each window is actually a different physical machine whose location then becomes irrelevant.

Next month we will talk about how you can use the X-window system to your advantage. If you want to learn more, you can read the "X Window System User's Guide" published by O'Reilly and Associates, a true gem of a book.


Synchronization of User ID Numbers

Just like the federal government, each UNIX system knows you only by your User ID number (UID). Currently, a user with accounts on more than one SGI has a different UID on each SGI. On April 30, the UIDs will be synchronized, so that each user will have one UID for all departmental SGI accounts. These improvements will be transparent to SGI users. among the advantages are the following:
  1. Each user needs only one home directory on all SGIs, saving disk space.
  2. Each user will have immediate access to all of his/her data on all disks, reducing the need to transfer files over the network.
  3. Improved automation of departmental accounting.
  4. Automation of departmental backups.
Synchronization of UIDs was dicussed in the April newsletter. due to problems with the network, the UID synchronization was postponed until April 30. Several reserach SGI system administrators requested that UIDs on their SGIs be synchronized. This UID synchronization of several research SGIs will occur in May, after confirming that synchronizing the departmental SGIs is successful.

Network Status

During the past 6 weeks, three different problems have been encountered, all of which are attributed to the heavy volume off Ethernet network traffic. During the last two weeks, the building network has been reconfigured to reduce traffic on the SGI network. If you still encounter problems, please send email to 'mpagel@indiana.edu' and describe the problem.

Problem: A disk located on chemvgx and mounted on another SGI becomes unmounted on the other SGI.
Solution: the system administrator should log in as root and type 'mount -av'

Problem: A SGI cannot connect to the network (rlogin, telnet, ftp, ping, etc., do not work).
Solution: The system administrator should log in as root and type 'route add default 129.79.136.174 1'. If the problem still exists, type '/etc/reboot'.

Problem: Commands and processes which use the network (including telnet, ftp, mosaic, sybyl, and logging in) are extremely slow.
Solution: Be patient. Stop the command (control-c) or process and try again.

NOTE THAT the next SGI Scream-Saver lunch will take place on June 2, 1994, at noon in room A400.


Back to Scream Saver Index
Return to MolViz Home
Send comments to chemvis@indiana.edu
Last updated: 01/23/2001