sap netweaver applicationserver upgrade guide · pdf file9 prepare process for sap ecc ......

Bonn � Boston

Bert Vanstechelman, Mark Mergaerts, Dirk Matthys

SAP NetWeaver® ApplicationServer Upgrade Guide

144.book Seite 3 Mittwoch, 1. August 2007 10:09 10

Contents at a Glance

1 Introduction ....................................................................................... 21

2 Upgrading SAP: The Project Perspective ........................................... 27

3 The SAP Upgrade Project .................................................................. 33

4 Technical Background Information ................................................... 63

5 Planning the Upgrade ........................................................................ 93

6 Preparing the Technical Upgrade ...................................................... 105

7 A Guided Tour of the Upgrade Tools ................................................. 149

8 Preparing the Upgrade for SAP ECC .................................................. 197

9 PREPARE Process for SAP ECC .......................................................... 205

10 The Upgrade Process for SAP ECC ..................................................... 239

11 Upgrade Postprocessing for SAP ECC ............................................... 281

12 Prepare the Upgrade for the AS Java ................................................ 293

13 The PREPARE Process for the AS Java ............................................... 297

14 The Upgrade Process for the AS Java ................................................ 317

15 Upgrade Postprocessing for the AS Java ........................................... 325

16 Upgrade of SAP NetWeaver Business Intelligence ........................... 329

17 Upgrade of SAP SCM ......................................................................... 347

18 Upgrade of SAP CRM and SRM ......................................................... 387

19 Unicode and the Combined Upgrade and Unicode Conversion ........ 389

20 Combined Upgrade and Unicode Conversion (CU&UC) in Detail ...... 411

21 Modification Adjustment .................................................................. 527

22 Resetting the Upgrade ...................................................................... 543

A Vocabulary Hints ............................................................................... 547

B SAP Releases and Upgrade Paths ...................................................... 559

C Database Transaction Log Modes ..................................................... 563

D Codepages ......................................................................................... 565

E SAP Notes .......................................................................................... 567

F References ......................................................................................... 571

G The Authors ....................................................................................... 573


7

Contents

1 Introduction ......................................................................... 21

2 Upgrading SAP: The Project Perspective ............................. 27

2.1 Why Upgrade? ......................................................................... 272.2 What Is the Effort? .................................................................. 292.3 To Which Release? .................................................................. 302.4 The Technical SAP Upgrade in a Nutshell ................................. 30

3 The SAP Upgrade Project ..................................................... 33

3.1 Project Planning ...................................................................... 333.1.1 Planning Levels ........................................................... 333.1.2 Critical Success Factors ................................................ 34

3.2 Aspects to Consider ................................................................. 353.2.1 Ongoing Development and Customizing ..................... 353.2.2 Testing ........................................................................ 353.2.3 Compatibility of SAP Plug-in Versions ......................... 363.2.4 Compatibility of the Operating System and

the Database ............................................................... 363.2.5 Hardware Capacity ...................................................... 363.2.6 Frontend (SAP GUI) .................................................... 363.2.7 SAP Solution Manager ................................................ 373.2.8 System Landscape During the Upgrade ....................... 373.2.9 Often Overlooked Upgrade Aspects ............................ 38

3.3 Where to Start? ....................................................................... 393.4 The Master Project Plan ........................................................... 393.5 The Project Team ..................................................................... 413.6 The Testing Phase .................................................................... 42

3.6.1 Test Strategy ............................................................... 433.6.2 Test Scenarios ............................................................. 443.6.3 Tools ........................................................................... 45

3.7 Status Reporting ...................................................................... 453.7.1 Global Status Reporting (the Test Cockpit) .................. 453.7.2 Make Your Progress Visible ......................................... 453.7.3 Estimate the Effort ...................................................... 463.7.4 The Number of SAP Objects Modified ......................... 473.7.5 Customer Developments ............................................. 483.7.6 ABAP Unicode Syntax Requirements ........................... 51


Contents

8

3.7.7 Custom-Developed Programs No Longer in Use .......... 513.7.8 Estimating the Functional Effort .................................. 513.7.9 Business Example, Upgrade from 4.6B to ECC 6.0 ....... 533.7.10 Estimating the Technical Upgrade Runtime for the

Production System ...................................................... 543.8 Enabling New Customizing and Functionality ........................... 553.9 Capacity Planning When Upgrading to SAP ERP ...................... 573.10 SAP Solution Manager and the SAP Upgrade Roadmap ........... 603.11 Final Tips and Recommendations ............................................. 61

3.11.1 Seek Assistance and Information ................................. 613.11.2 The Usual Suspects That Need Extra Attention ............ 61

4 Technical Background Information ...................................... 63

4.1 The SAP NetWeaver Architecture ............................................ 634.1.1 People Integration ...................................................... 634.1.2 Information Integration ............................................... 654.1.3 Process Integration ..................................................... 654.1.4 Application Platform ................................................... 66

4.2 Introducing SAP ERP ............................................................... 664.3 Names and Numbers: An Overview of SAP Releases ................ 684.4 Support Packages and Add-ons ................................................ 694.5 The System Switch Upgrade ..................................................... 704.6 Upgrade Strategy Planning ....................................................... 724.7 Database-Specific Aspects ....................................................... 764.8 Upgrades in an MCOD System Landscape ................................ 784.9 The SAP Landscape During the Upgrade .................................. 80

4.9.1 The Impact of the Upgrade on the Landscape ............. 804.9.2 Scenarios for the Landscape Setup .............................. 814.9.3 Scenario 1: The Sandbox System ................................. 814.9.4 Scenario 2: Extra Development and Quality-

Assurance Systems ...................................................... 834.9.5 Scenario 3: Contingency System .................................. 85

4.10 Upgrading the Frontend Software ............................................ 864.11 The Customer-Based Upgrade .................................................. 864.12 The Application Specific Upgrade ............................................ 884.13 Synchronized Upgrade of Double-Stacked Systems .................. 89

4.13.1 Upgrade Process ......................................................... 904.13.2 Technical Implementation ........................................... 92


Contents

9

5 Planning the Upgrade .......................................................... 93

5.1 Top-Level View ....................................................................... 935.2 Downtime-Minimized Versus Resource-Minimized .................. 955.3 Database Archiving Mode ........................................................ 965.4 Which Strategy Is the Best? ..................................................... 985.5 Time Schedule for Technical Upgrade ..................................... 995.6 Pre-Upgrade Downtime ........................................................... 1015.7 Upgrade Services ..................................................................... 102

5.7.1 SAP GoingLive Functional Upgrade Check ................... 1025.7.2 SAP Safeguarding for Upgrade ..................................... 1025.7.3 Other Upgrade Services .............................................. 1025.7.4 Information Links for SAP Upgrade Services ................ 103

6 Preparing the Technical Upgrade ......................................... 105

6.1 The Upgrade Documentation ................................................... 1066.1.1 The Upgrade Guides ................................................... 1066.1.2 The Upgrade Notes ..................................................... 1096.1.3 Creating Your Own Documentation ............................ 111

6.2 Hardware and Software Requirements ..................................... 1146.2.1 SAP Platform Availability Matrix (PAM) ....................... 1156.2.2 Informix No Longer Supported .................................... 1166.2.3 Capacity Requirements ............................................... 1166.2.4 SAP Solution Manager System .................................... 121

6.3 The Upgrade Directory ............................................................ 1216.3.1 ABAP Upgrade Directory: Path, Location, and

Subdirectories ............................................................. 1226.3.2 Java Upgrade Directory: Path, Location, and

Subdirectories ............................................................. 1256.4 The Media Directory ................................................................ 126

6.4.1 Purpose of the Media Directory .................................. 1266.4.2 Location and Path Name ............................................. 1276.4.3 Directory Structure ..................................................... 127

6.5 The Upgrade Media ................................................................. 1296.5.1 Packages and Downloads ............................................ 1296.5.2 Selecting the Media Needed for the Upgrade .............. 1316.5.3 The Upgrade Master Media ........................................ 1326.5.4 Kernel Media .............................................................. 1346.5.5 ABAP Upgrade Export ................................................. 1356.5.6 Java Components ........................................................ 1356.5.7 The Language Media (ABAP) ....................................... 135


Contents

10

6.5.8 The RDBMS Upgrade Media ....................................... 1356.5.9 Other Media ............................................................... 1356.5.10 File Formats for Downloads ........................................ 136

6.6 Support Packages and Other Fixes ........................................... 1366.6.1 Support Package Stacks (SP Stacks) ............................. 1376.6.2 Support Releases (SR) ................................................. 1376.6.3 Selecting and Downloading the SP Stack with the

Maintenance Optimizer .............................................. 1386.6.4 Corrections for the Upgrade Tools: The Fix Buffers ...... 145

7 A Guided Tour of the Upgrade Tools ................................... 149

7.1 Introducing the Tools .............................................................. 1507.1.1 Synchronized Upgrades ............................................... 1507.1.2 Upgrade Program and Control Program ....................... 1517.1.3 The Upgrade Programs: SAPup and SAPJup ................. 1517.1.4 PREPARE versus Upgrade ............................................ 1527.1.5 The Control Programs: Upgrade Assistant and SDT

Server/GUI .................................................................. 1557.1.6 The ABAP Upgrade Assistant (UA) .............................. 1567.1.7 SDT for Java ................................................................ 1597.1.8 Prerequisites for the Upgrade Tools ............................. 161

7.2 Installation of the Upgrade Tools: ABAP .................................. 1627.2.1 Initial Run of PREPARE ............................................... 1637.2.2 Initial PREPARE Run: UNIX and Linux ......................... 1637.2.3 Initial PREPARE run: Windows .................................... 1647.2.4 Replace SAPup ............................................................ 166

7.3 Using the ABAP Upgrade Assistant .......................................... 1677.3.1 Starting the UA Server ................................................. 1677.3.2 Starting the UA GUI .................................................... 1687.3.3 Features of the UA GUI ............................................... 1727.3.4 SAPup Command Options ........................................... 1827.3.5 Tips and Tricks ............................................................ 185

7.4 Installation of the Upgrade Tools: Java ..................................... 1887.4.1 Initial PREPARE Run: UNIX and Linux ......................... 1897.4.2 Initial PREPARE Run: Windows ................................... 190

7.5 Using the Java SDT GUI ........................................................... 1917.5.1 Starting the SDT Server ............................................... 1917.5.2 Starting the SDT GUI ................................................... 1927.5.3 Features of the SDT GUI .............................................. 1937.5.4 Tips and Tricks ............................................................ 195

7.6 Ready to Go ............................................................................ 196


Contents

11

8 Preparing the Upgrade for SAP ECC .................................... 197

8.1 SAP Solution Manager System ................................................. 1978.2 Review of Transport Requests .................................................. 1998.3 Activities in the SAP System .................................................... 199

8.3.1 Create a User for the Upgrade ..................................... 2008.3.2 Create a Development Class (Package) for

the Upgrade ................................................................ 2008.3.3 Repairs — Updates — Pending DB Conversions .......... 2008.3.4 Substitution Tables in Wrong Database Space ............. 2008.3.5 Migration of Workload Statistics Data to

SAP NetWeaver 2004s ................................................ 2038.3.6 Ready to Go! ............................................................... 204

9 PREPARE Process for SAP ECC ............................................. 205

9.1 PREPARE ................................................................................. 2059.2 The Upgrade Assistant (UA) ..................................................... 208

9.2.1 Administrator and Observer Modes ............................ 2089.2.2 Scroll Mode ................................................................ 209

9.3 The Initial Extraction Script ...................................................... 2109.4 SAPup and Correction Transports ............................................ 210

9.4.1 Replace SAPup ............................................................ 2109.4.2 Correction Transports (Fix Buffer) ................................ 211

9.5 Copy Phase List Files to PC (Optional) ..................................... 2119.6 Install UA GUI on Workstation (Optional) ............................... 2119.7 Start the UA Server .................................................................. 2129.8 Start UA GUI and Log In .......................................................... 213

9.8.1 Starting from a Browser ............................................... 2139.8.2 Starting as a Standalone Application ........................... 214

9.9 Runtime of PREPARE .............................................................. 2149.10 Input Up to Phase Selection .................................................... 2159.11 Entering the CD/DVD Mount Points ........................................ 2179.12 Kernel Extraction and Optional Replacement ........................... 2179.13 Input for Server and Path Names ............................................. 2189.14 Input for Parallel Processing .................................................... 2199.15 Further Input for Path Names .................................................. 2199.16 Input for MCOD ...................................................................... 2209.17 Upgrade Key (from SAP Solution Manager) .............................. 2209.18 J2EE Instance (Double-Stacked System) ................................... 2209.19 Tool Import ............................................................................. 2219.20 Input for Language Selection ................................................... 221


Contents

12

9.21 Add-on and Patch Binding ....................................................... 2229.21.1 Add-on Components ................................................... 2229.21.2 Patch Binding .............................................................. 224

9.22 Input for Modification Adjustment .......................................... 2269.23 Input for the Shadow Instance ................................................. 2289.24 Application-Specific Upgrade (ASU) ......................................... 2299.25 Result of PREPARE .................................................................. 2309.26 Correcting Errors Reported by PREPARE .................................. 230

9.26.1 The CHECKS.LOG File ................................................. 2319.26.2 PREPARE Errors .......................................................... 2319.26.3 Database Extensions ................................................... 2319.26.4 Change the Permissions of Executables ....................... 2329.26.5 Target Kernel Too Low ................................................ 2329.26.6 SAP Objects Locked in Repairs .................................... 2339.26.7 Doomed Dictionary Objects ........................................ 2339.26.8 Pending Update Records ............................................. 2349.26.9 Address Conversion .................................................... 2349.26.10 Overlap in Address Number Range .............................. 2349.26.11 Number of Objects for Modification Adjustment ......... 235

9.27 Repeating PREPARE ................................................................ 2359.28 After the End of PREPARE ....................................................... 236

9.28.1 Post-PREPARE Activities ............................................. 2369.28.2 Back Up Database and Upgrade Directory ................... 2369.28.3 Clean Up Database Archives ........................................ 236

9.29 SAP Start and Stop Scripts (UNIX) ............................................ 2379.30 Resetting PREPARE .................................................................. 237

10 The Upgrade Process for SAP ECC ....................................... 239

10.1 Uptime or Downtime? ............................................................. 23910.2 Starting SAPup Without an Error-Free PREPARE ...................... 24010.3 Upgrade Assistant (UA) ............................................................ 24010.4 Starting the Upgrade ............................................................... 24110.5 Interaction Until Start of Import .............................................. 24110.6 Data Import ............................................................................. 24710.7 The Shadow Instance ............................................................... 247

