BIND_PATCH

SAP Support Packages, described in more detail in Section 4.7, can be applied in two ways: standalone by using the SAP Package Manager (also known as SPAM) or by adding them to an SAP release upgrade. It’s very important to understand the consequences of BIND_PATCH before you’re going to make use of it.

Let’s assume we have an SAP R/3 system on start release 4.5B with Support Package level 25. We would like to upgrade to SAP R/3 Enterprise 4.7 without any additional Support Packages. The consequences on this action might be that we downgrade certain functionality. To explain, a situation can go wrong if we just upgrade a system without applying Support Packages. Imagine an ABAP program RVABAP01 that is delivered with SAP R/3 4.5B. This ABAP program contains a serious bug due to the fact it’s trying to divide a number by zero. Support Package 1 (SP1) will correct this problem by adjusting the ABAP code. However, this bug was discovered after the release of the newer version 4.7. Therefore, just upgrading from 4.5B SP1 to 4.7 SP0 will introduce this bug again.

Figure 8.15: ABAP source code correction deleted during upgrade.

In order to correct this bug again, we need to apply Support Packages after the upgrade in order to restore the original bug fix.

Performing this operation after the upgrade is not an issue, however, if we’re trying to correct an error on a table structure, which contains data. It is not possible to do that after the upgrade.

To explain the situation for data in tables, imagine we have a table called TABX in our 4.5B system with a certain structure. Due to new functionality added to the Support Package, for example, to support new legal requirements, fields are changed or even added to the table. When this new functionality was released to the market after the release of SAP R/3 4.7, this structure change is unknown to the upgrade.

Figure 8.16: Data lost during upgrade.

In the worst situation, you might end up loosing data during the upgrade.

This issue is known as “Equivalence Attributes” and can be solved in the upgrade during the BIND_PATCH phase.

To prevent this from happening, the upgrade allows you to include Support Packages in the upgrade. The BIND_PATCH phase in the PREPARE tool allows you to specify the Support Packages you want to add to the upgrade. However, since SAP Web AS 6.10, certain items in BIND_PATCH have been changed. We will take a look at both “old” solutions, based on R/3 target release 4.6C and lower and the “newer” solution, which is based on SAP R/3 target release 4.7 or higher. This means that there is a difference between SAP Basis 4.6 and lower and SAP Web AS 6.10 and higher.

During BIND_PATCH in PREPARE, you will be asked whether Support Packages need to be included. It is strongly recommended to include these.

Depending on the release of PREPARE and R3up, certain things need to be done manually. For example, the newer R3up is able to pick EPS (Electronic Package Service) files up from “/usr/sap/trans/EPS/in” and UNCAR or UNSAR them.

However, if you’re working with an older R3up due to the fact your target SAP release is older than R/3 Enterprise, you have to disassemble these EPS files yourself. Just download all necessary EPS files from the Web and place them in

“/usr/sap/trans/EPS/in” and update your system with the latest SPAM update.

TIP During a SPAM update, several errors might occur, such as: LOAD_PROGRAM_

LOST, SAPSQL_SELECT_WA_TOO_SMALL, or SAPSQL_WA_TOO_SMALL.

These errors are caused due to a “bootstrap” problem. You’re updating the engine, which is doing the update for you. Just ignore the message by exiting transaction SPAM, reset all buffers in the SAP system with /$SYNC, and restart transaction SPAM.

You need a copy of the latest SPAM for using program RSSAPM13 or RSSPDASS, depending on your SAP source release, in order to create co- and datafiles from every EPS file. At a later stage, R3up will bind these files to the upgrade. In a few occasions it might also be possible that R3trans and tp need to be upgraded to a higher patch level. This is possible in case the co- and datafiles are created by SAP with a newer version of tp and R3trans compared to what is installed on your system. In older SAP releases, the ABAP programs that are used instead are RSEPSUPL (Upload Support Packages in SPAM) and RSEPSDOL (Create ATT files from EPS bundles).

TIP Please read carefully the SAP Upgrade Manual and all related SAP notes before you do any actions. ABAP names might change from time to time and certain steps are done by R3up/SAPup now.

During previous upgrades, the process of applying Support Packages during the upgrade was similar to a normal, regular, import of Support Packages using SPAM. The co- and datafiles that reside in the Support Packages are imported the same way during phases BIND_PATCH, PATCH_CMDIMP, and PATCH_MERGE as done by SPAM. Therefore, the same rules apply for this technique as for the normal SPAM situation.

Not all combinations of Support Package queues can be imported into the system. The consequence of this is that only one Support Package queue can be imported during the upgrade. As explained previously in Chapter 4, certain Support Packages have conflicts.

Having conflicts between Support Packages during BIND_PATCH can be problematic when you loose data during the upgrade. Assume you’re on SAP R/3 3.1I, with Support Package level 35, and you want to upgrade to SAP R/3 4.6C.

Certain functionality is only shipped in Support Package 10 for release 4.6C and therefore you want to bind at least Support Package level 10 with your upgrade.

However, there is a conflict between Support Package 8 and 9, therefore, you can only bind up to level 8 in your upgrade phase BIND_PATCH. The warning, which is shown during PREPARE phase PATCH_CHKN look like this (this example is taken from a BW upgrade to 3.0B) :

WARNING> *** Patch Level too high ***

The latest “BW Support Package” confirmed in your system has patch level 17.

But: the upgrade to be applied here is based on

the BW Support Package state with patch level 14.

Any conflict with BW Support Package, patch level 15–17, can be resolved with the latest available release for the R/3 System

or with the latest “BW Support Package” for Release 30B.

TIP If you seem to lose data due to this issue, the advice would be to address this yourself by correcting the tables yourself. However, do this only when you’re on target release 4.6C or below. Otherwise, contact SAP Global Active Support.

The BIND_PATCH phase is also supported by phase CONFLICT_CHECK, which performs a sanity check with respect to conflicts between the various patches. This phase uses ABAP function module SPDA_PREPARE_PATCH, which is part of the SPAM transaction. Therefore this function is only available for upgrade with a SAP source release higher than 4.0B. The log files produced by the phase are “/usr/sap/put/log/CONFLCHK.LOG” and “/usr/sap/put/log/

SPDA_CONFLCHK.LOG”.