From: MERC::"uunet!WKUVX1.BITNET!MacroMan" 24-MAR-1993 03:59:57.90 To: MACRO32@WKUVX1.BITNET CC: Subj: Re: Trapping OPCOM messages in Detached proc In article <1993Mar23.154622.1@scsvxb.unocal.com>, ucisrcy@scsvxb.unocal.com writes: > I'd like to know if anybody out there has attempted to intercept and > process OPCOM messages via a detached process. yep! > If so, and you would like to share the code (or at least the general procedure) with me, I'd appreciate it! the code I did is part of a commercial product. However, similar things have appeared on DECUS VAX SIG symposium tapes; there's no secret about the general technique: The key is VMS's pseudoterminal driver. (I/O User's Reference Manual, Part I, Chapter 9 or so.) Create a pseudoterminal, associate a mailbox with it, enable it as an opcom terminal ($SNDOPR system service), set it for nobroadcast and broadcast mailbox ($QIOW SETMODE). The opcom messages then get sent to the associated malbox. You read them and do what you want with them. All of this worked the way the documentation said it would; there were no surprises. btw, using the broadcast mailbox is much better than reading the messages from the "backside" of the pseudoterminal directly. When you get them in the mailbox they'll be neatly packaged, one broadcast message per mailbox message (with imbedded CRLFs for multiple lines). If you read them directly from the backside of the pty there is no good way to figure out the boundaries of the messages. Either way, you will have to parse the messages to extract data like type of request, associated username, request number, and so on, out of them. This is non-trivial but quite doable. It is possible to steal the pointer to the OPCOM process's mailbox; this gets you the "binary" messages before OPCOM broadcasts them everywhere. However a lot of the info you need will still be in free-form text, and you will be using an undocumented interface besides... I looked at this approach and rejected it. > We have a large operations group that is based on an IBM system. My sympathies. :-) --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA drivers, internals, networks, applications, and training for VMS and Windows NT uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG Internet: jeh@cmkrnl.com Uucp: uunet!cmkrnl!jeh CIS: 74140,2055