×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 24 Dec 2012 18:27, Jack Kingsley wrote:
<<SNIP>>
Also, is there a way to monitor for the CPI1468 using a watch
session or something similar where you could essentially launch
a CLROUTQ QEZJOBLOB.
I would expect "Starting a watch session" to activate the so-called
"watch for event function" should suffice. There is an example in the
docs for the message CPF0907 which could probably be used as a model;
optionally adjusting the Watched message queue (WCHMSGQ) parameter
specification to refer instead to QSYS/QSYSMSG, if that message queue is
used:
IBM i 7.1 Information Center -> Troubleshooting -> Detecting problems ->
Watch for event function -> Scenario: Using the watch for event function
with an exit program
_i Starting a watch session i_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzahb/rzahb_startwatch.htm
"A watch session can be started by the Start Watch (STRWCH) command or
by the the Start Watch (QSCSWCH) API.
..."
More generically than the above example, giving more links, is:
_i Watching for messages i_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/wchmsg.htm
"The system provides a watch-for-event function that allows you to watch
for messages."
The noted message is documented as one which goes to the QSYSMSG
*MSGQ so a Break Handling program can monitor for message that is sent
when the event signaling that condition transpires:
IBM i 7.1 Information Center -> Programming -> Control language ->
Messages -> QSYSMSG message queue
_i Messages sent to QSYSMSG message queue i_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/msmqu.htm
"...
The system sends all other messages in this topic to both QSYSMSG and
QSYSOPR.
...
_CPI1468_
System work control block table nearing capacity.
The system sends this message when the number of entries in the
system job tables approaches the maximum number allowed. Permitting the
job tables to fill completely may prevent the successful submission of
jobs or the completion of the subsequent IPL.
..."
Also available should be the capability provided by Alerts. The
Alert feature can generate a "SNMP trap" [¿as defined by Network
Attributes?] or Send Data Queue entry which could be monitored. I have
never changed that specific message to test its capability in that
regard, but a message can be modified (CHGMSGD) to specify the Alert
Option (ALROPT); e.g. specifying the special value *IMMED to request "an
alert is sent immediately, simultaneous with sending the message to QHST
and/or QSYSOPR." Searching the non-delimited token "Alerts" in the
InfoCenter shows a bunch of topics, though I recall there was a separate
manual at one time [I may even have posted a link in the past].
midrange.com
