× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



>We have a number of 'async' jobs (never-ending batch jobs) that
>process batch transactions.  Some monitor message queues, some
>monitor database files.
>
>There's a parameter on the RCVMSG command that tells a program to
>'wait forever' until a message appears.  A similar construction on a
>database file tells OS/400 that when you read and hit the
>end-of-file condition, you're willing to wait forever for the next
>record.
>
>I'm at home now and don't have the details in front of me.  ):
>
>These techniques have the advantage of not making your program loop
>or delay forever; the OS notifies your program when there's
>something for it to do.
>
>I don't think this will have quite the effect you're looking for,
>however.  I appreciate that you're trying to offload batch
>operations from the interactive subsystem, but your users are still
>going to be sitting in front of an effectively dead screen until the
>batch process completes.  May I suggest that you modify your process
>so that your user's screen is not locked while the batch job
>processes? If you're performing a task on an order, for example,
>perhaps an 'order in use' flag, or 'waiting for batch processing to
>complete' flag can be used.  Your interactive users will then check
>the flag, and be notified if the batch process for that order has
>completed. Your application will honor the flag and not allow
>further operations until the batch job clears the flag.
>
>You'd also need a manual unlock function to clear the flag in case
>the batch job abends (which I'm sure it never will.   (:    ).
>
>--Paul E Musselman
>PaulMmn@ix.netcom.nospam.com
>
>
>
>
>
>>Could use a data area, and have the interactive job, check the data area
>>every X number of seconds.
>>cjg
>>
>>
>>Carl J. Galgano
>>EDI Consulting Services, Inc.
>>550 Kennesaw Avenue, Suite 800
>>Marietta, GA  30060
>>(770) 422-2995 - voice
>>(419) 730-8212 - fax
>>mailto:cgalgano@ediconsulting.com
>>http://www.ediconsulting.com
>>AS400 EDI, Networking, E-Commerce and Communications Consulting and
>>Implementation
>>http://www.icecreamovernight.com
>>Premium Ice Cream Brands shipped Overnight
>>FREE AS/400 Timesharing Service -
>>http://www.ediconsulting.com/timeshare.html
>>"You ain't gonna learn what you don't want to know" - rw
>>
>>-----Original Message-----
>>From: midrange-l-admin@midrange.com
>>[mailto:midrange-l-admin@midrange.com]On Behalf Of Gwecnal@aol.com
>>Sent: Thursday, October 25, 2001 5:13 PM
>>To: midrange-l@midrange.com
>>Subject: Batch/interactive interaction
>>
>>
>>Is there a way to have an interactive program submit
>>something to batch and then wait for the batch job
>>to finish before continuing?  I was thinking of having
>>the batch job send a message, but can't get it to work.
>>
>>TIA, Lance
>>_______________________________________________
>>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>>To post a message email: MIDRANGE-L@midrange.com
>>To subscribe, unsubscribe, or change list options,
>>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>>or email: MIDRANGE-L-request@midrange.com
>>Before posting, please take a moment to review the archives
>>at http://archive.midrange.com/midrange-l.
>>
>>_______________________________________________
>>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>>To post a message email: MIDRANGE-L@midrange.com
>>To subscribe, unsubscribe, or change list options,
>>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>>or email: MIDRANGE-L-request@midrange.com
>>Before posting, please take a moment to review the archives
>>at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.