Re: The Programmable Operator Facility
On Wed, Jul 9, 2008 at 7:37 PM, Imler, Steven J [EMAIL PROTECTED] wrote: Actually, generally speaking the CA VM products do not require these messages to function. And, in fact it is standard practice at many shops who run VM:Operator to do exactly this ... remove the noise of ATTACH and DETACH from the operator console. Trick is that these messages go to different parties (the one who issued the command, the recipient of the device, and the system operator). There's a check to prevent duplicates (if you attach to yourself, or when you are the system operator). I recall from a previous life that Dynam/T had the option to suppress the messages (useful, since it does an ATTACH / DETACH to scan the unit every few minutes). So the Dynam/T server issued the command and was recipient of the device. To suppress the messages, it would issue a STORE in its own VMDBK to make CP think it was the system operator. That meant that CP could skip all but one message, to Dynam/T itself. Unfortunately, other operator messages during that brief moment (typically EREP) would also not show on the operator console. But a backlevel version of Dynam/T stored in the wrong spot of the VMDBK (nice dump, we've used that for training purposes a few times). So we decided to just suppress them in PROP. This actually turned out to be helpful in diagnosing Dynam/T problems because you could see which units were being scanned. Rob - there is no information overload in a system log when you try to solve a problem
Re: The Programmable Operator Facility
In PROP, logging is all or nothing. VM:Operator has a NOLOG option, I don't know about IBM Operations Manager. At the other hand: DASD isn't that expensive, incomplete log files make debugging less easy. Alternatively, you could postprocess the log file of the previous day and code a PIPE filter to remove what you don't want to keep. 2008/7/9 Ray Waters [EMAIL PROTECTED]: We run z/VM 520 and use PROPST to filter messages to the OP1 console. We filter several commands including ATTACHED and DETACHED commands. I would like to filter other messages such as ATTACHED and DETACHED from going to the LOG FILE (LGYYMMDD XX) on Operator's 191 MDISK. In reading the CMS Planning and Administration Guide, I don't see how this can be done. We are a heavy TAPE use shop using DFSMS/RMS and there are just too many of these messages going to this log file. Is there a way to suppress the logging of certain messages? Thanks, Ray Waters Mainframe Technical Support Analyst Open Solutions Inc. 11 Greenway Plaza, Suite 300 Houston, TX 77046-1102 Office 713-965-8451 Cell 713-705-5403 Fax713-965-8405 Email [EMAIL PROTECTED] www.bank.opensolutions.com www.opensolutions.com NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You. -- Kris Buelens, IBM Belgium, VM customer support
Re: The Programmable Operator Facility
Personally I think ATTACH and DETACH (and others too i.e. DIAL) should have a NOMSG type option to just eliminate the message alltogether. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Kris Buelens Sent: Wednesday, July 09, 2008 11:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility In PROP, logging is all or nothing. VM:Operator has a NOLOG option, I don't know about IBM Operations Manager. At the other hand: DASD isn't that expensive, incomplete log files make debugging less easy. Alternatively, you could postprocess the log file of the previous day and code a PIPE filter to remove what you don't want to keep. 2008/7/9 Ray Waters [EMAIL PROTECTED]: We run z/VM 520 and use PROPST to filter messages to the OP1 console. We filter several commands including ATTACHED and DETACHED commands. I would like to filter other messages such as ATTACHED and DETACHED from going to the LOG FILE (LGYYMMDD XX) on Operator's 191 MDISK. In reading the CMS Planning and Administration Guide, I don't see how this can be done. We are a heavy TAPE use shop using DFSMS/RMS and there are just too many of these messages going to this log file. Is there a way to suppress the logging of certain messages? Thanks, Ray Waters Mainframe Technical Support Analyst Open Solutions Inc. 11 Greenway Plaza, Suite 300 Houston, TX 77046-1102 Office 713-965-8451 Cell 713-705-5403 Fax713-965-8405 Email [EMAIL PROTECTED] www.bank.opensolutions.com www.opensolutions.com NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You. -- Kris Buelens, IBM Belgium, VM customer support
Re: The Programmable Operator Facility
Alan may have fits over giving such power to users at logon time. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, July 09, 2008 9:05 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility Personally I think ATTACH and DETACH (and others too i.e. DIAL) should have a NOMSG type option to just eliminate the message alltogether. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Kris Buelens Sent: Wednesday, July 09, 2008 11:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility In PROP, logging is all or nothing. VM:Operator has a NOLOG option, I don't know about IBM Operations Manager. At the other hand: DASD isn't that expensive, incomplete log files make debugging less easy. Alternatively, you could postprocess the log file of the previous day and code a PIPE filter to remove what you don't want to keep. 2008/7/9 Ray Waters [EMAIL PROTECTED]: We run z/VM 520 and use PROPST to filter messages to the OP1 console. We filter several commands including ATTACHED and DETACHED commands. I would like to filter other messages such as ATTACHED and DETACHED from going to the LOG FILE (LGYYMMDD XX) on Operator's 191 MDISK. In reading the CMS Planning and Administration Guide, I don't see how this can be done. We are a heavy TAPE use shop using DFSMS/RMS and there are just too many of these messages going to this log file. Is there a way to suppress the logging of certain messages? Thanks, Ray Waters Mainframe Technical Support Analyst Open Solutions Inc. 11 Greenway Plaza, Suite 300 Houston, TX 77046-1102 Office 713-965-8451 Cell 713-705-5403 Fax713-965-8405 Email [EMAIL PROTECTED] www.bank.opensolutions.com www.opensolutions.com NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You. -- Kris Buelens, IBM Belgium, VM customer support
Re: The Programmable Operator Facility
DASD space is not the issue. While reviewing these logs, debugging other problems is slowed due to the volume of ATT/DET commands. Tapes being attached or detached is usually not a problem. Ray -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Wednesday, July 09, 2008 11:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility In PROP, logging is all or nothing. VM:Operator has a NOLOG option, I don't know about IBM Operations Manager. At the other hand: DASD isn't that expensive, incomplete log files make debugging less easy. Alternatively, you could postprocess the log file of the previous day and code a PIPE filter to remove what you don't want to keep. 2008/7/9 Ray Waters [EMAIL PROTECTED]: We run z/VM 520 and use PROPST to filter messages to the OP1 console. We filter several commands including ATTACHED and DETACHED commands. I would like to filter other messages such as ATTACHED and DETACHED from going to the LOG FILE (LGYYMMDD XX) on Operator's 191 MDISK. In reading the CMS Planning and Administration Guide, I don't see how this can be done. We are a heavy TAPE use shop using DFSMS/RMS and there are just too many of these messages going to this log file. Is there a way to suppress the logging of certain messages? Thanks, Ray Waters Mainframe Technical Support Analyst Open Solutions Inc. 11 Greenway Plaza, Suite 300 Houston, TX 77046-1102 Office 713-965-8451 Cell 713-705-5403 Fax713-965-8405 Email [EMAIL PROTECTED] www.bank.opensolutions.com www.opensolutions.com NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You. -- Kris Buelens, IBM Belgium, VM customer support NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You.
Re: The Programmable Operator Facility
You might consider using the CP SILENTLY command. From the help file for SILENTLY: Examples 1. To attach device 1234 to user MVS and suppress the messages sent to the issuer, to the user who is the object of the ATTACH, and to the system operator: a. Enable the ATTACH command for response suppression: modify command attach silent b. Issue the SILENTLY command for ATTACH: silently attach 1234 to mvs as 1234 If you are willing to add a 'NOMSG' option to the ATTACH command, might you be willing to precede the ATTACH command with 'SILENTLY' instead? I do not know if this meets your needs or not. Any ATTACH command that is not preceded with SILENTLY, will continue to operate as it does now. For any ATTACH command that is preceded with SILENTLY, message output is suppressed. For more information, please see the HELP files for CP SILENTLY and CP MODIFY COMMAND or get the information from the CP Commands and Utilities Reference book. Doug Breneman z/VM Development IBM Endicott, NY From: Huegel, Thomas [EMAIL PROTECTED] To: IBMVM@LISTSERV.UARK.EDU Date: 07/09/2008 12:05 PM Subject:Re: The Programmable Operator Facility Personally I think ATTACH and DETACH (and others too i.e. DIAL) should have a NOMSG type option to just eliminate the message alltogether. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Kris Buelens Sent: Wednesday, July 09, 2008 11:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility In PROP, logging is all or nothing. VM:Operator has a NOLOG option, I don't know about IBM Operations Manager. At the other hand: DASD isn't that expensive, incomplete log files make debugging less easy. Alternatively, you could postprocess the log file of the previous day and code a PIPE filter to remove what you don't want to keep. 2008/7/9 Ray Waters [EMAIL PROTECTED]: We run z/VM 520 and use PROPST to filter messages to the OP1 console. We filter several commands including ATTACHED and DETACHED commands. I would like to filter other messages such as ATTACHED and DETACHED from going to the LOG FILE (LGYYMMDD XX) on Operator's 191 MDISK. In reading the CMS Planning and Administration Guide, I don't see how this can be done. We are a heavy TAPE use shop using DFSMS/RMS and there are just too many of these messages going to this log file. Is there a way to suppress the logging of certain messages? Thanks, Ray Waters Mainframe Technical Support Analyst Open Solutions Inc. 11 Greenway Plaza, Suite 300 Houston, TX 77046-1102 Office 713-965-8451 Cell 713-705-5403 Fax713-965-8405 Email [EMAIL PROTECTED] www.bank.opensolutions.com www.opensolutions.com NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You. -- Kris Buelens, IBM Belgium, VM customer support
Re: The Programmable Operator Facility
I have a CLEANLOG XEDIT macro to remove various messages from console logs. It shows a selection panel. Things one can remove: - All LOGON/LOGOFF messages - All or many RSCS messages - SCIF messages of users you indicate - Various VMOPER macro messages - ... It really deletes the lines from the log. No problem in our case as we do not really XEDIT a LOGFILE, it is meant to be called after we run LGOPER, an EXEC -with a panel- that allows one to select the date of the log, timespan, etc; LGOPER creates an empty -storage resident only- file with what you selected, its fmode is set to A, so a FILE or SAVE won't change the real log. I'll send it to you for inspiration. It is however coded to handle VMOPER log files; PROP logfiles will be different in what if found where. 2008/7/9 Thomas Kern [EMAIL PROTECTED]: In viewing the logs with xedit, you could do an ALL command with not /ATTACH/ or not /DETACH/. That should help reduce what you need to look at. /Tom Kern Ray Waters wrote: DASD space is not the issue. While reviewing these logs, debugging other problems is slowed due to the volume of ATT/DET commands. Tapes being attached or detached is usually not a problem. Ray -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Wednesday, July 09, 2008 11:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility In PROP, logging is all or nothing. VM:Operator has a NOLOG option, I don't know about IBM Operations Manager. At the other hand: DASD isn't that expensive, incomplete log files make debugging less easy. Alternatively, you could postprocess the log file of the previous day and code a PIPE filter to remove what you don't want to keep. -- Kris Buelens, IBM Belgium, VM customer support
Re: The Programmable Operator Facility
Alan or Chuckie? I'm not 100% sure, so Steve Imler may have to chime in, but if your using VM:Tape, VM:Backup, et al, these products may look for certain messages to be posted before doing something else. Of course if you don't use the CA products or DFSMS, this probably doesn't apply. Steve -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, July 09, 2008 12:10 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility Alan may have fits over giving such power to users at logon time. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, July 09, 2008 9:05 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility Personally I think ATTACH and DETACH (and others too i.e. DIAL) should have a NOMSG type option to just eliminate the message alltogether. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Kris Buelens Sent: Wednesday, July 09, 2008 11:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility In PROP, logging is all or nothing. VM:Operator has a NOLOG option, I don't know about IBM Operations Manager. At the other hand: DASD isn't that expensive, incomplete log files make debugging less easy. Alternatively, you could postprocess the log file of the previous day and code a PIPE filter to remove what you don't want to keep. 2008/7/9 Ray Waters [EMAIL PROTECTED]: We run z/VM 520 and use PROPST to filter messages to the OP1 console. We filter several commands including ATTACHED and DETACHED commands. I would like to filter other messages such as ATTACHED and DETACHED from going to the LOG FILE (LGYYMMDD XX) on Operator's 191 MDISK. In reading the CMS Planning and Administration Guide, I don't see how this can be done. We are a heavy TAPE use shop using DFSMS/RMS and there are just too many of these messages going to this log file. Is there a way to suppress the logging of certain messages? Thanks, Ray Waters Mainframe Technical Support Analyst Open Solutions Inc. 11 Greenway Plaza, Suite 300 Houston, TX 77046-1102 Office 713-965-8451 Cell 713-705-5403 Fax713-965-8405 Email [EMAIL PROTECTED] www.bank.opensolutions.com www.opensolutions.com NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You. -- Kris Buelens, IBM Belgium, VM customer support
Re: The Programmable Operator Facility
On Wednesday, 07/09/2008 at 12:05 EDT, Huegel, Thomas [EMAIL PROTECTED] wrote: Personally I think ATTACH and DETACH (and others too i.e. DIAL) should have a NOMSG type option to just eliminate the message alltogether. Bite your tongue and perish the thought. DIAL??? That is a class ANY command. You want to let people you don't know suppress the knowledge that they are using your system?!? I'm feeling faint. Alan Altmark z/VM Development IBM Endicott
Re: The Programmable Operator Facility
I told you that Alan would be upset by the notion. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, July 09, 2008 10:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility On Wednesday, 07/09/2008 at 12:05 EDT, Huegel, Thomas [EMAIL PROTECTED] wrote: Personally I think ATTACH and DETACH (and others too i.e. DIAL) should have a NOMSG type option to just eliminate the message alltogether. Bite your tongue and perish the thought. DIAL??? That is a class ANY command. You want to let people you don't know suppress the knowledge that they are using your system?!? I'm feeling faint. Alan Altmark z/VM Development IBM Endicott
Re: The Programmable Operator Facility
Steve, Actually, generally speaking the CA VM products do not require these messages to function. And, in fact it is standard practice at many shops who run VM:Operator to do exactly this ... remove the noise of ATTACH and DETACH from the operator console. That being said, you may need these messages to trigger certain events ... for example a STK .DISMOUNT command to remove unloaded tapes from the tape transport (but I think the messages can still be suppressed from the operator console, you just have to be careful of the order you do things). That being said (again), Kris is correct that sometimes you need this information to diagnose a problem(s). You usually realize you really need the information because you don't have it. JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gentry, Stephen Sent: Wednesday, July 09, 2008 12:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility Alan or Chuckie? I'm not 100% sure, so Steve Imler may have to chime in, but if your using VM:Tape, VM:Backup, et al, these products may look for certain messages to be posted before doing something else. Of course if you don't use the CA products or DFSMS, this probably doesn't apply. Steve -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, July 09, 2008 12:10 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility Alan may have fits over giving such power to users at logon time. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, July 09, 2008 9:05 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility Personally I think ATTACH and DETACH (and others too i.e. DIAL) should have a NOMSG type option to just eliminate the message alltogether. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Kris Buelens Sent: Wednesday, July 09, 2008 11:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility In PROP, logging is all or nothing. VM:Operator has a NOLOG option, I don't know about IBM Operations Manager. At the other hand: DASD isn't that expensive, incomplete log files make debugging less easy. Alternatively, you could postprocess the log file of the previous day and code a PIPE filter to remove what you don't want to keep. 2008/7/9 Ray Waters [EMAIL PROTECTED]: We run z/VM 520 and use PROPST to filter messages to the OP1 console. We filter several commands including ATTACHED and DETACHED commands. I would like to filter other messages such as ATTACHED and DETACHED from going to the LOG FILE (LGYYMMDD XX) on Operator's 191 MDISK. In reading the CMS Planning and Administration Guide, I don't see how this can be done. We are a heavy TAPE use shop using DFSMS/RMS and there are just too many of these messages going to this log file. Is there a way to suppress the logging of certain messages? Thanks, Ray Waters Mainframe Technical Support Analyst Open Solutions Inc. 11 Greenway Plaza, Suite 300 Houston, TX 77046-1102 Office 713-965-8451 Cell 713-705-5403 Fax713-965-8405 Email [EMAIL PROTECTED] www.bank.opensolutions.com www.opensolutions.com NOTICE: This e-mail is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the original message at the listed email address. Thank You. -- Kris Buelens, IBM Belgium, VM customer support
Re: The Programmable Operator Facility
Richard, You were right on with that one.. You get a point. But I'd rether VTAM/CICS worry about that stuff, I don't really care to see a message that just says 'L007 DIALED TO VTAM1' that tells me nothing. Here is an idea that'll cause nightmeres. Turn off logging for operator (PROP) filter stuff I don't want to see, then run PROP on LGLOPR with logging turned on.. ugh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Schuh, Richard Sent: Wednesday, July 09, 2008 12:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility I told you that Alan would be upset by the notion. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, July 09, 2008 10:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility On Wednesday, 07/09/2008 at 12:05 EDT, Huegel, Thomas [EMAIL PROTECTED] wrote: Personally I think ATTACH and DETACH (and others too i.e. DIAL) should have a NOMSG type option to just eliminate the message alltogether. Bite your tongue and perish the thought. DIAL??? That is a class ANY command. You want to let people you don't know suppress the knowledge that they are using your system?!? I'm feeling faint. Alan Altmark z/VM Development IBM Endicott
Re: The Programmable Operator Facility
If you use IBM Operations Manager for z/VM, you can have your cake and ea t it, too. You can create rules to suppress specific messages from the console of one or more service machines, so when you view the console usi ng Operations Manager, the noise has been reduced. But the message will always be in the master log of all consoles that Operations Manager keeps . So when you're looking at a console to debug something, the messages you don't think you need to see aren't there, but if you find you need them, you can look in the log instead. Tracy Dean, IBM
Re: The Programmable Operator Facility
Actually I have to agree with Alan, I too like to see logging on the operator log and lots of it. In fact, i'd like to see even more than we have now. How about the network guy who has changed the vswitch configs and then we have to guess what he had changed? Or what about some user who has defined a minidisk over my IPL pack or the user that had defined a minidisk on the DIRMAINT 1DB (OK, usually it's me but that is besides the point)? And even the attach and detach messages produced because DYNAMCMS searches for a tape has helped me to investigate some errors in the past. But in all cases I don't like to see them on the LGLOPR console so they are suppressed but I still can view the events from the operator log and take action if I need to. I do agree that it would be nice to at least be able to suppress logging for some selected events. Then it would be up to me to decide if I realy want to get rid of some selected messages. Regards, Berry. Huegel, Thomas schreef: Richard, You were right on with that one.. You get a point. But I'd rether VTAM/CICS worry about that stuff, I don't really care to see a message that just says 'L007 DIALED TO VTAM1' that tells me nothing. Here is an idea that'll cause nightmeres. Turn off logging for operator (PROP) filter stuff I don't want to see, then run PROP on LGLOPR with logging turned on.. ugh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Schuh, Richard Sent: Wednesday, July 09, 2008 12:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility I told you that Alan would be upset by the notion. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, July 09, 2008 10:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: The Programmable Operator Facility On Wednesday, 07/09/2008 at 12:05 EDT, Huegel, Thomas [EMAIL PROTECTED] wrote: Personally I think ATTACH and DETACH (and others too i.e. DIAL) should have a NOMSG type option to just eliminate the message alltogether. Bite your tongue and perish the thought. DIAL??? That is a class ANY command. You want to let people you don't know suppress the knowledge that they are using your system?!? I'm feeling faint. Alan Altmark z/VM Development IBM Endicott
