111–120 of 139 posts
Shipping price conforms to a "pic 99v99". So what happens if a really big shipment needs to be made for which $100.47 needs to be charged?
Earlier quoted context omitted.
That’s actually quite readable
Readability is relative, of course. It's more readable than assembly language, compared to which COBOL is a win (for its intended use, of course). Compared to GW Basic (or any Basic with line numbers) it's probably about the same, though more verbose. Compared to a modern language, it's less readable and full of bizarre boilerplate. The question is, if you are not forced by a customer (such as a bank) or by the need…
Earlier quoted context omitted.
The feature we’re talking about here is an easy to use version of doing memory layouts like you’d do with C structs and unions. And combined in with that is automatic number formatting. And all of it uses a clean concise layout that’s self documenting.
COBOL structures are better for fixed-length strings than C structs are because C really prefers strings do be null terminated. In C you've got to specify the length of each string, whereas in COBOL the compiler takes care of that for you.
struct foo {
int count;
char name[16]; /* not null terminated! */
};
1> (typedef foo (struct foo (count int) (name (array 16 char))))
#
2> (ffi-put #S(foo count 42 name "ABCDABCDABCDABCD") (ffi foo))
#b'2a00000041424344 4142434441424344 41424344'
3> (ffi-get *2 (ffi foo))
#S(foo count 42 name "ABCDABCDABCDABCD")
Now, for fun, let's poke a zero byte into that buffer:
4> (set [*2 8] 0)
0
5> *2
#b'2a00000041424344 0042434441424344 41424344'
6> (ffi-get *2 (ffi foo))
#S(foo count 42 name "ABCD\xDC00;BCDABCDABCD")
If that U+DC00 is encoded back, it will reproduce the null byte:
7> (ffi-put *6 (ffi foo))
#b'2a00000041424344 0042434441424344 41424344'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…
That 72-character limit came about because the most popular IBM punch card reader at the time COBOL was being written could only read 72 of the 80 characters on a card. Once you know that anything after column 72 will be ignored, you can repurpose those columns for other things. At my shop we used them to denote revision numbers. And once practices like that get set, you're pretty much stuck with the older formatting…
Earlier quoted context omitted.
Readability is relative, of course. It's more readable than assembly language, compared to which COBOL is a win (for its intended use, of course). Compared to GW Basic (or any Basic with line numbers) it's probably about the same, though more verbose. Compared to a modern language, it's less readable and full of bizarre boilerplate. The question is, if you are not forced by a customer (such as a bank) or by the need…
Sure, if the money was right. I actually know a bit of COBOL, most of it forgotten. After a while I would move on if they didn’t give me other projects, but I’d even be willing to do it in parallel.
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…
Yep, that. I did a two-year stint in a major financial network. I guess it's not a lot of time, but while I was there, there was a big outage and it was not on the mainframe side of things- some all modern server farm bought the, er, farm.
From what I can tell, at least in that company, mainframes are still in use because their stability is simply unmatched by anything in the "distributed" world; Cobol is still in use because mainframes are still in use; and nobody dares replace the Cobol code with something else, because the code itself is damn stable, as a result of hundreds of people having worked on it for several decades now- and counting.
In general, Cobol on mainframes is a rock-solid system that doesn't fall down and that nobody wants to disturb.
Earlier quoted context omitted.
Cobol programmers are starting to get few nowadays, and finding people that actually want to be trained in it is not that easy. Plus you dont just need programmers, but z/OS engineers, DB2 DBAs, MQ specialists, etc. And that's before you even start talking about the nice cheque you're writing for IBM every month. It does add up.
Most if not all such managers (I always look for explanations in these cases that are not ascribed to an abstract business entity, but to individual people) have no stomach for porting. A typical manager's tenure over an organization that might have the scope to perform the port is shorter than the porting project itself. No manager wants to have such a large, expensive, risky project on their accomplishments list as…
I don't think that's the case. In the place I worked (major financial network) the average time people seemed to have ben with the company was 10 years. Especially in big companies, you can expect to see lots of people who go for a long-term career, instead of hopping from job to job (and promotion).
I think the real reason why management doesn't dare to make big changes is that they understand there's a very real risk to cause a significant loss to the company (and lose their job, as a consequence).
Which is why Cobol shops have absolutely mad processes. Where I worked, to make a change to a Cobol program -even if it was just the JCL that would run it- we had to complete a ten-page form, submit it and wait. They basically just don't let you touch the code. You work around it, sorta.
Earlier quoted context omitted.
Most if not all such managers (I always look for explanations in these cases that are not ascribed to an abstract business entity, but to individual people) have no stomach for porting. A typical manager's tenure over an organization that might have the scope to perform the port is shorter than the porting project itself. No manager wants to have such a large, expensive, risky project on their accomplishments list as…
As i've made clear in my other posts in this thread, i dont believe in rewrites. I've seen lots of very painful ones though, and never quite finished, nor iso-functional. However, there are other ways to unplug the mainframe. I would disagree with the assessment that management is too dysfunctional, it depends. But if they all were like you described, i would be out of work. And it just happens that we turned off a m…
Aw. I hope you didn't hurt it.
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…
"Dragged" as in it rains money on them until they stop saying "no".