Tom is an independent consultant and a frequent contributor to SHARE. I feel comfortable assuming that he is using his experiences at multiple shops to formulate his computations.
While the process of converting a PDS to a PDSE is indeed trivial, what happens after may not be so. I know my CIO would want assurances that this process would not disrupt our business at all. I might automate the actual conversion, but I would spend a whole lot of time testing first and monitoring it afterwards. Another area that would concern me is interfacing with ISV products. Most of them (at my shop anyway) still distribute load modules in PDSs, and many of them require compiling COBOL exit programs to configure some functionality. Do I convert their PDSs to PDSEs so I can use COBOL 5.1 to recompile their exits, or do I concatenate loadlibs in the started tasks? Sounds like a lot more testing to me. Greg Shirey Ben E. Keith Company -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Thursday, September 12, 2013 9:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PDS/E, Shared Dasd, and COBOL V5 I found Mr. Conley's computations interesting. They presumably reflect his practices and those of his shop, and what specifically I found most interesting about them is their manual, handicraft, repetitive character. His costing calculations assume that each PDS to PDSE conversion is a new problem, one that is to be approached, analyzed, and resolved ab initio. In fact the entire process is a trivial one that can be, has been, very largely automated. Moreover, it should be. The only distinctively human contribution that can be made to such repetitive processes are the errors that are inevitably introduced by fatigue and boredom. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
