Join the 80,000 other DTN customers who enjoy the fastest, most reliable data available. There is no better value than DTN!

(Move your cursor to this area to pause scrolling)




"Awesome response, as usual. It is a sincere and refreshing pleasure to do business with DTN, compared to your competition." - Comment from Ryan
"IQFeed version 4 is a real screamer compared to anything else I have seen." - Comment from Tom
"Version 4.0.0.2 has been working well for me and I appreciate that it is now a much tighter client to work with. I feel I can go to press with my own application and rely on a stable platform" - Comment from David in IA.
"The people at Nirvana have very nice things to say about your company and I can see why! Price and service is a potent combination." - Comment from Ed
"I "bracket trade" all major news releases and I have not found one lag or glitch with DTN.IQ feed. I am very comfortable with their feed under all typical news conditions (Fed releases, employment numbers, etc)." - Comment from Public Forum
"Previously I was using *******. IQFeed is WAY more economical, and for my charting needs is just as good, if not better." - Comment from Public Forum Post
"This is an excellent value, the system is generous (allowing for 500 stocks) and stable (and really is tick-by-tick), and the support is fantastic." - Comment from Shirin via Email
"Everything is working great ! Very impressive client. The news refreshes better and is more pertinent than the ******* feed I paid $ 100/month for. I Also like the charts a lot." - Comment from Leon
"Thanks for all of your help. Great customer service deserves to be recognized which one the reasons I've been a customer of DTN for over 10 years!" - Comment from Stuart
"You have an excellent feed. Very few spikes for Spot Forex." - Comment from Public Forum Post
Home  Search  Register  Login  Recent Posts

Information on DTN's Industries:
DTN Oil & Gas | DTN Trading | DTN Agriculture | DTN Weather
Follow DTNMarkets on Twitter
DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter
Viewing User Profile for: bludev
About Contact
Joined: Nov 14, 2012 09:16 PM
Last Post: Dec 3, 2017 11:52 PM
Last Visit: Dec 4, 2017 07:34 PM
Website:  
Location:
Occupation:
Interests:
AIM:
ICQ:
MSN IM:
Yahoo IM:
Post Statistics
bludev has contributed to 16 posts out of 19579 total posts (0.08%) in 2,761 days (0.01 posts per day).

20 Most recent posts:

Were there any EMINI live tick data latency or other data related issues last Friday 1st Dec 2017 around (10:12:36 to 10:13:09) and (10:36:36 to 10:46:10) Chicago time? as we experienced lagged in receiving the tick data as well as missing 10 minutes of data.


We found that some live tick data are different from historical tick data.

Live reporting more ticks than historical. These differences occur quite often throughout the day (thousands of ticks different).

Both live and historical use the same IQFeed on the same machine.

Live
Q,@ESZ17,09/18/2017,08:18:09.681,2501.75,1,298390
Q,@ESZ17,09/18/2017,08:18:10.080,2502,1,298393
Q,@ESZ17,09/18/2017,08:18:10.080,2502,1,298393
Q,@ESZ17,09/18/2017,08:18:10.080,2502,1,298393
Q,@ESZ17,09/18/2017,08:18:21.772,2502,1,298413
Q,@ESZ17,09/18/2017,08:18:27.135,2502,1,298440
Q,@ESZ17,09/18/2017,08:18:27.135,2502,1,298440
Q,@ESZ17,09/18/2017,08:18:33.750,2502,2,298461
...
Q,@ESZ17,09/18/2017,10:40:49.321,2504,6,777536
Q,@ESZ17,09/18/2017,10:40:52.318,2504,7,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,5,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,3,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,3,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,3,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,3,777627
Q,@ESZ17,09/18/2017,10:40:55.292,2504.25,1,777748
Q,@ESZ17,09/18/2017,10:40:55.292,2504.25,1,777748
Q,@ESZ17,09/18/2017,10:40:56.993,2504,2,777772


Historical
Q,@ESZ17,09/18/2017,08:18:09.681,2501.75,1,298390
Q,@ESZ17,09/18/2017,08:18:10.080,2502,1,298393
Q,@ESZ17,09/18/2017,08:18:21.772,2502,1,298413
Q,@ESZ17,09/18/2017,08:18:27.135,2502,1,298440
Q,@ESZ17,09/18/2017,08:18:33.750,2502,2,298461
...
Q,@ESZ17,09/18/2017,10:40:49.321,2504,2,777536
Q,@ESZ17,09/18/2017,10:40:49.321,2504,6,777536
Q,@ESZ17,09/18/2017,10:40:52.318,2504,7,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,5,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,1,777627
Q,@ESZ17,09/18/2017,10:40:52.318,2504,3,777627
Q,@ESZ17,09/18/2017,10:40:55.292,2504.25,1,777748
Q,@ESZ17,09/18/2017,10:40:56.993,2504,2,777772

