[Quickfix-developers] Problem in Sending and Recieving messages using QuickFIX

[Pramod.S.Warrier]

Hi,
I am using the quickfix engine and I am new to it. I am using the FIX 4.2 version.
I am trying to implement an initiator which will send QuoteRequest message to an acceptor. It works fine when I specific the NoRelatedSym=1. i.e., The acceptor receives
the QuoteRequest message sent by my initiator program. But when I use Repeating Groups (NoRelatedSym > 1), then the acceptor does not receive the messages send by the
initiator (fromApp function in Acceptor is not called). But in the initiator program it shows that it has sent the message to the acceptor and the message sent is also
logged in the Log File which is created.
I don't know where I am going wrong. So it would be really great if someone could please me help out.

Rgds,
Pramod.

[O***@thoughtworks.COM]

Do you get anything in your fromAdmin on your initiator after sending the
message? Like maybe a reject message?

--oren



|---------+----------------------------------------------->
| | "Pramod.S.Warrier" |
| | <***@infofin.com> |
| | Sent by: |
| | quickfix-developers-***@lists.sour|
| | ceforge.net |
| | |
| | |
| | 08/06/2002 04:13 AM |
| | |
|---------+----------------------------------------------->

----------------------------------------------------------------------------------------------|

| |
| To: quickfix-***@lists.sourceforge.net |
| cc: |
| Subject: [Quickfix-developers] Problem in Sending and Recieving messages using |
| QuickFIX |

----------------------------------------------------------------------------------------------|

Hi,
I am using the quickfix engine and I am new to it. I am using the FIX 4.2
version.
I am trying to implement an initiator which will send QuoteRequest
message to an acceptor. It works fine when I specific the NoRelatedSym=1.
i.e., The acceptor receives
the QuoteRequest message sent by my initiator program. But when I use
Repeating Groups (NoRelatedSym > 1), then the acceptor does not receive the
messages send by the
initiator (fromApp function in Acceptor is not called). But in the
initiator program it shows that it has sent the message to the acceptor and
the message sent is also
logged in the Log File which is created.
I don't know where I am going wrong. So it would be really great if
someone could please me help out.

Rgds,
Pramod.
(See attached file: pwarrier.vcf)

[Pramod.S.Warrier]

Hi,
Thanks for the quick response.
As for your query, the fromAdmin function of my initiator is also not called
and no reject message is received.
Besides for your information, the message thats displayed in the log file and
the toApp function is as given below.

The values i have entered is,
SenderCompID = CLIENT1
TargetCompID = TW
NoRelatedSym = 2
Symbol = IBM
Symbol = INTEL
QuoteReqID = QR1

and the message i get is

8=FIX.4.2`9=78`35=R`34=8`49=CLIENT1`52=20020806-12:23:43`56=TW`131=QR1`146=2`55=IBM`55=INTEL`10=082

What do you think are the possible areas where i could have erred ? Besides i
tried giving MassQuote and here too when theres a repeating group then the message
is not
recieved by the Acceptor. I hope theres no problems in the message that are being
generated.

Thanks,
Rgds,
Pramod.

Post by O***@thoughtworks.COM
Do you get anything in your fromAdmin on your initiator after sending the
message? Like maybe a reject message?
--oren
|---------+----------------------------------------------->
| | "Pramod.S.Warrier" |
| | Sent by: |
| | ceforge.net |
| | |
| | |
| | 08/06/2002 04:13 AM |
| | |
|---------+----------------------------------------------->

[O***@thoughtworks.COM]

Ok, this is what is probably going on. In order to parse messages with
repeating groups, you must supply a data dictionary to your receiving
application. It is the data dictionary that tells your app how to properly
parse these messages. FIX has certain rules about which field is the
delimiter, what order these fields need to be in etc. What is probably
happening is you don't have your data dictionary set to anything. It is
therefore considering the message garbled and the engine is ignoring it.
I'd say try assigining the FIX42.xml as the data dictionary to your
acceptor and see if you get better results.

--oren




"Pramod.S.Warrier"
@THOUGHTWORKS_COM To: ***@thoughtworks.COM
Sent by: cc:
***@THOUGHTWORKS_COM Subject: Re: [Quickfix-developers] Problem in Sending and Recieving messages
usingQuickFIX

08/06/2002 07:31 AM






Hi,
Thanks for the quick response.
As for your query, the fromAdmin function of my initiator is also not
called and no reject message is received.
Besides for your information, the message thats displayed in the log
file and the toApp function is as given below.

The values i have entered is,
SenderCompID = CLIENT1
TargetCompID = TW
NoRelatedSym = 2
Symbol = IBM
Symbol = INTEL
QuoteReqID = QR1

and the message i get is

8=FIX.4.2`9=78`35=R`34=8`49=CLIENT1`52=20020806-12:23:43`56=TW`131=QR1`146=2`55=IBM`55=INTEL`10=082


