Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!GOLD.BACS.INDIANA.EDU!ijah400%ivax.DECnet From: ijah400%ivax.DECnet@GOLD.BACS.INDIANA.EDU ("IVAX::IJAH400") Newsgroups: comp.os.vms Subject: Re: PRV$M_SETPRI (and other undocumented priv bits). Message-ID: <8807111737.AA03630@ucbvax.Berkeley.EDU> Date: 10 Jul 88 03:25:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 Peter Scott (PJS%GROUCH@JPL-MIL.JPL.NASA.GOV) writes about PRV$M_SETPRI: < not the same as either ALTPRI or SETPRV. I haven't found this discussed < anywhere. Can someone tell me what it is for, please? Sure they are. STARLET.REQ for VMS 4.x contains the following lines: literal PRV$M_SETPRI = 8192; literal PRV$M_ALTPRI = 8192; macro PRV$V_SETPRI = 0,13,1,0 %; ! MAY SET ANY PRIORITY VALUE macro PRV$V_ALTPRI = 0,13,1,0 %; ! MAY SET ANY PRIORITY VALE (SETPRI) So, PRV$M_SETPRI is just another name for the ALTPRI privilege bit. This appears to be "historical" (somebody at Digital decided to change the name). Now I have a question. In writing a recent application, I stumbled across four undocumented privilege bits that the SYSTEM account has. These are: UPGRADE DOWNGRADE TMPJNL PRMJNL UPGRADE and DOWNGRADE are both listed in STARLET.REQ, they are bits 0 and 1 in the second privilege longword. These are described as "may up(down)grade classification". AUTHORIZE seems to know about these too; at least it will let you give them to a user, but it won't list them out with SHOW. I can't find anything on TMPJNL and PRMJNL anywhere, except that the SYS$SETPRV documentation describes them (they aren't mentioned at all in the table in the DCL Concepts Manual). LIB$GETJPI returns them (when reading the AUTHPRIV mask of a process logged in as SYSTEM as a string) as SPARE1 and SPARE2 (which was what was screwing up my application). Do these have anything to do with transaction processing? And what's a "classification"? James A. Harvey ijah400@indyvax (bitnet) or ijah400%ivax.decnet@gold.bacs.indiana.edu