I think you have to see how many mainframe CICS environments have adopted the WEBifying processes in CICS, let along PHP for CICS. I am a strong proponent for putting web services in Mainframe applications. However, I would like to see more vetting of the ported tools to ensure a non-disruptive environment. Can a DoS attach occur? Can the mainframe stop it? How to I restrict services when needed?
It is also true that we have z/OS USS processes in the z/OS environment. We can run many ported tools. But again, look at how many shops have adopted it. Vendors like CA have incorporated JBOS into their MSM product for mainframe maintenance for CA software products. They originally used TOMCAT but now I think it is JBOS. We also have HTTP functions and well as others. We only install what has been vetted. Other products, we take a wait and see attitude. They are still in the minority. And unlike an open systems environment, we cannot buy a mainframe computer or carve out a new LPAR to just RUN a CICS environment that supports web and mobile applications. That is fiscally prohibitive. Though I am sure some shops that are HUGE, might have the dollars to do that. However small and medium shop have to be much more conservative. And I think that is the biggest difference between open systems and mainframe. We can multi-task huge applications and data on one LPAR or SYSPLEX. Whereas I believe in open systems, they just keep adding servers or VM Ware to handle the workload. Now, it is not for the lack of trying by some of us grey-beards. But the consideration for SLAs, outage impacts, up time, resource utilization, and performance aspects, must give us pause. I am now and always will be more concerned about system impacts than I will with how much a ported tool could make my life easier. Whenever I develop in-house an ISPF application for restricted usage, I get a ton of emails when it "does not work". So I have seen the pain of a limited usage process and not production. The last aspect I have not discussed is Change Control. The mainframe cannot always just add tools in, without a change control approval. That is why if it is under my TSO ID, I am good. If it is shared, there is change control. We really do need to know what is in use and where. Even my production batch JCL has to go through Change Control and a Change Management Software (like Changeman or Endevor). If I want to bring in something for a Proof of Concept, I have to go through Hoops. Again, my two cents worth Lizette -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Crayford Sent: Thursday, October 03, 2013 8:59 AM To: [email protected] Subject: Re: Interested in up to date open source software or low cost utilities? On 3/10/2013 11:47 PM, Lizette Koehler wrote: > The mainframe has massive applications that if they go down the > amount of time to recover the application and/or fix it could take > many hours/days that costs the business income. Or cause an LPAR wide > outage that affects many more working applications (MQ, DB2, IMS, > CICS). That is bad for the bottom line. > > Any "freeware", "Shareware", etc... brought in to a mainframe > environment will eventually become a critical piece of production > applications - no matter how much you say " THIS IS NOT FOR PRODUCTION" But CICS is now touting PHP for CICS applications for mobile devices. That's open source software. To keep up with the Jones the mainframe has to adapt. If a vendor like Rocket offer support for the open source software that's all well and good. But that's still vendor lock in isn't it? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
