In addition to what Dennis said, these buffers are for concurrent access
and are IN MEMORY above 16M. So they don't indicate "SPOOL full". Even on
my relatively small z/OS system, I set this number to 209. "It's virtual,
so it's not a real problem!" <grin/>

On Mon, Jan 5, 2015 at 11:09 AM, Phil Smith <p...@voltage.com> wrote:

> We have an open-source STC which, if not shut down cleanly, has a tendency
> to fill SPOOL. Obviously we need to hunt down the problem and kill it. In
> the meantime, when it happens, and our system gets IPLed (second-level
> guest, at IBM Dallas), we wind up unable to logon. Starting the guest gets:
>
> *$HASP050 JES2 RESOURCE SHORTAGE OF BUFX - 100% UTILIZATION REACHED
>           A TOTAL OF 49 BUFX ARE CURRENTLY DEFINED, OF WHICH:
>              49 (100%) ARE IN USE
>              40 (81%) ARE BEING WAITED FOR
>              0 PROCESSORS REQUESTED BUFX BUT DID NOT WAIT
>              THE LARGEST UNFULFILLED REQUEST WAS FOR 0 BUFX
>           A MINIMUM OF 89 BUFX IS REQUIRED TO SATISFY CURRENT DEMAND
>
> Issuing commands like VINPUT VMSG $POJOBQ,ALL,PROTECTED,DAYS>0 seems to
> purge a bunch of stuff (we get messages that suggest this is true, and
> repeating the command gets "HASP003 RC=(52),PO JOBQ  - NO SELECTABLE
> ENTRIES FOUND MATCHING") but doesn't seem to actually help.
>
> So...from a SECUSERed VM logon, how can we clear SPOOL? A cold start would
> suffice, although of course knowing how to do so without a cold start would
> be even better (for those times when it's full but not yet down).
>
> Thanks.
>
> And yes, I've Googled and Googled 'til my Googler is sore; there must be
> something I haven't thought of before... (with apologies to Mr. Geisel)
>
> ...phsiii
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to