PureBytes Links
Trading Reference Links
|
In the last year I encountered GS problems of two types. One, the server
would die after startup and the other was CTREE errors. The CTREE errors
can be caused by corruption in either or both the .idx and .dat files.
Sometimes just deleting the .idx and restarting clears up the ctree error
and other times both have to be deleted. In neither case did the
symswap.dat have to be deleted. The symswap.dat contains the "P" or process
codes that make the Global Server think its talking to a Signal data
manager. Well, that's not exactly right, but essentially that's what the
outcome is. So some feeds like DTN have to send process codes to tell the
server how to handle each symbol type of data. DTN sends these codes 4
times a day, but not all at once. So it may take one or two days to
populate the symswap.dat file. I believe all of them are resent over the
weekend. The Universal Market data server requires the "P" codes also. If
the data feed is Signal or esignal or you are using something like qfeed and
dynastore with a Signal version of the GS, then the p codes are not an issue
because once again there is compatibility. I believe P codes were a way of
making the GS multifeed compatible without a lot of rewriting of the server
code. The safest way to go is to make routine backups of the entire PDS
file in the server folder. Then if you have a crash or corrupted data you
can get running again rather fast by reinstalling that backup. My last
fiasco occurred last week when a cpu overheated and auto shutdown. It
resulted in corruption in the .idx files and ctree errors. Simply deleting
those and restarting got things going in minutes. The .idx were filled in
a minute or two and you can watch that by having the windows explorer open
to the server\pds location.
bobr
----- Original Message -----
From: "Lhermie Philippe" <philippe.lhermie@xxxxxxx>
To: <omega-list@xxxxxxxxxx>; "BobR" <bobrabcd@xxxxxxxxxxxxx>
Sent: Sunday, April 22, 2001 10:06 AM
Subject: RE: weird problem with my TS2K charts
> Bob,
> Could you enlighten us by explaining what is the "p" process codes?
>
> (Also, I know that If delete all these files it will take about 1 hour for
> my GS to open properly)
>
> Rgds,
> Phil
>
> -----Message d'origine-----
> De : BobR [mailto:bobrabcd@xxxxxxxxxxxxx]
> Envoyé : dimanche 22 avril 2001 18:54
> À : Jim Bronke; LScharpen@xxxxxxx; philippe.lhermie@xxxxxxx
> Cc : omega-list@xxxxxxxxxx
> Objet : Re: weird problem with my TS2K charts
>
>
> Except that the symswap.dat contains the "P" process codes and that may
> require the one to two day wait to rebuild those depending on the data
> supplier such as DTN. Not true with esignal, I believe.
>
> bobr
>
> ----- Original Message -----
> From: "Jim Bronke" <jvbronke@xxxxxxxx>
> To: <LScharpen@xxxxxxx>; <philippe.lhermie@xxxxxxx>
> Cc: <omega-list@xxxxxxxxxx>
> Sent: Sunday, April 22, 2001 9:36 AM
> Subject: Re: weird problem with my TS2K charts
>
>
> > Yes, You could try the old catchall fixit:
> >
> > Delete the following files from your Server folder: With the program not
> > running.
> > 1. gsqf.dat
> > 2. perfmon.dat
> > 3. symswap.dat
> > 4. sysevent.dat
> >
> > They generally had you reboot the computer afterwards. then run GS. It
> > rebuilds the files in seconds and you are off and running.
> >
> >
> > Jim Bronke
> > Phoenix, AZ
> >
> >
> >
> > ----- Original Message -----
> > From: <LScharpen@xxxxxxx>
> > To: <philippe.lhermie@xxxxxxx>
> > Cc: <omega-list@xxxxxxxxxx>
> > Sent: Sunday, April 22, 2001 9:19 AM
> > Subject: Re: weird problem with my TS2K charts
> >
> >
> > > In a message dated 4/22/01 8:27:23 AM Pacific Daylight Time,
> > > philippe.lhermie@xxxxxxx writes:
> > >
> > > << Dear Folks,
> > >
> > > I'm facing a weird problem with my TS2K charts:
> > > I cannot select a time compression which is a multiple of 5 min
> > > and every other selections work fine!
> > >
> > > I had a look in my GlobalServer and some of my symbols have a
> Resolution
> > of
> > > "Trade REcord 5 minutes" and some don't.
> > > But in any case there is no 5 min data available.
> > > >>
> > > =======================
> > >
> > > Philippe,
> > >
> > > I'm going to comment here from memory. A number of my old records
went
> to
> > > 'record heaven' when I converted to a new computer about 8 months ago
> and
> > > also moved physically. Anyway, what you describe rang a memory bell
> > > concerning similar problems I had a few years ago ... but that was
with
> > TS4
> > > and not TS2K (which is what I'm using now). I can't remember if my
> > 'problem'
> > > back then was the same as yours but it sure sounds quite similar.
After
> > some
> > > 'back and forth' with Omega Research Techies, I was instructed to
> > 'rebuild'
> > > my index file. The procedure for doing that also now resides in
'record
> > > heaven' so I can't be specific. IF that is related to your problem I
am
> > sure
> > > there is somebody on this list who might have details for the
procedure.
> > If
> > > not, give (what's their new name again?) Omega Research Tech Support a
> > > 'jingle' (e-mail works best for me) and see what they have to say.
> Unlike
> > > others who've posted to this list, I've found them to be most helpful.
> > But
> > > then again maybe they have gone to 'tech support heaven' too! <G>
> > >
> > > Lee Scharpen
> > >
> >
>
>
>
|