Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.
During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.
We apologize for the inconvenience while we perform important updates to the Community.
This is most likely known bug CSCsr93292:
The Health and Utilization Monitor job interfaces do not work. Instead, they display the following error:
Cannot connect to JRM. Check whether JRM is up and running.
This happens when the System Identity or Common Trust User is changed.
Edit NMSROOT/lib/classpath/jrmuser.properties, and change the Username property to the new System Identity User. The HUM job interfaces will work once again.
(Note: NMSROOT is the path into which CiscoWorks was installed. By default, this is /opt/CSCOpx on Solaris and C:\PROGRA~1\CSCOpx on Windows.)
I checked the jrmuser properties and the username was correct. I did start getting this error after I did change the System Identity User besides also doing a Miscrosoft backup of the server.
I tried changing the System Identity User back to what is was and it is still failing. Thanks for your response to my question.
The name in jrmuser.properties should really always be "admin". If the System Identity User is no longer admin, then you will get this error. If you've set the SIU back to admin, restart Daemon Manager, and you're still getting this error, then there may be a process failure. Please post the output of the pdshow command, the jrmuser.properties, and screenshot showing the current SIU.
You did not provide a screenshot showing the currently configured System Identity User. If it is admin, then restart Daemon Manager, and this error should go away.
All this checks out, a restart of DAemon Manager should allow HUM to connect to jrm. If not, please post the output of the pdshow command and the upm_process.log.
Okay, jrm is truly down because the CMF database has not come up. Shutdown Daemon Manager, and post the list of contents under NMSROOT/databases/cmf.
I just wanted the LIST of contents. You should delete these attachments as they may reveal sensitive information.
To fix your jrm problem, delete the cmf.log file. Then run:
NMSROOT\objects\db\win32\db\dbsrv10 -f NMSROOT\databases\cmf\cmf.db
Then restart Daemon Manager, and you should be good to go.
If you don't have LMS 3.1, then you won't have dbsrv10. The following command run from a DOS shell works for LMS 3.0:
NMSROOT\objects\db\win32\dbsrv9 -f NMSROOT\databases\cmf.db
However, based on this output, the very worst has happened. The cmf database is corrupt. The cmf database holds the DCR, so unless you have a known good LMS backup, you will need to reinitialize all of your LMS databases.
If you have a known good backup, restore it using the NMSROOT\bin\restorebackup.pl command. If not, you will need to run the following commands:
NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=cmf dmprefix=CMF
NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=rmeng dmprefix=RME
NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=ani dmprefix=ANI
NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=dfmInv dmprefix=INV
NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=dfmEpm dmprefix=EPM
NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=dfmFh dmprefix=FH
NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=ipm dmprefix=Ipm
NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=upm dmprefix=UPM
NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=opsxml dmprefix=Opsxml
Then remove NMSROOT\objects\smarts\local\repos\icf\DFM*.rps.
If you end up reinitializing your databases, you will lose all of your data, but LMS should be functional once again.