- CWNA Certified Wireless Network Administrator Offi...<http://www.booktube.info/2008/08/cwna-certified-wireless-network.html> - Microsoft Office Project Server 2007 The Complete ...<http://www.booktube.info/2008/08/microsoft-office-project-server-2007.html> - Microsoft Office Access 2007 Forms Reports and Que...<http://www.booktube.info/2008/08/microsoft-office-access-2007-forms.html> - Microsoft Office Project 2007 All in One Desk Refe...<http://www.booktube.info/2008/08/microsoft-office-project-2007-all-in.html> - Microsoft Excel and Access Integration With Micros...<http://www.booktube.info/2008/08/microsoft-excel-and-access-integration.html> - Wiley Office 2007 Bible Jun 2007<http://www.booI guess the question I need to ask is, has anyone else out there experienced >duplicate SMF records even though the dump process experienced no errors, >and the MAN datasets were cleared during each dump. > >The current process is dump each MAN dataset to a monthly JAG tape, >appending it to the end of the tape file every time the dump process runs. >In this shop, during the day, they dump a MAN dataset every 15-20 minutes, >and these are NOT small MAN datasets! Most of the data is DB2 related. And >no, they refuse to change the amount of DB2 data they collect! So that is >not an option... :( > >"I" think I recall that the IFASMFDP program would occasionally pick up >"old" SMF records from a "cleared" MAN dataset if it attempted to dump and >clear that particular MAN dataset again even though it was never written to >since the last dump/clear run... > >If this is true, it could explain the small number of duplicates and the >fact that the duplicates are so far removed from each other in the dumped >file. For example, one "pair" of duplicate application billing records I >found the duplicated record was about 10,000 records or so, further into the >file from the original. Of course, during a sort they would wind up next to >each other... 10,000 records between the two just may be some breadcrumbs >from the previously cleared MAN dataset... > >The fact that we have duplicate SMF data is not in dispute. However, the >CIO wants to know why. I can think of four scenarios, in ascending order of >probability. > >1. The application that writes the SMF records somehow writes the records >twice. Not likely. The possibility brings to mind the number Googolplex. >I found more than one type of duplicate record. >2. The SMF record processing inside the OS is faulty. I cannot believe we >are the first to experience this problem. If this were the problem, IBM >would have fixed it long ago. >3. The MOD'ing of the SMF monthly tape with the new data. Again, not >likely since MOD has been around since before I got into systems almost 3 >decades ago. If this were the problem it would affect more than just SMF >data. >4. IFASMFDP has a bug in it. The most likely. > >Any and all ideas are most welcomed. I must reiterate. there were NO >problems in the dump process. Even though I originally posted this to the >IBM Assembler NG, I received a couple of private emails telling me that my >problem could have been caused by, space problems, reruns, forgetting to >clear the MAN datasets, etc... None of this happened. > >Oh yes..., as of January 1st, we will have a new, refined, bullet-proof SMF >data handling process in place. ;) > > >Gary Green >Never use a 2x4 when a 2x6 will do just as well! >
Suggest you share information stating what technique you used to determine that an SMF record was in fact a duplicate of another SMF record. Do consider that the SMF type 30, for instance, has a "continuation" record, when there is insufficient record-space (LRECL) available to generate each of the job-step DD segments -- mostly typically found with DDCONS(NO). And, I'm surprised that the "invoicing" program/application makes no attempt to remove duplicates within a individual processing run, typically for a day's time-period. I work with a client that has a similar DISP=MOD processing with LPAR SMF dumping in the 8-10 minute interval, during peak business day -- also mostly SMF 101 (DB2) data. Scott Barry SBBWorks, Inc. ---------------------------------------------------------------------- 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
