I've always been somewhat annoyed by the fact that in various versions of the SAPgui the location of the saplogon.ini file moved around.
So the other day when I had a problem updating my gui to 7.30 (a requirement for PLM), I was once again met by problems as the saplogon decided to load an old version of my saplogon.ini.... As I only had the one version of the file on my computer (in c:\windows), I was baffled. Fortunately, I remembered a trick from virtualization: I simply closed down my SAP windows, and replaced the saplogon shortcut with a new one that looked something like this:
%programfiles%\SAP\FrontEnd\SAPgui\saplogon.exe /ini_file="C:\windows\saplogon.ini"
And hey presto. Up and running again. Now for the hard task of figuring out HOW an old version of the saplogon.ini was found....
Tuesday, April 23, 2013
Monday, April 22, 2013
Searching for breakpoints
Last week I had a look at the BI systems systemlog, and I found to my horror that someone (this was a generic job scheduling user, so no help there) had run a program (dynamic so no help there) that threw a lot of errors in the system log due to a breakpoint.I was down to about 2 minutes of logging. Hardly an ideal situation. Not to mention that some poor soul had some problems getting his program to work.
Armed with no dumps, no username, no jobname and a desire to avoid these thousands of errors, I dived into the problem.
My first thought was to find a way to determine the name of the actual program rather than the dynamic name. I even managed to find a function module that would translate the dynamic name in to a program name. However, that appeared to work for only function calls, not programs.
No help there. I then dived into the tracefiles in ST11. No joy. SM37.... there had to be something there. After all, it was a batch process. But no failures there. Apparently the break point is a perfectly valid command, so all batchjobs complete successfully. and all of the batchjobs at the time were pointing to the BI bacth manager. there were thousands of jobs scheduled. Again no help.
So I decided to bite the bullet and look for the source code. I found many less helpfull suggestions on the web. One was transaction EWK1. I have no idea when this was dropped, but it certainly doesn't exist in any of our systems. then someone suggested using the global search in SE80. However, I found that this requires spefici add-ons to be installed.again others suggested TREX, but that required that I attach a TREX and added all the code. Someone suggested using program RSRSCAN1, but this is pretty useless in an SAP system, as this only supports very old object names. I finally found RPR_ABAP_SOURCE_SCAN, but much to my dismay, this program was not present in our BI system, even though it was there in the ECC. But now i had hope. I tried looking at the code that I had working in the ECC, and found that all it did was calling another program: ABAP_SOURCE_SCAN. I crossed my fingers and tried running this program directly in our BI system, and lo and behold it worked !
I was able to search through all object type, and select only the active pieces of code too. This looks very similar to the code ferret in SALT. Really nice.... I was now able to identify only a few programs that had the active "break-point." code in them. Time to cleanup....
Armed with no dumps, no username, no jobname and a desire to avoid these thousands of errors, I dived into the problem.
My first thought was to find a way to determine the name of the actual program rather than the dynamic name. I even managed to find a function module that would translate the dynamic name in to a program name. However, that appeared to work for only function calls, not programs.
No help there. I then dived into the tracefiles in ST11. No joy. SM37.... there had to be something there. After all, it was a batch process. But no failures there. Apparently the break point is a perfectly valid command, so all batchjobs complete successfully. and all of the batchjobs at the time were pointing to the BI bacth manager. there were thousands of jobs scheduled. Again no help.
So I decided to bite the bullet and look for the source code. I found many less helpfull suggestions on the web. One was transaction EWK1. I have no idea when this was dropped, but it certainly doesn't exist in any of our systems. then someone suggested using the global search in SE80. However, I found that this requires spefici add-ons to be installed.again others suggested TREX, but that required that I attach a TREX and added all the code. Someone suggested using program RSRSCAN1, but this is pretty useless in an SAP system, as this only supports very old object names. I finally found RPR_ABAP_SOURCE_SCAN, but much to my dismay, this program was not present in our BI system, even though it was there in the ECC. But now i had hope. I tried looking at the code that I had working in the ECC, and found that all it did was calling another program: ABAP_SOURCE_SCAN. I crossed my fingers and tried running this program directly in our BI system, and lo and behold it worked !
I was able to search through all object type, and select only the active pieces of code too. This looks very similar to the code ferret in SALT. Really nice.... I was now able to identify only a few programs that had the active "break-point." code in them. Time to cleanup....
Wednesday, April 3, 2013
Reorganization of update date not allowed in batch
Or the story of how a spelling error in an error message can send you on a wild goose chase.
Today, one of my colleagues came to me and was worried about a job, SAP_REORG_UPDATERECORDS, that seemed to cancel everytime it ran, along with several other jobs.I started my investigation, and I found that we had a LOT of DB13 jobs and SAP standard jobs that had apparently been scheduled with no regard to what was actually needed. Some jobs even attempted to start an online backup. I started deleting the superflouos ones, but wondered a bit about the SAP_REORG_UPDATERECORDS. Surely a reorganization job would still need to run. I looked at the job log, and lo and behold, there was a nice and shiny error following the very first jobstep:
So I figured, hey, this is ofcourse somewhere in an OSS note. But nooooo. My dissapointment was obvious. untill I found note 1558304, which describes that a translation error had taken place:
Wrong English Text: Reorganization of update date not allowed in batch
Correct English Text: Reorganization of update data is not allowed in batch
Armed with the knowledge that this was infact just a regular update that wasn't allowed in batch, and had nothing at all to do with the date, I referenced note 67014 which basically states that you shouldn't really do update reorganizations at all. And I could now easily argue the fact that someone apparently forgot to delete the SAP_REORG_UPDATERECORDS job from the list of standard jobs in SM36. So I deleted all scheduled jobs, and deleted the job definition from the list of standard jobs, as suggested in note 16083.
Isn't it nice when SAP actually has notes for all of the stuff ? Even though sometimes there's a really long path leading there ;)
Today, one of my colleagues came to me and was worried about a job, SAP_REORG_UPDATERECORDS, that seemed to cancel everytime it ran, along with several other jobs.I started my investigation, and I found that we had a LOT of DB13 jobs and SAP standard jobs that had apparently been scheduled with no regard to what was actually needed. Some jobs even attempted to start an online backup. I started deleting the superflouos ones, but wondered a bit about the SAP_REORG_UPDATERECORDS. Surely a reorganization job would still need to run. I looked at the job log, and lo and behold, there was a nice and shiny error following the very first jobstep:
So I figured, hey, this is ofcourse somewhere in an OSS note. But nooooo. My dissapointment was obvious. untill I found note 1558304, which describes that a translation error had taken place:
Wrong English Text: Reorganization of update date not allowed in batch
Correct English Text: Reorganization of update data is not allowed in batch
Armed with the knowledge that this was infact just a regular update that wasn't allowed in batch, and had nothing at all to do with the date, I referenced note 67014 which basically states that you shouldn't really do update reorganizations at all. And I could now easily argue the fact that someone apparently forgot to delete the SAP_REORG_UPDATERECORDS job from the list of standard jobs in SM36. So I deleted all scheduled jobs, and deleted the job definition from the list of standard jobs, as suggested in note 16083.
Isn't it nice when SAP actually has notes for all of the stuff ? Even though sometimes there's a really long path leading there ;)
Subscribe to:
Posts (Atom)