What do you think are the possible areas where i could have erred ?
Besides i tried giving MassQuote and here too when theres a repeating group
then the message is not
recieved by the Acceptor. I hope theres no problems in the message that are
being generated.

Thanks,
Rgds,
Pramod.

Post by O***@thoughtworks.COM
Do you get anything in your fromAdmin on your initiator after sending the
message? Like maybe a reject message?
--oren
|---------+----------------------------------------------->
| | "Pramod.S.Warrier" |
| | Sent by: |
| | ceforge.net |
| | |
| | |
| | 08/06/2002 04:13 AM |
| | |
|---------+----------------------------------------------->

----------------------------------------------------------------------------------------------|

Post by O***@thoughtworks.COM
|

|
|
|

Post by O***@thoughtworks.COM
| Subject: [Quickfix-developers] Problem in Sending and

Recieving messages using |

Post by O***@thoughtworks.COM
| QuickFIX

|
----------------------------------------------------------------------------------------------|
(See attached file: pwarrier.vcf)

[Pramod.S.Warrier]

Hi,
Yes you were exactly right. When I made the changes in the cfg file (pointed the DataDictionaryPath to the place where my XML file was) , my acceptor has started
receiving the messages with Repeating Groups also.
Thanks for the help.

Besides I have one more doubt and I hope you can help me out. The problem is that, I am now trying to use my initiator with the acceptor which uses SunGard FIXEngine
4.5. Here when I am trying to Logon, I am always receiving Logout message. That is because the authentication is failing or some other problem. But when I look at the Logs
of the SunGard program, it shows that it had received the Logon message from my initiator and it had also sent me the Logon message in response. But I am not receiving this
message. Besides this, the logs of the SunGard program says that there is some communication problem.
What could be the possible area where I am erring? And what are the possible reasons for communication problem ? I have posted this query to SunGard also. But if u
could help me out then it would be really great !!

Thanx and Rgds,
Pramod.

Post by O***@thoughtworks.COM
Ok, this is what is probably going on. In order to parse messages with
repeating groups, you must supply a data dictionary to your receiving
application. It is the data dictionary that tells your app how to properly
parse these messages. FIX has certain rules about which field is the
delimiter, what order these fields need to be in etc. What is probably
happening is you don't have your data dictionary set to anything. It is
therefore considering the message garbled and the engine is ignoring it.
I'd say try assigining the FIX42.xml as the data dictionary to your
acceptor and see if you get better results.
--oren

[O***@thoughtworks.COM]

Are they on different machines? First thing I would check is that their
clocks are synchronized (by default within 120 seconds of each other).
Alternatively you can turn this check off in QuickFIX by setting the
CheckLatency config to N. You can also change the amount of acceptable
latency by setting the MaxLatency field.

I definately think it is time to institute some quality logging into
QuickFIX...

--oren




"Pramod.S.Warrier"
@THOUGHTWORKS_COM To: ***@thoughtworks.COM
Sent by: cc: quickfix-***@lists.sourceforge.net,
***@THOUGHTWORKS_COM quickfix-developers-***@lists.sourceforge.net
Subject: Re: [Quickfix-developers] Problem in Sending and Recieving
messagesusingQuickFIX
08/06/2002 08:31 AM






Hi,
Yes you were exactly right. When I made the changes in the cfg file
(pointed the DataDictionaryPath to the place where my XML file was) , my
acceptor has started
receiving the messages with Repeating Groups also.
Thanks for the help.