10.7.1 First Start (Phase START_SHDI_FIRST) ......................... 24710.7.2 Manually Starting and Stopping the Shadow

Instance ...................................................................... 24810.7.3 Service for Shadow Instance on Windows ................... 248

10.8 Stop for Modification Adjustment ........................................... 24810.9 The Activation Phase ............................................................... 250


Contents

13

10.10 Handling Activation Errors ....................................................... 25210.10.1 Open the System and Call Transaction SE11 ................ 25210.10.2 Identifying the Problem .............................................. 25310.10.3 Field Defined Twice .................................................... 25310.10.4 Identical Indexes ......................................................... 25410.10.5 Object Incorrect in Source Release .............................. 25410.10.6 References to an Object Deleted in the Upgrade ......... 25410.10.7 Objects Listed in SAP Notes ........................................ 255

10.11 Repeat the Activation .............................................................. 25510.12 Shadow Instance Stopped ........................................................ 25510.13 Incremental Conversion (ICNV) ................................................ 25610.14 Import Language Data and Support Packages ......................... 26310.15 Upgrade Waits for the J2EE Upgrade ....................................... 26410.16 Upgrade Reaches Downtime Point .......................................... 26410.17 Isolating the Central Instance .................................................. 265

10.17.1 Final Checks ................................................................ 26510.17.2 Lock the Users ............................................................ 26510.17.3 Disable Background Jobs (Release 3.1I – 4.0B) ............ 26610.17.4 Operation Modes ........................................................ 26610.17.5 Back Up Database, Upgrade Directory, and

Source Kernel ............................................................. 26710.17.6 Open Client 000 for Development .............................. 26710.17.7 Other Activities ........................................................... 267

10.18 Entering Downtime ................................................................. 26810.19 Logging on to SAP During Downtime ...................................... 26910.20 Unlock the System to Correct Errors ........................................ 26910.21 User Interaction and Monitoring During Downtime ................. 27010.22 The Switch Phases: EU_SWITCH and KX_SWITCH_1 ................ 27010.23 Table-Conversion Phase: PARCONV_UPG ................................ 27010.24 Import Control Data: TABIM_UPG ........................................... 27010.25 Conversion Programs: XPRAS_UPG .......................................... 271

10.25.1 XPRAs: Purpose and Behavior ..................................... 27110.25.2 Dealing with XPRA Errors ............................................ 27110.25.3 Action After an Error ................................................... 27210.25.4 Postponing an XPRA ................................................... 272

10.26 The Kernel Switch KX_SWITCH_2 ............................................ 27310.27 The Final Phases ...................................................................... 27310.28 Upgrade Information Files ....................................................... 27810.29 Closing the Upgrade Assistant ................................................. 279

10.29.1 Resetting the Upgrade ................................................ 279


Contents

14

11 Upgrade Postprocessing for SAP ECC .................................. 281

11.1 Actions at Operating System Level ........................................... 28111.1.1 The saproot.sh Script (UNIX) ....................................... 28211.1.2 Upgrade the Kernel on the Application Servers ........... 282

11.2 Actions at Database Level ........................................................ 28211.2.1 Back Up the Database ................................................. 28211.2.2 Update Statistics ......................................................... 28311.2.3 Parameter Changes ..................................................... 28311.2.4 Dropping the Old Repository ...................................... 283

11.3 Activities in the SAP System .................................................... 28311.3.1 Parameter Changes ..................................................... 28411.3.2 ABAP Load Generation (SGEN) ................................... 28411.3.3 Configure the Transport Management System (TMS) ... 28511.3.4 Nonfatal (Type P) Upgrade Errors ................................ 28611.3.5 Glossary and Terminology Data ................................... 28611.3.6 Language Supplementation ......................................... 28711.3.7 Reschedule Background Jobs ....................................... 28911.3.8 Import the Transport Queue ....................................... 29011.3.9 Cleanup ...................................................................... 29011.3.10 Migration of Workload Statistics Data to

SAP NetWeaver 2004s ................................................ 29011.3.11 Additional Postprocessing Steps .................................. 291

11.4 Save the Upgrade Logs ............................................................ 291

12 Prepare the Upgrade for the AS Java ................................... 293

12.1 Activities in the SAP System .................................................... 29312.1.1 Checking the Java Development Kit Version ................ 29312.1.2 Checking the Memory and JVM Settings ..................... 29412.1.3 Checking the Software Deployment Manager

Version ....................................................................... 29512.1.4 Undeploying the Software Component

NWMADMIN ............................................................. 29612.1.5 Additional Preparation Steps ....................................... 296

12.2 Ready to Go! ........................................................................... 296

13 The PREPARE Process for the AS Java ................................. 297

13.1 Functions of PREPARE ............................................................. 29713.2 Modification Adjustment ......................................................... 29813.3 Upgrade in a NWDI Landscape ................................................ 299


Contents

15

13.4 Starting PREPARE for the First Time ......................................... 30013.5 Starting the SDTGui ................................................................. 30113.6 Start PREPARE ......................................................................... 302

13.6.1 Logfiles ....................................................................... 30413.6.2 Trouble Tickets ........................................................... 30413.6.3 Trace Files ................................................................... 305

13.7 PREPARE Modules: Initialization and Extraction ...................... 30513.8 PREPARE Module: Configuration ............................................. 31113.9 PREPARE Modules: General Checks and Finalization ................ 314

14 The Upgrade Process for the AS Java ................................... 317

14.1 Starting the Upgrade ............................................................... 31714.2 UPGRADE Phases: DEPLOY_<name> ....................................... 319

14.2.1 Error Handling ............................................................ 31914.2.2 Starting and Stopping the J2EE Engine Manually ......... 321

14.3 Upgrade Phase: DOWNTIME_END .......................................... 322

15 Upgrade Postprocessing for the AS Java ............................. 325

15.1 The saproot.sh Script (UNIX) ................................................... 32515.2 Upgrading the Dialog Instances ............................................... 32515.3 Changing Passwords ................................................................ 32615.4 Updating the SLD Content ....................................................... 32615.5 Additional Postprocessing Steps .............................................. 328

16 Upgrade of SAP NetWeaver Business Intelligence ............. 329

16.1 BW-Specific Tasks .................................................................... 33016.1.1 Checking Number Ranges ........................................... 33016.1.2 Checking the Logical System ....................................... 33116.1.3 Checking the Consistency of the Web Templates ......... 33116.1.4 Checking Inconsistent InfoObjects .............................. 33116.1.5 Converting Data Classes of InfoCubes ......................... 33316.1.6 Converting Inconsistent Characteristics Values/

Alpha Conversion ........................................................ 33516.1.7 Migrating InfoPackage Groups to Process Chains ........ 33816.1.8 Changing Read Modes ................................................ 33816.1.9 Connections to the Backend Systems .......................... 339

16.2 The PREPARE and Upgrade Process for SAP BW ...................... 33916.2.1 During PREPARE ......................................................... 33916.2.2 During the Upgrade .................................................... 342


Contents

16

16.3 Upgrade Postprocessing for SAP BW ........................................ 34416.3.1 BW Post-processing Actions ........................................ 34416.3.2 Installing the Java Components ................................... 345

17 Upgrade of SAP SCM ........................................................... 347

17.1 Upgrading SCM APO ............................................................... 34717.1.1 Components of APO ................................................... 34817.1.2 Upgrade of liveCache and Optimizer ........................... 34817.1.3 Integration with R/3 .................................................... 34917.1.4 Functional Aspects During the Technical Upgrade ....... 349

17.2 Preparatory Actions ................................................................. 35017.2.1 Additional Documents and Notes ............................... 35017.2.2 Additional Upgrade Media .......................................... 35017.2.3 SAP Plug-In (PI) Version in R/3 Backend Systems ........ 35117.2.4 liveCache No Longer Supported on 32-Bit .................. 35117.2.5 Support Package Stacks ............................................... 35217.2.6 BW-Specific Preparations ............................................ 35417.2.7 SCM-Specific Preparations .......................................... 35417.2.8 Other Preparations ...................................................... 354

17.3 Program /SAPAPO/OM_LC_UPGRADE_50 ............................... 35417.3.1 Program sections ......................................................... 35517.3.2 Corrections ................................................................. 356

17.4 PREPARE and Uptime Part of Upgrade ..................................... 35717.4.1 /SAPAPO/OM_LC_UPGRADE_50 — Section A ............ 35717.4.2 Resume PREPARE ....................................................... 363

17.5 Actions Between PREPARE and the Start of the Upgrade ......... 36317.6 Uptime Part of Upgrade ........................................................... 36417.7 Downtime Part of Upgrade ...................................................... 364

17.7.1 Enter Downtime ......................................................... 36417.7.2 /SAPAPO/OM_LC_UPGRADE_50 — Section B ............ 36517.7.3 liveCache Upgrade ...................................................... 36817.7.4 Optimizer Upgrade ..................................................... 37417.7.5 /SAPAPO/OM_LC_UPGRADE_50 — Section C ............ 37617.7.6 liveCache/LCA Build Checks (C11) ............................... 382

17.8 Postprocessing Activities for SCM ............................................ 38317.8.1 Review and Adapt Macro Books .................................. 38417.8.2 liveCache Connection "LEA" ....................................... 38417.8.3 SCM-Related Activities from the Upgrade Guide ......... 38517.8.4 Prepare for Return to Production ................................ 38517.8.5 /SAPAPO/OM_LC_UPGRADE_50 — Section D ............ 385


Contents

17

18 Upgrade of SAP CRM and SRM ........................................... 387

19 Unicode and the Combined Upgrade and Unicode Conversion ............................................................................ 389

19.1 The Case for Unicode ............................................................... 39119.2 SAP and Multilanguage Support .............................................. 39519.3 SAP and Unicode ..................................................................... 396

19.3.1 Impact of Unicode on SAP Systems ............................. 39719.3.2 Upgrading Single Codepage Systems ........................... 39919.3.3 Upgrading MDMP Systems ......................................... 39919.3.4 Hardware Capacity ...................................................... 40019.3.5 Documentation Sources .............................................. 401

19.4 Combined Upgrade and Unicode Conversion (CU&UC): The Procedure ......................................................................... 40319.4.1 Supported Source Versions ......................................... 40319.4.2 Supported Codepage Configurations in the Source

System ........................................................................ 40419.4.3 Restrictions for Unicode Conversion ............................ 40419.4.4 Source Database Informix ........................................... 40419.4.5 Steps in a CU&UC Project ........................................... 40519.4.6 Planning Aspects ......................................................... 406

20 Combined Upgrade and Unicode Conversion (CU&UC) in Detail .................................................................................... 411

20.1 UCCHECK and ABAP Preparation ............................................ 41220.1.1 Determine the Programs to Check ............................... 41220.1.2 Object Types Checked ................................................. 41220.1.3 Using UCCHECK .......................................................... 41320.1.4 Making Programs Unicode-Compatible ....................... 419

20.2 PREPARE ................................................................................. 42020.2.1 Activities in PREPARE ................................................. 420

20.3 Preconversion Data Analysis with SPUMG/SPUM4 .................. 42220.3.1 Procedure Steps .......................................................... 42320.3.2 Preparations ................................................................ 42420.3.3 Initialization and Language List Configuration ............. 43320.3.4 Configure Settings ....................................................... 43320.3.5 Initialize the Work List ................................................ 43620.3.6 Table Scans ................................................................. 43620.3.7 Consistency Check (Scan 1) ......................................... 440


Contents

18

20.3.8 Tables Without Language Information (Scan 2) ........... 44120.3.9 Tables with Ambiguous Language Information

(Scan 3) ....................................................................... 44120.3.10 INDX Analysis (Scan 4) ................................................ 44220.3.11 Process Vocabulary ..................................................... 44220.3.12 Reprocess Scan (Scan 6) .............................................. 45220.3.13 INDX Repair Scan (Scan 7) .......................................... 453

20.4 Upgrade in the CU&UC Scenario .............................................. 45420.4.1 Preconversion Complete ............................................. 45420.4.2 Process New Tables ..................................................... 45520.4.3 Upgrade Activities ....................................................... 45620.4.4 Actions Between End of Upgrade and Unicode

Conversion .................................................................. 45620.5 The Unicode Conversion .......................................................... 458

20.5.1 Tools for System Copy, Migration, and Unicode Conversion .................................................................. 459

20.5.2 The Migration Monitor ............................................... 47420.5.3 Database Export .......................................................... 48120.5.4 Uninstall the Non-Unicode System (In-Place

Conversion) ................................................................. 49320.5.5 Central System Installation and Data Load .................. 49320.5.6 Database-Specific Aspects — Oracle ........................... 50020.5.7 Database-Specific Aspects — SQL Server ..................... 503

20.6 CU&UC Postprocessing ............................................................ 50420.6.1 Actions on OS Level .................................................... 50520.6.2 Actions on Database Level — Oracle ........................... 50520.6.3 Actions on Database Level — SQL Server .................... 50720.6.4 General Actions in SAP ............................................... 51020.6.5 Unicode Activities ....................................................... 512

20.7 Twin Upgrade & Unicode Conversion (TU&UC) ........................ 52220.7.1 Information and Support ............................................. 52220.7.2 TU&UC Phases ............................................................ 52320.7.3 The Twin Preparation Run ........................................... 52420.7.4 Production Run ........................................................... 525

21 Modification Adjustment ..................................................... 527

21.1 The Modification Browser SPDD .............................................. 52921.2 SPDD Object List ..................................................................... 53121.3 Adjusting Objects .................................................................... 532


Contents

19

21.4 Table and Structure Fields ....................................................... 53321.4.1 New Fields Added in Standard .................................... 53321.4.2 Proposals for Different Data Elements ......................... 535

21.5 Technical Settings for Tables .................................................... 53621.6 Other Objects .......................................................................... 53721.7 Returning an Object to the SAP Standard ................................ 53821.8 Keep the Transport for the Upgrade of the Next System .......... 53921.9 Documenting Your Modifications ............................................ 54021.10 Modification Adjustment with SPAU ....................................... 541

22 Resetting the Upgrade ......................................................... 543

22.1 Reset During PREPARE ............................................................ 54422.2 Reset SAPup Before MODPROF_TRANS .................................. 54422.3 Reset SAPup After MODPROF_TRANS .................................... 545

A Vocabulary Hints .................................................................. 547

A.1 Example 1: Field in the Same Table .......................................... 547A.1.1 Case Study .................................................................. 547A.1.2 Creating the Conditions .............................................. 548A.1.3 Creating the Wordlist .................................................. 549A.1.4 Creating the Hints ....................................................... 550A.1.5 Effect of the Hint ........................................................ 551A.1.6 Testing the Hint .......................................................... 551A.1.7 Executing the Hint ...................................................... 552A.1.8 Executing Hints in Parallel ........................................... 552A.1.9 Reusing the Hint ......................................................... 553

