topic Re: Dynamic Field-Symbol assignment - Short Dump in Application Development and Automation Discussions

Dynamic Field-Symbol assignment - Short Dump

aabhas_wilmar — Fri, 08 Aug 2008 07:50:33 GMT

Create three programs as mentioned:

REPORT zforms.

*&---------------------------------------------------------------------*
*&      Form  form_fs_assign
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
FORM form_fs_assign.
  FIELD-SYMBOLS <fs> TYPE table.
  DATA: fs_itab LIKE STANDARD TABLE OF tab_matnr WITH HEADER LINE.
  break-point.
  ASSIGN ('(ZPROGRAM1)ITAB[]') TO <fs>.
  IF sy-subrc EQ 0.
    fs_itab[] = <fs>[].
    LOOP AT fs_itab.
      WRITE / fs_itab-matnr.
    ENDLOOP.
  ELSE.
    Write:/ sy-repid, 'field-symbol not assigned'.
  ENDIF.
ENDFORM.                    "form_fs_assign

*----

REPORT zprogram1.

DATA: itab LIKE STANDARD TABLE OF tab_matnr WITH HEADER LINE.
itab-matnr = '1111'.
APPEND itab.
itab-matnr = '2222'.
APPEND itab.
WRITE:/ sy-repid.
PERFORM form_fs_assign IN PROGRAM zforms.
SUBMIT zprogram2.

*----

REPORT zprogram2.

break-point.

*-- enter (ZPROGRAM1)ITAB[] in the variable and press enter
* the yellow icon stating that it doesn't exist appears
* but when the following form is called, it does checks
* the <fs> assign and doesnt gives any runtime error
* while in Pricing routine, the similar situation
* does gives the error

PERFORM form_fs_assign IN PROGRAM zforms.

*----

*Execute zprogram1 and debug, works fine..*

*Execute zprogram2, (ZPROGRAM1)ITAB[] doesn't exist, still it doesn't leads to short dump*

*BUT, a very similar situation in a Pricing Requirment Routine leads to a short dump:*

*Runtime Error GETWA_NOT_ASSIGNED*

*ShrtText Field symbol has not yet been assigned.*

*Pricing Routine Code Snippet:*

*-- {3. -

determine qualifying prior invoices in memory----

FIELD-SYMBOLS: <fs_vbrk> TYPE table.
            FIELD-SYMBOLS: <fs_vbpa> TYPE table.
            FIELD-SYMBOLS: <fs_komv> TYPE table.

            DATA g_it_vbrk LIKE STANDARD TABLE OF vbrkvb WITH HEADER LINE.
            DATA g_it_vbpa LIKE STANDARD TABLE OF vbpavb WITH HEADER LINE.
            DATA g_it_komv LIKE STANDARD TABLE OF konv WITH HEADER LINE.

            DATA: l_vbrk_lines TYPE i.

            ASSIGN ('(SAPLV60A)XVBRK[]') TO <fs_vbrk>. <- "Error occurs here
            ASSIGN ('(SAPLV60A)XVBPA[]') TO <fs_vbpa>.
            ASSIGN ('(SAPLV60A)XKOMV[]') TO <fs_komv>.

            g_it_vbrk[] = <fs_vbrk>.
            g_it_vbpa[] = <fs_vbpa>.
            g_it_komv[] = <fs_komv>.

            DESCRIBE TABLE g_it_vbrk LINES l_vbrk_lines.
            READ TABLE g_it_vbrk INDEX l_vbrk_lines.
** remember to make vkorg and vtweg check for vbrk invoices
            DELETE g_it_vbrk WHERE vbeln = g_it_vbrk-vbeln.
            DELETE g_it_vbpa WHERE vbeln = g_it_vbrk-vbeln OR parvw <> 'WE'.
            DELETE g_it_komv WHERE knumv = g_it_vbrk-vbeln OR kschl <> 'ZF02' OR kbetr = 0.

Re: Dynamic Field-Symbol assignment - Short Dump

Former Member — Sat, 09 Aug 2008 04:55:59 GMT

Hi Aabhas,

Have a look at note 721297. This might resolve the issue.

It looks like incomplete customising

or ...

Then download the Short dump and create a help message with SAP and attach the Short dump.

Also...

Look at Note 862548 - GETWA_NOT_ASSIGNED Dump in cvse_customizing.

I got this from this thread...

http://service.sap.com/notes on the specific package file.

Mohinder

Re: Dynamic Field-Symbol assignment - Short Dump

matt — Mon, 11 Aug 2008 08:07:30 GMT

You don't get this dump when an assign fails. You only get it when you try to access an unassigned field-symbol. Try this code, and tell me if the problem goes away.

FIELD-SYMBOLS: <fs_vbrk> TYPE table.
            FIELD-SYMBOLS: <fs_vbpa> TYPE table.
            FIELD-SYMBOLS: <fs_komv> TYPE table.
 
            DATA g_it_vbrk LIKE STANDARD TABLE OF vbrkvb WITH HEADER LINE.
            DATA g_it_vbpa LIKE STANDARD TABLE OF vbpavb WITH HEADER LINE.
            DATA g_it_komv LIKE STANDARD TABLE OF konv WITH HEADER LINE.
 
            DATA: l_vbrk_lines TYPE i.
 
            ASSIGN ('(SAPLV60A)XVBRK[]') TO <fs_vbrk>. <- "Error occurs here
            ASSIGN ('(SAPLV60A)XVBPA[]') TO <fs_vbpa>.
            ASSIGN ('(SAPLV60A)XKOMV[]') TO <fs_komv>.

* Add this code block
            IF <fs_vbrk> IS NOT ASSIGNED OR <fs_vbpa> IS NOT ASSIGNED OR <fs_komv> IS NOT ASSIGNED.
              EXIT.
            ENDIF.

            g_it_vbrk[] = <fs_vbrk>.
            g_it_vbpa[] = <fs_vbpa>.
            g_it_komv[] = <fs_komv>.
...

Re: Dynamic Field-Symbol assignment - Short Dump

aabhas_wilmar — Mon, 11 Aug 2008 15:29:57 GMT

Thanks for the reply Matthew.

I have tried the checks u mentioned, in fact i tried both the possible checks,,,

IF <fs_vbrk> IS NOT ASSIGNED.
  EXIT.
ENDIF.

and

IF sy-subrc NE 0.
  EXIT.
ENDIF.

As mentioned, the error occurs in the ASSIGN statement:

ASSIGN ('(SAPLV60A)XVBRK[]') TO <fs_vbrk>. <- "Run-time error occurs here
IF <fs_vbrk> IS NOT ASSIGNED.
  EXIT.
ENDIF

It doesn't goes to the IF statement, the short dump occurs just before it.

Ref thread:

SD-Pricing Routines - Invoice Split - Field Symbols Issue]

