POOLFL - A PRIVILEGED TASK TO DISPLAY A SNAPSHOT MAP OF THE CURRENT CONTENTS OF POOL!!!! (currently for version 3.1 only) NOTE WELL: This program is sufficiently valuable to all system managers/ programmers who have pool space problems that it is (to my mind) well worth the risk of using. However, it is necessary while this program is scanning through pool to be on the system stack. Therefore if it encounters any data structure which it misinterprets or which has been corrupted, it is highly likely to cause a system crash with an odd address trap!!! It does, however, seem to work well on both our 11/34 and 11/70 systems, and has given us a good deal of insight into what fragments and/or gobbles up pool. The only known bug at this time is that it will crash your system if there are dynamic regions (created via the PLAS directives) existing at the time the program is run. The program will identify about 90% of the data structures kept in pool, in its current version. Remaining known structures not identified are: AST control blocks (see version 3.2 CDA manual description of same to see why I haven't yet tracked them down). 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 crashes). ACTIVE I/O packets (that is relatively easy, having already found all SCB's, but I haven't done it yet). FCB's for other than INDEXF.SYS (I need to track through all the luns of all active task headers). BUFFERS allocated by the terminal driver for as-yet incomplete unsolicited input. OTHERS which I don't remember at the moment. The program output will appear on the invoking terminal, unless the task is installed and the LUN reassigned to something like the lineprinter. Output format: 1st line: # of fragment of pool 2nd line: total words of pool next n lines: addresses and sizes of all free segments in pool next line: total # words free in pool Then the good part: 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. Free area is shown by -------- Used but not identified is shown by UUUUUUUU represents an attachment discriptor block is the task control block for task ...MCR, e.g. is a clock queue control block, where n is the type (see system data structure definitions for types) which is a login assignment, which of course will not move while the terminal is logged in. the volume control block for device DBn: Note that this is the only data structure which I know has changed enough for version 3.2 that source code change is necessary (the new VCB contains 12 bytes more to save the volume name). a file control block found for a file on DBn: Note that at the moment that is usually only for INDEXF.SYS, unless the ACP is a small one that keeps all its FCB's in pool. (You can't trace the FCB chain through the ACP internal storage in a reasonable way). a window block for a file, again (as for the FCB's) mostly for INDEXF.SYS an interrupt control block for device DV: The program might get a bit confused as to who owns these, since it is hard without reading the device driver .STB files to find out which is full-duplex, thus the program makes an intellligent guess. 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)!
is of course a task header for task POOLFL. 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. 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). ( FCSRES) is a PCB for a permanent partition, while (/POOLFL) is a subpartition control block, typically for the partition control block for a running task in a system controlled partition. A sub partition control block for a driver is (/ ZB: ) is an example of a task invoked as an external MCR function (i.e. RMD for a task called ...RMD) 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 awile, even if it doesn't need to get any information from the command line. A sample output might look like: 17. 8940. 055064-055067 2. 055234-055237 2. 055430-055437 4. . . . 070634-071753 296. 072004-071753 4178. 4652. --(/ TM: )--(/ VT: )
(/...PSZ)---< A>-(/ PL: )-------- --------------------UUUUUUUU
----------------------------------- ---------------------------------------------------------------- ------------------------------------------------< PKT OPT>----------------------------------------------- . . . )( GEN )( CD )( F4PRES)( FCSRES)( TERCOM)( MUXCOM)( REJLIB) ( FCSLIB)(DVRPAR)(FCPPAR)( TKNPAR)( MCRPAR)( SYSPAR) Note that in general the stuff at the top of pool is put there by VMR, which incidentally from this program I learned does a terrible job by not filling any holes created by removing tasks, for example. Comments and suggestion are welcome, but please don't complain if your system crashes. Hopefully I or others will get around to doing a few more data structures,and there will be fewer areas labelled UUUUUUUU. Keep in mind that it will never be possible to do all areas, since privileged tasks and drivers may take blocks out of pool which are not referred to by any standard data structures. Jim Neeland Hughes Research Labs 3011 Malibu Canyon Rd. Malibu, California 90265 (213) 456-6411 ext. 333