TIP: Click on subject to list as thread! ANSI
echo: cis.os9.68000.osk
to: Rainer Thieringer 100544,1230 (X)
from: Ian J Shearer 100410,2733
date: 1995-11-03 08:57:05
subject: #21255-OS9 3.0 crashes if ...

#: 21256 S12/OS9/68000 (OSK)
    03-Nov-95  08:57:05
Sb: #21255-OS9 3.0 crashes if ...
Fm: Ian J Shearer 100410,2733
To: Rainer Thieringer 100544,1230 (X)

Rainer,

 >> The PrivAlm seems to be something of a workaround for slightly flaky
alarms.
 >>Doesn't it only work to protect other UserID's (no use for tasks with a
common
 >>parent)? You can use semaphores to guard against accidental deletes, which
 >>avoids the M'ware bug.
 > In OS-9 Technical Manual pg. 2-29 the description to M$Compat says: "Only
the *process* that created an alarm can delete it". If you know more about that
flag, please let me know.

 You're right, that's what the manual says. I was basing my comments on
information from Microware Technical Support in the UK. To quote . . .

 "On Ver3.0 OS-9 this may be partially prevented by setting a field in the init
module, which causes a check such that when an alarm is deleted, it must be in
the same user/group."

 I queried the statement at the time, and was told (verbally) that sibling
processes sharing the same user/group ID could still accidentally delete each
others alarms. Since this didn't solve my problem, I used a workaround rather
than M$Compat.

 Not a complete answer, I know, but the best I can do for now. Hope it helps.


  -Ian J Shearer, Onyx Systems Ltd.

SOURCE: compuserve via textfiles.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.