for actual scenario...

Thanks...

Re: Dynamic Field-Symbol assignment - Short Dump

RichHeilman — Mon, 11 Aug 2008 15:39:47 GMT

Not sure why you are getting a dump when assigning, it should simply set SY-SUBRC to 4. Anyway, you might want to try this instead, and see if the ASSIGN is successful.

FIELD-SYMBOLS: <fs_vbrk> TYPE table.

            data: Lv_itabname type string.

            lv_itabname = '(SAPLV60A)XVBRK[]'.
 
            ASSIGN (lv_itabname) TO <fs_vbrk>.

Regards,

Rich Heilman

Re: Dynamic Field-Symbol assignment - Short Dump

naimesh_patel — Mon, 11 Aug 2008 16:30:14 GMT

XVBRK is not declared globally in the program SAPLV60A, which is a function group V60A.

XVBRK is part of the TABLES parameters of the FM inside this function group. and I don't think we can access to the Function modules' parameter by ASSIGNING to the field symbol. This would work fine if XVBRK would have been global table (declared in LV60ATOP).

I think you have to think on different way, instead of trying to access the parameter of FM.

Regards,

Naimesh Patel

Re: Dynamic Field-Symbol assignment - Short Dump

matt — Mon, 11 Aug 2008 17:29:37 GMT

hmm. Very odd. I'll be interested in knowing what the answer is, but I can't think of anything else to try.

matt

Re: Dynamic Field-Symbol assignment - Short Dump

former_member190578 — Tue, 12 Aug 2008 00:32:33 GMT

ASSIGN ('(ZPROGRAM1)ITAB[]') TO <fs>.

ZPROGRAM 1 can't work in ZPROGRAM 2

IN program Zprogram1:

PERFORM form_fs_assign IN PROGRAM zforms. NO Error

SUBMIT zprogram2. Error, because your "Pointer" to point on "Zprogram1"

You know? Your assign so called in Germany "dirty assign"

Edited by: Jürgen Hartwig on Aug 12, 2008 2:38 AM

Re: Dynamic Field-Symbol assignment - Short Dump

former_member190578 — Tue, 12 Aug 2008 00:42:44 GMT

XVBRK is not declared globally in the program SAPLV60A, which is a function group V60A.

For globally declared variables or tables you don't need this "dirty assign".

I suppose the coding

