They say that UTF-16 is a fixed width encoding. But I don’t think this is the case.
IBM COBOL for Linux on x86
101–110 of 112 posts
Re: IBM COBOL for Linux on x86
#102Seeing this and another thread about this https://gnucobol.sourceforge.io; wonder and guess none interoperability ba.
Re: IBM COBOL for Linux on x86
#103I remember years ago there was a contest for the most error messages from the fewest lines of code from a compiler. I believe you could get the IBM COBOL compiler to generate 600 lines of error messages if you put a single period in column 6. Of course times have changed and I don't know how to get a punched card into a linux machine. :)
Five spaces and a period.
with a proper drum card, you could just press skip. ;)
Re: IBM COBOL for Linux on x86
#104Earlier quoted context omitted.
> I can assure you that "Quickbook Payroll" would not be able to handle this on a similarly resourced x86 machine. Not even close. Why? I've been into x86 databases since the Windows NT days and 5000 doesn't seem an impressive number to me.
The OP's comment was conditional: on a similarly resourced x86 machine . Windows, let alone Quickbooks is not going to run very well on a machine with just 512MB of RAM.
Windows NT/2000/98 would run really well on 512MB of RAM.
Re: IBM COBOL for Linux on x86
#105I'm just imagining the level of jaw dropping and brain exploding that would have gone on had that same headline been published in 1998. Obviously at this point almost three decades into the internet era no one really cares. We all know that "somewhere" old COBOL code is running, but in practice the companies managing the bulk of data for society didn't even exist before Y2K. Everyone with unmaintainable COBOL has lon…
> I'm just imagining the level of jaw dropping and brain exploding that would have gone on had that same headline been published in 1998.
I worked at IBM at the time and we had internal-use-only versions of a lot of major IBM AIX/Unix software running on Linux by 1998. Our experiments with running it directly on big iron started around then too. At least in my area most of the engineers were moving from X terminals to Linux desktops at that point so porting the software they were working on was inevitable.
Re: IBM COBOL for Linux on x86
#106COBOL will always have a soft spot in my heart as the first programming language I learned. I did not use it much - 2 years max - but when reading COBOL it was really clear that there were some programmers who just saw code differently - in an abstract, artistic sense. It was the ultimate litmus test. COBOL is really easy to write spaghetti code with - perhaps even the default. But some of these programmers (not incl…
I worked full time maintaining a huge COBOL system in the 90s. Seeing how a massive code base could be elegantly structured around COBOL gave me a new respect for the language, and the original developers. I always felt a warm sense of pride every time I managed to improve upon their work.
It's not so much that languages are good or bad, it's developers that are. COBOL can be made elegant, Swift can be made ugly. Even driftwood can be made beautiful.
Re: IBM COBOL for Linux on x86
#107I wonder how much better than GnuCOBOL it is. https://gnucobol.sourceforge.io/
Probably a lot. Gnu COBOL has some annoying limitations, such as no easy to use network API, nor do they make it easy to read-write files whose names are not declared at compile time.
Re: IBM COBOL for Linux on x86
#108COBOL will always have a soft spot in my heart as the first programming language I learned. I did not use it much - 2 years max - but when reading COBOL it was really clear that there were some programmers who just saw code differently - in an abstract, artistic sense. It was the ultimate litmus test. COBOL is really easy to write spaghetti code with - perhaps even the default. But some of these programmers (not incl…
some programmers who just saw code differently - in an abstract, artistic Yes, some people like this are absolute geniuses.... And also result in code that's incredibly difficult to maintain, especially when it wasn't well documented or documentation binders have been sitting in boxes at some off-site cold storage for 25 years. For anything that isn't pushing the boundaries of computing, I'd much prefer a few experts…
^^ I understand my comment on genius could be seen in a negative light, e.g., genius-level intellects are problematic and perhaps undesired. I mean quite the opposite:
1) I prefer geniuses to be working in areas where they are pushing boundaries further. I don't think such talent is used wisely in service to finding novel solutions to mundane problems much faster than the average expert. Better to throw three experts at the problem instead.
2) However, sometimes a large organization finds itself with a true genius in the ranks. (It might just be the sort of work they enjoy, or the best job in their region and they don't want to relocate, or any other factor) The problem is that even well-organized large organizations are is highly structured and setup to organize the massively vast majority of people who are not geniuses.
Yet a true genius is inherently an agent of chaos. They are a genius precisely (in part) because they see things beyond the current structures & paradigms, and realizing their potential requires them to either break or circumvent the current status quo. If you put such a person in an agile scrum and assign them stories, they will either
1) Quit out of boredom
2) Fuck off on their responsibilities out of boredom.
3) Complete their assigned tasks finding novel and interesting ways to solve (compared to their capacity) stupidly simple problems that will make future code maintenance a nightmare when a mere expert or newbie has to decipher it.
4) If #3, they may have their productivity recognized and be promoted into a PM/Manager type of role they will hate, at which point see #1 & #2.
Under #2 & #3, if you're fortunate, they will spend their copious free time finding more interesting things to do that benefit the organization. If not, they'll be off pursuing their own curiosity.
So, any organization should have some mechanism of recognizing these individuals (This is not something I have an easy solution for because, given #1 & #2 above, they can sometimes be indistinguishable from lazy/incompetent) However, if recognize, you need to set them to very challenging tasks suited to the direction of their genius:
Build a team around them. At least one of those team members needs to be an expert. This is the person that will act as a buffer between the genius and everyone else. The expert will also coordinate with the rest of the team to determine the practical/logistics involved in making use of the output of the genius. They will systematize the chaotic creative forces at work. They will document, they will disseminate to the rest of the organization, they will ensure that the incredible value of the genius's work isn't lost if/when the genius moves on, retires, or whatever.
How do I know this? I've seen one or two geniuses myself. I have even experienced this dynamic first hand. Let me be clear though: I am absolutely not a genius on that level. I am very much a generalist with a few areas that extend close to expertise. I have, however, found myself working in organizations that are so far behind what is possible that even very basic things have had people label me a "genius", which is very embarrassing because I'm not. And what I've done-- to use an artistic metaphor-- is kindergarten finger painting, Yet presented to a crowd that's never seen art, I am praised as a Picasso. Seriously: Pulling down 5 years of data, pre-processing in python (my preference) and running some basic regressions in R to show that a current very time-consuming process was useless was thought to be revolutionary.
As a result, I've been through #1, #2, #3, and I'm currently resisting #4. When in #3, which is most of the time, I try to document as much as possible and make sure anyone who would be responsible for my work if I left is fully in the loop on what I'm doing. And I get to spend about 10% of my time on things I find truly interesting that push my own limits. But I like working for organizations that are behind the times, if they are flexible to accept change. I like it precisely because while I am not a genius, I am pretty good, and working with such organizations still allows me to make an outsized impact on them for the good.
Re: IBM COBOL for Linux on x86
#109I'm just imagining the level of jaw dropping and brain exploding that would have gone on had that same headline been published in 1998. Obviously at this point almost three decades into the internet era no one really cares. We all know that "somewhere" old COBOL code is running, but in practice the companies managing the bulk of data for society didn't even exist before Y2K. Everyone with unmaintainable COBOL has lon…
1998 was a bit early, but I could easily have imagined it any time after 2000. I'm frankly surprised it has taken this long.