subroutines

Former Member · ‎2007 May 02

Hi Friends,

can any one Explain below this code..

i am confusing about the Using Changing options in this prg.

pls.explain what using doing correctly and also changing doing correctly.

and explain differnece between using and changing...

when we using changing option...

see below code:

DATA: num1 TYPE i,

num2 TYPE i,

sum TYPE i.

num1 = 2. num2 = 4.

PERFORM addit USING num1 num2 CHANGING sum.

num1 = 7. num2 = 11.

PERFORM addit USING num1 num2 CHANGING sum.

FORM addit

USING add_num1 TYPE any

add_num2 TYPE any

CHANGING add_sum TYPE any.

add_sum = add_num1 + add_num2.

PERFORM out USING add_num1 add_num2 add_sum.

ENDFORM.

FORM out

USING out_num1 TYPE any

out_num2 TYPE any

out_sum TYPE any.

WRITE: / 'Sum of', out_num1, 'and', out_num2, 'is', out_sum.

ENDFORM.

rgds,

h_senden2 · ‎2007 May 02

USING is used for input parameters which cannot be changed.

CHANGING is used for input parameter which can be changed and export parameters.

The normal Abap compiler is not that strict and will allow to change USING parameters, but in Abap OO it is not allowed.

regards,

Hans

Please reward all helpful answers !!!!!

Former Member · ‎2007 May 02

hi,

CHNAGING will provide an referece to the variable in main program its like pointer conscept in C so what r the variable u putting in chanign n manupulatin inside the form n enform its changes will be automatically reflected back to main program.

UISNG is like pass by value u r passing the valur from the main prog to the subroutine in the subroutine it wil be stored in an local variable which has life inside subroutine.

if i am wrong somebody correct me....

reward if helpful

ravi

Former Member · ‎2007 May 02

With subroutines ..you are passing the variable value that is assigned to the vaiables just before calling the subroutined...

now why are subroutines for,,,, bascally beacuse you don't have to write the same piece of code again and again...

so using subroutine,,, you are only changing the vaible values and performing the same operation two time....

So, what happening here is that you are passing numc1 and numc2 and changing the value of sum ..ie.e the sum of there two interger variable....

Hope it may help you ...

Regards,

jayant

Former Member · ‎2007 May 02

Hi , have a look at the following data:

Basic form

FORM form [TABLES ...] [USING ...] [CHANGING ...].

Additions:

1. ... TABLES itab1 ... itabn

2. ... USING [VALUE(p1)| p1] ... [VALUE(pn) |pn]

