Truncating the bi on a hot standby should not be done.
While it is technically possible to truncate the bi file of a hot standby and not invalidate the standby strategy (when the number of Active Transactions is zero), this is not a supported usage and Progress will not guarantee that there are no in-flight transactions when truncating.If there are in-flight transactions when the truncate is performed, it will invalidate the standby strategy. In which case, if after truncating the bi subsequent roll forward operations would fail with time stamp errors like:
** The database was last changed Ddd Mmm d hh:mm:ss yyyy. (831)
** The after-image file expected Ddd Mmm d hh:mm:ss yyyy. (832)
** Those dates don't match, so you have the wrong copy of one of them. (833)
This is because the database is opened when the bi is truncated. The roll forward qualifier to RFUTIL will fail if the database is opened before all AI extents are applied. For further clarification refer to Article
Why you should NOT truncate the bi of the target database when using an ai disaster recovery plan ? 
