Linked by snydeq on Fri 12th Aug 2011 03:55 UTC
OSNews, Generic OSes InfoWorld's Galen Gruman highlights 18 technologies that remain core to the computing experience for IT, engineers, and developers 25 to 50 years since their inception. From Cobol, to the IBM mainframe, to C, to x86, these high-tech senior citizens not only keep kicking but provide the foundations for many vital systems that keep IT humming.
Thread beginning with comment 484836
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Infoworld
by Kebabbert on Sat 13th Aug 2011 10:22 UTC in reply to "RE[4]: Infoworld"
Member since:

Mainframes are supposedly about throughput of many concurrent transactions, I/O; lots of stuff is offloaded to coprocessors. Central Processing Unit seems to have slightly different meaning in them (mainframes don't really seem to be strictly about raw CPU crunching)

Yes, but maybe we can agree that IBM Mainframes have slow cpus, inferior to x86 cpus. So, you dont buy IBM Mainframes for their cpus, because they are not suited for raw number crunching. Any cheap x86 cluster is much faster at raw number crunching.

Then there are claims about reliability, on-line repairs and upgrades, verifiability (they seem to basically do everything two times and compare the results, at minimum? That ought to slow things down), or security (apparently stemming from few choices about overall architecture of the machines; also can't help, at the least, with raw CPU number crunching)

Yes, IBM has made lot of claims. For instance, the biggest Mainframe can virtualize 1.500 x86 servers. I dug more into this, and it turned out that IBM assumed all x86 servers idle, and the Mainframe is 100% loaded. That makes sense, because if any x86 server start to do some work, then the Mainframe can not cope with the fast x86 cpus.

But in my opinion, this is false marketing. Because I can boot up 10 mainframes on my PC. But it would be false of me to say "my PC can virtualize 10 IBM Mainframes". Dont you agree?

Also, there are claims that IBM Mainframes can handle 400.000 clients. I would not be surprised if IBM assume all clients to idle, and only a few of them does real work. Judging from the example above.

Regarding the Mainframes reliability. One of the largest train installation in Scandinavia: the CEO said "our IBM mainframe crashed recently, that is strange. It normally never crashes. Last time it happened were six years ago". This is a contradiction. It seems their mainframe crashes every 5 year. I can google that article if you want to read. Just tell me.

Reply Parent Score: 3

RE[6]: Infoworld
by zima on Sat 13th Aug 2011 17:58 in reply to "RE[5]: Infoworld"
zima Member since:

So, what, you're now essentially saying that you've built your initial critique of their CPU raw numbers on s straw man? I don't see anybody promoting mainframes for cluster ("supercomputer" now, it seems) number crunching.

I wasn't even taking a side in this, none has any particularly warm place in my heart, just adding a fuller picture to your - at best - snippet. Even doing so in an extremely neutral tone (as you sort of noticed...*), since a lot of people on the web doesn't feel the concept of pointing out some inaccuracy without taking sides (*...but also took it further; plus the claims I mentioned are not solely by IBM)

Reply Parent Score: 1

RE[7]: Infoworld
by rcsteiner on Sun 14th Aug 2011 07:30 in reply to "RE[6]: Infoworld"
rcsteiner Member since:

Mainframe have never been marketed for CPU-intensive tasks. They're highly reliable machines designed to handle large-I/O applications, which is why you seem them used for airline reservation systems and other similar things which require low latency and a large number of concurrent users.

Reply Parent Score: 2

RE[6]: Infoworld
by rcsteiner on Sun 14th Aug 2011 01:08 in reply to "RE[5]: Infoworld"
rcsteiner Member since:

Mainframes use a number of decades-old tricks to optimize multiple concurrent connections and minimize transaction overhead.

At least in our case, terminals (usually a PC-based UTS emulator like UTS Express, PEP, or Liaison) are using synchronous I/O. Data is only sent on the network when a Transmit key is pressed or a special key like a function key is pressed, unlike Vxxx terminals which flood the network with packets every time a key is hit. That's a waste of resources. UTS terminals are also smart enough to handle some editing locally and to only send those portions of a screen which have changed. I think 3270's can operate in synchronous mode, not sure.

Programs don't generally request memory dynamically at all ... there is no MALLOC. A program is allocated a fixed block to use, period, and the OLTP transaction environment allocates that block to each program at load time. If you need more, you write more than one program or routine and chain them together, using buffers (DBAs in USAS/HVTIP, temp files like ONLINEFAST2A in TIP), to pass data between program segments if it won't fit in the COMPOOL buffer or equivalent. Applications don't run resident (only the scheduler does) but can can be cached in memory (data area, instruction area, both) to reduce load times. The OLTP scheduler directs control to various programs as required. Commonly used files are resident in cache.

(There's an OS layer underneath called the EXEC which maintains paged virtual memory, but application programs are completely unaware of its existence. They don't need to know. All they know is the OLTP environment in which they run.)

The OS (in this case OS 2200) has a higher granularity of process control than UNIX generally does, with multiple classes of process priorities (HIGH EXEC, LOW EXEC, TIP/OLTP, BATCH, DEMAND (interactive userland), and with each of those areas subdivided into 64 process priorities. Stuff that needs priority gets it ... this ensures that some slow batch process doesn't touch OLTP performance.

It's a fascinating world. Please don't assume that mainframes are low tech. Much of the tech is old, yes, but there are reasons why those concepts still work well. Mainframe OSes like OS 2200, MCP, and zOS can be very different from UNIX and were designed to solve somewhat different problems.

Reply Parent Score: 3

RE[7]: Infoworld
by rcsteiner on Sun 14th Aug 2011 01:14 in reply to "RE[6]: Infoworld"
rcsteiner Member since:

Weird to reply to myself... Programs on the mainframe can obviously request memory in most instances, but when doing OLTP that is not allowed. The system handles it, so things like memory leaks caused by OLTP application programs simply don't exist.

If you want to write a vanilla C program, tho, you can do it. But it won't be running under the OLTP subsystem unless you agree to use its built-in memory management, its I/O subsystem, etc.

Edited 2011-08-14 01:15 UTC

Reply Parent Score: 2