On Fri, May 25, 2018 at 12:39 PM Jesse 1 Robinson <jesse1.robin...@sce.com> wrote:
> I'm sympathetic to the argument that new stuff should be investigated, but > the problem is whether that really happens in practice. We've all met the > sysprog who meticulously codes parameter defaults as a kind of in-your-face > documentation so that 'we will all know' what's happening. Then years later > the defaults change, but the user-coded list does not get updated. Call me > Pollyanna, but I'm willing to trust the latest default. > I'm a bit like that latter. I tend to code all the known parms of any kind of "configuration" member even if all I'm doing is restating the default. One reason, IIRC, was a vendor put out a either some maintenance or a new version which changed the default on something. And after I implemented it, I got a ton of complaints that "the product is broken" because the programmers depended on the previous, now changed, default. > > As for getting inconsistent results, I suspect that SMP/E results can be > influenced by the particular mix of elements being processed in a given > run. That is, applying SYSMOD-A and SYSMOD-B in the same step might uncover > a sinkhole that applying one sysmod or the other alone would not. This > problem is very difficult to detect in development and may require a lot of > customer activity to unearth. > Yeah, I vaguely remember something long ago where I had some such problem. I eventually had to try doing a APPLY S(one-entry) GROUPEXTEND to put things on more slowly. And I had to figure out the "correct" order myself too. I.e. I could apply A, then B and A would succeed & B fail, but if I did apply B, then A -- everything was fine. I really got P.O.'d as I recall. I'm now pretty much too old to bother. That's why our "maintenance" philosophy in the past was to RECEIVE each RSU as it was announced. And do _nothing_ with it; unless there was a specific need. We would simply order an new IPO/CPDO/whatever about every 6 months. And install a completely new z/OS image on new volumes -- new RES, DLIB, & SMP volumes. This is likely easier in our very small, single production image + sandbox, environment. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > -- Once a government places vague notions of public safety and security above the preservation of freedom, a general loss of liberty is sure to follow. GCS Griffin -- Pelaran Alliance -- TFS Guardian (book) Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
