- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logic...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-24-2004 05:59 AM
тАО06-24-2004 05:59 AM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-24-2004 08:50 AM
тАО06-24-2004 08:50 AM
SolutionLike 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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-24-2004 08:55 AM
тАО06-24-2004 08:55 AM
Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2004 01:44 AM
тАО06-25-2004 01:44 AM
Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2004 02:35 AM
тАО06-25-2004 02:35 AM
Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-29-2004 11:09 AM
тАО06-29-2004 11:09 AM
Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2004 01:49 AM
тАО06-30-2004 01:49 AM
Re: OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals
In the end it does what I want. OPERxx classes wait for another day ;-)
Cheers,
Art