Which one is correct? Is live reporting more ticks or is the historical missing some ticks?

Thanks


We found that two of our applications received some differences in the live tick data. Both application run on the same machine using the same IQFeed id (same protocol 5.0).

It seems like one received consolidated ticks and the other received expanded ticks. This happens only on certain data block (the rest of the data are still identical).

First application received the following data (consolidated ticks)
...
Q,@ESZ17,09/18/2017,19:35:26.079,2502.75,3
Q,@ESZ17,09/18/2017,19:35:29.680,2502.5,88
Q,@ESZ17,09/18/2017,19:35:29.680,2502.25,237
Q,@ESZ17,09/18/2017,19:35:29.730,2502.25,1
Q,@ESZ17,09/18/2017,19:35:29.730,2502.25,1
Q,@ESZ17,09/18/2017,19:35:29.730,2502.5,1
Q,@ESZ17,09/18/2017,19:35:29.730,2502.5,8
Q,@ESZ17,09/18/2017,19:35:29.730,2502.5,3
Q,@ESZ17,09/18/2017,19:35:29.730,2502.25,22
Q,@ESZ17,09/18/2017,19:35:29.730,2502.25,7
Q,@ESZ17,09/18/2017,19:35:29.830,2502.25,1
Q,@ESZ17,09/18/2017,19:35:34.881,2502.25,3
Q,@ESZ17,09/18/2017,19:35:36.583,2502.5,1
Q,@ESZ17,09/18/2017,19:35:39.931,2502.25,10
Q,@ESZ17,09/18/2017,19:35:40.231,2502.25,22
Q,@ESZ17,09/18/2017,19:35:41.783,2502.25,1
Q,@ESZ17,09/18/2017,19:35:44.883,2502.5,1
...

Second application received the following (expanded ticks) - we have the tick id here (last field)
...
Q,@ESZ17,09/18/2017,19:35:30.091,2502.75,2,3982,1842509,
Q,@ESZ17,09/18/2017,19:35:30.091,2502.75,1,3983,1842509,
T,20170918 19:35:31
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,31,4014,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4015,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4016,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4017,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4018,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4019,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4020,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4021,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,4,4025,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4026,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4027,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4028,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4029,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4030,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,2,4032,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,2,4034,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4035,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4036,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,7,4043,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,4,4047,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4048,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4049,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4050,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,5,4055,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,3,4058,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4059,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,2,4061,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,2,4063,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,3,4066,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4067,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,1,4068,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.50,3,4071,1842520,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,6,4077,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,30,4107,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4108,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,87,4195,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,24,4219,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4220,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4221,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,2,4223,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,2,4225,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,9,4234,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4235,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4236,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,3,4239,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4240,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,3,4243,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4244,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4245,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4246,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,8,4254,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,2,4256,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4257,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,2,4259,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,3,4262,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,22,4284,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4285,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,12,4297,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,1,4298,1842521,
Q,@ESZ17,09/18/2017,19:35:33.713,2502.25,10,4308,1842521,
Q,@ESZ17,09/18/2017,19:35:33.727,2502.25,1,4309,1842522,
Q,@ESZ17,09/18/2017,19:35:33.727,2502.25,1,4310,1842523,
Q,@ESZ17,09/18/2017,19:35:33.727,2502.50,1,4311,1842531,
Q,@ESZ17,09/18/2017,19:35:33.728,2502.50,8,4319,1842559,
Q,@ESZ17,09/18/2017,19:35:33.728,2502.50,3,4322,1842562,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,5,4327,1842639,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,2,4329,1842639,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4330,1842639,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,3,4333,1842639,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4334,1842639,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4335,1842639,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,3,4338,1842639,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,3,4341,1842639,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,3,4344,1842639,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4345,1842650,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4346,1842650,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4347,1842650,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4348,1842650,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,2,4350,1842650,
Q,@ESZ17,09/18/2017,19:35:33.729,2502.25,1,4351,1842650,
Q,@ESZ17,09/18/2017,19:35:33.808,2502.25,1,4352,1842706,
...

Could you take a look at this issue and let us know what happen?

Thanks


We are having problem downloading historical data for the following IQFeedSymbol : "VIX.XO", "OVX.XO", "TYVIX.XO", "GVZ.XO", and "EVZ.XO". We noticed that this stopped working from 22-Apr-2017 since our program is scheduled to download once a day. We are using IQFeed ver 5.2.6.0.

The following is the message being sent and received:

