Mainframes are hip now! Compuware fires its dev environment into cloud

In an attempt to entice new blood to those dinosaur systems of record known as mainframes, Detroit software firm Compuware has moved its development environment to the cloud. The company's flagship mainframe Agile/DevOps product Topaz is now available on Amazon Web Services. As Compuware and competitors such as IBM and Micro …

[Anonymous Coward]

A confession

Ok - I liked COBOL.

I wouldn't use it for any number-wrangling stuff; I'd use FORTRAN for that, but I thought it was good for collating data and moving it around. At the time I was using it, in the mid to late 80's, I was happy using it for both batch processing and 80x25 'green-screen' displays, where screen layout via working-storage in the data division was a doddle. I especially liked what you could do with REDEFINES in working storage. Once though, I had to use the memory segmentation feature, on a large prog that had to run in the 128kb of an ICL DRS-20 (8085 cpu), and although it felt like a bit of a messy compromise, it actually worked and made the difference between being able to do what was needed and not being able to do it all. Personally, I didn't mind its verbosity.

It was far from perfect, of course - Oh! how amusing to have your biggish compilation fail with several thousand errors, every line of code having thrown up a syntax error after the missing '.' at the beginning of the Identification Division.

[bombastic bob]

Re: A confession

"Ok - I liked COBOL"

There's an 'Open COBOL' (now gnu cobol) that probably works just fine with old stuff...

https://sourceforge.net/p/open-cobol/

(apparently translates COBOL code into 'C' first, which is actually a really good feature if you think about it)

I think COBOL was the first lingo to truly support named structure elements, and structures within structures. OK you _could_ do it with FORTRAN 'equivalence' statements, but still... that was kludgy

So: why code for a MAINFRAME when you can code for a rack-mount or cloudy VM instead ??

I bet those old mainframes can't even handle the load compared to a modern x86 or ARM-based architecture.

seriously!

[hmv]

Re: A confession

Don't be daft.

Mainframes aren't old (unless you insist on an old one), and scale far bigger than x86 systems (excluding clusters) in terms of processor power and memory size … traditionally the mainframe's weakest point.

[jake]

But, but, but ...

Mainframes ARE cloud computing!

[bombastic bob]

Re: But, but, but ...

"Mainframes ARE cloud computing!"

in theory, yeah. That's if you consider a bunch of rack mounts running cloudy VM tasks with load balancing and replication and other related "cloudy management" things, then the entire 'rack' becomes "a mainframe".

Sort of.

/me wonders about special VMs to run COBOL programs

[Long John Brass]

Solution is simple

Up the rate for COBOL, PL/1 etc programmers...

Ohh, you want a cheap youthful and dynamic labour pool for your dev/ops teams, never mind; My bad

[Doctor Syntax]

Re: Solution is simple

Yup. There's nothing like offering serious money and this is nothing like offering serious money.

[Anonymous Coward]

yawn... time for bed.

[Snores loudly]

[Anonymous Coward]

Mainframes ARE slow.

"The biggest problem with mainframe is the perception" that it's "old, antiquated and slow,"

But Mainframes are slow. The cpus that is. I/O of a mainframe is superior. But cpu is way slower than a high end Intel Xeon. IBM posts benchmarks all over the internet when they have some good performance, look at POWER7 - there were benchmarks all over the web. There are no Mainframe SPECint2006 benchmarks nowhere and has never been. No cpu benchmarks comparing x86 to Mainframe cpus, what so ever. No TPC benchmarks. No nothing. If Mainframe cpus were 10x faster than Intel Xeon, IBM would brag about it, not desperately try to hide it.

[bombastic bob]

Re: Mainframes ARE slow.

"I/O of a mainframe is superior"

that's the rumor, yeah. I have to wonder if that's stll the case for PCIe SSDs, a multi-GBit network backbone for talking between the blades, and other "fast things" built into a rack o' blades, running VM-based cloudy tasks.

Or is the mainframe's data throughput better than a storage device directly plugged into a PCIe slot? [or whatever new tech has come down the pike and I haven't heard of it yet - it has been a while since I scoped out bleeding-edge hardware]

[PlinkerTind]

Re: Mainframes ARE slow.

Mainframe cpus are slow. Mainframe I/O is superior. That is because Mainframes have lot of I/O co-processors. For instance, one Mainframe had 296.000 I/O channels. x86 does not have that many co-processors. But, OTOH, if you added co-processors to x86, it would be faster on I/O as well

[skies2006]

Re: Mainframes ARE slow.

"I/O of a mainframe is superior" that is a myth that was true in the 80'ies and 90'ies then the best you could get was a Intel 286 or 386 machine.

Nothing magic about I/O. I/O is just Input and Output of bits and bytes. There are different kinds of I/O, there is disk I/O, there is network I/O, there is memory I/O, there is ASCII terminal I/O, there is bus I/O.

What kind of I/O is the mainframe superior on I may ask. And where is the open and public benchmarks to prove it.

[jake]

Re: Mainframes ARE slow.

skies, might want to look up the concept of Channel I/O. Your common or garden PC might have a handful of I/O channels, each dedicated to one aspect of computing. Mainframes, on the other hand, might have tens of thousands of general purpose I/O channels. One machine that I'm aware of had a quarter million I/O channels (at SLAC, a couple dozen years ago). The PC platform, and it's derivatives, quite simply can't scale to this kind of level when it comes to I/O ... they aren't designed for it.

[klcorbett]

Product Manager

I have to disagree with Dale. COBOL is just another language. As with any language you need to understand the syntax. Yes, you can lead a horse to water. And you can teach them to drink and be productive.

[Ian Joyner]

COBOL?

Dijkstra's take on COBOL was

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.”

Now we have 'newer' languages to fulfil that role:

The use of C++ cripples the mind; its teaching should, therefore, be regarded as a criminal offence.

[jake]

Re: COBOL?

Yes, COBOL.

I would never poo-poo EWD's contributions to computer science. Ever.

That said, I use COBOL nearly everyday. Likewise Fortran. And C. And APL. And Lisp. (What else mattered in that time frame? Prolog[0], Simula & Smalltalk, certainly, but not outside academia ... ) But ALGOL? Maybe once in a blue moon. Theory's all very well and good, but then we run into the big, ugly real world. I have to fall back on the old mantra "running code trumps all" and keep on keepin' on.

Agree on C++ and all it's evil spawn ... it was designed for people who are afraid to tell the computer what to do. All in all an 'orrible travesty of a computer language.

[0] Is IBM's UIMA used anywhere outside IBM research and Apache?

[Ian Joyner]

Burroughs was best

Probably the most advanced architecture ever was the Burroughs B5000. It should be studied now for a regular instruction set with security baked in. The B5000 was not just designed as a CPU, but an entire system.

https://en.wikipedia.org/wiki/Burroughs_large_systems

[jake]

Re: Burroughs was best

I dunno ... I was always partial to assembler. Without it, I never really considered myself in charge of the machine. That said, you can't argue with success; after over 50 years, Unisis is still developing MCP ...