×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.?
midrange.com
