quickfix-developers — QuickFIX developers forum

[Quickfix-developers] Strange error...

[<Sa...@uc...>]

Hello all...

I'm attempting to build a NewOrderSingle message beginning with the
following lines...

==========================================================================
QuickFix42.NewOrderSingle fixord = new QuickFix42.NewOrderSingle() ;
fixord.set( new QuickFix.SenderCompID("SEND"));	//ERROR
fixord.set( new QuickFix.TargetCompID("TARG"));	//ERROR
fixord.set( new QuickFix.SenderSubID("SSID"));	//ERROR
fixord.set( new QuickFix.TargetSubID("TSID"));	//ERROR
fixord.set( new QuickFix.ClOrdID("10001")) ;
fixord.set( new QuickFix.Symbol("IBM")) ;
fixord.set( new QuickFix.Side(QuickFix.Side.BUY)) ;
fixord.set( new QuickFix.OrderQty(100) ;

==========================================================================

The first 4 lines produce errors :
==============================================
error CS1502: The best overloaded method match for
'QuickFix42.NewOrderSingle.set(QuickFix.ClearingAccount)' has some invalid
arguments
error CS1503: Argument '1': cannot convert from 'QuickFix.Field' to
'QuickFix.ClearingAccount'
=============================================

.. Any idea why it would produce these errors??

.. Am I going about this the right way?

Thanks,
Sam

RE: [Quickfix-developers] VB.NET Sample Code

[<Sa...@uc...>]

> -----Original Message-----
> From: Miller, Oren [mailto:OM...@ri...]
> Sent: Wednesday, December 31, 2003 3:50 PM
> To: sa...@uc...; qui...@li...
> Subject: Re: [Quickfix-developers] VB.NET Sample Code
>
>
> It would probably be helpful if you can post your application
> class or project.
>
> --------------------------
> Sent from my BlackBerry Wireless Handheld
>
>

Of course!....

.. here is the class that I hoped would act just like it's C# counterpart in
the "executor" sample code.

'=======================
Imports System
Imports QuickFix

Public Class qf_app
    Inherits QuickFix.MessageCracker
    Implements QuickFix.Application

    Public Sub toApp(ByVal msg As QuickFix.Message, ByVal sid As
QuickFix.SessionID) Implements QuickFix.Application.toApp
    End Sub

    Public Sub fromAdmin(ByVal msg As QuickFix.Message, ByVal sid As
QuickFix.SessionID) Implements QuickFix.Application.fromAdmin
    End Sub

    Public Sub onCreate(ByVal sid As QuickFix.SessionID) Implements
QuickFix.Application.onCreate
    End Sub

    Public Sub onLogon(ByVal sid As QuickFix.SessionID) Implements
QuickFix.Application.onLogon
    End Sub

    Public Sub onLogout(ByVal sid As QuickFix.SessionID) Implements
QuickFix.Application.onLogout
    End Sub

    Public Sub toAdmin(ByVal msg As QuickFix.Message, ByVal sid As
QuickFix.SessionID) Implements QuickFix.Application.toAdmin
    End Sub

    Public Sub fromApp(ByVal msg As QuickFix.Message, ByVal sid As
QuickFix.SessionID) Implements QuickFix.Application.fromApp
    End Sub

End Class
'=======================

... and here is the vb MAIN function
'=======================
Option Strict Off
Option Explicit On
Imports System
Imports QuickFix

	Public Sub Main()


        Try
            Dim settings As New
SessionSettings("d:\QuickFix\cfg\SupMon.cfg")
            Dim app As New qf_app()
            Dim storfact As New FileStoreFactory(settings)
            Dim logfact As New ScreenLogFactory(True, True, True)
            Dim msgfact As New DefaultMessageFactory()
            Dim sckinit As New QuickFix.SocketInitiator(app, storfact,
settings, logfact, msgfact)

            sckinit.start()
            Console.Read()
            sckinit.stop()

        Catch ex As System.Exception
            MessageBox.Show(ex.Message)
        End Try

	End Sub

'=======================

... and finally.. here is the error message I get when I run the
application.  It compiles fine, but then breaks as soon as it begins to
execute.

'=======================
'DefaultDomain': Loaded
'c:\winnt\microsoft.net\framework\v1.0.3705\mscorlib.dll', No symbols
loaded.
'FixRouter': Loaded 'D:\Net
Projects\GBC_R5\FixRouter.NET\bin\FixRouter.exe', Symbols loaded.
'FixRouter.exe': Loaded 'd:\net
projects\gbc_r5\fixrouter.net\bin\quickfix_net_debug.dll', No symbols
loaded.
An unhandled exception of type 'System.TypeLoadException' occurred in
Unknown Module.

Additional information: Signature of the body and declaration in a method
implementation do not match.  Type: FixRouter.qf_app.  Assembly: FixRouter,
Version=4.8.1465.26007, Culture=neutral, PublicKeyToken=null.

The program '[402] FixRouter.exe' has exited with code 0 (0x0).

'=======================

Thanks,

Sam

> -----Original Message-----
> From: Sa...@uc... <sa...@uc...>
> To: qui...@li...
> <qui...@li...>
> Sent: Wed Dec 31 07:41:07 2003
> Subject: [Quickfix-developers] VB.NET Sample Code
>
> Hi all...
>
> I'm a long time VB guy trying to make the jump to the NET environment, and
> use this product at the same time.  ...and I'm not fairing too well.
>
> Would anyone know where I could see some coding examples - using the
> QuickFix classes - done in VB.Net.  I've been trying to reproduce the C#
> example in VB.Net but having no luck.  I tried make a VB version of the
> Application class (inherits messagecracker, implements
> Quickfix.Application).  It compiles fine and then blows up when I run it -
> some crap about me not implementing the interface - it's a lie!
>
> Thanks,
> Sam
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>

Re: [Quickfix-developers] Saving incoming messages: decision point

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

John,
 
I tend to disfavor option number #1.  I can see the same database being shared by counterparties in internal systems.  For instance if an internal client is interacting with an internal server like an orderrouter, someone may make the decision to store everything in a central database.  Reversing the compids would make this difficult.
 
I would prefer #2.  I'm not concerned about the change in format, as these tables are really not designed for long term storage.  They are cleared out at the start of a session anyway, so it is reasonable to have people regenerate the table when upgrading.  Alternately a script can be provided that will convert the previous format to the new one.
 
--oren

John Muehlhausen <jg...@jg...> wrote:

All,

As I mentioned before, we are changing QuickFIX to support optional 
saving of incoming messages to the message store (via config 
parameter).

I see two options when it comes to the MySQLStore implementation:

1) reverse the sender and target IDs and create/update a record with 
that key
2) add another field to the key (messages table) which indicates 
incoming or outgoing

(1) may cause a problem if both sides of a session are using the same 
database-- for example, in testing

(2) involves a schema change which might cause some current users 
problems when upgrading to a future QuickFIX release that has this 
feature

Does anyone have a preference? I'm inclined to go with (1)...

Thanks,
John

PS-- the motivation for this is to help in applications that actually 
use the message store for other processing, such as in generation of 
OATS reports and for other audit procedures. I'm not sure that I want 
to use the MySQL log facility for this since it involves writing 
outbound messages to the database twice (= performance hit)... and 
could result in more than one entry per sequence number (= dups).



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

---------------------------------
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003

RE: [Quickfix-developers] VB.NET Sample Code

[Vitor C. <vc...@hi...>]

Hello Sam,

What version of QF are you using? Some earlier versions had some =
Namespace
naming problems when used in VB.Net.

Regards=20


Vitor Castro | DIS
<mailto:vc...@hi...>

=20

.............  .............

Beloura Office Park - ed. 7 - 1=BA =95 2710-444  Sintra - Portugal=20

Tel: 21 910 92 00 / Fax: 21 924 11 38 =95 URL: www.hiperbit.pt

=85.......................................................

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Sa...@uc...
Sent: quarta-feira, 31 de Dezembro de 2003 13:41
To: qui...@li...
Subject: [Quickfix-developers] VB.NET Sample Code

Hi all...

I'm a long time VB guy trying to make the jump to the NET environment, =
and
use this product at the same time.  ...and I'm not fairing too well.

Would anyone know where I could see some coding examples - using the
QuickFix classes - done in VB.Net.  I've been trying to reproduce the C#
example in VB.Net but having no luck.  I tried make a VB version of the
Application class (inherits messagecracker, implements
Quickfix.Application).  It compiles fine and then blows up when I run it =
-
some crap about me not implementing the interface - it's a lie!

Thanks,
Sam



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

RE: [Quickfix-developers] VB.NET Sample Code

[Vitor C. <vc...@hi...>]

Hello Sam,

What version of QF are you using? Some earlier versions had some =
Namespace
naming problems when used in VB.Net.

Regards=20


Vitor Castro | DIS
<mailto:vc...@hi...>

=20

.............  .............

Beloura Office Park - ed. 7 - 1=BA =95 2710-444  Sintra - Portugal=20

Tel: 21 910 92 00 / Fax: 21 924 11 38 =95 URL: www.hiperbit.pt

=85.......................................................

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Sa...@uc...
Sent: quarta-feira, 31 de Dezembro de 2003 13:41
To: qui...@li...
Subject: [Quickfix-developers] VB.NET Sample Code

Hi all...

I'm a long time VB guy trying to make the jump to the NET environment, =
and
use this product at the same time.  ...and I'm not fairing too well.

Would anyone know where I could see some coding examples - using the
QuickFix classes - done in VB.Net.  I've been trying to reproduce the C#
example in VB.Net but having no luck.  I tried make a VB version of the
Application class (inherits messagecracker, implements
Quickfix.Application).  It compiles fine and then blows up when I run it =
-
some crap about me not implementing the interface - it's a lie!

Thanks,
Sam



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] Saving incoming messages: decision point

[John M. <jg...@jg...>]

All,

As I mentioned before, we are changing QuickFIX to support optional 
saving of incoming messages to the message store (via config 
parameter).

I see two options when it comes to the MySQLStore implementation:

1) reverse the sender and target IDs and create/update a record with 
that key
2) add another field to the key (messages table) which indicates 
incoming or outgoing

(1) may cause a problem if both sides of a session are using the same 
database-- for example, in testing

(2) involves a schema change which might cause some current users 
problems when upgrading to a future QuickFIX release that has this 
feature

Does anyone have a preference?  I'm inclined to go with (1)...

Thanks,
John

PS-- the motivation for this is to help in applications that actually 
use the message store for other processing, such as in generation of 
OATS reports and for other audit procedures.  I'm not sure that I want 
to use the MySQL log facility for this since it involves writing 
outbound messages to the database twice (= performance hit)... and 
could result in more than one entry per sequence number (= dups).

[Quickfix-developers] "quickfix/" needed in #include ?

[John M. <jg...@jg...>]

Regarding both the current CVS and 1.6 release on Solaris 9 (gcc 3.3):

It seems like at some point a change was made from #include <file.h> to 
#include <quickfix/file.h> in certain contexts.

This change was apparently not reflected in the following files, unless 
I am missing something:

src/java/org_quickfix_MySQLStoreFactory.cpp
src/java/org_quickfix_MySQLStore.cpp
src/java/org_quickfix_MySQLLogFactory.cpp
src/java/org_quickfix_MySQLLog.cpp

Does the auto-build cover "--with-mysql" and Java?

-John

Re: [Quickfix-developers] VB.NET Sample Code

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

It would probably be helpful if you can post your application class or =
project.

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


-----Original Message-----
From: Sa...@uc... <sa...@uc...>
To: qui...@li... =
<qui...@li...>
Sent: Wed Dec 31 07:41:07 2003
Subject: [Quickfix-developers] VB.NET Sample Code

Hi all...

I'm a long time VB guy trying to make the jump to the NET environment, =
and
use this product at the same time.  ...and I'm not fairing too well.

Would anyone know where I could see some coding examples - using the
QuickFix classes - done in VB.Net.  I've been trying to reproduce the C#
example in VB.Net but having no luck.  I tried make a VB version of the
Application class (inherits messagecracker, implements
Quickfix.Application).  It compiles fine and then blows up when I run it =
-
some crap about me not implementing the interface - it's a lie!

Thanks,
Sam



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for =
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys =
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] Mapping OrderCapacity+OrderRestrictions -> Rule80A

[Caleb E. <ca...@bk...>]

	Has anyone put together a table to map from the combination of
	OrderCapacity + OrderRestrictions (FIX 4.4 I think) to Rule80A
	codes?  I'm trying to avoid this tedious exercise myself and
	hoping someone out there has done it first :)

-- 
Caleb Epstein |  bklyn . org  | You seek to shield those you love and you like
    cae at    | Brooklyn Dust | the role of the provider.
bklyn dot org |   Bunny Mfg.  |

[Quickfix-developers] VB.NET Sample Code

[<Sa...@uc...>]

Hi all...

I'm a long time VB guy trying to make the jump to the NET environment, and
use this product at the same time.  ...and I'm not fairing too well.

Would anyone know where I could see some coding examples - using the
QuickFix classes - done in VB.Net.  I've been trying to reproduce the C#
example in VB.Net but having no luck.  I tried make a VB version of the
Application class (inherits messagecracker, implements
Quickfix.Application).  It compiles fine and then blows up when I run it -
some crap about me not implementing the interface - it's a lie!

Thanks,
Sam

[Quickfix-developers] Re: All timestamps, including DB

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

The current CVS quickfix version (soon to be 1.7.0) has support for
milliseconds in timestamps. You must set the=20
config setting MillisecondsInTimeStamp=3DY, and it will only add
milliseconds to the SendingTime field
if the message header is FIX.4.2 or greater.=20
If you want to simply generate a UtcTimeStamp and format it with
milliseconds for
your own use other than the SendingTime field in a FIX message, you do
not need to set the
MillisecondsInTimeStamp config.  The UtcTimeStampConvertor() allows you
to control this:

	UtcTimeStamp now;
	std::cout << "With Milliseconds " <<
UtcTimeStampConvertor::convert(now,true) << std::endl;=20
	std::cout << "Without Milliseconds " <<
UtcTimeStampConvertor::convert(now,false) << std::endl; =20
      std::cout << "Without Milliseconds " <<
UtcTimeStampConvertor::convert(now) << std::endl; =20

When I made the changes, I used ftime(), which under WIN32 only has a
resolution of
10ms on a single processor, or 15ms on a multiprocessor machine.  This
precision has been well documented
by Microsoft, so I will not get into the details here.  I do not know
how ftime() is implemented in
the *nix, or what the precision is.  There are of course higher
microsecond resolution timers in
WIN32 (GetPerformanceCounter) but these can not be easily converted to
the actual time of day.


Daniel


--__--__--

Message: 2
From: "Dr. David A. Janello" <dja...@ar...>
To: John Muehlhausen <jg...@jg...>, John Muehlhausen <jg...@jg...>
Cc: Evan Price <ep...@ra...>,
<qui...@li...>,
        Mike Eichin <mi...@ra...>, David Janello
<dja...@ar...>,
        George Thiruvathukal <gj...@ra...>
Date: Mon, 22 Dec 2003 13:33:06 -0500 (EST)
Subject: [Quickfix-developers] Re: All timestamps, including DB


The default for the Available Shares Service is to use hundredths, let
me know if this is a good unit to use for the sub-second interval.

Hyperfeed uses this so hundredths makes sense.

--Dave


---- John Muehlhausen <jg...@jg...> wrote:
>=20
> As a follow-on to this, I want to put the sub-seconds in every FIX=20
> message that we generate.
>=20
> I think that is supported in later FIX versions, otherwise we use a=20
> custom tag.
>=20
> On Dec 20, 2003, at 7:31 PM, John Muehlhausen wrote:
>=20
> >
> > All, just a reminder that ALL timestamps must be in sub-seconds,=20
> > including all MySQL records.
> >
> > We are going to be selling stock a split second after we buy it and=20
> > we need to be able to prove that if it ever comes up.
> >
> > -John
> >
>=20
>=20
>=20

RE: [Quickfix-developers] build problems.

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

