>Sourceforge is a wonderful resource and community. Today, NONE of the tools >used to make/build/test software in that (sourceforge) world can help you >when you have to update a CICS COBOL program to fix a bug, or get a patch >from IBM for the operating system and apply it across 20 LPAR's with no >disruption of business. 1) Edit the COBOL source in a PDS member. 2) Submit a compile. 3) View the compile output 4) Test the transaction 5) Submit a job to install to production. All of these features are available today in WebSphere Studio Enterprise Developer (WSED). WSED uses Eclipse and functions such as submitting jobs and viewing output are IBM provided plugins. But those same plugins *could* be created by an open source MVS community.
If that CICS source is currently under the control of a Source Manager, such as SCLM, CVS, PCVS or Serena Version Manager you probably already have access to it through your favorite Windows or Linux based IDE. ANT is a great tool for building and installing software. I currently use ANT to build java code and install to z/os with an ANT FTP task. There are currently few ANT tasks available for z/os but I'm sure more are on the way. The lines are blurring. Many of the strong tools created in the *nix/Win world are moving towards operability with a z/os server. IBM is meeting them halfway with support for various remote protocols. >CAN something like sourceforge be used to perform controlled maintenance of >CICS COBOL and the other MVS projects we must support? Yes, they *can*, but >unless IBM writes it, promotes it, and supports it, no business manager is >going to allow you use it. Too much business and career risk. IBM is writing it and promoting it. What is internet service delivery? We're throwing around the term "Sourceforge". Let me make a distinction here. I think the sourceforge model could be a stronger method for collaborative development of public domain software like that found on the CBT tape. I'm not suggesting a public "sourceforge" be used to maintain in- house programs. But there may be benefits in adopting a private sourceforge -- strong version control, communication, continuos integration, more flexibility in programmer and admin tools. >Just NOT for their installed base of batch programs and transaction >processing. And it *is* hard to use CVS for anything when you can't compile >CICS COBOL and link to a standard PDS LOADLIB for testing and QA and >Production. There aren't any "promotion" tools available for standard >change control procedures There are products today that drive remote z/os builds from a workstation or remote server. Eclipse supports SCLM (pretty standard promotion tool) for source maint and builds with ANT. How about Serena ChangeMan? I'm sure there are others. >When z/OS Unix Services is indistinguishable from a standard GNU linux (and >not just posix) environment AND supports appropriate interfaces to current >MVS technology (i.e., transparent access to MVS/EBCDIC files and data from >all utilities), then maybe there will be a need/desire for a sourceforge >equivalent of CBT. There's an assumption that all these new tools must execute on the z/os box. I don't think so. z/os only needs to provide interfaces to data and tasks. For example, we run our CVS servers on Windows but z/os jobs can access the data through a CVS client running in z/os Unix Services. >Until then CBT does the job. It isn't broken, so >there's no need to fix it, much less replace it. I agree that the CBT has served us well and will continue to do so. There's nothing stopping someone from starting a new MVS sourceforge project, not as a replacement but as an adjunct to CBT. The sourceforge project could automatically distribute to the CBT, providing both choices for distribution. If the new approach is valuable, it will prove itself out. -Rob ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
