The ABAP Detective And The Degraded Upgrade – PART 1
I’d begun to feel degraded. All this development around my shabby office cubicle and nothing for me to show for it but a PDF image. It had been years since the last shakedown of software in this vicinity. But I’m getting ahead of myself. I’m the ABAP Detective. I’ve been in this racket for a long time, enough to make some enemies, but fortunately many more friends. They don’t think much of me down at the precinct, but the beat workers, they know I’m a straight coder. And decoder, for that. What I do is investigate code jams. Not the kind you might be thinking of, with pizza and caffeine flowing, but the kind where screens slow to a crawl, and someone notices.
In this caper, I’m not exactly a prime player. It’s an enterprise upgrade, getting done under the wire, before the contracts are put out. Where I come in is near the beginning, when projections are made, and at the end, when those projections are put to the test. In the past, I might have been more involved in the daily cycle of transports and quality testing, but those are just memories now. I’ll share what I can, without shining the big light on the ugliest spots.
We’ve been on hold with version 4.7 for years, cycling through different changes without tackling the long downtime that comes with each major change. I set up my surveillance and settled in to watch for developments. It wasn’t long before those developments unfolded. In the development system in fact.
The case file pages that follow have been altered slightly in space and time, partly for basic redaction, but also for narrative sweep. Other than user reports of problems, the gold mine of tracking system change health remains the runtime logs. I find the poor coding, the poor user behavior, and the parallel and scaling issues that need attention there.
You get to see cryptic help, like this:
The internal table “\FUNCTION=LIST_DOWNLOAD_HTML\DATA=HTML_TAB” could not be further extended. To enable error handling, the table had to be delete [sic] before this log was written. As a result, the table is displayed further down or, if you branch to the ABAP Debugger, with 0 rows.
Memory management isn’t my cup of tea. The next genners will tell you that everything fits in memory. I like to break it down, and only try to remember the important data. But this isn’t an upgrade issue, unless there’s a data format change that blew things up.
The next clue I dug through was more to my taste – esoteric.
Error in the ABAP Application Program
The current ABAP program “SAPLV60A” had to be terminated because it has come across a statement that unfortunately cannot be executed.
The following syntax error occurred in program “SAPLJ1BG” in include “LJ1BGF01” in
“The field “OLD_WNFUNTX” is unknown, but there is a field with the similar name “WNFUNTX”.”
It happened a few times, around the same hour. Typical human testers, not believing the first error, but repeating it until finally giving up. I’d pass by this error, and check a few days later, to see if they got it out of their system. Field attribute changes, and overloading of domains, is typical shakedown during an upgrade or patch cycle. Figuring out what old salts need to be kept, and which need to be flushed, keeps the developers busy. Not much I can do for syntax errors.
I drilled into one of the above hits, and show the classic “long text”. They call this “ECC 6” or “ERP 6”, but inside, it’s known as 7.02, or just “702”, like a graffiti tag artist. The good news is that the kernels from this year, almost in the same quarter. It can be a major headache once a system has been running for a few years and a new problem occurs.
During another check, I found different errors. Not unexpected, since different portions of systems are tested by different people with their own styles. Besides the relatively simple syntax errors I listed above, this time I’m seeing DDIC errors. These shouldn’t get out of the initial tests, so I’d call in the reinforcements once I saw these. A similar set of errors found another day:
The termination was triggered in function “ab_RxDdicTypeError” of the SAP kernel, in line 1069 of the module
The internal operation just processed is ” “.
Internal mode was started at 20121115160528.
There is an inconsistency in the DDIC structure “TXW_FI_HD”, the corresponding dictionary runtime object (NAMETAB) is incorrect.
The number of components of the structure (NAMETAB component “fldcnt”) is specified using 39. If you dismantle all the substructures and calculate the actual total number of all the components recursively then the result is a different value.
“If you dismantle … recursively then the result is a different value.” Wow. Someone got paid to stay up late and make that as clear as the strong black coffee I’d need to drink to put it back into the box it came in. In other words, it’s broken. Take pictures, write it up, get the story in before deadline. If it were me, I’d jump in a yellow cab, and say “follow that cab.” It’s not the recursion you think it is.
Besides the syntax errors easily parsed from the notes, there are some not so easy to unwind. One example:
The following syntax error was found in the program SAPFMCVF :
“You cannot specify a length <= 0”
Looking at the code, though, where the error is supposed to be, hints at maybe the report coming in being a bit garbled, like a bad steno or telegraph operator. “These keys don’t match”.
I’m not seeing how “IF RETURNCODE <> 0” ends up flagged as “length <= 0”. Maybe it’s buried in the PERFORM call, maybe it’s a slight piece of misdirection, and maybe it’s a correctly reported error. Running the syntax check on RMCX0008 returns “Program RMCX0008 is syntactically correct”.
Digging around the various compost piles where errors are cached and rehashed, I noticed a warning about pricing conditions. Since I can’t share what’s in the online help systems, I’ll just drop this link to a publicly viewable PDF file on the topic.
You can do your own detective work, and back track from there.
After development, there’s quality, right? Keep your thumb on the pulse, and I’ll be back.