how to pass selection option values in subroutine

[Former Member]

i want to pass s_bukrs(select option field) in subroutine like

perform check_compcd using s_burks

form check_compcd using rs_bukrs type ???

• validation code.

endform.

what type i have to use?

[suresh_datti]

You have to pass it as a table..

perform check_compcd tables s_burks.

Regards,

Suresh Datti

[Former Member]

• int_table is your select-options. then execute this.

Perform TheRoutine tables int_table.

[former_member186741]

SAP recommend NOT to use the 'tables' option of forms anymore.

the perform will have to be:

perform check_compcd using s_bukrs[].

the form:

form check_compcd using rs_bukrs like s_bukrs[]. *validation code.

endform.

[Former Member]

Hai Neil Woodruff,

thanks.problem solved..pts given..

perform check_compcd using s_bukrs[].

form check_compcd using rs_bukrs like s_bukrs[].

endform.

[Former Member]

Hi All,

I am having the similar problem but i have declared the subroutine in a include whihc is called in the same program as:

PERFORM get_data using so_date[] so_time[].

and..........

FORM get_data using p_date like so_date[]

p_time like so_time[].

in include......

I am getting an error here: "P_TIME" is a table without a header line and therefore has no component called "LOW".

let me know what wrong at this point?

[Former Member]

Hi Kumar,

U have to create Internal table of Select Otion type(Ranges Table),u can use the following in ur code.

DATA : lit_sel_burks LIKE TABLE OF s_burks.

lit_sel_burks[] = s_burks[].

Or

DATA : lit_sel_burks LIKE TABLE OF s_burks.
  DATA: wa_burks LIKE LINE OF s_burks.                " work area for
                                                         "select option
DATA: wa_sel_burks LIKE LINE OF lit_sel_burks.
  
LOOP AT lv_burks INTO wa_burks.               "looping at select option

    wa_sel_burks-sign = wa_burks-sign.
    wa_sel_burks-option = wa_burks-option.
    wa_sel_burks-low = wa_burks-low.
    wa_sel_mprn-high = wa_mprn-high.

    APPEND wa_sel_burks TO lit_sel_burks.

  ENDLOOP.

that means u have to copy the content of select option to local internal table and then pass it to subroutine.

<b>Close the thread if u got the answer</b>.

Regards,

Ranjit Thakur.

Please Mark The Helpful Answer.

[Former Member]

perform check_compcd tables s_burks.

form check_compcd tables p_burks like s_bukrs.

*--here you can use P_BUKRS as you use S_BUKRS.

endform

[hymavathi_oruganti]

as secet option is internally a table,

u need to pass as table body in both perform and form

perform ..........s_burks[]

form ...........using p_bukrs[]

[Former Member]

select-options s_bukrs for t001-bukrs.

perform chk_compcode using s_bukrs

form chk_compcode using rs_bukrs like s_bukrs.

data i_t001 type standard table of t001 with header line.

select bukrs from t001 into table i_t001

where bukrs in rs_bukrs.

endform.

getting invalid in operator error..

so how to use s_bukrs in perform statement

[Former Member]

Kumar,

Do this

form chk_compcode using rs_bukrs like s_bukrs type ranges.

you will have to indicate that the parameter is of RANGES / SELECT-OPTIONS type.

Regards,

Ravi

Note : Please mark the helpful answers

[former_member186741]

Kumar,

when you pass s_bukrs without the [], it is interpreted as sending the header line as a parameter NOT the whole table. If you want to operate on the select option as a TABLE use this:

the perform will have to be:

perform check_compcd using s_bukrs[].

the form:

form check_compcd using rs_bukrs like s_bukrs[]. *validation code.

endform.

[Former Member]

Hi kumar,

1. Simple

2. Make this minor corrections in your program.

3. See bold.

4.

report abc.

tables : t001.

select-options s_bukrs for t001-bukrs.

perform chk_compcode <b>tables s_bukrs.</b>

*----

---

• FORM

*----

---

form chk_compcode <b>tables rs_bukrs structure RSOBUKRS.</b>

data i_t001 type standard table of t001 with header line.

select bukrs from t001 into table i_t001

where bukrs in rs_bukrs.

endform. "

regards,

amit m.

[Former Member]

Hi Kumar,

please check this code it is working fine.....

tables : t001.
select-options s_bukrs for t001-bukrs.

*select option ranges table
TYPES : BEGIN OF ty_sel_bukrs,
         sign(1) TYPE c ,
         option(2) TYPE c,
         low  LIKE t001-bukrs,
         high LIKE t001-bukrs,
      END OF ty_sel_bukrs.

*work area for ranges table
DATA : wa_sel_bukrs TYPE ty_sel_bukrs.
DATA : lit_sel_bukrs LIKE TABLE OF wa_sel_bukrs.

 LOOP AT lit_sel_bukrs INTO wa_sel_bukrs.               "looping at
*select option

    wa_sel_bukrs-sign = s_bukrs-sign.
    wa_sel_bukrs-option = s_bukrs-option.
    wa_sel_bukrs-low = s_bukrs-low.
    wa_sel_bukrs-high = s_bukrs-high.

    APPEND wa_sel_bukrs TO lit_sel_bukrs.

  ENDLOOP.

perform chk_compcode using lit_sel_bukrs.


form chk_compcode using rs_bukrs like  lit_sel_bukrs.

data i_t001 type standard table of t001 with header line.
select bukrs from t001 into table i_t001
where bukrs in rs_bukrs.

endform.

OR SIMPLY USE THIS,

tables : t001.
select-options s_bukrs for t001-bukrs.

DATA : lit_sel_bukrs LIKE TABLE OF s_bukrs.
lit_sel_bukrs[] = s_bukrs[].

perform chk_compcode using lit_sel_bukrs.


form chk_compcode using rs_bukrs like  lit_sel_bukrs.

data i_t001 type standard table of t001 with header line.
select bukrs from t001 into table i_t001
where bukrs in rs_bukrs.
break-point.
endform.

Regards,

Ranjit Thakur.

Please Mark The Helpful Answer.

<b></b>

[Former Member]

Hai Kumar

Check the following Document & Examples

1. ... TABLES itab1 ... itabn

2. ... USING p1 ... pn

3. ... CHANGING p1 ... pn

Effect

Defines a subroutine called by PERFORM

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. 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. FORM statements are not allowed within FORM ... ENDFORM structures (i.e. no nested definitions). Nested and recursive calls are possible. The optional parameters must always be specified in the order TABLES , USING and CHANGING .

Addition 1

... TABLES itab1 ... itabn

Effect

TABLES allows you to pass internal tables with or without header lines to subroutines. For information about assigning types TABLES parameters, see Type assignment . TABLES parameters are passed by reference.

Example

DATA: BEGIN OF X.

INCLUDE STRUCTURE SFLIGHT.

DATA: ADDITION(8) TYPE C,

END OF X.

...

PERFORM U USING X.

...

FORM U USING X STRUCTURE SFLIGHT.

WRITE: X-FLDATE.

ENDFORM.

Example

TYPES: BEGIN OF FLIGHT_STRUC,

FLCARRID LIKE SFLIGHT-CARRID,

PRICE LIKE SFLIGHT-FLDATE,

END OF FLIGHT_STRUC.

DATA: MY_FLIGHT TYPE FLIGHT_STRUC OCCURS 0 WITH HEADER LINE,

IBOOK1 LIKE SBOOK OCCURS 0 WITH HEADER LINE,

IBOOK2 LIKE IBOOK1 OCCURS 0,

STRUC LIKE SBOOK.

PERFORM DISPLAY TABLES MY_FLIGHT IBOOK1 IBOOK2 USING STRUC.

FORM DISPLAY TABLES P_ITAB LIKE MY_FLIGHT[]

P_BOOK1 LIKE IBOOK1[]

P_BOOK2 LIKE IBOOK2[]

USING P_STRU LIKE STRUC.

DATA L_CARRID LIKE P_ITAB-FLCARRID.

...

WRITE: / P_STRU-CARRID, P_STRU-CONNID.

...

LOOP AT P_ITAB WHERE FLCARRID = L_CARRID.

...

ENDLOOP.

...

ENDFORM.

Addition 2

... USING p1 ... pn

Effect

Defines the formal parameters p1 ,... pn which are replaced by actual parameters when you call the subroutine.

The formal parameters p1 ,... pn can have a particular type (see Type assignment ). You can also specify the transfer type (i.e. how you want to pass them).

Note

Transfer types: USING ... p ...

Transfer is by reference. This means you can change the transferred field continually in the subroutine.

USING ... VALUE(p) ...

When you specify VALUE(...) , transfer is by value, i.e. the field contents are passed to the relevant local field. VALUES parameters thus behave in the same way as local fields.

Addition 3

... CHANGING p1 ... 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 heasder 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 convnetion for fields in subroutines. You should, for instance, always start FORM parameters with the prefix 'P_' and local fields with the prefix 'L_' .

1. PERFORM form.

2. PERFORM form(prog).

3. PERFORM form IN PROGRAM prog.

4. PERFORM n OF form1 form2 form3 ... .

5. PERFORM n ON COMMIT.

Variant 1

PERFORM form.

Additions

1. ... USING p1 p2 p3 ...

2. ... CHANGING p1 p2 p3 ...

3. ... TABLES itab1 itab2 ...

Effect

Calls the subroutine form specified in the FORM statement. On completion, processing in the main program resumes.

Example

PERFORM HELP_ME.

...

FORM HELP_ME.

...

ENDFORM.

The PERFORM statement calls the subroutine HELP_ME .

Notes

Nested calls are allowed (i.e. PERFORM within a FORM ... ENDFORM ).

Recursive calls are also possible.

To define local data, use the DATA statement after FORM . Each time you enter the subroutine, the data is recreated (with an initial value) and released at the end (from the stack).

To define global data used within a subroutine, use the LOCAL statement after FORM . The values are saved when you enter the subroutine and then released at the end (from the stack).

Note

Runtime errors

PERFORMANCE_PARAMETER_MISSING : The called form expects more parameters than were specified.

PERFORM_PARAMETER_COUNT ,

PERFORM_TOO_MANY_PARAMETERS : More parameters were given than

the FORM expected.

PERFORM_CONFLICT_TYPE ,

PERFORM_CONFLICT_GENERIC_TYPE ,

PERFORM_BASE_WRONG_ALIGNMENT ,

PERFORM_PARAMETER_TOO_SHORT ,

PERFORM_TABLE_REQUIRED : The parameter type does not match the type specified in the FORM definition.

PERFORM_BASE_LITL : A literal was passed to a structured parameter.

Addition 1

... USING p1 p2 p3 ...

Addition 2

... CHANGING p1 p2 p3 ...

Effect

These additions are equivalent to each other. For documentation reasons however, you should use the same one as with the associated FORM definition.

Both additions pass the parameters p1 p2 p3 ... to the called subroutine. You can use as many parameters as you like.

Sequence is important here because the first parameter of the PERFORM call is passed to the first parameter of the FORM definition, the second to the second and so on.

You can use the following as parameters:

DATA fields (see DATA )

Field strings (see DATA BEGIN OF )

Literals

Field symbols (see FIELD-SYMBOLS )

Parameter offset and length can be passed as variables. The addition ' ...USING p1+off(*) ' causes parameter p1 to be passed with offset off so that the field limits of p1 are not exceeded.

Example

DATA: NUMBER_I TYPE I VALUE 5,

NUMBER_P TYPE P VALUE 4,

BEGIN OF PERSON,

NAME(10) VALUE 'Paul',

AGE TYPE I VALUE 28,

END OF PERSON,

ALPHA(10) VALUE 'abcdefghij'.

FIELD-SYMBOLS .

ASSIGN NUMBER_P TO .

PERFORM CHANGE USING 1

NUMBER_I

NUMBER_P

PERSON

ALPHA+NUMBER_I().

FORM CHANGE USING VALUE(PAR_1)

PAR_NUMBER_I

PAR_NUMBER_P

PAR_POINTER

PAR_PERSON STRUCTURE PERSON

PAR_PART_OF_ALPHA.

ADD PAR_1 TO PAR_NUMBER_I.

PAR_NUMBER_P = 0.

PAR_PERSON-NAME+4(1) = ALPHA.

PAR_PERSON-AGE = NUMBER_P + 25.

ADD NUMBER_I TO PAR_POINTER.

PAR_PART_OF_ALPHA = SPACE.

ENDFORM.

Field contents after the PERFORM call are as follows:

NUMBER_I = 6

NUMBER_P = 6

= 6

PERSON-NAME = 'Paula'

PERSON-AGE = 25

ALPHA = 'abcde j'

Note

The field type and length of the parameters remain. If parameter values change within the subroutine, these new values remain after you leave the subroutine. However, this does not apply to parameters passed with VALUE (see FORM ).

If you pass literals, you must either leave them unchanged or pass them in the FORM definition with the USING VALUE statement.

Addition 3

... TABLES itab1 itab2 ...

Effect

You use TABLES to pass internal tables to subroutines.

Example

DATA: BEGIN OF ITAB OCCURS 100,

TEXT(50),

NUMBER TYPE I,

END OF ITAB.

STRUC LIKE T005T.

...

PERFORM DISPLAY TABLES ITAB

USING STRUC.

FORM DISPLAY TABLES PAR_ITAB STRUCTURE ITAB

USING PAR STRUCTURE T005T.

DATA LOC_COMPARE LIKE PAR_ITAB-TEXT.

WRITE: / PAR-LAND1, PAR-LANDX.

...

LOOP AT PAR_ITAB WHERE TEXT = LOC_COMPARE.

...

ENDLOOP.

...

ENDFORM.

Within the subroutine DISPLAY , you can apply all the available table operations to the internal tables passed.

Note

TABLES must always appear first in the PERFORM call. It must not be preceded by an addition.

Variant 2

PERFORM form(prog).

Additions

1. ... USING p1 p2 p3 ...

2. ... CHANGING p1 p2 p3 ...

3. ... TABLES itab1 itab2 ...

4. ... IF FOUND

Effect

Calls the subroutine form defined in the program prog (i.e. external PERFORM ).

Notes

Parameter passing to the external subroutine is the same as in variation 1.

Parameter passing can be implemented by using a common data area (see DATA BEGIN OF COMMON PART ).

Nested calls are possible, even with several external subroutines from different programs.

If you call a subroutine of a program prog , the system loads the program prog

Note

Runtime errors

PERFORM_NOT_FOUND : The subroutine specified was not found.

Addition 1

... USING p1 p2 p3 ...

Effect

See addition 1 of variation 1.

Addition 2

... CHANGING p1 p2 p3 ...

Effect

See addition 2 of variation 1.

Addition 3

... TABLES itab1 itab2 ...

Effect

See addition 3 of variation 1.

Addition 4

... IF FOUND

Effect

Calls the specified subroutine only if it already exists. Otherwise, the statement is ignored.

Notes

If the program specified is not available or incorrect, a runtime error is output.

The only way of determining whether the specified routine existed (in an available program) is by writing your own program (e.g. by setting a flag that is passed to the subroutine).

Variant 3

PERFORM form IN PROGRAM prog.

Additions

1. ... USING p1 p2 p3 ...

2. ... CHANGING p1 p2 p3 ...

3. ... TABLES itab1 itab2 ...

4. ... IF FOUND

Effect

Similar to variation 2 (external PERFORM ), except that here you can specify both the subroutine and the program dynamically (at runtime); in this case, you must enclose the variables form or prog in parentheses. If you omit specification of the program after IN PROGRAM , ABAP/4 searches for the routine in the current program.

Example

DATA: RNAME(30) VALUE 'WRITE_STATISTIC',

PNAME(8) VALUE 'ZYX_STAT'.

PERFORM WRITE_STATISTIC(ZYX_STAT).

PERFORM (RNAME) IN PROGRAM ZYX_STAT.

PERFORM WRITE_STATISTIC IN PROGRAM (PNAME).

PERFORM (RNAME) IN PROGRAM (PNAME).

All four of the above PERFORM statements have the same effect, i.e. they call the subroutine 'WRITE_STATISTIC' defined in the program 'ZYX_STAT' .

Note

This dynamic PERFORM requires more CPU time, since the system has to search for the subroutine each time.

Addition 1

... USING p1 p2 p3 ...

Effect

See addition 1 of variation 1.

Addition 2

... CHANGING p1 p2 p3 ...

Effect

See addition 2 of variation 1.

Addition 3

... TABLES itab1 itab2 ...

Effect

See addition 3 of variation 1.

Addition 4

... IF FOUND

Effect

Calls the specified subroutine only if it already exists. Otherwise, the statement is ignored.

Variant 4

PERFORM n OF form1 form2 form3 ... .

Effect

Drives a subroutine specified by the index n from a list of subroutine names listed in the statement. At runtime, the variable n must contain a value between 1 (first name) and the total number of subroutines specified (last name). Up to 256 subroutine names are possible.

Note

Runtime errors

PERFORM_INDEX_0 : The index specified was too small.

PERFORM_INDEX_NEGATIVE : The index specified was negative.

PERFORM_INDEX_TOO_LARGE : The index specified was too large.

Variant 5

PERFORM n ON COMMIT

Addition

1. ... LEVEL level

Effect

Executes the specified subroutine when a COMMIT WORK occurs. This allows you to execute a subroutine only if the logical transaction has ended successfully. The subroutine is not executed until the key word COMMIT WORK is called. FORMs specified several times are executed only once on COMMIT WORK (see COMMIT WORK ).

If you call ROLLBACK WORK , you delete all the specified routines.

Note

With PERFORM ... ON COMMIT , you cannot transfer any data with USING/CHANGING . To do this, you must either store the data in global variables or store it temporarily with EXPORT ... TO MEMORY .

Addition 1

... LEVEL level

Effect

The addition LEVEL , followed by a field, defines the order in which the subroutines are executed after COMMIT WORK . They are called in ascending order of level. If there is no addition LEVEL , the subroutine always has the level zero. If the level is the same, the order of calls determines the order of execution. Level assignment occurs during development, e.g. by defining constants in an include program. The level must be of type I.

Thanks & regards

Sreenivasulu P