ANR8341I End-of-volume reached for FILE volume

ACTION TAKEN: I informed the customer after discussion with development:
We have had multiple discussions with different developers and each time
we get to the same point of this is not something that we can fix in an
APAR. This is working as designed but it is clearly not a desired
behavior. When no scratch volumes are available and the sessions ended
up waiting on a filling volume that gets filled up by another session we
do not have a good recovery method at that point. The way this is
currently handled and has always been handled is we tell the client that
we did not have the space and then they redrive the request.

All of this works fine when there are scratch volumes available, but in
the special case of a file pool where disk is a limiting factor and
there may be no possibility of scratch volumes this does not work as
efficiently.

This will have to be handled as an RFE. The general design of an almost
full sequential storage pool when backup operations go directly into
that
storage pool does not handle these issues very well. For initial
allocations this would not be too difficult of a fix, the real problem
is handling spanned volumes. Because we do not allow a bitfile to span
storage pools this would leave us the quandary of deciding to error like
we do now or to wait hoping that a volume becomes available eventually.
Since we also do not have a method to preallocate space in a sequential
pool like we do a random access pool we can not just direct the backup
directly to the next pool is we were able to make an initial allocation
into the storage pool or if there is a filling volume available because
maybe there would be space on that volume once we were able to obtain
the volume.

Anything that we could look at fixing in the service stream for this
issue would only help in a few specific cases but would not fix the
general case of this problem and for that we need an RFE to be able to
handle the general case of the problem. Note, we state this is a
problem for an almost full sequential storage pool. If the storage pool
was completely full such that there are no remaining scratch volumes
available and there are no empty or filling volumes in the pool then the
initial allocation would go directly to the next storage pool.