quickfix-developers — QuickFIX developers forum

[Quickfix-developers] =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_[Quickfix-developers]_Sequence_numbers?= not incrementing

[<ili...@bn...>]

Oren,

Thanks for the quick answer. There is no carriage return in the text field,
but the field didn't appear correctly in my last copy/paste. The correct
value is:

58=Counterparty 'TSCREENBKL' is unknown

Thanks,
Ilyas




Internet
ore...@ya... - 07/11/2003 18:55

Pour : Ilias USAL, quickfix-developers

cc :


Objet :     Re: [Quickfix-developers] Sequence numbers not incrementing


Is there a carraige return in your text field?  I
wonder if it may be having a problem with that.

--- ili...@bn... wrote:
> Hello,
>
> I'm experiencing a very serious problem with the
> last realease of QuickFix. When I send out an
> EXECUTION REPORT with OrderStatus 'REJECTED'
> or an ORDER CANCEL REJECT, the sendToTarget fails,
> and the next message has the exact same sequence
> number, which causes the connection
> to end.
>
> I'm sending the message using
>      if
>
(FIX::Session::sendToTarget(*pc_FixMessage,sessionID))
>       {
>       gc_Program.Log().info("Send msg fix...OK");
>       }
>     else
>       {
>       gc_Program.Log().info("Send msg fix...KO");
>       }
>
> Here's an excerpt of my log file:
>
>       Send application message :
>
>
8=FIX.4.29=31235=834=30749=***52=20031107-15:27:4956=***128=***1=***
>
>
6=0.00000011=030311070000007R14=015=GBp17=20031107152742092320=022=231=0.00000032=0

>
>
37=2368438=20039=840=148=092528854=255=GB000925288258=Counterparty
> is unknown
>
> 59=075=20031107109=100259120=GBp150=8151=20010=188
>       Send msg fix...KO
>       Send HeartBeat SeqNum: 307
>
>
8=FIX.4.29=5435=034=30749=BPEFRTSTEST52=20031107-15:28:4956=TS10=118
>
> The crazy thing is that the message is received at
> the other end of the line.
>
> Did anyone experience the same problem, or better
> yet, does anyone has a solution?
>
> Many thanks,
> Ilyas USAL
>
>
>
>
> This message and any attachments (the "message") is
> intended solely for the addressees and is
> confidential.
> If you receive this message in error, please delete
> it and immediately notify the sender. Any use not in
> accord with
> its purpose, any dissemination or disclosure, either
> whole or partial, is prohibited except formal
> approval.
> The internet can not guarantee the integrity of this
> message. BNP PARIBAS (and its subsidiaries) shall
> (will) not
> therefore be liable for the message if modified.
>
>
> ---------------------------------------------
>
> Ce message et toutes les pieces jointes (ci-apres le
> "message") sont etablis a l'intention exclusive de
> ses
> destinataires et sont confidentiels. Si vous recevez
> ce message par erreur, merci de le detruire et d'en
> avertir
> immediatement l'expediteur. Toute utilisation de ce
> message non conforme a sa destination, toute
> diffusion
> ou toute publication, totale ou partielle, est
> interdite, sauf autorisation expresse. L'internet ne
> permettant pas
> d'assurer l'integrite de ce message, BNP PARIBAS (et
> ses filiales) decline(nt) toute responsabilite au
> titre de ce
> message, dans l'hypothese ou il aurait ete modifie.
>
>
>
>
-------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback
> Program.
> Does SourceForge.net help you be more productive?
> Does it
> help you create better code?   SHARE THE LOVE, and
> help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree







This message and any attachments (the "message") is intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with 
its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. 
The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

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

Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses 
destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir 
immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion 
ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas 
d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce 
message, dans l'hypothese ou il aurait ete modifie.

Re: [Quickfix-developers] Sequence numbers not incrementing

[Oren M. <ore...@ya...>]

Is there a carraige return in your text field?  I
wonder if it may be having a problem with that.

--- ili...@bn... wrote:
> Hello,
> 
> I'm experiencing a very serious problem with the
> last realease of QuickFix. When I send out an
> EXECUTION REPORT with OrderStatus 'REJECTED'
> or an ORDER CANCEL REJECT, the sendToTarget fails,
> and the next message has the exact same sequence
> number, which causes the connection
> to end.
> 
> I'm sending the message using
>      if
>
(FIX::Session::sendToTarget(*pc_FixMessage,sessionID))
>       {
>       gc_Program.Log().info("Send msg fix...OK");
>       }
>     else
>       {
>       gc_Program.Log().info("Send msg fix...KO");
>       }
> 
> Here's an excerpt of my log file:
> 
>       Send application message :
>      
>
8=FIX.4.29=31235=834=30749=***52=20031107-15:27:4956=***128=***1=***
>      
>
6=0.00000011=030311070000007R14=015=GBp17=20031107152742092320=022=231=0.00000032=0
>      
>
37=2368438=20039=840=148=092528854=255=GB000925288258=Counterparty
> is unknown
>      
> 59=075=20031107109=100259120=GBp150=8151=20010=188
>       Send msg fix...KO
>       Send HeartBeat SeqNum: 307
>      
>
8=FIX.4.29=5435=034=30749=BPEFRTSTEST52=20031107-15:28:4956=TS10=118
> 
> The crazy thing is that the message is received at
> the other end of the line.
> 
> Did anyone experience the same problem, or better
> yet, does anyone has a solution?
> 
> Many thanks,
> Ilyas USAL
> 
> 
> 
> 
> This message and any attachments (the "message") is
> intended solely for the addressees and is
> confidential. 
> If you receive this message in error, please delete
> it and immediately notify the sender. Any use not in
> accord with 
> its purpose, any dissemination or disclosure, either
> whole or partial, is prohibited except formal
> approval. 
> The internet can not guarantee the integrity of this
> message. BNP PARIBAS (and its subsidiaries) shall
> (will) not 
> therefore be liable for the message if modified. 
> 
>                
> ---------------------------------------------
> 
> Ce message et toutes les pieces jointes (ci-apres le
> "message") sont etablis a l'intention exclusive de
> ses 
> destinataires et sont confidentiels. Si vous recevez
> ce message par erreur, merci de le detruire et d'en
> avertir 
> immediatement l'expediteur. Toute utilisation de ce
> message non conforme a sa destination, toute
> diffusion 
> ou toute publication, totale ou partielle, est
> interdite, sauf autorisation expresse. L'internet ne
> permettant pas 
> d'assurer l'integrite de ce message, BNP PARIBAS (et
> ses filiales) decline(nt) toute responsabilite au
> titre de ce 
> message, dans l'hypothese ou il aurait ete modifie.
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback
> Program.
> Does SourceForge.net help you be more productive? 
> Does it
> help you create better code?   SHARE THE LOVE, and
> help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

[Quickfix-developers] Sequence numbers not incrementing

[<ili...@bn...>]

Hello,

I'm experiencing a very serious problem with the last realease of QuickFix. When I send out an EXECUTION REPORT with OrderStatus 'REJECTED'
or an ORDER CANCEL REJECT, the sendToTarget fails, and the next message has the exact same sequence number, which causes the connection
to end.

I'm sending the message using
     if (FIX::Session::sendToTarget(*pc_FixMessage,sessionID))
      {
      gc_Program.Log().info("Send msg fix...OK");
      }
    else
      {
      gc_Program.Log().info("Send msg fix...KO");
      }

Here's an excerpt of my log file:

      Send application message :
      8=FIX.4.29=31235=834=30749=***52=20031107-15:27:4956=***128=***1=***
      6=0.00000011=030311070000007R14=015=GBp17=20031107152742092320=022=231=0.00000032=0
      37=2368438=20039=840=148=092528854=255=GB000925288258=Counterparty is unknown
      59=075=20031107109=100259120=GBp150=8151=20010=188
      Send msg fix...KO
      Send HeartBeat SeqNum: 307
      8=FIX.4.29=5435=034=30749=BPEFRTSTEST52=20031107-15:28:4956=TS10=118

The crazy thing is that the message is received at the other end of the line.

Did anyone experience the same problem, or better yet, does anyone has a solution?

Many thanks,
Ilyas USAL




