After brooding quite a while over SMF records and (today) a dump, here is what I have to say about PDSE 'performance':
I have 26 large PDSE datasets (for Fault Analyzer side files) on 10 mod9 volumes, a few of the datasets more than 100000 tracks allocation. Non-SMS managed. Last week I used ISPF 3.4 to display them, put a 'b' in front of all of them and then typed PF3 in advance 26 times. It took more than 25 minutes to get the directory displayed for all of them. Yes, MINUTES. In the following I'll be concentrating on one of those datasets. It has 9899 member, and SMF 42 tells me that it took 10697 read requests with 465 read hits. How come it takes more read requests for the directory than there are member? Especially since I had just 'reorganized' that dataset (reallocate and copy - takes 50 minutes for 100000 tracks) which freed about 25000 pages. This morning I asked a colleague to do the browse for me via ISPF, while I dumped his userid to get a trace table. Aside from the fact that I caught the tail end of 'preparation' (apparently), as there is still some ISPF activity with dynallocs going on, I also caught some of the actual (PDSE) processing that takes forever: Apparently the C01 PC (called 'DFSMS') first does some sort of getmain via PDSE storage manager. It touches all those pages once, then around *every* SSCH the following is done: PC312 (TCBToken) out of IGWBIRP2 (the 'readpage routine') PC90E (IARV64 PageFix) initiate IO and suspend SSCH I/O Interrupt and resume the tcb (with IO times between ssch and IO interrupt around 4-8ms) PC90E (IARV64 PageUnfix) out of IGWBITX1 go back to TCBToken While I certainly understand that a page must be fixed in order to do I/O to it, why fix each and every page separately? While apparently each call fixes a different page, why not do a bunch of them in one call? Then do a bunch of IO? Answer to self: Presumably because the page just read-in is the only place that has the pointer to the next page containing directory information. If that's true: What a design! When I looked at the 11 (eleven) linkage stack entries (did I mention that there is a ton of linkage stack expand/contract program checks?) and searched SIS for the module names, it turned out that most of them belong to the 'PDSE Index Manager' that has more ptfs against it than can be healthy. <sarcasm on>That 'Index Manager' must have a very good algorithm to manage indices. <sarcasm off> Not to mention a ton of 'closed RET for more documentation' apars when said index manager has corrupted the PDSE. Well, unless corruption is copied over, it should not be corrupted. And I would need to open an ETR with IBM to get a current copy of IGWPIT (aka PHATOOL from the PDSE redbook; presumably the -further developed- anti-corruption tool that was announced for 1.12 - it has been around for a while, mine is from z/OS 1.6). So, now that John Ehrmann has managed to get the PDSE discussion started, he is conspiciously absent from the discussion.... I repeat what I said before: If at all possible, stay away from large PDSEs! (There is a reason why HFSs are not 'strategic' and get replaced by zFS.) My next step will be to try and get the things SMS-managed. While that *may* get rid of the 60s I/O times (about 10.000 times 6ms) that still leaves around 30s 'other' processing, presumably then all cpu intensive.... Regards, Barbara ---------------------------------------------------------------------- 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
