A SAPScript Mystery: We fixed the code but why did it ever work?

[Former Member]

I recently had to do a very minor bit of maintenance on a SAPScript check-printing form - all I had to do was to move the check window a little lower.

So I copied the original form to a new form, made the change, activated the new form, and reconfig'd so that the RFFOUS_C program pointed to the new form.

To my surprise, the program then blew off in a custom subroutine that the Form called during printing of the check window. The code in the form was calling the custom subroutine with two variables, not three, so the code in the subroutine was blowing off becuase there was no third row in an itab.

So I commented out the code in the custom subroutine that was looking for a third table row, reactivated, and everything worked fine.

But here's the question:

Why did the original Form and custom subroutine ever work correctly together at all? The original Form was calling the subroutine with two variables, but the original subroutine never blew off on a bad table read.

If anyone can answer this, I'll ask Craig to chip in an extra 10 points over my 10, cause this one is a real puzzler.

[Former Member · Accepted solution]

Question??

When you are running your copied form...

Is it run in the same language as of the originial form..

Meaning did you run both the forms in the same language...And checked..

Before you commenting for the third parameter..

Thanks,

Naren

[RichHeilman · Accepted solution]

Hi,

<i>Is the 'nomrbre3' use in the READ TABLE pointing to a text element...

Is that something to do with the translation of the text 'nomrbre3'..

If it is pointed to a text element..Is that text translated in spanish ..

Thanks,

Naren</i>

Gentlemen, I think Naren might be on to something here.

In the READ statement, does it use a text element or a literal as I have above?

If a text-element this could be a piece of the puzzle. But it really depends on if you are using multiple languages forms.

Regards,

Rich Heilman

[former_member181923 · Accepted solution]

Rich/Narem -

I will check on the literal vs text-element variable in the call on Monday - I haven't been with my current client long enough to be trusted with VPN yet.

Rich -

Yeah - that puzzled me too about the code. I guess the previous developer figured that the code would never be changed so the lazy read without sy-subrc check would be OK. "Just shows to go you . . ."

[former_member181923 · Accepted solution]

Much appreciated

Dave

[former_member181923 · Accepted solution]

I checked the original form and the original custom subroutine and don't see any mention of "nombre3".

The original form calls the subroutine as follows:

PERFORM PROVEEDOR IN PROGRAM ZFI_FORMULARIO_CHEQUES

USING &REGUH-ZADNR&

CHANGING &NOMBRE_PROVEEDOR&

CHANGING &NOMBRE_PROVEEDOR2&

ENDPERFORM

The subroutine is:

FORM proveedor TABLES: it_entrada STRUCTURE itcsy

it_salida STRUCTURE itcsy.

DATA: c_lifnr LIKE reguh-lifnr,

nombre(40),

nombre2(46),

nombre3(40).

*>JGMB-01

DATA c_zadnr LIKE reguh-zadnr.

*

*Se busca el nombre del proveedor.

• READ TABLE it_entrada WITH KEY name = 'REGUH-LIFNR'.

• MOVE it_entrada-value TO c_lifnr.

READ TABLE it_entrada INDEX 1.

MOVE it_entrada-value TO c_zadnr.

• CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'

• EXPORTING

• input = c_lifnr

• IMPORTING

• output = c_lifnr.

CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'

EXPORTING

input = c_zadnr

IMPORTING

output = c_zadnr.

• SELECT SINGLE *

• FROM lfa1 CLIENT SPECIFIED

• WHERE mandt EQ sy-mandt

• AND lifnr EQ c_lifnr.

• IF sy-subrc EQ 0.

SELECT SINGLE *

FROM adrc CLIENT SPECIFIED

WHERE client EQ sy-mandt

*>JGMB-01

• AND addrnumber EQ lfa1-adrnr.

AND addrnumber EQ c_zadnr.

• IF sy-subrc EQ 0.

• MOVE adrc-name1 TO nombre.

• CONCATENATE adrc-name2 adrc-name3(5) INTO nombre2.

• ELSE.

• CLEAR: nombre, nombre2.

*

• "JGMB-01

• ENDIF.

• "#id.eacc-03.sn

IF sy-subrc EQ 0.

MOVE adrc-name1 TO nombre.

MOVE adrc-name2 TO nombre2.

MOVE adrc-name3 TO nombre3.

ELSE.

CLEAR: nombre, nombre2, nombre3.

ENDIF.

• "#id.eacc-03.en

• Exporto el nombre del proveedor.

READ TABLE it_salida WITH KEY name = 'NOMBRE_PROVEEDOR'.

