Hi,
I disagree with the assertion that increasing MAXMSG will not cause
XCF to consume more storage. Yes, XCF only uses what it needs. So in that
sense a MAXMSG value bigger than what is needed does not cause any
additional storage to be consumed. But if you are getting "no buffer"
conditions, the system is banging into the MAXMSG limit. Increasing the
MAXMSG limit in that case will likely lead to the use of more storage.
Exploiters hate being told "no buffer" and invariably tell customers
to increase the MAXMSG. Many customers oblige by increasing the send side
MAXMSG limits (either PATHOUT or Transport Class), and declare "success" if
the exploiter stops complaining. However, taking cold medicine to
alleviate your sniffles does not mean you still don't have a cold. Sure
you can keep increasing MAXMSG until the symptoms disappear. But there may
be an underlying problem that remains. If so, it will likely surface in
less obvious ways that can have more serious impacts than the "no buffer"
complainer.
So I encourage customers to look for the underlying root cause of the
issue. Assuming all the XCF/XES health checks are satisfied, I'll next
focus on the inbound side (receiving system). Are there signs of trouble
over there? A "no buffer" condition on the outbound side is often the
result of issues on the inbound side that impede the flow of message
traffic. Is the inbound system running enough, are there stalled XCF
members, long queues, dispatching delays, ENQ/latch contention, CF response
time issues, CTC device issues, etc. Has there been an increase in message
traffic? For example, if the increase in traffic arises from XES having to
deal with lock contention, you might be better off addressing the
contention so as to eliminate the increased message traffic. Are there
enough signalling paths to handle the load? Are the transport class
definitions appropriate? After looking at all that, I might consider
increasing the inbound MAXMSG value (assuming there was evidence of inbound
"no buffer" conditions). And finally I might then consider increasing the
outbound MAXMSG.
Mark A. Brooks
z/OS Sysplex design and development
845-435-5149 T/L 8-295-5149
Poughkeepsie, NY
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
