Art I think the only way to make progress toward simplification and standardization is creating automated tools that function similar to the IBM healthchecker. In a large data center, it can be a full time job because it has two components, removing exceptions found in the system and preventing new exceptions from being installed. Complicating this effort is OEM MVS software that has rigid install procedures that usually do not conform to the standards useful in maintaining IBM products. If software management is siloed into autonomous groups with no institutionalized methodology of enforcing cooperation, it becomes more difficult.
Having gone through the standardization process that took place at the Auburn Hills data center, and standardizing the production software environment at Kraft, I know it is possible if the leadership is steadfast. I believe simplification, standardization and automation allows quicker and easier implementation and quicker resolution of processing exceptions and so is worth the effort. I am betting you see it as I do. My point is that I sympathize with what you have inherited, and I think you captured the essence of the situation with this phrase: "*dataset names created before I knew what a computer was*" I hope you have a Merry Christmas. On Wed, Dec 17, 2008 at 8:42 AM, Arthur Gutowski <aguto...@ford.com> wrote: > On Wed, 17 Dec 2008 08:27:43 -0500, Jousma, David > <david.jou...@53.com> wrote: > > >I have to agree, why in this day in age, would you want to create the > >mess of consolidated datasets..... > > > >Converting to LIBDEF is a simple matter. > > Easy for you to say. I'm in the process of converting dozens of > infrastructure > users over to LIBDEF for our applications. We can eliminate some merged > datasets, but not all. > > I have 30 years of evolution to overcome, thousands of users to support on > 25+ z/OS instances, and each major application group has their own flavor > of > an allocation Clist, bastardized from some Clist that some techie wrote > with "system" dataset names created before I knew what a computer was, > each with it's own primary option menu stuffed in some panel library I > can't > even open for READ. > > This shop used to copy outside of ServerPac. At least now we manage the > beast with SMP/E. > > With business as bad as it is, I can little afford to disrupt it further > and cost > thousands to millions of dollars per hour when someone can't get to their > data > because I broke their ability to logon. Many of our end users don't even > know they are logging into a mainframe. An applications rep (or their > predecessor) hands them a script and says, "Here, follow this recipe once a > week." > > LIBDEF is the Nerdvana of TSO/E & ISPF support, but the summit is barely > visible from where I stand today. It will be a long time before I can > twist each > application owner's arm into building off a standard base and take > responsibility for their own, especially with outsourcing and head-cutting > becoming the norm, rather than the exception. If only I could start from > scratch... I, too, could be just like Tom (now, I have attended his SHARE > pitches, found them highly useful, am trying to apply the knowledge here, > and > always appreciated his time answering my pedantic inquiries, so Thank You). > > Regards, > Art Gutowski > Ford Motor Company > > ---------------------------------------------------------------------- > 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 > -- Glen J. Gasior (630) 712-2104 Chicago, Illinois 60611 "Leadership that improves the process of change" ---------------------------------------------------------------------- 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
