× 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.



Tom-

I was running OVRMSGF within the job submission utility.  I also reduced the
code to the lowest common denominator -- a CL stream that overrides the
message file before submitting a job on hold and performing a RLSJOB.  I
would perform my tests interactively then display QSYSOPR to see if the
RLSJOB was still sending the message to the operators message queue.

It appears that OVRMSGF will stop messages from being logged to the
releasing job's job log, but it won't override the message sent by the
RLSJOB command to QSYSOPR.

Much thanks...

-Jim

-----Original Message-----
From: qsrvbas@netscape.net [mailto:qsrvbas@netscape.net]
Sent: Wednesday, November 27, 2002 9:22 PM
To: midrange-l@midrange.com
Subject: RE: RLSJOB message on QSYSOPR


Jim:

Just to be clear, I think Pete's suggestion was that the OVRMSGF should be
within the "job submission utility CL program". It sounded like you were
saying that you were executing OVRMSGF instead in the job that was
displaying QSYSOPR.

You'd get very different results in those two cases. (You can get a very
confusing image of QSYSOPR when a message file is overridden in the display
job! Surprise a co-worker some day... :-) )

Tom Liotta

midrange-l-request@midrange.com wrote:

>  11. RE: RLSJOB message on QSYSOPR (Jim Damato)
>
>I've given it a try, and I can see what you mean, Pete.  Unfortunately
>OVRMSGF is not working in this case.  Messages I put in my own message file
>do not show up in the job log, but CPC1163 is still being sent to QSYSOPR.
>
>If I specify SECURE(*YES) in the OVRMSGF command it makes DSPMSG QSYSOPR
>look really cool.
>
>Back to the drawing board.  Thanks for your help.
>
>-Jim
>
>-----Original Message-----
>
>At 17:42 11/25/2002, Jim Damato wrote:
>>We've just had to make a change to our software package so that all
>>submitted jobs are submitted on hold then released a few steps later in
the
>>job submission utility CL program.  (It's a long ugly story, and we're
>>trying to find a better way.)  As a result we're getting hundreds of
>>messages flooding the QSYSOPR message queue with CPC1163:
>>
>>Job 123456/WHOEVER/WHATEVER released by user WHOEVER.
>>
>>We have our operators filtering out severity 00 messages.  I was wondering
>>if there's a way to execute the RLSJOB command without triggering the
>>message to QSYSOPR.  Does anyone have any bright ideas?
>
>Use the ovrmsgf command to override qusrmsg to a message file of your
>choosing. In that message file, use addmsgd to create a message CPC1163,
>with no message text or second level text. The system will not insert an
>empty message into the joblog. If you're not familiar with ovrmsgf, it
>works a little like a library list. If the message ID isn't in there, it
>uses the original message file instead, so there's no (minuscule) chance of
>unintended consequences.

--
--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertechgroup.com



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.