Re: Is threading the right solution for this challenge?
- From: "James J. Gavan" <jgavandeletethis@xxxxxxx>
- Date: Thu, 04 May 2006 21:19:05 GMT
Chris wrote:
Thanks Oliver - I appreciate the feedback.
The problem I am facing is that it is a complex routing that is called
in order to refresh the screen. There are several tables in an Oracle
database that need to be interrogated, several OS processes that need
to be examined, etc. A typical screen "refresh" could take up to 10-15
seconds.
I didn't want the user to have to wait 10-15 seconds between their
input and the application's reaction to it. That is why I was leaning
toward threads. I understand that there can be some overlapping of
memory resources, and some unexpected results if you are not careful in
your coding, but I believe MF gives me a way out of that mess with the
THREAD-LOCAL-STORAGE section.
What I was envisioning was the main program spawning two threads - one
that continually updates the display, and the other that simply
accepts/reacts to user input. If the user chose to exit, I could kill
the display thread (since it is only inquiring there is no danger
there) and have the application exit immediately.
To get the same type behavior in a single program, I'd need to have the
loop that is collecting information to update the display continuously
interrupt itself to check for user input and react to it. That didn't
seem like the most efficient way for me to accomplish what I am looking
to do.
Does anyone else have any opinions on this?
Thanks,
Chris
OK - should have waited for your reply to Oliver. What are you doing - entering Customer info, Purchase Orders or what ? Is the action on the Database independent or are different Tables being updated as a result of user input to the Screen Section, which causes you to refresh.
Two possibilities :
1) using a Flag :-
01 InputFlag pic 9 value 0.
88 InputAvailable value 1.
88 NoInput value 0.
If in fact your DB Tables are being updated as a result of user input - having re-displayed the appropriate Table info check the above Flag, i.e. :-
ACCEPT input and SET InputAvailable to TRUE.
2) Back when I was using Screen-Section I used 'dummy' pushbuttons at the bottom of the screen - <OK>, <Cancel>, <Delete> etc. So user would click using Mouse, (Don't think you can with Unix - or that's what the manuals seem to imply for Unix ????), on the <OK> Button which meant the input got added and written to DB Tables.
Jimmy
.
- References:
- Is threading the right solution for this challenge?
- From: Chris
- Re: Is threading the right solution for this challenge?
- From: Oliver Wong
- Re: Is threading the right solution for this challenge?
- From: Chris
- Is threading the right solution for this challenge?
- Prev by Date: 3-6 month contract in AL for a Senior Mainframe P/A with Cobol/CICS/DB2/VSAM
- Next by Date: Re: Call AcuCobol Program in Unix from Windows and obtain the output
- Previous by thread: Re: Is threading the right solution for this challenge?
- Next by thread: Re: Is threading the right solution for this challenge?
- Index(es):