quickfixj-users

[Quickfixj-users] Generate FIX string with tags in a specific order?

[David B. <dbu...@gm...>]

Hi Folks,

I was wondering, is there a means to generate a fix message with tags in a
specific order?

I have a destination I connect to that requires LegRefNo(654) to be the
anchor tag in a multi leg order.

So basically, they need 654 to be the first tag in each segment of the
repeating group.

any chance there's something built in for this?  or should I start hacking?

Re: [Quickfixj-users] Generate FIX string with tags in a specific order?

[Steve B. <st...@te...>]

Hello,

The engine will order the tags in a repeating group based on the
data dictionary ordering.

Steve

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Hi Folks,
>
> I was wondering, is there a means to generate a fix message with tags in a
> specific order?
>
> I have a destination I connect to that requires LegRefNo(654) to be the
> anchor tag in a multi leg order.
>
> So basically, they need 654 to be the first tag in each segment of the
> repeating group.
>
> any chance there's something built in for this?  or should I start
> hacking?
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>
> http://get.splunk.com/_______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] Generate FIX string with tags in a specific order?

[David B. <dbu...@gm...>]

Right, but the problem I have is, there seems to be no way to generate the
fix string based on a new dictionary.

ie: everyone else expects tag 600 to be the first, but one guy want's 654 to
be first.  What's the normal way to accomplish this?

Create a new message and copy all the fields one at a time?

there is an "initializeFrom" field in FieldMap, but it's protected, so I
can't just call it to clone the fields.

I was hoping for something that let me do (in effect)
msg.toString(Dictionary)

which would render the fix string with a given dictionary.

But I'm pretty sure there is no mechanism like that exists, at least as far
as I can tell from the source.

On 8/13/07, Steve Bate <st...@te...> wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Hello,
>
> The engine will order the tags in a repeating group based on the
> data dictionary ordering.
>
> Steve
>
> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> > QuickFIX/J Support: http://www.quickfixj.org/support/
> > Hi Folks,
> >
> > I was wondering, is there a means to generate a fix message with tags in
> a
> > specific order?
> >
> > I have a destination I connect to that requires LegRefNo(654) to be the
> > anchor tag in a multi leg order.
> >
> > So basically, they need 654 to be the first tag in each segment of the
> > repeating group.
> >
> > any chance there's something built in for this?  or should I start
> > hacking?
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >>
> > http://get.splunk.com/_______________________________________________
> > Quickfixj-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> >
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] Generate FIX string with tags in a specific order?

[Toli K. <to...@ma...>]

David,

> I was hoping for something that let me do (in effect)
> msg.toString(Dictionary)

There actually is a quickfix.Message call you can use:
    public void fromString(String messageData, DataDictionary dd,
boolean doValidation)

Will that work of you? you can create one message the "regular way",
then to a toString() on it and use the string-based FIX messgae to
re-create it using a custom dictionary.

Perhaps that may work for you?

-- 
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

Re: [Quickfixj-users] Generate FIX string with tags in a specific order?

[dmd <dm...@co...>]

This solution will work, but it seems rather inefficient, especially for
latency sensitive applications, like ours for instance.  Will this issue be
'fixed' at some point?

Actually, does the FIX spec mandate that tags be in a particular order?  Or
is it just according to the dictionary's definition?  In other words, is the
particular aforementioned exchange doing something non-standard?

Cheers,
Dan



toli wrote:
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> David,
> 
>> I was hoping for something that let me do (in effect)
>> msg.toString(Dictionary)
> 
> There actually is a quickfix.Message call you can use:
>     public void fromString(String messageData, DataDictionary dd,
> boolean doValidation)
> 
> Will that work of you? you can create one message the "regular way",
> then to a toString() on it and use the string-based FIX messgae to
> re-create it using a custom dictionary.
> 
> Perhaps that may work for you?
> 
> -- 
> Toli Kuznets
> http://www.marketcetera.com: Open-Source Trading Platform
> download.run.trade.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Generate-FIX-string-with-tags-in-a-specific-order--tp12129446p15219578.html
Sent from the QuickFIX/J mailing list archive at Nabble.com.

Re: [Quickfixj-users] Generate FIX string with tags in a specific order?

[Steve B. <st...@te...>]

Hi Dan,

Based on what you've said, it sounds nonstandard. The FIX
specification does specify the order of repeating group fields
but not the non-group message fields.

