RE: Interactive lock down while batch runs

Whether you're waiting on a data queue or updating a data area there's a
simple technique for staying on top of abnormal termination.  The batch
process should perform an ALCOBJ shared on the data queue or data area for
the duration of the batch job.

As it refreshes its display the monitoring interactive process attempts an
to allocate the data queue or data area exclusively.  If the interactive
process' ALCOBJ fails you can assume the batch job is running, and the
interactive process can move on to checking status.  If the interactive
process is able to allocate  the object it should deallocate it immediately
and report a failure status to the screen.

The only circumstance you can't reliably code for is if the batch job is
ended from the job queue.  Your last data queue entry or data area status
can be initialized to JOBQ, and can be updated to STARTED as the first step
in batch process, but I can't think of an easy way to differentiate between
a batch job waiting or held on a job queue and a job that ended before it
became active.

-Jim

James P. Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@dollargeneral.com>


-----Original Message-----
From: Simon Coulter [mailto:shc@flybynight.com.au]
Sent: Friday, December 21, 2001 11:25 PM
To: midrange-l@midrange.com
Subject: Re: Interactive lock down while batch runs



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