3 ms·

Before I worked on the product they tried, I am told, to port it to .NET and WIN servers, but it was so slow in comaprison that they quickly gave up. Huge amoun

Before I worked on the product they tried, I am told, to port it to .NET and WIN servers, but it was so slow in comaprison that they quickly gave up. Huge amounts of data in chain store databases and linked services accross the country, all sorts of integration. These are of course things that .NET can handle very well, but apparently not as fast as COBOL binary files and an ODBC database.

SmellyGeekBoy 11y ago
I actually have some experience in getting .NET to talk to COBOL flat file databases and I agree it's not something that anyone seems to have managed to get 100% right. CONNX is a pretty good product but still seems to suffer from locking and needing to manually restart the service from time to time, and this was on a project much smaller in scale than anything a group as big as Dixons would need. As a .NET developer myself I certainly don't envy the guys who had to deal with all our complaints from the shop floor, and of course the ageing SCO system had to be replaced with something. These days it would probably be something lightweight and browser based as opposed to a full-blown WinForms application, pretty much emulating the old terminal-based setup (hardware-wise if not interface-wise). The keyboard navigation and super-low-latency feedback of the old system would still be a huge challenge, though.
digi_owl 11y ago
A quick glance at the COBOL page on Wikipedia it seems to "suffer" from the kind of verbosity that has also sunk ADA (as i understand it at least). Frankly i find myself wondering if it is high time that computer education is split between computer science and computer engineering. It seems to me that much of the ailments of the computing world is that people keep bringing stuff from computer science into the larger world virtually untested.

3 ms·

Before I worked on the product they tried, I am told, to port it to .NET and WIN servers, but it was so slow in comaprison that they quickly gave up. Huge amoun

by kagamine 11y ago

SmellyGeekBoy 11y ago
I actually have some experience in getting .NET to talk to COBOL flat file databases and I agree it's not something that anyone seems to have managed to get 100% right. CONNX is a pretty good product but still seems to suffer from locking and needing to manually restart the service from time to time, and this was on a project much smaller in scale than anything a group as big as Dixons would need. As a .NET developer myself I certainly don't envy the guys who had to deal with all our complaints from the shop floor, and of course the ageing SCO system had to be replaced with something. These days it would probably be something lightweight and browser based as opposed to a full-blown WinForms application, pretty much emulating the old terminal-based setup (hardware-wise if not interface-wise). The keyboard navigation and super-low-latency feedback of the old system would still be a huge challenge, though.
digi_owl 11y ago
A quick glance at the COBOL page on Wikipedia it seems to "suffer" from the kind of verbosity that has also sunk ADA (as i understand it at least). Frankly i find myself wondering if it is high time that computer education is split between computer science and computer engineering. It seems to me that much of the ailments of the computing world is that people keep bringing stuff from computer science into the larger world virtually untested.