This message and any attachments (the "message") is intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with 
its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. 
The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

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

Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses 
destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir 
immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion 
ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas 
d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce 
message, dans l'hypothese ou il aurait ete modifie.

[Quickfix-developers] re: Duplicate logon attempt handling

[Howard E. <ho...@ex...>]

Unfortunately your the only person who has posted about the problem.  I
was hoping to avoid having to modify the quickfix lib to handle this,
but I will probably end up doing something like your mod.

Thanks,

Howard


Message: 9
Subject: [Quickfix-developers] Duplicate logon attempt handling
Date: Thu, 6 Nov 2003 13:32:54 -0500
From: "Daniel May" <Dan...@ma...>
To: <ho...@ex...>,
        <qui...@li...>

Howard,
        Did any one get back to you on this ?  The current (non
QuickFix) servers I connect to do
not even allow multiple connections from a client app already connected
to a given port, they
block it at the socket connection level.  QuickFix is designed to accept
multiple connections on the same port,
with the Sender,Target, and BeginString being unique for each
session.=20

[Quickfix-developers] Duplicate logon attempt handling

[Daniel M. <Dan...@ma...>]

Howard,
	Did any one get back to you on this ?  The current (non
QuickFix) servers I connect to do
not even allow multiple connections from a client app already connected
to a given port, they
block it at the socket connection level.  QuickFix is designed to accept
multiple connections on the same port,
with the Sender,Target, and BeginString being unique for each session.=20

Here is what the spec says about rejecting a logon:

* The initiator sends a Logon message. The acceptor will authenticate
the identity of the initiator by examining the Logon message. The Logon
message will contain the data necessary to support the previously agreed
upon authentication method. If the initiator is successfully
authenticated, the acceptor responds with a Logon message. If
authentication fails, the session acceptor should shut down the
connection after optionally sending a Logout message to indicate the
reason of failure. Sending a Logout in this case is not required because
doing so would consume a sequence number for that session, which in some
cases may be problematic. The session initiator may begin to send
messages immediately following the Logon message, however, the acceptor
may not be ready to receive them. The initiator must wait for the
confirming Logon message from the acceptor before declaring the session
fully established.


In regards to QuickFix, I made a modification in Acceptor.cpp to reject
any logon message if the session
trying to logon is already logged on:

line:149
    Sessions::iterator i =3D m_sessions.find( sessionID );
    if ( i !=3D m_sessions.end() )
    {
      // we have a logon message, we found a session defined for it,
      // now see if this session isLoggedOn, if so, drop it
	  if(i->second->isLoggedOn())
		return 0;

      i->second->setResponder( &responder );
      return i->second;
    }


Ideally, I would like to send the second session a Logout message with
text in the message explaining why,
but that is a little more complicated.  I have not checked this in, as I
am not sure what Oren thinks of it.


Daniel




Reply-To: ho...@ex...
To: QuickFIX Questions <qui...@li...>
Organization: E-xchange Advantage
Date: Tue, 04 Nov 2003 13:42:30 -0500
Subject: [Quickfix-developers] Duplicate logon attempt handling


--=3D-AsZnvoI7U1AYW73moz1y
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Testing my fix server under the following circumstances seems to put
quickfix into an erratic state.

A user logons on with a SessionId (FIX.4.2:SBI0->SLGM0) and sends in
some orders.

Then that users starts a second logon with the same SessionID.

I never see this second Logon attempt in my App class's fromAdmin or
onLogon overrides, however, my App class does receive the onLogout event
twice (both times with the same SessionID).

Furthermore, the second session is disconnected, however I continue to
see heartbeats being received from the User's First fix client in the
FIX incoming log, however I do not receive these in the fromAdmin
override, and I do not see anything in my FIX outgoing log.

Ideally, in this situation, if I receive a Logon Request for a Session
that I currently belive to be alive, I would like to drop the first
session, and then handle the LogonRequest.=20
If not that, then I'd at least like to be able to Reject the second
logon attempt.  However, since I never receive the fromAdmin it doesn't
seem like there's anything I can do either way.

Any help would be appreciated.

Thanks,

-H


--=3D-AsZnvoI7U1AYW73moz1y
Content-Type: text/html; charset=3Dutf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML>
<HEAD>
  <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
CHARSET=3DUTF-8">
  <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.0.9"> </HEAD> <BODY> =
Testing
my fix server under the following circumstances seems to put quickfix
into an erratic state.<BR> <BR> A user logons on with a SessionId
(FIX.4.2:SBI0-&gt;SLGM0) and sends in some orders.<BR> <BR> Then that
users starts a second logon with the same SessionID.<BR> <BR> I never
see this second Logon attempt in my App class's fromAdmin or onLogon
overrides,<BR> however, my App class does receive the onLogout event
twice (both times with the same SessionID).<BR> <BR> Furthermore, the
second session is disconnected, however I continue to see heartbeats
being received <BR> from the User's First fix client in the FIX incoming
log, however I do not receive these in the <BR> fromAdmin override, and
I do not see anything in my FIX outgoing log.<BR> <BR> Ideally, in this
situation, if I receive a Logon Request for a Session that I currently
belive to be alive, I <BR> would like to drop the first session, and
then handle the LogonRequest.&nbsp; If not that, then I'd at least like
to be<BR> able to Reject the second logon attempt.&nbsp; However, since
I never receive the fromAdmin it doesn't seem like<BR> there's anything
I can do either way.<BR> <BR> Any help would be appreciated.<BR> <BR>
Thanks,<BR> <BR> -H<BR> <BR> </BODY> </HTML>

--=3D-AsZnvoI7U1AYW73moz1y--



--__--__--

Message: 2
From: Brian Egge <Br...@ma...>
To: 'Joerg Thoennes' <Joe...@ma...>, Oren Miller
	 <ore...@ya...>,
"'qui...@li...'"
	 <qui...@li...>
Date: Tue, 4 Nov 2003 15:29:13 -0500
Subject: [Quickfix-developers] Additional test cases for
ParserTestCase::extractLength


In ParserTestCase.h:

class extractLength : public Test
  {
    bool onSetup( Parser*& pObject );
    void onRun( Parser& object );

    std::string m_normalLength;
    std::string m_badLength;
    std::string m_negativeLength;
// New Code Start
    std::string m_incomplete_1;
    std::string m_incomplete_2;
// New Code End
  }

In ParserTestCase.cpp:

bool ParserTestCase::extractLength::onSetup( Parser*& pObject )
{
  m_normalLength =3D3D =3D
"8=3D3DFIX.4.2\0019=3D3D12\00135=3D3DA\001108=3D3D30\00110=3D3D31\001";
  m_badLength =3D3D =3D
"8=3D3DFIX.4.2\0019=3D3DA\00135=3D3DA\001108=3D3D30\00110=3D3D31\001";
  m_negativeLength =3D3D =3D
"8=3D3DFIX.4.2\0019=3D3D-1\00135=3D3DA\001108=3D3D30\00110=3D3D31\001";
// New Code Start
  m_incomplete_1 =3D3D "8=3D3DFIX.4.2";
  m_incomplete_2 =3D3D "8=3D3DFIX.4.2\0019=3D3D12";
// New Code End
  return true;
}

void ParserTestCase::extractLength::onRun( Parser& object )
{
  int length =3D3D 0;
  std::string::size_type pos =3D3D 0;

  assert( object.extractLength(length, pos, m_normalLength) );
  assert( length =3D3D=3D3D 12 );
  assert( pos =3D3D=3D3D 15 );

// Add this line:
	pos =3D3D 0;
  try { object.extractLength(length, pos, m_badLength);
        assert(false); }
  catch( MessageParseError& ) {}

// Add this line:
	assert(pos =3D3D=3D3D 0);
  try { object.extractLength(length, pos, m_negativeLength);
        assert(false); }
  catch( MessageParseError& ) {}

// New Code Start
	assert(pos =3D3D=3D3D 0);
	try {
	assert( object.extractLength(length, pos, m_incomplete_1) =3D3D=3D3D
=3D
false);
	assert(pos =3D3D=3D3D 0); }
	catch( MessageParseError& ) { assert(false) }
=3D09
	try {
	assert( object.extractLength(length, pos, m_incomplete_2) =3D3D=3D3D
=3D
false);
	assert(pos =3D3D=3D3D 0); }
	catch( MessageParseError& ) { assert(false) }
// New Code End

  assert( !object.extractLength(length, pos, "") );
}

