Jim writes:
> >> Dan's original message suggested that there was a POSIX interface on unix
> >> that could be used to lock a file into memory.  Is this true?  I'd be kind
...
> >No, Dan contended that there is, but the closest I could find is a procedure
> >that says "lock *MY* program into memory" ... which is not the same ability
> >as "lock *THAT* program into memory".
...
>
> Dan might be referring to UNIX's shared memory interfaces.  Take a look at
> shmctl(2) and notice the keyword SHM_LOCK.  A person might be able to
> create a shared memory segment, read a file into it, and then lock the
> shared memory segment in memory.
 
true, but that's different than locking "a file".  To me, "a file" implies
a degree of freedom/spontaneity like "I just noticed that this file, being
used this instant, might benefit by being locked into memory".  With MPE,
various methods (free: Debug, "freeze" routine; and products) provide this
ability.
 
This doesn't mean that I don't like POSIX shared memory stuff.
 
> This suggestion is, of course, just a WAG on my part.  If locking a program
> in memory is needed, then the "lock *MY* program into memory" sustem call
> you mention above might be able to lock any specified program, if run by
> root (or setuid root).
 
Sorry, I was trying to make it clear that the only POSIX system call that
locks program code (not shared memory!) files into memory lacks any kind
of parameter to say "lock that there program" ... it can only lock the program
that is calling the routine.
 
That's nice, but it requires that the programmer
of the program make the call.  I prefer a "lock specified program" routines,
since they can always handle the simple case that POSIX provides, and also
provide much more power and flexibility.
 
BTW, since Brian (?) mentioned ALLOCATE, I'll note in passing that some
Unix implementations:
 
   1) do work similar to loading CM Programs ... i.e., work at load time
      that isn't necessary if the program is currently loaded by someone
      else;
 
   2) have a "sticky bit" on the program file that basically is equivalent
      to saying "automatically ALLOCATE this program when it is loaded",
      which keeps the "load" work/info around, so the next attempt to
      run the program (when no one else is running it) is fast ... exactly
      the same benefit of ALLOCATE, but with a different slant.  (MPE can't
      assocate ALLOCATE with a CM PROG file in a permanent manner, but
      HP-UX can't say "AUTOALLOCATE ON", or "ALLOCATE specified running
      program" (although "chmod +t running_program_name" might do it!)
 
On HP-UX 10.0, you add "sticky" to a program by doing:
 
   chmod +t programfilename
(as root)
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html