QXJlIHlvdSBhYmxlIHRvIGJvb3RzdHJhcC9jb25maWd1cmUvbWFrZSB0aGUgbWFpbiBRRiBzb3Vy
Y2U/ICBEb2VzIHRoaXMgcHJvYmxlbSBvbmx5IG9jY3VyIHdoZW4geW91IGJ1aWxkIHRoZSBleGFt
cGxlcz8NCiANCi0tb3Jlbg0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTog
YmFsYWppLnNyaW5pdmFzYW5AdWJzLmNvbSBbbWFpbHRvOmJhbGFqaS5zcmluaXZhc2FuQHVicy5j
b21dIA0KCVNlbnQ6IFdlZCAxMi8yNC8yMDAzIDk6MDMgQU0gDQoJVG86IHF1aWNrZml4LWRldmVs
b3BlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCUNjOiANCglTdWJqZWN0OiBbUXVpY2tmaXgt
ZGV2ZWxvcGVyc10gYnVpbGQgcHJvYmxlbXMuDQoJDQoJDQoNCglGb2xrcywgDQoJICAgICAgICBJ
IGhhdmUgdGhlIGZvbGxvd2luZyBwcm9ibGVtIHdoZW4gSSBydW4gYm9vdHN0cmFwIGZyb20gdGhl
IGV4YW1wbGVzIGRpcmVjdG9yeS4gDQoJTXkgdmVyc2lvbiBvZiBhdXRvaGVhZGVyIGlzIDIuNTcs
IHRoZSB2ZXJzaW9uIG9mIGFjbG9jYWwgYW5kIGF1dG9tYWtlIGlzIDEuNy42LiANCg0KCTx4c3Rt
OTg2OWRhcC8+IC4vYm9vdHN0cmFwICANCglhdXRvaGVhZGVyLi4uIA0KCWF1dG9oZWFkZXI6IGVy
cm9yOiBBQ19DT05GSUdfSEVBREVSUyBub3QgZm91bmQgaW4gY29uZmlndXJlLmluIA0KCWxpYnRv
b2xpemUuLi4gDQoJYWNsb2NhbC4uLiANCglhY2xvY2FsOiBjb25maWd1cmUuaW46IDY6IG1hY3Jv
IGBBTV9ESVNBQkxFX1NUQVRJQycgbm90IGZvdW5kIGluIGxpYnJhcnkgDQoJYWNsb2NhbDogY29u
ZmlndXJlLmluOiAxNDogbWFjcm8gYEFNX1BST0dfTElCVE9PTCcgbm90IGZvdW5kIGluIGxpYnJh
cnkgDQoJYXV0b21ha2UuLi4gDQoJY29uZmlndXJlLmluOiBubyBwcm9wZXIgaW52b2NhdGlvbiBv
ZiBBTV9JTklUX0FVVE9NQUtFIHdhcyBmb3VuZC4gDQoJY29uZmlndXJlLmluOiBZb3Ugc2hvdWxk
IHZlcmlmeSB0aGF0IGNvbmZpZ3VyZS5pbiBpbnZva2VzIEFNX0lOSVRfQVVUT01BS0UsIA0KCWNv
bmZpZ3VyZS5pbjogdGhhdCBhY2xvY2FsLm00IGlzIHByZXNlbnQgaW4gdGhlIHRvcC1sZXZlbCBk
aXJlY3RvcnksIA0KCWNvbmZpZ3VyZS5pbjogYW5kIHRoYXQgYWNsb2NhbC5tNCB3YXMgcmVjZW50
bHkgcmVnZW5lcmF0ZWQgKHVzaW5nIGFjbG9jYWwpLiANCgkvUHJvZ3JhbVRyYWRpbmcvZDEwL3Jo
NzJfZ2NjMzIxL3NoYXJlL2F1dG9tYWtlLTEuNy9hbS9kZXBlbmQyLmFtOiBhbV9fZmFzdGRlcENY
WCBkb2VzIG5vdCBhcHBlYXIgaW4gQU1fQ09ORElUSU9OQUwgDQoJL1Byb2dyYW1UcmFkaW5nL2Qx
MC9yaDcyX2djYzMyMS9zaGFyZS9hdXRvbWFrZS0xLjcvYW0vZGVwZW5kMi5hbTogQU1ERVAgZG9l
cyBub3QgYXBwZWFyIGluIEFNX0NPTkRJVElPTkFMIA0KCS9Qcm9ncmFtVHJhZGluZy9kMTAvcmg3
Ml9nY2MzMjEvc2hhcmUvYXV0b21ha2UtMS43L2FtL2RlcGVuZDIuYW06IGFtX19mYXN0ZGVwQ1hY
IGRvZXMgbm90IGFwcGVhciBpbiBBTV9DT05ESVRJT05BTCANCgkvUHJvZ3JhbVRyYWRpbmcvZDEw
L3JoNzJfZ2NjMzIxL3NoYXJlL2F1dG9tYWtlLTEuNy9hbS9kZXBlbmQyLmFtOiBBTURFUCBkb2Vz
IG5vdCBhcHBlYXIgaW4gQU1fQ09ORElUSU9OQUwgDQoJL1Byb2dyYW1UcmFkaW5nL2QxMC9yaDcy
X2djYzMyMS9zaGFyZS9hdXRvbWFrZS0xLjcvYW0vZGVwZW5kMi5hbTogYW1fX2Zhc3RkZXBDWFgg
ZG9lcyBub3QgYXBwZWFyIGluIEFNX0NPTkRJVElPTkFMIA0KCS9Qcm9ncmFtVHJhZGluZy9kMTAv
cmg3Ml9nY2MzMjEvc2hhcmUvYXV0b21ha2UtMS43L2FtL2RlcGVuZDIuYW06IEFNREVQIGRvZXMg
bm90IGFwcGVhciBpbiBBTV9DT05ESVRJT05BTCANCgkvUHJvZ3JhbVRyYWRpbmcvZDEwL3JoNzJf
Z2NjMzIxL3NoYXJlL2F1dG9tYWtlLTEuNy9hbS9kZXBlbmQyLmFtOiBhbV9fZmFzdGRlcENYWCBk
b2VzIG5vdCBhcHBlYXIgaW4gQU1fQ09ORElUSU9OQUwgDQoJL1Byb2dyYW1UcmFkaW5nL2QxMC9y
aDcyX2djYzMyMS9zaGFyZS9hdXRvbWFrZS0xLjcvYW0vZGVwZW5kMi5hbTogQU1ERVAgZG9lcyBu
b3QgYXBwZWFyIGluIEFNX0NPTkRJVElPTkFMIA0KCWF1dG9jb25mLi4uIA0KCU5vdyBydW4gY29u
ZmlndXJlIHdpdGggYW55IGFyZ3VtZW50cyBuZWNlc3NhcnkgDQoNCgkgICAgICAgIFN1YnNlcXVl
bnRseSB3aGVuIEkgcnVuIGNvbmZpZ3VyZSBhbmQgbWFrZSwgbWFrZSBmYWlscyBzYXlpbmcgQXBw
bGljYXRpb24uUG8gYW5kIHRyYWRlY2xpZW50LlBvIGlzIG1pc3NpbmcuIA0KCUFueSBoZWxwIHdv
dWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuIA0KDQoJdGhhbmtzIA0KCS1CYWxhamkgU3JpbnZp
YXNhbiANCg0KDQoJVGhpcyBtYXRlcmlhbCBoYXMgYmVlbiBwcmVwYXJlZCBieSBVQlMgQUcgb3Ig
YW4gYWZmaWxpYXRlIHRoZXJlb2YgDQoJKCJVQlMiKS4gVGhpcyBtYXRlcmlhbCBpcyBhIHNhbGVz
IGFuZCB0cmFkaW5nIGNvbW11bmljYXRpb24gYW5kIHNob3VsZCANCglub3QgYmUgdmlld2VkIGFz
IHJlc2VhcmNoLiBPcGluaW9ucyBleHByZXNzZWQgaGVyZWluIGFyZSBzdWJqZWN0IHRvIA0KCWNo
YW5nZSB3aXRob3V0IG5vdGljZSBhbmQgbWF5IGRpZmZlciBvciBiZSBjb250cmFyeSB0byB0aGUg
b3BpbmlvbnMgb3IgDQoJcmVjb21tZW5kYXRpb25zIG9mIFVCUyBJbnZlc3RtZW50IHJlc2VhcmNo
IG9yIHRoZSBvcGluaW9ucyBleHByZXNzZWQgDQoJYnkgb3RoZXIgYnVzaW5lc3MgYXJlYXMgb3Ig
Z3JvdXBzIG9mIFVCUyBhcyBhIHJlc3VsdCBvZiB1c2luZyANCglkaWZmZXJlbnQgYXNzdW1wdGlv
bnMgYW5kIGNyaXRlcmlhLiBGdWxsIGRldGFpbHMgb2YgVUJTIEludmVzdG1lbnQgDQoJUmVzZWFy
Y2gsIGlmIGFueSwgYXJlIGF2YWlsYWJsZSBvbiByZXF1ZXN0LiBBbnkgcHJpY2VzIG9yIHF1b3Rh
dGlvbnMgDQoJY29udGFpbmVkIGhlcmVpbiBhcmUgaW5kaWNhdGl2ZSBvbmx5IGFuZCBkbyBub3Qg
Y29uc3RpdHV0ZSBhbiBvZmZlciB0byANCglidXkgb3Igc2VsbCBhbnkgc2VjdXJpdGllcyBhdCBh
bnkgZ2l2ZW4gcHJpY2UuIE5vIHJlcHJlc2VudGF0aW9uIG9yIA0KCXdhcnJhbnR5LCBlaXRoZXIg
ZXhwcmVzcyBvciBpbXBsaWVkLCBpcyBwcm92aWRlZCBpbiByZWxhdGlvbiB0byB0aGUgDQoJYWNj
dXJhY3ksIGNvbXBsZXRlbmVzcywgcmVsaWFiaWxpdHkgb3IgYXBwcm9wcmlhdGVuZXNzIG9mIHRo
ZSANCglpbmZvcm1hdGlvbiwgbWV0aG9kb2xvZ3kgYW5kIGFueSBkZXJpdmVkIHByaWNlIGNvbnRh
aW5lZCB3aXRoaW4gdGhpcyANCgltYXRlcmlhbC4gVGhlIHNlY3VyaXRpZXMgYW5kIHJlbGF0ZWQg
ZmluYW5jaWFsIGluc3RydW1lbnRzIGRlc2NyaWJlZCANCgloZXJlaW4gbWF5IG5vdCBiZSBlbGln
aWJsZSBmb3Igc2FsZSBpbiBhbGwganVyaXNkaWN0aW9ucyBvciB0byBjZXJ0YWluIA0KCWNhdGVn
b3JpZXMgb2YgaW52ZXN0b3JzLiBPcHRpb25zLCBkZXJpdmF0aXZlIHByb2R1Y3RzIGFuZCBmdXR1
cmVzIGFyZSANCglub3Qgc3VpdGFibGUgZm9yIGFsbCBpbnZlc3RvcnMsIGFuZCB0cmFkaW5nIGlu
IHRoZXNlIGluc3RydW1lbnRzIGlzIA0KCWNvbnNpZGVyZWQgcmlza3kuIFBhc3QgcGVyZm9ybWFu
Y2UgaXMgbm90IG5lY2Vzc2FyaWx5IGluZGljYXRpdmUgb2YgDQoJZnV0dXJlIHJlc3VsdHMuIEZv
cmVpZ24gY3VycmVuY3kgcmF0ZXMgb2YgZXhjaGFuZ2UgbWF5IGFkdmVyc2VseSANCglhZmZlY3Qg
dGhlIHZhbHVlLCBwcmljZSBvciBpbmNvbWUgb2YgYW55IHNlY3VyaXR5IG9yIHJlbGF0ZWQgDQoJ
aW5zdHJ1bWVudCBtZW50aW9uZWQgaW4gdGhpcyByZXBvcnQuIFVCUywgaXRzIGRpcmVjdG9ycywg
b2ZmaWNlcnMgYW5kIA0KCWVtcGxveWVlcyBvciBjbGllbnRzIG1heSBoYXZlIG9yIGhhdmUgaGFk
IGludGVyZXN0cyBvciBsb25nIG9yIHNob3J0IA0KCXBvc2l0aW9ucyBpbiB0aGUgc2VjdXJpdGll
cyBvciByZWxhdGVkIGZpbmFuY2lhbCBpbnN0cnVtZW50cyByZWZlcnJlZCANCgl0byBoZXJlaW4s
IGFuZCBtYXkgYXQgYW55IHRpbWUgbWFrZSBwdXJjaGFzZXMgYW5kL29yIHNhbGVzIGluIHRoZW0g
YXMgDQoJcHJpbmNpcGFsIG9yIGFnZW50LiBVQlMgbWF5IHByb3ZpZGUgaW52ZXN0bWVudCBiYW5r
aW5nIGFuZCBvdGhlciANCglzZXJ2aWNlcyB0byBhbmQvb3Igc2VydmUgYXMgZGlyZWN0b3JzIG9m
IHRoZSBjb21wYW5pZXMgcmVmZXJyZWQgdG8gaW4gDQoJdGhpcyBtYXRlcmlhbC4gTmVpdGhlciBV
QlMgaXRzIGRpcmVjdG9ycywgZW1wbG95ZWVzIG9yIGFnZW50cyBhY2NlcHQgDQoJYW55IGxpYWJp
bGl0eSBmb3IgYW55IGxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgb3V0IG9mIHRoZSB1c2Ugb2YgYWxs
IG9yIA0KCWFueSBwYXJ0IG9mIHRoZXNlIG1hdGVyaWFscy4gVGhpcyBtYXRlcmlhbCBpcyBkaXN0
cmlidXRlZCBpbiB0aGUgDQoJZm9sbG93aW5nIGp1cmlzZGljdGlvbnMgYnk6IFVuaXRlZCBLaW5n
ZG9tOiBVQlMgTGltaXRlZCwgYSBzdWJzaWRpYXJ5IA0KCW9mIFVCUyBBRywgdG8gcGVyc29ucyB3
aG8gYXJlIG1hcmtldCBjb3VudGVycGFydGllcyBvciBpbnRlcm1lZGlhdGUgDQoJY3VzdG9tZXJz
IChhcyBkZXRhaWxlZCBpbiB0aGUgRlNBIFJ1bGVzKSBhbmQgaXMgb25seSBhdmFpbGFibGUgdG8g
c3VjaCANCglwZXJzb25zLiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBkb2VzIG5v
dCBhcHBseSB0bywgYW5kIA0KCXNob3VsZCBub3QgYmUgcmVsaWVkIHVwb24gYnksIHByaXZhdGUg
Y3VzdG9tZXJzLiBTd2l0emVybGFuZDogVUJTIEFHIA0KCXRvIGluc3RpdHV0aW9uYWwgaW52ZXN0
b3JzIG9ubHkuIEl0YWx5OiBHaXViZXJnaWEgVUJTIFNJTSBTcEEsIGFuIA0KCWFzc29jaWF0ZSBv
ZiBVQlMgU0EsIGluIE1pbGFuLiBVUzogVUJTIFNlY3VyaXRpZXMgTExDIG9yIFVCUyBGaW5hbmNp
YWwgDQoJU2VydmljZXMgSW5jLiwgc3Vic2lkaWFyaWVzIG9mIFVCUyBBRywgb3Igc29sZWx5IHRv
IFVTIGluc3RpdHV0aW9uYWwgDQoJaW52ZXN0b3JzIGJ5IFVCUyBBRyBvciBhIHN1YnNpZGlhcnkg
b3IgYWZmaWxpYXRlIHRoZXJlb2YgdGhhdCBpcyBub3QgDQoJcmVnaXN0ZXJlZCBhcyBhIFVTIGJy
b2tlci1kZWFsZXIgKGEgIm5vbi1VUyBhZmZpbGlhdGUiKS4gVHJhbnNhY3Rpb25zIA0KCXJlc3Vs
dGluZyBmcm9tIG1hdGVyaWFscyBkaXN0cmlidXRlZCBieSBhIG5vbi1VUyBhZmZpbGlhdGUgbXVz
dCBiZSANCgllZmZlY3RlZCB0aHJvdWdoIFVCUyBTZWN1cml0aWVzIExMQyBvciBVQlMgRmluYW5j
aWFsIFNlcnZpY2VzIEluYy4gDQoJQ2FuYWRhOiBVQlMgU2VjdXJpdGllcyBDYW5hZGEgSW5jLiwg
YSBzdWJzaWRpYXJ5IG9mIFVCUyBBRyBhbmQgYSANCgltZW1iZXIgb2YgdGhlIHByaW5jaXBhbCBD
YW5hZGlhbiBzdG9jayBleGNoYW5nZXMgJiBDSVBGLiBKYXBhbjogVUJTIA0KCVNlY3VyaXRpZXMg
SmFwYW4gTHRkIG9yIFVCUyBBRywgVG9reW8gQnJhbmNoLCB0byBpbnN0aXR1dGlvbmFsIA0KCWlu
dmVzdG9ycyBvbmx5LiBIb25nIEtvbmc6IFVCUyBTZWN1cml0aWVzIEFzaWEgTGltaXRlZCBvciBV
QlMgQUcsIEhvbmcgDQoJS29uZyBCcmFuY2guIFNpbmdhcG9yZTogVUJTIFNlY3VyaXRpZXMgU2lu
Z2Fwb3JlIFB0ZS4gTHRkIG9yIFVCUyBBRywgDQoJU2luZ2Fwb3JlIEJyYW5jaC4gQXVzdHJhbGlh
OiBVQlMgQWR2aXNvcnkgYW5kIENhcGl0YWwgTWFya2V0cyANCglBdXN0cmFsaWEgTHRkIGFuZCBV
QlMgU2VjdXJpdGllcyBBdXN0cmFsaWEgTHRkLiBGb3IgYWRkaXRpb25hbCANCglpbmZvcm1hdGlv
biBvciB0cmFkZSBleGVjdXRpb24gcGxlYXNlIGNvbnRhY3QgeW91ciBsb2NhbCBzYWxlcyBvciAN
Cgl0cmFkaW5nIGNvbnRhY3QuIA0KDQoJQ29weXJpZ2h0IDIwMDMgVUJTLiBBbGwgcmlnaHRzIHJl
c2VydmVkLiBUaGlzIG1hdGVyaWFsIGlzIHN0cmljdGx5IA0KCWZvciBzcGVjaWZpZWQgcmVjaXBp
ZW50cyBvbmx5IGFuZCBtYXkgbm90IGJlIHJlcHJvZHVjZWQsIGRpc3RyaWJ1dGVkIA0KCW9yIGZv
cndhcmRlZCBpbiBhbnkgbWFubmVyIHdpdGhvdXQgdGhlIHBlcm1pc3Npb24gb2YgVUJTLiANCg0K
DQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSANCglUaGlzIFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IElCTSBMaW51eCBUdXRvcmlh
bHMuIA0KCUJlY29tZSBhbiBleHBlcnQgaW4gTElOVVggb3IganVzdCBzaGFycGVuIHlvdXIgc2tp
bGxzLiAgU2lnbiB1cCBmb3IgSUJNJ3MgDQoJRnJlZSBMaW51eCBUdXRvcmlhbHMuICBMZWFybiBl
dmVyeXRoaW5nIGZyb20gdGhlIGJhc2ggc2hlbGwgdG8gc3lzIGFkbWluLiANCglDbGljayBub3ch
IGh0dHA6Ly9hZHMub3Nkbi5jb20vP2FkX2lkIDxodHRwczovL3BvcnRhbC5yaXRjaGllY2FwaXRh
bC5jb20vLERhbmFJbmZvPWFkcy5vc2RuLmNvbSs/YWRfaWQ+IBI3OCZhbGxvY19pZDM3MSZvcD1p
Y2sgDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQoJ
UXVpY2tmaXgtZGV2ZWxvcGVycyBtYWlsaW5nIGxpc3QgDQoJUXVpY2tmaXgtZGV2ZWxvcGVyc0Bs
aXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQoJaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlz
dHMvbGlzdGluZm8vcXVpY2tmaXgtZGV2ZWxvcGVycyA8aHR0cHM6Ly9wb3J0YWwucml0Y2hpZWNh
cGl0YWwuY29tL2xpc3RzL2xpc3RpbmZvL3F1aWNrZml4LWRldmVsb3BlcnMsRGFuYUluZm89bGlz
dHMuc291cmNlZm9yZ2UubmV0LFNTTCs+ICANCg0K

