Very well written... It won me over with the "better understanding" to ask the "WHY"...
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, March 14, 2012 6:49 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Weird Printer Issue
On 13-Mar-2012 11:24 , Jerry C. Adams wrote:
<<SNIP>>
I can't even test out any suggestions since things are (apparently)
working now. But for future reference, when it happens again, has
anyone seen anything like this before and/or got clue(s) what to look
for the next time it happens (cause I know it will - and at the worst
possible time).
In my experience, spending some time to better understand the why and
how everything is working as desired presently and to also gather some
specific details about the environment wherein everything is working
well [i.e. the details that confirm my understanding or inference about
why and how everything is working as expected] can be valuable as a
basis for comparison when things eventually stop working [again].
What needs to be understood as best as possible for this scenario is
how the session decides where data that is directed to print will
actually print; most consider that complicated, even without the S/36EE
in the mix. I can know with near certainty how print\spool will
function in SPCENV(*NONE), but I can barely recall the nuances of
printing within the *S36 special environment. The system I access does
not have the S36E installed, so I can not even refresh with actual
experience.
If I expected that I would be able to visit and work from a session
of a user to reproduce the problem, then while everything is working
well I would make a preemptive visit. In that first visit I would
collect stuff like: WRKJOB OUTPUT(*PRINT) and the s/36e-specific display
job information [i.e. IIRC, the SysRqs-3 details] from their session
[after the FORMS and\or PRINTER OCL, just before the printing request],
then additional information like DSPS36, DSPUSRPRF, WRKWTR *ALL, DSPDEVD
of the *PRT *DEVD, DSPPLFA of a simple spool that prints as expected,
and maybe DSPOBJD of some things that should not change as a record of
the last change date\time [perhaps even the system/36 environment
configuration object if an external object type]. Such things can then
be compared to the same information taken when visiting the same user
again after the printing stopped working again. If most users are
effectively "the same" in configuration, then even if not "the same"
user, some information may still have value to compare against the
pre-problem doc collection.
FWiW: SPOOL(*NO) as I recall was sometimes a typical effect from the
S/36, for which OUTQ is rendered meaningless. If a DEV specification
for a printer file or otherwise effected resolving to the device BB,
then attempts to redirect according to an OUTQ specification has no
effect, and the data spools\is-written directly to the device without
going through a queue; though the device must not be active to a writer.
Regards, Chuck
midrange.com
