Hi all !!! answer me please why onbar -l making logs back up so long than ontape. although onbar -b -L0 mydbs make dbspaces back up fast.
my part of onconfig
LOGFILES 100
LOGSIZE 500
LTAPEDEV \\.\TAPE0
LTAPEBLK 256
LTAPESIZE 1950000
LOGBUFF 32
LOGSMAX 300
BAR_MAX_BACKUP 4
BAR_RETRY 1
BAR_NB_XPORT_COUNT 20
BAR_XFER_BUF_SIZE 31

Hi,
Given the 2K pagesize for your system, your transfer buffers are sized at 63,988 bytes ( (BAR_XFER_BUF_SIZE * PAGESIZE) + 500 = 63988 ).
The extra 500 is for overhead. This number is just fine since XBSA has a 64K limit for transfer buffers anyway.
As you have set "LTAPEBLK 256", it is normal I think...
A nice explanation from John Miller is :

Just a few hints about BAR_NB_XPORT_COUNT & BAR_NB_XPORT_SIZE.
1. The number of buffer allocated for sending data for a single onbar
process to/from the storage manager. If you have 4 onbar process,
you will have 4 * BAR_NB_XPORT_COUNT buffer allocated.
2. If you change BAR_NB_XPORT_SIZE at ALL previous
backup, both logs and archives, are invalid.
3. Generally it is already set as large as possible. The XBSA spec
states that this can be 1 byte less then 64KB. Informix set it to
one database page less than 64KB. So for system with 2KB
database page size this would be 31 (2KB*31=62KB).

What these buffers do is hold the archive data for both informix and
the storage manager. In an attempt to not bycopy data Informix allocates
a set (the number determined by BAR_NB_XPORT_COUNT) of buffers
that are filed by the kaio threads in the engine and the pointers to these
buffers
are passed to onbar. This means that the actual data in the buffer (which is
sized
by BAR_NB_XPORT_SIZE) is not moved. onbar takes this pointer and
hands it directly to storage manager. Again the data never moves. While this
single buffer is being passed to the storage manager, oninit is filling the
other buffers (BAR_NB_XPORT_COUNT - 1) with data. This will
ensure that when onbar request another buffer it is already filled with data.

To view the status of these buffer you can use the command onstat -g stq. This
will show you the buffer and if they are on the full size (engine has filled
them with data) or the empty side (engine needs to fill the buffer with data).
You should
generally see one buffer missing of these queues and that is the buffer
currently being processed by the storage manager.

Hope this helps...

Murat

Thank you that you answered me! but I changed those sets and do not care I have similarly problems
Once again thanks
Idris