From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Timothy Sipples Sent: Sunday, October 13, 2019 11:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Z Development and Test Environment (zD&T)
David Jousma wrote: >We happen to be all parallel sysplex. *All* z/OS instances, including your development LPAR(s)? >> yes, all lpars are PS. >The other problem that we see is that an image that a developer spins >up wont have the knowledge let alone sysprog access to start/stop >regions, etc, >etc, etc. IBM's answer was just give them the >access, if they screw it up, just wipe it out, and >reclone the image. The problem is you are asking >developers to do things in this environment that they would have not >access to do on the "real systems" and would generate endless calls to >my team for support. Not endless, or at least not in the sense you evidently mean it. Look, fundamentally IBM is correct. IBM's basic advice is entirely consistent with the real rest of the world. We've seen this tired movie plot many times before, including four decades ago when business people "smuggled" Apple IIs with Visicalc into the office suites because IT departments were so terrible in supporting their innovative needs. In every other development context developers are allowed, even encouraged, to "screw up." And thank goodness they "screw up," because that's exactly what they should be doing as early as possible. They have "disposable" operating system instances, and when they inevitably wreck one, they toss it in the (virtual) trash, fire up another one, and try again. That's how people learn, and that's a good thing! The correct answer here is not to withhold thoroughly common and ordinary development capabilities from developers. That's an expedited path to the grave, really. If you're concerned about having "too much" demand for your support services -- puzzling to me since being in high(er) demand seems like an awfully good thing professionally and for job security, but OK, if that's your view -- then just handle all such support inquiries as "Low Severity" within your organization, prioritized well below the more important things they're doing. Declare that prioritization up front, and if somebody is upset that developers aren't supported well enough, management can decide whether to resolve that through more investments in education, more support staff, an outsourced developer support contract, more "how-to" documentation, or some combination. You also certainly don't get rid of your existing development resources on your IBM Z machines. Indeed, you also ought to ask IBM about getting an "Application Development and Test Solution" to expand those resources if you haven't already. >>Timothy, I agree with your comments about the future and the platform and >>folks learning. The per-instance cost of ZD&T (what we've been quoted >>anyways) is quite high for on-the-job hobbyist/business learning. But, >>please don't compare z/OS to Windows or Linux where everyone and their >>brother has personal copies at home to play with since their inception. The >>fact is that what most of us on this list have learned in decades of work >>experience can't be just "jumped into". What linux and windows does >>"built-in" z platform requires manual care and feeding. Like most on this >>list can attest too, staffing for z platform in the last 10-20 years has gone >>from robust to bare-bones. The bottom line is that I just don't have the >>resources to be the teacher/mentor/helpdesk for some percentage of the large >>development staff we have. Now, back to the discussion of usefulness of ZD&T... If nothing is the same as the "home" environment, how would one expect a developer to know how to compile programs, etc? Do you think every shop runs with the IBM supplied compile procs? What about application data? Dataset naming standards with regards to alias entries in mastercat/usercat's on the ZDT image? To be really useful to any level of ZD&T user, I'd have to build a Fifth Third flavored image that includes our non-blue software catalog, and come up with an automated process that would refresh the image regularly to keep things relatively in synch (security, catalog updates,?) so that something built and tested in ZD&T world would run on the z hardware platform. On a side-note, we are in the process of modernizing our Application Development toolset. Our mainframe developers have been relegated to managing their applications the same way they always have in the last 20 years. We are doing a POC expected to be implemented project to migrate the development efforts into iDZ/GIT/DBB/UCD/Jenkins managed development pipeline. When we get there, we will be in a much better position to support a ZD&T environment if it were to make sense. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
