Hi to all, In thread 'Why is GRS ENQ needed in SMFDUMP program?' I described the GRS ENQ in SMFDUMP and the resulting START PENDING problem. That was in June 2012 and there was a very interesting discussion lasted a while.
This problem is now resolved at all. Thanks to all who replied, all replies were very helpful. I would like to share it in case someone needs it. I'm now using IEFU29 just as it is supplied in SYS1.SAMPLIB with little modifications (WTO white space eliminated and command string 'S SMFDUMP,....' changed to 'S <something>,...' The STC, residing in a single SysPlex-wide Proclib, is using Symbolic names to resolve actual datasets in the JCL. All and every datasets used are unique per LPAR, so absolutely NO ENQ can take place as far as those dumping goes. Since IEE391A is suppressed, no automation software is kicking off SMFDUMP anymore, but on messages IEE366*, IEE985A, etc, the usual SMFDUMP program is started by automation software. This is because the IEFU29 (and the STC submitted) cannot handle situations where more than one MANx is in 'DUMP REQUIRED" status. This is fine with me because it is a seldom event. I can now use automation software to issue 'I SMF' on all my dozen plus LPARS simultaneausly. No ENQ, no START PENDING, etc are experienced at all. I do that 'RO *ALL,I SMF' after midnight, 06:00 and 22:00 - 23:00 on all LPARS without causing any delays or problems. Even our nightly backup jobs are running faster. Of course the IEEU29 as supplied by IBM has still that same ENQ macro with the same keywords as used by the SMFDUMP program, but the wall-clock duration of that ENQ is just a second or two. The important difference between IEFU29 and SMFDUMP regarding that ENQ is - IEFU29 ENQ is after the actual 'I SMF', while SMFDUMP is using the ENQ during the whole story of 'I SMF' and finishing off all those MANx datasets and then release that ENQ. I see also the advantage of using a STC to do the dump - no JES2 initiators, higher WLM priority and it seemed to me (or I imagined :-D ) the dumping/emptying of MANx is going somewhat faster. Since I don't have to stagger my SMFDUMP jobs about 30 minutes on all LPARS, all our batch jobs depending on those SMF data can be run earlier in the morning - thus releasing extra CPU cycles to our impatient users. ;-) That is all folks! Many thanks to all who replied to me last year! I'm very grateful of your kind help. Now off to another quest. ;-D Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
