Skip to Content

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 ?

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Bala Prabahar
    Martin,

    Thanks for writing this blog. I will either write a blog or add comments to this blog about non-SAP skills I used. For now, please review this blog explaining how I used “truss” in Solaris to uncover an issue:

    AHA! Moments Series

    Thanks again,
    Bala

    (0) 
  2. Bala Prabahar
    Here is one more challenge I experienced. Identifying the cause for this challenge required DB knowledge. A few months ago, we saw a warning message in backup log which caused a concern on database health. The warning was written at 4:26am. Here is the warning:

    WRN-/oracle/PM1/sapdata1/sr3_26/sr3.data26 is on an unavailable NFS file system. Skipping.

    This warning made me nervous. This definitly warranted analysis to find out what triggered the warning.  First I checked alert*.log to see if there are any ORA warnings. Second I checked the status of data files and tablespaces. They didn’t report anything unusual.
    Later I checked alert*log to see what was Oracle doing at the time the warning was reported by the backup tool. Active checkpoint was in progress:). That was an Aha! moment. Since checkpoint would take a lock on data file before flushing data blocks, the backup tool couldn’t take a lock within default NFS_ACCESS_TIMEOUT of 5 seconds and so reported NFS error.
    I documented this issue in this blog:
    http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/15376. [original link is broken] [original link is broken]

    Thanks,
    Bala

    (0) 
    1. Martin English Post author
      Thanks, Bala,
      One of the big problems with the BASIS area is that you tend to get thrown into the deep end. Knowing where logs are, or even an educated guess about their location, makes a big difference to how quickly you can resolve issues.
      (0) 
      1. Markus Doehr
        > One of the big problems with the BASIS area is that you tend to get thrown into the deep end.

        I think that one problem is, that in classes, on presentations, on demos etc. it is suggested that a “SAP installation” is done by throwing in a DVD, search for an .EXE file and doubleclick it, press next-next-finish and you’re done.

        I still can’t understand when people are “administrators” of a SAP system and don’t even know, where to look for logs.

        And even then everyone pushing on “play” or “stop” in an MMC should know, what’s happening in the background, how memory is allocated, how the connections to the database work etc.

        This is one curse of being only mouse-hustler – not meant as an offense but just as a conclusion. The GUI assumes it’s easy and self-explaining on the first sight – unfortunately it is not (always).

        (0) 
        1. Martin English Post author
          There’s one issue underlying both problems we’ve described; this issue is that outside the BASIS (and perhaps OS / DBMS) Administration teams, very few people really know what we do.  It’s compounded by the issue of DBMS and OS differences, let alone the different SAP products and releases, when we compare your site to mine. 
          SAP doesn’t help, in that it is in their interest to make installation and administration sound as easy and painless as they can get away with.  On top of that is the place of SAP within the Business, and within the IT department.  This means that if someone outside the BASIS team DOES work out what we do, it can be very difficult to apply this to another organisation. 

          Depending on your internal motivation, this can be very useful, as it means you can have some freedom to direct your own work.  Regardless of anything else, though, it means it is up to YOU to make sure that BOTH management and the business know that what you are doing has a verifiable bottom line.

          (0) 

Leave a Reply