04 - Daily Tasks

HP Service Manager 9.
x: System Admin
©2010 Hewlett-Packard Development Company, L..P. 1-1

HP Service Manager 9.x: System Admin


• Review the sm.log file for warnings and errors for negative performance indicators.
• There are many different types of warnings and errors, such as a license about to expire,
warnings about java heap space, shared memory and others. If desired, the Windows find
command or the UNIX Grep tool can be used to search the sm.log file and extract desired text
into another text file. For example, from the Windows DOS command prompt, change the path
to the Service Manager logs folder and issue the command:
find “ E “ sm.log > smerrors.log
Find searches the sm.log file for any line that has an “ E “ (Error) message level with a space on
either side of the letter and writes it to a new log file. You can change the search string to filter
on some other element in the log, change the initial log being used, and the name of the external
log file created.
• Investigate each one and contact support if you need assistance on fixing the issue or an
explanation of the message. Support will require a copy of the log to investigate.
• The following parameters added to the server’s sm.ini file will also help ensure meaningful data
to check:
– msglog:1 – captures all onscreen messages in the sm.log in addition to being sent to the user’s screen.
– debugdbquery:<n> – captures details of all queries that take longer than <n> seconds to
execute. Use a large enough number, such as 3 to only get messages written to the log file for
queries that took longer than 3 seconds to execute.
– Note: The find or grep tool is often used in conjunction with the Service Manager
debugdbquery parameter to help indentify slow queries, partial or non-keyed indexes, and
timing thresholds. The results can then be imported into a spreadsheet to sort and analyze
the data.

• The following list contains the most common HP Service Manager errors encountered. For
information on solutions to the most common errors, see the Help Server for the related topics.
– Error message: Cannot Find SQL Server, Error Connecting to servername.
– Error message: Corresponding join not defined.
– Error message: Error opening the Core.ir file in read mode.
– Power outages and hardware failure.
– Slow query execution.


Schedule file
• The schedule file contains a list of outstanding scheduled tasks the Service Manager system will
perform. Scheduled tasks are created either from agent initialization records or from triggers. The
Schedule File enables you to establish the interval in which your background processing agents
run, such as refreshing charts, marquees, global lists, and SLA records, scheduling archives and
purges of tables and log files, process messages, invoking the inactivity timer process, and more.
Accessing the schedule file

• In the Service Manager command line, type the following command: sch and then press Enter,
or, from Database Manager, type schedule, click the Search button, and select the schedule
form.
• The schedule.looksee.g form opens.
Note: Once you have created an Agent Record, you must schedule it to be run.


• When checking which system processes are active in the system status, it is a good idea to
maintain a list of those background processes that should always be running. If one of these
processes is not running, check the sm.log file to see if there are any messages as to what caused
the interruption. Ensure that the process is in the startup record of the info table.

• The Anubis background process monitors background processes and automatically restarts a process if it
has terminated for any reason.
• To start the anubis process, it will be necessary to:
1. Create an anubis agent record
2. Create a schedule record to call the anubis agent
3. Start the process through the System Status form.
Note: To automatically start the anubis process upon starting the Service Manager server, add the
process to the info table’s startup record.
Side Note - The process name, Anubis, was coined by the ServiceCenter Developer who created the
process and named the process after the Egyptian god of the dead since the process can bring a killed
process back to life. For more information about Anubis and general background scheduler processing
refer to the Help Server contents Server Performance Tuning –> Scheduled Processes.
Creating an anubis agent record
• You can create an anubis agent record to restart stopped background processes automatically.
To create an anubis agent record:
1. In the command line, type the following command: info and then press Enter.
The info.startup.g form opens.
2. Type the following information.
– Type: anubis.
– Description: Agent process that brings a dead process back to life.
– Name: anubis
– RAD Application: scheduler
– Class: anubis
– Wakeup Interval (secs.): 30
3. Click Add.
Service Manager adds the Information record.

Creating an anubis schedule record

