OPERATOR.LOG flush interval or unpriv user triggers

[Craig A]

I'm aware of this article:

http://h71000.www7.hp.com/wizard/wiz_7763.html

but it doesn't help much.

Basically, I need an unprivileged user to be able to trigger an event after an error.

Users will typically have TMPMBX, NETMBX and cannot have write access to files/directories they do not own.

I've dedicated an OPCOM class and have the DCL sending REQUEST messages to this class. then I have abatch job running under a priileged account which interrogates the OPERATOR.LOG for actions whcih it then completes.

The "problem" is that the OPERATOR.LOG file only seems to get flushed periodically (however, it seems to be more often than the every 5 minutes mention in the original article).

This delay isn't the end of the world but I'd like to reduce it if at all possible so was wondering if there have been any developments in this area in recent years (we are running OpenVMS v8.3 on Alpha) or whether the folks here have any other ideas on how an unprivileged user can send trigger events.

In any event both the trigger code and the listener code needs to be in DCL.

Cheers

Craig A

[Joseph Huber_1]

Besides the flush delay, are You sure the OPCOM is logging alsways/on all nodes to a file ?

A much simpler solution could be:

The privileged process (request receiver) establishes a permanent mailbox.
Then it loops to read the mailbox and filters/executes the requests message.

The unprivileged processes (requesters) do a write to the permanent mailbox.
The mailbox-write can be in the simplest case a DCL WRITE.

Mailbox I/O doing e.g. non-blocking read/write can be found in Ian Miller's MBU utility (freeware archives),
or in my MBX routines
http://wwwvms.mpp.mpg.de/~huber/util/main/mbx.html

[The Brit]

Joseph,

You mentioned in your response that

> The mailbox-write can be in the simplest case a DCL WRITE.

What would be the sequence of DCL commands to achieve this? Similarly, what would be the sequence to retrieve the message?

Dave.

[Joseph Huber_1]

In DCL, say the mailbox be MBAnnn: (or a logical created with the mailbox, say RQMBX), it is as simple as:
OPEN/READ/WRITE mbx MBAnnn: (or RQMBX:)
READ/ERROR=RFAIL mbx symbol

WRITE mbx "my request"

DCL mailbox read/write is synchronous, i.e. it does not return from read until a message is written into it.
If kind of async write/read is needed (queuing for several writers), then non-blocking write (and/or read) has to be done using QIOs as in the programs I mentioned in my previous reply.

In fairly recent VMS versions (I think 7.3-2 and later), permanent mailboxes can be created by CREATE/MAILBOX commands.
In earlier versions, one needs a program like my CREMBX, or a trick (I think it is described in the VMS FAQ): create a subprocess, which creates a temporary mailbox, then defines a group or system logical to point to it for the users.

An example of a mailbox-creating subprocess is e.g.
http://www.mpp.mpg.de/~huber/vmssig/src/COM/CREATE_MBX.COM CREA_MAILBOX_FROM_DCL.COM

[Joseph Huber_1]

Sorry, in my reply was a wrong link pasted, the better of the two command files is

An example of a mailbox-creating subprocess is e.g.
http://www.mpp.mpg.de/~huber/vmssig/src/COM/CREA_MAILBOX_FROM_DCL.COM

Here replace the define/job by define/group or define/system if the mailbox should be accessible outside a job tree.

[Joseph Huber_1]

One addition:
if You create the mailbox using the above sub-process method, and if creator and user (request writer) is not the same UIC, then the protection of the mailbox must be set to allow writing and logical IO:

set protection=G:RWL/device MBAnnn:
or
set protection=W:RWL/device MBAnnn:

[John Gillings]

Craig,

V8 and above can do this all from DCL.

Your action process runs with whatever privilges are needed to perform the actions, plus SYSNAM anmd PRMMBX. It starts with:

$ CREATE/MAILBOX/PERMANENT TRIGGER_EVENT
$ OPEN/READ TRIGGER TRIGGER_EVENT

its event loop looks like:

$ Loop: READ TRIGGER EVENT
$ parse and execute event
$ GOTO Loop

You should have a "terminate" event, which does:

$ CLOSE TRIGGER
$ DELETE/MAILBOX TRIGGER_EVENT

You should also set protection and/or ACL on TRIGGER_EVENT so only authorized users can send messages. I'd suggest using an identifier GRANTed to authorized users.

Note that TRIGGER_EVENT becomes a SYSTEM logical name, so make sure whatever name you choose doesn't clash with anything else.


From your unprivileged users you could OPEN the mailbox, WRITE then CLOSE, but my preference would be a one liner:

$ PIPE WRITE SYS$OUTPUT "Some Event" > TRIGGER_EVENT

This avoids the issue of the mailbox being left open, which would prevent the action process from closing and deleting it, since it's a single PIPE command it executes in the context of the current process, so there's no process creation cost.

A safer version of the user side would be:

$ PIPE WRITE SYS$OUTPUT "Some Event" > 'F$TRNLNM("TRIGGER_EVENT")'

The difference is the first would silently create a file in the local directory if the mailbox didn't exist. The second version would fail with:

%DCL-W-INCREDSYN, incomplete redirection syntax; supply missing file parameter

so your sender would know it failed.