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

From: Clark F. Morris, Jr. (cfmtech_at_istar.ca)
Date: 01/26/04

  • Next message: Charl Freysen: "Re: ACCEPT - Stupid question"
    Date: Sun, 25 Jan 2004 21:35:48 -0400
    
    

    I belated posted Pete Dashwood's comments to the mainframe list ibm-main
    and almost instantly got the following response. John does not follow
    comp.lang.cobol.

    -------- Original Message --------
    Subject: Re: [Fwd: Re: Mainframe not a good architecture for interactive
    was Re: What is the future of COBOL? Answer: Irrelevant???]
    Date: Sun, 25 Jan 2004 04:58:39 GMT
    From: John S. Giltner, Jr. <giltjr@earthlink.net>
    Organization: EarthLink Inc. -- http://www.EarthLink.net
    Newsgroups: bit.listserv.ibm-main
    References: <3FE0AC45.3070208@istar.ca>

    Personal opinion: Whomever Pete is seems to be trying to compare a
    networking protocol (TCP/IP) to a computer architecture (mainframe) and
    a application server (CICS). He should try comparing:

            TCP/IP to SNA
            IBM s/390 cpus to Intel 486's or IBM PowerPC, Sun's Sparc
            CICS to ?????

    Other comments inserted below:

    Clark F. Morris, Jr. wrote:

    > In the posting below Peter Dashwood is agreeing with Howard Hinman on
    > the inappropriateness of the architecture based on his experience with
    > multiple platforms including IBM 360 and descendants. I also note that
    > the PC's cited by Howard Hinman replaced a two engine 3090 that had 41
    > MIPs in total. They also moved from a CICS application using COBOL to a
    > web application using COBOL. I would assume that the PC's had far more
    > compute power and main memory than the 3090.

    CPU yes, I/O I am not sure.

    >
    > When applications are replaced in your shop (and many mainframe COBOL
    > applications are long overdue for replacement based on the ones I have
    > worked on), what platform and language is being used? Where is the new
    > application development being done? If a package is used, will that
    > vendor supply it on the IBM mainframe and does it have any customers on
    > that platform?

    We are look at three possibility, all use IBM current mainframe as the
    server:

            EJB's under WAS with EJB handing the DB calls.
            EJB's under WAS using JDBC
            EJB's front ending CICS apps and CICS apps doing the DB calls.

    Data base is DB2.

    >
    > -------- Original Message --------
    > Subject: Re: Mainframe not a good architecture for interactive was Re:
    > What is the future of COBOL? Answer: Irrelevant???
    > Date: Fri, 12 Dec 2003 10:55:58 +1300
    > From: Peter E.C. Dashwood <dashwood@ibm-main.enternet.co.nz>
    > Newsgroups: comp.lang.cobol
    >
    > "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.
    >

    Hum, I bet Pete was an application programmer and not a system
    programmer. CICS only maintains the state of terminal that are in
    session with it, just like any and all "distributed" server
    applications. In the early days CICS did need to have pre-defined
    tables entries for any terminal that was going to connect to it, but you
    have been able to dynamically defined and delete this entries for over
    20 years now. If distrubuted servers share the same single buffer for
    all connections/sessions how does it keep track if information that is
    unqiue to each connection/session.

    > 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 military command and control after parts of
    > the network were destroyed by nuclear attack.)

    The comparison is of totally different things. One is a application
    server (CICS) the other is a networking protocol (TCP/IP). SNA does
    keep track of the status of every terminal that it owns. TCP/IP does
    not keep track of every IP address within it's subnet. However, a
    distributed server using TCP/IP as it networking protocol does keep
    track of each client that is connected to it by IP address. A web
    server has a "DFHCOMM area" for each HTTP connection. A since getting a
    single web page from a single client can create up to 5 HTTP connections
      to a Web Server, this means that for an equal number of clients, a Web
    server is keeping track of 5 times the connections.

    >
    > 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).

    Depends on the application design and size of the mainframe (just like
    in a distributed environment) the number of transactions and response
    time. We average 30 tps with avg. response time of less than .5
    seconds. We can peak in the 100 of tps, however it is not CPU that is
    restricting this, it is the speed of the network connections to our
    customers. Guess what, the majority of our sessions connections are
    TCP/IP, not SNA.

    >
    > 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.)

    Umm, I can remember reading cost comparisons as recent as 3 years ago
    where a full distributed environment supports 2000 users with Windows
    servers was 4 times more expensive than a mainframe environment and
    using UNIX based servers was 2 times more expensive. I can remember
    studies from 10 years ago where the numbers were 7 and 5 times more
    expensive. The two major issues was the personal cost of supports 2000
    PC's and the fact that it took many, many distributed servers to run the
    same number of applications as were being run on a single mainframe.
    Most distributed servers run one application per box, or in some
    instances multiple boxes run the same application either for backup or
    because a single box can not handle the load. A large scale Intel box,
    IBM pSeries, or Sun Sparc can get into the millions, just like a
    mainframe.

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

    Define Client/Server. That I am aware of the development of client
    server applications are on the downward trend and Web based applications
    are being used. The argument could be made that Web is "thin" client
    server, but then it could be argued that CICS and 3270 is "thinner"
    client server. Yes, some Web based applications can get thick, with
    Javascript or Java applets, but these offload some of the processing off
    of the "sever" (be it a MF, *inx, Windows box).

    >
    >> 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
    > bandwidth (which is increasing each year). And you are correct that it
    > is about dollars (this is where the mainframe is losing badly...)

    Not really. If you look at performance only the mainframe is more
    expensive, however when you start looking at reliability a distributed
    environment start getting more expensive when you want to keep it up.

    >
    >> 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 mainframes.

    A mainframe enviroment can do billions of transactions a day.

    How do you know GOOGLE is not running mainframes? They are using Linux
    based Web server and Linux does run on IBM mainframes.

    Define mainframe. Unisys make the ES/7000 a hugh box with many many
    processors and many independent PCI buses. The box is designed to be
    used as a central computer in a computing environment, to me this means
    mainframe. The same thing can be said for some if IBM pSeries servers,
    future xSeries, and some of Sun's large systems.

    Now, you also have look at what the transactions are. The majority of
    GOOGLE's transactions are queries, very few updates. Updates are what
    slow things down. IBM lastest performance number on their largest
    mainframe shows that a fully configured plex could do the same number of
    transactions in 24 hours that are done on the Internet in one week. I
    fully confiugred plex is 32 boxes. Lets see 32 distrubuted boxes do thtat

    >
    >> 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 mainframe 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...)

    What is wrong with TCP/IP? Mainframes have been supporting TCP/IP
    longer than Windows. They can support up to 24 Gigabit Ethernet
    adapters per box and drive all of them to line speed.

    CICS is NOT a network, it is application server.

    What distributed software is better than mainframe software.

    >
    > 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.
    >

    I doubt if batch processing will ever go away. I mean are backups batch?


  • Next message: Charl Freysen: "Re: ACCEPT - Stupid question"