HP Interactive Upgrade Guide

Select the current version of your Service Manager or ServiceCenter applications

SC 6.2x
SM 7.0x
SM 7.1x
SM 9.2x
Welcome to the HP Service Manager 9.31 Interactive Upgrade Guide. This guide enables you to select options that describe your configuration of ServiceCenter or Service Manager and then view or print a customized upgrade guide that includes only the requirements and tasks that apply to you.

Start by choosing your current version of ServiceCenter or Service Manager applications from the options on the left.The HP Service Manager Upgrade Utility upgrades your applications to Service Manager 9.31 .

Select the type of database that currently stores your data

Peregrine Four (P4)
RDBMS
If you use P4, before you can upgrade the server and client or upgrade the applications, you must push all of your existing data to an RDBMS supported by Service Manager 9.31.

Select your RDBMS

SQL Server
DB2
Oracle
Select the relational database management system (RDBMS) that you will convert your data to.

Select your operating system

Windows
UNIX

Have you upgraded ServiceCenter or Service Manager in the past?

Yes, we have performed an upgrade in the past
No, this is our first upgrade

Do you want to use the optional data scan utility before you run the upgrade?

Yes, show me the instructions to use the optional data scan utility
No, I do not want to use the data scan utility
Before you run an upgrade, you can scan a portion of your data set for certain types of data that may cause issues following the upgrade. The data scan utility scans for two types of problematic data: null values in fields applied with certain keys and mismatches between the data type defined on the field and the data type of the field value.

View or print

Click View to view the upgrade guide online, or click Print to send the guide to a printer for printing.

Check your selections

The following steps are customized according to your selections. Check that your selections are correct.

 

If you want to select different options, click Change. Make your selections, and then click View or Print.

Using this guide

This upgrade guide is interactive and enables you to view the upgrade instructions that are relevant for your Service Manager setup. You can change your selections any time by clicking the Change button at the top of the page. When you complete a step or task, you can click the check box to the left of the heading to collapse that section. To expand sections, clear the check box.

The bottom of the pages in the online version of this guide list the following identifying information:

  • Document Release Date, which changes each time the document is updated.
  • Software Release Date, which indicates the release date of this version of the software.

