NT: Dispatcher in status 'Yellow',SAP system running

The system starts without problems and is fully operational. Nevertheless, in the SAP Service Manager or in the SAP MMC Snap-in, the dispatcher remains in the status 'Yellow'.

Upgrade:

The error can also occur during the SAP upgrade. Since there the SAP system is generally not started via the MMC or the SAP Service Manager but via R3up, the 'Yellow' dispatcher cannot be recognized. If the error occurs (SAP system started but start phase of the R3up is noted as incorrect), start the SAP Service Manager or the MMC with the SAP Snap-in to check the status.

Typical characteristics of the error during the upgrade are:

- the start of the SAP system after the R/3 kernel switch fails. The
  R3up Logfile R3up.eco shows:   EXECUTING E:usrsapputexestartsap.exe name=SID nr=00 SAPDIAHOST=
   STARTSAP failed
   Details are written to E:usrsapputtmpstartSID.log
   Process with ID 515 terminated with status -1

- The STARTSAP logfile then shows the corresponding error:    running E:usrsapputexesapstart.exe name=SID nr=00 SAPDIAHOST=   SAPSTART finished successfully on <hostname>_<SID>_00,      but Dispatcher is not connected to MessageServer !
MSCS (Microsoft Cluster Server):
The SAP system no longer starts in the cluster, but it can be started manually via the SAP MMC snap-in or the SAP Service Manager. There, you see that the dispatcher is stuck in a 'yellow' status even thought you can work with the system.


For one of the following reasons, the logon of the message server to the dispatcher fails.

1. Discrepancies in hostname resolution

In the name resolution via the IP address and DNS, the host is determined with a different syntax as the NetBios name (upper/lowercase).As the message server logon is case sensitive, the message server is not recognized correctly by the dispatcher.

2. Changes to the sapms<SID> Entry in the Services file

After changing the port number for the entry sapms<SID> in the 'Services' file (directory %windir%system32driversetc), with R/3 shut down but without restarting the service SAP<SID>_00, the service cannot create a link to the message server, because it uses the value from sapms<SID> which is internally buffered.

3. Restart the message server (Release < 3.1G)

If an error occurs on the logging socket of the message server, this is closed and a new one is opened.This new logging socket may not work correctly under Windows NT.

4. Discrepancies exist in the profile parameter Start profile <-> Instance profile

This error can also occur if parameters with the same name are defined differently in the start profile and in the instance profile.The inconsistency is due to the fact that the SAP service (sapntstartb.exe) reads the start and default profiles, whereas the R/3 kernel only reads the default and instance profiles.If parameters (for example, SAPLOCALHOST) are not identical, the message server logon will fail.

5. Discrepancies in the dispatcher queue length (rdisp/elem_per_queue) between SAP service and MMC Snap-In (only 4.5B and higher). In addition to the 'yellow' status, the following error message is displayed in the MMC Snap-In for the dispatcher:  "Running but Dialog Queue info unavailable".

6. Service and dispatcher have different versions

When exchanging the kernel, the old directory was moved using the NT Explorer and the registry values were updated as well. Thus, the old service is still started.

7. MSCS only!

The SAPLOCALHOST parameter must exist in the start profile and the instance profile and must point to the virtual R/3 network name. If the parmeter is missing, for example, in the start profile, the parameter is automatically determined by determining the physical host name. In doing so, the paramter values deviate between instance profile and the start profile.

The following solution is used to overcome the issue.

1. With the R/3 System running, go into the command prompt and execute::
          lgtst -S sapms<SID> -H <hostname>
In the result string, the hostnames determined in the first two brackets should be written identically (upper/lowercase).

2. Stop R/3 again and restart the service SAP<SID>_00.The dispatcher is then 'Green' when R/3 is started again.

3. Download a downwardly compatible kernel patch 3.0F from sapservX.Fixed in patch level 15 .

4. Variances between start-up profile and instance profile in relation to the following parameters can lead to the described situation:

          rdisp/mshost => <hostname> (is set in default.pfl)       rdisp/msserv  => sapms$(SAPSYSTEMNAME)
          rdisp/myname  => $(SAPLOCALHOST)_$(SAPSYSTEMNAME)_$$

for Release 4.5B and higher in addition:
      rdisp/elem_per_queue = <number_of_elements>
rdisp/myname and rdisp/msserv are determined dynamically and should not be set in one of the profiles. You can check the parameter values between the profiles simply by using
      sappfpar.exe pf=<PATH><PROFILE>
Call SAPPFPAR once with the instance profile and once with the start profile and compare the values for:
              rdisp/mshost
              rdisp/msserv
              rdisp/myname
              rdisp/elem_per_queue
The default .pfl msut not be tested because this is always loaded automatically from SAPPFPAR from the transported directory <PATH>.

5. Because the SAP service delivered with SAP MMC Snap-In draws considerably more information from the R/3 kernel currently running, identical information regarding various parameters must be available to both the SAP service as well as the R/3 kernel.Because the SAP service only reads the SAP start and default profile, the value changed in the instance profile for 'rdisp/elem_per_queue' cannot be recognized.
    Set 'rdisp/elem_per_queue' with identical value in the start profile too or make sure that this is set. With the right mouse button, click on the name of the machine in SAP MMC Snap-In and there select 'All tasks--> Restart service'.After a while, the dispatcher switches to the 'Green' status.

6. Explorer Move: Please only use the Copy(or overwrite)/Delete commands. To solve the problem, move the old directory/files back to restore the original state, and replace the directories using commands Copy(or overwrite)/Delete. Another possibility is to register the new service with "sapstartsrv.exe -t" again.

7. MSCS: Make sure that none of the above points applies. Then check whether the parameter SAPLOCALHOST exists in the start profile and instance profile and points to the virtual R/3 network name.

    If none of the proposed actions helps, attach the following information to your OSS message.
          - Ouptut of "lgtst.exe -S sapms<SID> -H <hostname_of_CI>"
            (CI = central instance)
          - default profile, instance profile and start profile