On Tue, 6 Feb 2007 16:32:31 -0600, Eric Bielefeld <[EMAIL PROTECTED]> wrote:
>We just made an interesting discovery. Our SMF SID parameter is the same >for our production Lpar and the corrosponding Test Lpar for one of our >boxes. I changed the SID for the Test MVS machine, as that would not >affect the production system. We run two sysplexes, which do not talk to >each other. DASD is all separate. We have a Prod sysplex, and a Test >sysplex. > >My question is, will this affect anything? Is there any program products >that could be affected by changing the SID? I read the whole chapter in >the Init & Tuning Reference, and I didn't see anything that would matter to >us. > The short answer is yes. There could be many or none for ISV. Here are a few I know of, but I can't remember for sure if I really had to re-create all of them or just rename them when I changed the sysid for a system in our test plex a few years back. I do remember that I would never want to do this for a production LPAR. I usually keep very good notes for things like this but for some reason I didn't this time. SYNCSORT history for SYNCDSM(already mentioned) CA-VCSS checkpoint (part of DISPATCH) CA-JOBTRAC ckpt CA-ENF database CA-SYSVIEW syslog index COMPUWARE LMS checkpoint For IBM there are obviously considerations also, but perhaps you already ran into some or all of them. I'm pretty sure I had to re-create my RMF III dsns (not just rename them). There could also be exits in use with hard coded SYSIDs. Not just IBM exits, any exits. Automation code that is shared between LPARs is another thing to review. MICS, MXG, anything that creates specialized reports from that data, etc. The list goes on... (this is why I would never want to do this on a production LPAR!). Someone asked me about doing this in 2003 on search390.com. You can still find my response where they archived all the Q&As at http://expertanswercenter.techtarget.com/ but I will re-post here. Unfortunately this Q&A was also before I actually did it so I'm sure there were things I missed. Q: As I have multiple systems, I would like to change the SYSID. The only reference I could find was in SYS1.IPLPARM (LOADxx)IODF statement but after changing the SYSID here, the following cold start IPL failed. A: The name you found for the IODF statement in LOADxx actually has nothing to do with the SYSNAME in the operating system. It is the system configuration name to use at IPL time that is stored in the IODF file itself. You most likely changed it to a name that did not exist and entered a disabled wait when you tried to IPL the system -- probably a 0B1. Using the SYSNAME as the system configuration name is a convention many shops use, but it is not a requirement. You can change the SYSNAME without changing your LOADxx member. If you really want to change this, you need to use the HCD ISPF application to create a new system configuration. The SYSNAME may be specified in several places on your ADCD system, but it isn't required to be the same everywhere. For example, the SMFID (SID) in your SMFPRMxx member does not have to match the system name, but most shops make them the same. The SYSNAME can actually be up to eight characters long but most shops use a 4 character name because the SMFID can only be four characters. The "true" SYSNAME is specified in IEASYSxx or IEASYMxx. IBM recommends that you specify the system name in IEASYMxx. It's been a long time since I've tried to actually change the system name of an existing system, but here are some places to look in your PARMLIB(s) that may contain the current name: IEASYSxx IEASYMxx SMFPRMxx JES2PARM Some other things I can think of: 1. The system name is probably stored in your SMS configuration so you should add your new system name to the configuration prior to changing it or you will run into problems when you IPL with the new SYSNAME (the ADCD system may be using the SYSPLEX name instead of the system name, but I don't know which way the ADCD system is currently distributed). 2. Unless you do a JES2 cold start, you will get warning messages about adding the new member name to your configuration. You can just let the new name get added if you don't want to perform a JES2 cold start by using the appropriate responses to the WTORs. 3. The system name may be contained in operational data set names like LOGREC, PAGE, or SMF data sets and specified in PARMs or STC JCL by using the &SYSNAME system symbol. You may need to recreate/rename the data sets or hard code the old names in PARMs or JCL. That is all I can think of, but I may be missing something. Good luck! -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html ---------------------------------------------------------------------- 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
