Re: [Fwd: 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: 01/27/04 

Date: Tue, 27 Jan 2004 22:02:29 +1300

"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-55AFDA.22271526012004@corp.supernews.com...
> I just had to drop in a few comments. Please forgive the middle-posting:
>
> In article <bv1r7c$pgt$1@news.eusc.inter.net>,
> "Clark F. Morris, Jr." <cfmtech@istar.ca> wrote:
> > 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>
>
> Because of excessiive posting and reposting, I'm not sure if C.F.Morris
> or J.S.Giltner posted this...but I have to comment.
>
> >[much snippage]
> >
> > Hum, I bet Pete was an application programmer and not a system
> > programmer.

I have promised myself to stay out of what I perceive to be a pointless
debate (pointless because the debaters all have entrenched positions and no
minds are likely to be changed...) the fun bit is over and I honestly
believe this thread should be put to bed, but, leaving that aside, the facts
are as follows:

I worked as an IBM Sytems Programmer for three years in a career than
spanned nearly forty years. At least twenty of those years were spent in
Application programming for which I make no apology; it was my choice, I
enjoyed it and I believe it is the lifeblood of commerce. I have (right up
to this day) NEVER been ashamed to call myself an "Application Programmer'';
neither have I ever been ashamed to admit to programming in COBOL.

The poster is correct that my experience with CICS was over 20 years ago,
(it was nearer 30 years), and so my comments were based on my experience of
CICS which DID require predefined terminal tables at that time.

>> 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.
>
> The conceit of this statement is amazing. Do you realize that all of
> the helpful applications that you, as a sysprog, use every day are
> written by applications programmers???
>
> There were days when sysprogs were selected from the ranks of
> applications programmers for their willingness to understand the lower
> level operations of things. That was something like 30 years ago.
>
> Today, there is a pretty clear difference between "programmer" and
> "administrator".
>
> From previous discussions on C.L.C. I know Peter Dw is quite clueless in
> the areas of modern CICS. But I also have seen enough snippets of his
> code to know that he is one of the few Cobol programmers that groks
> sensible code construction, and is all around quite functional.
>
Well thanks, Joe...I think <G>. I have never claimed expertise in ''modern
CICS'', but I have never liked it as a TP monitor; I still consider IMS/DC
could eat it, and Shadow and TaskMaster (running on IBM mainframes in the
70s) could eat ANY IBM TP offering. But that's just my clueless
opinion...<G>

>
> > > 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.
>
> Here, you show that you do not understand subnets. TCP/IP keeps just
> fine track of all the addresses on a single host. A subnet is only a
> possible range -- using your implied criteria, does SNA keep track of
> all possible LU's defined by an 8-byte name space?
>
> And an HTTP connection can create as many connections as the receiving
> client (and feeding server) will allow. Why only 5? Stateless
> protocols operate in stateless ways.
>
> You seem to be trying to confuse the benefits of fixed circuit
> networking with virtual circuit networking. Or maybe just having an IE
> moment.
>
>
> > >> 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.
>
> Which decade are you in? You could add an order of magnitude to that.

Relevant Pages

  • Re: OT: Question for computer pros . . .
    ... I'm an old NeXT programmer so I can dig that. ... suspected I may have spyware so I used spysweep and all it found were ... my connection is being hijacked and re-routed through another node. ...
    (rec.games.pinball)
  • Re: X server mishap
    ... And that'll be fun as I've not quite gotten the internet connection sorted out for users. ... As a general question of curiosity, is it worth facing the learning curve to become a systems administrator and programmer? ... The Rute book and my friend's Admin text book are quite exhaustive in the technical aspects. ... To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". ...
    (Debian-User)
  • Re: Real life cost of using exceptions for control flow?
    ... > your program operates in normal conditions" (and bad input is one of the ... single land line, DSL connection, and on all network connections between two ... If I am a reliable programmer, the second connection was already up ... spurious exceptions like out-of-space on the disk. ...
    (microsoft.public.dotnet.framework.performance)
  • Re: what is the least amount of typing to assign the same value to multiple variables
    ... If there is no connection between them, however, and the requirement to ... have the same value is merely a coincidence (e.g. you're "zeroing them ... maintenance programmer the intent of the original programmer. ...
    (comp.lang.c)
  • PICK Programmer needed in Renton, WA
    ... A co-worker of mine has an opening for a PICK programmer to work on his ... Develop, support and perform extensive or complex, advanced ... Debug programs and applications. ... develop an understanding of the roles and responsibilities of the ...
    (comp.databases.pick)