Service parameter [something] contains special characters. Please correct

This thing started to annoy me at one point in time. I've had the error in the past as well, with a setting for ~sap-language, but now I also had it with a HTTP-HTTS (yes, I know, it should be HTTPS, but this is how SAP has named the parameter)

I bing'ed, searched notes, the SCN, various SAP groups, and everyone had an answer that was completely useless to me. Untill I found out I was actually searching for the wrong thing. Despite getting the error message here:

I found out I was actually looking for the wrong thing. What I should be focusing on was the fact that this was a special character, and not what it was, or why it was. I then found a note saying that the use of special characters was not supported for all basis versions.... I was astounded that this note did not turn up in my initial search, but note 1780585, actually did resolve my issue. Now I could add in the minus sign in my parameter. Yay ! Oh and please dont ask me why I would want to add in the HTTP-HTTPS parameter, unless you want to see a grown man cry.

Moving your SAP system to UTC

'Tis the the season for shutting down your SAP systems.... Again. And you likely did it last year aswell. Because SAP says you should, as the SAP system does not support the double timestamps that might occur.

Well, then you have the option of using "extended time". And some people might be very happy about this.
But what really happens, is that you get the wrong timestamp on items, up to half an hour off, and some businesses might not be happy with that.

Fortunately it's fairly simple to migrate to UTC (or UTC+1, or any other non-DST timezone) in your SAP system, even if you even missed it again this year, because the good news is: You have an entire Year to implement your changes. This will become an issue again next year.
The problem is that SAP apparently aren't able to provide a guide for how to do this, so many companies choose to have the added cost of shutting down the systems. But you really dont have to, changing to UTC time is really simple.
And all you have to do is:

Set servertime to UTC (or any non-DST timezone equivalent), on ALL servers in the instance

Set timezone on each client using transaction STZAC (while users are not active) identical to servertime

Set timezone for each user in transaction SU01 (or using a masschange or similar)

Download zip file from note 198411 and apply to SAP system using report TZCUSTIM

Verify timezone data consistency with report TZONECHECK, correct any problems as they show up.

Be aware that changing to UTC may also require downtime. This is required if you are moving your system back in time (eg from UTC+4 or equivalent to UTC+2 or equivalent), but not if you move it forward in time.

Benefits:

No need for downtime during start of DST

No need for NTP service during end of DST

Less confusion about time across multiple timezones

Easier to implement the use of various timeservices, NTP etc.

No time differences in documents of the type seen using SAPs “extended time”

Drawbacks:

Users may need time to adjust, as timestamps may vary between user- and servertime depending on programming, eg. Posting time is usually based on servertime, so end/beginning of time period may move a few hours.
Batchjobs are based on servertime, and jobs required to run at specific times may thus need to be rescheduled

Timezones must be set identical for ALL application servers, database servers, listeners etc for an entire system.

           Need to maintain time zones on a regular basis (they change a lot), see note 198411

Performing OS commands from within SAP

We all know it, we all need it once in a while. The options for running stuff from within SAP (like for instance file manipulations) just isn't really that well developed within SAP. However, you can often run single commands within SAP using transaction SM69. However this transaction has severe limitations. You can only run one command, and you cannot stack them by sending command interpreted characters along (like the pipe | ). Similarly, using -exec as a parameter is also not a legal call, so you can pretty much only do very basic manipulation from within SAP.
that leaves two options. One, you give permission to use SE38 to whatever user needs to run the report. Auditing will look very disfavorable upon that option. Or two, you make a script that does what you need, and call it.

Now, in the past, I have simply created my scripts on the OS, and caleld it from within SAP. It was simple, clean and functional. I did it, because it was easier to do, and because I had access to the OS.
But this week, I was posed with a problem of having to delete multiple files from a directory, of a certain date and with a specific syntax. something that I needed a script for. But I have no OS access to the systems. So what do I do ?

Well, I look at the type of OS my SAP is running on, from my system information:

then I create a small ABAP program with the following data

REPORT  ZZ_CLEANUP_INTERFACE_FILES_1.

DATA : my_command(255).
DATA: BEGIN OF MYTABL OCCURS 0,             " defines output
            LINE(255),
      END OF MYTABL.

my_command = 'find /usr/sap/interfaces/*zip* -mtime +15 -exec rm {} \; '.   " the Linux command

CLEAR MYTABL. REFRESH MYTABL.
CALL 'SYSTEM' ID 'COMMAND' FIELD my_command
              ID 'TAB'     FIELD MYTABL-*SYS*.

LOOP AT MYTABL.                             " displays output
  write :/ MYTABL-LINE.
ENDLOOP.