ASSIGN ('(SAPLV60A)XVBRK[]') TO <fs_vbrk>. <- "Error occurs here

is on the wrong place.

Edited by: Jürgen Hartwig on Aug 12, 2008 2:44 AM

Re: Dynamic Field-Symbol assignment - Short Dump

aabhas_wilmar — Tue, 12 Aug 2008 02:16:15 GMT

Hello friends,

Rich,

The piece of code you suggested didn't work, and still led to the short dump.

Naimesh,

I agree that XVBRK is not declared globally, and if it is a Table, and declared as global work area using Tables, we could have used it directly using ASSIGN (VBRK)...

But, since its not the case, I am not able to do so...

Still, my requirement remains the same. I have to get the invoices created (in memory) but not saved during a collective billing run.

And the required data is available in the (SAPLV60A)XVBRK internal table, from which I am able to retrieve it for the first time, but clicking on the conditions tab in the item details leads to this short dump, becs (SAPLV60A)XVBRK[] isn't available at that moment. Still, if it is not available I suppose it should just set the sy-subrc to 4 instead of ending into a short-dump.

Jürgen Hartwig,

I know ZPROGRAM 1 can't work in ZPROGRAM 2, but it doesnt leads to the short dump either, does it? But in case of pricing it gives the run time error, this is exception I want to handle!

XVBRK is not declared globally, but since SAPLV60A calls a perform in SAPLV61A, it remains in the ABAP stack and we can access it using (SAPLV60A)XVBRK[] kind of assignment.

When the same is called during Item Conditions display, its PBO is in the stack but not other forms (in which it might have defined).

Rich, is there a way to get all the variables available in scope at any instance during runtime?

Well, Jürgen, I though it Germany it was called "schmutzig zuweisen" :-)... by the way, the same method has been used at several places in standard SAP programs with the sy-subrc check.

Reference Data:

when the assignment happens successfully, the ABAP Stack looks similar to:

Call | Program | Subroutine

10 | SAPLV61A | some_subrountine

09 | SAPLV61A | some_subrountine

08 | SAPLV61A | some_subrountine

07 | SAPLV60A | some_subrountine

06 | SAPLV60A | some_subrountine

05 | SAPLV60A | some_subrountine

04 | SAPLV60A | some_subrountine

03 | SAPLV60A | some_subrountine

02 | SAPLV60A | some_XKOMV_AUBE..subrountine

01 | SAPLV60A | PAI_some_subrountine

when the assignment doesnt happens, the ABAP Stack looks similar to:

04 | SAPLV61A | some_subrountine

03 | SAPLV61A | some_subrountine

02 | SAPLV61A | some_subrountine

01 | SAPLV60A | PBO_some_subrountine

Re: Dynamic Field-Symbol assignment - Short Dump

former_member190578 — Tue, 12 Aug 2008 02:44:18 GMT

Maybe try LIKE this, it works in my (other) program

....TYPE ANY..... or ANY TABLE ????

CONSTANTS:

c_xlikp(32) TYPE c VALUE '(SAPMV50A)XLIKP',

c_xlips(32) TYPE c VALUE '(SAPMV50A)XLIPS[]'.

FIELD-SYMBOLS:

TYPE ANY, "Structure

TYPE ANY TABLE. "Table

ASSIGN (c_xlikp) TO .

Edited by: Jürgen Hartwig on Aug 12, 2008 4:44 AM

Text formatting

Edited by: Jürgen Hartwig on Aug 12, 2008 4:46 AM

Re: Dynamic Field-Symbol assignment - Short Dump

aabhas_wilmar — Tue, 12 Aug 2008 03:38:24 GMT

I tried it Jürgen with no luck... same run-time error!

I guess the problem is not with the TYPE becs it works fine on the first shot, the problem is with the existance of the data in scope... Should there be any means by which we could have checked the existance, the error could have been handled...

I guess SAP work debugger has that mechanism to know if a variable exists or not... like it shows the status using yellow icon stating that the variable doesn't exists when we put it in the variable list.

In classical debugger the structure ABDBG contains this sort of data... but its an structure not the table...

Well, I guess I m going to deep into ABAP, while problem lies at the higher level itself...

By the way I have a solution to my problem of avoiding the dump, but that will be worst of the coding... still it will work fine! And that solution is cheking the system variable:

SY-DYNGR = 'LIST' means the first screen

SY-DYNGR = 'ITEM' means the item screen (where assignment gives the error)

By writing the following code:

IF SY-DYNGR = 'LIST'.
"Assign field-symbols here
ENDIF.

I can avoid the run-time error... but this will be more dirty code... I can use several other system variables as well...

