Re: Mainframe not a good architecture for interactive was Re: What is the future of COBOL? Answer: Irrelevant???

From: Peter E.C. Dashwood (dashwood_at_enternet.co.nz)
Date: 12/11/03 

Date: Fri, 12 Dec 2003 10:55:58 +1300

"Clark F. Morris, Jr." <cfmtech@istar.ca> wrote in message
news:3FD7D224.90906@istar.ca...
> While cleaning out my drafts folder, I came across this posting that I
> vehemently disagree with.

I take it you disagree with his statement that the mainframe is not a good
architecture for interactive use? You don't disagree with his results?

> While the particular application that Howard
> is referring to may have been running abysmally on the mainframe, in
> general, given proper tuning and resource allocation, I'll bet on the
> IBM mainframe to give very good response time.

Yes, it can. BUT it is NOT a good architecture for doing so. CICS is robust
(it ought to be; it has been around now for over 30 years) but it suffers by
comparison to a distributed network system.

CICS was NEVER as good as IMS/DC, SHADOW, or TASKMASTER, even in the IBM
mainframe environment, so it is hardly surprising that it suffers in
comparison to systems that are DESIGNED to be networked.

The main problem is the pseudo-conversational mode, where a connection is
established between the processor and the terminal, via a terminal dependent
buffer that must be reloaded each time the terminal is activated. The system
has to maintain tables that tell it what terminals are on the network and
what state they're in.

PC networks don't work that way. The devices on the network are recognised
by addressable hardware cards. There are a number of protocols (not least of
which is the ubiquitous TCP/IP protocol that makes it possible for us to
have this conversation) that simply transmit packets around the network.
Network servers pass messages to each other until the required client is
located. There is no requirement for terminal dependent buffers (DFHCOMM
area or SPA) or maintenance of state (the system is stateless), and the
whole thing is much more fail safe because if parts of the network are down
or missing, packets get re-routed "automatically". (It was designed that
way, as it was developed from a military system called ARPANET that was
designed to enable the continuance of miltary command and control after
parts of the network were destroyed by nuclear attack.)

Howard claims ASP was 9 times faster than the mainframe. Presumably, this is
compared to the CICS system running the equivalent application. I can
understand you being incensed because this was obviously not a fair
comparison. Besides, we cannot take one instance, where we don't know all
the details, as being indicative of a general case.

Certainly a modern mainframe would have no trouble maintaining 30
transactions a second on its own network, and I agree with you that (most of
the time) CICS will give "fast" response (certainly within 2 seconds).

The problem is that when you come to compare the cost of a LAN, served by
servers with the equivalent performance, against the above system, the
mainframe loses badly. The Client/Server solution would be less than one
fifth of the mainframe cost (I am looking at the TOTAL mainframe cost, which
includes infrastructure support, systems programmers, etc.)

That is probably why Client/Server has been encroaching on what was
previously the mainframe's domain.

> CICS is currently used
> by most large banks because it does provide good response time under
> large loads. What size IBM system was the application running on? I
> have read of shops that have kept mainframes for 10 - 15 years and in
> some cases they still beat the client server du jour. If IBM would ever
> learn the meaning of small and get the idea through its head and the
> collective heads of the various Independent Software Vendors that 200
> mips in 2003 is the same as 20 mips in 1995, you might really see the
> mainframe outperform the other platforms for the dollar in the
> environments where much of the computing is done.

 It isn't about MIPS (although they certainly help). It is about bandwith
(which is increasing each year). And you are correct that it is about
dollars (this is where the mainframe is losing badly...)

> Sub-second response
> time is a major goal for many CICS systems. 3000 transactions a second
> may not be unusual for some of the larger systems.

It isn't for some Internet sites either. GOOGLE copes with several billion
transactions per day, without requiring manframes.

> If personal
> computers could actually handle the large data loads and numbers of
> transactions for a large bank, we would be seeing a lot more of what
> Howard Hinman is talking about.

Well, they can and we are.

The reason it is taking so long is because the transition from Legacy to New
Technology is risky and complex. Nevertheless, it IS happening, even in the
large banks you are talking about.

Banks are probably the last stronghold of the mainframe because they are not
quite as driven by cost considerations as other businesses, and they are
inherently conservative and resistant to change. I believe WestPacTrust (a
major Australasian Bank) has moved almost totally to client server over the
past 10 years. Their online and phone banking is exemplary and they seem to
get the statements right <G>.
I don't know what the transaction rate is but it would be "non-trivial".

I have to agree with Howard's statement that the mainframe architecture is
not good for interactive use, insofar as it "suffers by comparison". (It
isn't just the processor architecture; it is the network architecture also.
So far, mainframes have not coped well with this. If the manframe is to
become another powerful network server (and some organisations see it in
this role) then the price would need to drop significantly and the system
software would need to improve significantly. CICS just won't cut it...)

I see the future role of the mainframe as Batch Processing, until such time
as online systems become efficient enough to remove the need for Batch
processing altogether.

Pete.

Relevant Pages

  • Re: Yearlong DBA contract - State of AZ/Phoenix
    ... Yearlong DBA contract - State of AZ/Phoenix ... Z196 Mainframe, running z/OS 1.10 and 50+ discreet Transaction Server ... application systems must interface successfully with the z/OS operating ... the agency data, and the communications network. ...
    (bit.listserv.ibm-main)
  • [Fwd: Re: Mainframe not a good architecture for interactive was Re: What is the future of COBOL? An
    ... I belated posted Pete Dashwood's comments to the mainframe list ibm-main ... a application server (CICS). ... > suffers by comparison to a distributed network system. ...
    (comp.lang.cobol)
  • Re: Contrarian view of COBOL
    ... of mainframe processing, than from any real need to do so. ... Database servers also do this, ... it is imagination that builds businesses ... also believe that eventually the network will consume everything so it makes ...
    (comp.lang.cobol)
  • Re: The Emerging Mind :Rationalization and inquiry
    ... conscious computers and all the instinctual level conscious computers ... are known as Chupee, and even the mainframe, is also considered to be ... Chupee only a much bigger smarter more powerful wiser more capable ... Along with this mystery is that network of Chupees. ...
    (sci.physics)
  • Re: Productivity
    ... Your mainframe salesman just wants you to think they are... ... battled with when Sun came up with 'the network IS the computer'. ... A Blade Server that is roughly equivalent, with SAN, runs closer to $730K. ... thing trying to max out the channel I/O. ...
    (comp.lang.cobol)