hi

[Former Member]

subroutines overview briefly

[Former Member]

Hi Vinay,

WELCOME TO SDN

Subroutines are procedures that you can define in any ABAP program and also call from any program. Subroutines are normally called internally, that is, they contain sections of code or algorithms that are used frequently locally. If you want a function to be reusable throughout the system, use a function module.

Defining Subroutines

A subroutine is a block of code introduced by FORM and concluded by ENDFORM.

FORM <subr> [USING ... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ]

[CHANGING... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ].

...

ENDFORM.

<subr> is the name of the subroutine. The optional additions USING and CHANGING define the parameter interface. Like any other processing block, subroutines cannot be nested. You should therefore place your subroutine definitions at the end of the program, especially for executable programs (type 1). In this way, you eliminate the risk of accidentally ending an event block in the wrong place by inserting a FORM...ENDFORM block.

Calling Subroutines

You call subroutines using the statement

PERFORM... [USING ... <pi>... ]

[CHANGING... <pi>... ].

Subroutines can call other subroutines (nested calls) and may also call themselves (recursive calls). Once a subroutine has finished running, the calling program carries on processing after the PERFORM statement. You can use the USING and CHANGING additions to supply values to the parameter interface of the subroutine.

Please check this link

http://help.sap.com/saphelp_46c/helpdata/en/9f/db975c35c111d1829f0000e829fbfe/content.htm

reward if helpful

raam

[Former Member]

hi,

Subroutines are procedures that you can define in any ABAP program and also call from any program. Subroutines are normally called internally, that is, they contain sections of code or algorithms that are used frequently locally. If you want a function to be reusable throughout the system, use a function module.

http://help.sap.com/saphelp_nw04/helpdata/en/9f/db975c35c111d1829f0000e829fbfe/content.htm

Hope ths helps, Do reward.

[Former Member]

Hi,

Please refer below documentation, direct extract from SAP Help (abapdocu).

This statement calls the subroutine specified with the name subr_identifier and assigns the actual parameters specified in parameter_list to the formal parameters of the subroutine.

The name subr_identifier can be specified as follows, with subr as the name of the subroutine declared in FORM and prog as the name of an ABAP program. sname and pname are character-like fields that contain the name of a subroutine or program while the statement is being executed.

subr

If you specify subr, the system calls any subroutine of the same program. The subroutine must exist.

{subr|(sname)} IN PROGRAM [prog|(pname)] [IF FOUND]

This statement calls any subroutine of another program or the current program. The subroutine and the program can either be specified statically as subr and prog (static external subroutine call) or dynamically in the character-like fields in parentheses, sname and pname. sname and pname must contain the names of a subroutine or program in block capitals when the statement is executed (dynamic external subroutine call). If you do not make an entry afer IN PROGRAM, the system searches for the subroutine in the current program.

If the addition IF FOUND is not specified and the system is unable to find the specified subroutine or program, an untreatable exception is created.

If the addition IF FOUND is specified and the specified program does not exist, the system ignores the PERFORM statement. If the specified program does exist, it is loaded into the internal session, if necessary, and the system searches for the specified subroutine without triggering the event LOAD-OF-PROGRAM. If the subroutine exists, the event LOAD-OF-PROGRAM is triggered, if this has not already happened, and the subroutine is then executed.

n OF subr1 subr2 ...

This statement selects a subroutine subr in the same program from a list. The list subr1 subr2 ... can contain up to 256 subroutines specified directly. For n, you must specify a numeric data object that contains a number between 1 and the number of subroutines specified when executed. The system calls the subroutine subr, for which the list item i is contained in n. You cannot specify parameter_list for this variant and you can only call subroutines without a parameter interface.

subr(prog) [IF FOUND]

With this specification, a subroutine subr of a program prog is directly specified. If the specified subroutine or program does not exist and the addition IF FOUND is specified, the PERFORM statement is ignored. Otherwise, the system creates an untreatable exception.

Note

Since the direct program name prog is specified in parentheses instead of a character-like field for the specification subr(prog) [IF FOUND], this form of the name subr_identifier is only allowed outside classes. Instead, you must use the specification with the addition IN PROGRAM.

Thanks,

Sriram Ponna.

[prasanth_kasturi]

hi

A subroutine is a reusable section of code. It is like a mini-program that can be called from another point in your program. Within it you can define variables, execute statements, compute results, and write output. To define a subroutine, use the form statement to indicate the start of a subroutine, and use endform to indicate the end of the subroutine. The name of a subroutine cannot exceed 30 characters.

To call a subroutine, use the perform statement.

Listing 17.6 provides a sample program that defines and calls a subroutine.

-

---

Listing 17.6 Defining and Calling a Subroutine

1 report ztx1706.

2

3 write: / 'Before call 1'.

4 perform sub1.

5 write: / 'Before call 2'.

6 perform sub1.

7 write: / 'After calls'.

8

9 form sub1.

10 write: / 'Inside sub1'.

11 endform.

-

---

The code in Listing 17.6 produces the following output:

Before call 1

Inside sub1

Before call 2

Inside sub1

After calls

Line 3 executes.

Line 4 transfers control to line 9.

Line 10 executes.

Line 11 transfers control back to line 4.

Line 5 executes.

Line 6 transfers control to line 9.

Line 10 executes.

Line 11 returns control to line 6.

Line 7 executes.

There are two types of subroutines:

Internal subroutines

External subroutines

Listing 17.6 illustrated a call to an internal subroutine.

Defining and Calling Internal Subroutines

Subroutine definitions are usually placed at the end of the program, after all events. The form statement defines the end of the preceding event, and the beginning of a subroutine. Subroutines cannot be nested inside of events.

Syntax for the form Statement

form s [tables t1 t2 ...]

[using u1 value(u2) ...]

[changing c1 value(c2) ...].

---

endform.

where:

s is the name of the subroutine.

t1, t2, u1, u2, c1, and c2 are parameters.

tables allows internal tables to be passed as parameters.

The value addition cannot be used after tables.

The value addition can be applied to any variables passed via using or changing.

--- represents any number of lines of code.

The following points apply:

All additions are optional.

When they are coded, additions must appear in the order shown here. If coded, tables must come first, then using, and then changing.

Each addition can only be specified once. For example, the tables addition can only appear once. However, multiple tables can appear after it.

Do not use commas to separate parameters.

tables only allows internal tables to be passed-not database tables.

A subroutine can call another subroutine.

Recursion is supported. A subroutine can call itself or a subroutine that calls it.

Subroutine definitions cannot be nested. (You cannot define a subroutine within another subroutine.)

Syntax for the perform Statement

perform a) s

b) n of s1 s2 s3 ...

[tables t1 t2 ...]

[using u1 u2 ...]

[changing c1 c2 ...].

where:

s, s1, s2, s3, are subroutine names.

n is a numeric variable.

a) and b) are mutually exclusive.

tables, using, and changing can appear with either a) or b).

The addition value() cannot be used with perform.

