following up a message from Jack Stein to Harry Wesebaum:
 JS>  Session_Priority, as I understand it,  sets all sessions to 1 by
 JS> default. Setting a session to 2 will make it the LAST session
 JS> serviced, when time permits.  Doesn't matter at all if you set it to 2
 JS> or 32, it's still last. In other words, I don't think session_priority
 JS> does what you think.  My feeling is it should be left alone unless
 JS> really needed for something.  I guess, for example, you might set
 JS> every session to 2 except your BBS, which you set to 1, making sure
 JS> that always gets first dibs, but I never had to here. Also if you have
 JS> a process that you absolutly don't care about speed, you could give it
 JS> a 2 priority and insure everything else gets serviced first.
 JS> Generally, OS/2 does fine without touching this setting, left to it's
 JS> own devices.  Again, this is how *I* understand it...
 HW> *My* understanding of Session_Priority is the exact
 HW> opposite. The higher number gets priority first and the
 HW> lower numbers are last on the service list. 
 HW> Which of us is right?
 JS> I guess it should be easy enough to test, but I'm not in the
 JS> mood at the moment, and if I'm wrong it'll drive me crazy
 JS> trying to come up with where I got the info:-)
I just tested this with a little .bat file loop, and you (and the .docs are 
right, the higher number gets the priority.  It seemed to make no difference 
if the priority was 2 or 32, but the higher number gets absolute first dibs.
I wonder why when I set my BBS to a higher priority, I had problems?  I guess 
it could be related to other settings I have in there for the comm session, 
or perhaps my my memory is faulty on what exactly I did, or who knows.  Maybe 
I'll play with it again and see, but really OPUS works  exactly as I want it 
to now, OS/2 does a good job of handling multiple sessions with OPUS running 
without any forced motions.  
When I tested this with the bat file, the lower priority bat file basically 
stopped dead while the higher priority did its work, not something I normally 
would want. 
My test was a simple do loop:
timer
do 1000
  echo this is a test of session priorities
enddo
timer
I sure didn't need the timer:-)     I did it with one session set to 32, and 
then one session to 2, and both times the session_priority = 1 session about 
stopped.  With both sessions set to 1, they both ran fast, faster than 
running the script 2 times in a single session.  On my system, a 486/33, with 
this specific task, the Session_Priority = 2 was similar to setting all other 
DOS tasks to NOT run in the background, at least while the session was doing 
work.
                                         Jack 
--- timEd/2-B11
---------------