Lesson 9 Dialogs and Screens

 Screens are made up of more than just a monitor display with input and output fields.

Screens' integration with the ABAP-Dictionary allows the system to perform consistency checks for their input fields automatically. These checks include required input check, type checks, foreign key checks, and fixed value checks. All of these checks rely upon ABAP Dictionary information.

Checks like the ones above can be complemented by other program specific checks. There are techniques available for screens that allow you to control in what order checks are then performed.

When an error is detected, the corresponding field is called and displayed ready for input. Screen layout is also very flexible. Input fie lds, output fields, radio buttons, check boxes, and even pushbuttons can be placed on screens. They allow users to determine in which direction the program will proceed.

On the whole, such user influence on program progression allows for more program flexibility in those programs that do contain screens.

You can call screens from any ABAP processing block that you want.

You can link several screens to one another and then call them from within a program by simply calling the first screen.

Some ABAP programs are made up exclusively of screens and their correponding ABAP

processing blocks. In this case the first screen is called directly using a transaction code.

Double-click on an entry in the basic list 'timetable' to reach a screen. This screen displays data

The major steps in creating a screen:

specifying its properties (Screen Attributes)

specifying its layout (in Fullscreen Editor)

defining attributes for the elements on the screen (Field List)

programming its flow logic

You should be able to call your screen by double -clicking a line within the basic list and you should be able to return to the basic list by choosing the appropriate function key on the screen.

There are several ways to create screens:

Forward Navigation: You can create screens from within the ABAP Editor by double –clicking on the screen number. This transfers you into Screen Painter automatically

Object Navigator: You can also create a screen from the object list in the Object Navigator

When creating a screen for the first time the system will ask you to enter screen attributes. Enter a short description of the screen, select screen type Normal and enter the number of the subsequent screen in the Next Screen input field.

If you enter 0 or leave the Next Screen field blank, the system first processes your screen completely and then returns to processing the program at the point immediately following the screen call. Be aware that in the Next screen input field, the 0 is suppressed, since it is the same as the initial value of the field.

There are two ways of assigning field attributes to screen fields:

Adopt them from the Dictionary: You can adopt types and field attributes from existing

ABAP Dictionary structures. This makes all information about the object available to you,

including semantic information about its data elements and foreign key dependencies. The name of the Dictionary field is automatically adopted as a field name.

Adopt them from a program: You can adopt field attributes from data objects already defined within a program. In order to do this, however, an activated copy of the program must already exist. The name of the data object is automatically adopted as a field name.

The Graphical Screen Painter's interface allows you to define screen elements (for example, input and output fields, keyword texts, borders, and so on) with relative ease. Choose the desired screen element from the column on the left and then place it on the screen using your mouse.

You can delete screen elements simply by selecting them with your mouse and then choosing delete.

You can move screen elements by holding down your left mouse button and dragging them to a new position.

You can maintain screen field attributes by selecting a field and choosing Attributes.

You can classify certain fields as 'mandatory'.(. "Required field"). A question mark is displayed at runtime if the field is initial.

If not all required fields have been filled at runtime and a user action is performed, an error dialog is triggered and all input fields are once again displayed ready for input.

You can also edit screen field attributes by choosing Field list.

The field list is then displayed as a tab.

This same function can also be accessed in a different format from within the Graphical Screen Painter.

The statement TABLES declares an internal data object that serves as an interface for the screen.

TABLES always refers to a structure that is defined in the ABAP Dictionary.

If a TABLES statement and a screen field both refer to the same Dictionary structure, this data object's data is transported to the screen fields every time the screen is called. Any new entries or changes that the user makes on the screen are then transferred back into this data object.

Data transport takes place automatically between screens and program data objects of the same name:

Immediately before a screen is sent to the presentation server (after all PBO event modules have been processed) the system copies field contents out of the ABAP work area into their corresponding fields in the screen work area.

ABAP statements facilitate data transport between program data objects and the work area designated as the screen interface.

Data transport takes place automatically between screens and program data objects of the same name:

Immediately after a user action (before the first PAI module has been processed) the system copies field contents out of the screen work area and into their corresponding fields in the ABAP work area.

ABAP statements facilitate data transport between the work area designated as the screen interface and program data objects.

