I can't speak for COBOL per-se, but many years ago I worked on medical lab software. Our product was written in PL/I (subset G, Digital Research's compiler). It was a VERY extensive system with about 2 million lines of PL/I and about 100K lines of x86 assembly (much of both it written by me--and the TSRs and instrument handlers were in C and x86 doing interrupt-driven stuff on the serial ports under DesqView/OmniView). This application was based on Btrieve's record manager and ran in a small-model DOS application (64K program, 64K data) running over Novell Netware with _very extensive_ overlaying... I am proud of what we could do...
As time went on it got harder and harder to find PL/I developers and we were constantly fighting against the limitations of small-model code . We eventually decided to "rewrite" in C++ (this was around the Windows 3.11 era, so it was that or Java 1, really). We used an expert-system (Alydaar, where are you?) to morph the PL/I code to C++ classes and I wrote a library to extensively emulate the PL/I's CHAR, VARCHAR, FIXED BINARY and FIXED DECIMAL data types (and believe me, that was NOT easy, but at least FLOAT BINARY was IEEE). This was an essential step to an eventual migration to "real" C++ OOP, and a "real" database (SQL Server), but on the way we still had to support running side-by-side with existing PL/I DOS versions, and later also had to support the access to the archived data in its original Btrieve databases. In the medical industry, you essentially have to be able to review abnormal results forever and normal results for 15 year so optical media (the predecessors to our CD-ROMs) wa the storage media of choice. You don't just arbitrariy convert data on read-only disks you can't even find replacement drives for! So, can you guess what the data format of those Btrieve records was? It was fixed-length strings all around. Another MAJOR factor was the difficulty of testing an application of this scope (running in > 400 hospitals world-wide, with end-user configuration options running in the 100s) long before the days of nUnit/jUnit or anything else... we basically couldn't RISK the change of data formats because of the "interesting" and possibling "unintended" sematics of the fixed-string formats. So I find all this discussion about "why would you do that" a little suspect... we don't know the business requirements that drive these choices. What I do know is that it is distinctly plausible to emulate those fixed-length/blank-padded strings in C++, so it's probably not much harder to do in .Net Simply put, if you're going up against another company that says "can do, in Java" you either better be able to A) walk away, or B) say "can do, in .Net". -- "We do not have the luxury of making that risky assumption that people will not be affected by the potential change. I know this can be frustrating for you as it is for us. Thanks for your understanding in this matter.." --Some misguided soul at Microsoft Marc C. Brooks http://musingmarc.blogspot.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