>>SENT
HDT,VIX.XO,20161231,,,1,,
>>RECEIVE
S,CURRENT PROTOCOL,5.0
E,Unauthorized user ID.,
!ENDMSG!,

It works fine for the tick data but not the daily data.

Please help!

Thanks

IQFeed Developer Support » CME protocol Jul 8, 2015 04:33 AM (Total replies: 28)

Hi Jay, any updates on this issue?

Data and Content Support » Symbol for VSTOXX Index Mar 22, 2015 11:14 PM (Total replies: 2)

Hi guys, I do not seem to be able to locate the IQFeed symbol for the VSTOXX index.

http://www.stoxx.com/indices/index_information.html?symbol=V2TX

On most other platforms this appears to be V2TX?

Thanks
Tom

Data and Content Support » ASX SPI & XT Futures Data Issue Jan 24, 2014 02:00 AM (Total replies: 9)

Hi Mike

Many thanks for the clarification. Lets hope this is able to be resolved soon. In the meantime I will work to approximate the data aggregation % and adjust our market modelling accordingly.

Many thanks

Data and Content Support » ASX SPI & XT Futures Data Issue Jan 22, 2014 07:41 PM (Total replies: 9)

Hi Curtis,

While I appreciate you getting back to me, I find this response very unsatisfactory.

IQFeed promotes itself as a "TRUE, tick-by-tick datafeed. This feed is completely unfiltered, allowing you to see EVERY TRADE that occurs in real-time."

Unfortunately the situation that we have here flies in the face of these claims as we are certainly not seeing every trade that occurs in real-time.

The response 'there is not much we can do to fix this' concerns me greatly and to be honest, after several years of great service from IQFeed, I am somewhat surprised.

Modelling of ASX markets by anyone using tick-based bars (such as myself) is no longer going to be receiving accurate results.

Clearly there are other 3rd party vendors out there that continue to access true tick-by-tick data from the ASX every day. I would kindly ask that you escalate this issue with the appropriate people, while it appears it is currently not currently a priority for IQFeed, it is a priority for our business.

Best Regards

Data and Content Support » ASX SPI & XT Futures Data Issue Jan 21, 2014 11:13 PM (Total replies: 9)

Hi Curtis

I have not heard anything for a week now and was wondering if there is any update?

I am concerned that I am trading based on inaccurate data and it is costing me money. Do you know how long the data has been inaccurate for? And more importantly, when it is going to be resolved?

Thanks

Data and Content Support » ASX SPI & XT Futures Data Issue Jan 15, 2014 08:33 PM (Total replies: 9)

Thanks for the update Curtis. It would be great to get to the bottom of this asap as it has a significant impact on our trading of this market.

Data and Content Support » ASX SPI & XT Futures Data Issue Jan 13, 2014 10:38 PM (Total replies: 9)

Hi, I have an issue whereby the number of ticks for ASX futures data being received via IQfeed is significantly less than expected.

I have checked both the SPI and AX symbol's data and both seem to be between 20% and 30% down on the number of expected ticks, yet the total volume of contracts traded matches very closely. I am comparing IQfeed data to Tickdata.com historical tick data to which I subscribe. You can see in the screenshot attached the significant difference I am talking about with the SPI.

When I perform the same comparison between IQfeed and Tickdata.com for CME futures markets, the tick volume difference is nearly always less than 1%.

I noticed an example on the AX where multiple ticks appear to have been aggregated in IQfeed's output:

Timestamp - 13JAN2014 16:09:38 - Tick Volumes as follows:
Tickdata.com: 3,14,10,1,5,5,5,8
IQfeed: 3,40,8

You will note the first and last ticks 3 and 8 are the same. Also, the SUM of all the Tickdata tick volumes in between these two ticks is 40, the same as the volume reported in the IQfeed tick.

Any help on how this issue can be resolved would be appreciated.

IQFeed Developer Support » Data spikes Jul 26, 2013 01:27 AM (Total replies: 3)

Thanks for this comprehensive reply, very helpful.

So having now had a chance to play with Most Recent Trade Conditions and Message Contents fields, I can see that all the spikes in my future currency data (e.g. @AD and @JY) where due to the occasional group O messages with condition 4D.

However... for crude futures QCL, these same group O messages seem to make up a substantial (~5%) portion of the data which look legitimate and without any spikes. In fact including these group O messages we are now getting much better agreement between IQ feed tick data for crude and the data we can download from TickWrite the next day.

So my question now is, is there any API for programatically finding out which symbols should include group O messages as part of normal data and which ones should exclude them? Or is this a user parameter that one would only know by trial and error?

IQFeed Developer Support » Data spikes Jul 19, 2013 04:31 AM (Total replies: 3)

