This section provides information about tools in the DeskSet.
You can only run one Binder at a time because your user database locks while the Binder is running. If you cannot start up the Binder, and you receive a message in your console telling you that you do not have permission to write to your user database, it's probably because you have another Binder currently running.
If a File Type entry that you think is associated with a Binder entry is not showing up, it's probably because the Binder read in a duplicate of that File Type entry before it read the Binder entry in question. When there are duplicate File Type entries, the Binder only uses the first one it reads. The first File Type entry that the Binder reads does not necessarily correspond to the first Binder entry in the base window scrolling list. Therefore, you should use caution when using the Copy button to copy a File Type entry. If a File Type entry does not show up for a particular Binder entry, try to find and delete the duplicate File Type entry.
This section describes basic Calendar Manager troubleshooting.
The Calendar Manager consists of two parts:
A database manager, called rpc.cmsd (Calendar Manager service), that maintains the information for the Calendar Manager
The Calendar Manager application itself, called cm
The Calendar Manager application cannot function without the Calendar Manager service.
If your Calendar Manager does not display appointments, or if you get RPC timeout messages in the console window, rpc.cmsd may not be running. To check your configuration, use these steps:
Open a Command Tool or Shell Tool.
See Chapter 6, Command Tool, Shell Tool, and Console Window for information about the Command and Shell Tools.
At the system prompt type ps -e | grep rpc.cmsd and press Return.
This asks for a listing of all processes containing the string rpc.cmsd.
Look at the listing displayed in the window.
Figure A-1 shows a listing that contains the Calendar Manager service process. You can ignore the entry grep rpc.cmsd in your ps listing.
If you do not have an rpc.cmsd process running, follow these steps:
If you have a Calendar Manager application running, quit the Calendar Manager by choosing Quit from the Window menu.
At the system prompt, type vi /etc/inetd.CONF
Look for the entry: Rpc.cmsd
Make sure the pathname specified is correct and that an Rpc.cmsd entry exists in the specified pathname. If not, change the path to point to where the Rpc.cmsd exists. Then view the pid of inetd by typing:
ps -e | grep inetd
Then reread the inetd.CONF file by typing:
kill -1 inetd-pid
Restart Calendar Manager.
To make sure that the Calendar Manager Service is now running, type ps -e | grep rpc.cmsd and press Return.
If you are upgrading the SunOS, you need to back up the following directory, to preserve the information there:/var/spool/calendar
Use whatever backup medium is available to you, and restore the directory when the operating system upgrade is complete.
If your appointments are not displayed, make sure you have run the installation script, as necessary. See "RPC Problems and Calendar Manager Installation" for information. Before trying the following procedure, try restarting Calendar Manager first.
If your appointments are still not displayed, and you see the string NO NAME in your Calendar Manager header, the permissions are probably wrong for the /usr/spool/calendar directory and files. Make sure they are exactly as described in the following steps.
Type ls -lsa /usr/spool, and check the permissions for the directory: /usr/spool/calendar.
The permissions need to be exactly: drwxrwsrwt. This should be owned by daemon in the daemon group. (Get help from your system administrator to change the permissions, if necessary.)
To check the permissions of your calendar database, type:
ls -lsa /usr/spool/calendar/callog.<username>.
Substitute your user name in place of <username>. For example, type ls -lsa /usr/spool/calendar/callog.egret. The permissions need to be exactly: -r--rw----. Also, this file needs to be owned by the user and in the daemon group.
There are two basic symptoms of remote Calendar Manager access problems:
You try to browse a remote calendar where you think you have Browse access, and all you can see are appointment times.
You try to insert, delete, or change an appointment on a remote calendar where you think you have access, and Calendar Manager gives you an Access Denied... error message in the footer of the Appointment Editor.
There are three things you can check to try to fix these access problems:
If you are using the NIS or DNS system, which uses the concept of mail domains, make sure you are trying to browse a calendar in your domain or that you have specified the domain in your browse list. For example, if you are trying to browse the calendar of user Rob in your domain, you can simply specify Rob@host. If you are in a domain called Eng, and Rob is in a domain called Corp, you need to specify rob@host.Corp in your browse list.
Make sure that the owner of the remote calendar has really given you Browse, Insert, and/or Delete access.
In order for the access to occur, make sure both of these conditions are met:
Names in the access list must take the form user@host or just user. (Note that if the name in the access list is just user, access is given to anyone on your network with that user name.) If you are using the NIS or DNS system, make sure your name in the access list is not listed in the form user@domain or email@example.com.
The owner of the calendar must remember to click SELECT on the Apply button on the Access List and Permissions Properties window.
Check the user ID and group ID on both your workstation and the remote workstation. The user ID and group ID must be the same in both locations.
Determine your user ID and group ID on each workstation as follows:
Look for your password entry in the file /etc/passwd.
If you have an entry in this file, the user ID is the third field (the number between the second and third colons). The group ID is the fourth field (the number between the third and fourth colons). For example, if the entry for user Egret in the /etc/passwd file is:
the user ID for user Egret is 3286, and the group ID is 10. The values of the user ID and group ID should be between 0 and 32767.
If you are using the NIS system, and you do not have an entry in the file /etc/passwd and the last line of /etc/passwd starts with a `+', check for an entry in the NIS passwd entries. To determine your NIS user entry, type ypmatch username passwd in a Command Tool or Shell Tool.
For example, to find the NIS password entry for user Egret, type:
ypmatch egret passwd
If the system responds with a user entry, the user ID is the third field, and the group ID is the fourth field.
If you'd like to add a second calendar on your workstation, you need to create a dummy user for that calendar. For example, you might want to add a second calendar for appointments for your entire work group.
To create the dummy user and new calendar, use the following steps. These steps assume a basic understanding of UNIX system administration, so you may need to get some assistance. This assumes you are root.
Add a dummy entry in the /etc/passwd file of the workstation where you want to create the second calendar.
You need to specify a name, a dummy user ID, and so forth.
Bring down the cm and rpc.cmsd processes.
Log in as the new dummy user, and start a new Calendar Manager.
Edit the access list and permissions for your group.
Add the calendar name to the browse list.
Log out, and log back in with your own login.
You can now browse the new calendar.
If you move around from workstation to workstation, and you want to always be able to access your real Calendar, you need to have Calendar Manager running on each workstation. Use the following steps to set up access to your calendar from multiple workstations:
On your primary workstation, give full access list permissions to your calendars at the remote workstations.
For example, suppose user Egret has his real calendar on the workstation named "work", and also accounts and calendars on remote workstations named "sea" and "ocean". He would add egret@sea and egret@ocean to his calendar access list, and give these users full Browse, Insert, and Delete permissions. See the section Chapter 5, Calendar Manager, for instructions.
When you are logged in at the remote workstations, browse your real calendar.
Since you have full access permissions, you can read all your appointments, change your appointments, and so forth.
In the previous example, when Egret is logged in to "sea" or "ocean" he can browse the calendar egret@work to access his real calendar.
Do not mount the /usr/spool/calendar directory from a remote disk. Doing so may result in loss of Calendar data.
If you run an older version of OpenWindows after running the current version of OpenWindows, the older version of Calendar Manager will not be able to read your appointment data file. To avoid this problem, back up the following file before starting the current version of Calendar Manager: usr/spool/calendar/callog.<user>.
Before you return to an older version of Calendar Manager, restore your old file making sure you maintain the permissions on the directory and file. If you browse a calendar that is running a different version from your own, it should work.
Displaying seconds for the clock may have a negative effect on system performance.
If your Workspace color is black, your clock is invisible when it is an icon on the Workspace. See the man page for clock to learn how to have the clock icon painted with the Window Background color instead of the Workspace color.
The section describes some of the error messages you may get while attempting a drag and drop from on deskset application to another.
Drag and Drop: Timed Out
This can occur if the server is unable to connect with the receiving application within a certain time. The default timeout value for an XView application is three seconds.
You can change this value by adding a line to your ~/.Xdefaults file. If you wanted to change this to five seconds, add the line:
to ~/.Xdefaults file and then type xrdb ~/.Xdefaults from a command line to setup the server with the new timeout value.
The receiving application does not support drag and drop operations.
This message may also appear if the receiving application's drag and drop targets are not responding to the sender. If this is the case, restarting the receiving application may clear up the problem.
The dragged object was dropped onto the root window. Normally, this is considered an error by the sending application, though File Manager assumes in this case that the item is to be opened.
An unknown, internal error occurred while trying to establish a drag and drop connection.
An unknown, internal error occurred while trying to establish a drag and drop connection. Try the drag and drop operation again.
This section describes the solutions to common File Manager questions and problems.
If you try to format a floppy using Format from the File Manager File menu and it does not work, your system may not be set up to run the format program. Contact your system administrator for assistance.
If you think you changed a file's icon with the Binder, but you do not see the change in the File Manager, make sure that you restarted the File Manager after you saved the Binder changes. If you have already restarted the File Manager, recheck your changes with the Binder. Make sure the entry you changed was saved to your user database with the Binder Save button. Also, make sure the file displayed really falls into the class of files changed with the Binder.
If your File Manager displays only the three generic types of icons (folders, applications, and documents), the File Manager was unable to connect with the Binder database. Check your Console window for error messages indicating where the problem occurred.
If you delete a window for a floppy disk or CD, you can bring it back by selecting them from the Go To menu button. They are always displayed within the application specific section of the Go To menu. For information on using the Go To menu refer to Chapter 2, File Manager.
If you use File Manager to drag and drop a file to another application, but you get the error message
drag and drop: illegal target
If files you expect to see in the file pane are not being displayed, make sure you have not specified a view filter pattern from the File Manager Properties window which can suppress the display of those files. When a filter is specified, it is always displayed in the header of the File Manager window. To clear this up try selecting View Icon by Name.
If you have trouble transferring files between remote systems, you may not have the correct permissions to access the file, directory, or system, or the remote system may not be accessible through the network. Contact the person who owns the files (or the person who asked you to transfer the files) to change permissions so the transfer will work. To find out if the remote system is available on your network, contact your system administrator.
When the File Manager is viewing files by content, it needs to read and compress the first screen of files so they can be displayed. For Sun icons, X Bitmap, and X Pixmap files, this should work fairly quickly. However, compressing large Sun raster images can take some time. Therefore, if you only need to look at icon files, be sure to only have Monochrome Icons and Color Icons set on the Properties: Current Folder or New Folder window for the Files to View setting.
If you try to run Image Tool and you receive the following message:
ld.so.1: imagetool: can't find file libxil.so.1 Killed
You need to have the XIL packages installed. Contact your system administrator for assistance.
If you run multiple versions of mail programs, Mail Tool may become confused about the state of your In-Box. If Mail Tool takes a long time to open the In-Box, it's possible that a Mail Tool lock file needs to be removed. If there is not enough disk space for the Save Changes operation, you will need to remove messages from the current mail file. This section describes how to recognize and correct these problems. In addition, it describes where you can find your Mail Tool In-Box and where you can find mail messages you were composing that were cleared or lost during a Mail Tool or window system crash.
If you run multiple versions of Mail Tool at the same time (or the Mail Tool application and the Mail program), you may receive notices from your Mail Tool application advising you to Save Changes or Quit one of the Mail Tool applications. This is because both versions try to modify your In-Box. Follow the instructions of the notices to avoid creating confusion about the state of your In-Box.
If you did not choose Done or Save Changes in the Mail Tool application before running another Mail Tool application or the Mail program, a notice instructs you to quit your Mail Tool application. If you did save your changes, you will be given a choice to either quit the Mail Tool application or Save Changes to keep it in its original state.
You can avoid having to quit your Mail Tool application by getting into the habit of choosing Done from the File menu at the end of each day, or when it is likely that you will be logging into your machine and reading mail from a remote location.
If you forget to choose Done, and you remotely log into your machine to read mail, you can tell Mail Tool to choose Done by following these steps:
From a Shell Tool prompt type ps -e | grep mailtool and press Return.
The listing should look like the one shown in Figure A-2.
Look in the left-hand column of the listing for mailtool (not the listing for grep mailtool) to find the process number (PID).
The process number is the first number on each line.
Type kill -USR1 PID and press Return.
In the example above, the process number is 1431, so you would type: kill -USR1 1431
Read your mail as you usually do from the remote location.
The next time you open your Mail Tool, the changes you make to your In-Box from the remote location are incorporated and recorded as part of the Mail Tool.
The steps above only work with the DeskSet Mail Tool application. Using these steps for other versions of Mail Tool kills Mail Tool.
The Mail utility uses a lock file to prevent two or more processes from altering your mail spool file at the same time. If Mail Tool quits unexpectedly, the lock file may be left behind.
If Mail Tool takes a long time to open the In-Box, either when you specifically request it or when you open Mail Tool after you have chosen Done from the File menu, check for a lock file. Look in the directory /var/mail for a file named username.lock, where username is your login name.
To remove the file, from a system prompt type:
For example, if your username is "mary", you would type:
Alternatively, you can find the lock file in the File Manager, and drag it to the Wastebasket to delete it.
The default location for the Mail Tool In-Box is /var/mail/username. If the environment variable $MAIL exists, Mail Tool uses its value as the In-Box location.
If you are in the middle of composing a mail message when your Mail Tool application or your window system crashes, you can recover a copy of the message from the file dead.letter in your home directory minus the last 80 edits, that is the application keeps track of the number of edits and files saves every 80 edits. So the most edits lost would be the last 80.
Your message is also saved in the file dead.letter whenever you click SELECT on the Clear button in the Compose window or choose Clear message from the Compose window's Deliver menu.
See the man page for mail for information about dead.letter and the save variable.
If you try to save changes, by selecting Save Changes or Done from the File menu, or by switching mail folders, and Mail Tool warns that it has run out of disk space, you must remove messages from the current mail file to make it small enough to save.
You can remove messages by deleting or moving them. Removing larger messages helps the most. You can find the largest messages by choosing Size from the Sort By submenu of the View menu.
Mail Tool may run out of swap space if you drag-and-drop a file that is too large into MailTool Attachment window. You can remedy this by increasing your swap space.
If a file has an inappropriate print script in the binder database (this is not an ASCII file and the possible location is /usr/openwin/lib/cetables), the Print Tool may hang when you use it to print that file. The print script may be missing the $FILE, $PRINTER, or $COPIES variable. See Chapter 16, Binder, for information about how to change print scripts using the Binder.
If you print a file and the appropriate filter is not available on the printer, you will receive an error message.
A potential problem with Snapshot is creating a raster file that has the wrong dimensions for use with another application. This is described in the following section.
If you experience difficulty in using Snapshot files with other applications, it may be because you are trying to incorporate a snapshot from a grayscale or color monitor into an application that can only handle black-and-white images.
Raster files have three dimensions: height, width, and depth. Black-and-white raster files are 1-bit deep. Grayscale and color raster files are usually 8-bits deep. True color raster files are 24-bits deep. If you take a snapshot on a 4-bit screen, it is saved as an 8-bit raster file.
You can see the depth of a raster file by typing file rasterfilename in a Shell Tool or Command Tool prompt, or by selecting the file from the File Manager and displaying the Information window. In the example shown in Figure A-3, the listing shows the file properties for all files ending in .rs. As you can see from the listing, there is one 8-bit raster file (snapshot.rs) and the rest are 1-bit files.
The best way to convert an image to the same depth as your monitor is to use Image Tool. You can take the snapshot, View it, and use Save as to select b&w as the number of colors. Refer to Chapter 13, Image Tool.
This section describes some common problems you may encounter with the Tape Tool, and it offers possible solutions.
To correct the block size, choose Block I/O from the Tape Tool Properties window. In the text field that appears, type the correct block size (the one from the tape).
If you retrieve files from a tape and they are not copied to the destination directory you specify, list the contents of the tape to see if the file names are preceded by an absolute path name. When you retrieve files that have an absolute path name, that path is used as the destination directory.
Tape device names are not automatically included in your system configuration unless a tape drive is hooked up at the time of installation.
If you add a tape driver after the inital system installtion but did not reboot your system afterwards, you will get this error message. To reconfigure your system to include the new tape device name, shut down your system and reboot with the following flags:
The new tape drive will appear in /dev/rmt.