topic Re: Avoid intrusion alerts for DECnet objects in Operating System - OpenVMS

Avoid intrusion alerts for DECnet objects

Hans Adriaanse — Thu, 13 Apr 2006 03:48:11 GMT

Hello,

I have the next situation: one system connects to a DECnet object on another system. This DECnet is created in an application. So if the application is not running (planned or unplanned), the object is not available. But each time the other system tries to connect, I get a security alert. I am not allowed to disable this security alert (security policy of the company). I thought about the next solution: install a dummy object that closes each incomming connection immediately. When the application starts, it first removes this dummy object and installs itself as that object. But when the applciation crashes, I cannot restore the dummy object. Is it possible to installe 2 objects with the same name, but with a difference in priority or something like that.
Please some suggestions to avoid the intrusion alerts without affecting the security settings.

Thanks in advance,
Hans

Re: Avoid intrusion alerts for DECnet objects

Volker Halle — Thu, 13 Apr 2006 04:50:25 GMT

Hans,

I'm pretty sure, that you cannot install two DECnet objects (in NCL speak: session control applications) with the same name or number.

You may need to write some checking DCL procedure (as a batch or detached job), which checks if the real application has crashed and re-instates the dummy object. Depending on how the application process is running (detached process ?), you could wrap it into a DCL procedure, which sets up the dummy object, if the real application program exists.

Volker.

Re: Avoid intrusion alerts for DECnet objects

John Travell — Tue, 18 Apr 2006 05:36:48 GMT

I have implemented something similar to what Volker suggests myself.
1. create a batch queue with JOB_LIMIT=1.
2. Wrap your application in a procedure that:
__2a. checks the queue to ensure that a second copy of the job is pending in the queue.
__2b. notifies you if the 'spare' job is missing.
__2c. resubmits itself.
3. submit your job and forget it until you get a notification of failure, then check the logfile to see WHY it failed.
4. fix the cause of the failure, goto 3.

I could supply some sample dcl, but I would have to spend some time anonymising it first.

John T.

Re: Avoid intrusion alerts for DECnet objects

Hans Adriaanse — Tue, 18 Apr 2006 08:45:49 GMT

Thank you guys. This is the best solution I can think of (not optimal, but the best).

Thanx.

Re: Avoid intrusion alerts for DECnet objects

John Travell — Tue, 18 Apr 2006 17:25:36 GMT

Hans, Can you assign points for this topic, you seem to have done so for only half of the replies to your questions. It is the only way to reward contributors. Remember that you can assign zero points if a comment has zero value...