regarding program types

[Former Member]

how many types of programs are there in abap.

could u plz explain clearly.

[Former Member]

Hi Rajesh,

Types of programs are given below.

Executable

Include

Module Pool

Function group

Subroutine pool

Interface pool

class pool

U can check them in the attributes list of SE38 and F1 help will give you the below details

Executable Programs (1)

Can be started without a transaction code,

either directly or in the background.

Executable programs are controlled by an invisible system program.

The system program calls processing blocks in the program in a

pre-defined order. It displays the selection screen at the

beginning of the program and outputs a list at the end. Executable

programs allow you to work with logical databases.

Module Pools for Screen Painter Screens (M)

Contain processing steps for screen

modules from the transaction and can only

be executed with a transaction code or a

menu function.

Includes (I)

Contain program code that cannot be

run on its own.

You call them from another program using

INCLUDE statements.

Subroutines (S)

Contain parts of programs (FORM routines) that can be called

using external PERFORM statements.

Function Groups (F)

Contain function modules. Function groups and function

modules are managed in the Function Builder. Program

type F is set by the Function Builder, and cannot be changed

in the program attributes.

Interface Pools (J)

Contain interfaces. Classes and interfaces are managed (administered)

in the Class Builder; program type J cannot be changed in the attributes.

Class Pools (K)

Contain interfaces. Classes and interfaces are managed (administered)

in the Class Builder; program type K cannot be changed in the attributes.

Regards,

Vishnu Priya

Message was edited by:

Vishnu priya

[Former Member]

thanks

[Former Member]

Way of saying thanks in SDN is by rewarding points if helpful.

[Former Member]

Hi,

Executable programs

are made for reporting. They are the only programs that can be started via SUBMIT (which is the ABAP statement that lies behind transaction SA38!). SUBMIT starts a reporting process in the ABAP runtime environment, that is tailor made for receiving user input, selecting data from database tables, and displaying them on a list. The reporting process triggers a sequence of events -- as for example INITIALIZATION, START-OF-SELECTION etc. -- that can be handled in the executable program. Stay tuned for an upcoming Weblog about SUBMIT.

Module pools

are very similar to executable programs. Except for reporting events and for being callable via SUBMIT, module pools support the same features as executable programs. In another way around, module pools could be fully replaced by executables. Traditionally, module pools are chosen to implement the application logic of so called dialog programs. Those are programs that communicate with the user via Dynpros. A Module pool Ís usually executed by calling a transaction code connected to one of its Dynpros. The dialog modules are then called from the Dynpro's flow logic.

Function pools

are the only programs that can contain function modules. They are not maintained in the standard ABAP Editor, but in the Function Builder instead. Function pools and their function modules deliver reusable functions to other programs. Besides that, function pools have the same features as module pools. Especially, they can contain Dynpros and dialog modules. Therefore, function pools are the first choice, if you want to encapsulate dynpro based user dialogs (note that class pools do not support Dynpros). An application program or a class can call a function module, which then calls one of the function pool's Dynpros via CALL SCREEN.

Subroutine pools

-- as the name says -- were created to contain selections of subroutines, that can be called externally from other programs. Before release 6.10, this was the only way, how subroutine pools could be used. But besides subroutines, subroutine pools can also contain local classes and interfaces. As of release 6.10, you can connect transaction codes to methods. Therefore, you can now also call subroutine pools via transaction codes. This is the closest to a Java program you can get in ABAP: a subroutine pool with a class containing a method -- say -- main connected to a transaction code!

Type pools

are the precursors to general type definitions in the ABAP Dictionary. Before release 4.0, only elementary data types and flat structures could be defined in the ABAP Dictionary. All other types, that should be generally available, hat to be defined with TYPES in type pools. As of release 4.0, type pools were only necessary for constants. As of release 6.40, constants can be declared in the public sections of global classes and type pools can be replaced by global classes.

Class pools

serve as containers for exactly one global class. Besides the global class, they can contain global types/data and local classes/interfaces to be used in the global class. A class pool is executed by calling a public method of its global class. This can be done from any ABAP program, but also via a transaction code connected to one of its public methods. You maintain class pools in the class builder.

Interface pools

serve as containers for exactly one global interface -- nothing more and nothing less. You use an interface pool by implementing its interface in classes and by creating reference variables with the type of its interface. You maintain interface pools in the class builder.

Regards

Sudheer

[Former Member]

Rajesh,

1.Executable :

This is only for executable reports.(Ordinary Reports)

2.Include :

These are not self executable programs.We can write the reusable code which using more than one programs.we call these in Executable programs.So that, that functionality will be available to that program.(Reusability of functionality)

3.Modulepool

This is also not self executable program.We have to call it by tcode.

Here we will have dialog screens to allow the user to enter input.

4.Function Group : This is one place where all relavant function module can store.

we can declare global data in this pool which all function modules can commomly use.

5.Subroutine pool : here all relavent function module can store in one subroutine pool.we can use these as external subroutine.

6.Interfacepool : This just like includes ,but this is related to Object oriented programming.

7.Classpool : Here all relavant classes can decalre.

Pls. reward if useful

[Azeemquadri]

ABAP has the following program types:

Executable Program

Type 1; introduced with the REPORT statement; can be started by entering the program name or using a transaction code; can be called using SUBMIT; can have its own screens.

Module Pool

Type M; introduced with the PROGRAM statement; can be started using a transaction code; can be called using CALL TRANSACTION or LEAVE TO TRANSACTION; have their own screens.

Function Group

Type F; introduced with the FUNCTION-POOL statement; non-executable; container for function modules; can have its own screens.

Class Definition

Type K; introduced with the CLASS-POOL statement; non-executable; container for classes; cannot (currently) have its own screens.

Interface Definition

Type J; introduced with the CLASS-POOL statement; non-executable; container for interfaces; cannot have its own screens.

Subroutine Pool

Type S; introduced with the PROGRAM statement; non-executable; container for subroutines; cannot have its own screens.

Type Groups

Type T; introduced with the TYPE-POOL statement; non-executable; container for type definitions; cannot have its own screens.

Include Program

Type I; no introductory statement; non-executable; container for source code modules.

Non-executable programs with types F, K, J, S, and T are loaded into memory as required. Include programs are not separately-compiled units; their source code is inserted into the programs in which the corresponding include statement occurs

Check <a href="http://help.sap.com/saphelp_470/helpdata/en/d3/2e974d35c511d1829f0000e829fbfe/frameset.htm">here.</a>