ist663i suppression
Abdullah AlShaalan
I try to supress ist663i using MPF but it does not work.
I used netview to suppress it before.
know, we cancel the netview license, so I need a way to suppress this messge.
thank you
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Binyamin Dissen
wrote:
:>I try to supress ist663i using MPF but it does not work.
How are you trying?
What do you mean by "it does not work"?
:>I used netview to suppress it before.
:>know, we cancel the netview license, so I need a way to suppress this messge.
--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
Chris Mason
> so I need a way to suppress this (IST553I) messge.
There's the hard - but right - way and there's the easy - but wrong - way.
-
The easy - but wrong - way to suppress the IST663I message - and all
following messages in the message group - is to specify SIRFMSG=NONE in the
start option member of VTAMLST, ATCSTRxx, in all your VTAMs.
<quote>
SIRFMSG start option
Controls the display of messages IST663I, IST664I, IST889I, and their
message groups. These messages are issued when a session initiation request
fails. The ASIRFMSG, ESIRFMSG, FSIRFMSG, and RSIRFMSG start options can
be used in conjunction with SIRFMSG to generate additional messages as part
of this message group.
- ASIRFMSG controls whether the IST890I and IST896I messages are
displayed.
- ESIRFMSG controls whether the IST891I, IST892I, and IST893I messages
are displayed.
- FSIRFMSG controls whether the IST1704I, IST1705I, IST894I, and IST895I
messages are displayed.
- RSIRFMSG controls whether the IST1460I, IST1461I, IST2102I, IST2103I,
and IST2104I messages are displayed.
You can change the value of SIRFMSG with the MODIFY VTAMOPTS command
while VTAM is running.
SIRFMSG=ALLSSCP
Specifies that messages are issued in all SSCPs. This the default.
SIRFMSG=OLUSSCP
Specifies that messages are issued only in the origin logical unit (OLU) SSCP.
SIRFMSG=NONE
Specifies that no messages are issued in any SSCP.
</quote>
The above is a slightly edited version of the description of the SIRFMSG start
option ion the z/OS Communications Server SNA Resource Definition Reference
manual.
-
However, the right way to go about suppressing the IST663I message and all
the following messages in the message group is first to work out why the
messages are there in the first place and then deal with the problem which
causes them to be created.
Here's the prototype for the IST663I, IST664I and IST896I messages from
the z/OS Communications Server SNA Messages manual:
<quote>
IST663I request REQUEST [{TO|FROM} adjnode] action, SENSE= code
Explanation: This message is the first in a group of messages that VTAM
issues when a request/response unit (RU) fails to complete successfully. A
description of the message group follows.
IST663I request REQUEST [{TO|FROM} adjnode] action, SENSE=code
IST664I {REAL|ALIAS} {OLU|PLU}=luname1 {REAL|ALIAS} {DLU|SLU}
=luname2
IST889I SID = sessid
</quote>
An IST663I message group appears because there has been a *failure* in
setting up a session. Some presumably business function in your installation is
not working correctly and whoever is responsible for the SNA-based
applications needs to solve whatever problem the IST663I message group
describes.
I'm assuming that at some time in the past somebody noticed that there were
a lot of IST663I messages and, rather than bother about why they were being
created, "cleverly" recalled that the quick way to deal with unwanted
messages was to use the NetView "Message Automation Table" (MAT),
forgetting that the purpose of the NetView MAT was to get rid of messages
which didn't really matter - of which indeed there are many.[1]
In conclusion, solving the problem described by each IST663I message group
is the right way to suppress them.
-
Addendum: there is also a *wasteful* way to suppress any message -
sometimes unavoidable - which is to suppress the message *after* a product,
in this case VTAM, has gone to all the trouble of creating the message!
Chris Mason
[1] I used to run "hands-on" classes and, because of the nature of the
student practical work I had to shut down to JES2 stopping and starting JES2
again for the new group. I fully automated the process - also starting up in
the first place and shutting down. I eliminated - suppressed - all the messages
that just happened as products started up and closed down.
Then my colleagues complained. "The system just sits there" they said "and
we can't tell what it's doing." So I introduced some special messages for each
of my fully automated actions such as starting CICS. These invented
messages were "retained" on the console until the action such as starting
CICS had completed. My colleagues were now happy!
On Sun, 30 Aug 2009 14:42:23 +0300, Abdullah AlShaalan
<a.sh...@HOTMAIL.COM> wrote:
>hi
>I try to supress ist663i using MPF but it does not work.
>I used netview to suppress it before.
>know, we cancel the netview license, so I need a way to suppress this
messge.
>thank you
Juergen Keller
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
Chris Mason
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
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
Behalf Of Chris Mason
Sent: Monday, August 31, 2009 8:21 AM
To: IBM-...@bama.ua.edu
Subject: Re: ist663i suppression
<SNIPPAGE>
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!
<SNIPPAGE>
So this is to an ESL (English as a Second Language) poster, and you
imply that you are using a walnut to crack a sledgehammer?
Regards,
Steve Thompson
-- Opinions expressed by this poster may not reflect those of poster's
employer --