× 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 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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.