BRIS has changed format of DRF multi-file

[rrbauer]

Here's a heads-up that I learned about today after fooling around for about 4 hours tyring to decide why my processes were not including past performance data from BRIS. It turns out that they changed (for files dated Feb 8 and forward) the format of the DR3 file. Here it is straight from the horse's (pun intended) mouth:

"Sorry to hear that you're having trouble with the DRF multi-file. We did start populating
a "reserved" field yesterday (3rd file field #62 -BRIS Race Shape 1st Call), but I'm
surprised that would cause you any trouble???. Regardless, we also recently started
populating another "reserved" field (3rd file field #55 - BRIS Race Shape 2nd Call).
We will be updating the file structures today to reflect "BRIS Race Shape" instead of
"Reserved".

So now I know and so do you....

Since I've seen this type problem before with BRIS it isn't even worth getting upset about....I didn't play today because I couldn't produce my handicapping tools...so I painted....nuff of that shit!

[forecast]

Thanks for the heads-up. Fortunately, I was not affected, as I put the reserved fields in my database when I built it. Guess that was a lucky/good call. Do yourself a favor, and don't check the results for today. You know Beyer's rule about betting when you can't make it to the races......:mad:

Anyway, thanks again for the heads-up, and good luck tomorrow.

Forecast

[DJofSD]

Richard, you might have missed this other recent thread about the new BRIS race shape numbers. Tom's BRIS race shape thread. (http://www.paceadvantage.com/forum/showthread.php?p=354706#post354706)

I normally don't D/L the multiple file data but I'll do so and poke around. Likely in a few days.

I hope BRIS revises their documentation for all the documents in the library.

[Tom]

Why would populating previously empty files affect anything?
Unless you were using them as space holders.:confused:

[rrbauer]

Why would populating previously empty files affect anything?
Unless you were using them as space holders.:confused:

Suppose you had the "reserved" field defined as a floating-point value. So long as it was represented by a comma (null value) in their data, no problem. Then they put character data in it enclosed in parens.

Program no like. I also found out that in the same record they have been populating field #39 with character data even though it shows in the doc as "reserved".. turns out that data is what they term Gate Call Position. I guess in routes it could be different from the "first call" in the pp line.

[Tom]

Gottcha. I use a blank field as a spacer in my Infotran files.

[DJofSD]

In my job I use documentation provided by the vendor of a computer operating system that, in part, describes data structures used by the operating system. Quiet often, there are fields which are marked as reserved. Typically this means not is use at this time.

In the bad old days, other vendors would exploit these fields for their own use.
Things would be OK, going along swimmingly until all of a sudden some piece of maintenance or a new release of a product would cause things to break.

What I am trying to say is you cannot assume anything about the field that is described as reserved -- best leave it alone altogther.

[rrbauer]

In my job I use documentation provided by the vendor of a computer operating system that, in part, describes data structures used by the operating system. Quiet often, there are fields which are marked as reserved. Typically this means not is use at this time.

In the bad old days, other vendors would exploit these fields for their own use.
Things would be OK, going along swimmingly until all of a sudden some piece of maintenance or a new release of a product would cause things to break.

What I am trying to say is you cannot assume anything about the field that is described as reserved -- best leave it alone altogther.

I would love to "leave it alone". However, they use a comma delimiter as a marker for the field even though it is not in use at this time. So in a formatted read I have to deal with it even if for no other reason than to get past the comma.

[cj]

I would love to "leave it alone". However, they use a comma delimiter as a marker for the field even though it is not in use at this time. So in a formatted read I have to deal with it even if for no other reason than to get past the comma.


I treat all reserved fields as text (strings), that way you never get an error. If you want to change them later, it is easy.

[rrbauer]

I treat all reserved fields as text (strings), that way you never get an error. If you want to change them later, it is easy.

If my parsing routines were written in "C" that would be fine. They are written in MS-F77 and it is very strict about data typing and it expects "string" data to be enclosed in parens. I appreciate the tips but in this case I'm being driven by the old, "if it works don't fix it" motive! And these routines have been doing this just fine for about 20 years!

[DJofSD]

MS-F77? MicroSoft FORTRAN 77?

[cj]

If my parsing routines were written in "C" that would be fine. They are written in MS-F77 and it is very strict about data typing and it expects "string" data to be enclosed in parens. I appreciate the tips but in this case I'm being driven by the old, "if it works don't fix it" motive! And these routines have been doing this just fine for about 20 years!

Gotcha...the good thing when you write your own code is that changes are usually apparent right away, even if undocumented.

[raybo]

In my job I use documentation provided by the vendor of a computer operating system that, in part, describes data structures used by the operating system. Quiet often, there are fields which are marked as reserved. Typically this means not is use at this time.

In the bad old days, other vendors would exploit these fields for their own use.
Things would be OK, going along swimmingly until all of a sudden some piece of maintenance or a new release of a product would cause things to break.

What I am trying to say is you cannot assume anything about the field that is described as reserved -- best leave it alone altogther.

I guess I don't get it either. When Bris calls a field "reserved" that means it's not used for reasons of future expansion purposes. I never, in 10 years of using Bris data files, thought that they would not, at some point, utilize at least some of these reserved fields for new data.