Re: Interactive lock down while batch runs

Nathan,

Close, but we may be confusing terms.

You say data area, I say data queue.  Two different animals.

I already have a generic, callable, progress bar window program.  Booth has a
rewrite that shows up on the message line area of the caller display (really
nice BTW).  Too bad it's not open source and can't use it.

I hate to admit it, but it looks like I'm going to have to write an old style
S/38 menu type program that does a lock and wait on a SBMJOB run.

This job can wait on a data queue for program name and progress and pass that on
to the progress display program.  Really trivial interactive work load.  Have to
change every batch type program though.  But then again, what solution doesn't
require a change to every program?  Luckily they all contain a /COPY to call the
progress display program directly and I only have to change that one /COPY to
perform a SNDDTAQ instead.  Gotta love that old /COPY.  Modular programming, old
enough to vote. Older than our home!

When the batch CPW will out perform the interactive on a 3:1 ratio, IMHO, it's a
bang for buck solution.

Just to digress a bit, but I've been going through the program list to try to
figure out how many are truly interactive and how many are truly batch.  I still
conclude that the interactive is the inverse 80/20 rule.  By that I mean that
80% of the work load is batch type processing and 20% is interactive, yet 80% of
what the user sees is the 20%.  The tip of the iceberg is the total of
perception.  Convincing some users is like trying to tell them that there is
more than the gas peddle that makes their car move forwards ;-)

J. (working below sea level) Kilgore

"Nathan M. Andelin" wrote:
>
> Do I understand the question?  The interactive job could alternate between
> displaying the progress bar and checking the data area for new status.  The
> batch job updates the data area (status).  The WAITRCD parameter on the
> CRTDSPF command specifies the maximum number of seconds to wait for the
> display file read operation before returning control to the interactive job.
>