A.2 Example 2: Fields from a Different Table .................................. 554A.2.1 Creating the View ....................................................... 554A.2.2 Create Conditions, Wordlists, and Hints ...................... 555A.2.3 Test and Execute the Hint ........................................... 557A.2.4 Extra Index for Hint Performance ................................ 557

B SAP Releases and Upgrade Paths ........................................ 559

B.1 SAP NetWeaver and Basis Releases .......................................... 559B.2 R/3 Releases ............................................................................ 561

C Database Transaction Log Modes ........................................ 563


Contents

20

D Codepages ............................................................................ 565

E SAP Notes ............................................................................ 567

E.1 Upgrade Notes ........................................................................ 567E.2 Unicode Conversions ............................................................... 568E.3 System Copies and Migrations ................................................. 569

F References ............................................................................ 571

G The Authors .......................................................................... 573

Index ......................................................................................................... 575


149

In the previous chapter, you learned about the organizational measures, system checks, research, and other actions that are necessary to prepare for the technical upgrade. Now the time has come to actually start the upgrade. This chapter will explain which upgrade tools exist, how they work, and how you use them to control and monitor the upgrade.

7 A Guided Tour of the Upgrade Tools

The purpose of this chapter is to introduce you to the SAP upgrade tools. You willlearn how they work, where to find them, how to install them and get themgoing, and how to use their management and monitoring features so that youstay in control of the upgrade and know at all times what is happening.

The information presented in this chapter lays the common foundation for eve-rything that is to follow. By “common,” we mean those functions, mostly in thearea of monitoring and managing the upgrade, that you can use in any upgradescenario regardless of the component and release you are upgrading. Viewing theupgrade logs, changing the passwords of upgrade users, or asking the upgradeprocess to trigger an alert when it stops are useful functions in every upgrade.

When we describe the upgrade procedure for various components in the comingchapters, features of the upgrade tools will be shown as and when they areneeded. However, those chapters concentrate on the task at hand rather than onthe mechanics of the tools themselves. When dealing with a complex processsuch as an SAP upgrade — especially when things go awry — knowledge ispower. That knowledge begins with becoming familiar with the upgrade pro-grams and user interfaces. Being comfortable with these will greatly improveyour effectiveness; you will do the right thing at the right moment, and you willbe able to correctly identify and solve problems if and when they arise.

Compared with earlier versions, the current generation of SAP upgrade tools iseither brand-new or at least comes equipped with a new look and feel. However,the tools are built upon operational concepts and methods of user interactionthat have been around since early versions of SAP R/3 and have had plenty oftime to stabilize and mature. The tools have been thoroughly tested and tweaked,and when the going gets tough, they will serve you reliably. They won’t tie them-selves into knots, spew gibberish at you (or go incommunicado), or vanish intothin air altogether.


A Guided Tour of the Upgrade Tools7

150

7.1 Introducing the Tools

Since Basis release 6.20, SAP delivers and supports both the SAP NetWeaverApplication Server ABAP and the SAP NetWeaver Application Server Java.

Whichever component you upgrade, if it is based on the SAP NetWeaver 2004splatform, you will always use the same upgrade programs:

� SAPup for the upgrade of ABAP

� SAPJup for the upgrade of Java

SAPup is the successor to the R3up program, which was used in all previous ver-sions of SAP. SAPJup is new because SAP NetWeaver 2004s with AS 7.00 is thefirst release that provides an upgrade procedure for the AS Java.

To control the upgrade process and to interface with the user running theupgrade, the ABAP and Java components also provide applications of their own:

� The Upgrade Assistant Server and Upgrade Assistant GUI for the ABAPupgrade

� The SDT Server and SDT GUI for the Java upgrade (SDT stands for SoftwareDelivery Tools)

If the system to be upgraded only runs one stack, then you only use the upgradetools for that stack. For a pure ABAP system, you use the ABAP tools SAPup andthe Upgrade Assistant. For a pure Java system, you use the Java tools SAPJup andthe SDT Server and GUI. With double-stack systems (ABAP + Java), you use thetwo combined.

7.1.1 Synchronized Upgrades

If the system runs both an ABAP and a Java stack, then you will need both sets ofupgrade tools. The tools are designed in such a way that each knows of theother’s existence; more than that, at several points during the upgrade, they willsynchronize their activity, allowing the other upgrade to catch up or waiting untilthe other side has completed a critical task. For example, just before the ABAPupgrade hits the point where it shuts down the SAP central instance, marking thebeginning of downtime, it will verify how far the concurrently running Javaupgrade has progressed. If SAPJup has not yet reached its beginning of down-time, then ABAP will wait. The inverse is also true.

By running in a synchronized manner, the ABAP and Java upgrades can be exe-cuted simultaneously without the risk of conflicts (e.g., one side stopping the SAPsystem at a time when the other side is working in it). There is one precondition,


Introducing the Tools 7.1

151

however, you must always start the ABAP upgrade (SAPup) first. The ABAP sidedetermines that the SAP system is double-stack and takes the necessary measuresto make sure that the ABAP and Java upgrades will be able to run together.

The requirement to start the ABAP upgrade first has little or no effect on theoverall time needed to upgrade the system. Unless it runs into some serious trou-ble, the runtime of the Java upgrade is much shorter than that of the ABAPupgrade. This is true both for the uptime part of the upgrade (especially if youartificially slow down the ABAP import phases) and for the downtime part(where the Java side mostly does software deployment, whereas the ABAP sidealso has to deal with things like table conversions and data conversion programs).

7.1.2 Upgrade Program and Control Program

The general architecture of the ABAP and Java upgrade tools is very similar. Bothare made up of the actual upgrade program (SAPup, SAPJup) and a control pro-gram (Upgrade Assistant, SDT). The upgrade program drives the actual upgradeactivities, such as data imports, structure conversions of objects in the database,Java deployment and ABAP transports, and so on. The control program does notdo any technical upgrade work. Its main responsibility is to handle communica-tion with the users (who are connected via their GUI) and to control and monitorthe upgrade processes. Via the control program, you will instruct the upgradeprogram to start (and sometimes to stop). If errors occur, you will be notified ofthese through the control program; after investigating and fixing the error, youwill, once more via the control program, order the upgrade process to retry thefailed step.

7.1.3 The Upgrade Programs: SAPup and SAPJup

SAPup (for ABAP) and SAPJup (for Java) are responsible for running the entireupgrade process from start to — hopefully successful — finish. However, they donot do any of the dirty work themselves; this they leave to the appropriate utility,such as tp (to import transport requests into the AS ABAP) or JSPM (Java SupportPackage Manager, to deploy software on the AS Java). The main task of theupgrade programs is to start these worker utilities when needed, to monitor themand examine their result, to interrupt or slow down the upgrade when needed, toobtain input and instructions (not directly but via the control program) from theuser who administers the upgrade, and to report the progress of the upgrade andalert the user in case of problems (again through the control program).

An upgrade is really a serial process made up of a long series of activity steps orphases. The total number of phases depends on the SAP release and the nature of



152

the upgraded component, but in an ABAP upgrade, there are well over 200phases and in a Java upgrade over 150. Each phase in the upgrade deals with onespecific task. What the phase has to do can range from the simple and almost triv-ial, such as checking or modifying a flag in a database table, to the very complexand elaborate, such as activating the new dictionary or deploying the new ver-sions of business applications. With such vast differences in the amount of worka phase must do, it is easy to understand that the runtime of the upgrade phaseswill also vary widely. Many phases will take just fractions of a second (whichdoes not make them any less important!), but others may run for several hours.One group of phases, the ABAP database import, can even be slowed done artifi-cially to minimize its impact on the server load (more on this later).

The fact that the upgrade process is serial in nature does not mean that it is alsosingle-threaded. Some heavy-duty phases, such as dictionary activation, table con-version, or the huge data imports and data conversion runs during downtime,use parallel processing to benefit as much as possible from the capacity of theserver and thus reduce the upgrade time.

7.1.4 PREPARE versus Upgrade

Both the ABAP and Java upgrade processes are divided into two major parts: oneis called PREPARE, and the other is the actual upgrade. Both the PREPARE andthe upgrade are subdivided into phases, as explained previously.

PREPARE

As you can guess from the name, PREPARE deals with all the preparatory activitiesin the system to be upgraded. The first thing PREPARE will do is prompt you forthe parameters of the upgrade, such as the location of the upgrade media, hostnames, passwords, and so on. These parameters will be used throughout theupgrade, and you will not have to enter them again (not that anything you enter isirreversible; you have the opportunity to change parameters later on if necessary).

After asking for the upgrade parameters, PREPARE copies data and programs intothe upgrade directory, imports the upgrade tools into the database, and installs theshadow instance (for ABAP). Add-ons, support packages, and languages are inte-grated into the upgrade. After the initial configuration of the upgrade, PREPAREverifies that the source system meets the requirements of the upgrade process andof the target release. This produces an action list, which must be taken care ofbefore the actual upgrade can start. If the first pass of PREPARE detects errors (i.e.,preconditions for the upgrade that are not met), then you must repeat the corre-sponding parts of PREPARE until no more problems are reported.



153

PREPARE is executed with the system up and running. End users are not affected.As explained elsewhere in this book, you normally run PREPARE several daysbefore the actual upgrade. Runtimes vary, but for a “typical” ABAP PREPARE,you should expect a runtime between four and eight hours, mostly depending onfactors such as the number of support packages to bind into the upgrade, thenumber of languages, and quite a few more.

Java PREPARE also runs during uptime. Like ABAP PREPARE, its first action is toprompt for the upgrade parameters. Its other tasks are also similar to those ofABAP PREPARE, but it normally has less work to do and therefore has a shorterruntime (typically between 1.5 and 3 hours, but again this is just an estimatebased on our own upgrade experience).

Upgrade (ABAP)

When PREPARE has done its work and is satisfied with the condition of the sys-tem, you can start the actual upgrade. Way back yonder, this was the momentwhen you asked users of the SAP system to kindly log off and find some otheroccupation for the next few days. Today, that will happen only if you unwiselydecided to run the upgrade in resource-minimized mode. You find more infor-mation about the downtime-minimized and resource-minimized upgrade modesin Chapter 4.

If you opted for the downtime-minimized method — as you ought to do — thenthe first (and longer) part of the upgrade happens while the SAP system is still innormal use. During this time, the upgrade performs all the necessary actions tobuild the shadow repository containing not only the new release but also a copyof all your own development. Early on in the process, the upgrade imports thedata from the Upgrade Export media into the database. Because of the perform-ance impact this data import may have and because of the number of databaselogs it will generate, you have the option of artificially slowing down the import.In this way, the upgrade takes as few resources as possible away from the produc-tion system. A slowed-down import also enables the backup procedures to keepup with the volume of database logs.

Not very long after the database import finishes, the upgrade starts up theshadow instance. After some preparatory work to make this instance fully usable,the upgrade will stop and ask you to carry out the dictionary modification adjust-ment using Transaction SPDD. When this is finished, the activation of the newdictionary begins (still in the shadow instance and shadow repository). After theactivation and some other phases, the upgrade shuts down the shadow instance,which will not be needed again. Next, the main upgrade transports and the



154

support packages that were bound into the upgrade are imported into theshadow repository. All the while, the main system remains productive.

Finally, with the shadow repository fully built up, the upgrade will inform youthat all its uptime processing is done, and that it now waits for your permissionto shut down the system and enter downtime. With correct planning and with-out accidents, this should happen some time before the start of the planneddowntime window. For instance, the upgrade might reach the downtime pointon Thursday afternoon while planned downtime begins at 7 p.m. Friday evening.In that case, you simply leave the upgrade waiting.

After the downtime window begins, you inform the upgrade via the upgrade GUIthat it may stop the SAP system. Between then and a time quite close to the endof the upgrade, the upgrade process takes full control of the system, stopping andstarting it as and when required. During this downtime phase, the system isplaced in “upgrade lock” mode, which means that you can only log on as SAP* orDDIC. Except for problem solving, there is normally no need to log on to the sys-tem (and you are bound to be kicked out without warning anyway when theupgrade reaches a phase in which it has to stop the SAP system).

Near the end of its run, the upgrade process unlocks the system, which by now isfully on the new version, and restarts it for the last time. The upgrade has only afew more phases to run (although some of these, e.g., the variant restore, can stillbe quite lengthy), but during this time, you can already log on to the system andstart on the postprocessing tasks. After some final interaction, the upgrade kindlyinforms you that the upgrade is complete (somewhat optimistically because thereis still a load of post-upgrade work waiting), produces a timing document and anevaluation form, and then stops.

Upgrade (Java)

The Java upgrade process (SAPJup) is on the whole a simpler affair than its ABAPcounterpart and is likely to take less time. By far the most important task for theJava upgrade is the deployment of the new release on the AS Java.

After you start SAPJup, the process will soon stop to announce the beginning ofdowntime. Once you confirm this, SAPJup takes control of the AS Java, stoppingand restarting it whenever necessary.

When it reaches the end of downtime, the upgrade will again stop, prompt youto back up the database and Java upgrade directory, and restart the AS Java. Afterproducing an evaluation form, the upgrade process ends.

The Java upgrade does not use a shadow instance.



155

Synchronized Upgrade (ABAP and Java)

With a double-stack system, you run two PREPAREs and also two upgrade pro-grams. The ABAP upgrade must always be started first, before the Java upgrade.Each side is aware of the other’s existence. During much of the time, the twoupgrades work independently, each on its own stack, but at some critical points,it is necessary that they synchronize with each other. For example, the ABAPupgrade will not enter downtime unless the Java upgrade is ready to do so aswell (and vice versa). The one who reaches the downtime point first will wait forthe other to catch up. Another example is that in a double-stack upgrade, theABAP side is responsible for installing the new kernel. If the Java upgradereaches the point where it needs the new kernel and sees that the ABAP side stillhas to carry out the kernel switch, it will wait for ABAP.

This superficial description of the double-stack upgrade process only serves as anintroduction. Chapters 8 to 15 describe a complete ABAP-cum-Java upgrade,including the two PREPARE processes.

7.1.5 The Control Programs: Upgrade Assistant and SDT Server/GUI

Both control programs are designed as two-tier client-server applications, with aserver program running on the upgrade (SAP central instance) host, and a GUIrunning on the user’s workstation.