-----Original Message-----
From: Joerg Thoennes [mailto:Joe...@ma...]
Sent: Monday, November 03, 2003 11:12 AM
To: Oren Miller
Cc: Brian Egge; 'Miller, Oren';
'qui...@li...'
Subject: Re: [Quickfix-developers] BodyLength or CheckSum missing


Oren Miller wrote:
> Post you're fix to the developers list and someone
> will check it in.  It would be a good idea to update
> the test case to reflect this problem. Do you have a
> test case that will make the old code fail but is
> succesfull with your code?  Something like this will
> allow us to get it into the codebase quicker.  Thanks!

I already thought of checking this in, but was lacking the test case.
So if you have a test case, Brian, I could do the check-in.

Cheers, J=3DF6rg

> --- Brian Egge <Br...@ma...> wrote:
>=3D20
>>I think I have found the problem that is causing
>>this error.  The error only
>>surfaces when the 8=3D3DFix is received, but the
>>9=3D3Dlength has not been.
>>
>>The problem is in Parser.cpp:
>>
>>bool Parser::extractLength( int& length,
>>std::string::size_type& pos,
>>                            const std::string&
>>buffer )
>>throw( MessageParseError& )
>>{ QF_STACK_PUSH(Parser::extractLength)
>>
>>  if( !buffer.size() ) return false;
>> =3D20
>>  std::string::size_type startPos =3D3D buffer.find(
>>"\0019=3D3D", 0 );
>>  if( pos =3D3D=3D3D std::string::npos ) return false;
>>// This should be:
>>//  if( startPos =3D3D=3D3D std::string::npos ) return
>>false;
>>//
>>  startPos +=3D3D 3;
>>  std::string::size_type endPos =3D3D buffer.find(
>>"\001", startPos );
>>// This should be:
>>//  if( endPos =3D3D=3D3D std::string::npos ) return false;
>>//
>>  pos =3D3D endPos + 1;
>>
>>What happens with the current code is strLength gets
>>set to 'FIX.4.x'.  This
>>raises and exception and throws a MessageParseError.
>>
>>I'd like to get this fix checked in to CVS.  I
>>haven't used CVS before, and
>>I don't know who is given access to check in
>>changes.
>>
>>Brian=3D20
>>
>>
>>-----Original Message-----
>>From: Miller, Oren
>>[mailto:OM...@ri...]
>>Sent: Tuesday, October 14, 2003 6:02 PM
>>To: Br...@ma...;
>>qui...@li...
>>Subject: Re: [Quickfix-developers] BodyLength or
>>CheckSum missing
>>
>>
>>Do yo have an example of a message that causes this
>>error?
>>
>>--------------------------
>>Sent from my BlackBerry Wireless Handheld
>>
>>
>>-----Original Message-----
>>From: Brian Egge <Br...@ma...>
>>To: qui...@li...
>><qui...@li...>
>>Sent: Tue Oct 14 10:10:55 2003
>>Subject: [Quickfix-developers] BodyLength or
>>CheckSum missing
>>
>>I seem to be having a problem where I get an
>>InvalidMessage("BodyLength or
>>CheckSum missing") exception thrown from
>>Message::validate().  When I look
>>at my logs, or even re-parse the message, everything
>>is in tact.  I can't
>>see any reason why this exception is being thrown.=3D20
>>I only get this with one
>>venue, and it only happens every couple of days or
>>so.  Has anyone else had
>>this problem before?
>>
>>I've added some more logging to this area, and I
>>think I will figure it out
>>soon.  The item that concerns me more is that this
>>exception does not get
>>handled, and the EH eventually calls terminate() or
>>abort() and the program
>>ends.  I'm using version 1.6, and I have two
>>suggestions.
>>
>>1)  "bool SocketConnection::read( SocketAcceptor& a,
>>SocketServer& s )" has
>>an exception handler, while bool
>>"SocketConnection::read( SocketConnector& s
>>)" does not.  My exception occurs in the latter
>>case.  I copied the
>>exception code from the one read to the other to
>>make them consistent.
>>
>>2)  I added try {} catch(...) statement to the
>>onStart() procedures, to trap
>>any unhanded exceptions.   I'd rather have the
>>thread safely terminate than
>>for my whole app to end.  =3D20
>>
>>If these changes are worthwhile, I'll try to merge
>>them in CVS.=3D20
>>
>>-Brian
>>
>>
>>
>=3D20
> -------------------------------------------------------
>=3D20
>>This SF.net email is sponsored by: SF.net Giveback
>>Program.
>>SourceForge.net hosts over 70,000 Open Source
>>Projects.
>>See the people who have HELPED US provide better
>>services:
>>Click here: http://sourceforge.net/supporters.php
>>_______________________________________________
>>Quickfix-developers mailing list
>>Qui...@li...
>>
>=3D20
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=3D20
>>
>>
> -------------------------------------------------------
>=3D20
>>This SF.net email is sponsored by: SF.net Giveback
>>Program.
>>Does SourceForge.net help you be more productive?=3D20
>>Does it
>>help you create better code?   SHARE THE LOVE, and
>>help us help
>>YOU!  Click Here: http://sourceforge.net/donate/
>>_______________________________________________
>>Quickfix-developers mailing list
>>Qui...@li...
>>
>=3D20
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=3D20
>=3D20
> __________________________________
> Do you Yahoo!?
> Exclusive Video Premiere - Britney Spears
> http://launch.yahoo.com/promos/britneyspears/
>=3D20
>=3D20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=3D20


--=3D20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen


--__--__--

Message: 3
From: Brian Egge <Br...@ma...>
To: "'qui...@li...'"
	 <qui...@li...>
Date: Tue, 4 Nov 2003 15:50:45 -0500=20
Subject: [Quickfix-developers] UtcTimeStamp additions / tests

Recently I've found a need to use the tm_yday member in the struct tm,
used
by the UtcTimeStamp class.

The strptime.c does not calculate or clear this member.

I've added this code at the bottom of strptime.c to calcuate this value:

	char isLeapYear;
	int mon,year;
...
	// Fix up yday field
	year =3D tm->tm_year + 1900;
	isLeapYear =3D (year%4=3D=3D0) - (year%100=3D=3D0) + (year%400=3D=3D0) =
-
(year%4000=3D=3D0);
	mon =3D tm->tm_mon; // 0 =3D=3D January
	tm->tm_yday =3D=20
		(mon>0)*31 + // Jan
		(mon>1)*(28+isLeapYear) + // Feb
		(mon>2)*31 + // March
		(mon>3)*30 + // April
		(mon>4)*31 + // May
		(mon>5)*30 + // June
		(mon>6)*31 + // July
		(mon>7)*31 + // Aug
		(mon>8)*30 + // Sept
		(mon>9)*31 + // Oct
		(mon>10)*30 + // Nov
		+ tm->tm_mday - 1;

In FieldType.h, I've added to the UtcTimeStamp class:

	int getYday() const { return tm_yday + 1; }

and to the UtcDate class:

	int getYday() const { return UtcTimeStamp::getYday(); }

I've added two test cases to FieldConvertsTestCase.cpp:

void FieldConvertorsTestCase::utcTimeStampConvertFrom::onRun( void*& )
{
...
	assert( result.getYday() =3D=3D 117 );
}

void FieldConvertorsTestCase::utcDateConvertFrom::onRun( void*& )
{
...
	assert( result.getYday() =3D=3D 117 );
}

I was not able to contact the author of strptime.c to submit this
addition.




--__--__--

_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


End of Quickfix-developers Digest

Re: [Quickfix-developers] QuickFIX certification

[Oren M. <ore...@ya...>]

I've certified QF on Archipelago, REDIFix, and Bear Stearns.  Arca was done with a really early version like 1.0.3, the other two were certified with 1.6.0.  These destinations all worked without modification to QF.

Joerg Thoennes <Joe...@ma...> wrote:
Hi all,

I would like to ask all users of QuickFIX whether they did some sort of 
official FIX certification of their software and in this way also 
certified the QuickFIX library.

Please provide me with the following information:

