Phases of Support Package Manager explained

Phases of the Support Package Manager

In the status bar, Support Package Manager informs you of the status of the current phase. To find out which phases are executed for which scenario (test or standard scenario), run program RSSPAM10.

The following list provides an overview of all the modules and phases in the order in which Support Package Manager executes them:

Preparation Module

1. PROLOGUE
This phase checks whether you are authorized to import Support Packages.
2. CHECK_REQUIREMENTS
This phase checks various prerequisites for importing Support Packages such as the tp logon to your system.
3. DISASSEMBLE
This phase unpacks files from the appropriate EPS parcels and saves them to the transport directory.
4. ADD_TO_BUFFER
This phase adds the queue to your system’s transport buffer.
5. MODIFY_BUFFER
This phase prepares the transport buffer so that the subsequent import phases can be processed correctly.
6. IMPORT_OBJECT_LIST
This phase imports the object lists for the Support Packages in the queue into the system.
7. TEST_IMPORT
This phase performs a test import for the current queue using tp. The system checks for objects that are in open repairs and that are overwritten during the import, or for other factors that might prevent an object being imported.
8. OBJECTS_LOCKED
This phase checks for objects that are overwritten by the import and are in requests that have not yet been released.
9. ADDON_CONFLICTS
This phase checks for conflicts between objects in the queue and installed add-ons.
10. SCHEDULE_RDDIMPDP
This phase schedules the transport daemon (program RDDIMPDP).
Module Import 1

11. CREATE_VERS_BEFORE
This phase generates versions of the objects that are contained in the Support Packages in the queue (if this option is set).
12. SPDD_SPAU_CHECK
In this phase, the system checks if a modification adjustment is necessary (transactions SPDD/SPAU).
13. DDIC_IMPORT
This phase imports all ABAP Dictionary objects in the queue.
14. AUTO_MOD_SPDD
This phase checks if modifications to ABAP Dictionary objects can be adjusted automatically.
15. RUN_SPDD
This phase prompts you to adjust your modifications to ABAP Dictionary objects with Transaction SPDD.
16. LOCK_EU (only for import mode downtime-minimized)
This phase locks the development environment.
17. INACTIVE_IMPORT (only for import mode downtime-minimized)
This phase imports program code and program texts in an inactive state.
Module Import 2

18. DDIC_ACTIVATION
This phase activates the imported ABAP Dictionary objects.
19. IMPORT_PROPER
This phase imports all repository objects and table entries not already imported during phase INACTIVE_IMPORT. This is preceded by actions such as table conversion and activation of the name tabs.
20. PREPARE_XPRA
This phase prepares the execution of the XPRAs and after-import methods.
21. UNLOCK_EU (only for import mode downtime-minimized)
This phase unlocks the development environment.
22. AUTO_MOD_SPAU
It checks whether modifications can be adjusted automatically.
23. XPRA_EXECUTION
This phase executes the XPRAs and after-import methods.
24. ABAP_GENERATION
This phase generates the runtime objects for the imported Repository objects (ABAP source code, screens).
Clean Up Module

25. RUN_SPAU
It prompts you to adjust your modifications to repository objects by calling transaction SPAU.
26. CLEAR_OLD_REPORTS (only for import mode downtime-minimized)
This phase deletes obsolete versions of program code and program texts in the database.
27. EPILOGUE
This phase completes the import process. Among other things, it checks whether the queue has been processed completely.

DB startup failure due to trigger execution

Issue: 
DB startup failure due to triggers were not executed properly


Preface:
The DB parameter 'MaxUserTasks' was set to 10000 instead of 1000(as a part of upgrade), which implicitly increased the 'MaxParallelLiveCacheTraceFiles' parameter value to 10001.

Solution:

DB could not be made ONLINE as the DB parameter ‘UseSystemTrigger’ was set to NO during MaxDB Upgrade(2.0 with MaxDB 7.7.07.26 to 2.6 with MaxDB 7.9.07.06), after this the parameter is set to YES.

I have changed the parameter value to NO and made it ONLINE.

Again I have changed the parameter to have default value as YES.

As this was only a temporary solution to make DB online, the next database restart failed with a 'restart trigger error', because MaxDB could not allocate enough memory for that many trace files. So I changed the 'UseSystemTrigger' to NO and started the DB. But restart trigger *must* be enabled in 7.9 to ensure that the liveCache works correctly, so this is cannot be a long-term workaround as it cures only one symptom (failing restart) and possibly introduces more issues.

