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