Is threading the right solution for this challenge?

Compiler: MF SE 4.2 SP2
Platform: HP-UX 11i

Challenge: Have a continually refreshing display screen that also
responds to user input.


I had been considering using ACCEPT with a TIMEOUT clause and
refreshing after each time out, but that does not seem to be the
optimal solution here. In theory, this would give me a sluggish
application. Either the user would be waiting on the compilation of
display data, or the display would become "stale" while processing user
input.

I'm thinking that this is a prime candidate for me to tackle my first
threaded application. I figure I can run the user input interface in
one thread, whil running the continually updating output display in
another thread.

Since I have ZERO experience in this arena, I wanted to throw it out
there for the masses and see what everyone thought.

In the meantime I'll be wading through the MF documentation on writing
threaded applications and try to discern what I can. What is the
typical method when designing a threaded application? Do I start by
creating the two individual applications and then work toward linking
them together, or are there other considerations?


Of course - if anyone has any samples that they'd like to share, I
would love to have a look. It's always nice to see what others are
doing to accomplish similar tasks.


Thanks in advance for any/all feedback.

Chris

"Chris" <ctaliercio@yahoo.com> wrote in message
news:1146500082.954862.255300@i39g2000cwa.googlegroups.com...
> Compiler: MF SE 4.2 SP2
> Platform: HP-UX 11i
>
> Challenge: Have a continually refreshing display screen that also
> responds to user input.
>
>
> I had been considering using ACCEPT with a TIMEOUT clause and
> refreshing after each time out, but that does not seem to be the
> optimal solution here. In theory, this would give me a sluggish
> application. Either the user would be waiting on the compilation of
> display data, or the display would become "stale" while processing user
> input.
>
> I'm thinking that this is a prime candidate for me to tackle my first
> threaded application. I figure I can run the user input interface in
> one thread, whil running the continually updating output display in
> another thread.

I don't have much COBOL experience, but the functionality you're
referring to is commonly seen in games (e.g. update the screen, check if the
user entered any input, and if so process it; either way, update the screen
again and repeat). Usually in game development, you want to avoid threads
where ever possible (an exception might be heavy duty 3D graphics
processing, which I don't think applies to your case), as they tend to just
add complexity without bringing too much benefit.

In ACCEPT with TIMEOUT, what happens if the user was in the process of
entering data, and then the timeout occurs? Do you get the data that the
user half-submitted, or do you get nothing? If it's the former, you could
probably use ACCEPT with TIMEOUT, with a very low timeout (e.g. 1/100th of a
second?), and just capture 1 character a time, constructing the full string
of the user's input manually. If it's the latter, you might want to look
into hooking into a library or API written in another language to provide
you with the facility to capture characters one a time. See for example the
"getch() function with no-delay" at
http://www.mkssoftware.com/docs/man3/curs_getch.3.asp

>
> Since I have ZERO experience in this arena, I wanted to throw it out
> there for the masses and see what everyone thought.
>
> In the meantime I'll be wading through the MF documentation on writing
> threaded applications and try to discern what I can. What is the
> typical method when designing a threaded application? Do I start by
> creating the two individual applications and then work toward linking
> them together, or are there other considerations?

There are many considerations when writing multithreaded code, and it's
one of those things that's hard to get right. Code like:

MOVE 3 TO A
DISPLAY A

might not yield the output 3, if another thread has stepped in an
modified the contents of A in between those two lines. There are techniques
and data structures specifically designed for use in multithreaded
programming (e.g. mutex, condition variable, locks, etc.), and entire books
on writing multithreaded applications within a given programming language.

You might want to start at
[url]http://users.actcom.co.il/~choo/lupg/tutorials/multi-thread/multi-thread.html[/url
]
and work from there.

- Oliver

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


Oliver Wong wrote:
> "Chris" <ctaliercio@yahoo.com> wrote in message
> news:1146500082.954862.255300@i39g2000cwa.googlegroups.com... 
>
>     I don't have much COBOL experience, but the functionality you're
> referring to is commonly seen in games (e.g. update the screen, check if t
he
> user entered any input, and if so process it; either way, update the scree
n
> again and repeat). Usually in game development, you want to avoid threads
> where ever possible (an exception might be heavy duty 3D graphics
> processing, which I don't think applies to your case), as they tend to jus
t
> add complexity without bringing too much benefit.
>
>     In ACCEPT with TIMEOUT, what happens if the user was in the process of
> entering data, and then the timeout occurs? Do you get the data that the
> user half-submitted, or do you get nothing? If it's the former, you could
> probably use ACCEPT with TIMEOUT, with a very low timeout (e.g. 1/100th of
 a
> second?), and just capture 1 character a time, constructing the full strin
g
> of the user's input manually. If it's the latter, you might want to look
> into hooking into a library or API written in another language to provide
> you with the facility to capture characters one a time. See for example th
e
> "getch() function with no-delay" at
> http://www.mkssoftware.com/docs/man3/curs_getch.3.asp
> 
>
>     There are many considerations when writing multithreaded code, and it'
s
> one of those things that's hard to get right. Code like:
>
> MOVE 3 TO A
> DISPLAY A
>
>     might not yield the output 3, if another thread has stepped in an
> modified the contents of A in between those two lines. There are technique
s
> and data structures specifically designed for use in multithreaded
> programming (e.g. mutex, condition variable, locks, etc.), and entire book
s
> on writing multithreaded applications within a given programming language.
>
> You might want to start at
> [url]http://users.actcom.co.il/~choo/lupg/tutorials/multi-thread/multi-thread.html[/u
rl]
> and work from there.
>
>     - Oliver

