OPA - A PRIVILEGED TASK TO DISPLAY A SNAPSHOT MAP OF THE CURRENT CONTENTS OF POOL!!!! (for RSX-11MPlus V.1) AS MODIFIED FOR MPLUS with accounting - Kitty Bethe 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. It catches its own odd address or memory protect traps, and reports them rather than causing a system crash. 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. It does, however, seem to work well on our 11/70 system, and has given us a good deal of insight into what fragments and/or gobbles up pool. The program output will appear on the invoking terminal; however LOG can be used to run it in order to get a copy on disk (LOG OPA.LOG/TI=TI:) If the task gets a command-line switch of /F, then it will list the free- segment list described below, after the task accounting output and before the map output. Output format: The output is in 3 parts: - active task pool usage summary - free segment list (optional) - visual map of pool An example of output from our system is at the end of this document, a more complex one can be found in OPA.LOG in this UIC. A description of each part of the output follows. Active task pool usage summary Each active task is listed along with its header size (0 if checkpted), the number of open files it has (window blocks), the number of outstanding QIOs, the number of receive (data or by ref) packets queued to it, the number of clock queue entries, the number of attachments it has ( one for each library, common, dynamic common, and one to itself if it is fixed), the number of other miscellaneous bytes charged to it are from specified asts, ast completions, parent/offspring blocks (charged to offspring), and pcb vectors (these could be separated out in a future version). The total bytes a task is using in pool include its PCB and TCB as well as the previous items. Note that all numbers are decimal and the sizes for the data structures are included in the header line. Free segment List 1st line: # 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 # words free in pool Visual Map of Pool 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 ???????? The following structures are grouped alphabetically within delimeter class: @ is a common PCB vector for an installed task [ASn] is a specifed-ast control block, where n is the ast type code. [...] is some other ast control block (completion ast) [BIO..TT:] is the ast control block for terminal buffered I/O [CT] is a common task image PCB [CQn] is a clock queue control block, where n is the type (see system data structure definitions for types) [FDX..TT:] is an ast control block from the full duplex tt driver [+taskname+] a receive by reference queue packet for the task "taskname" [*taskname*] a receive data packet (primary pool portion) for "taskname" *A* represents an attachment discriptor block *U* represents a UMR allocation block *W* represents a wait for UMR allocation block *x* is a logical assignment control block, where x is the type (global asn is type 0). The most interesting from the point of pool fragmentation is */* which is a login assignment, which of course will not move while the terminal is logged in. !W the primary pool portion of a window block for a file !M is a mount control block ^taskname is an offspring control block where the parent task is taskname. (_FCSRES) is a PCB for a permanent partition, while (>...OPA) is a subpartition control block for an active task, (=F11ACP) is a fixed task. A subpartition control block for a driver is ( ZB: ), while (!F4PFSL) is a dynamic or PLAS region, and (+...EDI) is the read only part of a multi-user task. Non-memory resident installed commons and libraries have PCBs also, these are marked as ($FCSRES) - checkpointed tasks have PCBs also, these are marked as (-HRC...). is a checkpoint file control block The data structures for a loadable driver with a loadable database. It will not handle data structures which have oddball SCB lengths for some reason. a file control block found for the index file on DBn:
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. is an I/O packet waiting for input from TTnn: is an I/O packet either currently in use or queued to device DVn: 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 will stay around until the task exits, so you should remember to do 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. is an I/O packet waiting for output to finish on TTnn: 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. is the task control block for task ...MCR, e.g. is a ucb extension block for TTnn that has overflowed from terminal pool into primary pool the volume control block for device DBn: 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 ????????. 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. 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. ORIGINAL AUTHOR: MPLUS version with task accounting: Jim Neeland Kitty Bethe Hughes Research Labs Bankers Trust Company 3011 Malibu Canyon Rd. 130 Liberty St. 37th floor Malibu, California 90265 New York, N.Y. 10006 (213) 456-6411 ext. 333 (212) 775-4190 AN EXAMPLE OF OPA DONE VIA LOG: ANALYSIS OF ACTIVE TASK POOL USAGE: |---------- COUNTS ----------| TASK HEADER OPEN RECV ATTCH NAME SIZE FILES QIOS* PKTS CLQ MENTS OTHER TOTAL (BYTES) (8) (40) (40) (16) (12) (BYTES) (BYTES) ****** 0 3 0 1 1 1 56 252 ...LDR 102 0 0 0 0 1 0 218 MCR... 114 0 0 0 0 1 0 230 F11ACP 138 0 0 0 0 1 0 254 COT... 126 1 0 0 0 1 8 258 HRC... 138 0 0 0 0 1 8 262 BAP0 126 0 0 0 0 1 36 278 VT2 102 0 0 0 0 1 28 246 QMG... 134 1 0 0 1 2 4 290 TTP5 126 0 0 0 0 1 44 286 AT.V2 150 0 0 0 0 2 32 310 LOGT33 114 1 0 0 0 1 8 246 ED2T34 154 3 1 0 0 3 6 364 TT6 174 0 0 0 0 3 24 338 ______________________________________________________________ TOTALS 1698 9 1 1 2 20 254 2480 * THIS ANALYSIS WILL NOT FIND MOST QIOS TO DMC LINES ****** (ANALYSIS FOR INACTIVE TASKS - OPEN FILES ARE INDEX FILES) NUMBER OF INSTALLED INACTIVE TASKS: 45 BYTES USED FOR THEIR TCBS: 3060 POOL MAP: . . . . . . . * . . . . . . . * . . . . . . . * . . . . . . . 034400: @@[ 035000: CT]*A*(=F11ACP)(_FCPPAR)(_SHFPAR)(_TKNPAR)(_DCL 035400: PAR)(_MCRPAR)(_SYSPAR)( TT: )[CT](!TTCOM )( XM: )( NL: )( 036000: VT: )( RD: )( CO: )( MM: )( DB: )(_DRVPAR)*A*(=...LDR) 036400:
(_LDRPAR)(_SECPOL)*0* 037000: *A*[CQ0](>ED2T34)-@[CT]!M!W@@-[+QUEMGR+]!M!W@!W*1*!W!M!W*1*!W*A*-*A*@@*0*!M
(>MCR...)*A*-*/*@[AS5][AS2][AS2]!W*0**0**0**0**A**A 041000: **A*(>COT...)!W!W(>HRC...)
*A* 041400: [AS5]???????[AS2]*0**0**0**0**A*($F4PRES)[CT]@[CT]-
(!F4PFSL)[CT][CQ2]($FCSR 042400: ES)*A**/**/*(>TTP5 )(>QMG...)
??????*A**/* 043400: ^QMG...
^QMG...(>LOGT3 044000: 3)*1**A**1*-(>BAP0 )
[AS5]*A**A*(+...EDI)*/*[CT]-*/*
^LOGT33--[CT]-*1**1*----(!SCRPAR)*0*-- 046000: */*--*0**0**0**0**0**0**0**0**0*--[CT]*0*(+...ED2)*0*--*A*-*0**0**0**0**0**0**0**0**0**0**0**0**0**0**0**0* 047400: *0**0**0**0**0**0**0**0**0**0**0**0**0**0**0**0**0**0**0**0**0*< 050000: DCB+UCB = VT2: %>(>AT.V2 )-----[EF]---(!QUEPAR)
^AT.V2 -------[AS1]------(>VT2 051400: )--------*A*
------- 052000: (>TT6 )[AS3][AS2]*A*-
---(!OD1300)*A*
-------*1*------------------ 053400: ---------------------------------------------------------------- 054000: --------------------------[CT]----------------- 054400: ------------------------------ 055000: (!LINPAR)--------------------------------------------- 055400: ---------------------------------------------------------------- 056000: ---------------------------------------------------------------- (ABOVE REPEATED MANY TIMES) 112400: ---------------------------------------------------------@@-----------------@@@@(!FCSFSL)(!DEVCO 117400: M)(_IO PAR)(_GEN )(_AMTBUF)
AT.>^Z >@