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>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>Collected 5082 filenames from [/usr/sap/trans/cofiles/.]
check>Found 3 invalid filenames on Cofile-directory
check>No Cofile found for TA STOPMARK
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
parameter is missing
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
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
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
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
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.
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 ?