Re: IEFU29 and Automation
Thank you, Lizette and Mark, for your help. I have fetched SMFDUMP from CBT tape, installed it and corrected the procedure. Now it works OK. Shimeon Ginsburg. On Mon, 3 Aug 2009 11:02:59 -0400, Lizette Koehler wrote: >I would look on the CBT TAPE under UPDATEs on the left hand side of the page. It should be file 686. > >Lizette > > > >> >>>Lizette is correct. The example I posted requires the use of the "CBIPO" >>>SMFDUMP program for the "ALL" step. Search the archives if you want >>>to know more about the SMFDUMP program. >>> > >>> >>> >>>On Sun, 2 Aug 2009 10:46:47 -0400, Lizette Koehler >> >>>wrote: >>> Please post your JCL for this process. The ALL step uses SMFDUMP and the FALSE step uses IFASMFDP. Lizette > Lizette, > > The problem occured when ALL=TRUE was specified. In this case the > DUMPONE step is not executed . The step that is executed is DUMPALL. In > this step there is no reference to the MAN variable, so that specifying MAN in > calling the procedure would not help. > -- >> >>I have failed to notice that the ALL step uses SMFDUMP . >>I have found a 1996 version of this program in one of our linklist libraries. >>Where can I find a current version ? >> > >-- -- 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
Re: IEFU29 and Automation
I would look on the CBT TAPE under UPDATEs on the left hand side of the page. It should be file 686. Lizette > >>Lizette is correct. The example I posted requires the use of the "CBIPO" >>SMFDUMP program for the "ALL" step. Search the archives if you want >>to know more about the SMFDUMP program. >> >> >> >>On Sun, 2 Aug 2009 10:46:47 -0400, Lizette Koehler > >>wrote: >> >>>Please post your JCL for this process. The ALL step uses SMFDUMP and the >>>FALSE step uses IFASMFDP. >>> >>>Lizette >>> Lizette, The problem occured when ALL=TRUE was specified. In this case the DUMPONE step is not executed . The step that is executed is DUMPALL. In this step there is no reference to the MAN variable, so that specifying >>>MAN in calling the procedure would not help. >>> >>>-- > >I have failed to notice that the ALL step uses SMFDUMP . >I have found a 1996 version of this program in one of our linklist libraries. > >Where can I find a current version ? > -- 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
Re: IEFU29 and Automation
On Sun, 2 Aug 2009 14:32:29 -0500, Mark Zelden wrote: >Lizette is correct. The example I posted requires the use of the "CBIPO" >SMFDUMP program for the "ALL" step. Search the archives if you want >to know more about the SMFDUMP program. > >Regards, > >Mark >-- >Mark Zelden >Sr. Software and Systems Architect - z/OS Team Lead >Zurich North America / Farmers Insurance Group - ZFUS G-ITO >mailto:mark.zel...@zurichna.com >z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ >Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html > > >On Sun, 2 Aug 2009 10:46:47 -0400, Lizette Koehler >wrote: > >>Please post your JCL for this process. The ALL step uses SMFDUMP and the >>FALSE step uses IFASMFDP. >> >>Lizette >> >>> Lizette, >>> >>> The problem occured when ALL=TRUE was specified. In this case the >>> DUMPONE step is not executed . The step that is executed is DUMPALL. In >>> this step there is no reference to the MAN variable, so that specifying >>MAN in >>> calling the procedure would not help. >>> >> >>-- I have failed to notice that the ALL step uses SMFDUMP . I have found a 1996 version of this program in one of our linklist libraries. Where can I find a current version ? -- 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
Re: IEFU29 and Automation
Lizette is correct. The example I posted requires the use of the "CBIPO" SMFDUMP program for the "ALL" step. Search the archives if you want to know more about the SMFDUMP program. Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html On Sun, 2 Aug 2009 10:46:47 -0400, Lizette Koehler wrote: >Please post your JCL for this process. The ALL step uses SMFDUMP and the >FALSE step uses IFASMFDP. > >Lizette > >> Lizette, >> >> The problem occured when ALL=TRUE was specified. In this case the >> DUMPONE step is not executed . The step that is executed is DUMPALL. In >> this step there is no reference to the MAN variable, so that specifying >MAN in >> calling the procedure would not help. >> > >-- >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
Re: IEFU29 and Automation
Please post your JCL for this process. The ALL step uses SMFDUMP and the FALSE step uses IFASMFDP. Lizette > Lizette, > > The problem occured when ALL=TRUE was specified. In this case the > DUMPONE step is not executed . The step that is executed is DUMPALL. In > this step there is no reference to the MAN variable, so that specifying MAN in > calling the procedure would not help. > -- 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
Re: IEFU29 and Automation
On Sun, 2 Aug 2009 09:18:23 -0400, Lizette Koehler wrote: >When you used Mark's solution, how did you code >//SMFDUMP PROC >MAN='X',ALL=FALSE >The X= part? This process requires the fully qualified MAN file to be >dumped. > >You should have started the ALL process something like > >S SMFDUMP,MAN='SYS1.MANx',ALL=TRUE >Where MAN is your fully qualified man file. > >Is that what you did? If it is, please show us the JCL output from the >failed process. > >Lizette > > >> >> >>I am having a discussion with a coworker about whether or not we need to >> >run IEFU29. We have OPS/MVS in house. I say that we do not need IEFU29 >> >because OPS/MVS can trap on the IEE388I SMF NOW RECORDING ON VOLSER >> DCSMF3, >> >DSN=SYS1.SPG7.MAN3 TIME=10.30.00 message, display the man files at that >> >point and the issue the Dump command for the correct MAN file. >> >> >> >>My coworker says we have to run the IEFU29 exit to do this. >> >> >> >>I know we could put the IEFU29 in place, but I think the less exits to >> >maintain the better. >> >> >> > >> > >> >I've done it both ways. Here, we use IEFU29 but used to use automation >on >> >a few of monoplex LPARs. I standardized on IEFU29 sometime after >> >I started working here. >> > >> >One advantage that the automation had was that when shutting down LPARs >> >you can leave a MANx file that still needs to be dumped (too late in the >> >shutdown process for it to be started), then the next time you IPL it >will >> >start recording on the first one which leaves a MANx file that needs to >> >be dumped. The old automation used to include a "D SMF" at IPL time >> >and dump those MANx files that required it. >> > >> >There were 2 solutions I had for that. >> > >> >1) Ignore it. As long as there were enough MANx data sets to handle >> >the load, the SMFDUMP program that runs after midnight dumps them >> >all anyway (in addition to doing a switch). MXG doesn't care if the SMF >> >data is out of order anyway. >> > >> >2) Use a proc like the following at IPL time and "S SMFDUMP,ALL=TRUE" >> >(I only use this in my sandbox LPARs that don't have automation nor >> >SMF daily processing): >> > >> > >> >//SMFDUMP PROC MAN='X',ALL=FALSE >> >//* >> >//* THIS PROC IS NORMALLY STARTED VIA IEFU29 SMF EXIT WHEN AN >> >//* SMF DATA SET SWITCH OCCURS (ONLY THE FIRST STEP RUNS): >> >//*S SMFDUMP,MAN=SMF.DATA.SET.NAME >> >//* >> >//* AT IPL TIME IS IS STARTED AS FOLLOWS TO RUN THE SMFDUMP >> >//* PROGRAM TO ENSURE ALL FULL SYS1.MANX DATA SETS ARE DUMPED: >> >//*S SMFDUMP,ALL=TRUE >> >//* >> >//* IT IS ALSO STARTED THIS WAY AT MIDNIGHT TO USE THE SMFDUMP >> >//* PROGRAM WHICH FORCES AN SMF SWITCH IN ORDER TO CAPTURE ALL >> >//* THE SMF DATA UP TO THAT POINT FOR DAILY PROCESSING. >> >//* >> >//TESTEXEC EXEC PGM=IEFBR14 >> >//* >> >// >> >> >//TESTONE IF (TESTEXEC.RUN NE &ALL) THEN >> >// >> >> >//DUMPONE EXEC PGM=IFASMFDP,TIME=1440 >> >//SYSPRINT DD SYSOUT=* >> >//DUMPIN DD DSN=&MAN,DISP=SHR >> >//DUMPOUT DD DSN=hlq.&SYSNAME..SMF(+1),DISP=(,CATLG), >> >// DCB= (SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA, >> >// SPACE=(CYL,(100,100),RLSE) >> >//SYSINDD DUMMY >> >// ENDIF >> >// >> >> >//TESTALL IF (TESTEXEC.RUN EQ &ALL) THEN >> >// >> >> >//DUMPALL EXEC PGM=SMFDUMP,TIME=1440 >> >//SYSPRINT DD SYSOUT=* >> >//DUMPOUT DD DSN=hlq.&SYSNAME..SMF(+1),DISP=(,CATLG), >> >// DCB= (SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA, >> >// SPACE=(CYL,(100,100),RLSE) >> >//SYSINDD DUMMY >> >// ENDIF >> > >> > >> -- >> >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 >> >> I have tried to implement this sample. But when I started the procedure >with >> ALL=TRUE the following messages were issued: >> >> IFA010I SMF DUMP PARAMETERS >> IFA010I END(2400) -- DEFAULT >> IFA010I START() -- DEFAULT >> IFA010I DATE(190,2099366) -- DEFAULT >> IFA010I OUTDD(DUMPOUT,TYPE(0:255)) -- DEFAULT >> IFA010I INDD(DUMPIN,OPTIONS(ALL)) -- DEFAULT >> IFA012I DSORG OF DUMPIN CANNOT BE DETERMINED >> IFA012INO FURTHER PROCESSING OF THIS DATASET >> IFA011I SMF DUMPOUT DATASET CANNOT BE OPENED >> IFA011INO FURTHER PROCESSING OF THIS DATASET >> >> Can IFASMFDP work without the DUMPIN dd card? >> > >-- Lizette, The problem occured when ALL=TRUE was specified. In this case the DUMPONE step is not executed . The step that is executed is DUMPALL. In this step there is no reference to the MAN
Re: IEFU29 and Automation
When you used Mark's solution, how did you code >//SMFDUMP PROC MAN='X',ALL=FALSE The X= part? This process requires the fully qualified MAN file to be dumped. You should have started the ALL process something like S SMFDUMP,MAN='SYS1.MANx',ALL=TRUE Where MAN is your fully qualified man file. Is that what you did? If it is, please show us the JCL output from the failed process. Lizette > > >>I am having a discussion with a coworker about whether or not we need to > >run IEFU29. We have OPS/MVS in house. I say that we do not need IEFU29 > >because OPS/MVS can trap on the IEE388I SMF NOW RECORDING ON VOLSER > DCSMF3, > >DSN=SYS1.SPG7.MAN3 TIME=10.30.00 message, display the man files at that > >point and the issue the Dump command for the correct MAN file. > >> > >>My coworker says we have to run the IEFU29 exit to do this. > >> > >>I know we could put the IEFU29 in place, but I think the less exits to > >maintain the better. > >> > > > > > >I've done it both ways. Here, we use IEFU29 but used to use automation on > >a few of monoplex LPARs. I standardized on IEFU29 sometime after > >I started working here. > > > >One advantage that the automation had was that when shutting down LPARs > >you can leave a MANx file that still needs to be dumped (too late in the > >shutdown process for it to be started), then the next time you IPL it will > >start recording on the first one which leaves a MANx file that needs to > >be dumped. The old automation used to include a "D SMF" at IPL time > >and dump those MANx files that required it. > > > >There were 2 solutions I had for that. > > > >1) Ignore it. As long as there were enough MANx data sets to handle > >the load, the SMFDUMP program that runs after midnight dumps them > >all anyway (in addition to doing a switch). MXG doesn't care if the SMF > >data is out of order anyway. > > > >2) Use a proc like the following at IPL time and "S SMFDUMP,ALL=TRUE" > >(I only use this in my sandbox LPARs that don't have automation nor > >SMF daily processing): > > > > > >//SMFDUMP PROC MAN='X',ALL=FALSE > >//* > >//* THIS PROC IS NORMALLY STARTED VIA IEFU29 SMF EXIT WHEN AN > >//* SMF DATA SET SWITCH OCCURS (ONLY THE FIRST STEP RUNS): > >//*S SMFDUMP,MAN=SMF.DATA.SET.NAME > >//* > >//* AT IPL TIME IS IS STARTED AS FOLLOWS TO RUN THE SMFDUMP > >//* PROGRAM TO ENSURE ALL FULL SYS1.MANX DATA SETS ARE DUMPED: > >//*S SMFDUMP,ALL=TRUE > >//* > >//* IT IS ALSO STARTED THIS WAY AT MIDNIGHT TO USE THE SMFDUMP > >//* PROGRAM WHICH FORCES AN SMF SWITCH IN ORDER TO CAPTURE ALL > >//* THE SMF DATA UP TO THAT POINT FOR DAILY PROCESSING. > >//* > >//TESTEXEC EXEC PGM=IEFBR14 > >//* > >// > > >//TESTONE IF (TESTEXEC.RUN NE &ALL) THEN > >// > > >//DUMPONE EXEC PGM=IFASMFDP,TIME=1440 > >//SYSPRINT DD SYSOUT=* > >//DUMPIN DD DSN=&MAN,DISP=SHR > >//DUMPOUT DD DSN=hlq.&SYSNAME..SMF(+1),DISP=(,CATLG), > >// DCB=(SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA, > >// SPACE=(CYL,(100,100),RLSE) > >//SYSINDD DUMMY > >// ENDIF > >// > > >//TESTALL IF (TESTEXEC.RUN EQ &ALL) THEN > >// > > >//DUMPALL EXEC PGM=SMFDUMP,TIME=1440 > >//SYSPRINT DD SYSOUT=* > >//DUMPOUT DD DSN=hlq.&SYSNAME..SMF(+1),DISP=(,CATLG), > >// DCB=(SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA, > >// SPACE=(CYL,(100,100),RLSE) > >//SYSINDD DUMMY > >// ENDIF > > > > > -- > >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 > > I have tried to implement this sample. But when I started the procedure with > ALL=TRUE the following messages were issued: > > IFA010I SMF DUMP PARAMETERS > IFA010I END(2400) -- DEFAULT > IFA010I START() -- DEFAULT > IFA010I DATE(190,2099366) -- DEFAULT > IFA010I OUTDD(DUMPOUT,TYPE(0:255)) -- DEFAULT > IFA010I INDD(DUMPIN,OPTIONS(ALL)) -- DEFAULT > IFA012I DSORG OF DUMPIN CANNOT BE DETERMINED > IFA012INO FURTHER PROCESSING OF THIS DATASET > IFA011I SMF DUMPOUT DATASET CANNOT BE OPENED > IFA011INO FURTHER PROCESSING OF THIS DATASET > > Can IFASMFDP work without the DUMPIN dd card? > -- 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
Re: IEFU29 and Automation
On Mon, 13 Apr 2009 11:07:14 -0500, Mark Zelden wrote: >On Mon, 13 Apr 2009 11:14:15 -0400, Lizette Koehler > wrote: > >>I am having a discussion with a coworker about whether or not we need to >run IEFU29. We have OPS/MVS in house. I say that we do not need IEFU29 >because OPS/MVS can trap on the IEE388I SMF NOW RECORDING ON VOLSER DCSMF3, >DSN=SYS1.SPG7.MAN3 TIME=10.30.00 message, display the man files at that >point and the issue the Dump command for the correct MAN file. >> >>My coworker says we have to run the IEFU29 exit to do this. >> >>I know we could put the IEFU29 in place, but I think the less exits to >maintain the better. >> > > >I've done it both ways. Here, we use IEFU29 but used to use automation on >a few of monoplex LPARs. I standardized on IEFU29 sometime after >I started working here. > >One advantage that the automation had was that when shutting down LPARs >you can leave a MANx file that still needs to be dumped (too late in the >shutdown process for it to be started), then the next time you IPL it will >start recording on the first one which leaves a MANx file that needs to >be dumped. The old automation used to include a "D SMF" at IPL time >and dump those MANx files that required it. > >There were 2 solutions I had for that. > >1) Ignore it. As long as there were enough MANx data sets to handle >the load, the SMFDUMP program that runs after midnight dumps them >all anyway (in addition to doing a switch). MXG doesn't care if the SMF >data is out of order anyway. > >2) Use a proc like the following at IPL time and "S SMFDUMP,ALL=TRUE" >(I only use this in my sandbox LPARs that don't have automation nor >SMF daily processing): > > >//SMFDUMP PROC MAN='X',ALL=FALSE >//* >//* THIS PROC IS NORMALLY STARTED VIA IEFU29 SMF EXIT WHEN AN >//* SMF DATA SET SWITCH OCCURS (ONLY THE FIRST STEP RUNS): >//*S SMFDUMP,MAN=SMF.DATA.SET.NAME >//* >//* AT IPL TIME IS IS STARTED AS FOLLOWS TO RUN THE SMFDUMP >//* PROGRAM TO ENSURE ALL FULL SYS1.MANX DATA SETS ARE DUMPED: >//*S SMFDUMP,ALL=TRUE >//* >//* IT IS ALSO STARTED THIS WAY AT MIDNIGHT TO USE THE SMFDUMP >//* PROGRAM WHICH FORCES AN SMF SWITCH IN ORDER TO CAPTURE ALL >//* THE SMF DATA UP TO THAT POINT FOR DAILY PROCESSING. >//* >//TESTEXEC EXEC PGM=IEFBR14 >//* >// >//TESTONE IF (TESTEXEC.RUN NE &ALL) THEN >// >//DUMPONE EXEC PGM=IFASMFDP,TIME=1440 >//SYSPRINT DD SYSOUT=* >//DUMPIN DD DSN=&MAN,DISP=SHR >//DUMPOUT DD DSN=hlq.&SYSNAME..SMF(+1),DISP=(,CATLG), >// DCB=(SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA, >// SPACE=(CYL,(100,100),RLSE) >//SYSINDD DUMMY >// ENDIF >// >//TESTALL IF (TESTEXEC.RUN EQ &ALL) THEN >// >//DUMPALL EXEC PGM=SMFDUMP,TIME=1440 >//SYSPRINT DD SYSOUT=* >//DUMPOUT DD DSN=hlq.&SYSNAME..SMF(+1),DISP=(,CATLG), >// DCB=(SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA, >// SPACE=(CYL,(100,100),RLSE) >//SYSINDD DUMMY >// ENDIF > > >-- >Mark Zelden >Sr. Software and Systems Architect - z/OS Team Lead >Zurich North America / Farmers Insurance Group - ZFUS G-ITO >mailto:mark.zel...@zurichna.com >z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ >Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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 I have tried to implement this sample. But when I started the procedure with ALL=TRUE the following messages were issued: IFA010I SMF DUMP PARAMETERS IFA010I END(2400) -- DEFAULT IFA010I START() -- DEFAULT IFA010I DATE(190,2099366) -- DEFAULT IFA010I OUTDD(DUMPOUT,TYPE(0:255)) -- DEFAULT IFA010I INDD(DUMPIN,OPTIONS(ALL)) -- DEFAULT IFA012I DSORG OF DUMPIN CANNOT BE DETERMINED IFA012INO FURTHER PROCESSING OF THIS DATASET IFA011I SMF DUMPOUT DATASET CANNOT BE OPENED IFA011INO FURTHER PROCESSING OF THIS DATASET Can IFASMFDP work without the DUMPIN dd card? -- 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
Re: IEFU29 and Automation
Hi, I have seen this sample and tried to implement it, but when I started the procedure with ALL=TRUE the following messages were issued: IFA010I SMF DUMP PARAMETERS IFA010I END(2400) -- DEFAULT IFA010I START() -- DEFAULT IFA010I DATE(190,2099366) -- DEFAULT IFA010I OUTDD(DUMPOUT,TYPE(0:255)) -- DEFAULT IFA010I INDD(DUMPIN,OPTIONS(ALL)) -- DEFAULT IFA012I DSORG OF DUMPIN CANNOT BE DETERMINED IFA012INO FURTHER PROCESSING OF THIS DATASET IFA011I SMF DUMPOUT DATASET CANNOT BE OPENED IFA011INO FURTHER PROCESSING OF THIS DATASET Can the IFASMFDP utility work without the DUMPIN dd card? -- 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
Re: IEFU29 and Automation
On Mon, 13 Apr 2009 11:07:14 -0500, Mark Zelden wrote: > >I've done it both ways. Here, we use IEFU29 but used to use automation on >a few of monoplex LPARs. I standardized on IEFU29 sometime after >I started working here. > I guess I should have given a reason for my choice. My team doesn't install the automation software nor can we update / control it in any way. I wanted control over this process since it is an operating system function that we are responsible for. If something changes due to an OS migration, PTF, etc., we can change it without coordinating it with the automation folks. A good example will be if / when we migrate to SMF logstreams. If this shop ran like some smaller shops I've been at where the MVS sysprogs install the automation or can at least update / change the automation, I wouldn't care as much. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: IEFU29 and Automation
On Mon, 13 Apr 2009 16:28:07 +, Ted MacNEIL wrote: >>Guess I'm with the EXITs crowd. May be instances where OPS/MVS needs to be >down or fixed while rest of system chugs along. > >I agree. >And, it's not as if you have to write IEFU29 from scratch. > >- True. The reason that my shop migrated from IEFU29 to CA-OPS/MVS II is mainly that REXX is easier to write than HLASM. Our general rule is "minimal customization" so that "future fools" (my classification) can still maintain the system. This even applies to Windows applications - our ticketing system was just upgraded and can no longer auto logon because the new admins don't know how to do it. That was a customization by a former admin who knew how to program. The new admins don't know how to program to "script", so if it is not supported "out of the box", it can't be implemented. Also, it is easier to change an OPS rule than the IEFU29 exit in the one-in-a-million chance that some change is needed. -- John -- 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
Re: IEFU29 and Automation
Thanks everyone. I will go without the exit. Reason is due to no assembler coders here to support it. I am the only one that can code assembler and if it breaks and I am not here, well you know. ;-Q Lizette > >>Guess I'm with the EXITs crowd. May be instances where OPS/MVS needs to be >down or fixed while rest of system chugs along. > >I agree. >And, it's not as if you have to write IEFU29 from scratch. > -- 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
Re: IEFU29 and Automation
>Guess I'm with the EXITs crowd. May be instances where OPS/MVS needs to be down or fixed while rest of system chugs along. I agree. And, it's not as if you have to write IEFU29 from scratch. - Too busy driving to stop for gas! -- 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
Re: IEFU29 and Automation
In a message dated 4/13/2009 10:54:35 A.M. Central Daylight Time, stars...@mindspring.com writes: I know we could put the IEFU29 in place, but I think the less exits to maintain the better. Any thoughts? >> Guess I'm with the EXITs crowd. May be instances where OPS/MVS needs to be down or fixed while rest of system chugs along. **The Average US Credit Score is 692. See Yours in Just 2 Easy Steps! (http://pr.atwola.com/promoclk/100126575x1221621489x1201450100/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26h mpgID%3D62%26bcd%3DAprilAvgfooterNO62) -- 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
Re: IEFU29 and Automation
On Mon, 13 Apr 2009 11:14:15 -0400, Lizette Koehler wrote: >I am having a discussion with a coworker about whether or not we need to run IEFU29. We have OPS/MVS in house. I say that we do not need IEFU29 because OPS/MVS can trap on the IEE388I SMF NOW RECORDING ON VOLSER DCSMF3, DSN=SYS1.SPG7.MAN3 TIME=10.30.00 message, display the man files at that point and the issue the Dump command for the correct MAN file. > >My coworker says we have to run the IEFU29 exit to do this. > >I know we could put the IEFU29 in place, but I think the less exits to maintain the better. > I've done it both ways. Here, we use IEFU29 but used to use automation on a few of monoplex LPARs. I standardized on IEFU29 sometime after I started working here. One advantage that the automation had was that when shutting down LPARs you can leave a MANx file that still needs to be dumped (too late in the shutdown process for it to be started), then the next time you IPL it will start recording on the first one which leaves a MANx file that needs to be dumped. The old automation used to include a "D SMF" at IPL time and dump those MANx files that required it. There were 2 solutions I had for that. 1) Ignore it. As long as there were enough MANx data sets to handle the load, the SMFDUMP program that runs after midnight dumps them all anyway (in addition to doing a switch). MXG doesn't care if the SMF data is out of order anyway. 2) Use a proc like the following at IPL time and "S SMFDUMP,ALL=TRUE" (I only use this in my sandbox LPARs that don't have automation nor SMF daily processing): //SMFDUMP PROC MAN='X',ALL=FALSE //* //* THIS PROC IS NORMALLY STARTED VIA IEFU29 SMF EXIT WHEN AN //* SMF DATA SET SWITCH OCCURS (ONLY THE FIRST STEP RUNS): //*S SMFDUMP,MAN=SMF.DATA.SET.NAME //* //* AT IPL TIME IS IS STARTED AS FOLLOWS TO RUN THE SMFDUMP //* PROGRAM TO ENSURE ALL FULL SYS1.MANX DATA SETS ARE DUMPED: //*S SMFDUMP,ALL=TRUE //* //* IT IS ALSO STARTED THIS WAY AT MIDNIGHT TO USE THE SMFDUMP //* PROGRAM WHICH FORCES AN SMF SWITCH IN ORDER TO CAPTURE ALL //* THE SMF DATA UP TO THAT POINT FOR DAILY PROCESSING. //* //TESTEXEC EXEC PGM=IEFBR14 //* // //TESTONE IF (TESTEXEC.RUN NE &ALL) THEN // //DUMPONE EXEC PGM=IFASMFDP,TIME=1440 //SYSPRINT DD SYSOUT=* //DUMPIN DD DSN=&MAN,DISP=SHR //DUMPOUT DD DSN=hlq.&SYSNAME..SMF(+1),DISP=(,CATLG), // DCB=(SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA, // SPACE=(CYL,(100,100),RLSE) //SYSINDD DUMMY // ENDIF // //TESTALL IF (TESTEXEC.RUN EQ &ALL) THEN // //DUMPALL EXEC PGM=SMFDUMP,TIME=1440 //SYSPRINT DD SYSOUT=* //DUMPOUT DD DSN=hlq.&SYSNAME..SMF(+1),DISP=(,CATLG), // DCB=(SYS1.MODEL,LRECL=X,BLKSIZE=32756,RECFM=VBS),UNIT=SYSDA, // SPACE=(CYL,(100,100),RLSE) //SYSINDD DUMMY // ENDIF -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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
Re: IEFU29 and Automation
On Mon, 13 Apr 2009 11:14:15 -0400, Lizette Koehler wrote: >I am having a discussion with a coworker about whether or not we need to run IEFU29. We have OPS/MVS in house. I say that we do not need IEFU29 because OPS/MVS can trap on the IEE388I SMF NOW RECORDING ON VOLSER DCSMF3, DSN=SYS1.SPG7.MAN3 TIME=10.30.00 message, display the man files at that point and the issue the Dump command for the correct MAN file. > >My coworker says we have to run the IEFU29 exit to do this. > >I know we could put the IEFU29 in place, but I think the less exits to maintain the better. > >Any thoughts? > >Lizette We did exactly as you propose to do. We removed our IEFU29 exit, replacing it with a CA-OPS/MVS II rule. However, we trap IEE391A as that shows the DSN which just filled up and needs dumping. The IEE388I message shows the NEW DSN which is now in use. You don't want to try to dump that one. -- John -- 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
IEFU29 and Automation
I am having a discussion with a coworker about whether or not we need to run IEFU29. We have OPS/MVS in house. I say that we do not need IEFU29 because OPS/MVS can trap on the IEE388I SMF NOW RECORDING ON VOLSER DCSMF3, DSN=SYS1.SPG7.MAN3 TIME=10.30.00 message, display the man files at that point and the issue the Dump command for the correct MAN file. My coworker says we have to run the IEFU29 exit to do this. I know we could put the IEFU29 in place, but I think the less exits to maintain the better. Any thoughts? Lizette -- 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