[Quickfix-developers] build problems.

[<bal...@ub...>]

Folks,
	I have the following problem when I run bootstrap from the examples =
directory.
My version of autoheader is 2.57, the version of aclocal and automake is =
1.7.6.

<xstm9869dap/> ./bootstrap =20
autoheader...
autoheader: error: AC_CONFIG_HEADERS not found in configure.in
libtoolize...
aclocal...
aclocal: configure.in: 6: macro `AM_DISABLE_STATIC' not found in library
aclocal: configure.in: 14: macro `AM_PROG_LIBTOOL' not found in library
automake...
configure.in: no proper invocation of AM_INIT_AUTOMAKE was found.
configure.in: You should verify that configure.in invokes =
AM_INIT_AUTOMAKE,
configure.in: that aclocal.m4 is present in the top-level directory,
configure.in: and that aclocal.m4 was recently regenerated (using =
aclocal).
/ProgramTrading/d10/rh72_gcc321/share/automake-1.7/am/depend2.am: =
am__fastdepCXX does not appear in AM_CONDITIONAL
/ProgramTrading/d10/rh72_gcc321/share/automake-1.7/am/depend2.am: AMDEP =
does not appear in AM_CONDITIONAL
/ProgramTrading/d10/rh72_gcc321/share/automake-1.7/am/depend2.am: =
am__fastdepCXX does not appear in AM_CONDITIONAL
/ProgramTrading/d10/rh72_gcc321/share/automake-1.7/am/depend2.am: AMDEP =
does not appear in AM_CONDITIONAL
/ProgramTrading/d10/rh72_gcc321/share/automake-1.7/am/depend2.am: =
am__fastdepCXX does not appear in AM_CONDITIONAL
/ProgramTrading/d10/rh72_gcc321/share/automake-1.7/am/depend2.am: AMDEP =
does not appear in AM_CONDITIONAL
/ProgramTrading/d10/rh72_gcc321/share/automake-1.7/am/depend2.am: =
am__fastdepCXX does not appear in AM_CONDITIONAL
/ProgramTrading/d10/rh72_gcc321/share/automake-1.7/am/depend2.am: AMDEP =
does not appear in AM_CONDITIONAL
autoconf...
Now run configure with any arguments necessary

	Subsequently when I run configure and make, make fails saying =
Application.Po and tradeclient.Po is missing.
Any help would be greatly appreciated.

thanks
-Balaji Srinviasan


This material has been prepared by UBS AG or an affiliate thereof
("UBS"). This material is a sales and trading communication and should
not be viewed as research. Opinions expressed herein are subject to
change without notice and may differ or be contrary to the opinions or
recommendations of UBS Investment research or the opinions expressed
by other business areas or groups of UBS as a result of using
different assumptions and criteria. Full details of UBS Investment
Research, if any, are available on request. Any prices or quotations
contained herein are indicative only and do not constitute an offer to
buy or sell any securities at any given price. No representation or
warranty, either express or implied, is provided in relation to the
accuracy, completeness, reliability or appropriateness of the
information, methodology and any derived price contained within this
material. The securities and related financial instruments described
herein may not be eligible for sale in all jurisdictions or to certain
categories of investors. Options, derivative products and futures are
not suitable for all investors, and trading in these instruments is
considered risky. Past performance is not necessarily indicative of
future results. Foreign currency rates of exchange may adversely
affect the value, price or income of any security or related
instrument mentioned in this report. UBS, its directors, officers and
employees or clients may have or have had interests or long or short
positions in the securities or related financial instruments referred
to herein, and may at any time make purchases and/or sales in them as
principal or agent. UBS may provide investment banking and other
services to and/or serve as directors of the companies referred to in
this material. Neither UBS its directors, employees or agents accept
any liability for any loss or damage arising out of the use of all or
any part of these materials. This material is distributed in the
following jurisdictions by: United Kingdom: UBS Limited, a subsidiary
of UBS AG, to persons who are market counterparties or intermediate
customers (as detailed in the FSA Rules) and is only available to such
persons. The information contained herein does not apply to, and
should not be relied upon by, private customers. Switzerland: UBS AG
to institutional investors only. Italy: Giubergia UBS SIM SpA, an
associate of UBS SA, in Milan. US: UBS Securities LLC or UBS Financial
Services Inc., subsidiaries of UBS AG, or solely to US institutional
investors by UBS AG or a subsidiary or affiliate thereof that is not
registered as a US broker-dealer (a "non-US affiliate"). Transactions
resulting from materials distributed by a non-US affiliate must be
effected through UBS Securities LLC or UBS Financial Services Inc.
Canada: UBS Securities Canada Inc., a subsidiary of UBS AG and a
member of the principal Canadian stock exchanges & CIPF. Japan: UBS
Securities Japan Ltd or UBS AG, Tokyo Branch, to institutional
investors only. Hong Kong: UBS Securities Asia Limited or UBS AG, Hong
Kong Branch. Singapore: UBS Securities Singapore Pte. Ltd or UBS AG,
Singapore Branch. Australia: UBS Advisory and Capital Markets
Australia Ltd and UBS Securities Australia Ltd. For additional
information or trade execution please contact your local sales or
trading contact.

Copyright 2003 UBS. All rights reserved. This material is strictly
for specified recipients only and may not be reproduced, distributed
or forwarded in any manner without the permission of UBS.

RE: [Quickfix-developers] ResendRequest

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

TWFyaywNCiANCllvdSBjYW4gZG8gdGhpcy4gIFdoZW4geW91IGVuY291bnRlciBhIG1lc3NhZ2Ug
aW4gdG9BcHAgeW91IGRvbid0IHdhbnQgdG8gcmVzZW50LCBzaW1wbHkgdGhyb3cgYSBEb05vdFNl
bmQgZXhjZXB0aW9uLiAgVGhpcyB3aWxsIGNhdXNlIHRoZSBtZXNzYWdlIHRvIGJlIHJlcGxhY2Vk
IHdpdGggYSBnYXAgZmlsbC4gIE1ha2Ugc3VyZSB0byBjaGVjayBmb3IgdGhlIFBvc0R1cCBmbGFn
IGluIHRoZSBoZWFkZXIgc28geW91IGRvbid0IHRocm93IG91dCBuZXcgbWVzc2FnZXMuDQogDQot
LW9yZW4NCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBNYXJ0aW4uRGVya2Vu
bmUgW21haWx0bzptYXJ0aW4uZGVya2VubmVAYWN0YW50LmNvbV0gDQoJU2VudDogVHVlIDEyLzIz
LzIwMDMgODo1NSBBTSANCglUbzogcXVpY2tmaXgtZGV2ZWxvcGVyc0BsaXN0cy5zb3VyY2Vmb3Jn
ZS5uZXQgDQoJQ2M6IA0KCVN1YmplY3Q6IFtRdWlja2ZpeC1kZXZlbG9wZXJzXSBSZXNlbmRSZXF1
ZXN0DQoJDQoJDQoJSSBhbSB0cnlpbmcgdG8gZGV0ZXJtaW5lIGp1c3QgaG93IG11Y2ggSSBoYXZl
IHRvIGludGVycHJldCB0aGUgdmFyaW91cyBhZG1pbiBtZXNzYWdlcyB0aGF0IGFyZSByZWNlaXZl
ZCBieSBteSBRdWlja0ZpeCBjbGllbnQgYXBwbGljYXRpb24uIA0KCSANCglBcyBhbiBleGFtcGxl
LCBpZiBteSBhcHBsaWNhdGlvbiBpcyBhc2tlZCB0byByZXNlbmQgbWVzc2FnZXMgOCB0aHJvdWdo
IDEyLCBpdCBtaWdodCBub3Qgd2FudCB0byByZXNlbmQgbWVzc2FnZSA5IGFzIHRoaXMgY291bGQg
YmUgYSBzdGFsZSBuZXcgb3JkZXIgcGxhY2VtZW50IChpbiB3aGljaCBjYXNlIG15IGNsaWVudCBh
cHBsaWNhdGlvbiB3aWxsIG5vdGlmeSB0aGUgdXNlciB0aGF0IHRoZSBvcmRlciBwbGFjZW1lbnQg
ZmFpbGVkIGFuZCB0aGV5IHNob3VsZCByZXNlbmQgaWYgdGhleSB3YW50IHRvKS4gVGhlIHBvaW50
IGhlcmUgaXMgZm9yIG1lc3NhZ2UgOSB3ZSB3YW50IHRvIHNlbmQgYSBnYXAgZmlsbCBtZXNzYWdl
IGluIGl0cyBwbGFjZS4gDQoJIA0KCUl0IHNlZW1zIEkgc2hvdWxkIGludGVyY2VwdCB0aGUgdG9B
cHAgbWVzc2FnZSBmb3IgdGhlIHJlc2VuZCwgYW5kIGRldGVybWluZSB0aGVyZSB3aGV0aGVyIEkg
d2FudCB0byBtYWtlIHRoZSBtZXNzYWdlIGludG8gYSBTZXF1ZW5jZSBSZXNldCAoR2FwIEZpbGwp
LiBJcyB0aGlzIHRoZSBjb3JyZWN0IOKAmHByb2NlZHVyZeKAmSBpbiB0aGlzIGluc3RhbmNlPyAN
CgkgDQoJVGhhbmtzDQoJTWFydGluLiANCgkgDQoJIA0K

[Quickfix-developers] ResendRequest

[Martin.Derkenne <mar...@ac...>]

I am trying to determine just how much I have to interpret the various
admin messages that are received by my QuickFix client application.=20
=20
As an example, if my application is asked to resend messages 8 through
12, it might not want to resend message 9 as this could be a stale new
order placement (in which case my client application will notify the
user that the order placement failed and they should resend if they want
to). The point here is for message 9 we want to send a gap fill message
in its place.=20
=20
It seems I should intercept the toApp message for the resend, and
determine there whether I want to make the message into a Sequence Reset
(Gap Fill). Is this the correct 'procedure' in this instance?=20
=20
Thanks
Martin.=20
=20
=20

[Quickfix-developers] Re: All timestamps, including DB

[Dr. D. A. J. <dja...@ar...>]

The default for the Available Shares Service is to use hundredths, let me know if this is a good unit to use for the sub-second interval.

Hyperfeed uses this so hundredths makes sense.

--Dave


---- John Muehlhausen <jg...@jg...> wrote:
> 
> As a follow-on to this, I want to put the sub-seconds in every FIX 
> message that we generate.
> 
> I think that is supported in later FIX versions, otherwise we use a 
> custom tag.
> 
> On Dec 20, 2003, at 7:31 PM, John Muehlhausen wrote:
> 
> >
> > All, just a reminder that ALL timestamps must be in sub-seconds, 
> > including all MySQL records.
> >
> > We are going to be selling stock a split second after we buy it and we 
> > need to be able to prove that if it ever comes up.
> >
> > -John
> >
> 
> 
> 

Re: [Quickfix-developers] Re: All timestamps, including DB

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

John, sub-second support has already been added in the repository.  It can be turned on and off via a flag in the configuration file.  I believe it can be activated for FIX.4.2 and higher.

John Muehlhausen <jg...@jg...> wrote:
As a follow-on to this, I want to put the sub-seconds in every FIX 
message that we generate.

I think that is supported in later FIX versions, otherwise we use a 
custom tag.

On Dec 20, 2003, at 7:31 PM, John Muehlhausen wrote:

>
> All, just a reminder that ALL timestamps must be in sub-seconds, 
> including all MySQL records.
>
> We are going to be selling stock a split second after we buy it and we 
> need to be able to prove that if it ever comes up.
>
> -John
>



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


---------------------------------
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing

[Quickfix-developers] Re: All timestamps, including DB

[John M. <jg...@jg...>]

As a follow-on to this, I want to put the sub-seconds in every FIX 
message that we generate.

I think that is supported in later FIX versions, otherwise we use a 
custom tag.

On Dec 20, 2003, at 7:31 PM, John Muehlhausen wrote:

>
> All, just a reminder that ALL timestamps must be in sub-seconds, 
> including all MySQL records.
>
> We are going to be selling stock a split second after we buy it and we 
> need to be able to prove that if it ever comes up.
>
> -John
>

[Quickfix-developers] All timestamps, including DB

[John M. <jg...@jg...>]

All, just a reminder that ALL timestamps must be in sub-seconds, 
including all MySQL records.

We are going to be selling stock a split second after we buy it and we 
need to be able to prove that if it ever comes up.

-John

[Quickfix-developers] Shared connections -- RFC: transaction, speed upgrades

[John M. <jg...@jg...>]

One more detail:

When a config file specifies more than one session and at least one of 
them is transactional then a warning will be logged if they are not all 
transactional or do not all share the same MessageStore configuration.

Also, MessageStore instances that are transactional must be implemented 
to share the underlying DB connection/context.  That will be done for 
MySQLStore (in transaction mode only) so that all operations from all 
Sessions can be in the same transaction.  Also, we may implement a pool 
of connections that are mapped to threads instead of to Sessions.  All 
such connections are to the same underlying transactional store but 
would allow for concurrent cross-session transactions.  There may be 
little real-world benefit to this design but it will be considered.  It 
is MessageStore implementation specific anyway and doesn't affect any 
interfaces.

-John

On Dec 19, 2003, at 9:01 AM, John Muehlhausen wrote:

