(see thread on RPG list) Re: Test program calls puts(), creates spool file here, but not on customer box

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 this happened.

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 there?

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.

--
JHHL