Which exchange is requiring this behavior?

I assume you are building your message using the generated
group subclasses. Is that right? If so, you could instead create
a Group object with the required nonstandard first/delimeter
field and the required field order for the remaining group
fields.

For example, the Header.NoHops group class is defined as ...

  public static class NoHops extends Group {
    public NoHops() {
        super(627, 628,
            new int[] {628, 629, 630,  0 } );
    }

    ...
  }

The first constructor argument is the count tag, the 
second argument is the delimeter/first field tag and the third 
argument is the group field ordering.

If you need field 629 to be the first group field you
could use a generic Group like ...

   new Group(627, 629, new int[] { 629, 628, 630, 0 });

This group could be created using data from a data dictionary.
You could also create a custom subclass with the modified 
constructor.

  public class NonstandardNoHops extends Group {
    public NoHops() {
        super(627, 629,
            new int[] {629, 628, 630,  0 } );
    }

    ...
  }

Another option is to modify the data dictionary XML and
regenerate the classes for the nonstandard exchange. (This might
require running the engine for that exchange in it's own
JVM to avoid problems with differing message classes.)

There are lots of options. As you mentioned, we could also
format group-related fields using a data dictionary but
this will be somewhat slower than the current approach. 

Regards,

Steve

> -----Original Message-----
> From: qui...@li... 
> [mailto:qui...@li...] On 
> Behalf Of dmd
> Sent: Thursday, January 31, 2008 9:37 PM
> To: qui...@li...
> Subject: Re: [Quickfixj-users] Generate FIX string with tags 
> in a specific order?
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> 
> 
> 
> This solution will work, but it seems rather inefficient, 
> especially for latency sensitive applications, like ours for 
> instance.  Will this issue be 'fixed' at some point?
> 
> Actually, does the FIX spec mandate that tags be in a 
> particular order?  Or is it just according to the 
> dictionary's definition?  In other words, is the particular 
> aforementioned exchange doing something non-standard?
> 
> Cheers,
> Dan
> 
> 
> 
> toli wrote:
> > 
> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> > QuickFIX/J Support: http://www.quickfixj.org/support/ David,
> > 
> >> I was hoping for something that let me do (in effect)
> >> msg.toString(Dictionary)
> > 
> > There actually is a quickfix.Message call you can use:
> >     public void fromString(String messageData, DataDictionary dd, 
> > boolean doValidation)
> > 
> > Will that work of you? you can create one message the 
> "regular way", 
> > then to a toString() on it and use the string-based FIX messgae to 
> > re-create it using a custom dictionary.
> > 
> > Perhaps that may work for you?
> > 
> > --
> > Toli Kuznets
> > http://www.marketcetera.com: Open-Source Trading Platform 
> > download.run.trade.
> > 
> > 
> ----------------------------------------------------------------------
> > --- This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX 
> and a browser.
> > Download your FREE copy of Splunk now >>  http://get.splunk.com/ 
> > _______________________________________________
> > Quickfixj-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> > 
> > 
> 
> --
> View this message in context: 
> http://www.nabble.com/Generate-FIX-string-with-tags-in-a-speci
> fic-order--tp12129446p15219578.html
> Sent from the QuickFIX/J mailing list archive at Nabble.com.
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> 

Re: [Quickfixj-users] Generate FIX string with tags in a specific order?

[dmd <dm...@co...>]

Thanks very much Steve!

It seems like subclassing the Group and defining the custom ordering will be
the best solution in our case.

Cheers,
Dan



