Hi,

There's only one kind of PIN (Process Identification Number).

Prior to MPE/iX 7.0, the maximum PIN was about 8191 (and smaller on
some older releases).  With 7.0, very large systems can enable the
BIGPIN option, increasing the limit to 12000 PINs.

Thus, a PIN can be represented in 16 bits.

As for 16-bit vs. 32-bit....

On MPE V, intrinsics that accepted PIN parameters used 16 bits
for the parameters.  On MPE/iX, we wanted to look forward to the
possibility of having more than 32767 processes.  (During the original
design of HPE, which became MPE XL / MPE/iX, negative values had
a special meaning.  Sadly, that feature was dropped (apparently
by Ed McClanahan) after I left HP.)   The possibility of having
a larger number of processes -- someday -- led me to use 32-bits to
hold PINs in all new (i.e., native mode) data structures.

However, for source-code compatibility reasons, all native mode intrinsics
that had the same name as their CM counterparts had to keep their
parameter size the same (where possible ... CREATEPROCESS, SEARCH, and
MYCOMMAND are the three most common intrinsics whose parameters
had to change).  New intrinsics (e.g., AIFPROCGET) should have a
32-bit parameter for passing/returning a PIN ... even though values
no larger than 12000 will be returned.

Here are the NM intrinsics that either have an explicit PIN parameter,
or that return a PIN as a functional result.  (Omitted from the list
are intrinsics like HPFOPEN and JOBINFO, which can accept or return
PINs via a somewhat different mechanism.)

Intrinsics in SYSINTR:
   ACTIVATE       uint16 <-- BUG
   CREATE          int16
   CREATEPROCESS   int16
   FATHER         uint16 <-- BUG
   GETPRIORITY    uint16 <-- BUG
   GETPROCID      uint16 <-- BUG
   GETPROCINFO    uint16 <-- BUG
   KILL           uint16 <-- BUG
   LOCRINOWNER     int16
   MAIL            int16
   PROCINFO       uint16 <-- BUG
   RECEIVEMAIL     int16
   SENDMAIL        int16

Note that I flagged some as "BUG".  Those intrinsics are **DOCUMENTED**
as having a signed 16 bit parameter/result, but are *IMPLEMENTED*
(in the SYSINTR/PEINTR files) as having *UNSIGNED* 16 bit parameters.

(A very brief look at NL.PUB.SYS, seems to confirm that those parameters
/functional results are indeed unsigned 16-bit integers.)

Sheesh.

Although debatably called "intrinsics", we should also peek at some of
the routines in the AIF (Architected Interface Facility) ... they're examples
of routines that should have 32-bit signed integers for PIN parameters/results:

Intrinsics in AIF intrinsic file(s):
   AIFPROCGET      int32
   AIFPROCPUT      int32
   PEARM          uint16 <-- BUG
   PEDISARM        int32

Oh well :(


> But then I looked at PROCINFO.  That has a 16 bit PIN which is
> documented as not being compatible with GETPROCINFO PIN's.

Documentation bug.
I have no idea what the author of that document was thinking of.

Hope that helps!

Note that I didn't even mention the MPE PID (which would have been better
named "XPIN" (for eXtended PIN).  The comp.sys.hp / HP3000-L posts:

   http://groups.google.com/groups?q=pid+pin+sieler&hl=en&lr=&ie=UTF-8&oe=UTF-
8&newwindow=1&selm=53253%40cup.portal.com&rnum=1

and

   http://groups.google.com/groups?q=pid+pin+sieler&hl=en&lr=&ie=UTF-8&oe=UTF-
8&newwindow=1&scoring=d&selm=F4B1826B1A21D211AEC5006008207AF401E23E3E%40dogbert.
csillc.com&rnum=4

discuss the MPE PID (different than POSIX PID or PA-RISC PID).


--
Stan Sieler
[log in to unmask]
www.allegro.com/sieler/wanted/index.html

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *