Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!yale!husc6!mit-eddie!genrad!decvax!ucbvax!psw.DEC.COM!winalski
From: winalski@psw.DEC.COM (Paul S. Winalski)
Newsgroups: mod.computers.vax
Subject: Re: PIDs -- curiosity
Message-ID: <8701132004.AA03728@decwrl.dec.com>
Date: Tue, 13-Jan-87 17:58:00 EST
Article-I.D.: decwrl.8701132004.AA03728
Posted: Tue Jan 13 17:58:00 1987
Date-Received: Thu, 15-Jan-87 03:04:30 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 25
Approved: info-vax@sri-kl.arpa

The low-order bits of a PID contain the process's Process Control Block (PCB)
index number and an incarnation count for use of that index number.  The
high-order bits of a PID contain a cluster node number value and an incarnation
count for use of that node number value.  This information is bit-stuffed
into the 32 bit PID value in a way that is not documented and is totally
subject to change.  Even within the VMS kernel itself, the knowledge of how
to pick apart a PID into its component pieces is confined to two routines
(one takes the pieces and builds a PID, the other takes a PID and returns the
pieces).  These are the only parts of the whole operating system that know
or care what the internal format of a PID is.

The change that you saw in the PID for SWAPPER from 00000010 to 00000040 most
likely occurred because your system went from a max. process count of 16 to
a max. process count of 32.  Probably because of something AUTOGEN did when
you installed one of the other subsets.

The change from 2040xxxx to 2140xxxx on a clustered system looks like a change
in the incarnation number for that node in the cluster.  Is it possible that
it crashed (or was taken down) and rebooted, while the cluster remained up?
When it re-joins the cluster, the incarnation number will be bumped by one
so that processes on other cluster nodes that may have known about PIDs on
the system that left the cluster (and now has rejoined) don't get the wrong
process by mistake.

--PSW