I believe I have found the solution. As I said I looked the V6 system and
the message appeared in the job log and QSYSOPR message queue.
A light went off in my brain and I went and compared the backup control
groups. On the sequence number for *ALLUSR I changed Save while active to
*synclib and the message queue QSYSOPR on the V5R4 system. That line now
matches the V6 system
The backup will run tonight and I check in the morning to see what the
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, October 22, 2013 1:27 PM
Subject: Re: save while active message
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)
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
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.
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.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l