Larry Byler <[log in to unmask]> wrote:
 
<snip>
 
>Here's what we can do quickly:
>
>o   Increase the spool file limit to 50000.  Simply requires changing a
>    CONST.  We don't want to go higher than that because of a current
>    limitation in XM.
 
Why choose 50,000?  Would, say 30,000 be adequate?
 
 
>o   Currently SPOOLF ;ALTER dequeues and requeues *even if the priority
>    or device specification doesn't change*.  Do a SPOOLF O@;SHOW as an SM
>    user (remember, the command defaults to ALTER) and you wait -- and
>    every other SPFDIR user waits with you.  (Note that this is not a
>    problem if you are a vanilla user with access to only a few spool
>    files, even if the system has many thousands of files -- the time is
>    spent only on the cached files, those that survive the cut).
>
>    It's easy to avoid the requeueing step if neither priority nor device
>    changes (as would be true for SPOOLF O@;SHOW).  On the 957 with 30000
>    spool files, the command released the lock after 22 seconds and began
>    the file display at 1:39 (the interval was spent updating FLABXs).
>    But if you *do* change either attribute, and you can access all those
>    files, everyone will still wait (10 minutes with 9000 spool files,
>    did not take data with 30000 spool files).
 
 
Sounds good to me.
 
 
>o   Apply a heuristic to the DELETE function -- reverse the order of the
>    individual file deletions.  Because of the way spool file entries are
>    cached for deletion and XM directory transactions are logged, this
>    should substantially reduce the wait time for the DELETE user.
 
This seems OK too (but changing the ALTER behavior should have priority.)
 
These things never happened with the CM spooler; maybe we should go back to
that... ;-)
 
 -- Evan