"Chris" <ctaliercio@yahoo.com> wrote in message
news:1146769621.763307.155120@u72g2000cwu.googlegroups.com...
> 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.

I'm assuming that the displaying thread will just do its query and
display the results, without ever affecting the user input thread. Is there
anything that the user input thread could do that would directly affect the
displaying thread? For example if the user input thread changes some records
in the Oracle DB, presumably the DB will take care of its own concurrency
locking issues, and the input thread won't directly, for example, edit the
variables within the displaying thread. Rather they will communicate to each
other only with the Oracle DB acting as a middle man.

If so, you might be able to avoid all the pitfalls that are typically
present in multithreaded programming. If you're working on a line oriented
system though, have you tried writing a simple mock up program to ensure
that it's possible to have two threads, one performing a DISPLAY and one
performing an ACCEPT on the same terminal at the same time?

- Oliver

You are correct in all assumptions.

The input thread will never directly affect the display thread. Any
perceived "interaction" between the threads will only be the outward
appearance of what is happening.

For (a really simple) example: if the display thread is showing the
number of records in a table, and the user adds a record in the input
thread, the display will be updated because it is actually counting the
number of records in the table - not because of any true inter-thread
communications.


Right now I have two threads updating the screen concurrently. I have
not verified that one thread can do the accept whil the other is doing
the display, but I will work on that and let you know.


Thanks,
Chris



Oliver Wong wrote:
> "Chris" <ctaliercio@yahoo.com> wrote in message
> news:1146769621.763307.155120@u72g2000cwu.googlegroups.com... 
>
>     I'm assuming that the displaying thread will just do its query and
> display the results, without ever affecting the user input thread. Is ther
e
> anything that the user input thread could do that would directly affect th
e
> displaying thread? For example if the user input thread changes some recor
ds
> in the Oracle DB, presumably the DB will take care of its own concurrency
> locking issues, and the input thread won't directly, for example, edit the
> variables within the displaying thread. Rather they will communicate to ea
ch
> other only with the Oracle DB acting as a middle man.
>
>     If so, you might be able to avoid all the pitfalls that are typically
> present in multithreaded programming. If you're working on a line oriented
> system though, have you tried writing a simple mock up program to ensure
> that it's possible to have two threads, one performing a DISPLAY and one
> performing an ACCEPT on the same terminal at the same time?
>
>     - Oliver

Oliver Wong wrote:

Oliver, not sure he is asking the question that you supplied an answer
to :-).

I had a helluva job finding TIMEOUT - looked at the overall index for
the N/E 4.0 on-line manuals and found following :-

http://supportline.microfocus.com/s...ndx.ht
m

So very often people ask a question here framed in a way that they
understand, 'cos they know what they want to do - so they get answers
based on what the reader interprets.

So The originator asks, "I've got a cart with a donkey which has a HUGE
rock in the back. How do I get the donkey to move ?".

They get answers like "Entice the donkey with a carrot", or perhaps,
"Prod a stick up its arse !".

But it turns out the originator has a solution for getting the donkey to
move forwards. What he is really asking is "How can I get the donkey to
go into reverse until I reach a cliff top so that I can tip the rock
into the sea below !". (Naturally, he gets the donkey from out between
the shafts before tipping the cart).

Net Express GUI classes allow "wantAllKeys" for a dialog; then on an
event you go to a callback to check keystrokes. But Chris is in Unix -
purely a (text) Character Mode display. (Might be a bit tricky for him
to try mixing DOS/Unix-type Screen Section with OO events, in any language).

He has two choices coding programatically :-

ACCEPT Customer-Screen (all the screen fields making up the displayed
record, automatically moving between the fields based on terminating
with the <ENTER> key); OR

ACCEPT Customer-Account-Number (one specific field).

