Confirmation of Support Packages (Phase PATCH_CHK)

Release upgrade only:

This phase checks that the following prerequisites are met:

• Confirm all support packages for the source release. Unconfirmed support packages are displayed on the screen, and in the PATCHOUT.LOG file located in the log subdirectory.

• The source release does not contain support packages that are more recent than those in the delivered target release.

If you have to confirm support packages for the source release, proceed as follows:

1. Call transaction SPAM and confirm the support packages that are proposed there.

2. If a warning appears that the support package level of your source release is too high, proceed as follows:

   • If you have already included support packages in the BIND_PATCH phase, you can ignore this warning.

   • If you have not included any support packages in the BIND_PATCH phase, you lose data if you continue with the upgrade. In this case, reset the upgrade, repeat all phases including phase BIND_PATCH, and include the necessary support packages.

SPS update:

All support packages have to be confirmed in your system. Unconfirmed support packages are displayed on the screen, and in the PATCHOUT.LOG file as well. The log file can be found in the log sub directory of the SUM directory.

If you still have to confirm support packages, call transaction SPAM and confirm the support packages that are proposed there.

Automatic Reset of Non-Adjusted Repository Objects to SAP Original Version (Phase RUN_SUM_SPDD_RESET_CANDIDATES or RUN_SUM_SPDD_RESET_CANDIDATES_TRANS)

In this phase, the Software Update Manager identifies and lists ABAP Dictionary objects with active SAP versions that are modified but not yet adjusted, and that can be reset to SAP standard versions. The Software Update Manager compares the existing customer version of a repository object with the new, imported SAP version. If the SAP version is type compatible with the customer version, the Software Update Manager lists the object as a potential reset candidate. Type compatibility in this context means that the customer version is included in the SAP version.

The compatibility check includes more data for a comparison than the data mentioned in the previous examples. The log file of the phase RUN_SUM_SPDD_RESET_CANDIDATES contains the details about the compared objects and informs you about the reasons why an object is considered to be a potential reset candidate or not. In addition, the log file contains a plain list of all potential reset candidates in the summary section.

Make sure that you check the candidates list before you execute the automatic reset because the compatibility check covers the technical perspective only.

Consistency Check for Components and Objects (RUN_RSUPG_TADIR_COMPONENT_CHECK)

During a System Switch Upgrade procedure (see also Technical Details of the Upgrade Procedure), a new ABAP repository is set up in the shadow instance based on the data of the Upgrade Export archives. This repository replaces the repository of the source release. Customer repository objects, which do not belong to SAP and which are to be used after the update, must be rescued before the replacement.

The Software Update Manager performs this rescue by exporting the repository objects from the old ABAP repository and importing them to the new one. The information about the affected repository objects is calculated and collected in phase RUN_RDDIT006. It analyzes the SAP system to find customer objects as well as objects modified by the customer. All objects selected for the rescue are written to dedicated transport requests that is imported into the new ABAP repository in various DIFFEX* phases.

It is important for a complete and correct rescue that the correct owner is associated to customer objects and that all optional add-ons are correctly installed, too. To avoid a loss of ABAP repository objects, several checks for inconsistencies are performed in phase RUN_RSUPG_TADIR_COMPONENT_CHECK. If the Software Update Manager displays error messages as a result of the checks, you have to examine them carefully.

You can use the program RSUPG_TADIR_COMPONENT_CHECK, which is delivered together with the Software Update Manager, to correct the following issues:

• Ownership of customer objects

  You can correct the ownership of all LOCAL and HOME objects that cannot be identified as customer objects.

• Unregistered software components

  You can select the software components that are relevant for the new ABAP repository and change them to customer objects. However, we strongly recommend contacting the vendor to request the delivery of the software component as a regular add-on.

The change of the ownership is registered in the transport request that you specify when you select this option. Use this transport to correct the ownership of the objects in the other systems of the system landscape, too.

Operating System and Database Version (Phase CONFCHK_X)

This target release is released for certain combinations of operating system and database versions only. This phase checks that the operating system and database versions installed on your computer satisfy the requirements for the upgrade.

You can interrupt the procedure at this point if you must import additional software, or if you must upgrade the database or the operating system to a new version because of a version check.

Conflicts with Customer Tables in the SAP Namespace (Phase VIEWCHK*)

This phase displays conflicts between customer tables in the SAP namespace and views that are delivered for the first time. It also writes this information to a log file.

You have to rename or delete the tables. If the tables are transparent, you can delete the customer tables using the Software Update Manager. You have to delete pool or cluster tables manually in the SAP system. First save any data that you need in these tables.

Environment Profiles Customizing (Phase ENVFILES_PREP)

The file templates of the environment files are copied to subdirectory <SUM directory>/abap/sapnames/envfiles and stored here with capital letters and without leading point as follows:

An entry in the log file CHECKS.LOG informs you that the user environment has been prepared. You have now the option to adjust the environment files to the environment profiles of target system user <SID>adm. You can make the changes up to the start of phase ENVFILES_COPY, in which the environment files are then copied to the home directory of user <SID>adm on your target system.

For more information, see Customizing of Environment Profiles.

Repairs and Requests Containing Objects Locked by SAP (Phase REPACHK1)

This phase displays all repairs and requests containing objects locked by SAP and writes them to the REPACHK1.LOG file.

You can ignore the messages at this point. Release these objects and the repairs confirmed at the latest by the REPACHK2 phase.

Outstanding or Incomplete Updates (Phase JOB_RSVBCHCK2)

If there are any outstanding or incomplete updates, the update stops in this phase with a message.

If errors occur in this phase and you have not stopped production operation yet, you can skip these errors with ignore without entering a password. However, we recommend that you check for these updates and clean them up. The message is:

Open update tasks found; please clean them up

Free Space in Subdirectory log (Phase FREECHK_X)

This phase checks whether there is enough free space in log subdirectory during the update. Make sure you have enough free space in the log subdirectory so that the update can run without errors.

If a kernel switch is performed, this phase also compares the free disk space in the SAP kernel directory with the space requirements of the new SAP kernel. Make sure that you are able to restore the old SAP kernel if this becomes necessary.

ABAP Workbench Locking (Phase REPACHK_EHPI)

If you perform an enhancement package installation or an support package stack update, and you have chosen scenario strategy Standard or Downtime-optimized, the Software Update Manager asked you in this phase to confirm the locking of the ABAP Workbench on all SAP instances.

This lock prevents development objects (for example, ABAP reports, table definitions, and so on) from being changed during the update since these modifications would be lost.

You can continue to use your SAP system in production operation, even if you confirm that the ABAP Workbench can be locked. However, after you have confirmed the ABAP Workbench lock, no more transports can be made into or out of the SAP system. Some further actions can be blocked that either check for this lock as well or for the running update. This is especially known in the area of Business Intelligence and SAP Solution Manager.

This phase displays all the repairs that are still in open transport requests. They are also written to the REPACHK_EHPI.LOG file. Release these transport requests so that you can continue; otherwise, the objects contained in these repairs are locked.

Unreleased Repairs and Corrections and ABAP Workbench Locking (Phase REPACHK2)

This phase displays all the repairs and corrections that are not released and writes them to the REPACHK_EHPI.LOG file. Furthermore, the Software Update Manager asks you during an upgrade in this phase to confirm the locking of the ABAP Workbench on all SAP instances.

The Software Update Manager waits until the time you entered as the maximum synchronization time for all instances has expired.

This phase displays all the repairs that are still in open transport requests. They are also written to the REPACHK_EHPI.LOG file. Release these transport requests so that you can continue; otherwise, the objects contained in these repairs are locked.

Terminated Conversion Cleanup (Phase CNV_CHK_XT)

This phase checks whether the following still exist:

• Unprocessed conversion requests

• Restart logs

If there are errors, you receive an error message. Proceed as described in Cleaning Up Terminated Conversions in the DB Conversion Phases.

Comparison of Modifications (Phase ADJUSTCHK)

If you chose to copy a request in the SUMASK_SPDD_SPAU phase, the modifications it contains are now compared with the modifications in the system. The result of this comparison appears.