1. Who certified the software?
2. Which version of QuickFIX was used?
3. Which modifications to the QuickFIX software had to be done?

Cheers, Jörg

-- 
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

Re: [Quickfix-developers] Additional test cases for ParserTestCase::extractLength

[Joerg T. <Joe...@ma...>]

Hi all,

> I have applied your changes (see attachment) and had to made a minor 
> correction. If compilation and test goes well, they go into CVS tomorrow.

The changes to fix the parsing of tag 9 (BodyLength) are now in the CVS 
repository. The fix worked well for Linux, but I have no other system 
available for the moment. ChangeLog entry:

2003-11-06 17:09  thoennes

     * src/C++/: Parser.cpp, test/ParserTestCase.cpp,
       test/ParserTestCase.h: Fixed parsing of tag 9 (BodyLength): Now
       extractLength returns false if there is no (complete) tag 9 in
       the current buffer.  Submitted by Brian Egge
       <Br...@ma...>.


Please, could anybody with a Windows or a Solaris system check-out, 
compile and test that? We currently have no automatic build system, Oren 
is about to organize that.

Cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

RE: [Quickfix-developers] How to set the plain string value of a field

[Miller, O. <OM...@ri...>]

FieldBase has a method on it called setString.

-----Original Message-----
From: Joerg Thoennes [mailto:Joe...@ma...]=20
Sent: Thursday, November 06, 2003 10:56 AM
To: developers QuickFIX
Subject: [Quickfix-developers] How to set the plain string value of a =
field

Hi there,

I would like to set the untyped string value of a FIX field directly. I=20
know that there is a method in the C++ API, but I could not find it. I=20
would like to add that to the Java API.

Could anybody give me a clue?

Thanks, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] How to set the plain string value of a field

[Joerg T. <Joe...@ma...>]

Hi there,

I would like to set the untyped string value of a FIX field directly. I 
know that there is a method in the C++ API, but I could not find it. I 
would like to add that to the Java API.

Could anybody give me a clue?

Thanks, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-developers] RE: Modification to pass CME Certification

[Rich H. <rh...@st...>]

Joerg,

>platform

We use a combination of Windows and Linux with C++ and Python as the =
languages of choice.

>If we include such a feature, we should make it configurable. What are=20
>the exact problems with ResendRequests? Beginning with 1.6.0, QF uses=20
>ResendRequest to Infinity. This shall fix some race conditions (and=20
>infinite loops) occured with 1.5.0. We also have some issues on=20
>ResendRequest still to be fixed in 1.6.0. Could you give the latest=20
>version (1.6.0) a try and tell me whether is solves your 500 message=20
>problem?

I agree this need to be configurable along with the week long session. =20

I am using 1.6.0.  The problem with the CME is if you send a resend =
request of > 2000 messages they will reject it (they should just send a =
gap fill and be done with it!).  The reject has no context info to know =
that the reject belongs to a resend request (IMO this is a failing with =
the FIX protocol in general).  Since the sequence is still too high, QF =
resends the resend request before even processing the reject.  The CME =
then rejects it, and on and on...  This is a infinite loop that could =
cause huge amounts of data to be exchanged - without any productive work =
and no real way out.  That is why I limited the resend request to 500 =
messages, it prevents this situation from occurring.

Cheers,
Rich


-----Original Message-----
From: Joerg Thoennes [mailto:Joe...@ma...]=20
Sent: Thursday, November 06, 2003 9:00 AM
To: Rich Holm
Cc: developers QuickFIX
Subject: Re: Modification to pass CME Certification

Hi Rich,

> I have since made a few more changes.  I have attached them to this
> message.

I will look at you changes. They will require some extra modifications,
e.g. for the other API (Java, .NET etc). Which operating system and
software do you use with QuickFIX?

> One needed feature is a week long session.  The CME starts you
> session on Monday and ends it Friday.  I haven't had a chance to work
> on this.  For now I just modify the .session file each night.


> If you have any questions on the changes I made, please let me know.
> One thing I hacked was resend requests.  The CME rejects resend
> requests of over 2000 messages which actually causes an infinite loop
> of messages back and forth.  I added a check for this and now request
> a maximum of 500.

If we include such a feature, we should make it configurable. What are=20
the exact problems with ResendRequests? Beginning with 1.6.0, QF uses=20
ResendRequest to Infinity. This shall fix some race conditions (and=20
infinite loops) occured with 1.5.0. We also have some issues on=20
ResendRequest still to be fixed in 1.6.0. Could you give the latest=20
version (1.6.0) a try and tell me whether is solves your 500 message=20
problem?

Cheers, J=F6rg

P.S. I Cc:'ed the developers list since such issues are of interest to
      the other developers, too. So please send your message to this =
list
      everytime it is appropriate. Thanks!

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-developers] Re: Modification to pass CME Certification

[Joerg T. <Joe...@ma...>]

Hi Rich,

> I have since made a few more changes.  I have attached them to this
> message.

I will look at you changes. They will require some extra modifications,
e.g. for the other API (Java, .NET etc). Which operating system and
software do you use with QuickFIX?

> One needed feature is a week long session.  The CME starts you
> session on Monday and ends it Friday.  I haven't had a chance to work
> on this.  For now I just modify the .session file each night.


> If you have any questions on the changes I made, please let me know.
> One thing I hacked was resend requests.  The CME rejects resend
> requests of over 2000 messages which actually causes an infinite loop
> of messages back and forth.  I added a check for this and now request
> a maximum of 500.

If we include such a feature, we should make it configurable. What are 
the exact problems with ResendRequests? Beginning with 1.6.0, QF uses 
ResendRequest to Infinity. This shall fix some race conditions (and 
infinite loops) occured with 1.5.0. We also have some issues on 
ResendRequest still to be fixed in 1.6.0. Could you give the latest 
version (1.6.0) a try and tell me whether is solves your 500 message 
problem?

Cheers, Jörg

P.S. I Cc:'ed the developers list since such issues are of interest to
      the other developers, too. So please send your message to this list
      everytime it is appropriate. Thanks!

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-developers] QuickFIX certification

[Joerg T. <Joe...@ma...>]

Hi all,

I would like to ask all users of QuickFIX whether they did some sort of 
official FIX certification of their software and in this way also 
certified the QuickFIX library.

Please provide me with the following information:

1. Who certified the software?
2. Which version of QuickFIX was used?
3. Which modifications to the QuickFIX software had to be done?

Cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

Re: [Quickfix-developers] Millisecond resolution in UTCTimeStamp

[Joerg T. <Joe...@ma...>]

Daniel May wrote:
> My changes only add milliseconds if the BeginString in the message
> header is >= FIX.4.2 .  
> The old conversion routines do NOT throw an exception if there are
> milliseconds in the time stamp, they just get quietly
> ignored. The call to strptime() was not bothered by them.  My opinion
> would be that anyone talking to a > FIX.4.2 connection
> needs to be prepared to process milliseconds per the specification.
> 
> I will add the configuration setting if you still think it is needed.

IMHO, you should add this option. There are other options (e.g. for out
of order fields) which disable FIX compliant behaviour to cope with the
pecularities of the different FIX engines.

Cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

RE: [Quickfix-developers] Millisecond resolution in UTCTimeStamp

[Miller, O. <OM...@ri...>]

I'd also like to add a configuration setting that can turn on and off =
sending messages with milliseconds.  There may be some fix engines =
people want to talk to (QF 1.0 to 1.6 for instance!) that will not be =
able to handle them.


-----Original Message-----
From:	Daniel May [mailto:Dan...@ma...]
Sent:	Wed 11/5/2003 9:29 AM
To:	qui...@li...
Cc:	Miller, Oren; Joerg Thoennes
Subject:	 [Quickfix-developers] Millisecond resolution in UTCTimeStamp
I have checked in the code changes that allow millisecond time stamp
resolution per the FIX 4.2 and later
specification.  QF will check message headers and include the
milliseconds if the BeginString >=3D FIX.4.2 .
There were several files that needed to be modified, I have listed them
below along with a few caveats concerning
the implementation.

FieldTypes.h and FieldType.cpp
	These files contain the bulk of the code changes.  I added a