• To create an anubis schedule record:
1. In the Service Manager command line, type the following command: sch and then press
Enter.
The schedule.looksee.g form opens.
2. Type or select the following information.
– Name: Type anubis.
– Class: Type anubis.
– Expiration: Type or select any date and time prior to the current time.
– Scheduled Class: Type anubis.
– Repeat Interval: Select Other and then type repeat interval. For example, type 00:00:30 for a thirty-second
repeat interval.
– Application: Type apm.anubis.
3. Click Add.
Service Manager adds the schedule record.

Starting the Anubis Process
1. In the System Navigator, click System Status.

2. Check to see if the anubis process appears in the list of processes running on your system.
3. If anubis is not on the list, click Start Scheduler.
4. Double-click anubis in the Startup Record list to start the program.

The Anubis background process now displays in the System Status list with the time it started in the
on-screen message.

• If needed, a Systems Administrator can kill off a user or process through the System Status form to
either free up a floating license or to stop and restart a process without having to bring the server
down.
• To kill a user or process through the System Status:
1. In the System Navigator, click System Status. The system.status.list.g form opens.
2. In the command column, type k next to the process or user you wish to kill and press Enter.
3. Click on the Execute Commands button. A message displays the Session ID for the anubis
process has been terminated.
Note – Most likely, the process or person will not disappear from the list immediately. Wait a
short while and then click the Refresh Display button to refresh the list and remove the
session from view.

Broadcast a message to a particular user

• To broadcast a message to a particular user:
1. Click System Status. The system status form opens.
2. In the Command column, type s next to the user you want to send a message.
3. Click Execute Commands.

4. The operator status display form (operator.status.g) opens.

5. Click Send Msg.
6. Type the message you want to broadcast.
7. Click Send Msg.
Service Manager sends your message to the selected user.

Broadcast a message to all users

• You can broadcast a message to all users from the system status form.
To broadcast a message to all users:
1. Click System Status.
2. Click Broadcast. The system.status.broadcast.g form opens.
3. Type the text of your message in the field provided.
4. Click Send Msg.
Service Manager broadcasts your message to all currently logged on users.

• Killing off a user and sending a broadcast message


• Review the sm.log file or system status regularly to check the number of concurrent users or
connected processes and servlet utilization. If necessary, add another servlet to the group
dynamically or add another servlet line to the sm.cfg file for the next recycle of Service Manager.
On the Windows operating system, when starting a servlet dynamically from a DOS prompt, it is
imperative to not log out from the server machine since this would terminate the servlet you just
started. Ensure that the system is set to lock the desktop and requires authentication to unlock.

• threadsperprocess - Defines the number of threads you want the Service Manager server to
start when it starts a new process. Each thread can support one client connection or one
background process. The recommend maximum value for the parameter threadsperprocess is 60.
Usually the value of this parameter should be below 50.
• session-timeout - Defines the number of minutes that the server waits for a client heartbeat
signal before the server assumes that the client session has timed out and closes the connection. It
is best practice to lower the session-timeout value to 2 minutes if you experience Service Manager
Web client sessions lingering for a longer period of time than expected.





• Check the database backups (or have the DBA check them) to ensure they completed with no
problems. If the backup failed, consider taking another backup or determine if this can wait for
the next scheduled backup. In most companies, the DBA is responsible for backups but the System
Administrator should know the backup schedule and verify that backups work correctly.
• When deciding what files you need to back up, note that the following file types are essential to
run HP Service Manager:
– sm.ini
– sm.cfg
– All RDBMS data files


Locks
• Occasionally view the lock activity in the environment – either through system status or through
the command sm -reportlocks. If there are locks on items other than agent records, and they are
held for more than a few seconds, investigate. For instance, if a user has a lock on an incident
ticket for a very long time and other users or background processors are waiting for the lock to
be released, you may want to contact that user to release the lock. If this is not possible there
may be a need to “terminate” the user’s session that is holding the lock so that other processes /
users can access the ticket.

To check the system to see if you have a lock on a resource or to unlock a resource:
1. Login as a falcon or a System Administrator
2. From the System Navigator, select System Status. The System Status form displays.
3. Select Show Locks.
4. In the Command column, type a “K” by the resource you wish to unlock and then select
Execute Command.
The lock on the resource will be freed.