You are prompted to confirm that the request was copied. If this request contains all the modifications found in the system, the Software Update Manager does not stop before the activation of the ABAP Dictionary objects. However, you can still specify that you want the Software Update Manager to stop in this phase.

Cleanup of Outstanding Updates (Phases JOB_RSVBCHCK_R and JOB_RSVBCHCK_D)

In these phases, you must clean up all outstanding updates. Furthermore, you have to clean up all outbound queue RFC calls and all open data extraction orders that you notice in the system at this point in time.

Proceed as follows:

1. Clean up the outstanding updates, outbound queue RFC calls, and open data extraction orders as described in Evaluating the Results of the Checks Roadmap Steps.

   See there under message: Open update tasks found; please clean them up

2. Repeat the current phase.

Modification Adjustment and Activation (ACT_UPG)

Depending on the results of the SUMASK_SPDD_SPAU phase, the Software Update Manager can ask you at the beginning of this phase to adjust your modifications to ABAP Dictionary objects. In this way, they correspond to the new SAP standard version of the objects.

The ACT_UPG phase can take long, particularly when you have made many modifications to the SAP system or included a lot of support packages. This is because the ABAP Dictionary activation program first calculates the dependent objects and the activation sequence for all ABAP Dictionary objects that must be activated. For example, structures have to be activated before they can be used in tables or table types. These dependencies between ABAP Dictionary objects are often complicated. The same kind of dependencies might have to be calculated several times with different input sets. Nevertheless, you can check in the process overview of transaction SM50 that the batch job RDDMASGL is still running.

Modification Adjustment

To make adjustments, proceed as follows:

1. The Software Update Manager prompts you to confirm that you want to perform a modification adjustment.

2. Add an entry for the shadow instance to the SAP Logon.

   For the server and system ID, use the values from the original system; for the instance number, use the value you specified in the preparation units for the shadow instance. The default value is the instance number of the original system plus one.

   Since the original system is still running if you use the scenario strategy Standard or Downtime-optimized, you can also log on to the shadow instance in transaction SM59 with the RFC connection SAP_UPGRADE_SHADOW_SYSTEM.

3. Log on to the shadow instance as user DDIC with the DDIC password of the original system.

   Only the users DDIC and SAP* exist in the shadow instance.

4. To set the system change option, call transaction SE06. Perform the following actions:

   1. Set the global setting to Modifiable.

   2. Set the change option for the software components to Modifiable or Restricted modifiable.

   3. Set the SAP namespace to Modifiable.

5. Call transaction SU01 to create one or more users to perform the modification adjustment. The new users exist only on the shadow instance and are not copied to the original system.

   Release upgrade only: Copy the user DDIC of client 000.

   SPS update: Since all users of client 000 are copied in the DBCLONE phase to the shadow instance, any of them can be used for the modification adjustment.

6. Log on to the shadow instance with one of the new users.

   Modification adjustment of ABAP Dictionary objects has to be performed in client 000.

7. To determine the ABAP Dictionary objects that must be adjusted, call transaction SPDD.

   For more information about transaction SPDD, see the SAP NetWeaver Library for the target release at:

   Function-Oriented View  Application Server ABAP  Application Development on AS ABAP  ABAP Customer Development  Changing the SAP Standard (BC)  Modifying the Standard  The Modification Assistant  Upgrade Procedure /Support Packages (link at the bottom of the page)  Adjusting ABAP Dictionary Objects

   For more information about the Modification Assistant, see the SAP NetWeaver Library for the target release at:

   SAP NetWeaver Library Process Integration Library  Function-Oriented View  Application Server ABAP  Application Development on AS ABAP  ABAP Customer Development  Changing the SAP Standard (BC)  The Modification Assistant

Activation

Customer-defined ABAP Dictionary objects may have activation errors during the ACT_UPG phase. This happens, for example, when these objects refer to SAP objects that were deleted in the target release. For similar reasons, modifications of ABAP Dictionary objects that belong to the SAP standard delivery may also cause activation errors.

If your customer-defined objects have activation errors, you can correct them using transaction SE11 in the shadow system. If, however, you activate the objects using transaction SE11 in the shadow system, the objects are created with inactive runtime objects. This behavior is different compared to the regular behavior of transaction SE11 in a development system.

