Evan, You are correct, someone will be wanting to track the progress, real time. The idea behind using a data queue would be that the background process would feed the queue (regardless if there is an interactive monitor or not) and the monitor (whenever they decided to look) would be brought up to date. Got to love those data queues. When a user asks to calculate the payroll, their workstation would call a program that does a SBMJOB and waits on a queue for progress feedback. If the interactive job abends, so what. The queue still gets filled with progress. When the interactive session gets on line again it will be brought to current batch status (via reading the queue). Remember the issue at hand is locking the interactive session, during a batch process, while the batch process provides feedback for user display. Sort of like doing an FTP download with xx minutes remaining without consuming too many interactive CPW cycles. Should the batch job fail, that's a different issue and a different solution set. Evan Harris wrote: > > JameS > > I would think client/server, or client requester for the enquiry end of the > process. > > In case I have my terminology wrong, what I mean is that, I would have a > process that allowed you to inquire or feedback the progress of the payroll > job IF someone wanted to track it or see where it was up to, but (unless I > am misunderstanding) you are proposing making the display part of the process. > > What happens if the interactive portion of the program abends ? Will this > prevent anything continuing ?