From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 10-FEB-1994 16:16:57.92 To: EVERHART CC: Subj: Re: SOFTQUOTA utility From: wayne@tachyon.com (Wayne Sewell) X-Newsgroups: vmsnet.sources.d,comp.os.vms Subject: Re: SOFTQUOTA utility Message-ID: <1994Feb10.085946.1111@tachyon.com> Date: 10 Feb 94 08:59:39 CST Organization: Tachyon Software Consulting Lines: 133 To: Info-VAX@CRVAX.SRI.COM X-Gateway-Source-Info: USENET In article <1994Feb9.081841.1202@nrlvx1.nrl.navy.mil>, koffley@nrlvx1.nrl.navy.mil ("JOE KOFFLEY") writes: > Has anoyone seen a more current version of a utility called SOFTQUOTA ? I > have a version from the 87 DECUS tapes but it is attempting to use some > kernel mode code to find matching UICs that generates warnings a la : > > %MACRO-W-GENWRN, Generated WARNING: Raising I P L to 80$ provides no multiproce > ssing synchronization > > There were 0 errors, 1 warning and 0 information messages, on lines: > 107 (1) > > MAC FIND_UIC > %LINK-W-WRNERS, compilation warnings > in module FIND_UIC file UTILITY:[SOFTQUOTA]FIND_UIC.OBJ;1 > %LINK-W-NUDFSYMS, 1 undefined symbol: > %LINK-I-UDFSYM, SCH$GL_CURPCB > %LINK-W-USEUNDEF, undefined symbol SCH$GL_CURPCB referenced > in psect FIND_CODE offset %X0000005B > in module FIND_UIC file UTILITY:[SOFTQUOTA]FIND_UIC.OBJ;1 > > I'm not a MACRO systems programmer but I can see the general idea behind the > offending code based on the comments it contains. They are : > > ; FUNCTIONAL DESCRIPTION: > ; > ; Loop through all PCBs and look for another process with the > ; same UIC. If on the same node compare PID to see if another process > ; > ; CALLING SEQUENCE: > ; > ; answer = find_uic(UIC, PID) > ; > ; INPUTS: > ; 4(AP) - UIC want to match > ; 8(AP) - 0 if process wanting to match is on another node in cluster > ; PID if process is on same node > ; > ; IMPLICIT INPUTS: > ; SCH$GL_PCBVEC - contains address of PCB vector > ; SCH$GL_MAXPIX - maximum process index > ; SCH$GL_CURPCB - contains address of pcb of current process > ; > ; OUTPUTS: > ; R0 - Whether another process with the same UIC was found > ; > ; IMPLICIT OUTPUTS: > ; none. > ; > ; ROUTINE VALUE: > ; > ; R0 = SS$_NORMAL - another process found with same UIC > ; = SS$_NOMOREPROC - no other processes found with same UIC > ; = SS$_BADPARAM - bad UIC > ; > ; SIDE EFFECTS: > ; > ; Some of this routine is executed at IPL SYNCH to synchronize > ; the use of the PCB Vector and the PHD for each process. > ; > ; None intentional - has tendency to crash system while testing! > ;--; > > In lieu of a newer version, would anyone be willing to look at the MACRO > source (I'll mail it or post it as it's very short) and suggest a fix ? > My own assessment of the situation is that the code was written under a much > older VMS and some of the symbols have been replaced/obsoleted and/or > changed their names. > > I am fairly confident that the functionality can be replaced by code using > $GETJPI but I'd venture a guess that the purpose in writing (sp) it in MACRO > was to exploit speed advantages that $GETJPI doesn't offer. > > Hopefully I've at least given enough info to satisfy Carl or Ehud and avoid > any flames. > > > -- > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > < Joe Koffley KOFFLEY@NRLVAX.NRL.NAVY.MIL > > < Naval Research Laboratory > > < Code 8101 KOFFLEY@NRLVX6.NRL.NAVY.MIL > > < Space Systems Division AT&T : 202-767-0894 > > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > The program was written before SMP. Both of the errors are related to changes for SMP support. Before SMP, raising IPL was an acceptable way for kernel mode code to synchronize access to system data structures. Under SMP, that breaks. The IPL change affects only one processor and the other processors are not locked out. Thus synchronization requires use of a spin lock, a new mechanism introduced for SMP. It uses the interlocked bit instructions to synchronize multiple processors. In general, you replace occurences of DSBINT or SETIPL >0 with calls to the LOCK or DEVICELOCK macro, and replace ENBINT or SETIPL 0 with the UNLOCK and DEVICEUNLOCK macros. In places where you want to continue using SETIPL, possibly in conjunction with a spinlock, adding "ENVIRON=UNIPROCESSOR" will get rid of the warning message. Since this code is scanning the PCBs, I would imagine that it is raising IPL to IPL$_SYNCH for access to the scheduler database. This should replaced with code to lock the SCHED spinlock. The SCH$GL_CURPCB symbol is obsolete because there can now be *more than one* current process, since each processor can have a current process. A single memory location won't work any more. The current process is now kept in the CPU database. Each processor has its own private storage in the CPU database, and CPU-specific information such as current process is kept there. There is a macro to find the database for the CPU on which you are executing, but this may not be necessary. If a process wants to get its *own* PCB address (and in process context, curr_pcb=my_pcb), there are easier ways to get it. In process context the control region is visible, so you can get the pcb address from CTL$GL_PCB. This would be a straightforward upgrade to SMP. The Device Support Manual should give you all the information you need. Wayne -- ============================================================================== Wayne Sewell |INET: wayne@tachyon.com Tachyon Software Consulting |UUCP: uupsi!uupsi6!tachyon!wayne P. O. Box 550937, Dallas TX 75355-0937 |Voice: (214)-553-9760, Fax: -553-0077 ============================================================================= Moe, holding out fingers:"Pick two." Curly:"One, two. Yeow!"