Abdullah
> 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
<[email protected]> 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
----------------------------------------------------------------------
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