From the Command Line, type: sm –reportlocks
This parameter displays resource locks, which you can capture in a text file using standard output
(stdout) parameters appropriate to your operating system.

Debug a suspended or hung system

• If HP Service Manager is unresponsive or appears hung, you can use the reportsem command
to determine if any locks, or semaphores, as called in the UNIX envirnment, are locked and
releasesem to unlock the semaphore.
• To force the semaphore to release:

1. Log on to the server’s operating system, and open a command prompt.
2. From the shell prompt (Unix) or the DOS command prompt (Windows), change the directories
to Service Manager's RUN folder.
3. Type: sm –reportsem
4. Press Enter.
5. Review the semaphore report and check to see if the # Waiting value is nonzero and/or the
Available value is 0 (or Not Available in a Windows report) for any of the rows. If you see
either of these conditions, you may need to force the release of the semaphore by killing the
lock.
6. Note the value of the unavailable semaphore.
7. Rerun the semaphore report and check the semaphore.
If the semaphore was being used by another thread when you ran the first report, the value in
the Count column should increment in the second report, and the semaphore is available. If the
value remains the same, then the semaphore is not available and you must manually release it.
Force the lock (semaphore) to release on UNIX
Warning: You must©2010

perform this procedure
Hewlett-Packard only with
Development the L..P.
Company, assistance of HP Customer Support.
1-31
Releasing a semaphore or mutex prematurely can damage the integrity of your data.

• Verify that none of the schedule records have encountered errors. Schedule records that
encountered an error will have a status of “application failed due to error - check msglog for
possible messages” and the class field will be empty with the scheduled class being set to the
value of the class field. On occasion, the class field will contain a value of “error”. The status of
“application running” does not indicate an error in most cases but, may indicate that the
application is in a loop if in that state for more than 15 minute, or that the processor was
terminated by an external source. Contact support and provide an RTM:3 and
debugdbquery:999 trace on failed or looping background process as described in the
Diagnostics and Tuning white paper.
• In the slide above, the schedule record, KMUpdate, displays an error in the Status field. The
Knowledge Management service, KMUpdate, had been stopped, thus causing the error in the
schedule record. It is possible by restarting the KMSearch service, the
• To resolve a schedule record that has an error in the Status field:
1. In the Service Manager command line, type sch.
2. In the Name field, type: KM and click Search.
3. In the Status field, clear the contents and type: Rescheduled.
4. In the Class field, type whatever data is displayed in the Scheduled Class field. In this example,
KMUpdate.
5. In the Expiration field, change the date or time to a date or time in the past.
6. Verify either a RAD application is in the Application field on the Description tab or Javascript is
in the Javascript field on the Javascript tab.
7. Click Save.

• If using asynchronous IR, check the irqueue table. The IRQueue process (sm –que:ir) should pick
up records from the irqueue table on a regular basis and process them. If this is not the case,
verify that the process is running and check for any error messages in the sm.log file. Contact
support with the information found in the log file for help.



On-call schedules
• On-call schedules help managers or administrators determine whether they have enough resources on call
to cover all shifts for each day. The on-call schedule specifies who is to be notified, when, and the
notification method. An administrator must complete the On Call Information form to identify individual
operator or contact assignments before HP Service Manager can create an on-call schedule record.
• At midnight, the problem background processor generates the on-call schedule for the next day. The
background processor uses information in these tables to produce the on-call schedule for the next 24
hours:
– caldutyhours contains shift definition records.
– operator and contacts provide information about the operator.
– oncallsched defines on call assignments, notification methods, and time zone variations.
– tzfile defines time zones.
Daily Schedule
• Service Manager displays daily schedule information for regular on call dates and times using a relative
date and time format that is not dependent on a specific time zone. The relative time format is
dd hh:mm:ss. For example, the Servicedesk Agent always begins work at 8:00:00 and stops work at
17:00:00.