Steve Bate wrote:
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> 
> 
> Hi Dan,
> 
> Based on what you've said, it sounds nonstandard. The FIX
> specification does specify the order of repeating group fields
> but not the non-group message fields.
> 
> Which exchange is requiring this behavior?
> 
> I assume you are building your message using the generated
> group subclasses. Is that right? If so, you could instead create
> a Group object with the required nonstandard first/delimeter
> field and the required field order for the remaining group
> fields.
> 
> For example, the Header.NoHops group class is defined as ...
> 
>   public static class NoHops extends Group {
>     public NoHops() {
>         super(627, 628,
>             new int[] {628, 629, 630,  0 } );
>     }
> 
>     ...
>   }
> 
> The first constructor argument is the count tag, the 
> second argument is the delimeter/first field tag and the third 
> argument is the group field ordering.
> 
> If you need field 629 to be the first group field you
> could use a generic Group like ...
> 
>    new Group(627, 629, new int[] { 629, 628, 630, 0 });
> 
> This group could be created using data from a data dictionary.
> You could also create a custom subclass with the modified 
> constructor.
> 
>   public class NonstandardNoHops extends Group {
>     public NoHops() {
>         super(627, 629,
>             new int[] {629, 628, 630,  0 } );
>     }
> 
>     ...
>   }
> 
> Another option is to modify the data dictionary XML and
> regenerate the classes for the nonstandard exchange. (This might
> require running the engine for that exchange in it's own
> JVM to avoid problems with differing message classes.)
> 
> There are lots of options. As you mentioned, we could also
> format group-related fields using a data dictionary but
> this will be somewhat slower than the current approach. 
> 
> Regards,
> 
> Steve
> 
>> -----Original Message-----
>> From: qui...@li... 
>> [mailto:qui...@li...] On 
>> Behalf Of dmd
>> Sent: Thursday, January 31, 2008 9:37 PM
>> To: qui...@li...
>> Subject: Re: [Quickfixj-users] Generate FIX string with tags 
>> in a specific order?
>> 
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> 
>> 
>> 
>> This solution will work, but it seems rather inefficient, 
>> especially for latency sensitive applications, like ours for 
>> instance.  Will this issue be 'fixed' at some point?
>> 
>> Actually, does the FIX spec mandate that tags be in a 
>> particular order?  Or is it just according to the 
>> dictionary's definition?  In other words, is the particular 
>> aforementioned exchange doing something non-standard?
>> 
>> Cheers,
>> Dan
>> 
>> 
>> 
>> toli wrote:
>> > 
>> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> > QuickFIX/J Support: http://www.quickfixj.org/support/ David,
>> > 
>> >> I was hoping for something that let me do (in effect)
>> >> msg.toString(Dictionary)
>> > 
>> > There actually is a quickfix.Message call you can use:
>> >     public void fromString(String messageData, DataDictionary dd, 
>> > boolean doValidation)
>> > 
>> > Will that work of you? you can create one message the 
>> "regular way", 
>> > then to a toString() on it and use the string-based FIX messgae to 
>> > re-create it using a custom dictionary.
>> > 
>> > Perhaps that may work for you?
>> > 
>> > --
>> > Toli Kuznets
>> > http://www.marketcetera.com: Open-Source Trading Platform 
>> > download.run.trade.
>> > 
>> > 
>> ----------------------------------------------------------------------
>> > --- This SF.net email is sponsored by: Splunk Inc.
>> > Still grepping through log files to find problems?  Stop.
>> > Now Search log events and configuration files using AJAX 
>> and a browser.
>> > Download your FREE copy of Splunk now >>  http://get.splunk.com/ 
>> > _______________________________________________
>> > Quickfixj-users mailing list
>> > Qui...@li...
>> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> > 
>> > 
>> 
>> --
>> View this message in context: 
>> http://www.nabble.com/Generate-FIX-string-with-tags-in-a-speci
>> fic-order--tp12129446p15219578.html
>> Sent from the QuickFIX/J mailing list archive at Nabble.com.
>> 
>> 
>> --------------------------------------------------------------
>> -----------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Generate-FIX-string-with-tags-in-a-specific-order--tp12129446p15220625.html
Sent from the QuickFIX/J mailing list archive at Nabble.com.

[Quickfixj-users] acceptor

[Robert B. <rbr...@me...>]

Hey guys,

