Re: Seven page spooled file for F6=Print [Message]. Really?

On 31-Jul-2016 13:58 -0500, CRPence wrote:

[…] I just noticed that the F6=Print taken from an
F1=Help for the barest of messages produces a six-page or seven-page
spooled file! […] Shocking. […]

In the 7-page spooled file of a logged request message:

1 footing\output-end line
14 heading [7pg*2/pg] lines; quite distracting really
4 inexplicable blank lines
24 pertinent msg info lines

By my estimation, that makes:

~37% fluff\extraneous\worthless lines
~56% potentially revealing details about the msg
~07% worthwhile\legitimate heading+footing data

I can perceive a possible origin for the effect, in part, being an effective pre-defined formatting allowing for accommodation of the largest amount of data possible for many of the message elements; e.g. "From procedure" name could be very long, spanning many lines. Yet this feature uses the QSYSPRT Printer File (PRTF), an un-described printer file; i.e. no Record Formats (RCDFMT). That implies the ability of the feature to perform quite nearly free-form reporting. But even had the feature used an externally described printer file, most design[er]s would include the fixed mandatory\minimum output of [probably just] the first line as descriptive text for the element of data to be presented, and then conditionally output each additional line of data for that element; i.e. designed to allow the next record format to align [likely with a space-before] immediately after the final line of output from the prior record format, rather than forcing unconditionally, onto a new page, the next element of data.

I notice that QMHSCLVL as the program that generates the output is using the User Interface Manager (UIM) print capability. So possibly the issue is general to the [interface defined to the] UIM rather than specific to this feature of effective Display Message (DSPMSG) for OUTPUT(*PRINT). Or perhaps that program implementing the F6=Print request is incorrectly informing the UIM that the full amount of data always exists, despite various elements having included no details [no data] to be presented in the generated output.

Not having used the UIM print capabilities, I am unaware of the interface. I doubt the interface to UIM is so crappy, that the current ridiculous effect could not be improved upon, to generate output that seems at least somewhat less daft in presentation.?