Using syntax b) you can specify that one of a list of subroutines be performed. The nth subroutine in the list of subroutine names following of is performed. For example, if n is 2, the second subroutine in the list will be performed. Listing 17.7 illustrates this syntax.

regards

prasanth

[Former Member]

hi vinay,

Subroutines are procedures that you can define in any ABAP program and also call from any program. Subroutines are normally called internally, that is, they contain sections of code or algorithms that are used frequently locally. If you want a function to be reusable throughout the system, use a function module.

Defining Subroutines

A subroutine is a block of code introduced by FORM and concluded by ENDFORM.

FORM <subr> [USING ... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ]

[CHANGING... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ].

...

ENDFORM.

<subr> is the name of the subroutine. The optional additions USING and CHANGING define the parameter interface. Like any other processing block, subroutines cannot be nested. You should therefore place your subroutine definitions at the end of the program, especially for executable programs (type 1). In this way, you eliminate the risk of accidentally ending an event block in the wrong place by inserting a FORM...ENDFORM block.

Global Data from the Main Program

Subroutines can access all of the global data in the program in which they are defined (main program). You therefore do not need to define a parameter interface if you do not want to change any data in the subroutine, or if very little data is involved.

FORM HEADER.

WRITE: / 'Program started by', SY-UNAME,

/ 'on host', SY-HOST,

'date:', SY-DATUM, 'time:', SY-UZEIT.

ULINE.

ENDFORM.

This example creates a subroutine called HEADER, which, like the example of an include program, displays a list header.

However, if you want subroutines to perform complex operations on data without affecting the global data in the program, you should define a parameter interface through which you can pass exactly the data you need. In the interests of good programming style and encapsulation, you should always use a parameter interface, at least when the subroutine changes data.

Protecting Global Data Objects Against Changes

To prevent the value of a global data object from being changed inside a subroutine, use the following statement:

LOCAL <f>.

This statement may only occur between the FORM and ENDFORM statements. With LOCAL, you can preserve the values of global data objects which cannot be hidden by a data declaration inside the subroutine.

For example, you cannot declare a table work area that is defined by the TABLES statement with another TABLES statement inside a subroutine. If you want to use the table work area locally, but preserve its contents outside the subroutine, you must use the LOCAL statement.

PROGRAM FORM_TEST.

TABLES SFLIGHT.

PERFORM TABTEST1.

WRITE: / SFLIGHT-PLANETYPE, SFLIGHT-PRICE.

PERFORM TABTEST2.

WRITE: / SFLIGHT-PLANETYPE, SFLIGHT-PRICE.

FORM TABTEST1.

SFLIGHT-PLANETYPE = 'A310'.

SFLIGHT-PRICE = '150.00'.

WRITE: / SFLIGHT-PLANETYPE, SFLIGHT-PRICE.

ENDFORM.

FORM TABTEST2.

LOCAL SFLIGHT.

SFLIGHT-PLANETYPE = 'B747'.

SFLIGHT-PRICE = '500.00'.

WRITE: / SFLIGHT-PLANETYPE, SFLIGHT-PRICE.

ENDFORM.

When you run the program, the following is displayed:

A310 150.00

A310 150.00

B747 500.00

A310 150.00

The program creates a table work area SFLIGHT for the database table SFLIGHT. Different values are assigned to the table work area SFLIGHT in TABTEST1 and TABTEST2. While the values assigned in TABTEST1 are valid globally, the values assigned in TABTEST2 are only valid locally.

Terminating Subroutines

A subroutine normally ends at the ENDFORM statement. However, you can terminate them earlier by using the EXIT or CHECK statement. When you terminate a subroutine with EXIT or CHECK, the current values of the output parameters (CHANGING parameters passed by value) are passed back to the corresponding actual parameter.

Use EXIT to terminate a subroutine unconditionally. The calling program regains control at the statement following the PERFORM statement.

PROGRAM FORM_TEST.

PERFORM TERMINATE.

WRITE 'The End'.

FORM TERMINATE.

WRITE '1'.

WRITE '2'.

WRITE '3'.

EXIT.

WRITE '4'.

ENDFORM.

The produces the following output:

1 2 3 The End

In this example, the subroutine TERMINATE is terminated after the third WRITE statement.

Use CHECK to terminate a subroutine conditionally. If the logical expression in the CHECK statement is untrue, the subroutine is terminated, and the calling program resumes processing after the PERFORM statement.

PROGRAM FORM_TEST.

DATA: NUM1 TYPE I,

NUM2 TYPE I,

RES TYPE P DECIMALS 2.

NUM1 = 3. NUM2 = 4.

PERFORM DIVIDE USING NUM1 NUM2 CHANGING RES.

NUM1 = 5. NUM2 = 0.

PERFORM DIVIDE USING NUM1 NUM2 CHANGING RES.

NUM1 = 2. NUM2 = 3.

PERFORM DIVIDE USING NUM1 NUM2 CHANGING RES.

FORM DIVIDE USING N1 N2 CHANGING R.

CHECK N2 NE 0.

R = N1 / N2.

WRITE: / N1, '/', N2, '=', R.

ENDFORM.

The produces the following output:

3 / 4 = 0.75

2 / 3 = 0.67

In this example, the system leaves the subroutine DIVIDE during the second call after the CHECK statement because the value of N2 is zero.

If the EXIT or CHECK statement occurs within a loop in a subroutine, it applies to the loop, and not to the subroutine. EXIT and CHECK terminate loops in different ways (see Loops), but behave identically when terminating subroutines.

Local Data in the Subroutine

Data declarations in procedures create local data types and objects that are only visible within that procedure. There are two kinds of data types and objects – dynamic and static. Dynamic data objects only exist while the subroutine is running, while static objects still exist after the subroutine has finished running, and retain their values until the next time the subroutine is called. Field symbols can be declared locally. You can also use a special kind of data object for subroutines – copies of global data on a local data stack. You define and address them using field symbols.

Dynamic Local Data Types and Objects

Local data types and objects declared in subroutines using the TYPES and DATA statements are deleted when the subroutine ends, and recreated each time the routine is called.

Every subroutine has its own local naming space. If you declare a local data type or object with the same name as a global data type or object, the global type or object cannot be addressed from within the subroutine. Local data types or data objects hide identically named global data types or objects. This means that if you use the name of a data type or object in the subroutine, you always address a locally declared object – if this exists – and otherwise a globally declared one. To avoid this, you must assign other names to local types and objects. For example, you might name all of your local data starting with ‘L_’.

REPORT demo_mod_tech_data_types .

TYPES word(10) TYPE c.

DATA text TYPE word.

text = '1234567890'. WRITE / text.

PERFORM datatest.

WRITE / text.

FORM datatest.

TYPES word(5) TYPE c.

DATA text TYPE word.

text = 'ABCDEFGHJK'. WRITE / text.

ENDFORM.

When you run the program, the following is displayed:

1234567890

ABCDE

1234567890

