home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / prime / 2015 < prev    next >
Encoding:
Text File  |  1992-08-29  |  4.9 KB  |  111 lines
  1. Newsgroups: comp.sys.prime
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!rpigate!x
  3. From: uucp@attmail.com
  4. Subject: (none)
  5. Message-ID: <9208290006.AA20506@usenet.rpi.edu>
  6. Sender: ListServer@Blx-A.Prime.COM (Prime Netherlands ListServer v1.12)
  7. Reply-To: Info-Prime@Blx-A.Prime.COM
  8. Date: Fri, 28 Aug 1992 23:57:11 GMT
  9. Lines: 100
  10.  
  11. Received: from internet by attmail; Fri Aug 28 23:57 GMT 1992
  12. >From Relay.Prime.COM!Blx-A.Prime.COM!Info-Prime Fri Aug 28 19:54:44 EDT 1992 remote from internet
  13. Received: by att.att.com; Fri Aug 28 19:56:43 EDT 1992
  14. Received: from Blx-A.Prime.COM by Relay.Prime.COM; 28 Aug 92 20:02:12 EST
  15. Received: from 0311061700114 (caller not authenticated) by Blx-A.Prime.COM; 29 Aug 92 01:55:51 +0200
  16. Received: (from user J.BUSH) by md-b.prime.com; 28 Aug 92 19:54:46 EDT
  17. Received: (from user J.BUSH using PRIMAILPLUS Version 1.0.2)
  18. Subject: Re: tuning
  19. To: internet!Blx-A.Prime.COM!Info-Prime 
  20. From: internet!Relay.Prime.COM!Blx-A.Prime.COM!Info-Prime
  21.     internet!MD-B.Prime.COM!J.BUSH (John Bush (PrimeService +1 508-620-2800 Voice x7068 Fax x5744))
  22. Date: Fri, 28 Aug 1992 19:54:44 EDT
  23. Sender: 
  24.     internet!Blx-A.Prime.COM!ListServer (Prime Netherlands ListServer v1.12) 
  25. Reply-To: internet!Blx-A.Prime.COM!Info-Prime 
  26.  
  27. RE:  4150 tuning
  28.  
  29.   It's been a while since I was directly involved in this,
  30.   and I need a respite right now ...
  31.  
  32. > .... There are about 30 users logged in, all using the same
  33. > login id and therefore the same CPL that presents a menu.
  34.  
  35.   Oh no, not another LOGIN.CPL menu system!  I'm not sure when
  36.   a fix went in for this... people from Product Integrity can
  37.   clarify it.  I'm working off memory here.  Up until a recent
  38.   rev of Primos, the timeslice granted at Login was real BIG.
  39.   The rationale was to be able to complete external login processing
  40.   before hitting the low priority queues.  By kicking off the APP
  41.   from within LOGIN.CPL, the system thinks you're still logging in,
  42.   and your timeslice is something like 32000 seconds!
  43.  
  44.   Thus, break loose from it.  If you have an external login program,
  45.   try inserting a CALL RECYCL in it.  The RECYCL call actually
  46.   throws yourself at the mercy of the scheduler.  But as a result,
  47.   you come out of it with a new (regular) timeslice.  It may take
  48.   5 extra seconds to login if the system is busy, because of the
  49.   queuing on the low pri queue.  This trick is untested as far as
  50.   I know.  Plus, it's listed as "OBSOLETE" in the Subr. Ref. Guide.
  51.   Ha!  It's been obsolete for several years now, but keeps right on
  52.   ticking.  I used to use RECYCLE to time scheduler performance
  53.   and calculate queue service rates.
  54.  
  55.   Another thing you can try is to force the LOGIN.CPL to exit without
  56.   losing menu control.  Here's how:  Extract the menu stuff out of
  57.   LOGIN.CPL and put it into a program called USERMENU.CPL.
  58.  
  59.   Create a "BREAKAWAY.COMI" file that looks like the following:
  60.  
  61.               R <wherever>USERMENU
  62.               CO -TTY
  63.  
  64.   Then, terminate LOGIN.CPL like this:
  65.  
  66.               COMI <wherever>BREAKAWAY.COMI
  67.               &RETURN
  68.  
  69.   This convoluted technique uses command processor "abeyance" to
  70.   force execution of the "&RETURN" statement in the LOGIN.CPL
  71.   program. When you issue the COMI command, it doesn't force
  72.   execution of the file right away, it merely redirects the command
  73.   stream so the next user command will come from that source. CPL
  74.   doesn't read directives from the command stream. However, as soon
  75.   as the &RETURN gets executed, the next command will be picked up
  76.   from BREAKAWAY.COMI, which in turn, gets you into the menu, but
  77.   you are completely free from the original LOGIN.CPL.
  78.  
  79. > .... The problem seems
  80. > to be when the user has to stop one .RUN program and return to the CPL
  81. > menu to invoke another .RUN.
  82.  
  83.   Try creating REGISTERED EPFs.
  84.  
  85.   In addition, modify the user profile:  Give more active EPFs per user,
  86.   and more dynamic segments.  Do be careful, however, because your system
  87.   is paging, and anything which adds to the memory demand can be
  88.   detrimental.  (is that the same as "decrimental"?)
  89.  
  90.   Investigate what is causing the your page faults.
  91.  
  92.   Maybe you have seek contention, with PAGING and program data residing
  93.   on the same drive.  Can you relocate PAGING to another less used drive?
  94.   Do you have too many LOCATE BUFFERS configured?  I used to advocate
  95.   always setting locate buffers to the maximum, simply because if an
  96.   I/O was to occur, it doesn't matter whether it happens as a page fault
  97.   or as a file system read.  It might actually be more efficent to
  98.   do a page fault in response to a LOCATE FIND rather than to MISS and
  99.   do regular I/O.  On the other hand, LOCATE buffers can thrash against
  100.   large programs rolling in and out of memory.  Trial and error is still
  101.   the best method for figuring it out, as long as you pretend you know
  102.   what you're doing.  Depending on the reason for the page faults, adjust
  103.   accordingly.  (or do I mean, "adjust the accordion?")
  104.  
  105.   If page faults were due to your programs' working set size, adding
  106.   memory should have helped.
  107.  
  108. Regards,
  109. John Bush
  110.  
  111.