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

Reply via email to