From: uucp@attmail.com
Subject: (none)
Reply-To: Info-Prime@Blx-A.Prime.COM
Date: Fri, 28 Aug 1992 23:57:11 GMT

Received: from internet by attmail; Fri Aug 28 23:57 GMT 1992
>From Relay.Prime.COM!Blx-A.Prime.COM!Info-Prime Fri Aug 28 19:54:44 EDT 1992 remote from internet
Received: by att.att.com; Fri Aug 28 19:56:43 EDT 1992
Received: from Blx-A.Prime.COM by Relay.Prime.COM; 28 Aug 92 20:02:12 EST
Received: from 0311061700114 (caller not authenticated) by Blx-A.Prime.COM; 29 Aug 92 01:55:51 +0200
Received: (from user J.BUSH) by md-b.prime.com; 28 Aug 92 19:54:46 EDT
Received: (from user J.BUSH using PRIMAILPLUS Version 1.0.2)
Subject: Re: tuning
To: internet!Blx-A.Prime.COM!Info-Prime 
From: internet!Relay.Prime.COM!Blx-A.Prime.COM!Info-Prime
	internet!MD-B.Prime.COM!J.BUSH (John Bush (PrimeService +1 508-620-2800 Voice x7068 Fax x5744))
Date: Fri, 28 Aug 1992 19:54:44 EDT
	internet!Blx-A.Prime.COM!ListServer (Prime Netherlands ListServer v1.12) 
Reply-To: internet!Blx-A.Prime.COM!Info-Prime 

RE:  4150 tuning

  It's been a while since I was directly involved in this,
  and I need a respite right now ...

> .... There are about 30 users logged in, all using the same
> login id and therefore the same CPL that presents a menu.

  Oh no, not another LOGIN.CPL menu system!  I'm not sure when
  a fix went in for this... people from Product Integrity can
  clarify it.  I'm working off memory here.  Up until a recent
  rev of Primos, the timeslice granted at Login was real BIG.
  The rationale was to be able to complete external login processing
  before hitting the low priority queues.  By kicking off the APP
  from within LOGIN.CPL, the system thinks you're still logging in,
  and your timeslice is something like 32000 seconds!

  Thus, break loose from it.  If you have an external login program,
  try inserting a CALL RECYCL in it.  The RECYCL call actually
  throws yourself at the mercy of the scheduler.  But as a result,
  you come out of it with a new (regular) timeslice.  It may take
  5 extra seconds to login if the system is busy, because of the
  queuing on the low pri queue.  This trick is untested as far as
  I know.  Plus, it's listed as "OBSOLETE" in the Subr. Ref. Guide.
  Ha!  It's been obsolete for several years now, but keeps right on
  ticking.  I used to use RECYCLE to time scheduler performance
  and calculate queue service rates.

  Another thing you can try is to force the LOGIN.CPL to exit without
  losing menu control.  Here's how:  Extract the menu stuff out of
  LOGIN.CPL and put it into a program called USERMENU.CPL.

  Create a "BREAKAWAY.COMI" file that looks like the following:

              R <wherever>USERMENU
              CO -TTY

  Then, terminate LOGIN.CPL like this:

              COMI <wherever>BREAKAWAY.COMI
              &RETURN

  This convoluted technique uses command processor "abeyance" to
  force execution of the "&RETURN" statement in the LOGIN.CPL
  program. When you issue the COMI command, it doesn't force
  execution of the file right away, it merely redirects the command
  stream so the next user command will come from that source. CPL
  doesn't read directives from the command stream. However, as soon
  as the &RETURN gets executed, the next command will be picked up
  from BREAKAWAY.COMI, which in turn, gets you into the menu, but
  you are completely free from the original LOGIN.CPL.

> .... The problem seems
> to be when the user has to stop one .RUN program and return to the CPL
> menu to invoke another .RUN.

  Try creating REGISTERED EPFs.

  In addition, modify the user profile:  Give more active EPFs per user,
  and more dynamic segments.  Do be careful, however, because your system
  is paging, and anything which adds to the memory demand can be
  detrimental.  (is that the same as "decrimental"?)

  Investigate what is causing the your page faults.

  Maybe you have seek contention, with PAGING and program data residing
  on the same drive.  Can you relocate PAGING to another less used drive?
  Do you have too many LOCATE BUFFERS configured?  I used to advocate
  always setting locate buffers to the maximum, simply because if an
  I/O was to occur, it doesn't matter whether it happens as a page fault
  or as a file system read.  It might actually be more efficent to
  do a page fault in response to a LOCATE FIND rather than to MISS and
  do regular I/O.  On the other hand, LOCATE buffers can thrash against
  large programs rolling in and out of memory.  Trial and error is still
  the best method for figuring it out, as long as you pretend you know
  what you're doing.  Depending on the reason for the page faults, adjust
  accordingly.  (or do I mean, "adjust the accordion?")

  If page faults were due to your programs' working set size, adding
  memory should have helped.

Regards,
John Bush

Newsgroups: comp.sys.prime