Also make sure you really need all of these SMF records and some software allow to limit the size or records (e.g. SIZE). Often I saw installation with a large number of unneeded SMF records (e.g. TYPE99)
For DB2 V8 you may use ACCUMAC ZPARM to limit the number of SMF TYPE101 records. For CICS 3.1 you may not need the DB2 SMF Type101 for accounting as the DB2 CPU is already in the CICS TYPE110. Do you know you can build a CICS MCT to limit the size of TYPE110. Roland -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Thursday, March 01, 2007 9:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How are you handling high SMF record volume? > >We are running into issues with the volume of SMF records that we need >to process. We create a GDG every day for that day's records. >Occasionaly we run into contention issues during the day but mostly it >hits us at the end of the day when we read the day's records from the >GDG and split the output into various other tapes for specific >functions (accounting, performance, etc). While that job is reading the >many tapes created during the day, the GDG base is locked so our dump >jobs are forced to wait which eventually causes lost SMF data. Has >anyone else run into this problem? How are other shops handling high >SMF volumes? Here is what we do on one of our larger LPARs for example: 6 SMF MANx dsns IEFU29 triggers SMFDUMP job at switch time to DASD or virtual tape GDG. SMFDUMP job runs in "STCHI" which is IMP=2, but we have very little imp=1 work. So other than SYSSTC IMP=2 is equal with onlines. If I had to, I would change it to SYSSTC. Some LPARs go to disk, but some of the larger ones go to virtual tape. Just after midnight we run the "CBIPO" SMFDUMP program. That makes sure all MANx dsns have been dumped and causes one last switch and dumps that also. We then run the job to combine all the dumped GDGs to single daily tape runs in a "hot batch" service class. But at that time of night there are spare cycles anyway. If switches happen during the combine job... the SMFDUMP job does have to wait, but we catch up after the combine job is done. SMFPRMxx is set up with BUFSIZMAX(1024M) to help prevent loss of data if things do get backed up. ---------------------------------------------------------------------- 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
