3 ms·

They used https://en.wikipedia.org/wiki/Interdata_7/32_and_8/32 https://en.wikipedia.org/wiki/Interdata_7/32_and_8/32 and the Interdata OS/32 operating system.

They used https://en.wikipedia.org/wiki/Interdata_7/32_and_8/32 https://en.wikipedia.org/wiki/Interdata_7/32_and_8/32 and the Interdata OS/32 operating system. They wrote all the code in Fortran. There is a clue about the rationale for that in the Bloomberg on Bloomberg book: from memory it's something like that they didn't want the (now defunct) investment bank they'd come from to think they'd copied anything so they used a different OS and language. I think they did some pretty interesting things with their own networking technology to get all the market data around the place back then but I know nothing about any of that. One interesting thing about the Interdata systems is that they were the first non-PDPs to run Unix, via a guerilla porting project done at a university in Australia. Bloomberg used the native OS/32 though, and somewhere there is a paper from that Australian university that gives a scathing review of it. Some kind of timesharing, but with a single console where all output would appear. That made me laugh, because the 'console room' was Bloomberg lingo for a kind of sysadmin group. Later Bloomberg used a lot of different commercial Unix variants. At least HP/UX, AIX, Solaris and RHEL are used, and a lot of C++, Javascript and other languages. There is still plenty of older code from the Interdata OS/32 days in service though and a lot of unusual system control scripts and commands from that defunct system. I guess (?) it's probably nearly all Linux by now though!

apaprocki 7y ago
The Interdata (PE) OS/32 manual is here, for those interested: http://www.dvq.com/oldcomp/interdata/interdata-os_32_mt-pgm-config-manual-opt.pdf http://www.dvq.com/oldcomp/interdata/interdata-os_32_mt-pgm-...
JackFr 7y ago
I was tasked with calculating OAS durations on callable agency bonds with the Bloomberg API in Perl in the 90's. Basically I'd take the price and use the API to get the OAS, then bump the OAS up and down a basis point, calculate price up and price down and get the difference. The problem was sporadically I'd get a price back that was out of line. It would match to the 5th or 6th decimal, but then would diverge. I could make the same call 10 times in a row and the price would be identical 8 times, but 2 others it would be different in the 5th or 6th decimals. Since I was taking the difference of two prices which were relatively close otherwise, this would wreck havoc with my results. Bloomberg support was always quick with a response, but often the first level support had no idea what they were talking about. For two weeks they kept insisting that because the yield curve I was pricing with was live, what I was seeing was because of market moves. Finally I got to someone who was on the implementation team for that bit of code, and he explained that they had both Data General and Perkin Elmer (Interdata) machines supporting that function, and the answers depended on which architecture handled the response.
- raldi 7y ago
  When I worked there (2003-2007), first level support was where new hires learned the ropes before moving on to their actual assignments. It was an amazing way to keep employees well in touch with customers' needs, and at least at the time the program seemed to be well-enough run to deliver great customer support. Sorry to hear your experience was different.
skissane 7y ago
> somewhere there is a paper from that Australian university that gives a scathing review of it You are probably thinking of this: http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/32bit/unix/univWollongong_v6/miller.pdf http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/...
- macdice 7y ago
  That's the one, a great story!

apaprocki 7y ago

The Interdata (PE) OS/32 manual is here, for those interested: http://www.dvq.com/oldcomp/interdata/interdata-os_32_mt-pgm-config-manual-opt.pdf http://www.dvq.com/oldcomp/interdata/interdata-os_32_mt-pgm-...

JackFr 7y ago

I was tasked with calculating OAS durations on callable agency bonds with the Bloomberg API in Perl in the 90's. Basically I'd take the price and use the API to get the OAS, then bump the OAS up and down a basis point, calculate price up and price down and get the difference. The problem was sporadically I'd get a price back that was out of line. It would match to the 5th or 6th decimal, but then would diverge. I could make the same call 10 times in a row and the price would be identical 8 times, but 2 others it would be different in the 5th or 6th decimals. Since I was taking the difference of two prices which were relatively close otherwise, this would wreck havoc with my results. Bloomberg support was always quick with a response, but often the first level support had no idea what they were talking about. For two weeks they kept insisting that because the yield curve I was pricing with was live, what I was seeing was because of market moves. Finally I got to someone who was on the implementation team for that bit of code, and he explained that they had both Data General and Perkin Elmer (Interdata) machines supporting that function, and the answers depended on which architecture handled the response.

raldi 7y ago
When I worked there (2003-2007), first level support was where new hires learned the ropes before moving on to their actual assignments. It was an amazing way to keep employees well in touch with customers' needs, and at least at the time the program seemed to be well-enough run to deliver great customer support. Sorry to hear your experience was different.

skissane 7y ago

> somewhere there is a paper from that Australian university that gives a scathing review of it You are probably thinking of this: http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/32bit/unix/univWollongong_v6/miller.pdf http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/...

macdice 7y ago
That's the one, a great story!