What is a "strange character"? How can one write such a note...

[Former Member]

While fiddling with my personally best avoided "Java" I´m running to a problem while installing support packagees and found a matching note:

1170160 - Deployment of application sap.com~tc~esi~esp~app.sda, fails
<...>
2. There should be application.xml within the sap.com~tc~esi~esp~app.sda
   Check if there are any strange characters at the beginning of that
   .xml file. You might need a HEX editor to see them as they seem to be
   some kind of a byte-order marks breaking xml parse.
<...>

Something like that can only come from a developer, who was never sitting at a customers site.

I sometimes really wonder, if they are effectively so single threaded in their minds, that they really assume, all people reading that sentence will understand what they mean - with a "strange character" - or maybe the reason for this was the reflection of their face in their monitor (pun intended)... (and no, I won´t install a Hex-editor, I opened an OSS call...)

Markus

PS: the best note search term is "****" - try it and look into the code corrections...

[markus_doehr2]

Closing... but:

That MOPZ is another piece of useless software. It doesn´t help on implementations of SPs nor does it reduce the TCO - it PRODUCES costs (in sense of time and $$$).

Markus

[matt]

Seems perfectly clear to me. Which might well mean that it is developer speak! I just googled on "strange characters" as a phrase, and it seems to have more hits in connection with text files than with people.

*@ ÿ

btw, xvi32 is a great hex-editor - you don't need admin rights on your pc to install it.

matt

[markus_doehr2]

Well - we live in the Unicode world, don´t we? So without a semantical context no character is by definition "strange". And: do I know if some special "by-order-marks" are necessary in those files (speaking of LE/BE)?

On top of that comes the fact, that this note is for SP5, I see the same problem on SP6 so I think that the source of the problem should be fixed; otherwise I will need to re-do that again and again with each new SP.

Call me ignorant (or selectively perceptive) but I won´t do that "workaround".

That is all too typical. The "installed based maintenance" has a workaround and that´s it. Why bothering the development fixing the root cause? Let´s have the customers deal with that...

Markus

[matt]

>Why bothering the development fixing the root cause? Let´s have the customers deal with that...
> Markus

Well that's what we're for!

I like the phase "selectively perceptive". I'm sure I'm going to use that in future.

[markus_doehr2]

>Why bothering the development fixing the root cause? Let´s have the customers deal with that...

Markus

Well that's what we're for!

Tell that the "Installed Base Maintenance"! ) But no, stop, this will put a bad spot on their monthly performance reports...

I like the phase "selectively perceptive". I'm sure I'm going to use that in future.

Even better is "selective apperception", this underlines the psychological element even more (and yes, I know, I´m reading too much Freud - which is a result of the support-countertransference...)

Markus

[markus_doehr2]

Just to follow up on this:

> Well that's what we're for!

I just got the information that there is a "fix" for that problem in the latest patch for that component. Unfortunately it's neither possible to

- exchange the current SCA because the filename is different and its original filename is stored in the .xml file

- tell the maintenance optimizer to download the correct package

Conclusion:

The support lets all customers downloading that known broken package and refer to the note in case a call is opened instead of FIXING the broken package. This will need to be done for each instance of that package - and it's in ALL the new J2EE 5.0.

<rant>

I'm sorry - but if that is not ignorant (given the other two facts too) then I don't know what it is...

</rant>

Markus