From: gml4410@uk0x08.ggr.co.uk (Lack Mr G M)
Subject: Re: Rev 23.2 bits
Reply-To: Info-Prime@Blx-A.Prime.COM
Date: Thu, 9 Apr 1992 10:49:44 GMT

> Paging: When we first booted up, we had horrendous problems. Apparently we
> were 100000+ pages short of the recommended number according to the message
> from the console - ouch! Most of the PRIMOS.COMI bits were okay, though the
> command environment had a tendency to reinitialise due to lack of segments
> (our defaults were 128/128 dyn/static). It seems that for anyone to get
> anywhere we will have to give them a more generous segment count ... :-(

     Yes,  Prime  reckons  that  you  need 1000 pages per NUSR + NRUSR +
NPUSR + NTSUSR.  This is a little on the catious side when you  have  to
set  NPUSR  high  to  get all of the TCP/IP (and other) server processes
running and they only use ca.   100  each.   The  message  is  *only*  a
warning. 

> I read that after CONFIG_USERS is invoked, EDIT_PROFILE is no longer usable.
> This is a little disconcerting, if I am correct here, as virtually all of our
> user-adding programs utilise EDIT_PROFILE in CPL ...

     I  think  this  is  only true if you use the CONFIG_USERS option to
turn on the extra security features at Rev23.2 (password history etc.). 

> REGISTER_EPF looks like it could be fun. With the -PUBLIC declaration in
> ENTRY$.SR, does it then matter where the associated rule actually resides;
> ie. can I put things like LIBRARIES*>APPLICATION_LIBRARY at the bottom of the

     You  should  have  the -PUBLIC entry in the relevant place and then
add the non-PUBLIC ones  again  at  the  very  end,  just  in  case  the
registration fails.  It may also be more efficient to use:

-PUBLIC <epf_lib_name>

in each specific location rather than the generic -PUBLIC: I don't know.

>     My interpretation is that commands like LD can be registered too.
> How does registering affect updatess to libraries/programs whilst the
> original is in use?

     You can only register a program if it was built as a registered EPF
(which isn't difficult  we just added:

        progmode -register
        default_dynt_type -shared

to  a  loading  sequence).  To update a registered EPF just register the
new copy (but not to often, otherwise you will run out of dynamic  DTAR3
segments). 


> TCP/IP: I seem to remember 2.4 supporting ip numbers access. Or is that based
> within PRIMOS (we haven't got the source yet, as the tapes arrived
> corrupted).

     It's in at 2.4, and there's a sample program (in C) to show you how
to get the info (although you don't need C at all...  the info come from
NT$LTS in Primos). 

     Be warned, though, that there is a bug in the TCP/IP_MANAGER at 2.4
(fix due soon...) related  to  malloc/free.   It  uses  more  pages  and
segments  as  time  goes  on  (but  only 16 pages per segment!) and will
eventually crash, either by running out of dynamic segments or  reaching
the  NSEG  limit  (and,  of  course,  other users may have problems with
segmnet availability once the TCP/IP_MANAGER has reached a  few  hundred
instead of his (her?) usual 12. 


> The parallel SHARES.COMI: can this include initialisation commands like
> EMACS -INIT etc, and PROP -COLDSTART, or must these still be in PRIMOS.COMI?

     It  *can*  include  EMACS  (mine  does)  but  PROP  -Coldstart  (in
SPOOL.SHARE.COMI) we failed on (but even that might  work  if  you  make
SYTSEM a .SPOOL_ADMINISTRATOR$ - however, is it worth it?). 

Newsgroups: comp.sys.prime