In this example, a data type WORD and a data object TEXT with type WORD are declared globally in the main program. After assigning a value to TEXT and writing it to the list, the internal subroutine DATATEST is called. Inside the subroutine, a data type WORD and a data object TEXT with type WORD are declared locally. They hide the global type and object. Only after exiting the subroutine the global definitions are valid again.

Static Local Data Objects

If you want to keep the value of a local data object after exiting the subroutine, you must use the STATICS statement to declare it instead of the DATA statement. With STATICS you declare a data object that is globally defined, but only locally visible from the subroutine in which it is defined.

REPORT demo_mod_tech_statics.

PERFORM datatest1.

PERFORM datatest1.

SKIP.

PERFORM datatest2.

PERFORM datatest2.

FORM datatest1.

TYPES f_word(5) TYPE c.

DATA f_text TYPE f_word VALUE 'INIT'.

WRITE f_text.

f_text = '12345'.

WRITE f_text.

ENDFORM.

FORM datatest2.

TYPES f_word(5) TYPE c.

STATICS f_text TYPE f_word VALUE 'INIT'.

WRITE f_text.

f_text = 'ABCDE'.

WRITE f_text.

ENDFORM.

When you run the program, the following is displayed:

INIT 12345 INIT 12345

INIT ABCDE ABCDE ABCDE

In this example, two similar subroutines DATATEST1 and DATATEST2 are defined. In DATATEST2, the STATICS statement is used instead of the DATA statement to declare the data object F_TEXT. During each call of DATATEST1, F_TEXT is initialized again, but it keeps its value for DATATEST2. The VALUE option of the STATICS statement functions only during the first call of DATATEST2.

Local field symbols

All field symbols declared in a subroutine using the FIELD-SYMBOLS statement are local. The following rules apply to local field symbols:

You cannot address local field symbols outside the subroutine.

When you call the subroutine, any local field symbols are unassigned, even if you assigned a field to them the last time the subroutine was called.

Local field symbols can have the same names as global field symbols. Local field symbols hide global field symbols.

You can also declare structured field symbols locally. They can have local structures and you can assign local fields to them.

Local Copies of Global Fields

In a subroutine, you can create local copies of global data on the local stack. To do this, use a local field symbol and the following variant of the ASSIGN statement:

ASSIGN LOCAL COPY OF <f> TO <FS>.

The system places a copy of the specified global field <f> on the stack. In the subroutine, you can access and change this copy without changing the global data by addressing the field symbol <FS>.

You can use the LOCAL COPY OF addition with all variants of the ASSIGN statement except ASSIGN COMPONENT.

Other variants of the ASSIGN statement that are used in subroutines are:

ASSIGN LOCAL COPY OF INITIAL <f> TO <FS>.

This statement creates an initialized copy of the global field <f> on the stack without copying the field contents.

ASSIGN LOCAL COPY OF INITIAL LINE OF <itab> TO <FS>.

This statement creates an initial copy of the line of a global internal table <itab> on the stack.

ASSIGN LOCAL COPY OF INITIAL LINE OF (<f>) TO <FS>.

This statement creates an initial copy of the line of a global internal table <itab> on the stack. The internal table is specified dynamically as the contents of the field <f>.

REPORT demo_mod_tech_assign_local_cop.

DATA text(5) TYPE c VALUE 'Text1'.

PERFORM routine.

WRITE text.

FORM routine.

FIELD-SYMBOLS <fs> TYPE ANY.

ASSIGN LOCAL COPY OF text TO <fs>.

WRITE <fs>.

<fs> = 'Text2'.

WRITE <fs>.

ASSIGN text TO <fs>.

WRITE <fs>.

<fs> = 'Text3'.

ENDFORM.

The output is:

Text1 Text2 Text1 Text3

By assigning TEXT to <FS> in the subroutine ROUTINE in the program FORMPOOL, you place a copy of the field TEXT on the local data stack. By addressing <FS>, you can read and change this copy. The global field TEXT is not affected by operations on the local field. After you have assigned the field to the field symbol without the LOCAL COPY OF addition, it points directly to the global field. Operations with the field symbol then affect the global field.

The Parameter Interface

The USING and CHANGING additions in the FORM statement define the formal parameters of a subroutine. The sequence of the additions is fixed. Each addition can be followed by a list of any number of formal parameters. When you call a subroutine, you must fill all formal parameters with the values from the actual parameters. At the end of the subroutine, the formal parameters are passed back to the corresponding actual parameters.

Within a subroutine, formal parameters behave like dynamic local data. You can use them in the same way as normal local data objects that you would declare with the DATA statement. They mask global data objects with the same name. The value of the parameters at the start of the subroutine is the value passed from the corresponding actual parameter.

Subroutines can have the following formal parameters:

Parameters Passed by Reference

You list these parameters after USING or CHANGING without the VALUE addition:

FORM <subr> USING ... <pi> [TYPE <t>|LIKE <f>] ...

CHANGING ... <pi> [TYPE <t>|LIKE <f>] ...

The formal parameter occupies no memory of its own. During a subroutine call, only the address of the actual parameter is transferred to the formal parameter. The subroutine works with the field from the calling program. If the value of the formal parameter changes, the contents of the actual parameter in the calling program also change.

For calling by reference, USING and CHANGING are equivalent. For documentation purposes, you should use USING for input parameters which are not changed in the subroutine, and CHANGING for output parameters which are changed in the subroutine.

To avoid the value of an actual parameter being changed automatically, you must pass it by value.

Input Parameters That Pass Values

You list these parameters after USING with the VALUE addition:

FORM <subr> USING ... VALUE(<pi>) [TYPE <t>|LIKE <f>] ...

The formal parameter occupies its own memory space. When you call the subroutine, the value of the actual parameter is passed to the formal parameter. If the value of the formal parameter changes, this has no effect on the actual parameter.

Output Parameters That Pass Values

You list these parameters after CHANGING with the VALUE addition:

FORM <subr> CHANGING ... VALUE(<pi>) [TYPE <t>|LIKE <f>] ...

The formal parameter occupies its own memory space. When you call the subroutine, the value of the actual parameter is passed to the formal parameter. If the subroutine concludes successfully, that is, when the ENDFORM statement occurs, or when the subroutine is terminated through a CHECK or EXIT statement, the current value of the formal parameter is copied into the actual parameter.

If the subroutine terminates prematurely due to an error message, no value is passed. It only makes sense to terminate a subroutine through an error message in the PAI processing of a screen, that is, in a PAI module, in the AT SELECTION-SCREEN event, or after an interactive list event.

Specifying the Type of Formal Parameters

Formal parameters can have any valid ABAP data type. You can specify the type of a formal parameter, either generically or fully, using the TYPE or LIKE addition. If you specify a generic type, the type of the formal parameter is either partially specified or not specified at all. Any attributes that are not specified are inherited from the corresponding actual parameter when the subroutine is called. If you specify the type fully, all of the technical attributes of the formal parameter are defined with the subroutine definition.