private member to the class
FIX::UtcTimeStamp to hold milliseconds, m_ms.  I added a set/get for
access.  When you create
a FIX::UtcTimeStamp, the default has always been to set it to the
current time/date, this remains
the same, and the millisecond field is populated.  I chose to use
ftime() to replace time() since
it returns the time_t structure the original FIX::UtcTimeStamp was
derived from. PLEASE NOTE:  Under
MS Windows (NT,2K,XP), ftime() has at best a resolution of 10ms on a
single processor machine, and 15ms on
a multiple processor machine.


FieldConvertors.h
	When using UtcTimeStampConvertor to convert to a std::string,
there is an optional bool
parameter (default false) which will force the conversion to include
.sss in the string.  When converting
from a std::string to a UtcTimeStamp, I will always parse the
milliseconds if they are present in the
format HH:MM:SS.sss, with some basic validation.  The same holds true
for UtcTimeOnlyConvertor.

Session.cpp
	When setting the SendingTime() field, I check for a BegingString
>=3D BeginString_FIX42, and
include milliseconds.


fieldconvertorstestcase.cpp sessiontestcase.cpp utctimeonlytestcase.cpp
utctimestamptestcase.cpp
	Several of the test cases had to be modified to properly
initialize the milliseconds in UtcTimeStamp.
I also added a test case to verify the conversion routines.
=09

=20
Daniel May
da...@so...

RE: [Quickfix-developers] Millisecond resolution in UTCTimeStamp

[Oren M. <ore...@ya...>]

In my last message "But I'm sure all do" should read
"but I'm not sure all do"

--- Daniel May <Dan...@ma...> wrote:
> My changes only add milliseconds if the BeginString
> in the message
> header is >= FIX.4.2 .  
> The old conversion routines do NOT throw an
> exception if there are
> milliseconds in the time stamp, they just get
> quietly
> ignored. The call to strptime() was not bothered by
> them.  My opinion
> would be that anyone talking to a > FIX.4.2
> connection
> needs to be prepared to process milliseconds per the
> specification.
> 
> I will add the configuration setting if you still
> think it is needed.
> 
> Daniel
> 
> 
> -----Original Message-----
> From: Miller, Oren
> [mailto:OM...@ri...] 
> Sent: Wednesday, November 05, 2003 2:37 PM
> To: Daniel May;
> qui...@li...
> Cc: Joerg Thoennes
> Subject: RE: [Quickfix-developers] Millisecond
> resolution in
> UTCTimeStamp
> 
> I'd also like to add a configuration setting that
> can turn on and off
> sending messages with milliseconds.  There may be
> some fix engines
> people want to talk to (QF 1.0 to 1.6 for instance!)
> that will not be
> able to handle them.
> 
> 
> -----Original Message-----
> From:	Daniel May [mailto:Dan...@ma...]
> Sent:	Wed 11/5/2003 9:29 AM
> To:	qui...@li...
> Cc:	Miller, Oren; Joerg Thoennes
> Subject:	 [Quickfix-developers] Millisecond
> resolution in
> UTCTimeStamp
> I have checked in the code changes that allow
> millisecond time stamp
> resolution per the FIX 4.2 and later specification. 
> QF will check
> message headers and include the milliseconds if the
> BeginString >=
> FIX.4.2 .
> There were several files that needed to be modified,
> I have listed them
> below along with a few caveats concerning the
> implementation.
> 
> FieldTypes.h and FieldType.cpp
> 	These files contain the bulk of the code changes. 
> I added a
> private member to the class FIX::UtcTimeStamp to
> hold milliseconds,
> m_ms.  I added a set/get for access.  When you
> create a
> FIX::UtcTimeStamp, the default has always been to
> set it to the current
> time/date, this remains the same, and the
> millisecond field is
> populated.  I chose to use
> ftime() to replace time() since
> it returns the time_t structure the original
> FIX::UtcTimeStamp was
> derived from. PLEASE NOTE:  Under MS Windows
> (NT,2K,XP), ftime() has at
> best a resolution of 10ms on a single processor
> machine, and 15ms on a
> multiple processor machine.
> 
> 
> FieldConvertors.h
> 	When using UtcTimeStampConvertor to convert to a
> std::string,
> there is an optional bool parameter (default false)
> which will force the
> conversion to include .sss in the string.  When
> converting from a
> std::string to a UtcTimeStamp, I will always parse
> the milliseconds if
> they are present in the format HH:MM:SS.sss, with
> some basic validation.
> The same holds true for UtcTimeOnlyConvertor.
> 
> Session.cpp
> 	When setting the SendingTime() field, I check for a
> BegingString
> >= BeginString_FIX42, and
> include milliseconds.
> 
> 
> fieldconvertorstestcase.cpp sessiontestcase.cpp
> utctimeonlytestcase.cpp
> utctimestamptestcase.cpp
> 	Several of the test cases had to be modified to
> properly
> initialize the milliseconds in UtcTimeStamp.
> I also added a test case to verify the conversion
> routines.
> 	
> 
>  
> Daniel May
> da...@so...
> 
> 
> 
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback
> Program.
> Does SourceForge.net help you be more productive? 
> Does it
> help you create better code?   SHARE THE LOVE, and
> help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

RE: [Quickfix-developers] Millisecond resolution in UTCTimeStamp

[Oren M. <ore...@ya...>]

I agree that any compliant FIX engine should support
it, but I'm sure all do, and most importantly we know
for a fact that earlier versions of QF do not.  If the
milliseconds cannot be turned off, that will create a
problem that version 1.7 of QF will not be able to
talk to earlier versions of QF running running FIX 4.2
or later.

The problem is not whether the new version will throw
an exception, I'm sure it will handle everything find.
 My concern is that when we send a message with
milliseconds, if an earlier version of QF receives
this message it will be rejected.  If we can't turn
off the milliseconds, then systems running different
versions of QF will be unable to communicate.

--- Daniel May <Dan...@ma...> wrote:
> My changes only add milliseconds if the BeginString
> in the message
> header is >= FIX.4.2 .  
> The old conversion routines do NOT throw an
> exception if there are
> milliseconds in the time stamp, they just get
> quietly
> ignored. The call to strptime() was not bothered by
> them.  My opinion
> would be that anyone talking to a > FIX.4.2
> connection
> needs to be prepared to process milliseconds per the
> specification.
> 
> I will add the configuration setting if you still
> think it is needed.
> 
> Daniel
> 
> 
> -----Original Message-----
> From: Miller, Oren
> [mailto:OM...@ri...] 
> Sent: Wednesday, November 05, 2003 2:37 PM
> To: Daniel May;
> qui...@li...
> Cc: Joerg Thoennes
> Subject: RE: [Quickfix-developers] Millisecond
> resolution in
> UTCTimeStamp
> 
> I'd also like to add a configuration setting that
> can turn on and off
> sending messages with milliseconds.  There may be
> some fix engines
> people want to talk to (QF 1.0 to 1.6 for instance!)
> that will not be
> able to handle them.
> 
> 
> -----Original Message-----
> From:	Daniel May [mailto:Dan...@ma...]
> Sent:	Wed 11/5/2003 9:29 AM
> To:	qui...@li...
> Cc:	Miller, Oren; Joerg Thoennes
> Subject:	 [Quickfix-developers] Millisecond
> resolution in
> UTCTimeStamp
> I have checked in the code changes that allow
> millisecond time stamp
> resolution per the FIX 4.2 and later specification. 
> QF will check
> message headers and include the milliseconds if the
> BeginString >=
> FIX.4.2 .
> There were several files that needed to be modified,
> I have listed them
> below along with a few caveats concerning the
> implementation.
> 
> FieldTypes.h and FieldType.cpp
> 	These files contain the bulk of the code changes. 
> I added a
> private member to the class FIX::UtcTimeStamp to
> hold milliseconds,
> m_ms.  I added a set/get for access.  When you
> create a
> FIX::UtcTimeStamp, the default has always been to
> set it to the current
> time/date, this remains the same, and the
> millisecond field is
> populated.  I chose to use
> ftime() to replace time() since
> it returns the time_t structure the original
> FIX::UtcTimeStamp was
> derived from. PLEASE NOTE:  Under MS Windows
> (NT,2K,XP), ftime() has at
> best a resolution of 10ms on a single processor
> machine, and 15ms on a
> multiple processor machine.
> 
> 
> FieldConvertors.h
> 	When using UtcTimeStampConvertor to convert to a
> std::string,
> there is an optional bool parameter (default false)
> which will force the
> conversion to include .sss in the string.  When
> converting from a
> std::string to a UtcTimeStamp, I will always parse
> the milliseconds if
> they are present in the format HH:MM:SS.sss, with
> some basic validation.
> The same holds true for UtcTimeOnlyConvertor.
> 
> Session.cpp
> 	When setting the SendingTime() field, I check for a
> BegingString
> >= BeginString_FIX42, and
> include milliseconds.
> 
> 
> fieldconvertorstestcase.cpp sessiontestcase.cpp
> utctimeonlytestcase.cpp
> utctimestamptestcase.cpp
> 	Several of the test cases had to be modified to
> properly
> initialize the milliseconds in UtcTimeStamp.
> I also added a test case to verify the conversion
> routines.
> 	
> 
>  
> Daniel May
> da...@so...
> 
> 
> 
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback
> Program.
> Does SourceForge.net help you be more productive? 
> Does it
> help you create better code?   SHARE THE LOVE, and
> help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

