.comment .comment File: OPA.RNO .comment .comment Description: .comment .comment This file documents the online pool analyzer utility .comment The information contained in this document was taken largely .comment from the documentation provided on the DECUS tape by: .comment .comment Jim Neeland .comment Hughes Research Labs .comment 3011 Malibu Canyon Rd. .comment Malibu, California 90265 .comment .comment .comment Author: Rick Webster .comment MSDGO, Process Control .comment Caterpillar Tractor Co. .comment .comment Date: 13-JAN-83 .comment .PS 60,71 .LM 0 .NHD .OD; .HEADER .SUBTITLE OPA - Online Pool Analyzer .HL 1 OPA - Online Pool Analyzer .X OPA - Online Pool Analyzer .HL 2 Release notes .x OPA> Release notes .p 0 A number of bugs have been fixed, some of which were introduced with RSX11M V4.0 and others which existed in V3.2. The .IDENT of the new version of OPA in V04.0. The previous version of OPA was JN3.32. The following changes were made: .list .le;Increased the buffer to map up to 14K words of pool instead of just 10K .le;Added code to map to a device's ACP when searching for all its FCB's. This allows identification of FCB's in pool that are pointed to by FCB's in the ACP's private pool. .le;Changed the TCB display to allow for the increased size of TCB's in RSX11M V4.0. TCB's for V3.2 will still be the correct size. .le;Modified the window block display so that window blocks for an index file will contain the device name and unit number in the display (if it will fit). Window blocks for files will contain the task name that has the file open in the display. If the additional information will not fit, then the window block display will just have '====='s. .le;Corrected the display for VCB's and FCB's so that a two digit unit number is displayed instead of just 1. To do this, the "@" no longer appears in the FCB display. Also the length of the VCB was corrected. .le;Fixed up the output format a bit .le;Changed OPA to use the disable context switching feature of RSX11M ($CXDBL) instead of using $SWSTK. This allows the user instruction PAR's to be used instead of the kernel inst. PAR's. This also allows the use of ODT for debugging instead of XDT, reduces chances of crashing the system when debugging and allows use of system directives if needed. Yet no other task may run while context switching is disabled so all data structures remain intact. .els The above corrections were done in part to accomodate RSX11M V4.0 but OPA should still function correctly on V3.2. .HL 2 Description .X OPA> Description .P 0 OPA is a privileged task to display a snapshot map of the current contents of pool. This program is sufficiently valuable to all system managers/programmers who have pool space problems that it is well worth the risk of using. However, it is necessary while this program is scanning through pool to be on the system stack. It has been made somewhat more rugged than the 3.1 version submitted for San Diego DECUS, as it now catches its own odd address or memory protect traps, and reports them rather than causing a system crash. It is, however, conceivable that it might corrupt something in the EXEC, although rather less likely. The biggest problem from overuse is that some device drivers may require frequent access to system state (i.e. forking) in order not to lose interrupts. While this task is collecting data, the EXEC cannot handle fork requests. However it has been in use on the Process Control development computers in MSDGO at Caterpillar for quite some time, with no adverse effects. .p 0 The program will identify about 95% of the data structures kept in pool, in its current version. Remaining known structures not identified are: .p 0 .lm +10 .i -10 AST#######control blocks and I/O packets associated w/ the full-duplex terminal driver... .b .i -10 RECEIVE###packets (certain tasks [notably TKTN, LOADER] have non-standard message sizes, and without significant checking any attempt to map those packets along with the standard ones would certainly cause difficulties). .b .i -10 FCB's#####for other than INDEXF.SYS (The window blocks for files which are open by tasks currently in memory and not buffered in the ACP) .b .i -10 BUFFERS###allocated by the half-duplex terminal driver for as-yet incomplete unsolicited input, or completed messages for MCR from either terminal driver. .b .i -10 ERRLOG####an 8-word block allocated by ERRLOG which is undocumented... .b .i -10 DECNET####data structures... .b .i -10 TRANSIENT#some rather transient data structures such as UMR allocation blocks... .b .i -10 OTHERS####for which no documentation could be found... .b .i -10 NON-RSX###data structures from other layered products and software from third party vendors. For example SRF (System Reporting Facility from GEJAC Inc.) uses a lot of pool but its data structures will show up as question marks in the OPA listing. .lm -10 .p 0 The program output will appear on the invoking terminal, unless the task is installed and the LUN re-assigned to something like the lineprinter. .p 0 If the task gets a command-line switch of /F, then it will list the free- segment list described below, otherwise it will skip directly to the map output. .lit Output format: 1st line: number of fragments of pool 2nd line: total words of pool next n lines: addresses and sizes of all free segments in pool next line: total number of words free in pool Map format: .eli In this display, each ASCII character represents a minimum allocatable piece of pool, i.e. 4 bytes. Each line is 64(10) characters, corresponding to 400(8) bytes of pool. .b Free area is shown by -------- .b Used but not identified is shown by ???????? .b .list .le ; .b represents an attachment discriptor block .le ;[An] .b is a specifed-ast control block, where n is the ast type code. .le ; .b is a checkpoint file control block .le ; .b is the task control block for task ...MCR, e.g. .le ; .b is a clock queue control block, where n is the type (see system data structure definitions for types) .le ; which is a login assignment, which of course will not move while the terminal is logged in. .le ; .b the volume control block for device DBn: .le ; .b a file control block found for a file on DBn: .le ; or or .b The first form which contains a device name is a window block for the index file for that disk. The second form containing a task name is a window block for a file currently opened by that task. The third form which contains only '===='s is a window block of either type which is not large enough to hold the device or task name in the display. .le ; .b an interrupt control block for device DV: .le ; .b The data structures for a loadable driver with a loadable database. This may not be quite right if you have a 22-bit system with a DMA device that does not say it is but still allocates space in the SCB for saving the UNIBUS mapping register assignments. There is a real example of such a device (the VERSATEC DMA interface)! It also will not handle data structures which have oddball SCB lengths for other reasons. .le ;
.b is of course a task header for task ...OPA. Note that this is one of the significant pool fragmenters, particularly if you get either MCR or an ACP checkpointed, since the header then will wind up in the middle of pool somewhere when the task comes back in, and since the task never exits (just stops) the header never goes back out. .le ; .b is an I/O packet either currently in use or queued to device DVn: Note that this does not include 'buffered I/O packets' used by the full-duplex terminal driver. Those are pointed to by pointers which are usually in the terminal-driver's address space, and are therefore rather hard to track down. .le ; .b is a saved I/O size packet for QIO optimization. These devils will really fragment your pool, as they get allocated mostly when your system is busy, then hang around later so it's hard to move/get rid of them, except of course by turning off the optimization (we've had to do that to avoid pool problems occurring on a regular basis). .le ;( FCSRES) .b is a PCB for a permanent partition, while (/...OPA) is a subpartition control block, typically for a partition control block for a running task in a system controlled partition. A subpartition control block for a driver is (/ ZB: ), while (+NT.DL ) is a dynamic or PLAS region. .le ; .b is an example of a task invoked as an external MCR function (i.e. JNK for a task called ...JNK) which hasn't gotten around to doing a GMCR$. This structure may stay until the task exits, so you should remember to to a GMCR$ for any task which will be invoked as an external MCR function and which will be active for awhile, even if it doesn't need to get any information from the command line. .els .rm 72 .tp 41 .p 0 A sample run might look like: .lit OPA /F Number of free pool fragments: = 17. Size of pool in words : = 8940. Free Segment List ----------------- 055064-055067 2. 055234-055237 2. 055430-055437 4. . . . 070634-071753 296. 072004-071753 4178. Total free words in pool : = 4652. Pool Map 0-------40------100-----140-----200-----240-----300-----340----- 053400: 054000: --(/ TM: )(/...PSZ)---< 055000: A>---(/ PL: )-------- 055400: -[A4]---------------????????
------(+MYPLAS)------- 072000: ------------------------------------------- 072400: ------------------------------------------------< 073000: PKT OPT>----------------------------------------------- . . . 117000: -----------------( SHFPAR)
( TKNPAR)
( LDRPAR) .eli .rm 71 Note that in general the stuff at the top of pool is put there by VMR, which incidentally from this program show that it does a terrible job by not filling any holes created by removing tasks, for example. .p 0 Keep in mind that it will never be possible to identify all areas of pool usage, since privileged tasks and drivers may take blocks out of pool which are not referred to by any standard data structures. Also some structures are pointed to only by things in the task headers, and if the task is checkpointed there is no way to find them. A good example is window blocks for files opened by various active tasks.