Jeff,

Thanks for your suggestion.

Clearing the message queue as they arrive would do the trick using a
message handling program.
I had originally hoped to fix the problem with a parameter value. 

It is designed this way in part because it also checks a flag in a
database to see if should continue to run
(infinite loop control structure). I have considered the data queue
technique, but personally have never used it. By far this would be the
more efficient thing to do: waiting for a message from the data queue,
then checking the database value to see if it should continue to run.

The data queue would have to be attached to an out queue. And I think
that a data queue cannot be added to an out queue if the queue is
already created. Is this true?

Thanks again for your help.

Regards,
Erick

Jeffrey M. Silberberg wrote:
> 
>    A copy of quick ideas. First, put a break message handling program on
> the submitting job, and simply remove the comp messages as they arrive.
> Second, why is this thing designed this way, it sounds like it would be
> much more efficent to have the submitted job wait on an event, dataq,
> msgq, or dlyjob rather than supporting the 8640 +/- jobs in the system
> created if this thing runs 24 * 7.
> 
>         JMS
> 
> On Fri, 5 Jun 1998, Erick wrote:
> 
> > I have a client who runs a CL program that submits a job to a user
> > defined subsystem. The job then runs every 10 seconds. Even though the
> > job is submitted qualified as MSGQ(*NONE) and job logging is set for
> > *NONE, a message complete is still being generated. Since this job runs
> > continuously, the message job queue fills up and ends the job. He also
> > has a specific class and job description for the SBMJOB. Is there an
> > presidence here that I don't understand?
> >
> > I had suggested ti the client that changing the system value QJOBMSGQFL
> > to *WRAP would alleviate the problem. He does not want to do this.
> >
> > Thank you in advance for any advice in this matter?
> >
> > Erick
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator: 
>david@midrange.com
> > +---
> >
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.