Barry,
Actually, for the SCRT report, the reports need all Lpars for each CPU. The
prod and the test lpar both run on the same machine, and the SCRT report had
some flaky messages and wouldn't give the proper results. I'm not doing the
SCRT stuff, so I never really saw what the error message was.
Shortly before I left for home, I did learn of one product that was affected
by the SMF SID change. Syncsort has a proc that gets started that said it
couldn't continue because the history dataset had the wrong SID. Tomorrow
I'll have to reallocate a new history dataset. I remember that from my last
job, but its been a while.
Eric Bielefeld
Sr. z/OS Systems Programmer
Lands End
Dodgeville, Wisconsin
414-475-7434
----- Original Message -----
From: "Barry Merrill" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@BAMA.UA.EDU>
Sent: Tuesday, February 06, 2007 5:45 PM
Subject: Re: Changing the SMF SID Parameter
While IBM added the "SYSTEM NAME FROM IEASYSXX" SMF70SNM field
back in 1994, it was only last year that I observed in data
that if you have the same SYSTEM name in two LPARs in a SYSPLEX,
that SMF70SNM must be added to the "BY" variables to segregate
RMF data, and thus last year, all of the MXG RMF sorting was
revised to use SYSPLEX SYSTEM SYSNAME to protect for the
same SYSTEM name in the same SYSPLEX.
In your case, as long as your reports are at least
BY SYSPLEX SYSTEM, you are safe since they are in
different SYSPLEXes.
Barry
----------------------------------------------------------------------
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