Reference Data:

__System variable__|______Value when no error____|_____Value when error occurs_____

SYCALLD_________|___X______________________|___X__________________________

SYDYNNR________|___102_____________________|___6002_______________________

SYDYNGR________|___LIST____________________|___ITEM_______________________

SYPFKEY________|___SM_____________________|___TPKO_______________________

SYUCOMM_______|___________________________|___PFKO_______________________

SYTITLE__________|___Create Billing Document___|___Invoice_(F2) Create: Item Data____

SYCPROG________|___SAPMV60A_____________|___SAPMV60A___________________

SYXPROG________|___SAPCNVE______________|___SAPCNVE____________________

SYMSGID________|___KM_____________________|________________________________

SYMSGTY________|___E______________________|___E____________________________

SYMSGNO________|___452____________________|___452__________________________

SYMSGV1_________|___PGLA_________________|___PGLA_________________________

Re: Dynamic Field-Symbol assignment - Short Dump

former_member190578 — Tue, 12 Aug 2008 04:36:37 GMT

Do you exactly try this with using STRING or CONSTANTS????


data: Lv_itabname type string.
 
            lv_itabname = '(SAPLV60A)XVBRK[]'.
 
            ASSIGN (lv_itabname) TO <fs_vbrk>.

or this....


CONSTANTS:
c_xlips(32) TYPE c VALUE '(SAPMV50A)XLIPS[]'.

<fs_xlips> TYPE ANY TABLE. "Table

ASSIGN (c_xlips) TO <fs_xlips>.

Maybe this "direct-assign" doesn't work???



ASSIGN ('(SAPLV60A)XVBRK[]') TO <fs_vbrk>. <- "Error occurs here

Edited by: Jürgen Hartwig on Aug 12, 2008 6:37 AM

Edited by: Jürgen Hartwig on Aug 12, 2008 6:38 AM

Re: Dynamic Field-Symbol assignment - Short Dump

aabhas_wilmar — Tue, 12 Aug 2008 05:14:14 GMT

Jürgen... no luck even this time! I tried with constant, with string and with a beer too 😜 it didn't work!

How about finding a way to get all the variables available in scope at any instance during runtime?

As the debugger has that mechanism to know if a variable exists or not.

It shows the status using yellow icon stating that the variable doesn't exists when we put it in the variable list.

regards,

Aabhas K Vishnoi

Re: Dynamic Field-Symbol assignment - Short Dump

aabhas_wilmar — Mon, 25 Aug 2008 08:08:38 GMT

Problem solved!!

Solution: Delete the statements which cause problems

Well, a workaround worked...

I used the exit in RV60AFZZ to Export the internal tables XVBRK, XVBPA and XKOMV using the EXPORT ... TO MEMORY ID 'XXXXX' command, and imported the same in my routine using the IMPORT ... FROM MEMORY ID 'XXXXX'.

It worked well, I thought of implementing this earlier... but... all laziness!

Still, the question remains in place, why ABAP leads to the short-dump!!

Regards,

Aabhas K Vishnoi

Re: Dynamic Field-Symbol assignment - Short Dump

Former Member — Thu, 24 Mar 2016 17:53:17 GMT

This is a very old thread, but I just solved a similar issue. Some of my explanation has been discussed already, but I will recap anyway. The problem, in my case, was that the object I was trying to assign was recognized but just did not exist at that moment. If you put a stop point and run your debugger, look at the ABAP stack (“Desktop 2” while in the debugger). When the program you are trying to refer back to (i.e. SAPLV60A) is not in that list, you will not be able to assign your field symbol. Now you are thinking that I am overstating the obvious at this point, but stay with me. Add the object to your variables in the “Desktop 1” …don’t forget to include the brackets “(SAPLV60A)”. If the object is not in your ABAP stack, the value will be blank and the status column should be either a squiggly line “Invalid Variable” or a bell “Not Assigned”. If the object is invalided, the assign command will simply return a sy-subrc value of 0 and continue, however, if the object is not assigned, the program will dump at the assign statement. Therefore you can simply check that the object exists in the ABAP stack before the assignment of the field symbol. Try something like this:

field-symbols: <fs> type vbrkvb.

data fld1(15) type c value '(SAPLV60A)XVBRK'.

data lt_callstack type abap_callstack.

data la_callstack type abap_callstack_line.

call function 'SYSTEM_CALLSTACK'

exporting max_level = 0

importing callstack = lt_callstack.

read table lt_callstack into la_callstack with key mainprogram = 'SAPMV60A'.

if sy-subrc = 0.

assign (fld1) to <fs>.

else.

exit.

endif.