The R/3 Basis system is the platform for all other applications (financial accounting, logistics, human resources management) in the R/3 System.
This documentation explains just what the Basis system is, and how it ties in with the R/3 System as a whole. It starts by introducing the Basis system in general. The second part concentrates on one central component - the application server. Finally, it will explain about work processes, which are components of the application server.
Position of the Basis System Within the R/3 System
Application Server
Work Processes
Wednesday, July 30, 2008
Position of the Basis System Within the R/3 System
The following sections describe three different views of the R/3 System, which show the role of the Basis system.
The following illustration represents a logical view of the R/3 System.
The difference between the logical view and a hardware- or software-based view is that not all of the above components can be assigned to a particular hardware or software unit. The above diagram shows how the R/3 Basis system forms a central platform within the R/3 System. Below are listed the tasks of the three logical components of the R/3 Basis system.
Kernel and Basis Services
The kernel and basis services component is a runtime environment for all R/3 applications that is hardware-, operating system- and database-specific. The runtime environment is written principally in C and C++. However, some parts are also written in ABAP. The tasks of the kernel and basis services component are as follows:
- Running applications
All R/3 applications run on software processors (virtual machines) within this component. - User and process administration
An R/3 System is a multi-user environment, and each user can run several independent applications. In short, this component is responsible for the tasks that usually belong to an operating system. Users log onto the R/3 System and run applications within it. In this way, they do not come into contact with the actual operating system of the host. The R/3 System is the only user of the host operating system. - Database access
Each R/3 System is linked to a database system, consisting of a database management system (DBMS) and the database itself. The applications do not communicate directly with the database. Instead, they use Basis services. - Communication
R/3 applications can communicate with other R/3 Systems and with non-SAP systems. It is also possible to access R/3 applications from external systems using a BAPI interface. The services required for communication are all part of the kernel and basis services component. - System Monitoring and Administration
The component contains programs that allow you to monitor and control the R/3 System while it is running, and to change its runtime parameters.
ABAP Workbench
The ABAP Workbench component is a fully-fledged development environment for applications in the ABAP language. With it, you can create, edit, test, and organize application developments. It is fully integrated in the R/3 Basis system and, like other R/3 applications, is itself written in ABAP.
Presentation Components
The presentation components are responsible for the interaction between the R/3 System and the user, and for desktop component integration (such as word processing and spreadsheets).
The following illustration represents a software-oriented view of the R/3 System. The software-oriented view describes the various software components that make up the R/3 System. In the software-oriented view, all of the SAPgui components and application servers in the R/3 System make up the R/3 Basis system.
The R/3 Basis system is a multi-tier client/server system. The individual software components are arranged in tiers and function, depending on their position, as a client for the components below them or a server for the components above them. The classic configuration of an R/3 System contains the following software layers:
Database Layer
The database layer consists of a central database system containing all of the data in the R/3 System. The database system has two components - the database management system (DBMS), and the databse itself. SAP does not manufacture its own database. Instead, the R/3 System supports the following database systems from other suppliers: ADABAS D, DB2/400 (on AS/400), DB2/Common Server, DB2/MVS,INFORMIX, Microsoft SQL Server, ORACLE, and ORACLE Parallel Server.
The database does not only contain the master data and transaction data from your business applications, all data for the entire R/3 System is stored there. For example, the database contains the control and Customizing data that determine how your R/3 System runs. It also contains the program code for your applications. Applications consist of program code, screen definitions, menus, function modules, and various other components. These are stored in a special section of the database called the R/3 Repository, and are accordingly called Repository objects. You work with them in the ABAP Workbench.
Application Layer
The application layer consists of one or more application servers and a message server. Each application server contains a set of services used to run the R/3 System. Theoretically, you only need one application server to run an R/3 System. In practice, the services are distributed across more than one application server. This means that not all application servers will provide the full range of services. The message server is responsible for communication between the application servers. It passes requests from one application server to another within the system. It also contains information about application server groups and the current load balancing within them. It uses this information to choose an appropriate server when a user logs onto the system.
Presentation Layer
The presentation layer contains the software components that make up the SAPgui (graphical user interface). This layer is the interface between the R/3 System and its users. The R/3 System uses the SAPgui to provide an intuitive graphical user interface for entering and displaying data. The presentation layer sends the user’s input to the application server, and receives data for display from it. While a SAPgui component is running, it remains linked to a user’s terminal session in the R/3 System.
This software-oriented view can be expanded to include further layers, such as an Intenet Transaction Server (ITS).
Software-oriented and Hardware-oritented View
The software-oriented view has nothing to do with the hardware configuration of the system. There are many different hardware configuration possibilities for both layers and components. When distributing the layers, for example, you can have all layers on a single host, or, at the other extreme, you could have at least one host for each layer. When dealing with components, the distribution of the database components depends on the database sytsem you are using. The application layer and presentation layer components can be distributed across any number of hosts. It is also possible to install more than one application server on a single host. A common configuration is to run the database system and a single application server (containing special database services) on one host, and to run each further application server on its own host. The presentation layer components usually run on the desktop computers of the users.
Advantages of the Multi-tier Architecture
The distribution of the R/3 software over three layers means that the system load is also distributed. This leads to better system performance.
Since the database system contains all of the data for the entire R/3 System, it is subject to a very heavy load when the sytsem is running. It is therefore a good idea not to run application programs on the same host. The architecture of the R/3 System, in which the application layer and database layer are separate, allows you to install them on separate hosts and let them communicate using the network.
It also makes sense to separate program execution from the tasks of processing user input and formatting data output. This is made possible by separating the presentation layer and the application layer. SAPgui and the application servers are designed so that the minimum amount of data has to be transported between the two layers. This means that the presentation layer components can even be used on hosts that have slow connections to application servers a long way away.
The system is highly scalable, due to the fact that the software components of an R/3 System can be distributed in almost any configuration across various hosts. This is particularly valuable in the application layer, where you can easily adapt your R/3 System to meet increasing demand by installing further application servers.
Consequences for Application Programming
The fact that the application and presentation layers are separate carries an important consequence for application programmers. When you run an application program that requires user interaction, control of the program is continually passed backwards and forwards between the layers. When a screen is ready for user input, the presentation layer is active, and the application server is inactive with regard to that particular program, but free for other tasks. Once the user has entered data on the screen, program control passes back to the application layer. Now, the presentation layer is inactive. The SAPgui is still visible to the user during this time, and it is still displaying the screen, but it cannot accept user input The SAPgui does not become active again until the application program has called a new screen and sent it to the presentation server.
As a consequence, the program logic in an application program that occurs between two screens is known as a dialog step.
The following illustration represents a user-oriented view of the R/3 System:
For the user, the visible components of the R/3 System are those that appear as a window on the screen. The windows are generated by the presentation layer of the R/3 System, and form a part of the R/3 Basis system.
Before the user logs onto the R/3 System, he or she must start a utility called SAP Logon, which is installed at the front end. In SAP Logon, the user chooses one of the available R/3 Systems. The program then connects to the message server of that system and obtains the address of a suitable (most lightly-used) application server. It then starts a SAPgui, connected to that application server. The SAP Logon program is then no longer required for this connection.
SAPgui starts the logon screen. Once the user has successfully logged on, it displays the initial screen of the R/3 System in an R/3 window on the screen. Within SAPgui, the R/3 window is represented as a session. After logging on, the user can open up to five further sessions (R/3 windows) within the single SAPgui. These behave almost like independent SAPguis. The different sessions allow you to run different applications in parallel, independently of one another.
Within a session, the user can run applications that themselves call further windows (such as dialog boxes and graphic windows). These windows are not independent - they belong to the session from which they were called. These windows can be either modal (the original window is not ready for input) or amodal (both windows are ready for input).
The user can open other SAPguis, using SAP Logon, to log onto the same system or another R/3 System. The individual SAPguis and corresponding R/3 terminal sessions are totally independent. This means that you can have SAPguis representing the presentation layers of several R/3 Systems open on your desktop computer.
Application Servers in SAP
R/3 programs run on application servers. They are an important component of the R/3 System. The following sections describe application servers in more detail.
Structure of an Application Server
The application layer of an R/3 System is made up of the application servers and the message server. Application programs in an R/3 System are run on application servers. The application servers communicate with the presentation components, the database, and also with each other, using the message server.
The following diagram shows the structure of an application server:
The individual components are:
Work Processes
An application server contains work processes, which are components that can run an application. Each work process is linked to a memory area containing the context of the application being run. The context contains the current data for the application program. This needs to be available in each dialog step. Further information about the different types of work process is contained later on in this documentation.
Dispatcher
Each application server contains a dispatcher. The dispatcher is the link between the work processes and the users logged onto the application server. Its task is to receive requests for dialog steps from the SAPgui and direct them to a free work process. In the same way, it directs screen output resulting from the dialog step back to the appropriate user.
Gateway
Each application server contains a gateway. This is the interface for the R/3 communication protocols (RFC, CPI/C). It can communicate with other application servers in the same R/3 System, with other R/3 Systems, with R/2 Systems, or with non-SAP systems.
The application server structure as described here aids the performance and scalability of the entire R/3 System. The fixed number of work processes and dispatching of dialog steps leads to optimal memory use, since it means that certain components and the memory areas of a work process are application-independent and reusable. The fact that the individual work processes work independently makes them suitable for a multi-procecssor architecuture. The methods used in the dispatcher to distribute tasks to work processes are discussed more closely in the section Dispatching Dialog Steps.
Shared Memory
All of the work processes on an application server use a common main memory area called shared memory to save contexts or to buffer constant data locally.
The resources that all work processes use (such as programs and table contents) are contained in shared memory. Memory management in the R/3 System ensres that the work processes always address the correct context, that is the data relevant to the current state of the program that is running. A mapping process projects the required context for a dialog step from shared memory into the address of the relevant work process. This reduces the actual copying to a minimum.
Local buffering of data in the shared memory of the application server reduces the number of database reads required. This reduces access times for application programs considerably. For optimal use of the buffer, you can concentrate individual applications (financial accounting, logistics, human resources) into separate application server groups.
Database Connection
When you start up an R/3 System, each application server registers its work proceses with the database layer, and receives a single dedicated channel for each. While the system is running, each work process is a user (client) of the database system (server). You cannot change the work process registration while the system is running. Neither can you reassign a database channel from one work process to another. For this reason, a work process can only make database changes within a single database logical unit of work (LUW). A database LUW is an inseparable sequence of database operations. This has important consequences for the programming model explained below.
Dispatching Dialog Steps
The number of users logged onto an application server is often many times greater than the number of available work processes. Furthermore, it is not restricted by the R/3 system architecture. Furthermore, each user can run several applications at once. The dispatcher has the important task of distributing all dialog steps among the work processes on the application server.
The following diagram is an example of how this might happen:
- The dispatcher receives the request to execute a dialog step from user 1 and directs it to work process 1, which happens to be free. The work process addresses the context of the application program (in shared memory) and executes the dialog step. It then becomes free again.
- The dispatcher receives the request to execute a dialog step from user 2 and directs it to work process 1, which is now free again. The work process executes the dialog step as in step 1.
- While work process 1 is still working, the dispatcher receives a further request from user 1 and directs it to work process 2, which is free.
- After work processes 1 and 2 have finished processing their dialog steps, the dispatcher receives another request from user 1 and directs it to work process 1, which is free again.
- While work process 1 is still working, the dispatcher receives a further request from user 2 and directs it to work process 2, which is free.
From this example, we can see that:
- A dialog step from a program is assigned to a single work process for execution.
- The individual dialog steps of a program can be executed on different work processes, and the program context must be addressed for each new work process.
- A work process can execute dialog steps of different programs from different users.
The example does not show that the dispatcher tries to distribute the requests to the work processes such that the same work process is used as often as possible for the successive dialog steps in an application. This is useful, since it saves the program context having to be addressed each time a dialog step is executed.
Dispatching and the Programming Model
The separation of application and presentation layer made it necessary to split up application programs into dialog steps. This, and the fact that dialog steps are dispatched to individual work processes, has had important consequences for the programming model.
As mentioned above, a work process can only make database changes within a single database logical unit of work (LUW). A database LUW is an inseparable sequence of database operations. The contents of the database must be consistent at its beginning and end. The beginning and end of a database LUW are defined by a commit command to the database system (database commit). During a database LUW, that is, between two database commits, the database system itself ensures consistency within the database. In other words, it takes over tasks such as locking database entries while they are being edited, or restoring the old data (rollback) if a step terminates in an error.
A typical SAP application program extends over several screens and the corresponding dialog steps. The user requests database changes on the individual screens that should lead to the database being consistent once the screens have all been processed. However, the individual dialog steps run on different work processes, and a single work process can process dialog steps from other applications. It is clear that two or more independent applications whose dialog steps happen to be processed on the same work process cannot be allowed to work with the same database LUW.
Consequently, a work process must open a separate datables LUW for each dialog step. The work process sends a commit command (database commit) to the database at the end of each dialog step in which it makes database changes. These commit commands are called implicit database commits, since they are not explicitly written into the application program.
These implicit database commits mean that a database LUW can be kept open for a maximum of one dialog step. This leads to a considerable reduction in database load, serialization, and deadlocks, and enables a large number of users to use the same system.
However, the question now arises of how this method (1 dialog step = 1 database LUW) can be reconciled with the demand to make commits and rollbacks dependent on the logical flow of the application program instead of the technical distribution of dialog steps. Database update requests that depend on one another form logical units in the program that extend over more than one dialog step. The database changes associated with these logical units must be executed together and must also be able to be undone together.
The SAP programming model contains a seies of bundling techniques that allow you to group database updates together in logical units. The section of an R/3 application program that bundles a set of logically-associated database operations is called an SAP LUW. Unlike a database LUW, a SAP LUW includes all of the dialog steps in a logical unit, including the database update.
Work Processes in SAP ABAP
Work processes execute the individual dialog steps in R/3 applications. The next two sections describe firstly the structure of a work process, and secondly the different types of work process in the R/3 System.
Work processes execute the dialog steps of application programs. They are components of an application server. The following diagram shows the components of a work process:
Each work process contains two software processors and a database interface.
Screen Processor
In R/3 application programming, there is a difference between user interaction and processing logic. From a programming point of view, user interaction is controlled by screens. As well as the actual input mask, a screen also consists of flow logic. The screen flow logic controls a large part of the user interaction. The R/3 Basis system contains a special language for programming screen flow logic. The screen processor executes the screen flow logic. Via the dispatcher, it takes over the responsibility for communication between the work process and the SAPgui, calls modules in the flow logic, and ensures that the field contents are transferred from the screen to the flow logic.
ABAP-Prozessor
The actual processing logic of an application program is written in ABAP - SAP’s own programing language. The ABAP processor executes the processing logic of the application program, and communicates with the database interface. The screen processor tells the ABAP processor which module of the screen flow logic should be processed next. The following screen illustrates the interaction between the screen and the ABAP processors when an application program is running.
The database interface provides the following services:
- Establishing and terminating connections between the work process and the database.
- Access to database tables
- Access to R/3 Repository objects (ABAP programs, screens and so on)
- Access to catalog information (ABAP Dictionary)
- Controlling transactions (commit and rollback handling)
- Table buffer administration on the application server.
The following diagram shows the individual components of the database interface:
The diagram shows that there are two different ways of accessing databases: Open SQL and Native SQL.
Although all work processes contain the components described above, they can still be divided into different types. The type of a work process determines the kind of task for which it is responsible in the application server. It does not specify a particular set of technical attributes. The individual tasks are distributed to the work processes by the dispatcher.
Before you start your R/3 System, you determine how many work processes it will have, and what their types will be. The dispatcher starts the work processes and only assigns them tasks that correspond to their type. This means that you can distribute work process types to optimize the use of the resources on your application servers.
The following diagram shows again the structure of an application server, but this time, includes the various possible work process types:
The various work processes are described briefly below. Other parts of this documentation describe the individual components of the application server and the R/3 System in more detail.
Dialog Work Process
Dialog work processes deal with requests from an active user to execute dialog steps.
Update Work Process
Update work processes execute database update requests. Update requests are part of an SAP LUW that bundle the database operations resulting from the dialog in a database LUW for processing in the background.
Background Work Process
Background work processes process programs that can be executed without user interaction (background jobs).
Enqueue Work Process
The enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for the R/3 System and is an important part of the SAP LUW concept. In an R/3 System, you may only have one lock table. You may therefore also only have one application server with enqueue work processes.
Spool Work Process
The spool work process passes sequential datasets to a printer or to optical archiving. Each application server may contain only one spool work process.
The services offered by an application server are determined by the types of its work processes. One application server may, of course, have more than one function. For example, it may be both a dialog server and the enqueue server, if it has several dialog work processes and an enqueue work process.
You can use the system administration functions to switch a work process between dialog and background modes while the system is still running. This allows you, for example, to switch an R/3 System between day and night operation, where you have more dialog than background work processes during the day, and the other way around during the night.
Overview of the Components of Application Programs in SAP ABAP
This overview describes application programming in the R/3 System. All application programs, along with parts of the R/3 Basis system, are written in the ABAP Workbench using ABAP, SAP’s programming language. The individual components of application programs are stored in a special section of the database called the R/3 Repository. The R/3 Repository serves as a central store for all of the development objects in the R/3 System. The following sections of this documentation cover the basics and characteristics of application programming.
Structure of an Application Program
Screens
Structure of the Processing Logic
Processing Blocks in ABAP Programs
ABAP Statements
Logical Databases and Contexts
Memory Structures of an ABAP Program
Structure of an Application Program
Screens
Structure of the Processing Logic
Processing Blocks in ABAP Programs
ABAP Statements
Logical Databases and Contexts
Memory Structures of an ABAP Program
Structure of an Application Program in SAP ABAP
R/3 application programs run within the R/3 Basis system on the work processes of application servers. This makes them independent of the hardware and operating system that you are using. However, it also means that you cannot run them outside the R/3 System.
As described in the Overview of the R/3 Basis System, a work process contains a screen processor for processing user input, an ABAP processor for processing the program logic, and a database interface for communicating with the database. These components of a work process determine the following structure of an applciation program:
An application program consists of two components, each of which has a different task:
Flow Logic
Interaction between application programs and the user is implemented using screens. Screens are processed by the screen processor of a work process. As well as the input mask, they consist of flow logic. This is coding, written using a special set of keywords called the screen language. The input mask is displayed by the SAPgui, which also transfers the user action on the screen back to the flow logic. In the program flow, screens react to the user actions and call program modules. These program modules form the processing logic.
Processing logic
The components of application programs that are responsible for data processing in the R/3 System are ABAP programs. ABAP stands for ‘Advanced Business Application Programming’. ABAP programs run on the ABAP processor of a work process. They receive screen input from the screen processor and send it to the screen processor. You access the database using the database interface. ABAP contains a special set of commands called OPEN SQL. This allows you to read from and write to the database regardless of the database you are using. The database interface converts the OPEN SQL commands into commands of the relevant database. You can also use native SQL commands, which are passed to the database without first being converted. There is a range of further interfaces such as memory, sequential files and external interfaces. These provide other means of sending data to and from ABAP programs. When working together with screens, ABAP programs play a more passive role, acting as a container for a set of modules that can be called from the flow logic.
Screens in SAP ABAP
Each screen that a user sees in the R/3 System belongs to an application program. Screens send data to, receive data from, and react to the user’s interaction with the input mask. There are three ways to organize screen input and output. These differ in the way in which they are programmed, and in how the user typically interacts with them.
Screens
In the most general case, you create an entire screen and its flow logic by hand using the Screen Painter in the ABAP Workbench.
Selection Screens and Lists
There are two special kinds of screen in the R/3 System that you will often use - selection screens and lists. These screens and their flow logic are generated from ABAP statements in the processing logic. In this case, you do not have to work with the Screen Painter. Instead, you define the entire screen in the processing logic.
Screens in the R/3 System also contain a menu bar, a standard toolbar, and an application toolbar. Together, these three objects form the status of the screen. Each status is an object of its corresponding application program. It is a standalone part of the screen . Since it does not expressly belong to one screen, it can be reused in any number of screens. You define statuses using the Menu Painter in the ABAP Workbench. You can define your own statuses for screens and lists. Selection screens have a fixed status.
The following sections describe the different types of screen in more detail.
Each screen contains an input mask that you can use for data input and output. You can design the mask yourself. When the screen mask is displayed by the SAPgui, two events are triggered: Before the screen is displayed, the Process Before Output (PBO) event is processed. When the user interacts with the screen, the Process After Input (PAI) event is processed.
Each screen is linked to a single PBO processing block and a single PAI processing block. The PAI of a screen and the PBO of the subsequent screen together form a dialog step in the application program.
The screen language is a special subset of ABAP, and contains only a few keywords. The statements are syntactically similar to the other ABAP statements, but you may not use screen statements in ABAP programs or ABAP statements in the screen flow logic. The most important screen keywords are MODULE, FIELD, CHAIN, and LOOP. Their only funciton is to link the processing logic to the flow logic, that is, to call modules in the processing logic, and control data transfer between the screen and the ABAP program, for example, by checking fields.
The input/output mask of a screen contains all of the normal graphical user interface elements, such as input/output fields, pushbuttons, and radio buttons. The following diagram shows a typical screen mask:
All of the active elements on a screen have a field name and are linked to screen fields in shared memory. You can link screen fields to the ABAP Dictionary. This provides you with automatic field and value help, as well as consistency checks.
When a user action changes the element, the value of the screen field is changed accordingly. Values are transported between screens and the processing logic in the PAI event, where the contents of the screen fields are transported to program fields with the same name.
Each screen calls modules in its associated ABAP program which prepare the screen (PBO) and process the entries made by the user (PAI). Although there are ABAP statements for changing the attributes of screen elements (such as making them visible or invisible), but there are none for defining them.
Dialog screens enable the user and application programs to communicate with each other. They are used in dialog-oriented programs such as transactions, where the program consists mainly of processing a sequence of screens. Essentially, you use screens when you need more flexibility than is offered by selection screens or lists.
Selection screens are special screens used to enter values in ABAP programs. Instead of using the Screen Painter, you create them using ABAP statements in the processing logic of your program. The selection screen is then generated according to these statements. The screen flow logic is supplied by the system, and remains invisible to you as the application programmer.
You define selection screens in the declaration part of an ABAP program using the special declaration statements PARAMETERS, SELECT-OPTIONS and SELECTION-SCREEN). These statements declare and format the input fields of each selection screen. The following is a typical selection screen:
The most important elements on a selection screen are input fields for single values and for selection tables. Selection tables allow you to enter more complicated selection criteria. Selection tables are easy to use in ABAP because the system automatically processes them itself. As on other screens, field and possible values help is provided for input fields which refer to an ABAP Dictionary field. Users can use pre-configured sets of input values for selection screens. These are called variants.
You call a selection screen from an ABAP program using the CALL SELECTION-SCREEN statement. If the program is an executable (report) with type 1, the ABAP runtime environment automatically calls the selection screen defined in the declaration part of the program. Selection screens trigger events, and can therefore call event blocks in ABAP programs.
Since selection screens contain principally input fields, selection screen dialogs are more input-oriented than the screens you define using the Screen Painter. Dialog screens can contain both input and output fields. Selection screens, however, are appropriate when the program requires data from the user before it can continue processing. For example, you would use a selection screen before accessing the database, to restrict the amount of data read.
Lists are output-oriented screens which display formatted, structured data. They are defined, formatted, and filled using ABAP commands. The system displays lists defined in ABAP on a special list screen. As with selection screens, the flow logic is supplied by the system and remains hidden from the application programmer.
The most important task of a list is to display data. However, users can also interact with them. Lists can react to mouse clicks and contain input fields. Despite these similarities with other types of screen, lists are displayed using a completely different technique. Input fields on lists cannot be compared with those on normal screens, since the method of transferring data between the list and the ABAP program is completely different in each case. If input fields on lists are linked to the ABAP Dictionary, the usual automatic field and possible values help is available. The following is a typical list:
You define lists using a special set of statements (the list statements WRITE, SKIP, ULINE, NEW-PAGE and so on) in the processing blocks of ABAP programs. When these statements are executed, a list is composed within the system. An internal system program called the list processor is responsible for displaying lists and for interpreting user actions in the list. Lists are important because only data in list format can be sent to the R/3 spool system for printing.
In an ABAP program, you can use the LEAVE TO LIST-PROCESSING statement to define the next screen as a list. If the ABAP program is an executable (report) with type 1, the ABAP runtime environment automatically calls the list defined in your program. A single program can be responsible for a stack of up to 21 lists. From one basic list, you can create up to 20 details lists. User actions on a list screen trigger events, and can thus call event blocks in the ABAP program.
Lists are output-oriented. When users carry out actions on a list screen, it is normally to use part of the list contents in the next part of the program, and not to input values directly. Using lists is appropriate when you want to work with output data, to print data or when the user’s next action depends on output data.
Structure of ABAP Programs
ABAP processing logic is responsible for processing data in R/3 application programs. ABAP was designed specifically for dialog-oriented database applications. The following sections deal with how an ABAP program is structured and executed.
ABAP programs are responsible for data processing within the individual dialog steps of an application program. This means that the program cannot be constructed as a single sequential unit, but must be divided into sections that can be assigned to the individual dialog steps. To meet this requirement, ABAP programs have a modular structure. Each module is called a processing block. A processing block consists of a set of ABAP statements. When you run a program, you effectively call a series of processing blocks. They cannot be nested.
The following diagram shows the structure of an ABAP program:
Each ABAP program consists of the following two parts:
Declaration Part for Global Data, Classes and Selection Screens
The first part of an ABAP program is the declaration part for global data, classes, and selection screens. This consists of:
- All declaration statements for global data. Global data is visible in all internal processing blocks. You define it using declarative statements that appear before the first processing block, in dialog modules, or in event blocks. You cannot declare local data in dialog modules or event blocks.
- All selection screen definitions.
- All local class definitions (CLASS DEFINITION statement). Local classes are part of ABAP Objects, the object-oriented extension of ABAP.
Declaration statements which occur in procedures (methods, subroutines, function modules) form the declaration part for local data in those processing blocks. This data is only visible within the procedure in which it is declared.
Container for Processing Blocks
The second part of an ABAP program contains all of the processing blocks for the program. The following types of processing blocks are allowed:
- Dialog modules (no local data area)
- Event blocks (no local data area)
- Procedures (methods, subroutines and function modules with their own local data area).
Whereas dialog modules and procedures are enclosed in the ABAP keywords which define them, event blocks are introduced with event keywords and concluded implicitly by the beginning of the next processing block.
All ABAP statements (except declarative statements in the declaration part of the program) are part of a processing block. Non-declarative ABAP statements, which occur between the declaration of global data and a processing block are automatically assigned to the START-OF-SELECTION processing block.
Calling Processing Blocks
You can call processing blocks either from outside the ABAP program or using ABAP commands which are themselves part of a processing block. Dialog modules and event blocks are called from outside the ABAP program. Procedures are called using ABAP statements in ABAP programs.
Calling event blocks is different from calling other processing blocks for the following reasons:
An event block call is triggered by an event. User actions on selection screens and lists, and the runtime environment trigger events that can be processed in ABAP programs. You only have to define event blocks for the events to which you want the program to react (whereas a subroutine call, for example, must have a corresponding subroutine). This ensures that while an ABAP program may react to a particular event, it is not forced to do so.
When you run an ABAP program, you call its processing blocks. ABAP programs are controlled from outside the program itself by the processors in the current work process. For the purposes of program flow, we can summarize the screen processor and ABAP processor into the ABAP runtime environment. The runtime environment controls screens and ABAP processing blocks. It contains a range of special control patterns that call screens and processing blocks in certain orders. These sections are also called processors. When you run an ABAP program, the control passes between various processors.
In the R/3 System, there are various types of ABAP program. The program type determines the basic technical attributes of the program, and you must set it when you create it. The main difference between the different program types is the way in which the runtime environment calls its processing blocks.
When you run an application program, you must call at least the first processing block from outside the program, that is, from the runtime environment. This processing block can then either call further processing blocks or return control to the runtime environment. When you start an ABAP program, the runtime environment starts a processor (dependent on the program type), which calls the first ABAP processing block. An ABAP program can be started either by the user or by the system (for example, in background processing), or through an external interface (for example, Remote Function Call).
There are two ways of allowing users to execute programs - either by entering the program name or by entering a transaction code. You can assign a transaction code to any program. Users can then start that program by entering the code in the command field. Transaction codes are also usually linked to a menu path within the R/3 System.
The following program types are relevant to application programming:
Type 1
Type 1 programs have the important characteristic that they do not have to be controlled using user-defined screens. Instead, they are controlled by the runtime environment, which calls a series of processing blocks (and selection screens and lists where necessary) in a fixed sequence. User actions on screens can then trigger further processing blocks.
You can start a type 1 program and the corresponding processor in the runtime environment using the SUBMIT statement in another ABAP program. There are also various ways of starting a type1 program by entering its program name. This is why we refer to type 1 programs as executable programs.
When you run a type 1 program, a series of processors run in a particular order in the runtime environment. The process flow allows the user to enter selection parameters on a selection screen. The data is them selected from the database and processed. Finally, an output list is displayed. At no stage does the programmer have to define his or her own screens. The runtime environment also allows you to work with a logical database. A logical database is a special ABAP program which combines the contents of certain database tables. The flow of a type 1 program is oriented towards reporting, whose main tasks are to read data from the database, process it, and display the results. This is why executable programs (type 1) in the R/3 System are often referred to as reports, and why running an executable program is often called reporting.
Since it is not compulsory to define event blocks, you can yourself determine the events to which your ABAP program should react. Furthermore, you can call your own screens or processing blocks at any time, leaving the prescribed program flow. You can use this, for example, to present data in a table on a dialog screen instead of in a list. The simplest executable program (report) contains only one processing block (START-OF-SELECTION).
Executable programs do not require any user dialog. You can fill the selection screen using a variant and output data directly to the spool system instead of to a list. This makes executable programs (reports) the means of background processing in the R/3 System.
You can also assign a transaction code to an executable program. Users can then start it using the transaction code and not the program name. The reporting-oriented runtime environment is also called when you run a report using a transaction code. This kind of transaction is called a report transaction.
It is appropriate to use executable programs (reports) when the flow of your program corresponds either wholly or in part to the pre-defined flow of the runtime environment. Until Release 4.5A, the only way to use a logical database was to use an executable program. However, from Release 4.5A, it is also possible to call logical databases on their own.
Type M
The most important technical attribute of a type M program is that it can only be controlled using screen flow logic. You must start them using a transaction code, whcih is linked to the program and one of its screens (initial screen). Another feature of these programs is that you must define your own screens in the Screen Painter (although the intial screen can be a selection screen).
When you start a program using a transaction code, the runtime environment starts a processor that calls the initial screen. This then calls a dialog module in the corresponding ABAP program. The remainder of the program flow can take any form. For example, the dialog module can:
- return control to the screen, after which, the processing passes to a subsequent screen. Each screen has a following screen, set either statically or dynamically.
- call other sequences of screens, selection screens or lists, from which further processing blocks in the ABAP program are started.
- call other processing blocks itself, either internally or externally.
- call other application programs using CALL TRANSACTION (type M program) or SUBMIT (type 1 program).
ABAP programs with type M contain the dialog modules belonging to the various screens. They are therefore known as module pools. It is appropriate to use module pools when you write dialog-oriented programs using a large number of screens whose flow logic largely determines the program flow.
Type F
Type F programs are containers for function modules, and cannot be started using a transaction code or by entering their name directly. Function modules are special procedures that you can call from other ABAP programs.
Type F programs are known as function groups. Function modules may only be programmed in function groups. The Function Builder is a tool in the ABAP Workbench that you can use to create function groups and function modules. Apart from function modules, function groups can contain global data declarations and subroutines. These are visible to all function modules in the group. They can also contain event blocks for screens in function modules.
Type K
You cannot start type K programs using a transaction code or by entering the program name. They are containers for global classes in ABAP Objects . Type K programs are known as class definitions. The Class Builder is a tool in the ABAP Workbench that you can use to create class definitions.
Type J
You cannot start type J programs using a transaction code or by entering the program name. They are containers for global interface in ABAP Objects . Type J programs are known as interface definitions. Like class definitions, you create interface definitions in the Class Builder.
Type S
You cannot start a type S program using a transaction code or by entering the program name. Instead, they are containers for subroutines, which you can call externally from other ABAP programs. Type S programs are known as subroutine pools. They cannot contain screens.
Type I
Type I programs - called includes - are a means of dividing up program code into smaller, more manageable units. You can insert the coding of an include program at any point in another ABAP program using the INCLUDE statement. There is no technical relationship between include programs and processing blocks. Includes are more suitable for logical programming units, such as data declarations, or sets of similar processing blocks. The ABAP Workbench has a mechanism for automatically dividing up module pools and function groups into include programs.
Processing Blocks in ABAP Programs
The following sections explain the different processing blocks in ABAP programs and how they are called.
Dialog Modules
You call dialog modules from the screen flow logic (screen command MODULE). You can write a dialog module in an ABAP program for each state (PBO, PAI; user input) of any of the screens belonging to it. The PAI modules of a screen together with the PBO modules of the subsequent screen form a dialog step. The interaction between the flow logic and the screen is controlled by a dialog processor.
Dialog modules are introduced with the MODULE statement and concluded with the ENDMODULE statement.
Fields on a dialog screen have the same name as a corresponding field in the ABAP program. Data is passed between identically-named fields in the program. You do notdefine dialog screens in the ABAP programs.
Event Blocks for Selection Screens
A selection screen is a special kind of dialog screen that you create using ABAP commands in the declaration part of the program. The different events in a selection screen (PAI, PBO, user input), are controlled by a selection screen processor. You can program processing logic for these events in your program. The selection screen processor controls the flow logic of the selection screen.
You do not have to create the screen flow logic yourself, neither can you create your own dialog modules for the PBO or PAI events . Data is passed between selection screen and ABAP program using the fields (parameters and selection tables) which you create in the selection screen definition in the declaration part of the ABAP program.
Event Blocks for Lists
Lists are special screens which output formatted data. You can create them in any processing block in an ABAP program using a special set of commands (such as WRITE, NEW-PAGE and so on). The list processor displays the list on the screen and handles user actions within lists. The list processor controls the flow logic of the list. You do not have to create the screen flow logic yourself, neither can you create your own dialog modules for the PBO or PAI events .
You can call various event blocks while the list is being created which are used in page formatting. The above illustration contains the event block TOP-OF-PAGE, which is called from the ABAP program itself. When the list is displayed, the user can carry out actions which trigger event blocks for interactive list events (such as AT LINE-SELECTION). You can program processing logic for the interactive list events in your program. Data is transferred from list to ABAP program via system fields or an internal memory area called the HIDE area.
Event Blocks for Executable Programs (Reports)
When you run an executable program (type 1), it is controlled by a predefined process in the runtime environment. A series of processors is called, one after the other. These processors trigger events, for which you can define event blocks. Type 1 programs are event-driven.
The process is as follows:
- The runtime environment creates the INITIALIZATION event and calls the corresponding event block (if it has been defined in the ABAP program).
- If there is a selection screen defined in the program, control returns to the selection screen processor. This generates the corresponding events and calls their event blocks.
- Control then passes to the reporting processor. It creates the START-OF-SELECTION event and calls the corresponding event block (if it has been defined in the ABAP program).
- The logical database, if you are using one, calls further event blocks at this point.
- The reporting processor creates the END-OF-SELECTION event and calls the corresponding event block (if it has been defined in the ABAP program).
- If the program contains a list description, control now passes to the list processor. The list processor displays the list defined in the ABAP program. It converts user actions on the list into events and calls the corresponding event blocks.
Subroutines
You call subroutines from ABAP programs using the PERFORM statement.
Subroutines are introduced with the FORM statement and concluded with the ENDFORM statement.
You can define subroutines in any ABAP program. You can either call a subroutine that is part of the same program or an external subroutine, that is, one that belongs to a different program. If you call an internal subroutine, you can use global data to pass values between the main program and the subroutine. When you call an external subroutine, you must pass actual parameters from the main program to formal parameters in the subroutine.
Function Modules
Function modules are external functions with a defined interface. You call function modules from ABAP programs using the CALL FUNCTION statement.
Function modules are introduced with the FUNCTION statement and concluded with the ENDFUNCTION statement.
You can only create function groups within special ABAP programs called function groups using the Function Builder. This means that you can only call them externally from other ABAP programs. Unlike subroutines, you always pass data to function modules using an explicit parameter interface.
Methods
Methods describe the functions of classes in ABAP Objects. Like function modules, they have a defined interface. You call methods from ABAP programs using the CALL METHOD statement.
Methods are introduced with the METHOD statement and concluded with the ENDMETHOD statement.
Methods can only be defined in the implementation parts of classes. You can either do this globally in the Class Builder, or locally within ABAP programs. Methods can work with the attributes of their class and with data that you pass to them using their explicit parameter interface.
ABAP Statements in SAP ABAP
The source code of an ABAP program consists of comments and ABAP statements. Comments are distinguished by the preceding signs * (at the beginning of a line) and " (at any position in a line). ABAP statements always begin with an ABAP keyword and are always concluded with a period (.) . Statements can be several lines long; conversely, a line may contain more than one statement. ABAP statements use ABAP data types and objects.
The first element of an ABAP statement is the ABAP keyword. This determines the category of the statements. The different statement categories are as follows:
Declarative Statements
These statements define data types or declare data objects which are used by the other statements in a program or routine. The collected declarative statements in a program or routine make up its declaration part.
Examples of declarative keywords:
TYPES, DATA, TABLES
Modularization Statements
These statements define the processing blocks in an ABAP program.
The modularization keywords can be further divided into:
· Event Keywords
You use statements containing these keywords to define event blocks. There are no special statements to conclude processing blocks - they end when the next processing block is introduced.
Examples of event keywords are:
AT SELECTION SCREEN, START-OF-SELECTION, AT USER-COMMAND
· Defining keywords
You use statements containing these keywords to define subroutines, function modules, dialog modules and methods. You conclude these processing blocks using the END- statements.
Examples of definitive keywords:
FORM ..... ENDFORM, FUNCTION ... ENDFUNCTION,
MODULE ... ENDMODULE.
Control Statements
You use these statements to control the flow of an ABAP program within a processing block according to certain conditions.
Examples of control keywords:
IF, WHILE, CASE
Call Statements
You use these statements to call processing blocks that you have already defined using modularization statements. The blocks you call can either be in the same ABAP program or in a different program.
Examples of call keywords:
PERFORM, CALL, SET USER-COMMAND, SUBMIT, LEAVE TO
Operational Statements
These keywords process the data that you have defined using declarative statements.
Examples of operational keywords:
WRITE, MOVE, ADD
Database Statements
These statements use the database interface to access the tables in the central database system. There are two kinds of database statement in ABAP: Open SQL and Native SQL.
Open SQL
Open SQL is a subset of the standard SQL92 language. It contains only Data Manipulation Language (DML) statements, such as SELECT, IINSERT, and DELETE. It does not contain any Data Definition Language (DDL) statements (such as CREATE TABLE or CREATE INDEX). Functions of this type are contained in the ABAP Dictionary. Open SQL contains all of the DML functions from SQL92 that are common to all of the database systems supported by SAP. It also contains a few SAP-specific functions. ABAP programs that use only Open SQL statements to access the database are fully portable. The database interface converts the OPEN SQL commands into commands of the relevant database.
Native SQL
Native SQL statements are passed directly from the database interface to the database without first being converted. It allows you to take advantage of all of your database’s characteristics in your programs. In particular, it allows you to use DDL operations. The ABAP Dictionary uses Native SQL for tasks such as creating database tables. In ordinary ABAP programs, it is not worth using DDL statements, since you cannot then take advantage of the central administration functions of thie ABAP Dictionary. ABAP programs that use Native SQL statements are database-specific, because there is no standardized programming interface for SQL92.
The physical units with which ABAP statements work at runtime are called internal program data objects. The contents of a data object occupy memory space in the program. ABAP statements access these contents by addressing the name of the data object. For example, statements can write the contents of data objects in lists or in the database, they can pass them to and receive them from routines, they can change them by assigning new values, and they can compare them in logical expressions.
Each ABAP data object has a set of technical attributes, which are fully defined at all times when an ABAP program is running. The technical attributes of a data object are: Data type, field length, and number of decimal places.
The data type determines how the contents of a data object are interpreted by ABAP statements. As well as occurring as attributes of a data object, data types can also be defined independently. You can then use them later on in conjunction with a data object. You can define data types independently either in the declaration part of an ABAP program (using the TYPES statement), or in the ABAP Dictionary.
The data types you will use in a program depend on how you will use your data objects. The task of an ABAP program can range from passing simple input data to the database to processing and outputting a large quantity of structured data from the database. ABAP contains the following data types:
Predefined and User-defined Elementary Types
There are five predefined non-numeric data types:
Character string (C), Numeric character string (N), Date (D), Time (T) and Hexadecimal (X)
and three predefined numeric types:
Integer (I), Floating-point number (F) and Packed number (P).
The field length for data types D, F, I, and T is fixed. The field length determines the number of bytes that the data object occupies in memory. In types C, N ,X and P, the length is not part of the type definition. Instead, you define it when you declare the data object in your program.
Data type P is particularly useful for exact calculations in a business context. When you define an object with type P, you also specify a number of decimal places.
You can also define your own elementary data types in ABAP using the TYPES statement. You base these on the predefined data types. This determines all of the technical attribtues of the new data type. For example, you could define a data type P_2 with two decimal places, based on the predefined data type P. You could then use this new type in your data declarations.
You use elementary data types to define individual elementary data objects. You use these object to transfer input and output values, as auxiliary fields in calculations, to store intermediate results, and so on. The aggregated data types described below are made up of elementary data types.
An aggregated data type can be a structure or an internal table.
Structures
A structure is a user-defined sequence of data types. It fully defines the data object. You can either access the entire data object, or its individual components. ABAP has no predefined structures. You therefore need to define your own structures, either in the ABAP program in which you want to use it, or in the ABAP Dictionary.
You use structures in ABAP programs to group work areas that logically belong together. Since the individual elements within a structure can be of any type, and can also themselves be structures or internal tables, the possible uses of structures are very wide-ranging. For example, you can use a structure with elementary data types to display lines from a database table within a program. You can also use structures containing aggregated elements to include all of the attributes of a screen or control in a single data object.
Internal Tables
Internal tables consists of a series of lines that all have the same data type.
Internal tables are characterized by:
· Their line type.
The line type of an internal table can be any ABAP data type - an elementary type, a structure or an internal table.
· A key
The key of an internal table is used to identify its entries. It is made up of the elementary fields in the line. The key may be unique or non-unique.
· The access type
The access method determines how ABAP will access individual table entries. There are three access types, namely unsorted tables, sorted index tables and hash tables.
For index tables, the system maintains a linear index, so you can access the table either by specifying the index or the key.
Hashed tables have no linear index. You can only access hashed tables by specifying the key. The system has its own hash algorithm for managing the table.
You should use internal tables whenever you need to use structured data within a program. One imprint use is to store data from the database within a program.
Data Types for Reference
You use references to refer to objects in ABAP Objects. References are stored in reference variables. The data type of the reference determines how it is handled in the program. There are different types for class and interface variables.
Reference variables in ABAP are treated like other elementary data objects. This means that a reference variable can occur as a component of a structure or internal table as well as on its own.
Declaring Data Objects
Apart from the interface parameters of routines, you declare all of the data objects in an ABAP program or routine in its declaration part. The declarative statements establish the data type of the object, along with any missing technical attributes, such as its length or the number of decimal places. This all takes place before the program is actually executed. The exception to this are internal tables.
When you declare an internal table, you specify the above details. However, you do not need to specify the overall size of the data object. Only the length of a row in an internal table is fixed. The number of rows (the actual length of the data object in memory) is adapted dynamically at runtime. In short, internal tables can be extended dynamically while retaining a fixed structure.
The interface parameters of routines are generated as local data objects, but not until the routine is called. You can define the technical attributes of the interface parameters in the routine itself. If you do not, they adopt the attributes of the parameters from which they receive their values.
Logical Databases and Contexts in SAP ABAP
This section introduces logical databases and contexts - two methods that make it easier to read data from database tables. Both of them encapsulate Open SQL statements in separate ABAP programs.
Logical Databases
Logical databases are special ABAP programs that read data from database tables. They are used by executable (type 1) programs. At runtime, you can regard the logical database and the executable program (reports) as a single ABAP program, whose processing blocks are called by the runtime environment in a particular, pre-defined sequence.
You edit logical databases using a tool within the ABAP Workbench, and link them to executable programs (reports) when you enter the program attributes. You can use a logical database with any number of executable programs (reports). From Release 4.5A, it is also possible to call logical databases on their own.
Structure of a Logical Database
The following diagram shows the structure of a logical database, which can be divided into three sections:
Structure
The structure of a logical database determines the database tables which it can access. It adopts the hierarchy of the database tables defined by their foreign key relationships. This also controls the sequence in which the tables are accessed.
Selection Part
The selection part of the logical database defines input fields for selecting data. The runtime environment displays these on the selection screen when you run an executable program linked to the logical database. The corresponding fields are also available in the ABAP program, allowing you, for example, to change their values to insert default values on the selection screen.
Database Program
The database program of a logical database is a container for special subroutines, in which the data is read from the database tables. These subrotuines are called by the reporting processor in the runtime environment in a predefined sequence.
Running Type 1 Programs with a Logical Database
The following diagram shows the principal processing blocks that are called when you run an executable program linked to a logical database:
The runtime environment calls depend both on the structure of the logical database and on the definition of the executable program. The structure of the logical database determines the sequence in which the processing blocks of the logical database are called. These in turn call GET event blocks in the executable program. These GET event blocks determine the read depth in the structure of the logical database. TABLES or NODES statements in the declaration part of the executable program determine which of the input fields defined in the logical database are included in the selection screen. They also define interface work areas for passing data between the logical database and the executable program.
The actual access to the R/3 System database is made using OPEN SQL statements in the PUT_subroutines. The data that is read is passed to the executable program using the interface work areas (defined using the TABLES statement). Once the data has been read in the logical database program, the executable program (report) can process the data in the GET event blocks. This technique separates data reading and data processing.Uses of Logical Databases
The main use of logical databases is to make the code that accesses data in database tables reusable. SAP supplies logical databases for all applications. These have been configured for optimal performance, and contain further functions such as authorization checks and search helps. It is appropriate to use logical databases whenever the database tables you want to read correspond largely to the structure of the logical database and where the flow of the system program (select - read - process - display) meets the requirements of the application.
Contexts
In application programming, you often use a relatively small set of basic data to derive further data. This basic data might, for example, be the data that the user enters on the screen. The relational links in the database are often used to read further data on the basis of this basic data, or further values are calculated from it using ABAP statements.
It is often the case that certain relationships between data are always used in the same form to get further data, either within a single program or in a whole range of programs. This means that a particular set of database accesses or calculations is repeatedly executed, despite the fact that the result already exists in the system. This causes unnecessary system load, which can be alleviated by using contexts.
You define contexts in the Context Builder, which is part of the ABAP Workbench. They consist of key input fields, the relationships between the fields, and the other fields and values that you can derive from them. Contexts can link these derived fields by foreign key relationships between tables, by function modules, or by other contexts.
In application programs, you work with instances of a context. You can use more than one instance of the same context. The application program supplies input values for the key fields in the context using the SUPPLY statement, and can query the derived fields from the instance using the DEMAND statement.
Each context has a cross-transaction buffer on the application server. When you query an instance for values, the context program searches first of all for a data record containing the corresponding key fields in the appropriate buffer. If one exists, the data is copied to the instance. If one does not exist, the context program derives the data from the key field values supplied and writes the resulting data record to the buffer.
Memory Structures of an ABAP Program
In the Overview of the R/3 Basis System you have seen that each user can open up to six R/3 windows in a single SAPgui session. Each of these windows corresponds to a session on the application server with its own area of shared memory.
The first application program that you start in a session opens an internal session within the main session. The internal session has a memory area that contains the ABAP program and its associated data. When the program calls external routines (methods, subroutines or function modules) their main program and working data are also loaded into the memory area of the internal session.
Only one internal session is ever active. If the active application program calls a further application program, the system opens another internal session. Here, there are two possible cases: If the second program does not return control to the calling program when it has finished running, the called program replaces the calling program in the internal session. The contents of the memory of the calling program are deleted. If the second program does return control to the calling program when it has finished running, the session of the called program is not deleted. Instead, it becomes inactive, and its memory contents are placed on a stack.
The memory area of each session contains an area called ABAP memory. ABAP memory is available to all internal sessions. ABAP programs can use the EXPORT and IMPORT statements to access it. Data within this area remains intact during a whole sequence of program calls. To pass data to a program which you are calling, the data needs to be placed in ABAP memory before the call is made. The internal session of the called program then replaces that of the calling program. The program called can then read from the ABAP memory. If control is then returned to the program which made the initial call, the same process operates in reverse.
All ABAP programs can also access the SAP memory. This is a memory area to which all sessions within a SAPgui have access. You can use SAP memory either to pass data from one program to another within a session, or to pass data from one session to another. Application programs that use SAP memory must do so using SPA/GPA parameters (also known as SET/GET parameters). These parameters are often used to preassign values to input fields. You can set them individually for users, or globally according to the flow of an application program. SAP memory is the only connection between the different sessions within a SAPgui.
The following diagram shows how an application program accesses the different areas within shared memory:
In the diagram, an ABAP program is active in the second internal session of the first main session. It can access the memory of its own internal session, ABAP memory and SAP memory. The program in the first internal session has called the program which is currently active, and its own data is currently inactive on the stack. If the program currently active calls another program but will itself carry on once that program has finished running, the new program will be activated in a third internal session.
Subscribe to:
Comments (Atom)