"unrecoverable error" HPSM 9.20

[Dominic McConne]

I have a case opened w/ support for this, but just wondering if anyone here had any ideas. 

I'm getting this:

Unrecoverable error in application:  se.call.process on panel call.rad.1

Unrecoverable error in application:  se.view.engine on panel call.init.process.1

Format "sc.display.slos" not found (se.call.process,call.rad.1)

when trying to just view an Incident.  It had been working so I must have done something to mess it up.

I'm not sure if it's in Format Control, a database issue, other....I was trying to use the Debugger to figure it out, but I'm not familiar enough with it to really do any effective troubleshooting. 

[Ronald Baas]

As the message says : Format "sc.display.slos" not found

I would start checking if the format 'sc.display.slos' still exists in your database as it might have been deleted or renamed.

[AFranke]

This error does not relate to a format, as you use it normally:

Every RAD application (or RAD panel as well) has a parameter panel. This panel has the same name as the RAD application and is used, when you can a RAD application.
In fact, if you like to know the parameters with which you need to call a specific RAD application, go into Forms Designer to the format with name as the RAD application and inspect the input properties (I usually prefer the RAD editor with help on field to do that, but basically its the same thing).

So what you need to check, if you have a RAD application sc.display.slos in your system - in my OOB system, I didn't find it.
If so, you either miss it after an upgrade, or the call from Process record is defective.
To find out, which Process contains this, reproduce while running debugdbquery:999 and inspect the log.

[Dominic McConne]

I think what may have happened is that when the DBA set up the database for Release Control, it wacked the HPSM database.  Still investigating....

5132(  3300) 11/07/2011 07:08:59  RTE D (0x02C89D00)      DBACCESS - Find         against file format
  5132(  3300) 11/07/2011 07:08:59  RTE D DBFIND^F^format(sqlserver I)^1^0.000000^ ^0^0.000000^"syslanguage="en" and name="sc.display.slos""^ ^0.000000^0.000000 ( [ 1] se.call.process call.rad.1 )
  5132(  3300) 11/07/2011 07:08:59  RTE D (0x02C89D00)      DBACCESS - Find         against file format in 0.010000 seconds
  5132(  3300) 11/07/2011 07:08:59  RTE D (0x02C906C0)      DBACCESS - Cache Find   against file scmessage found 0 records, query: syslanguage="en" and class="error" and message.id="10"
  5132(  3300) 11/07/2011 07:08:59  RTE D (0x02C906C0)      DBACCESS - Find         against file scmessage

[Dominic McConne]

Well I restored the database from a backup from last week and I'm still getting the same errors.  Still investigating...

[HeikeUlshoefer]

I just want to add one thing to Ronalds reply:
sc.display.slos
is no format in the SM 9.20 Out of the box system. It must be a customized, maybe migrated format (from older ServiceCenter days).
Where is the format "sc.display.slos" used ? You can check that with the RAD application find.string . If you need some more advise how to use that application, let me know.

[HeikeUlshoefer]

The system searches for
syslanguage="en" and name="sc.display.slos"
What happens if you search with forms designer with expert search
name="sc.display.slos"
without the syslanguage parameter ?

[Dominic McConne]

I'm not sure how to use the expert search in Format Control.  What I did returned this:

Query field (sc.display.slos) in (formatctrl) not defined in dbdict (se.search.engine,select.records)

[RemcoGommers]

Hi Dominic,

- in SM, on the command line type : db,
- then in Database Manager, goto the format screen,
- once the format screen has opened, in the field name format name type in :sc.display.slos

If the format exists it will be found here. If it doesn't, then the format is not in the database, and that would explain why you are getting the errors that you saw..

Additionally, you can check in SM to see if this particular format gets referenced anywhere in the system.

For that, use the find.string RAD app:
- again, from the command line in SM, type ag, this opens the RAD editor,
- in the application name field, enter : find.string,
- once the find.string RAD opens, click on the Test button in the button bar,
- click on the Proceed button on the button bar,
- now on the entry screen for the find.string app, enter the search string, in your case sc.display.slos, in the string field,
- in the File field you can enter any name of a SM table, for which you want to search this string within that table,

In case a record gets found in the table that contains the string value, you will see a list displayed that shows the name of the record in that particular table that contains the string value.
If no record is found, the you will get a message stating this.

The most obvious SM files you want to search are:
- format,
- formatctrl,
- displayscreen,
- displayoption,
- Object,
- Process,
- States,

Have a go to see if the format exists in SM, or whether a record references the format you are looking for.

[Dominic McConne]

Thanks for the help everyone!  The sc.display.slos wasn't showing in our 9.20 version but is in our 7.02.  It might be something that was specially tailored.  I couldn't figure out where/what to do with it so I just uninstalled everything and did another fresh install of 9.20. 

[-m- · Accepted solution]

For those that are interested, the error messages can be translated as follows:

A Process record (see Document Engine) was attempting to execute a RAD Application named: sc.display.slos. The error message also indicates the Process was defined as an Initialization Process (see States in Document  Engine).

Based on the errors, scenario (viewing an Incident) and OOB SM7x data, the im.view.init Process record was the likely cause of the issue. The question of how that Process record got into the SM9x system is a different issue.

Note: The sc.display.slos RAD Application exists in SM7x but not in SM9x. It would take a list of SLA IDs, query for related sloresponse records, and then build a number of variables (arrays).

[Dominic McConne]

"The question of how that Process record got into the SM9x system is a different issue"

I must have pulled it from our 7.02 to our 9.20 system in one of the unload/loads I did.  Not sure which one though...