In order to ensure that the database data that is displayed on the screen is up-to-date, the record is read again from the database at the beginning of AT LINE-SELECTION.

Advantages of this method:

For the basic list, only those columns of the database table that are displayed on the list need to be read. This can improve performance with large lists.

The data that is displayed on the screen is always up-to-date, even if the data record selected has only just been changed using this program. This would not happen if all screen data was placed in the HIDE area when the basic list is created.

Changes made to the database using the screen do not lead to incorrect values in the basic list, as the modifiable fields are not contained in the list.

Looking ahead to the lock concept: The lock times can be shortened. You find more detailed information on this topic in the Database Dialogs II unit.

The program can be extended: Additional information from the data record can be displayed on the screen without having to make many changes.

To display data on the screen, the TABLES structure must be filled with current data before the screen is sent to the presentation server. The example above shows one way of doing this.

The data record is read from the database using SELECT SINGLE. This ensures that the structure contains current data, even if the user has just changed the data. The structure is assigned the same type as the database table line type, so that suitable fields are available for all data in the data record.

The system transports the structure data to the screen fields automatically.

Each screen has two corresponding event blocks:

PROCESS BEFORE OUTPUT (PBO) is processed immediately before a screen is displayed. At this time modules are called that take care of tasks such as inserting recommended values into input fields.

PROCESS AFTER INPUT (PAI) is processed immediately after a user action. All program logic that is influenced by user action must be processed at PAI. You will learn more about this in step three.

Note: The code for the events PBO and PAI is written using the Screen Painter and not the ABAP Editor. These two event blocks make up a screen's flow logic.

When programming flow logic, use the set of commands called Screen ABAP. MODULE is the most important Screen ABAP command. It calls a special ABAP processing block called a module.

Modules are ABAP processing blocks with no interface that can only be called from within a program's flow logic. Modules begin with the ABAP statement MODULE and end at ENDMODULE.

Program logic that logically belongs to a specific screen should normally be processed at the screen's PBO and PAI events.

If you enter 0 or leave the Next Screen field blank, the system first processes your screen completely and then carries on processing the program from where the screen was called.

If you set the Next screen of screen 100 to 100, the system processes the screen again, after it has finished processing the PAI module.

You can use the ABAP statement SET SCREEN within a PAI module to override dynamically the value set in the Next screen attribute.

Often the same screen number is entered in both the Screen number and Next screen fields. In this case, when you choose Enter, a field check is performed and the system returns you to the same screen. In order to leave the screen, an appropriate pushbutton must be defined that then triggers a Next screen change within the PAI module.

With the help of the OK_CODE field, different program logic can now be processed by the PAI modules depending on what the user inputs.

If an OK_CODE field is not initialized, errors can occur since not every pushbutton is required to have a function code. There are two ways of doing this:

Initialize the OK_CODE field in a PBO module. Then it is set to the initial value at PAI, unless the user has carried out a user action to which a function code is assigned. In this case, the OK_CODE field contains the function code.

Use an auxiliary field and copy the contents of the OK_CODE field to the auxiliary field in a PAI module, and then initialize the OK_CODE field. In this case, the auxiliary field must be queried in the PAI module for the function code evaluation.

You can implement calls such as MODULE within a screen's flow controls (PBO and PAI events).

The modules themselves are, however, created using ABAP.

There are two ways to create a module:

using forward navigation: Double-click on the module name from within the Screen Painter Editor to create the module.

Using the Object Navigator: If you want to create a module using the object list in the Object Navigator, first display your program, then choose 'PBO module' or 'PAI module' in the ProgramObjects display and create a new development object by selecting the create icon.

A module can be called from more than one screen. (Reusability)

Be aware that modules called at PBO events must be defined using the statement MODULE ... OUTPUT, whereas modules defined with MODULE ... INPUT, can only be called at PAI events.

LESSON 8 USER DIALOGS AND SELECTION SCREEN

Selection screens allow users to enter selection criteria required by the program.

For example, if you create a list containing data from a very large database table, you can use a selection screen to restrict the amount of data that is selected. At runtime, the user can enter intervals for one of the key fields, and only data in this interval is read from the database and displayed in the list. This considerably reduces the load on the network.

Selection screens are designed to present users with an input template allowing them to enter selections, which reduce the amount of data that has to be read from the database. The following possibilities are available to the user:

Entries to single fields

Complex entries: Intervals, operations, patterns

Saving selections fields filled with values as variants

Input help and search helps are available by choosing the F4 function key or the possible entries pushbutton

You can translate selection texts into other languages so that they are then displayed in the language in which the user is logged on.

The system checks types automatically. If you enter a value with an incorrect type, the system displays an error message and makes the field ready to accept your corrected entry.

Selection screens allow you to enter complex selections as well as single -value selections. Functions of selection options programming include:

Setting selection options

Entering multiple values or intervals

Defining a set of exclusionary criteria for data selection

Every selection screen contains an information icon. Choose this icon to display additional. information.

If you refer an input field to an ABAP Dictionary object to which a search help is assigned, the system automatically provides the corresponding possible values help.

You can adapt the possible values help to meet your own requirements by defining a search help in the ABAP Dictionary.

On the selection screen, the names of the variables appear next to the input fields. However, you can replace these with selection texts, which you can then translate into any further languages you require. Selection texts are displayed in the user's logon language.

You can define and store variants for any selection screen. You do this by starting the program and choosing Variants -> Save as variant.

Variants allow you to make selection screens easier to use by end users by:

Pre-assigning values to input fields

Hiding input fields

Saving these settings for reuse

A single variant can refer to more than one selection screen.

Variants are client specific.

If you choose the information icon (on any selection screen), the system will display more

information about variants. You can also find out more in course BC405 Techniques of List

Processing.

In an executable program, a single PARAMETERS statement is sufficient to generate a standard selection screen.

The PARAMETERS TYPE statement and the PARAMETERS LIKE statement both generate a simple input field on the selection screen, and a data object with the type you have specified.

If the user enters a value and chooses 'Execute', that value is placed in the internal data object in the program. The system will only permit entries with the appropriate type.

Once the INITIALIZATION event block has been processed, the selection screen is sent to the presentation server. The runtime system transports the data object values that are defined using PARAMETERS to the selection screen input fields of the same name.

The user can then change the values in the input fields. If the user then clicks on the 'Execute' function, the input field values are transported to the program data objects with the same name and can be evaluated in the ABAP processing blocks.

If you have used the PARAMETERS statement to program an input field as a key field for a database table, you can use a WHERE clause at the SELECT statement to limit data selection to this value.

The statement SELECT-OPTIONS FOR defines a selection option:

This places two input fields on the selection screen, with the same type that you have defined in the reference. This enables users to enter a value range or complex selections. The statement also declares an internal table within the program, with the following four columns:

sign: This field designates whether the value or interval should be included in or excluded from the selection.

option: This contains the operator: For a list of possible operators, see the keyword

documentation for the SELECT-OPTIONS statement.

low: This field contains the lower limit of a range, or a single value.

high: This field contains the upper limit of a range.

Selection table always refers to a data object that has already been declared. This data object serves as a target field during database selection, the selection table as a pool of possible values. A special version of the WHERE clause exists for database selection. It determines whether or not the database contains the corresponding field within its pool of possible values.

If the user enters several values or intervals for a selection option and chooses 'Execute', the system places them in the internal table.

Conditions in an internal table declared using SELECT-OPTIONS are interpreted as follows:

If the internal table is empty, the condition IN is always true.

If the internal table only contains simple inclusive conditions i1, ..., in, the result is the composite condition ( i1 OR ... OR in ).

If the internal table only contains simple exclusive conditions e1, ..., em, the result is the

composite condition ( NOT e1 ) AND ... AND ( NOT em ).

If the internal table contains both the simple inclusive conditions i1, ..., in and the simple exclusive conditions e1, ..., em, the result is the composite condition ( i1 OR ... OR in ) AND ( NOT e1 ) AND ... AND ( NOT em ).

In an executable program, the ABAP runtime system generates a standard selection screen as long as you have written at least one PARAMETERS or SELECT-OPTIONS statement. The selection screen belongs to the event block AT SELECTION-SCREEN.

The selection screen is displayed after the event block INITIALIZATION.

Each time the user presses Enter, a pushbutton, a function key, or chooses a menu function, the system carries out a type check. If the entries do not have the correct type, the system displays an error message, and makes the fields ready for input again. When the data types have been corrected, the system triggers the AT SELECTION-SCREEN event.