RE: [Quickfix-developers] Millisecond resolution in UTCTimeStamp

[Daniel M. <Dan...@ma...>]

My changes only add milliseconds if the BeginString in the message
header is >=3D FIX.4.2 . =20
The old conversion routines do NOT throw an exception if there are
milliseconds in the time stamp, they just get quietly
ignored. The call to strptime() was not bothered by them.  My opinion
would be that anyone talking to a > FIX.4.2 connection
needs to be prepared to process milliseconds per the specification.

I will add the configuration setting if you still think it is needed.

Daniel


-----Original Message-----
From: Miller, Oren [mailto:OM...@ri...]=20
Sent: Wednesday, November 05, 2003 2:37 PM
To: Daniel May; qui...@li...
Cc: Joerg Thoennes
Subject: RE: [Quickfix-developers] Millisecond resolution in
UTCTimeStamp

I'd also like to add a configuration setting that can turn on and off
sending messages with milliseconds.  There may be some fix engines
people want to talk to (QF 1.0 to 1.6 for instance!) that will not be
able to handle them.


-----Original Message-----
From:	Daniel May [mailto:Dan...@ma...]
Sent:	Wed 11/5/2003 9:29 AM
To:	qui...@li...
Cc:	Miller, Oren; Joerg Thoennes
Subject:	 [Quickfix-developers] Millisecond resolution in
UTCTimeStamp
I have checked in the code changes that allow millisecond time stamp
resolution per the FIX 4.2 and later specification.  QF will check
message headers and include the milliseconds if the BeginString >=3D
FIX.4.2 .
There were several files that needed to be modified, I have listed them
below along with a few caveats concerning the implementation.

FieldTypes.h and FieldType.cpp
	These files contain the bulk of the code changes.  I added a
private member to the class FIX::UtcTimeStamp to hold milliseconds,
m_ms.  I added a set/get for access.  When you create a
FIX::UtcTimeStamp, the default has always been to set it to the current
time/date, this remains the same, and the millisecond field is
populated.  I chose to use
ftime() to replace time() since
it returns the time_t structure the original FIX::UtcTimeStamp was
derived from. PLEASE NOTE:  Under MS Windows (NT,2K,XP), ftime() has at
best a resolution of 10ms on a single processor machine, and 15ms on a
multiple processor machine.


FieldConvertors.h
	When using UtcTimeStampConvertor to convert to a std::string,
there is an optional bool parameter (default false) which will force the
conversion to include .sss in the string.  When converting from a
std::string to a UtcTimeStamp, I will always parse the milliseconds if
they are present in the format HH:MM:SS.sss, with some basic validation.
The same holds true for UtcTimeOnlyConvertor.

Session.cpp
	When setting the SendingTime() field, I check for a BegingString
>=3D BeginString_FIX42, and
include milliseconds.


fieldconvertorstestcase.cpp sessiontestcase.cpp utctimeonlytestcase.cpp
utctimestamptestcase.cpp
	Several of the test cases had to be modified to properly
initialize the milliseconds in UtcTimeStamp.
I also added a test case to verify the conversion routines.
=09

=20
Daniel May
da...@so...

Re: [Quickfix-developers] Additional test cases for ParserTestCase::extractLength

[Joerg T. <Joe...@ma...>]

Hi Brian,

I have applied your changes (see attachment) and had to made a minor 
correction. If compilation and test goes well, they go into CVS tomorrow.

Cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-developers] Millisecond resolution in UTCTimeStamp

[Daniel M. <Dan...@ma...>]

I have checked in the code changes that allow millisecond time stamp
resolution per the FIX 4.2 and later
specification.  QF will check message headers and include the
milliseconds if the BeginString >=3D FIX.4.2 .
There were several files that needed to be modified, I have listed them
below along with a few caveats concerning
the implementation.

FieldTypes.h and FieldType.cpp
	These files contain the bulk of the code changes.  I added a
private member to the class
FIX::UtcTimeStamp to hold milliseconds, m_ms.  I added a set/get for
access.  When you create
a FIX::UtcTimeStamp, the default has always been to set it to the
current time/date, this remains
the same, and the millisecond field is populated.  I chose to use
ftime() to replace time() since
it returns the time_t structure the original FIX::UtcTimeStamp was
derived from. PLEASE NOTE:  Under
MS Windows (NT,2K,XP), ftime() has at best a resolution of 10ms on a
single processor machine, and 15ms on
a multiple processor machine.


FieldConvertors.h
	When using UtcTimeStampConvertor to convert to a std::string,
there is an optional bool
parameter (default false) which will force the conversion to include
.sss in the string.  When converting
from a std::string to a UtcTimeStamp, I will always parse the
milliseconds if they are present in the
format HH:MM:SS.sss, with some basic validation.  The same holds true
for UtcTimeOnlyConvertor.

Session.cpp
	When setting the SendingTime() field, I check for a BegingString
>=3D BeginString_FIX42, and
include milliseconds.


fieldconvertorstestcase.cpp sessiontestcase.cpp utctimeonlytestcase.cpp
utctimestamptestcase.cpp
	Several of the test cases had to be modified to properly
initialize the milliseconds in UtcTimeStamp.
I also added a test case to verify the conversion routines.
=09

=20
Daniel May
da...@so...

Re: [Quickfix-developers] Missing FieldMap.get/set/removeField in .NET ?

[Miller, O. <OM...@ri...>]

Sorry, no.  I've not yet looked at this and probably won't get a chance =
until tommorw.

--------------------------
Sent from my BlackBerry Wireless Handheld


-----Original Message-----
From: Anton Varn=E4s <va...@kt...>
To: Miller, Oren <OM...@ri...>; =
qui...@li... =
<qui...@li...>
Sent: Wed Nov 05 02:08:45 2003
Subject: Re: [Quickfix-developers] Missing FieldMap.get/set/removeField =
in .NET ?

Oren,

Has this issue been altered?

Best Regards,
Anton Varn=E4s

----- Original Message -----=20
From: "Anton Varn=E4s" <va...@kt...>
Sent: Thursday, October 23, 2003 10:07 AM


Oren,

I am using release 1.6.0 for the moment, but could use any release if =
the features where available in another. ( I have need for at least fix =
4.3, though)

Best Regards,
Anton


----- Original Message -----=20
From: "Miller, Oren" <OM...@ri...>
Sent: Wednesday, October 22, 2003 7:15 PM


Can you specify which version of QF you are using?

-----Original Message-----
From: Anton Varn=E4s [mailto:ant...@sm...]=20
Sent: Wednesday, October 22, 2003 7:14 AM

Hello,

