Why would one want to do such a thing? A major reason is that the HP-UX SNMP daemon only supports the EMANATE protocol for subagents; this means that subagents that support the AgentX protocol (which NET-SNMP – provided as part of HP’s Internet Express – supports) are not supported and cannot be accessed via HP’s SNMP daemon.
However, the HP-UX specific information is only available via the HP-UX native SNMP daemon. What is the answer?
Change one or the other to run on a non-native port, that’s the answer. With the two daemons listening on different ports – in essence, acting like to discrete damons – the capabilities of both can be exploited. Since the native HP-UX snmp daemon does not provide the capability of specifying the port, the net-snmp daemon can be moved – and it is relatively trivial to do so as well.
There is probably already a line that says:
agentaddress 161
Change this line to a new port – I used 166:
agentaddress 166
Restart the daemon. Once the NET-SNMP daemon has been moved, enable HP’s SNMP daemon (if you’ve not already done so) and start it up again:
cd /sbin/init.d
SnmpMaster start
This should enable your two SNMP daemons on different ports. Now you can access whichever one holds the data you want. For example, using the command snmpwalk, getting Caché data can be as simple as:
snmpwalk -m ALL -v 2c -c public my:166 .1.3.6.1.4.1.16563
Whereas getting HP-specific data can be retrieved this way:
snmpwalk -m ALL -v 2c -c public my .1.3.6.1.4.1.11
Note the contrast between the two commands: one accesses the host my with the standard port (my); one uses the host my with the port 166 (my:166).
As a side note, note that Caché provides AgentX subagents, and note, too, that OpenVMS supports SNMP and AgentX as of v8.x. Thus, there’s no fighting with the SNMP daemon on OpenVMS.