Besides I have one more doubt and I hope you can help me out. The
problem is that, I am now trying to use my initiator with the acceptor
which uses SunGard FIXEngine
4.5. Here when I am trying to Logon, I am always receiving Logout message.
That is because the authentication is failing or some other problem. But
when I look at the Logs
of the SunGard program, it shows that it had received the Logon message
from my initiator and it had also sent me the Logon message in response.
But I am not receiving this
message. Besides this, the logs of the SunGard program says that there is
some communication problem.
What could be the possible area where I am erring? And what are the
possible reasons for communication problem ? I have posted this query to
SunGard also. But if u
could help me out then it would be really great !!

Thanx and Rgds,
Pramod.

Post by O***@thoughtworks.COM
Ok, this is what is probably going on. In order to parse messages with
repeating groups, you must supply a data dictionary to your receiving
application. It is the data dictionary that tells your app how to

properly

Post by O***@thoughtworks.COM
parse these messages. FIX has certain rules about which field is the
delimiter, what order these fields need to be in etc. What is probably
happening is you don't have your data dictionary set to anything. It is
therefore considering the message garbled and the engine is ignoring it.
I'd say try assigining the FIX42.xml as the data dictionary to your
acceptor and see if you get better results.
--oren

(See attached file: pwarrier.vcf)

[Pramod.S.Warrier]

Hi,
Yes they are on different messages. And as you suggested, first the problem was because of the Time not being
synchronised and that was displyed in the log file generated by the SunGard Engine and in the quickfix logs also I used to
get the error message (Sending Time Problem).
But now I have syncronised the time and the error messages that I had mailed you earlier were after making those changes.
Are there any other issues due to which such communication problems can arise? I mean are there any reasons for the initiator
not recieving the messages that are sent to it ?

Besides I also have another query. I wanted to know if I could test the messages that are being generated by my initiator
program without having to write the whole acceptor program ? I mean some site or some other application which will take as
input any FIX messages generated by my initiator and give as output whether the message is valid or not.

Thanks and Rgds,
Pramod.

Post by O***@thoughtworks.COM
Are they on different machines? First thing I would check is that their
clocks are synchronized (by default within 120 seconds of each other).
Alternatively you can turn this check off in QuickFIX by setting the
CheckLatency config to N. You can also change the amount of acceptable
latency by setting the MaxLatency field.
I definately think it is time to institute some quality logging into
QuickFIX...
--oren

[O***@thoughtworks.COM]

The other possibility is that SunGuard is sending a sequence number that is
lower than QuickFIX is expecting. This would cause QuickFIX to immediately
kill the connection.

--oren



"Pramod.S.Warrier"
@THOUGHTWORKS_COM To: ***@thoughtworks.COM
Sent by: cc: ***@ThoughtWorks.COM, quickfix-***@lists.sourceforge.net,
***@THOUGHTWORKS_COM quickfix-developers-***@lists.sourceforge.net
Subject: Re: [Quickfix-developers] Problem in Sending and
RecievingmessagesusingQuickFIX
08/06/2002 09:05 AM






Hi,
Yes they are on different messages. And as you suggested, first the
problem was because of the Time not being
synchronised and that was displyed in the log file generated by the SunGard
Engine and in the quickfix logs also I used to
get the error message (Sending Time Problem).
But now I have syncronised the time and the error messages that I had
mailed you earlier were after making those changes.
Are there any other issues due to which such communication problems can
arise? I mean are there any reasons for the initiator
not recieving the messages that are sent to it ?

Besides I also have another query. I wanted to know if I could test the
messages that are being generated by my initiator
program without having to write the whole acceptor program ? I mean some
site or some other application which will take as
input any FIX messages generated by my initiator and give as output whether
the message is valid or not.

Thanks and Rgds,
Pramod.

Post by O***@thoughtworks.COM
Are they on different machines? First thing I would check is that their
clocks are synchronized (by default within 120 seconds of each other).
Alternatively you can turn this check off in QuickFIX by setting the
CheckLatency config to N. You can also change the amount of acceptable
latency by setting the MaxLatency field.
I definately think it is time to institute some quality logging into
QuickFIX...
--oren

(See attached file: pwarrier.vcf)

[Pramod.S.Warrier]