I would like to use the following members in Message/Group (FieldMap) =
with the .NET dll. (with C#)

      void  FieldMap::setField (int field, const std::string value)=20

      std::string  FieldMap::getField (int field) const throw ( =
FieldNotFound& )=20

      void  removeField (int field)=20

      bool  hasGroup (int field) const=20

      int  groupCount (int field) const=20


I cannot find them with the XML completion and my code does not compile. =
How can I use these members?

Best Regards,
Anton Varn=E4s


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Missing FieldMap.get/set/removeField in .NET ?

[<va...@kt...>]

Oren,

Has this issue been altered?

Best Regards,
Anton Varn=E4s

----- Original Message -----=20
From: "Anton Varn=E4s" <va...@kt...>
Sent: Thursday, October 23, 2003 10:07 AM


Oren,

I am using release 1.6.0 for the moment, but could use any release if =
the features where available in another. ( I have need for at least fix =
4.3, though)

Best Regards,
Anton


----- Original Message -----=20
From: "Miller, Oren" <OM...@ri...>
Sent: Wednesday, October 22, 2003 7:15 PM


Can you specify which version of QF you are using?

-----Original Message-----
From: Anton Varn=E4s [mailto:ant...@sm...]=20
Sent: Wednesday, October 22, 2003 7:14 AM

Hello,

I would like to use the following members in Message/Group (FieldMap) =
with the .NET dll. (with C#)

      void  FieldMap::setField (int field, const std::string value)=20

      std::string  FieldMap::getField (int field) const throw ( =
FieldNotFound& )=20

      void  removeField (int field)=20

      bool  hasGroup (int field) const=20

      int  groupCount (int field) const=20


I cannot find them with the XML completion and my code does not compile. =
How can I use these members?

Best Regards,
Anton Varn=E4s


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] UtcTimeStamp additions / tests

[Brian E. <Br...@ma...>]

Recently I've found a need to use the tm_yday member in the struct tm, used
by the UtcTimeStamp class.

The strptime.c does not calculate or clear this member.

I've added this code at the bottom of strptime.c to calcuate this value:

	char isLeapYear;
	int mon,year;
...
	// Fix up yday field
	year = tm->tm_year + 1900;
	isLeapYear = (year%4==0) - (year%100==0) + (year%400==0) -
(year%4000==0);
	mon = tm->tm_mon; // 0 == January
	tm->tm_yday = 
		(mon>0)*31 + // Jan
		(mon>1)*(28+isLeapYear) + // Feb
		(mon>2)*31 + // March
		(mon>3)*30 + // April
		(mon>4)*31 + // May
		(mon>5)*30 + // June
		(mon>6)*31 + // July
		(mon>7)*31 + // Aug
		(mon>8)*30 + // Sept
		(mon>9)*31 + // Oct
		(mon>10)*30 + // Nov
		+ tm->tm_mday - 1;

In FieldType.h, I've added to the UtcTimeStamp class:

	int getYday() const { return tm_yday + 1; }

and to the UtcDate class:

	int getYday() const { return UtcTimeStamp::getYday(); }

I've added two test cases to FieldConvertsTestCase.cpp:

void FieldConvertorsTestCase::utcTimeStampConvertFrom::onRun( void*& )
{
...
	assert( result.getYday() == 117 );
}

void FieldConvertorsTestCase::utcDateConvertFrom::onRun( void*& )
{
...
	assert( result.getYday() == 117 );
}

I was not able to contact the author of strptime.c to submit this addition.

[Quickfix-developers] Additional test cases for ParserTestCase::extractLength

[Brian E. <Br...@ma...>]

In ParserTestCase.h:

class extractLength : public Test
  {
    bool onSetup( Parser*& pObject );
    void onRun( Parser& object );

    std::string m_normalLength;
    std::string m_badLength;
    std::string m_negativeLength;
// New Code Start
    std::string m_incomplete_1;
    std::string m_incomplete_2;
// New Code End
  }

In ParserTestCase.cpp:

bool ParserTestCase::extractLength::onSetup( Parser*& pObject )
{
  m_normalLength =3D =
"8=3DFIX.4.2\0019=3D12\00135=3DA\001108=3D30\00110=3D31\001";
  m_badLength =3D =
"8=3DFIX.4.2\0019=3DA\00135=3DA\001108=3D30\00110=3D31\001";
  m_negativeLength =3D =
"8=3DFIX.4.2\0019=3D-1\00135=3DA\001108=3D30\00110=3D31\001";
// New Code Start
  m_incomplete_1 =3D "8=3DFIX.4.2";
  m_incomplete_2 =3D "8=3DFIX.4.2\0019=3D12";
// New Code End
  return true;
}

void ParserTestCase::extractLength::onRun( Parser& object )
{
  int length =3D 0;
  std::string::size_type pos =3D 0;

  assert( object.extractLength(length, pos, m_normalLength) );
  assert( length =3D=3D 12 );
  assert( pos =3D=3D 15 );

// Add this line:
	pos =3D 0;
  try { object.extractLength(length, pos, m_badLength);
        assert(false); }
  catch( MessageParseError& ) {}

// Add this line:
	assert(pos =3D=3D 0);
  try { object.extractLength(length, pos, m_negativeLength);
        assert(false); }
  catch( MessageParseError& ) {}

// New Code Start
	assert(pos =3D=3D 0);
	try {
	assert( object.extractLength(length, pos, m_incomplete_1) =3D=3D =
false);
	assert(pos =3D=3D 0); }
	catch( MessageParseError& ) { assert(false) }
=09
	try {
	assert( object.extractLength(length, pos, m_incomplete_2) =3D=3D =
false);
	assert(pos =3D=3D 0); }
	catch( MessageParseError& ) { assert(false) }
// New Code End

  assert( !object.extractLength(length, pos, "") );
}

-----Original Message-----
From: Joerg Thoennes [mailto:Joe...@ma...]
Sent: Monday, November 03, 2003 11:12 AM
To: Oren Miller
Cc: Brian Egge; 'Miller, Oren';
'qui...@li...'
Subject: Re: [Quickfix-developers] BodyLength or CheckSum missing


Oren Miller wrote:
> Post you're fix to the developers list and someone
> will check it in.  It would be a good idea to update
> the test case to reflect this problem. Do you have a
> test case that will make the old code fail but is
> succesfull with your code?  Something like this will
> allow us to get it into the codebase quicker.  Thanks!

I already thought of checking this in, but was lacking the test case.
So if you have a test case, Brian, I could do the check-in.

Cheers, J=F6rg

> --- Brian Egge <Br...@ma...> wrote:
>=20
>>I think I have found the problem that is causing
>>this error.  The error only
>>surfaces when the 8=3DFix is received, but the
>>9=3Dlength has not been.
>>
>>The problem is in Parser.cpp:
>>
>>bool Parser::extractLength( int& length,
>>std::string::size_type& pos,
>>                            const std::string&
>>buffer )
>>throw( MessageParseError& )
>>{ QF_STACK_PUSH(Parser::extractLength)
>>
>>  if( !buffer.size() ) return false;
>> =20
>>  std::string::size_type startPos =3D buffer.find(
>>"\0019=3D", 0 );
>>  if( pos =3D=3D std::string::npos ) return false;
>>// This should be:
>>//  if( startPos =3D=3D std::string::npos ) return
>>false;
>>//
>>  startPos +=3D 3;
>>  std::string::size_type endPos =3D buffer.find(
>>"\001", startPos );
>>// This should be:
>>//  if( endPos =3D=3D std::string::npos ) return false;
>>//
>>  pos =3D endPos + 1;
>>
>>What happens with the current code is strLength gets
>>set to 'FIX.4.x'.  This
>>raises and exception and throws a MessageParseError.
>>
>>I'd like to get this fix checked in to CVS.  I
>>haven't used CVS before, and
>>I don't know who is given access to check in
>>changes.
>>
>>Brian=20
>>
>>
>>-----Original Message-----
>>From: Miller, Oren
>>[mailto:OM...@ri...]
>>Sent: Tuesday, October 14, 2003 6:02 PM
>>To: Br...@ma...;
>>qui...@li...
>>Subject: Re: [Quickfix-developers] BodyLength or
>>CheckSum missing
>>
>>
>>Do yo have an example of a message that causes this
>>error?
>>
>>--------------------------
>>Sent from my BlackBerry Wireless Handheld
>>
>>
>>-----Original Message-----
>>From: Brian Egge <Br...@ma...>
>>To: qui...@li...
>><qui...@li...>
>>Sent: Tue Oct 14 10:10:55 2003
>>Subject: [Quickfix-developers] BodyLength or
>>CheckSum missing
>>
>>I seem to be having a problem where I get an
>>InvalidMessage("BodyLength or
>>CheckSum missing") exception thrown from
>>Message::validate().  When I look
>>at my logs, or even re-parse the message, everything
>>is in tact.  I can't
>>see any reason why this exception is being thrown.=20
>>I only get this with one
>>venue, and it only happens every couple of days or
>>so.  Has anyone else had
>>this problem before?
>>
>>I've added some more logging to this area, and I
>>think I will figure it out
>>soon.  The item that concerns me more is that this
>>exception does not get
>>handled, and the EH eventually calls terminate() or
>>abort() and the program
>>ends.  I'm using version 1.6, and I have two
>>suggestions.
>>
>>1)  "bool SocketConnection::read( SocketAcceptor& a,
>>SocketServer& s )" has
>>an exception handler, while bool
>>"SocketConnection::read( SocketConnector& s
>>)" does not.  My exception occurs in the latter
>>case.  I copied the
>>exception code from the one read to the other to
>>make them consistent.
>>
>>2)  I added try {} catch(...) statement to the
>>onStart() procedures, to trap
>>any unhanded exceptions.   I'd rather have the
>>thread safely terminate than
>>for my whole app to end.  =20
>>
>>If these changes are worthwhile, I'll try to merge
>>them in CVS.=20
>>
>>-Brian
>>
>>
>>
>=20
> -------------------------------------------------------
>=20
>>This SF.net email is sponsored by: SF.net Giveback
>>Program.
>>SourceForge.net hosts over 70,000 Open Source
>>Projects.
>>See the people who have HELPED US provide better
>>services:
>>Click here: http://sourceforge.net/supporters.php
>>_______________________________________________
>>Quickfix-developers mailing list
>>Qui...@li...
>>
>=20
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=20
>>
>>
> -------------------------------------------------------
>=20
>>This SF.net email is sponsored by: SF.net Giveback
>>Program.
>>Does SourceForge.net help you be more productive?=20
>>Does it
>>help you create better code?   SHARE THE LOVE, and
>>help us help
>>YOU!  Click Here: http://sourceforge.net/donate/
>>_______________________________________________
>>Quickfix-developers mailing list
>>Qui...@li...
>>
>=20
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=20
>=20
> __________________________________
> Do you Yahoo!?
> Exclusive Video Premiere - Britney Spears
> http://launch.yahoo.com/promos/britneyspears/
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>=20