All changes to an ABAP Dictionary object during the ACT_UPG phase are automatically recorded in a transport request. If you have to adjust modified SAP objects in transaction SPDD, the SAP system creates the transport request automatically, as mentioned above. If however, you correct your customer-defined objects, we recommend that you create a transport request and use it as a single transport request in your subsequent system during the update. For more information about including the single transport request, see Request for Single Transport Request (Phase SUMASK_SINGLE_TRANSPORT_REQUEST) in Important Entries for the Configuration Roadmap Step.

However, you can also choose accept non-severe errors to temporarily ignore these errors. You do not need a password to do this. If you chose accept non-severe errors here, you have to activate these objects after the update.

In case of non-ignorable errors, you must not continue with the next phase. You first have to remove the cause of the termination.

Safety Export for Objects Adjusted with SPDD (Phase UEXP_SPDD_SAV)

During an update, subsequent systems might require an SPDD transport request before the Postprocessing roadmap step. To meet this requirement, the Software Update Manager creates and exports a safety transport request directly after the activation phase. This is phase ACT_TRANS, if you use scenario strategy Single System.

If you use scenario strategy Standard or Downtime-optimized, the activation phase is called ACT_UPG.

This transport request contains all objects of the flagged SPDD transport request. Both the data and the cofiles of the safety transport request are copied to the transport directory of your SAP system. The name of this transport request is stored in the log file UEXP_SPDD_SAV.LOG.

Creation of Database Indexes (Phase RUNASYN_RSINDCRE)

The Software Update Manager starts the background job RSINDCRE that creates secondary database indexes. The Software Update Manager does not wait for the results of this phase, it continues with the next phase.

If the creation of a secondary database index fails, an error message is written to the log file RSINDCRE.<SID> and the creation of the index is repeated during the downtime. This can in rare cases increase the duration of the downtime.

If you want to make sure that all secondary database indexes have been created successfully before you start with the downtime, check log file RSINDCRE.<SID> for any error messages. If log file RSINDCRE.<SID> displays error messages and you can solve these errors, restart the asynchronous index creation during the uptime by performing the following steps:

1. Check whether background job RSINDCRE has stopped and is no longer running as a background job.

2. Reschedule background job RSINDCRE.

SAP Notes Implementation in the Shadow System (CHECK4NOTES_TOOL_SHD2)

The Software Update Manager displays in phase CHECK4NOTES_TOOL_SHD2 in the shadow system a list of SAP Notes that have to be implemented using the SAP Note Assistant (transaction SNOTE). After the implementation of all relevant SAP Notes, repeat the phase and then continue the process.

Preparation of SAP System for Downtime (Phase DOWNCONF*)

At the end of the Preprocessing roadmap step, the Software Update Manager requests you in phase DOWNCONF_DTTRANS to perform actions that prepare your SAP system for the downtime.

The Software Update Manager requests you to perform the following actions:

1. Make sure that all production work in the SAP system is stopped and no users are logged on to the SAP system.

2. Make sure that no scheduled batch jobs can start anymore and await regular completion of currently running jobs.

3. Isolate the primary application server instance.

   For more information, see Isolating the Primary Application Server Instance.

4. After having completed these actions, choose Next to proceed to the next screen.

   The Software Update Manager stops the primary application server instance.

5. Before you enter the downtime, you are requested to perform the following backups:

   1. Back up your database.

      In case of problems during the downtime, for example, a hardware failure, you need the backup of your database and the directories to reset the SAP system to the current state. The directories include, among others, profiles, trace files, and files for the SAP kernel needed for a reset of the SAP system.

   2. Back up directory /usr/sap/<SID> including the update directory.

   3. Back up the home directory of user <SID>adm. If you must reset the update and problems occur when starting and stopping the SAP system, you may need to use the old user profiles contained in this directory.

6. If you have chosen the scenario strategy Standard or Downtime-optimized, archiving is disabled. If the disabling of the archiving fails, the Software Update Manager prompts you to disable archiving manually.