|
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-2024 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.