Re: EREP query
On Tue, 11 Aug 2009 11:11:54 -0500, Richard Peurifoy wrote: >There is a SETLOGRC IGNORE command. >I don't know if this would allow you to scratch and reallocate it or >not. It will allow you to scratch and reallocate it, but then again, you can do that without SETLOGRC IGNORE. It still won't be usable until you IPL. But SETLOGRC IGNORE should be used if the OP plan's on increasing the size now. Probably better to wait to just prior to IPL to reallocate it so nothing is lost. >Remember to dump it before you do this if you want to preserve >whats already in it. >If this works then a SETLOGRC DATASET should restart it. > It will attempt to restart recording, but will have I/O errors. So it won't work or do what you think it should. The ERDS DEB is in *MASTER*. However, the OP could switch to LOGSTREAM on the fly. >Warning, I have never tried this. > 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 -- 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: EREP query
Richard Peurifoy wrote: Beesley, Paul wrote: Richard and Mark Thanks for the info and suggestions. I plan to increase LOGREC ( pity it needs an IPL, one of the few things that does so these days) - its only 59 tracks. Hadn't heard of IFCOFFLD, looks useful There is a SETLOGRC IGNORE command. I don't know if this would allow you to scratch and reallocate it or not. Remember to dump it before you do this if you want to preserve whats already in it. If this works then a SETLOGRC DATASET should restart it. Warning, I have never tried this. Also, the new one probably needs to be on the same volume. -- Richard -- 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: EREP query
Beesley, Paul wrote: Richard and Mark Thanks for the info and suggestions. I plan to increase LOGREC ( pity it needs an IPL, one of the few things that does so these days) - its only 59 tracks. Hadn't heard of IFCOFFLD, looks useful There is a SETLOGRC IGNORE command. I don't know if this would allow you to scratch and reallocate it or not. Remember to dump it before you do this if you want to preserve whats already in it. If this works then a SETLOGRC DATASET should restart it. Warning, I have never tried this. -- Richard -- 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: EREP query
Richard and Mark Thanks for the info and suggestions. I plan to increase LOGREC ( pity it needs an IPL, one of the few things that does so these days) - its only 59 tracks. Hadn't heard of IFCOFFLD, looks useful Regards Paul -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richard Peurifoy Sent: 11 August 2009 16:50 To: IBM-MAIN@bama.ua.edu Subject: Re: EREP query IFCEREP1 downloads the MDR's at the time it runs (Z EOD also does this). I think they also get downloaded if the counters overflow. You should increase the size of you LOGREC or switch to the system logger. If your LOGREC is full, and you don't want to loose the MDR's you can run IFCOFFLD which dumps/clears LOGREC without downloading the MDR's. -- Richard -- 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 ___ Atos Origin and Atos Consulting are trading names used by the Atos Origin group. The following trading entities are registered in England and Wales: Atos Origin IT Services UK Limited (registered number 01245534) and Atos Consulting Limited (registered number 04312380). The registered office for each is at 4 Triton Square, Regents Place, London, NW1 3HG.The VAT No. for each is: GB232327983 This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos Origin therefore can accept no liability for any errors or their content. Although Atos Origin endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos Origin by email. ___ -- 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: EREP query
Beesley, Paul wrote: We run a job every day at 06:30 to clear LOGREC and write to a history file ( JCL below ). Every day without fail the following message is issued while the job is running. *IFB081I LOGREC DATA SET IS FULL,06.30.58, DSN=SYS1.FIF2.LOGREC When I check LOGREC, its full of MDR records for every DASD volume in the known universe as at 06:30. Why is this happening and how can I stop it ? There's not much point clearing logrec only for it to fill up again with useless MDR records. This caused us to have no valid logrec records for IBM the other day after a system outage ... //JS010 EXEC PGM=IFCEREP1,TIME=10, //PARM='LINECT=60,ACC=Y,HIST=N,ZERO=Y,SYSUM=Y' //SERLOG DD DSN=SYS1.FIF2.LOGREC,DISP=SHR //ACCDEV DD DSN=SYS3.FIF2.EREPHIST, //DISP=(NEW,CATLG,DELETE), //SPACE=(2000,(3000,3000),RLSE), //AVGREC=U, //LRECL=2000, //RECFM=VB //DIRECTWK DD UNIT=SYSALLDA,SPACE=(CYL,(5,5)) //TOURIST DD SYSOUT=* //EREPPT DD SYSOUT=* //SYSINDD DUMMY,DCB=BLKSIZE=80 IFCEREP1 downloads the MDR's at the time it runs (Z EOD also does this). I think they also get downloaded if the counters overflow. You should increase the size of you LOGREC or switch to the system logger. If your LOGREC is full, and you don't want to loose the MDR's you can run IFCOFFLD which dumps/clears LOGREC without downloading the MDR's. -- Richard -- 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: EREP query
On Tue, 11 Aug 2009 14:51:52 +0100, Beesley, Paul wrote: >We run a job every day at 06:30 to clear LOGREC and write to a history >file ( JCL below ). >Every day without fail the following message is issued while the job is >running. >*IFB081I LOGREC DATA SET IS FULL,06.30.58, > DSN=SYS1.FIF2.LOGREC >When I check LOGREC, its full of MDR records for every DASD volume in >the known universe as at 06:30. >Why is this happening and how can I stop it ? There's not much point >clearing logrec only for it to fill up again with useless MDR records. >This caused us to have no valid logrec records for IBM the other day >after a system outage ... > 1) Have you looked into what those MDR records are? 2) How big is your LOGREC data set and why not just make it large enough to handle whatever the "normal" activity would be PLUS a large fudge factor for abnormal activity? 3) Have you considered using the system logger for LOGREC since you wouldn't run into a full condition for some unexpected abnormal activity (unless your DASD pool fills up)? -- 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
EREP query
We run a job every day at 06:30 to clear LOGREC and write to a history file ( JCL below ). Every day without fail the following message is issued while the job is running. *IFB081I LOGREC DATA SET IS FULL,06.30.58, DSN=SYS1.FIF2.LOGREC When I check LOGREC, its full of MDR records for every DASD volume in the known universe as at 06:30. Why is this happening and how can I stop it ? There's not much point clearing logrec only for it to fill up again with useless MDR records. This caused us to have no valid logrec records for IBM the other day after a system outage ... //JS010 EXEC PGM=IFCEREP1,TIME=10, //PARM='LINECT=60,ACC=Y,HIST=N,ZERO=Y,SYSUM=Y' //SERLOG DD DSN=SYS1.FIF2.LOGREC,DISP=SHR //ACCDEV DD DSN=SYS3.FIF2.EREPHIST, //DISP=(NEW,CATLG,DELETE), //SPACE=(2000,(3000,3000),RLSE), //AVGREC=U, //LRECL=2000, //RECFM=VB //DIRECTWK DD UNIT=SYSALLDA,SPACE=(CYL,(5,5)) //TOURIST DD SYSOUT=* //EREPPT DD SYSOUT=* //SYSINDD DUMMY,DCB=BLKSIZE=80 Paul Beesley ___ Atos Origin and Atos Consulting are trading names used by the Atos Origin group. The following trading entities are registered in England and Wales: Atos Origin IT Services UK Limited (registered number 01245534) and Atos Consulting Limited (registered number 04312380). The registered office for each is at 4 Triton Square, Regents Place, London, NW1 3HG.The VAT No. for each is: GB232327983 This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos Origin therefore can accept no liability for any errors or their content. Although Atos Origin endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos Origin by email. ___ -- 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