• Each day, Service Manager creates a daily schedule record in the oncall table for each group
defined in the Daily On Call Records table (oncallsched). The default time for the generation of
this record is midnight (00:00:00). As the administrator, you can create and define the Daily On
Call Records.
• To determine the recipients of a notification sent to a group specified in the Recipients field, the
Notification Engine refers to the Group File field in the Notification Definition record. If the oncall
table is selected, then only the people on call at that day and time (in the group specified in the
Recipients field) receive the notification. The members of the on call groups are redefined daily
from the oncallsched table.
• To Create an On Call Schedule:

1. Click Tailoring > Notifications > Daily On Call Records. The oncallsched.g form opens.
2. Type or select the information for the various fields, specifying days of the week and start and stop times, and
a notification method to be used.
3. Click Add. Service Manager displays the message: oncallsched record added.
4. At midnight, Service Manager will generate the next day’s On Call Schedule from the Daily On Call Records.

Exceptions
• Service Manager displays on call exception dates and times using an absolute date and time
format. The absolute date and time are for the time zone specified in the On Call Information
form. If you omit a time zone, the default value is the time zone in the company record. The
absolute time format is mm/dd/yyyy hh:mm:ss.
• Exceptions are useful to put temporary changes into an operator or contact’s On Call
Information, without making a permanent change to the Daily Schedule. Exceptions can be used
to change either the Notify Method, or the Time Zone for an operator or contact for a period of
time.
• Note: If “Replace Daily” does not evaluate to true, the On Call Schedule will use both the Daily
and the Exception methods of notification.
Time zones
• The On Call Information form has a time zone field where you can note deviations from the server
time zone for any operator. For example, consider this scenario:
– A European company has headquarters in London, where the corporate server is located.
– The company record specifies that Western European Time (WET) is the default time zone.
– Rachel Boudreau is an employee, but she works remotely from California.
– Her manager notes that her Local Time in the on-call schedule form is Pacific Standard Time (PST).
– When her manager sends her to Chicago for two weeks of on-site customer support, the manager makes an
entry in the Exception Time Zone field that temporarily changes her location to Central Standard Time (CST).
©2010 Hewlett-Packard
– When she returns to California, the manager Development
removes thisCompany,
exceptionL..P.
entry from the on-call schedule form1-39
before
• One critical feature of the Daily On Call Records form is the Notify Method field. If you are using
oncall as your Group table, the message type would be determined by the information in the
Notify Method field of the oncallsched record, not the message type defined in the notification
record. Unless you wish to override the notification record, you do not have to enter a Notify
Method type when you are using oncall as your Group table.
• It is important to note that changes to the records in Daily On Call Records will not be reflected in
the actual On Call Schedule until the daily record is re-generated (by default, the next midnight).

• The sc.oncall RAD application is run once a day (at midnight by default) by the problem
scheduler to generate the oncall records (the On Call Schedule) for the next 24 hours. For each
group in the On Call Information table (oncallsched), a record is generated in the On Call
Schedule for the next day. Each record lists the hours each contact/operator in a group is
available to receive notifications, and the method that will be used to notify them (if specified).
• To force an update of the oncall records based on the current oncallsched records, type
*asc.oncall in the Embedded Command Line. (*a tells the server to execute a RAD application,
in this case, sc.oncall.)


• If using external email from Service Manager, check that emails are being sent successfully
• If email is not being sent successfully, check the following:
– Verify that sm –scautolistener:<port#> (for incoming and outgoing email) or sm –emailout <”profilename”> (for
outgoing email only) were started successfully by checking the sm.log file and the system status screen
– Check whether the emails are in the eventout table
– Verify that the mail server is running
• For more information refer to the latest SCAutomate Applications for Windows NT and
UNIX documentation.

Checking the Eventout Queue for Email

To check if an email has been generated and is waiting to be sent from Service Manager:
1. Click Taioring > Event Services > Output Events, or,
In the Command Line, type: eventout.
2. Search for an event with a Event Code of email.
The Event Services Output Queue displays emails waiting to be sent from Service Manager.
3. Scroll through the list to find your email or narrow your search criteria in step 2.
Troubleshooting: Sending an email to an external program with SCAuto installed
• To test sending an email to an external program if SCAuto/SDK is installed:

