Jon Perryman wrote: >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. >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. >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. I don't disagree, but I'm not really going to tell a customer, "I'm sorry, you're clearly not up to the job of installing this product. Who else there knows more than you do?" so I'm not sure what your real-world point is-IOW, what different action you're suggesting. >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. PSWI? Pharmacy Society of Wisconsin? CA has built essentially a whole product for product installation and maintenance. They have (or at least had) the manpower to do that. I don't. >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. Again, don't disagree that they don't understand, but?? >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. But if I make the changes (via automation) and it screws up, it's my fault. If I gave them something that won't run as provided, and they make changes and it screws up, it's their fault. This matters. >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. When they do get it wrong, SMP/E errors are usually incomprehensible. I've said this repeatedly; are some of my posts not getting through? I see them. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
