IBM i5/iSeries Primer(c) Concepts and Techniques for Programmers, Administrators, and Sys[... ]ators
Printer files are not as complicated as display files. For one thing, printed material can go on for hundreds of lines, even if you disregard the perforation between pages or the physical end of one sheet in laser printers.
Displayed information, on the other hand, has to be designed so that it fits the limitations of the display device. This limitation means the programmer needs to be concerned with Roll keys or use subfiles or other techniques to overcome these difficulties.
Much of the difficulty of display files is due to their ability to accept user input. Printer files, on the other hand, are strictly for output, which simplifies their design and coding enormously.
| Tip | RLU, a tool equivalent to SDA, can be used to design printer fileson the screen. The problem with RLU is its interface. While SDA provides a WYSIWYG (what you see is what you get) approach, RLU does not. RLU's display helps, but what you see on the screen is not what you will get. Using RLU is not as easy and intuitive as SDA. |
RLU can be too cumbersome to be of value, but there are alternatives. At least one other company offers a report design tool that works similarly to SDA. IBM's CODE Designer provides a GUI tool for developing printer and display files. Some developers prefer to enter printer file DDS through SEU. You should investigate these methods and decide for yourself which method works best for you.
General Overview
To design printed output, you must concern yourself with different record formats. Imagine a typical file listing report, such as one that lists all vendors in a master file. The report must have a title line that usually contains the title of the report ("Vendor Master Listing") and other information such as date run, page number, and some identification code. Then, you need another record that contains the column headings, so that each column of data is identified. Finally, you need another record that contains the information for each vendor in the file.
When do you need to write each record? The title record and the column heading record are required only once per page when the page begins. The data record, however, has to be printed many times on each page, line after line until you reach the end of the page.
Because this simple report does not need to differentiate between the title record and the column heading record (both contain constants only, and both are printed at the same time), you could simplify coding by combining the two into a single record.
Sample Report
The physical file, VNDMST, was defined earlier in this chapter. It contains basic information about vendors. Let's use that example again to design a sample report that lists all records in VNDMST. Figure 22.18 displays the DDS of VNDMST.
Figure 22.19 shows what the DDS for the printer file (let's call it VNDLST) might look like.
Only two records have been defined: HEADER (with the report title and column headings) and DETAIL (with the data from each vendor). First, notice the REF keyword at the file level that references file VNDMST. Note also that all fields in record DETAIL are defined by reference, without the REFFLD keyword. Because REFFLD is missing, the data fields in the printer file will have the same names as the fields in the physical file.
Next, several spacing keywords are used. The HEADER record has SKIPB(3) at the record level. This skips three lines before writing the record (i.e., the heading will begin on line 4). Then there are SPACEA(3) and SPACEA(2), also in the HEADER record, which provide space after (three lines or two lines). This makes the printer leave blank lines. For example, SPACEA(2) advances two lines after printing, which leaves one blank line.
The DETAIL record prints the vendor number, the name, city, state, zip code, and amount due, then advances one line. On the next line, it prints the first line of the address immediately below the name (previous line), then advances to the next line and prints the second line of the address. After that, the detail record advances two lines. The next DETAIL record you write will be separated from the previous one by a blank line.
Finally, note the presence of a DATE keyword in the HEADER record, which is immediately followed by EDTCDE(Y). This retrieves the current job date (not the system date), and edits it with a Y edit code. It is equivalent to the UDATE field in RPG. A TIME keyword also exists, but it is not include in this report. On the other hand, a PAGNBR keyword, followed by EDTCDE(3), has been included. This retrieves the current page number and edits it by removing leading zeros. Again, it is equivalent to the PAGE field in RPG.
| Tip | When you use the TIME keyword, remember that it doesn'tneed editing the way DATE and PAGNBR do. You will have to get used to this irregularity. |
Using the Printer File
Figure 22.20 is how you could code RPG IV to print a list of vendors, using the previous example.
Both files are described externally to the program. The K in the VNDMST File Specification indicates that the file is to be read sequentially by key. The 99 in the OFLIND keyword on the printer file's File Specification is the overflow indicator. All externally described indicators must use numeric (01–99) indicators.
Before the program does anything else, it runs the *INZSR subroutine that writes the HEADER record and prints the report title and column headings for the first page of the report. Because all indicators are at the beginning of the program, Indicator 99 (*IN99) is off at this time.
Each cycle checks *IN99. If it is on, overflow has occurred. In this case, the WRITE operation outputs the HEADER record again, which starts a new page. Then, *IN99 is turned off manually (the RPG cycle doesn't do it for you). Following suit, once per cycle, you write the DETAIL record, which outputs the vendor data to the printer file. You don't have to move data between the physical file and the printer file because the data fields are identically named; RPG also takes care of that.