On Tue, 20 Oct 2009 09:17:26 -0500, David Waldman <[email protected]> wrote:
>Tuco, > >The 'K Q' command is no longer suported for EMCS consoles on 1.9. This is >explained in the z/OS V1R9.0 MVS Planning: Operations manual. > Dave, Control (K) commands have never applied to EMCS consoles as far as I know and that is because EMCS consoles are a programming interface and not real consoles. It also has to do with the queuing that is behind EMCS consoles -- it is not the same queuing that is behind MCS and SMCS consoles. EMCS queuing is data space based and involves Message Data Blocks (MDBs). MCS and SMCS queuing resides in Consoles below-the-line private and is WQE and CQE based. The Control commands understand CQEs and WQEs; they do not understand MDBs. Now it is true that prior to the z/OS R4 Console Restructure that messages would pass through the MCS and SMCS queues on their way to the EMCS queues. If the MCS and SMCS queues got backed up, that also affected messages going to the EMCS queues. In that case, K Q commands issued against MCS or SMCS consoles might unclog the MCS and SMCS queues sufficiently that messages would again flow to the EMCS queues, but this was a side-effect of clearing the MCS and/or SMCS console queues, nothing more. With the z/OS R4 Console Restructure, the message flow was drastically altered -- all messages flow into the Console Message Cache data space and from that messages are pulled by three queuing tasks that queue messages to all of the EMCS queues. There are several special EMCS queues -- one of which receives all of the messages destined for all of the MCS and SMCS consoles. Messages in that special EMCS queue are extracted, converted from MDBs into WQEs and then inserted into the traditional WQE/CQE based MCS and SMCS console queues, which still exist in below-the-line Console private. The Control (K) commands still apply to those queues, but because EMCS queuing occurs prior to queuing to the MCS and SMCS consoles, K Q commands no longer affect messages going to the EMCS queues. As I said earlier, use of the K Q command prior to the Console Restructure had the side-effect of sometimes getting messages flowing again to EMCS consoles, but the K Q command was never modified to specifically manipulate EMCS queues. Because EMCS and SYSLOG traffic no longer pass through the MCS and SMCS message queues, console buffer shortages should be less common. Also, by splitting the EMCS and SYSLOG traffic out of the message path earlier, EMCS consoles and SYSLOG (OPERLOG too) will continue to operate even if a buffer shortage has affected MCS and SMCS consoles. In the past, EMCS and SYSLOG died along with the MCS and SMCS consoles. If you are seeing console buffer shortage conditions within EMCS, it is usually caused by one of two things: messages are not being removed from the EMCS data space as rapidly as they are being queued, or perhaps the data space was sized too small to handle fluctuations in message rates. Now it is certainly the case that message floods can overwhelm EMCS consoles just as they do MCS and SMCS consoles (although not as easily). You are using MPF to suppress a lot of your message traffic I hope? And you have implemented Message Flood Automation to handle message floods, right? W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