Now within the Screen Section/Panels that he is using there are various
ways of terminating fields, and recognizing keystrokes or Function Keys
- much too much to absorb in a quick read - I'm assuming Chris has
checked out the On-line manuals on Character Handling.

My question to Chris - care to elaborate on why you need to keep
refreshing the screen. (No doubt you have a good reason - but I'd like
to know what it is). Using GUIs I only refresh screen when there is a
CHANGE to say a Listbox or Treeview. One exception with Treeview - no
changes and user clicks on the {-} or {+} appearing before Treeview
Labels - based on the event you expand/contract the Treeview and then
re-display.

I'm trying to establish if you want the donkey to go forwards or into
reverse :-).

Jimmy

>
> "Chris" <ctaliercio@yahoo.com> wrote in message
> news:1146500082.954862.255300@i39g2000cwa.googlegroups.com...
> 
>
>
>    I don't have much COBOL experience, but the functionality you're
> referring to is commonly seen in games (e.g. update the screen, check if
> the user entered any input, and if so process it; either way, update the
> screen again and repeat). Usually in game development, you want to avoid
> threads where ever possible (an exception might be heavy duty 3D
> graphics processing, which I don't think applies to your case), as they
> tend to just add complexity without bringing too much benefit.
>
>    In ACCEPT with TIMEOUT, what happens if the user was in the process
> of entering data, and then the timeout occurs? Do you get the data that
> the user half-submitted, or do you get nothing? If it's the former, you
> could probably use ACCEPT with TIMEOUT, with a very low timeout (e.g.
> 1/100th of a second?), and just capture 1 character a time, constructing
> the full string of the user's input manually. If it's the latter, you
> might want to look into hooking into a library or API written in another
> language to provide you with the facility to capture characters one a
> time. See for example the "getch() function with no-delay" at
> http://www.mkssoftware.com/docs/man3/curs_getch.3.asp
> 
>
>
>    There are many considerations when writing multithreaded code, and
> it's one of those things that's hard to get right. Code like:
>
> MOVE 3 TO A
> DISPLAY A
>
>    might not yield the output 3, if another thread has stepped in an
> modified the contents of A in between those two lines. There are
> techniques and data structures specifically designed for use in
> multithreaded programming (e.g. mutex, condition variable, locks, etc.),
> and entire books on writing multithreaded applications within a given
> programming language.
>
> You might want to start at
> [url]http://users.actcom.co.il/~choo/lupg/tutorials/multi-thread/multi-thread.html[/u
rl]
> and work from there.
>
>    - Oliver

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

Oliver Wong wrote:

>
> "Chris" <ctaliercio@yahoo.com> wrote in message
> news:1146500082.954862.255300@i39g2000cwa.googlegroups.com...
> 
>
>    I don't have much COBOL experience, but the functionality you're
> referring to is commonly seen in games (e.g. update the screen, check if
> the user entered any input, and if so process it; either way, update the
> screen again and repeat). Usually in game development, you want to avoid
> threads where ever possible (an exception might be heavy duty 3D
> graphics processing, which I don't think applies to your case), as they
> tend to just add complexity without bringing too much benefit.
>
>    In ACCEPT with TIMEOUT, what happens if the user was in the process
> of entering data, and then the timeout occurs? Do you get the data that
> the user half-submitted, or do you get nothing? If it's the former, you
> could probably use ACCEPT with TIMEOUT, with a very low timeout (e.g.
> 1/100th of a second?), and just capture 1 character a time, constructing
> the full string of the user's input manually. If it's the latter, you
> might want to look into hooking into a library or API written in another
> language to provide you with the facility to capture characters one a
> time. See for example the "getch() function with no-delay" at
> http://www.mkssoftware.com/docs/man3/curs_getch.3.asp

I support a CICS green screen application that does this, but the
solution was not in COBOL.  It relied on CICS services.

In a CICS pseudo-conversational program with a BMS Map, the program
issues a CICS command to display the screen and then returns to CICS
(usually with a COMMAREA containing user data).  Then the CICS program
goes away.  The user can enter new data, but it is only when an
attention interrupt key is pressed (such as ENTER, or CLEAR, or a PF
Key) that the CICS program is started up again.  If a COMMAREA
containing data is present, the CICS program can use that data to
recover its state before continuing.

So the way we solved this problem is that we issued a CICS START
command to invoke the current program 300 seconds in the future, then
issued the command to display the screen, and then EXEC CICS RETURN
with COMMAREA.

If the user pressed an attention interrupt key, the program started
again, cancelled it's time-initiated task, and continued processing.

But if the user did nothing for 300 seconds, the program would be
re-invoked as a time-initiated task, and would display an updated
screen, after first starting itself 300 seconds in the future.


--
http://arnold.trembley.home.att.net/


> What I was envisioning was the main program spawning two threads - one
> that continually updates the display,

That is one way of chewing up all CPU time so that all programs and the
whole OS becomes unresponsive - min CPU requirement goes to 4GHz.

> There are several tables in an Oracle
> database that need to be interrogated, several OS processes that need
> to be examined, etc.

Put a trigger on each table so that these set a 'new data available'
data item.  Or even have a trigger maintain a summary table.

Hi Jimmy.

Sorry - maybe if I had laid out more clearly what I was trying to do it
would have been easier to understand the "requirements."

Let me clarify here:

What I am trying to do is construct a monitoring utility for my
application in much the same vein as a UNIX utility like top or glance.

My overall application is running several (upwards of 50 right now)
processes in the background that should, under ideal conditions, be
constantly processing data. The only drawback is that it's hard
sometimes for the end-users to tell if a background process is doing
its job. This new utility will provide a way for an end-user to inspect
the processes to ensure that each one is performing and running as
expected.

The "display" thread that I mentioned will inspect the system to see
which background processes are running and which aren't (the list of
all processes are stored in a database table). When it identifies a
running process, it will call the OS to get information about the
process (memory usage, CPU consumption, etc). It will also make a
customized call to a data monitor program, which will report the number
of outstanding records to be handled by that process.

The "accept" thread will handle user requests, such as; start process,
stop process, heartbeat, up/down, page up/down, exit, etc.


Addressing Richard's concern:

The CPU will not cycle out of control on the display thread, as I will
obviously need to have some sort of sleep/delay mechanism in there.
More likely than not this will be a user defined parameter (much the
same as glance takes a parameter for it's sleep interval).

I also thought of the summary table concept last night while trying to
figure out the true "best approach" for this challenge. I could easily
use the DBMS_ALERT package that Oracle provides to make updates to this
summary table. Then, using that table (containing all of the items on
the screen), a refresh after an ACCEPT ... WITH TIMEOUT would be fairly
fast and I could avoid threads. The problem there is that I am relying
on one of the background jobs to be running itself, and I was hoping to
avoid that.

I have had some problems with the display in one thread and an accept
in the other, so I'll need to iron that wrinkle out. But otherwise,
I've found that working with the thread logic is not that bad.


Also - from the technical standpoint - I do not have the luxury of
Dialog System or anything of that sort. This is strictly a character
based UI - the only available commands are display and accept.

Again - thanks to everyone for the input - always good to get feedback
from folks with a similar background.


Chris




James J. Gavan wrote:
> Oliver Wong wrote:
>
> Oliver, not sure he is asking the question that you supplied an answer
> to :-).
>
> I had a helluva job finding TIMEOUT - looked at the overall index for
> the N/E 4.0 on-line manuals and found following :-
>
> http://supportline.microfocus.com/s...ndx.
htm
>
> So very often people ask a question here framed in a way that they
> understand, 'cos they know what they want to do - so they get answers
> based on what the reader interprets.
>
> So The originator asks, "I've got a cart with a donkey which has a HUGE
> rock in the back. How do I get the donkey to move ?".
>
> They get answers like "Entice the donkey with a carrot", or perhaps,
> "Prod a stick up its arse !".
>
> But it turns out the originator has a solution for getting the donkey to
> move forwards. What he is really asking is "How can I get the donkey to
> go into reverse until I reach a cliff top so that I can tip the rock
> into the sea below !". (Naturally, he gets the donkey from out between
> the shafts before tipping the cart).
>
> Net Express GUI classes allow "wantAllKeys" for a dialog; then on an
> event you go to a callback to check keystrokes. But Chris is in Unix -
> purely a (text) Character Mode display. (Might be a bit tricky for him
> to try mixing DOS/Unix-type Screen Section with OO events, in any language
).
>
> He has two choices coding programatically :-
>
> ACCEPT Customer-Screen (all the screen fields making up the displayed
> record, automatically moving between the fields based on terminating
> with the <ENTER> key); OR
>
> ACCEPT Customer-Account-Number (one specific field).
>
> Now within the Screen Section/Panels that he is using there are various
> ways of terminating fields, and recognizing keystrokes or Function Keys
> - much too much to absorb in a quick read - I'm assuming Chris has
> checked out the On-line manuals on Character Handling.
>
> My question to Chris - care to elaborate on why you need to keep
> refreshing the screen. (No doubt you have a good reason - but I'd like
> to know what it is). Using GUIs I only refresh screen when there is a
> CHANGE to say a Listbox or Treeview. One exception with Treeview - no
> changes and user clicks on the {-} or {+} appearing before Treeview
> Labels - based on the event you expand/contract the Treeview and then
> re-display.
>
> I'm trying to establish if you want the donkey to go forwards or into
> reverse :-).
>
> Jimmy
>