This is my understanding as well - what I'm trying to establish is a
mechanism of maintaining an MQT with some assurance that updates to it
will remain closely tied with updates to its source tables. I'm okay
with relying on triggers and stored procs, but have not (for example)
had success in coding a stored proc which calls a 'refresh table'
statement, even though it's mentioned in the z/OS SQL guide as a
supported statement for a stored proc.

I recognize that I cannot initiate a REFRESH TABLE from within a
trigger directly - I've read in the SQL dox about the dozen-or-so
valid statements for triggers.

I believe I should be able to code a stored proc to do it, but the
following proc does not compile:

CREATE PROCEDURE MYSCHEMA.MQTREFRESH ()
LANGUAGE SQL
BEGIN
REFRESH TABLE MQT1;
END

It returns an 'unexpected token "REFRESH TABLE"' message, expecting a
token of "SPACE"

If I schema-qualify the MQT name, returns an "unexpected token
MQT1...following MYSCHEMA." message.

Please don't misunderstand - I'm not looking for help coding a stored
proc (I recognize I'm not particularly experienced with them, either).
I'm simply trying to understand how, under z/OS, do DBAs who want the
IMMEDIATE REFRESH functionality of an MQT, get that kind of
functionality? If I want an MQT with some assurance that updates to it
will occur as closely as possible in time to the updates on the source
tables, what's the best strategy, in the absence of an IMMEDIATE
REFRESH MQT?

Do people build tables manually, and rely on manually-coded triggers,
somehow 'emulating' the immediate functionality?

Thanks kindly for the response...

BD