To check for updates, or to verify that you are using the most recent edition of this document, go to the HP Software Product Manuals web site (http://h20230.www2.hp.com/selfsolve/manuals). This site requires that you register for an HP Passport and sign-in. To register for an HP Passport ID, click the New users - please register link on the HP Passport login page. You will also receive updated or new editions if you subscribe to the appropriate product support service. Contact your HP sales representative for details.

Printing this guide

This guide will not print correctly if you attempt to print it using the Internet Explorer print feature. If you decide that you want to print this guide, click Change at the top of this page, and then click Print at the bottom of the page where you made your selections.

Finding troubleshooting information

You can find troubleshooting information at the end of this guide.

Upgrade process overview

The HP Service Manager Upgrade Utility upgrades your applications to Service Manager 9.31 .

Note: You can upgrade to interim application releases by using the Applications Patch Manager. For more information, see the Applications Patch Manager Guide.

You use three environments to complete the upgrade process: your current production environment, a new development environment, and a new test environment. You will duplicate your production environment to create the development and test environments. Run the out-of-box upgrade and create the custom upgrade on the development environment, and then run and test the custom upgrade on the test environment before you apply it to your production environment. The figure below provides an overview of the steps in the upgrade process.

Upgrade process overview

Upgrade process overview

Upgrade process overview

Plan the upgrade

Before you begin an upgrade, HP recommends that you complete the following steps:

  1. Review this upgrade guide to familiarize yourself with all of the requirements.

  2. Understand that you should be an experienced system administrator who is familiar with your installation and knows how the existing Service Manager file system operates, how the application files function, how to compare records, and how to use the Rapid Application Development (RAD) environment if you have tailored RAD applications. You can also contact HP Software Support for help with troubleshooting upgrade errors.
  3. Make sure that you are familiar with the tools available and have access to the documentation:
    • Service Manager tools: Database Manager, Database Dictionary, Display Application, Forms Designer, System Definition.
    • RDBMS: Know how the Service Manager file system interacts with the relational database management system (RDBMS) that stores your data.
    • Documentation resources:
      • Service Manager 9.31 online Help for information about database dictionaries, Database Manager, Forms Designer, Request Management, and the Display application. You can access the Help when you install the Help server.
      • HP Service Manager Installation Guide for client and server installation instructions. HP bundles this guide with the installation media.
      • HP Service Manager Release Notes for information about Software Change Requests (SCRs), enhancements, and known issues. The release notes are part of the installation materials and are also available on the Software Support web site (http://www.hp.com/go/hpsoftwaresupport).
  4. Meet the system requirements:
    1. Your RDBMS version, operating system, and client and server environment must meet all criteria listed in the Compatibility Matrix for Service Manager 9.31. You can view the Compatibility Matrix on HP Customer Support web site.
    2. Convert all database tables and fields from lowercase to uppercase: Service Manager does not generate lowercase table names or field names. Therefore, if your database is case sensitive, you must convert all tables and fields from lowercase to uppercase before you can upgrade the server and client or applications.

    3. Do not install Service Manager or the Upgrade Utility on an NFS-mounted partition. Service Manager generates significant database read/write activity, and an NFS-mounted partition is significantly slower than a local drive and can cause serious performance degradation.
    4. Convert your RDBMS code page to Unicode. For more information, see your RDBMS vendor documentation.
  5. Perform a system health check: A well-maintained production system is the easiest to upgrade. Before starting the upgrade process, perform all regular maintenance on your production system.
  6. Develop an upgrade strategy:

    HP strongly recommends that you allow the Upgrade Utility to modify your RDBMS tables for you. If you chose not to allow the Upgrade Utility to modify your RDBMS tables and want to modify your tables manually, you can use the SQL Compare utility to determine the tables that you need to update.

    Tailored systems: A list of tailored files can help you resolve differences quickly between your existing files and new files. You can also use the SQL Compare utility to determine how files differ. Customization affects the upgrade process the following ways:

    Object changes: The Upgrade Utility compares the objects in your database with their out-of-box versions and the corresponding objects provided from the upgrade package. The Upgrade Utility compares objects by their signatures. Each data record in Service Manager has a unique signature, which changes once that data record is updated.

    • If an object in your database that has been tailored does not match the corresponding object that is provided by the upgrade package, the following behaviors apply: 
      • If this is your first upgrade, the Upgrade Utility tries to merge the object from the upgrade package with your tailored object. If the merge is successful, the Upgrade Utility marks the new merged object as "Auto Merged." If the merge fails, Upgrade Utility marks the object as "Renamed." In both cases, the Upgrade Utility prefixes the object from the upgrade package with "NEW931," and then copies the object in your datebase and prefixes that object as "PRE<version_number>". For example, an object from application version 7.11.000 would be prefixed with "PRE7.11.000."
      • If this is a custom upgrade, the Upgrade Utility marks the object from the upgrade package as “Forced,” and then copies the object in your database, prefixing it with “OLD<version_number>." For example, an object from application version 7.11.000, would be prefixed with "OLD711."
    • If an object in your database has been tailored, but the out-of-box version matches exactly the corresponding object from the upgrade package, the following behaviors apply:
      • If this is your first upgrade, the Upgrade Utility keeps your local version, even if your version has been tailored and marks your local version as “Kept Customer”.
      • If this is a custom upgrade, the Upgrade Utility marks your local version object as “Already Current.”
    • If an object in your database has not been tailored, but does not match the corresponding object provided from the upgrade package, the following behaviors apply:
      • If this is your first upgrade, the Upgrade Utility overwrites the object in your database with the object from the upgrade package, and marks the object as “Upgraded.”
      • If this is a custom upgrade, the Upgrade Utility marks the object from the upgrade package as “Forced,” and then copies the object from your database, prefixing it with “OLD<version_number>." For example, an object from application version 7.11.000, would be prefixed with "OLD711."
    • If an object in your database matches exactly the object provided from the upgrade package, the Upgrade Utility marks the object as "Already Current" regardless of whether this is the first upgrade or a custom upgrade.
    • If an object from the upgrade package does not have a corresponding object from your database, the Upgrade Utility adds the object to your database and marks the object as "Added" regardless of whether this the first upgrade or a custom upgrade.
    • If an object from your database does not have a corresponding object from the upgrade package, the Upgrade Utility ignores it.

    Schema changes: The Upgrade Utility merges new fields to existing schemas, without deleting any existing fields.

    Field mapping changes: The Upgrade Utility applies field mapping changes automatically. For example, when a length change is required, the utility automatically expands the length mapping.

    Key changes: The Upgrade Utility applies key changes automatically. It does not delete existing keys, except when Unique keys must be overwritten to support required changes. Do not tailor any applications in your production database during the upgrade process. Changes made to applications in your production database after you duplicate the production environment for running an upgrade may not get upgraded.

    Localized systems: The Upgrade Utility supports upgrading systems that have language packs applied. The upgrade contains the latest language pack records and will upgrade any language pack record to the latest version or flag any changed records for reconciliation.

    Backups: HP highly recommends that, at a minimum, you back up the development environment database after you apply the upgrade and after you resolve conflicts.

  7. Note the following new features provided by the release of Service Manager 9.31 that require an application upgrade:
    • Process Designer
    • Knowledge Management SOLR search engine
    • Mobility
    • Service Manager 9.31 Service Request Catalog (SRC)

Upgrade the server and client on your production system

Make sure that you have upgraded your server and the client to the latest version before you attempt to run an application upgrade. This allows the upgrade utility to call the new functions in the latest server and client and to take full advantage of all of the application features following an upgrade.

To upgrade your applications to version 9.31 you must first perform a server and client upgrade. The applications upgrade to HP Service Manager 9.31 depends on features in the 9.31 platform (server and client) .

  • To obtain the latest client, install the client from the installation CD-ROM and follow the instructions in the HP Service Manager Installation Guide.
  • To obtain the latest server, install the HP Service Manager 9.31 server from the installation CD-ROM.

If you have deployed Knowledge Management, you must also upgrade the Knowledge Management Search Engine to the new version. Follow the instructions in the HP Service Manager 9.31 Installation Guide to install the latest search engine.

Convert all ServiceCenter data to a supported RDBMS

Service Manager stores application data in a relational database management system (RDBMS). Before you can upgrade the server or applications, you must convert your ServiceCenter data from your original P4 data store to a supported RDBMS. For more information about how to convert your data, see the Database Conversion and RDBMS Support Guide for HP ServiceCenter 6.2 available on your ServiceCenter 6.2 help server.

Enlarge the page size for DB2 RDBMS table spaces

Increase the user space from the current 4k size for the following tables:

  • inbox
  • kmquery
  • svcCatalog
  • systemperform

Notes:

  • USER32K represents the name of the larger-sized user space, one that has a buffer size larger than 4k.
  • If the kmquery table is empty, you can skip the insert step.

To enlarge user space for affected tables

Complete the following procedure from the command line. Increase the user space for each table separately.

  1. From the command line: type the following commands. Press Enter after each command:
    1. create table INBOXM1_TEMP like INBOXM1 in USER32K
    2. commit
    3. insert into INBOXM1_TEMP (select * from INBOXM1)
    4. commit
    5. drop table INBOXM1
    6. commit
    7. rename table INBOXM1_TEMP to INBOXM1
    8. commit
  2. Repeat step 1 for each table, making the applicable command substitutions. Note that the command sequence shown in Step 1 applies to inbox1.

Remove indexes and constraints in the RDBMS

The current or a previous upgrade process may fail to remove certain mapped indexes and constraints after removing a key from Service Manager applications. These indexes or constraints may prevent the upgrade process from adding records to those specific tables. To remove these indexes and constraints manually:
  1. Open the dbdict for the svcCatInterface table, and remove the service.request.id unique key.
  2. Log in to the RDBMS, and remove the mapped index for the svcCatInterface table.

    Example: For an Oracle RDBMS, run the following SQL statements to determine the key name and remove the index if it exists:

    select i.index_name, c.column_name from user_indexes i, user_ind_columns c where i.table_name='SVCCATINTERFACEM1' and i.index_name=c.index_name                                
    drop index SVCCATINTERFACEM1_2
  3. Log in to the RDBMS, and remove the mapped constraint and index for the notification table.

    Example: For an Oracle RDBMS, run the following SQL statements to remove the constraint and index (if they exist):

    alter table notificationm1 drop constraint NOTIFICATIONM1_P
    drop index NOTIFICATIONM1_P
    

Purge any existing upgrade files

Remove any upgrade files from previous versions of Service Manager. You can run the purge tool to remove temporary objects that were generated by the Upgrade Utility. However, the purge tool may not clean up some artifacts that could be left from past upgrades, such as objects prefixed with OLD<version_number>. Before running the purge tool, you can search the Upgrade Results report for records with a result type of "Forced" to find left over artifacts. You can export the list of objects to an Excel spreadsheet so that you can refer to the list when you manually delete the objects from your system.

To view the Upgrade Results report

  1. Log in to Service Manager with a system administrator account.
  2. Type smupgrade in the Service Manager client command box and press Enter.
  3. Click View/Merge Upgrade Results in the Upgrade Utilities menu.
  4.  Select Forced in the Result drop-down list, and then press Enter.
  5. If you want to export the to a Microsoft Excel spreadsheet, from the Upgrade Results report, click the drop-down options menu and select Export to Excel. You can also select File > Print from the Upgrade Results report to print the list of records.

To run the purge tool

  1. Type *aapm.upgrade.purge in the client command box and press Enter.
  2. Select I’m done, and I want to remove the upgrade files completely.
  3. Click OK to purge any existing upgrade files.
  4. Click OK again to exit the Purge Routine Completed dialog box.

Duplicate your production environment and create a development environment

Duplicate your current ServiceCenter or Service Manager production environment and create a development environment for running the out-of-box upgrade and creating the custom upgrade. Set up the duplicate environment to match your production server exactly. Make sure that the operating system and service pack level on the development environment is identical to the production server.

  1. Identify a server to use for the development environment.

  2. Make sure that your development system meets all of the upgrade requirements:
    • Your RDBMS version, operating system, and client/server environment must meet all criteria listed in the Compatibility Matrix for Service Manager 9.31. You can view the Compatibility Matrix on the Software Support web site (http://www.hp.com/go/hpsoftwaresupport).
    • Do not install Service Manager or the Upgrade Utility on an NFS-mounted partition. Service Manager generates significant database read/write activity, and an NFS-mounted partition is significantly slower than a local drive and can cause serious performance degradation.
  3. Install the Service Manager 9.31 platform (server and client) Patch on the development system, following the instructions in the HP Service Manager Installation Guide.
  4. Copy your existing production system data onto your development system.
  5. Make sure that you point the development server to your data copy on the development system.

Prepare the Service Manager server on the development environment

To prepare the server for the upgrade, edit the Service Manager configuration (sm.cfg) and initialization (sm.ini) files. Note that you must return the sm.ini and sm.cfg files to their original state after the upgrade, so you may want to keep copies of the original files.

  1. Stop the Service Manager service.
  2. Open the Service Manager configuration file (sm.cfg) with a text editor.
  3. Comment out the sm system.start line to disable the background processes: #sm system.start.
  4. Add sm -sync to the end of the file if it does not yet exist. This parameter starts the sync process, which identifies and releases locks owned by inactive processes and shared memory that is not in use.

  5. If the the sm.cfg file contains more than one instance of the sm -httpPort parameter, comment out all instances except for one. Each sm -httpPort parameter starts a Service Manager server process. The upgrade needs only one process. Comment out all other parameters. Commenting out the parameters disables all of the other Service Manager processes that are not required during an upgrade.
  6. Save and close sm.cfg.
  7. Open the Service Manager initialization (sm.ini) file with a text editor.
  8. Add the sessiontimeout:1200 parameter to the end of the file if it does not exist. If this parameter exists, update it to an appropriate value. This parameter defines the number of minutes that the server waits for a client signal before the server assumes that the client session has timed out and closes the connection. A value of 1200 sets the timeout to 20 hours (1200 minutes), a period that should be long enough for an upgrade phase to complete in a typical scenario.
  9. Add the heartbeatinterval:120 parameter to the end of the file if it does not exist. This parameter 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.
  10. If you use HP-UX, add the following JVM option to the end of the file if it does not exist: JVMOption(#):-Xss6M. This parameter increases the Java virtual machine stack size to 6MB.

    When you add the parameter, replace the hash symbol (#) with an option number that does not exist in the sm.ini file. For example, if the file already contains a JVMOption(0) and JVMOption(1), add JVMOption(2):-Xss6M to the file.

  11. Replace the default shared_ memory:32000000 with shared_memory:96000000. This sets the shared memory size to 96MB. However, if you have a large database, you may need to allocate more shared memory to accommodate the upgrade processing.
  12. Add the jsgctrigger:67108864 parameter to the end of the file if it does not exist. This enables JavaScript garbage collection at a memory threshold of 64MB to avoid potential issues.
  13. Disable IR keys by adding this line to the end of the file: ir_disable:1
  14. Save and close sm.ini.
  15. Restart the Service Manager service.

Copy the application Upgrade Utility files to your development environment

Since the upgrade process needs read-write access to the Upgrade Utility files, you cannot run the upgrade directly from the DVD. Follow these steps to copy the Upgrade Utility files to the primary directory on the development system.

  1. Create an upgrade folder on the development system. For example, C:\temp\upgrade.

    Create an upgrade folder on the development system. For example, /tmp/upgrade.

    Note: If you connect to the development server from a client on a remote computer, make sure that you create the folder on the development server and not the client machine.

  2. Make sure that the Service Manager server process (sm) has write and execute privileges for the upgrade directory that you create.
  3. Extract the Service Manager application Upgrade Utility files to the upgrade folder.

The Upgrade Utility includes these files:

  • AppUpgVersion.txt: Contains Upgrade Utility version and build numbers to help you identify which application upgrade version you have available. For example, a version of "SC62-9.31.xxx v9.31.001 Upgrade Build 1234" indicates that the Upgrade Utility upgrades ServiceCenter 6.2 and later releases to Service Manager 9.31, the utility version number is 9.31.001, and the build number for this version is 1234.
  • preupg.bin: Files that enable access to the Upgrade Utility features. The preupg.bin and transfer.bin upgrade files contain the applications and data to run the upgrade.
  • transfer.bin: Files that enable the upgrade to run. The preupg.bin and transfer.bin upgrade files contain the applications and data to run the upgrade on your development system.
  • sqlupgrade.unl: SQL Compare utility files.
  • upgdbdct.dta: Temporary database dictionaries (dbdicts) needed for the SQL compare process.
  • upgrade.inf: Signature information for the upgrade objects.
  • upgrade.mak: Signature definitions for the upgrade objects.
  • upgrade.str: Database dictionaries to be upgraded.
  • upgrade.ver: Version stamp for the upgrade.
  • *.dta (in the data folder): The data files for each table. For example, upgradeactivityactions.dta and upgradeactivitytype.dta.

Load the application upgrade files on the development environment

  1. Log in to Service Manager with a system administrator account.
  2. Click Window > Preferences > HP Service Manager and clear the Client side load/unload check box.

    Important: Failure to disable the Client side load/unload option causes the upgrade process to fail.

  3. Type db in the Service Manager client command box, and press Enter.
  4. From the Database Manager drop-down options menu, select Import/Load. Menu icon
  5. In the File Name field, navigate to the upgrade directory that you created, and double-click preupg.bin. For example, C:\temp\upgrade\preupg.bin.

    In the File Name field, navigate to the upgrade directory that you created, and double-click preupg.bin. For example, /tmp/upgrade/preupg.bin.

  6. Click Load FG.
  7. Type smupgrade in the Service Manager client command box, and press Enter.
  8. In the Upgrade Utility menu, click Load Transfer.
  9. Type the fully qualified path to the upgrade folder that you created. For example, C:\temp\upgrade.

    Type the fully qualified path to the upgrade folder that you created. For example, /tmp/upgrade.

  10. Click Next. The system loads transfer.bin and performs various mapping activities against select tables. Service Manager displays a "Transfer files loaded" message when the load is complete.
  11. Log out of the client and stop the Service Manager service.
  12. Restart the Service Manager service and log in to the client.

Use the data scan utility

Before you run the upgrade, you use the data scan option in the Upgrade Utility to scan a portion of your data set for certain types of data that may cause issues following the upgrade. The data scan logs to the datascan.log file basic information about the scan results, such as how many data records it scanned and which records it updated automatically. The scan logs to the sm.log file details about which problematic records it corrected. The data scan option enables you to scan for two types of problematic data:

  • Null values in fields applied with certain keys.
  • Mismatches between the data type defined on the field and the data type of the field value.

The data scan does not allow you to specify the tables to scan. The tables that are scanned include the list of tables noted in the latest patches record. To view the patches record, click SERVICE PACK > Update Patch Definitions in the Upgrade Utility. For more information about the rtecall functions that the data scan uses and about how you can implement these functions to scan for additional tables, such as probsummary, see the Service Manager Programming Guide.

  1. Log in to Service Manager as a system administrator.
  2. Type smupgrade in the Service Manager client command box and press Enter.
  3. In the DATA SCAN UTILITY menu, Click San for and Fix Incorrect Data.
  4. Click Next and follow the instructions.

If you want to modify the automatically fixed data to your own values, follow the instructions below.

Change null values disallowed by keys

The data scan option scanned for null values that violated the restrictions imposed by a No Nulls or Unique key. The utility then removed the record if null values violated a Unique key or replaced one of the null values with a default value if the null values violated a No Nulls key.

To change automatically modified values to your own values

  1. Open the sm.log file in the upgrade folder.
  2. Search for deleted a record or updated a record to locate a message that resembles either of the following:
    • scan: scan for nulls, deleted a record that contains null values on a "Unique" key field, table = TABLE_NAME, record = RECORD_CONTENTS

      This message indicates that the utility removed a record. TABLE_NAME shows the name of the table, and RECORD_CONTENTS shows all of the fields and values of the removed record.

    • scan: scan for nulls, updated a record that contains null values on a "No Nulls" key field, table = TABLE_NAME, key = RECORD_IDENTIFIER

      This message indicates that the utility replaced a null value with a default value. TABLE_NAME shows the name of the table, and RECORD_IDENTIFIER shows the primary key and its value for the updated record.

  3. Change the automatically modified value to your own value or restore the removed record with valid field values, either by using the Service Manager client or by directly updating data in the RDBMS.
  4. Search for the next occurrence of deleted a record or updated a record to fix the next automatically modified record.
  5. Repeat steps 2 through 4 to change all of the values that the utility updated.

Change data type mismatches

The data scan option scanned for mismatches between the data type defined on the field and the data type of the field value.

To change automatically modified values to your own values

  1. Open the sm.log file in the upgrade folder.
  2. Search for scan for inconsistent data types, table to locate a message that resembles either of the following:
    • scan: scan for inconsistent data types, table: "TABLE_ NAME", key: "RECORD_ IDENTIFIER", field: "FIELD_ NAME", value "ORIGINAL_VALUE", type: ORIGINAL_TYPE, value changed to: "NEW_VALUE", type: NEW_TYPE.

      This message indicates that the utility changed the value of a field in a record:

      • TABLE_NAME shows the name of the table.
      • RECORD_IDENTIFIER shows the primary key and its value of the updated record.
      • FIELD_NAME shows the name of the field that was updated.
      • ORIGINAL_VALUE shows the original value of the field that was updated.
      • ORIGINAL_TYPE shows the original type of the field that was updated.
      • NEW_VALUE shows the new value of the field that was updated.
      • NEW_TYPE shows the corrected type of the field that was updated.
    • scan: scan for inconsistent data types, table: "TABLE_ NAME", key: "RECORD_ IDENTIFIER", field: "FIELD_ NAME", value "ORIGINAL_VALUE", type: ORIGINAL_TYPE, type changed to NEW_TYPE.

      This message indicates that the utility changed the type of a field in a record:

      • TABLE_NAME shows the name of the table.
      • RECORD_IDENTIFIER shows the primary key and its value of the updated record.
      • FIELD_NAME shows the name of the field that was updated.
      • ORIGINAL_VALUE shows the original value of the field that was updated.
      • ORIGINAL_TYPE shows the original type of the field that was updated.
      • NEW_TYPE shows the corrected type of the field that was updated.
  3. Change the automatically modified value to your own value or restore the removed record with valid field values, either by using the Service Manager client or by directly updating data in the RDBMS.
  4. Search for the next occurrence of scan for inconsistent data types, table to fix the next automatically modified record.
  5. Repeat steps 2 through 4 to change all of the values that the utility updated.

Run the SQL Compare utility on the development environment

The SQL Compare utility is an informational tool that you can use to compare your existing table and field information with the tables and fields of Service Manager 9.31. It reports new fields that will merge into the existing tables. You can use the list of the fields produced by SQL Compare to determine whether any fields in your current system differ from those in the new version. Use can also use the report to determine which new fields you must add to RDBMS-mapped files if you choose to make the changes manually during the application upgrade.

Note: If you are going to accept the new dbdicts and the changes made to the dbdicts in the upgrade, you do not need to run this utility.

To run the SQL compare routine

  1. Log in to Service Manager as a system administrator.
  2. Type db in the client command box and press Enter to open Database Manager.
  3. From the Database Manager drop-down options menu, select Import/Load. Drop-down options menu
  4. In the File Name field, navigate to the upgrade directory that you created when you copied the Upgrade Utility to your development environment, and double-click sqlupgrade.unl.
  5. Click Load FG. Service Manager loads sqlupgrade.unl into your development environment.
  6. Type smupgrade in the client command box and press Enter.
  7. Click Run SQL Compare Utility.
  8. Type the fully qualified path to the upgrade folder that you created. Include the final back slash (\) in the path. For example, C:\temp\upgrade\.

    Type the fully qualified path to the upgrade folder that you created. Include the final forward slash (/) in the path. For example, /tmp/upgrade/.

  9. Click Load. SQL Compare displays the message, "Process Complete. Please check for any additional messages." Service Manager adds the results of the SQL Compare process to the sqlupgrade record. This file resets each time you run SQL Compare.

View the SQL Compare Utility results and make necessary changes

SQL Compare returns messages for dbdict mappings that contain new fields. You can update the dbdicts to contain the fields specified by SQL Compare before you begin the application upgrade.

  1. Type smupgrade in the Service Manager client command box and press Enter.
  2. Click View SQL Compare Results.
  3. Click Search. The sqlupgrade report lists each database dictionary file that requires changes. When you select a file in the top pane, Service Manager displays in the bottom pane any new fields that you must add to the database dictionary if you are updating your RDBMS mapped system manually.
  4. Add the new fields to the appropriate database dictionary and SQL database. The sqlupgrade record provides the following information for each new field:
    • Field Name: The exact field name to add to the associated database dictionary.
    • Type: The data type of the field.
    • Level: The level where the field resides.
    • Structure: The structure and array name that you should add to this field.
    • Alias of: If this is an alias field, it contains the name of the primary field that it is an alias of. Otherwise this field is blank.

    The new fields must exist in the database dictionary and the SQL database. If you are updating your RDBMS system manually, you must add them to the database and update the existing Service Manager SQL mapping. When you update a table in sqlsystemtables, add fields only through the database dictionary. Modifying the SQL mapping damages the file structure of the table.

    In most cases, you should add the new field to the descriptor structure. However, sometimes the Structure field contains something other than the word descriptor. When this occurs, add the new field to the appropriate location:

    • If the field resides in another structure: If the field is not an array field, you must add the field to the structure listed in the Structure field. For example, if the Structure field value is middle, add the field to the middle structure of the dbdict.
    • If the field is an array: The field name appears twice in the new field list. The first entry has a data type of array; the second is the data type of the array, such as character or logical. Use the first entry to determine the structure where you should add the array. The Structure field in the second entry reflects both the structure for the array (unless it uses the descriptor structure) and the name of the array.
    • The field is part of an array of structures: If the Structure field lists multiple fields exclusive of an array name, add the field to a structured array. To determine the placement in the structured array, follow the list of field names in the Structure/Array from left to right. The first name is the array name and the second is the structure name.

      Note: When adding fields to a structured array, add them in the same order as they appear in the sqlupgrade record.

Run the Upgrade Utility

The Service Manager Upgrade Utility upgrades the display components, database dictionaries, and the application data. The utility uses digital signatures to determine if an application matches the original application. A matching signature indicates that the object in your system has not changed from the original object and the utility can upgrade it safely. If a signature does not match the object in your system, the Upgrade Utility copies the new object to your system but does not overwrite the existing object. You can then examine both versions during the resolution process.

The Upgrade Utility runs three primary phases:

  1. During the first phase, the Upgrade Utility guides you through several questions and collects information needed for the upgrade.
  2. During the second phase, the utility updates dbdicts.
  3. During the third phase, the utility updates application data.

Caution! If you experience problems such as a power failure or a network connection error while upgrading the system, you can fix the issues and rerun the Upgrade Utility. The utility resumes the upgrade from the failure point. However, if the upgrade does not resume from the failure point, restore your database to the last backup point and fix possible issues; then rerun the Upgrade Utility.

To run the Upgrade Utility

  1. Type smupgrade in the Service Manager client command box and press Enter.
  2. Click SERVICE PACK in the Upgrade Utility menu.
  3. Click Apply an Upgrade.
  4. Make sure that the Applications version upgrading from field lists your current version of ServiceCenter or Service Manager, and then click Next. If the screen does not display the correct version number, do not continue with the upgrade. Contact HP Software Customer Support.
  5. Review the list of supported non-English languages that the Upgrade Utility will upgrade. By default, the languages that are installed on your system are set to true. Select false for the languages that you do not want to upgrade, and then click Next.

    Note: If you choose only part of the languages in this step, there are two points later in the upgrade lifecycle where you can rerun the Upgrade Utility to specify additional languages to be updated:

    • Before creating a custom upgrade (then the updates to the selected additional languages will be included in the custom upgrade package)

      Warning: However, in this case, you must finish conflict reconciliation before you update additional languages, because the Upgrade Results will be cleaned up.

    • After completing an upgrade (to perform an upgrade that updates only the languages)
  6. Select Yes if you will create a custom upgrade on this system to apply to your production environment. Or select No if you will not create a custom upgrade.
  7. Click Next.
  8. By default, the text box displays the fully qualified path to the Upgrade folder on the Service Manager server. Accept the path unless it does not specify the correct folder, and then click Next.
  9. Select Install HP's Version of the Object Alongside Your Own, and then click Next.

    Note: The Replace your version of the object with the HP Service Manager's version of the object option is for applying a custom upgrade. Do not choose that option at this point unless you are sure that you want to replace your own versions of objects and do not need to perform conflict resolution.

  10. For the Upgrade Utility to merge conflicting objects automatically, select the Enable check box, select a Base Version from the list, and then click Next.

    Note: The Base Version you select here will be considered as a clean version on which all changes are based. The earlier the version is, the less the chance your tailoring will be discarded. However, the earlier the version is, the less likely the utility will successfully merge objects. Typically, it is safe to keep the default value, which is set to the earliest version that your applications were previously upgraded from.

  11. The utility asks if you want to generate To Do records for all existing open records in the major modules. If you want to generate all open application records, leave the Generate To Do records check box selected, and then click Next.

    Depending on the number of records in your Change Management, Incident Management, Service Desk, Problem Management, and Request Management applications, this step can take a significant amount of time. If you have a large number of records, you can choose to generate the records after completing the upgrade by typing *aapm.upgrade.todo in the Service Manager client command box.

    From Service Manager 9.31 Application Patch 2, some Module Fields in the TodoMap table have updated mappings for the To Do List Field. See the following table for these new mappings:

    Changes to the ToDoMap Table
    Table Name Old Module Field Name New Module Field Name ToDo List Field Name
    cm3r

    description,1

    brief.description description
    cm3t description,1 brief.desc description
    incidents description,1 title description

    ocml

    description,1 description description
    ocmo description,1 description description

    ocmq

    description,1 brief.description description
    probsummary next.breach sla.expire target.date

    Notes:

    • If any Module Field that is mapped to a ToDo List Field has no SQL Name, the value of the mapped To Do List Field will be empty.
    • If any Module Field that is mapped to the “description” ToDo List Field has an SQL Type of IMAGE or BLOB (which are incompatible with the SQL Type TEXT or CLOB), the value of To Do List Field “description” will be set empty.
    • If these issues occur warning messages will be logged in the Service Manager Message Console and in the except.log file.
  12. Click Next to start the upgrade.
  13. Click Yes to confirm that you want to proceed. While the upgrade runs, the Upgrade Utility displays the progress of the upgrade by indicating which process is running, the progress of record processing, and the completion percentage for the upgrade.
  14. When you receive an UPGRADE IS COMPLETE message, the Upgrade Utility has finished the data processing.
  15. Log out of the Service Manager client and stop the Service Manager service.
  16. Restart the service and then log in to the client.
  17. Open the scversion table in Database Manager and verify that the Application Version field is 9.31.0022. If this field displays a value other than 9.31.0022, check the log files to identify the issue that occurred.

Review the upgrade log files and resolve any exceptions

After running the Upgrade Utility, the next step is to resolve any exceptions or conflicts that prevented the utility from updating certain objects. Until you reconcile these objects, Service Manager features may not behave as expected or may not function at all. First review the upgrade log files to determine if there are any exceptions. Then review the upgrade reports to find any conflicts.

The Upgrade Utility creates a set of log files in the same directory as the upgrade files:

  • The detail.log file contains specific information about the upgrade such as which files are being signed at any time.
  • The upgrade.log file contains information about the step that the upgrade is on. This file contains only the main steps of the upgrade.
  • The except.log file contains information about any exceptions reported by the upgrade. This log may have important messages about data type mismatches to resolve or database dictionaries that it cannot upgrade. If the file lists error messages, HP highly recommends that you do not continue the upgrade process until you resolve the errors.

You can open the log .txt files in the upgrade folder that you created when you copied the upgrade files to your development environment.

Data type mismatches

If the data type of a field in your dbdict does not match the data type of the like-named field defined in the dbdict provided by the upgrade package, the Upgrade Utility cannot merge these dbdicts. For example, if an existing dbdict has a scalar field and the Upgrade Utility attempts to add a structure field with the same name, this discrepancy prevents the dbdict from being updated.

To fix this issue, you can change the data type and the SQL type of the field, and use Complex Update to migrate existing data on that field to the target data type. The following is an example that shows the process of fixing a typical data type mismatch.

Note: The error messages in the except.log file identify each data type by an index number:

Index number Data type
1 number
2 character
3 date/time
4 logical
8 array
9 structure
11 expression

The following table shows a list of data type mismatches that may appear in the except.log file. The data type mismatches are listed for an Oracle database. If you are using an MSSQL or a DB2 database, the actual error message may vary slightly. For example, the following bullet points highlight the different errors in the different databases:

  • Oracle Error : dbdict:ApprovalDef, field:appr.condition, SQL type is CHAR(1) -- expected to be:RAW(255)
  • MSSQL Error: dbdict:ApprovalDef, field:appr.condition, SQL type is CHAR(1) -- expected to be:VARBINARY(255)
  • DB2 Error: dbdict:ApprovalDef, field:appr.condition, SQL type is CHAR(1) -- expected to be:VARCHAR(255) FOR BIT DATA

Data type mismatches for HP ServiceCenter 6.2x:

Error message in Oracle: Solution:

dbdict:ApprovalDef, field:appr.condition, SQL type is CHAR(1) -- expected to be:RAW(255)

dbdict:cm3r, field:svc.options, SQL type is VARCHAR2(30) -- expected to be:BLOB

dbdict:incidents, field:svc.options, SQL type is VARCHAR2(90) -- expected to be:BLOB

dbdict:ocmq, field:svc.options, SQL type is VARCHAR2(30) -- expected to be:BLOB

dbdict:svcCartItem, field:bundle.options, SQL type is VARCHAR2(30) -- expected to be:BLOB

dbdict:svcCatalog, field:access.filter.xml, SQL type is VARCHAR2(40) -- expected to be:BLOB

To fix these issues, change the SQL type to RAW(255) or BLOB by using the Dbdict utility.

Additionally, you will need to set the “SQL RC” to true to allow the field to store RAD expressions. Note that the stored value of the field in the database is encoded by Service Manager.

dbdict:cm3eventack, field:number, field type is number -- expected to be:character

To fix this issue, change the field type to character by using the Dbdict utility.

dbdict:eventin, field:evnumber, field type is number -- expected to be:character

dbdict:eventout, field:evnumber, field type is number -- expected to be:character

These fields reside in the descriptor structure field of BLOB SQL type. To fix this issue, change the field type to character by using the Dbdict utility.

dbdict:licenseinfo, field:id, field type is character -- expected to be:number

The licenseinfo table is used to track license information by Service Manager server. This issue should be ignored.

dbdict:svcCatalog, field:id.attach, field type is character -- expected to be:number

This id.attach field is an alias of id field in svcCatalog table. To fix the issue, change the field type to by using the Dbdict utility.

dbdict:cm3profile, field:update, field type is logical -- expected to be:character

dbdict:icmenv, field:update, field type is logical -- expected to be:character

dbdict:ocmprofile, field:update, field type is logical -- expected to be:character

dbdict:pmenv, field:update, field type is logical -- expected to be:character

dbdict:rcenv, field:update, field type is logical -- expected to be:character

dbdict:rcenv, field:pmt.update, field type is logical -- expected to be:character

dbdict:rcenv, field:kne.update, field type is logical -- expected to be:character

dbdict:slaprofile, field:sla.update, field type is logical -- expected to be:character

dbdict:slaprofile, field:slor.update, field type is logical -- expected to be:character

dbdict:slaprofile, field:sloa.update, field type is logical -- expected to be:character

dbdict:slaprofile, field:slocat.update, field type is logical -- expected to be:character

dbdict:smenv, field:update, field type is logical -- expected to be:character

These fields reside in the descriptor structure field of BLOB SQL type. To fix the issue, change the field type to character by using the Dbdict utility.

dbdict:probsummary, field:critical.user, field type is character -- expected to be:logical

This issue can be fixed by following the steps in the Fixing the probsummary critical.user field section.

Data type mismatches for HP Service Manager 7.0x

Error message in Oracle: Solution:

dbdict:ApprovalDef, field:appr.condition, SQL type is CHAR(1) -- expected to be:RAW(255)

dbdict:cm3r, field:svc.options, SQL type is VARCHAR2(30) -- expected to be:BLOB

dbdict:incidents, field:svc.options, SQL type is VARCHAR2(90) -- expected to be:BLOB

To fix these issues, change the SQL type to RAW(255) or BLOB by using the Dbdict utility.

Additionally, you will need to set the “SQL RC” to true to allow the field to store RAD expressions. Note that the stored value of the field in the database is encoded by Service Manager.

dbdict:cm3eventack, field:number, field type is number -- expected to be:character

To fix this issue, change the field type to character by using the Dbdict utility.

dbdict:eventin, field:evnumber, field type is number -- expected to be:character

dbdict:eventout, field:evnumber, field type is number -- expected to be:character

These fields reside in the descriptor structure field of BLOB SQL type. To fix this issue, change the field type to character by using the Dbdict utility.

dbdict:licenseinfo, field:id, field type is character -- expected to be:number

The licenseinfo table is used to track license information by Service Manager server. This issue should be ignored.

dbdict:svcCatalog, field:id.attach, field type is character -- expected to be:number

This id.attach field is an alias of id field in svcCatalog table. To fix the issue, change the field type to by using the Dbdict utility.

dbdict:FolderRights, field:close, field type is logical -- expected to be:character

The close field is an alias of delete field in FolderRights table. To fix the issue, change the field type to character by using the Dbdict utility.

dbdict:FolderRights, field:delete, field type is logical -- expected to be:character

This issue can be fixed by following the steps in the Fixing the FolderRights delete field section.

Data type mismatches for HP Service Manager 7.1x:

Error message in Oracle: Solution:

dbdict:cm3r, field:svc.options, SQL type is VARCHAR2(30) -- expected to be:BLOB

dbdict:incidents, field:svc.options, SQL type is VARCHAR2(90) -- expected to be:BLOB

To fix these issues, change the SQL type to RAW(255) or BLOB by using the Dbdict utility.

Additionally, you will need to set the “SQL RC” to true to allow the field to store RAD expressions. Note that the stored value of the field in the database is encoded by Service Manager.

dbdict:cm3eventack, field:number, field type is number -- expected to be:character

To fix this issue, change the field type to character by using the Dbdict utility.

dbdict:eventin, field:evnumber, field type is number -- expected to be:character

dbdict:eventout, field:evnumber, field type is number -- expected to be:character

These fields reside in the descriptor structure field of BLOB SQL type. To fix this issue, change the field type to character by using the Dbdict utility.

dbdict:licenseinfo, field:id, field type is character -- expected to be:number

The licenseinfo table is used to track license information by Service Manager server. This issue should be ignored.

dbdict:svcCatalog, field:id.attach, field type is character -- expected to be:number

This id.attach field is an alias of id field in svcCatalog table. To fix the issue, change the field type to by using the Dbdict utility.

dbdict:FolderRights, field:close, field type is logical -- expected to be:character

The close field is an alias of delete field in FolderRights table. To fix the issue, change the field type to character by using the Dbdict utility.

dbdict:FolderRights, field:delete, field type is logical -- expected to be:character

This issue can be fixed by following the steps in the Fixing the FolderRights delete field section.

Data type mismatches for HP Service Manager 9.2x:

Error message in Oracle: Solution:

dbdict:incidents, field:svc.options, SQL type is VARCHAR2(90) -- expected to be:BLOB

To fix this issue, change the SQL type to RAW(255) or BLOB by using the Dbdict utility.

Additionally, you will need to set the “SQL RC” to true to allow the field to store RAD expressions. Note that the stored value of the field in the database is encoded by Service Manager.

dbdict:cm3eventack, field:number, field type is number -- expected to be:character

To fix this issue, change the field type to character by using the Dbdict utility.

dbdict:eventin, field:evnumber, field type is number -- expected to be:character

dbdict:eventout, field:evnumber, field type is number -- expected to be:character

These fields reside in the descriptor structure field of BLOB SQL type. To fix this issue, change the field type to character by using the Dbdict utility.

dbdict:licenseinfo, field:id, field type is character -- expected to be:number

The licenseinfo table is used to track license information by Service Manager server. This issue should be ignored.

dbdict:svcCatLanguage, field:catalogid, field type is character -- expected to be:number

This field resides in the catalog structure field of BLOB SQL type. To fix this issue, change the field type to number by using the Dbdict utility.

dbdict:svcCatalog, field:id.attach, field type is character -- expected to be:number

This id.attach field is an alias of id field in svcCatalog table. To fix the issue, change the field type to by using the Dbdict utility.

dbdict:FolderRights, field:close, field type is logical -- expected to be:character

The close field is an alias of delete field in FolderRights table. To fix the issue, change the field type to character by using the Dbdict utility.

dbdict:FolderRights, field:delete, field type is logical -- expected to be:character

This issue can be fixed by following the steps in the Fixing the FolderRights delete field section.

Fixing the FolderRights delete field

Example: The dbdict for the FolderRights table has a delete field with the "logical" data type. The Upgrade Utility tries to update the delete field with the "character" data type, which has possible values of "always," "never," "workgroup," and "assigned."

  1. In the dbdict for the FolderRights table, add a field named delete.tmp with a data type of character, and update the dbdict.
  2. Log out of the system and log back in.
  3. Make sure that the Complex Update feature is enabled for the FolderRights table.
  4. In the Database Manager, search for all records in the FolderRights table.
  5. From the More Actions menu, click Mass Update.
  6. When you are asked whether you want to update all records, click Yes.
  7. Click Complex Update on the toolbar.
  8. In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the delete field to the delete.tmp field.

    Example:

    if delete in $file=true then delete.tmp in $file="always" else delete.tmp in $file="never"

  9. In the dbdict for the FolderRights table, edit the delete field and add the Type (character) and SQL Type (same as the SQL Type automatically assigned for delete.tmp).
  10. Log out of the system and log back in.
  11. In the Database Manager, search for all records in the FolderRights table.
  12. From the More Actions menu, click Mass Update.
  13. Click Complex Update on the toolbar.
  14. In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the delete.tmp field to the delete field and empty the delete.tmp field.

    Example:

    delete in $file=delete.tmp in $file; delete.tmp in $file=NULL

  15. In the dbdict for the FolderRights table, delete the delete.tmp field.
  16. Log out of the system and log back in.
  17. Test the change by updating records in the FolderRights table and populating the delete field with "always," "never," "workgroup," or "assigned."

Fixing the probsummary critical.user field

Example: The dbdict for the probsummary table has a critical.user field with the "logical" data type. The Upgrade Utility tries to update the critical.user field with the "logical" data type, which has possible values of true or false.

  1. In the dbdict for the probsummary table, add a field named critical.user.tmp with a data type of logical, and update the dbdict.
  2. Log out of the system and log back in.
  3. Make sure that the Complex Update feature is enabled for the probsummary table.
  4. In the Database Manager, search for all records in the probsummary table.
  5. From the More Actions menu, click Mass Update.
  6. When you are asked whether you want to update all records, click Yes.
  7. Click Complex Update on the toolbar.
  8. In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the critical.user field to the critical.user.tmp field.

    Example:

    if critical.user in $file="true" then critical.user.tmp in $file=true else critical.user.tmp in $file=false

  9. In the dbdict for the probsummary table, edit the critical.user field and add the Type (logical) and SQL Type (same as the SQL Type automatically assigned for critical.user.tmp).
  10. Log out of the system and log back in.
  11. In the Database Manager, search for all records in the probsummary table.
  12. From the More Actions menu, click Mass Update.
  13. Click Complex Update on the toolbar.
  14. In the statements area under Instructions for action on EACH RECORD, add statements using standard RAD expressions to migrate data from the critical.user.tmp field to the critical.user field and empty the critical.user.tmp field.

    Example:

    critical.user in $file=critical.user.tmp in $file; critical.user.tmp in $file=NULL

  15. In the dbdict for the probsummary table, delete the critical.user.tmp field.
  16. Log out of the system and log back in.
  17. Test the change by updating records in the probsummary table and populating the critical.user field with true or false.

Key change failures

If the except.log file lists key change failures such as the ones listed below, follow the appropriate steps to correct the keys:

  • Error: Failed to add <key_type> key: <field_name> to table <table_name>. Add the key manually:
    1. Type dbdict in the Service Manager client command box and press Enter.
    2. In the File Name field, type the table name indicated by the error message, and then click Search.
    3. Click the Keys tab.
    4. Position the mouse pointer in the key name part of an empty key structure and click New Field/Key.
    5. Select the appropriate key type from the combo list, and add the appropriate field to the key, as indicated by the error message.
    6. Click Add, and then click Yes to confirm.
    7. Click the Keys tab, and then click OK to save the change.
    8. Repeat steps i through vii for each key that the utility failed to add.
  • Error: Failed to update <key_type> key: <old_field_name> to <new_field_name> in table <table_name>. Update the key manually:
    1. Type dbdict in the Service Manager client command box and press Enter.
    2. In the File Name field, type the table name indicated by the error message, and then click Search.
    3. Click the Keys tab.
    4. From the key list, select the key name that the error message indicates, and then click Edit Field/Key.
    5. Update the fields in the key according to the field names indicated by the error message.
    6. Click OK, and then click Yes to confirm.
    7. Click the Keys tab, and then click OK to save the change.
    8. Repeat steps i through vii for each key that the utility failed to update.
  • Error: Failed to remove <key_type> key: <field_name> from table <table_name>. Remove the key manually:
    1. Type dbdict in the Service Manager client command box and press Enter.
    2. In the File Name field, type the table name indicated by the error message, and then click Search.
    3. Click the Keys tab.
    4. From the key list, select the key name that the error message indicates, and then click Edit Field/Key.
    5. Click Delete, and then click Yes to confirm.
    6. Click the Keys tab, and then click OK to save the change.
    7. Repeat steps i through vi for each key that the utility failed to update.

In addition, you may encounter the following Unique Key errors:

Error: dbdict:Approval, Unique Key is {"unique.key", "file.name", "name"} -- expected to be:{"unique.key", "file.name", "name", "component"}

Error: dbdict:ApprovalLog, Unique Key is {"counter", "file.name", "unique.key"} -- expected to be:{"counter", "file.name", "unique.key", "component"}

Error: dbdict:displayeventrev, Unique Key is {"screen.id", "language", "event", "event.sig", "sc.revision"} -- expected to be:{"id", "sc.revision"}

Error: dbdict:displayoptionrev, Unique Key is {"screen.id", "language", "txt.bank", "txt.option", "text.sig", "sc.revision"} -- expected to be:{"id", "sc.revision"}

Error: dbdict:kmknowledgebaseupdates, Unique Key is {} -- expected to be:{"id"}

Error: dbdict:wfwenvironment, Unique Key is {} -- expected to be:{"name"}

Unexpected errors

If the except.log file or the Upgrade Results report lists any errors other than key change failures and data type mismatches, contact HP Software Customer Support for assistance.

Review the Upgrade Results report and resolve conflicts

Follow the instructions in the task below to find conflicts that need to be resolved and to mark objects as reconciled after you resolve the conflicts.

  1. View the Upgrade Results report:
    1. Type smupgrade in the Service Manager client command box and press Enter.
    2. Click View/Merge Upgrade Results in the Upgrade Utilities menu.
    3. In the Result drop-down list, select the type of results you want to search for. For example, select Renamed.

      Note: When you select a result type from the drop-down list, the description of that result type appears under the drop-down list. If you want to view the full Upgrade Results report that includes all objects and statuses, clear the Result field and press Enter.

  2. For each renamed or forced object, choose one of the following options:
    • Option 1: Use your customized object instead of the new object. In this case, delete the new object that is prefixed with NEW931 and the copied object that is prefixed with PRE<version_number>.
    • Option 2: Use the new object instead of your customized object. In this case, delete your customized object and the copied object that is prefixed with PRE<version_number> and rename the new object by removing the NEW931 prefix.
      Note: The Mass Choose Upgrade feature can help you replace multiple customized objects with new objects that are prefixed with NEW931. For more information, see the "Using the Mass Choose Upgrade feature" section.
    • Option 3: Merge the changes shipped with the new object into your customized object. In this case, find out what changes the new object includes, manually apply those changes to your customized object, and then delete the new object that is prefixed with NEW931 and the copied object that is prefixed with PRE<version_number>.
      Note: The Merge tool, Auto-Merge and Revert options, and third-party three-way compare and merge tools can assist you in comparing the objects and merging the code during the out-of-box upgrade. See Using the Merge tool and Using the Auto Merge and Revert options for more information.
  3. After you change an object, mark the object as reconciled so that the Upgrade Utility will not identify this object as conflicting when it applies an upgrade to a later version. When you upgrade to a later version in the future, the Upgrade Utility will mark the object as Previously Reconciled instead of Renamed.
    Note: The Mark as Reconciled feature can assist you to mark the object as Reconciled." See "Using the Mark as Reconciled feature" for more information.

Note: You can export the upgrade results data to a Microsoft Excel spreadsheet. To do so, from the Upgrade Results report, click the drop-down options menu and select Export to Excel. You can also select File > Print from the Upgrade Results report to print the list of records. For more information, see the Service Manager online help.

Using the Merge tool

For each object marked as "Renamed" in the Upgrade Results list, the Upgrade Utility generates XML objects for the three versions of the object: base, customer, and upgrade.

Version Location Description
base Upgrade\3waymerge\work\base An XML representation of every object that has been signatured in the pre-upgrade out-of-box version.
customer Upgrade\3waymerge\work\customer An XML representation of all objects that were tailored in the customer version and resulted in a conflict during the upgrade.
upgrade Upgrade\3waymerge\work\upgrade An XML representation of the object provided by the upgrade package of all objects that resulted in a conflict.

Each of the three folders described above contains a sub-folder for each signatured table. You can find the XML representations of the objects in the table within these sub-folders.

The built-in, two-way/three-way Merge tool allows you to examine the upgrade and customer versions of a record in a side-by-side view as well as the base, upgrade, and customer versions of a record in a three-way view. This will help you to determine which changes to include in the final record.

Note:The tool does not work with RAD applications.

This tool assists the conflict resolution process in these two ways:

  • It allows you to identify where changes are located before you can visually compare the objects and to make changes manually, such as in format records.
  • It allows you to identify and merge changes directly between objects, such as ScriptLibrary records.

To use the Merge tool, follow these steps:

  1. In the UPGRADE UTILITY section, click View/Merge Upgrade Results.
  2. In the Result drop-down list, select Renamed.
    Note: The Two-way/Three-way Merge tool is available only for “Renamed” records.
  3. Click Search.
  4. A list is returned that displays all the result records of the “Renamed” type. Select a record that you want to examine, click More or the More Actions icon, and then click Merge.
  5. The current default merge mode is Three-Way Merge mode. The merge option is not available for format records. Instead, you can click Compare option from the More Actions menu to start the merge tool in read-only mode. You can use this mode to identify the differences in the side-by-side view or three-way view and then merge records manually in Forms Designer.

    1. In Three-Way Merge mode, click the Show Ancestor Pane button to show the base record reference. Click the button again to hide the base record reference.


    2. In Three-Way Merge mode, if the records of base, upgrade, and customer versions are all different, the background color is red. If you put the cursor into the records with the red background and then click the Copy Current Change from Left to Right button, the selected records from the left pane will be appended to selected records in the right pane.

    3. In Three-Way Merge mode, if the records of the customer version are identical to the base version, but different from the upgrade version, the background color is blue. If you put the cursor into the records with the blue background, and then click the Copy Current Change from Left to Right button the selected records from the right pane will be replaced by the selected records from the left pane.
    4. In Three-Way Merge mode, if the records on the left contain red background records, and you then click the Copy All from Left to Right button, the records in the right pane with blue background will be replaced with selected records from the left pane.
      Note: The right records with red background will not be changed. To do this, you will need to switch to Two-Way Merge mode to use Copy All from Left to Right feature.

  6. To enter Two-Way Merge mode, click the Two-Way Compare (Ignore Ancestor) button. In this mode, the Show Ancestor Pane button is disabled.
    Note: When you do this, the button label changes to Three-Way Compare.  Click this again to revert to Three-Way Compare mode.

    1. In Two-Way-Merge mode, if one record differs upgrade and customer versions, you can click Copy Current Change from Left to Right button to replace a selected record from the left pane to the right pane.
    2. In Two-Way-Merge mode, click Copy All from Left to Right button to replace all records in the right pane with the records from the left pane.

Using a third party tool to visually compare objects

You may also visually compare the three versions of each object using a three-way compare and merge tool outside Service Manager, and then merge them manually in Service Manager. For example, you can use a tool, such as KDiff3 for Windows, to compare and merge objects.

To download and learn about KDiff3, visit the KDiff3 Web site.

A brief example of using KDiff3 to compare the three versions of an object is provided in the following steps:

  1. Install KDiff3 on the Service Manager server host.
  2. Open KDiff3. For more information, refer to the KDiff3 documentation.
  3. For the A(Base) parameter, specify the path to the Upgrade\3waymerge\work\base folder.
  4. For the B parameter, specify the path to the Upgrade\3waymerge\work\customer folder.
  5. For the C parameter, specify the path to the Upgrade\3waymerge\work\upgrade folder.
  6. Click OK.
  7. Navigate the folder structure and double-click the file that is named after the object you want to merge.
  8. Compare the three versions of the object in the 3-way compare view.

  9. Manually apply the changes you have identified to the object in Service Manager.

Using the Auto Merge and Revert options

If, during the upgrade, the Upgrade Utility automatically merges some of your objects with the upgraded versions of the objects, the Upgrade Results reports lists these merged objects as Auto Merged. You can use the Revert feature in the drop-down options menu to restore Auto Merged or Renamed objects to their original states. From the drop-down options menu, select Revert to restore one object or select Mass Revert to restore multiple objects. After you restore an object, you can also reapply the Auto Merge to that object by selecting the Auto Merge or Mass Auto Merge option from the drop-down options menu.

Using the Mass Choose Upgrade feature

During the Upgrade process, you can use the Mass Choose Upgrade feature to overwrite your systems old objects with the newer versions from the upgrade utility. You can use this feature to quickly update the objects of the following statuses, which are generated during the upgrade:

  • Auto Merged
  • Renamed
  • Previously Reconciled
  • Reconciled

To use the Mass Choose Upgrade feature, follow these steps:

  1. In the UPGRADE UTILITY section, click View/Merge Upgrade Results.
  2. In the Result drop-down list, filter the set of objects (Auto Merged; Renamed; Previously Reconciled; Reconciled) on which you wish to use the Mass Choose Upgrade feature and then click Search.
  3. If more than two objects exist in the resulting search, click the Mass Choose Upgrade button from More Actions menu in the returned list and then click Yes.

After you click Yes, the objects that you selected will be updated with the contents of the newer versions from the upgrade utility.

Using the Mark as Reconciled feature

During the Upgrade process, you must mark conflicting objects as “Reconciled” after resolving each conflict. To help with this process, you can use the Mass Mark as Reconciled feature to mark multiple objects as “Reconciled.” You can use this feature on objects with the following statuses:

  • Auto Merged
  • Renamed
  • Previously Reconciled

To use the Mass Mark as Reconciled feature, follow these steps:

  1. In the UPGRADE UTILITY section, click View/Merge Upgrade Results.
  2. In the Result drop-down list, filter the set of objects (Auto Merged; Renamed; Previously Reconciled) on which you wish to use the Mass Mark as Reconciled feature and then click Search.
  3. If more than two objects exist in the resulting search, click the Mass Mark as Reconciled button from the More Actions menu and then click Yes. After you click Yes, all objects that you selected will be marked as “Reconciled” and removed from current conflict list.

    Note: If only one object exits in the resulting search, or if you want to resolve conflicts for the selected objects individually, you can use the Mark as Reconciled button from the More Actions menu on each object instead of the Mass Mark as Reconciled button.

RAD application differences

You can follow the standard conflict resolution process to resolve conflicts for RAD applications. Since a RAD application is made up of records from several different tables, the Upgrade Results report assigns an object type of Application Cluster for RAD application objects with conflicts.

Note: The codes for RAD applications for which "Current Release Level" is not marked as "SM 9.31" (for example "7.1"), are already current with the ones in Service Manager9.31. Therefore, you should not change the "Current Release Level" field to "SM 9.31". There are two cases in which a RAD application's "Current Release Level" may be marked as "SM 9.31":

  1. The RAD applications which are new in Service Manager 9.31.
  2. The RAD applications whose code has been changed in Service Manager 9.31.

Records with the Application Cluster object type appear in the Upgrade Results list only in the following scenarios:

  • Your organization has a RAD license and has tailored the RAD application in question. You can choose one of the following options when resolving a RAD application conflict:
    • Option 1: Use your customized object instead of the new object. In this case, delete the new object that is prefixed with NEW931 and the copied RAD application that is prefixed with PRE<version_number>.
    • Option 2: Use the new object instead of your customized object. In this case, delete your customized object and the copied RAD application that is prefixed with PRE<version_number> and rename the new object by removing the NEW931 prefix.
    • Option 3: Merge the changes shipped with the new object into your customized object. In this case, find out what differences exist between the RAD applications, manually update the customized RAD application, and compile the code. Then, delete the new RAD application that is prefixed with NEW931 and the copied RAD application that is prefixed with PRE<version_number>. For example, you can use the Compare All feature in the RAD Editor to assist you in identifying which panels have changed and then manually update panels as necessary in that RAD application.
  • Your organization has applied a hotfix or patch that included a RAD application, which changed the existing RAD application when it was loaded into the system.
    • Option 3 is not applicable to you. You can keep the new version of the RAD application that came with the upgrade package or keep the RAD application that was loaded with the hotfix or patch. In most cases, you need the newest version of the RAD application, the one that came with the upgrade package. In this scenario, resolving RAD application conflicts involves deleting a RAD application and renaming a RAD application:
      • To delete a RAD application, open the RAD application in the RAD Editor. Click Delete, and then click Delete All.
      • To rename a RAD application, open the RAD application in the RAD Editor. From the drop-down options menu, click Copy/Rename. Type the name of the new RAD application, and then click Rename.

Display component differences

The Upgrade Utility upgrades the display components and reports discrepancies if any of your components differ from the new versions. You can follow the standard conflict resolution process to resolve these conflicts. However, you must pay special attention to following types of display components:

  • The Display RAD application (RAD=display)
  • displayscreen records
  • displayoption records
  • displayevent records

Display application

The Display RAD application (RAD=display) is a Service Manager RAD application that provides access to RAD features without requiring RAD programming skills or RAD licensing. If a Display RAD application appears in the Upgrade Results report, perform conflict resolution on that application by following the standard conflict resolution process. HP highly recommends that you use the new version of the application.

Display screen records

Display screen records (displayscreen) are individual records identified by a unique screen ID. The displayscreen records define the attributes of a screen and provide access to the individual records for options and events. A display screen is not the same as a form. If displayscreen objects appear in the Upgrade Results report, perform conflict resolution on the objects by following the standard conflict resolution process.

Caution! There are triggers attached to the displayscreen file. Changes to the records in this file affect their associated display options and events.

Display options and display events

The Upgrade Utility upgrades the display components in the same manner as all other components. The displayoption table and displayevent table have a unique identifier stored in the ID field. The upgrade process assigns an ID to every display option, following the convention <screen id>_<action>_<number> where the screen ID and action are from the display option or event, and the number is an optional field added when multiple options have the same screen ID and action.

If options that have been added to your system have the same action as others in the same display screen, the upgrade process assigns a <number> in the order of the options' GUI option number. If an added option was not the last option in terms of GUI option number, the upgrade process does not add the additional numbers in the ID field in the same order as it would have for an out-of-box system. The upgrade process renames the added option and any option after it (in GUI option order) and does not upgrade the option or event automatically.

To make sure that this type of renaming does not happen in future upgrades, when performing conflict resolution on these options, use the ID of the renamed option, NEW931<screen id>_<action>_<number>, and change the identifier of the added options. Rename all other options to match the ID of the renamed ones. When renaming an option, use an identifier to specify that this is a customized option added for your installation. For example, apm.edit.problem_do_nothing_ACME1.

The following table gives an example of part of the display screen conflict resolution for apm.edit.problem.

Screen ID GUI action Upgrade action User action
300 do nothing update Name: apm.edit.problem_do_nothing_1
Result: This item was updated correctly.
User action: No action necessary.
400 do nothing update Name: apm.edit.problem_do_nothing_2
Result: This item was updated correctly.
User action: No action necessary.
450 (this is an option that you added) do nothing rename Name: apm.edit.problem_do_nothing_3
Result:This item was renamed. It is your customized option.
User action: Rename this object to give it a unique name. For example, apm.edit.problem_do_nothing_ACME1.

Name: NEW931apm.edit.problem_do_nothing_3
Result: This is the new SM931 option.
User action: Perform conflict resolution.
To perform conflict resolution, open apm.edit.problem and look at the options. Compare this option with apm.edit.problem_do_nothing_3 and NEW931apm.edit.problem_do_nothing_3.
500 do nothing The upgrade ignores this option. Result: This option does not appear in the reports.
User action: Perform conflict resolution.
To perform conflict resolution, open apm.edit.problem and look at the options. Compare this option with apm.edit.problem_do_nothing_3 and NEW931apm.edit.problem_do_nothing_3.

Perform additional manual tasks

This section describes changes that the Upgrade Utility cannot make automatically. Make the following changes manually.

The Upgrade utility does not automatically clean up artifacts that were left over by the upgrade, such as objects that were prefixed with NEW931 or PRE<version_number> which are copied and renamed from pre-upgrade objects. You must manually delete those objects against the exported list. Otherwise, the system may not work as expected. To find those objects, search the Upgrade Results list for records with a result type of "Auto Merged" "Previously Reconciled" "Renamed" or "Reconciled" and then export the list to an Excel file.

To make added or upgraded display options work as expected, you must manually re-save all the related display screens. To find those display screens, you can search the Upgrade Results list for display options records with a result type of "Added" "Auto Merged" "Previously Reconciled" "Renamed" "Reconciled" or "Upgraded" and export the list to an Excel file.

(Required) Make sure that all existing operator records have a contact record

Service Manager requires that every operator have a contact record. You can, however, have a contact record without a corresponding operator record. Review your existing operator records and create a contact record for every operator record that does not already have one. Service Manager provides four wizards that you can use to create the missing contact or operator records. These wizards become available when you click the drop-down options menu icon in the contacts.g and operator.g forms.

Disable the Synchronize contacts with operators option in the System Information Definition before running these wizards:

  • Create Operator wizard: Creates an operator record from a contact record.
  • Mass Create Operators wizard: Creates a batch of operator records from a batch of contact records.
  • Create Contact wizard: Creates a contact record from an operator record.
  • Mass Create Contacts wizard: Creates a batch of contact records from a batch of operator records.

You can customize how the wizards map fields from the contacts and operator tables by editing the createUsers JavaScript in the script library.

(Required) Update profile records in Problem Management

In Problem Management, profile records now contain settings to control access to Known Error Tasks. After you update your applications, the settings in the Known Error Tasks section of the profile records are not populated. Therefore, no users can access this feature. You must update your profile records to enable users to view and modify records within Known Error Tasks.

(Required) Specify the contact for Service Desk tickets

The Service Desk application uses these fields to list contacts for new calls:.

  • Contact for this call (callback.contact)
  • This call is for (contact.name)

Specify the contact for the callback.contact and contact.name fields for each existing Service Desk ticket in your system. You can use the Complex Update feature to fill these fields automatically if you have a large number of records. Once you select a contact (callback.contact), the other field, if left blank, defaults to the callback.contact.

(Required) Expose fields in the cm3r table

For Change Management with Web Services, the following fields in the cm3r table must be exposed after an upgrade:

  • header,assign.dept
  • affected.item
  • closureComments

These are now mandatory fields when opening or closing a Change record, so they must be accounted for in any Web services definitions. HP also recommends that you expose the emergency field in the cm3r table to support emergency changes.

To expose the fields, add them to the appropriate extaccess records for the cm3r table published in the Web services API.

  • header,assign.dept (suggested Caption=AssignmentGroup)
  • affected.item (suggested Caption=Service)
  • closureComments (suggested Caption=ClosureComments)
  • emergency (suggested Caption=Emergency)

For Incident Management with Web Services, expose the affected.item field in the cm3r table following an upgrade of the server. This is now a mandatory field when opening or closing an Incident record, so it must be accounted for in any Web services definitions.

To expose the field, add it to the appropriate extaccess records for the probsummary table published in the Web services API.

  • affected.item (suggested Caption=Service)

(Required) Change Configuration Item to Affected Item

In the Incident Management and Service Desk applications, the utility renamed the Configuration Item label to Affected Item. Review customized menus, formats, and messages that refer to Configuration Items and make any necessary changes to match the new naming convention (Affected Item).

(Required) Change modules to support multiple SLAs

Several Service Manager applications now support the use of multiple service level agreements (SLAs) for interactions, incidents, problem records and problem tasks, and change records. Service Manager uses a new agreement.ids array field instead of the scalar agreement.id field to represent SLA IDs. Therefore, you must identify your tailoring that references the agreement.id field and make changes accordingly. To do so, scan for references in tailoring that explicitly have agreement.id in an expression, and update each of those expressions so that it points to the agreement.ids field. Such references may reside in Format Control, Process, Scripts, Wizards, and other areas.

Example

If an expression contains: if agreement.id in $L.file=13 then $L.x="abc", you can change it to the following: if index(agreement.ids in $L.file,13)>0 then $L.x="abc".

To search for agreement.id

To identify tailoring that references agreement.id, you can use the out-of-box RAD function findAll, as described in these steps:

  1. Type rad in the Service Manager client command box and press Enter.
  2. When the RAD Editor opens, type findAll in the Application field, and then click Search.
  3. Select the findAll application and click Test.
  4. Click Proceed.
  5. In the String to Search for field, type agreement.id, and then click Search.

Possible areas that may include references to agreement.id

  • If any applications use the agreement.id field for SLA management, you must set the SLA ID Field to agreement.ids in the SLA Integration record for each application (by opening Service Level Management > SLA Administration > Configure Application). For example, change the SLA ID Field to agreement.ids for these applications:
    • The cm3r and cm3t tables in Change Management.
    • The probsummary table in Incident Management.
    • The rootcause and roocausetask tables in Problem Management.
    • The incidents table in Service Desk.
  • If you use Event Services that have event maps against the agreement.id field, update the event map or create a new one that maps to the agreement.ids field (array of numbers).
  • If you expose the agreement.id field in any existing extaccess records, change the field to agreement.ids.

(Optional) Localize Service Catalog items

The format of the Service Catalog data now allows for localization. For each Service Catalog item, the Upgrade Utility creates a record in the svcDisplay table for a language available on your system. The utility copies the original English record and adds a language code to each copy. Follow the steps in this section to localize your Service Catalog items.

  1. Type db in the Service Manager client command box and press Enter.
  2. In the Table field, type svcDisplay and click Search.
  3. From the Language drop-down list, select the language into which you want to localize your catalog items, and then click Search.
  4. Select each record, and replace the English text in the fields with the appropriate translation.
  5. Click Save.

(Optional) Modify automatically fixed data

If the Upgrade Utility found duplicates when imposing a Unique or No Duplicates key on a field, the utility fixed the duplicates by appending suffixes such as -dup1, - dup2, ...-dupx.

To change automatically modified values to your own values

  1. Open the sm.log file in the upgrade folder.
  2. Search for -dup and locate a message that resembles the following:

    RTE I scan: fix duplicates, changed column COLUMN_NAME in TABLE_ NAME to new value: ORIGINAL-dup1

    This message indicates that the utility found duplicates in the COLUMN_NAME field in the TABLE_NAME table, and it changed all duplicates other than the first instance from ORIGINAL to ORIGINAL-dup1, ORIGINAL-dup2, and so on.

  3. Change the auto-modified value to your own value, either by using the Service Manager client or by directly updating data in the RDBMS.
  4. Search for the next occurrence of -dup to fix the next duplicate item.
  5. Repeat steps 2 through 4 to change all of the values that the utility updated.

Return the development system to normal operation

After the upgrade, the system may not work correctly until you return it to its normal operating environment.

  1. Log out of the client and stop the Service Manager service.
  2. Restore the sm.cfg file to its original state.
  3. Restore the sm.ini file to its original state.
  4. Restart the Service Manager server and log in to the client.
  5. Regenerate your IR keys for the incidents table.

Note: Service Manager does not recompile indexes in your RDBMS. If your RDBMS is not configured to recompile indexes automatically after index changes, recompile your indexes manually.

Test the development system

After you resolve all conflicts, perform functional testing on the upgraded system and verify that it functions properly. In addition, make a checkpoint backup of the data files to enable you to restore from this point if necessary. Refer to the documentation for your RDBMS for backup instructions.

Create the custom upgrade

This section describes how to build a custom upgrade to apply to your production system. Before you create and apply a custom upgrade, make sure that all conflicts are resolved. A custom upgrade consists of three types of files:

  • New Service Manager 9.31 files that replaced old application files.
  • Customized application files that you retained.
  • Merged files that combine prior customization with new application functionality.

To create the custom upgrade

  1. Create a custom upgrade folder on the Service Manager server. For example, C:\temp\customupgrade. Make sure that the custom upgrade folder is empty.

    Create a custom upgrade folder on the Service Manager server. For example, /tmp/customupgrade. Make sure that the custom upgrade folder is empty.

    Note: If you are connecting to the Service Manager server from a client on a remote computer, make sure that the you create the custom upgrade folder on the Service Manager server and not the client computer.

  2. Type smupgrade in the Service Manager client command box and press Enter.
  3. Click SERVICE PACK in the Upgrade Utilities menu.
  4. Click Create an Upgrade. The Service Manager Upgrade Builder guides you through questions about the upgrade process.
  5. Click Next.
  6. Specify a name for the custom upgrade package. For example, SM930.
  7. Click Next.
  8. Review the list of supported non-English languages that the Upgrade Utility will upgrade. By default, the languages that are installed on your system are set to true. Select false for the languages that you do not want to upgrade.

    Note: You cannot rerun the upgrade to select additional languages. Make sure that all languages that you want to upgrade are set to true.

  9. Click Next.
  10. Provide the fully qualified path to the custom upgrade directory that you created in step 1.

    Provide the fully qualified path to the custom upgrade directory that you created in step 1.

  11. Click Next.
  12. Select the SM93 patch record from the drop-down list and click Next.
  13. Make sure that Complete Upgrade Build (Recommended) is selected and click Next.
  14. Click Yes to confirm that you want to proceed. Note that the process will destroy any existing upgrade definitions on file.
  15. When you receive a "Finished creating the transfer files for the upgrade" message, the Upgrade Utility has finished the data packaging.

Duplicate your production environment and create a test environment

Duplicate your current ServiceCenter or Service Manager production environment and create a test environment for running and testing the custom upgrade before you apply it to the production environment. Set up the duplicate environment to match your current production server exactly. Make sure that the operating system and service pack level on the test environment is identical to the production server.

  1. Identify a server to use for the test environment.

  2. Make sure that your test system meets all of the upgrade requirements:
    • Your RDBMS version, operating system, and client/server environment must meet all criteria listed in the Compatibility Matrix for Service Manager 9.31. You can view the Compatibility Matrix on the Software Support web site (http://www.hp.com/go/hpsoftwaresupport).
    • Do not install Service Manager or the Upgrade Utility on an NFS-mounted partition. Service Manager generates significant database read/write activity, and an NFS-mounted partition is significantly slower than a local drive and can cause serious performance degradation.
  3. Install the Service Manager 9.31 platform (server and client) Patch on the test system, following the instructions in the HP Service Manager Installation Guide.
  4. Copy your existing production system data onto your test system.
  5. Make sure that you point the test server to the data copy on the test system.

Prepare the Service Manager server on the test environment

To prepare the server for the upgrade, edit the Service Manager configuration (sm.cfg) and initialization (sm.ini) files. Note that you must return the sm.ini and sm.cfg files to their original state after the upgrade, so you may want to keep copies of the original files.

  1. Stop the Service Manager service.
  2. Open the Service Manager configuration file (sm.cfg) with a text editor.
  3. Comment out the sm system.start line to disable the background processes: #sm system.start.
  4. Add sm -sync to the end of the file if it does not yet exist. This parameter starts the sync process, which identifies and releases locks owned by inactive processes and shared memory that is not in use.

  5. If the the sm.cfg file contains more than one instance of the sm -httpPort parameter, comment out all instances except for one. Each sm -httpPort parameter starts a Service Manager server process. The upgrade needs only one process. Comment out all other parameters. Commenting out the parameters disables all of the other Service Manager processes that are not required during an upgrade.
  6. Save and close sm.cfg.
  7. Open the Service Manager initialization (sm.ini) file with a text editor.
  8. Add the sessiontimeout:1200 parameter to the end of the file if it does not exist. If this parameter exists, update it to an appropriate value. This parameter defines the number of minutes that the server waits for a client signal before the server assumes that the client session has timed out and closes the connection. A value of 1200 sets the timeout to 20 hours (1200 minutes), a period that should be long enough for an upgrade phase to complete in a typical scenario.
  9. Add the heartbeatinterval:120 parameter to the end of the file if it does not exist. This parameter 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.
  10. If you use HP-UX, add the following JVM option to the end of the file if it does not exist: JVMOption(#):-Xss6M. This parameter increases the Java virtual machine stack size to 6MB.

    When you add the parameter, replace the hash symbol (#) with an option number that does not exist in the sm.ini file. For example, if the file already contains a JVMOption(0) and JVMOption(1), add JVMOption(2):-Xss6M to the file.

  11. Replace the default shared_ memory:32000000 with shared_memory:96000000. This sets the shared memory size to 96MB. However, if you have a large database, you may need to allocate more shared memory to accommodate the upgrade processing.
  12. Add the jsgctrigger:67108864 parameter to the end of the file if it does not exist. This enables JavaScript garbage collection at a memory threshold of 64MB to avoid potential issues.
  13. Disable IR keys by adding this line to the end of the file: ir_disable:1
  14. Save and close sm.ini.
  15. Restart the Service Manager service.

Load the custom upgrade files on the test environment

  1. Copy from the development environment the custom upgrade folder that contains the custom upgrade files that the utility created. If you transfer the files to your system by FTP, set FTP to binary mode.
  2. Place the custom upgrade folder on the test server. For example, C:\temp\customupgrade.

    Place the custom upgrade folder on the test server. For example, /tmp/customupgrade.

  3. Make sure that the Service Manager server process (sm) has write and execute privileges for the custom upgrade directory.
  4. Log in to Service Manager as a system administrator.
  5. Click Window > Preferences > HP Service Manager and clear the Client side load/unload check box.

    Important: Failure to disable the Client side load/unload option causes the upgrade process to fail.

  6. Type db in the client command box, and then press Enter.
  7. From the Database Manager drop-down options menu, select Import/Load. Menu icon
  8. In the File Name field, navigate to the custom upgrade directory that you created, and double-click preupg.bin. For example, C:\temp\customupgrade\preupg.bin.

    In the File Name field, navigate to the custom upgrade directory that you created, and double-click preupg.bin. For example, /tmp/customupgrade/preupg.bin.

  9. Click Load FG.
  10. Type smupgrade in the Service Manager client command box, and press Enter.
  11. In the Upgrade Utility menu, click Load Transfer.
  12. Type the fully qualified path to the custom upgrade folder that you created. For example, C:\temp\customupgrade.

    Type the fully qualified path to the custom upgrade folder that you created. For example, /tmp/customupgrade.

  13. Click Next. The system loads transfer.bin and performs various mapping activities against select tables. Service Manager displays a "Transfer files loaded" message when the load is complete.
  14. Log out of the client and stop the Service Manager service.
  15. Restart the Service Manager service and log in to the client.

Apply the custom upgrade to the test environment

Tip: Note how long it takes to apply the custom upgrade so that you can determine how long the production system will be unavailable during the production upgrade.

Caution! If you experience problems such as a power failure or a network connection error while upgrading the system, you can fix the issues and rerun the Upgrade Utility. The utility resumes the upgrade from the failure point. However, if the upgrade does not resume from the failure point, restore your database to the last backup point and fix possible issues; then rerun the Upgrade Utility.

  1. Type smupgrade in the client command box and press Enter.
  2. Click SERVICE PACK in the Upgrade Utilities menu.
  3. Click Apply an Upgrade, and then click Next.
  4. Make sure that the Applications version upgrading from field lists your current version of ServiceCenter or Service Manager, and then click Next. If the screen does not display the correct version number, do not continue with the upgrade. Contact HP Software Customer Support.
  5. Review the list of supported non-English languages that the Upgrade Utility will upgrade. By default, the languages that are installed on your system are set to true. Select false for the languages that you do not want to upgrade, and then click Next.

    Note: You cannot rerun the upgrade to select additional languages. Make sure that all languages that you want to upgrade are set to true.

  6. Select No since you are running the custom upgrade.
  7. Click Next.
  8. By default, the text box displays the fully qualified path to the Upgrade folder on the Service Manager server. Accept the path unless it does not specify the correct folder, and then click Next.
  9. Since you are running a custom upgrade that includes objects that you consider final, select Replace your version of the object with the HP Service Manager's version of the object, and then click Next.
  10. The utility asks if you want to generate To Do records for all existing open records in the major modules. If you want to generate all open application records, leave the Generate To Do records check box selected, and then click Next.

    Depending on the number of records in your Change Management, Incident Management, Service Desk, Problem Management, and Request Management applications, this step can take a significant amount of time. If you have a large number of records, you can choose to generate the records after completing the upgrade by typing *aapm.upgrade.todo in the Service Manager client command box.

  11. Click Next to start the upgrade.
  12. Click Yes to confirm that you want to proceed. While the upgrade runs, the Upgrade Utility displays the progress of the upgrade by indicating which process is running, the progress of record processing, and the completion percentage for the upgrade.
  13. When you receive an UPGRADE IS COMPLETE message, the Upgrade Utility has finished the data processing.

    Caution! If the status window displays new schedulers after the upgrade completes, do not stop the system. Let the schedulers finish the background data upgrade before stopping the system.

  14. Log out of the Service Manager client and stop the Service Manager service.
  15. Restart the service and then log in to the client.
  16. Open the scversion table in Database Manager and verify that the Application Version field is 9.31.0022. If this field displays a value other than 9.31.0022, check the log files to identify the issue that occurred.

Finding tables and records that the Upgrade Utility did not upgrade

The Upgrade Utility does not automatically upgrade all tables and records. You can view the patches record to see a list of the tables and records that the custom upgrade includes. To view the patches record, click SERVICE PACK > Update Patch Definitions in the Upgrade Utility.

Customizations made to tables or records that do not appear in the patches record do not get upgraded. To make sure that the objects that you have reconciled are moved to the production system, verify that the patches record includes these objects. If it does not, you can do one of the following:

  • Create an unload file containing the objects by adding them to an unload script or using the standard Service Manager Unload/Export Facility.
  • Make the same changes manually by directly modifying or deleting the objects on the production system.

Perform additional manual tasks

This section describes changes that the Upgrade Utility cannot make automatically. Make the following changes manually.

The Upgrade utility does not automatically clean up artifacts that were left over by the upgrade, such as objects that were prefixed with NEW931 or PRE<version_number> which are copied and renamed from pre-upgrade objects. You must manually delete those objects against the exported list. Otherwise, the system may not work as expected. To find those objects, search the Upgrade Results list for records with a result type of "Auto Merged" "Previously Reconciled" "Renamed" or "Reconciled" and then export the list to an Excel file.

To make added or upgraded display options work as expected, you must manually re-save all the related display screens. To find those display screens, you can search the Upgrade Results list for display options records with a result type of "Added" "Auto Merged" "Previously Reconciled" "Renamed" "Reconciled" or "Upgraded" and export the list to an Excel file.

(Required) Make sure that all existing operator records have a contact record

Service Manager requires that every operator have a contact record. You can, however, have a contact record without a corresponding operator record. Review your existing operator records and create a contact record for every operator record that does not already have one. Service Manager provides four wizards that you can use to create the missing contact or operator records. These wizards become available when you click the drop-down options menu icon in the contacts.g and operator.g forms.

Disable the Synchronize contacts with operators option in the System Information Definition before running these wizards:

  • Create Operator wizard: Creates an operator record from a contact record.
  • Mass Create Operators wizard: Creates a batch of operator records from a batch of contact records.
  • Create Contact wizard: Creates a contact record from an operator record.
  • Mass Create Contacts wizard: Creates a batch of contact records from a batch of operator records.

You can customize how the wizards map fields from the contacts and operator tables by editing the createUsers JavaScript in the script library.

(Required) Update profile records in Problem Management

In Problem Management, profile records now contain settings to control access to Known Error Tasks. After you update your applications, the settings in the Known Error Tasks section of the profile records are not populated. Therefore, no users can access this feature. You must update your profile records to enable users to view and modify records within Known Error Tasks.

(Required) Specify the contact for Service Desk tickets

The Service Desk application uses these fields to list contacts for new calls:.

  • Contact for this call (callback.contact)
  • This call is for (contact.name)

Specify the contact for the callback.contact and contact.name fields for each existing Service Desk ticket in your system. You can use the Complex Update feature to fill these fields automatically if you have a large number of records. Once you select a contact (callback.contact), the other field, if left blank, defaults to the callback.contact.

(Required) Expose fields in the cm3r table

For Change Management with Web Services, the following fields in the cm3r table must be exposed after an upgrade:

  • header,assign.dept
  • affected.item
  • closureComments

These are now mandatory fields when opening or closing a Change record, so they must be accounted for in any Web services definitions. HP also recommends that you expose the emergency field in the cm3r table to support emergency changes.

To expose the fields, add them to the appropriate extaccess records for the cm3r table published in the Web services API.

  • header,assign.dept (suggested Caption=AssignmentGroup)
  • affected.item (suggested Caption=Service)
  • closureComments (suggested Caption=ClosureComments)
  • emergency (suggested Caption=Emergency)

For Incident Management with Web Services, expose the affected.item field in the cm3r table following an upgrade of the server. This is now a mandatory field when opening or closing an Incident record, so it must be accounted for in any Web services definitions.

To expose the field, add it to the appropriate extaccess records for the probsummary table published in the Web services API.

  • affected.item (suggested Caption=Service)

(Required) Change Configuration Item to Affected Item

In the Incident Management and Service Desk applications, the utility renamed the Configuration Item label to Affected Item. Review customized menus, formats, and messages that refer to Configuration Items and make any necessary changes to match the new naming convention (Affected Item).

(Required) Change modules to support multiple SLAs

Several Service Manager applications now support the use of multiple service level agreements (SLAs) for interactions, incidents, problem records and problem tasks, and change records. Service Manager uses a new agreement.ids array field instead of the scalar agreement.id field to represent SLA IDs. Therefore, you must identify your tailoring that references the agreement.id field and make changes accordingly. To do so, scan for references in tailoring that explicitly have agreement.id in an expression, and update each of those expressions so that it points to the agreement.ids field. Such references may reside in Format Control, Process, Scripts, Wizards, and other areas.

Example

If an expression contains: if agreement.id in $L.file=13 then $L.x="abc", you can change it to the following: if index(agreement.ids in $L.file,13)>0 then $L.x="abc".

To search for agreement.id

To identify tailoring that references agreement.id, you can use the out-of-box RAD function findAll, as described in these steps:

  1. Type rad in the Service Manager client command box and press Enter.
  2. When the RAD Editor opens, type findAll in the Application field, and then click Search.
  3. Select the findAll application and click Test.
  4. Click Proceed.
  5. In the String to Search for field, type agreement.id, and then click Search.

Possible areas that may include references to agreement.id

  • If any applications use the agreement.id field for SLA management, you must set the SLA ID Field to agreement.ids in the SLA Integration record for each application (by opening Service Level Management > SLA Administration > Configure Application). For example, change the SLA ID Field to agreement.ids for these applications:
    • The cm3r and cm3t tables in Change Management.
    • The probsummary table in Incident Management.
    • The rootcause and roocausetask tables in Problem Management.
    • The incidents table in Service Desk.
  • If you use Event Services that have event maps against the agreement.id field, update the event map or create a new one that maps to the agreement.ids field (array of numbers).
  • If you expose the agreement.id field in any existing extaccess records, change the field to agreement.ids.

(Optional) Localize Service Catalog items

The format of the Service Catalog data now allows for localization. For each Service Catalog item, the Upgrade Utility creates a record in the svcDisplay table for a language available on your system. The utility copies the original English record and adds a language code to each copy. Follow the steps in this section to localize your Service Catalog items.

  1. Type db in the Service Manager client command box and press Enter.
  2. In the Table field, type svcDisplay and click Search.
  3. From the Language drop-down list, select the language into which you want to localize your catalog items, and then click Search.
  4. Select each record, and replace the English text in the fields with the appropriate translation.
  5. Click Save.

(Optional) Modify automatically fixed data

If the Upgrade Utility found duplicates when imposing a Unique or No Duplicates key on a field, the utility fixed the duplicates by appending suffixes such as -dup1, - dup2, ...-dupx.

To change automatically modified values to your own values

  1. Open the sm.log file in the upgrade folder.
  2. Search for -dup and locate a message that resembles the following:

    RTE I scan: fix duplicates, changed column COLUMN_NAME in TABLE_ NAME to new value: ORIGINAL-dup1

    This message indicates that the utility found duplicates in the COLUMN_NAME field in the TABLE_NAME table, and it changed all duplicates other than the first instance from ORIGINAL to ORIGINAL-dup1, ORIGINAL-dup2, and so on.

  3. Change the auto-modified value to your own value, either by using the Service Manager client or by directly updating data in the RDBMS.
  4. Search for the next occurrence of -dup to fix the next duplicate item.
  5. Repeat steps 2 through 4 to change all of the values that the utility updated.

Return the test system to normal operation

After the upgrade, the system may not work correctly until you return it to its normal operating environment.

  1. Log out of the client and stop the Service Manager service.
  2. Restore the sm.cfg file to its original state.
  3. Restore the sm.ini file to its original state.
  4. Restart the Service Manager server and log in to the client.
  5. Regenerate your IR keys for the incidents table.

Note: Service Manager does not recompile indexes in your RDBMS. If your RDBMS is not configured to recompile indexes automatically after index changes, recompile your indexes manually.

Test the test system

Perform user acceptance testing on the test environment to verify that it functions properly. If there are problems that you cannot resolve, contact HP Software Support.

Prepare the Service Manager server on the production environment

To prepare the server for the upgrade, edit the Service Manager configuration (sm.cfg) and initialization (sm.ini) files. Note that you must return the sm.ini and sm.cfg files to their original state after the upgrade, so you may want to keep copies of the original files.

  1. Stop the Service Manager service.
  2. Open the Service Manager configuration file (sm.cfg) with a text editor.
  3. Comment out the sm system.start line to disable the background processes: #sm system.start.
  4. Add sm -sync to the end of the file if it does not yet exist. This parameter starts the sync process, which identifies and releases locks owned by inactive processes and shared memory that is not in use.

  5. If the the sm.cfg file contains more than one instance of the sm -httpPort parameter, comment out all instances except for one. Each sm -httpPort parameter starts a Service Manager server process. The upgrade needs only one process. Comment out all other parameters. Commenting out the parameters disables all of the other Service Manager processes that are not required during an upgrade.
  6. Save and close sm.cfg.
  7. Open the Service Manager initialization (sm.ini) file with a text editor.
  8. Add the sessiontimeout:1200 parameter to the end of the file if it does not exist. If this parameter exists, update it to an appropriate value. This parameter defines the number of minutes that the server waits for a client signal before the server assumes that the client session has timed out and closes the connection. A value of 1200 sets the timeout to 20 hours (1200 minutes), a period that should be long enough for an upgrade phase to complete in a typical scenario.
  9. Add the heartbeatinterval:120 parameter to the end of the file if it does not exist. This parameter 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.
  10. If you use HP-UX, add the following JVM option to the end of the file if it does not exist: JVMOption(#):-Xss6M. This parameter increases the Java virtual machine stack size to 6MB.

    When you add the parameter, replace the hash symbol (#) with an option number that does not exist in the sm.ini file. For example, if the file already contains a JVMOption(0) and JVMOption(1), add JVMOption(2):-Xss6M to the file.

  11. Replace the default shared_ memory:32000000 with shared_memory:96000000. This sets the shared memory size to 96MB. However, if you have a large database, you may need to allocate more shared memory to accommodate the upgrade processing.
  12. Add the jsgctrigger:67108864 parameter to the end of the file if it does not exist. This enables JavaScript garbage collection at a memory threshold of 64MB to avoid potential issues.
  13. Disable IR keys by adding this line to the end of the file: ir_disable:1
  14. Save and close sm.ini.
  15. Restart the Service Manager service.

Load the custom upgrade files on the production environment

  1. Copy from the development environment the custom upgrade folder that contains the custom upgrade files that the utility created. If you transfer the files to your system by FTP, set FTP to binary mode.
  2. Place the custom upgrade folder on the production server. For example, C:\temp\customupgrade.

    Place the custom upgrade folder on the production server. For example, /tmp/customupgrade.

  3. Make sure that the Service Manager server process (sm) has write and execute privileges for the custom upgrade directory.
  4. Log in to Service Manager as a system administrator.
  5. Click Window > Preferences > HP Service Manager and clear the Client side load/unload check box.

    Important: Failure to disable the Client side load/unload option causes the upgrade process to fail.

  6. Type db in the client command box, and then press Enter.
  7. From the Database Manager drop-down options menu, select Import/Load. Menu icon
  8. In the File Name field, navigate to the custom upgrade directory that you created, and double-click preupg.bin. For example, C:\temp\customupgrade\preupg.bin.

    In the File Name field, navigate to the custom upgrade directory that you created, and double-click preupg.bin. For example, /tmp/customupgrade/preupg.bin.

  9. Click Load FG.
  10. Type smupgrade in the Service Manager client command box, and press Enter.
  11. In the Upgrade Utility menu, click Load Transfer.
  12. Type the fully qualified path to the custom upgrade folder that you created. For example, C:\temp\customupgrade.

    Type the fully qualified path to the custom upgrade folder that you created. For example, /tmp/customupgrade.

  13. Click Next. The system loads transfer.bin and performs various mapping activities against select tables. Service Manager displays a "Transfer files loaded" message when the load is complete.
  14. Log out of the client and stop the Service Manager service.
  15. Restart the Service Manager service and log in to the client.

Apply the custom upgrade to the production system

Make sure that users cannot access the production system before you start the upgrade.

Caution! If you experience problems such as a power failure or a network connection error while upgrading the system, you can fix the issues and rerun the Upgrade Utility. The utility resumes the upgrade from the failure point. However, if the upgrade does not resume from the failure point, restore your database to the last backup point and fix possible issues; then rerun the Upgrade Utility.

  1. Type smupgrade in the client command box and press Enter.
  2. Click SERVICE PACK in the Upgrade Utilities menu.
  3. Click Apply an Upgrade, and then click Next.
  4. Make sure that the Applications version upgrading from field lists your current version of ServiceCenter or Service Manager, and then click Next. If the screen does not display the correct version number, do not continue with the upgrade. Contact HP Software Customer Support.
  5. Review the list of supported non-English languages that the Upgrade Utility will upgrade. By default, the languages that are installed on your system are set to true. Select false for the languages that you do not want to upgrade, and then click Next.

    Note: You cannot rerun the upgrade to select additional languages. Make sure that all languages that you want to upgrade are set to true.

  6. Select No since you are running the custom upgrade.
  7. Click Next.
  8. By default, the text box displays the fully qualified path to the Upgrade folder on the Service Manager server. Accept the path unless it does not specify the correct folder, and then click Next.
  9. Since you are running a custom upgrade that includes objects that you consider final, select Replace your version of the object with the HP Service Manager's version of the object, and then click Next.
  10. The utility asks if you want to generate To Do records for all existing open records in the major modules. If you want to generate all open application records, leave the Generate To Do records check box selected, and then click Next.

    Depending on the number of records in your Change Management, Incident Management, Service Desk, Problem Management, and Request Management applications, this step can take a significant amount of time. If you have a large number of records, you can choose to generate the records after completing the upgrade by typing *aapm.upgrade.todo in the Service Manager client command box.

  11. Click Next to start the upgrade.
  12. Click Yes to confirm that you want to proceed. While the upgrade runs, the Upgrade Utility displays the progress of the upgrade by indicating which process is running, the progress of record processing, and the completion percentage for the upgrade.
  13. When you receive an UPGRADE IS COMPLETE message, the Upgrade Utility has finished the data processing.

    Caution! If the status window displays new schedulers after the upgrade completes, do not stop the system. Let the schedulers finish the background data upgrade before stopping the system.

  14. Log out of the Service Manager client and stop the Service Manager service.
  15. Restart the service and then log in to the client.
  16. Open the scversion table in Database Manager and verify that the Application Version field is 9.31.0022. If this field displays a value other than 9.31.0022, check the log files to identify the issue that occurred.

Finding tables and records that the Upgrade Utility did not upgrade

The Upgrade Utility does not automatically upgrade all tables and records. You can view the patches record to see a list of the tables and records that the custom upgrade includes. To view the patches record, click SERVICE PACK > Update Patch Definitions in the Upgrade Utility.

Customizations made to tables or records that do not appear in the patches record do not get upgraded. To make sure that the objects that you have reconciled are moved to the production system, verify that the patches record includes these objects. If it does not, you can do one of the following:

  • Create an unload file containing the objects by adding them to an unload script or using the standard Service Manager Unload/Export Facility.
  • Make the same changes manually by directly modifying or deleting the objects on the production system.

Perform additional manual tasks

This section describes changes that the Upgrade Utility cannot make automatically. Make the following changes manually.

The Upgrade utility does not automatically clean up artifacts that were left over by the upgrade, such as objects that were prefixed with NEW931 or PRE<version_number> which are copied and renamed from pre-upgrade objects. You must manually delete those objects against the exported list. Otherwise, the system may not work as expected. To find those objects, search the Upgrade Results list for records with a result type of "Auto Merged" "Previously Reconciled" "Renamed" or "Reconciled" and then export the list to an Excel file.

To make added or upgraded display options work as expected, you must manually re-save all the related display screens. To find those display screens, you can search the Upgrade Results list for display options records with a result type of "Added" "Auto Merged" "Previously Reconciled" "Renamed" "Reconciled" or "Upgraded" and export the list to an Excel file.

(Required) Make sure that all existing operator records have a contact record

Service Manager requires that every operator have a contact record. You can, however, have a contact record without a corresponding operator record. Review your existing operator records and create a contact record for every operator record that does not already have one. Service Manager provides four wizards that you can use to create the missing contact or operator records. These wizards become available when you click the drop-down options menu icon in the contacts.g and operator.g forms.

Disable the Synchronize contacts with operators option in the System Information Definition before running these wizards:

  • Create Operator wizard: Creates an operator record from a contact record.
  • Mass Create Operators wizard: Creates a batch of operator records from a batch of contact records.
  • Create Contact wizard: Creates a contact record from an operator record.
  • Mass Create Contacts wizard: Creates a batch of contact records from a batch of operator records.

You can customize how the wizards map fields from the contacts and operator tables by editing the createUsers JavaScript in the script library.

(Required) Update profile records in Problem Management

In Problem Management, profile records now contain settings to control access to Known Error Tasks. After you update your applications, the settings in the Known Error Tasks section of the profile records are not populated. Therefore, no users can access this feature. You must update your profile records to enable users to view and modify records within Known Error Tasks.

(Required) Specify the contact for Service Desk tickets

The Service Desk application uses these fields to list contacts for new calls:.

  • Contact for this call (callback.contact)
  • This call is for (contact.name)

Specify the contact for the callback.contact and contact.name fields for each existing Service Desk ticket in your system. You can use the Complex Update feature to fill these fields automatically if you have a large number of records. Once you select a contact (callback.contact), the other field, if left blank, defaults to the callback.contact.

(Required) Expose fields in the cm3r table

For Change Management with Web Services, the following fields in the cm3r table must be exposed after an upgrade:

  • header,assign.dept
  • affected.item
  • closureComments

These are now mandatory fields when opening or closing a Change record, so they must be accounted for in any Web services definitions. HP also recommends that you expose the emergency field in the cm3r table to support emergency changes.

To expose the fields, add them to the appropriate extaccess records for the cm3r table published in the Web services API.

  • header,assign.dept (suggested Caption=AssignmentGroup)
  • affected.item (suggested Caption=Service)
  • closureComments (suggested Caption=ClosureComments)
  • emergency (suggested Caption=Emergency)

For Incident Management with Web Services, expose the affected.item field in the cm3r table following an upgrade of the server. This is now a mandatory field when opening or closing an Incident record, so it must be accounted for in any Web services definitions.

To expose the field, add it to the appropriate extaccess records for the probsummary table published in the Web services API.

  • affected.item (suggested Caption=Service)

(Required) Change Configuration Item to Affected Item

In the Incident Management and Service Desk applications, the utility renamed the Configuration Item label to Affected Item. Review customized menus, formats, and messages that refer to Configuration Items and make any necessary changes to match the new naming convention (Affected Item).

(Required) Change modules to support multiple SLAs

Several Service Manager applications now support the use of multiple service level agreements (SLAs) for interactions, incidents, problem records and problem tasks, and change records. Service Manager uses a new agreement.ids array field instead of the scalar agreement.id field to represent SLA IDs. Therefore, you must identify your tailoring that references the agreement.id field and make changes accordingly. To do so, scan for references in tailoring that explicitly have agreement.id in an expression, and update each of those expressions so that it points to the agreement.ids field. Such references may reside in Format Control, Process, Scripts, Wizards, and other areas.

Example

If an expression contains: if agreement.id in $L.file=13 then $L.x="abc", you can change it to the following: if index(agreement.ids in $L.file,13)>0 then $L.x="abc".

To search for agreement.id

To identify tailoring that references agreement.id, you can use the out-of-box RAD function findAll, as described in these steps:

  1. Type rad in the Service Manager client command box and press Enter.
  2. When the RAD Editor opens, type findAll in the Application field, and then click Search.
  3. Select the findAll application and click Test.
  4. Click Proceed.
  5. In the String to Search for field, type agreement.id, and then click Search.

Possible areas that may include references to agreement.id

  • If any applications use the agreement.id field for SLA management, you must set the SLA ID Field to agreement.ids in the SLA Integration record for each application (by opening Service Level Management > SLA Administration > Configure Application). For example, change the SLA ID Field to agreement.ids for these applications:
    • The cm3r and cm3t tables in Change Management.
    • The probsummary table in Incident Management.
    • The rootcause and roocausetask tables in Problem Management.
    • The incidents table in Service Desk.
  • If you use Event Services that have event maps against the agreement.id field, update the event map or create a new one that maps to the agreement.ids field (array of numbers).
  • If you expose the agreement.id field in any existing extaccess records, change the field to agreement.ids.

(Optional) Localize Service Catalog items

The format of the Service Catalog data now allows for localization. For each Service Catalog item, the Upgrade Utility creates a record in the svcDisplay table for a language available on your system. The utility copies the original English record and adds a language code to each copy. Follow the steps in this section to localize your Service Catalog items.

  1. Type db in the Service Manager client command box and press Enter.
  2. In the Table field, type svcDisplay and click Search.
  3. From the Language drop-down list, select the language into which you want to localize your catalog items, and then click Search.
  4. Select each record, and replace the English text in the fields with the appropriate translation.
  5. Click Save.

(Optional) Modify automatically fixed data

If the Upgrade Utility found duplicates when imposing a Unique or No Duplicates key on a field, the utility fixed the duplicates by appending suffixes such as -dup1, - dup2, ...-dupx.

To change automatically modified values to your own values

  1. Open the sm.log file in the upgrade folder.
  2. Search for -dup and locate a message that resembles the following:

    RTE I scan: fix duplicates, changed column COLUMN_NAME in TABLE_ NAME to new value: ORIGINAL-dup1

    This message indicates that the utility found duplicates in the COLUMN_NAME field in the TABLE_NAME table, and it changed all duplicates other than the first instance from ORIGINAL to ORIGINAL-dup1, ORIGINAL-dup2, and so on.

  3. Change the auto-modified value to your own value, either by using the Service Manager client or by directly updating data in the RDBMS.
  4. Search for the next occurrence of -dup to fix the next duplicate item.
  5. Repeat steps 2 through 4 to change all of the values that the utility updated.

Return the production system to normal operation

After the upgrade, the system may not work correctly until you return it to its normal operating environment.

  1. Log out of the client and stop the Service Manager service.
  2. Restore the sm.cfg file to its original state.
  3. Restore the sm.ini file to its original state.
  4. Restart the Service Manager server and log in to the client.
  5. Regenerate your IR keys for the incidents table.

Note: Service Manager does not recompile indexes in your RDBMS. If your RDBMS is not configured to recompile indexes automatically after index changes, recompile your indexes manually.

Apply post-upgrade updates

For all the existing integrations to work correctly, you must remove and re-create certain integrations in the Integration Manager. These integrations include the following:

  • Release Control integration
  • BSM OMi integration

For more information about your specific integration, see the Integrations section in the Service Manager Help.

Test the production system

Test the upgraded system and verify that it functions properly. If there are problems that you cannot resolve, contact HP Software Support.

Next steps

Congratulations! You have completed the upgrade to Service Manager 9.31 . You can view the Service Manager 9.31 online Help for information about database dictionaries, Database Manager, Forms Designer, Request Management, and the Display application.

Troubleshooting

Before you contact HP Service Manager Customer Support, try the following troubleshooting instructions to identify and resolve your issues. Click a symptom below to view information about the symptom and a possible resolution for the issue.

Document release date: October 2012
Software release date: October 2012