We had many problems with PDSE on the installation where I worked until last month.
When the PDSE has a massive update process (inserting and deleting members - the installation has a system that uses PDSE as base to archive he last three days of production jobs JES sysouts) something happens that after some time it is impossible update the file. We turn around this problem when monthly a job create a new PDSE, copy the contents of the old to the new, delete the old and rename the new one to the old name. At least once we couldn't read the file after this problem. We don't know if this problem was solved or not because we kept the turn around process. The last problem that we faced with PDSE was on the delete members process, because the file was full and was allocated with no secondary allocation space parameter. This began with zOS 1.10 - until zOS 1.8 never was happened. The program sometimes ends with D37. The IBM Lab sad that it's because of the directory process update demands some space. We turn around specifying secondary allocation space parameters only in this process. Until now the people there feel unsecure to use PDSE for production load modules or other production library. Adauto -----Mensagem original----- De: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] Em nome de Chase, John Enviada em: quinta-feira, 11 de fevereiro de 2010 10:53 Para: IBM-MAIN@bama.ua.edu Assunto: Re: PDS vs. PDSE > -----Original Message----- > From: IBM Mainframe Discussion List On Behalf Of R.S. > > I dared to get all the objections together combined with some mines: > > Disadvantages: > 1. New feature - people still think that way <vbg> > 2. Former requirement for SMS-management > 3. "New" keyword to create PDSE (DSNTYPE) > 4. Cross-sysplex sharing > 5. Cannot hold both data and programs (and no visible clue what's the kind > 6. LPALST, LNKLST restrictions > 7. Quite recent changes (address spaces) - look like "work in progress" > 8. PTFs > 9. With fe exceptions (listed below) no visible advantage. Long names > are not usable in JCL or ISPF (where they are usable?). Load module size > is limit rarely a problem. New program format is not an advantage itself. > 10. As above: 64k TRKs limit relieved, but ther's still single vol > restriction. > 11. Still many datasets cannot be PDSEs. > 12. Performance can be worse than PDS. > 13. Secret documentation. BTW: It is horrible that basic function as > "get_dataset_size" is kept secret for regular users! > 14. 4k block boundary for members can consume more space than regular PDS > > Advantages: > 1. No need to compress > 2. 123 extents > 3. No 64k TRKs limit > 4. Cannot be destroyed when open for output as PS (common mistake). 5. Counts as one extent in LNKLST regardless the actual number of extents. -jc- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
