TSM on GPFS quota support

del fi on repl target using dedup and GPFS
.
Problembeschreibung
when running some del fi on a repl target using dedub and having DB,
LOG and STGP on GPFS

caused by the Dedup Deletion Worker the archlog was used to the given maximum by quota, i guess by a long running transaction. but from df where was used less than 80%

So no BD BACKUP was started and than it seems that DB2
filled up all space in activelog which has no quota to share the space to all TSM instances. But we use ActiveLogSize which is not honored becaus DB2 is using all active log space, not TSM.

can this be confirmed?
how can we avoid this, because the active log is used y other instances
too, and they got also problems caused by the filled filesystem.
can a DB Backup be triggered anyway?

DB2 support says:

Regarding your question. No, DB2 doesn't know anything about quota.
DB2 received information regarding no free space on the disk from the
operating system.

As I understand DB2 received errors regarding lack of the space but the
customer has sufficient free space on the disk.
I have reviewed the data provided by the customer (db2support).
From the database logs I see that the customer has the same errors not
only on /tsmarchlog but also on /tsmdb.

I discussed q log issue with development;

they conclude:
There is no quota support within the current Q LOG. We use a combination
of DB2
and STATVFS queries to generate the output.. Much like DB2, we take the
statistics from the filesystem to generate our
utilization report....and if the stat provides inconsistencies because
of the quota the application
will be unaware. The utilization percentage coming from DB2 will be
correct, as stated by DB2..they
just write away, so that is the key. We need to provision enough log
space for their TSM activity.

So currently it works as designed.