Re: IEFACTRT problem - z/OS 1.11
OK, the IEF032I (no IEF374I messages in the JES log) messages have no TCB or SRB so I guess that this is a red herring. That goes to show how close we look at our SYSOUTs...lol. Thanks, Jon -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Tuesday, January 04, 2011 11:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 On Tue, 4 Jan 2011 09:48:51 -0500, Veilleux, Jon L veilleu...@aetna.com wrote: Mark, thanks for the explanation. However, I find it strange that almost all of the jobs I have looked at in our archives have no TCB or SRB time. I can't believe that all of them are that short running, but who knows? Jon It's easy enough to verify, just look at the IEF374I message in JESYSMSG. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: IEFACTRT problem - z/OS 1.11
On Wed, 5 Jan 2011 07:07:50 -0500, Veilleux, Jon L veilleu...@aetna.com wrote: OK, the IEF032I (no IEF374I messages in the JES log) messages have no TCB or SRB so I guess that this is a red herring. That goes to show how close we look at our SYSOUTs...lol. Thanks, Jon Well, that would mean z/OS 1.12, correct? This thread is about z/OS 1.11 so that must be your problem! :-) Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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: IEFACTRT problem - z/OS 1.11
Ok, my last response that I posted mere seconds before walking out the door last night might have been less than helpful. Those changes were for the version of the IEFACTRT exit that prints the following: - --TIMINGS (MINS.)-- -STEP JOBNAME STEPNAME PROCSTEP PROGRAM RC EXCPTCBSRB CLOCK SERV SERVCLASS - 1 SYS08SM2 DUMP1 IFASMFDP00 452K.40.054.3 560K BATCHDEF IEF404I SYS08SM2 - ENDED - TIME=10.38.01 -SYS08SM2 ENDED. NAME-NEALETOTAL TCB CPU TIME= .40 TOTAL ELAPSED TIME= 4.34 As you can see, I made other changes to the exit from the IBM supplied version. The SuperC listing SHOULD give you enough information to make your changes, but I can send you the whole modified exit if you would like. Neal -- 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: IEFACTRT problem - z/OS 1.11
The exit does not provide CPU (TCB and SRB) counts. It is always helpful when describing a problem to be as specific as possible. By does not provide do you mean that the fields are 0? Do you mean that the address is 0? (This would be expected for job termination entries to IEFACTRT, but not for step termination) Curious: why did you make up your own field names? The IEEACTRT sample has PARMNJOB and PARMNSTP. If the field is 0, then my only guess is that you're looking at data for a short-running job that has not accumulated 1/100 of a second of time. Peter Relson z/OS Core Technology Design -- 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: IEFACTRT problem - z/OS 1.11
What I meant was that all of the CPU Time fields are zero, both in JESYSMSG and in JESMSGLG. Elapsed time fields are OK. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Peter Relson Sent: Tuesday, January 04, 2011 4:10 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 The exit does not provide CPU (TCB and SRB) counts. It is always helpful when describing a problem to be as specific as possible. By does not provide do you mean that the fields are 0? Do you mean that the address is 0? (This would be expected for job termination entries to IEFACTRT, but not for step termination) Curious: why did you make up your own field names? The IEEACTRT sample has PARMNJOB and PARMNSTP. If the field is 0, then my only guess is that you're looking at data for a short-running job that has not accumulated 1/100 of a second of time. Peter Relson z/OS Core Technology Design -- 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 לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- 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: IEFACTRT problem - z/OS 1.11
On Mon, 3 Jan 2011 10:31:07 -0500, Veilleux, Jon L veilleu...@aetna.com wrote: It's not in MLPA and I looked back through several years of listings and it doesn't seem to have worked for quite a while. I guess no one is looking at those fields... Jon et. al., I looked when I upgraded to z/OS 1.11 and retrofitted my code into the samplib version. I just looked at a few jobs again (again) and it appears to be correct. I am using the SAMPLIB version, with the change described by OA31624, along with a bunch of code inserted to create an EXCP flower box on JESYSMSG (the code I retrofitted from past IEFACTRT versions I used). Maybe you (and others) are not aware those times are in minutes, so they often show up as .00 for TCB and SRB for short steps. Because of the way rounding / shifting is done, you need at least .60 seconds of TCB time to even get .01 minutes of TCB to show up on the joblog. Of course the same applies to SRB and it is even more likely to show .00. Go ahead and try some tests.. perhaps running a REXX in batch with a (large) DO loop. Cheers, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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: IEFACTRT problem - z/OS 1.11
Mark, thanks for the explanation. However, I find it strange that almost all of the jobs I have looked at in our archives have no TCB or SRB time. I can't believe that all of them are that short running, but who knows? Jon -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Tuesday, January 04, 2011 9:36 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 On Mon, 3 Jan 2011 10:31:07 -0500, Veilleux, Jon L veilleu...@aetna.com wrote: It's not in MLPA and I looked back through several years of listings and it doesn't seem to have worked for quite a while. I guess no one is looking at those fields... Jon et. al., I looked when I upgraded to z/OS 1.11 and retrofitted my code into the samplib version. I just looked at a few jobs again (again) and it appears to be correct. I am using the SAMPLIB version, with the change described by OA31624, along with a bunch of code inserted to create an EXCP flower box on JESYSMSG (the code I retrofitted from past IEFACTRT versions I used). Maybe you (and others) are not aware those times are in minutes, so they often show up as .00 for TCB and SRB for short steps. Because of the way rounding / shifting is done, you need at least .60 seconds of TCB time to even get .01 minutes of TCB to show up on the joblog. Of course the same applies to SRB and it is even more likely to show .00. Go ahead and try some tests.. perhaps running a REXX in batch with a (large) DO loop. Cheers, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: IEFACTRT problem - z/OS 1.11
You're not running Ops/MVS 11.8 are you ? If so, have you applied RO24950, RO24031, RO23310, and RO20991? I noticed the same symptoms in IEFACTRT because I had OpsMVS running in enclave mode by mistake. If not .. ignore this ... Regards Paul -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Veilleux, Jon L Sent: 04 January 2011 14:49 To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 Mark, thanks for the explanation. However, I find it strange that almost all of the jobs I have looked at in our archives have no TCB or SRB time. I can't believe that all of them are that short running, but who knows? Jon ___ 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: IEFACTRT problem - z/OS 1.11
No, we don't use Ops/MVS. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Beesley, Paul Sent: Tuesday, January 04, 2011 10:01 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 You're not running Ops/MVS 11.8 are you ? If so, have you applied RO24950, RO24031, RO23310, and RO20991? I noticed the same symptoms in IEFACTRT because I had OpsMVS running in enclave mode by mistake. If not .. ignore this ... Regards Paul -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Veilleux, Jon L Sent: 04 January 2011 14:49 To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 Mark, thanks for the explanation. However, I find it strange that almost all of the jobs I have looked at in our archives have no TCB or SRB time. I can't believe that all of them are that short running, but who knows? Jon ___ 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: IEFACTRT problem - z/OS 1.11
On Tue, 4 Jan 2011 09:48:51 -0500, Veilleux, Jon L veilleu...@aetna.com wrote: Mark, thanks for the explanation. However, I find it strange that almost all of the jobs I have looked at in our archives have no TCB or SRB time. I can't believe that all of them are that short running, but who knows? Jon It's easy enough to verify, just look at the IEF374I message in JESYSMSG. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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: IEFACTRT problem - z/OS 1.11
On Mon, 3 Jan 2011 09:33:38 +0200, #1490;#1491;#1497; amp;#1489;#1503; #1488;#1489;#1497; gad...@malam.com wrote: Hi, We are testing z/OS 1.11. We use the supplied sample for IEFACTRT provided in SYS1.SAMPLIB(IEEACTRT). The exit does not provide CPU (TCB and SRB) counts. All other values seem to be OK. Has anyone seen the problem? Gadi, Have a look at APAR OA31624. Roger -- 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: IEFACTRT problem - z/OS 1.11
Thanks, I saw that, but it doesn't say anything about CPU time. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Roger Lowe Sent: Monday, January 03, 2011 4:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 On Mon, 3 Jan 2011 09:33:38 +0200, #1490;#1491;#1497; amp;#1489;#1503; #1488;#1489;#1497; gad...@malam.com wrote: Hi, We are testing z/OS 1.11. We use the supplied sample for IEFACTRT provided in SYS1.SAMPLIB(IEEACTRT). The exit does not provide CPU (TCB and SRB) counts. All other values seem to be OK. Has anyone seen the problem? Gadi, Have a look at APAR OA31624. Roger -- 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 לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- 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: IEFACTRT problem - z/OS 1.11
And it doesn't seem to help. I still don't get valid TCB or SRB times after I installed the new exit. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of ??? ?? ??? Sent: Monday, January 03, 2011 9:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 Thanks, I saw that, but it doesn't say anything about CPU time. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Roger Lowe Sent: Monday, January 03, 2011 4:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 On Mon, 3 Jan 2011 09:33:38 +0200, #1490;#1491;#1497; amp;#1489;#1503; #1488;#1489;#1497; gad...@malam.com wrote: Hi, We are testing z/OS 1.11. We use the supplied sample for IEFACTRT provided in SYS1.SAMPLIB(IEEACTRT). The exit does not provide CPU (TCB and SRB) counts. All other values seem to be OK. Has anyone seen the problem? Gadi, Have a look at APAR OA31624. Roger -- 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 לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: IEFACTRT problem - z/OS 1.11
Check to see if you have the module in MLPA (IEALPAxx). I know we do. Regards, John K From: Veilleux, Jon L veilleu...@aetna.com To: IBM-MAIN@bama.ua.edu Date: 01/03/2011 09:17 AM Subject:Re: IEFACTRT problem - z/OS 1.11 And it doesn't seem to help. I still don't get valid TCB or SRB times after I installed the new exit. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of ??? ?? ??? Sent: Monday, January 03, 2011 9:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 Thanks, I saw that, but it doesn't say anything about CPU time. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Roger Lowe Sent: Monday, January 03, 2011 4:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 On Mon, 3 Jan 2011 09:33:38 +0200, #1490;#1491;#1497; amp;#1489;#1503; #1488;#1489;#1497; gad...@malam.com wrote: Hi, We are testing z/OS 1.11. We use the supplied sample for IEFACTRT provided in SYS1.SAMPLIB (IEEACTRT). The exit does not provide CPU (TCB and SRB) counts. All other values seem to be OK. Has anyone seen the problem? Gadi, Have a look at APAR OA31624. Roger -- 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 לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: IEFACTRT problem - z/OS 1.11
It's not in MLPA and I looked back through several years of listings and it doesn't seem to have worked for quite a while. I guess no one is looking at those fields... -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John P Kalinich Sent: Monday, January 03, 2011 10:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 Check to see if you have the module in MLPA (IEALPAxx). I know we do. Regards, John K From: Veilleux, Jon L veilleu...@aetna.com To: IBM-MAIN@bama.ua.edu Date: 01/03/2011 09:17 AM Subject:Re: IEFACTRT problem - z/OS 1.11 And it doesn't seem to help. I still don't get valid TCB or SRB times after I installed the new exit. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of ??? ?? ??? Sent: Monday, January 03, 2011 9:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 Thanks, I saw that, but it doesn't say anything about CPU time. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Roger Lowe Sent: Monday, January 03, 2011 4:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 On Mon, 3 Jan 2011 09:33:38 +0200, #1490;#1491;#1497; amp;#1489;#1503; #1488;#1489;#1497; gad...@malam.com wrote: Hi, We are testing z/OS 1.11. We use the supplied sample for IEFACTRT provided in SYS1.SAMPLIB (IEEACTRT). The exit does not provide CPU (TCB and SRB) counts. All other values seem to be OK. Has anyone seen the problem? Gadi, Have a look at APAR OA31624. Roger -- 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 לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: IEFACTRT problem - z/OS 1.11
Our module is in LPA. Gadi From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Veilleux, Jon L [veilleu...@aetna.com] Sent: 03 January 2011 17:31 To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 It's not in MLPA and I looked back through several years of listings and it doesn't seem to have worked for quite a while. I guess no one is looking at those fields... -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John P Kalinich Sent: Monday, January 03, 2011 10:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 Check to see if you have the module in MLPA (IEALPAxx). I know we do. Regards, John K From: Veilleux, Jon L veilleu...@aetna.com To: IBM-MAIN@bama.ua.edu Date: 01/03/2011 09:17 AM Subject:Re: IEFACTRT problem - z/OS 1.11 And it doesn't seem to help. I still don't get valid TCB or SRB times after I installed the new exit. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of ??? ?? ??? Sent: Monday, January 03, 2011 9:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 Thanks, I saw that, but it doesn't say anything about CPU time. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Roger Lowe Sent: Monday, January 03, 2011 4:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IEFACTRT problem - z/OS 1.11 On Mon, 3 Jan 2011 09:33:38 +0200, #1490;#1491;#1497; amp;#1489;#1503; #1488;#1489;#1497; gad...@malam.com wrote: Hi, We are testing z/OS 1.11. We use the supplied sample for IEFACTRT provided in SYS1.SAMPLIB (IEEACTRT). The exit does not provide CPU (TCB and SRB) counts. All other values seem to be OK. Has anyone seen the problem? Gadi, Have a look at APAR OA31624. Roger -- 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 לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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 לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed
Re: IEFACTRT problem - z/OS 1.11
Here is a Superc listing of the changes I made for z/OS 1.11. Good Luck! I - L R01,PARMSPTALOAD STEP TCB CPU TIME ADDR RPL=3 00368 00368 D - L R01,PARMSTPCLOAD STEP TCB CPU TIME ADDR I - ICM R01,KF,K0(R01) LOAD STEP TCB CPU TIME MSPIPOI00369 00369 D - ICM R01,K7,K0(R01) LOAD STEP TCB CPU TIME MSPIPOI I - *LAR01,K0(,R01)ZERO HIGH ORDER BYTE00370 00370 D - LAR01,K0(,R01)ZERO HIGH ORDER BYTE MAT= 81 I - MVC WTO1TXT+LINE4E(L'LINE4E),DWORD+L'DWORD-L'LINE4E- K1RPL=1 00452 00452 D - MVC WTO1TXT+LINE4E(L'LINE4E),DWORD+L'DWORD-L'LINE4E- K2 MAT= 279 I -PU TIME=XXX.XX TOTAL ELAPSED TIME=.XX' RPL=1 00732 00732 D -PU TIME=XXX.XX TOTAL ELAPSED TIME=.X' MAT= 6 I - LINE4E EQU 90,7OFFSET OF ELAPSED TIME IN LINE4 TEXT RPL=1 00739 00739 D - LINE4E EQU 90,6OFFSET OF ELAPSED TIME IN LINE4 TEXT MAT= 67 I - PARMJPTA DSFPTR TO JOB PROCESSOR TIMEINS=3 00807 00807 I - PARMSPTA DSFPTR TO STEP PROCESSOR TIME 00808 I - PARMSSNA DSFPTR TO SUBSYSTEM NAME 00809 -- 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: IEFACTRT
I can't help solve the problem but I am curious if either vendor's documentation explains why it needs this SMF exit. -Original Message- From: Michele Gionfriddo [mailto:[EMAIL PROTECTED] Sent: Thursday, November 27, 2008 10:01 AM To: IBM-MAIN@bama.ua.edu Subject: IEFACTRT Hi. I have two product that need two different customized mod iefactrt. Every product gives a sample of iefactrt, but these two sample are very different. I manage system software with SMP/E, and i don't know the way to resolve the problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT
The name IEFACTRT is the default name for an exit at that point. By means of PROGxx, SETPROG EXIT or CSVDYNEX you can specify a module with a different name, and more importantly, more than one of them. You may have to consider how the exit return codes are used, I think by default the RC from the first exit is used - check out the doc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT
The name for an IEFACTRT exit doesn't have to be IEFACTRT. You can use the PROGxx member of parmlib or the SETPROG command to define more than one module name that will be invoked for IEFACTRT processing. Refer to z/OS MVS Initialization and Tuning Reference for more information. So, you can install the two IEFACTRT exits under two different names. If this is new to your installation, you may wish to experiment on a test LPAR, Bill On Thu, 27 Nov 2008 12:01:15 -0600, Michele Gionfriddo [EMAIL PROTECTED] wrote: Hi. I have two product that need two different customized mod iefactrt. Every product gives a sample of iefactrt, but these two sample are very different. I manage system software with SMP/E, and i don't know the way to resolve the problem. Thank. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT
I would advise going back to both product vendors and encourage them to either : (1) Supply their IEFACTRT exits using their own product prefix on the module name (eg XYZACTRT) and then have code within their product to perform the required CSVDYNEX steps to install it (2) Supply instructions on how to install their IEFACTRT exit alongside existing ISV or site IEFACTRT exits. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Michele Gionfriddo Sent: 27 November 2008 18:01 To: IBM-MAIN@bama.ua.edu Subject: IEFACTRT Hi. I have two product that need two different customized mod iefactrt. Every product gives a sample of iefactrt, but these two sample are very different. I manage system software with SMP/E, and i don't know the way to resolve the problem. Thank. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT exit
Thanks. We'll look into that parameter. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of ITURIEL DO NASCIMENTO NETO Sent: Tuesday, January 22, 2008 1:26 PM To: IBM-MAIN@BAMA.UA.EDU Subject: RES: IEFACTRT exit And you can try VSM CHECKREGIONLOSS parameter of DIAGxx Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto Banco Bradesco S/A 4254/DPCD Alphaville Engenharia de Software - Sistemas Operacionais Mainframes Tel: 55 11 4197-2021 Fax: 55 11 4197-2814 |-Mensagem original- |De: IBM Mainframe Discussion List |[mailto:[EMAIL PROTECTED] Em nome de O'Connor, Ruth Enviada em: |terça-feira, 22 de janeiro de 2008 16:15 |Para: IBM-MAIN@BAMA.UA.EDU |Assunto: Re: IEFACTRT exit | |Thanks for the information and suggestions. DAE doesn't show anything |recent for the LPAR in question. | |We're going for the simple minded plan, too! We already stop and |restart our production initiators freqently, for other reasons, and we |will now do the same for the applications development inits. | HTMLfont face=Tahoma size=1HRAVISO LEGAL brEsta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. HTMLfont face=Tahoma size=1HRLEGAL ADVICE brThis message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT exit
Thanks for the information and suggestions. DAE doesn't show anything recent for the LPAR in question. We're going for the simple minded plan, too! We already stop and restart our production initiators freqently, for other reasons, and we will now do the same for the applications development inits. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Skip Robinson Sent: Friday, January 18, 2008 6:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IEFACTRT exit Initiators have a historic tendency for storage problems, especially the longer they run. Fixing your WTO problem by restarting the initiator is a classic workaround for such problems. It's possible that you're taking abends you're not seeing because of DAE dump suppression. As a first pass, look in IPCS at the DAE utility (3.5) for getmain failures. If nothing shows up, when the problem occurs again, set a nonspecific PER SLIP trap for a job name that is known or likely to fail. Unfortunately, finding a getmain failure does not solve the problem, which is probably a result of storage fragmentation over time. We had a similar problem once, and our simple minded plan was to stop and restart initiators at intervals frequent enough to reduce the effects of fragmentation. Diagnosis of the root cause will not be simple. . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Shane [EMAIL PROTECTED] .AU To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: IEFACTRT exit 01/18/2008 02:50 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU On Fri, 2008-01-18 at 16:19 -0500, O'Connor, Ruth wrote: Any ideas about what could have happened to the initiator to affect an smf exit's WTOs? Have a look at the subpool for any getmains. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT exit
Initiators have a historic tendency for storage problems, especially the longer they run. Fixing your WTO problem by restarting the initiator is a classic workaround for such problems. It's possible that you're taking abends you're not seeing because of DAE dump suppression. As a first pass, look in IPCS at the DAE utility (3.5) for getmain failures. If nothing shows up, when the problem occurs again, set a nonspecific PER SLIP trap for a job name that is known or likely to fail. Unfortunately, finding a getmain failure does not solve the problem, which is probably a result of storage fragmentation over time. We had a similar problem once, and our simple minded plan was to stop and restart initiators at intervals frequent enough to reduce the effects of fragmentation. Diagnosis of the root cause will not be simple. . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Shane [EMAIL PROTECTED] .AU To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: IEFACTRT exit 01/18/2008 02:50 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU On Fri, 2008-01-18 at 16:19 -0500, O'Connor, Ruth wrote: Any ideas about what could have happened to the initiator to affect an smf exit's WTOs? Have a look at the subpool for any getmains. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT exit
On Fri, 2008-01-18 at 16:19 -0500, O'Connor, Ruth wrote: Any ideas about what could have happened to the initiator to affect an smf exit's WTOs? Have a look at the subpool for any getmains. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT exit
Ruth, It is possible that the WTO operation in the exit is failing - maybe due to a overlay in the exit working storage or some other bad parameter list error. I would check any code in the exit that varies with userid/jobname values and also check the bounds of any other variables around the WTO parmlist in the working storage. It would help if you posted the source code as some bright spark on here might see something that you missed. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of O'Connor, Ruth Sent: 18 January 2008 15:45 To: IBM-MAIN@BAMA.UA.EDU Subject: IEFACTRT exit Hello We have an intermittent problem with IEFACTRT and are wondering if anyone else has ever seen this phenomenon. We're running z/OS 1.7 with Top Secret 9.0 but the problem goes back at least several years and software levels. Like many shops, we use the exit to write WTO messages at the end of each batch job step. Every once in a while a user reports that the messages are no longer being written for his batch jobs, even though the messages were being produced for that user the previous day (or previous hour) and the messages are still being produced for other users' jobs. The messages don't come back for that user's batch jobs until the next time we IPL the LPAR. We have never been able to figure out what causes this problem. The type 30, subtype 4, smf records are still being cut for the jobs without the messages. I have looked through the exit code without finding anything useful. We're wondering if something prevents the IEFACTRT exit from being called for certain users. This week the problem has been reported in our applications development LPAR. For at least 3 userids (or ACIDs in Top Secret terminology) the messages stopped appearing early Monday morning. There is nothing in logrec at that time and I don't see anything strange in syslog, either. A search of the archives turned up one thread about a similar problem at a DR site but there didn't appear to be any resolution. Thanks in advance for any suggestions. Ruth O'Connor Senior Systems Software Specialist Boston University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT exit
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of O'Connor, Ruth Sent: Friday, January 18, 2008 3:20 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IEFACTRT exit Richard, That's a good question. We do use IEFYS to write some messages to JESYSMSG but the messages that were missing are WTOs that we send to syslog and to JESMSGLG. Until you asked about IEFYS I hadn't noticed that the JESYSMSG messages did appear correctly in the affected jobs. That means the smf exit was being taken, killing one of my theories. Since my first email we have figured out that all the problem jobs executed in one JES2 initiator. Stopping and restarting that initiator fixed the problem for now. The affected users all happened to be using the same jobclass and were getting the same initiator consistently. The userid seems to be irrelevant after all. We still don't know why the problem occurred, though. There were no obvious errors in the initiator; no syslog message that we could ask the automation group to react to in the future; no logrec entries. Any ideas about what could have happened to the initiator to affect an smf exit's WTOs? Thanks very much, Ruth I don't know, but I saw the following in the WTO description for RC=30: quote Meaning: Environmental error. For routing code 11, the required resource was not available and the request was ignored. For any other routing code, the request was processed. /quote -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT exit
I haven't seen such a problem in Top Secret or in IEFACTRT; I'd look at the userids involved. Are they receiving other WTOs? Does NOTIFY= get through to them? Have their TSO profiles gotten set to NOINTERCOM? Do they have full TSO/E log datasets? Is a JES2 MAS devouring messages for duplicate userids logged on to multiple members? Bob O'Connor, Ruth wrote: Hello We have an intermittent problem with IEFACTRT and are wondering if anyone else has ever seen this phenomenon. We're running z/OS 1.7 with Top Secret 9.0 but the problem goes back at least several years and software levels. Like many shops, we use the exit to write WTO messages at the end of each batch job step. Every once in a while a user reports that the messages are no longer being written for his batch jobs, even though the messages were being produced for that user the previous day (or previous hour) and the messages are still being produced for other users' jobs. The messages don't come back for that user's batch jobs until the next time we IPL the LPAR. We have never been able to figure out what causes this problem. The type 30, subtype 4, smf records are still being cut for the jobs without the messages. I have looked through the exit code without finding anything useful. We're wondering if something prevents the IEFACTRT exit from being called for certain users. This week the problem has been reported in our applications development LPAR. For at least 3 userids (or ACIDs in Top Secret terminology) the messages stopped appearing early Monday morning. There is nothing in logrec at that time and I don't see anything strange in syslog, either. A search of the archives turned up one thread about a similar problem at a DR site but there didn't appear to be any resolution. Thanks in advance for any suggestions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT exit
On Fri, 18 Jan 2008 10:44:55 -0500, O'Connor, Ruth [EMAIL PROTECTED] wrote: Hello We have an intermittent problem with IEFACTRT and are wondering if anyone else has ever seen this phenomenon. We're running z/OS 1.7 with Top Secret 9.0 but the problem goes back at least several years and software levels. Like many shops, we use the exit to write WTO messages at the end of each batch job step. Every once in a while a user reports that the messages are no longer being written for his batch jobs, even though the messages were being produced for that user the previous day (or previous hour) and the messages are still being produced for other users' jobs. The messages don't come back for that user's batch jobs until the next time we IPL the LPAR. *Snip* Ruth, the IEFACTRT that we run (for Pace / KOMMAND), ALSO echos the WTO messages for that STEP, etc. info in SYSLOG. Does yours, even when it does NOT for the users? Might want to check that? TTFN, Mark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT exit
O'Connor, Ruth wrote: Hello We have an intermittent problem with IEFACTRT and are wondering if anyone else has ever seen this phenomenon. We're running z/OS 1.7 with Top Secret 9.0 but the problem goes back at least several years and software levels. Like many shops, we use the exit to write WTO messages at the end of each batch job step. Every once in a while a user reports that the messages are no longer being written for his batch jobs, even though the messages were being produced for that user the previous day (or previous hour) and the messages are still being produced for other users' jobs. The messages don't come back for that user's batch jobs until the next time we IPL the LPAR. We have never been able to figure out what causes this problem. The type 30, subtype 4, smf records are still being cut for the jobs without the messages. I have looked through the exit code without finding anything useful. We're wondering if something prevents the IEFACTRT exit from being called for certain users. This week the problem has been reported in our applications development LPAR. For at least 3 userids (or ACIDs in Top Secret terminology) the messages stopped appearing early Monday morning. There is nothing in logrec at that time and I don't see anything strange in syslog, either. A search of the archives turned up one thread about a similar problem at a DR site but there didn't appear to be any resolution. Thanks in advance for any suggestions. Ruth O'Connor Senior Systems Software Specialist Boston University Sorry, sent this to the newsgroup rather than the list the first time. Are these realy WTO's, or are you using the IEFYS interface to write messages to JESYSMSG (where the allocation messages are written). -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT exit
Richard, That's a good question. We do use IEFYS to write some messages to JESYSMSG but the messages that were missing are WTOs that we send to syslog and to JESMSGLG. Until you asked about IEFYS I hadn't noticed that the JESYSMSG messages did appear correctly in the affected jobs. That means the smf exit was being taken, killing one of my theories. Since my first email we have figured out that all the problem jobs executed in one JES2 initiator. Stopping and restarting that initiator fixed the problem for now. The affected users all happened to be using the same jobclass and were getting the same initiator consistently. The userid seems to be irrelevant after all. We still don't know why the problem occurred, though. There were no obvious errors in the initiator; no syslog message that we could ask the automation group to react to in the future; no logrec entries. Any ideas about what could have happened to the initiator to affect an smf exit's WTOs? Thanks very much, Ruth -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Richard Peurifoy Sent: Friday, January 18, 2008 3:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IEFACTRT exit O'Connor, Ruth wrote: Hello We have an intermittent problem with IEFACTRT and are wondering if anyone else has ever seen this phenomenon. We're running z/OS 1.7 with Top Secret 9.0 but the problem goes back at least several years and software levels. Like many shops, we use the exit to write WTO messages at the end of each batch job step. Every once in a while a user reports that the messages are no longer being written for his batch jobs, even though the messages were being produced for that user the previous day (or previous hour) and the messages are still being produced for other users' jobs. The messages don't come back for that user's batch jobs until the next time we IPL the LPAR. We have never been able to figure out what causes this problem. The type 30, subtype 4, smf records are still being cut for the jobs without the messages. I have looked through the exit code without finding anything useful. We're wondering if something prevents the IEFACTRT exit from being called for certain users. This week the problem has been reported in our applications development LPAR. For at least 3 userids (or ACIDs in Top Secret terminology) the messages stopped appearing early Monday morning. There is nothing in logrec at that time and I don't see anything strange in syslog, either. A search of the archives turned up one thread about a similar problem at a DR site but there didn't appear to be any resolution. Thanks in advance for any suggestions. Ruth O'Connor Senior Systems Software Specialist Boston University Sorry, sent this to the newsgroup rather than the list the first time. Are these realy WTO's, or are you using the IEFYS interface to write messages to JESYSMSG (where the allocation messages are written). -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT exit
On Jan 18, 2008, at 4:50 PM, Shane wrote: On Fri, 2008-01-18 at 16:19 -0500, O'Connor, Ruth wrote: Any ideas about what could have happened to the initiator to affect an smf exit's WTOs? Have a look at the subpool for any getmains. I would take a look at logrec to see if there were any software hits somewhere around the time this started happening. You may see some abend or something that at least you can do a search in IBMLINK (assuming its available). Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT modifications
Jaco Kruger wrote: We were requested to display the JOB MAXCC on the SYSLOG on Job completion What z/OS level? We display the return codes correctly except when a step is FLUSHED because of Condition Code settings or when the job is FLUSHED e.g. when JCL ERROR occured. What message(s) do you see? Any output from IEFACTRT? Care to show declarations for RCJ and RWORK? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT modifications
--snip--- We were requested to display the JOB MAXCC on the SYSLOG on Job completion We customized our IEFACTRT exit for the required changes. We display the return codes correctly except when a step is FLUSHED because of Condition Code settings or when the job is FLUSHED e.g. when JCL ERROR occured. Can anyone give us some advice on what we are doing wrong Below is the code we changed ---remainder snipped- You're not doing anything wrong, Jaco. That exit is not invoked under the conditions you mention. If the job is flushed due to a JCL error, you're not going to get a MAXCC because nothing is executed to create a CC. If the job is flushed due to Condition Codes, you might add a IEFBR14 step at the end, with COND= values that will force it to execute, or with IF/THEN/ELSE logic that forces it to run in any case. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT modifications
Our Z/OS Level is 1.8 Following is the output in the SYSLOG IEF404I DSYSPJKA - ENDED - TIME=16.27.19 -DSYSPJKA ENDED. NAME-TEST TOTAL TCB CPU TIME= .00 TOTAL ELAPSED TIME=.0 MAXCC=0 $HASP395 DSYSPJKA ENDED SE '16.27.19 JOB04508 $HASP165 DSYSPJKA ENDED AT TST1 MAXCC=16' LOGON,USER=(DSYSPJK) Regards Jaco Kruger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT modifications
Here is the code that we use: NOFLUSH TMK0(R01),SMF30ABDDID IT ABEND?MSEIPO4 BOSTPABENDYES, GO CONVERT ABEND CODE N R00,=A(X'FFF') ZERO UNUSED PORTION CVD R00,RWORK GET ADDRESS OF COND FIELD MVC RC-K1(L'RC+K1),=X'402020212020' MOVE IN EDIT MASK EDRC-K1(L'RC+K1),RWORK+K5 CONVERT RET CODE TO CHAR B PRETEXT BR TO RETURN Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jaco Kruger Sent: Wednesday, December 05, 2007 3:03 AM To: IBM-MAIN@BAMA.UA.EDU Subject: IEFACTRT modifications We were requested to display the JOB MAXCC on the SYSLOG on Job completion We customized our IEFACTRT exit for the required changes. We display the return codes correctly except when a step is FLUSHED because of Condition Code settings or when the job is FLUSHED e.g. when JCL ERROR occured. Can anyone give us some advice on what we are doing wrong Below is the code we changed JOBTERM DS0H ENTRY ON JOB TERMINATION MVC WTO1TXT,LINE4 SET UP OUTPUT LINE MVC WTO1TXT+LINE4J(L'LINE4J),JMRJOB MOVE IN JOB NAME L R01,PARMPROGLOAD ADDR OF PROGRAMMER NAME MVC WTO1TXT+LINE4N(L'LINE4N),K0(R01) MOVE IN PROG NAME SLR R00,R00 ZERO REG LRR01,R00 ZERO REG 1 L R02,PARMJOBCLOAD JOB TCB CPU TIME ADDR ICM R01,K7,K0(R02) LOAD JOB TCB CPU TIME BAL R14,PCLOCK CONVERT TIME FOR OUTPUT MVC WTO1TXT+LINE4C(L'LINE4C),DWORD+L'DWORD-L'LINE4C-K1 LRR04,R09 GET RECORD ADDRESS MSEIPO4 A R04,SMF30TOFPOINT TO SS SEGMENT MSEIPO4 USING SMF30CMP,R04 LAR01,SMF30STI SLR R00,R00 ICM R00,K3,SMF30SCC GET COND CODE PRETCDEJ DS0H TMK0(R01),SMF30FLHWAS STEP FLUSHED MSEIPO4 BNO NOFLUSHJNO,BRANCH PAST MVC RCJ,=C'FLUSH'MOVE IN FLUSHED MESSAGE B MOVETXT BR TO RETURN NOFLUSHJ TMK0(R01),SMF30ABDDID IT ABEND?MSEI BOSTPABNDJYES, GO CONVERT ABEND CODE N R00,=A(X'FFF') ZERO UNUSED PORTION CVD R00,RWORK GET ADDRESS OF COND FIELD UNPK RCJ,RWORK GET ADDRESS OF COND FIELD OIRCJ+4,X'F0' B MOVETXT STPABNDJ DS0H CLM R00,2,=X'80'WAS IT A USER ABEND CODE? BLSYSABNDJNO, PROCESS SYSTEM ABEND CODE. N R00,=A(X'FFF') TURN OFF X'80' BIT CVD R00,RWORK CONVERT FOR OUTPUT MVC RCJ-K1(L'RCJ+K1),=X'402120202020' MOVE IN EDIT MASK EDRCJ-K1(L'RCJ+K1),RWORK+K5 CONVERT TO CHARACTER MVI RCJ,C'U' MOVE IN 'U' USER ABEND B MOVETXT BR TO RETURN SYSABNDJ STH R00,RWORK STORE ABEND CODE UNPK RWORK+K3(K5),RWORK(K3) ADD ZONES TO CC FIELD TRRWORK+K4(K3),TRTAB-C0 TRANSLATE TO CHARACTERS MVC RCJ+K2(L'RCJ-K2),RWORK+K4 MOVE TO OUTPUT LINE MVC RCJ(K2),=C'*S' MOVE IN S FOR SYSTEM ABEND MOVETXT DS0H MVC WTO1TXT+LINE4CC(L'LINE4CC),RCJ DROP R04 LINE4DCCL(LLINE2)' ' JOB TERMINATION MESSAGE LINE ORG LINE4 DCC' ' DCC' ENDED. NAME- TOTAL TCB CX PU TIME=.XX TOTAL ELAPSED TIME=.X MAXCC=X' *012345678901234567890123456789012345678901234567890123 * 50- 45678901234567890123456789012345678901234567890123456789 ORG LINE4+LLINE2
Re: IEFACTRT
With apologies in advance to Darren and the readers for bothering to reply. Ed, I was not the one challenging others recollections, you were. I was merely asking you why you challenge other people's memory when you know your own is subject, to use your words, parity errors. I am fairly sure 99% of the people that read my post below understood that point. Why couldn't you? Bob Shannon's post was not an attempt to provide all the details that Scott and Kirk subsequently provided and what he wrote was correct. Thanks to Scott and Kirk for the trip down memory lane. I was a customer of both companies and respected each very highly. Bob Richards -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Friday, August 04, 2006 9:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IEFACTRT On Aug 4, 2006, at 2:48 PM, Richards.Bob wrote: A subsequent post by Scott Barry filled in all the blanks. And it is not a case of whether Bob Shannon could be right, he *was* right. Why do you challenge the recollections of others when you freely admit to having an iffy memory? Bob Richards Bob, All of us are getting older (including you) and memory becomes subject to parity errors. I am surprised you think yours is any better than the rest of ours. Also there was at least one step Bob S omitted. so he was not 100 percent right. I would not ask such a question if I was 100 percent sure. I dropped a(n) acquisition and I will freely admit it. What's the big deal ? The 90's saw a great deal of take over and mergers and the like. LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. Seeing Beyond Money is a service mark of SunTrust Banks, Inc. [ST:XCL] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT
snip of Duquesne systems in Pittsburg snip Unfortunately the cost for the product was not cheap and I think that is what lead to the demise of the company Duquesne merged with Morino to form Legent. Legent was acquired by CA. Duquesne didn't die, it merely morphed. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT
Oh, yes. Duquesne's BDBF (Billing Data Base Facility, the MICS-alternative for smaller shops) lived on for a while during the morph of: Duquesne/Morino_Associates-Morino_Inc/Goal_Systems/BST-LEGENT-Computer_Associates/CA Could have been the phrase merger of equals was coined with the Morino/Duquesne combining forces and only until Goal Systems came into the picture did anyone really see that having to company Headquarters (Pittsburgh and McLean, VA) was ill-conceived and somewhat misleading. Took the likes of Dave Wetmore from Goal Systems (finally, a bean-counter comes on board), John Burton from BST (Endevor), Joe Henson from Prime Computer, and others to grow the company very quickly. And the VC guys (General Atlantic Partners, from the Morino founding days) had confidence that it would eventually work out, and so they didn't mettle in the mess of personality differences and dart-board like attempts at various sales/marketing strategies over the next 5 years. So, in walks Jerre Stead, and in less than a year (after meeting Sanjay), LEGENT disappears, consumed by the well-oiled acquisition machine of CA (cash buyout at $47 dollars a share -- IRS made out much better than some on this deal). That was 16 years ago this month!! Personal stories of Morino Associates parties, holiday treats (damn good liquor) delivered by Mario with a shopping cart with a Santa hat on, and well-deserved fiscal year-end bonuses (did I say outrageous), have molded my professional career while experiencing this morph process and other sibling products. What a great ride that was. And to have been acquired by CA twice, once as a Monday morning acquisition (Johnson Systems -- APEX job scheduler, JARS family, UMAX, ALARM hardware monitor) and then again with LEGENT, there are probably more like me than I wish to count. Regards, Scott Barry SBBWorks, Inc. http://www.findarticles.com/p/articles/mi_m0SMG/is_n3_v13/ai_13427334 http://www.findarticles.com/p/articles/mi_m0SMG/is_n11_v10/ai_9460779 Date: Thu, 3 Aug 2006 22:09:34 -0500 Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU From: Ed Gould [EMAIL PROTECTED] Subject: Re: IEFACTRT -SNIP Scott, There *USED* to be a package (called QCM) that did all this and quite a bit more 20 or more years ago. I believe it was written by Glen Chatfield(sp?) of Duquesne systems in Pittsburg. If there was something to account for QCM could produce *VALID* numbers. Like chargeback for paging and even IO timings for anything in the system. IIRC we had a user who disputed the numbers and brought in a hardware monitor to verify (contest?) the numbers. The difference was so insignificant that the user coughed up the $$ without admitting defeat. Unfortunately the cost for the product was not cheap and I think that is what lead to the demise of the company. BTW they developed SDSI (now called MIM) on our systems. They also offered a product called STAM which allowed tape drives to be shared among systems. This was in the 70's and perhaps early 80's. When (at the early stages) their software caused any of our systems to crash they were always the first one to step up to the plate with research and debugging that even our local PSR was impressed with. Ed On Aug 3, 2006, at 4:49 PM, Scott Barry wrote: Consider that job-end statistics (if the output is captured or big_snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT
On Aug 4, 2006, at 5:46 AM, Bob Shannon wrote: snip of Duquesne systems in Pittsburg snip Unfortunately the cost for the product was not cheap and I think that is what lead to the demise of the company Duquesne merged with Morino to form Legent. Legent was acquired by CA. Duquesne didn't die, it merely morphed. Bob Shannon Rocket Software Bob, Thanks for tilting the memory, now I remember it better. I lost track of them just before the merge. I memory is iffy but I vaguely recall another step in the process, but its been so long you could be right. Anyone care to add? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT
A subsequent post by Scott Barry filled in all the blanks. And it is not a case of whether Bob Shannon could be right, he *was* right. Why do you challenge the recollections of others when you freely admit to having an iffy memory? Bob Richards -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Friday, August 04, 2006 3:21 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IEFACTRT On Aug 4, 2006, at 5:46 AM, Bob Shannon wrote: snip of Duquesne systems in Pittsburg snip Unfortunately the cost for the product was not cheap and I think that is what lead to the demise of the company Duquesne merged with Morino to form Legent. Legent was acquired by CA. Duquesne didn't die, it merely morphed. Bob Shannon Rocket Software Bob, Thanks for tilting the memory, now I remember it better. I lost track of them just before the merge. I memory is iffy but I vaguely recall another step in the process, but its been so long you could be right. Anyone care to add? LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. Seeing Beyond Money is a service mark of SunTrust Banks, Inc. [ST:XCL] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT
On Aug 4, 2006, at 2:48 PM, Richards.Bob wrote: A subsequent post by Scott Barry filled in all the blanks. And it is not a case of whether Bob Shannon could be right, he *was* right. Why do you challenge the recollections of others when you freely admit to having an iffy memory? Bob Richards Bob, All of us are getting older (including you) and memory becomes subject to parity errors. I am surprised you think yours is any better than the rest of ours. Also there was at least one step Bob S omitted. so he was not 100 percent right. I would not ask such a question if I was 100 percent sure. I dropped a(n) acquisition and I will freely admit it. What's the big deal ? The 90's saw a great deal of take over and mergers and the like. Get over it. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT
Consider that job-end statistics (if the output is captured or reviewed by the submitter) only represents a portion of what would normally be a chargeback bill/invoice/receipt (okay, or call it cost allocation or recovery). Also, how will a DB2 DDF (remote) customer get their bill or a CICS transaction user, etc. -- these typically involve tables mapping USERIDs to a related owner/group? Considering the cost of DASD and tape storage (local/vault, reel, real, virtual, high-capacity), how will these resources be tallied and communicated to the appropriate department/cost_center or resource consumer? CPU normalization, rates, and possibly surcharge/discount logic may need to be maintained, depending on the chargeback algorithm and IT chargeback methodology intended to be used for any given system/customer. Support for new rates with effective dates and other comprehensive logic should likely be considered, if the reported charges are to be considered credible, especially when transitioning between fiscal calendar cycles. Better to consider generating a consolidated resource consumer report, at day's end (or otherwise), and accumulate the various resource buckets/areas, in a back-end system that post-processes the various SMF and other system logs. Some that come to mind are SMF type 30 (address space activity for batch, TSO, STC, OMVS/USS, and maybe APPC), type 6 (output/print), type 101 (DB2), type 110 (CICS/CMF), IMS log (or BMC's Patrol / IMF), other DBMS tools (IDMS, M204, Datacom, Supra), and DASD (IBM DCOLLECT snapshot), tape (tape mgmt catalog snapshot) focusing on long-term data storage. Given the possibilities of unknowns, it's best to get management's expectations well-documented, evolve that information along with technical/business considerations into an explanation and/or position paper, so all involved parties understand what's at stake before valuable staff resources are expended. Sincerely, Scott Barry SBBWorks, Inc. Date: Thu, 3 Aug 2006 12:00:24 -0400 From: Anne Crabtree [EMAIL PROTECTED] Subject: IEFACTRT Does anyone have an example of IEFACTRT using type 30 and doing chargeback that they would be willing to share? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT
On Aug 3, 2006, at 4:49 PM, Scott Barry wrote: Consider that job-end statistics (if the output is captured or reviewed by the submitter) only represents a portion of what would normally be a chargeback bill/ invoice/receipt (okay, or call it cost allocation or recovery). Also, how will a DB2 DDF (remote) customer get their bill or a CICS transaction user, etc. -- these typically involve tables mapping USERIDs to a related owner/group? Considering the cost of DASD and tape storage (local/vault, reel, real, virtual, high-capacity), how will these resources be tallied and communicated to the appropriate department/cost_center or resource consumer? CPU normalization, rates, and possibly surcharge/discount logic may need to be maintained, depending on the chargeback algorithm and IT chargeback methodology intended to be used for any given system/customer. Support for new rates with effective dates and other comprehensive logic should likely be considered, if the reported charges are to be considered credible, especially when transitioning between fiscal calendar cycles. Better to consider generating a consolidated resource consumer report, at day's end (or otherwise), and accumulate the various resource buckets/areas, in a back-end system that post-processes the various SMF and other system logs. Some that come to mind are SMF type 30 (address space activity for batch, TSO, STC, OMVS/USS, and maybe APPC), type 6 (output/ print), type 101 (DB2), type 110 (CICS/CMF), IMS log (or BMC's Patrol / IMF), other DBMS tools (IDMS, M204, Datacom, Supra), and DASD (IBM DCOLLECT snapshot), tape (tape mgmt catalog snapshot) focusing on long-term data storage. -SNIP Scott, There *USED* to be a package (called QCM) that did all this and quite a bit more 20 or more years ago. I believe it was written by Glen Chatfield(sp?) of Duquesne systems in Pittsburg. If there was something to account for QCM could produce *VALID* numbers. Like chargeback for paging and even IO timings for anything in the system. IIRC we had a user who disputed the numbers and brought in a hardware monitor to verify (contest?) the numbers. The difference was so insignificant that the user coughed up the $$ without admitting defeat. Unfortunately the cost for the product was not cheap and I think that is what lead to the demise of the company. BTW they developed SDSI (now called MIM) on our systems. They also offered a product called STAM which allowed tape drives to be shared among systems. This was in the 70's and perhaps early 80's. When (at the early stages) their software caused any of our systems to crash they were always the first one to step up to the plate with research and debugging that even our local PSR was impressed with. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT and routing questions
On Mon, 2006-05-01 at 08:35 -0500, George Dranes wrote: This output is only written to Hardcopy, not the consoles. In our exit we let the ROUTE codes and MCSFLAGS default. We use ROUTCDE=(13),DESC=(6) and then configure SYS1.PARMLIB(CONSOLxx) appropriately to route the messages where we want. (We don't use ROUTCDE=11 because this results in duplicate IEF196I messages when IEFACTRT runs under a WLM initiator.) -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT and routing questions
I'm also kind of curious why the IEF170I message comes up for STC's It appears to have something to do with the MCSFLAGS. University Information Management Systems George Dranes Manager-Technical Services [EMAIL PROTECTED] Morgan Hall 121 1 University Circle Macomb, IL 61455-1390 tel: 309-298-1097 X261 fax: 309-298-1451 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews Sent: Monday, May 01, 2006 8:56 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IEFACTRT and routing questions On Mon, 2006-05-01 at 08:35 -0500, George Dranes wrote: This output is only written to Hardcopy, not the consoles. In our exit we let the ROUTE codes and MCSFLAGS default. We use ROUTCDE=(13),DESC=(6) and then configure SYS1.PARMLIB(CONSOLxx) appropriately to route the messages where we want. (We don't use ROUTCDE=11 because this results in duplicate IEF196I messages when IEFACTRT runs under a WLM initiator.) -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT and routing questions
I was able to eliminate the IEF170I on STCs by setting the MCSFLAG field in IEEACTRT to the following: MCSFLAG DCB'1000' *0123456789ABCDEF The WTO now goes to our consoles and to hardcopy since our hardcopy is defined as ROUTCODE(ALL) in our CONSOLXX member. Thanks for the help. Quoting David Andrews [EMAIL PROTECTED]: On Mon, 2006-05-01 at 08:35 -0500, George Dranes wrote: This output is only written to Hardcopy, not the consoles. In our exit we let the ROUTE codes and MCSFLAGS default. We use ROUTCDE=(13),DESC=(6) and then configure SYS1.PARMLIB(CONSOLxx) appropriately to route the messages where we want. (We don't use ROUTCDE=11 because this results in duplicate IEF196I messages when IEFACTRT runs under a WLM initiator.) -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT modifications
Currently here is a display of our consoles: CONSOLE/ALTID --- SPECIFICATIONS -- SYSLOG COND=H AUTH=CMDS NBUF=0U ROUTCDE=ALL 01/01 01 COND=M AUTH=MASTER NBUF=0U 0521 AREA=Z MFORM=T,J SAND DEL=RD RTME=1 RNUM=16 SEG=16 USE=FC LEVEL=ALL PFKTAB=*DE ROUTCDE=1-12 So, now how do I proceed to NOT have my ACTRT stats appear on SYSLOG and the console at 521? John Norgauer University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT modifications
John Norgauer wrote: Currently here is a display of our consoles: CONSOLE/ALTID --- SPECIFICATIONS -- SYSLOG COND=H AUTH=CMDS NBUF=0U ROUTCDE=ALL 01/01 01 COND=M AUTH=MASTER NBUF=0U 0521 AREA=Z MFORM=T,J SAND DEL=RD RTME=1 RNUM=16 SEG=16 USE=FC LEVEL=ALL PFKTAB=*DE ROUTCDE=1-12 So, now how do I proceed to NOT have my ACTRT stats appear on SYSLOG and the console at 521? Simple. You need to write the messages using a routing code that these consoles do not display. In the case of your 0521 console, that is any code from 13-128. Your syslog is defined to capture all routing codes and will need to be changed. (I question your setup entirely, since you display route code 11 -- programmer information -- messages in both places! But I digress...) My consoles look like this: |IEE889I 10.51.18 CONSOLE DISPLAY 865 |MSG: CURR=0LIM=5000 RPLY:CURR=4LIM=31 SYS=MVS60 PFK=00 | CONSOLEID --- SPECIFICATIONS --- | SYSLOG COND=H AUTH=CMDS NBUF=N/A |ROUTCDE=1-10,12-13,15-128 | OPERLOGCOND=H AUTH=CMDS NBUF=N/A |ROUTCDE=1-10,12-13,15-128 | MSTR60A01 COND=M AUTH=MASTER NBUF=0 | 0600 AREA=Z,AMFORM=S,J | MVS60 DEL=RD RTME=1/4RNUM=5SEG=16CON=N |USE=FC LEVEL=ALL PFKTAB=PFKTAB1 |ROUTCDE=1-2,7-10,16-96,99-112,115-128 |LOGON=OPTIONAL |CMDSYS=MVS60 |MSCOPE=*ALL |MONITOR=JOBNAMES |ALTGRP=MSTRGRP . . (many others follow here) . Notice how route codes 11 and 14 don't appear in the logs or on consoles. Our IEFACTRT WTOs use route code 14. Why 14 instead of 11? So we can temporarily enable the display of messages with route code 14 without also getting all of those route code 11 messages. -- - | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT modifications
Ed et al, Thanks for info. I changed my ROUTCDEs on my SYSLOG and MCS and along with a mod to ACTRT to only process ROUTCDE 11, I now have the displays working great. John Norgauer University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT modifications
Sine I am right now in just this area: Here ACTRT spits out a WTO with the step completion code that everyone wants to see in the JESMSGLG (not JESYSMSG). Using IEFYS would move the location of the message in the output to JESYSMSG, I think. Using a WTO with ROUTCDE 11 (only) is not a good idea (as I just found out) as that gets converted to a WTP, and for every STC on my system that results in duplication of the message, the duplicate being preceded by IEF170I. In the past, we had used ROUTCDE 6, and I have written an MPF exit to suppress the message for OMVS steps (it's annoying when there is nothing but this message for pages in the hardcopy log). I got objections when I suppressed the message completely (via MPF) from hardcopy. Regards, Barbara Nitz -- Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat, DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT modifications
Hi John, Which IEFACTRT there are a bunch on the CBT Tape? You should just be able to change the WTO to route code 11 and the hardcopy only flag for good measure and the messages should not be on any console. Have you checked the route codes that the console is set to display? Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Norgauer Sent: Friday, November 04, 2005 5:48 PM To: IBM-MAIN@BAMA.UA.EDU Subject: IEFACTRT modifications We are using the CBTTAPE version of IEFACTRT. This version displays on the Console and the batch job's JESMSGLG and JESYSMSG step and job statistic messages. While the info display on the JESMSGLG and JESYSMSG are very useful to the batch job submitter, the messages that appear on the console and SYSLOG are really very redundant and not needed. Has anyone modified this exit to eliminate the latter messages? If so, what was your approach. I tried changing the ROUTCDES, but to no avail. Thanks John Norgauer University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFACTRT modifications
IEFACTRT can use a system routine (IEFYS?) - usually link edited in - to write to the messages data set (where the COND CODE is) without having to worry about WTO routing codes and SYSLOG or console effects. That's what most flower boxes use. Many places use IEFACTRT to issue WTO messages reporting the step completion results for job log and/or syslog reference. After the demise of the I/O count zap usermod I resorted to using IEFU83 to trap SMF type 14/15/64 records to report EXCP counts against each data set. Without the ability to use IEFYS in this exit I had to use WTO with ROUTCDE=11 to get the info to the messages data set. I did not want all batch data set activity logged to the syslog, or even reported in the job's own job log. Fortunately, though IBM taketh away it also giveth. OCO prevented (for practical purposes) an updated I/O count zap hack but MPF had been introduced. So, a few simple bit switching MPF exits allowed the messages issued by my IEFU83 to show up in the messages data set without clogging up the job log, syslog, or console(s). The same could be done for any WTO messages from anywhere (given known message ids). The messages also go to the Master Trace Table if that is a consideration for anyone. It wasn't for me. In fact it provided a nice place for me to observe how many messages my exit was producing system-wide. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