Hi, I have recently switched to IQFeed 5.0 protocol with
"S,SELECT UPDATE FIELDS,Most Recent Trade Date,Most Recent Trade TimeMS,Most Recent Trade,Most Recent Trade Size,Total Volume"
This is all working fine except now occasionally I'm getting some spikes in the data which don't look like they are real trades. I'm attaching an example here (PNG file) which I've also verified by looking through IQConnectLog.txt:

Q,@ADU13,07/18/2013,07:10:36.004,0.9187,1,38571,
Q,@ADU13,07/18/2013,07:30:36.418,0.9187,19,39741,

Any ideas what is causing these? Are these errors/blips in the data or some sort of "non-qualified" trade? Is there any systematic way to filter these out?

Thanks!

IQFeed Developer Support » IQ developer data feed? Jul 1, 2013 09:05 PM (Total replies: 1)

Hi,

We have 2 accounts registered with IQ feed which are being used on 2 production systems. Do you by any chance offer a complementary developer feed I could independently use in the development environment for testing and debugging?

Using the production accounts is not really an option in the long run because of all the disruptions during the testing phase, and it is a bit silly to register another full account when I only need to use it for a few days once every few months.

Any guidance on how to best proceed would be appreciated.


Hi,

Thanks for your reply and sorry for my late response:

Here is my attempt at a summary overview of how we use IQFeed

To connect we have an AttemptConnection() routine which roughly speaking does the following...

SocketAdmin_.Connect(New IPEndPoint(IPAddress.Parse("127.0.0.1"),"9300"))
SocketAdmin_.Send("S,REGISTER CLIENT APP,[productid]," & ID)
SocketLevelI _.Connect(New IPEndPoint(IPAddress.Parse("127.0.0.1"),"5009"))
SocketLevelI_.Send("S,REQUEST STATS")
listening to receive "REGISTER CLIENT APP COMPLETED"
SocketLevelII _.Connect(New IPEndPoint(IPAddress.Parse("127.0.0.1"),"9200"))
SocketHistoricData _.Connect(New IPEndPoint(IPAddress.Parse("127.0.0.1"),"9100"))

The routine is designed such that any failure or time-out at any of the above steps would return false and we try again by repeating the process at some later point. If every line executes normally then the routine return true and we assume that the connection with IQFeed is established normally and tick data must be coming through.

Any exceptions while attempting to Connect, Send, Receive or ListenForData, will trigger a ConnectionClosed() event. This event’s handler includes the following instructions:

SocketAdmin_.Close()
SocketLevelI_.Close()
SocketLevelII_.Close()
SocketHistoricData_.Close()

to clean everything up. At this stage the IQFeed application is NOT closed and the tray icon persists. We then run AttemptConnection() asynchronously in a timed loop until a connection is established.

As I mentioned before, this often works. But sometimes if the cause of the initial disconnect is unexpected internet outage, then AttemptConnection() returns true giving the impression that everything is ok but then no data is received. So I guess one issue to look at is how to programmatically detect the problem in the first place.

Please let me know if you need me to be more specific about any of the above procedures and provide more information.
Edited by DTN_Jay_Froscheiser on Nov 26, 2012 at 07:44 AM


Hi,
I am experiencing an issue where IQFeed level 1 data never recovers after an unexpected internet disruption.

My application detects the initial internet outage and properly closes all port connections (admin, level 1, level 2 and history) and then starts regular attempts at reconnection until it succeeds when the internet connection is restored. But then every so often (could be intermittent) although my connection to level 1 (port 5009) is successful, I do not receive any live tick data at all, but somehow I can retrieve historical data (port 9100) without any problem.

I can confirm that this is not a problem within the application code, because of two observations
1. “Seconds since last update” in the feed status steadily increases indicating no level 1 data is being received by IQFeed
2. The IQConnect test in the diagnostics tool fails for level 1 data.

So my questions are:
1. Is this a known bug?
2. If so, are there any immediate plans to release a fix?
3. Seeing as the client application thinks it is “successfully” connected to level 1 port, is there any way of programmatically detecting the fault? (other than detecting ticks which can be a problem if the market is shut and we trade many markets in many time zones with daylight saving, so this approach can get tedious)
4. Assuming there is some way for the application to know when the IQfeed level 1 data is not working, then is there a workaround other than closing IQfeed completely and restarting again?

I am developing in Windows 7 x64 and have had this same experience with both IQFeed version 4.8 and 4.9.

Thank you in advance.
Edited by bludev on Nov 14, 2012 at 10:03 PM


Time: Fri June 5, 2020 5:02 AM CFBB v1.2.0 16 ms.
© AderSoftware 2002-2003