Hi,
I dont think that is the case. Because its not the quickfix which is issuing the Logoff message. Its the SunGard Engine that is
closing the connection and sending my program the logoff message (onLogoff function is being called). And its written in the log file of
SunGard that this may be because of some communication problem. As for my initiator its only sending Logon messages to the SunGrad
acceptor. And retrying after the ReconnectInterval specified after it gets a Logoff message from the other side.
So i would like to know the possible reasons for getting these communication problems using QuickFIX ?

Thanks and Regards,
Pramod.

Post by O***@thoughtworks.COM
The other possibility is that SunGuard is sending a sequence number that is
lower than QuickFIX is expecting. This would cause QuickFIX to immediately
kill the connection.
--oren

[Pramod.S.Warrier]

Hi,
The communication problem of SunGard FIX Engine and QuickFix is solved using a configuration option of SunGard Engine. According to
SunGard support, QuickFix (client) is not able to accept long logon message. I'm not clear on this. Following are the lines from their
mail :


It seems that your FIX client cannot accept long logon messages, and stops communication because of that --- even though long logon
messages are part of the FIX 4.2 protocol.

To suppress the long logon message, add SUPPORT_ROLE=N to the configuration file.

Can anyone help me with these long logon messages?

Thanks and Regards,
Pramod.

[O***@thoughtworks.COM]

Hmmm. I have to say I do not know what they are refering to, and I don't
see that terminology anywhere in the spec. Is it possible you can get some
clarification from SunGuard on what that is? If you could also provide a
sample of such a message that would be extremely useful as well.

--oren



|---------+----------------------------------------------->
| | "Pramod.S.Warrier" |
| | <***@infofin.com> |
| | Sent by: |
| | quickfix-developers-***@lists.sour|
| | ceforge.net |
| | |
| | |
| | 08/07/2002 04:45 AM |
| | |
|---------+----------------------------------------------->

----------------------------------------------------------------------------------------------|

| |
| To: ***@thoughtworks.COM |
| cc: ***@ThoughtWorks.COM, quickfix-***@lists.sourceforge.net, |
| quickfix-developers-***@lists.sourceforge.net |
| Subject: Re: [Quickfix-developers] Problem in Sending |
| andRecievingmessagesusingQuickFIX |

----------------------------------------------------------------------------------------------|

Hi,
The communication problem of SunGard FIX Engine and QuickFix is solved
using a configuration option of SunGard Engine. According to
SunGard support, QuickFix (client) is not able to accept long logon
message. I'm not clear on this. Following are the lines from their
mail :


It seems that your FIX client cannot accept long logon messages, and
stops communication because of that --- even though long logon
messages are part of the FIX 4.2 protocol.

To suppress the long logon message, add SUPPORT_ROLE=N to the configuration
file.

Can anyone help me with these long logon messages?

Thanks and Regards,
Pramod.


(See attached file: pwarrier.vcf)

[Pramod.S.Warrier]

Hi,
I have got the reply from the SunGard support team regarding the long
logon message. Following are the lines from mail that i received from
them.

"As for the long logon message. You can find its definition in the
FIX
4.2 logon message definition. It is not mentioned as "long" logon, but
it contains an optional list of message types that are supported. When
using these optional fields, you get a logon message. When you don't,
the logon message is short."

I hope your query has been solved and I would really like to know if
this could be the problem in communicating between the SunGard and
QuickFix Engine? Doesn't the QuickFix support Logon message with
optional fields included ?

Thanks and Regards,
Pramod.

Post by O***@thoughtworks.COM
Hmmm. I have to say I do not know what they are refering to, and I don't
see that terminology anywhere in the spec. Is it possible you can get some
clarification from SunGuard on what that is? If you could also provide a
sample of such a message that would be extremely useful as well.
--oren

[O***@thoughtworks.COM]

Ah ok. There is no reason that I can think of that QuickFIX should have a
problem with those messages, but adding an explicit test case will tell us
for sure. Is it possible for you to send us the message that Sunguard is
generating for the long logon? If so we can plug that message straight into
our test suite and make sure that we are supporting it properly.

--oren



|---------+----------------------------------->
| | "Pramod.S.Warrier" |
| | @THOUGHTWORKS_COM |
| | Sent by: |
| | ***@THOUGHTWORKS_COM |
| | |
| | |
| | 08/10/2002 12:23 AM |
| | |
|---------+----------------------------------->

