David It looks like these excessive messages you are describing constitutes a *problem* for you and I guess - it's not really actually stated - that you are appealing to those from "other shops" who may have had to face this problem.
Well, I'm not from any particular shop having this problem although the customer with which I am working from time to time these days certainly had an ATCCON00 member which needed cleaning up so that we always reviewed the VTAM log - as well as just removing known atrophied members - in order to be sure the new ATCCON00 was correct. Assuming that, as a result of your untended ATCCON00 member, the bulk of the messages you don't want are messages with the same message identifier, what you should do is review Communications Server SNA Resource Definition Reference > Chapter 5. User-defined tables and data filter > Message-flooding prevention table. This may offer you a more surgical way to deal with these messages. I wonder really why it might not just be faster and better simply to clean up the ATCCON00 member. After all somebody in the installation should understand your VTAM environment and be able to do the job swiftly - or is this yet another case of a vital member of the team having been "let go"? Chris Mason On Wed, 8 Oct 2008 11:24:06 -0500, Cebell, David <[EMAIL PROTECTED]> wrote: >Years ago we had VTAM Systems Programmer who attended to this >discipline. > >Now we do it all. > > > >The VTAM ATCCON00 list is very old and large. > >It needs to be cleaned up but is a low priority. > > > >So we are flooding the SYSLOG with NET / VTAM / IST* messages which we >pretty much ignore. > >A MPFLST entry will stop the mundane messages from appearing on the >Consoles but they are > >Still routed to the SYSLOG. > > > >And since we do most of our work using SDSF, which views the SYSLOG, we >must wade through all the > >IST* messages to find what we are looking for. > > > >The "quick and dirty" is to issue > >F NET,VTAMOPTS,SUPP=SER but this stops the valid errors. > > > >Certainly this can not be the only shop that has this issue. ---------------------------------------------------------------------- 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

