Managing Datacom SYSOUT Spool Datasets
Article ID: 373397
Updated On:
Products
Issue/Introduction
During a recent problem, the MUF produced a lot of dumps, and I see these messages in the MUF log:
06.15.28 JOB10444 MYMUFP1:DB02405I - PXX START MYCICSRG 49122 94(086) REDLE-###-XXX D-45 TRNS???? 03230
06.15.28 JOB10444 $HASP375 MYMUFP1 ESTIMATE EXCEEDED BY 22,000,000 LINES 3 % SPOOL
06.15.29 JOB10444 MYMUFP1:DB02401W - PXXML01 AREA FULL
My MUF options has
DB01900I - SYSOUT X,15M,1M,1M,2M,2M CLASS,ML,CBS,SQL,DD,DST
So I issued /F MYMUFP1,COMM CLRML and received:
14.22.28 JOB10444 MYMUFP1:DB01311I - COMM CLRML
14.22.28 JOB10444 MYMUFP1:DB01335I - CONSOLE SCHEDULED - COMM CLRML
14.22.28 JOB10444 MYMUFP1:DB02402I - PXXML AREA RESET
However, when I go into SDSF and display my output files under that job I see:
NP DDNAME StepName ProcStep DSID Owner C Dest Rec-Cnt Page-Cnt Byte-Cnt CC
JESJCLIN 1 ZEKE P 13 756 1
JESMSGLG JES2 2 ZEKE P 2M 190M 1
JESJCL JES2 3 ZEKE P 153 10,429 1
JESYSMSG JES2 4 ZEKE P 597 23,878 1
$INTTEXT JES2 5 ZEKE A 110 3,441 1
EVENTLOG JES2 8 ZEKE A 0 1
DD@MSG JS0010 V15R1L02 106 ZEKE P 5M 384M 1
SYSPRINT JS0010 V15R1L02 107 ZEKE P 0 1
PXXML01 JS0010 V15R1L02 114 ZEKE X LOCAL 15M 1B 1
PXXCBS01 JS0010 V15R1L02 115 ZEKE P 0 1
PXXSQL01 JS0010 V15R1L02 116 ZEKE P 0 1
PXXDD01 JS0010 V15R1L02 117 ZEKE P 0 1
PXXDST01 JS0010 V15R1L02 118 ZEKE P 0 1
RESTART JS0010 V15R1L02 119 ZEKE P 24 1 1,746 1
PXXML02 JS0010 V15R1L02 120 ZEKE P 0 1
Why am I still seeing 15M records in PXXML01? If I select that file, it still shows me the dumps.
How do I clear the PXXML01 so that I am prepared to catch more dumps???
Resolution
First, as you have seen, the statistics and dump data is now written to multiple spool files instead of a single DASD-based PS file. This provides more opportunities for managing the output by using the various spool capabilities, like multiple destinations, different output writers, etc.
This also means that the presentation within the overall job output is different. When the MUF starts, there are five different spool files to handle the data for Master List and PXX dumps, CBS diagnostics, SQL traces and diagnostics, Datadictionary traces and messages, and messages related to Datacom Dynamic System Tables processing. Having these broken out makes it easier to find specific data about CBS traces, for example, without having to dump the entire PXX. When the MUF starts, these five areas are given the suffix number "01" as they are the first of the spool files for that classification. Hence, you will see PXXML01, PXXCBS01, PXXDD01, PXXSQL01, and PXXDST01.
Now in your MUF Startup Options, you have given these spool files each a specific line limit on the SYSOUT option (15M,1M,1M,2M,2M), after which no more data will be captured. That is what happened to your PXXML01 spool file. Once it reached 15M records, no more data would be written there, and you will see the "AREA FULL" message.
In prior versions, you would issue a COMM CLRPXX command to reset the PXX to the unused state, so you could then continue writing to the file. Now, you have the ability to manage each spool file separately. Instead of the COMM CLRPXX, you would use COMM CLRML, CLRCBS, CLRSQL, CLRDD, or CLRDST to reset the active PXXML##, PXXCBS##, PXXSQL##, PXXDD##, or PXXDST## spool files that have become full, or to separate the output for other uses.
When you issue this CLRxxx command, the currently active spool file is closed, released and spun off for processing. In its place, a new file with the next suffix is opened. You can see this in the DD list from the MUF you have shown me. Here is the relevant part of that display:
NP DDNAME StepName ProcStep DSID Owner C Dest Rec-Cnt Page-Cnt Byte-Cnt CC
PXXML01 JS0010 V15R1L02 114 ZEKE X LOCAL 15M 1B 1
PXXCBS01 JS0010 V15R1L02 115 ZEKE P 0 1
PXXSQL01 JS0010 V15R1L02 116 ZEKE P 0 1
PXXDD01 JS0010 V15R1L02 117 ZEKE P 0 1
PXXDST01 JS0010 V15R1L02 118 ZEKE P 0 1
PXXML02 JS0010 V15R1L02 120 ZEKE P 0 1
As you can see above in yellow, the original PXXML01 spool file has a Dest of LOCAL and a Sysout Class of X, since it has been closed and released. Now, the active file is PXXML02 (shown in green), which was created when you ran the COMM CLRML command at 14.22. The PXXxxx files are allocated dynamically, and managed by the MUF through these commands and by JES when they reach their limit. It is important to ensure you are using the proper Sysout Class so that these files are retained with the rest of the MUF output, or so the spool files are written to your output management tool for future access.
There is no need to do anything further here, as PXXML01 is closed and PXXML02 is open and active. One change that some customers make is to have their automation issue the appropriate CLRxxx command when the "XXXX AREA FULL" is issued, so that data loss is minimized. In your case, the excessive number of dumps that were created caused the PXXML01 file to fill up; normally I expect that this is not a problem.
Additional Information
For more information about this processing, please see the Datacom Core documentation for the SYSOUT MUF Startup Option, the COMM CLRxxx command to close the current spool file and open a new one, and the section that explains a methodology for managing this PXX data.
As always, please contact Broadcom support for Datacom if you have further questions.
Feedback