it_salida-value = nombre.

MODIFY it_salida INDEX sy-tabix.

• Exporto el nombre del proveedor.

READ TABLE it_salida WITH KEY name = 'NOMBRE_PROVEEDOR2'.

it_salida-value = nombre2.

MODIFY it_salida INDEX sy-tabix.

• "#id.eacc-03.sn

• Exporto el nombre3 del proveedor.

• READ TABLE it_salida WITH KEY name = 'NOMBRE_PROVEEDOR3'.

• it_salida-value = nombre3.

• MODIFY it_salida INDEX sy-tabix.

• "#id.eacc-03.en

ENDFORM. "proveedor

There are no text-elements defined within the program ZFI_FORMULARIO_CHEQUES.

So I think this one has to remain open as a continuing mystery, although I do think you're both correct that the question has something to do with the English vs Spanish versions of the form and program.

The form's original language was Spanish (ES) but current language is English (EN).

[Former Member]

Hi,

Is the 'nomrbre3' use in the READ TABLE pointing to a text element...

Is that something to do with the translation of the text 'nomrbre3'..

If it is pointed to a text element..Is that text translated in spanish ..

Thanks,

Naren

Message was edited by: Narendran Muthukumaran

[former_member181923]

NM -

I'll have to check that further and get back to you but you might be onto something. When I copied the Form (not the subroutine), I didn't check to see whether text elements copied it.

Is it possible the old Form had three elements but my copy of it only had two ???

That would be a neat solution to the mystery.

Dave

[former_member181923]

NM -

I'll let Rich decide whether you've got the answer here. I think you probably do, but I'm not sure myself.

Dave

[former_member181923]

Rich -

Yeah - you've ID'd the line correctly. Instead of doing what you suggested (or checking for a bad sy-subrc before the modify), I just commented out the read because everyone agreed the third read would never be needed if the subroutine was only being called with two variables (nombre1 and nombre2).

But still - the question is why did the call with two variables and the subroutine with three ever work at all?

[former_member181923]

Rich -

I forgot to mention. The reason it bombed is because of the modify in the next line. It reads with key of name = "nombre3" and doesn't find it, so sy-tabix becomes unusable. And therefore, the following "modify" statement blows off because it's a modify with a sy-tabix in it (at least in our version of the subroutine.)

Dave

[RichHeilman]

Right, the READ fails, MODIFY will definitly give you a dump. Seems that the previous developer has miss a fundimental of ABAP, check sy-subrc. Anyway that still doesn't solve the puzzle.

REgards,

Rich Heilman

[RichHeilman]

Any chance that the form has been modified without transporting to production? Maybe a developer was messing around and got rid of the 3rd variable from the the form and never changes the program logic. Just a guess.

Regards,

Rich Heilman

[former_member181923]

Rich -

No - everything happened in our DEV system - if I pointed RFFOUS_C to the original form, it worked fine; if I pointed it to the new form, then the subroutine blew off.

Here's one thing that may be a clue for you, though. (I'm not playing "cute" here - I'm honestly puzzled.)

The custom subroutine was a form in a group of forms compiled within one program "ZFI_FORMULARIO_CHEQUES".

This program had an original language of Spanish, but had been recompiled into English for an earlier fix involving lifnr.

The form, on the other hand, was still a "Spanish" form.

I'm wondering if the cross-language situation could have caused some confusion, i.e. whether my repointing of RFFOUS_C to a new form caused a recompile of something in DEV - a recompile from something that didn't have the error to something that did.

Trouble with this hypothesis is that I can't see any evidence for there being an earlier version of the Form or the custom client program containing the subroutine that blew off (i.e. an arlier version of the Form that called the subroutine with three variables, or an earlier version of the subroutine that read the table only twice.)

[Former Member]

Hi,

please let us know the subroutine code...

Thanks,

Naren

[former_member181923]

NM -

It was a client subroutine written in Spanish to deal with the "proveedor" ("vendor") name. The form was calling the subroutine passing "nombre1" and "nombre2" but not "nombre3". The subroutine was reading "it_salida" (the "exit" control itab) looking for a third row with key name = "nomrbre3".

So I think it was a customer-specific error that won't affect anyone else.

Thanks

Dave

[RichHeilman]

Not sure why it would bomb just because it couldn't find row of the itab. It should have simply set SY-SUBRC to 4 if it didn't get a hit.

Is this what is in the FORM(subroutine)

READ TABLE IT_SALIDA with key Name = 'NOMRBRE3'.

If so, this should not have bombed, simply just set sy-subrc = 4.

Regards,

Rich Heilman