TS/MP System Management Manual (G06.24+, H06.03+)

Maintaining a PATHMON Environment
NonStop TS/MP System Management Manual—541819-001
5-31
Recovering from PATHMON Failure
•
Status information; at the system prompt, perform:
STATUS /OUT <statfile>/ *, PROG <prog filename>, DETAIL
where statfile is the listing file that captures the status display in an edit file,
and prog filename is the server program’s file name.
Recovering from PATHMON Failure
If PATHMON fails, perform these steps to capture data about the failure and restart the
PATHMON process.
1. Determine whether it is in your users’ best interests to bring the PATHMON
environment down right away. A well-designed, well-tuned system may actually
run for one or two days without the PATHMON process. Contact users and find
out whether critical applications are running as expected. If they are, you may be
able to wait before stopping the entire environment.
2. Capture data about the failure. Use VPROC to get the product version. If you
have been running the PATHMON environment with DUMP ON, retrieve dumps
from ZZPMnnn. Get any relevant messages from the PATHMON log and the EMS
log. Note what commands you were using or functions you were performing at the
time of the failure. Collect this information to have available when you contact your
HP representative for help.
3. Bring the PATHMON environment down using Guardian STOP commands to stop
all processes. For more information about the Guardian STOP command, see the
Guardian User’s Guide .
4. Start PATHMON again.
5. Coolstart the PATHMON environment.
Keep Development and Production Separate
It is recommended that you do not mix your development and production
environments. Ideally, you should have separate PATHMON environments for your
development and production environments.
If you do not maintain separate environments, you might jeopardize the availability of
your production environment. For example, suppose there are problems with a
Guardian server that indicate the developer must use the Inspect product to debug the
server. During this time, the server is unavailable, and any processes attempting to
establish links to the server could encounter an unacceptable delay. Similarly, a TCP
that handles both production and development SCREEN COBOL requesters might not
be able to respond to a user if a developer is making changes based on development
requirements.
If you cannot maintain totally separate development and production environments, try
to keep as much of your production environment separate as you can. It is highly