Re: Interactive lock down while batch runs

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

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  / \
--------------------------------------------------------------------