Re: Need to include ACF2 SMF 230 in SMFPRMxx?
Tony Harminc wrote: We agreed with the customer. Customer is *always* correct. :-D We had been treating any non-zero RC from SMFWTM as an error (with a not very informative generic message), so we changed our code to treat only some RCs as errors, and merely report in summary on others at product shutdown, e.g. nnn SMF records were suppressed by SMF configuration, nnn SMF records were suppressed by SMF installation exit, etc. I know that some products write on SYSLOG if there is a problem with SMF, say if the SMF buffers are full or suppressed or something like that. I have set up my automation software to respond on it or notify us. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
Closing the loop, I have now gotten a reply on the ACF2 list from CA support. (Thanks Ross!) FWIW, here is my model of how this all works. SMFPRMxx is a suggestion to SMF-record-writing components. SMF itself does not filter based on SMFPRMxx. You can code SYS(NOTYPE(199)) and I can still write a program that uses SMF(E)WTM to write type 199 records and they will end up in your SMF datasets and/or logstream (subject to any IEFU8x exit). What a well-behaved program *should* do, apparently (although this does not seem to be well-documented) and apparently what ACF2 and every IBM product do is query SMFRTEST to determine whether the shop wants its record type, and adjust its logic accordingly. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Saturday, October 05, 2013 7:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Need to include ACF2 SMF 230 in SMFPRMxx? I asked this question on the ACF2 list. The only answer I got was from the always-helpful Lizette who indicated a low degree of certainty in her answer and suggested that I ask here. I am trying to clarify some product documentation and clean up some internal logic - I don't have an actual problem. Question: Assuming an ACF2 shop wants to cut SMF 230 (or other as configured) records, is it sufficient to specify ACF2=230 on the @SMF macro of the ACFFDR in UM99901, or is it also necessary that the shop specify SYS(TYPE(230)) or the equivalent in the SMFPRMxx member of the SYS1.PARMLIB concatenation? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
On Tue, 8 Oct 2013 10:52:36 -0700, Charles Mills charl...@mcn.org wrote: Closing the loop, I have now gotten a reply on the ACF2 list from CA support. (Thanks Ross!) FWIW, here is my model of how this all works. SMFPRMxx is a suggestion to SMF-record-writing components. SMF itself does not filter based on SMFPRMxx. You can code SYS(NOTYPE(199)) and I can still write a program that uses SMF(E)WTM to write type 199 records and they will end up in your SMF datasets and/or logstream (subject to any IEFU8x exit). What a well-behaved program *should* do, apparently (although this does not seem to be well-documented) and apparently what ACF2 and every IBM product do is query SMFRTEST to determine whether the shop wants its record type, and adjust its logic accordingly. Charles This is news to me. I can't speak to the validity without writing my own program, but on the surface doesn't seem to agree with the description for SMFRTEST in the SMF manual. Pay attention to the wording in the last sentence. 5.8 SMFRTEST -- Testing record recording The SMFRTEST macro allows you to determine if a particular type, or subtype, of a record is being recorded. Issue this macro before collecting data for a particular record or subtype to avoid the overhead of data collection if it is not written. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
You may be right. Trying to make complete sense of D SMF,O output may be the death of me yet. Also on the ACF2 list Tony Harminc points out the 36 (24) return code from SMF(E)WTM. I will investigate further when I have time. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Tuesday, October 08, 2013 11:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need to include ACF2 SMF 230 in SMFPRMxx? On Tue, 8 Oct 2013 10:52:36 -0700, Charles Mills charl...@mcn.org wrote: Closing the loop, I have now gotten a reply on the ACF2 list from CA support. (Thanks Ross!) FWIW, here is my model of how this all works. SMFPRMxx is a suggestion to SMF-record-writing components. SMF itself does not filter based on SMFPRMxx. You can code SYS(NOTYPE(199)) and I can still write a program that uses SMF(E)WTM to write type 199 records and they will end up in your SMF datasets and/or logstream (subject to any IEFU8x exit). What a well-behaved program *should* do, apparently (although this does not seem to be well-documented) and apparently what ACF2 and every IBM product do is query SMFRTEST to determine whether the shop wants its record type, and adjust its logic accordingly. Charles This is news to me. I can't speak to the validity without writing my own program, but on the surface doesn't seem to agree with the description for SMFRTEST in the SMF manual. Pay attention to the wording in the last sentence. 5.8 SMFRTEST -- Testing record recording The SMFRTEST macro allows you to determine if a particular type, or subtype, of a record is being recorded. Issue this macro before collecting data for a particular record or subtype to avoid the overhead of data collection if it is not written. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
Mark, You do not need to ...It comes that way right out of the box... Scott J Ford Software Engineer http://www.identityforge.com/ From: Mark Zelden m...@mzelden.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, October 8, 2013 2:13 PM Subject: Re: Need to include ACF2 SMF 230 in SMFPRMxx? On Tue, 8 Oct 2013 10:52:36 -0700, Charles Mills charl...@mcn.org wrote: Closing the loop, I have now gotten a reply on the ACF2 list from CA support. (Thanks Ross!) FWIW, here is my model of how this all works. SMFPRMxx is a suggestion to SMF-record-writing components. SMF itself does not filter based on SMFPRMxx. You can code SYS(NOTYPE(199)) and I can still write a program that uses SMF(E)WTM to write type 199 records and they will end up in your SMF datasets and/or logstream (subject to any IEFU8x exit). What a well-behaved program *should* do, apparently (although this does not seem to be well-documented) and apparently what ACF2 and every IBM product do is query SMFRTEST to determine whether the shop wants its record type, and adjust its logic accordingly. Charles This is news to me. I can't speak to the validity without writing my own program, but on the surface doesn't seem to agree with the description for SMFRTEST in the SMF manual. Pay attention to the wording in the last sentence. 5.8 SMFRTEST -- Testing record recording The SMFRTEST macro allows you to determine if a particular type, or subtype, of a record is being recorded. Issue this macro before collecting data for a particular record or subtype to avoid the overhead of data collection if it is not written. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
Scott, Your response isn't clear to me. Are you saying what Charles wrote is accurate (SMFPRMxx setting doesn't really matter) or that SMFPRMxx always has the final say (as I always thought it did up until Charles posted). Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ p.s. Have I mentioned how much I dislike when bottom posting and top posting get mixed in the same thread lately? I prefer bottom, but will go with the flow once started. Is it that hard to follow what's already there and do something different than your default reply settings in your email program? /end soap box On Tue, 8 Oct 2013 12:02:46 -0700, Scott Ford scott_j_f...@yahoo.com wrote: Mark, � You do not need to ...It comes that way right out of the box... Scott J Ford Software Engineer http://www.identityforge.com/ � From: Mark Zelden m...@mzelden.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, October 8, 2013 2:13 PM Subject: Re: Need to include ACF2 SMF 230 in SMFPRMxx? On Tue, 8 Oct 2013 10:52:36 -0700, Charles Mills charl...@mcn.org wrote: Closing the loop, I have now gotten a reply on the ACF2 list from CA support. (Thanks Ross!) FWIW, here is my model of how this all works. SMFPRMxx is a suggestion to SMF-record-writing components. SMF itself does not filter based on SMFPRMxx. You can code SYS(NOTYPE(199)) and I can still write a program that uses SMF(E)WTM to write type 199 records and they will end up in your SMF datasets and/or logstream (subject to any IEFU8x exit). What a well-behaved program *should* do, apparently (although this does not seem to be well-documented) and apparently what ACF2 and every IBM product do is query SMFRTEST to determine whether the shop wants its record type, and adjust its logic accordingly. Charles This is news to me.� I can't speak to the validity without writing my own program, but on the surface doesn't seem to agree with the description for SMFRTEST in the SMF manual.� Pay attention to the wording in the last sentence. 5.8 SMFRTEST -- Testing record recording� The SMFRTEST macro allows you to determine if a particular type, or subtype, of a record is being recorded. Issue this macro before collecting data for a particular record or subtype to avoid the overhead of data collection if it is not written. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS� mailto:m...@mzelden.com� � ITIL v3 Foundation Certified� � � � � � � � � � � � � � � � � � Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
At 13:13 -0500 on 10/08/2013, Mark Zelden wrote about Re: Need to include ACF2 SMF 230 in SMFPRMxx?: SMFPRMxx is a suggestion to SMF-record-writing components. SMF itself does not filter based on SMFPRMxx. You can code SYS(NOTYPE(199)) and I can still write a program that uses SMF(E)WTM to write type 199 records and they will end up in your SMF datasets and/or logstream (subject to any IEFU8x exit). What a well-behaved program *should* do, apparently (although this does not seem to be well-documented) and apparently what ACF2 and every IBM product do is query SMFRTEST to determine whether the shop wants its record type, and adjust its logic accordingly. This is news to me. I can't speak to the validity without writing my own program, but on the surface doesn't seem to agree with the description for SMFRTEST in the SMF manual. Pay attention to the wording in the last sentence. 5.8 SMFRTEST -- Testing record recording The SMFRTEST macro allows you to determine if a particular type, or subtype, of a record is being recorded. Issue this macro before collecting data for a particular record or subtype to avoid the overhead of data collection if it is not written. The wording is based on the assumption that the test will be done before an attempt to add the record to the SMF dataset and that the record will thus not be submitted if the result indicates that the record is not to be recorded. This does NOT however say that a submission of such a record will be rejected by SMF. The wording needs to be updated to mention testing before submitting since there is a difference between the records being blocked by SMF itself and the submitters not submitting due to the macro call results. There is a subtle difference in the significance of that sentence. This is that it is worded as Do not bother to do the collection since there WILL [not the correct (if submitters check before submitting) SHOULD] not be any records. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
Mark, Sorry misread, my mistake Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Oct 8, 2013, at 3:13 PM, Mark Zelden m...@mzelden.com wrote: Scott, Your response isn't clear to me. Are you saying what Charles wrote is accurate (SMFPRMxx setting doesn't really matter) or that SMFPRMxx always has the final say (as I always thought it did up until Charles posted). Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ p.s. Have I mentioned how much I dislike when bottom posting and top posting get mixed in the same thread lately? I prefer bottom, but will go with the flow once started. Is it that hard to follow what's already there and do something different than your default reply settings in your email program? /end soap box On Tue, 8 Oct 2013 12:02:46 -0700, Scott Ford scott_j_f...@yahoo.com wrote: Mark, � You do not need to ...It comes that way right out of the box... Scott J Ford Software Engineer http://www.identityforge.com/ � From: Mark Zelden m...@mzelden.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, October 8, 2013 2:13 PM Subject: Re: Need to include ACF2 SMF 230 in SMFPRMxx? On Tue, 8 Oct 2013 10:52:36 -0700, Charles Mills charl...@mcn.org wrote: Closing the loop, I have now gotten a reply on the ACF2 list from CA support. (Thanks Ross!) FWIW, here is my model of how this all works. SMFPRMxx is a suggestion to SMF-record-writing components. SMF itself does not filter based on SMFPRMxx. You can code SYS(NOTYPE(199)) and I can still write a program that uses SMF(E)WTM to write type 199 records and they will end up in your SMF datasets and/or logstream (subject to any IEFU8x exit). What a well-behaved program *should* do, apparently (although this does not seem to be well-documented) and apparently what ACF2 and every IBM product do is query SMFRTEST to determine whether the shop wants its record type, and adjust its logic accordingly. Charles This is news to me.� I can't speak to the validity without writing my own program, but on the surface doesn't seem to agree with the description for SMFRTEST in the SMF manual.� Pay attention to the wording in the last sentence. 5.8 SMFRTEST -- Testing record recording� The SMFRTEST macro allows you to determine if a particular type, or subtype, of a record is being recorded. Issue this macro before collecting data for a particular record or subtype to avoid the overhead of data collection if it is not written. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS� mailto:m...@mzelden.com� � ITIL v3 Foundation Certified� � � � � � � � � � � � � � � � � � Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
I am now convinced that I was confused in my early experiment. The SMF record that I wrote was in fact allowed by SMFPRMxx. So I have no proof that my earlier assertion is correct. OTOH, I have not, and probably will not take the time to, run an experiment to see if the assertion of most of the posters here is correct: that a specified or implied permission in SMFPRMxx is a necessary condition for writing SMF records of a particular type number. I guess a well-behaved and efficient program would check SMFRTEST at startup to avoid the overhead of constructing unwanted SMF records, but if it did not, I now suspect it would be prevented from writing them, and would in fact receive a 36 (24) from SMF(E)WTM. My apologies for the confusion. BTW, I agree with Robert A. Rosenberg. The documentation is less than clear. You can IMHO read it either way, and nowhere does it say SMF(E)WTM *will* fail if the indicated record type is not permitted by SMFPRMxx. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, October 08, 2013 11:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need to include ACF2 SMF 230 in SMFPRMxx? You may be right. Trying to make complete sense of D SMF,O output may be the death of me yet. Also on the ACF2 list Tony Harminc points out the 36 (24) return code from SMF(E)WTM. I will investigate further when I have time. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Tuesday, October 08, 2013 11:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need to include ACF2 SMF 230 in SMFPRMxx? On Tue, 8 Oct 2013 10:52:36 -0700, Charles Mills charl...@mcn.org wrote: Closing the loop, I have now gotten a reply on the ACF2 list from CA support. (Thanks Ross!) FWIW, here is my model of how this all works. SMFPRMxx is a suggestion to SMF-record-writing components. SMF itself does not filter based on SMFPRMxx. You can code SYS(NOTYPE(199)) and I can still write a program that uses SMF(E)WTM to write type 199 records and they will end up in your SMF datasets and/or logstream (subject to any IEFU8x exit). What a well-behaved program *should* do, apparently (although this does not seem to be well-documented) and apparently what ACF2 and every IBM product do is query SMFRTEST to determine whether the shop wants its record type, and adjust its logic accordingly. Charles This is news to me. I can't speak to the validity without writing my own program, but on the surface doesn't seem to agree with the description for SMFRTEST in the SMF manual. Pay attention to the wording in the last sentence. 5.8 SMFRTEST -- Testing record recording The SMFRTEST macro allows you to determine if a particular type, or subtype, of a record is being recorded. Issue this macro before collecting data for a particular record or subtype to avoid the overhead of data collection if it is not written. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
On 8 October 2013 20:35, Charles Mills charl...@mcn.org wrote: OTOH, I have not, and probably will not take the time to, run an experiment to see if the assertion of most of the posters here is correct: that a specified or implied permission in SMFPRMxx is a necessary condition for writing SMF records of a particular type number. I guess a well-behaved and efficient program would check SMFRTEST at startup to avoid the overhead of constructing unwanted SMF records, but if it did not, I now suspect it would be prevented from writing them, and would in fact receive a 36 (24) from SMF(E)WTM. I dug out the customer complaint (from 2003) that provoked us to make code changes in one of our products: === Through SMF parm (SMFPRM00) we specifically code the system not to record SMF type nnn with subtype of 224 226. This is the result from product: msgid SMF WRITE FAILURE The Question is why should product care whether through system installation we suppressed certain smf subtypes or not? We believe this is a bug because it is clearly stated in SMFEWTM or SMFWTM macro that if the record was not written because the record type specified is not currently being recorded, the return code is 36. === We agreed with the customer. We had been treating any non-zero RC from SMFWTM as an error (with a not very informative generic message), so we changed our code to treat only some RCs as errors, and merely report in summary on others at product shutdown, e.g. nnn SMF records were suppressed by SMF configuration, nnn SMF records were suppressed by SMF installation exit, etc. But certainly back in 2003 this configuration caused RC 36 from SMFWTM. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
I do not know about ACF2 but with every other product I have worked with you need to set the SMFPRMxx member to include the record being written. Also I do not know of a way to programically add a record type to SMFPRMxx. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
On 10/05/2013 09:47 AM, Charles Mills wrote: I asked this question on the ACF2 list. The only answer I got was from the always-helpful Lizette who indicated a low degree of certainty in her answer and suggested that I ask here. I am trying to clarify some product documentation and clean up some internal logic - I don't have an actual problem. Question: Assuming an ACF2 shop wants to cut SMF 230 (or other as configured) records, is it sufficient to specify ACF2=230 on the @SMF macro of the ACFFDR in UM99901, or is it also necessary that the shop specify SYS(TYPE(230)) or the equivalent in the SMFPRMxx member of the SYS1.PARMLIB concatenation? We don't run ACF2 so I can't experiment (but we have customers that do). The documentation of SMFPRMxx TYPE() would seem to imply that SMF suppresses any record type not specified in SMFPRMxx, but I know from experiments that I can write a user SMF record successfully with SMF(E)WTM even if the type is not in SMFPRMxx. However, that's not the whole answer because a third party product such as ACF2 *could* use SMFRTEST to see if the customer wanted 230's or not, and if TYPE(230) were not specified, not write them. I also have a customer that I know is writing 230's that I asked to eyeball a D SMF,O and they said 230 was not in there, but I am not sure that I trust their answer. I have a question in to CA but so far they are scratching their collective heads. Thanks, Charles Any application or product with proper authority can create and write an SMF record with SMF(E)WTM, and that creation should appear successful as long as the record is successfully passed to SMF. Whether that record actually makes it all the way to the SMF datasets depends on SMF Exits and SMFPRMxx PARMLIB definitions. Since there are all sorts of ways of including and excluding record types and ranges of record types in SMFPRMxx, that doesn't necessary mean you would see an explicit occurrence of 230 in SMFPRMxx. The ACF2=230 sounds like a way to tell ACF that it should write Type 230 records. I would think it highly unlikely that this would also control whether SMF physically saves the records to its datasets, unless the ACF installation process uses the mentioned @SMF macro to generate a new SMFPRMxx that you are supposed to install as part of ACF customization. I think it more likely they would just advise one to modify or assume you would know to modify SMFPRMxx if you wanted to retain the records. A Sort of SMF data that only includes records with type field of 230 (X'E6') would give a definitive answer if you don't trust eyeball analysis. However, the free CBT REVIEW utility also allows you to eyeball specific SMF record types, and that should be pretty definitive as well. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
It depends. Some shops specify SYS(TYPE(xxx)) to only record selected records in SMFPRMxx. Others specify (SYS(NOTYPE(xxx)) to record everything except type xxx HTH, snip I asked this question on the ACF2 list. The only answer I got was from the always-helpful Lizette who indicated a low degree of certainty in her answer and suggested that I ask here. I am trying to clarify some product documentation and clean up some internal logic - I don't have an actual problem. Question: Assuming an ACF2 shop wants to cut SMF 230 (or other as configured) records, is it sufficient to specify ACF2=230 on the @SMF macro of the ACFFDR in UM99901, or is it also necessary that the shop specify SYS(TYPE(230)) or the equivalent in the SMFPRMxx member of the SYS1.PARMLIB concatenation? We don't run ACF2 so I can't experiment (but we have customers that do). The documentation of SMFPRMxx TYPE() would seem to imply that SMF suppresses any record type not specified in SMFPRMxx, but I know from experiments that I can write a user SMF record successfully with SMF(E)WTM even if the type is not in SMFPRMxx. However, that's not the whole answer because a third party product such as ACF2 *could* use SMFRTEST to see if the customer wanted 230's or not, and if TYPE(230) were not specified, not write them. I also have a customer that I know is writing 230's that I asked to eyeball a D SMF,O and they said 230 was not in there, but I am not sure that I trust their answer. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to include ACF2 SMF 230 in SMFPRMxx?
Forgot to add, the SMF default is to record *ALL* records unless otherwise instructed via SYS(TYPE/NOTYPE). HTH, It depends. Some shops specify SYS(TYPE(xxx)) to only record selected records in SMFPRMxx. Others specify (SYS(NOTYPE(xxx)) to record everything except type xxx HTH, snip I asked this question on the ACF2 list. The only answer I got was from the always-helpful Lizette who indicated a low degree of certainty in her answer and suggested that I ask here. I am trying to clarify some product documentation and clean up some internal logic - I don't have an actual problem. Question: Assuming an ACF2 shop wants to cut SMF 230 (or other as configured) records, is it sufficient to specify ACF2=230 on the @SMF macro of the ACFFDR in UM99901, or is it also necessary that the shop specify SYS(TYPE(230)) or the equivalent in the SMFPRMxx member of the SYS1.PARMLIB concatenation? We don't run ACF2 so I can't experiment (but we have customers that do). The documentation of SMFPRMxx TYPE() would seem to imply that SMF suppresses any record type not specified in SMFPRMxx, but I know from experiments that I can write a user SMF record successfully with SMF(E)WTM even if the type is not in SMFPRMxx. However, that's not the whole answer because a third party product such as ACF2 *could* use SMFRTEST to see if the customer wanted 230's or not, and if TYPE(230) were not specified, not write them. I also have a customer that I know is writing 230's that I asked to eyeball a D SMF,O and they said 230 was not in there, but I am not sure that I trust their answer. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