1. Click System Administration > Ongoing Maintenance > Communication
Utilities > Write an Output Event.
2. Select Generic (Message).
3. Click Write Event.
A message displays saying a generic dbadd event has been written to the output queue.
4. Click Taioring > Event Services > Output Events.
5. Search for an event with a event code of dbadd.
The Event Services Output Queue should include the test message you generated.






04 - Daily Tasks

Uploaded by

Copyright:

Available Formats

04 - Daily Tasks

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04 - Daily Tasks

Uploaded by

Copyright:

Available Formats

HP Service Manager 9.

©2010 Hewlett-Packard Development Company, L..P. 1-1

©2010 Hewlett-Packard Development Company, L..P. 1-2

©2010 Hewlett-Packard Development Company, L..P. 1-3

©2010 Hewlett-Packard Development Company, L..P. 1-4

©2010 Hewlett-Packard Development Company, L..P. 1-5

©2010 Hewlett-Packard Development Company, L..P. 1-6

Accessing the schedule file

©2010 Hewlett-Packard Development Company, L..P. 1-7

©2010 Hewlett-Packard Development Company, L..P. 1-8

©2010 Hewlett-Packard Development Company, L..P. 1-9

©2010 Hewlett-Packard Development Company, L..P. 1-10

Creating an anubis schedule record

©2010 Hewlett-Packard Development Company, L..P. 1-11

Starting the Anubis Process

1. In the System Navigator, click System Status.

©2010 Hewlett-Packard Development Company, L..P. 1-12

©2010 Hewlett-Packard Development Company, L..P. 1-13

©2010 Hewlett-Packard Development Company, L..P. 1-14

Broadcast a message to a particular user

©2010 Hewlett-Packard Development Company, L..P. 1-15

4. The operator status display form (operator.status.g) opens.

©2010 Hewlett-Packard Development Company, L..P. 1-16

Broadcast a message to all users

©2010 Hewlett-Packard Development Company, L..P. 1-17

• Killing off a user and sending a broadcast message

©2010 Hewlett-Packard Development Company, L..P. 1-18

©2010 Hewlett-Packard Development Company, L..P. 1-19

©2010 Hewlett-Packard Development Company, L..P. 1-20

©2010 Hewlett-Packard Development Company, L..P. 1-21

©2010 Hewlett-Packard Development Company, L..P. 1-22

©2010 Hewlett-Packard Development Company, L..P. 1-23

©2010 Hewlett-Packard Development Company, L..P. 1-24

©2010 Hewlett-Packard Development Company, L..P. 1-25

©2010 Hewlett-Packard Development Company, L..P. 1-26

©2010 Hewlett-Packard Development Company, L..P. 1-27

©2010 Hewlett-Packard Development Company, L..P. 1-28

©2010 Hewlett-Packard Development Company, L..P. 1-29

From the Command Line, type: sm –reportlocks

©2010 Hewlett-Packard Development Company, L..P. 1-30

Debug a suspended or hung system

• To force the semaphore to release:

Force the lock (semaphore) to release on UNIX

Warning: You must©2010

©2010 Hewlett-Packard Development Company, L..P. 1-32

©2010 Hewlett-Packard Development Company, L..P. 1-33

©2010 Hewlett-Packard Development Company, L..P. 1-34

©2010 Hewlett-Packard Development Company, L..P. 1-35

©2010 Hewlett-Packard Development Company, L..P. 1-36

©2010 Hewlett-Packard Development Company, L..P. 1-37

• To Create an On Call Schedule:

©2010 Hewlett-Packard Development Company, L..P. 1-38

©2010 Hewlett-Packard Development Company, L..P. 1-40

©2010 Hewlett-Packard Development Company, L..P. 1-41

©2010 Hewlett-Packard Development Company, L..P. 1-42

©2010 Hewlett-Packard Development Company, L..P. 1-43

Checking the Eventout Queue for Email

Troubleshooting: Sending an email to an external program with SCAuto installed

• To test sending an email to an external program if SCAuto/SDK is installed: