NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/os/vms/21677

Internet Message Format | 1993-01-22 | 3.0 KB

Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!ucbvax!ELROS.STG.TRW.COM!powers
From: [e-mail]
Newsgroups: comp.os.vms
Subject: RE: "Beat the Buzzer" Game
Message-ID: <[e-mail]>
Date: 21 Jan 93 07:50:43 GMT
Sender: [e-mail]
Distribution: world
Organization: The Internet
Lines: 54


Ken Bosward ([e-mail]):
> Any ideas for a "beat the buzzer" game to make a training class more
> interesting?  There will be around 8 users in the same group with VT100/220
> terminals and OPER privilege. I have trialled a program using $BRKTHRU to
> send messages to my terminal, which works ok although occasionally some
> messages get lost if they all arrive in quick succession.
>
> I would like ideas to achieve the following:
  ... [stuff deleted] ...
> - ensuring that the first person to press his button really *is* the first
>   to get through to my terminal.
>
> Are there better methods than using $BRKTHRU (e.g. Common Event Flags and
> Global Sections)?

Think about using BRKTHRU in combination with the lock manager (or "lock
management services" -- I'm at home late at night and don't remember the
official name -- it's in the System Services docs).

It's been several years since I did programming with locks, so I do not
remember the details, but the basic idea is that the program that a student
would run to ring the bell would grab an exclusive lock on a named resource,
say, "WINNER," then use BRKTHRU to bong the bell, then wait awhile to ensure
that the competing students are foiled, and finally release the lock.
Identical programs run by the losers would fail when they try to lock the
WINNER resource, and could then write a "You lose" message to their terminals
without bonging anything (except themselves or the other losers, depending on
how mean you want to be to the losers).  The neat thing here is that the
programs run by the losers would know that they lost the game internally, and
you could use that knowledge for any purpose, from silence to flames, as you
see fit.

This is vintage 1985 knowledge.  Then, anyway, the system services of interest
were ENQ and DEQ.  You may or may not need to install the programs with SYSLCK
privilege, in addition to OPER for BRKTHRU, depending on your circumstances.
Also see the system service GETLKI.  As I recall, the only difficult thing
about ENQ/DEQ in 1985 was getting used to the idea that the lock was on a
name, not a thing.

Time check:  It is January 20.  Last time I sent a response to the group,
my post was marooned somewhere (sri.com?) for three days before distribution,
and I was criticised for being out-of-touch with the thread.

Apologies for my 1985 recollections, but this is just a suggestion about where
to look for a winner-takes-all enforcer in the system services manual anyway.
Supposing that this post isn't marooned again, someone who has worked with
locks recently might be inspired to post some modern 1993 poop on the subject,
which might be more helpful.

      Lester Powers
      [e-mail]