Jack Trachtman "I was hoping to find a way to do this in DCL."
Please explain what you mean by "in DCL". If you mean "pure DCL" where no images are activated, then as Hoff said, there isn't anything in stock VMS that does what you want.
PPF the program is a non-privileged program that can determine the file specification associated with any process permanent file. It sets DCL symbols (up to three, which can be quite different, see the comments in the source code). Other than not being guaranteed to be on every VMS system, this works well with DCL. As written, you have no choice of the symbols that the file name will be placed in, other than recompiling the code (in MACRO32, so that is on every VMS system).
There is no lexical function f$ppf to provide the same info that the ppf program does. (at least not in any version <= 8.3, and I am not aware of any plans for it).
This will work fine as long as someone is not actively trying to avoid it. If you put this into the command procedure, you will need to write the results somewhere, and if you are not protecting the source command procedure against read access, you can't prevent it being copied and being edited to remove any auditing capability you place into it. Also, I am not aware of any way to have DCL open a file using only trusted logical names, so for example, it you were writing to an audit file that was opened using a file name containing logical names, any of the logical names could be replaced by the user's process or job level logical names to point to their own "audit file".
I doubt the command procedure itself is "pure dcl", so if you want to be able to audit the use of programs, and where they write their output, you should be doing it in the program. You have much more control there, and you can then get more information from VMS, i.e. image level accounting and auditing will be able to show you what image accessed the file, etc.
You also have the ability to grant privilege to a program. This gives you the capability to allow a non-privileged user write access to an audit file they do not have write access to from DCL, via subsystem identifiers or a program installed with privilege.
Be aware that it is easy to introduce security vulnerabilities by installing a program with privilege if you are not extremely diligent and paranoid.
If you are still interested in the PPF program, see my comment dated Jun 22, 2007 21:00:12 GMT in the following thread
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1138609It has the PPF.MAR file attached as a text document, so it will display correctly on windows without jumping through hoops.
It is a useful program, and does work for the case @file/out=, but I don't think you will be able to use it as an auditing tool.
And if you are considering using mail to notify you, try this:
$ def/user mail mymail
and use your imagination as to how that can defeat what you want.
Getting the "raw" command line isn't trivial (at least in my experience). There are ways to get the commands from the recall buffer, but that works only for interactive processes, and can be erased without privilege. (recall/erase).
You may want to look at the jump package on the freeware, but that won't be transparent to the user. I am not sure it this the audit package, is still available, it was a commercial package that attempted to keep a record of what was sent to the terminal in a tamperproof way. I have no experience with the package. It was related to the Raxco support tool carboncopy, but couldn't be turned off by the (unprivileged) user.
If you haven't already read it, read the article referenced in Hoff's reply dated Jun 25, 2007 20:35:55 GMT.
Good luck,
Jon
it depends