>
> Oops-- when I wrote down the details I forgot one important thing:
> pause() and resume() must happen for *all* Responders that are used
> within the transaction, not just for the one from the Session that
> began the transaction.
>
> There are two options here:
> a) pause all Responders in all Sessions when the transaction begins
> b) record that a transaction has begun and pause each affected session
> at the first operation on it from within the transaction
>
> After commit() all paused queues must be resumed.  In (a) that means
> all sessions.  In (b) that means only paused sessions.
>
> While (b) is a bit more complex it will allow unaffected send queues to
> drain while a transaction is taking place-- a good thing for
> performance.  I think that is the way I want to go.
>
> Also, we will research whether the session threads (not the queue
> threads) can each have their own MessageStore environment with regard
> to transactions.  This would allow for concurrent transactions and
> means that pause() and resume() must increment and decrement a counter
> instead of just toggling a boolean (and the "transaction in progress"
> indicator is also a counter).  Whether this is supported will probably
> be MessageStore dependent.
>
> -John
>
> On Dec 18, 2003, at 4:04 PM, John Muehlhausen wrote:
>
>>
>> ******* please read IMPORTANT NOTE below if nothing else *******
>>
>> I am beginning to formulate a plan.  Please let me know if I am going
>> off the deep end:
>>
>> FIX::MessageStore -- I plan to add a boolean isTransactional property.
>>  I will also add two virtual methods begin() and commit() -- no-ops by
>> default.
>>
>> FIX::MySQLStore / Factory -- the factory will pick up two additional
>> settings: whether to use transactions and the database version number.
>>  If the version is > 4.1.1 then the prepared statements will be used.
>> If we are to use transactions then the MessageStore is transactional.
>> Auto-commit is still on (more on that below).
>>
>> FIX::Responder -- Add pause() and resume() pure virtual methods.
>>
>> FIX::Queue<T> -- add boolean signal property.  If property is marked
>> false then push() does not signal.  If property is marked true then
>> push() signals again and also signal() is called.
>>
>> FIX::ThreadedSocketConnection -- Another FIX::Queue and thread are
>> added for sending.  pause() is implemented to set send queue signal
>> property to false.  resume() is implemented to set send queue signal
>> property to true.  IMPORTANT NOTE: I'd like to change things so that
>> ThreadedSocketConnection *always* uses a send queue and thread.
>> Anyone have a problem with that?  If the new thread encounters a write
>> error then that will be communicated back to the send() method at next
>> enqueue attempt as per my previous email.
>>
>> FIX::SocketConnection -- pause() is implemented to create a std::queue
>> and make send() enqueue instead of send.  resume() is implemented to
>> send everything on the queue and destroy the queue.  Alternatively I
>> can make the queue hang around all the time if that is what people
>> want (slight performance increase).  I'm only doing this for people
>> who want a single thread *and* transactions.
>>
>> FIX::Session -- admin messages are not wrapped in transactions and
>> Responder::pause() and resume() are not called.  (They are persisted
>> since auto-commit is on in MySQL.)  Session::begin() will be
>> implemented to call pause() on the responder and then begin() on the
>> message store (by way of the session state).  Session::commit() will
>> be implemented to call commit() on the message store followed by
>> resume() on the responder.  fromApp() will be wrapped as follows:
>>
>> if( session state -> message store -> is transactional )
>> 	begin();
>> fromApp(); // incrNextSenderSeqNum() calls and set() calls will be in
>> the transaction
>> m_state.incrNextTargetMsgSeqNum(); // removed from verify(), also
>> called if admin type
>> if( session state -> message store -> is transactional )
>> 	commit();
>>
>> Note that begin and commit are called conditionally instead of just
>> being no-ops in the non-transactional case for sake of clarity.
>> Otherwise someone might think that a transaction always takes place.
>>
>> Within fromApp() the user may want to use MySQL within the same
>> transaction for different purposes.  If there is not currently a
>> method for exposing that then I will add one.
>>
>> That's it so far...  Comments?  Concerns?
>>
>> -John
>>
>> On Dec 17, 2003, at 5:05 PM, John Muehlhausen wrote:
>>
>>>
>>> Hello,
>>>
>>> I am making some changes to QuickFIX and would like feedback on the
>>> plans.  I'm not sure how best to get the changes into the source tree
>>> but that is my goal since I think they'll be generally useful and I'd
>>> like to not patch future versions...  :-)  I'm hoping to get some
>>> consensus on the work to be done so that my chances of getting the
>>> changes incorporated are greater... and to benefit from the combined
>>> wisdom of the group.  I am relatively new to QuickFIX so please bear
>>> with me!  I would need a volunteer to get the Java wrappers done
>>> since we are C++ only...
>>>
>>> First: I'd like to modify MySQLStore such that it uses the "prepared
>>> statements" in version 4.1.1+.  I'm hoping for a significant
>>> performance improvement.
>>>
>>> Second: I'd like to provide the option to store the received messages
>>> in the 'messages' table in case the developer needs to look at those
>>> messages for some other reason.  This would be less error prone than
>>> remembering to manually persist received messages.  For reasons that
>>> will become clear soon, this would happen at dequeue from the
>>> ThreadedSocket* objects.
>>>
>>> The third proposal needs some motivation:
>>>
>>> In some applications the validity of sending a FIX message depends on
>>> the success of sending another FIX message.  It would therefore be
>>> nice to have an atomic unit of work that involves the processing and
>>> sending of an arbitrary number of messages.  One simple example: the
>>> developer wants to send an execution report AND a drop copy somewhere
>>> else.  If the execution report doesn't happen then the drop copy
>>> should not either (and vice versa).
>>>
>>> Proposed solution (using MySQL 4.1.1+ with BDB or InnoDB tables):
>>>
>>> a) Add begin() and commit() methods to MySQLStore (and perhaps nil
>>> versions in MessageStore) which returns handle(s) useful for
>>> performing other MySQL statements in the same transaction.  The
>>> generalized transaction looks like this:
>>>
>>> 	begin transaction
>>> 	receive message from queue, persisting changes to next incoming
>>> seqnum (can't take place in socket reader thread-- does it now?)
>>> 	business logic resulting in message send(s) and potentially in other
>>> persistence within the same transaction
>>> 	commit transaction
>>>
>>> The problem here is that we cannot actually send messages unless we
>>> get past commit-- otherwise we might advertise something that didn't
>>> actually happen!  More on this follows... Also, the user manually
>>> calls begin() and commit() if the enclosed send(s) and other
>>> persistence are not in response to a received message.
>>>
>>> b) static Utility::socket_send() is re-implemented to place bytes on
>>> a send queue instead of actually sending on the socket-- and there is
>>> YAWT (yet another worker thread) draining this queue onto the socket.
>>>  There are two reasons for this-- first, bandwidth utilization may
>>> increase if business logic can run concurrently (our in-house engine
>>> has this).  Second, this provides a mechanism for stalling the actual
>>> send until post-commit (more in the next point).  If the worker
>>> thread encounters a write error then the queue is marked bad/emptied
>>> and socket_send() returns the error encountered by the write instead
>>> of performing the next enqueue.  The enqueued messages are lost but
>>> will be resent at next session startup (gap fill).  BTW, I am aware
>>> that socket_send() is static-- the socket handle is used with a
>>> global map to obtain the queue associated with the socket.  Hmmm...
>>> since there is really no reason to do this with the non-threaded
>>> incarnation of QuickFIX perhaps the right place for this is a
>>> re-implementation of ThreadedSocketConnection::send().
>>>
>>> c) when beginning the transaction, a barrier is placed on the write
>>> queues of each active session (whether connected or not).  The
>>> barrier means "don't send past this point, wait here".  All such
>>> barriers are removed just after the transaction is committed.  This
>>> delays the send of each message generated from within the transaction
>>> until after the message and seqnum increment have been persisted -- a
>>> guarantee that they are available for servicing future resend
>>> requests.
>>>
>>> High performance, reliable routing-type applications stand to benefit
>>> the most from these changes.  If a process/server dies in the middle
>>> of a transaction then the incoming message being acted on is
>>> effectively "un-received" and any messages produced are not sent.  Of
>>> course changes would be made in such a way as to not impact current
>>> QuickFIX users.
>>>
>>> It would be nice if "someone" wanted to do all of this for BDBStore
>>> (imaginary Berkeley DB transactional implementation of MessageStore)
>>> in the cases where MySQL is not practical-- like a desktop
>>> application.
>>>
>>> Comments? Concerns?
>>>
>>> Thanks,
>>> John
>>>
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for 
> IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys 
> admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] One more detail -- RFC: transaction, speed upgrades

[John M. <jg...@jg...>]

Oops-- when I wrote down the details I forgot one important thing: 
pause() and resume() must happen for *all* Responders that are used 
within the transaction, not just for the one from the Session that 
began the transaction.

There are two options here:
a) pause all Responders in all Sessions when the transaction begins
b) record that a transaction has begun and pause each affected session 
at the first operation on it from within the transaction

After commit() all paused queues must be resumed.  In (a) that means 
all sessions.  In (b) that means only paused sessions.

While (b) is a bit more complex it will allow unaffected send queues to 
drain while a transaction is taking place-- a good thing for 
performance.  I think that is the way I want to go.

Also, we will research whether the session threads (not the queue 
threads) can each have their own MessageStore environment with regard 
to transactions.  This would allow for concurrent transactions and 
means that pause() and resume() must increment and decrement a counter 
instead of just toggling a boolean (and the "transaction in progress" 
indicator is also a counter).  Whether this is supported will probably 
be MessageStore dependent.

-John

On Dec 18, 2003, at 4:04 PM, John Muehlhausen wrote:

>
> ******* please read IMPORTANT NOTE below if nothing else *******
>
> I am beginning to formulate a plan.  Please let me know if I am going 
> off the deep end:
>
> FIX::MessageStore -- I plan to add a boolean isTransactional property. 
>  I will also add two virtual methods begin() and commit() -- no-ops by 
> default.
>
> FIX::MySQLStore / Factory -- the factory will pick up two additional 
> settings: whether to use transactions and the database version number. 
>  If the version is > 4.1.1 then the prepared statements will be used.  
> If we are to use transactions then the MessageStore is transactional.  
> Auto-commit is still on (more on that below).
>
> FIX::Responder -- Add pause() and resume() pure virtual methods.
>
> FIX::Queue<T> -- add boolean signal property.  If property is marked 
> false then push() does not signal.  If property is marked true then 
> push() signals again and also signal() is called.
>
> FIX::ThreadedSocketConnection -- Another FIX::Queue and thread are 
> added for sending.  pause() is implemented to set send queue signal 
> property to false.  resume() is implemented to set send queue signal 
> property to true.  IMPORTANT NOTE: I'd like to change things so that 
> ThreadedSocketConnection *always* uses a send queue and thread.  
> Anyone have a problem with that?  If the new thread encounters a write 
> error then that will be communicated back to the send() method at next 
> enqueue attempt as per my previous email.
>
> FIX::SocketConnection -- pause() is implemented to create a std::queue 
> and make send() enqueue instead of send.  resume() is implemented to 
> send everything on the queue and destroy the queue.  Alternatively I 
> can make the queue hang around all the time if that is what people 
> want (slight performance increase).  I'm only doing this for people 
> who want a single thread *and* transactions.
>
> FIX::Session -- admin messages are not wrapped in transactions and 
> Responder::pause() and resume() are not called.  (They are persisted 
> since auto-commit is on in MySQL.)  Session::begin() will be 
> implemented to call pause() on the responder and then begin() on the 
> message store (by way of the session state).  Session::commit() will 
> be implemented to call commit() on the message store followed by 
> resume() on the responder.  fromApp() will be wrapped as follows:
>
> if( session state -> message store -> is transactional )
> 	begin();
> fromApp(); // incrNextSenderSeqNum() calls and set() calls will be in 
> the transaction
> m_state.incrNextTargetMsgSeqNum(); // removed from verify(), also 
> called if admin type
> if( session state -> message store -> is transactional )
> 	commit();
>
> Note that begin and commit are called conditionally instead of just 
> being no-ops in the non-transactional case for sake of clarity.  
> Otherwise someone might think that a transaction always takes place.
>
> Within fromApp() the user may want to use MySQL within the same 
> transaction for different purposes.  If there is not currently a 
> method for exposing that then I will add one.
>
> That's it so far...  Comments?  Concerns?
>
> -John
>
> On Dec 17, 2003, at 5:05 PM, John Muehlhausen wrote:
>
>>
>> Hello,
>>
>> I am making some changes to QuickFIX and would like feedback on the 
>> plans.  I'm not sure how best to get the changes into the source tree 
>> but that is my goal since I think they'll be generally useful and I'd 
>> like to not patch future versions...  :-)  I'm hoping to get some 
>> consensus on the work to be done so that my chances of getting the 
>> changes incorporated are greater... and to benefit from the combined 
>> wisdom of the group.  I am relatively new to QuickFIX so please bear 
>> with me!  I would need a volunteer to get the Java wrappers done 
>> since we are C++ only...
>>
>> First: I'd like to modify MySQLStore such that it uses the "prepared 
>> statements" in version 4.1.1+.  I'm hoping for a significant 
>> performance improvement.
>>
>> Second: I'd like to provide the option to store the received messages 
>> in the 'messages' table in case the developer needs to look at those 
>> messages for some other reason.  This would be less error prone than 
>> remembering to manually persist received messages.  For reasons that 
>> will become clear soon, this would happen at dequeue from the 
>> ThreadedSocket* objects.
>>
>> The third proposal needs some motivation:
>>
>> In some applications the validity of sending a FIX message depends on 
>> the success of sending another FIX message.  It would therefore be 
>> nice to have an atomic unit of work that involves the processing and 
>> sending of an arbitrary number of messages.  One simple example: the 
>> developer wants to send an execution report AND a drop copy somewhere 
>> else.  If the execution report doesn't happen then the drop copy 
>> should not either (and vice versa).
>>
>> Proposed solution (using MySQL 4.1.1+ with BDB or InnoDB tables):
>>
>> a) Add begin() and commit() methods to MySQLStore (and perhaps nil 
>> versions in MessageStore) which returns handle(s) useful for 
>> performing other MySQL statements in the same transaction.  The 
>> generalized transaction looks like this:
>>
>> 	begin transaction
>> 	receive message from queue, persisting changes to next incoming 
>> seqnum (can't take place in socket reader thread-- does it now?)
>> 	business logic resulting in message send(s) and potentially in other 
>> persistence within the same transaction
>> 	commit transaction
>>
>> The problem here is that we cannot actually send messages unless we 
>> get past commit-- otherwise we might advertise something that didn't 
>> actually happen!  More on this follows... Also, the user manually 
>> calls begin() and commit() if the enclosed send(s) and other 
>> persistence are not in response to a received message.
>>
>> b) static Utility::socket_send() is re-implemented to place bytes on 
>> a send queue instead of actually sending on the socket-- and there is 
>> YAWT (yet another worker thread) draining this queue onto the socket. 
>>  There are two reasons for this-- first, bandwidth utilization may 
>> increase if business logic can run concurrently (our in-house engine 
>> has this).  Second, this provides a mechanism for stalling the actual 
>> send until post-commit (more in the next point).  If the worker 
>> thread encounters a write error then the queue is marked bad/emptied 
>> and socket_send() returns the error encountered by the write instead 
>> of performing the next enqueue.  The enqueued messages are lost but 
>> will be resent at next session startup (gap fill).  BTW, I am aware 
>> that socket_send() is static-- the socket handle is used with a 
>> global map to obtain the queue associated with the socket.  Hmmm... 
>> since there is really no reason to do this with the non-threaded 
>> incarnation of QuickFIX perhaps the right place for this is a 
>> re-implementation of ThreadedSocketConnection::send().
>>
>> c) when beginning the transaction, a barrier is placed on the write 
>> queues of each active session (whether connected or not).  The 
>> barrier means "don't send past this point, wait here".  All such 
>> barriers are removed just after the transaction is committed.  This 
>> delays the send of each message generated from within the transaction 
>> until after the message and seqnum increment have been persisted -- a 
>> guarantee that they are available for servicing future resend 
>> requests.
>>
>> High performance, reliable routing-type applications stand to benefit 
>> the most from these changes.  If a process/server dies in the middle 
>> of a transaction then the incoming message being acted on is 
>> effectively "un-received" and any messages produced are not sent.  Of 
>> course changes would be made in such a way as to not impact current 
>> QuickFIX users.
>>
>> It would be nice if "someone" wanted to do all of this for BDBStore 
>> (imaginary Berkeley DB transactional implementation of MessageStore) 
>> in the cases where MySQL is not practical-- like a desktop 
>> application.
>>
>> Comments? Concerns?
>>
>> Thanks,
>> John
>>
>

RE: [Quickfix-developers] Memory Leaking

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

Alan,

I'm using QF 1.6, and I always keep leak detection on in debug.  I never
have had any problems with leaks as long as the engine shuts down ok.  Are
you getting these leaks from one of the example programs, or something
you've created?

Brian

-----Original Message-----
From: Alan Chen [mailto:al...@cn...]
Sent: Wednesday, December 17, 2003 11:26 PM
To: qui...@li...
Subject: [Quickfix-developers] Memory Leaking


Hi,
    I downloaded the quickfix on the website, and I found out that there is
a memory leaking in the lib.  Any idea of how to fix it?

