rico999 wrote:Since the system is vanilla IBM only (which I was obviously not aware of until now), it renders my request moot so no need to get into a big debate over PDS' merits, is there? ...
I was not debating or discussing the merits of the product. I have never used it, so I'm not in a position to discuss this.
rico999 wrote:... From my experience, I can tell you that your "reasons" for not trying/using PDS are all bureaucratic and LAME. ...
So what. Over the years I had developed tools that replicated some of what PDS is supposed to do, so even when I worked in shops that had PDS installed I never had occasion to learn it.
rico999 wrote:... Although, based on the APF authorization finding, your initial ignorant comment "So what? If it's so great install it yourself for your ID" isn't really possible, is it?
You are correct. When I made the statement I had never looked into what was required to install it. I then downloaded the product from CBT and loaded it into Fandezhi to see what was involved. That's when I discovered the APF requirement (which I had suspected anyway, but it's better to see it in green and black) and the dependency on a number of other CBT products (which I was not aware of). The audit requirement is a standard for any careful shop; I see no reason to bypass it for Fandezhi.
I have nothing against CBT, but the product quality is awfully uneven. I have a product there, file 713. File 713 was an improved version of earlier submission. When I did the change I had 2 goals; remove the APF requirement and add limited PDSE support. APF is sometimes an admission that the programmer does not know how to do something and he cheats; that was the case here. There were other improvements that could have been made, but it was more than I wanted to do in 2005. In any event I had another program that does what file 713 does, so I was not about to use the file 713 program in my production use. The present file 713 has two serious problems; it does not support PDS in track managed space on an "extended attribute" volume, and I'm almost certain it does not support a PDS located in cylinder managed space on an "extended attribute" volume. I can't fix either problem since Fandezhi does not support "extended attribute" volumes. The first problem is easy to correct; just update the CAMLST with EADSCB=OK. The second problem is more complex; you can't use CVTPCNVT and CVTPRLTV for cylinder managed data sets; there are new macros for this, though I don't recall their names.
... all bureaucratic and LAME ...
The first time I really ran into this was for a shop that ran all proposed changes through an approval process. My initial reaction was this is "bureaucratic". After they stopped a proposed change I realized was pretty stupid I changed my mind; at one point this shop made an entire calender year with no unplanned outages.
In this respect Fandezhi does pretty well; we had no system outages from May 2012 through July 2013, though there were some issues with network outages that were hardly the fault of z/OS. It's been a bit rocky since then, but z/OS can't be blamed for power failures and data center reconfigurations.