There’s change in the air for SDN, but in the meantime I saw a tweet the other day from DJ Adams….

There’s not much chance of it getting fixed now, as the new SDN, as a new SDN based on Jive 5, will be going live
before the end of the year. However, the community comes to the rescue, with Sascha Wenninger posting a bookmarklet that is meant to take https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/26224 (with a title of SAP Community Network Blogs) and replaces it with https://weblogs.sdn.sap.com/cs/blank/view/wlg/26224, with the correct title. Unfortunately, his one doesn’t always work. For example, it assumes that the url starts with https, which requires you to logon to SDN before you can run it. So I modified, and present for your edification the Unwrap SDN Blog bookmarklet.

Drag the Unwrap SDN Blog bookmarklet to your tool bar, go to Sascha’s blog post, and hit the bookmarklet.

hth

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 ?

It started with a request to bring a 46C landscape up to date.  The starting levels for the Basis, ABA and R3 Support Packages were all at the low 20′s, while the target level for each of them was level 53. 

This meant I needed to install about 90 support packs per instance.  Comparing the sizes of the Support Packages against the space available in /usr/sap/trans suggested that I might be able to fit everything in without annoying the Storage Management team, if I was able to clean up all the old transports.

Which was where I hit the snag:

zuxdc22:dp1adm 19> tp check all pf=TP_DOMAIN_DP1.PFL
This is tp version 305.13.24 (release 46D) for ANY database

check>Log file is written to /usr/sap/trans/tmp/CHECK.LOG

check>
check>Collected 22 filenames from [/usr/sap/trans/buffer/.]
check>Collected 5 Systemnames from [/usr/sap/trans/buffer/.]
check>Collected 00160 out of 00160 entries from buffer ZP1.
check>Collected 01233 out of 01233 entries from buffer TP1.
check>Collected 03037 out of 03189 entries from buffer PP1.
check>Collected 00094 out of 03254 entries from buffer QP1.
check>Collected 00023 out of 02671 entries from buffer DP1.
check>Collected 04547 entries from buffers
check>.
check>Collected 5082 filenames from [/usr/sap/trans/cofiles/.]
check>Found 3 invalid filenames on Cofile-directory
check>No Cofile found for TA STOPMARK
check>HALT 20100916141327
ERROR: A target system group (/U9C_ALR/) is used with a name longer than 3.
This is only possible with NBUFFORM=TRUE!
ERROR: EXIT(16) -> process ID is: 87782

tp returncode summary:

TOOLS: Highest return code of single steps was: 16
ERRORS: Highest tp internal error was: 0204
tp finished with return code: 204
meaning:
parameter is missing
zuxdc22:dp1adm 20>

However, when I checked the domain profile TP_DOMAIN_DP1.PFL, the values for NBUFFORM (and a related parameter, CTC) were set correctly….

#

TRANSDIR            = /usr/sap/trans
#
DP1/CTC             = 1

DP1/DBHOST          = zuxdc22
DP1/DBNAME          = DP1
DP1/DBTYPE          = db6

DP1/NBUFFORM        = 1

But that’s OK – This problem (NBUFFORM and CTC are set correctly, but don’t take effect) will probably be fixed when I upgrade the kernel, which I’m going to have to do as part of the Support Pack upgrades.  But I need to upgrade the kernel when I upgrade the Support Packs, and I couldn’t reliably do that until I cleaned out the transport directories.  Which required an upgrade to the kernel, ….. and of course what happens if the kernel upgrade doesn’t fix the problem ? I needed another solution.

Sometimes you need more than SAP knowledge to get things going.  At this point, I knew there was at least one ‘invalid’ Target System Group in the transport directories, with at least one transport using it.  So I decided to find out what that transport  (and any others with the same Target System Group !!) was ….

zuxdc22:dp1adm 21> cd ../cofiles

zuxdc22:dp1adm 22> pwd
/usr/sap/trans/cofiles
zuxdc22:dp1adm 23> grep U9C_ALR *.*
K111738.DP1:HERMANNMA    K /U9C_ALR/  3   0   0   0   0   0   0   0   0 1 46C   .  0   0   0   0   0 000

zuxdc22:dp1adm 24>

Remembering that the contents of the /usr/sap/trans/cofiles directory are text files (the /usr/sap/trans/data files are binary), I was able to edit the cofile for the transport in error (I used vi because this was on an AIX system).

zuxdc22:dp1adm 24> vi K111738.DP1

zuxdc22:dp1adm 22> pwd
/usr/sap/trans/cofiles
zuxdc22:dp1adm 23> head K111738.P9C
HERMANNMA    K U9C  3   0   0   0   0   0   0   0   0   1  46C   .  0   0

0   0   0 000
….
….
zuxdc22:dp1adm 24>

