Believe the behavior is as expected, as IDN_SELECTFEED (usually aliased from ELEKTRON) is a content-case service, so a lock is required as input, to check content-based service permissions.
The usage should be:
dacsSubscribeClient [-D dacs_daemon] -S service_name -u username [-p position] [-a appID] [-L log_level] [-T wait_time] [-i item_name] pe1 [pe2 [peN]]
From the list of PEs a dacs lock is going to be generated, that will allow to check subscription on a content-based service.
Please see this previous discussion thread for additional details.
As Permission Entity for INTC.O is 74, the correct check, under certain assumptions, should be
dacsSubscribeClient -D narvlii02156.xmp.net.intra:8211 -S IDN_SELECTFEED -u wuk -p 10.111.166.82/net -a 304 -i INTC.O 74
You should see:
allowed access item name INTC.O , PE 74
1. OpenDACS API is a view into DACS, DACS is a complex system, and if in your local DACS the definition in DACS is not exactly as we expect, then the result via OpenDACS will be different as well. In this case, consult with your local DACS admin/group and find out what is defined within your local DACS and consequently, what to expect on the check.
2. Item name is not mandatory for this example usage, what is being checked is Permssion Enttity within DACS, i.e.
dacsSubscribeClient -D narvlii02156.xmp.net.intra:8211 -S IDN_SELECTFEED -u wuk -p 10.111.166.82/net -a 304 74
will also be true (assuming the definition for your user in DACS is as we expect it.
... -i INTC.O 75
denied access item name INTC.O , PE 75
that is, if your user is not permissioned for PE = 75. if the user is permissioned, it will be allowed.
In my opinion, OpenDACS API usage is so closely related to DACS definitions, that one can not proceed on integration and design without OpenDACS without knowing exactly what is defined in DACS at every step.