RE: Best options for polling a file

What you are saying about data queues doesn't make any sense. Data queues take almost zero amount of system resources. Having a job sitting around hitting a file every few factions of seconds would take tons of resources. Others have suggested submit jobs, the most expensive thing in the system or using EOFDLY which again takes all kinds of resources. Data queues are just about as perfect as anything can be on the AS/400. Remember the only thing you have to send through is the key. Triggers and data queues would have an almost zero overhead. I have used triggers and data queues through my trigger mediator and have seen virtually zero overhead. The only scenario that I could think of where data queues would not be appropriate is where you are adding thousands and thousands of records and only want to do something very small. The question would be then why you would not just call a procedure in a service program to do the job. If the processing is disconnected, then data queues cannot be beaten. I encapsulate data queues in a service program so I can just call a procedure and let the service program do the work of setting up and writing to the data queue and reading back. Makes no sense to put a data queue into a program. 

If you don't think data queues are fast enough, there are user queues and faster than anything, a TCP socket call. 

-----Original Message-----
From: pascal.jacquemain@xxxxxxxxxxxxxx
[mailto:pascal.jacquemain@xxxxxxxxxxxxxx]
Sent: Monday, May 23, 2005 9:57 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Best options for polling a file


Hello,

Imagine a file where records are created by jobs and are processed by other
jobs. The processing jobs do not access all records but only those with the
right key field. There are several solutions to get data from the file and
to "wake up" the processing job.

- Use of data queue or message queue to tell the processing job to "wake
up". While not a bad idea, it means programs that create records in the file
must also call a program to generate the data queue message or the message.
This may be done via a trigger but this adds processing time every time a
record is created.

- Use a delay wait method (in this case, waiting 0.1 second each time) and
check with SETLL or CHAIN that at least 1 record is awaiting processing.
This is a "lighter" option than the above on the jobs that create data but
can lead to unnecessary use of CPU or I/O (although while running on our
system, the CPU and I/O of jobs that have nothing to process are very low if
not negligible).

Can you make comments or are there other more desirable methods? (We do not
want to use either data queues or MQ queues or message queues to store the
temporary data).

Thanks

Pascal

The opinions expressed within this email represent those of the
individual and not necessarily those of Gullivers Travel Associates (GTA).

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify postmaster@xxxxxxxxxxxxxx

Should you wish to use email as a form of communication, GTA are unable to
guarantee the security of email content outside of our own computer systems.


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________