On Fri, 20 Nov 2015 08:11:08 -0700, Sri h Kolusu wrote: >>>I looked at that. It builds a list of IDCAMS commands to delete the >members one-by-one. > >Well the deletion of all members of a PDS DFSORT trick is written when >IDCAMS did not support the Wild card deletion function on PDS members. So >DFSORT chose the traditional method of deleting the members. The new >features are written based on the customers needs and if a customer is >upto date with the latest features then he can use IDCAMS wild card >deletion. We just keep on adding new tricks of DFSORT and never delete off >any trick from that document. > >Similarly DFSORT had another trick of reading GDG generations in FIFO >order and with z/OS 2.1 the system itself supports the FIFO parm. So the >new enhancements gives you an alternative solution and the customer is >wise to chose the optimal solution. > When better techniques become available, perhaps the inferior ones should me marked in future editions as deprecated.
But, yes, they continue to have instructional value, at least as syntax examples. >>>>Does it at least sort the list in descending order? > >Descending order of what? member names or Size? Why exactly do you need to >sort the list ? Do you think it would make a difference to the directory >blocks? And just for the record as DFSORT is capable of sorting the member >names in either ascending/descending order. > Member names. I believe that when the alphabetically first member is deleted all following directory blocks (not data blocks) are rewritten to fill the gap, an unwelcome quadratic behavior. Deleting the last member requires rewriting only the last active directory block. (Yes, I thought this would be a natural application of DFSORT. I bet DFSORT is faster than quadratic time.) Thanks, gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
