Abdullah After my last post, doing some other work I was reminded of another way in which you could suppress VTAM messages.
This suggestion from Juergen Keller is yet another idea. - Let's first explain what Juergen Keller is talking about. >From time to time there is a discussion in this list over what "USS" means. Normally I find myself defending VTAM's corner in relation to the *terminal user* flavour of VTAM's USS. In this case we are dealing with a much more obscure flavour of VTAM's USS which is the *operator* flavour. Table ISTINCNO provides templates for both VTAM commands as described in the z/OS Communications Server (CS) SNA Operations manual and VTAM messages as described in the z/OS CS SNA Messages manuals - as well as the z/OS CS Operations manual in the form of example output from commends. One of the operands of each message template is SUPP. This indicates the *level* of the message to be compared with a global level set by the SUPP start option and which can be changed by the MODIFY SUPP command. As supplied in table ISTINCNO message IST663I (and all messages following in the multi-line message group) are given the level SER which means you must want to suppress *all* messages considered to have a level of "serious" in order to prevent message IST663I from appearing - if you used the table ISTINCNO without change. This is clearly not a good idea! However, there are two options which, in effect, bypass the specification of the SUPP start option (and associated MODIFY command). These are NEVER, meaning never suppress the message whatever the specified "SUPP" level is, and ALWAYS, meaning always suppress the message whatever the specified "SUPP" level is. Juergen Keller is suggesting modifying the supplied ISTINCNO table, reassembling it and relinkage-editing it in order to store the resulting load module into a user VTAMLIB concatenated before the supplied VTAMLIB in your VTAM started task procedure member, typically named NET. Now let us compare this idea with simply entering the following command: MODIFY NET,VTAMOPTS,SIRFMSG=NONE This will have an effect identical to Juergen Keller's suggestion. You may or may not be familiar with the English expression, "using a sledgehammer to crack a nut" but here I present you with an apposite application! Incidentally, trying OW13186 in the search field on the www.ibm.com web site yields no hits. - And now to the other possibility I recalled after my last post. It may be that, despite your best efforts, you cannot eliminate the source of the IST663I messages. It may be that normal operational conditions require that one application repeatedly tries to initiate a session with an application which, for very good reasons, cannot always be running. It may be that there are no commands available easily to prevent the session setup attempts and so you must accept periods during which VTAM has a reason to create these IST663I messages. The other suggestion I have is to use the "message-flooding prevention table". Using this table you can ensure that a message is produced one time and that following essentially identical messages are suppressed for a period of time. You can read up on how to use this table in actually the same chapter of the z/OS CS SNA Resource Definition Reference manual as describes the use of the ISTINCNO table, Chapter 5, "User-defined tables and data filter". However one enormous benefit in using the "message-flooding prevention table" is that no assembly and linkage edit is required and the revised table is stored in your VTAMLST library. The other benefit is that you are reminded by one message every so often that the problem described by the IST663I message still exists. Please post again if you need help with this suggestion. Chris Mason On Mon, 31 Aug 2009 01:45:30 -0500, Juergen Keller <[email protected]> wrote: >hi, >have a look at "SYS1.SAMPLIB(ISTINCNO)". There you can see how the messages >are defined. There might be an option to change SUPP to ALWAYS and create a >new table. I havn't done this before so I don't know if it works. See als >OW13186 for some explanations. Maybe this helps you. >Juergen Keller ---------------------------------------------------------------------- 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