3. ... CHANGING [VALUE(p1(| p1] ... [VALUE(pn) |pn]

Effect

Defines a subroutine called by PERFORM

You can assign a type to the parameters of the subroutine. For details about types of formal parameters, see specifying forms.

Example

PERFORM WELCOME.

FORM WELCOME.

WRITE / 'Hello world'.

ENDFORM.

The subroutine WELCOME called by the PERFORM statement outputs 'Hello world'.

Notes

Subroutines defined by FORM can have parameters and local fields. These parameters and local fields shadow global fields. Their visibility begins at their declaration, and ends at the ENDFORM statement.

Any local fields you declare with DATA after a FORM statement are recreated and initialized for each PERFORM call. When the call has finished, the memory for local fields is released again.

You can define global fields that are only visible within the FORM using the STATICS statement.

You can define global data that you want to use locally within a subroutine using the LOCAL statement after the FORM statement. The values for this data are saved when you enter the subroutine, and released from the stack when you leave it.

FORM statements are not allowed within FORM ... ENDFORM structures (i.e. no nested definitions).

Nested and recursive calls are possible.

The parameters must always be specified in the order TABLES, USING and CHANGING.

Addition 1

... TABLES itab1 ... itabn

Effect

Instead of the TABLES addition, you should use the USING or CHANGING addition wherever possible. You can only use tables with table type STANDARD in the TABLES addition. The internal tables you specify are always passed to the FORM along with their header line. If you pass a table without header line as a TABLES parameter, the system automatically generates a header line for it. This is only valid within the FORM . You should not use any global commands (such as HIDE) on the header line. For details about specifying the type of a TABLES parameter, see specifying types. TABLES parameters are always passed by reference.

Example

TYPES: BEGIN OF T_X,

INCLUDE STRUCTURE SFLIGHT.

TYPES: ADDITION(8) TYPE C,

END OF T_X.

DATA: X TYPE STANDARD TABLE OF T_X WITH NON-UNIQUE DEFAULT KEY

INITIAL SIZE 0,

...

PERFORM U TABLES X.

...

FORM U TABLES X STRUCTURE SFLIGHT.

WRITE: X-FLDATE.

ENDFORM.

Addition 2

... USING [VALUE(p1)|p1] ... [VALUE(pn)|pn]

Effect

Defines formal parameters p1,...pn, which are replaced by actual parameters when the subroutine is called.

You can assign a type to the formal parameters p1, ..., pn (see specifying types). You can also specify the method with which they are passed.

Note

Passing methods:

USING ... p ...

The parameters are passed by reference. The field passed can be changed within the subroutine. The changes are kept beyond the subroutine.

USING ... VALUE(p) ...

The VALUE(...) addition passes the parameter by copying the field contents to a corresponding local field. VALUE parameters behave in the same way as local fields.

Example

TYPES: BEGIN OF FLIGHT_STRUC,

FLCARRID LIKE SFLIGHT-CARRID,

PRICE LIKE SFLIGHT-FLDATE,

END OF FLIGHT_STRUC.

DATA: MY_FLIGHT TYPE TABLE OF FLIGHT_STRUC,

IBOOK1 TYPE TABLE OF SBOOK,

IBOOK2 LIKE TABLE OF IBOOK1,

STRUC TYPE SBOOK.

PERFORM DISPLAY USING MY_FLIGHT IBOOK1 IBOOK2 STRUC.

FORM DISPLAY USING P_ITAB LIKE MY_FLIGHT[]

P_BOOK1 LIKE IBOOK1[]

P_BOOK2 LIKE IBOOK2[]

P_STRU LIKE STRUC.

DATA: L_FLIGHT LIKE LINE OF P_ITAB,

L_CARRID LIKE L_FLIGHT-FLCARRID.

...

WRITE: / P_STRU-CARRID, P_STRU-CONNID.

...

LOOP AT P_ITAB INTO L_FLIGHT WHERE FLCARRID = L_CARRID.

...

ENDLOOP.

ENDFORM.

Addition 3

... CHANGING [VALUE(p1) |(p1)] ... [VALUE(pn) |(pn)]

Effect

The parameters after CHANGING can accept the same specifications as those after USING.

To link the VALUE specification with the change of a parameter value, you can use the addition CHANGING ... . Then, all the formal parameters specified by VALUE(...) are transported back to the actual parameters at the end of the subroutine (i.e. after ENDFORM). If the subroutine is terminated by a dialog message, none of the parameters referenced by CHANGING VALUE ... changes.

Otherwise, the effect of USING and CHANGING is identical.

Example

DATA: NUMBER_1 TYPE I VALUE 1,

NUMBER_2 TYPE I VALUE 2,

TEXT_1(10) VALUE 'one',

TEXT_2(10) VALUE 'two'.

PERFORM CONFUSE USING NUMBER_1

NUMBER_2

TEXT_1

NUMBER_1

TEXT_2.

FORM CONFUSE USING PAR_NUMBER_1 TYPE I

PAR_NUMBER_2 TYPE I

PAR_TEXT_1 TYPE C

VALUE(PAR_V_NUMBER_1) TYPE I

VALUE(PAR_V_TEXT_2) TYPE C.

ADD 3 TO PAR_V_NUMBER_1.

ADD 4 TO PAR_NUMBER_1.

ADD NUMBER_1 TO PAR_NUMBER_2.

TEXT_2 = 'three'.

PAR_TEXT_1 = PAR_V_TEXT_2.

PAR_V_TEXT_2 = 'four'.

ENDFORM.

Field contents after the PERFORM call:

NUMBER_1 = 5

NUMBER_2 = 7

TEXT_1 = 'two'

TEXT_2 = 'three'

Note

In subroutines, you are recommended to use the following procedure:

Pass input parameters as USING parameters and output parameters as CHANGING parameters. If in doubt, pass the parameter by VALUE. You should be particularly careful with passed SY fields. For performance reasons, data objects which contain tables should not be passed by VALUE if at all possible.

You can protect TABLES parameters whose header lines must remain unchanged with LOCAL.

STATICS allows you to create global fields with a local visibility area. In the case of local fields which are initialized on each call, you can replace DATA by STATICS. With frequently called FORM routines, this can lead to a noticeable improvement in performance.

To avoid shadowing problems with parameters, you are recommended to keep to the naming convention for fields in subroutines. You should, for instance, always start FORM parameters with the prefix 'P_' and local fields with the prefix 'L_'.

Regards,

Balakrishna.N

aris_hidalgo · ‎2007 May 02

Hi,

To help you understand better, I have created a simple subroutine for you.


REPORT  z_aris_test_12.

DATA: gv_export1(20) TYPE c VALUE 'Apple',
      gv_export2(20) TYPE c VALUE 'Banana',
      gv_flag        TYPE flag VALUE 'X'.

START-OF-SELECTION.

  PERFORM check_values USING gv_export1 gv_export2
                       CHANGING gv_flag.

*&---------------------------------------------------------------------*
*&      Form  check_values
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->%IMPORT1   text
*      -->%IMPORT2   text
*      -->%FLAG      text
*----------------------------------------------------------------------*
FORM check_values USING %import1 %import2
                  CHANGING %flag.
  IF %import1 <> 'Apple'.
    MOVE space TO %flag.
  ENDIF.

  IF %import2 <> 'Banana'.
    MOVE space TO %flag.
  ENDIF.
ENDFORM.                    "check_values

END-OF-SELECTION.
  IF gv_flag = 'X'.
    WRITE: 'Success!'.
  ELSE.
    WRITE: 'Fail!'.
  ENDIF.

Hope it helps...

P.S. Please award points if it helps...

By Category

Related Content

Activity Groups

Industry Groups

Influence and Feedback Groups

Interest Groups

Location Groups

Customer Only Groups

Forums

Related Resources

Products

Learning and Support

About

My SAP Profile

My SAP Profile

subroutines