Re: Potential z/OS MPF behavior change -- comments please
Automation is just another user of the system albeit a programmed one. To attempt to define what is an automation only message would be easy. An automation only message is sent from an automation unit to an automation unit for the purpose of them information each other of events, using text messages. TSO users are automation taken to the intelligent level ( I know I will get comments for saying that :) ) where they receive both visual and textual message from the system and respond to them. I would not wish to have my TSO users disappear from the system messages for much the same reason that the programmed automation messages should be visible and recorded too. I need to see what is going on in my system and those messages are a part of it. Even heartbeat messages tell you that something is still looking for work if nothing else. So if the customer has an MPF list entry for an automation message, then they need to live with it being hardcopied IMHO. If they dont want it hardcopied then remove the MPF exit that processes it. OR are you saying that the existence of ANY MPF processing even if not for their automation message causes it to be hardcopied? -- 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: Potential z/OS MPF behavior change -- comments please
Kevin, maybe som of the others have the same problem *I* have in understanding the term 'monitor message'. I just reread Planning:OPS and the message manual where the IEF's are in, and I am still unclear what 'monitor message' is/means. Take IEF403I and IEF404I (two of those that I need in hardcopy to *prove* that something happened at a certain time, in addition to the HASP messages and our home-grown uji001 and trt002 at step start/stop): Is all of IEF403I the monitor message that would not be issued if we hadn't set the consolxx definition to MONITOR(JOBNAMES-T)? Or is just the time part of ief403I (which would appear in joblog that doesn't have the hardcopy-log- timestamp) the 'monitor' thing? The 1.12 message book for ief403i is certainly VERY silent about this. Is a list of 'the monitor messages' published anywhere? We still have the MN dsname command in commndxx, which at IPL gets the expected error of 'monitor command not supported' or some such (I was not allowed to remove it for heaven knows what reasons). Despite that, D opdata still shows that DSNAME monitoring is on (because of the INIT statement in consolxx?) Why can I not specify the log option on the INIT statement? We don't issue any setcon command for it, and it defaults to LOG (which isn't explicitly stated in the books, either!) Presumably for monitor dsname on init, it will also default to log. In addition, the message books are fairly obtuse about what a monitor message is. Unless you already know, it is not clear what is a monitor message and what isn't. Looking at the hardcopy log, IEF403I shows that it is issued without any routing codes, but it does have the 'MESSAGE NOT SERVICED BY ANY WTO USER EXIT' and 'AUTOMATION REQUESTED' bits on in HCLREQFL (x'0090'). I have always been unclear if such a message would show up on the console or not and had to rely on actually *looking* at he console to determine that. This despite us having a default routcode of 11 specified in consolxx. Which does not show up in the hardcopied message. And some of the responses here seem to reflect the same lack of understanding I have, probably because of fairly insufficient docs. Maybe IBM will consider to educate us at the next SHARE? Richard, But if I understand this correctly, these messages normally didn't go to syslog. They only went to syslog if MPF deleted them from the console. No. We don't have anything in MPF for ief403/404 (other than a no_entry statement explicitly saying SUP(NO)), and these messages certainly appear in hardcopy log *and* on the console. Brian, Personally I have used seemingly trivial Syslog entries to debug and correct issues that would have been difficult or next to impossible to do in a timely manner without them. I don't think making a no-log default is ever a good idea. I concur. Thanks. Best regards, Barbara -- 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: Potential z/OS MPF behavior change -- comments please
Maybe I was too hasty. If a message is suppressed from every console AND from the log, it could be considered lost. Exactly. That was my first thought. In my experience, I am *required* to proof to all and sundry (most notably IBM software support) that things happened in a certain order or that they happened *at all*. How am I supposed to do that if a message is suppressed from hardcopy? I fully concur with Barbara. Thers is nothing more frustrating than having to explain what happend when you don't have means to find out what happened. SYSLOG/OPERLOG is one of the great things MVS offers to help with debugging and problem analyzing. If you're going to change that behaviour, make it so that someone needs to activate it with full awareness of what is going to change and leave the default as it is. -- Peter Hunkeler Credit Suisse -- 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: Potential z/OS MPF behavior change -- comments please
Kevin , The SYSLOG / OPERLOG in many place treated as an aeroplane black boxes. It records *everything *that is happening in the system. It server as tool for technical and legal problems investigation and it is archived for years. There are installations that forbid suppressing any message, including messages that create and serve only automation processes (by automation products). Another issue is that, the MPF does not have a security mechanism. Therefore, anyone that can write a MPF process can cause eliminating messages from SYSLOG unintentionally or intentionally. Automation products, that already suppress messages from everywhere, have the security mechanism that can and should be use. Bottom line: Leave it as today. Those that need more sophisticated options should use more sophisticated tools. Have a nice day Doron On Wed, Oct 20, 2010 at 08:02, Barbara Nitz nitz-...@gmx.net wrote: Kevin, maybe som of the others have the same problem *I* have in understanding the term 'monitor message'. I just reread Planning:OPS and the message manual where the IEF's are in, and I am still unclear what 'monitor message' is/means. Take IEF403I and IEF404I (two of those that I need in hardcopy to *prove* that something happened at a certain time, in addition to the HASP messages and our home-grown uji001 and trt002 at step start/stop): Is all of IEF403I the monitor message that would not be issued if we hadn't set the consolxx definition to MONITOR(JOBNAMES-T)? Or is just the time part of ief403I (which would appear in joblog that doesn't have the hardcopy-log- timestamp) the 'monitor' thing? The 1.12 message book for ief403i is certainly VERY silent about this. Is a list of 'the monitor messages' published anywhere? We still have the MN dsname command in commndxx, which at IPL gets the expected error of 'monitor command not supported' or some such (I was not allowed to remove it for heaven knows what reasons). Despite that, D opdata still shows that DSNAME monitoring is on (because of the INIT statement in consolxx?) Why can I not specify the log option on the INIT statement? We don't issue any setcon command for it, and it defaults to LOG (which isn't explicitly stated in the books, either!) Presumably for monitor dsname on init, it will also default to log. In addition, the message books are fairly obtuse about what a monitor message is. Unless you already know, it is not clear what is a monitor message and what isn't. Looking at the hardcopy log, IEF403I shows that it is issued without any routing codes, but it does have the 'MESSAGE NOT SERVICED BY ANY WTO USER EXIT' and 'AUTOMATION REQUESTED' bits on in HCLREQFL (x'0090'). I have always been unclear if such a message would show up on the console or not and had to rely on actually *looking* at he console to determine that. This despite us having a default routcode of 11 specified in consolxx. Which does not show up in the hardcopied message. And some of the responses here seem to reflect the same lack of understanding I have, probably because of fairly insufficient docs. Maybe IBM will consider to educate us at the next SHARE? Richard, But if I understand this correctly, these messages normally didn't go to syslog. They only went to syslog if MPF deleted them from the console. No. We don't have anything in MPF for ief403/404 (other than a no_entry statement explicitly saying SUP(NO)), and these messages certainly appear in hardcopy log *and* on the console. Brian, Personally I have used seemingly trivial Syslog entries to debug and correct issues that would have been difficult or next to impossible to do in a timely manner without them. I don't think making a no-log default is ever a good idea. I concur. Thanks. Best regards, Barbara -- 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: Potential z/OS MPF behavior change -- comments please
On Wed, 20 Oct 2010 00:16:24 -0500, Barbara Nitz nitz-...@gmx.net wrote: Mark, 1) It is recommended to NOT use IEFUSI for OMVS (I removed it many years ago). 2) When I did, I checked for OMVS and skipped writing the messages: CLC 0(4,R5),=C'OMVS' BE SKIPWTO ehm, my USI does this (and has been since I rewrote it when memlimit came out): CLC 0(4,SUBNAME),=C'OMVS' BNE MNOMVS not OMVS MVC 16(8,RA),Z6GIG MEMLIMIT max for OMVS:=6G B EXIT so exit, memlimit stays 6GB Now, I don't understand what a 'step ended' message spit out for every step by IEFACTRT (hence TRT* message) has to do with IEFUSI? We also have a 'step has started' message named UJI001 spit out of IEFUJI. That dates from before my time here. :-) Best regards, Barbara Hi Barbara, Sorry, I read your post too quickly and for some reason had IEFUSI on the brain instead of TRT (even though you did state TRT). 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: Potential z/OS MPF behavior change -- comments please
I would like to see you change MPFLST, so if you suppress messages (i.e. IEC*) that highlighted IEC messages would still display on the console. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of W. Kevin Kelley Sent: Tuesday, October 19, 2010 9:11 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Potential z/OS MPF behavior change -- comments please Good comments from you all. Thanks! The specific problem we are attempting to solve is interactions between MONITOR message generation and MPF. With the changes we made during the Console Restructure, MONITOR messages can be produced without a console requesting them. You can request that the messages not be queued to a console for display purposes (but will be queued to EMCS consoles for automation purposes) and you can request that the messages not be logged. All of this was done to allow customers whose automation require the messages to receive the messages but not have the messages -- optionally -- go anywhere else. The problem is that if a customer requests that the messages not be logged but puts an entry for the message in MPF, MPF undoes the no logging. The simple solution is to remove the message entry from MPF, but perhaps the customer wanted to drive an MPF exit, and then would be unable to do so. There is a more general question and that is how should we be handling messages that are being generated solely for automation and being solely consumed by automation? The MONITOR messages are but the tip of the iceberg in this regard. We have had requests for ways of specifying on commands that the command response message is to be returned to the console (typically an EMCS automation console) but is not to be logged. From the comments I've seen so far, whatever we do must be optional. W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development -- 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 NOTE: This electronic message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error, any unauthorized review, use, disclosure, distribution or copying of this message is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature or writing. -- 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: Potential z/OS MPF behavior change -- comments please
I agree that if things don't change, they never get better. However, I still stand by the fact that it should be either/or, all/none. There needs to be the ability to maintain status quo for those who desire it. ___ Jim Petersen MVS - Lead Systems Engineer Home Depot Technology Center 1300 Park Center Drive, Austin, TX 78753 www.homedepot.com email:jim_peter...@homedepot.com 512-977-2615 direct 512-977-2930 fax 210-859-9887 cell phone -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, October 18, 2010 4:12 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Potential z/OS MPF behavior change -- comments please On Mon, 18 Oct 2010 15:40:24 -0500, Petersen, Jim wrote: I also agree with Mr. Rosenberg. There has to be a way for us old timers to say we don't care what you want, we want it to be the way it has always been. If things don't change, they never get better. -- gil -- 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 The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message ! or its attachment. -- 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: Potential z/OS MPF behavior change -- comments please
On Mon, 18 Oct 2010 23:49:27 -0500, Barbara Nitz nitz-...@gmx.net wrote: I am heavily using MPF to reduce message traffic to the console, *and* we spit out a 'TRT002' message at every step end (which is rc11 and hence doesn't go to the consoles). Which is an absolute nuisance for the systems that use the newfangled OMVS stuff, because for pages and pages and pages and pages all I see are TRT messages in the hardcopy log. snip HI Barbara, 1) It is recommended to NOT use IEFUSI for OMVS (I removed it many years ago). 2) When I did, I checked for OMVS and skipped writing the messages: CLC 0(4,R5),=C'OMVS' BE SKIPWTO 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: Potential z/OS MPF behavior change -- comments please
I have always taken comfort in the fact that every message was going to be on the syslog. This always gave an immutable paper trail (remember when we tried to print the hardcopy log on paper. Maybe I am an anachronism but I think the syslog should always have every message all the time. If you don't want to see every message then don't look at the syslog. I would absolutely vote NO to changing the way the syslog messages are recorded and would NOT ever like to see messages disappear. There HAS to be a place where the entire story is still available IMNSHO. -- 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: Potential z/OS MPF behavior change -- comments please
On 10/19/2010 1:06 PM, Ricc Harding wrote: I have always taken comfort in the fact that every message was going to be on the syslog. This always gave an immutable paper trail (remember when we tried to print the hardcopy log on paper. Maybe I am an anachronism but I think the syslog should always have every message all the time. If you don't want to see every message then don't look at the syslog. I would absolutely vote NO to changing the way the syslog messages are recorded and would NOT ever like to see messages disappear. There HAS to be a place where the entire story is still available IMNSHO. But if I understand this correctly, these messages normally didn't go to syslog. They only went to syslog if MPF deleted them from the console. Perhaps it would help if we had a sample of the sorts of messages that specify no hardcopy. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Potential z/OS MPF behavior change -- comments please
On 2010-10-15 10:53 PM, W. Kevin Kelley wrote: Back then, every message was considered sacrosanct, so a design decision was made to guarantee that a message could always be found in the SYSLOG even if it was suppressed from display. That design decision no longer makes sense. Messages are no longer sacrosanct; It appears from the responses you have received that a number of people do consider all messages to be sacrosanct. Not too many people want to wade through the volume of messages today, but many people do value them as an audit trail. I think you need to ensure that the current behavior remains available as an option. Perhaps it would be good to initially make the current behavior the default and then switch the default later, as has been done for various other items such as ALLOWUSERKEYCSA and REUSASID. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- 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: Potential z/OS MPF behavior change -- comments please
If it ain't broke (and it isn't!), don't fix it. On Fri, Oct 15, 2010 at 7:53 PM, W. Kevin Kelley wkkel...@optonline.netwrote: MPF has the following behavior: If SUP(YES) or SUP(ALL) is coded on an MPFLSTxx message definition or on a .NO_ENTRY statement, any matching message will always be written to hardcopy (unless overridden by an MPF exit) even if the message -- when issued -- specified no hardcopy (i.e. MPF always forces a matching message that is to be suppressed from display to be hardcopied). MPF was created to reduce console message rates for the 3084 machine (our first 4-way MP -- all of about 27 MIPs). Back then, every message was considered sacrosanct, so a design decision was made to guarantee that a message could always be found in the SYSLOG even if it was suppressed from display. That design decision no longer makes sense. Messages are no longer sacrosanct; we've allowed you to delete them completely for quite awhile (even if we didn't make it easy for you to do so). As part of the Console Restructure, we enhanced the handling of MONITOR messages so that automation programs could receive the messages without the messages having to be written to the SYSLOG or OPERLOG. Unfortunately, it appears that if you create an entry in MPFLSTxx for a MONITOR message (say IEF403I) and MONITOR processing has requested that the message be issued no hardcopy, MPF will override the no hardcopy and force the message to be hardcopied. To make a long story short: we are proposing to change MPF processing so that it no longer forces matching messages to hardcopy. If a message is issued requesting that the message be hardcopied (the default), MPF will honor it; if the message is issued requesting that the message not be hardcopied, MPF will no longer override the request (forcing the message to be hardcopied). If we decide to make this change, it will be done on a release boundary with appropriate Interface Change Notifications (ICNs) to the venders in advance of the release being available. Make sense? I'd like to hear your comments... W. Kevin Kelley -- IBM Pok Lab -- z/OS Core Technical Development -- 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 -- Guy Gardoit z/OS Systems Programming -- 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: Potential z/OS MPF behavior change -- comments please
On Fri, 15 Oct 2010 21:53:07 -0500, W. Kevin Kelley wkkel...@optonline.net wrote: -snip- As part of the Console Restructure, we enhanced the handling of MONITOR messages so that automation programs could receive the messages without the messages having to be written to the SYSLOG or OPERLOG. Unfortunately, it appears that if you create an entry in MPFLSTxx for a MONITOR message (say IEF403I) and MONITOR processing has requested that the message be issued no hardcopy, MPF will override the no hardcopy and force the message to be hardcopied. To make a long story short: we are proposing to change MPF processing so that it no longer forces matching messages to hardcopy. If a message is issued requesting that the message be hardcopied (the default), MPF will honor it; if the message is issued requesting that the message not be hardcopied, MPF will no longer override the request (forcing the message to be hardcopied). -snip- There's no problem definition here and the second paragraph in the excerpt appears to be a generalization of a response or an overreaction to the statement of fact in the first paragraph. What problem are you trying to solve? Best inference I can make is that there is a flood of MONITOR messages overrunning the SYSLOG capability to consume them. If so, then the desired behavior change would amount to honor MPF deletion of MONITOR messages. Scott Fagen Chief Architect CA Technologies - Mainframe -- 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: Potential z/OS MPF behavior change -- comments please
-snip As part of the Console Restructure, we enhanced the handling of MONITOR messages so that automation programs could receive the messages without the messages having to be written to the SYSLOG or OPERLOG. Unfortunately, it appears that if you create an entry in MPFLSTxx for a MONITOR message (say IEF403I) and MONITOR processing has requested that the message be issued no hardcopy, MPF will override the no hardcopy and force the message to be hardcopied. To make a long story short: we are proposing to change MPF processing so that it no longer forces matching messages to hardcopy. If a message is issued requesting that the message be hardcopied (the default), MPF will honor it; if the message is issued requesting that the message not be hardcopied, MPF will no longer override the request (forcing the message to be hardcopied). ---unsnip I would have a problem with this. My management looks upon SYSLOG as the Holy of Holies as far as message/commands are concerned. If I can't force ALL messages to SYSLOG, my management will go absolutely BALLISTIC. I don't mind using a little BAL code to set bits, but make sure that I'll be able to force all messages to SYSLOG. Rick -- 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: Potential z/OS MPF behavior change -- comments please
Good comments from you all. Thanks! The specific problem we are attempting to solve is interactions between MONITOR message generation and MPF. With the changes we made during the Console Restructure, MONITOR messages can be produced without a console requesting them. You can request that the messages not be queued to a console for display purposes (but will be queued to EMCS consoles for automation purposes) and you can request that the messages not be logged. All of this was done to allow customers whose automation require the messages to receive the messages but not have the messages -- optionally -- go anywhere else. The problem is that if a customer requests that the messages not be logged but puts an entry for the message in MPF, MPF undoes the no logging. The simple solution is to remove the message entry from MPF, but perhaps the customer wanted to drive an MPF exit, and then would be unable to do so. There is a more general question and that is how should we be handling messages that are being generated solely for automation and being solely consumed by automation? The MONITOR messages are but the tip of the iceberg in this regard. We have had requests for ways of specifying on commands that the command response message is to be returned to the console (typically an EMCS automation console) but is not to be logged. From the comments I've seen so far, whatever we do must be optional. W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development -- 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: Potential z/OS MPF behavior change -- comments please
Mark, 1) It is recommended to NOT use IEFUSI for OMVS (I removed it many years ago). 2) When I did, I checked for OMVS and skipped writing the messages: CLC 0(4,R5),=C'OMVS' BE SKIPWTO ehm, my USI does this (and has been since I rewrote it when memlimit came out): CLC 0(4,SUBNAME),=C'OMVS' BNE MNOMVS not OMVS MVC 16(8,RA),Z6GIG MEMLIMIT max for OMVS:=6G B EXIT so exit, memlimit stays 6GB Now, I don't understand what a 'step ended' message spit out for every step by IEFACTRT (hence TRT* message) has to do with IEFUSI? We also have a 'step has started' message named UJI001 spit out of IEFUJI. That dates from before my time here. :-) Best regards, Barbara -- 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: Potential z/OS MPF behavior change -- comments please
The SyzMPF/z product we market has those same capabilities and (not just because we market the product) I think it's better to allow individual sites to decide on an individual basis what they want done with messages than to change the entire default behavior. Creating a new function or adding a new type of behavior is a great idea, to change the default is a bad idea. I realize that it is looked at as a default because of some past negligence, but it's a default none-the-less. The whole concept of default behavior changes when you start changing the defaults. I don't think it stagnates a product to establish and adhere to certain default behavior. I think it's a sign of a great product to stick to the rules and not change the rules because it might suit you at that period in time. What would keep IBM from deciding next year that it has another better idea on what the default should be? Personally I have used seemingly trivial Syslog entries to debug and correct issues that would have been difficult or next to impossible to do in a timely manner without them. I don't think making a no-log default is ever a good idea. Just my $.02 Brian -- 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: Potential z/OS MPF behavior change -- comments please
I concur w/Robert Rosenberg's position. Maintain the current behavior as a default, with the option (via parmlib or other) to invoke the new behavior. snip To make a long story short: we are proposing to change MPF processing so that it no longer forces matching messages to hardcopy. If a message is issued requesting that the message be hardcopied (the default), MPF will honor it; if the message is issued requesting that the message not be hardcopied, MPF will no longer override the request (forcing the message to be hardcopied). If we decide to make this change, it will be done on a release boundary with appropriate Interface Change Notifications (ICNs) to the venders in advance of the release being available. Make sense? I'd like to hear your comments... W. Kevin Kelley -- IBM Pok Lab -- z/OS Core Technical Development /snip -- 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: Potential z/OS MPF behavior change -- comments please
I also agree with Mr. Rosenberg. There has to be a way for us old timers to say we don't care what you want, we want it to be the way it has always been. ___ Jim Petersen MVS - Lead Systems Engineer Home Depot Technology Center 1300 Park Center Drive, Austin, TX 78753 www.homedepot.com email:jim_peter...@homedepot.com 512-977-2615 direct 512-977-2930 fax 210-859-9887 cell phone -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert A. Rosenberg Sent: Saturday, October 16, 2010 3:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Potential z/OS MPF behavior change -- comments please At 21:53 -0500 on 10/15/2010, W. Kevin Kelley wrote about Potential z/OS MPF behavior change -- comments please: To make a long story short: we are proposing to change MPF processing so that it no longer forces matching messages to hardcopy. If a message is issued requesting that the message be hardcopied (the default), MPF will honor it; if the message is issued requesting that the message not be hardcopied, MPF will no longer override the request (forcing the message to be hardcopied). If we decide to make this change, it will be done on a release boundary with appropriate Interface Change Notifications (ICNs) to the venders in advance of the release being available. Make sense? I'd like to hear your comments... Sounds good to me. To pacify the backward compatible bevavior types, this change should be made a default with the ability to still force the no-hardcopy override via a parm setting. IOW: Allow the user to require the old behavior for those who want the hardcopy to still contain the message in all cases. -- 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 The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message ! or its attachment. -- 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: Potential z/OS MPF behavior change -- comments please
On Mon, 18 Oct 2010 15:40:24 -0500, Petersen, Jim wrote: I also agree with Mr. Rosenberg. There has to be a way for us old timers to say we don't care what you want, we want it to be the way it has always been. If things don't change, they never get better. -- gil -- 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: Potential z/OS MPF behavior change -- comments please
On 10/15/2010 7:53 PM, W. Kevin Kelley wrote: MPF has the following behavior: If SUP(YES) or SUP(ALL) is coded on an MPFLSTxx message definition or on a .NO_ENTRY statement, any matching message will always be written to hardcopy (unless overridden by an MPF exit) even if the message -- when issued -- specified no hardcopy (i.e. MPF always forces a matching message that is to be suppressed from display to be hardcopied). I had no idea this was the case. IMHO, this behavior seems wrong. At the very least, it violates the principle of least astonishment. Had someone noticed this when MPF was first written, it might have been APARable. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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: Potential z/OS MPF behavior change -- comments please
On 10/15/2010 9:54 PM, W. Kevin Kelley wrote: To make a long story short: we are proposing to change MPF processing so that it no longer forces matching messages to hardcopy. If a message is issued requesting that the message be hardcopied (the default), MPF will honor it; if the message is issued requesting that the message not be hardcopied, MPF will no longer override the request (forcing the message to be hardcopied). I think this is a good idea. If the message wasn't going to hardcopy originally, why add it. If someone really wants it to go to there, they could write an exit to turn the flag on or maybe there could be a new option in MPF to specify a matching message should go to hardcopy. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Potential z/OS MPF behavior change -- comments please
If things don't change, they never get better. But, change for the sake of change is not a good thing. Give me a valid reason (or even a semi-) and I'll change. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- 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: Potential z/OS MPF behavior change -- comments please
On Mon, 18 Oct 2010 14:26:29 -0700, Edward Jaffe edja...@phoenixsoftware.com wrote: I had no idea this was the case. IMHO, this behavior seems wrong. At the very least, it violates the principle of least astonishment. Had someone noticed this when MPF was first written, it might have been APARable. -- Ed, As I said, it was a concious design decision at the time to do it that way and was done to mollify the people that insisted that if a message was suppressed from display, that it'd still be available somewhere else. We can look back on the decision now and say that it was dumb, but at the time, suppressing messages from display ran into a lot of opposition, even though an operator couldn't survive without it. We ran a lot of human factor studies back then on message rates, and what we found was that an operator couldn't handle more than about a message a second on a sustained basis. We also collected and analyzed a lot of SYSLOGs and came up with my Rule of Thumb: an upper bound on message rates is approximately 0.1 message / second / MIP for a system running a broad mix of work -- batch, TSO, CICS, IMS, etc. At ~27 MIPs, a 3084 given that criteria had a message rate of ~2.7 messages / second which was beyond what our human factors studies said an operator could handle. That is of course aggregate, but what we also found out was that the bulk of the message traffic was going to route codes 1 2 which was the master console. You could try to split some of the traffic off to other consoles, but the master console (and the operator assigned to it) became the bottleneck. This all seems quaint by today's standards, but it was quite a problem at the time. I still remember having to present to the Poughkeepsie (hardware) Lab Director (a guy known as Black Jack Bertram) and tell him that his shiny new 3084 couldn't be operated (and possibly not sold) because of the message rate problem. To put it politely, he wasn't happy. And that is how MPF very quickly came into being, warts and all. At least some of the warts are fixable... W. Kevin Kelley -- IBM Pok Lab -- z/OS Core Technical Development -- 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: Potential z/OS MPF behavior change -- comments please
On 10/18/2010 6:00 PM, W. Kevin Kelley wrote: As I said, it was a concious design decision at the time to do it that way and was done to mollify the people that insisted that if a message was suppressed from display, that it'd still be available somewhere else. Maybe I was too hasty. If a message is suppressed from every console AND from the log, it could be considered lost. So both positions have merit. What is the rationale for changing the default behavior now? Too many messages on the log nowadays? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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: Potential z/OS MPF behavior change -- comments please
Maybe I was too hasty. If a message is suppressed from every console AND from the log, it could be considered lost. Exactly. That was my first thought. In my experience, I am *required* to proof to all and sundry (most notably IBM software support) that things happened in a certain order or that they happened *at all*. How am I supposed to do that if a message is suppressed from hardcopy? I am heavily using MPF to reduce message traffic to the console, *and* we spit out a 'TRT002' message at every step end (which is rc11 and hence doesn't go to the consoles). Which is an absolute nuisance for the systems that use the newfangled OMVS stuff, because for pages and pages and pages and pages all I see are TRT messages in the hardcopy log. BUT that has saved our beacon a number of times when it came time to *prove* that things happened the way they did. So both positions have merit. No, I don't think so. Keep the old behaviour as default and let those that have no clue about tell-tale trails use the new option. Rather, educate most of the world how to *read* a hardcopy log. In my experience, I am the only one around here who is able to tell if a message went to hardcopy only or what its routing codes are to determine if it showed up at the console. Reading a hardcopy log is almost as interesting as redaing a system trace table. Almost, but not quite. I am always stumped when I am required to tell the descriptor code, as that doesn't really show up (other than the asterisk). And educate all the IBM development labs in the *meaning* of routing codes (and descriptor codes, while you're at it!). Their defaults (think Merva or NetView or a few others) are just stupid. A large collection of routing codes that would go to the console for a message that is needed at the most in hardcopy log. And since *those* defaults were set a long time ago, nobody knows anymore *why*, much less how to change them. (There are a few that have customizable routing code settings.) Barbara Nitz -- 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: Potential z/OS MPF behavior change -- comments please
On Mon, 2010-10-18 at 23:49 -0500, Barbara Nitz wrote: snip And educate all the IBM development labs in the *meaning* of routing codes (and descriptor codes, while you're at it!). Their defaults (think Merva or NetView or a few others) are just stupid. A large collection of routing codes that would go to the console for a message that is needed at the most in hardcopy log. And since *those* defaults were set a long time ago, nobody knows anymore *why*, much less how to change them. (There are a few that have customizable routing code settings.) One thing nice about CA-OPS/MVS (and maybe other auto ops packages) is that if I really need to, I can change the ROUTCDE and/or DESC as I desire. Also, there is an option to totally suppress the message from the z/OS console and even SYSLOG/OPERLOG. Barbara Nitz -- 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 -- John McKown Maranatha! -- 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: Potential z/OS MPF behavior change -- comments please
At 21:53 -0500 on 10/15/2010, W. Kevin Kelley wrote about Potential z/OS MPF behavior change -- comments please: To make a long story short: we are proposing to change MPF processing so that it no longer forces matching messages to hardcopy. If a message is issued requesting that the message be hardcopied (the default), MPF will honor it; if the message is issued requesting that the message not be hardcopied, MPF will no longer override the request (forcing the message to be hardcopied). If we decide to make this change, it will be done on a release boundary with appropriate Interface Change Notifications (ICNs) to the venders in advance of the release being available. Make sense? I'd like to hear your comments... Sounds good to me. To pacify the backward compatible bevavior types, this change should be made a default with the ability to still force the no-hardcopy override via a parm setting. IOW: Allow the user to require the old behavior for those who want the hardcopy to still contain the message in all cases. -- 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
Potential z/OS MPF behavior change -- comments please
MPF has the following behavior: If SUP(YES) or SUP(ALL) is coded on an MPFLSTxx message definition or on a .NO_ENTRY statement, any matching message will always be written to hardcopy (unless overridden by an MPF exit) even if the message -- when issued -- specified no hardcopy (i.e. MPF always forces a matching message that is to be suppressed from display to be hardcopied). MPF was created to reduce console message rates for the 3084 machine (our first 4-way MP -- all of about 27 MIPs). Back then, every message was considered sacrosanct, so a design decision was made to guarantee that a message could always be found in the SYSLOG even if it was suppressed from display. That design decision no longer makes sense. Messages are no longer sacrosanct; we've allowed you to delete them completely for quite awhile (even if we didn't make it easy for you to do so). As part of the Console Restructure, we enhanced the handling of MONITOR messages so that automation programs could receive the messages without the messages having to be written to the SYSLOG or OPERLOG. Unfortunately, it appears that if you create an entry in MPFLSTxx for a MONITOR message (say IEF403I) and MONITOR processing has requested that the message be issued no hardcopy, MPF will override the no hardcopy and force the message to be hardcopied. To make a long story short: we are proposing to change MPF processing so that it no longer forces matching messages to hardcopy. If a message is issued requesting that the message be hardcopied (the default), MPF will honor it; if the message is issued requesting that the message not be hardcopied, MPF will no longer override the request (forcing the message to be hardcopied). If we decide to make this change, it will be done on a release boundary with appropriate Interface Change Notifications (ICNs) to the venders in advance of the release being available. Make sense? I'd like to hear your comments... W. Kevin Kelley -- IBM Pok Lab -- z/OS Core Technical Development -- 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
