ABAP 7.40 - Bug Report?

[Juwin]

How do I effectively report a 'bug', with the new syntax introduced in ABAP 7.40?

I saw someone reporting bugs, as comments in 's blogs. I am just learning new syntaxes and so, this isn't a true production down situation to report as a OSS message. Moreover, do ABAP syntax check errors also get reported in the same way as functionality bugs?

Just to document my findings, so that it may help anyone whoever is reading this:

It seems that the new constructor VALUE, forgot a CLEAR statement, in the LOOP.

Here, I am declaring a table, with 3 fields A, B and C. Then, I am populating values, 1, 2 and 3 into them and displaying output.

report value.

  types:begin of   st1,

         a type c,

         b type c,

         c type c,

       end   of   st1,

       tb1 type standard table of st1 with non-unique key a b c.

cl_demo_output=>display_data( value tb1(

                ( a = 1 b = 2 c = 3 ) ) ).

The expected output is:

A	B	C
1	2	3

And, the actual output, matches the expected output.

Now, I am adding more rows to the table:

cl_demo_output=>display_data( value tb1(

                ( a = 1 b = 2 c = 3 )

                ( b = 2 c = 3 )

                ( c = 3 )

                ( b = 2 ) ) ).

The expected output is:

A	B	C
1	2	3
	2	3
		3
	2

And, the actual output, matches the expected output.

Now, I am adding some conditions to the field populating logic.

cl_demo_output=>display_data( value tb1(

                ( a = 1 b = 2 c = 3 )

                ( c = cond #( when 1 = 2 then 4 else 3 ) )

                ( b = 2 )

                ( c = cond #( when 1 = 1 then 4 else 3 ) )

                ( b = cond #( when 1 = 2 then 5 else 2 ) ) ) ).

The expected output is:

A	B	C
1	2	3
		3
	2
		4
	2

The actual output is:

Where did the extra 2, in the column B of 4th row come from? I am not populating that in the table.

One more try:

cl_demo_output=>display_data( value tb1(

                ( a = 1 b = 2 c = 3 )

                ( c = cond #( when 1 = 2 then 4 else 3 ) )

                ( b = 2 )

                ( c = cond #( when 1 = 1 then 4 else 3 ) )

                ( a = 1 c = 3 )

                ( b = cond #( when 1 = 2 then 5 else 2 ) ) ) ).

Again, where did the extra 2, in rows 4 & 5, come from?

Note that it didn't copy column A or C over in the same fashion - so copy behavior is arbitrary? This happens only when I try to add a function within the VALUE operator.

VALUE operator without additional built-in function.

cl_demo_output=>display_data( value tb1(

                ( a = 1 b = 2 c = 3 )

                ( c = 3 )

                ( b = 2 )

                ( c = 4 )

                ( a = 1 c = 3 )

                ( b = 2 ) ) ).

And, the output is perfect once more.

The only way around this as of this moment, seems to be, is to explicitly populate every field in every row.

cl_demo_output=>display_data( value tb1(

                 ( a = 1 b = 2 c = 3 )

                 ( a = space b = space c = cond #( when 1 = 2 then 4 else 3 ) )

                 ( a = space b = 2 c = space )

                 ( a = space b = space c = cond #( when 1 = 1 then 4 else 3 ) )

                 ( a = 1 b = space c = 3 )

                 ( a = space b = cond #( when 1 = 2 then 5 else 2 ) c = space ) ) ).

I am on SP10, with support package SAPKA74010. Is this issue already reported and corrected in a later patch? If so, please forgive me.

Thanks,

Juwin

[horst_keller · Accepted solution]

Hi Juwin,

First of all it is a bug that is meanwhile fixed in recent Kernels:

If I remember it right, it was already reported in SCN and I forwarded it to development.

How to report it?

Since it is officially delivered functionality, you can of course report it via OSS. Then you also will learn in which kernel patch the correction was made.

If you just want to know if it is a bug and if it is corrected meanwhile, you can also place a discussion in SCN. If I am notified, I'll look at it and forward to development if necessary. In fact, I'm doing a kind of voluntary additional hotline service here.

Horst

[mspix]

I also noted an issue with the COND# operator in SAP_ABA 750 SP 0025. In the following coding, there is a syntax error in line 6. It seems that the compiler confuses the field symbol <> for the comparison operator <> for some reason, but only if an ELSE token appears afterwards. I don't want to open an Incident for that, but in my opinion this is a bug in the ABAP compiler.

REPORT.
FIELD-SYMBOLS <>.
FIELD-SYMBOLS <a>.
data(a) = cond char1( WHEN 1 = 2 THEN <> ). "works fine
data(b) = cond char1( WHEN 1 = 2 THEN <a> ELSE 'a' ). "also works fine
data(c) = cond char1( WHEN 1 = 2 THEN <> ELSE 'a' ). "syntax error

[matt]

I agree it's a bug.

FIELD-SYMBOLS <>. 

should be a syntax error. But that won't change, just in case someone really has used <> in a real program. I doubt it will be fixed as it really is a pathological example. As I recall there are also issues using variables with the same name as keywords.

Please tell me you use meaningful names for variables in real programs and this is just the result of playing around. 🙂

[mspix]

matthew.billingham Of course, we do not name our field-symbols <> in productive applications, but yes, I noted that while trying some stuff.

[Sandra_Rossi]

Because Matt noticed 7.50 was ok, I searched the SMP: 2243679 - Wrong result of table constructor with conditional

[matt]

Nice bit of analysis!

I am just learning new syntaxes and so, this isn't a true production down situation to report as a OSS message. Moreover, do ABAP syntax check errors also get reported in the same way as functionality bugs?

If you look in support.sap.com/notes, you'll see plenty of notes for ABAP tools, like SLIN (I know,  because it dumps when there's a VALUE #( blah ) statement on my 7.4 instance!). None of these cover "production down" situations either. When you create a support request, there's no such requirement either. You're reporting an issue with the product.

I suggest you create a support message with a low priority and your analysis. Then they'll either fix it (a kernel fix) or Horst will update the documentation!

EDIT: it must be fixed in a later release. I've tried it in a 7.50 system and everything works as expected.

[raphael_almeida]

Is there a good question!

Juwin, I tested one of its statements in my SAP (SAP_ABA SP 12), in fact until this SP is this "bug", but impressive it is to change this line:

( c = COND #( WHEN 1 = 2 THEN 4 ELSE 3 ) ) ) ).

The result was satisfactory (of course, instead of being the 4, he took 3). My question now is, when the condition was false, why he did "right"?

Just like you, I will wait for the answer

My results:

When 1 = 1:

When 1 = 2:

Added images