home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6498 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  3.7 KB
  1. Path: sparky!uunet!mcsun!uknet!edcastle!simon
  2. From: simon@castle.ed.ac.uk (Simon Brown)
  3. Newsgroups: comp.databases
  4. Subject: TP monitors for SunOs, 3278 drivers.
  5. Message-ID: <25442@castle.ed.ac.uk>
  6. Date: 2 Sep 92 14:01:37 GMT
  7. Organization: Meiko Scientific
  8. Lines: 62
  9.  
  10. I'm posting this article on behalf of a friend who doesn't have access to the
  11. net. 
  12.  
  13. Subject: TP monitors for SunOs, 3278 drivers.
  14.  
  15. Dear Netters,
  16.  
  17. TP monitors are a popular discussion topic these days. However, I confess 
  18. to having experienced real difficulty in piecing together a coherent 
  19. understanding of what I may be able to use one for. 
  20.  
  21. I hope that what follows serves to start a discussion, as well as to give me
  22. some pointers towards useful products. I am sure it is incorrect in many 
  23. respects, which is partly why I am posting it.
  24.  
  25. The problem seems to me to be that there once was a term "TP monitor" which 
  26. meant something quite specific. It came from the days when Big Computing
  27. in the DP world was all about handling very large numbers of small, simple
  28. users on machines with relatively small numbers of MIPS, and relatively
  29. small memories. An installation would only have one of these machines,
  30. and it would be very big, and very expensive.
  31.  
  32. To handle this large number of users two things are critical: to minimise
  33. the cost of context switches between users, and to minimise the amount a state
  34. that needs to be held per user in fast memory. TP monitors (EG CICS) achieve
  35. this by being much less extravagent with their use of heavy processes than Unix
  36. applications would typically be. Instead, they have a few (?) great big
  37. processes which work on behalf of a large number of users, holding for each
  38. user the bare minmal amount of state information required. A typical Unix 
  39. setup would, by contrast, have at least one heavyweight process per user (maybe two, if using a 2-task RDBMS setup).
  40.  
  41. Some "TP monitor" products now exist for the SunOS platform (in which I am 
  42. interested). However, they differ from my expectations in some subtle and
  43. confusing ways. Firstly, they seem to consist of a package of functionality
  44. which starts with what I understand to be a TP monitor, but extends to cover
  45. many other areas. The only way in which I can usefully catagorise this extra 
  46. stuff is as "things which got left out of RDBMSs and O/Ss, but which
  47. database system designers might find useful". It includes things like network
  48. load balancing, database distribution and so on. 
  49.  
  50. The other difference is that (in my naive understanding), a Unix TP monitor
  51. is really no more than a sophisticated RPC system. It expects there
  52. to be clients, probably out over the network somewhere, which run as proper
  53. grown-up programs, talking to the RPC-server (AKA TP monitor) via something
  54. sophisticated and expensive like TCP/IP. This is fine, provided your
  55. system architecture allows it. However, it does you much less good 
  56. if your front-end is an enormous network of dumb terminals, or even semi-dumb
  57. terminals like IBM 3278s. What you want then is CICS, under Unix. Not a CICS
  58. migration tool, or a compatability interface, but something which lets you
  59. service a sensible number (500 ?) of OLTP users on a small machine like a 
  60. SPARCstation 10 (?). Something which concentrates on servicing terminal
  61. (or 3278) i/o with jealously husbanded CPU cycles, and holds not one 
  62. byte more data than is really needed.
  63.  
  64. Does anyone out there have any suggestions (products) ? or corrections ?
  65. I would be quite interested in information on 3278 terminal driving h/w
  66. and s/w for SunOs too. Over to you.
  67.  
  68. ------------------------------------------------------------------------------
  69. Simon Brown             / /     email: simon@ed.ac.uk, or simon@meiko.co.uk 
  70. Meiko Ltd. (Edinburgh) / /
  71. ------------------------------------------------------------------------------
  72.