Where to check for application problems

Edit online

This information describes where to look if SA z/OS indicates a problem with one of the defined UNIX applications, in particular with the SAP system.

UNIX application cannot be started or stopped
- Check *.log files in the administrator's home directory for error messages.
  The name of the log file is specified in the start/stop/monitor command in SA z/OS, and it identifies resources and the system where the command has been executed. In our configuration, they are all located in the home directory /u/<sid>adm.
  
  The following command shows the log files in chronological order:
```
ls -rtl *.log
```
- Log file does not exist.
  In this case, SA z/OS apparently either did not issue the USS command, or was unable to execute the command. You can do the following:
  - Check the z/OS system log for messages (see z/OS syslog).
  - Check the z/OS UNIX system log (syslogd) for messages.
  - Check the availability of file systems. Are the SAP global, profile, and exe directories accessible?
  - Log on to z/OS UNIX and execute the command manually.
- For remote resources, the log files usually indicate the reason that SA z/OS failed to manage the resource. It may be that the remote resource is not truly unavailable. Instead, remote monitoring, or remote execution, may be inhibited.
  - Check that the remote system is available.
  - Check that remote execution works.
  - Log on to the remote system and check the status.
SAP enqueue server, message server, gateway do not start
First check, if the sapstart.log file in the work directory of the SCS instance is correctly tagged. If it is incorrectly tagged, then the SCS Instance does not start under SA z/OS, because it cannot be read. See an example, where it is incorrectly tagged:
```
coh1vipa:/usr/sap/HA2/ASCS20/work (2)>ls -lT sapstart.log
t IBM-1047 T=on -rw-rw-rw- 1 ha2adm sapsys 2525 Mar 6 15:10 sapstart.log
```
This is the correct tagging:
```
coh1vipa:/usr/sap/HA2/ASCS20/work (3)>ls -lT sapstart.log
- untagged T=off -rw-r--r-- 1 ha2adm sapsys 1990 Jul 6 09:33 sapstart.log
```
To fix this:
1. Rename or delete sapstart.log.
2. Make sure that the sapstart executable has the minimum required patch level (see Software prerequisites).
  To check this, log on as user <sid>adm under z/OS UNIX in its home directory and perform the following:
```
sapcontrol -nr <instance_nr> -host <virt_hostname> -function GetVersionInfo
```
Check messages in the log file that you defined for the SA z/OS resource in the SA z/OS policy. The log files are located in the home directory of the administrator user, for example, /u/ha2adm, and contain the LPAR name in their name. If the enqueue server was started on the COH1 LPAR, the policy creates the log files:
- start_ASCS20_srv.COH1.log.old (log file from previous start of the sapstartsrv service)
- start_ASCS20_srv.COH1.log (log file from start of the sapstartsrv service)
- start_ASCS20.COH1.log.old (log file from previous start of the ASCS instance)
- start_ASCS20.COH1.log (log file from start of the ASCS instance)
Further SAP log files can be found in the work directory for the central services instance, for example:
```
/usr/sap/HA2/ASCS20/work (for the SAP System NW 7.10 test system HA2)
```
For the enqueue server, browse the enquelog file in the work directory. It shows when the enqueue server has been started and stopped, and whether the enqueue replication server is activated.
The application servers do not connect to the message server or the enqueue server
- Check the network and the routing; refer to Checking the network.
- Check that the enqueue server can be reached. For this purpose, use the ensmon command:
```
ensmon -H <hostname> -I <enq_instance_number> 1
```
  In this configuration, the command looks as follows:
```
ensmon -H ha2ascsv -I 20 1
```
  The command writes further trace information into file dev_ensmon in the current directory. If ensmon fails on a remote system, but succeeds on the system where the enqueue server is running, the cause is probably a network problem.