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

On 21-Dec-2011 11:37 , James Lampert wrote:

<<SNIP>>

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.

Ignoring "puts()"... The printer file defined to the active display file is configurable, either at the file-level or the record-level, I do not recall.

It acts as if a spool file was produced, but there's no evidence that
this happened.

The SPOOL(*NO) attribute can ensure no spooling, for which I expect but do not recall, no FIN status spool file should appear in the WRKJOB OPTION(*SPLF). If a spool had been produced in the job, then the WRKJOB should show something; perhaps only if run by a user with *SPLCTL, in case something like SPLFOWN() setting might restrict the spool entry visibility to the user associated with the job.

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 would expect the results of a trace of the job would help to expose more details about the request. Especially helpful when comparing the failing scenario to the functional scenario. The QDMCOPEN logs in the trace data the file that was opened; stopping in an OPM program at statement '/1', a program that either writes or closes the spool, would allow inspecting the various job details in WRKJOB; e.g. if the SPLF appears in WRKJOB OPTION(*SPLF), what overrides might be in effect, etc.

I don't suppose there's something that bypasses spool files entirely,
is there?

For a specific file the output can be eliminated; e.g. for the printer file QSYSPRT:

OVRDBF QSYSPRT TOFILE(SomeDBfile) INHWRT(*YES) OVRSCOPE()

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.

For any operation which might use QPRINT, look into the existence of a file QPRINT in QTEMP in any job, per the effect of "puts()" as I had noted in the thread in the RPG forum:
http://archive.midrange.com/rpg400-l/201112/threads.html#00012

But again, a TRCJOB reveals much.

Regards, Chuck