GET
This is the most important event for executable programs that use a logical database. It occurs when the logical database has read a line from the node <table> and made it available to the program in the work area declared using the statement NODES <table>.
When you define the corresponding event block in the program, you can specify a field list if the logical database supports field selection for this node:
GET <table> [FIELDS <f1> <f 2>...].
You can process the data in the work area in this event block. For example, you can write it directly to a list, or store it in a sequential dataset (internal table or extract) so that you can process it later.
The logical database reads all columns from all nodes that are not designated for field selection in the logical database and which are superior to <table> on the access path of the logical database. This works independently of whether you have defined GET event blocks for these nodes or not. However, you can only access the data of the nodes for which you have declared a work area in the NODES statement.
At the end of a hierarchy level of the logical database, all of the fields in the work area <table> are set to the value Hexadecimal 00. If you are using extracts, there is a special sort rule for fields with the content hexadecimal 00. For further information, refer to
Sorting Extract Datasets.Performance can be much better for tables that are designated for field selection in the logical database. If there are nodes of this type above <table> in the hierarchy of the logical database for which there are no GET event blocks, the data for all columns is only read for the nodes for which there is a NODES statement in the program. For nodes without a NODES statement, only the key fields are read. The logical database needs the key fields to construct an access path.
You can use the FIELDS option to specify explicitly the columns of a node that the logical database should read. With the FIELDS option, the logical database program reads only the fields <f
1 > <f 2 > ... and the key fields from the database table <table>. However, the node <table> must have been designated for field selection in the logical database.Using FIELDS can result in much better response times than when the logical database has to read all of the columns of the node.
All fields of the node <table> that are not key fields and are not listed after FIELDS, are not read by the logical database. The contents of the corresponding components of the table work area <table> are set to hexadecimal 00. This means that they are also set to hex 00 during the GET events of the nodes below <table> in the hierarchy. You should therefore not use these fields in your program or call subroutines that work with them. If you use the GET event block to fill an extract dataset, remember that they have a special sort rule for fields with the contents hexadecimal 00.
The following program is connected to the logical database F1S.
REPORT EVENT_DEMO.
NODES: SPFLI, SFLIGHT, SBOOK.
START-OF-SELECTION.
WRITE 'Test Program for GET'.
GET SPFLI.
SKIP.
WRITE: / 'From:', SPFLI-CITYFROM,
'TO :', SPFLI-CITYTO.
GET SFLIGHT.
SKIP.
WRITE: / 'Carrid:', SFLIGHT-CARRID,
'Connid:', SFLIGHT-CONNID.
ULINE.
GET SBOOK.
WRITE: / 'Fldate:', SFLIGHT-FLDATE,
'Bookid:', SBOOK-BOOKID,
'Luggweight', SBOOK-LUGGWEIGHT.
ULINE.
The table work area SFLIGHT is also used in the event block for GET SBOOK. Depending on what you enter on the selection screen, the beginning of the list display might look like this:
In the logical database F1S, the nodes SFLIGHT and SBOOK are designated for field selection. This means that you can specify a field list in their GET event blocks:
REPORT EVENT_DEMO.
NODES: SFLIGHT, SBOOK.
GET SFLIGHT
FIELDS CARRID CONNID....
GET SBOOK
FIELDS BOOKID....
GET SFLIGHT LATE
FIELDS PLANETYPE....
In this case, the logical database reads the following fields:
The system reads the fields MANDT and FLDATE from SFLIGHT, even though they are not specified in the field list, since they belong to the table key.
Only the key fields of SBOOK are read.
