In a message dated 6/6/2007 11:41:09 A.M. Central Daylight Time, [EMAIL PROTECTED] writes:
>>Schramm, Rob wrote: >> When I change the size of the System Trace Table (i.e. TRACE ST,512K), >> where is the storage taken from? >Common Name: Master Trace Table Mapping Macro Alas, the Master Trace Table is not synonymous with the System Trace Table, which was the original question. The Master Trace Table is populated with messages that appear on consoles. The System Trace Table is populated with entries describing various hardware events, and the format of its various entries are documented in the Principles of Operation. Certain hardware events, like Branch or Program Call, automatically create an entry in the processor's Trace Table, but entries are also added via the processor TRACE instruction for events like I/O and SVC interrupts. Whenever an entry is put into the processor's Trace Table, the address of the entry to be used is fetched from that processor's Control Register 12, the entry is built, then Control Register 12 is updated by the length of the entry just built. How big is this processor trace table? From reading the PoOps, I deduce that it must be 4K, since a trace table exception interrupt is created if the next available trace table entry address would be in the next higher 4K of storage. I am guessing that when this interrupt occurs, the program interrupt SLIH moves the contents of this 4K into a much large System Trace Table, which is a wrap-around table, and then resets Control Register 12 to point to the beginning of the 4K storage block containing the hardware Trace Table for that particular processor. The large System Trace Table is the one that shows up in a formatted dump. So from where is the storage obtained? The hardware trace table is only 4K for each processor. It is obtained during NIP, I would assume the real and virtual addresses are saved somewhere (probably in the PSA or PCCA for that processor), and its real address is put into CR12. This 4K block could be gotten from anywhere in central storage, as B. Dissen answered. The System Trace Tables for each processor do not need to be accessed via a real address from CR12, so I assume it is accessed totally via virtual addressing. It can be anywhere, and Rob Schramm says it comes from the Trace Address Space's private storage. So it is not from ECSA. I would expect that the System Trace Tables are all long-term page-fixed for performance reasons, meaning the larger they are then the less real storage is available for the dynamic paging workload. There are other tracing facilities operating inside z/OS; e.g., the Monitor Call trace facility (commonly misnamed GTF, as GTF is but one possible software exploiter of the hardware' Monitor Call trace facility), which is invoked via the Monitor Call instruction which, if tracing is enabled for the type of event being traced, causes a program interrupt which ultimately enters GTF modules to trace that event. Using a program interrupt to effect a trace entry involves much more overhead than the processor TRACE instruction. Then there are component traces. Do not confuse or conflate the various distinct tracing functions. Bill Fairchild Plainfield, IL ************************************** See what's free at http://www.aol.com. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