When we fire up our acceptor (we're using JDBC logging), it logs an
entry in the sessions table and continues to log to the other 3 tables
throughout the day, but NEVER comes back to the session table to
increment the sequence numbers.  It's internally keeping tally of the
sequence numbers, which kind of sucks because if something happens and
our acceptor instance goes down, our vendor needs to resend the entire
days' worth of messages because even if we manually update the session
entry in the sessions table with the correct sequence numbers, it
refuses to read that entry, creates a new entry and starts from 1, 1.

I just figured out what the problem is but I don't know how to fix it
without modifying the source code and rebuilding the jar file, which I
was hoping to not have to do because then that becomes a maintenance
nightmare whenever a new release of the quickfix libraries is released
and we'd like to upgrade.

The issue is we're using an oracle database and with an acceptor you're
not allowed to use a session qualifier for whatever reason and I'm
guessing somehow the initial creation of the session entry works but any
subsequent update to the table fails because the session qualifier is
null.  I haven't looked into the code but I remember that JDBC logging
against an Oracle db is a problem if you don't provide a session
qualifier.  This is all working fine and good for our initiators, but
the acceptor doesn't not update the sessions table at all...all other
tables get inserted to just fine.  I guess I could modify the source
code in the interim but I was hoping we could put in for a fix in a
future release for this or get an explanation as to why session
qualifiers don't work for acceptors?

Thanks!

robert l. brueckmann
vice president
merlin securities
712 fifth avenue
new york, ny 10019
p: 212.822.4821
f: 212.822.4820

Merlin Securities - #1 Prime Broker North America and #1 Prime Broker Singl=
e Strategy Funds - Global Custodian 2007
#1 Prime Broker for Hedge Funds under $1 Billion - Alpha Survey 2007



=20

--------------------------------------------------------

This message contains information from Merlin Securities, LLC, or from one =
of its affiliates, that may be confidential and privileged. If you are not =
an intended recipient, please refrain from any disclosure, copying, distrib=
ution or use of this information and note that such actions are prohibited.=
 If you have received this transmission in error, please notify the sender =
immediately by telephone or by replying to this transmission.
=20
Merlin Securities, LLC is a registered broker-dealer. Services offered thro=
ugh Merlin Securities, LLC are not insured by the FDIC or any other Federal=
 Government Agency, are not deposits of or guaranteed by Merlin Securities,=
 LLC and may lose value. Nothing in this communication shall constitute a s=
olicitation or recommendation to buy or sell a particular security.

Re: [Quickfixj-users] acceptor

[Steve B. <st...@te...>]

> The issue is we're using an oracle database and with an acceptor you're
> not allowed to use a session qualifier for whatever reason and I'm
> guessing somehow the initial creation of the session entry works but any
> subsequent update to the table fails because the session qualifier is
> null.  I haven't looked into the code but I remember that JDBC logging
> against an Oracle db is a problem if you don't provide a session
> qualifier.

Hello Robert,

This problem is only indirectly related to session qualifiers. The root
problem is that Oracle treats empty strings as SQL nulls. The SessionID
uses empty strings rather than Java nulls for unset values. My guess is
this was done in QF to avoid this very problem of attempting to put SQL
nulls into nonnullable primary key columns. However, Oracle's behavior
breaks that approach.

One way to fix the Oracle problem is to provide a different default
value for unset SessionID properties. I'd recommend doing this in the
JdbcStore immediately before performing SQL operations. Therefore, it
would be an option on the JdbcStore (something like
"JdbcStoreSessionIdPropertyDefault"). You could then create a setting
like

JdbcStoreSessionidPropertyDefault=N/A

and the string "N/A" would be written to the database instead of
an empty string. If you are using 1.3.1 and need this in a hurry,
this would be an easy modification to the JdbcUtil.setSessionIdParameters()
method.

In the meantime, I've added a Jira issue (QFJ-295) to add this capability
into the next release.

> ... get an explanation as to why session qualifiers don't work
> for acceptors?

This is really a separate issue, but session qualifiers are a
hack for initiators that must communicate with nonstandard counterparties
who use the same session ID for multiple sessions (rare). This works on
the initiator side because the initiating application specifies the specific
session when sending a message and received messages arrive on a socket
that is bound to the qualifier session. It doesn't work for an acceptor.
There
is no standard way for a counterparty to send a session qualifier to
an acceptor. When the acceptor receives a message it would have no way
to know which "qualified" session to dispatch it to.

Regards,

Steve

Re: [Quickfixj-users] acceptor

[Robert B. <rbr...@me...>]

Thanks for the quick and thorough reply Steve!  The other problem I
encountered is we're using Java 1.4.2...but I think I can convince them
to upgrade to Java 5 for the FIX servers at least.  Domino effect!

Intervening on the source code is slightly problematic for upgrades for
us because we're also using an extended FIX42.xml data dictionary file
as well (which already requires me to unjar the 42 library and replace
the data dictionary with our extended version and then re-jar it)...
that contains the following two additional entries for liquidity for
Nasdaq and DirectEdge who unfortunately use the same custom liquidity
tag and for ARCA:

<field number="9882" name="INETLiquidity" type="CHAR">
      <value enum="A"
description="(INET)ADDED(EDGA-EDGX)EXECUTION_ADDED_LIQUIDITY_TO_INET_BOO
K_(TAPE_A-B-C)"/>
      <value enum="B"
description="(EDGA-EDGX)EXECUTION_ADDED_LIQUIDITY_(TAPE_B)"/>
      <value enum="C" description="(INET)CLOSING_CROSS_BILLABLE"/>
      <value enum="D"
description="(INET)DOT(EDGA-EDGX)LISTED_ROUTE_REMOVING_LIQUIDITY_FROM_NY
SE_DOT_(TAPE_A)"/>
      <value enum="E"
description="(EDGA-EDGX)INTERNAL_MATCH_(TAPE_A-B-C_ADD_AND_REMOVE_MMIDS_
ARE_THE_SAME)"/>
      <value enum="F"
