Personally, I prefer to include a "progress graph" (of sorts) in batch
jobs just as much as I do in the interactive ones.
For example, I have a program (that I wrote) that downloads a PTF order
from IBM's FTP server. It often takes 12-16 hours to download a CUM...
I like that I can check to see how it's progressing... but I sure
don't want to tie up a terminal for that long.
I accomplish mine by sending both a *STATUS and a *DIAG message
containing a percentage. I save the MSGKEY of the *DIAG message, and
update the percentage each time the status changes.
In an interactive job, I can always see the current status at the bottom
of the screen. In a batch job, I can view the job log, and the last
message will be the progress.
On 8/29/2011 8:45 PM, Mike Cunningham wrote:
Design question. Why are you running this interactive at all? Why tie
up the users terminal for a long running job that can easily be run
in batch and let the user go back to work.
This mailing list archive is Copyright 1997-2026 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.
midrange.com
