IBM Creates a COBOL Compiler For Linux On x86 (theregister.com) 188
IBM has announced a COBOL compiler for Linux on x86. "IBM COBOL for Linux on x86 1.1 brings IBM's COBOL compilation technologies and capabilities to the Linux on x86 environment," said IBM in an announcement, describing it as "the latest addition to the IBM COBOL compiler family, which includes Enterprise COBOL for z/OS and COBOL for AIX." The Register reports: COBOL -- the common business-oriented language -- has its roots in the 1950s and is synonymous with the mainframe age and difficulties paying down technical debt accrued since a bygone era of computing. So why is IBM -- which is today obsessed with hybrid clouds -- bothering to offer a COBOL compiler for Linux on x86? Because IBM thinks you may want your COBOL apps in a hybrid cloud, albeit the kind of hybrid IBM fancies, which can mean a mix of z/OS, AIX, mainframes, POWER systems and actual public clouds.
[...]
But the announcement also suggests IBM doesn't completely believe this COBOL on x86 Linux caper has a future as it concludes: "This solution also provides organizations with the flexibility to move workloads back to IBM Z should performance and throughput requirements increase, or to share business logic and data with CICS Transaction Server for z/OS." The new offering requires RHEL 7.8 or later, or Ubuntu Server 16.04 LTS, 18.04 LTS, or later.
[...]
But the announcement also suggests IBM doesn't completely believe this COBOL on x86 Linux caper has a future as it concludes: "This solution also provides organizations with the flexibility to move workloads back to IBM Z should performance and throughput requirements increase, or to share business logic and data with CICS Transaction Server for z/OS." The new offering requires RHEL 7.8 or later, or Ubuntu Server 16.04 LTS, 18.04 LTS, or later.
serious geek boner right now (Score:5, Funny)
Always kind of interested me.. (Score:2)
Cobol has always kind of interested me. It's my understanding that Cobol is reasonably easy to learn and the code is more-or-less self-documenting. Someday (someday...) I'll probably get around to playing with Cobol just for the hell of it.
But I don't think it's going to be IBM's Cobol since they'll want a hefty price for it. (I checked the website, there's a tab labelled "pricing" but there's no content there yet.)
https://gnucobol.sourceforge.i... [sourceforge.io] is free, though, and if I do actually get off my butt an
Re: (Score:2)
I recall seeing COBOL in the portfolio of the Microfocus as well. There may be more spin-offs.
Re: Always kind of interested me.. (Score:2)
Last time I looked, there were three open source COBOL "lite"s (IE: partial), Micro Focus, Faircom, Actian, Veryant and AMT.
The question for me is, why are IBM jumping into a crowded market?
Re: (Score:2)
Comment removed (Score:5, Interesting)
Re: (Score:2)
If you're used to working in a modern language, I think the verbosity of COBOL will crush your soul. But then, Java persists, so what do I know?
Re: (Score:2)
I love a good Java bashing but is Java really more verbose than C#. I mean class patterns in general are "verbose" simply because the patterns that exist with whitespace which I think is why people eventually really pushed for inline functions, so you can have a simple line that includes a simple function without having all the extra whitespace. Of course there is a lot more to that decision but nonetheless, it seems like one reason people can like them and probably overuse them as an anti-pattern.
Re: (Score:2)
Re: (Score:2)
Plain Java is way better than IBM's EGL or VG - which is a language that you can then generate COBOL or Java code with for back end and JSPs for front end.
Re: (Score:2)
I agree with you, but apparently verbosity isn't the downside some of us think it is. See: Powershell still existing
Re: (Score:2)
Verbose languages are less of an issue today than they were 30 years ago.
1. Modern Displays can do 230 characters in one screen, clearly and readable. Back in the old days 80 column displays were the high resolution screens. Old school verbose languages were stuck with a lot of line wrapping, (or if they were card based, a lot of extra cards)
2. Modern IDEs allow type ahead, and searching for commands. This makes referencing long winded commands much faster and easier, often requiring you only type a couple
Re: (Score:2)
I think RPG is far more "self-documenting" than COBOL and I agree with jlowery that the verbosity of COBOL can be soul crushing. Nonetheless, playing with it or at least seeing some basic programs in it, can be a good experience.
Re: (Score:3)
The announcement already sounds expensive enough:
IBM COBOL for Linux on x86 1.1 introduce the following part numbers:
Part number description Part number
IBM COBOL for Linux on x86 Virtual Processor Core License + SW Subscription & Support 12 Months D28XQLL
IBM COBOL for Linux on x86 Virtual Processor Core License SW Subscription & Support Renewal E0R5KLL
IBM COBOL for Linux on x86 Virtual Processor Core License SW Subscription & Support Reinstatement 12 Months D28XRLL
IBM COBOL for Linux on x86 Virtual Processor Core License Monthly License D28XTLL
Something with a monthly support plan generally isn't cheap.
I suppose the big reason is it's IBM - they know that many big companies have extensive amounts of COBOL code running throughout, and maybe on aging mainframe hardware they wish to migrate off of for various reasons.
COBOL is
Re: (Score:2)
Anyone who is even remotely interested in this doesn't give a damn about the maintenance subscription, because they want this in order to shift away from even more expensive maintenance on a Z-series mainframe or many P-series AIX servers or aging AS/400 installs. Being able to run their decades-old legacy apps on Linux/x86 means being able to virtualize right next to their other x86 server workloads on their already existing vSphere clusters, existing cloud environments, or for the more adventurous, conta
Re: (Score:2)
This could very well help companies migrated off unsupported ancient equipment and migrate to new systems without having to rewrite a ton of existing code that already does what you need.
Or rewrite the old code, but only one module at a time since it can run on the same platform.
Re:Always kind of interested me.. (Score:5, Insightful)
> I checked the website, there's a tab labelled "pricing" but there's no content there yet.
If you have to ask how much it costs, you can't afford it.
Re: (Score:2)
Also, IBM loves to charge different companies different prices for the same things. That's one of the many benefits of positioning yourself as a contracting/services company.
Re: Always kind of interested me.. (Score:2)
It's worth going through a tutorial just to see what the fuss is about. It's more like SQL than a real programming language.
How about RPG? (Score:2)
We also need an RPG compiler for the picture to become complete.
Re: (Score:2)
I know you're joking, but I cut my teeth on RPGII, RPGIII, and RPG400, before I moved on to other worlds.
I don't mind RPG at all. It's quite fast when doing what it was designed to do.
Re:How about RPG? (Score:5, Interesting)
This. RPG perhaps is the best at what it's designed to do. Other languages have to use certain patterns, ORM, and more with code that seems less self-documenting than what RPG can do. COBOL in my mind is largely a patch for going beyond RPG, where more logic is required than can be achieved in RPG. This is a bit weird because if I recall right, COBOL is an ancestor of RPG but when I see RPG/COBOL shops, COBOL is only used when you need the extra logic.
Re: (Score:2)
Dotnet runs on Linux, no? Alas, you may be stuck on Windows for the IDE.
https://www-356.ibm.com/partne... [ibm.com]
Re: (Score:2)
Re: How about RPG? (Score:2)
I'm sure there's RPG. There are PL/I, MUMPS and BCPL compilers for Linux.
But why? (Score:2, Interesting)
There is already GnuCOBOL [sourceforge.net] which translates COBOL into standard C (which is then compiled), is free, passes all the NIST COBOL 85 test suite tests, is translated into a bunch of languages, and is multiplatform.
COBOL is solved problem; there is no need for a new COBOL compiler.
Re:But why? (Score:5, Insightful)
COBOL is solved problem; there is no need for a new COBOL compiler.
That's like saying GCC compiles C so nobody else should make a C compiler.
Re: (Score:2)
I would think it may even be more complex than that? More like python compilers. I know there are many different versus of COBOL and there might be some limitations to GnuCOBOL that do not really work for the IBM shops that still want to develop COBOL on Linux.
Re: (Score:2)
Yeah. It's not as if Microsoft invented vendor lock-in. It was IBM. They were masters of it before Microsoft even existed. Without a doubt (ok, maybe some doubt - I really have never touched COBOL), IBM has COBOL/Blue that adds a few non-standard features.
Re: (Score:2)
COBOL is solved problem; there is no need for a new COBOL compiler.
I'll never understand this attitude. Though I suspect it's why so much modern software ends up being hundreds of megabytes of libraries uncomfortably glued together.
After all, if we didn't reinvent the wheel, my bicycle would weigh 800lbs.
Not totally unrelated: It's essential for the long-term health of any programming language to have multiple, compatible, implementations. I'm sure you can think of a few programming languages that died because the maintainers of the only implementation gave up on it. I
Re: (Score:2)
There may well be people asking whether there is a COBOL compiler on x86 they can _buy_. Some people and organizations do not understand FOSS. Or they want to pay money so they can sue later if things do not work. (Good luck with that...)
Re: (Score:2)
Or they want to pay money so they can sue later if things do not work. (Good luck with that...)
Or just for passing the buck reasons. "We used IBM, how could that possibly go wrong?" No need to justify your decision to choose the 800 ton gorilla, like you would with something that cost $0.
Re: (Score:2)
I think it is so IBM can keep its business partnerships.
Companies are no longer buying mainframes, and big iron. While a modern mainframe is an amazing computer to work on, and handles heavy load like a real champ. It is extremely difficult to justify that performance for its price, then factoring in today's business need to fail-over and redundancy it gets way more expensive very fast.
They are a still a lot of COBOL code out there running things, but IBM Customers are looking at the expense on keeping t
A week late (Score:2)
April 1st was last week
Be nice to COBOL... (Score:3)
Or if not yours, someone elses in the world, somewhere.
Re: Be nice to COBOL... (Score:2)
Not ancient enough (Score:4, Funny)
Forget it. I am only interested in coding by setting positions of gears on the antikythera mechanism.
Re: (Score:2)
Forget it. I am only interested in coding by setting positions of gears on the antikythera mechanism.
Easy there young blood with your fancy gears and such. Real programming is when putting up 25-ton rocks ('SET'), after dragging them ('CARRY') a few dozen kilometers from the computational storage space ('QUARRY') to the computation site ('HENGE').
A language with built-in rust. (Score:3)
It's also got "Native support for XML"? and features from ANSI COBOL 2014, presumably it's more COBOL++ or something.
I'll stick to POSIX shell scripts.
Re:A language with built-in rust. (Score:5, Funny)
presumably it's more COBOL++ or something.
It's actually called ADD ONE TO COBOL GIVING COBOL
Re: (Score:2)
Re: (Score:2)
You are of course correct, but the point of the joke is to be mean to COBOL, so I think it's funnier than omitting the "GIVING" phrase, even if pedantically I'm not correct.
Re: (Score:2)
presumably it's more COBOL++ or something.
It's actually called ADD ONE TO COBOL GIVING COBOL
It's:
ADD 1 TO COBOL GIVING OBJECT-ORIENTED-COBOL
When I give a talk that's my opening joke and has been for decades. It's an interesting joke because to get it someone has to understand enough C to understand the language name "C++" and they have to understand enough COBOL and they have to put it all together. Younger crowds have no idea, but guys my age who learned COBOL in university (and then took a shower) get it.
Re: (Score:2)
I don't get it?
Isn't that equivalent to object_oriented_c = c+1? With the GIVING something-else, the value of COBOL is unmodified.
I the point of ADD ONE TO COBOL is it modifies COBOL, like c++. The GIVING phrase is just to troll.
In a way it is a superior tech/dev environment (Score:5, Interesting)
High throughput: for example CICS/COBOL and an IBM mainframe could easily manage a national (50000 terminal) network of ATM's using 1960's compute power (RAM and storage measured in KB), compute power/CPU speed in MHz! - do that with modern tech and see what milage you get.
Isolation: Stuff was written as "transations" discreet smallish programs that has limited and defined interaction with other code (sounding familiar?). Data integrity was built in and guaranteed at the transaction level with automatic backout if the transaction failed.
HIGHLY resource efficient: The level of memory optimisation and reuse was phenomenal - no waste - ever
High Programmer productivity: Program isolation (from other programs) and the consistency/simplicity of the environment meant very high productivity.
Sophisticated framworks built in: for example dynamic distribution of workload and data, program to program communication etc etc.
There's many more reasons but that's the first few that come to mind (I worked in the CICS product development team in IBM Hursley by the way)
Re:In a way it is a superior tech/dev environment (Score:5, Interesting)
IBM had a lot of fascinating architectures. The take away I get from studying them is they tried to move as much OS overhead into hardware as possible. Dedicated hardware is always faster than a general purpose CPU. For the longest time people (including myself) thought IBM made boring beige colored boxes for boring business purposes. It turns out the engineering was top notch and how things worked was completely alien compared to your typical PC or Unix workstation. People thing spinning up a VM is some new idea. Well IBM was doing that back in the 1970s.
Re: (Score:2)
Re: (Score:2)
Idea is old school in keeping with hardware limitations of the time. We kept the ideas and grew the hardware.
Need some extra money after retirement? (Score:4, Funny)
Learn COBOL and FORTRAN! You will be the youngest one on the team!
COBOL in the browser is next (Score:2)
I am waiting until you can program web front ends in COBOL compiled to Javascript before I dive in. COBOL, DOM, Javascript in a stateless environment sounds like a dream.
Finally Proper Indentation (Score:2)
Robot voice (Score:2)
All cobol compilers should come with a 80's like voice synth that read the code
Why is COBOL Still Here? (Score:3)
No Education Allowance (Score:2)
How much does this product cost?
Do you have to purchase it with software maintenance?
Sadly, there is no Educational Allowance so schools will be unable to teach this enterprise language.
No Linux dreiver... (Score:2)
I can't seem to find a working Linux driver for the IBM 711 Hollerith Card Reader my COBOL program demands...
Kernel Rewrite (Score:5, Funny)
Now how do we convince Linus to rewrite the Linux kernel in COBOL?
Re:Finally the wait is over! (Score:5, Insightful)
Re:Finally the wait is over! (Score:5, Interesting)
Your bible verse is surprising apt for your post... really surprising.
I learned COBOL and RPG on an AS/400 and I studied in the early part of this century. It lead to my first internship because my ability in computing was very broad and the insurance company I worked for used this mainframe. They had a significant debacle a year after I worked for them, so that path was relatively narrow but it gave me a foundation in databases that lead to further opportunities and my first real job. Every once and awhile I see a job offer come my way for COBOL development to support these legacy systems and I have never taken one up but yes, it's all about money and mostly from a generation that's on their last leg. COBOL will likely continue to have a "significant" role for these businesses till the middle of the century, so I assume this work is to better support some of the development environments these developers are working within. In general, the green screen is an interesting environment and I personally find the commands for working on IBM mainframes rather intuitive, versus something like linux where you just have to remember strange command names that I personally still don't understand the "etymology" behind their naming (e.g. awk).
COBOL is dirty though, and I would prefer RPG but it's more limited. This also doesn't get into the beauty of many modern languages such as C# but I don't think you can fully appreciate these languages without having some experience with them, likewise the relative strengths that exist between languages (i.e. RPG is perfectly good for it's purpose and perhaps one of the simplest for it -- though I am willing to debate this). Every once and awhile you hear reports of these killer languages like I believe Facebook was pushing some language called F? This shit often is a product of a lack of "touring" the history of language development.
Re: Finally the wait is over! (Score:2)
Re: (Score:2)
The etymology behind awk exactly parallels that of RSA: the initials of the surnames of the three people who originally developed it. (Yes, ok, to be pedantic that's incorrect because RSA was originally developed but not published by a mathematician working for GCHQ).
But I have to say that in 20 years of using Linux I've never needed to lea
Glad I avoided it !! (Score:2)
I 've been a developer since the late 80's. I always avoided COBOL like the plaque. I had a couple of CS classes that used it and when I graduated I took a test for a Federal govt job and scored a 98 ( it was an easy easy test). The closest I came was doing FoxPro on Dos and Windows 3 in the early 90's. That was good enough for me. If you had to do COBOL to pay the bills I salute you. I did work for a company in the early 2000's that was rewriting their COBOL mainframe code into a web based Java ap
Re: (Score:3, Funny)
I did it for 28 years, supported a family, got a retirement. IMO, COBOL is great. Maybe not the best language but I was always happy with it. Too verbose but then so is my wife.
Re:Finally the wait is over! (Score:5, Funny)
This is the key of some very, very old jokes.
Would you write Cobol code for $1,000,000 ?
Would you do it for $20?
We've established what you are, now we're negotiating a price.
Re: (Score:2)
Guess the moderatrolls are just forever too young to have matured past puberty. :)
Re: (Score:3)
The break even point at which someone would otherwise be paying me enough money to otherwise work in COBOL is, I think, somewhat higher than what would be sufficient for me to experience levels of guilt about taking unfair advantage of someone's ignorance about what a job is objectively worth while I otherwise might try to enjoy the money.
Either I would have to blow through the money very quickly so that the guilt similarly didn't last long, in which case the wage would not make a difference significant
Objectively worth? (Score:3)
> someone's ignorance about what a job is objectively worth
If Bob saves the taxpayers $74 million, how much is that objectively worth? Some would say saving $74 million is worth about $74 million.
I recently talked to two companies, Lockheed Martin (missile guidance group) and DTCC. If I fix a bug that would cause missiles to occasionally strike completely the wrong target, how much is that objectively worth?
DTCC processes billions of dollars transactions each day. If do work that prevents them from goi
Re: (Score:3)
Moving COBOL projects around, perhaps.
Re: (Score:2)
I'm only surprised this hasn't been done decades ago.
Re: Finally the wait is over! (Score:3)
There have been COBOL compilers for Linux for at least two decades. There are even PL/I compilers for Linux.
Re: (Score:3)
Re: (Score:2)
Care to explain that assertion?
COBOL doesn't come anywhere close to perl's ability to work with strings.
And I say this as someone who is categorically *not* a fan of perl.
Around the time that I was learning COBOL, there were a couple of lesser-known languages, SNOBOL and Icon (both worked on by the same person, iirc), which for their time were unparalleled when it came to string manipulation.
Re: (Score:3)
No fucking regex and awk(ward) crap required.
BUT... I have never worked in Perl either (well, not enough to say I am comfortable with it) so I can't give an accurate comparison myself.
Just seems to be more crap involved in working with strings in Perl, I mean any language worth it's salt can use regex, it doesn't make
Re:Finally the wait is over! (Score:5, Funny)
Seriously in the current market why would anyone half decent at coding would start working on COBOL projects?
SOME people don't think it's a good idea to wait until the last minute before addressing the looming Y3K problem, thank you very much.
Re: (Score:2)
Do you mean the 2038 problem [wikipedia.org]?
Re: (Score:2)
Re:Finally the wait is over! (Score:5, Informative)
The use case I think is quite obvious. There are many applications in the financial world that are still needed, but require not too many changes, i.e. long lasting financial products that are no longer being offered but still active. If they can run these reliably on Linux they can move this to i.e. a VM and send some old and expensive to maintain hardware like mainframes or AIX machines to the scrapheap. If it is an official IBM compiler the software is likely to behave exactly the same which means less testing and a lot less fuss if the software is subject to regulation.
This is not for new stuff, this is for old stuff that still runs fine and has no other need to be coded in a different language other than to get it of expensive hardware.
And yes I know mainframes are still awesome and have their uses, but if you only maintain them for old stuff that is idling most of the time they get to be very expensive overkill.
Re: (Score:2)
but if you only maintain them for old stuff that is idling most of the time
COBOL is normally run in batches using CICS and whatnot. The COBOL programs aren't idling and not taking up any resources when they aren't being run.
Re: (Score:3)
The COBOL programs aren't idling and not taking up any resources when they aren't being run.
But the hardware still has to exist and be maintained. And the cost of that maintenance will be the same no matter whether the software is running 5% of the time or 95% of the time. So if the overall mainframe utilization is so low that the software can be pushed onto hardware that is cheaper to maintain, then that is a perfect business decision.
Re: (Score:2)
Re: Finally the wait is over! (Score:2)
Well, you're right, but this isn't remotely close to being the first COBOL compiler for Linux by a mainstream company. Why enter a crowded market?
Re: Finally the wait is over! (Score:5, Interesting)
Because unfortunately COBOL isnt COBOL. Its like C in the sense you can be disciplined and write it to one of the standards. Like C89 or in this case COBOL74 or COBOL85, or you can litter it will all kinds of vendor-isms.
If you wrote to one of the standards than odds are good its pretty portable; with but and its a big BUT; COBOL programs usually have pretty heavy dependancies on their environment. They depend on the system to wire up all the file I/O (JCL's job in the IBM world) or they are expecting inputs from interactive stuff like CICS or they have bind variables into DB2... Few COBOL "applications" are really monolithic programs in the sense one binary handles some process from start to finish. They are usually a series of job steps, and they may depend on all kinds of non-COBOL glue like sync sorts and stuff between them which may or may not have suitable analogs on other systems.
Even if you have a very 'standards compliant' COBOL corpus the odds you can just pick it up and move it from and IBM mainframe or even iSeries environment to pick-your-PC-COBOL without a significant redesign is pretty slim. So having an IBM provided environment will likely address some of that stuff. I can't imagine they are releasing 'just a compiler' because there are plenty of them that can spit out an x86 binary from some COBOL85 source already.
Re: (Score:2)
Like they say; so that you can try it out on linux, and go back to z/OS if you don't like it.
COBOL isn't portable. When you change compilers, you have to do some porting. This avoids that.
Re:Finally the wait is over! (Score:5, Insightful)
I waited for decades, decades to finally be able to work with COBOL on Raspberry Pi ... oh wait.
Seriously in the current market why would anyone half decent at coding would start working on COBOL projects?
Good market and few coders available for maintenance and further development on all of those backend systems using Cobol... also, knowing the language would make projects integrating with or replacing these backend systems easier, meaning you can charge more.
Re: (Score:3)
Re:Finally the wait is over! (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
languages like C/C++ had way worse Y2K problems than COBOL, it is just that dufuses like to say, "hurr durr, still using COBOL?!?!"
I was doing consulting at the time, and I never saw anybody wrapping years at 1920. Everybody switched to 4-digit years.
I know that SAS used date windowing. But that is C.
In COBOL you'd have to do that by hand, and it doesn't save much work. And when it was done in COBOL it was often like 1960-2059 in the first place.
Re: (Score:2)
"start"? Nobody. Maintain or migrate projects that are 40 years old, costed half a billion back when they were created and everybody who understands their inner workings has already retired - there are some people who will do it for the right price.
Re: (Score:2)
Seriously in the current market why would anyone half decent at coding would start working on COBOL projects?
It occasionally happens, but what this is more likely to do is facilitate moving legacy COBOL code off of a more expensive platform. IE, we have a ton of AS400 applications written in COBOL. The people that wrote them are long gone (some are long dead). We have current COBOL programmers but a lot of aspects of those old programs are basically mysteries. They work, and when it works you try not to mess with it.
Being able to move the code over to a Linux x86 box though would potentially save the org a ton
Re: (Score:3)
We have current COBOL programmers but a lot of aspects of those old programs are basically mysteries.
When I read stuff like this I have assume its because nobody is really trying very hard if that is the case. COBOL makes it hard to do anything mysterious for the most part; with the exception of business rules themselves.
I then have to ask how come nobody knows those business rules. Sadly I have walked into lots of orgs where things like their quoting tools are filled with logic nobody understands. "We charge this much because the tool says so" At that point the problem isnt that you are still on COBOL or
Re: (Score:2)
I doubt this is really about working on new COBOL projects, but rather about being able to target a new environment for running existing COBOL projects. Like, for example, hosting applications on commodity x86-64 hardware running Linux. Or Linux virtual machines running on commodity hardware (or a cloud account) you already have.
I'm sure that IBM would rather you buy expensive P-series servers running AIX or Z-series mainframes, but they'll be happy to license you software for running on x86-64 too. And,
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
It is very convenient to have guaranteed decimal math, and not have to jump through hoops to make sure you used some "alternate" numbers just to get human math that works with accounting.
And modern COBOL removes a lot of the boilerplate that made it crufty.
Also, it integrates with C just fine, so it can be useful to encapsulate the accounting portion of a work flow.
Re: (Score:2)
Seriously in the current market why would anyone half decent at coding would start working on COBOL projects?
Because the grey beards who support the existing COBOL projects are retiring? And companies who own said projects would prefer to run on cheaper hardware/operating systems?
Which means some seriously good money.
Re: Finally the wait is over! (Score:3)
Seriously in the current market why would anyone half decent at coding would start working on COBOL projects?
Do you work for bragging rights or a paycheck?
Working with out-of-favor technology can be very lucrative. Schools stopped teaching COBOL decades ago, but industry still relies on it for A LOT of work, and will for many years to come.
It's great that you have a list of special skills and talents learned over countless years of learning the latest and greatest tools, but as the pool of COBOL programmers shrinks, and the need remains fairly constant, COBOL programmer wages may eclipse yours.
But hey, you'll have
Re: Actual clouds? (Score:2)
Cloud does not just mean 'server'. It means 'somebody else's server' to which you can be arbitrarily denied access.
Re: Actual clouds? (Score:4, Insightful)
Re: (Score:2)
Only true if you pretend private clouds [differencebetween.com] don't exist.
Cloud is as much a means of implementation [youtu.be] as a location.
Re:Actual clouds? (Score:5, Informative)
Saying "cloud" to mean servers makes you a PHB or a luddite.
That depends. I've seen hosts who provide a "cloud" composed of a single bare metal server in a data center. So, yes, there are people who use it as synonymous with servers, and that's indeed moronic. But outside that misidentification, "cloud" does have a specific, concrete meaning that differs from a generic "servers", in the sense that all clouds are sets of servers, but not not all sets of servers are clouds.
So, a proper cloud is a set of one or more bare metal servers, in a single data center or spread on different data centers at different locations, all running a minimal OS with a specific proprietary or open source software stack such as OpenStack, CloudStack, OpenNebula or some other, VPNed into a single decentralized OS-like system designed to manage virtual machines. This OS-like software layer works in a distributed manner, so if bare metal machines go on or off it doesn't affect your interaction with that set of servers. When it's running, users can in turn create, duplicate, delete, start, gracefully stop, or ungracefully kill one or more VMs, usually via special scripts written in languages designed for this purpose.
Those VMs, in turn, usually run servers OSes also specialized for very fast boot and shut down times, configured via scripts rather than manually fine tuned, that allow new instances to be built, configured, updated, and integrated into specific distributed workloads under sub-VPNs of their own, with coherent, predictable, and reproducible behaviors, and usually with enough resilience and redundancy embedded into them so as to not cause any damage, or other undesirable side-effects, to the workloads they're part of if and when they're suddenly killed, and then another set of VM instances is started in an entirely different data center/geographical location to continue the work from where the killed VM stopped.
That is a cloud platform. So, unless the person/entity means all of that, then it isn't in fact a cloud platform.
And, the thing is, IBM does mean all of that, so their use of the word "cloud" is perfectly accurate.