Despite this similarity in design, the ABAP and Java upgrade control programsare not completely identical. Their look-and-feel is not quite the same, nor arethey used in exactly the same manner. In part, this goes back to their origins. Theancestor of the current ABAP upgrade tools was a program called R3up, whichback in the old days was used for upgrades to SAP R/3 releases 2.x and 3.x. Theold R3up was both upgrade and control program. It had no GUI client; you sim-ply started it from the OS command line and interacted with it via this same OSsession window. In a less than perfect world, this had obvious drawbacks: eventhe briefest network failure between server and PC could kill the active upgradeprocess, not to mention a hanging PC, a Windows error, or user mistakes such asa badly aimed mouse click or (Ctrl)+(C).

With the advent of release 4.0, SAP redesigned the upgrade program, separatingthe server activity (upgrading) from the user interaction (monitoring, parameterinput, starting and stopping). The former was still handled by R3up1, which hadnow become a strictly server-based program running in the background and thusinvulnerable to whatever went wrong at the frontend. The interaction and com-

1 The program continued to be called R3up until SAP NetWeaver 2004 (Basis release 6.40).With SAP NetWeaver 2004s/Basis 7.00, the name changed to SAPup.



156

munication part was confided to a new Upgrade Assistant (UA), which itself con-sisted of a server process running on the upgrade host — and like R3up shieldedagainst frontend trouble — and a GUI, which could be used to connect to and dis-connect from the upgrade at will.

SDT for Java is a very close relative of the installation utility SAPINST (the pictureof the cable-stayed bridge on the progress screen will be familiar to you if youhave ever done SAP installations for Basis 6.40 or higher). Like UA, SDT consistsof a server and a GUI client. However, as you’ll see next, its features are morelimited and it does not provide the same flexibility as UA for ABAP.

7.1.6 The ABAP Upgrade Assistant (UA)

Chances are that you will be doing far more ABAP upgrades than Java upgrades.Therefore, let’s look at the Upgrade Assistant (UA) for ABAP first.

UA is the “driver” program of the entire upgrade process. The UA itself does notdo any technical upgrade work. Its main responsibility is to handle communica-tion with the users (who are connected via their UA GUI) and to control andmonitor the upgrade processes.

The UA is designed as a two-tier client-server application with an Upgrade Assist-ant Server (UA Server) running on the upgrade host and one or more UA GUI ses-sions on users’ workstations.

An important characteristic of the ABAP UA (which it does not share with its Javacounterpart) is its capability to have multiple users logged on via GUI to the run-ning upgrade, and the distinction that it makes between two user roles: the“administrator” and the “observer.” We’ll discuss these upgrade roles first beforetaking a closer look at the UA Server and GUI.

Users: admin and observer

When you use the UA GUI for the ABAP PREPARE and upgrade, you must log onto the GUI as a valid user; this is one of the main differences between the ABAPUA and the Java SDT. UA knows two users: the Upgrade administrator (user ID:admin) and the Upgrade observer (user ID: observer).

Note

Even today, it is possible to run SAPup (the successor to R3up) in the so-called “scrollmode”, where you run it in an OS session window like a DOS shell for Windows or aTelnet session for UNIX and interact with it directly. This can help if for some reasonusing the UA GUI is impossible, but it should only be used as a last resort.



157

� The administrator has active control over the upgrade process. This user hasthe ability to start and stop upgrade processes and to interact with the upgradevia input screens in GUI.

� An observer has only a passive role. Observers can monitor the progress of theupgrade via GUI, but they cannot actively influence it. Their GUI screens arenot enabled for input.

At any time during the upgrade, at most one administrator session can be loggedon, but there can be any number of observers. While they are connected to UA,GUI users can dynamically change roles: administrators can demote themselvesto observers, and an observer can promote himself to administrator (therebyautomatically demoting the current administrator if one is logged on).

Administrators and observers are roles defined by the UA GUI. It is not necessaryfor an UA GUI to be active at any time; the upgrade can run nicely even withoutany user session connected. For instance, if a lengthy upgrade phase starts late inthe evening and is likely to run through the best part of the night, the adminis-trator and the present observers may decide to log off from their UA GUI and gohome. At that moment, there is neither an administrator nor an observer, butthat does not bother the running upgrade in any way. If the upgrade stops, forexample because of an error, then it will simply wait until an administratorcomes online and communicates with the upgrade via the error screen in the UAGUI. If the alert service is enabled (discussed later), then UA will also invoke thealert script so that someone is notified of the stop.

Both user roles are protected by a password. You set the administrator passwordthe first time you start the UA Server (discussed next). You do not create namedusers for UA; to log on with a certain role, you simply enter the password of thatrole. The logon screen of the UA GUI does give you the option to enter a name,but this is optional and purely informative; you may choose to enter your realname there or anything that helps others to identify you. You can also enter acontact telephone number on the logon screen.

The UA Server

The server side of UA is the Upgrade Assistant Server (UA Server). This processruns on the same host as the actual upgrade, that is, the host where the centralinstance of the SAP system resides. You do not interact directly with the UAServer except once: When you start the server for the first time, it will promptyou for the password of the administrator. After that, the server will never inter-act directly with you again, so you may then let it run as a background process(on OSs supporting this). You’ll see the commands to run the UA Server later in



158

this chapter. All further communication between the administrator and the UAServer are via the UA GUI.

The PREPARE and the ABAP upgrade program (SAPup) run under the control ofthe UA Server. The server will start these processes when instructed to do sofrom the administrator’s UA GUI session. From then on, it monitors the proc-esses, forwarding their console output to all open UA GUI windows. When anupgrade stops for interaction, either because it needs parameter input or becausean error has occurred, the server will handle the user interaction via the admin-istrator’s UA GUI session (if an administrator is currently logged on), and pass onthis input to the upgrade process.

The server is started from the OS command line. It is stopped from inside the UAGUI, or you can also terminate it at the OS level when it is no longer needed. Allthis will be covered in detail next.

The UA GUI

The client is the UA GUI. Client and server communicate with each other via aTCP/IP port (port 4241). On a second port (4239), the UA Server is capable ofreceiving HTTP requests, allowing it to interact with a browser running on auser’s PC. Access via a browser can be used to launch the UA GUI or to requestinformation related to the upgrade, such as the phase list or the evaluation form.We’ll take a closer look at the browser interface later.

Although the UA GUI runs on the user’s PC, it is not necessary to perform a sep-arate installation of the upgrade tools on the PC. The UA GUI (like the UA Server)is a Java application that is uploaded to the server during the initial run of thePREPARE script (described later in this chapter). Both the UA Server and UA GUIare Java applications residing in Java Archive (JAR) files. When the user starts theUA GUI from the browser, the Java code for the UA GUI is loaded onto the PCunder control of Java Web Start.

Java Web Start is a Java application used to deploy and run client-side Java appli-cations. The traditional method for client-side code is the use of applets, butapplets face two major limitations that make them very difficult to use in manyenvironments:

� Applets work under serious security restrictions; for example, they normallycannot access local files or external network addresses.

� Applets depend on the Java VM (virtual machine) built into the browser,which may cause version problems and incompatibilities.



159

Java Web Start deploys and starts applications to the client and is also capable ofuploading and installing the correct version of the Java Runtime Environment(JRE) at the same time.

Figure 7.1 shows a simple diagram of the architecture of the UA. Here an admin-istrator and several observers are logged on to the UA GUI; there are also activebrowser sessions communicating with the server via its HTTP interface.

7.1.7 SDT for Java

Like UA for ABAP, the upgrade tool for Java has a client-server design, consistingof the SDT Server and SDT GUI. SDT is the underlying framework that the Javaupgrade tool has in common with the SAP installation utility SAPINST. Beingbuilt on the same platform, SAPINST and the Java upgrade GUI have much thesame look and feel as we mentioned earlier.

Figure 7.1 Upgrade Assistant (UA)

UA Server

UAGUI

UAGUI

UAGUI

UAGUI

Browser

Port 4241 Port 4239

Upgrade (SAPup)

ObserverObserver ObserverAdministrator

Upgrade tools (tp, R3load, etc.)



160

The Java upgrade behaves in a way that is very similar to its ABAP counterpart.The server runs on the upgrade host and does not interact directly with the user.It controls the two major phases of the upgrade, the Java PREPARE and the Javaupgrade (SAPJup). The server also handles all communication between the userand the upgrade process. Messages from the upgrade process, including requestsfor user input and error reports, are sent on to the SDT GUI. User commands anduser input are transmitted from the GUI via the server to the upgrade process.

The SDT GUI is started in the same way as the UA GUI, namely from a browser.In the browser, you connect to the SDT Server via port 6239. The application isloaded from the server and started via the Java Web Start framework (see the ear-lier section The UA GUI). The SDT GUI communicates with the server via port6241.

Figure 7.2 shows the architecture of the Java upgrade.

The similarity with the ABAP upgrade is clear, but you may be struck by a majordifference too. In Figure 7.1, several users were connected to the ABAP upgradevia their UA GUI; only one of them, the administrator, could be in control, but

Figure 7.2 Java Upgrade

SDT Server

SDTGUI

Port 6241 Port 4239

Upgrade (SAPJup)

Upgrade tools (SDM, etc.)

Browser

Port 6239



161

there could be any number of observers simultaneously logged on. In Figure 7.2for Java, you only see one SDT GUI connected. This is because the Java upgradehas no notion of different users. It does not make a distinction between activeadministrators and passive observers, and only allows one user to be logged onto the SDT GUI at any one time. Any attempt to open a second SDT GUI on a run-ning Java upgrade will simply produce a rather terse error message (see Figure7.3) and leave you no other choice but to close this GUI.

7.1.8 Prerequisites for the Upgrade Tools

The upgrade tools for both ABAP and Java need a Java installation on the serverand on the workstation where you run the GUI.

Java SDK or JRE for ABAP Upgrade Assistant

The ABAP UA is a Java application, which means that a JVM must be installed onthe upgrade host (where the UA Server runs) and also on every workstationwhere you intend to run the UA GUI.

The Java requirement is strictest on the server side. The UA Server requires theJava Software Development Kit (SDK) version 1.4 or higher. An installation ofthe JRE is not sufficient.

The UA GUI is less demanding. Here the Java version must be 1.1 or higher, andboth the Java SDK and JRE will do.

Figure 7.3 Error When Starting a Second SDT GUI



162

To check the currently installed Java version, both on the server and on the GUIworkstations, open a command shell, log in as the SAP administrator (user<sid>adm), and type the command:

java –version

Figure 7.4 shows an example on a Windows PC.

This workstation runs a Java 1.5 version. For UA (Server or GUI), this is all right.For AS 7.0 Java, this would not be all right (only 1.4 supported).

Java SDK or JRE for SDT

SDT is also a Java application. Because SDT is used to upgrade AS Java systems, aJava SDK must obviously be installed on the server. As explained previously, ver-sion 1.4 SDK is required. At the time of writing, 1.5 SDK was not supported. 1.4SDK also meets the requirements for the Java upgrade tools on the server side.

On the client side, the workstation must meet the requirements of the SAPINSTtool, that is, a Java JRE must be present. We recommend that you use 1.4 JRE orSDK on the workstation like on the server, although 1.5 should also be okay.

7.2 Installation of the Upgrade Tools: ABAP

Making the upgrade tools ready for use is easy: all you need to do is run a scriptand, in the case of ABAP, replace the extracted version of the SAPup utility withthe latest patch.

Important

If the SAP system to be upgraded contains a Java stack, then the host must also meetthe requirements for AS Java. These will normally be stricter than those for the UAServer. With AS 7.0, the Java SDK version must be 1.4, not lower (1.3), nor higher (1.5).More precise restrictions, for example, a specific minimum version of the 1.4 Java SDK,may apply. Full details are in SAP Note 723909 and in a set of platform-dependentnotes, which are all listed in Note 723909. In practice, you should always use the latestavailable Java SDK within the range of supported versions (which is actually what Note723909 tells you to do).

Figure 7.4 Checking the Java Version


Installation of the Upgrade Tools: ABAP 7.2

163

7.2.1 Initial Run of PREPARE

The script for the initial extraction is located on the ABAP Upgrade Master DVD.This script is called PREPARE, which is a little confusing because the first majorphase of the upgrade is also called PREPARE. Keep in mind that the two are notrelated.

The following section describes how to use the PREPARE script on UNIX/Linuxand on Windows. For IBM iSeries, the procedure is different; refer to the sectionStarting PREPARE for the First Time in the Upgrade Guide for IBM iSeries for theexact commands.

7.2.2 Initial PREPARE Run: UNIX and Linux

In this example, we assume that you have placed disk copies of the upgrademedia in a server directory /sapcd. You have placed the ABAP Upgrade Master CDin a subdirectory named /sapcd/UPGMSTR_ABAP.

To run PREPARE initially, proceed as follows:

1. Log on as user <sid>adm.

2. Switch to the upgrade directory:

cd /usr/sap/put

3. Type the command:

/sapcd/UPGMSTR_ABAP/PREPARE

If the name of the ABAP upgrade directory is not /usr/sap/put, then you mustspecify the path via a command-line argument, for example:

/sapcd/UPGMSTR_ABAP/PREPARE upgdir=/usr/sap/putPRD

Keep in mind that to use an upgrade directory with a name different from thedefault, you must also adapt the SAP profile parameter DIR_PUT.

4. The PREPARE script creates the required subdirectories in the upgrade direc-tory, installs the initial set of upgrade tools (including the SAPup executable),and performs some basic tests, for example, checking the availability of theC++ runtime library.

5. Finally, PREPARE prompts you for an action:

Select operation mode:– "EXIT"– "SERVER"– "SCROLL"

Enter one of these options [EXIT] :=



164

Possible choices at this point are:

� EXIT

End the script. This is the default choice and also the one we recommendyou use.

� SERVER

This starts the UA Server. It is preferable to start the UA Server manuallylater.

� SCROLL

Starts SAPup in scroll mode (see Section 7.1.5). Except in very special cir-cumstances, you will never use this option.

7.2.3 Initial PREPARE run: Windows

The command file PREPARE.BAT does nothing other than invoke the JavaScriptfile PREPARE.JS. For this method to work, Windows Script Host (WSH) must beavailable. WSH is a facility that provides powerful scripting capabilities. WSH isinstalled by default, so normally it will always be available. However, it is possi-ble for system administrators to disable or uninstall WSH for security reasons(scripts have been abused as virus carriers). The WSH version on the SAP servermight also be too low. The SAP upgrade requires at least WSH version 5.6.

You don’t need to check anything related to WSH before starting the PREPAREscript. If WSH is missing or its version is too low, then PREPARE will report this.If you do want to check the WSH version upfront, then do the following:

1. Open a DOS shell (CMD).

2. Type the command

cscript

3. The output shows the version banner followed by the command-line options.

4. If necessary, you can download WSH free of charge from the Microsoft Down-load Center at http://www.microsoft.com/downloads.

