SAPCAR is SAPCAR ......

[martin_E]

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).