------------------------------------------------------------------------------------------------------------------------------|

| |
| To: ***@thoughtworks.COM |
| cc: ***@ThoughtWorks.COM, quickfix-***@lists.sourceforge.net, |
| quickfix-developers-***@lists.sourceforge.net |
| Subject: Re: [Quickfix-developers] Problem in SendingandRecievingmessagesusingQuickFIX |

------------------------------------------------------------------------------------------------------------------------------|

Hi,
I have got the reply from the SunGard support team regarding
the long
logon message. Following are the lines from mail that i received from
them.

"As for the long logon message. You can find its definition in
the
FIX
4.2 logon message definition. It is not mentioned as "long" logon, but
it contains an optional list of message types that are supported. When
using these optional fields, you get a logon message. When you don't,
the logon message is short."

I hope your query has been solved and I would really like to
know if
this could be the problem in communicating between the SunGard and
QuickFix Engine? Doesn't the QuickFix support Logon message with
optional fields included ?

Thanks and Regards,
Pramod.

Hmmm. I have to say I do not know what they are refering to, and I don't
see that terminology anywhere in the spec. Is it possible you can get

some

clarification from SunGuard on what that is? If you could also provide a
sample of such a message that would be extremely useful as well.
--oren
(See attached file: pwarrier.vcf)

[Pramod.S.Warrier]

Hi,
I have attached the log file that was generated by the SunGard
Acceptor that I am using. In the log file, the logon message sent by
them contains the list of message types that are accepted by the
SunGard Engine.

Thanks and Regards,
Pramod.

Post by O***@thoughtworks.COM
Ah ok. There is no reason that I can think of that QuickFIX should have a
problem with those messages, but adding an explicit test case will tell us
for sure. Is it possible for you to send us the message that Sunguard is
generating for the long logon? If so we can plug that message straight into
our test suite and make sure that we are supporting it properly.
--oren

[O***@thoughtworks.COM]

Pramod,

Very helpful. It looks like SunGuard is not generating this message quite
correctly. If you look at the logon they are sending, it contains a
repeating group as such:

384=92
35=A
385=R
35=A
385=S
35=0
385=R
35=0
385=S
35=1
385=R
...

Field 384 is the begining of the repeating group saying that there are 92
repeating instances. The message than goes on to list the message types
the application supports and their directions. The problem is that they
are using field 35 (MsgType) to convey the supported message types wheras
the FIX spec requires that field 372 (RefMsgType) be used. QuickFIX is
therefore rejecting the message as invalid. You might want to write to
sunguard and let them know that in future versions they may want to start
using field 372 in accordance with the spec (or you can probably just
forward this to them)

In the meantime, QuickFIX can support receiving these messages. All you
need to do is modify the XML data dictionary that QuickFIX uses for
SunGuard connections to reflect their proprietary variation of this
message. In FIX42.xml you can simply change the following section:

<group number="384" name="NoMsgTypes">
<field number="372" name="RefMsgType" required="N" />
<field number="385" name="MsgDirection" required="N" />
</group>

to look like this:

<group number="384" name="NoMsgTypes">
<field number="35" name="MsgType" required="N" />
<field number="385" name="MsgDirection" required="N" />
</group>

I hope this resolves your QuickFIX<->SunGuard connectivity issues while
using long logon messages. Give my best to the folks at SunGuard.

--oren



|---------+----------------------------------->
| | "Pramod.S.Warrier" |
| | @THOUGHTWORKS_COM |
| | Sent by: |
| | ***@THOUGHTWORKS_COM |
| | |
| | |
| | 08/12/2002 09:14 AM |
| | |
|---------+----------------------------------->

------------------------------------------------------------------------------------------------------------------------------|

| |
| To: ***@thoughtworks.COM |
| cc: ***@ThoughtWorks.COM, quickfix-***@lists.sourceforge.net, |
| quickfix-developers-***@lists.sourceforge.net |
| Subject: Re: [Quickfix-developers] Problem inSendingandRecievingmessagesusingQuickFIX |

------------------------------------------------------------------------------------------------------------------------------|

Hi,
I have attached the log file that was generated by the SunGard
Acceptor that I am using. In the log file, the logon message sent by
them contains the list of message types that are accepted by the
SunGard Engine.