Subsequent program flow depends on the user action:

If the user chose F8 or 'Execute', the next event block is called: In this case, START-OFSELECTION.

If the user chose any other function, the selection screen is redisplayed.

Use the event block AT SELECTION-SCREEN whenever you want to program additional input checks for a standard selection screen.

The event block AT SELECTION-SCREEN is triggered by each user action. If an error dialog is triggered, the system jumps back to the selection screen and automatically resets all input fields to ready for input and displays a message in the status line.

For more detailed information on the MESSAGE statement, refer to the keyword documentation as well.

Additional information can be found in the keyword documentation for AT SELECTION-SCREEN.

 

LESSON 7 USER DIALOGS-LISTS

The main purpose of a list is to output data in a manner that can be easily understood by the user; this output often takes on the form of a table. Lists in R/3 take into account special business data requirements:

They are language-independent. Texts and headers appear in the logon language whenever the appropriate translation is available.

They can output monetary values in numerous currencies.

You can output list data in the following ways:

to the screen; here you can add colors and icons

to the printer

to the Internet/intranet: Automatic conversion to HTML

you can also save lists in the R/3 System or output them for processing by external commercial software applications like spreadsheet programs

The standard list interface offers the user several navigation features:

Back

Exit

Cancel

Print

Find (in List)

Save: saves the list either as a file on the desktop, in a report tree, or to the Office

Send: sends the list in e-mail form

For further information on how you can adjust the standard list interface to fit your individual needs see Dialogs: Interfaces.

Each list can have a list header and up to four lines of column headers . There are two different ways to go about using these tools:

from within the Editor using the text element maintenance functions

from within the list itself. If you save your program, activate it and then run it to create the list, you can enter both list and column headers by choosing the menu path System -> List -> List headers.

The main advantage of using this method is that the list is still displayed on the screen. This makes it easier to position column headers.

The next time you start the program, the new headers will appear in the list automatically.

When no header text is entered, the program title is inserted in the header.

Titles and headers are part of a program's text elements. You can translate all text elements into other languages. The logon language setting on the logon screen detemines in which language text elements will be displayed.

Text symbols are another kind of text element. These are special text literal data objects. Compared to normal text literals, text symbols have the advantage that they can be translated into different languages without having to change a program's source code. Text symbols allow you to create lists independent of language.

You can write text symbols into your program in either of the following ways:

TEXT- (where xxx is a character string three characters long)

''() (where xxx is a character string three characters long)

In executable programs (type 1), lists are automatically displayed after their corresponding event blocks have been processed. These processing blocks must, however, contain a list creation statement. These are WRITE, SKIP, and ULINE.

Event blocks are called in a sequence designed for list processing:

Prior to sending the selection screen: INITIALIZATION

After leaving the selection screen: START-OF-SELECTION

All output from START-OF-SELECTION event blocks, subroutines, and function modules that is processed before a list is displayed is temporarily stored in the list buffer.

Once all list creation processing blocks (for example START-OF-SELECTION) have been processed, all data from the list buffer is output in the form of a list.

In executable programs, you can use the event block AT LINE-SELECTION to create detail lists.

The ABAP runtime system:

Displays the basic list after the appropriate event blocks have been processed (for example, after START-OF-SELECTION). In this case, system field sy-lsind contains the value 0.

Processes the event block AT LINE-SELECTION each time you double -click on an entry. If you are using a standard status, this happens automatically every time you choose the Choose icon, the Choose menu item in the Edit menu, or the function key F2.

Displays detail lists after the AT LINE-SELECTION event block has been processed and increases the value contained in sy-lsind by one.

Displays the detail list from the previous level in the list hierarchy (n-1) every time you choose the green arrow icon from the current detail list (n).

The lists in the example program should function as follows:

The basic list should display the text 'Basic List' and system field sy-lsind.

The user should be able to call the initial detail list using a double -click or by choosing its

corresponding icon from the application toolbar or its menu entry or by using the function key F2. Then the 'Detail list' appears and the system field sy-lsind has the value 1.

Repeating this action should call the second detail list, where system field sy-lsind contains the value 2 (representing the current detail list level).

Repeating this action increases the sy-lsind value by one every time up to a value of twenty (the total number of detail lists supported).

Choosing the green arrow takes the user back a single detail list level at a time until the basic

