Thread: Re: [Quickfix-developers] mixed up pasting - please look here for details
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: <gar...@su...> - 2003-03-04 21:41:01
|
Yes, the data dictionary is exactly the same as the working version. One of the things I was wondering was whether it mattered where the native libraries were compiled. Right now I am packaging all the native libraries (stdc++, quickfix, quickfix_jni, xml2, and stlport) on one machine and am including those in my deployment package. Is it a coincidence that the machine that this works for is the same machine the libraries were compiled on? Also, does the order of the fields as they appear in the message store have any indication as to the order that is used when parsing and generating the message? As I mentioned in a different thread, I have an Incoming message store where I store every message received by the FIX engine. When I look at the allocation message in that message store, it does appear that some of the fields are not in the same order as in the FileStore of the sending FIX engine. Could the saving of the message into another message store somehow corrupt the field order? Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com Oren Miller <ore...@ya...> Sent by: To: gar...@su..., qui...@li... qui...@li...ur cc: ceforge.net Subject: Re: [Quickfix-developers] mixed up pasting - please look here for details 03/04/03 04:32 PM Please respond to omiller Did you copy your data dictionary over to the new machine? The data dictionary of the receiving application would need to have the proper groups defined. --- gar...@su... wrote: > Oops - please ignore the prior email. I mixed up > the pasting of the > messages.... > > > > > I've run into a serious problem that I haven't been > able to figure out. > > In trying to send across allocation messages (which > contain groups), I am > able to successfully do so on my development > platform. When I move the > receiving FIX engine to another environment (same > class machine, same java > version, same OS version-solaris 8), the receiving > side is unable to parse > the allocation message correctly which causes the > processing to fail. > > My outgoing message appears to be right in its XML > form while the incoming > message does not show the repeating group entries. > I am also including the > 'raw' format as printed in the output: > > Does anyone have any suggestions as to how to > proceed resolving this > problem? This is now holding up our UAT and > production release schedules. > > Thanks for any help, > Gary > > Outgoing > ========= > > <20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST, > outgoing> > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > > <message> > <header> > <field number="8" value="FIX.4.2"/> > <field number="9" value="372"/> > <field number="35" value="J"/> > </header> > <body> > <field number="6" value="99.991667"/> > <field number="15" value="USD"/> > <field number="22" value="1"/> > <field number="48" value="CUSIP"/> > <field number="53" value="1000000"/> > <field number="54" value="1"/> > <field number="55" value="FIXED"/> > <field number="60" value="20030304-20:12:54"/> > <field number="70" value="Allocation: 0"/> > <field number="71" value="3"/> > <field number="73" value="1"/> > <field number="75" value="20030304"/> > <field number="78" value="1"/> > <field number="106" value="GECC"/> > <field number="118" value="100"/> > <field number="124" value="1"/> > <field number="381" value="999916.67"/> > <field number="6609" value="CP"/> > <field number="6611" value="100"/> > <field number="6613" value="MONEYMARKET"/> > <field number="6614" value="1"/> > <field number="6629" value="MATURITY"/> > <field number="6637" value="20031204"/> > <group> > <field number="11" value="NONREF"/> > <field number="37" value="155882"/> > </group> > <group> > <field number="79" value="FCUSM"/> > <field number="80" value="1000000"/> > <field number="76" value="GECC"/> > <field number="154" value="999916.67"/> > <field number="6604" value="PartAllocID:1"/> > </group> > <group> > <field number="32" value="1000000"/> > <field number="17" > value="155882_20031204_151254"/> > <field number="31" value="3"/> > <field number="6640" value="99.991667"/> > </group> > </body> > <trailer> > > > > > Incoming > ========== > <20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST, > incoming> > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > <message> > <header> > <field number="8" value="FIX.4.2"/> > <field number="9" value="424"/> > <field number="35" value="J"/> > <field number="34" value="474"/> > <field number="49" value="FMRFITST"/> > <field number="52" value="20030304-20:12:56"/> > <field number="56" value="STNMMTST"/> > </header> > <body> > <field number="6" value="99.991667"/> > <field number="11" value="NONREF"/> > <field number="15" value="USD"/> > <field number="17" > value="155882_20031204_151254"/> > <field number="22" value="1"/> > <field number="31" value="3"/> > <field number="32" value="1000000"/> > <field number="37" value="155882"/> > <field number="48" value="CUSIP"/> > <field number="53" value="1000000"/> > <field number="54" value="1"/> > <field number="55" value="FIXED"/> > <field number="60" value="20030304-20:12:54"/> > <field number="70" value="Allocation: 0"/> > <field number="71" value="3"/> > <field number="73" value="1"/> > <field number="75" value="20030304"/> > <field number="76" value="GECC"/> > <field number="78" value="1"/> > <field number="79" value="FCUSM"/> > <field number="80" value="1000000"/> > <field number="106" value="GECC"/> > <field number="118" value="100"/> > <field number="124" value="1"/> > <field number="154" value="999916.67"/> > <field number="381" value="999916.67"/> > <field number="6604" value="PartAllocID:1"/> > <field number="6609" value="CP"/> > <field number="6611" value="100"/> > <field number="6613" value="MONEYMARKET"/> > <field number="6614" value="1"/> > <field number="6629" value="MATURITY"/> > <field number="6637" value="20031204"/> > <field number="6640" value="99.991667"/> > </body> > <trailer> > <field number="10" value="053"/> > </trailer> > </message> > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave > you feeling lost and > disoriented. TotalView can help you find your way. > Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: <gar...@su...> - 2003-03-04 21:49:15
|
Actually, my xml printout of the trade happens before I store the incoming message so saving it can't be the reason why the message is not getting parsed correctly.... Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com gar...@su... Sent by: To: om...@th... qui...@li...ur cc: qui...@li..., ceforge.net qui...@li... Subject: Re: [Quickfix-developers] mixed up pasting - please look here for details 03/04/03 04:40 PM Yes, the data dictionary is exactly the same as the working version. One of the things I was wondering was whether it mattered where the native libraries were compiled. Right now I am packaging all the native libraries (stdc++, quickfix, quickfix_jni, xml2, and stlport) on one machine and am including those in my deployment package. Is it a coincidence that the machine that this works for is the same machine the libraries were compiled on? Also, does the order of the fields as they appear in the message store have any indication as to the order that is used when parsing and generating the message? As I mentioned in a different thread, I have an Incoming message store where I store every message received by the FIX engine. When I look at the allocation message in that message store, it does appear that some of the fields are not in the same order as in the FileStore of the sending FIX engine. Could the saving of the message into another message store somehow corrupt the field order? Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com Oren Miller <ore...@ya...> Sent by: To: gar...@su..., qui...@li... qui...@li...ur cc: ceforge.net Subject: Re: [Quickfix-developers] mixed up pasting - please look here for details 03/04/03 04:32 PM Please respond to omiller Did you copy your data dictionary over to the new machine? The data dictionary of the receiving application would need to have the proper groups defined. --- gar...@su... wrote: > Oops - please ignore the prior email. I mixed up > the pasting of the > messages.... > > > > > I've run into a serious problem that I haven't been > able to figure out. > > In trying to send across allocation messages (which > contain groups), I am > able to successfully do so on my development > platform. When I move the > receiving FIX engine to another environment (same > class machine, same java > version, same OS version-solaris 8), the receiving > side is unable to parse > the allocation message correctly which causes the > processing to fail. > > My outgoing message appears to be right in its XML > form while the incoming > message does not show the repeating group entries. > I am also including the > 'raw' format as printed in the output: > > Does anyone have any suggestions as to how to > proceed resolving this > problem? This is now holding up our UAT and > production release schedules. > > Thanks for any help, > Gary > > Outgoing > ========= > > <20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST, > outgoing> > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > > <message> > <header> > <field number="8" value="FIX.4.2"/> > <field number="9" value="372"/> > <field number="35" value="J"/> > </header> > <body> > <field number="6" value="99.991667"/> > <field number="15" value="USD"/> > <field number="22" value="1"/> > <field number="48" value="CUSIP"/> > <field number="53" value="1000000"/> > <field number="54" value="1"/> > <field number="55" value="FIXED"/> > <field number="60" value="20030304-20:12:54"/> > <field number="70" value="Allocation: 0"/> > <field number="71" value="3"/> > <field number="73" value="1"/> > <field number="75" value="20030304"/> > <field number="78" value="1"/> > <field number="106" value="GECC"/> > <field number="118" value="100"/> > <field number="124" value="1"/> > <field number="381" value="999916.67"/> > <field number="6609" value="CP"/> > <field number="6611" value="100"/> > <field number="6613" value="MONEYMARKET"/> > <field number="6614" value="1"/> > <field number="6629" value="MATURITY"/> > <field number="6637" value="20031204"/> > <group> > <field number="11" value="NONREF"/> > <field number="37" value="155882"/> > </group> > <group> > <field number="79" value="FCUSM"/> > <field number="80" value="1000000"/> > <field number="76" value="GECC"/> > <field number="154" value="999916.67"/> > <field number="6604" value="PartAllocID:1"/> > </group> > <group> > <field number="32" value="1000000"/> > <field number="17" > value="155882_20031204_151254"/> > <field number="31" value="3"/> > <field number="6640" value="99.991667"/> > </group> > </body> > <trailer> > > > > > Incoming > ========== > <20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST, > incoming> > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > <message> > <header> > <field number="8" value="FIX.4.2"/> > <field number="9" value="424"/> > <field number="35" value="J"/> > <field number="34" value="474"/> > <field number="49" value="FMRFITST"/> > <field number="52" value="20030304-20:12:56"/> > <field number="56" value="STNMMTST"/> > </header> > <body> > <field number="6" value="99.991667"/> > <field number="11" value="NONREF"/> > <field number="15" value="USD"/> > <field number="17" > value="155882_20031204_151254"/> > <field number="22" value="1"/> > <field number="31" value="3"/> > <field number="32" value="1000000"/> > <field number="37" value="155882"/> > <field number="48" value="CUSIP"/> > <field number="53" value="1000000"/> > <field number="54" value="1"/> > <field number="55" value="FIXED"/> > <field number="60" value="20030304-20:12:54"/> > <field number="70" value="Allocation: 0"/> > <field number="71" value="3"/> > <field number="73" value="1"/> > <field number="75" value="20030304"/> > <field number="76" value="GECC"/> > <field number="78" value="1"/> > <field number="79" value="FCUSM"/> > <field number="80" value="1000000"/> > <field number="106" value="GECC"/> > <field number="118" value="100"/> > <field number="124" value="1"/> > <field number="154" value="999916.67"/> > <field number="381" value="999916.67"/> > <field number="6604" value="PartAllocID:1"/> > <field number="6609" value="CP"/> > <field number="6611" value="100"/> > <field number="6613" value="MONEYMARKET"/> > <field number="6614" value="1"/> > <field number="6629" value="MATURITY"/> > <field number="6637" value="20031204"/> > <field number="6640" value="99.991667"/> > </body> > <trailer> > <field number="10" value="053"/> > </trailer> > </message> > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > for complex code. Debugging C/C++ programs can leave > you feeling lost and > disoriented. TotalView can help you find your way. > Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: <gar...@su...> - 2003-03-04 22:17:03
|
Here is the message as it is stored on the sending side (where it looks=
right)
8=3DFIX.4.2=019=3D414=0135=3DJ=0134=3D4=0149=3DFMRFITST=0152=3D20030304=
-22:06:54=0156=3DSTNMMTST=01
6=3D99.991667=0115=3DUSD=0122=3D1=0148=3DCUSIP=0153=3D1000000=0154=3D1=01=
55=3DFIXED=01
60=3D20030304-21:14:27=0170=3DAllocation: 0=0171=3D3=0173=3D1=0111=3DNO=
NREF=0137=3D155888=01
75=3D20030304=0178=3D1=0179=3DFCUSM=0180=3D1000000=01154=3D999916.67=01=
6604=3DPartAllocID:1=01
106=3DGECC=01118=3D100=01124=3D1=0132=3D1000000=0117=3D155888_20031404_=
161427=0131=3D3=01
6640=3D99.991667=01381=3D999916.67=016609=3DCP=016611=3D100=016613=3DMO=
NEYMARKET=016614=3D1=01
6629=3DMATURITY=016637=3D20030604=0110=3D038=01
Here is the message as it is stored in my incoming message store (on th=
e
side that it is wrong)
8=3DFIX.4.2=019=3D414=0135=3DJ=0134=3D4=0149=3DFMRFITST=0152=3D20030304=
-22:06:54=0156=3DSTNMMTST=01
6=3D99.991667=0111=3DNONREF=0115=3DUSD=0117=3D155888_20031404_161427=01=
22=3D1=0131=3D3=0132=3D1000000
=0137=3D155888=0148=3DCUSIP=0153=3D1000000=0154=3D1=0155=3DFIXED=0160=3D=
20030304-21:14:27=01
70=3DAllocation: 0=0171=3D3=0173=3D1=0175=3D20030304=0178=3D1=0179=3DFC=
USM=0180=3D1000000=01106=3DGECC=01
118=3D100=01124=3D1=01154=3D999916.67=01381=3D999916.67=016604=3DPartAl=
locID:1=016609=3DCP=01
6611=3D100=016613=3DMONEYMARKET=016614=3D1=016629=3DMATURITY=016637=3D2=
0030604=016640=3D99.991667
=0110=3D038=01
Here also is my fromApp implementation so you can see that I am printin=
g
out the xml of the trade before storing it:
public void fromApp(org.quickfix.Message message,
SessionID sessionID)
throws FieldNotFound, UnsupportedMessageType, IncorrectTagValue=
{
LogUtil.debug ("Message received (" + sessionID + ") type: " +
message.getClass() + "\n " + message.toXML());
storeIncomingMessage (message, sessionID);
crack((org.quickfix.Message) message, sessionID);
}
Gary Mui
Prescient Markets, Inc 914-989-3118 (W)
445 Hamilton Avenue 914-422-3693 (F)
White Plains, NY 10601
Please visit us at http://www.cpmarket.com
=
=
=20
Oren Miller <ore...@ya...> =
=
=20
Sent by: To: =
qui...@li..., =
=20
qui...@li...ur quic=
kfi...@li... =
=20
ceforge.net cc: =
=
=20
Subj=
ect: Re: [Quickfix-developers] mixed up pasting - please look here for =
=20
deta=
ils =
=20
03/04/03 05:10 PM =
=
=20
Please respond to omiller =
=
=20
=
=
=20
=
=
=20
Field order is generally not important, except when it
comes to repeating groups where it is very important.
If the fields get out of order somewhere, that would
cause a problem trying to parse the message.
If you are getting messages from the QF callback, and
the session is given the correct DataDictionary, then
the fields should be in the same order on both sides
(assuming you are using QF on both sides, other
engines may vary the order).
If you can post the string of the stored message that
may provide a clue.
--- gar...@su... wrote:
>
> Yes, the data dictionary is exactly the same as the
> working version.
>
> One of the things I was wondering was whether it
> mattered where the native
> libraries were compiled. Right now I am packaging
> all the native libraries
> (stdc++, quickfix, quickfix_jni, xml2, and stlport)
> on one machine and am
> including those in my deployment package. Is it a
> coincidence that the
> machine that this works for is the same machine the
> libraries were compiled
> on?
>
> Also, does the order of the fields as they appear in
> the message store have
> any indication as to the order that is used when
> parsing and generating the
> message? As I mentioned in a different thread, I
> have an Incoming message
> store where I store every message received by the
> FIX engine. When I look
> at the allocation message in that message store, it
> does appear that some
> of the fields are not in the same order as in the
> FileStore of the sending
> FIX engine. Could the saving of the message into
> another message store
> somehow corrupt the field order?
>
>
>
> Gary Mui
> Prescient Markets, Inc 914-989-3118 (W)
> 445 Hamilton Avenue 914-422-3693 (F)
> White Plains, NY 10601
>
> Please visit us at http://www.cpmarket.com
>
>
>
>
>
> Oren Miller
> <ore...@ya...>
>
>
> Sent by:
> To: gar...@su...,
> qui...@li...
>
> qui...@li...ur cc:
>
>
> ceforge.net
> Subject: Re: [Quickfix-developers]
> mixed up pasting - please look here for
>
> details
>
>
>
>
> 03/04/03 04:32 PM
>
>
> Please respond to omiller
>
>
>
>
>
>
>
>
>
>
>
> Did you copy your data dictionary over to the new
> machine? The data dictionary of the receiving
> application would need to have the proper groups
> defined.
>
> --- gar...@su... wrote:
> > Oops - please ignore the prior email. I mixed up
> > the pasting of the
> > messages....
> >
> >
> >
> >
> > I've run into a serious problem that I haven't
> been
> > able to figure out.
> >
> > In trying to send across allocation messages
> (which
> > contain groups), I am
> > able to successfully do so on my development
> > platform. When I move the
> > receiving FIX engine to another environment (same
> > class machine, same java
> > version, same OS version-solaris 8), the receiving
> > side is unable to parse
> > the allocation message correctly which causes the
> > processing to fail.
> >
> > My outgoing message appears to be right in its XML
> > form while the incoming
> > message does not show the repeating group entries.
> > I am also including the
> > 'raw' format as printed in the output:
> >
> > Does anyone have any suggestions as to how to
> > proceed resolving this
> > problem? This is now holding up our UAT and
> > production release schedules.
> >
> > Thanks for any help,
> > Gary
> >
> > Outgoing
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > <20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST,
> > outgoing>
> >
> >
>
(8=3DFIX.4.2^A9=3D424^A35=3DJ^A34=3D474^A49=3DFMRFITST^A52=3D20030304-2=
0:12:56^A56=3DSTNMMTST^A6=3D99.991667^A15=3DUSD^A22=3D1^A48=3DCUSIP^A53=
=3D1000000^A54=3D1^A55=3DFIXED^A60=3D20030304-20:12:54^A70=3DAllocation=
:
>
> >
> >
>
0^A71=3D3^A73=3D1^A11=3DNONREF^A37=3D155882^A75=3D20030304^A78=3D1^A79=3D=
FCUSM^A80=3D1000000^A76=3DGECC^A154=3D999916.67^A6604=3DPartAllocID:1^A=
106=3DGECC^A118=3D100^A124=3D1^A32=3D1000000^A17=3D155882_20031204_1512=
54^A31=3D3^A6640=3D99.991667^A381=3D999916.67^A6609=3DCP^A6611=3D100^A6=
613=3DMONEYMARKET^A6614=3D1^A6629=3DMATURITY^A6637=3D20031204^A10=3D053=
^A)
>
> >
> >
> >
> > <message>
> > <header>
> > <field number=3D"8" value=3D"FIX.4.2"/>
> > <field number=3D"9" value=3D"372"/>
> > <field number=3D"35" value=3D"J"/>
> > </header>
> > <body>
> > <field number=3D"6" value=3D"99.991667"/>
> > <field number=3D"15" value=3D"USD"/>
> > <field number=3D"22" value=3D"1"/>
> > <field number=3D"48" value=3D"CUSIP"/>
> > <field number=3D"53" value=3D"1000000"/>
> > <field number=3D"54" value=3D"1"/>
> > <field number=3D"55" value=3D"FIXED"/>
> > <field number=3D"60" value=3D"20030304-20:12:54"/>
> > <field number=3D"70" value=3D"Allocation: 0"/>
> > <field number=3D"71" value=3D"3"/>
> > <field number=3D"73" value=3D"1"/>
> > <field number=3D"75" value=3D"20030304"/>
> > <field number=3D"78" value=3D"1"/>
> > <field number=3D"106" value=3D"GECC"/>
> > <field number=3D"118" value=3D"100"/>
> > <field number=3D"124" value=3D"1"/>
> > <field number=3D"381" value=3D"999916.67"/>
> > <field number=3D"6609" value=3D"CP"/>
> > <field number=3D"6611" value=3D"100"/>
> > <field number=3D"6613" value=3D"MONEYMARKET"/>
> > <field number=3D"6614" value=3D"1"/>
> > <field number=3D"6629" value=3D"MATURITY"/>
> > <field number=3D"6637" value=3D"20031204"/>
> > <group>
> > <field number=3D"11" value=3D"NONREF"/>
> > <field number=3D"37" value=3D"155882"/>
> > </group>
> > <group>
> > <field number=3D"79" value=3D"FCUSM"/>
> > <field number=3D"80" value=3D"1000000"/>
> > <field number=3D"76" value=3D"GECC"/>
> > <field number=3D"154" value=3D"999916.67"/>
> > <field number=3D"6604" value=3D"PartAllocID:1"/>
> > </group>
> > <group>
> > <field number=3D"32" value=3D"1000000"/>
> > <field number=3D"17"
> > value=3D"155882_20031204_151254"/>
> > <field number=3D"31" value=3D"3"/>
> > <field number=3D"6640" value=3D"99.991667"/>
> > </group>
> > </body>
> > <trailer>
> >
> >
> >
> >
> > Incoming
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > <20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST,
> > incoming>
> >
> >
>
(8=3DFIX.4.2^A9=3D424^A35=3DJ^A34=3D474^A49=3DFMRFITST^A52=3D20030304-2=
0:12:56^A56=3DSTNMMTST^A6=3D99.991667^A15=3DUSD^A22=3D1^A48=3DCUSIP^A53=
=3D1000000^A54=3D1^A55=3DFIXED^A60=3D20030304-20:12:54^A70=3DAllocation=
:
>
>
=3D=3D=3D message truncated =3D=3D=3D
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debu=
gger
for complex code. Debugging C/C++ programs can leave you feeling lost a=
nd
disoriented. TotalView can help you find your way. Available on major U=
NIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
=
|
|
From: Oren M. <ore...@ya...> - 2003-03-05 02:32:43
|
Have you applied this patch? http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/quickfix/quickfix/src/java/Conversions.h.diff?r1=1.3&r2=1.4&only_with_tag=MAIN If not, this may explain the behavior you are seeing. We used to use setString to copy the message before passing it to the java fromApp, which would cause the fields to go out of order because no dictionary was provided. We then switched to properly using the copy operator. I think this is likely the case in your situation. If you hadn't supplied a data dictionary correctly, then it is unlikely your message would make it through to the fromApp since it would fail the message length and the checksum tests. At this point it already passed those tests and is being improperly converted after the fact. I believe Gene submitted this fix some time back. --- gar...@su... wrote: > > > Here is the message as it is stored on the sending > side (where it looks > right) > > 8=FIX.4.29=41435=J34=449=FMRFITST52=20030304-22:06:5456=STNMMTST > 6=99.99166715=USD22=148=CUSIP53=100000054=155=FIXED > 60=20030304-21:14:2770=Allocation: > 071=373=111=NONREF37=155888 > 75=2003030478=179=FCUSM80=1000000154=999916.676604=PartAllocID:1 > 106=GECC118=100124=132=100000017=155888_20031404_16142731=3 > 6640=99.991667381=999916.676609=CP6611=1006613=MONEYMARKET6614=1 > 6629=MATURITY6637=2003060410=038 > > > > Here is the message as it is stored in my incoming > message store (on the > side that it is wrong) > > 8=FIX.4.29=41435=J34=449=FMRFITST52=20030304-22:06:5456=STNMMTST > 6=99.99166711=NONREF15=USD17=155888_20031404_16142722=131=332=1000000 > 37=15588848=CUSIP53=100000054=155=FIXED60=20030304-21:14:27 > 70=Allocation: > 071=373=175=2003030478=179=FCUSM80=1000000106=GECC > 118=100124=1154=999916.67381=999916.676604=PartAllocID:16609=CP > 6611=1006613=MONEYMARKET6614=16629=MATURITY6637=200306046640=99.991667 > 10=038 > > > Here also is my fromApp implementation so you can > see that I am printing > out the xml of the trade before storing it: > > > public void fromApp(org.quickfix.Message message, > SessionID sessionID) > throws FieldNotFound, > UnsupportedMessageType, IncorrectTagValue { > LogUtil.debug ("Message received (" + > sessionID + ") type: " + > message.getClass() + "\n " + message.toXML()); > storeIncomingMessage (message, sessionID); > > crack((org.quickfix.Message) message, > sessionID); > } > > > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > > Oren Miller > <ore...@ya...> > > > Sent by: > To: > qui...@li..., > > > qui...@li...ur > qui...@li... > > ceforge.net > cc: > > > Subject: Re: [Quickfix-developers] > mixed up pasting - please look here for > > details > > 03/04/03 05:10 PM > > > Please respond to omiller > > > > > > > > > > > > Field order is generally not important, except when > it > comes to repeating groups where it is very > important. > If the fields get out of order somewhere, that would > cause a problem trying to parse the message. > > If you are getting messages from the QF callback, > and > the session is given the correct DataDictionary, > then > the fields should be in the same order on both sides > (assuming you are using QF on both sides, other > engines may vary the order). > > If you can post the string of the stored message > that > may provide a clue. > > --- gar...@su... wrote: > > > > Yes, the data dictionary is exactly the same as > the > > working version. > > > > One of the things I was wondering was whether it > > mattered where the native > > libraries were compiled. Right now I am packaging > > all the native libraries > > (stdc++, quickfix, quickfix_jni, xml2, and > stlport) > > on one machine and am > > including those in my deployment package. Is it a > > coincidence that the > > machine that this works for is the same machine > the > > libraries were compiled > > on? > > > > Also, does the order of the fields as they appear > in > > the message store have > > any indication as to the order that is used when > > parsing and generating the > > message? As I mentioned in a different thread, I > > have an Incoming message > > store where I store every message received by the > > FIX engine. When I look > > at the allocation message in that message store, > it > > does appear that some > > of the fields are not in the same order as in the > > FileStore of the sending > > FIX engine. Could the saving of the message into > > another message store > > somehow corrupt the field order? > > > > > > > > Gary Mui > > Prescient Markets, Inc 914-989-3118 (W) > > 445 Hamilton Avenue 914-422-3693 (F) > > White Plains, NY 10601 > > > > Please visit us at http://www.cpmarket.com > > > > > > > > > > > > Oren Miller > > <ore...@ya...> > > > > > > Sent by: > > To: gar...@su..., > > qui...@li... > > > > qui...@li...ur cc: > > > > > > ceforge.net > > Subject: Re: [Quickfix-developers] > > mixed up pasting - please look here for > > > > details > > > > > > > > > > 03/04/03 04:32 PM > > > > > > Please respond to omiller > > > > > > > > > > > > > > > > > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: <gar...@su...> - 2003-03-04 22:18:28
|
Also, I tried running the FIX engine that is generating these allocation messages on the same environment and there doesn't seem to be any trouble in creating allocation messages with repeating groups. I can even send out allocation messages with the right repeating groups from the same fix engine that cannot seem to receive and parse them. Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com Oren Miller <ore...@ya...> Sent by: To: qui...@li..., qui...@li...ur qui...@li... ceforge.net cc: Subject: Re: [Quickfix-developers] mixed up pasting - please look here for details 03/04/03 05:10 PM Please respond to omiller Field order is generally not important, except when it comes to repeating groups where it is very important. If the fields get out of order somewhere, that would cause a problem trying to parse the message. If you are getting messages from the QF callback, and the session is given the correct DataDictionary, then the fields should be in the same order on both sides (assuming you are using QF on both sides, other engines may vary the order). If you can post the string of the stored message that may provide a clue. --- gar...@su... wrote: > > Yes, the data dictionary is exactly the same as the > working version. > > One of the things I was wondering was whether it > mattered where the native > libraries were compiled. Right now I am packaging > all the native libraries > (stdc++, quickfix, quickfix_jni, xml2, and stlport) > on one machine and am > including those in my deployment package. Is it a > coincidence that the > machine that this works for is the same machine the > libraries were compiled > on? > > Also, does the order of the fields as they appear in > the message store have > any indication as to the order that is used when > parsing and generating the > message? As I mentioned in a different thread, I > have an Incoming message > store where I store every message received by the > FIX engine. When I look > at the allocation message in that message store, it > does appear that some > of the fields are not in the same order as in the > FileStore of the sending > FIX engine. Could the saving of the message into > another message store > somehow corrupt the field order? > > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > > Oren Miller > <ore...@ya...> > > > Sent by: > To: gar...@su..., > qui...@li... > > qui...@li...ur cc: > > > ceforge.net > Subject: Re: [Quickfix-developers] > mixed up pasting - please look here for > > details > > > > > 03/04/03 04:32 PM > > > Please respond to omiller > > > > > > > > > > > > Did you copy your data dictionary over to the new > machine? The data dictionary of the receiving > application would need to have the proper groups > defined. > > --- gar...@su... wrote: > > Oops - please ignore the prior email. I mixed up > > the pasting of the > > messages.... > > > > > > > > > > I've run into a serious problem that I haven't > been > > able to figure out. > > > > In trying to send across allocation messages > (which > > contain groups), I am > > able to successfully do so on my development > > platform. When I move the > > receiving FIX engine to another environment (same > > class machine, same java > > version, same OS version-solaris 8), the receiving > > side is unable to parse > > the allocation message correctly which causes the > > processing to fail. > > > > My outgoing message appears to be right in its XML > > form while the incoming > > message does not show the repeating group entries. > > I am also including the > > 'raw' format as printed in the output: > > > > Does anyone have any suggestions as to how to > > proceed resolving this > > problem? This is now holding up our UAT and > > production release schedules. > > > > Thanks for any help, > > Gary > > > > Outgoing > > ========= > > > > <20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST, > > outgoing> > > > > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > > > > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > > > > > > > <message> > > <header> > > <field number="8" value="FIX.4.2"/> > > <field number="9" value="372"/> > > <field number="35" value="J"/> > > </header> > > <body> > > <field number="6" value="99.991667"/> > > <field number="15" value="USD"/> > > <field number="22" value="1"/> > > <field number="48" value="CUSIP"/> > > <field number="53" value="1000000"/> > > <field number="54" value="1"/> > > <field number="55" value="FIXED"/> > > <field number="60" value="20030304-20:12:54"/> > > <field number="70" value="Allocation: 0"/> > > <field number="71" value="3"/> > > <field number="73" value="1"/> > > <field number="75" value="20030304"/> > > <field number="78" value="1"/> > > <field number="106" value="GECC"/> > > <field number="118" value="100"/> > > <field number="124" value="1"/> > > <field number="381" value="999916.67"/> > > <field number="6609" value="CP"/> > > <field number="6611" value="100"/> > > <field number="6613" value="MONEYMARKET"/> > > <field number="6614" value="1"/> > > <field number="6629" value="MATURITY"/> > > <field number="6637" value="20031204"/> > > <group> > > <field number="11" value="NONREF"/> > > <field number="37" value="155882"/> > > </group> > > <group> > > <field number="79" value="FCUSM"/> > > <field number="80" value="1000000"/> > > <field number="76" value="GECC"/> > > <field number="154" value="999916.67"/> > > <field number="6604" value="PartAllocID:1"/> > > </group> > > <group> > > <field number="32" value="1000000"/> > > <field number="17" > > value="155882_20031204_151254"/> > > <field number="31" value="3"/> > > <field number="6640" value="99.991667"/> > > </group> > > </body> > > <trailer> > > > > > > > > > > Incoming > > ========== > > <20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST, > > incoming> > > > > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Gene G. <mus...@ya...> - 2003-03-05 02:19:26
|
Like Oren mentioned before, this looks exactly like symptoms for missing or incorrect DataDictionary XML on the receiving side. Creation and sending of group message does not require it, while parsing and receiving does; triple check your config file. Also, there used to be a problem with older FIX versions that did not handle absolute paths to the data dictionary XML properly on Unix, and one always had to use relative notation. We had a patch out a couple of months ago. Perhaps you have an unpatched version and use full path? Gene --- gar...@su... wrote: > > Also, > > I tried running the FIX engine that is generating > these allocation messages > on the same environment and there doesn't seem to be > any trouble in > creating allocation messages with repeating groups. > I can even send out > allocation messages with the right repeating groups > from the same fix > engine that cannot seem to receive and parse them. > > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > > Oren Miller > <ore...@ya...> > > > Sent by: > To: > qui...@li..., > > > qui...@li...ur > qui...@li... > > ceforge.net > cc: > > > Subject: Re: [Quickfix-developers] > mixed up pasting - please look here for > > details > > 03/04/03 05:10 PM > > > Please respond to omiller > > > > > > > > > > > > Field order is generally not important, except when > it > comes to repeating groups where it is very > important. > If the fields get out of order somewhere, that would > cause a problem trying to parse the message. > > If you are getting messages from the QF callback, > and > the session is given the correct DataDictionary, > then > the fields should be in the same order on both sides > (assuming you are using QF on both sides, other > engines may vary the order). > > If you can post the string of the stored message > that > may provide a clue. > > --- gar...@su... wrote: > > > > Yes, the data dictionary is exactly the same as > the > > working version. > > > > One of the things I was wondering was whether it > > mattered where the native > > libraries were compiled. Right now I am packaging > > all the native libraries > > (stdc++, quickfix, quickfix_jni, xml2, and > stlport) > > on one machine and am > > including those in my deployment package. Is it a > > coincidence that the > > machine that this works for is the same machine > the > > libraries were compiled > > on? > > > > Also, does the order of the fields as they appear > in > > the message store have > > any indication as to the order that is used when > > parsing and generating the > > message? As I mentioned in a different thread, I > > have an Incoming message > > store where I store every message received by the > > FIX engine. When I look > > at the allocation message in that message store, > it > > does appear that some > > of the fields are not in the same order as in the > > FileStore of the sending > > FIX engine. Could the saving of the message into > > another message store > > somehow corrupt the field order? > > > > > > > > Gary Mui > > Prescient Markets, Inc 914-989-3118 (W) > > 445 Hamilton Avenue 914-422-3693 (F) > > White Plains, NY 10601 > > > > Please visit us at http://www.cpmarket.com > > > > > > > > > > > > Oren Miller > > <ore...@ya...> > > > > > > Sent by: > > To: gar...@su..., > > qui...@li... > > > > qui...@li...ur cc: > > > > > > ceforge.net > > Subject: Re: [Quickfix-developers] > > mixed up pasting - please look here for > > > > details > > > > > > > > > > 03/04/03 04:32 PM > > > > > > Please respond to omiller > > > > > > > > > > > > > > > > > > > > > > > > Did you copy your data dictionary over to the new > > machine? The data dictionary of the receiving > > application would need to have the proper groups > > defined. > > > > --- gar...@su... wrote: > > > Oops - please ignore the prior email. I mixed > up > > > the pasting of the > > > messages.... > > > > > > > > > > > > > > > I've run into a serious problem that I haven't > > been > > > able to figure out. > > > > > > In trying to send across allocation messages > > (which > > > contain groups), I am > > > able to successfully do so on my development > > > platform. When I move the > > > receiving FIX engine to another environment > (same > > > class machine, same java > > > version, same OS version-solaris 8), the > receiving > > > side is unable to parse > > > the allocation message correctly which causes > the > > > processing to fail. > > > > > > My outgoing message appears to be right in its > XML > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: <gar...@su...> - 2003-03-05 06:13:41
|
PFA+VGhhbmtzIHRvIE9yZW4gYW5kIEdlbmUgZm9yIHlvdXIgaW5wdXQgb24gbXkgcHJvYmxlbXMu ICZuYnNwO0Rlc3BpdGUgbWUgdmVyaWZ5aW5nIHRoYXQgdGhlIHZhbGlkYXRpb24gZmlsZSB3YXMg dGhlcmUgYW5kIGV4YWN0bHkgYXMgaXQgd2FzIGluIG15IHdvcmtpbmcgZW52aXJvbm1lbnQsIGl0 IHR1cm5zIG91dCB0aGF0IHRoZSBpbml0LmQgc3RhcnR1cCBzY3JpcHRzIHdlcmUgc3BlY2lmeWlu ZyB0byBzdGFydCBpbiBhIGRpZmZlcmVudCBkaXJlY3RvcnkgdGhhbiBteSBzdGFydHVwIHNjcmlw dHMuICZuYnNwO1RoZXJlZm9yZSwgdGhlIHJlbGF0aXZlIHNwZWNpZmljYXRpb24gb2YgdGhlIHZh bGlkYXRpb24gZmlsZSB3YXMgaW5jb3JyZWN0LiAmbmJzcDtBIHNpbXBsZSBzeW1saW5rIGZpeGVk IGFsbCBvZiBteSBwcm9ibGVtcyBhbmQgaXQncyB3b3JraW5nIGFzIGV4cGVjdGVkLjwvUD48UD5U aGFua3MgYWdhaW4gZm9yIHlvdXIgaGVscC4gJm5ic3A7SSdtIHJlYWxseSBhcHByZWNpYXRpdmUg b2YgdGhpcyBwcm9qZWN0IGFuZCBhbGwgb2YgeW91ciBoZWxwZnVsbmVzcy4gJm5ic3A7V2l0aCBh bnkgbHVjaywgd2Ugc2hvdWxkIGJlIG1vdmluZyBpbnRvIHByb2R1Y3Rpb24gd2l0aCBvdXIgZmly c3QgRklYIGNsaWVudCB0aGlzIHdlZWshPC9QPjxQPiZuYnNwOzwvUD48UD5HYXJ5IE11aTxCUj5Q cmVzY2llbnQgTWFya2V0cywgSW5jIDkxNC05ODktMzExOCAoVyk8QlI+NDQ1IEhhbWlsdG9uIEF2 ZW51ZSA5MTQtNDIyLTM2OTMgKEYpPEJSPldoaXRlIFBsYWlucywgTlkgMTA2MDEgPEJSPjxCUj5Q bGVhc2UgdmlzaXQgdXMgYXQgPEEgSFJFRj1odHRwOi8vd3d3LmNwbWFya2V0LmNvbT5odHRwOi8v d3d3LmNwbWFya2V0LmNvbTwvQT4gPC9QPg== |
|
From: Oren M. <ore...@ya...> - 2003-03-04 22:10:28
|
Field order is generally not important, except when it comes to repeating groups where it is very important. If the fields get out of order somewhere, that would cause a problem trying to parse the message. If you are getting messages from the QF callback, and the session is given the correct DataDictionary, then the fields should be in the same order on both sides (assuming you are using QF on both sides, other engines may vary the order). If you can post the string of the stored message that may provide a clue. --- gar...@su... wrote: > > Yes, the data dictionary is exactly the same as the > working version. > > One of the things I was wondering was whether it > mattered where the native > libraries were compiled. Right now I am packaging > all the native libraries > (stdc++, quickfix, quickfix_jni, xml2, and stlport) > on one machine and am > including those in my deployment package. Is it a > coincidence that the > machine that this works for is the same machine the > libraries were compiled > on? > > Also, does the order of the fields as they appear in > the message store have > any indication as to the order that is used when > parsing and generating the > message? As I mentioned in a different thread, I > have an Incoming message > store where I store every message received by the > FIX engine. When I look > at the allocation message in that message store, it > does appear that some > of the fields are not in the same order as in the > FileStore of the sending > FIX engine. Could the saving of the message into > another message store > somehow corrupt the field order? > > > > Gary Mui > Prescient Markets, Inc 914-989-3118 (W) > 445 Hamilton Avenue 914-422-3693 (F) > White Plains, NY 10601 > > Please visit us at http://www.cpmarket.com > > > > > > Oren Miller > <ore...@ya...> > > > Sent by: > To: gar...@su..., > qui...@li... > > qui...@li...ur cc: > > > ceforge.net > Subject: Re: [Quickfix-developers] > mixed up pasting - please look here for > > details > > > > > 03/04/03 04:32 PM > > > Please respond to omiller > > > > > > > > > > > > Did you copy your data dictionary over to the new > machine? The data dictionary of the receiving > application would need to have the proper groups > defined. > > --- gar...@su... wrote: > > Oops - please ignore the prior email. I mixed up > > the pasting of the > > messages.... > > > > > > > > > > I've run into a serious problem that I haven't > been > > able to figure out. > > > > In trying to send across allocation messages > (which > > contain groups), I am > > able to successfully do so on my development > > platform. When I move the > > receiving FIX engine to another environment (same > > class machine, same java > > version, same OS version-solaris 8), the receiving > > side is unable to parse > > the allocation message correctly which causes the > > processing to fail. > > > > My outgoing message appears to be right in its XML > > form while the incoming > > message does not show the repeating group entries. > > I am also including the > > 'raw' format as printed in the output: > > > > Does anyone have any suggestions as to how to > > proceed resolving this > > problem? This is now holding up our UAT and > > production release schedules. > > > > Thanks for any help, > > Gary > > > > Outgoing > > ========= > > > > <20030304-20:12:54, FIX.4.2:FMRFITST->STNMMTST, > > outgoing> > > > > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > > > > > 0^A71=3^A73=1^A11=NONREF^A37=155882^A75=20030304^A78=1^A79=FCUSM^A80=1000000^A76=GECC^A154=999916.67^A6604=PartAllocID:1^A106=GECC^A118=100^A124=1^A32=1000000^A17=155882_20031204_151254^A31=3^A6640=99.991667^A381=999916.67^A6609=CP^A6611=100^A6613=MONEYMARKET^A6614=1^A6629=MATURITY^A6637=20031204^A10=053^A) > > > > > > > > > <message> > > <header> > > <field number="8" value="FIX.4.2"/> > > <field number="9" value="372"/> > > <field number="35" value="J"/> > > </header> > > <body> > > <field number="6" value="99.991667"/> > > <field number="15" value="USD"/> > > <field number="22" value="1"/> > > <field number="48" value="CUSIP"/> > > <field number="53" value="1000000"/> > > <field number="54" value="1"/> > > <field number="55" value="FIXED"/> > > <field number="60" value="20030304-20:12:54"/> > > <field number="70" value="Allocation: 0"/> > > <field number="71" value="3"/> > > <field number="73" value="1"/> > > <field number="75" value="20030304"/> > > <field number="78" value="1"/> > > <field number="106" value="GECC"/> > > <field number="118" value="100"/> > > <field number="124" value="1"/> > > <field number="381" value="999916.67"/> > > <field number="6609" value="CP"/> > > <field number="6611" value="100"/> > > <field number="6613" value="MONEYMARKET"/> > > <field number="6614" value="1"/> > > <field number="6629" value="MATURITY"/> > > <field number="6637" value="20031204"/> > > <group> > > <field number="11" value="NONREF"/> > > <field number="37" value="155882"/> > > </group> > > <group> > > <field number="79" value="FCUSM"/> > > <field number="80" value="1000000"/> > > <field number="76" value="GECC"/> > > <field number="154" value="999916.67"/> > > <field number="6604" value="PartAllocID:1"/> > > </group> > > <group> > > <field number="32" value="1000000"/> > > <field number="17" > > value="155882_20031204_151254"/> > > <field number="31" value="3"/> > > <field number="6640" value="99.991667"/> > > </group> > > </body> > > <trailer> > > > > > > > > > > Incoming > > ========== > > <20030304-20:12:56, FIX.4.2:STNMMTST->FMRFITST, > > incoming> > > > > > (8=FIX.4.2^A9=424^A35=J^A34=474^A49=FMRFITST^A52=20030304-20:12:56^A56=STNMMTST^A6=99.991667^A15=USD^A22=1^A48=CUSIP^A53=1000000^A54=1^A55=FIXED^A60=20030304-20:12:54^A70=Allocation: > > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X