|
Hello James,
Aside from the the obvious fact that submitting a job and then tying up a
screen until it completes defeats the whole point of asynchronous batch
work and is therefore simply stupid -- but then it's a user request so why
am I not surprised.
I've seen various suggestions but here is my version:
o Interactive job creates a data queue
o Interactive job submits batch process
o Interactive job opens a display file that has the previously
mentioned data queue associated with it (CRTDSPF/CHGDSPF/OVRDSPF
DTAQ(lib/queue)
o Interactive job writes format using LOCK and FRCDTA (Work in
progress stuff)
o Interactive job waits on data queue
o Batch job sends status info to data queue
o Interactive job updates display then loops to wait on data queue
o Eventually batch job completes
o Interactive job updates final status and either returns to menu
or waits for user to press Enter or something
A variation would be to not lock the keyboard but let the user exit the
progress display at will and provide a menu option that displayed the
progress bar again.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software AS/400 Technical Specialists
http://www.flybynight.com.au/
Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\
Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.