IBM i5/iSeries Primer(c) Concepts and Techniques for Programmers, Administrators, and Sys[... ]ators

Display and printer files are two types of device files supported by the i5 server. They are as important as physical and logical files because they provide an avenue through which a program communicates with the user.

In theory, both display and printer files can be created with or without DDS. In practice, however, display files are almost useless if they are created without DDS. Printer files, on the other hand, are equally useful either way, if you program mainly in RPG. In other languages, printer files are much easier to handle if they also are created with DDS.

The remainder of this section assumes that you create your display and printer files with DDS.

Common Features

Both display and printer files support the following features:

• They usually contain more than one record format. A display file can use one record format to ask the user to enter a customer number and a different record format to display the customer's information. A printer file can use one record format for report headings and a different one for columnar data.

• Both support constant fields. Constant fields, as their name implies, are fields that never change in value. In a display file, a constant field could be the title that is centered at the top, or the legend that informs the user to press F3 to exit the program.

• Fields can be conditioned with indicators. You can condition the inclusion of a field in a record format so that the field is part of the record only if a set of indicators matches a certain pattern (off-on-off, for example). You can also condition some of the attributes of a field, such as making it appear underlined. Indicators are logical variables (switches) that can have only two values: on or off.

Display Files

You create a display file by writing the DDS and running the Create Display File (CRTDSPF) command. Display files offer a variety of functions:

• Data can go into or out of the program, because the fields can be defined as input, output, or both.

• The display file can sense when the user has pressed a function key (F1 to F24, Enter, Roll Up, Roll Down) and notify the program through an indicator.

• The display file can also sense many things about the input entered by the user and can act upon them. For example, you can define an input field in such a way that it only accepts the values ‘A’ or ‘B’. If the user enters a ‘C’, the display file rejects the input. The program doesn't get involved.

• You can define subfiles within the display file. A subfile is a group of similar records that can be displayed at one time on the screen and make columns of data. You can use arrays to simulate these columns, but subfiles simplify some of the coding (although they complicate other things).

The utility called Screen Design Aid (SDA) simplifies the design and maintenance of display files. SDA is described in Chapter 29.

Printer Files

Technically speaking, a printer file doesnt pass information from the program to the printer, but to a spool file in an output queue. To avoid unnecessary confu-sion, however, the popular printer file term will be used.

Printer files do more than pass information to a printer. They also format the data by adhering to the record format definition. They also contain a number of printer settings necessary to print the report successfully.

For example, you can create a printer file for printing purchase order forms. When you create the printer file (using the Create Printer File [CRTPRTF] command), you tell the system what form type to use, how many lines long the form is, how many characters wide, whether to skip unprintable characters, and the name of the default output queue or printer device.

From then on, each time you run a program that writes to that printer file, the system remembers all the printer settings and automatically generates a spool file that matches them. You don't have to remember the settings.

Printer files don't offer as many bells and whistles as display files because printers are not capable of receiving input or presenting text in blinking characters, for example. Printer files can still simplify the generation of bar codes and provide two special effects: underlining and highlighting (by printing more than once on the same spot).

You can design printer files by entering the DDS specifications directly with SEU, but there is another way, using IBMs Report Layout Utility (RLU), IBM's CODE Designer, or similar tools from other companies.