Re: Interactive lock down while batch runs

["Booth Martin" <booth@xxxxxxxxxxxx>]

What is the goal of the project James?  To get the person back to work or to
cut down the interactive tax from IBM?

I ask this because we went through this exercise a couple of years ago, with
the idea of letting the user get back to work.  In the end we found the best
and easiest solution was to teach the users involved how to have two open
Client Access sessions, and to use the other session for jobs like you
describe.  The jobs run interactively still, and the user can see the
progress bar still, but they can (and do) run other jobs on the front
session.  It proved the most attractive solution in the end.

--------------------------------------------
Booth Martin
MartinB@Goddard.edu
802-454-8315 x235
--------------------------------------------
-------Original Message-------

From: midrange-l@midrange.com
Date: Friday, December 21, 2001 09:33:20 AM
To: midrange-l@midrange.com
Subject: Re: Interactive lock down while batch runs

You could have the option that submits the job create a data area that is
updated somehow by the submitted program. then have the interactive job
display an indicator from the data area.


Thanks,

Mark


Mark Walter
Sr. Programmer/Analyst
Hanover Wire Cloth a div of CCX, Inc.
mwalter@hanoverwire.com
http://www.hanoverwire.com
717.637.3795 Ext.3040



"James W. Kilgore"
<eMail@James-W-Kilg To: MIDRANGE-L@midrange.com
ore.com> cc:
Sent by: Subject: Interactive lock down while batch runs
midrange-l-admin@mi
drange.com


12/20/01 07:26 PM
Please respond to
midrange-l






Howdy,

We are attempting to shift some legacy interactive workload to batch and
have a
situation that I would like some feedback on.

For example, a Payroll process is usually a batch type work load. The menu
system gives the user a choice to:

(there's more but these are the batch type workload)

1) verify the payroll entries
2) run the calculations
3) print the checks
4) post the payroll

It would be real simple to take option #1 and make it a SBMJOB, if, and
it's a
big IF, I could get the people to not run #2 until #1 is done.

Now I know that I could lock an object and prevent #2 from being run while
#1 is
already running and have the user try again every five minutes or so. They
won't go for that. Why? Because they are used to having a progress bar
being
displayed showing them how many minutes are left in the process so they can
do
some other stuff while they wait. They don't have do try and die, they
just
watch and wait.

So here is what I would like to do:

1) have the job perform a SBMJOB to utilize the batch CPW
2) lock down the workstation, showing a process bar during the run

If the payroll run were only one program I could have the interactive
caller
contain a data queue to sync with the SBMJOB process, but the batch process
is a
series of programs, each having their own progress bar: compute gross
wages,
compute 401k, compute section 125 medical, compute federal taxes, compute
state
takes, compute disability, compute garnishments, etc.

I'm thinking that I would write an interactive "requester" that sits on a
data
queue to lock the workstation, does the SBMJOB and each step feeds back
it's
particular point in time back to the requester which displays the progress
bar.
Since the interactive session uses very little resources it should have
minimum
impact on the interactive CPW.

Any better suggestions?

TIA,
J. Kilgore
_______________________________________________