description="(INET)ADDED_OR_OPENING_TRADE_(ON_NYSE)(EDGA-EDGX)LISTED_ROU
TE_ADDING_LIQUIDITY_TO_NYSE_DOT_(TAPE_A)"/>
      <value enum="G"
description="(INET)ODD_LOT_OR_ON-CLOSE_ORDER_(ON_NYSE)"/>
      <value enum="H"
description="(INET)HALT_IPO_CROSS_BILLABLE(EDGA-EDGX)EXECUTION_ADDED_LIQ
UIDITY_FROM_HIDDEN_ORDER_(TAPE_A-B-C_EDGA_ONLY)"/>
      <value enum="I"
description="(INET)INTRADAY_POST-MARKET_CROSS(EDGA-EDGX)ROUTE_TO_NYSE-AR
CA_AMEX_OR_REGIONALS_(TAPE_A-B)"/>
      <value enum="J" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="K" description="(INET)HALT_IPO_CROSS_NON-BILLABLE"/>
      <value enum="L"
description="(INET)CLOSING_CROSS_NON-BILLABLE(EDGA-EDGX)ODD_LOT_ROUTE_TO
_NYSE-ARCA_(TAPE_A-B)"/>
      <value enum="M" description="(INET)OPEN_CROSS_NON-BILLABLE"/>
      <value enum="N"
description="(EDGA-EDGX)EXECUTION_REMOVED_LIQUIDITY_(TAPE_B-C)"/>
      <value enum="O"
description="(INET)OPEN_CROSS_BILLABLE(EDGA-EDGX)ROUTED_TO_THE_NASDAQ_OP
ENING_CROSS_(TAPE_C)"/>
      <value enum="P"
description="(EDGA-EDGX)ROUTE_TO_NYSE-ARCA_(TAPE_C)"/>
      <value enum="Q"
description="(EDGA-EDGX)ROUTE_TO_EXTERNAL_VENUE_(TAPE_A)"/>
      <value enum="R"
description="(INET)REMOVED(EDGA-EDGX)LISTED_ROUTE_REROUTING_VIA_NYSE_DOT
_(TAPE_A)"/>
      <value enum="S"
description="(EDGA-EDGX)EXECUTION_FOR_AN_ISO_ORDER_ROUTED_EXTERNALLY_AS_
ISO_(TAPE_A-B-C)"/>
      <value enum="T" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="U" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="V"
description="(EDGA-EDGX)EXECUTION_ADDED_LIQUIDITY_(TAPE_A)"/>
      <value enum="W"
description="(EDGA-EDGX)EXECUTION_REMOVED_LIQUIDITY_(TAPE_A)"/>
      <value enum="X"
description="(INET)ROUTED(EDGA-EDGX)ROUTE_TO_EXTERNAL_VENUE_(TAPE_B-C)"/
>
      <value enum="Y"
description="(INET)RE-ROUTED_BY_NYSE(EDGA-EDGX)EXECUTION_ADDED_LIQUIDITY
_(TAPE_C)"/>
      <value enum="Z"
