>> And, many disciplines, such as capacity planning. >> Example: type 30, type 110 do not have serial numbers, LPAR names, etc. >> Type 72, 74, etc don't have them either.
>So what? I don't see any relationship to 110 or 30. Then obviously you've never done Capacity Planning, Performance Management or Chargeback. Without going into details, a standard methodology of allocating CPU usage for planning purposes is merging type 70, 72, and 30 (interval). Only one of those has hardware details. Simply put, 70 gives me the detail of overall usage, 72 allows for the breakdown by workload (with capture ratios applied), and 30 allows me to determine which application within workload. Type 110 allows for a merging of CICS transactions (for this example), along with other details. 74 gives me the I/O component. With other records (I've only given a few examples), I can end up with a profile vector, of CPU, LPAR, Workload, application, I/O, and other details. Yes, you could re-write all the canned, homegrown, vendor, and other code to do something else. But, these tools all know about the existing SMFID and won't work without unique IDs. So, the choice is simple. Differing SMFIDs, and existing/working tools, chaos, or don't do Capacity Planning with SMF. As far as NJE is concerned, we used to get error messages whenever the SMFID of the sending system wasn't in a user table, and the acknowledgement wasn't able to be transmitted back. If this is still the case, which I don't know since I haven't seen it in years -- meaning people have been keeping it up to date or it's changed, then duplicate IDs would cause problems. I think that the fact there are other reasons for duplicate IDs negates the issue with SCRT. - Too busy driving to stop for gas! ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
