× 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 10/22/13 10:36 AM, ldwopt@xxxxxxx wrote:
I am still working on figuring out the MONSWABRM command but thought
I would attack the problem from a different angle.

The system is a V5R4 system. When the save of the USER libraries are
done with the SAVCHGOBJ command these messages appear:
Save-while-active checkpoint processing in progress.
Save-while-active checkpoint processing complete.

The first message apparently is msg CPI3725, and the second message presumably is msg CPI3712 as noted in the prior thread.

Where do they appear? In the joblog and/or the specified message queue [i.e. the Save active message queue (SAVACTMSGQ)], the *SYSOPR and\or QHST [aka History log: DSPLOG], the workstation message queue? In the status message line at the interactive workstation?

What is specified for the SavAct Message Queue on the request? Is that message queue possibly being monitored by a process that removes the messages; i.e. such that the messages are properly not visible? Or is that message queue placed in *BREAK mode with SEV(0) to ensure any new messages break to a screen... at a display where the user knows not to delete them.? And for a workstation message queue, if the expectation of effects between systems is to be the same, ensure the job's Break message handling (BRKMSG) and the *WRKSTN message queue's Delivery (DLVRY) and Severity code filter (SEV) settings are identical.

When I changed the command to:
STRBKUBRM CTLGRP(NEWSWA) SBMJOB(*NO) RETENTION(*DAYS 14)
MONMSG MSGID(BRM10A1)
MONMSG MSGID(CPA0701)

The message CPA0701 is issued as an *inquiry* message that occurs when an error is unmonitored and thus not [coded to be] handled by a CLP; i.e. the run-time /default handler/ for the CLP gets invoked, whose effect is to issue that inquiry. Thus that MONMSG is futile, because an inquiry message is not a /monitorable/ condition via the Monitor Message command-statement; and is confusing to a reader. To prevent the default handler from taking control, use either MONMSG MSGID(CPF9999) or MONMSG(CPF0000) in place of the spurious monitor for an inquiry.

The message does not appear.

Two messages were shown. Does that imply neither message appears?

I have looked at a V6 system using the same command and the message
is displayed.

Again... Where? Apparently the expectation is that wherever the /message/ [or is it messages?] appear on v6r1 system, they should similarly appear on the v5r4 system.... but please do divulge where they are being seen\found; i.e. the [same] place where they are to be found wherever they are not being found.

Any ideas?

If the concern is merely for their appearance in the status message line, then probably a user profile preference or the job is [changed or] setup to *not present* status messages. Thus the recovery action of [either, if there is one... I do not recall, CHGPRF STSMSG(*NORMAL) or] CHGJOB STSMSG(*NORMAL) would suffice; i.e. the messages should start appearing, if the status messaging is turned on for the job.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.