Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!van-bc!tfic.bc.ca!clh From: clh@tfic.bc.ca (Chris Hermansen) Newsgroups: comp.databases Subject: Re: Any TUXEDO users here? Message-ID: <1991Jan23.205907.5477@tfic.bc.ca> Date: 23 Jan 91 20:59:07 GMT References: <2060008@hpcuhc.cup.hp.com> Reply-To: clh@tacitus.UUCP (Chris Hermansen) Organization: Timberline Forest Inventory Consultants Lines: 64 In article <2060008@hpcuhc.cup.hp.com> dhepner@hpcuhc.cup.hp.com (Dan Hepner) writes: >From: dafuller@sequent.UUCP (David Fuller) > >>>Since they have only begun to penetrate the market, perhaps someone will be >>>good enough to explain what they are and when they are useful? > >>The wizzened IBM or Tandem hand would claim that the assertion of "recent >>market penetration" is equivalent to "UNIX market immaturity". >>Dave Fuller > >Great posting, Dave Fuller. Amen. > >There's good reasons why TP monitors have not penetrated the >Unix market to the extent that they have penetrated the mainframe >market. It's interesting to note that several/most of the problems which >drove the original development of CICS (the most significant IBM monitor) >simply don't exist on Unix. CICS came into being in an environment >where timesharing wouldn't be available for years to come, where >the computing paradigm was a batch job which took over the entire >computer and ran to completion, and then the next one began. In >order to allow for OLTP, some mechanism was needed to have >a "single, perpetual batch job which interacted with lots of terminals". [stuff deleted] Just a few more comments (hopefully germane :-) One of the big uglies with CICS was (is?) (on VS1, at least) that, using one large enclosing batch job, all user programs linked in had the potential of stomping all over other user programs (they all used the same protect key). Usually, programs so ill behaved merely resulted in an addressing exception, but I always wondered about program segments going off the ends of arrays... (WHAT! What do you mean, my bank balance is zero!?!?!). It's my understanding that MVS may have fixed this problem. What VS1 shops used to do was have two CICS partitions (out of a maximum of 15, I believe) - one for testing, one for production. When you had a new program to test, you got the system manager to relink the test CICS and start up a fresh copy. When you had it "working", you put in a request to have it linked to the production CICS, which usually would happen just after backups when the system was brought back up. Point being, there was no dynamic linking... Software AG made (makes?) a TP monitor called COM-PLETE that gives a different perspective to the problems above; I believe that most sites that have given COM-PLETE a try are fairly happy with it (no plug intended). It uses a "multithreaded" approach, maintaining a separate thread for each application program. And one other issue about TP monitors; remember that in the big IBM environment, the three hundred fast-knuckled folks pounding in data are using block-mode terminals, not full-duplex VT100s, the point being that only a tiny amount of system resources are being used in dealing with user interrupts, and each one of those interrupts is one transaction. One doesn't often see UN*X systems configured like that :-) Interesting thread. Chris Hermansen Timberline Forest Inventory Consultants Voice: 1 604 733 0731 302 - 958 West 8th Avenue FAX: 1 604 733 0634 Vancouver B.C. CANADA clh@tfic.bc.ca V5Z 1E5 C'est ma facon de parler.