This problem began at the top of the month, when I tried to use the c
puts() function to provide quick-and-dirty diagnostics to a headless
server program, and was discussed briefly on the RPG list, without any
resolution so far. Then it got shoved aside in favor of more pressing
matters. But it has abruptly returned to the foreground.
Here is what we know so far:
On our boxes, and on the customer's old box, all of the usual ways to
produce spool files (e.g., compilation listings, PRTTRGPGM listings, the
"Host Print" key [from QuestView, or from a system menu], calling the
puts() function in the C runtime within a batch job, and so forth) all
produce spool files.
But on their new box, while compilation listings and PRTTRGPGM listings
still produce spool files, the "host print" key (wherever I've tried it)
and "puts() in a batch job" don't. There is no spool file if I do a
WRKSPLF; there's no spool file in WRKJOB option 4; there have been no
reports of unexpected pages coming out of unexpected printers.
It acts as if a spool file was produced, but there's no evidence that
One note: the print key takes about 2 seconds to produce the spool file
and unlock the keyboard on our 170, about half a second to do so on our
E4A, about 24 seconds to do so on the customer's old box (an M25), and
11 seconds to unlock the keyboard and come back with "Print operation
complete to the default printer device file" (but no actual spool file)
on the customer's new box (also an M25).
I don't suppose there's something that bypasses spool files entirely, is
QPRINT and QSYSPRT both exist, and they're both PRTFs. QPRINT is in
QGPL, and while QGPL is not in the default *LIBL, adding it has no
effect on the weird behavior.