cobol400-l-request@xxxxxxxxxxxx wrote:
1. defining multiple printer files in ILE COBOL...
(Michael Rosinger)
It is my understanding that a typical printer file definition is something
like:
SELECT PRINT-FILE1 ASSIGN TO PRINTER-QPRINT.
If the program in question produces multiple reports, is it as simple as
defining additional files like this?
SELECT PRINT-FILE2 ASSIGN TO PRINTER-QPRINT.
SELECT PRINT-FILE3 ASSIGN TO PRINTER-QPRINT.
If so, how does the O/S know to separate the reports as individual files? Or
am I missing a qualification somewhere? Something special in the CL? The
above compiles fine but I'm not yet able to test the program.
A CL example calling a program that produces multiple report files would be
very helpful. TIA
Michael:
Strictly speaking, you probably shouldn't be using [QPRINT] at all;
you should create a printer file that is appropriate to its usage.
You create a printer file more or less like you would create a
physical data file or a display file -- by entering DDS source and
compiling. And you create them for similar reasons -- a different
printer file has different headings, different columns, different
totals, different widths, etc., just as various display files do.
Most likely you rarely use any of IBM's display files. Why would you
use their printer files?
Well, I understand why; mostly because that's what most others do
and it's (at first look) easy. But it has restrictions.
For example, if you use the same file definition twice, you have a
hard time determining which is which, both at run-time and later
when the spooled output is sitting on an *outq.
You _could_ create a display file that had basically a big blank
buffer and then write all the code that fills in constants and field
definitions before writing it to the screen; and then read it back
in and extract what you needed. But you probably wouldn't since it's
much easier to create a unique, externally-described display file
for each unique usage.
The same principles apply to printer files.
Unfortunately, the use of QPRINT (or QSYSPRT or whichever is common
in your environment) got entrenched because IBM didn't supply a
developer tool that was as easy as SDA for designing screen formats.
The RLU tool was deemed too cumbersome and never got used as much;
and that led to it being ignored by both developers and IBM.
However, by learning either RLU or the DDS itself, you can bring
(more or less) the same advantages of externally-described printer
files to your programming as happens with display files or data
files. Not only will you get much more precise control, but you get
to maintain the printer file specifications without always needing
to change program code.
Others are saying plenty about the question you asked. Rather than
repeat what's been said, I just thought I'd bring a different slant
to the discussion. I haven't compiled [QPRINT] or other IBM-supplied
printer file into a (production) program for almost 20 years, since
first giving the alternative a try.
Tom Liotta
midrange.com
