RE: Design for data queue-driven subsystem

Zak,

I believe information about this may also be in the archives.

About seven years ago I wrote a system like you describe.  We used data
areas to control the minimum number of jobs receiving queue entries, and
IIRC a percentage threshold of entries on the queue to maximum the queue
would hold (That was before the autosizing queues so this may not be a good
idea today.), and the delay time to check how things were going.

The trickiest part was identifying the number of active jobs receiving queue
entries.  The work management API's will give you all you need for this.
There have also been several tools mentioned on this list that accomplish
the same thing.  The retrieve data queue attributes command will tell you
all you need to know about the status of the data queue.

Be sure to check for queue overflow in the program placing entries onto the
queue.  If the queue overflows you will receive a hard error and it's pretty
hard to recover without data loss.

Controlling parameters were checked at each program run so that any changes
made to system parameters were effective without stopping the entire
process.  We didn't code a job start delay into the process.  If the number
of queue entries had exceeded our threshold we submitted another job
immediately.

HTH,

Rick

-----Original Message-----
From: Metz, Zak [mailto:Zak_Metz@xxxxxx]
Sent: Wednesday, July 09, 2003 11:04 AM
To: Midrange Systems Technical Discussion
Subject: Design for data queue-driven subsystem

I am such a dork. A thousand apologies for this now duplicated message with
corrected title.

> -----Original Message-----
> From: Metz, Zak
> Sent: Wednesday, July 09, 2003 11:30 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: ODBC from IFS
>
>
> I would like to design a relatively generic model for a data
> queue-driven, dynamically scaling subsystem.
>
> It would seem obvious that the main part of this is the job that
> monitors the queue depth or response time and starts or ends
> additional
> jobs as needed. But, that's about all I have worked out.
>
> Has anyone developed a generic design for such a thing. I'm
> thinking it
> would be controlled by parms such as minimum/maximum number
> of jobs, min
> delay before additional job started, min depth before additional job
> started, how often to check...but if someone has already gone through
> this exercise perhaps they would consider sharing what a
> flexible set of
> controlling parameters consists of, and any other gotchas?
>
> And is there a shorter term for this sort of thing besides "data
> queue-driven, dynamically scaling subsystem?"
>
> Kind regards,
> Zak Metz
> .