Sales are tanking, money is tight, the company is cutting costs everywhere. And you want them to fund your SAP upgrade project ? Given that only about one-third of SAP customers have upgraded to ECC/ERP 6.0, and most of these have opted to do only technical upgrades in order to save time and money, you’re not alone.

The challenge you have is that there’s no business payback for doing a technical upgrade – the only thing you end up doing is staying on support. Going to the board with this as your major justification will get your submission (and maybe you !!) thrown out.

This means you need to be creative in seeking out the payback. Not even the pure techos like to use staying on support as the main justification for an upgrade. So you need other business drivers for SAP upgrades, including the benefits of new business and technical functionality and creating a foundation for other business initiatives.

However, there are some support-driven reasons to upgrade that could pay off. One of the drivers is mitigating the risk of receiving slower maintenance responses from SAP.

Also, with a technical upgrade, you can leverage your existing existing resources to enable the upgrade, such as using the opportunity to replace hardware. For instance, switching to Windows operating system from Unix may substantially lower costs, or alternatively, changing application servers to energy (i.e. cost) saving Linux blade-type servers.

Using tools like those provided by HCL, Intellicorp or Panaya can give insight into how the current, live production system and older systems are being used. This will also identify how end users are using the system, by looking at how the standard and customized parts of the system are being used. This raises the possibility of removing some of those customized areas, and containing costs by focusing testing and support on the modules and components being used.

But the biggest driver for an upgrade is another factor (and perhaps one more reason to complete the SAP technical ERP upgrade): not having to do any more of them.

Being on the NetWeaver platform and ERP 6.0 will allow companies to adopt SAP enhancement packages . These are a mature (first released in 2006) method of applying new functionality to individula modules, and, eventually, updates to the core platform. SAP has said many times this means the end of the traditional upgrade.

Occassionally, when loading Support Packages or SPAM/SAINT Updates, the Support Package Manager (transaction SPAM) can get a bit ‘confused’. A colleaugue had this problem recently, where she was attempting to update the SPAM tool on a 4.6C system. The result was that the Support Package Manager was reporting Queue_Not_Empty .

Some times the cause is simply forgetting to confirm / finish the last SPAM/SAINT update. Once you’ve eliminated this, you need to start checking what the TMS mechanism thinks has happened. To check what is in the TMS buffers, logon to the Operating System, change directories to /usr/sap/trans/bin and execute the following:

tp SHOWBUFFER -D SOURCESYSTEMS= TAG=SPAM


Basically you need to reset the SPAM Queue to match the TMS buffers. To remove entries from the internal SPAM Queue, uUse the function module (transaction SE37) OCS_RESET_QUEUE. Execute it with parameters IV_TOOL=SPAM, IV_FORCE=X. To remove entries from the TMS buffer, execute the following command (change directory to /usr/sap/trans/bin first), where SAPKXXXXX is the 'offending' Support package or SPAM/SAINT Update:

tp delfrombuffer SAPKXXXXX pf=/usr/sap/trans/bin/TP_DOMAIN_.PFL