Again I changed the 'MaxUserTasks' to 1000 but unfortunately the implicitly raised parameter value 'MaxParallelLiveCacheTraceFiles' was not automatically recalculated and therefore the issue still persisted.

Then DB developer checked the this parameter and he has set to 1 and new value calculated to 1001

param_directput MaxParallelLiveCacheTraceFiles = 1

param_checkall

param_directget MaxParallelLiveCacheTraceFiles

-> 1001

dbmcli on  Vadb<SID>  : >param_directget MaxParallelLiveCacheTraceFiles

OK

MaxParallelLiveCacheTraceFiles  1001

---

Now the trigger value is set to YES and DB restart happened(so system triggers got executed).

dbmcli on Vadb<SID> : >param_directget usesystemtrigger

OK

usesystemtrigger        YES

---

dbmcli on  Vadb<SID>  : >db_online

OK

---

This analysis has solved the issue.

TREX did not turn up after system restart

Issue: 
The TREX was not coming up after the system including DB was restarted with xuser file changed after hardware movement as a part of upgrade.

Solution:
The xuser.ini file is created but a newline character(Enter key in keyboard) was not given at the end of entries in this file. This will not create a .XUSER batch file successfully. 

We get the below kind of error while creating the batch file if entries maintained are wrong in this file.

vsa7561:nwvadm 56> xuser -b xuser_NWV.ini
Updating entry 1 for Userkey 'DEFAULT           '
Updating entry 2 for Userkey 'c                 '
Updating entry 3 for Userkey 'w                 '
Updating entry 4 for Userkey 'domain            '
Updating entry 5 for Userkey 'NWV               '
Entry 6 discarded (incomplete). Given Userkey was 'c_TREX            '
vsa7561:nwvadm 55>

So here details for ‘c_TREX’(key)/SAP<SID>TX(user) is not updated. 

So correct the entries, batch file is created successfully and TREX is up and running fine.

Error in adding the system to SAPLOGON PAD

Issue: 
Cannot add the system into the SAPLOGON PAD

Solution : 

In this case ,there are 7 possible cases which will lead to failure of adding system in SAP LOGON pad. So we have to crosscheck the following

 1. Check the current status of system (DOWN or LIVE ) that was facing the problem of adding in SAP LOGON pad.

 2. Check SISM settings of "SAPmsg.ini;"  . This option should be checked in  "SISM -> Further System Settings -> SAPmsg.ini; WDF only" 

3.  Entry in the services file located in /etc/services . This can be checked with the following command:

 Also make sure that double entries and duplicate entries should not be present. 

If you find the same remove the double or duplicate entry.

4. Entry in "sapmsg" configuration file in SAP LOGON PAD.

   Go to : SAPLOGON PAD ->options -> SAP Logon Options -> Configuration Files -> message Server file.
 

  There crosscheck if the paricular system message sever entry is present or not. 

  If it is not present, please run SAPPCADM Update (refer  point 7)

5. sapmsSID entry  should be present in the local deskptop windows in path : C:\WINDOWS\system32\drivers\etc

   Go to the mentioned path and open services file .Crosscheck if the  sapmsSID port number is present for the particular system. If not add the entry in UNIX admin portal.

6. Sapgui 720 problem- update your SAPLogon Pad

 Not possible to login from start -> run without providing default system number 00

Copy saplogon.ini from C:\Users\Username\AppData\Roaming\SAP\Common to C:\Windows which will allow you to login without providing default system number 00. Found, it can be the same 710 effect of login when you copy the saplogon.ini to windows base folder. Recently from 720,this file was put under C:\Users\Username\AppData\Roaming\SAP\Common folder.

Note : Restart of sapgui should be necessary 

7. Run SAPPCADM Update. 

• Click on Windows-Start-Button

• Go to "Control Panel"

• Go to "Run Advertised Programs"

• Chose "SAP GUI Connectivity – Refresh" and hit "Run"

• Wait ~1 Minute to get Confirmation via Popup.

• Close SAP Logon Pad completely (could be done before Update as well).

• Start SAP Logon Pad as usual  System Descriptions have been updated.

Same steps are needed to let SAP Logon Pad "learn" new systems. Ages ago, this refresh was performed automatically.