--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-developers] Duplicate logon attempt handling

[Howard E. <ho...@ex...>]

Testing my fix server under the following circumstances seems to put
quickfix into an erratic state.

A user logons on with a SessionId (FIX.4.2:SBI0->SLGM0) and sends in
some orders.

Then that users starts a second logon with the same SessionID.

I never see this second Logon attempt in my App class's fromAdmin or
onLogon overrides,
however, my App class does receive the onLogout event twice (both times
with the same SessionID).

Furthermore, the second session is disconnected, however I continue to
see heartbeats being received 
from the User's First fix client in the FIX incoming log, however I do
not receive these in the 
fromAdmin override, and I do not see anything in my FIX outgoing log.

Ideally, in this situation, if I receive a Logon Request for a Session
that I currently belive to be alive, I 
would like to drop the first session, and then handle the LogonRequest. 
If not that, then I'd at least like to be
able to Reject the second logon attempt.  However, since I never receive
the fromAdmin it doesn't seem like
there's anything I can do either way.

Any help would be appreciated.

Thanks,

-H

Re: [Quickfix-developers] BodyLength or CheckSum missing

[Joerg T. <Joe...@ma...>]

Oren Miller wrote:
> Post you're fix to the developers list and someone
> will check it in.  It would be a good idea to update
> the test case to reflect this problem. Do you have a
> test case that will make the old code fail but is
> succesfull with your code?  Something like this will
> allow us to get it into the codebase quicker.  Thanks!

I already thought of checking this in, but was lacking the test case.
So if you have a test case, Brian, I could do the check-in.

Cheers, Jörg

> --- Brian Egge <Br...@ma...> wrote:
> 
>>I think I have found the problem that is causing
>>this error.  The error only
>>surfaces when the 8=Fix is received, but the
>>9=length has not been.
>>
>>The problem is in Parser.cpp:
>>
>>bool Parser::extractLength( int& length,
>>std::string::size_type& pos,
>>                            const std::string&
>>buffer )
>>throw( MessageParseError& )
>>{ QF_STACK_PUSH(Parser::extractLength)
>>
>>  if( !buffer.size() ) return false;
>>  
>>  std::string::size_type startPos = buffer.find(
>>"\0019=", 0 );
>>  if( pos == std::string::npos ) return false;
>>// This should be:
>>//  if( startPos == std::string::npos ) return
>>false;
>>//
>>  startPos += 3;
>>  std::string::size_type endPos = buffer.find(
>>"\001", startPos );
>>// This should be:
>>//  if( endPos == std::string::npos ) return false;
>>//
>>  pos = endPos + 1;
>>
>>What happens with the current code is strLength gets
>>set to 'FIX.4.x'.  This
>>raises and exception and throws a MessageParseError.
>>
>>I'd like to get this fix checked in to CVS.  I
>>haven't used CVS before, and
>>I don't know who is given access to check in
>>changes.
>>
>>Brian 
>>
>>
>>-----Original Message-----
>>From: Miller, Oren
>>[mailto:OM...@ri...]
>>Sent: Tuesday, October 14, 2003 6:02 PM
>>To: Br...@ma...;
>>qui...@li...
>>Subject: Re: [Quickfix-developers] BodyLength or
>>CheckSum missing
>>
>>
>>Do yo have an example of a message that causes this
>>error?
>>
>>--------------------------
>>Sent from my BlackBerry Wireless Handheld
>>
>>
>>-----Original Message-----
>>From: Brian Egge <Br...@ma...>
>>To: qui...@li...
>><qui...@li...>
>>Sent: Tue Oct 14 10:10:55 2003
>>Subject: [Quickfix-developers] BodyLength or
>>CheckSum missing
>>
>>I seem to be having a problem where I get an
>>InvalidMessage("BodyLength or
>>CheckSum missing") exception thrown from
>>Message::validate().  When I look
>>at my logs, or even re-parse the message, everything
>>is in tact.  I can't
>>see any reason why this exception is being thrown. 
>>I only get this with one
>>venue, and it only happens every couple of days or
>>so.  Has anyone else had
>>this problem before?
>>
>>I've added some more logging to this area, and I
>>think I will figure it out
>>soon.  The item that concerns me more is that this
>>exception does not get
>>handled, and the EH eventually calls terminate() or
>>abort() and the program
>>ends.  I'm using version 1.6, and I have two
>>suggestions.
>>
>>1)  "bool SocketConnection::read( SocketAcceptor& a,
>>SocketServer& s )" has
>>an exception handler, while bool
>>"SocketConnection::read( SocketConnector& s
>>)" does not.  My exception occurs in the latter
>>case.  I copied the
>>exception code from the one read to the other to
>>make them consistent.
>>
>>2)  I added try {} catch(...) statement to the
>>onStart() procedures, to trap
>>any unhanded exceptions.   I'd rather have the
>>thread safely terminate than
>>for my whole app to end.   
>>
>>If these changes are worthwhile, I'll try to merge
>>them in CVS. 
>>
>>-Brian
>>
>>
>>
> 
> -------------------------------------------------------
> 
>>This SF.net email is sponsored by: SF.net Giveback
>>Program.
>>SourceForge.net hosts over 70,000 Open Source
>>Projects.
>>See the people who have HELPED US provide better
>>services:
>>Click here: http://sourceforge.net/supporters.php
>>_______________________________________________
>>Quickfix-developers mailing list
>>Qui...@li...
>>
> 
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 
>>
>>
> -------------------------------------------------------
> 
>>This SF.net email is sponsored by: SF.net Giveback
>>Program.
>>Does SourceForge.net help you be more productive? 
>>Does it
>>help you create better code?   SHARE THE LOVE, and
>>help us help
>>YOU!  Click Here: http://sourceforge.net/donate/
>>_______________________________________________
>>Quickfix-developers mailing list
>>Qui...@li...
>>
> 
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 
> 
> __________________________________
> Do you Yahoo!?
> Exclusive Video Premiere - Britney Spears
> http://launch.yahoo.com/promos/britneyspears/
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 


-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen