A printer file is an object which contains a defintiion of the layout (fields, constants, etc) that a program will use to print. Printer files are described using DDS (data description specifications). There are utilities to help you define print files, the IBM supplied one is called RLU.
You can find more information in the DDS for printer files manuals :-
For these types of questions, the <a href=”http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp”>i5/OS Information Center</a> is a valuable resource. Searching the Information Center using “printer file” you find hits such as <a href=”http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzalu/rzaluprtfover.htm”>System i: Printer File</a> which then links to an overview of printer file and, from there, additional links to further information on program described printer files, externerally described printer files, etc.
Providing integrated solutions for the System i user community
A printer file relates to what a program prints to a spooled report as a display file relates to what a program displays on a screen.
A printer file might have one record format that describes all of the fields and constants that appear in the headings of a report. The program moves the data into the fields of the record format, issues a WRITE statement for that record format, and all of the header lines are printed for that page at one time.
Another record format might describe a detail line on the report. The program could loop through the file and issue one WRITE for each detail line. (Or a detail record format might include many lines. I have had detail formats that describe entire pages — one WRITE caused the whole page to print.)
Create printer files in order to have the output layout described outside of any program. Technically, all printed output in an entire application could be described as record formats in a single “application printer file”. The programs could all use the same PRTF, but they would each WRITE only the record formats that were meaningful to them.
That wouldn’t be a useful design for the vast majority of applications though. A PRTF should include information about how many lines are on each page, how many lines can print before overflow is signaled, what the lines-per-inch and characters-per-inch are, and all of the characteristics of a particular kind of report.
The idea is that the logic of printing can be separated from the detail layout of pages. You can modify layout in the DDS and not have to recompile the program.