| -----Original Message-----
| From: midrange-l-bounces@xxxxxxxxxxxx
| [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of jt
| Sent: Friday, March 05, 2004 8:43 PM
| To: Midrange Systems Technical Discussion
| Subject: RE: Disabling Qinter... (Follow up question)
| (Except the first SBS to
| allocate a
| DEV should always get the lock, afaik...  Dunno how multiple cores handle
| task dispatching, of course.)

Wrote the above before I saw the below.  My recollection is vague, and Could
Very Well Be the Last SBS to allocate the DEV gets it.  Can't remember for
certain, and even if I had a system to test on I dunno if I would, in this
case.  (At any rate, mutually exclusive WrkStn name and type Entries are the
solution, as beens noted.)  My recollection, after reading this, is that
this is how you can switch a set of terminals from one subsys to another:
Start the second and when the user's signoff then it gets switched to the
other subsys.

Wonder if that would work for a QSPL that's gotten hung-up??

| -----Original Message-----
| From: midrange-l-bounces@xxxxxxxxxxxx
| [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Andy
| Nolen-Parkhouse
| Sent: Saturday, March 06, 2004 11:50 AM
| To: 'Midrange Systems Technical Discussion'
| Subject: RE: Disabling Qinter... (Follow up question)
| Tom,
| You make an excellent point regarding using the allocation attempt versus
| the subsystem start as the point of conflict.  My understanding has always
| been that the last allocation attempt takes precedence and determines the
| "winner" when multiple subsystems are trying to allocate a device.  My
| memory may be faulty and I don't have the ability to test right now, but
| that's what I remember.
| Regards,
| Andy Nolen-Parkhouse

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