>PDSEs have been available for a long time, and provide many >advantages over PDSs. Why are people reluctant to use PDSEs?
In our case: Extremely bad performance on large datasets, as in a little more than 10.000 members in 101.000 tracks, lrecl=1562, recfm=vb, blksize=32760. In ISPF 3.4, despite using the 'caching' from SMSPDSE/1, a 'browse' still takes almost a minute before ISPF shows you the directory. Considering that Fault Analyzer has to open them all (they contain Fault Analyzer side files - and we have 8 big ones and several smaller ones) until it finds the right source data set for analysis, this is extremely bad performance. It gets slightly better after 'reorganizing', i.e. just copy the dataset, in which case the directory isn't scattered across all 101000 tracks anymore. And let's not talk about data integrity. We lost two of those already. Irrevocably, as we the 4 backups we had all had the error which PDSE code had put in weeks ago. It's a very good thing that these can be rebuild or rather, gradually filled again. If the procedures here would allow with a reasonable organizational effort to NOT allocate them that large so they could be PDSs, we would never have used PDSEs. As it is, there is no way around the fact that the primary allocation is bigger than 65K tracks, necessitating PDSEs. And believe me, I had been an advocat of PDSEs in the beginning. And I still use PDSEs for my own, small JCL and source data sets. Stress on small. Regards, Barbara Nitz ---------------------------------------------------------------------- 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