I corrected the transport in error, and reran tp check all to see if there was anything else in error, before running tp testold or tp clearold.

Some Notes
This is a fairly esoteric example of where pure SAP skills won’t help with an SAP related problem.  It was actually worse than I’ve described above, as my second run of tp check all highlighted a Target System Group that had 45 transports belonging to it.  I fixed these, thinking if there were any more errors, I would have to find a different way to approach the problem, but they were the last errors.

Depending on the number of errors, I would also look at installing the latest copies of the tp programs and modules in a separate directory.  Without having gone through it, I can’t think of any logical problems, but it would have been an interesting exercise…  It may have been more time consuming, though, which also needs to be taken into consideration.  For what its worth, the way to check the release level of the tp program is described in OSS Note 155350.

When have you had to go above and beyond SAP, to get the job done ?  What non SAP skills do you get to use on a regular basis in your SAP work ?

I feel a bit ordinary writing a blog post about something as trivial as one line of javascript, so I decided to include a picture as well.

It shows a screen from the guided procedure for Solution Manager Configuration.  The interesting part is what I have done wrong.  I’m using the javascript referred to by this link ( Show Passwords ) to display the value(s) of all password fields on the current web page.

In this case, the Administrative User values are the same, but the Administrative Password fields are different.  Since they are using the same User Source (the ABAP engine), one of the values (or both !!) must be incorrect.

Save the javascript by dragging the Show Passwords link to your bookmarks, or by saving the link to your bookmarks.  This has been tested in IE6 thru IE8 and in Firefox.

Every two months ERPtips Express publish a set of three of their articles as a sample of whats available under their subscription model.

This months edition includes three detailed articles.

BI: Getting Optimum Performance from Your SAP BI/BW Environment, by Arthur Pesa.

This article acquaints you with the different dependencies found in the BI/BW environment that can impact your system’s performance, and how to properly assess them.

Data Archiving: Archiving SAP Sales Documents, Part I: Analysis, by Breck Whitten.

There are many loopholes that can leave old data unarchived, without your realizing it. This article covers some of them, which may lead you to revisit your Sales Document archiving strategy.

ABAP: Flexible Programming Continued: Using Field Symbols and References, by Rehan Zaidi.

This article delves into how to combine field symbols and data references using a dynamic programming technique. This is quite usefull knowledge for debugging as its quite widely used in the standard SAP programs.

These articles are available free of charge, but get replaced by new free content every two months, again fee of charge, at http://www.ERPtips.com/Express.asp.

A standard BASIS problem is the generic “what is it doing and why ?” question. This could be in the context of debugging a program or process, or trying to work out what configuration changes are required to make something work. It generally occurs when the development or functional team have moved on, leaving someone who knows what to do but not why – usually a user (under pressure from their boss) who just wants to get the system doing what they’ve been told it should be doing….

However, your BASIS team (or person) has to be a jack of all trades, with not just a smattering of SAP functional knowledge, but also a working knowledge of Networking, Desktop PCs, the Operating System(s) and Databases(s) their SAP systems are running on and so on.

I’ve found that the best way of dealing with this need to know something about everything is not by trying to know everything, but by knowing how to find out everything. An example of this is comes from Jerome Mungapen’s SAPLOG, where he provides a useful reminder of some of the various ways of finding what tables and fields lie behind an SAP transaction:

Have you ever been frustrated trying to find which table and field a piece of data is stored in. You can see it on the screen, and the old faithful F1 – F9 results in some useless structure information. Or have you ever started looking at a piece of functionality you are unfamiliar with wanting to find the table structures behind it in SAP. Well this article shows my favorite five ways of digging under the hood to find out what’s going on.

Jerome lists five methods, but one of them assumes you have the time (and need) to get really in depth knowledge of a given area of SAP. I’ve listed the four methods I use (plus Jerome’s extra one) in the order I’ use them when closely examining or debugging a transaction I’m unfamiliar with.

Use a Different Field

If the technical information pop up shows a structure and not a real field, just try another field on the same area of the screen. It is surprising how often this works !!

Use Where Used on the Data Element

From the technical information pop up, select the data element then press Navigate to get to the Data Dictionary. Once there, press the Where Used button.

Trace Analysis

Transactions SE30 Runtime Analysis and ST05 SQL Trace can be over-kill for determining what fields and tables are being used, but can be used to see how (for example) configuration data controls how and / or when the fields and tables are updated. It’s also useful when dealing with Z or Y code, structures and tables.

SE80 Object Navigator

This is probably more useful for a functional person, and is not available on the older SAP releases anyway. However, if you know the program behind the transaction, you can use SE80 to find all the Data Dictionary objects (including tables and fields) associated with that program.

Environmental Analysis

For those requiring a wider understanding of how a given area works in the SAP system. Jerome’s explanation of Environmental Analysis says it all.