91–100 of 139 posts
My impression was that COBOL has only a global data space, and that there is no way to write functions - rather like the original BASIC?
My overall impression is that it's verbose (obviously), but it's also fairly straight-forward and easy to read even if you don't know COBOL.
The most interesting part of it, for me anyway, are the 88-level declarations[0]. Basically it's like a logic test encapsulated in a variable. You can say something like "IF STAFF-MEMBER" where STAFF-MEMBER actually means that some field has a certain value. It makes it easy to understand in some respects, but also adds a layer of obfuscation.
[0] http://www.mainframestechhelp.com/tutorials/cobol/cobol-88-l...
Is there a version of COBOL that support's FORTRAN's feature of changing the value of a constant? It would be so cool if you could go "ADD ONE TO FIVE". https://everything2.com/title/Changing+the+value+of+5+in+FOR...
One thing I don’t understand with these very old languages is that I thought the reason they are still around is because of some programs written in the 70s to early 90s are still around and needs to be maintained. But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on. What makes it that e…
> But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on. What makes it that expensive that no one wants to rewrite them in a modern language? You would be utterly shocked. I did some COBOL work for a bank. Most of the new code they write is in C++. However, COBOL was still a huge part of t…
1. Introduction of errors (both overt and subtle)
2. Fixing of what seem to be issues in the original code that are actually undocumented workarounds (or similar things) to potential bugs (in COBOL or who-knows-what-else-in-the-codebase)
Both are big issues in such a move; software engineers don't often appreciate that much of this old stuff is still around because it WORKS. It has been virtually fully debugged, just through the iteration of time and experience.
So porting can easily introduce bugs that may not be apparent immediately; and because software engineers are always wanting to make thing better, if they are working with the COBOL codebase and see something that they think could be done "better" - that change might actually cause problems down the road, perhaps in ways that aren't recognized immediately, or only in edge cases - things that were worked around decades ago in the COBOL implementation.
Don't like COBOL but the way it specifies data formats was practical. 9(5) = 5 digits, X(20) = 20 characters, etc. From time to time I catch myself using these while drafting a table or data structure.
That gets to be a little old.
Sincerely, CHRISTOPHE (or, as I'm usually known, Christopher)
I worked for one of those companies using COBOL. This strikes me: > Once I discovered what the problem was, the fix was easy: I deleted one character of white space from the beginning of line 19, which put the period at column 72. Although I'd never encountered it before, this was such a common bug that many mainframe COBOL programmers would tape a piece of thread between columns 72 and 73 on their terminals. Why wou…
Of course retrospectively with gigabytes at our disposal it is hard to put yourself in that frame of mind.
Maybe it helps to understand this better if you realize that the assembler that I cut my teeth on only supported 6 character labels and symbols.
Is there a version of COBOL that support's FORTRAN's feature of changing the value of a constant? It would be so cool if you could go "ADD ONE TO FIVE". https://everything2.com/title/Changing+the+value+of+5+in+FOR...
That is a truly remarkable feature! Does it come with the ability to change the definition of "constant"?
It's surprisingly well adapted to web development too http://www.coboloncogs.org/
https://github.com/azac/cobol-on-wheelchair/blob/master/READ...
There was this really great COBOL programmer back in the 1990's who was making piles of money hand over fist, but was overworked and getting really tired of working on Y2K fixes, and becoming extremely worried that civilization was going to collapse due to Y2K bugs. She never wanted to look at another line of COBOL ever again, she was so sick of it. So she signed up with Alcor, and had herself cryonically frozen in 1…
I have not used COBOL for 30 years but the language deserves respect. The transition from assembler to COBOL was one of the biggest productivity improvements in the history of programming, comparable to the introduction of Java and VM-based programs in the 1990s. COBOL is still pretty efficient for tasks like scanning data on magnetic tapes--not that most of us do that any more. In fact it was pretty good for any pro…
The best thing about COBOL is the distinct lack of hipster coders or frameworks. I worked on various COBOL code bases over the years, and they were always approachable, if a little long-winded. My cheques still process via COBOL code a friend's grandmother wrote and still runs on emulated Unisys hardware.