Attempt to load a file from the command line results in the errorRTE E ==>Error!! failed to parse command, execution aborted::

Attempting to load an unload file on Windows from the command line can result in an error when the file path contains a backslash ‘\’

For example this command line:

sm file.load c:\clocks.unl NULL NULL winnt

will result in these errors:

RTE E ==>Error!! failed to parse command, execution aborted:
RTE E ‘sm file.load c:\clocks.unl NULL NULL winnt’
RTE E Please examine/correct your parameters, then resubmit the command.


The backslash character is interpreted as an escape character in which the data following the backslash is read as input.


Use a double backslash, \\

sm file.load c:\\clocks.unl NULL NULL winnt

to allow SM to read the backslash as a backslash


Inactivity timer throws negative minutes in message

When the inactivity timer sends a message, the onscreen message is ok but the popup message looks like:

Your inactive HP Service Manager session (UID# 5) will be automatically disconnected in -2132464512 minute(s) 270643684 second(s)

One scmessage record seems to be wrong in the database. This could be caused by migration from earlier SM versions.

Wrong scmessage record :


Message number=130

Text: Your inactive HP Service Manager session (UID# %ld) will be automatically disconnected in %d minute(s) %d second(s)

To fix this issue overwrite the Text in scmessage record

Your inactive HP Service Manager session (UID# %ld) will be automatically disconnected in %d minute(s) %d second(s)
Your inactive session will terminate in %ld minutes,do you want to extend your session time?

How to modify the scmessage record:

1. Command db

2. Table: scmessage

3. Search

4. Search for this scmessage record with class “scbase” and message number “130”.

5. Correct the Text

6. Save the record

How exactly does “Build List on Startup” (field build.startup) option work for globallists

Current Helpserver:

Once you have created a global list with the Build List on Startup option selected, Service Manager automatically rebuilds the global list when users log in.


This is not completely true.

For globallists with “filename” and “limiting SQL” the background process “lister” must run and update the globallist if something has changed.

This kind of global list is not “_automatically rebuild when users log in_”. lister process is neccessary.

The “Build List on Startup” flag does not initiate a “Rebuild” of the list, it just makes the current list available to a new logged in user.

A globallist is new build on either one of these actions:

– press “Rebuild Global list” (current and new sessions get the new list)

– lister process runs on this globallist (expiration is in the past and background process “lister” runs).

This is neccessary for globallists with “filename” and “limiting SQL”.

In SM941 there is an optimization called “lazy loading Global Lists”. In SM940 and before, all globallists (GL) were loaded by applications (APPs) which caused a long login delay.

Since SM941, GL will be loaded into memory by RunTimeEnvironment (RTE) only when it is needed, and for a newly added Global List, a restart of RTE is needed unless the name begins with “$”.

Reopen closed Incident from Interaction is now allowed

Service Desk Interactions with a Notify By value of Telephone will set to Callback status when the linked Incident is closed. However, the ability to reopen the Incident from within the Interactions Required Actions does not exist. Users are presented with a Closed Incident with no ability to reopen it.


The following steps will work around the problem.

1. Create a new RuleSet with the following:

Name: im.reopen

Available as Action: true

Name: Reopen Incident

Table name: probsummary

Rules: Call a Process "im.reopen"

2. Copy the Workflow "Incident" – along with the RuleSets – and give it a new name

Select the Phase "Closure" in the chart.

In tab "Action", add one action:

Id: Reopen

Action: Reopen Incident

Location: Tray

Action Condition: $G.ess="false" (select Variable $G.ess equal Value false)

3. Assign the new Workflow

4. The ability to reopen the closed Incident is present

Equivalent RAD command for the “PROCEED” button

When automating the SM deployment process via HPOO, while taking an unload, we need the equivalent RAD command for the "PROCEED" button.

1. Firstly create an unload script to query all backup code, for example, in OOB, there is unload script named "SQL Upgrade Utility"

2. Secondly create a folder to place the generated unload file, for example, C:\unload

3. Execute command, for example, in Windows, sm.exe -bg us.unload.automation NULL NULL "SQL Upgrade Utility" "C:\\unload\\SQL_Upgrade_Utility.unl" NULL

– For Linux, the folder could be for example /opt/unload, so the parameter in the command is "/opt/unload"

Format control calculation initialize Resolve time as NULL

There is an OOB calculation on format control IM.update.incident which initializes resolved.time, NULL on initialization of format.

Steps to reproduce:

1. Resolve an Incident

2. Save the Incident

3. Exit and again search the Incident

4. Resolve time is NULL

If user saves the record it make the resolve time NULL. in $file=NULL; in $file=NULL;resolved.time in $file=NULL; in $file=NULL;adj.resolution.time in $file=NULL


Go to trigger and set a trigger –>add.resolution.infomation

Table name–>probsummary

Tigger Type –>3 – Before Update

Application –>leave blank

if(record.problem_status==’Resolved’ && oldrecord.problem_status !=record.problem_status)





How the File Upload Servlet and Attachment Upload Servlet be de-activated in web.xml

The functionality for File Upload Servlet, as well as Attachment and Image Upload servlet does not match the table extensionstate, and it requires maintaining this list in addition to maintaining the extensionstate table.

The idea with the allowed extension is to provide additional protection using a so-called “white list”. From the web client, you can submit only attachments whose file types are in this whitelist.

The extensionstate on the other hand, is meant to manage the restrictions, so the “black list”. So actually the File, Image and Attachment Upload Servlet Parameters complement the protection of the table. At startup, the web tier and the Windows client retrieve the forbidden list, which is stored in the extensionstate table in the database; if no list is available, the clients use a default list of forbidden file types stored on the client side. With the new feature you can limit what can be submitted from web client, while you might allow other file types added from Windows client or web services, if they are not restricted in the extensionstate table.

The functionality cannot be disabled directly as there is no switch parameter provided. The fast way is to remove the whole xml label including “allowed” as follows

If this is done, the files with any file types not restricted in the extensionstate table will be allowed to upload, so disabling this functionality you take the risk.