some ct_options / ct_diag questions

We are trying to get a CT-lib based driver between our software and a 
Sybase ASE backend to work with freetds as well,
so it would be possible to transparently support SQL Server as a backend 
as well.
We are running into a few issues however. Maybe someone can shed some 
light.

1) In the API support matrix it says that ct_options() is fully supported.
    However, the line:

    ct_options(dbconn, CS_SET, CS_OPT_ANSIPERM, &cstrue, CS_UNUNSED, NULL)

    elicits the following server message (from ASE only, no problem on SQL 
Server):
    msg number = 3807
    state = 9
    severity = 18
    text = "The datastream specifies a wrong option or commandl The 
datastream is 'TDS OPTION CMD'. This is an internal error"

    For the record, we also run:
    ct_options(dbconn, CS_SET, CS_OPT_ANSINULL, &cstrue, CS_UNUNSED, NULL) 
and
    ct_options(dbconn, CS_SET, CS_OPT_CURCLOSEONXACT,  &cstrue, 
CS_UNUNSED, NULL)
    and they give no problem.
    Does this have to do with the "type" of connection that freetds makes 
to ASE? I seem to recall reading somewhere
    that the freetds connection looks to ASE "just like an odbc 
connection".
 
2) I take it that support for the Open Client runtime configuration file 
does not work at all?
    In the documentation it says that cs_config() is partially supported.
    In any case, the call cs_config(context, CS_SET, CS_APPNAME, (CS_VOID 
*)"my_app", CS_NULLTERM, NULL) simply fails.

3) It looks like in-line message handling via ct_diag() is not supported 
in freetds, and a typedef for SQLCA is missing in the header file.
    Not too much of a problem, we can switch to message handling via 
callbacks.
   There remains one issue however in that case. In our driver we support 
a mechanism for 'array upsert'. You can pass in an SQL update statement
   with parameter markers and a set of row values, that are sequentially 
applied. Whenever one fails with an ansi 'record-not-found' condition,
   an alternate statement, usually an SQL insert is tried instead.
   'Array indate' is also possible if you suspect that the majority of 
your data won't be in the database yet. In this case insert is tried 
first,
   and if it fails with a duplicate key violation, update is used as the 
alternate.
   For upsert we exploit the fact that the Sybase Open Client library 
automatically converts the client message that ASE generates
   for an update statement that affected no rows, into an SQLCA with an 
sqlcode of 100. So we can check for errors codes 100 and 2601 (with ASE)
   to decide whether or not to apply the alternate statement.
   Any suggestions on how to accomplish this with freetds?

regards and tia,
Tim Knigge