Much Ado About an Override
March 2, 2005 Ted Holt
Just when I think I’ve seen it all, along comes something unexpected. A dedicated reader of this column, one of the several Davids who writes me regularly, recently sent me an email with a line of CL code and the question, “Why does this work?”
This is the CL command:
OVRDBF FILE(REPORT) TOFILE(QSYSPRT)
If nothing appears out of kilter, then take a look at the following RPG file specs:
Fqsysprt o f 132 printer oflind(*inof) Freport o f 132 printer oflind(*inov)
Or, if you prefer, the COBOL equivalent from the environment division:
Select print1 assign to printer-qsysprt. Select print2 assign to printer-report.
That’s right. REPORT and QSYSPRT are printer files, but the command is Override with Database File.
Today is as good as any day to take a closer look at overrides. After all, judging from some of the code I’ve had to work on, the override commands seem to be among the few that some programmers seem to know.
When the operating system is called on to run a program, it has to go through certain preliminary steps, one of which is resolving all file references. If there are overrides, the system honors those, but let’s forget about overrides for the moment. In this example, the system looks for files REPORT and QSYSPRT. If there is a file named REPORT, the program attempts to allocate it to the program. The strange thing is that REPORT does not have to be a printer file. The same is true for QSYSPRT, of course.
If you’re interested, take it for a test drive. Flesh out the RPG or COBOL program and compile it:
Fqsysprt o f 132 printer oflind(*inof) Freport o f 132 printer oflind(*inov) C eval *inlr = *on C except Oqsysprt e 1 O 'qsysprt test' Oreport e 1 O 'report test'
Identification division.
Program-ID. Prt002A.
Environment division.
Configuration section.
Input-output section.
File-control.
Select print1 assign to printer-qsysprt.
Select print2 assign to printer-report.
Data division.
File section.
FD Print1.
01 Print1-rec.
05 Msg1 pic x(132).
FD Print2.
01 Print2-rec.
05 Msg2 pic x(132).
Procedure division.
Main-paragraph.
Open output print1 print2.
Move "Print1" to Msg1.
Write Print1-rec after 1.
Move "Print2" to Msg2.
Write Print2-rec after 1.
Goback.
Yes, I had to be sure that it worked the same way in COBOL too. I didn’t try C. Does anybody use C for report generation?
Create a program-described database file in QTEMP:
CRTPF QTEMP/REPORT RCDLEN(132)
Make sure that QTEMP is higher in the library list than any other library that contains a file called REPORT. Call your program. Take a look at the REPORT file in QTEMP:
DSPPFM QTEMP/REPORT
You should see the output from your program. The operating system didn’t care that the RPG program thought it was writing to a printer file, but REPORT was a database file instead. Check the output produced by your job. You’ll see a spool file produced by QSYSPRT.
|
If one or more overrides are in effect for the file NAME, the operating system will apply them. Clear (or delete) file QTEMP/REPORT, issue the OVRDBF command shown earlier, and call your program again. This time you’ll find two spool files, one for REPORT and one for QSYSPRT. The system used the database override to direct printer output to a printer file.
From these two test runs, it is evident that OS/400 allows device independence where it makes sense. That is, you can override a printer file to a database file (in some circumstances), but you can’t override an input-capable database file to a printer file. And therein lies the answer to David’s question.
The reason David found this oddity was that he needed to make a change to the override. I forget which parameter he had to change, but it was one of the parameters that are found in the Override with Printer File (OVRPRTF) command, such as COPIES or OUTQ. He replaced the OVRDBF command with an OVRPRTF command and everything was copacetic:
OVRPRTF FILE(REPORT) TOFILE(QSYSPRT) COPIES(2)
Click here to contact Ted Holt by e-mail.