Had the system been a windows box, I could simply have typed in a windows command in the my_command field instead.
Do I need to run more than one command, I can just do a new my_command followed by a new SYSTEM call.
Do I need manipulation of the data, I have the output, line for line in MYTABL.

The really huge upside to this strategy is that: It's totally hardware independant (ok, it will only run on a similar OS, but I can move to another server and it will still work), I can limit access to the report via normal SAP authorizations, and I even get reporting, documentation and alerting similar to any SAP report.

I am certainly one happy camper, and might entirely forego the use of OS scripting in the future.

SoapDoc::Init: Cannot set inout buffer

A while ago I was setting up some SOAP connectors for our BI guys. I went into the SICF transaction and activated the connectors they needed.

They called me back, complaining that they would get this error message in the SOAPUI:

<p>URL http://xxx.xxx.xxx:yyyy/sap/bc/soap_sap-client=zzz call was terminated because the corresponding service is not available.</p>

I investigated. I tried to go to the webpage and see if it would return anything to me. I went into my browser and disabled the "nice error messages" option, so I could see it all. I then went to the URL and found:

 

My users immediately complained that "there's an error - Look it says cannot set inout buffer, the problem must be in the ICM, you fix it". But I didn't actually call the interface with any data. So it was just returning what it was asked.... An XML with absolultely nothing in it. Sending data through the interface would make the error go away.

Lesson learned: A "nice" error message is problematic, but a misleading one isn't any better ;)

SPAM queue unable to reset after phase IMPORT_PROPER

You know it, I know it, SAP knows it.... We all make a few mistakes once in a while. The other day I apparently messed up a SPAM queue updating some support packages.
"no worries" I thought, I'll just reset the queue and start all over. but noooo. SAP stops me from that. Errors like:

You cannot reset the queue from import phase 'IMPORT_PROPER'

immediately hit me..... Annoying. However, I remembered a little trick I did a while ago (yeah, so I dont really learn NOT to make mistakes, I only learn to clean up after myself):

1)  Clear data in the TP buffer, this can be done by renaming the buffer file in /usr/sap/trans/buffer (or whereever the bufferfile is located)
2)  Run the command tp r3i all <SID> pf=<path to TP_DOMAIN_.PFL file> tag=SPAM –Dclientcascade=yes –Drepeatonerror=8
3)  Go to SAP and run transaction se37 and enter the function module ocs_reset_queue, hit F8 and apply parameters IV_TOOL=SPAM and IV_FORCE=x
4)  Now the queue is nice and clean....


Downside is ofcourse that doing this might leave you with an unstable system. But if the alternative is a restore, then I'll personally be happy to try this first.Though next time I think I'll try to spend some time to figure out how to forcefully complete the queue instead. That could come in handy if I fail during the DDIC_ACTIVATION phase instead.

HTTP error: 400 Bad Request, no connection to docbase - Archivelink isn't working

The other day we had to move some servers around. But when we were done functional testing showed that an archive link in OAC0 was defective. It showed up with the error

HTTP error: 400 Bad Request, no connection to docbase 'docsap': No repository

I was puzzled, in that we didn't really move the tomcat running the connection. Moving the calling database shouldn't cause this problem either.
It took a while, but after some investigation, we found that this error was preexisiting in our system. So no luck running through the changes.
I looked at the SAP side of things, and the connection hadn't changed in a few years, so it wasn't a change. It had to be a bug. I tried moving the archivelink to the development server. It worked like a charm. So not a bug in SAP then.
As an error 400 meant that an error was received (in this case "no repository") The tomcat service was responding. I would have gotten an error 404 if it had been down. However, just to be on the safe side, I decided to restart the service. It IS running on windows after all.
No joy. Maybe an undocumented firewall change ?
Again, no joy. I checked the documentum server manager on the machine. The archive was available.
Maybe a config change in the documentum server ? I looked at the configfiles, there were some issues, but nothing that should cause problems like this. I fixed whatever was apparent, and restarted the tomcat again.
No joy. I was getting spooked. Was it a priviledge problem ? I looked at the user rights. They were good.

Given that another installation seemed to work, it HAD to be the tomcat. I was about to make the call and start a reinstallation of the service, when I wondered: "What would be the difference between reinstalling and now....." Then it hit me.... The workfiles !!! All that temporary crap. I entered the tomcats work dir and cleaned everything that had to do with my repository. Then I rebooted the virtual instance, and 5 minutes later..... Error gone....

this makes me wonder, if I restart my service, why is it even bothering to read through the old crap ? But never mind, I just put a nice little cleanup script together and placed it in the startup of the service.

Loading saplogon.ini from a custom location

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

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