Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals

SOLVED
Go to solution
Art Wiens
Respected Contributor

OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals

I recently brought two VAX's into our main cluster. The developers of the apps on these systems thought it was a "great idea" to make copious use of $ REQUEST to detail the progress of a nightly production run. That was fine when they were the only two nodes in their own cluster. All nodes are now being "sprayed" with OPCOM messages all night long.

Does anyone have any experience with the two logicals noted in the title? It sounds like the ticket to supress the unwanted messages. Any "gotcha's" if I define OPC$ALLOW_INBOUND on the the systems that I don't want to see these OPCOM's on? I assume OPCOM needs to be restarted for them to take effect?

I would prefer to set OPC$ALLOW_OUTBOUND on the offending systems, but they are VAX/VMS v6.2 ... release notes say they were new logicals for v7.

I've also thought about defining OPERx classes, but that would mean editing "tons" of DCL procedures.

Thanks as always,
Art
6 REPLIES
John Gillings
Honored Contributor
Solution

Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals

Art,

Like the release notes say - new in V7. I've confirmed that it does not work under V6.2. If you were on V7, yes you would have to restart OPCOM for changes in logical names to take effect.

So you're left with OPERx classes (which is a better solution anyway).

Editing "tons" of things the same way is what computers are really good at! I'd write a little TPU or EVE script to do the change, then use a SEARCH command to find the names of the procedures you want to change. Edit that list of names into a procedure to invoke the script. Only a few minutes work!

A crucible of informative mistakes
Art Wiens
Respected Contributor

Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals

No no, mixed-mode, the other nodes in the cluster are Alpha's running v7.2-2, so the idea is to block them from coming in, instead of (desired) blocking from going out.

The VAX's are in the cluster to take advantage of the HSG80 SAN. Even served over ethernet, disk access is still much better than their previous DSSI->HSD05->SCSI disks.

Art
Keith Parris
Trusted Contributor

Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals

About the only disadvantage I see of using OPC$ALLOW_INBOUND on the Alphas is they will also block OPCOM messages from each other, not just from the VAXen.

Long-term, I like the idea of either a separate OPCOM class, or preferably, for the programmers to use another method of notification entirely. (And there needs to be an easy way to turn it off, as well.)

I've seen cases where an application written to use OPCOM for notification ended up generating millions of lines of OPCOM output per hour after the business volume had grown over the years and was now operating in a large cluster. It actually slowed the whole cluster down, and OPCOM got behind by 2.5 hours of output at peak times, which made OPCOM pretty useless (coupled with having to wade through the huge volume of OPCOM messages to find the important system-related messages). I finally ended up commenting-out the worst-offending OPCOM call in the application code myself to stop them.
Art Wiens
Respected Contributor

Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals

"About the only disadvantage I see of using OPC$ALLOW_INBOUND on the Alphas is they will also block OPCOM messages from each other, not just from the VAXen."

I appreciate that and that's why I'm a tad hesitant, but in the end, member nodes don't _really_ rely on OPCOM for anything right? If there's a message that needs to be replied to, it's up to a human and the operators "should" be logged into the node they're running production on.

I agree OPERx would be cleaner, but one logical is way easier...and it's Friday ;-)

Cheers,
Art
Lawrence Czlapinski
Trusted Contributor

Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals

1. No experience with those OPC logicals.
2. Your idea is worth trying. I can't think of any "gotcha's". If you turned the messages off, you could lose some startup OPCOM messages from other nodes. Most OPCOM messages from other nodes aren't that important or are redundant.
3. When developers use OPCOMS, they should be using $REQUEST/TO=OPERxx.
You could designate a different oper number for each system. If you ever need to change the $ REQUEST, you can easily do it with the EDIT REPLACE command. You could do it over time. Then you can turn off the OPERxx classes you don't want. It isn't a good idea for the developers to use a lot of OPCOMS.
If something goes wrong, the messages can fill up the SYSTEM disk and lock up the systems using that system disk due to insufficent SYSTEM disk space.
4. Application logfiles should preferably be on a non-SYSTEM disk for the same reason.
Art Wiens
Respected Contributor

Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals

I went ahead and defined OPC$ALLOW_INBOUND to be FALSE on the Alpha's and it does what it's supposed to do. If I REQUEST on the VAX, it does not appear on the Alpha. However the curious thing, when I REQUEST on the Alpha, it also does not appear on the VAX!? I have not defined OPC$ALLOW_OUTBOUND , nor did I define either logical on the VAX's.

In the end it does what I want. OPERxx classes wait for another day ;-)

Cheers,
Art