When the DFSMSrmm CIM provider does not return output

If you request DFSMSrmm data from a CIM client and no data is returned, check these items:

If message BPXP015I HFS PROGRAM /bin/printenv IS NOT MARKED PROGRAM CONTROLLED appears on your z/OS console, set the program control flag ON by issuing this command from the OMVS shell:
```
extattr +p /bin/printenv
```

If the CIM provider uses the DFSMSrmm Web service API:

Ensure that the DFSMSrmm Web service is up and running. Having the DFSMSrmm Web service up and running is required in order for the DFSMSrmm CIM provider to work.
If the DFSMSrmm CIM provider does not show data, start a DFSMSrmm Web service client. Collect data from the DFSMSrmm Web service client to ensure that the underlying DFSMSrmm Web service is working correctly.
When using the WebSphere Application server, ensure that the DFSMSrmm Web service default user ID has the sufficient RACF authorizations needed to access DFSMSrmm.
When using Tomcat, ensure that the user credentials, provided in rmmcust.properties as TOMCAT_USER_NAME and TOMCAT_USER_PASSWORD, are set correctly and authorized to use the Tomcat server (see Tomcat readme file rmmtc.txt).
If the DFSMSrmm Web service is working correctly, open the options file, rmmcust.properties, and check these settings:
- Timeout value. Ensure that the timeout value is not too low. A slow network connection or a large data request can cause the DFSMSrmm Web service to time-out. For example, the WEB_SERVICE_TIMEOUT = 10000 setting allows 10 seconds (10 000 milliseconds) to wait.
- If your DFSMSrmm Web service destination URLs are stored in the option file, WEB_SERVICE_REGISTRY = FILE, ensure that your WEB_SERVICE_LOCATIONS points to valid URLs for your Web servers. Ensure that this line is not commented out (// at the beginning of the line).
- If your DFSMSrmm Web service is published in a UDDI, WEB_SERVICE_REGISTRY = UDDI, ensure that the UDDI registry URLS are correct for UDDI_INQUIRY_URL. The Web services need to be published to the registry, and the registry must be up and running. The UDDI search string, UDDI_SEARCH_STRING, must match the published names of your Web services. The names must start with that string and are case-sensitive.
- Ensure that the operands, as specified in the appropriate instance of class IBMrmm_SearchOperands, do not limit your search requests. For example, defining the instance IBMrmm_SearchOperands, Resource="IBMrmm_PhysicalVolume" Operands="Owner(*) Volume(A*) Limit(100)", limits a subsequent search of IBMrmm_PhysicalVolume objects to those that start with an "A" in their volser.
- If the data is behind a firewall, make sure that you have logged in before connecting the DFSMSrmm Web service.
- Finally, open the DFSMSrmm CIM provider log, rmmcim.log, for additional information. See Using the DFSMSrmm CIM logger for additional information on working with the DFSMSrmm CIM logger.

If the CIM provider uses the direct HLL API (WEB_SERVICE_REGISTRY = NONE):

Ensure that this symbolic link is set within the $LIBPATH of OMVS:
```
ln -e EDGXHCLL libEDGXHCLL.so 
```
Ensure rmmjapi.jar is added to your CLASSPATH variable.

Refer to rmmcim.txt for additional troubleshooting hints. You might also want to start the CIM server with tracing ON to obtain more debugging information. See the CIM server documentation on how to enable the trace mode.