Thanks and Regards,
Pramod.

Ah ok. There is no reason that I can think of that QuickFIX should have

a

problem with those messages, but adding an explicit test case will tell

us

for sure. Is it possible for you to send us the message that Sunguard is
generating for the long logon? If so we can plug that message straight

into

our test suite and make sure that we are supporting it properly.
--oren
2002-08-12 13:20:22.654 -0- ACCEPTOR_QFTARGET> SUNGARD FIX Engine version

4.5 - SunGard 2002 Copyright (c)
2002-08-12 13:20:22.654 -0- ACCEPTOR_QFTARGET> Expires on 2002-12-31
2002-08-12 13:20:22.724 -0- ACCEPTOR_QFTARGET> # The setup parameters for
this session :
2002-08-12 13:20:22.724 -0- ACCEPTOR_QFTARGET> #
---------------------------------------
2002-08-12 13:20:22.734 -0- ACCEPTOR_QFTARGET> # MODE = STORE_AND_FORWARD
2002-08-12 13:20:22.734 -0- ACCEPTOR_QFTARGET> # SESSION_ID =
ACCEPTOR_QFTARGET
2002-08-12 13:20:22.734 -0- ACCEPTOR_QFTARGET> # SENDER_COMP_ID = ACCEPTOR
2002-08-12 13:20:22.734 -0- ACCEPTOR_QFTARGET> # TARGET_COMP_ID = QFTARGET
2002-08-12 13:20:22.734 -0- ACCEPTOR_QFTARGET> # FIX_VERSION = FIX.4.2
2002-08-12 13:20:22.734 -0- ACCEPTOR_QFTARGET> # LOG_FILE_LEVEL = 3
2002-08-12 13:20:22.734 -0- ACCEPTOR_QFTARGET> # LOG_AUTO_FLUSH = 1
2002-08-12 13:20:22.744 -0- ACCEPTOR_QFTARGET> # PTP_LATENCY = 5
2002-08-12 13:20:22.744 -0- ACCEPTOR_QFTARGET> # PTP_TIME_OUT = 50
2002-08-12 13:20:22.744 -0- ACCEPTOR_QFTARGET> # PTP_CONNECTION = TCPServer
2002-08-12 13:20:22.744 -0- ACCEPTOR_QFTARGET> # TCP_PORT = 9000
2002-08-12 13:20:22.744 -0- ACCEPTOR_QFTARGET> # ON_UNKNOWN_REJECT = CLOSE
2002-08-12 13:20:22.754 -0- ACCEPTOR_QFTARGET> # STORAGE_TYPE = FILE
2002-08-12 13:20:22.754 -0- ACCEPTOR_QFTARGET> # RMI_HOST = 127.0.0.1
2002-08-12 13:20:22.754 -0- ACCEPTOR_QFTARGET> # RMI_PORT = 9999
2002-08-12 13:20:22.754 -0- ACCEPTOR_QFTARGET> # OPERATOR_LOG_BUFFER = 0
2002-08-12 13:20:22.754 -0- ACCEPTOR_QFTARGET> # OPERATOR_LOG_REFRESH = 0
2002-08-12 13:20:22.754 -0- ACCEPTOR_QFTARGET> # MSG_TYPES_SUPPORT_SEND =
ALL
2002-08-12 13:20:22.754 -0- ACCEPTOR_QFTARGET> # MSG_TYPES_SUPPORT_RECEIVE
= ALL
2002-08-12 13:20:22.754 -0- ACCEPTOR_QFTARGET> # SET_CMD = set
2002-08-12 13:20:22.754 -0- ACCEPTOR_QFTARGET> # HEARTBT_INT = 60
2002-08-12 13:20:22.754 -0- ACCEPTOR_QFTARGET> # RESTORE_TIMEOUT = 10
2002-08-12 13:20:22.764 -0- ACCEPTOR_QFTARGET> # POST_LOGIN_TIMEOUT = 10
2002-08-12 13:20:22.764 -0- ACCEPTOR_QFTARGET> # IN_SYNC_TIMEOUT = 25
2002-08-12 13:20:22.764 -0- ACCEPTOR_QFTARGET> # IN_EOD_TIMEOUT = 10
2002-08-12 13:20:22.774 -0- ACCEPTOR_QFTARGET> # ENCRYPT_METHOD = 0
2002-08-12 13:20:22.774 -0- ACCEPTOR_QFTARGET> # ENC_FILE_NAME =
ACCEPTOR_QFTARGET_logon.txt
2002-08-12 13:20:22.774 -0- ACCEPTOR_QFTARGET> # IN_SEQ_NUM_NAME =
ACCEPTOR_QFTARGET_IN
2002-08-12 13:20:22.774 -0- ACCEPTOR_QFTARGET> # OUT_SEQ_NUM_NAME =
ACCEPTOR_QFTARGET_OUT
2002-08-12 13:20:22.784 -0- ACCEPTOR_QFTARGET> # WORK_DIRECTORY = .
\Acceptor\
2002-08-12 13:20:22.784 -0- ACCEPTOR_QFTARGET> # OUTGOING_DBS_NAME =
ACCEPTOR_QFTARGET_OUT
2002-08-12 13:20:22.784 -0- ACCEPTOR_QFTARGET> # HEARTBT_LATENCY = 5
2002-08-12 13:20:22.794 -0- ACCEPTOR_QFTARGET> # LOGON_INITIATOR = true
2002-08-12 13:20:22.794 -0- ACCEPTOR_QFTARGET> # LAST_EOD_PERFORMED_NAME =
ACCEPTOR_QFTARGET_LAST_EOD_PERFORMED
2002-08-12 13:20:22.794 -0- ACCEPTOR_QFTARGET> # IN_EOD_NAME =
ACCEPTOR_QFTARGET_IN_EOD
2002-08-12 13:20:22.794 -0- ACCEPTOR_QFTARGET> # EOD_SENT_NAME =
ACCEPTOR_QFTARGET_EOD_SENT
2002-08-12 13:20:22.794 -0- ACCEPTOR_QFTARGET> # EOD_RECEIVED_NAME =
ACCEPTOR_QFTARGET_EOD_RECEIVED
2002-08-12 13:20:22.794 -0- ACCEPTOR_QFTARGET> # RECONNECT_COUNT = 3
2002-08-12 13:20:22.794 -0- ACCEPTOR_QFTARGET> # SUPPORT_ROLE = true
2002-08-12 13:20:22.794 -0- ACCEPTOR_QFTARGET> # End of the setup
parameters for this session.
2002-08-12 13:20:22.794 -0- ACCEPTOR_QFTARGET> #
---------------------------------------------
2002-08-12 13:20:22.854 -0- ACCEPTOR_QFTARGET> FIX formatter created
[FixFormatter version: FIX.4.2]
2002-08-12 13:20:22.944 -0- ACCEPTOR_QFTARGET> PTP connection created
[TCP/IP-Server(null:9000)]
2002-08-12 13:20:23.115 -0- ACCEPTOR_QFTARGET> Encryption Factory created
[No Encryption [0]]
2002-08-12 13:20:23.155 -0- ACCEPTOR_QFTARGET> Registering RMI service
Operator/FIXSession/ACCEPTOR/QFTARGET ...
2002-08-12 13:20:23.155 -0- ACCEPTOR_QFTARGET> RMI service
Operator/FIXSession/ACCEPTOR/QFTARGET is ready.
2002-08-12 13:20:23.175 -0- ACCEPTOR_QFTARGET> FIX Engine ACCEPTOR_QFTARGET
created successfully.
2002-08-12 13:20:23.205 -1- ACCEPTOR_QFTARGET> Clear PTP: cleared PTP
incoming queue, stopped outgoing queue dispatcher and cleared outgoing PTP
queue.
2002-08-12 13:20:23.205 -0- ACCEPTOR_QFTARGET> FIX Engine started...
2002-08-12 13:20:24.597 -2- ACCEPTOR_QFTARGET> APPL request to open
connection.
2002-08-12 13:20:24.617 -1- ACCEPTOR_QFTARGET> Fix state changed from
Closed to InConnect. Reason: API REQUEST [0] Open
2002-08-12 13:20:24.627 -1- ACCEPTOR_QFTARGET> Clear PTP: cleared PTP
incoming queue, stopped outgoing queue dispatcher and cleared outgoing PTP
queue.
2002-08-12 13:20:24.627 -1- ACCEPTOR_QFTARGET> Trying to open PTP
communication.
2002-08-12 13:20:24.647 -2- ACCEPTOR_QFTARGET> API state changed from:
CLOSED to: CONNECTING
2002-08-12 13:20:24.897 -1- ACCEPTOR_QFTARGET> Fix state changed from
InConnect to InLogin. Reason: PARTNER REQUEST [1] Opened PTP connection
successfully
2002-08-12 13:20:24.917 -3- ACCEPTOR_QFTARGET> Received message from PTP
with sequence number greater than expected. 8=FIX.4.2
9=67
35=A
34=2