5. To run the PREPARE script, you must log on as the <sid>adm user.

6. To start the script, open Explorer, and browse to the directory of the UpgradeMaster DVD (see Figure 7.5).

7. Start PREPARE.BAT.

8. A file selection box opens (see Figure 7.6). Browse to the ABAP upgrade direc-tory.

9. Click OK. After a few seconds, a DOS box opens prompting you for an action(see Figure 7.7).


Installation of the Upgrade Tools: ABAP 7.2

165

Figure 7.5 Select PREPARE.BAT in Windows Upgrade Master

Figure 7.6 Select Upgrade Directory



166

The available choices are the same as with UNIX: EXIT (the default), SERVER, andSCROLL. See Section 7.2.2 for a description of the choices.

7.2.4 Replace SAPup

The script has installed the SAPup executable (SAPUP.EXE in the case of Win-dows) in the subdirectory bin of your upgrade directory. Before starting theupgrade, you must now replace this version of SAPup with the latest patch,which you downloaded earlier from the SAP Service Marketplace. Instructionsfor identifying and downloading the required SAPup patch were given in Chap-ter 6.

Use the following instructions to install the SAPup patch after you have run theinitial PREPARE extraction script:

1. Open a command shell on the server and log on as <sid>adm.

2. Determine the current version of SAPup:

Unix/Linux

./SAPup –V

Windows

.\SAPup –V

This will also show the flavor. Example:

This is SAPup version 7.00/2, build 24.067

Figure 7.7 Action Prompt After Initial Extraction


Using the ABAP Upgrade Assistant 7.3

167

3. Optionally, save a copy of the current SAPup:

Unix/Linux:

cd /usr/sap/put/binmv SAPup SAPup.orig

Windows:

cd \usr\sap\put\binrename sapup.exe sapup_orig.exe

4. Extract the patch archive. The actual name changes with the patch level. <...>denotes the variable part of the name:

SAPCAR –xvf SAPup7002_<...>.SAR

5. Repeat the version check. The version will be higher, but the flavor must bethe same.

Unix/Linux:

./SAPup –V

Windows:

.\SAPup –V

7.3 Using the ABAP Upgrade Assistant

In this section you will learn how to start the ABAP UA and how to use the func-tions of the UA GUI.

7.3.1 Starting the UA Server

If possible, you should let the UA Server run as a background process to preventunwanted terminations, for example, because you accidentally close the windowit is running in, or because the network connection server and PC is interrupted.Windows does not give you this possibility, so you will have to run the UAServer in a DOS shell that normally remains open throughout the upgrade. OnUNIX/Linux, you can start the UA Server as a background process; there you can

Caution!

Exchange the version of SAPup only before you start the upgrade. Never change SAPupduring the upgrade unless SAP instructs you to do so!



168

also use the nohup2 facility to make sure the server process keeps running evenafter the session from where it was started logs off.

The very first time you run the UA Server, it will prompt you for the administra-tor password. User interaction is only possible with a process running in the fore-ground, so the first start of the server should always be in the foreground, evenon UNIX and Linux.

For the first run, follow these steps:

1. Open a command shell on the upgrade host (DOS box, Telnet session), and login as <sid>adm.

2. Type the command:

java -cp /usr/sap/put/ua/ua.jar UaServer

For Windows, use the same command with the slashes reversed.

The name of the Java class (UaServer) is case-sensitive, also on Windows.

3. The server prompts for the password of the administrator user. Enter and con-firm the password.

Please enter administrator passwordEnter password:*********Confirm password:*********

4. On Windows, you can leave this server process running. The following stepsare for UNIX/Linux only.

5. On UNIX/Linux, wait until you see the message

UaServer> Ready

6. At that point, terminate the running server with (Ctrl)+(C).

7. Restart the UA Server as a background and no-hangup process:

nohup java -cp /usr/sap/put/ua/ua.jar UaServer &

7.3.2 Starting the UA GUI

To start the UA GUI, you first connect to the UA Server using an Internetbrowser. The Java Web Start framework will then launch the GUI on your work-station.

2 nohup (no-hangup) is a feature of UNIX that allows you to start a background process insidea command session and keeps this process alive when your session ends (normal back-ground processes terminate along with the shell from where they were started). For exam-ple, to run a command comm. in this way, type “nohup comm. &” (the ampersand specifiesthat comm. must run in the background, and the nohup prefix ensures the command does notget terminated when the session ends).



169

Connect to UA Server via a Browser

1. To connect to the UA server, open a browser on your PC.

2. Type the URL http://<server>:4239 where <server> is the host name (or possi-bly the full domain name, depending on how networking is set up) of the hostwhere the UA Server is running. Example:

http://sapdev.mycomp.com:4239

If you decide to start the browser on the upgrade host itself rather than on alocal PC, you may also use the URL http://localhost:4239.

3. The main page of the ABAP UA now opens (see Figure 7.8).

4. If you do not see this window, check the following:

� Is the host name you specified correct and can it be resolved to an IPaddress from your PC? Use ping to check this.

� Is the UA Server running and ready to receive browser requests? Open thecommand window where you started the UA server and make sure theserver has displayed the messages:

UaServer> Starting HTTP serverUaServer> HTTP server startedUaServer> Ready

� If you started the server as a nohup background process (UNIX and Linux),then you might not see these messages in the command window. In that

Figure 7.8 ABAP UA Main Page



170

case, look at the standard output file (typically nohup.out in the directoryfrom where you started the server).

If the server encounters an error, it writes a Java stack trace and terminates. Thistrace can be quite long, but the first few messages will usually reveal what theproblem was.

In some cases, the port 4239, which is used for communication between thebrowser and the UA Server, may be unusable, for instance, because it is blockedby a firewall or because it is already in use by another application (which couldeven be another SAP upgrade running on the same host). In that case, ask the net-work administrator either to open the ports for the UA (if blocking by the fire-wall is the problem) or to determine alternative port numbers you can use. SeeSection 7.3.4 for information about the port numbers used by the UA.

Start the UA GUI

1. On the main upgrade page, click on Start Upgrade Assistant.

2. The Java Web Start window pops up, and the loading of the application begins(seee Figure 7.9).

Sometimes Java Web Start encounters an error while it loads the UA GUI tothe workstation; see the section Java Web Start errors while loading the UA GUI.

3. When the loading is complete, the logon screen of the UA GUI appears (seeFigure 7.10).

4. Log on as administrator. The user name and password fields are mandatory.What you enter for the user name is entirely up to you; anything that identifiesyou is acceptable. The UA GUI only demands that the user name be at least twocharacters long.

If you expect that several users will access the UA GUI during the upgrade,then it is convenient that you also specify your telephone number.

Figure 7.9 Java Web Start Loading the UA GUI



171

5. Click on Login.

6. On the next screen, you can choose functions from the menu. In the next sec-tion, we describe the available functions in more detail. These functions arecommon to all ABAP upgrades (the UA GUI menu is always the same regard-less of the product you are upgrading).

Java Web Start Errors While Loading the UA GUI

If Java Web Start is unable to upload and start the UA GUI to your workstation,an error Unable to launch Upgrade Assistant appears (see Figure 7.11). Clickon the Details button to see more information about the problem. The most use-ful information is probably in the upper parts of the Java stack trace, which youfind under the Exceptions tab.

Java stack traces are not gems of readability, but most of the time you will be ableto find at least one interesting term pointing to the cause of the error. In this caseUnknownHostException followed by a server name indicates that Java Web Startwas unable to resolve the host name of the server. In our experience, this is themost common problem you can encounter with the Java Web Start mechanism.The usual cause is that the host name of the SAP server is not known in the net-work configuration (DNS). Adding an entry in the local HOSTS file on the PCoften — but not always — helps; otherwise, you must report the problem to thenetwork administrator.

Figure 7.10 Logon Screen of UA GUI



172

7.3.3 Features of the UA GUI

Let’s begin with a brief tour of the menu functions, and then we’ll turn our atten-tion to the different services UA provides for controlling the upgrade and, when-ever necessary, changing its behavior.

The File menu:

� File � Change RoleSwitches the UA GUI session between administrator and observer roles. If youswitch from observer to administrator, the current administrator (if there isone) is automatically demoted to observer.

In Figure 7.12, user Mark changes his current role from administrator toobserver.

� File � List of usersLists all users currently logged on to UA. A pop-up window opens showing thename, telephone number, and current role of all connected users (seeFigure 7.13).

Figure 7.11 Java Web Start Error



173

� File � ExitEnds your UA GUI session. Leaving the UA GUI has no effect at all on the UAServer (and thus the upgrade), which simply continue running.

The Administrator menu:

� Administrator � Start PREPAREStarts SAPup in PREPARE mode.

� Administrator � Start SAPupStarts SAPup in upgrade mode. PREPARE must be complete for this.

� Administrator � Start SAPup with optionsStarts SAPup with a command option. You can run SAPup interactively to per-form some special operations. You can do this directly on the host (via thecommand line) or via the function Start SAPup with options inside the UAGUI. The default command option here is set stdpar, which is the option youneed if for some reason you want to change the upgrade parameters. See Sec-tion 7.3.4 for more information about SAPup command options.

Figure 7.12 Change Role in UA GUI

Figure 7.13 Users Logged on to UA



174

� Administrator � Stop SAPup after current phaseThis instructs a running SAPup process (in PREPARE or upgrade mode) to haltafter it finishes the current upgrade phase. This option is useful if for somereason you need to interrupt the upgrade, for example, to reboot the server, tochange database or SAP profile parameters, and so on.

� Administrator � Terminate SAPupTerminates a running SAPup process immediately. This is the emergencybrake, which you should only use in exceptional circumstances.

� Administrator � Connect UaServer to SAPupWith this function, which is rarely used, you can instruct a newly started UAServer to connect to an already running SAPup process. You could use this, forinstance, when the UA Server stopped abnormally and had to be restarted.The new UA Server would then connect to SAPup (which was not affected bythe abnormal stop of the server).

This is, to put it mildly, not the most reliable of UA features; in fact, our expe-rience is that this rarely — if ever — works. If you lose the UA Server whileSAPup is running, your best bet is probably to wait until a “natural” stop ofSAPup, for example, to request user input, and then stop and restart bothSAPup and the UA Server. In the meantime, you can monitor the upgrade viathe logs in the upgrade directory.

� Administrator � Disconnect UaServer from SAPupThis breaks the connection between the UA Server and SAPup. SAPup willcontinue until it needs to interact with the user and will then stop. We havenever used this function and, given the quirky behavior of its Connect coun-terpart, we’re not likely to try.

� Administrator � Set AlertUse this function to make the UA GUI invoke a script or command of yourchoice when it stops for interaction. This is a very useful feature if you want tolet the upgrade run unattended, but you want to be informed when your inter-vention is needed. The alert function is described in section The Alert Service.

� Administrator � Change PasswordsThis function lets you change the administrator and observer passwords. Ifyou forget the administrator password, then you need a special procedurebecause you cannot log on to the UA GUI; see Setting a New AdministratorPassword in Section 7.3.5 for the solution.

� Administrator � Terminate Upgrade Assistant ServerThis function stops the UA Server. It is a clean alternative to killing the serverfrom the OS.



175

The Services menu:

� Services � File ServiceLets you select and display files on the upgrade host. This is normally used todisplay upgrade logs. See the upcoming section The File Service for details

� Services � Upgrade MonitorBrings up a progress window showing the upgrade phases. See the upcomingsection The Upgrade Monitor.

� Services � Console WindowDisplays the main upgrade log. See the upcoming section The Console Service.

� Services � SAP Notes SearchOpens a browser session in the SAP Service Marketplace to search notes. Seethe upcoming section The Notes Service.

The Help menu:

� Help � IntroductionOpens a browser session with information about the upgrade tools. Interest-ing reading but unfortunately not always up to date. At the time of writing,the information provided here was for the upgrade tools of Basis 6.40 and notof Basis 7.00, which could be confusing.

� Help � AboutShows the version of the UA and the copyright notice.

The Alert Service

Unless you work in a round-the-clock team and an administrator is constantlywatching, chances are that the upgrade will at certain times run unattended.Although this may give you a welcome opportunity to get some sleep or to dosome other important task, you don’t want to come back to the upgrade to findout that it has stopped for user input or because of an error and has been in thatidle state for many hours. To prevent these nasty surprises and the resulting lossof time, you can instruct the UA Server to trigger an alert whenever it stops.When the alert goes off, the UA Server invokes a command of your choice. Thiscould be a shell script to send an email to the members of the technical upgradeteam or a script that sends an SMS (Short Message Service) message to yourmobile phone, for instance.



176

To enable alerts, do the following:

1. Choose Administrator � Set Alert in the UA GUI menu.

2. In Alert Command, type the full path name of the command or script youwant the UA Server to call.

3. In Alert Text File, you can specify the name of a file on the host where the UAServer will write the same information that it sent to the UA GUI when theupgrade stopped.

4. In Alert Delay, enter a delay the UA Server must observe between the momentthe upgrade stops and the moment the alert is triggered. The default is 500 sec-onds. You might want to reduce this somewhat, for example, to 2 or 3 min-utes, but do not set the delay to 0 because this will cause many unnecessaryalerts.

5. With the Set active flag, you can enable and disable the alert configuration atwill.

If alerts are active, then the following happens when the upgrade stops for userinteraction (this may be normal interaction, i.e., prompting for user input, or anerror stop):

1. The UA Server waits for the amount of time set in the Alert Delay.

2. If the user does not restart the upgrade before this delay expires, the UA Serverwrites the text of the upgrade message to the alert text file.

3. The UA Server then invokes the alert command.

In the example given in Figure 7.14, the UA Server is instructed to call a scriptupgrade_sms whenever the upgrade stops for more than 2 minutes. Judging bythe name, the script creates an SMS message, which it sends to some administra-tor’s cell phone. More sophisticated scripts are, of course, possible; you could,for instance, design a shell script that “noisily” alerts the administrator by send-ing a brief SMS and at the same time also sends an email with the contents of thealert text file.

Figure 7.14 Defining an Alert



177

Figure 7.15 shows an example of an alert text file. Here the upgrade stopped notbecause of an error but to notify the user that action is needed, which, in thiscase, is upgrading the liveCache during an APO (Advanced Planning and Optimi-zation) upgrade.

The File Service

The File Service in the UA GUI lets you select and display files on the upgradehost. A file selection window opens, showing the directory structure of the host.You can use this window to navigate through the directory tree. Alternatively, ifyou know the full path name of the file you want to display, you can type thisinto the File input field at the bottom (Figure 7.16, left). The file is displayeddirectly. Unfortunately, you can only enter file names and not directory namesinto this field.

