4 ms·

One of the real gotchas in old systems is the data limits. So systems working fine, all working with say a name field that's locked in at 40 characters as that

by Zenst 6y ago

One of the real gotchas in old systems is the data limits. So systems working fine, all working with say a name field that's locked in at 40 characters as that when original designed was enough and storage wasn't cheap then. Or a comments field, 250 characters felt generous back then, today - that's the first sentence just about. So you get old fine working do the job systems, then you get what I call bolt-ons to those systems, web front-end and the like that all distill the input into a format the old working system can take in. Which is fine, but the data limits of the back-end really do start to stand out more and more then and seen many a case of a front-end allowing more input only for it to get blindly truncated before it is fed into the backend. Things like that can and do create interesting issues. Though as true today as it was back when COBOL was born - garbage in garbage out.

kqr 6y ago
Isn't that a matter of abstraction? We have to consider the old backend a type of "virtual machine" with a domain-specific instruction set. Of course, this is a rather funny virtual machine with some odd technical limitations, but it's not infeasible to consider writing a new back-end (middle end? middle...ware?) that targets the old funny backend but abstracts over its limitations e.g. by using two records to get additional name storage. Depending on how complicated the business logic rules encoded in the old backend are, could this be more efficient than modifying the old backend?
- Zenst 6y ago
  Generally and for many things, augmenting the existing backend is the best way over a rewrite which would take more than 5 years for many systems and with that, get shot down by accountants and management bureaucracy. As for the VM analogy, hmmmm from a data perspective, maybe. But it all boils down to how the old system stores data, and some will enable you to hold multiple records and for example a comments field. May have the last character closed of from input as it is a continuation marker that means there is another record and they are joined, as you say two records. Changes like that will entail changes to the backend, though the impact can be more manageable than alternatives. Then you can use replication or data warehousing and from that, lots of reports and other aspects that would hammer the backend become much more pleasant. Crux is the limitations, things like names, so entwined into a system that it does not lend itself to the two records solution. So you use another solution. You mention business rules and that is very much key and having somebody who knows the business logic is way more valuable to understanding the a system than knowing the language it is written in. So as an aside, if I had to employ somebody to work on an old legacy system, I'd take the person who knew or showed a grasp of the business logic and how that works over somebody who knew COBOL. As it is easier to teach COBOL than an entire business. COBOL has many books and resources, a business tends not to have such clear cut documentation.

by Zenst 6y ago

kqr 6y ago

Isn't that a matter of abstraction? We have to consider the old backend a type of "virtual machine" with a domain-specific instruction set. Of course, this is a rather funny virtual machine with some odd technical limitations, but it's not infeasible to consider writing a new back-end (middle end? middle...ware?) that targets the old funny backend but abstracts over its limitations e.g. by using two records to get additional name storage. Depending on how complicated the business logic rules encoded in the old backend are, could this be more efficient than modifying the old backend?

Zenst 6y ago
Generally and for many things, augmenting the existing backend is the best way over a rewrite which would take more than 5 years for many systems and with that, get shot down by accountants and management bureaucracy. As for the VM analogy, hmmmm from a data perspective, maybe. But it all boils down to how the old system stores data, and some will enable you to hold multiple records and for example a comments field. May have the last character closed of from input as it is a continuation marker that means there is another record and they are joined, as you say two records. Changes like that will entail changes to the backend, though the impact can be more manageable than alternatives. Then you can use replication or data warehousing and from that, lots of reports and other aspects that would hammer the backend become much more pleasant. Crux is the limitations, things like names, so entwined into a system that it does not lend itself to the two records solution. So you use another solution. You mention business rules and that is very much key and having somebody who knows the business logic is way more valuable to understanding the a system than knowing the language it is written in. So as an aside, if I had to employ somebody to work on an old legacy system, I'd take the person who knew or showed a grasp of the business logic and how that works over somebody who knew COBOL. As it is easier to teach COBOL than an entire business. COBOL has many books and resources, a business tends not to have such clear cut documentation.