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 node and made it available to the program in the work area declared using the statement NODES node.
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 node [FIELDS f1 f2...].
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 are superior to node 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 NODESstatement.
At the end of a hierarchy level of the logical database, all of the fields in the work area node are set to the value Hexadecimal null. 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 node 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 NODESstatement, 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 f1 f2... and the key fields from the node 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.
All fields of the node node 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 node are set to hexadecimal null. This means that they are also set to hex zero during the GET events of the nodes below node in the hierarchy. You should therefore not use these fields in your program or call subroutines that work with them. If an extract dataset is filled in the GET event block, remember that extracts have a special sort rule for fields with the contents hexadecimal null.
The following executable program is connected to the logical database F1S.
NODES: spfli, sflight, sbook.
WRITE 'Test Program for GET'.
WRITE: / 'From:', spfli-cityfrom,
'TO :', spfli-cityto.
WRITE: / 'Carrid:', sflight-carrid,
WRITE: / 'Fldate:', sflight-fldate,
'Luggweight', sbook-luggweight UNIT 'kg'.
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:
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:
· MANDT, CARRID, CONNID, FLDATE, and PLANETYPE from SFLIGHT
· MANDT, CARRID, CONNID, FLDATE, and BOOKID from SBOOK
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.