SYNFUL@DRYCAS.BITNET.UUCP (01/11/87)
This is not a high-priority item, but just a matter of curiosity... I just finished un-upgrading our uVAX-I from VMS V4.4 to V4.3 (because of the flaky DEQNA and our Internet software crapping out on it) and I discovered some interesting things: When I first installed V4.3 (after all reasonable backups and such) and all chosen options from the SYSP, USER, UTIL, PROG, and other subsets, the machine tried to boot up as a cluster. (I had also installed DECnet but not the End Node Key.) [On bootup it complained that CLUSTRLOA.EXE was missing.] Using B/5, I found that AUTOGEN had set my VAXCLUSTER to a value of 1, which I reset to 0 and made DRYCAS happy to be alone. After this was done, I noticed that the PID for SWAPPER was 00000010. Normally (when I ran 4.3 before and when I was running 4.4) it was 00000040. After I installed a few more packages, SWAPPER returned to its normal 00000040. On our 8650 running V4.4 (and recently clustered), the PIDs are 2140xxxx (now, anyway...sometime before I could have sworn they were 2040xxxx). Am I confused or is there logic to this? --Marc Shannon CMU Computer Club SYNFUL@DRYCAS.Bitnet
cetron%utah-ced@UTAH-CS.ARPA (Ed Cetron) (01/13/87)
don't know about logic, but all of our 4.3 machines with deqna's have terrible problems, but all of the 4.4 and 4.5 machines run sweet as can be.....(and we have TERRIBLE problems on the 4.3 nodes)..... Do you have the newest DEQNA's with the recent ECO???? Or are they the older (original) ones??? -ed cetron center for engineering design univ of utah
winalski@psw.DEC.COM (Paul S. Winalski) (01/14/87)
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
ted@cgl.ucsf.edu@blia.UUCP (01/14/87)
In article <8701131650.AA08077@ucbvax.Berkeley.EDU>, SYNFUL@DRYCAS.BITNET (Marc Shannon) writes: > After this was done, I noticed that the PID for SWAPPER was 00000010. > Normally (when I ran 4.3 before and when I was running 4.4) it was > 00000040. After I installed a few more packages, SWAPPER returned > to its normal 00000040. > On our 8650 running V4.4 (and recently clustered), the PIDs are > 2140xxxx (now, anyway...sometime before I could have sworn they > were 2040xxxx). This is all due to the format of version 4.x external PIDs. The format of the longword is as follows: | | | | | cluster node # | IPID sequence # | IPID slot # | | (10 bits) | (22-n bits) | (n bits) | | | | | where the "IPID sequence #" is the high word of the internal PID (equiv. to the version 3.x PID), "IPID slot #" is the low word of the internal PID, and "n" is the minimum number of bits required to hold the process slot number as determined from the SYSGEN maximum number of processes. Thus, the high 10 bits contains the node number (0 on a non-clustered VAX), the low "n" bits contains the process slot number (just as many bits as required), and the remaining bits contain the sequence number for the process slot. Since the swapper is slot # 1, sequence # 1, on a system configured for 15 or fewer processes and not in a cluster, its pid would be 00000011. Reconfiguring the system for 32 to 63 processes would change it to 00000041. (I assume your saying the swapper was in 10 and 40 was a typo. Either you meant the null process or you meant 11 and 41). Your big VAX has its node number in the high bits and so its PIDs are 214xxxxx. The PID conversion routines are in the module SYSPCTRL in facility SYS if you want to look at the fiche. These routines are described on page 8-12 of the version 4.0 release notes (you did keep the 4.0 release notes, didn't you? :->). =============================================================================== Ted Marshall Britton Lee, Inc. p-mail: 14600 Winchester Blvd, Los Gatos, Ca 95030 voice: (408)378-7000 uucp: ...!ucbvax!mtxinu!blia!ted ARPA: mtxinu!blia!ted@Berkeley.EDU disclaimer: These opinions are my own and may not reflect those of my employer; I leave them alone and they leave me alone. fortune for today: Churchill's Commentary on Man: Man will occasionally stumble over the truth, but most of the time he will pick himself up and continue on.