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



>
>bvining@vnet.ibm.com wrote:
>
>> Having said the above, a definite gray area can exist in that if one
>> (and I do mean one) interactive task is active and the interactive task
>> has minimal interactive interaction, then the interactive threshold is
>> unlikely to be reached and so CFINT should not kick in.  The "gray area"
>> has to do with defining "minimal interactive interaction" and is a bit
>> too much to really get into.
>
>In other words, a definite maybe. (VVBG)  When you say 'interactive
>interaction' (for some reason, this reminds me of 'conjunction junction'
>from Sesame Street, but I digress), do you mean the user has to be
>striking keys on the keyboard?  Let's say I do a RCLSTG interactively.
>I won't touch the keyboard for hours.  Will it progress at 'interactive
>CPW' or 'batch CPW'?
>

By interactive interaction I meant performing actual device IO.  This
could be depressing AID keys (Enter, F1, etc.), the program refreshing
the display screen, the program posting status messages to the display,
and the like.  Basically what the Support Line Technical Document
(referenced elsewhere and which I wish I had known existed prior to my
responding) refers to as "doing 5250 display device I/O".

>
>> This area of one interactive task
>> executing is independent of the system being in restricted state (though
>> making sure just the one job is active is obviously alot easier to
>> control by going into restricted state), so having other selected
>> subsystems up concurrent to one save operation should be OK.
>
>Good to hear.
>
>> You could
>> be in restricted state and still see CFINT per the above (if the job
>> is heavily interactive, though then I wonder if a traditional application
>> could really drive the CPU if waiting for terminal input and performing
>> normal IO operations).
>
>Interesting.  Not being on a RISC system yet, I hadn't thought of it
>this way.  IOW, I thought that all the I/O, the updating of object save
>history, etc was all considered 'interactive' because it was running in
>an interactive job.  Are you saying this is not the case?  Wouldn't it
>be true that all the activity in a backup is considered 'interactive'
>even though the keyboard is not being touched for 40 minutes?
>

In the special case of only one "interactive" job running on the system,
the backup would not be considered as interactive (assuming that the
backup is not performing 5250 display device I/O as described above).

>
>Thanks.
>
>-Jeff
>


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.