Re: Servicing z/OSMF (Was: A Warning to Anyone Servicing z/OSMF - SOLVED!)
On 7/16/2011 8:28 PM, Greg Dorner wrote: I've experienced some strange install/maintenance scenarios with z/OSMF, but have managed so far to get it all put back together again. I went from z/OS 1.10 to 1.12 with z/OSMF, which was a bit tricky with all the config file changes, but I haven't had any problems with PTF's. You just need to NOT take the holddata literally. They give you the parameters to run the shell script. but the user controlled variables, like config name and location must be replaced with those required for your environment. The doc in the hold could be worded much better. The primary intent of my post was to ascertain, from IBM-MAIN participants with off-platform WAS maintenance experience, whether similar manual, post-service requirements exist on other platforms or if this need is a z/OS idiosyncrasy... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Servicing z/OSMF (Was: A Warning to Anyone Servicing z/OSMF - SOLVED!)
No surprises this time. The following ++HOLD instructions were followed and all is well... We have _only one_ WAS application (z/OSMF) and we had to manually run two scripts. That makes me wonder: 1) If we had twenty WAS applications, would we need to manually run twenty-one scripts? 2) Are similar post-service steps required on other platforms when servicing WAS and WAS applications? Or is this a z/OS idiosyncrasy? Websphere OEM To apply service for the IBM WebSphere Application Server OEM for z/OS V7.0, perform the following steps: 1. Stop IBM IBM WebSphere Application Server OEM for z/OS V7.0 if it is running. 2. Roll service into place. 3. Using a privileged user id, before starting each WebSphere Application Server OEM for z/OS V7.0 instance, run the fixAllGroupPerms.sh script from the WebSphere Application Server OEM for z/OS V7.0 product file system, specifying the WebSphere Application Server OEM for z/OS instance WAS_HOME directory. For example: cd /usr/lpp/zWebSphereOEM/V7R0/bin ./fixAllGroupPerms.sh /zWebSphereOEM/V7R0/condfig1/AppServer This script will ensure that the post-installer can correctly update files in the profile configuration. This should only be necessary once per IBM WebSphere Application Server OEM for z/OS V7.0 instance. 4. Start IBM WebSphere Application Server OEM for z/OS V7.0. /Websphere OEM z/OSMF If z/OSMF has already been configured, then it will be necessary to redeploy z/OSMF. To redeploy the z/OSMF, perform the following steps: 1. Stop the appropriate IBM WebSphere Application Server OEM Edition for z/OS if it is running. 2. Run the following script from the z/OSMF Administrator ID. (ZOSMFAD, by default) Specify the next 2 lines on a single command line. /usr/lpp/zosmf/V1R12/bin/izusetup.sh -file /etc/zosmf/izuconfig1.cfg -service 3. Restart IBM WebSphere Application Server OEM Edition for z/OS. In this example, izuconfig1.cfg is the name of the configuration file used to save your configuration settings. If you installed z/OSMF as part of a ServerPac order, the configuration file is named serverpac.cfg. The configuration file is stored, by default, in the /etc/zosmf directory.). /z/OSMF -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: Servicing z/OSMF (Was: A Warning to Anyone Servicing z/OSMF - SOLVED!)
I've experienced some strange install/maintenance scenarios with z/OSMF, but have managed so far to get it all put back together again. I went from z/OS 1.10 to 1.12 with z/OSMF, which was a bit tricky with all the config file changes, but I haven't had any problems with PTF's. You just need to NOT take the holddata literally. They give you the parameters to run the shell script. but the user controlled variables, like config name and location must be replaced with those required for your environment. The doc in the hold could be worded much better. -- 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
Re: A Warning to Anyone Servicing z/OSMF - SOLVED!
On 5/22/2011 7:55 PM, Edward Jaffe wrote: A few months ago, we brought up z/OSMF under z/OS 1.12. Applying service this weekend made it totally unusable. It turns out our configuration files have been wiped out! OK. Thankfully, our configuration files were not lost. Rather, some ominous looking messages made it appear that way and some good ol' fashioned conclusion jumping did the rest. First, WAS OEM would not come up. The second step (the 'Multi-Product PTF Post-Installer') failed with RC=4095. It writes STDERR and STDOUT to /zWebSphereOEM/V7R0/config1/BBNBASE.BBNNODE.BBNS001.HOME/properties/service/logs/applyPTF.out which had as its last line: FSUM1004 Cannot change to directory /var/zWebSphereOEM/V7R0/home/WSCFG1 Second, when we attempted to redeploy z/OSMF using the '/usr/lpp/zosmf/V1R12/bin/izusetup.sh -file /etc/zosmf/izuconfig1.cfg -service' command shown in the ACTION HOLD, it failed with: IZUG207E: File /etc/zosmf/izuconfig1.cfg does not exist. It appeared we had lost our configuration information. In reality, we just needed to run the z/OSMF redeployment script with the correct parameters for our installation. The last line in that applyPTF.out file is now: No post install service pending, no action taken. Tue May 31 12:48:23 PDT 2011 WAS OEM initializes and z/OSMF is accessible again. Whew! Apologies for the false alarm--especially to poor Anuja Deedwaniya whose eyes were probably as big as saucers when she first saw my post! :-[ That's what happens when you let part-time sysprogs do a full-time sysprog's job. ;-) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: A Warning to Anyone Servicing z/OSMF - SOLVED!
Hi Ed, Thanks for the update. I am so glad this worked out for you. Take care! -Anuja Deedwaniya -- 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
Re: A Warning to Anyone Servicing z/OSMF
Hi Ed, The runtime or product (read only) hfs is managed via SMPE, whereas the config hfs is not managed through SMPE. Or it is not supposed to be. Applying service to the WAS OEM runtime hfs should not destroy the config hfs or require redeploy of z/OSMF. It looks like that you applied both WAS OEM and z/OSMF maintenance. The HOLDDATA for the z/OSMF PTFs will instruct that the affected applications need to be redeployed via the script as a post SMPE install step. The z/OSMF service should be activated 'after' any WASOEM service update is completed. I would like to work with you to understand what could have happened, as typically service upgrade in WASOEM or z/OSMF should not wipe out your configuration files or require you to reconfigure. Take care! Regards, Anuja Deedwaniya -- 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
Re: A Warning to Anyone Servicing z/OSMF
On 5/24/2011 9:52 AM, Anuja Deedwaniya wrote: I would like to work with you to understand what could have happened, as typically service upgrade in WASOEM or z/OSMF should not wipe out your configuration files or require you to reconfigure. I re-read the three ACTION HOLDs in our SMP/E run and two of them say to 'redeploy z/OSMF' after the APPLY using a shell script. They are UK62012 and UK62872. The other ACTION HOLD was in UK62090 for WAS OEM. It doesn't actually say we should save/restore the configuration per se. It says we should make a copy of [our] product file system data set (whatever that is) and perform the APPLY against that. We didn't do that copy step, so maybe something got corrupted? Running /usr/lpp/zosmf/V1R12/bin/izusetup.sh -file /etc/zosmf/izuconfig1.cfg -service under ZOFMFAD: IZUG207E: File /etc/zosmf/izuconfig1.cfg does not exist. IZUG211E: Script /usr/lpp/zosmf/V1R12/bin/izusetup.sh encountered errors: exiting script. Sure enough, that file doesn't exist. Starting WAS OEM: IEF142I BBNS001 BBNS001 - STEP WAS EXECUTED - COND CODE IEF142I BBNS001 - STEP WAS EXECUTED - COND CODE 4095 IEF272I BBNS001 BBNS001 - STEP WAS NOT EXECUTED. IEF272I BBNS001 BBNS001 - STEP WAS NOT EXECUTED. I just assumed this behavior was WAD. Since you're surprised by this, I'll do some digging when I get a chance and I'll let you know (via private email) what I find. Thanks! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: A Warning to Anyone Servicing z/OSMF
On Tue, 24 May 2011 17:53:26 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: ..snip.. I re-read the three ACTION HOLDs in our SMP/E run and two of them say to 'redeploy z/OSMF' after the APPLY using a shell script. They are UK62012 and UK62872. The other ACTION HOLD was in UK62090 for WAS OEM. ..snip Ed, FYI - I have managed to successfully install the above listed ptfs to our z/OS 1.12 zOS MF environment without any problems. Since installing those ptfs, they have been subsequently sup'd: UK62012 - UK64892 UK62872 - UK66066 UK62090 - UK66412 . Roger -- 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
Re: A Warning to Anyone Servicing z/OSMF
Ed, Do you have the specific ptf that had that hold? I ask because I just ran an applycheck for everything for wasoem and z/osmf, and only got one hold, on UK66412. It could be that I'm at a higher level than you, but I just want to verify. Thanks! MA -- 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
Re: A Warning to Anyone Servicing z/OSMF
Ed and Barbara, Yes, this is one of those hidden features you get with updating WASOEM or z/OSMF. Besides having SMPPTS entries that are larger than those for JAVA, applying then will very nicely wipe out your configuration files. When applying this maintenance, I create a clone filesystem to hold all the config files. Then I can just pull them back over after the apply is complete and I have a chance to see what has happened to the target filesystem. Always fun when dealing with products that don't fully understand how SMPE can work for you. Everyone is trying to use the One size fits all format in a tailored world. Doesn't really work too good does it? Brad S. Carson Manager Mainframe Technical Support Laboratory Corporation of America Phone: 336-436-8294 Fax: 336-436-1033 email: cars...@labcorp.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Monday, May 23, 2011 1:09 AM To: IBM-MAIN@bama.ua.edu Subject: Re: A Warning to Anyone Servicing z/OSMF A few months ago, we brought up z/OSMF under z/OS 1.12. Applying service this weekend made it totally unusable. It turns out our configuration files have been wiped out! ... I'm not sure if this is what I would necessarily call 'progress', but it's definitely a brave new world out there. Beware! Uh-oh - is that Barbara I hear charging in from stage calling out I tried to warn you all ... ? :-) No it's not. We haven't installed it, anyway. But I am really NOT surprised, given how I hear my colleagues complain about WAS deploys. I even went through a 2 day seminar on deploying this stuff under zLinux, and then I 'got' why z/OSMF deploy is a two-stage process. I consider it too awkward, anyway. Given that I knew WAS back when it was called 'Component Broken' (by those that heard about it - OS/390 R6 days), I am waiting for the day when they go back to replacing the full product every time a single ptf needs to go in (and when they ditch SMP/E :-) ). Now *THAT* will be fun for z/OS! NOT. I do appreciate Eds warning, though, and will gleefully relate it to anyone here who might have wanted to 'test' z/OSMF, despite my dire warnigns :-) Barbara -- 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 -This e-mail and any attachments may contain CONFIDENTIAL information, including PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or disclosure of this information is STRICTLY PROHIBITED; you are requested to delete this e-mail and any attachments, notify the sender immediately, and notify the LabCorp Privacy Officer at privacyoffi...@labcorp.com or call (877) 23-HIPAA / (877) 234-4722. -- 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
Re: A Warning to Anyone Servicing z/OSMF
Since it appears that the config files must live in SMPE managed filesystems, it would seem like you need to make your config files a usermod so that they are not lost.I already do something like this for the required JAVA filesystem changes that are necessary for tape encryption. Usermod would then just reload your config files after the application of the maintenance. Only other alternative would be to externalize the config files to /etc, if that is even possible. I am not running z/OSMF yet. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Carson, Brad Sent: Monday, May 23, 2011 9:17 AM To: IBM-MAIN@bama.ua.edu Subject: Re: A Warning to Anyone Servicing z/OSMF Ed and Barbara, Yes, this is one of those hidden features you get with updating WASOEM or z/OSMF. Besides having SMPPTS entries that are larger than those for JAVA, applying then will very nicely wipe out your configuration files. When applying this maintenance, I create a clone filesystem to hold all the config files. Then I can just pull them back over after the apply is complete and I have a chance to see what has happened to the target filesystem. Always fun when dealing with products that don't fully understand how SMPE can work for you. Everyone is trying to use the One size fits all format in a tailored world. Doesn't really work too good does it? Brad S. Carson Manager Mainframe Technical Support Laboratory Corporation of America Phone: 336-436-8294 Fax: 336-436-1033 email: cars...@labcorp.com This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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
Re: A Warning to Anyone Servicing z/OSMF
On 5/23/2011 5:29 AM, Mary Anne Matyaz wrote: Ed, Do you have the specific ptf that had that hold? I ask because I just ran an applycheck for everything for wasoem and z/osmf, and only got one hold, on UK66412. It could be that I'm at a higher level than you, but I just want to verify. You're probably ahead of me. I installed the following three PTFs: UK62090 UK62012 UK62872 -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: A Warning to Anyone Servicing z/OSMF
Uh-oh - is that Barbara I hear charging in from stage calling out I tried to warn you all ... ? :-) Shane ... On Sun, 22 May 2011 19:55:03 -0700 Edward Jaffe wrote: A few months ago, we brought up z/OSMF under z/OS 1.12. Applying service this weekend made it totally unusable. It turns out our configuration files have been wiped out! ... I'm not sure if this is what I would necessarily call 'progress', but it's definitely a brave new world out there. Beware! -- 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
Re: A Warning to Anyone Servicing z/OSMF
A few months ago, we brought up z/OSMF under z/OS 1.12. Applying service this weekend made it totally unusable. It turns out our configuration files have been wiped out! ... I'm not sure if this is what I would necessarily call 'progress', but it's definitely a brave new world out there. Beware! Uh-oh - is that Barbara I hear charging in from stage calling out I tried to warn you all ... ? :-) No it's not. We haven't installed it, anyway. But I am really NOT surprised, given how I hear my colleagues complain about WAS deploys. I even went through a 2 day seminar on deploying this stuff under zLinux, and then I 'got' why z/OSMF deploy is a two-stage process. I consider it too awkward, anyway. Given that I knew WAS back when it was called 'Component Broken' (by those that heard about it - OS/390 R6 days), I am waiting for the day when they go back to replacing the full product every time a single ptf needs to go in (and when they ditch SMP/E :-) ). Now *THAT* will be fun for z/OS! NOT. I do appreciate Eds warning, though, and will gleefully relate it to anyone here who might have wanted to 'test' z/OSMF, despite my dire warnigns :-) Barbara -- 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