Detected memory leaks!
Dumping objects ->
{682022} normal block at 0x01F7A478, 33 bytes long.
 Data: < 8=FIX.4.4      > 00 38 3D 46 49 58 2E 34 2E 34 01 00 CD CD CD CD
{682018} normal block at 0x01F7A270, 33 bytes long.
 Data: < FIX.4.4        > 00 46 49 58 2E 34 2E 34 00 CD CD CD CD CD CD CD
{682017} normal block at 0x01F7A208, 44 bytes long.
 Data: <     {          > F8 D4 B5 00 90 7B F7 01 F8 D4 B5 00 CC CD CD CD
{682016} normal block at 0x01F7A2D8, 33 bytes long.
 Data: < 8=             > 00 38 3D 01 00 CD CD CD CD CD CD CD CD CD CD CD
{682013} normal block at 0x01F7A1B0, 20 bytes long.
 Data: <@e  H   @e      > 40 65 B5 00 48 9D F7 01 40 65 B5 00 CB 01 00 00
{682012} normal block at 0x01F79D48, 20 bytes long.
 Data: <@e              > 40 65 B5 00 F0 9C F7 01 B0 A1 F7 01 CA 01 00 00
{682011} normal block at 0x01F7A148, 44 bytes long.
 Data: <H       H       > 48 A1 F7 01 F8 D4 B5 00 48 A1 F7 01 CD CD CD CD
{682009} normal block at 0x01F7A0D0, 52 bytes long.
 Data: <                > D0 A0 F7 01 08 D4 B5 00 D0 A0 F7 01 CD CD CD CD
{682007} normal block at 0x01F7A068, 36 bytes long.
 Data: <h   8   h       > 68 A0 F7 01 38 D3 B5 00 68 A0 F7 01 CD CD CD CD
{682005} normal block at 0x01F7A000, 36 bytes long.
 Data: <    h           > 00 A0 F7 01 68 D2 B5 00 00 A0 F7 01 CD CD CD CD
{682003} normal block at 0x01F79F98, 36 bytes long.
 Data: <                > 98 9F F7 01 98 D1 B5 00 98 9F F7 01 CD CD CD CD
{682001} normal block at 0x01F79F40, 24 bytes long.
 Data: <@   P   @       > 40 9F F7 01 50 B8 B5 00 40 9F F7 01 CD CD CD CD
{681999} normal block at 0x01F79EE8, 20 bytes long.
 Data: <    @e          > E8 9E F7 01 40 65 B5 00 E8 9E F7 01 CD CD CD CD
{681997} normal block at 0x01F79E90, 20 bytes long.
 Data: <    @e          > 90 9E F7 01 40 65 B5 00 90 9E F7 01 CD CD CD CD
{681995} normal block at 0x01F79CF0, 20 bytes long.
 Data: <H   H           > 48 9D F7 01 48 9D F7 01 B0 A1 F7 01 CD CD CD CD
{681993} normal block at 0x01F79E28, 32 bytes long.
 Data: <(       (       > 28 9E F7 01 C8 D0 B5 00 28 9E F7 01 CD CD CD CD
{681991} normal block at 0x01F79DB0, 48 bytes long.
 Data: <                > B0 9D F7 01 90 95 B5 00 B0 9D F7 01 CD CD CD CD
{681989} normal block at 0x01F79C78, 48 bytes long.
 Data: <x       x       > 78 9C F7 01 90 95 B5 00 78 9C F7 01 CD CD CD CD
{681984} normal block at 0x01F79B40, 244 bytes long.
 Data: <  Z             > B0 19 5A 00 01 01 01 CD 08 00 00 00 CC CD CD CD
{681983} normal block at 0x01F79AE8, 20 bytes long.
 Data: <@e  8   @e      > 40 65 B5 00 38 9A F7 01 40 65 B5 00 F1 00 00 00
{681982} normal block at 0x01F79A90, 20 bytes long.
 Data: <@e  8   @e      > 40 65 B5 00 38 9A F7 01 40 65 B5 00 F3 00 00 00
{681981} normal block at 0x01F79A38, 20 bytes long.
 Data: <                > E8 9A F7 01 20 97 F7 01 90 9A F7 01 F2 00 00 00
{681980} normal block at 0x01F799E0, 20 bytes long.
 Data: <@e  0   @e      > 40 65 B5 00 30 99 F7 01 40 65 B5 00 F5 00 00 00
{681979} normal block at 0x01F79988, 20 bytes long.
 Data: <@e  0   @e      > 40 65 B5 00 30 99 F7 01 40 65 B5 00 F7 00 00 00
{681978} normal block at 0x01F79930, 20 bytes long.
 Data: <    x           > E0 99 F7 01 78 97 F7 01 88 99 F7 01 F6 00 00 00
{681977} normal block at 0x01F798D8, 20 bytes long.
 Data: <@e      @e  1   > 40 65 B5 00 D0 97 F7 01 40 65 B5 00 31 01 00 00
{681976} normal block at 0x01F79880, 20 bytes long.
 Data: <@e  (   @e  3   > 40 65 B5 00 28 98 F7 01 40 65 B5 00 33 01 00 00
{681975} normal block at 0x01F79828, 20 bytes long.
 Data: <        @e  4   > 80 98 F7 01 D0 97 F7 01 40 65 B5 00 34 01 00 00
{681974} normal block at 0x01F797D0, 20 bytes long.
 Data: <    x   (   2   > D8 98 F7 01 78 97 F7 01 28 98 F7 01 32 01 00 00
{681973} normal block at 0x01F79778, 20 bytes long.
 Data: <0               > 30 99 F7 01 20 97 F7 01 D0 97 F7 01 00 01 00 00
{681972} normal block at 0x01F79720, 20 bytes long.
 Data: <8       x       > 38 9A F7 01 C8 8B F7 01 78 97 F7 01 F4 00 00 00
{681971} normal block at 0x01F796C8, 20 bytes long.
 Data: <@e      @e  6   > 40 65 B5 00 18 96 F7 01 40 65 B5 00 36 01 00 00
{681970} normal block at 0x01F79670, 20 bytes long.
 Data: <@e      @e  8   > 40 65 B5 00 18 96 F7 01 40 65 B5 00 38 01 00 00
{681969} normal block at 0x01F79618, 20 bytes long.
 Data: <        p   7   > C8 96 F7 01 A8 92 F7 01 70 96 F7 01 37 01 00 00
{681968} normal block at 0x01F795C0, 20 bytes long.
 Data: <@e      @e  <   > 40 65 B5 00 B8 94 F7 01 40 65 B5 00 3C 01 00 00
{681967} normal block at 0x01F79568, 20 bytes long.
 Data: <@e      @e  >   > 40 65 B5 00 10 95 F7 01 40 65 B5 00 3E 01 00 00
{681966} normal block at 0x01F79510, 20 bytes long.
 Data: <h       @e  j   > 68 95 F7 01 B8 94 F7 01 40 65 B5 00 6A 01 00 00
{681965} normal block at 0x01F794B8, 20 bytes long.
 Data: <            =   > C0 95 F7 01 00 93 F7 01 10 95 F7 01 3D 01 00 00
{681964} normal block at 0x01F79460, 20 bytes long.
 Data: <@e      @e  m   > 40 65 B5 00 08 94 F7 01 40 65 B5 00 6D 01 00 00
{681963} normal block at 0x01F79408, 20 bytes long.
 Data: <@e  X   `   l   > 40 65 B5 00 58 93 F7 01 60 94 F7 01 6C 01 00 00
{681962} normal block at 0x01F793B0, 20 bytes long.
 Data: <@e  X   @e      > 40 65 B5 00 58 93 F7 01 40 65 B5 00 B4 01 00 00
{681961} normal block at 0x01F79358, 20 bytes long.
 Data: <                > 08 94 F7 01 00 93 F7 01 B0 93 F7 01 B3 01 00 00
{681960} normal block at 0x01F79300, 20 bytes long.
 Data: <        X   k   > B8 94 F7 01 A8 92 F7 01 58 93 F7 01 6B 01 00 00
{681959} normal block at 0x01F792A8, 20 bytes long.
 Data: <            9   > 18 96 F7 01 20 8C F7 01 00 93 F7 01 39 01 00 00
{681958} normal block at 0x01F79250, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 A0 91 F7 01 40 65 B5 00 CE 01 00 00
{681957} normal block at 0x01F791F8, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 A0 91 F7 01 40 65 B5 00 1E 02 00 00
{681956} normal block at 0x01F791A0, 20 bytes long.
 Data: <P   x           > 50 92 F7 01 78 8C F7 01 F8 91 F7 01 CF 01 00 00
{681955} normal block at 0x01F79148, 20 bytes long.
 Data: <@e      @e  R   > 40 65 B5 00 F0 90 F7 01 40 65 B5 00 52 02 00 00
{681954} normal block at 0x01F790F0, 20 bytes long.
 Data: <@e      H   Q   > 40 65 B5 00 E8 8F F7 01 48 91 F7 01 51 02 00 00
{681953} normal block at 0x01F79098, 20 bytes long.
 Data: <@e  @   @e  *   > 40 65 B5 00 40 90 F7 01 40 65 B5 00 2A 03 00 00
{681952} normal block at 0x01F79040, 20 bytes long.
 Data: <@e              > 40 65 B5 00 E8 8F F7 01 98 90 F7 01 FB 02 00 00
{681951} normal block at 0x01F78FE8, 20 bytes long.
 Data: <        @   S   > F0 90 F7 01 D0 8C F7 01 40 90 F7 01 53 02 00 00
{681950} normal block at 0x01F78F90, 20 bytes long.
 Data: <@e      @e  n   > 40 65 B5 00 E0 8E F7 01 40 65 B5 00 6E 03 00 00
{681949} normal block at 0x01F78F38, 20 bytes long.
 Data: <@e      @e  r   > 40 65 B5 00 E0 8E F7 01 40 65 B5 00 72 03 00 00
{681948} normal block at 0x01F78EE0, 20 bytes long.
 Data: <    (   8   o   > 90 8F F7 01 28 8D F7 01 38 8F F7 01 6F 03 00 00
{681947} normal block at 0x01F78E88, 20 bytes long.
 Data: <@e      @e  t   > 40 65 B5 00 80 8D F7 01 40 65 B5 00 74 03 00 00
{681946} normal block at 0x01F78E30, 20 bytes long.
 Data: <@e      @e  v   > 40 65 B5 00 D8 8D F7 01 40 65 B5 00 76 03 00 00
{681945} normal block at 0x01F78DD8, 20 bytes long.
 Data: <0       @e      > 30 8E F7 01 80 8D F7 01 40 65 B5 00 AD 03 00 00
{681944} normal block at 0x01F78D80, 20 bytes long.
 Data: <    (       u   > 88 8E F7 01 28 8D F7 01 D8 8D F7 01 75 03 00 00
{681943} normal block at 0x01F78D28, 20 bytes long.
 Data: <            s   > E0 8E F7 01 D0 8C F7 01 80 8D F7 01 73 03 00 00
{681942} normal block at 0x01F78CD0, 20 bytes long.
 Data: <    x   (   m   > E8 8F F7 01 78 8C F7 01 28 8D F7 01 6D 03 00 00
{681941} normal block at 0x01F78C78, 20 bytes long.
 Data: <            P   > A0 91 F7 01 20 8C F7 01 D0 8C F7 01 50 02 00 00
{681940} normal block at 0x01F78C20, 20 bytes long.
 Data: <        x       > A8 92 F7 01 C8 8B F7 01 78 8C F7 01 C9 01 00 00
{681939} normal block at 0x01F78BC8, 20 bytes long.
 Data: <     x      5   > 20 97 F7 01 80 78 F7 01 20 8C F7 01 35 01 00 00
{681938} normal block at 0x01F78B70, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 C0 8A F7 01 40 65 B5 00 F1 00 00 00
{681937} normal block at 0x01F78B18, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 C0 8A F7 01 40 65 B5 00 F3 00 00 00
{681936} normal block at 0x01F78AC0, 20 bytes long.
 Data: <p               > 70 8B F7 01 A8 87 F7 01 18 8B F7 01 F2 00 00 00
{681935} normal block at 0x01F78A68, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 B8 89 F7 01 40 65 B5 00 F5 00 00 00
{681934} normal block at 0x01F78A10, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 B8 89 F7 01 40 65 B5 00 F7 00 00 00
{681933} normal block at 0x01F789B8, 20 bytes long.
 Data: <h               > 68 8A F7 01 00 88 F7 01 10 8A F7 01 F6 00 00 00
{681932} normal block at 0x01F78960, 20 bytes long.
 Data: <@e  X   @e  1   > 40 65 B5 00 58 88 F7 01 40 65 B5 00 31 01 00 00
{681931} normal block at 0x01F78908, 20 bytes long.
 Data: <@e      @e  3   > 40 65 B5 00 B0 88 F7 01 40 65 B5 00 33 01 00 00
{681930} normal block at 0x01F788B0, 20 bytes long.
 Data: <    X   @e  4   > 08 89 F7 01 58 88 F7 01 40 65 B5 00 34 01 00 00
{681929} normal block at 0x01F78858, 20 bytes long.
 Data: <`           2   > 60 89 F7 01 00 88 F7 01 B0 88 F7 01 32 01 00 00
{681928} normal block at 0x01F78800, 20 bytes long.
 Data: <        X       > B8 89 F7 01 A8 87 F7 01 58 88 F7 01 00 01 00 00
{681927} normal block at 0x01F787A8, 20 bytes long.
 Data: <    P|          > C0 8A F7 01 50 7C F7 01 00 88 F7 01 F4 00 00 00
{681926} normal block at 0x01F78750, 20 bytes long.
 Data: <@e      @e  6   > 40 65 B5 00 A0 86 F7 01 40 65 B5 00 36 01 00 00
{681925} normal block at 0x01F786F8, 20 bytes long.
 Data: <@e      @e  8   > 40 65 B5 00 A0 86 F7 01 40 65 B5 00 38 01 00 00
{681924} normal block at 0x01F786A0, 20 bytes long.
 Data: <P   0       7   > 50 87 F7 01 30 83 F7 01 F8 86 F7 01 37 01 00 00
{681923} normal block at 0x01F78648, 20 bytes long.
 Data: <@e  @   @e  <   > 40 65 B5 00 40 85 F7 01 40 65 B5 00 3C 01 00 00
{681922} normal block at 0x01F785F0, 20 bytes long.
 Data: <@e      @e  >   > 40 65 B5 00 98 85 F7 01 40 65 B5 00 3E 01 00 00
{681921} normal block at 0x01F78598, 20 bytes long.
 Data: <    @   @e  j   > F0 85 F7 01 40 85 F7 01 40 65 B5 00 6A 01 00 00
{681920} normal block at 0x01F78540, 20 bytes long.
 Data: <H           =   > 48 86 F7 01 88 83 F7 01 98 85 F7 01 3D 01 00 00
{681919} normal block at 0x01F784E8, 20 bytes long.
 Data: <@e      @e  m   > 40 65 B5 00 90 84 F7 01 40 65 B5 00 6D 01 00 00
{681918} normal block at 0x01F78490, 20 bytes long.
 Data: <@e          l   > 40 65 B5 00 E0 83 F7 01 E8 84 F7 01 6C 01 00 00
{681917} normal block at 0x01F78438, 20 bytes long.
 Data: <@e      @e      > 40 65 B5 00 E0 83 F7 01 40 65 B5 00 B4 01 00 00
{681916} normal block at 0x01F783E0, 20 bytes long.
 Data: <        8       > 90 84 F7 01 88 83 F7 01 38 84 F7 01 B3 01 00 00
{681915} normal block at 0x01F78388, 20 bytes long.
 Data: <@   0       k   > 40 85 F7 01 30 83 F7 01 E0 83 F7 01 6B 01 00 00
{681914} normal block at 0x01F78330, 20 bytes long.
 Data: <     |      9   > A0 86 F7 01 A8 7C F7 01 88 83 F7 01 39 01 00 00
{681913} normal block at 0x01F782D8, 20 bytes long.
 Data: <@e  (   @e      > 40 65 B5 00 28 82 F7 01 40 65 B5 00 CE 01 00 00
{681912} normal block at 0x01F78280, 20 bytes long.
 Data: <@e  (   @e      > 40 65 B5 00 28 82 F7 01 40 65 B5 00 1E 02 00 00
{681911} normal block at 0x01F78228, 20 bytes long.
 Data: <     }          > D8 82 F7 01 00 7D F7 01 80 82 F7 01 CF 01 00 00
{681910} normal block at 0x01F781D0, 20 bytes long.
 Data: <@e  x   @e  R   > 40 65 B5 00 78 81 F7 01 40 65 B5 00 52 02 00 00
{681909} normal block at 0x01F78178, 20 bytes long.
 Data: <@e  p       Q   > 40 65 B5 00 70 80 F7 01 D0 81 F7 01 51 02 00 00
{681908} normal block at 0x01F78120, 20 bytes long.
 Data: <@e      @e  *   > 40 65 B5 00 C8 80 F7 01 40 65 B5 00 2A 03 00 00
{681907} normal block at 0x01F780C8, 20 bytes long.
 Data: <@e  p           > 40 65 B5 00 70 80 F7 01 20 81 F7 01 FB 02 00 00
{681906} normal block at 0x01F78070, 20 bytes long.
 Data: <x   X}      S   > 78 81 F7 01 58 7D F7 01 C8 80 F7 01 53 02 00 00
{681905} normal block at 0x01F78018, 20 bytes long.
 Data: <@e  h   @e  n   > 40 65 B5 00 68 7F F7 01 40 65 B5 00 6E 03 00 00
{681904} normal block at 0x01F77FC0, 20 bytes long.
 Data: <@e  h   @e  r   > 40 65 B5 00 68 7F F7 01 40 65 B5 00 72 03 00 00
{681903} normal block at 0x01F77F68, 20 bytes long.
 Data: <     }      o   > 18 80 F7 01 B0 7D F7 01 C0 7F F7 01 6F 03 00 00
{681902} normal block at 0x01F77F10, 20 bytes long.
 Data: <@e   ~  @e  t   > 40 65 B5 00 08 7E F7 01 40 65 B5 00 74 03 00 00
{681901} normal block at 0x01F77EB8, 20 bytes long.
 Data: <@e  `~  @e  v   > 40 65 B5 00 60 7E F7 01 40 65 B5 00 76 03 00 00
{681900} normal block at 0x01F77E60, 20 bytes long.
 Data: < ~   ~  @e      > B8 7E F7 01 08 7E F7 01 40 65 B5 00 AD 03 00 00
{681899} normal block at 0x01F77E08, 20 bytes long.
 Data: <     }  `~  u   > 10 7F F7 01 B0 7D F7 01 60 7E F7 01 75 03 00 00
{681898} normal block at 0x01F77DB0, 20 bytes long.
 Data: <h   X}   ~  s   > 68 7F F7 01 58 7D F7 01 08 7E F7 01 73 03 00 00
{681897} normal block at 0x01F77D58, 20 bytes long.
 Data: <p    }   }  m   > 70 80 F7 01 00 7D F7 01 B0 7D F7 01 6D 03 00 00
{681896} normal block at 0x01F77D00, 20 bytes long.
 Data: <(    |  X}  P   > 28 82 F7 01 A8 7C F7 01 58 7D F7 01 50 02 00 00
{681895} normal block at 0x01F77CA8, 20 bytes long.
 Data: <0   P|   }      > 30 83 F7 01 50 7C F7 01 00 7D F7 01 C9 01 00 00
{681894} normal block at 0x01F77C50, 20 bytes long.
 Data: <     {   |  5   > A8 87 F7 01 F8 7B F7 01 A8 7C F7 01 35 01 00 00
{681893} normal block at 0x01F77BF8, 20 bytes long.
 Data: <p   P|  `~      > 70 8B F7 01 50 7C F7 01 60 7E F7 01 CD CD CD CD
{681891} normal block at 0x01F74BA0, 48 bytes long.
 Data: <     o          > 90 95 B5 00 F0 6F F7 01 90 95 B5 00 CC CD CD CD
{681890} normal block at 0x01F77B90, 44 bytes long.
 Data: <                > 08 A2 F7 01 08 A2 F7 01 08 A2 F7 01 CD CD CD CD
{681888} normal block at 0x01F77B18, 52 bytes long.
 Data: < {       {      > 18 7B F7 01 08 D4 B5 00 18 7B F7 01 CD CD CD CD
{681886} normal block at 0x01F77AB0, 36 bytes long.
 Data: < z  8    z      > B0 7A F7 01 38 D3 B5 00 B0 7A F7 01 CD CD CD CD
{681884} normal block at 0x01F77A48, 36 bytes long.
 Data: <Hz  h   Hz      > 48 7A F7 01 68 D2 B5 00 48 7A F7 01 CD CD CD CD
{681882} normal block at 0x01F779E0, 36 bytes long.
 Data: < y       y      > E0 79 F7 01 98 D1 B5 00 E0 79 F7 01 CD CD CD CD
{681880} normal block at 0x01F77988, 24 bytes long.
 Data: < y  P    y      > 88 79 F7 01 50 B8 B5 00 88 79 F7 01 CD CD CD CD
{681878} normal block at 0x01F77930, 20 bytes long.
 Data: <0y  @e  0y      > 30 79 F7 01 40 65 B5 00 30 79 F7 01 CD CD CD CD
{681876} normal block at 0x01F778D8, 20 bytes long.
 Data: < x  @e   x      > D8 78 F7 01 40 65 B5 00 D8 78 F7 01 CD CD CD CD
{681874} normal block at 0x01F77880, 20 bytes long.
 Data: <                > E8 9A F7 01 C8 8B F7 01 D8 8D F7 01 CD CD CD CD
{681872} normal block at 0x01F77610, 32 bytes long.
 Data: < v       v      > 10 76 F7 01 C8 D0 B5 00 10 76 F7 01 CD CD CD CD
{681870} normal block at 0x01F77808, 48 bytes long.
 Data: < x       x      > 08 78 F7 01 90 95 B5 00 08 78 F7 01 CD CD CD CD
{681868} normal block at 0x01F76FF0, 48 bytes long.
 Data: < K   K   K      > A0 4B F7 01 A0 4B F7 01 A0 4B F7 01 CD CD CD CD
{681863} normal block at 0x01F776D0, 244 bytes long.
 Data: <  Z             > B0 19 5A 00 01 01 01 CD 08 00 00 00 CC CD CD CD
{679746} normal block at 0x01F73F98, 33 bytes long.
 Data: < 8=FIX.4.4      > 00 38 3D 46 49 58 2E 34 2E 34 01 00 CD CD CD CD
{679742} normal block at 0x01F73DF8, 33 bytes long.
 Data: < FIX.4.4        > 00 46 49 58 2E 34 2E 34 00 CD CD CD CD CD CD CD
{679741} normal block at 0x01F73DA0, 20 bytes long.
 Data: <@e  89  @e  ^   > 40 65 B5 00 38 39 F7 01 40 65 B5 00 5E 02 00 00
{679740} normal block at 0x01F73938, 20 bytes long.
 Data: <@e   8   =  ]   > 40 65 B5 00 E0 38 F7 01 A0 3D F7 01 5D 02 00 00
{679739} normal block at 0x01F73D38, 44 bytes long.
 Data: <8=      8=      > 38 3D F7 01 F8 D4 B5 00 38 3D F7 01 CD CD CD CD
{679737} normal block at 0x01F73CC0, 52 bytes long.
 Data: < <       <      > C0 3C F7 01 08 D4 B5 00 C0 3C F7 01 CD CD CD CD
{679735} normal block at 0x01F73C58, 36 bytes long.
{639704} normal block at 0x01F259B0, 20 bytes long.
 Data: <@e  XY  @e  h   > 40 65 B5 00 58 59 F2 01 40 65 B5 00 68 02 00 00
{639703} normal block at 0x01F25958, 20 bytes long.
 Data: < Z   Y   Y  g   > 08 5A F2 01 00 59 F2 01 B0 59 F2 01 67 02 00 00
{639702} normal block at 0x01F25900, 20 bytes long.
{639700} normal block at 0x01F25850, 20 bytes long.
 Data: <@e   W  @e  l   > 40 65 B5 00 F8 57 F2 01 40 65 B5 00 6C 02 00 00
{639699}  Data: <@e  @V  @e  n   > 40 65 B5 00 40 56 F2 01 40 65 B5 00 6E 02
00 00
{639697} normal block at 0x01F25748, 20 bytes long.
 Data: <@e   V  @e  p   > 40 65 B5 00 98 56 F2 01 40 65 B5 00 70 02 00 00
{639696} {639695} normal block at 0x01F25698, 20 bytes long.
 Data: <HW  @V   V      > 48 57 F2 01 40 56 F2 01 F0 56 F2 01 E3 02 00 00
{639694}  Data: <@e  8U  @e      > 40 65 B5 00 38 55 F2 01 40 65 B5 00 AE 03
00 00
{639692} normal block at 0x01F25590, 20 bytes long.
 Data: <@e  8U  @e      > 40 65 B5 00 38 55 F2 01 40 65 B5 00 BC 03 00 00
{639691} {639690} normal block at 0x01F254E0, 20 bytes long.
 Data: <@V   T  8U      > 40 56 F2 01 88 54 F2 01 38 55 F2 01 FC 02 00 00
{639689}  Data: < Y   S   T  i   > 00 59 F2 01 D8 53 F2 01 88 54 F2 01 69 02
00 00
{639687} normal block at 0x01F253D8, 20 bytes long.
 Data: <h[   S  0T  a   > 68 5B F2 01 80 53 F2 01 30 54 F2 01 61 02 00 00
{639686} {639685} normal block at 0x01F25328, 20 bytes long.
 Data: < a   S   U      > 98 61 F2 01 80 53 F2 01 90 55 F2 01 CD CD CD CD
{639683}  Data: <(w  (w  (w      > 28 77 F2 01 28 77 F2 01 28 77 F2 01 CD CD
CD CD
{639680} normal block at 0x01F25248, 52 bytes long.
 Data: <HR      HR      > 48 52 F2 01 08 D4 B5 00 48 52 F2 01 CD CD CD CD
{639678} {639676} normal block at 0x01F25178, 36 bytes long.
 Data: <xQ  h   xQ      > 78 51 F2 01 68 D2 B5 00 78 51 F2 01 CD CD CD CD
{639674}  Data: < P  P    P      > B8 50 F2 01 50 B8 B5 00 B8 50 F2 01 CD CD
CD CD
{639670} normal block at 0x01F25060, 20 bytes long.
 Data: <`P  @e  `P      > 60 50 F2 01 40 65 B5 00 60 50 F2 01 CD CD CD CD
{639668} {639666} normal block at 0x01F24F38, 20 bytes long.
 Data: < p   a   d      > 08 70 F2 01 F0 61 F2 01 00 64 F2 01 CD CD CD CD
{639664}  Data: <(       (       > 28 1C F2 01 90 95 B5 00 28 1C F2 01 CD CD
CD CD
{639660} normal block at 0x01F21BB0, 48 bytes long.
 Data: < O   O   O      > 90 4F F2 01 90 4F F2 01 90 4F F2 01 CD CD CD CD
{639655} {638402} normal block at 0x01F225E0, 33 bytes long.
 Data: < 8=FIX.4.4      > 00 38 3D 46 49 58 2E 34 2E 34 01 00 CD CD CD CD
{638398}  Data: <@e      @e  a   > 40 65 B5 00 D0 1E F2 01 40 65 B5 00 61 03
00 00
{638396} normal block at 0x01F22390, 20 bytes long.
 Data: <@e  8#  @e  d   > 40 65 B5 00 38 23 F2 01 40 65 B5 00 64 03 00 00
{638395}
Thanks and regards,
Alan Chen



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

RE: [Quickfix-developers] More details -- RFC: transaction, speed upgrades

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

SnVzdCBhIGNvbW1lbnQgcmlnaHQgbm93IG9uIHRoaXMgcGFydGljdWxhciBzZWN0aW9uOg0KDQo+
PiBJTVBPUlRBTlQgTk9URTogSSdkIGxpa2UgdG8gY2hhbmdlIHRoaW5ncyBzbyB0aGF0IA0KPj4g
VGhyZWFkZWRTb2NrZXRDb25uZWN0aW9uICphbHdheXMqIHVzZXMgYSBzZW5kIHF1ZXVlIGFuZCB0
aHJlYWQuICBBbnlvbmUgDQo+PiBoYXZlIGEgcHJvYmxlbSB3aXRoIHRoYXQ/DQoNClRoZXJlIGhh
cyBiZWVuIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCBjcmVhdGluZyBhIHNlbmQgcXVldWUgdG8gc29s
dmUgc29tZSBvdGhlciBwcm9ibGVtcyBhcyB3ZWxsLiAgSSBiZWxpZXZlIEpvZXJnIHJlY2VudGx5
IHBvc3RlZCBzb21ldGhpbmcgb24gdGhpcyAoY29uY2VybmluZyBzZW5kaW5nIG5ldyBtZXNzYWdl
cyBkdXJpbmcgcmVzZW5kIHJlcXVlc3RzKS4gIFBlcmhhcHMgd2UgY2FuIHN0YXJ0IGJ5IHNvbHZp
bmcgdGhpcyBwcm9ibGVtIGZpcnN0Pw0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJ
RnJvbTogSm9obiBNdWVobGhhdXNlbiBbbWFpbHRvOmpnbUBqZ20ub3JnXSANCglTZW50OiBUaHUg
MTIvMTgvMjAwMyA0OjA0IFBNIA0KCVRvOiBxdWlja2ZpeC1kZXZlbG9wZXJzQGxpc3RzLnNvdXJj
ZWZvcmdlLm5ldCANCglDYzogS2FybC1IZWlueiBaaW1tZXI7IEV2YW4gUHJpY2UgDQoJU3ViamVj
dDogW1F1aWNrZml4LWRldmVsb3BlcnNdIE1vcmUgZGV0YWlscyAtLSBSRkM6IHRyYW5zYWN0aW9u
LCBzcGVlZCB1cGdyYWRlcw0KCQ0KCQ0KDQoNCgkqKioqKioqIHBsZWFzZSByZWFkIElNUE9SVEFO
VCBOT1RFIGJlbG93IGlmIG5vdGhpbmcgZWxzZSAqKioqKioqIA0KDQoJSSBhbSBiZWdpbm5pbmcg
dG8gZm9ybXVsYXRlIGEgcGxhbi4gIFBsZWFzZSBsZXQgbWUga25vdyBpZiBJIGFtIGdvaW5nIA0K
CW9mZiB0aGUgZGVlcCBlbmQ6IA0KDQoJRklYOjpNZXNzYWdlU3RvcmUgLS0gSSBwbGFuIHRvIGFk
ZCBhIGJvb2xlYW4gaXNUcmFuc2FjdGlvbmFsIHByb3BlcnR5LiAgDQoJSSB3aWxsIGFsc28gYWRk
IHR3byB2aXJ0dWFsIG1ldGhvZHMgYmVnaW4oKSBhbmQgY29tbWl0KCkgLS0gbm8tb3BzIGJ5IA0K
CWRlZmF1bHQuIA0KDQoJRklYOjpNeVNRTFN0b3JlIC8gRmFjdG9yeSAtLSB0aGUgZmFjdG9yeSB3
aWxsIHBpY2sgdXAgdHdvIGFkZGl0aW9uYWwgDQoJc2V0dGluZ3M6IHdoZXRoZXIgdG8gdXNlIHRy
YW5zYWN0aW9ucyBhbmQgdGhlIGRhdGFiYXNlIHZlcnNpb24gbnVtYmVyLiAgDQoJSWYgdGhlIHZl
cnNpb24gaXMgPiA0LjEuMSB0aGVuIHRoZSBwcmVwYXJlZCBzdGF0ZW1lbnRzIHdpbGwgYmUgdXNl
ZC4gIA0KCUlmIHdlIGFyZSB0byB1c2UgdHJhbnNhY3Rpb25zIHRoZW4gdGhlIE1lc3NhZ2VTdG9y
ZSBpcyB0cmFuc2FjdGlvbmFsLiAgDQoJQXV0by1jb21taXQgaXMgc3RpbGwgb24gKG1vcmUgb24g
dGhhdCBiZWxvdykuIA0KDQoJRklYOjpSZXNwb25kZXIgLS0gQWRkIHBhdXNlKCkgYW5kIHJlc3Vt
ZSgpIHB1cmUgdmlydHVhbCBtZXRob2RzLiANCg0KCUZJWDo6UXVldWU8VD4gLS0gYWRkIGJvb2xl
YW4gc2lnbmFsIHByb3BlcnR5LiAgSWYgcHJvcGVydHkgaXMgbWFya2VkIA0KCWZhbHNlIHRoZW4g
cHVzaCgpIGRvZXMgbm90IHNpZ25hbC4gIElmIHByb3BlcnR5IGlzIG1hcmtlZCB0cnVlIHRoZW4g
DQoJcHVzaCgpIHNpZ25hbHMgYWdhaW4gYW5kIGFsc28gc2lnbmFsKCkgaXMgY2FsbGVkLiANCg0K
CUZJWDo6VGhyZWFkZWRTb2NrZXRDb25uZWN0aW9uIC0tIEFub3RoZXIgRklYOjpRdWV1ZSBhbmQg
dGhyZWFkIGFyZSANCglhZGRlZCBmb3Igc2VuZGluZy4gIHBhdXNlKCkgaXMgaW1wbGVtZW50ZWQg
dG8gc2V0IHNlbmQgcXVldWUgc2lnbmFsIA0KCXByb3BlcnR5IHRvIGZhbHNlLiAgcmVzdW1lKCkg
aXMgaW1wbGVtZW50ZWQgdG8gc2V0IHNlbmQgcXVldWUgc2lnbmFsIA0KCXByb3BlcnR5IHRvIHRy
dWUuICBJTVBPUlRBTlQgTk9URTogSSdkIGxpa2UgdG8gY2hhbmdlIHRoaW5ncyBzbyB0aGF0IA0K
CVRocmVhZGVkU29ja2V0Q29ubmVjdGlvbiAqYWx3YXlzKiB1c2VzIGEgc2VuZCBxdWV1ZSBhbmQg
dGhyZWFkLiAgQW55b25lIA0KCWhhdmUgYSBwcm9ibGVtIHdpdGggdGhhdD8gIElmIHRoZSBuZXcg
dGhyZWFkIGVuY291bnRlcnMgYSB3cml0ZSBlcnJvciANCgl0aGVuIHRoYXQgd2lsbCBiZSBjb21t
dW5pY2F0ZWQgYmFjayB0byB0aGUgc2VuZCgpIG1ldGhvZCBhdCBuZXh0IA0KCWVucXVldWUgYXR0
ZW1wdCBhcyBwZXIgbXkgcHJldmlvdXMgZW1haWwuIA0KDQoJRklYOjpTb2NrZXRDb25uZWN0aW9u
IC0tIHBhdXNlKCkgaXMgaW1wbGVtZW50ZWQgdG8gY3JlYXRlIGEgc3RkOjpxdWV1ZSANCglhbmQg
bWFrZSBzZW5kKCkgZW5xdWV1ZSBpbnN0ZWFkIG9mIHNlbmQuICByZXN1bWUoKSBpcyBpbXBsZW1l
bnRlZCB0byANCglzZW5kIGV2ZXJ5dGhpbmcgb24gdGhlIHF1ZXVlIGFuZCBkZXN0cm95IHRoZSBx
dWV1ZS4gIEFsdGVybmF0aXZlbHkgSSANCgljYW4gbWFrZSB0aGUgcXVldWUgaGFuZyBhcm91bmQg
YWxsIHRoZSB0aW1lIGlmIHRoYXQgaXMgd2hhdCBwZW9wbGUgd2FudCANCgkoc2xpZ2h0IHBlcmZv
cm1hbmNlIGluY3JlYXNlKS4gIEknbSBvbmx5IGRvaW5nIHRoaXMgZm9yIHBlb3BsZSB3aG8gd2Fu
dCANCglhIHNpbmdsZSB0aHJlYWQgKmFuZCogdHJhbnNhY3Rpb25zLiANCg0KCUZJWDo6U2Vzc2lv
biAtLSBhZG1pbiBtZXNzYWdlcyBhcmUgbm90IHdyYXBwZWQgaW4gdHJhbnNhY3Rpb25zIGFuZCAN
CglSZXNwb25kZXI6OnBhdXNlKCkgYW5kIHJlc3VtZSgpIGFyZSBub3QgY2FsbGVkLiAgKFRoZXkg
YXJlIHBlcnNpc3RlZCANCglzaW5jZSBhdXRvLWNvbW1pdCBpcyBvbiBpbiBNeVNRTC4pICBTZXNz
aW9uOjpiZWdpbigpIHdpbGwgYmUgDQoJaW1wbGVtZW50ZWQgdG8gY2FsbCBwYXVzZSgpIG9uIHRo
ZSByZXNwb25kZXIgYW5kIHRoZW4gYmVnaW4oKSBvbiB0aGUgDQoJbWVzc2FnZSBzdG9yZSAoYnkg
d2F5IG9mIHRoZSBzZXNzaW9uIHN0YXRlKS4gIFNlc3Npb246OmNvbW1pdCgpIHdpbGwgYmUgDQoJ
aW1wbGVtZW50ZWQgdG8gY2FsbCBjb21taXQoKSBvbiB0aGUgbWVzc2FnZSBzdG9yZSBmb2xsb3dl
ZCBieSByZXN1bWUoKSANCglvbiB0aGUgcmVzcG9uZGVyLiAgZnJvbUFwcCgpIHdpbGwgYmUgd3Jh
cHBlZCBhcyBmb2xsb3dzOiANCg0KCWlmKCBzZXNzaW9uIHN0YXRlIC0+IG1lc3NhZ2Ugc3RvcmUg
LT4gaXMgdHJhbnNhY3Rpb25hbCApIA0KCSAgICAgICAgYmVnaW4oKTsgDQoJZnJvbUFwcCgpOyAv
LyBpbmNyTmV4dFNlbmRlclNlcU51bSgpIGNhbGxzIGFuZCBzZXQoKSBjYWxscyB3aWxsIGJlIGlu
IA0KCXRoZSB0cmFuc2FjdGlvbiANCgltX3N0YXRlLmluY3JOZXh0VGFyZ2V0TXNnU2VxTnVtKCk7
IC8vIHJlbW92ZWQgZnJvbSB2ZXJpZnkoKSwgYWxzbyANCgljYWxsZWQgaWYgYWRtaW4gdHlwZSAN
CglpZiggc2Vzc2lvbiBzdGF0ZSAtPiBtZXNzYWdlIHN0b3JlIC0+IGlzIHRyYW5zYWN0aW9uYWwg
KSANCgkgICAgICAgIGNvbW1pdCgpOyANCg0KCU5vdGUgdGhhdCBiZWdpbiBhbmQgY29tbWl0IGFy
ZSBjYWxsZWQgY29uZGl0aW9uYWxseSBpbnN0ZWFkIG9mIGp1c3QgDQoJYmVpbmcgbm8tb3BzIGlu
IHRoZSBub24tdHJhbnNhY3Rpb25hbCBjYXNlIGZvciBzYWtlIG9mIGNsYXJpdHkuICANCglPdGhl
cndpc2Ugc29tZW9uZSBtaWdodCB0aGluayB0aGF0IGEgdHJhbnNhY3Rpb24gYWx3YXlzIHRha2Vz
IHBsYWNlLiANCg0KCVdpdGhpbiBmcm9tQXBwKCkgdGhlIHVzZXIgbWF5IHdhbnQgdG8gdXNlIE15
U1FMIHdpdGhpbiB0aGUgc2FtZSANCgl0cmFuc2FjdGlvbiBmb3IgZGlmZmVyZW50IHB1cnBvc2Vz
LiAgSWYgdGhlcmUgaXMgbm90IGN1cnJlbnRseSBhIG1ldGhvZCANCglmb3IgZXhwb3NpbmcgdGhh
dCB0aGVuIEkgd2lsbCBhZGQgb25lLiANCg0KCVRoYXQncyBpdCBzbyBmYXIuLi4gIENvbW1lbnRz
PyAgQ29uY2VybnM/IA0KDQoJLUpvaG4gDQoNCglPbiBEZWMgMTcsIDIwMDMsIGF0IDU6MDUgUE0s
IEpvaG4gTXVlaGxoYXVzZW4gd3JvdGU6IA0KDQoJPiANCgk+IEhlbGxvLCANCgk+IA0KCT4gSSBh
bSBtYWtpbmcgc29tZSBjaGFuZ2VzIHRvIFF1aWNrRklYIGFuZCB3b3VsZCBsaWtlIGZlZWRiYWNr
IG9uIHRoZSANCgk+IHBsYW5zLiAgSSdtIG5vdCBzdXJlIGhvdyBiZXN0IHRvIGdldCB0aGUgY2hh
bmdlcyBpbnRvIHRoZSBzb3VyY2UgdHJlZSANCgk+IGJ1dCB0aGF0IGlzIG15IGdvYWwgc2luY2Ug
SSB0aGluayB0aGV5J2xsIGJlIGdlbmVyYWxseSB1c2VmdWwgYW5kIEknZCANCgk+IGxpa2UgdG8g
bm90IHBhdGNoIGZ1dHVyZSB2ZXJzaW9ucy4uLiAgOi0pICBJJ20gaG9waW5nIHRvIGdldCBzb21l
IA0KCT4gY29uc2Vuc3VzIG9uIHRoZSB3b3JrIHRvIGJlIGRvbmUgc28gdGhhdCBteSBjaGFuY2Vz
IG9mIGdldHRpbmcgdGhlIA0KCT4gY2hhbmdlcyBpbmNvcnBvcmF0ZWQgYXJlIGdyZWF0ZXIuLi4g
YW5kIHRvIGJlbmVmaXQgZnJvbSB0aGUgY29tYmluZWQgDQoJPiB3aXNkb20gb2YgdGhlIGdyb3Vw
LiAgSSBhbSByZWxhdGl2ZWx5IG5ldyB0byBRdWlja0ZJWCBzbyBwbGVhc2UgYmVhciANCgk+IHdp
dGggbWUhICBJIHdvdWxkIG5lZWQgYSB2b2x1bnRlZXIgdG8gZ2V0IHRoZSBKYXZhIHdyYXBwZXJz
IGRvbmUgc2luY2UgDQoJPiB3ZSBhcmUgQysrIG9ubHkuLi4gDQoJPiANCgk+IEZpcnN0OiBJJ2Qg
bGlrZSB0byBtb2RpZnkgTXlTUUxTdG9yZSBzdWNoIHRoYXQgaXQgdXNlcyB0aGUgInByZXBhcmVk
IA0KCT4gc3RhdGVtZW50cyIgaW4gdmVyc2lvbiA0LjEuMSsuICBJJ20gaG9waW5nIGZvciBhIHNp
Z25pZmljYW50IA0KCT4gcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnQuIA0KCT4gDQoJPiBTZWNvbmQ6
IEknZCBsaWtlIHRvIHByb3ZpZGUgdGhlIG9wdGlvbiB0byBzdG9yZSB0aGUgcmVjZWl2ZWQgbWVz
c2FnZXMgDQoJPiBpbiB0aGUgJ21lc3NhZ2VzJyB0YWJsZSBpbiBjYXNlIHRoZSBkZXZlbG9wZXIg
bmVlZHMgdG8gbG9vayBhdCB0aG9zZSANCgk+IG1lc3NhZ2VzIGZvciBzb21lIG90aGVyIHJlYXNv
bi4gIFRoaXMgd291bGQgYmUgbGVzcyBlcnJvciBwcm9uZSB0aGFuIA0KCT4gcmVtZW1iZXJpbmcg
dG8gbWFudWFsbHkgcGVyc2lzdCByZWNlaXZlZCBtZXNzYWdlcy4gIEZvciByZWFzb25zIHRoYXQg
DQoJPiB3aWxsIGJlY29tZSBjbGVhciBzb29uLCB0aGlzIHdvdWxkIGhhcHBlbiBhdCBkZXF1ZXVl
IGZyb20gdGhlIA0KCT4gVGhyZWFkZWRTb2NrZXQqIG9iamVjdHMuIA0KCT4gDQoJPiBUaGUgdGhp
cmQgcHJvcG9zYWwgbmVlZHMgc29tZSBtb3RpdmF0aW9uOiANCgk+IA0KCT4gSW4gc29tZSBhcHBs
aWNhdGlvbnMgdGhlIHZhbGlkaXR5IG9mIHNlbmRpbmcgYSBGSVggbWVzc2FnZSBkZXBlbmRzIG9u
IA0KCT4gdGhlIHN1Y2Nlc3Mgb2Ygc2VuZGluZyBhbm90aGVyIEZJWCBtZXNzYWdlLiAgSXQgd291
bGQgdGhlcmVmb3JlIGJlIA0KCT4gbmljZSB0byBoYXZlIGFuIGF0b21pYyB1bml0IG9mIHdvcmsg
dGhhdCBpbnZvbHZlcyB0aGUgcHJvY2Vzc2luZyBhbmQgDQoJPiBzZW5kaW5nIG9mIGFuIGFyYml0
cmFyeSBudW1iZXIgb2YgbWVzc2FnZXMuICBPbmUgc2ltcGxlIGV4YW1wbGU6IHRoZSANCgk+IGRl
dmVsb3BlciB3YW50cyB0byBzZW5kIGFuIGV4ZWN1dGlvbiByZXBvcnQgQU5EIGEgZHJvcCBjb3B5
IHNvbWV3aGVyZSANCgk+IGVsc2UuICBJZiB0aGUgZXhlY3V0aW9uIHJlcG9ydCBkb2Vzbid0IGhh
cHBlbiB0aGVuIHRoZSBkcm9wIGNvcHkgDQoJPiBzaG91bGQgbm90IGVpdGhlciAoYW5kIHZpY2Ug
dmVyc2EpLiANCgk+IA0KCT4gUHJvcG9zZWQgc29sdXRpb24gKHVzaW5nIE15U1FMIDQuMS4xKyB3
aXRoIEJEQiBvciBJbm5vREIgdGFibGVzKTogDQoJPiANCgk+IGEpIEFkZCBiZWdpbigpIGFuZCBj
b21taXQoKSBtZXRob2RzIHRvIE15U1FMU3RvcmUgKGFuZCBwZXJoYXBzIG5pbCANCgk+IHZlcnNp
b25zIGluIE1lc3NhZ2VTdG9yZSkgd2hpY2ggcmV0dXJucyBoYW5kbGUocykgdXNlZnVsIGZvciAN
Cgk+IHBlcmZvcm1pbmcgb3RoZXIgTXlTUUwgc3RhdGVtZW50cyBpbiB0aGUgc2FtZSB0cmFuc2Fj
dGlvbi4gIFRoZSANCgk+IGdlbmVyYWxpemVkIHRyYW5zYWN0aW9uIGxvb2tzIGxpa2UgdGhpczog
DQoJPiANCgk+ICAgICAgIGJlZ2luIHRyYW5zYWN0aW9uIA0KCT4gICAgICAgcmVjZWl2ZSBtZXNz
YWdlIGZyb20gcXVldWUsIHBlcnNpc3RpbmcgY2hhbmdlcyB0byBuZXh0IGluY29taW5nIA0KCT4g
c2VxbnVtIChjYW4ndCB0YWtlIHBsYWNlIGluIHNvY2tldCByZWFkZXIgdGhyZWFkLS0gZG9lcyBp
dCBub3c/KSANCgk+ICAgICAgIGJ1c2luZXNzIGxvZ2ljIHJlc3VsdGluZyBpbiBtZXNzYWdlIHNl
bmQocykgYW5kIHBvdGVudGlhbGx5IGluIG90aGVyIA0KCT4gcGVyc2lzdGVuY2Ugd2l0aGluIHRo
ZSBzYW1lIHRyYW5zYWN0aW9uIA0KCT4gICAgICAgY29tbWl0IHRyYW5zYWN0aW9uIA0KCT4gDQoJ
PiBUaGUgcHJvYmxlbSBoZXJlIGlzIHRoYXQgd2UgY2Fubm90IGFjdHVhbGx5IHNlbmQgbWVzc2Fn
ZXMgdW5sZXNzIHdlIA0KCT4gZ2V0IHBhc3QgY29tbWl0LS0gb3RoZXJ3aXNlIHdlIG1pZ2h0IGFk
dmVydGlzZSBzb21ldGhpbmcgdGhhdCBkaWRuJ3QgDQoJPiBhY3R1YWxseSBoYXBwZW4hICBNb3Jl
IG9uIHRoaXMgZm9sbG93cy4uLiBBbHNvLCB0aGUgdXNlciBtYW51YWxseSANCgk+IGNhbGxzIGJl
Z2luKCkgYW5kIGNvbW1pdCgpIGlmIHRoZSBlbmNsb3NlZCBzZW5kKHMpIGFuZCBvdGhlciANCgk+
IHBlcnNpc3RlbmNlIGFyZSBub3QgaW4gcmVzcG9uc2UgdG8gYSByZWNlaXZlZCBtZXNzYWdlLiAN
Cgk+IA0KCT4gYikgc3RhdGljIFV0aWxpdHk6OnNvY2tldF9zZW5kKCkgaXMgcmUtaW1wbGVtZW50
ZWQgdG8gcGxhY2UgYnl0ZXMgb24gYSANCgk+IHNlbmQgcXVldWUgaW5zdGVhZCBvZiBhY3R1YWxs
eSBzZW5kaW5nIG9uIHRoZSBzb2NrZXQtLSBhbmQgdGhlcmUgaXMgDQoJPiBZQVdUICh5ZXQgYW5v
dGhlciB3b3JrZXIgdGhyZWFkKSBkcmFpbmluZyB0aGlzIHF1ZXVlIG9udG8gdGhlIHNvY2tldC4g
IA0KCT4gVGhlcmUgYXJlIHR3byByZWFzb25zIGZvciB0aGlzLS0gZmlyc3QsIGJhbmR3aWR0aCB1
dGlsaXphdGlvbiBtYXkgDQoJPiBpbmNyZWFzZSBpZiBidXNpbmVzcyBsb2dpYyBjYW4gcnVuIGNv
bmN1cnJlbnRseSAob3VyIGluLWhvdXNlIGVuZ2luZSANCgk+IGhhcyB0aGlzKS4gIFNlY29uZCwg
dGhpcyBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3Igc3RhbGxpbmcgdGhlIGFjdHVhbCANCgk+IHNl
bmQgdW50aWwgcG9zdC1jb21taXQgKG1vcmUgaW4gdGhlIG5leHQgcG9pbnQpLiAgSWYgdGhlIHdv
cmtlciB0aHJlYWQgDQoJPiBlbmNvdW50ZXJzIGEgd3JpdGUgZXJyb3IgdGhlbiB0aGUgcXVldWUg
aXMgbWFya2VkIGJhZC9lbXB0aWVkIGFuZCANCgk+IHNvY2tldF9zZW5kKCkgcmV0dXJucyB0aGUg
ZXJyb3IgZW5jb3VudGVyZWQgYnkgdGhlIHdyaXRlIGluc3RlYWQgb2YgDQoJPiBwZXJmb3JtaW5n
IHRoZSBuZXh0IGVucXVldWUuICBUaGUgZW5xdWV1ZWQgbWVzc2FnZXMgYXJlIGxvc3QgYnV0IHdp
bGwgDQoJPiBiZSByZXNlbnQgYXQgbmV4dCBzZXNzaW9uIHN0YXJ0dXAgKGdhcCBmaWxsKS4gIEJU
VywgSSBhbSBhd2FyZSB0aGF0IA0KCT4gc29ja2V0X3NlbmQoKSBpcyBzdGF0aWMtLSB0aGUgc29j
a2V0IGhhbmRsZSBpcyB1c2VkIHdpdGggYSBnbG9iYWwgbWFwIA0KCT4gdG8gb2J0YWluIHRoZSBx
dWV1ZSBhc3NvY2lhdGVkIHdpdGggdGhlIHNvY2tldC4gIEhtbW0uLi4gc2luY2UgdGhlcmUgDQoJ
PiBpcyByZWFsbHkgbm8gcmVhc29uIHRvIGRvIHRoaXMgd2l0aCB0aGUgbm9uLXRocmVhZGVkIGlu
Y2FybmF0aW9uIG9mIA0KCT4gUXVpY2tGSVggcGVyaGFwcyB0aGUgcmlnaHQgcGxhY2UgZm9yIHRo
aXMgaXMgYSByZS1pbXBsZW1lbnRhdGlvbiBvZiANCgk+IFRocmVhZGVkU29ja2V0Q29ubmVjdGlv
bjo6c2VuZCgpLiANCgk+IA0KCT4gYykgd2hlbiBiZWdpbm5pbmcgdGhlIHRyYW5zYWN0aW9uLCBh
IGJhcnJpZXIgaXMgcGxhY2VkIG9uIHRoZSB3cml0ZSANCgk+IHF1ZXVlcyBvZiBlYWNoIGFjdGl2
ZSBzZXNzaW9uICh3aGV0aGVyIGNvbm5lY3RlZCBvciBub3QpLiAgVGhlIGJhcnJpZXIgDQoJPiBt
ZWFucyAiZG9uJ3Qgc2VuZCBwYXN0IHRoaXMgcG9pbnQsIHdhaXQgaGVyZSIuICBBbGwgc3VjaCBi
YXJyaWVycyBhcmUgDQoJPiByZW1vdmVkIGp1c3QgYWZ0ZXIgdGhlIHRyYW5zYWN0aW9uIGlzIGNv
bW1pdHRlZC4gIFRoaXMgZGVsYXlzIHRoZSBzZW5kIA0KCT4gb2YgZWFjaCBtZXNzYWdlIGdlbmVy
YXRlZCBmcm9tIHdpdGhpbiB0aGUgdHJhbnNhY3Rpb24gdW50aWwgYWZ0ZXIgdGhlIA0KCT4gbWVz
c2FnZSBhbmQgc2VxbnVtIGluY3JlbWVudCBoYXZlIGJlZW4gcGVyc2lzdGVkIC0tIGEgZ3VhcmFu
dGVlIHRoYXQgDQoJPiB0aGV5IGFyZSBhdmFpbGFibGUgZm9yIHNlcnZpY2luZyBmdXR1cmUgcmVz
ZW5kIHJlcXVlc3RzLiANCgk+IA0KCT4gSGlnaCBwZXJmb3JtYW5jZSwgcmVsaWFibGUgcm91dGlu
Zy10eXBlIGFwcGxpY2F0aW9ucyBzdGFuZCB0byBiZW5lZml0IA0KCT4gdGhlIG1vc3QgZnJvbSB0
aGVzZSBjaGFuZ2VzLiAgSWYgYSBwcm9jZXNzL3NlcnZlciBkaWVzIGluIHRoZSBtaWRkbGUgDQoJ
PiBvZiBhIHRyYW5zYWN0aW9uIHRoZW4gdGhlIGluY29taW5nIG1lc3NhZ2UgYmVpbmcgYWN0ZWQg
b24gaXMgDQoJPiBlZmZlY3RpdmVseSAidW4tcmVjZWl2ZWQiIGFuZCBhbnkgbWVzc2FnZXMgcHJv
ZHVjZWQgYXJlIG5vdCBzZW50LiAgT2YgDQoJPiBjb3Vyc2UgY2hhbmdlcyB3b3VsZCBiZSBtYWRl
IGluIHN1Y2ggYSB3YXkgYXMgdG8gbm90IGltcGFjdCBjdXJyZW50IA0KCT4gUXVpY2tGSVggdXNl
cnMuIA0KCT4gDQoJPiBJdCB3b3VsZCBiZSBuaWNlIGlmICJzb21lb25lIiB3YW50ZWQgdG8gZG8g
YWxsIG9mIHRoaXMgZm9yIEJEQlN0b3JlIA0KCT4gKGltYWdpbmFyeSBCZXJrZWxleSBEQiB0cmFu
c2FjdGlvbmFsIGltcGxlbWVudGF0aW9uIG9mIE1lc3NhZ2VTdG9yZSkgDQoJPiBpbiB0aGUgY2Fz
ZXMgd2hlcmUgTXlTUUwgaXMgbm90IHByYWN0aWNhbC0tIGxpa2UgYSBkZXNrdG9wIA0KCT4gYXBw
bGljYXRpb24uIA0KCT4gDQoJPiBDb21tZW50cz8gQ29uY2VybnM/IA0KCT4gDQoJPiBUaGFua3Ms
IA0KCT4gSm9obiANCgk+IA0KDQoNCg0KCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoJVGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNvcmVk
IGJ5OiBJQk0gTGludXggVHV0b3JpYWxzLiANCglCZWNvbWUgYW4gZXhwZXJ0IGluIExJTlVYIG9y
IGp1c3Qgc2hhcnBlbiB5b3VyIHNraWxscy4gIFNpZ24gdXAgZm9yIElCTSdzIA0KCUZyZWUgTGlu
dXggVHV0b3JpYWxzLiAgTGVhcm4gZXZlcnl0aGluZyBmcm9tIHRoZSBiYXNoIHNoZWxsIHRvIHN5
cyBhZG1pbi4gDQoJQ2xpY2sgbm93ISBodHRwOi8vYWRzLm9zZG4uY29tLz9hZF9pZD0xMjc4JmFs
bG9jX2lkPTMzNzEmb3A9Y2xpY2sgPGh0dHBzOi8vcG9ydGFsLnJpdGNoaWVjYXBpdGFsLmNvbS8s
RGFuYUluZm89YWRzLm9zZG4uY29tKz9hZF9pZD0xMjc4JmFsbG9jX2lkPTMzNzEmb3A9Y2xpY2s+
ICANCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyANCglR
dWlja2ZpeC1kZXZlbG9wZXJzIG1haWxpbmcgbGlzdCANCglRdWlja2ZpeC1kZXZlbG9wZXJzQGxp
c3RzLnNvdXJjZWZvcmdlLm5ldCANCglodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0
cy9saXN0aW5mby9xdWlja2ZpeC1kZXZlbG9wZXJzIDxodHRwczovL3BvcnRhbC5yaXRjaGllY2Fw
aXRhbC5jb20vbGlzdHMvbGlzdGluZm8vcXVpY2tmaXgtZGV2ZWxvcGVycyxEYW5hSW5mbz1saXN0
cy5zb3VyY2Vmb3JnZS5uZXQsU1NMKz4gIA0KDQo=

[Quickfix-developers] Unexpected exception...

[Andrew <and...@ho...>]

I had this crash... Maybe null sessionID, yes?

-Andrew Munn
and...@ho...






341867 [AWT-EventQueue-0] DEBUG oms.OmsApplication  - ***SEND Message:
8=FIX.4.1?9=74?35=F?1=8H3C?11=119?38=100?41=117?50=u780580?54=1?55=IBM?100=N
?115=u780580?10=081?

341867 [AWT-EventQueue-0] DEBUG oms.OmsApplication  - ***SEND sessionID:
null

thread(4294967294):
  at FieldMap::calculateString(.\src\C++\FieldMap.cpp:161)
  at Message::toString(.\src\C++\Message.cpp:115)
  at SocketMonitor::block(.\src\C++\SocketMonitor.cpp:161)
  at SocketConnector::block(.\src\C++\SocketConnector.cpp:150)
  at SocketInitiator::onStart(.\src\C++\SocketInitiator.cpp:99)
  at Initiator::startThread(.\src\C++\Initiator.cpp:211)

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : unknown exception code (0xe06d7363) occurred at
PC=0x77E73887
Function=RaiseException+0x50
Library=C:\WINDOWS\system32\kernel32.dll

Current Java thread:
        at org.quickfix.Session.sendToTarget(Native Method)
        at oms.OmsApplication.send(Unknown Source)
        at oms.OmsApplication.cancel41(Unknown Source)
        at oms.OmsApplication.cancel(Unknown Source)
        at oms.OrderTable.mouseClicked(Unknown Source)
        at
java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:212)
        at java.awt.Component.processMouseEvent(Component.java:5103)
        at java.awt.Component.processEvent(Component.java:4897)
        at java.awt.Container.processEvent(Container.java:1569)
        at java.awt.Component.dispatchEventImpl(Component.java:3615)
        at java.awt.Container.dispatchEventImpl(Container.java:1627)
        at java.awt.Component.dispatchEvent(Component.java:3477)
        at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3483)
        at
java.awt.LightweightDispatcher.processMouseEvent(Container.java:3207)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3128)
        at java.awt.Container.dispatchEventImpl(Container.java:1613)
        at java.awt.Window.dispatchEventImpl(Window.java:1606)
        at java.awt.Component.dispatchEvent(Component.java:3477)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
        at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja
va:201)
        at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
:151)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
        at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

Dynamic libraries:
0x00400000 - 0x00406000         c:\j2sdk1.4.2\bin\java.exe
0x77F50000 - 0x77FF7000         C:\WINDOWS\System32\ntdll.dll
0x77E60000 - 0x77F46000         C:\WINDOWS\system32\kernel32.dll
0x77DD0000 - 0x77E5D000         C:\WINDOWS\system32\ADVAPI32.dll
0x78000000 - 0x78086000         C:\WINDOWS\system32\RPCRT4.dll
0x77C10000 - 0x77C63000         C:\WINDOWS\system32\MSVCRT.dll
0x08000000 - 0x08136000         c:\j2sdk1.4.2\jre\bin\client\jvm.dll
0x77D40000 - 0x77DCC000         C:\WINDOWS\system32\USER32.dll
0x77C70000 - 0x77CB0000         C:\WINDOWS\system32\GDI32.dll
0x76B40000 - 0x76B6C000         C:\WINDOWS\System32\WINMM.dll
0x10000000 - 0x10007000         c:\j2sdk1.4.2\jre\bin\hpi.dll
0x00390000 - 0x0039E000         c:\j2sdk1.4.2\jre\bin\verify.dll
0x003A0000 - 0x003B8000         c:\j2sdk1.4.2\jre\bin\java.dll
0x003C0000 - 0x003CD000         c:\j2sdk1.4.2\jre\bin\zip.dll
0x02DE0000 - 0x02E86000         C:\javaclasses\quickfix_jni.dll
0x71AB0000 - 0x71AC5000         C:\WINDOWS\System32\WS2_32.dll
0x71AA0000 - 0x71AA8000         C:\WINDOWS\System32\WS2HELP.dll
0x771B0000 - 0x772D1000         C:\WINDOWS\system32\ole32.dll
0x77120000 - 0x771AB000         C:\WINDOWS\system32\OLEAUT32.dll
0x7C3A0000 - 0x7C41B000         C:\WINDOWS\System32\MSVCP71.dll
0x7C340000 - 0x7C396000         C:\WINDOWS\System32\MSVCR71.dll
0x02E90000 - 0x02ECF000         C:\WINDOWS\System32\LIBMYSQL.dll
0x71AD0000 - 0x71AD8000         C:\WINDOWS\System32\WSOCK32.dll
0x02FF0000 - 0x030FA000         C:\j2sdk1.4.2\jre\bin\awt.dll
0x73000000 - 0x73023000         C:\WINDOWS\System32\WINSPOOL.DRV
0x76390000 - 0x763AC000         C:\WINDOWS\System32\IMM32.dll
0x03110000 - 0x03160000         C:\j2sdk1.4.2\jre\bin\fontmanager.dll
0x03160000 - 0x0316F000         C:\j2sdk1.4.2\jre\bin\net.dll
0x71A50000 - 0x71A8B000         C:\WINDOWS\System32\mswsock.dll
0x76F20000 - 0x76F45000         C:\WINDOWS\System32\DNSAPI.dll
0x76FB0000 - 0x76FB7000         C:\WINDOWS\System32\winrnr.dll
0x76F60000 - 0x76F8C000         C:\WINDOWS\system32\WLDAP32.dll
0x76FC0000 - 0x76FC5000         C:\WINDOWS\System32\rasadhlp.dll
0x71A90000 - 0x71A98000         C:\WINDOWS\System32\wshtcpip.dll
0x73760000 - 0x737A4000         C:\WINDOWS\System32\ddraw.dll
0x73BC0000 - 0x73BC6000         C:\WINDOWS\System32\DCIMAN32.dll
0x73940000 - 0x73A07000         C:\WINDOWS\System32\D3DIM700.DLL
0x052E0000 - 0x052FB000         C:\j2sdk1.4.2\jre\lib\ext\x86\corojdk11.dll
0x76C90000 - 0x76CB2000         C:\WINDOWS\system32\imagehlp.dll
0x6D510000 - 0x6D58D000         C:\WINDOWS\system32\DBGHELP.dll
0x77C00000 - 0x77C07000         C:\WINDOWS\system32\VERSION.dll
0x76BF0000 - 0x76BFB000         C:\WINDOWS\System32\PSAPI.DLL

Heap at VM Abort:
Heap
 def new generation   total 576K, used 343K [0x10010000, 0x100b0000,
0x104f0000)
  eden space 512K,  62% used [0x10010000, 0x1005f688, 0x10090000)
  from space 64K,  40% used [0x10090000, 0x10096710, 0x100a0000)
  to   space 64K,   0% used [0x100a0000, 0x100a0000, 0x100b0000)
 tenured generation   total 3200K, used 2185K [0x104f0000, 0x10810000,
0x14010000)
   the space 3200K,  68% used [0x104f0000, 0x107124e8, 0x10712600,
0x10810000)
 compacting perm gen  total 14592K, used 14584K [0x14010000, 0x14e50000,
0x18010000)
   the space 14592K,  99% used [0x14010000, 0x14e4e288, 0x14e4e400,
0x14e50000)

Local Time = Thu Dec 18 16:51:09 2003
Elapsed Time = 341
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode)
#
# An error report file has been saved as hs_err_pid16300.log.
# Please refer to the file for further information.
#

[Quickfix-developers] More details -- RFC: transaction, speed upgrades

[John M. <jg...@jg...>]

******* please read IMPORTANT NOTE below if nothing else *******

I am beginning to formulate a plan.  Please let me know if I am going 
off the deep end:

FIX::MessageStore -- I plan to add a boolean isTransactional property.  
I will also add two virtual methods begin() and commit() -- no-ops by 
default.

FIX::MySQLStore / Factory -- the factory will pick up two additional 
settings: whether to use transactions and the database version number.  
If the version is > 4.1.1 then the prepared statements will be used.  
If we are to use transactions then the MessageStore is transactional.  
Auto-commit is still on (more on that below).

FIX::Responder -- Add pause() and resume() pure virtual methods.

FIX::Queue<T> -- add boolean signal property.  If property is marked 
false then push() does not signal.  If property is marked true then 
push() signals again and also signal() is called.

FIX::ThreadedSocketConnection -- Another FIX::Queue and thread are 
added for sending.  pause() is implemented to set send queue signal 
property to false.  resume() is implemented to set send queue signal 
property to true.  IMPORTANT NOTE: I'd like to change things so that 
ThreadedSocketConnection *always* uses a send queue and thread.  Anyone 
have a problem with that?  If the new thread encounters a write error 
then that will be communicated back to the send() method at next 
enqueue attempt as per my previous email.

FIX::SocketConnection -- pause() is implemented to create a std::queue 
and make send() enqueue instead of send.  resume() is implemented to 
send everything on the queue and destroy the queue.  Alternatively I 
can make the queue hang around all the time if that is what people want 
(slight performance increase).  I'm only doing this for people who want 
a single thread *and* transactions.

FIX::Session -- admin messages are not wrapped in transactions and 
Responder::pause() and resume() are not called.  (They are persisted 
since auto-commit is on in MySQL.)  Session::begin() will be 
implemented to call pause() on the responder and then begin() on the 
message store (by way of the session state).  Session::commit() will be 
implemented to call commit() on the message store followed by resume() 
on the responder.  fromApp() will be wrapped as follows:

if( session state -> message store -> is transactional )
	begin();
fromApp(); // incrNextSenderSeqNum() calls and set() calls will be in 
the transaction
m_state.incrNextTargetMsgSeqNum(); // removed from verify(), also 
called if admin type
if( session state -> message store -> is transactional )
	commit();

Note that begin and commit are called conditionally instead of just 
being no-ops in the non-transactional case for sake of clarity.  
Otherwise someone might think that a transaction always takes place.

Within fromApp() the user may want to use MySQL within the same 
transaction for different purposes.  If there is not currently a method 
for exposing that then I will add one.

That's it so far...  Comments?  Concerns?

-John

On Dec 17, 2003, at 5:05 PM, John Muehlhausen wrote:

>
> Hello,
>
> I am making some changes to QuickFIX and would like feedback on the 
> plans.  I'm not sure how best to get the changes into the source tree 
> but that is my goal since I think they'll be generally useful and I'd 
> like to not patch future versions...  :-)  I'm hoping to get some 
> consensus on the work to be done so that my chances of getting the 
> changes incorporated are greater... and to benefit from the combined 
> wisdom of the group.  I am relatively new to QuickFIX so please bear 
> with me!  I would need a volunteer to get the Java wrappers done since 
> we are C++ only...
>
> First: I'd like to modify MySQLStore such that it uses the "prepared 
> statements" in version 4.1.1+.  I'm hoping for a significant 
> performance improvement.
>
> Second: I'd like to provide the option to store the received messages 
> in the 'messages' table in case the developer needs to look at those 
> messages for some other reason.  This would be less error prone than 
> remembering to manually persist received messages.  For reasons that 
> will become clear soon, this would happen at dequeue from the 
> ThreadedSocket* objects.
>
> The third proposal needs some motivation:
>
> In some applications the validity of sending a FIX message depends on 
> the success of sending another FIX message.  It would therefore be 
> nice to have an atomic unit of work that involves the processing and 
> sending of an arbitrary number of messages.  One simple example: the 
> developer wants to send an execution report AND a drop copy somewhere 
> else.  If the execution report doesn't happen then the drop copy 
> should not either (and vice versa).
>
> Proposed solution (using MySQL 4.1.1+ with BDB or InnoDB tables):
>
> a) Add begin() and commit() methods to MySQLStore (and perhaps nil 
> versions in MessageStore) which returns handle(s) useful for 
> performing other MySQL statements in the same transaction.  The 
> generalized transaction looks like this:
>
> 	begin transaction
> 	receive message from queue, persisting changes to next incoming 
> seqnum (can't take place in socket reader thread-- does it now?)
> 	business logic resulting in message send(s) and potentially in other 
> persistence within the same transaction
> 	commit transaction
>
> The problem here is that we cannot actually send messages unless we 
> get past commit-- otherwise we might advertise something that didn't 
> actually happen!  More on this follows... Also, the user manually 
> calls begin() and commit() if the enclosed send(s) and other 
> persistence are not in response to a received message.
>
> b) static Utility::socket_send() is re-implemented to place bytes on a 
> send queue instead of actually sending on the socket-- and there is 
> YAWT (yet another worker thread) draining this queue onto the socket.  
> There are two reasons for this-- first, bandwidth utilization may 
> increase if business logic can run concurrently (our in-house engine 
> has this).  Second, this provides a mechanism for stalling the actual 
> send until post-commit (more in the next point).  If the worker thread 
> encounters a write error then the queue is marked bad/emptied and 
> socket_send() returns the error encountered by the write instead of 
> performing the next enqueue.  The enqueued messages are lost but will 
> be resent at next session startup (gap fill).  BTW, I am aware that 
> socket_send() is static-- the socket handle is used with a global map 
> to obtain the queue associated with the socket.  Hmmm... since there 
> is really no reason to do this with the non-threaded incarnation of 
> QuickFIX perhaps the right place for this is a re-implementation of 
> ThreadedSocketConnection::send().
>
> c) when beginning the transaction, a barrier is placed on the write 
> queues of each active session (whether connected or not).  The barrier 
> means "don't send past this point, wait here".  All such barriers are 
> removed just after the transaction is committed.  This delays the send 
> of each message generated from within the transaction until after the 
> message and seqnum increment have been persisted -- a guarantee that 
> they are available for servicing future resend requests.
>
> High performance, reliable routing-type applications stand to benefit 
> the most from these changes.  If a process/server dies in the middle 
> of a transaction then the incoming message being acted on is 
> effectively "un-received" and any messages produced are not sent.  Of 
> course changes would be made in such a way as to not impact current 
> QuickFIX users.
>
> It would be nice if "someone" wanted to do all of this for BDBStore 
> (imaginary Berkeley DB transactional implementation of MessageStore) 
> in the cases where MySQL is not practical-- like a desktop 
> application.
>
> Comments? Concerns?
>
> Thanks,
> John
>