The following remarks about specifying the types of parameters also apply to the parameters of other procedures (function modules and methods).

If you have specified the type of the formal parameters, the system checks that the corresponding actual parameters are compatible when the subroutine is called. For internal subroutines, the system checks this in the syntax check. For external subroutines, the check cannot occur until runtime.

By specifying the type, you ensure that a subroutine always works with the correct data type. Generic formal parameters allow a large degree of freedom when you call subroutines, since you can pass data of any type. This restricts accordingly the options for processing data in the subroutine, since the operations must be valid for all data types. For example, assigning one data object to another may not even be possible for all data types. If you specify the types of subroutine parameters, you can perform a much wider range of operations, since only the data appropriate to those operations can be passed in the call. If you want to process structured data objects component by component in a subroutine, you must specify the type of the parameter.

Specifying Generic Types

The following types allow you more freedom when using actual parameters. The actual parameter need only have the selection of attributes possessed by the formal parameter. The formal parameter adopts its remaining unnamed attributes from the actual parameter.

Type specification

Check for actual parameters

No type specification

TYPE ANY

The subroutine accepts actual parameters of any type. The formal parameter inherits all of the technical attributes of the actual parameter.

TYPE C, N, P, or X

The subroutine only accepts actual parameters with the type C, N, P, or X. The formal parameter inherits the field length and DECIMALS specification (for type P) from the actual parameter.

TYPE TABLE

The system checks whether the actual parameter is a standard internal table. This is a shortened form of TYPE STANDARD TABLE (see below).

TYPE ANY TABLE

The system checks whether the actual parameter is an internal table. The formal parameter inherits all of the attributes (line type, table type, key) from the actual parameter.

TYPE INDEX TABLE

The system checks whether the actual parameter is an index table (standard or sorted table). The formal parameter inherits all of the attributes (line type, table type, key) from the actual parameter.

TYPE STANDARD TABLE

The system checks whether the actual parameter is a standard internal table. The formal parameter inherits all of the attributes (line type, key) from the actual parameter.

TYPE SORTED TABLE

The system checks whether the actual parameter is a sorted table. The formal parameter inherits all of the attributes (line type, key) from the actual parameter.

TYPE HASHED TABLE

The system checks whether the actual parameter is a hashed table. The formal parameter inherits all of the attributes (line type, key) from the actual parameter.

Note that formal parameters inherit the attributes of their corresponding actual parameters dynamically at runtime, and so they cannot be identified in the program code. For example, you cannot address an inherited table key statically in a subroutine, but you probably can dynamically.

TYPES: BEGIN OF LINE,

COL1,

COL2,

END OF LINE.

DATA: WA TYPE LINE,

ITAB TYPE HASHED TABLE OF LINE WITH UNIQUE KEY COL1,

KEY(4) VALUE 'COL1'.

WA-COL1 = 'X'. INSERT WA INTO TABLE ITAB.

WA-COL1 = 'Y'. INSERT WA INTO TABLE ITAB.

PERFORM DEMO USING ITAB.

FORM DEMO USING P TYPE ANY TABLE.

...

READ TABLE P WITH TABLE KEY (KEY) = 'X' INTO WA.

...

ENDFORM.

The table key is addressed dynamically in the subroutine. However, the static address

READ TABLE P WITH TABLE KEY COL1 = 'X' INTO WA.

is syntactically incorrect, since the formal parameter P does not adopt the key of table ITAB until runtime.

Specifying Full Types

When you use the following types, the technical attributes of the formal parameters are fully specified. The technical attributes of the actual parameter must correspond to those of the formal parameter.

Type specification

Technical attributes of the formal parameter

TYPE D, F, I, or T

The formal parameter has the technical attributes of the predefined elementary type

TYPE <type>

The formal parameter has the type <type> This is a data type defined within the program using the TYPES statement, or a type from the ABAP Dictionary

TYPE REF TO <cif>

The formal parameter is a reference variable (ABAP Objects) for the class or interface <cif>

TYPE LINE OF <itab>

The formal parameter has the same type as a line of the internal table <itab> defined using a TYPES statement or defined in the ABAP Dictionary

LIKE <f>

The formal parameter has the same type as an internal data object <f> or structure, or a database table from the ABAP Dictionary

When you use a formal parameter that is fully typed, you can address its attributes statically in the program, since they are recognized in the source code.

Structured Formal Parameters

Since formal parameters can take any valid ABAP data type, they can also take structures and internal tables with a structured line type, as long as the type of the formal parameter is fully specified. You can address the components of the structure statically in the subroutine.

Generic Structures

If you pass a structured actual parameter generically to a formal parameter whose type is not correctly specified, you cannot address the components of the structure statically in the subroutine. For internal tables, this means that only line operations are possible.

To access the components of a generically passed structure, you must use field symbols, and the assignment

ASSIGN COMPONENT <idx>|<name> OF STRUCTURE <s> TO <FS>.

<idx> is interpreted as the component number and the contents of <name> are interpreted as a component name in the generic structure <s>.

DATA: BEGIN OF LINE,

COL1 VALUE 'X',

COL2 VALUE 'Y',

END OF LINE.

DATA COMP(4) VALUE 'COL1'.

PERFORM DEMO USING LINE.

FORM DEMO USING P TYPE ANY.

FIELD-SYMBOLS <FS>.

ASSIGN COMPONENT COMP OF STRUCTURE P TO <FS>.

WRITE <FS>.

ASSIGN COMPONENT 2 OF STRUCTURE P TO <FS>.

WRITE <FS>.

ENDFORM.

The output is:

X Y

The components COL1 and COL2 of the structure of P (passed generically) are assigned to the field symbol <FS>. You cannot address the components directly either statically or dynamically.

Fitting Parameters into Structures

Instead of using TYPE or LIKE, you can specify the type of a structure as follows:

... <pi> [STRUCTURE <s>] ...

where <s> is a local structure in the program (data object, not a type) or a flat structure from the ABAP Dictionary. The formal parameter is structured according to <s>, and you can address its individual components in the subroutine. When the actual parameter is passed, the system only checks to ensure that the actual parameter is at least as long as the structure. STRUCTURE therefore allows you to force a structured view of any actual parameter.

DATA: BEGIN OF LINE,

COL1,

COL2,

END OF LINE.

DATA TEXT(2) VALUE 'XY'.

PERFORM DEMO USING TEXT.

FORM DEMO USING P STRUCTURE LINE.

WRITE: P-COL1, P-COL2.

ENDFORM.

The output is:

X Y

The string TEXT is fitted into the structure LINE.

The TABLES Addition

To ensure compatibility with previous releases, the following addition is still allowed before the USING and CHANGING additions:

FORM <subr> TABLES ... <itabi> [TYPE <t>|LIKE <f>] ...

The formal parameters <itabi> are defined as standard internal tables with header lines. If you use an internal table without header line as the corresponding actual parameter for a formal parameter of this type, the system creates a local header line in the subroutine for the formal parameter. If you pass an internal table with a header line, the table body and the table work area are passed to the subroutine. Formal parameters defined using TABLES cannot be passed by reference. If you want to address the components of structured lines, you must specify the type of the TABLES parameter accordingly.

From Release 3.0, you should use USING or CHANGING instead of the TABLES addition for internal tables, although for performance reasons, you should not pass them by value.

Calling Subroutines

You call subroutines using the statement

PERFORM... [USING ... <pi>... ]

[CHANGING... <pi>... ].

Subroutines can call other subroutines (nested calls) and may also call themselves (recursive calls). Once a subroutine has finished running, the calling program carries on processing after the PERFORM statement. You can use the USING and CHANGING additions to supply values to the parameter interface of the subroutine

Naming Subroutines

With the PERFORM statement, you can call subroutines which are coded in the same ABAP program (internal calls), or subroutines which are coded in other ABAP programs (external calls).

You can also specify the name of the subroutine dynamically at runtime, and call subroutines from a list.

Internal Subroutine Calls

To call a subroutine defined in the same program, you need only specify its name in the PERFORM statement:

PERFORM <subr> [USING ... <pi>... ]

[CHANGING... <pi>... ].

The internal subroutine can access all of the global data of the calling program.

PROGRAM FORM_TEST.

DATA: NUM1 TYPE I,

NUM2 TYPE I,

SUM TYPE I.

NUM1 = 2. NUM2 = 4.

PERFORM ADDIT.

NUM1 = 7. NUM2 = 11.

PERFORM ADDIT.

FORM ADDIT.

SUM = NUM1 + NUM2.

PERFORM OUT.

ENDFORM.

FORM OUT.

WRITE: / 'Sum of', NUM1, 'and', NUM2, 'is', SUM.

ENDFORM.

The produces the following output:

Sum of 2 and 4 is 6

Sum of 7 and 11 is 18

In this example, two internal subroutines ADDIT and OUT are defined at the end of the program. ADDIT is called from the program and OUT is called from ADDIT. The subroutines have access to the global fields NUM1, NUM2, and SUM.

External subroutine calls

The principal function of subroutines is for modularizing and structuring local programs. However, subroutines can also be called externally from other ABAP programs. In an extreme case, you might have an ABAP program that contained nothing but subroutines. These programs cannot run on their own, but are used by other ABAP programs as pools of external subroutines.

However, if you want to make a function available throughout the system, you should use function modules instead of external subroutines. You create function modules in the ABAP Workbench using the Function Builder. They are stored in a central library, and have a defined release procedure.

You can encapsulate functions and data in the attributes and methods of classes in ABAP Objects. For any requirements that exceed pure functions, you can use global classes instead of external subroutines.

When you call a subroutine externally, you must know the name of the program in which it is defined:

PERFORM <subr>(<prog>) [USING ... <pi>... ]

[CHANGING... <pi>... ] [IF FOUND].

You specify the program name <prog> statically. You can use the IF FOUND option to prevent a runtime error from occurring if the program <prog> does not contain a subroutine <sub>. In this case, the system simply ignores the PERFORM statement.

When you call an external subroutine, the system loads the whole of the program containing the subroutine into the internal session of the calling program (if it has not already been loaded). For further information, refer to Memory Structure of an ABAP Program. In order to save memory space, you should keep the number of subroutines called in different programs to a minimum.

Suppose a program contains the following subroutine:

PROGRAM FORMPOOL.

FORM HEADER.

WRITE: / 'Program started by', SY-UNAME,

/ 'on host', SY-HOST,

'date:', SY-DATUM, 'time:', SY-UZEIT.

ULINE.

ENDFORM.

The subroutine can then be called from another program as follows:

PROGRAM FORM_TEST.

PERFORM HEADER(FORMPOOL) IF FOUND.

In this example, no data is passed between calling program and subroutine.

Specifying Subroutines Dynamically

You can specify the name of a subroutine and, in the case of external calls, the name of the program in which it occurs, dynamically as follows:

PERFORM (<fsubr>)[IN PROGRAM (<fprog>)][USING ... <pi>... ]

[CHANGING... <pi>... ]

[IF FOUND].

The names of the subroutine and the external program are the contents of the fields <fsubr> and <fprog> respectively. By using the option IF FOUND, you can prevent a runtime error from being triggered if <fprog> does not contain a subroutine with the name <fsubr>. If you omit the parentheses, this variant of the PERFORM statement behaves like the static variant.

Suppose a program contains the following subroutines:

PROGRAM FORMPOOL.

FORM SUB1.

WRITE: / 'Subroutine 1'.

ENDFORM.

FORM SUB2.

WRITE: / 'Subroutine 2'.

ENDFORM.

Dynamic subroutine specification:

PROGRAM FORM_TEST.

DATA: PROGNAME(8) VALUE 'FORMPOOL',

SUBRNAME(8).

SUBRNAME = 'SUB1'.

PERFORM (SUBRNAME) IN PROGRAM (PROGNAME) IF FOUND.

SUBRNAME = 'SUB2'.

PERFORM (SUBRNAME) IN PROGRAM (PROGNAME) IF FOUND.

The produces the following output:

Subroutine 1

Subroutine 2

The character field PROGNAME contains the name of the program, in which the subroutines are contained. The names of the subroutines are assigned to the character field SUBRNAME.

Calling Subroutines from a List

You can call a subroutine from a list as follows:

PERFORM <idx> OF <subr1> <subr 2>.... <subr n>.

The system calls the subroutine specified in the subroutine list in position <idx>. You can only use this variant of the PERFORM statement for internal subroutine calls, and only for subroutines without a parameter interface. The field <idx> can be a variable or a literal.

PROGRAM FORM_TEST.

DO 2 TIMES.

PERFORM SY-INDEX OF SUB1 SUB2.

ENDDO.

FORM SUB1.

WRITE / 'Subroutine 1'.

ENDFORM.

FORM SUB2.

WRITE / 'Subroutine 2'.

ENDFORM.

The produces the following output:

Subroutine 1

Subroutine 2

In this example, the two internal subroutines, SUB1 and SUB2, are called consecutively from a list.

Passing Parameters to Subroutines

If a subroutine has a parameter interface, you must supply values to all of the formal parameters in its interface when you call it. You list the actual parameters after the USING or CHANGING addition in the PERFORM statement.

When you pass the values, the sequence of the actual parameters in the PERFORM statement is crucial. The value of the first actual parameter in the list is passed to the first formal parameter, the second to the second, and so on. The additions USING and CHANGING have exactly the same meaning. You only need to use one or the other. However, for documentary reasons, it is a good idea to divide the parameters in the same way in which they occur in the interface definition.

Actual parameters can be any data objects or field symbols of the calling program whose technical attributes are compatible with the type specified for the corresponding formal parameter. When you specify the actual parameters, note that any that you pass by reference to a formal parameter, and any that you pass by value to an output parameter, can be changed by the subroutine. You should therefore ensure that only data objects that you want to be changed appear in the corresponding position of the actual parameter list.

If a subroutine contains TABLES parameters in its interface, you must specify them in a TABLES addition of the PERFORM statement before the USING and CHANGING parameters. TABLES parameters are only supported to ensure compatibility with earlier releases, and should no longer be used.

You can use offset addressing for actual parameters in the same way as offset addressing for field symbols. That is, you can select memory areas that lie outside the boundaries of the specified actual parameter.

PROGRAM form_test.

DATA: a1 TYPE p DECIMALS 3,

a2 TYPE i,

a3 TYPE d,

a4 TYPE spfli-carrid,

a5(1) TYPE c.

...

PERFORM subr USING a1 a2 a3 a4 a5.

...

PERFORM subr CHANGING a1 a2 a3 a4 a5.

...

PERFORM subr USING a1 a2 a3

CHANGING a4 a5.

...

FORM subr USING

value(f1) TYPE p

value(f2) TYPE i

f3 LIKE a3

CHANGING

value(f4) TYPE spfli-carrid

f5.

...

ENDFORM.

This example defines a subroutine SUBR with a parameter interface consisting of five formal parameters, F1 to F5. The subroutine is called internally three times. The actual parameters are the data objects A1 to A5. The three subroutine calls are all equally valid. There are further PERFORM statements that are also equally valid, so long as the sequence of the actual parameters remains unchanged. In each call, A1 is passed to F1, A2 to F2, and so on. When the subroutine ends, A3, A4, and A5 receive the values of F3, F4, and F5 respectively. The third of the subroutine calls documents in the program what the parameter interface of the subroutine shows, namely that only A4 and A5 are changed. Whether A3 is changed depends on the way in which the subroutine is programmed.

The following example shows how generically-typed formal parameters inherit their technical attributes from their corresponding actual parameters.

REPORT demo_mod_tech_describe.

DATA:

date1 TYPE d, date2 TYPE t,

string1(6) TYPE c, string2(8) TYPE c,

number1 TYPE p DECIMALS 2, number2 TYPE p DECIMALS 0,

count1 TYPE i, count2 TYPE i.

PERFORM typetest USING date1 string1 number1 count1.

SKIP.

PERFORM typetest USING date2 string2 number2 count2.

FORM typetest USING now

txt TYPE c

value(num) TYPE p

int TYPE i.

DATA: t(1) TYPE c.

DESCRIBE FIELD now TYPE t.

WRITE: / 'Type of NOW is', t.

DESCRIBE FIELD txt LENGTH t IN CHARACTER MODE.

WRITE: / 'Length of TXT is', t.

DESCRIBE FIELD num DECIMALS t.

WRITE: / 'Decimals of NUM are', t.

DESCRIBE FIELD int TYPE t.

WRITE: / 'Type of INT is', t.

ENDFORM.

This produces the following output:

Type of NOW is D

Length of TXT is 6

Decimals of NUM are 2

Type of INT is I

Type of NOW is T

Length of TXT is 8

Decimals of NUM are 0

Type of INT is I

An internal subroutine TYPETEST is called twice with different actual parameters. All actual and formal parameters are compatible and no error message occurs during the syntax check. Had you declared COUNT2 with type F instead of type I, the syntax check would have returned an error, since the formal parameter INT is specified with type I. The formal parameters with generic types adopt different technical attributes depending on their corresponding technical attributes.

thanks

karthik

reward me if usefull

[Former Member]

Hi,

Subroutines are procedures that you can define in any ABAP program and also call from any program. Subroutines are normally called internally, that is, they contain sections of code or algorithms that are used frequently locally. If you want a function to be reusable throughout the system, use a function module.

Defining Subroutines

A subroutine is a block of code introduced by FORM and concluded by ENDFORM.

FORM <subr> [USING ... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ]

[CHANGING... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ].

...

ENDFORM.

<subr> is the name of the subroutine. The optional additions USING and CHANGING define the parameter interface. Like any other processing block, subroutines cannot be nested. You should therefore place your subroutine definitions at the end of the program, especially for executable programs (type 1). In this way, you eliminate the risk of accidentally ending an event block in the wrong place by inserting a FORM...ENDFORM block.

Calling Subroutines

You call subroutines using the statement

PERFORM... [USING ... <pi>... ]

[CHANGING... <pi>... ].

Subroutines can call other subroutines (nested calls) and may also call themselves (recursive calls). Once a subroutine has finished running, the calling program carries on processing after the PERFORM statement. You can use the USING and CHANGING additions to supply values to the parameter interface of the subroutine.

Naming Subrotuines

With the PERFORM statement, you can call subroutines which are coded in the same ABAP program (internal calls), or subroutines which are coded in other ABAP programs (external calls).

You can also specify the name of the subroutine dynamically at runtime, and call subroutines from a list.

Internal Subroutine Calls

To call a subroutine defined in the same program, you need only specify its name in the PERFORM statement:

PERFORM <subr> [USING ... <pi>... ]

[CHANGING... <pi>... ].

The internal subroutine can access all of the global data of the calling program.

PROGRAM FORM_TEST.

DATA: NUM1 TYPE I,

NUM2 TYPE I,

SUM TYPE I.

NUM1 = 2. NUM2 = 4.

PERFORM ADDIT.

NUM1 = 7. NUM2 = 11.

PERFORM ADDIT.

FORM ADDIT.

SUM = NUM1 + NUM2.

PERFORM OUT.

ENDFORM.

FORM OUT.

WRITE: / 'Sum of', NUM1, 'and', NUM2, 'is', SUM.

ENDFORM.

The produces the following output:

Sum of 2 and 4 is 6

Sum of 7 and 11 is 18

In this example, two internal subroutines ADDIT and OUT are defined at the end of the program. ADDIT is called from the program and OUT is called from ADDIT. The subroutines have access to the global fields NUM1, NUM2, and SUM.

*External subroutine calls*

The principal function of subroutines is for modularizing and structuring local programs. However, subroutines can also be called externally from other ABAP programs. In an extreme case, you might have an ABAP program that contained nothing but subroutines. These programs cannot run on their own, but are used by other ABAP programs as pools of external subroutines.

However, if you want to make a function available throughout the system, you should use function modules instead of external subroutines. You create function modules in the ABAP Workbench using the Function Builder. They are stored in a central library, and have a defined release procedure.

You can encapsulate functions and data in the attributes and methods of classes in ABAP Objects. For any requirements that exceed pure functions, you can use global classes instead of external subroutines.

When you call a subroutine externally, you must know the name of the program in which it is defined:

PERFORM <subr>(<prog>) [USING ... <pi>... ]

[CHANGING... <pi>... ] [IF FOUND].

You specify the program name <prog> statically. You can use the IF FOUND option to prevent a runtime error from occurring if the program <prog> does not contain a subroutine <sub>. In this case, the system simply ignores the PERFORM statement.

When you call an external subroutine, the system loads the whole of the program containing the subroutine into the internal session of the calling program (if it has not already been loaded). For further information, refer to Memory Structure of an ABAP Program. In order to save memory space, you should keep the number of subroutines called in different programs to a minimum

Passing Parameters to Subroutines

If a subroutine has a parameter interface, you must supply values to all of the formal parameters in its interface when you call it. You list the actual parameters after the USING or CHANGING addition in the PERFORM statement.

When you pass the values, the sequence of the actual parameters in the PERFORM statement is crucial. The value of the first actual parameter in the list is passed to the first formal parameter, the second to the second, and so on. The additions USING and CHANGING have exactly the same meaning. You only need to use one or the other. However, for documentary reasons, it is a good idea to divide the parameters in the same way in which they occur in the interface definition.

Actual parameters can be any data objects or field symbols of the calling program whose technical attributes are compatible with the type specified for the corresponding formal parameter. When you specify the actual parameters, note that any that you pass by reference to a formal parameter, and any that you pass by value to an output parameter, can be changed by the subroutine. You should therefore ensure that only data objects that you want to be changed appear in the corresponding position of the actual parameter list.

If a subroutine contains TABLES parameters in its interface, you must specify them in a TABLES addition of the PERFORM statement before the USING and CHANGING parameters. TABLES parameters are only supported to ensure compatibility with earlier releases, and should no longer be used.

You can use offset addressing for actual parameters in the same way as offset addressing for field symbols. That is, you can select memory areas that lie outside the boundaries of the specified actual parameter.

PROGRAM form_test.

DATA: a1 TYPE p DECIMALS 3,

a2 TYPE i,

a3 TYPE d,

a4 TYPE spfli-carrid,

a5(1) TYPE c.

...

PERFORM subr USING a1 a2 a3 a4 a5.

...

PERFORM subr CHANGING a1 a2 a3 a4 a5.

...

PERFORM subr USING a1 a2 a3

CHANGING a4 a5.

...

FORM subr USING

value(f1) TYPE p

value(f2) TYPE i

f3 LIKE a3

CHANGING

value(f4) TYPE spfli-carrid

f5.

...

ENDFORM.

This example defines a subroutine SUBR with a parameter interface consisting of five formal parameters, F1 to F5. The subroutine is called internally three times. The actual parameters are the data objects A1 to A5. The three subroutine calls are all equally valid. There are further PERFORM statements that are also equally valid, so long as the sequence of the actual parameters remains unchanged. In each call, A1 is passed to F1, A2 to F2, and so on. When the subroutine ends, A3, A4, and A5 receive the values of F3, F4, and F5 respectively. The third of the subroutine calls documents in the program what the parameter interface of the subroutine shows, namely that only A4 and A5 are changed. Whether A3 is changed depends on the way in which the subroutine is programmed.

The following example shows how generically-typed formal parameters inherit their technical attributes from their corresponding actual parameters.

REPORT demo_mod_tech_describe.

DATA:

date1 TYPE d, date2 TYPE t,

string1(6) TYPE c, string2(8) TYPE c,

number1 TYPE p DECIMALS 2, number2 TYPE p DECIMALS 0,

count1 TYPE i, count2 TYPE i.

PERFORM typetest USING date1 string1 number1 count1.

SKIP.

PERFORM typetest USING date2 string2 number2 count2.

FORM typetest USING now

txt TYPE c

value(num) TYPE p

int TYPE i.

DATA: t(1) TYPE c.

DESCRIBE FIELD now TYPE t.

WRITE: / 'Type of NOW is', t.

DESCRIBE FIELD txt LENGTH t IN CHARACTER MODE.

WRITE: / 'Length of TXT is', t.

DESCRIBE FIELD num DECIMALS t.

WRITE: / 'Decimals of NUM are', t.

DESCRIBE FIELD int TYPE t.

WRITE: / 'Type of INT is', t.

ENDFORM.

This produces the following output:

Type of NOW is D

Length of TXT is 6

Decimals of NUM are 2

Type of INT is I

Type of NOW is T

Length of TXT is 8

Decimals of NUM are 0

Type of INT is I

An internal subroutine TYPETEST is called twice with different actual parameters. All actual and formal parameters are compatible and no error message occurs during the syntax check. Had you declared COUNT2 with type F instead of type I, the syntax check would have returned an error, since the formal parameter INT is specified with type I. The formal parameters with generic types adopt different technical attributes depending on their corresponding technical attributes.

Please reward if useful.

[Former Member]

Hi,

Subroutines are procedures that you can define in any ABAP program and also call from any program. Subroutines are normally called internally, that is, they contain sections of code or algorithms that are used frequently locally. If you want a function to be reusable throughout the system, use a function module.

Defining Subroutines

A subroutine is a block of code introduced by FORM and concluded by ENDFORM.

FORM <subr> [USING ... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ]

[CHANGING... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ].

...

ENDFORM.

<subr> is the name of the subroutine. The optional additions USING and CHANGING define the parameter interface. Like any other processing block, subroutines cannot be nested. You should therefore place your subroutine definitions at the end of the program, especially for executable programs (type 1). In this way, you eliminate the risk of accidentally ending an event block in the wrong place by inserting a FORM...ENDFORM block.

Calling Subroutines

You call subroutines using the statement

PERFORM... [USING ... <pi>... ]

[CHANGING... <pi>... ].

Subroutines can call other subroutines (nested calls) and may also call themselves (recursive calls). Once a subroutine has finished running, the calling program carries on processing after the PERFORM statement. You can use the USING and CHANGING additions to supply values to the parameter interface of the subroutine.

Naming Subrotuines

With the PERFORM statement, you can call subroutines which are coded in the same ABAP program (internal calls), or subroutines which are coded in other ABAP programs (external calls).

You can also specify the name of the subroutine dynamically at runtime, and call subroutines from a list.

Internal Subroutine Calls

To call a subroutine defined in the same program, you need only specify its name in the PERFORM statement:

PERFORM <subr> [USING ... <pi>... ]

[CHANGING... <pi>... ].

The internal subroutine can access all of the global data of the calling program.

PROGRAM FORM_TEST.

DATA: NUM1 TYPE I,

NUM2 TYPE I,

SUM TYPE I.

NUM1 = 2. NUM2 = 4.

PERFORM ADDIT.

NUM1 = 7. NUM2 = 11.

PERFORM ADDIT.

FORM ADDIT.

SUM = NUM1 + NUM2.

PERFORM OUT.

ENDFORM.

FORM OUT.

WRITE: / 'Sum of', NUM1, 'and', NUM2, 'is', SUM.

ENDFORM.

The produces the following output:

Sum of 2 and 4 is 6

Sum of 7 and 11 is 18

In this example, two internal subroutines ADDIT and OUT are defined at the end of the program. ADDIT is called from the program and OUT is called from ADDIT. The subroutines have access to the global fields NUM1, NUM2, and SUM.

*External subroutine calls*

The principal function of subroutines is for modularizing and structuring local programs. However, subroutines can also be called externally from other ABAP programs. In an extreme case, you might have an ABAP program that contained nothing but subroutines. These programs cannot run on their own, but are used by other ABAP programs as pools of external subroutines.

However, if you want to make a function available throughout the system, you should use function modules instead of external subroutines. You create function modules in the ABAP Workbench using the Function Builder. They are stored in a central library, and have a defined release procedure.

You can encapsulate functions and data in the attributes and methods of classes in ABAP Objects. For any requirements that exceed pure functions, you can use global classes instead of external subroutines.

When you call a subroutine externally, you must know the name of the program in which it is defined:

PERFORM <subr>(<prog>) [USING ... <pi>... ]

[CHANGING... <pi>... ] [IF FOUND].

You specify the program name <prog> statically. You can use the IF FOUND option to prevent a runtime error from occurring if the program <prog> does not contain a subroutine <sub>. In this case, the system simply ignores the PERFORM statement.

When you call an external subroutine, the system loads the whole of the program containing the subroutine into the internal session of the calling program (if it has not already been loaded). For further information, refer to Memory Structure of an ABAP Program. In order to save memory space, you should keep the number of subroutines called in different programs to a minimum

Passing Parameters to Subroutines

If a subroutine has a parameter interface, you must supply values to all of the formal parameters in its interface when you call it. You list the actual parameters after the USING or CHANGING addition in the PERFORM statement.

When you pass the values, the sequence of the actual parameters in the PERFORM statement is crucial. The value of the first actual parameter in the list is passed to the first formal parameter, the second to the second, and so on. The additions USING and CHANGING have exactly the same meaning. You only need to use one or the other. However, for documentary reasons, it is a good idea to divide the parameters in the same way in which they occur in the interface definition.

Actual parameters can be any data objects or field symbols of the calling program whose technical attributes are compatible with the type specified for the corresponding formal parameter. When you specify the actual parameters, note that any that you pass by reference to a formal parameter, and any that you pass by value to an output parameter, can be changed by the subroutine. You should therefore ensure that only data objects that you want to be changed appear in the corresponding position of the actual parameter list.

If a subroutine contains TABLES parameters in its interface, you must specify them in a TABLES addition of the PERFORM statement before the USING and CHANGING parameters. TABLES parameters are only supported to ensure compatibility with earlier releases, and should no longer be used.

You can use offset addressing for actual parameters in the same way as offset addressing for field symbols. That is, you can select memory areas that lie outside the boundaries of the specified actual parameter.

PROGRAM form_test.

DATA: a1 TYPE p DECIMALS 3,

a2 TYPE i,

a3 TYPE d,

a4 TYPE spfli-carrid,

a5(1) TYPE c.

...

PERFORM subr USING a1 a2 a3 a4 a5.

...

PERFORM subr CHANGING a1 a2 a3 a4 a5.

...

PERFORM subr USING a1 a2 a3

CHANGING a4 a5.

...

FORM subr USING

value(f1) TYPE p

value(f2) TYPE i

f3 LIKE a3

CHANGING

value(f4) TYPE spfli-carrid

f5.

...

ENDFORM.

This example defines a subroutine SUBR with a parameter interface consisting of five formal parameters, F1 to F5. The subroutine is called internally three times. The actual parameters are the data objects A1 to A5. The three subroutine calls are all equally valid. There are further PERFORM statements that are also equally valid, so long as the sequence of the actual parameters remains unchanged. In each call, A1 is passed to F1, A2 to F2, and so on. When the subroutine ends, A3, A4, and A5 receive the values of F3, F4, and F5 respectively. The third of the subroutine calls documents in the program what the parameter interface of the subroutine shows, namely that only A4 and A5 are changed. Whether A3 is changed depends on the way in which the subroutine is programmed.

The following example shows how generically-typed formal parameters inherit their technical attributes from their corresponding actual parameters.

REPORT demo_mod_tech_describe.

DATA:

date1 TYPE d, date2 TYPE t,

string1(6) TYPE c, string2(8) TYPE c,

number1 TYPE p DECIMALS 2, number2 TYPE p DECIMALS 0,

count1 TYPE i, count2 TYPE i.

PERFORM typetest USING date1 string1 number1 count1.

SKIP.

PERFORM typetest USING date2 string2 number2 count2.

FORM typetest USING now

txt TYPE c

value(num) TYPE p

int TYPE i.

DATA: t(1) TYPE c.

DESCRIBE FIELD now TYPE t.

WRITE: / 'Type of NOW is', t.

DESCRIBE FIELD txt LENGTH t IN CHARACTER MODE.

WRITE: / 'Length of TXT is', t.

DESCRIBE FIELD num DECIMALS t.

WRITE: / 'Decimals of NUM are', t.

DESCRIBE FIELD int TYPE t.

WRITE: / 'Type of INT is', t.

ENDFORM.

This produces the following output:

Type of NOW is D

Length of TXT is 6

Decimals of NUM are 2

Type of INT is I

Type of NOW is T

Length of TXT is 8

Decimals of NUM are 0

Type of INT is I

An internal subroutine TYPETEST is called twice with different actual parameters. All actual and formal parameters are compatible and no error message occurs during the syntax check. Had you declared COUNT2 with type F instead of type I, the syntax check would have returned an error, since the formal parameter INT is specified with type I. The formal parameters with generic types adopt different technical attributes depending on their corresponding technical attributes.

Please reward if useful.

[Former Member]

hi ,

it was some problem dont think the dashed lines as corrupted. they are right ones

karthik

[Former Member]

hi..

Subroutines are procedures that you can define in any ABAP program and also call from any program. Subroutines are normally called internally, that is, they contain sections of code or algorithms that are used frequently locally.

As mentioned, both forms and FMs are reusable modularization units. To distinguish we generally say that forms are used for internal modularization and FMs are used for external modularization.

To decide on which to implement, consider whether you need the content to be used just for a limited program or wheteher it can be called from many independent programs. For the first purpose it is better to implement a form whereas for the second we implement an FM.

However, ABAP does not isolate the usage context. That is; you can call a form from another program within whose code the form is not actually implemented. However, this requires attention since the form may utilize global variables.

The same issue holds for FMs. FMs are encapsulated in function groups and function groups may have global variables that can be globally used by all FMs inside it.

Subroutines are loacl to a progarm.. It cant be extended to other program.

But Function Modules are similar to subroutines but are global in view and can be used in many program.

Subroutine have three types.

pass by value, pass by reference and pass by value and reference similar to pointers but not exactly the same.

Function modules are used in BDC , BAPI etc..

Also there are standard FMs which can be used.

http://help.sap.com/saphelp_nw2004s/helpdata/en/c5/aa575926ad11d2954d0000e8353423/content.htm

http://www.sapbrainsonline.com/FAQs/TECHNICAL/SAP_ABAP_MODULARIZATION_FAQ.html

reward points if useful

Regards

Sas