49=QFTARGET
52=20020812-13:20:14
56=ACCEPTOR
98=0
108=60
10=224

2002-08-12 13:20:24.967 -1- ACCEPTOR_QFTARGET> sent Login message in
response to Login received. 35=A
49=ACCEPTOR
56=QFTARGET
34=1

52=20020812-07:50:24.927
98=0
108=60
384=92
35=A
385=R
35=A
385=S
35=0

385=R
35=0
385=S
35=1
385=R
35=1
385=S
35=2
385=R
35=2
385=S
35=3
385=R

35=3
385=S
35=4
385=R
35=4
385=S
35=5
385=R
35=5
385=S
35=6
385=S
35=7

385=S
35=8
385=S
35=9
385=S
35=B
385=S
35=C
385=S
35=D
385=S
35=E
385=S

35=F
385=S
35=G
385=S
35=H
385=S
35=J
385=S
35=K
385=S
35=L
385=S
35=M

385=S
35=N
385=S
35=P
385=S
35=Q
385=S
35=R
385=S
35=S
385=S
35=T
385=S

35=V
385=S
35=W
385=S
35=X
385=S
35=Y
385=S
35=Z
385=S
35=a
385=S
35=b

385=S
35=c
385=S
35=d
385=S
35=e
385=S
35=f
385=S
35=g
385=S
35=h
385=S

