> On Friday, August 25, 2023 at 01:41:17 PM PDT, Phil Smith III > <li...@akphs.com> wrote:
>> Jon Perryman wrote: >> Do you think we can't write rexx, use ISPF JCL tailoring, ISPF edit >> macros or the many other tools that everyone else uses to tailor JCL? > Not sure who "we" is. If you mean customers Sorry, I should have been clear that "we" refers to product developers. After 40 years, the SMP/e install jobs haven't significantly changed to make things automatically change. We have the tools, but we choose to have people modify the JCL even today. We don't want customers to automate the process. > I know from experience that many of "you" cannot do many of those things, or > have trouble with it. Customers shouldn't automate these tasks but not having these skills tells us they should not be installing z/OS because they don't have experience with z/OS planning, recovery and other required skills. Simply put they need guidance because automating the installation ignores things they don't understand. > Even if "you" can, then having the instructions say "Update these SET > statements > but also make the same changes in a bunch of other places" feels like amateur > hour and confuses customers. The SMP/e install jobs are the easy part. Customers who get confused at this stage don't know their company z/OS strategy and are a danger. It's been many years since my last z/OS install but understanding and setting the strategy many times required changes to the install jobs. Target & dist datasets and CSI's have an impact on recovery, disaster recovery and much more. If someone is confused during install, then they were overwhelmed during planning. > We are the vendor. We're dealing with our customers. Giving them a program > that updates the jobs automatically leads down a twisty maze of > "Where are the jobs they're updating?" and "Where do they put the Rexx > program?" > and such that's at least as bad as the original problem. It's quite amazing > how little many customers know. It's absurd to say updating jobs automatically creates a maze for the customer. CA has successfully used it for many years and IBM has PSWI. I think they put you into edit of each job that you submit. From my perspective, this encourages the uninitiated to submit the job without reviewing the job. They have a false sense of reality because they are not spending time changing the JCL. >> The bigger question is if using edit change commands causes this much >> grief, have you considered the implications of how you plan to >> maintain products? > Don't understand this question. We give them SMP/E update packages that apply > with another job. You say EDIT CHANGE ALL instances is causing customers grief. Do you think these people understand their companies z/OS strategy, planning, recovery and more? SMP/e is not the point of grief. z/OS is so stable, many customers don't consider the impact of not choosing wisely during install on when it goes live. > Anyway, when I get a chance, I'll look at the SYMBOLS= thing, > which will apparently solve our immediate problem. Just write a REXX exec that updates every JCL because customer coding accomplishes the same results. In both cases, the customers is going to blindly submit the job with the false impression you made the right choices for their environment. > I'd still suggest that a wee bit of effort in SMP/E error handling might be a > good investment. What SMP/e error handling are you recommending? Everything I'm hearing is confusion and annoyance about changing all occurrences in JCL. This has nothing to do with SMP/e. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
