While ‘resting between engagements’, I took the opportunity to install and configure a Solution Manager system on a cloud host local to Australia.  The main reason was for a demojam entry, but it’s always good to keep my skills up to date.  The target system provided was a Windows 2008 R2 system.

Windows
Server 2003 R2 and Windows Server 2003 only have functional differences; using the same SAP kernel version, the same service packs, and
the same hot fixes and security fixes.  By contrast, going from Windows Server 2008 to Windows Server 2008 R2 requires an updated kernel (see SAP note 1383873 – Windows Server 2008 R2 Support).  Now, I could say I was using 2008 R2 for all the right reasons; for example, according to Frequently Asked Questions – SAP on Windows Server 2008 R2:

The main benefits of Windows 2008 R2 are

• Scalability
  Windows Server 2008 R2 supports up to 256 logical processors.
• Improved virtualization features
  On Hyper-V in Windows Server
  2008 R2, the amount of cores supported by the hypervisor (up to 32) has
  been enhanced. Another enhancement is Live Migration support by the
  implementation of Cluster Shared Volumes (CSV). Virtual Machines can be
  migrated without service interruption between the cluster members.
• Power usage
  Windows Server 2008 R2 reduces processor power
  consumption in server computers with multi-core processors using a
  feature known as Core Parking. Core Parking allows Windows Server 2008
  R2 to consolidate processing onto the minimum number of required
  processor cores, and suspends inactive processor cores. The advantage of
  Core Parking over traditional servers is 10-15 % energy saving for the
  same workload.

For a complete list of features, see:
http://www.microsoft.com/windowsserver2008/en/us/overview.aspx

However the real reason was that Windows 2008 R2 was already installed on the server I was using.  This became a bit of an challenge, as the Install Kit I used wasn’t actually for 2008 R2 !!.  I found OSS Note 1383873 fairly quickly, but even after installing the appropriate kernel as suggested,  sapstartsrv.exe (used by the SAPxxx_NN service) would not start correctly.  I discovered via google that I needed to install an extra Microsoft c-runtime (vcredist) to run the new SAP kernel.

The reason for posting this as a blog (I’ll also add it to the wiki) is that while I’ve since found out that this is ‘general knowledge’, it wasn’t described in OSS Nnote 1383873 – Windows Server 2008 R2 Support , and in fact, the only reference I found to my symptom was in one line in 1494740- SAP system migration from Windows 2003 to 2008 (R2) 64-bit AFTER I chased the error down through Google.

Are you implementing or using Windows 2008 R2 ? If not, why not ? Corporate standards ?, Lack of product support ? Lack of in-house knowledge ?

Over Christmas / New year, I’ll be upgrading a customer from a very old (as in unsupported by both the vendor and SAP) release of their database to the latest release supported by 46C.  As part of the exercise, we are bring the Support Packs (Support Stacks came in after 4.6C) up to date.  However, when I loaded the Support Packs into the target system’s /usr/sap/trans, I couldn’t decompress them for processing via transaction SPAM.

I transferred the latest SPAM (SAPKD00040) and the 50 Support Packs (yes, I know) required from http://service.sap.com/swdc to the UNIX server via my PC.  When I started decompressing the Support packs on the UNIX system, everything went OK for the BASIS (KB46Cxx.CAR) and and ABAP (KA46Cxx.CAR) Support Packs, but when I went to decompress some of the R3 Support Packages, SAPCAR failed (with a less than useful message).

The tool used to decompress the CAR files is SAPCAR – SAP’s own version of the UNIX / Linux tool tar.  I sat back and had a think about what SAPCAR actually does, and what could have gone wrong.  My first thought was that I had corrupted the files somehow in the transfer process.  I still had the CAR files on my PC, so I downloaded SAPCAR_5-10000854.EXE (4.6D 32-BIT Windows Server on IA32 32bit – a windows compatible version of SAPCAR) to test whether the CAR files on the PC were OK – I went to http://service.sap.com/swdc, selected ‘Search for Support Packages and Patches in the Archive’, and searched for SAPCAR, but you can also search directly for SAPCAR_5-10000854.EXE (remember that the part of the name following SAPCAR will differ between SAP different releases and platforms).

When I attempted to decompress KH46C36.CAR on my PC using SAPCAR_5-10000854.EXE, it worked quite happily.  More importantly, it also worked for all the CAR files that were causing me problems on the AIX server.

Now, remember that I was thinking that the original problem was caused by corruption during the file transfer, either from SAP to my PC, or from my PC to the server.  The logical conclusion, if that was the case, would be to restart the transfer at whichever step had corrupted the file(s).  However, because it appeared that the problem may have been with the UNIX SAPCAR, I wondered whether the decompressed files created on the Windows system would work with the AIX system.  As it turned, after I transferred the decompressed files from Windows to the EPS/in directory on the AIX system, I was able to import the the Support package using SPAM.

This makes sense, given that what we are working with is the source of the platform independent ABAP code.  The code that ends up in the transport may look differently depending on the machine architechture (read up on little endian versus big endiann), but the contents of the transport will be the same across platforms, for the same release of SAP.  On the other hand, if I wanted to upgrade AIX or DBMS specific parts of this particular installation, I would be upgrading the kernel (i.e. /sapmnt/XXX/exe for 4.6C) files, not loading my data into the system via SPAM. 

More to the point, what does this get me ?

I can get the OS / DBMS independent upgrades completed, so that the testiers don’t get held up.  I get this done before I get distracted by tracking down the kernel error (i.e. why the AIX SAPCAR doesn’t work).  The division between SAP Application code and the Operating System / DBMS dependent code allows for some interesting ways of solving problems. Where have you used code or executables for one platform to help fix a problem on another platform ?

SAP have detected a problem in the spool area which affects all customers in the world regardless of the SAP release and any support package level.

As soon as the retention time of a spool request exceeds 2009/12/31 a wrong date 2100/01/01 is entered during creation of the spool request. As a consequence these spool requests will not be deleted anymore from the spool reorg jobs. Using the default retention period this affects all spool requests on each SAP system in the world created since 2009/12/23.

OSS Note 1422843 already contains the correction instructions and the relevant kernel patches for 3.1 –> 46B (one patch) and 46c –> 7.xx (another patch). There’s nothing for anyone (unfortunate enough to be) running any of the original 2.x systems yet.

It is a little ironic – An old friend and I were discussing Y2K and all that in a general “what were you doing ten years ago ?” manner on New Years Eve. Should I tell her that SAP had a Y2K+10 ?

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