Similar to a copy view, our extract only view will not require the Reference and Format phases. But now, instead of copying the input records to the output files, we will only select those fields we wish to use and write those to the output file. In this example, we’ll also still execute the copy view at the same time, demonstrating how the single pass architecture works.
The only change we have to make to the select phase is to ask it to execute two views, so the input parameter to the VDP Builder now includes both 3261 and 3262.
****** ************** Top of Data ***************
000001 3261
000002 3262
****** ************** Bottom of Data ************
The VDP that is created after running the VDP Builder contains two views, plus all the metadata needed for both.
Logic Table
The following is the logic table created from the VDP which contains both these views.
The HD Header, RENX Read Next, ES End of String and EN End of Logic Table functions are all pretty much the same. The rows for view 3261, logic table rows 3, 4 and 5 area also unchanged.
The Extract Only view, 3262, also is reading file 1284, and so it is placed immediately after view 3261. So when a record is read from that file, it will be passed first to view 3261 and then to 3262. This view is more complex. The Logic Table functions it performs are as follows:
The following table shows how the different areas in memory in GVBMR95 are used by the different function codes.
Extract Process
The trace from running the same event used in the last chapter is as follows:
Extract Program Control Report
A key control report in the process is the Extract Engine report, shown below:
- Because we only read one event file, only one thread was executed1.
- There were two views reading this file. If one of these views had been reading another event file as well, the count by “views per file processed” would have been 3, even though there were only two outputs.
- The “logic table rows” is equal to the row number on the EN row, i.e., the total number of rows in the logic table.
- The machine code generated from those logic table rows is 424 bytes. In other words, in the prior chapter we noted the CFEC created a CLC and BC assembler instructions, which required 20 bytes of the 424 generated.
- The record count of the records read from the Event file (with a DD Name of Event) is 3. Because we only read one event file, the total event records read is the same on the next line. Our process used no “pipes” which are virtual event files.
- The next section shows the results of each view against each event file.
- View 3261 extracted two records, and wrote them to DD Name F0003261.
- View 3262 extracted three records, and wrote them to DD Name F0003262.
- The zeros next to “F” and “NF” are for lookups “Found” and “Not Found”, because these views require no joins.
- Multiple views can write to an extract file. Thus the next set of rows show the total of record written to each extract file, and the total to all extract files, and to all Pipes.
- The Elapsed time is the total wall-clock time for the extract process.
If the outputs are not what was expected, this is perhaps the first places to look.
Analysis
The Extract Engine in this process has significantly increased efficiency over alternative methods of producing these two outputs, because in a single pass of the file, one IO to get the event file into memory for processing has allowed both outputs to be done. Certainly programs can be written to do this same thing, but it demands a programmer writing the program to design it that way. Here, two people independently can create views, and the tool will resolve them efficiently.
Remember, though, that this process does not include any parallelism. View number 2 is executed after view number 1 has seen the event record.
The next step in growing our understanding is to understand how to do lookups.
Parent Topic: Part 5. The Programmer