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