description="(EDGA-EDGX)ROUTE_TO_AN_IOI_DESTINATION_(TAPE_A-B-C_ROUZ_EXE
CBROKER_ONLY)"/>
      <value enum="0" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="1" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="2" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="3" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="4" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="5" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="6" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="7" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="8" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="9" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
    </field>
    <field number="9730" name="ARCALiquidity" type="CHAR">
      <value enum="A" description="ADDING"/>
      <value enum="B" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="C" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="D" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="E" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="F" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="G" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="H" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="I" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="J" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="K" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="L" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="M" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="N" description="NYSE_ROUTED"/>
      <value enum="O" description="AT_THE_OPENING_(OPENING_AUCTION)"/>
      <value enum="P" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="Q" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="R" description="REMOVING"/>
      <value enum="S" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="T" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="U" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="V" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="W" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="X" description="ROUTED_AWAY"/>
      <value enum="Y" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="Z" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="0" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="1" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="2" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="3" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="4" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="5" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="6" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="7" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="8" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
      <value enum="9" description="UNKNOWN_VALUE_NOT_IN_SPEC"/>
    </field>

I put in all the UNKNOWN_VALUE entries in there because the destinations
like to throw in new values all of the time, causing messages to reject.
I'm surprised the FIX spec doesn't have anything for liquidity like this
by default to unify this instead of every single destination coming up
with custom tags.  Oh well.

I tried adding the above to the FIX42.xml file and then running the jar
ant target in the 1.3.1 source download and that kept failing on the
creation of these tags as Java classes because I guess characters in my
description attribute for each value (which are all XML-compliant
characters) are causing the jalopy libraries to fail.

Fun times!  BTW, the fields above are direct from Nasdaq, DirectEdge and
ARCAs actual specifications with exact descriptions pulled from their
APIs...I couldn't think of a more elegant approach to the dually-used
9882 tag by both INET and DirectEdge...in case anyone is interested in
using them and are concerned as to their validity.

Thanks again for all your help!

robert l. brueckmann
vice president
merlin securities
712 fifth avenue
new york, ny 10019
p: 212.822.4821
f: 212.822.4820



Merlin Securities - #1 Prime Broker North America and #1 Prime Broker Single Strategy Funds - Global Custodian 2007
#1 Prime Broker for Hedge Funds under $1 Billion - Alpha Survey 2007



From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Steve Bate
Sent: Monday, February 04, 2008 10:45 AM
To: qui...@li...
Subject: Re: [Quickfixj-users] acceptor

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


> The issue is we're using an oracle database and with an acceptor
you're
> not allowed to use a session qualifier for whatever reason and I'm
> guessing somehow the initial creation of the session entry works but
any
> subsequent update to the table fails because the session qualifier is
> null.  I haven't looked into the code but I remember that JDBC logging
> against an Oracle db is a problem if you don't provide a session
> qualifier.

Hello Robert,

This problem is only indirectly related to session qualifiers. The root
problem is that Oracle treats empty strings as SQL nulls. The SessionID
uses empty strings rather than Java nulls for unset values. My guess is
this was done in QF to avoid this very problem of attempting to put SQL
nulls into nonnullable primary key columns. However, Oracle's behavior
breaks that approach.

One way to fix the Oracle problem is to provide a different default
value for unset SessionID properties. I'd recommend doing this in the
JdbcStore immediately before performing SQL operations. Therefore, it
would be an option on the JdbcStore (something like
"JdbcStoreSessionIdPropertyDefault"). You could then create a setting
like

JdbcStoreSessionidPropertyDefault=N/A

and the string "N/A" would be written to the database instead of
an empty string. If you are using 1.3.1 and need this in a hurry,
this would be an easy modification to the
JdbcUtil.setSessionIdParameters()
method.

In the meantime, I've added a Jira issue (QFJ-295) to add this
capability
into the next release.

> ... get an explanation as to why session qualifiers don't work
> for acceptors?

This is really a separate issue, but session qualifiers are a
hack for initiators that must communicate with nonstandard
counterparties
who use the same session ID for multiple sessions (rare). This works on
the initiator side because the initiating application specifies the
specific
session when sending a message and received messages arrive on a socket
that is bound to the qualifier session. It doesn't work for an acceptor.
There
is no standard way for a counterparty to send a session qualifier to
an acceptor. When the acceptor receives a message it would have no way
to know which "qualified" session to dispatch it to.

Regards,

Steve


------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
 

--------------------------------------------------------

This message contains information from Merlin Securities, LLC, or from one of its affiliates, that may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify the sender immediately by telephone or by replying to this transmission.
 
Merlin Securities, LLC is a registered broker-dealer. Services offered through Merlin Securities, LLC are not insured by the FDIC or any other Federal Government Agency, are not deposits of or guaranteed by Merlin Securities, LLC and may lose value. Nothing in this communication shall constitute a solicitation or recommendation to buy or sell a particular security.

