Hello,
I did not see a response to this particular post so if this
has been answered already my apologies.

I had a similar problem and the reason was that there were
no scratch volumes available for backing up the database.

To check if you have any scratch volumes left, go into
the server console and type

query libvolume

Look through the list to see if you have any. If not,
you need to add new 3590 tapes (be sure to add them
as scratch volumes).

It may be possible that you will not be able to add
the scratch volumes because the recovery log is full.

I do not quite remember all the details on how to solve
this problem. In my case I was forced to turn off roll forward
mode and/or extended the size of the recovery log (if the roll
forward mode is turned off, it may free up a lot of space
in your recovery log and you won't need to extend the
log, but I don't remember for sure). Then I added the scratch
volumes, made the database backup, and then put the recovery log
mode into roll forward again (by backing up the database, your
recovery log should be cleared).

Naomi van Roosmalen

RizzoM AT mail.dec DOT com wrote:
>
> Recently, DSMSERV refused to start on my RS6000 server
> due to not enough free space in the recovery log. I'm
> running in "roll-forward" mode with the database backup
> trigger set to 90% (of the recovery log). For some reason,
> the database could not be backed up and the log
> must have filled to capacity. My question is-
> what path does the database backup take?
> Does it follow a management class like other
> client backups (i.e. dump to backup pool)? Or
> does it follow some special type of backup scheme?
> I'm trying to find out if I have a disk problem (backup
> pool) or a tape problem (3590pool).
>
> Thanks,
>
> MJ. Rizzo
> DOD
> mark.rizzo AT digital DOT com