You likely have an active secondary truncation point in your database.
The quick-n-dirty solution:
============
use <dbname>
go
-- following may generate error if repagent not running; if so, just ignore
sp_stop_rep_agent <dbname>
go
-- following may also generate an error if you don't have a repagent
sp_config_rep_agent <dbname>,'disable'
go
-- following is needed if you don't have a repagent
dbcc settrunc(ltm,ignore)
go
============
The detailed explanation ... there are a few different items to understand ...
===============
1 - What's marked for replication:
sp_reptostandby is showing that the database is marked for replication ('ALL'), ie, this database was a source for replication at the customer's site.
NOTE: You can also run 'sp_setreplicate' to see if any tables/procs have also been marked for replication.
By itself the marking of a table and/or database does not mean that data will be actually be replicated. Generally speaking having a table/database marked for replication shouldn't cause you any problems as long as you don't have a repagent and/or secondary trunc point defined (see next bullets) ...
===============
2 - repagent
For data to be replicated out of a database said database must have a repagent configured and running.
Repagent configuration details should be brought across with a database dump, so your dump file may have some repagent configuration details.
You can run 'sp_help_rep_agent <dbname>' to see what repagent details (if any) came across in your database dump file.
If you do have a repagent configuration in your database, and your dataserver has been configured to allow repagents ('enable rep agent threads' = 1), you're likely seeing some error messages in your ASE errorlog about the repagent (brought over in the dump file) having problems connecting to the repserver (it's highly unlikely that you have a repserver with the same name/login/password, eh?).
If you do have a repagent configured in your database you can get rid of it with the following:
============
use <dbname>
go
-- following may generate error if repagent is not running; if so, just ignore
sp_stop_rep_agent <dbname>
go
sp_config_rep_agent <dbname>,'disable'
go
============
===============
3 - secondary truncation point
Last but not least you must have an active secondary truncation point in your database. This is used by the repagent to keep track of where it is terms of reading the log and sending 'marked' transactions to the repserver.
The secondary truncation point will also come across in a database dump.
If your database has an active secondary truncation point then you should see an entry in master..syslogshold where dbid = db_id(<dbname>) and name = '$replication_truncation_point".
An active secondary truncation point will keep you from truncating the log past the point in the log where the secondary truncation point is currently pointing. If you don't have an active repagent (forwarding transactions to the repserver; moving the secondary truncation point) then your log *WILL* fill up ... and this is likely what's happening in your case.
You can eliminate the secondary truncation point through a couple methods:
a - stop/disable the repagent (if you have a repagent); the act of disabling the repagent should also remove the secondary truncation point
b - if you don't have a repagent but you see a record in syslogshold, then run the following:
============
use <dbname>
go
dbcc settrunc(ltm,ignore)
go
============
(Obviously) If you're successful at removing the secondary truncation point then a) the row will disappear from syslogshold and b) you'll be able to truncate your log.