Open System Services Management and Operations Guide (G06.30+, H06.08+, J06.03+)

3. Use the OSS Monitor SCF ALTER FILESET command on each fileset managed by the OSS
name server you want to remove to change its NAMESERVER entry to specify another OSS
name server.
4. Warn your users to make sure that all their files in affected filesets are closed and all OSS
shell sessions using those filesets are terminated. You can use a method similar to the one
described under “Manually Stopping the OSS File System and the OSS Environment” (page 47).
5. Use the OSS Monitor SCF STOP FILESET command on each fileset managed by the OSS name
server you want to remove.
The OSS name server stops itself as soon as the last fileset it was managing stops.
6. Use the OSS Monitor SCF START FILESET command on each fileset formerly managed by the
OSS name server you want to remove.
7. Use the OSS Monitor SCF DELETE SERVER command to remove the stopped OSS name server
from your configuration.
8. If your site uses the STARTOSS utility and the deleted OSS name server serviced a deleted
fileset, you should also delete the fileset name from the OSSINFIL file. See “OSSINFIL File”
(page 408) for more information.
Removing a Network Services Server
Stopping the inetd, lwresd, or named server effectively removes that server from the OSS
environment. See “Stopping a Network Services Server” (page 135) for more information on stopping
the inetd, lwresd, or named process.
To remove the remote shell server rshd or the remote execution server rexecd, edit the /
etc/inetd.conf file to delete or comment out the entry for rshd or rexecd.
Although portmap and rpcinfo are used by products in the OSS environment, they are not
OSS processes and cannot be removed from the OSS environment. Stopping them in the Guardian
environment effectively removes then from the node.
Troubleshooting a Server
When you have problems managing a server, follow this general procedure:
1. Check the messages from the OSS Monitor that are sent to your terminal. If you redirect such
messages to a log file, check the log file for its most recent entries. Look up the cause, effect,
and recovery information for a message either in “OSS Monitor Messages” (page 355) or by
using the SCF HELP facility described in “Online Help Facility” (page 251).
2. When you are unsure of the outcome of a command entry, check the EMS log for the most
recent status messages. Look up the status messages in the Operator Messages Manual. For
a list of the subsystem IDs to look for in the EMS log, see “Messages” (page 335).
3. When you are unsure of the effect of an action on a server, use the STATUS SERVER command
DETAIL option to obtain the last internally reported error information for it. Look up that error
in “Numbered Messages” (page 361).
Configuration Files 139