35=i
385=S
35=j
385=S
35=k
385=S
35=l
385=S
35=m
385=S
35=6
385=R
35=7

385=R
35=8
385=R
35=9
385=R
35=B
385=R
35=C
385=R
35=D
385=R
35=E
385=R

35=F
385=R
35=G
385=R
35=H
385=R
35=J
385=R
35=K
385=R
35=L
385=R
35=M

385=R
35=N
385=R
35=P
385=R
35=Q
385=R
35=R
385=R
35=S
385=R
35=T
385=R

35=V
385=R
35=W
385=R
35=X
385=R
35=Y
385=R
35=Z
385=R
35=a
385=R
35=b

385=R
35=c
385=R
35=d
385=R
35=e
385=R
35=f
385=R
35=g
385=R
35=h
385=R

35=i
385=R
35=j
385=R
35=k
385=R
35=l
385=R
35=m
385=R

2002-08-12 13:20:24.977 -1- ACCEPTOR_QFTARGET> Fix state changed from
InLogin to PostLogin. Reason: PARTNER REQUEST [1] Received logon message
2002-08-12 13:20:24.987 -1- ACCEPTOR_QFTARGET> saved message received on
incoming PTP queue for later use.
2002-08-12 13:20:25.007 -1- ACCEPTOR_QFTARGET> sent ResendRequest message.
35=2
49=ACCEPTOR
56=QFTARGET
34=2
52=20020812-07:50:24.987
7=1
16=1

2002-08-12 13:20:25.007 -1- ACCEPTOR_QFTARGET> Starting Restore Timer until
sequence number 1 is received.
2002-08-12 13:20:25.518 -1- ACCEPTOR_QFTARGET> Fix state changed from
PostLogin to InConnect. Reason: COMMUNICATION PROBLEM [6] PTP
communication closed while in an open communication state.
2002-08-12 13:20:25.518 -1- ACCEPTOR_QFTARGET> Stopped RestoreState timer.
2002-08-12 13:20:25.628 -1- ACCEPTOR_QFTARGET> Clear PTP: cleared PTP
incoming queue, stopped outgoing queue dispatcher and cleared outgoing PTP
queue.
(See attached file: pwarrier.vcf)