Skip Robinson wrote:

>There are two distinct conditions that must be considered.

>1. A large output needs to be managed but is not causing a spool problem.
>2. An ginormous output--together with benign output--has pushed spool 
>utilization to 100%.

>In the case of #1, others have suggested ways to preserve at least some of the 
>output. Basically, assuming that the JCL was not coded to anticipate this 
>situation, you need to copy some portion of the output to another class or 
>destination. You could also save output to a data set. All spool management 
>tools I know of have this capability. Once desired output has been preserved 
>outside the jumbo job, El Gordo can be purged.

True. That is if the output is deallocated or freed by the offending program in 
the first place while that program is running.


>In the case of #2, your options are limited. If spool shortage cannot be 
>relieved, you may not even be able to logon to the MAS because even a TSO 
>address space needs some spool space.

True. I still have the scars of that, luckily I have a spare TSO session where 
I could fix those guzzling jobs properly. (and also sorted out an El Gordo XMIT 
data on the JES2 SPOOL, which guzzled up the whole spool. I deleted that and 
showed that grumbling XMITter how to do FTP instead of XMIT.)

And trained that submitter of those jobs to insert a SYSOUT 
FREE=CLOSE,SPIN=UNALLOC before re-submitting that offending job.

Or teach them to redirect the output to a dataset.

Hard work to train those dummies... ;-D


>I don't believe that you can purge an individual segment while a job is still 
>writing to it.

True. Also while that step is still writing to it. Wait for the step to free or 
deallocate the output and then you can purge it.


>When spool-full condition has hit us, the offending job is usually still 
>running, so that space recovered by purging some disposable output is 
>immediately filled up again by the same job. If this situation occurs, you 
>have little choice but to cancel *and purge* the offending job, which 
>unfortunately means losing all the output.

Sometimes the only option. Just preserve the 'x millions lines written' in the 
SYSLOG to pacify the angry submitter...

I sometimes threatened to write that JES2 exit to limit/crush those spool 
eating jobs outputs, but my users cancelled my obsession to keep the JES2 spool 
empty... ;-)

Groete / Greetings
Elardus Engelbrecht

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to