Hacker News Reader

Comment by skissane | Hacker News Reader

I'd love to know what technologies the Bloomberg Terminal, and the host side, were originally implemented with, back when they started in the 1980s. I've searched for information on this topic, but haven't had much luck finding answers.

View on HN

They used 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!

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.

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.

> 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/...

That's the one, a great story!

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

The pre-PC ones were basically SBCs running an OS provided by a certain well known CPU vendor. Original code on that side was PL/M before the whole thing went to Windows / C++.

Host side was mentioned in a sibling. It was all serial modem muxes back then, 300 baud up to 4800 baud backhaul.

Obviously it looks nothing like that today :)

Edit: from the man himself https://m.youtube.com/watch?feature=youtu.be&t=10m8s&v=WsRpY...

> The pre-PC ones were basically SBCs running an OS provided by a certain well known CPU vendor. Original code on that side was PL/M

I am guessing that you are talking about either Intel's ISIS or RMX operating systems?

Yes, RMX. Using a 2020 lens (pre-PC 80s were the Wild West, not diminishing any engineering effort there) the systems were straightforward. When PCs came about and everyone else was making mostly desktop software, all the real value (apps & data) remained from the very beginning “in the cloud”. It would be hard to predict that model would be exactly what everyone was clamoring for 30 years later.

C and FORTRAN.

Reply on news.ycombinator.com