Re: [Quickfixj-users] acceptor

[Steve B. <st...@te...>]

> Thanks for the quick and thorough reply Steve!  The other problem I
> encountered is we're using Java 1.4.2...but I think I can convince them
> to upgrade to Java 5 for the FIX servers at least.  Domino effect!

I've committed changes to the related JDBC log and store implementations
to the QFJ SVN trunk. If you need to patch your installation you can see
the files that changed in SVN by looking at the Subversion link in the
JIRA issue (QFJ-295). I'll update the documentation later for the new
setting.

> Intervening on the source code is slightly problematic for upgrades for
> us because we're also using an extended FIX42.xml data dictionary file
> as well (which already requires me to unjar the 42 library and replace
> the data dictionary with our extended version and then re-jar it)...
> that contains the following two additional entries for liquidity for
> Nasdaq and DirectEdge who unfortunately use the same custom liquidity
> tag and for ARCA:

Given the trouble, why do you put the data dictionary in the JAR file?
It will be picked up anywhere in the class path. For example, it could
be in your application JAR or in a well-known location in the file
system. If you name your data dictionary something like FIX42-DirectEdge.xml
then you won't have to worry about accidentally picking up the FIX42.xml
in the QFJ jars.

> <field number="9882" name="INETLiquidity" type="CHAR">
> ...

If you add the attribute allowOtherValues="Y" to your field definition
then you won't have to include the undefined values for validation purposes.
This was added in a recent release (1.3.0, I think, but it might have been
in 1.3.1).

For example...

<field number="9882" name="INETLiquidity" type="CHAR" allowOtherValues="Y">

Regards,

Steve

Re: [Quickfixj-users] acceptor

[Robert B. <rbr...@me...>]

Thanks so much for your help Steve...this is great!

robert l. brueckmann
vice president
merlin securities
712 fifth avenue
new york, ny 10019
p: 212.822.4821
f: 212.822.4820



Merlin Securities - #1 Prime Broker North America and #1 Prime Broker Single Strategy Funds - Global Custodian 2007
#1 Prime Broker for Hedge Funds under $1 Billion - Alpha Survey 2007



From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Steve Bate
Sent: Monday, February 04, 2008 1:17 PM
To: qui...@li...
Subject: Re: [Quickfixj-users] acceptor

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


> Thanks for the quick and thorough reply Steve!  The other problem I
> encountered is we're using Java 1.4.2...but I think I can convince
them
> to upgrade to Java 5 for the FIX servers at least.  Domino effect!

I've committed changes to the related JDBC log and store implementations
to the QFJ SVN trunk. If you need to patch your installation you can see
the files that changed in SVN by looking at the Subversion link in the
JIRA issue (QFJ-295). I'll update the documentation later for the new
setting.

> Intervening on the source code is slightly problematic for upgrades
for
> us because we're also using an extended FIX42.xml data dictionary file
> as well (which already requires me to unjar the 42 library and replace
> the data dictionary with our extended version and then re-jar it)...
> that contains the following two additional entries for liquidity for
> Nasdaq and DirectEdge who unfortunately use the same custom liquidity
> tag and for ARCA:

Given the trouble, why do you put the data dictionary in the JAR file?
It will be picked up anywhere in the class path. For example, it could
be in your application JAR or in a well-known location in the file
system. If you name your data dictionary something like
FIX42-DirectEdge.xml
then you won't have to worry about accidentally picking up the FIX42.xml
in the QFJ jars.

> <field number="9882" name="INETLiquidity" type="CHAR">
> ...

If you add the attribute allowOtherValues="Y" to your field definition
then you won't have to include the undefined values for validation
purposes.
This was added in a recent release (1.3.0, I think, but it might have
been
in 1.3.1).

For example...

<field number="9882" name="INETLiquidity" type="CHAR"
allowOtherValues="Y">

Regards,

Steve



------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
 

--------------------------------------------------------

This message contains information from Merlin Securities, LLC, or from one of its affiliates, that may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify the sender immediately by telephone or by replying to this transmission.
 
Merlin Securities, LLC is a registered broker-dealer. Services offered through Merlin Securities, LLC are not insured by the FDIC or any other Federal Government Agency, are not deposits of or guaranteed by Merlin Securities, LLC and may lose value. Nothing in this communication shall constitute a solicitation or recommendation to buy or sell a particular security.