Classification: Confidential " ACCEPT after about a year of a stable z/OS"
I usually run an accept just prior the next apply cycle. Presumably by that time I have a stable environment (FSVO stable). -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of David Purdy Sent: Tuesday, December 10, 2024 10:17 PM To: [email protected] Subject: SMP/E maintenance best practice for z/OS [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] We have had some spirited internal discussions on SMP/E best practice for applying z/OS maintenance while maintaining an environment for emergency PTFs as neededI upgrade z/OS version on a two year cycleCurrent process for a lot of maintenance with about a year's worth of RSUs - ACCEPT after about a year of a stable z/OS - create a new target and dlib CSI by copying and change relevant definitions of existing CSIs - upload the GIMXSID output, order the latest RSU (recommended on a quarter-end RSU), APPLY to new target CSI pointing to new RES libraries - IPL and test the new RES in the sandbox LPAR - incrementally roll out to development, production, then customer LPARs This allows an emergency/unexpected PTF(s) to be APPLYd to the original RES libraries in the middle of the updated rollout The discussion is - is the ACCEPT necessary as a baseline if you are creating a new target and dlib CSI with its own associated libraries? If unneeded, that is a significant labor savings In the past and infrequently, we encountered PREREQ/COREQ chains that required a lot of RESTOREs, and doing the ACCEPT first avoided that as we remember. This ACCEPT process has been successful in my 13 years at my present company - never gotten in the ditch Another proposed alternative is duplicate all SMP/E libraries and zones and customize, with each maintenance version having its own discrete SMP/E environment, but isn't that the point of one global with multiple target and dlib zones? By our SMP/E configuration, I realize REJECT and ACCEPT will delete the PTF from the PTS making PTFs unavailable to a global zone with multiple target zones, and the final fallback is always restore the backup and start over I reviewed Share and IBM-main, and didn't see any presentations or discussions Thoughts and best practices, anyone?Just looking for an overview Opinion part:Yes, secondary discussions about shorter maintenance intervals is important, but we don't have the labor or IPL schedule to realistically shorten that interval Will being more current on maintenance become an issue?I don't know about your shops, but I have never seen such a high rate of change/new products in my (oy vey) 49 years as a sysprog, and current maintenance will assuredly be an issue soon with some unscheduled PTFs being APPLYd already ThanksDavid ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
