SMQS scheduler status shows RES_LACK

Today I was confronted with the fact that our BI system wasn't reciving data from our R3. After a short investigation, I found that the IDOCs were not processed. Manually processing them sent them to the tRFC queue. However, from here they just ended in "transaction recorded".
From past experience I knew to check the registrations in the SMQS. However, today I was met with a weird situation. The registration was fine, but the scheduler had a weird status.

After a while of looking, I noticed that the "host ID" was that of another system (!)
My suspicions immediately went to last weeks homogenous system copy. So I went through every step of the RFC process, from data creation to the REF destinations. And lo and behold.... the RFC logon groups (RZ12) had not been configured. Simple fix, furtunately.

SAP line opener showing correupted XML file recieved

If like me, you are forced to use an archaeic line opener, that cannot even run as a service. You may on occasion run into problems, and wonder why there is no support to get. And in truth I cant tell you. Sometimes I get angry and just continuously ping the sapserv1 server, and then go home, knowing that things are working, but saddend by the fact that it's not running optimally.

However, at least one function I have managed to find a solution for. I frequently got the error:

Error: 04-08-2014 09:44:38: Function startProcess : Corrupted XML file received
Error: 04-08-2014 09:44:38: parseXML: non-XML file
04-08-2014 09:44:38:  begin of make_https
04-08-2014 09:44:38: Getting SAPRouter data for LOP in the SMP

I tried reinstallting the LOP, I tried using a different user, I've tried pretty much anything, but it never worked. Untill I found out that it was caused by the company proxy. Not that the proxy itself poses a problem, but the way SAP tried to connect, isn't entirely compatible with modern proxies (You will know this if you have ever tried to replace a SAP webdispatcher with a real reverseproxy).

So how did I resolve the problem ? Simple. I just logged into the SAP marketplace from the server running the LOP. Then the proxy information is passed correctly by IE, which also means the LOP wont have to.

Logical system name for this BI is not allowed

Following a homogenous systemcopy of our BI, we were following the normally outlined strategy from SAP regarding copying BW/BI systems, in SAP note 886102.
In this case, however, a successfull, albeit very fast run BDLS job, resulted in the following error message when attempting to rename the logical system. Even SAP were unable to provide a timely solution to the problem.

This was, in retrospect ofcourse caused by the fact that the BDLS job only LOOKED successfull, but in fact stopped after only a few tables. One of the tables was ofcourse the T000 (which meant that the client would try to use a logical system name which didn't correspond to the technical name), aswell as the DBLS table(s). So everything looked to have finished ok. There also wasn't any error messages.

The trick was, how could I see that the job actually hadn't doen what it was supposed to ? BDLS runs for other logical systems ran just fine, and this had never been an issue in the past. I had to run a debugging of the BDLS transaction.

I had in the past had many discussions with a colleague about the BDLS functionality. I said there was a dynamic program containing the fields to be converted, he said that all fields defined as "logsys" would be converted. It turned out We were both only partly right. There IS a program, which creates a dynamic mapping of all the fields containing the logsys. And then the conversion starts based on this BDLSMAP. However, there apparently isn't any controls available to determine if this mapping fails. and in my case it did.

So I ended up finding a service program for the BDLSMAP that could clear the mapped data, After running that, the BDLS run finished fine, and all of our logical system problems went away. I'm seriously considering if this program, RBDLSMAP_RESET shouldn't ALWAYS be run prior to a BDLS run.

Selected system is not a quality assurance system

The other day my developer colleagues started reporting problems with them being unable to release transports for testing. the STMS_QA transaction was throwing an error.  

I immediately looked at the STMS configuration, and found that the system attributes for the QA system did not have a checkmark at "delivery after confirmation". So I logged into the domain controller, set the checkmark and redistributed the configuration. That should have been the end of it.
But lo and behold, it didn't work..... I logged on the the QA system again and had a look, the changes wasn't distributed, even though I pressed the button (!!!). Luckily the "adjust with controller" DID grab the configuration from the controller...

That fixed the problem. Now to figure out why the distribution didn't work.....

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.