Dan 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 of
> >> surprised if the POSIX.1 standard included such an interface (and
> shouldn't we
> >> then have it on MPE/iX too?).
> >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".
>
> Let's not argue semantics about "this" and "that" in efforts to discredit
> one another. All I need is a programmatic way for a program to lock *itself*
> into memory. I do not need to lock "*THAT*" program into memory, so let's
> drop that thread of discussion.
 
No..let's not.  Other people have inquired in the past about locking programs
into memory ... programs they do *not* have the source code for...
thus the POSIX-style "lock me into memory" wouldn't help them, as that
would require (a) source code and (b) compiler.  That's why MPE's approach
of "lock that thing into memory" is more powerful, because it can always
be used as a "lock me into memory" if desired!  In general, when comparing
two features "A" and "B", if "A" also implements "B", then I'll choose "A".
 
> POSIX.1 does not define a memory locking facility, but POSIX.4 does:
>
> Lock entire program into memory:
> int mlockall(int flags);
> int munlockall(void);
>
> Lock portions into memory:
> int mlock(void *address, size_t length);
> int munlock(void *address, size_t length);
 
I'm glad Dan pointed these out...I'd like to be able to use them in
POSIX (on various machines), except that:
 
   1)  the appear to probably be 32-bit address oriented, since "void *address"
       is usually the default address size; ... which would imply they won't
       work on 64-bit (or larger) addresses.  (HP-UX has a poor man's
       64-bit virtual memory, but I'd still like to control it!)
 
   2) Neither HP-UX 10.0 nor IBM AIX 2.3 (admittedly not the latest version!)
      have mlock/mlockall.
 
still, I'm looking forward to a real, usable 64-bit and beyond memory
control API for POSIX/Unix ... maybe in a few years?  There's been some
noise about HP-UX learning about memory management from MPE/iX ... maybe
that can spark development of such an API?
 
> Both methods given (the 'debug method' and the 'freeze' method) do not
> address the need to *programatically* do memory locking from within an
> application itself. Is there a way or isn't there a way to have an NM
> program do this on MPE?
 
Yes, PM required:
 
   1) Debug
 
       var
          str : string [100];
 
       str := '~fva dp, 100; c~';
       hpdebug (status, str, ...);
 
   2) quicker...
 
      Procedure freeze (ptr    : globalanyptr;
                        bytes  : integer;
                    var status : hpe_status;
                        dummy  : integer)
            option default_parms (
                        dummy  := 0);
         external;
 
      (no, I don't know the exact definition of the "dummy" parameter...but
      every call to freeze that I've checked in MPE passes a 0 there.)
 
      Procedure unfreeze (ptr  : globalanyptr;
                        bytes  : integer;
                    var status : hpe_status);
         external;
 
 
      freeze (addr (my_buffer), sizeof (my_buffer), status);
            {above freezes the variable "my_buffer" into memory}
            {you could freeze code, too, if you know the virtual address}
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html