list is reached.

A detail list can be programmed as follows:

You create a basic list by filling the basic list buffer at an appropriate event block (here

START-OF-SELECTION) using either WRITE, SKIP, or ULINE.

Use the event block AT LINE-SELECTION when programming detail lists. Whenever you use WRITE, SKIP, or ULINE with this event block, you fill the detail list buffer for the next level (the detail list buffer with a level value one greater than the level on which the user

performed his or her action).

You can pre-determine navigation between detail lists by querying system field sy-lsind at the event block AT LINE-SELECTION.

We will now write a program using both basic lists and detail lists:

When the event AT LINE-SELECTION is processed, a program's data objects contain the same values as they did before the basic list display. A detail list, however, often needs data selected within the basic list itself. You can use the HIDE area to store certain data from the line that you have selected and then automatically insert where you need it in the corresponding data object for a detail list. You can predetermine which information should be classified by its line position when you are creating a basic list.

To do this, you use the ABAP keyword HIDE followed by a list of the data objects that you need. The runtime system automatically records the name and contents of the data object in relation to its line position in the list currently being created.

As soon as the interactive event (AT LINE-SELECTION in this example) is called by placing the cursor on a specific line and then either double -clicking or choosing the Choose icon, the values for this line stored in the HIDE area are inserted into their corresponding data objects.

You create a detail list by filling the detail list buffer at the AT LINE-SELECTION event block using either WRITE, SKIP, or ULINE. In this sample program, the key fields for the airline are displayed and the flights available for this airline in the database table SFLIGHT are read using a SELECT loop. Note that the line-specific information on the airline is only available by double - clicking in the data objects if the relevant data objects have been placed in the HIDE area when the basic list was created.

 

LESSON 6 INTERNAL PROGRAM MODULARIZATION

INTERNAL PROGRAM MODULARIZATION:

An ABAP program is a collection of processing blocks. A processing block is a passive section of program code that is processed sequentially when called.Processing blocks are the smallest units in ABAP. They cannot be split, which also means that they cannot be nested.

There are various kinds of ABAP processing blocks:

Event blocks are ABAP processing blocks that are called by the runtime system. Event blocks can logically belong to the executable program, to the selection screen, to the list or to the screen. This unit deals with event blocks that belong to the executable program. You can find information on event blocks that belong to the selection screen, the list or the screen in the units on user dialogs.

Subroutine processing is triggered by an ABAP statement. Parameters can be passed to

subroutines using an interface and subroutines can contain local variables.

Modules are special ABAP processing blocks for processing screens. Therefore modules are dealt with in the User Dialogs: Screens unit.

Memory areas are made available for all a program's global data objects when that program is started. Declarative ABAP statements are therefore not components of ABAP processing blocks but are collected from the overall source code using a search when the program is generated. The exceptions to this are local data objects in subroutines.

In all of the programs that we have seen so far in this course, there has only been one processing block in addition to the data declaration. In this case, there is no need to declare the processing block explicitly. However, in more complex programs, we will require several different processing blocks and will need to specify the type and name.

The program shown above is an example of event blocks. It contains an input value for a date on a selection screen. The default value is the date from the week before. This cannot be realized by a default value from the PARAMETERS statement, since a calculation is required. The DEFAULT addition to the PARAMETERS statement ensures that the data object is filled with the default value at the start of the program.

Default values can be literals or fields from the sy structure. The runtime system fills the sy-datum field with the current date at the start of the program. You can use the INITIALIZATION event block to change variables at runtime but before the standard selection screen is sent. START-OF-SELECTION is an event block for creating lists.

All global declarations are recognized as such by the system by the declarative ABAP key words that they use, and these form a logical processing block (regardless of where they are placed in the program code). When you generate the program, the system searches the entire program code for declarative statements. However, for the sake of clarity, you should place all declarative statements together at the beginning of your programs. The PARAMETERS statement is one of the declarative language elements. When the program is generated, a selection screen is also generate d along with the information on the elementary data object of the type specified.

The easiest events to understand are those for an executable program (type 1).

The ABAP runtime system calls event blocks in a sequence designed for generating and processing lists:

First, the INITIALIZATION event block is called

Then a selection screen is sent to the presentation server

After the user leaves the selection screen, START-OF-SELECTION is called