If the directory contains files, the file chooser window lists them (Figure 7.16,right).

Double-clicking on a file opens a new window with the contents of that file (seeFigure 7.17). With long files, use the More and End of File buttons to navigate.

Figure 7.15 Alert Text File



178

The Upgrade Monitor

Via Services � Upgrade Monitor, you can see how far the upgrade has pro-gressed. Click on Close to leave the monitor screen and return to the main UAGUI window.

Figure 7.16 UA File Service — File Chooser

Figure 7.17 UA File Service — Display File



179

Figure 7.18 shows the Upgrade Monitor during the actual upgrade. Here theprogress screen shows all the upgrade phases.

During PREPARE, which is subdivided into modules, you only see the phases ofthe currently executing module. You see an example of this in Figure 7.19.

Figure 7.18 Upgrade Monitor in UA GUI

Figure 7.19 Upgrade Monitor During PREPARE



180

The Console Service

While the upgrade is running, the UA GUI window displays a progress screenthat contains messages for the beginning and end of each phase, other messagesshown to the user (e.g., to signal errors), and all interaction with the upgradeadministrator (prompts and replies). You can scroll back inside this window tosee all the messages and user input since the beginning of the upgrade.

Note

Older versions of the UA also showed an estimate for the remaining runtime, both forthe current phase and for the entire upgrade. In practice, so many factors affect theruntime that a sensible prediction is very difficult to make. Because the time estimateswere often wide off the mark, this feature was removed.

Figure 7.20 Console Service



181

When the upgrade stops to interact with the user, this progress screen is tempo-rarily replaced with an input window. If you want to look at the progress screenat this point, for example, because you want to check some input you entered inan earlier phase, then choose Services � Console window. The progress screenwill then reappear (see Figure 7.20).

Another advantage of the console window is that copying text is enabled here.This is useful if you want to copy/paste parts of the upgrade dialog into your doc-umentation.

Click on the Close button to return to the input screen.

The Notes Service

The Notes Service function starts a browser on your PC and brings up a page forsearching SAP Notes in the SAP Service Marketplace (see Figure 7.21). As you cansee, this is not the usual page for searching notes (http://service.sap.com/NOTES).

Providing the ability to search SAP Notes directly from the GUI is a nice idea, but,in practice, there is just one tiny problem: It doesn’t work. No matter what you

Note

The complete upgrade dialog is also saved in the logfile /usr/sap/put/log/UpgDialog.log.Always keep this file after an upgrade because it contains information that will be veryuseful for your next upgrades.

Figure 7.21 Notes Service



182

enter in the search fields, the search result is always “no notes found.” This is abit silly but can hardly be called a major irritant. Just open a separate browserand go to the normal notes search page.

7.3.4 SAPup Command Options

The principal function of SAPup is to run in the background and to control theABAP PREPARE and the ABAP upgrade. In addition, SAPup also offers a com-mand interface, which you can use to perform certain special operations.

You can invoke the command mode of SAPup in two ways:

� On the upgrade host via the command line

� From inside the UA GUI

To see the available functions and command options, type the following com-mand:

/usr/sap/put/bin/SAPup -h

SAPup will prompt you for the path to the upgrade directory (press Enter if thedefault path shown is correct).

Most of the functions are not intended for your direct use. They are either calledinternally during the upgrade process or needed only in exceptional circum-stances. The functions that you will need most often are the ones that allow youto change parameters of the upgrade and those that control the shadow instance.These and some other useful functions of SAPup are described next.

Specifying the Upgrade Directory

If you run SAPup from the command line, SAPup will prompt you for the path tothe upgrade directory. To avoid this extra prompt, use the upgdir option. Exam-ple:

SAPup -h upgdir=/usr/sap/put

Show SAPup Version

This command displays the version. Example:

> ./SAPup -V upgdir=/usr/sap/putThis is SAPup version 7.00/2, build 24.081



183

Start and Stop Shadow Instance

Use the startshd and stopshd functions to start and stop the shadow instance.This is normally not necessary because SAPup takes care of starting and stoppingthe shadow instance at the right moment. However, it is sometimes necessary todo a manual stop/start, for instance, if you have to change profile parameters ofthe shadow instance.

Commands:

SAPup [upgdir=<upgrade_dir>] startshdSAPup [upgdir=<upgrade_dir>] stopshd

Unlock and Lock the Shadow Instance

Like the main instance during downtime, the shadow instance normally runs inupgrade lock mode, meaning that logging on to the instance is only possible forthe users SAP* and DDIC, and that workbench objects cannot be changed. At thebeginning of the modification adjustment (Transaction SPDD), SAPup will unlockthe shadow instance automatically. When activation begins after you have fin-ished SPDD, SAPup also locks the shadow instance again.

If, however, as is often the case, the activation phase reports errors for some dic-tionary objects, then you must manually unlock the shadow instance to be able tolog on as a user with development authority and to modify objects in the ABAPworkbench. When you are finished with correcting the activation errors, lock theshadow instance manually before resuming the upgrade.

Commands:

SAPup [upgdir=<upgrade_dir>] unlockshdSAPup [upgdir=<upgrade_dir>] lockshd

Change Parameters of the Upgrade

Early on in the PREPARE process, you will be prompted for all the parametersthat the upgrade process needs, such as host names, locations of the upgrademedia, and so on. These parameters are then used throughout the entire upgrade,and normally you will not change them again. If you do need to change a param-eter later in the upgrade (for example, because you had to move the upgradeDVDs to a different disk or file system), then use the following function:

SAPup [upgdir=<upgrade_dir>] set stdpar



184

As always, you can execute this command from inside the UA GUI or directly viathe command line of the OS. In this case, calling the command in the UA GUI ismore convenient because you are presented with the same graphical input win-dows as during PREPARE.

Change Parameters of the Shadow Instance

PREPARE also prompts you for the shadow instance parameters (instancenumber, port numbers, etc.). Again, you can change these parameters later if nec-essary by using the function

SAPup [upgdir=<upgrade_dir>] set shdpar

Change Parameters for Upgrade Strategy and Parallel Processing

SAPup (not PREPARE) prompts you for the upgrade strategy you want to use(downtime-minimized or resource-minimized) as well as for some other parame-ters that affect the resource usage by the upgrade:

� Allotted time for the database import

� Upgrade phase from where database archiving is to be disabled

� Number of parallel batch processes

If you need to change these parameters, you can do so with the function

./SAPup upgdir=/usr/sap/put set rswpar

Change DDIC Password

During the initial parameter input, PREPARE prompts for the password of userDDIC in client 000. DDIC in 000 is used throughout the entire upgrade for allphases that need a connection to the SAP system. It is good practice to set theDDIC password at the beginning of the upgrade and leave it unchanged until theend, but this is not always possible. The password might expire during theupgrade, or you might need to change it for any other unexpected reason.

If you alter the DDIC password, then you must inform the upgrade process of thiswith following SAPup function:

./SAPup upgdir=/usr/sap/put set ddicpwd

Note that this command by itself does not change the password (you need Trans-action SU01 for that); it simply informs SAPup of the password change.



185

Change the DDIC Password in the Shadow Instance

In the shadow instance, which has its own user configuration, user DDIC in client000 is created with the same password as in the source system. If you change theDDIC password in the shadow instance for whatever reason, then you must againmake SAPup aware of this:

./SAPup upgdir=/usr/sap/put set shdddicpwd

(Be careful: It’s three d’s in a row!)

Resetting PREPARE

Situations may arise — hopefully not too often — in which you decide that youwant to abandon the active PREPARE altogether and start over. What could alsohappen is that you run PREPARE in a system but then decide not to upgrade thatsystem after all. Leaving traces of this unfinished business in the system is not agood idea because it would prevent upgrading the system in the future. To resetPREPARE and thus erase any trace of the attempted upgrade, use the command

./SAPup upgdir=/usr/sap/put reset prepare

At this point, we only mention the command because resetting PREPARE is cov-ered in Section 9.30.

Other Functions

SAPup -h will list numerous other functions than the ones described in the previ-ous paragraphs. You normally do not need these functions and unless SAPinstructs you to use one of them, it is best to keep to the straight and narrow.Don’t start experimenting with them in a live upgrade!

7.3.5 Tips and Tricks

We end this section with two useful tips:

� How to make the UA use different network ports

� How to change the administrator password



186

Change the Port Numbers for the Upgrade Assistant

The UA uses a total of four ports for all its communication. By default, these portsare 4238, 4239, 4240, and 4241. These numbers are defined in the configurationfile /usr/sap/put/ua/UaServer.properties:

UA_R3UP_PORT = 4240UA_GUI_PORT = 4241UA_MONITOR_PORT = 4238(...)UA_HTTP_PORT = 4239

The first three entries are grouped together near the beginning of the file. TheUA_HTTP_PORT entry can be found further down in the section for the HTTPserver settings.

Normally there is no reason to change the port numbers, but there are situationswhere this becomes necessary. One or more of the ports might be in use byanother application or access to these ports might be blocked by a firewall. If yourun several ABAP upgrades simultaneously on the same host, then you will haveto change the port numbers for all but one of these upgrades; otherwise, therespective UA Servers will attempt to open the same ports, which results in anerror stop.

Before you assign new port numbers, make sure that these new numbers will beusable:

� The ports must not be blocked by the firewall.

� They must not be used by other applications. To check whether a port is cur-rently in use, type the following command:

netstat -an | grep <portnr> (Unix/Linux)

netstat -an | findstr <portnr> (Windows)

In the following example, you want to use the port 4339, but this port turnsout to be in use. The entry *.4339 indicates that some local program is listen-ing on the port (see Figure 7.22). The other entries show the IP address andport of the host in the first column, and the IP address and connected port ofall the clients currently using this port.

Figure 7.22 Network Port in Use



187

You must also check whether the ports have not been assigned for use by otherapplications, even if those applications are not active at present. You do this bylooking for an entry with this port number in the services file on the host. Thename of this file is /etc/services (Unix/Linux) or C:\WINDOWS\SYSTEM32\DRIV-ERS\ETC\SERVICES (Windows).

The entry in the services file in Figure 7.23 indicates that port 4339 is destinedfor use by another (in this case non-SAP) application.

After choosing a new set of port numbers and ascertaining that these ports can beused for the UA, you can configure the new ports:

1. Stop the UA Server if it is still running

2. Make a backup of the current properties file, for example:

cd /usr/sap/put/uamv UaServer.properties UaServer.properties.default

3. Use a text editor to change the four port entries in the UaServer.properties file.Let’s suppose that you chose to use ports 8238 to 8241:

UA_R3UP_PORT = 8240UA_GUI_PORT = 8241UA_MONITOR_PORT = 8238(...)UA_HTTP_PORT = 8239

4. Restart the UA Server, and wait for the “Ready” message.

5. Call the main upgrade page, using the new port number 8239: http://host-name:8239.

6. Start the UA GUI, and specify the new port number on the logon screen.

Setting a New Administrator Password

As explained earlier, you specify the password for the administrator role in theUA when you first start the UA Server. If you intend to use the observer role,then you set its password in the UA GUI.

Note

Depending on the version of Windows, the top directory might be called WINDOWS orWINNT.

Figure 7.23 Port Reserved in Services File



188

To change the administrator and observer passwords, you also use the UA GUI,and you must obviously be logged on as administrator.

But what if you forgot the administrator password, and you do not have an openUA GUI administrator session? Stopping and restarting the UA Server won’t helpyou; the UA Server will not prompt for the password again. Looking up theanswer in the Upgrade Guides or in the SAP Notes won’t do you any good either;both are silent on the subject. Fortunately, the solution is not difficult:

1. If the UA Server is currently running, then terminate it with OS means, such asthe kill command in UNIX or the End Process function in the Windows TaskManager, at the first convenient moment (preferably not in the middle of acritical or long-running upgrade phase):

2. Remove the file /usr/sap/put/UaState.

3. Remove the file /usr/sap/put/ua/ks (the “keystore”).

4. Start the UA Server, which will now prompt for the administrator passwordlike it did the first time you ran it.

The UA Server prompts for the password if it does not find the file ua/UaState.If you only remove this file but leave the keystore untouched, then the nextstart of the UA Server will prompt for the password but will then abort withan exception stack trace that includes the message:

java.io.IOExceptionKeystore was tampered with, or password was incorrect

7.4 Installation of the Upgrade Tools: Java

Compared with the ABAP side, installing and operating the upgrade tools forJava is a pretty simple affair. This is not necessarily an advantage because theinterface for Java also offers fewer facilities than its ABAP counterpart, the UA.As we mentioned earlier, the Java SDT has no notion of different user roles(administrator/observer) and does not allow more than one GUI to be connectedat any one time. These are characteristics the upgrade GUI for Java shares with itsvery close relative, the SAPINST installation utility.

Note

Depending on the UA release, you might also need to delete the following files inthe ua subdirectory:

.sdt_storage

.sdt_keystore


Installation of the Upgrade Tools: Java 7.4

189

Before you start, you must have downloaded the Java fix buffer and extracted thefix to the Java upgrade directory, as described in Section 6.3.2. The next step is toextract the tools to the upgrade directory. Like on the ABAP side, this is donewith a script located on the Java Upgrade Master DVD (for UNIX/Linux and Win-dows; for IBM iSeries, see the instructions in the SAP Upgrade Guide for thatplatform).

7.4.1 Initial PREPARE Run: UNIX and Linux

In this example, we assume that you have placed disk copies of the upgrademedia in a server directory /sapmedia. You have placed the Java Upgrade MasterCD in a subdirectory named /sapmedia/UPGMSTR_JAVA. The Java Upgrade Mas-ter contains the installation script for the Java upgrade tools.

For the Java upgrade directory, we assume that you use the default path name/usr/sap/jupgrade.

Follow these steps:

1. Log on as user <sid>adm.

2. Switch to the upgrade directory:

cd /usr/sap/jupgrade

3. Type the command

/sapmedia/UPGMSTR_JAVA/JPREPARE

If the name of the Java upgrade directory is not /usr/sap/jupgrade, thenyou must specify the path via a command-line argument, for example:

/sapmedia/UPGMSTR_JAVA/JPREPARE /usr/sap/jupgPRD

Note that here you simply specify the directory path as the command argu-ment; you do not add the upgdir= keyword as with ABAP.

If the upgrade directory does not exist, then JPREPARE will create it.

4. If the fix buffer was already placed in the upgrade directory as described in theSection 6.6.4, subsection Download and install fix buffers, then JPREPARE willalso unpack the UPG file. This is a minor difference with ABAP, where thebuffer is extracted during PREPARE and not by the initial script. If JPREPAREcreates the upgrade directory, or the fix buffer is not yet present, then the PRE-PARE process will take care of the fix buffer later; appropriate screens willappear in the SDT GUI.

5. JPREPARE then unpacks the upgrade files to /usr/sap/jupgrade and finallydisplays the message:



190

Waiting for SDTServer to connect on hostname <host>/<address> socket6240 ...

6. At this point, you can start the GUI, but it is a good idea not to let the processrun in the foreground. To free up the terminal window and start a backgroundprocess, break with (Ctrl) + (C) and then restart as follows (as <sid>adm):

cd /usr/sap/jupgrade/exenohup ./PREPARE &

Note that now the name is just PREPARE, not JPREPARE.

7.4.2 Initial PREPARE Run: Windows

For the Windows example, we assume that the upgrade media are in the folderD:\SAPMEDIA, with the Upgrade Master in the subfolder UPGMSTR_JAVA.

1. Go to the Upgrade Master folder, and start the script PREPARE.BAT:

cd /D D:\SAPMEDIA\UPGMSTR_JAVAjprepare

This assumes that you use the default path for the Java upgrade directory. Thisdefault path is \usr\sap\jupgrade on the drive pointed at by the SAPLOC share.If you want to use a different path name and/or a different drive for theupgrade directory, then you must specify the path on the command line, forexample:

jprepare F:\sapadmin\jupgrade

2. If the upgrade directory does not exist, JPREPARE creates it. It then creates thesubfolders (see Figure 7.24) and unpacks the upgrade tools.

3. Finally, JPREPARE launches the PREPARE process. At this point, you will seethe following message:

call exe\jump -cddir=D:\sapmedia\UPGMSTR_JAVA\\JUP run prepareWaiting for SDTServer to connect on hostname <server>/<ip> socket 6240

4. If you already placed the fix buffer into the upgrade directory (see Section6.6.4, subsection Download and install fix buffers), then PREPARE will immedi-ately unpack the UPG file:

Unpacking fix archive ‘FIX_J_NW04SSR2.UPG’...

Caution

You cannot specify a path in UNC format (\\host\share\path).


Using the Java SDT GUI 7.5

191

5. If JPREPARE creates the upgrade directory, or the fix buffer is not yet present,then the PREPARE process will take care of the fix buffer later; appropriatescreens will appear in the SDT GUI.

6. Minimize but do not close the command window where PREPARE is waiting.You are now ready to start the GUI.

7. If you have to restart the PREPARE process later, then proceed as follows:

cd \usr\sap\jupgrade\exeprepare

There is no need to specify a path here even if you are not using the defaultpath name for the upgrade directory.

7.5 Using the Java SDT GUI

Starting the Java upgrade involves an Internet browser and the Java Web Start,but that is where the similarity with the ABAP UA ends. Let's see how it works.

7.5.1 Starting the SDT Server

You do not start the SDT Server explicitly. When you start the SDT GUI asdescribed next, the server process also starts and connects to the waiting PRE-PARE process. At this point, the command window of PREPARE displays a “con-nected” message:

Figure 7.24 Java Upgrade Directory After Initial JPREPARE Run



192

Waiting for SDTServer to connect on hostname <server>/<ip> socket 6240... connected.

7.5.2 Starting the SDT GUI

To start the SDT GUI, follow these steps:

1. Open a browser on your PC.

2. Type the URL http://<server>:6239 where <server> is the host name (or possi-bly the full domain name, depending on how networking is set up) of the hostwhere the UA Server is running. Example:

http://sapdev.mycomp.com:6239

3. If you decide to start the browser on the upgrade host itself rather than on alocal PC, you may also use the URL

http://localhost:6239

4. The main Java Upgrade page now opens (see Figure 7.25).

5. The Java Web Start window pops up, and the application begins to load (seeFigure 7.26).

Figure 7.25 Java Upgrade — Main Page



193

6. See Section 7.3.2, subsection Java Web Start Errors While Loading the UA GUI,if Java Web Start fails to load and start the application.

7. The Welcome screen of the SDT GUI appears (see Figure 7.27). Remember thatthe Java upgrade does not have the concept of administrator and observerusers, so there is no logon screen.

7.5.3 Features of the SDT GUI

As we did for the ABAP UA GUI, let’s again make a brief tour of the menu func-tions, of which there are only a few.

Figure 7.26 Java Web Start Loading the SDT GUI

Figure 7.27 SDT GUI Welcome Screen



194

The JUpgrade menu:

� JUpgrade � ExitEnds the SDT GUI session. Leaving the SDT GUI does not end the active PRE-PARE or upgrade process, so you can safely do this.

The Services menu:

� Services � File ServiceLets you select and display files on the upgrade host. This is normally used todisplay upgrade logs. This function is identical to the File Service in the UAGUI. See Section 7.3.3, subsection The File Service for a description.

� Services � Log ServiceThis service provides immediate access to the Java upgrade logs. The left panelists the existing log and error files in /usr/sap/jupgrade/log. By clicking on afile, its contents are displayed in the right-hand pane. Figure 7.28 shows thelog service for a normal text log, which is displayed in free-format fashion.

Many of the upgrade logs, including the main SAPJup.LOG, are displayed in amore structured, tabular form showing the severity, date and time, messagetext, and call location. You can use the arrows in the toolbar at the top of thescreen to move through the file. You can also filter messages by choosing theminimum severity level, as shown in Figure 7.29.

Figure 7.28 SDT GUI Log Service (Free-Format Display)



195

The Help menu:

� Help � AboutShows the version of the Java Upgrade GUI and the copyright notice.

7.5.4 Tips and Tricks

Like on the ABAP side (see the earlier Section 7.3.5), you can change the networkports used for the Java upgrade if necessary. The default ports used by the Javaupgrade are 6239 (for HTTP connections from the browser) and 6241 (for theSDT GUI). You find these port numbers in the file

/usr/sap/jupgrade/server/sdtserver.xml

Note that here we are not dealing with a simple text file but with an XML file. Toedit the file, you could use a specialized XML editor, but a standard text editorsuch as Notepad or vi will do just as well. Simply search for the strings “6239”and “6241”; each appears only once in the file, with the respective tags <HTTP-Port> and <GuiPort>.

The same warnings and restrictions apply as for the ABAP UA:

� Don’t change the port numbers unless you have to.

� Make sure the new port numbers are not already used by another application.

� Also make sure the server ports are accessible (not blocked by a firewall) fromthe workstation you intend to use during the upgrade.

See Section 7.3.5, subsection Change the Port Numbers for the Upgrade Assistant,for instructions on how to check these requirements.

Figure 7.29 SDT GUI Log Service (Structured Display)



196

7.6 Ready to Go

In the preceding chapters, you have learned how to make all the necessary prep-arations and set up the infrastructure to carry out the technical upgrade. You alsoknow which upgrade tools exist; how to start, stop, and control them; and howto monitor their activities. With this knowledge, you are now ready to attack theupgrade at hand.


575

Index

/SAPAPO/ADV_UPGRADE_50 354, 384/SAPAPO/MC01_3X_40 378/SAPAPO/OM_LC_UPGRADE_50 354

corrections 356section A 357section B 365section C 376section D 385

/SAPAPO/OM_TS_LCCONS 363/SAPAPO/OM_UPGR table 365/SAPAPO/OM13 360, 382/SAPAPO/OM17 358/SAPAPO/PPM_UTC_PREPARE_DATA02

362

A

ABAP 66Unicode compliance 51

ABAP Dictionary objects 72ABAP Load Generation 284ABAP preparation system 406ABAP upgrade 153

Synchronizing with Java upgrade 150ACT_700 248, 250

errors 252repeat 255

activation errors 252faulty objects 254field defined twice 253handling 252identical indexes 254objects delivered with errors 255reference to deleted object 254

activation phase 250add-ons 69, 72

Business Intelligence 340address conversion 234Advanced Planning and Optimization,

APO 559alpha conversion 335, 354append structure 253Application Server Java, start and stop

manually 321Application Specific Upgrade � ASU

archive logs (database) clean up 236archive mode 244archiving 76

Unicode conversion 428archiving mode (database) 76, 96, 563archiving strategy 76area menu 344ASCII 391ASU (Application Specific Upgrade) 62,

88, 229, 274authorizations 38AUTOEXTEND mode 232auto-repeat

ACT_700 251

B

background jobs, reschedule 289backup 282

database (at start of downtime) 267balloon 278BAPIs 50BASIS Plug-in 329Basis releases 559batch input 50, 61BC Sets 57BEx Web 344BI (Business Intelligence) 329

alpha conversion 354in APO systems 348Java components 345terminology changes 345Unicode post-processing 521

blended codepages 396brconnect 506BTCTRNS1 266BTCTRNS2 289Business Content 329Business Intelligence � BIBusiness Process Management 66

C

capacity planning 57CATT 45


576

Index

CBU 86CCMS 60CD/DVD mount points 217CESU-8 394Change Request Management 60charts (BW) 344CHECKS.LOG 231, 235, 292

Java upgrade 315CHECKS.SAV 292CIF (Core Interface) 349, 383Cluster tables, Unicode conversion 431CMD files 469codepage 391, 550, 565

charts 402COM routines � LCA (liveCache Applica-

tions)Combined Upgrade and Unicode Conver-

sion (CU&UC) 400downtime 410supported codepage configurations 404supported releases 403

compatibilityOS and DBMS 36SAP Plug-in 36

ConfigTool, upgrade errors 320configuration 288Content Server 370contingency development system 37contingency system 81, 85control data 270conversion programs � XPRAcorrection transports 210country add-ons, Unicode conversion

425Coverage Analyzer (SCOV) 419CRM 387CRM Mobile Clients 387CRM server 387customer developments 48customer fields 534Customer Relationship Management,

CRM 559Customer-Based Upgrade 86customizing 35

D

data element 535data import 247

Data Warehousing Workbench 345database

parameters 283statistics 283

database extensions 231DataStore object 345DB and OS Abstraction 66DB conversions 200DB02 59DB13 511dbmcli 373DBMGUI 369

parameters for LiveCache 373DBSIZE.XML file 482DBTABLOG table 515DDIC password, change during upgrade

184DDXT* tables in Unicode conversion

458delivery class 56delta display 537deployment

error for wrong J2EE state 321errors during upgrade 319long run times 321

development 35development class (for upgrade) 200development objects 527development system 81, 83dictionary objects, activation 527DIR_PUT 101, 123disk space requirements 118double-stack upgrade, synchronization

point 318DOWNLOAD function module 416downtime 95, 268downtime-minimized 30, 239

BW upgrades 343

E

EBCDIC 391eCATT 45Enterprise Core Component 561Enterprise Portal Plug-in 330ENVCHK 545EPS Inbox 144, 312EU_IMPORT1 74, 98, 247EU_SWITCH 270


577

Index

evaluation form 278exenew directory 217EXT files 464extended ABAP syntax check 416extended maintenance 28Extension Set 561extraction script 210

F

FINBASIS 330fix buffer 145, 211

Java 301frontend 36frontend software, upgrade 86

G

glossary 286GUI_DOWNLOAD function module 416GUI_GET_DESKTOP_INFO 37GUI_GET_FILE_INFO 37GUI_GET_REGVALUE 37GUI_UPLOAD function module 416

H

hardware capacity 36hierarchy versions (BW) 345hint definition 556Hint Management 548hints 448HKSCS (Hong Kong Supplementary

Character Set) 404HTTP 66HTTPS 66

I

IB_SYM_ID number range object 359ICM 66ICNV 31, 71, 256

procedure for conversion 260ICNVREQ 257ICNVREQ_GO 260IGS 141import queue 290import, slow down (SAPup) 243incremental conversion 201, 202, 209

Incremental Table Conversion � ICNVINDX repair scan 453INDX table 427, 442, 453, 519

codepage setting 435InfoCubes

activation before upgrade 332data classes 333for APO Time Series 360, 366, 382

InfoObjects 331, 335repair 341

InfoPackage groups 338Information Integration 65Informix 116, 404instance directory

space 120Internet Communication Manager 66Internet Pricing and Configurator 387isolate the central instance 265

J

J2EE Engine 66Java 66

sizing requirements 118Java JRE 161, 162Java SDK 161, 162, 293Java upgrade 154

Synchronizing with ABAP upgrade 150Java Upgrade Management Program 90Java Virtual Machine, memory 294Java Web Start 158

errors 171JCE (Java Cryptography Extension)

policy files 293JDK 161, 293JMT (Java Migration Tool) 317JOB_RASUVAR2 274JOB_UM4_COPY_RESULTS 456JPREPARE 189, 300

fix buffer extraction 189path to upgrade directory 125

JRE 161JSPM 121, 151JVM 294

K

kernel extraction 217kernel upgrade 282


578

Index

Knowledge Management 64, 65KX_SWITCH 545KX_SWITCH_1 270KX_SWITCH_2 273

L

LAN Check by Ping 59landscape set-up 81LANG fields 428language data import 263Language media, maximum path length

127language supplementation 287LC10 367, 377LCA (liveCache Applications) 352, 382LCUPDATE.BAT 372LCUPDATE.SH 371, 372LEA, liveCache connection 384liveCache 348

32-bit platforms 351patches 352upgrade 348, 368

lock 154LOCKEU_PRE 246locking development 246log 98log on during downtime 269logon user exit 37logs, upgrade 291LONGPOST.LOG file 275, 286

M

macro books (SCM) 354, 384maintenance 28Maintenance Optimizer � SAP Solution

Managermaintenance periods, SAP support sys-

tems 39Master Project Plan 39Max number of batch processes 244MaxDB 348, 370MCOD (Multiple Components One Data-

base) 77, 220and Unicode 404upgrade 78

MDMP 28, 38, 395and upgrade 399

MDSP 395media directory 126

space 119Microsoft Management Console � MMCMigration Monitor 474

common properties 478ddlMap file 479export 490export properties 475import 498import properties 476logs 480orderBy file 479restart package 481skip package 481split tables 479, 488

MMC (Microsoft Management Console) 308, 318

MNLS 395Mobile Infrastructure 64Mobile Sales 387Modification Adjustment 48, 73, 235,

276, 527adjusting objects 532documentation 540Java 298SPAU 541stop 248

Modification Browser 47, 527modifications 34modified SAP objects 47MODPROF_TRANS 74, 96, 97, 244,

264, 268, 279, 543reset SAPup after 545reset SAPup before 544

MODPROFP_UPG 273Multi-Channel Access 64Multiple Components in One Database �

MCODmySAP ERP 66, 560

N

nametablanguage fields 430tables 458

netstat command 186New Dimension 559


579

Index

NLS (Native Language Support), configu-ring 514

nohup (UNIX) for UA Server 168, 169notes 567

system copy and migration 569Unicode conversion 568upgrade 567

NPREPCRE0 544number ranges, BW 330NWDI (NetWeaver Development Infra-

structure) 298, 299NWMADMIN 296

O

obsolete transactions 52OCSCMPLOBJ table 427ODS (Operational Data Store) 363OMS (Object Management Store) 348OPEN DATASET, Unicode 399operation modes 266Optimizer (SCM) 348

different versions on same host 375patches 353upgrade 349, 374

OracleARCHIVELOG mode 506database layout 500parameters 506schema ID 501statistics 506truncate tables 505

P

P errors 275, 286PAM (Platform Availability Matrix) 115parallel activation 251parallel processing 219PARCONV_UPG 270passwords, Java administrator 326patch binding 222path names 218, 219People Integration 63phase list 211PI (SAP Plug-In) 36

version for SCM 5.0 351PI_BASIS (Basis Plug-In) 329, 351ping 169

Plug-in upgrade 339Portal Infrastructure 64postprocessing 30, 278, 281preparations 197PREPARE 30, 93, 205

add-on components 222address conversion 234address number range 234AS 7.00 90CHECKS.LOG file 231database extensions 231dictionary objects, deleted in target

release 233double-stacked system 220errors 240extract kernel 217for Java 153function of 152host names 218initial run 163initial run (Java) 300initial script 210language selection 221locked objects 233Modification Adjustment 226, 235modules 206modules (Java) 302parallel processing 219patch binding 224patch binding (Java) 299phase selection 215post-PREPARE activities 236repeating 235resetting 237, 544resetting (ABAP) 185result 230run time 214shadow instance 228synchronizing ABAP and Java 300target kernel version too low 232tool import 221update requests 234write access to kernel files 232

pre-upgrade phase 93print requests, Unicode conversion 427process chains 338Process Integration 65profile parameters for Unicode 505project plan 33, 39


580

Index

protect.lst file 246put directory � upgrade directory

Q

quality assurance system 81, 83Quick Sizer 58, 118

R

R/3 Enterprise 66, 560R/3 Enterprise Core 561R/3 releases 561R3check 431R3ldctl 459R3load 460

conversion logs 517split tables 484

R3szchk 459R3ta (table splitter) 485R3trans processes 219R3up 93, 150, 155R3up.log 292R3upchk.log 292RADNTLANG 431RAR files 136RASUVAR1 230, 274RASUVAR2 274RDDIMPDP 266Read Modes 338Release Information Note (RIN) 139release support 28REPACHK2 246repairs 200repository switch upgrade 70, 72REQSTOPPROD 74, 98reset PREPARE 544reset to original 534, 538reset upgrade 279, 543resource-minimized 30, 95, 239

BW upgrades 343RFC (Remote Function Call), Unicode

394RFC destinations 512RFC quota 284RFC server groups 284RIN 139RPR_ABAP_SOURCE_SCAN 50RRINCLTAB_REBUILD 345

RS_BW_POST_MIGRATION 522RSA1 338RSCHECKEX 201RSCPINST 514RSD1 331, 332, 341RSDG_CUBE_ACTIVATE 332RSDG_DATCLS_ASSIGN 335RSMD_CHECK 336RSMDCNVEXIT 336RSRT 339RSRV 330RSSPAM_PREPARE_UC 427RSSPAM17 427RSUPGRCHECK 333RSUPGRES 545RSUPGSUM 54, 257, 279RSVTPROT 515RSXPRAUP 273RUNTIMES file 279, 292RUTTTYPACT 513RZ03 289, 511RZ04 266, 511RZ10 284, 511RZ12 284

S

SAMT 49sandbox system 81

TMS configuration 82SAP Accelerated Value Assessment 103SAP Business Information Warehouse,

BW 559SAP Business Intelligence 65SAP End-User Delta Training 103SAP Enterprise Portal 64SAP ERP 560SAP ERP Upgrade Portal 39SAP Exchange Infrastructure 65SAP Functional Upgrade Service 59SAP GoingLive Functional Upgrade Check

102SAP GUI 36, 86

Unicode requirements 426SAP Master Data Management 65SAP Mobile Infrastructure 64SAP NetWeaver 63SAP NetWeaver 2004 559SAP NetWeaver 2004s 559


581

Index

SAP NetWeaver Collaboration 64SAP notes � notesSAP Office, Unicode conversion 425SAP Plug-in 36SAP R/3 66SAP R/3 Enterprise 66, 560SAP releases 559SAP Safeguarding for Upgrade 102SAP service (Windows) 248SAP Solution Manager 45, 60, 121, 197,

560Maintenance Optimizer 138, 143upgrade key 197, 220, 306

SAP Test Management Optimization 45SAP Upgrade Hosting 103SAP Upgrade Roadmap 39, 60, 61SAP Upgrade Weekend Support 103SAP Value Assessment 103SAP Web Application Server 63, 560SAP Web Application Server 7.00,

upgrade process 90SAP* (J2EE super-user) 307SAPCPE 282SAPINST 156

command line arguments 483database export 481dialog instance upgrade 326Java SDK 482master password 495Prerequisite Checker 495properties 483split packages 488Unicode conversion 459uninstall old system 493XML files 473

SAPJup 90, 298binding kernel and IGS update 312binding Support Packages 311deployment errors 319deployment phases 319DOWNTIME_END phase 322keyword 306logs 304SAP* user 307SCS instance for upgrade 306starting 317trace 305trouble ticket 304upgrade key 306

SAPJup (cont.)UPGRADE program 318

SAPJup.log 304saposcol 282, 325saproot.sh 282, 325SAPSetup 86SAPup 210

balloon 278batch processes 244command options 182database backup 267DDIC password change 184disable background jobs 266download latest version 147evaluation form 278final checks 265flavours 147help (-h) 185import 243, 247information files 278keywords for add-ons 242latest patch 166lock users 265lockshd 183log on during downtime 269monitor during downtime 270non-fatal (type P) errors 275, 286operation modes 266option unlockshd 183parameter changes 183replacing 210reset 544reset upgrade 279reset prepare 185set ddicpwd 184set rswpar 184set shddicpwd 185set shdpar 184set stdpar 183shadow import 263shadow instance 247shadow instance lock/unlock 183shadow instance start/stop 183slow down import 243starting 241startshd 183stopshd 183unlock system 269upgdir 123, 182


582

Index

SAPup (cont.)user interaction in downtime 270version 182

SCA files 298SCC4 267, 290, 331

in shadow instance 249SCMP 57SCOV (SAP Coverage Analyzer) 407, 419SCPR20 57scroll mode 156, 209SCS (Central Services) instance during

Java upgrade 306SCU0 57sdb user 370sdba group 370SDM (Software Deployment Manager)

deployment during upgrade 319update source version 295version for upgrade 295

sdm_jstartup.properties 294SDN (SAP Developer Network) 118SDT (Java upgrade tool) 156, 159

initial PREPARE run 189installation 188Java SDK/JRE 162JPREPARE 189port numbers (change) 195sdtserver.xml file 195start SDT GUI 192start SDT server 191use different upgrade directory 189

SDT GUI 160, 301Help menu 195JUpgrade menu 194Services menu 194

SE06 290, 511SE09 540SE11 533

in shadow instance 252SE16 49, 450SE63 425, 515SE95 47SE95_UTIL 539Secure Store 326SEM (Strategic Enterprise Management

329SEM-BW 330server names 218services file 187

SGEN 275, 284shadow import 263shadow instance 71, 72, 228, 247

manual start and stop 248shutdown 255unlock manually 250Windows 248

shadow repository 247SHADOW_IMPORT_ALL 263SICK 510SLD (System Landscape Directory) 326SLICENSE 511SLIN (extended ABAP syntax check) 416SM04 59SM13 200, 245SM36 511SM37, disable jobs 266SM50 269SM59 512SM63 266SMLT 286SMSY 197SMTP 66SOAP 66solution gap 27sorted/unsorted export 465SP21 511SPAD 511SPAM/SAINT, Support Packages 143SPAU 48, 199, 226, 235, 276, 527, 528,

541list reset objects 539undo reset to original 539

SPDD 48, 153, 226, 235, 248, 527, 529adjusting objects 532append structures 533data elements 535documenting changes 540domains 537field length change 535indexes 537list reset objects 539modification state 531object list 531proposal 534reset to original 534, 538table and structure fields 533transport request 539undo reset to original 539


583

Index

SPDD stop 248SPUM4 397, 422

corrections 424kernel version for 424

SPUMG 397, 422kernel version for 424

SPUMG/SPUM4ambiguous language list 433checkpoints 434collision resolution 435common character set 435consistency check 440fallback codepage 434invalid language list 433job names 438job scheduling 437language list 433manual assignment 450minimum word length 434monitor 438new tables 455R3trans language 435reprocess log 452reprocess scan 452result screen 438run time 408scan INDX tables 442scan tables with ambiguous language

information 441scan tables with language information

446scan tables without language information

441separator characters 435unsolvable entries 451vocabulary 442vocabulary (VOC) files 446vocabulary duplicates 445vocabulary hints 448vocabulary import 446vocabulary methods 447vocabulary patterns 449vocabulary statistics 446worklist 436

SQL Serverdata file layout 503instance configuration 507page verify 509statistics 509

SQL Server (cont.)transaction log 503truncate tables 507

SR 137SSM2 344ST02 59ST03 203, 291ST03N 59ST04 59ST06 59, 512STAD 59START_SHDI_FIRST 247startsap script 237status reporting 45STMS 199, 285stopsap script 237STR files 462structure fields in SPDD 533SU01 in shadow instance 249SUID bit 282, 325SUMG 397, 517

automatic completion 519INDX tables 519manual repair 520reprocess log 519

Support Package Stacks (SP Stacks) 70, 137, 139CSV file 143side effect report 143XML file 143

Support Packages 28, 69, 72import 263

Support Release (SR) 137switch phases 270SYNC time 219synchronization points 91, 92synchronized upgrade 89, 150, 155system landscape 37System Switch Upgrade 70, 72, 95, 256

T

TABIM_UPG 270Table Browser � SE16table conversion phase 270table fields in SPDD 533TADIR 49technical upgrade 30technical upgrade process 93


584

Index

terminology data 286terminology, changes for Business Intelli-

gence 345Test Management Optimization service

45testing 35, 42

issue lists 44scenarios 44strategy 43test cockpit 45tools 45

Text Language flag 428time schedule 99TLOCK table 521TMS (Transport Management System)

82, 83, 85, 199, 285import queue after upgrade 290

TOC files 472TOOLIMP4_UCMIG 421TOOLIMPD1 544tp 151TPL files 464transaction logging 96, 563Transaction SE06 253Transaction SE09 265Transaction SE12 253Transaction SE37 50Transaction SE38 50Transaction SM04 59Transaction SM13 200Transaction SM50 250, 263Transaction SPUM4 547Transaction SPUMG 547Transaction ST02 59Transaction ST04 59Translation systems

actions after Unicode conversion 515Unicode conversion 425

transport directory, space 120Transport Organizer � SE09transport queue, import 290transport requests 199transport route 82TREX 65, 387trouble ticket 304TSK files 470TU&UC 400

Twin Upgrade & Unicode Conversion (TU&UC) 400, 522codepages 523Production Run 525source release 523Twin Preparation Run 524

TWTOOL01 457type P errors 286

U

UA GUI 158Administrator menu 173Alert service 175Console service 180File menu 172File service 177Help menu 175Notes service 181Services menu 175Upgrade monitor 178

UCCHECK 51, 399, 406, 412in TU&UC 523selection screen 413

UCMIG_DECISION 420UCMIG_REQINC 421UCMIG_STATUS_CHK 454UM4_FINISH_PREPARATION 426, 457UM4TXFLAG 429UME (User Management Engine) 91,

307UMG_ACTIVATE_TWIN_MODE 524UMG_ADD_PREP_STEP 426, 457UMG_HISTORY 513UMG_POOL_TABLE 458, 513UMG_SCAN_STATISTICS 516, 517UMG_TWIN_CREATE_TRANSPORT 525UMGPCONV table 457UMGSETTINGS table 524umodauto.lst file 226Unicode 28, 38, 393

and Informix 116CESU-8 394compliance of ABAP code 51hardware requirements 400Informix 404UTF-16 394UTF-32 394UTF-8 394


585

Index

Unicode Conversion Guides 401Unicode Conversion Guide for Basis 7.00

401Unicode Conversion Tips & Tricks 401

Unicode flag 399Unicode pre-conversion analysis 547unrar 136unsorted export 465unzip 136update requests 200, 245UpgDialog.log 292upgrade

CRM 387development class 200downtime 268downtime before upgrade 101downtime point 264effort 46frontend 86functional effort 51landscape 80logs 291MCOD 78postprocessing 281preparation 197reasons for 27reset 279resetting 543runtime 54, 74schedule 99SRM 387success factors 34target release 30user 200

Upgrade Assistant (ABAP) 156, 208, 240administrator 156, 208browser session 169closing 279extraction script 210GUI installation 211Java SDK/JRE 161observer 156, 208password changes 187passwords for users 157port numbers (change) 186scroll mode 209start UA GUI as stand-alone program

214start UA GUI from browser 213

Upgrade Assistant (ABAP) (cont.)start UA server 212starting the GUI 168starting the server 167UA GUI 158, 208UA Server 157, 208uaserver.properties file 186

upgrade coach 102Upgrade Control Document 111upgrade directory 121

backup 267space 119

Upgrade Guide 106Business Suite 107Master Guide 108media list 109NetWeaver 106OS Dependencies (for UNIX) 107technical upgrade guide 108

upgrade information files 278upgrade key 121, 220, 306upgrade lock 154, 269upgrade media 129

liveCache upgrade (APO) 350mount points 217path for download 130

upgrade methodology 30upgrade notes

compare versions 110general (all platforms) 109platform specific 109

upgrade paths 559upgrade phase 94upgrade portal 39, 571upgrade process 239upgrade project 33

main phases 40team 41

upgrade roadmap 39, 60upgrade services 102upgrade strategy 74, 77UPLOAD function module 416uptime processes 219user exits 49User Management Engine � UMEUTF-16 394UTF-32 394UTF-8 394


586

Index

V

version management 537, 539delta display 537

virtual system 82, 84, 85virtualProviders 345VOC files 446vocabulary � SPUMG/SPUM4vocabulary hints 547

W

Web templates (BW) 331, 344wordlist 548Workload Statistics 203

reimport after upgrade 290RSMIGR12 203

WP-PI (Workplace Plug-in) 329, 330WS_DOWNLOAD function module 416WS_UPLOAD function module 416

X

XPRA 271errors 271postponing 272repair severe errors 272

XPRAS_UPG 271xserver 371, 372

Z

ZIP files 136
