Amen Timothy Sipples! I have often seen systems programming/administration teams enact unnecessary restrictions on application programmers possibly to make their own jobs easier in the short-term (while destroying their value long-term). Or maybe they just like to wield their power. I believe the mainframe market would be bigger and healthier if it weren't for that attitude.
That said, I'm pretty sure that does not apply to Dave Jousma, as I've worked with him before, and he does want to innovate. It's ultimately up to management; and without wandering into my unsolicited opinions on corporate management, it's not that easy to get their attention, much less their buy-in for new things. sas On Sun, Oct 13, 2019 at 11:13 PM Timothy Sipples <sipp...@sg.ibm.com> wrote: > A couple quick comments and suggestions from me.... > > David Jousma wrote: > >We happen to be all parallel sysplex. > > *All* z/OS instances, including your development LPAR(s)? > > >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 Sipples > IT Architect Executive, Industry Solutions, IBM Z & LinuxONE > > -------------------------------------------------------------------------------------------------------- > > E-Mail: sipp...@sg.ibm.com > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