If the START-OF-SELECTION event block contains the ABAP statements WRITE, SKIP or ULINE, a list buffer is filled.

The list buffer is subsequently sent to the presentation server as a list.

Event blocks are processing blocks that are called by the ABAP runtime system. The sequence in which they are processed is determined by the runtime system.

In executable programs, there are different event blocks for the various tasks involved in creating lists.

In an ABAP program, an event block is introduced with an event key word. It ends when the next processing block starts. There is no ABAP statement that explicitly concludes an event block.

Event blocks are called by the ABAP runtime system. The order in which you arrange the event blocks in your program is irrelevant - the system always calls them in a particular order.

START-OF-SELECTION is the first event for generating a list. It is called by the ABAP runtime system as soon as you have pressed the execute button.

INITIALIZATION is an event that you can use if you need to set a large number of default values.

This event block allows you to set default values that can only be determined at runtime. In the above example, the date 'A week ago' is calculated and placed in data object pa_date. The ABAP runtime system then sends a selection screen to the presentation server containing the calculated value as a default. The value can, of course, still be changed by the user.

Subroutines are processing blocks with a defined interface that can be called from any processing block using the ABAP statement. Subroutines provide internal program encapsulation.

You can navigate from the program object list to the subroutines.

The where-used list for a subroutine displays all the program lines that call the subroutine.

Ideally, all you need to do to determine the functional scope of the subroutine is to examine the subroutine name, the interface and the comments. If the subroutine contains the functionality you require, then you need the following information to be able to call the subroutine:

Subroutine name

Interface parameters it accesses (read-only): the parameters are listed after the USING addition.

The type and sequence of the interface parameters is important.

Interface parameters it changes: the parameters are listed after the CHANGING addition. The type and sequence of the interface parameters is important.

When a subroutine is called, all the interface parameters have to be filled with values. A distinction is made between the following parameters:

After USING, the parameters that the subroutine only needs to read are listed.

After CHANGING, the parameters that are changed in the subroutine are listed.

If the subroutine is called from the ABAP processing block by a PERFORM statement, the system interrupts the processing block to process the subroutine sequentially. When the last line of the subroutine (ENDFORM.) is reached, the system carries processing after the PERFORM statement.

You can track runtime behavior in the debugging mode. This gives you various options:

You can go through the entire program, including the subroutine, line by line, using Single Step

You can go through a processing block line by line using Execute. Subroutines are then executed as a whole

You can leave single -step processing of a subroutine and return to the calling program using Return

The method used for calling the interface parameters is set in the subroutine interface. The

parameters can be called either by reference or by value.

Calling by reference: The address of the actual parameter is called. Within the subroutine, the variable is addressed using the formal parameter name. Changes have an immediate effect on the global variable. If only the formal parameter name is specified in the subroutine interface, then the parameter is called by reference.

Calling by value: When the subroutine is called, a local variant is created with the formal parameter name and the actual parameter value is copied to the formal parameter. There are two types of call by value:

Calling by value: the formal parameter is listed in the interface after the USING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter only affect the local copy, not the actual parameter.

Calling by value and result: the formal parameter is listed in the interface after the CHANGING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter initially only affect the local copy. When the ENDFORM statement is reached, the formal parameter value is copied back to the actual parameter.

The parameters in the interface are called formal parameters , and the parameters that you pass to the subroutine are called actual parameters .

You must have the same number of actual parameters as formal parameters. You cannot have optional parameters. Parameters are assigned in the sequence in which they are listed.

When you call a subroutine using PERFORM, the system checks whether the types of the actual parameters in the PERFORM statement are compatible with the formal parameters. Different kinds of checks are performed for different types:

Complete type checks:

TYPE D, F, I, T or . These types are fully specified. The system checks to see if the data type of the actual parameter is identical to the type of the formal parameter in its entirety.

Partial type checks of generic types

TYPE C, N, P or X. The system checks whether the actual parameter has the type C, N, P or X. The length of the parameter and the number of decimal places in the DECIMALS addition (type P) are passed from the actual parameter to the formal parameter.

TYPE all unspecified information from generic

Dictionary types is inherited by the formal parameter from an actual parameter.

The interface is defined in the FORM routine. USING and CHANGING in the PERFORM statement are purely documentary.